Common Control and Measurement Plane
charter-ietf-ccamp-09

I have a few suggestions that I hope are helpful.

Overview:
OLD
"The WG develops protocol extensions related to non-packet technologies networks including for some routing and signaling protocols developed by other routing area WGs."

NEW
"The WG develops protocol extensions related to non-packet technologies networks, including some for routing and signaling protocols developed by other routing area WGs."

Work scope:
"Description of non-packet-specific aspects of TE including for multi-area/multi-AS/multi-layer scenarios and definition of protocol extensions for them."

Expand the acronym "TE" here, or wherever it is first used. It is currently expanded in the last bullet of the work scope.

Coordination:
OLD
"The protocol extension work (especially definition of protocol formats and procedures) done in the WG will be done either jointly with or through reviews from the WGs such as LSR and TEAS WGs that maintain those base protocols (viz. OSPF, IS-IS, and RSVP-TE)"

NEW
"The protocol extension work, especially definition of protocol formats and procedures, will be done jointly with, or through reviews from, the WGs (e.g., LSR, TEAS) that maintain those base protocols (e.g., OSPF, IS-IS, RSVP-TE)."

I'm not going to send this one, because it is super simple:


typo?  transpoonders/transponders?

Thanks for the rechartering and for being clear about the intended publication status of the documents.

Nevertheless about the 2nd paragrapg, I find the use of 'non-packet' in the current and proposed charter rather vague, should it rather be 'sub-IP frames' or 'layer 1-2 frames' ? Mixing layer-2 Ethernet switches with layer-1 DWDM/OXC/... seems weird to me.

Thanks to Ketan to add more guardrails on the demarcation between LSR and CCAMP WG responsibilities

-------------------------------

Hi all,

Please find my comments on the proposed charter. The current charter already covers CCAMP’s scope well, however I would like clearer wording on the boundary with LSR.

I do not assume CCAMP will define new IGP TLVs, as this is within LSR’s scope. The text also suggests using IS-IS/OSPF to flood non-routing information. If that is intended, it should be discussed with LSR. The IGP is an foundational underlay technology; adding non-routing data impacts the LSDB, flooding, and stability.

Some observations from the newly proposed Charter:

"
- Functional specification of extensions for GMPLS-related routing (OSPF, IS-IS) and signaling (RSVP-TE) protocols required for path establishment and maintenance in non-packet technology-specific networks.
"

GV> Any new OSPF/IS-IS procedures should be defined with LSR. It would help to list which extensions CCAMP owns and how joint work with LSR is handled.

"
- Define how the properties of network resources gathered by a measurement protocol (or by other means such as configuration) can be distributed in existing routing protocols, such as OSPF, IS-IS, and BGP-LS.
"

GV> Using IGPs to distribute non-routing properties tends to be avoided by IGPs. It is not what IGPs were originally designed for. This needs clearer scope, requirements, and alignment with LSR.

"
- Maintenance of specifications related to protocol extensions and data models for non-packet technology-specific networks (Ethernet, TDM, OTN) published by CCAMP. This includes extensions to RSVP-TE, OSPF, IS-IS, and Link Management Protocol (LMP).
"

GV> Does this imply CCAMP owns extensions to these protocols instead of LSR?

"
Coordination:
The protocol extension work (especially definition of protocol formats and procedures) done in the WG will be done either jointly or in coordination with the WGs such as LSR and TEAS WGs that maintain those base protocols (viz. OSPF, IS-IS, and RSVP-TE). The WG will coordinate with the TEAS WG on all aspects related to TE and specifically to determine whether such protocol extensions should be generalized for TE in any network. The WG will coordinate with the PCE WG when it comes to the Path Computation Element Protocol (PCEP) and path computation aspects in non-packet technology-specific networks. Data model design will be coordinated with other related WGs, such as TEAS, OPSAWG, IVY, NMOP, and GREEN.
"

GV> This conflicts with earlier text implying CCAMP ownership by work scope. Please clarify responsibilities and the boundary with LSR at relevant places.

Be well,
Thanks,
G/
Routing AD

"WG", paragraph 0
> ##Work scope:
> CCAMP WG work scope includes:
> - Definition of protocol-independent metrics and parameters (measurement
> attributes) for describing links and paths that are required for routing and
> signaling in non-packet technology-specific networks. These will be developed
> in conjunction with requests and requirements from other WGs to ensure overall
> usefulness. - Functional specification of extensions for GMPLS-related routing
> (OSPF, IS-IS) and signaling (RSVP-TE) protocols required for path establishment
> and maintenance in non-packet technology-specific networks. - Description of
> non-packet-specific aspects of TE including for multi-area/multi-AS/multi-layer
> scenarios and definition of protocol extensions for them. - Define how the
> properties of network resources gathered by a measurement protocol (or by other
> means such as configuration) can be distributed in existing routing protocols,
> such as OSPF, IS-IS, and BGP-LS. - Necessary protocol extensions to support
> data planes standardized outside the IETF (e.g. ITU-T), where such extensions
> fall within the established architectural scope of the WG. This work will be
> performed in coordination with the relevant SDOs. The definition, modification,
> or evolution of the data plane itself is out of scope. - Definition of
> technology-specific data models for network control and management of
> non-packet technology-specific networks, including network representation (from
> network, connection, and service perspectives) and management functionalities.
> - Definition of management objects (e.g., as part YANG data models) and control
> of OAM techniques relevant to the protocols and extensions specified within the
> WG in alignment with OAM specifications developed by other WGs. - The
> applicability of Abstraction and Control of Traffic Engineering (TE) Networks
> (ACTN) for non-packet technology networks.

The approved charter (08) explicitly listed Link Management Protocol (LMP) 
maintenance as both a work scope item and a current focus item. The proposed 
charter removes LMP from both lists — it appears only parenthetically as "LMP" 
in the maintenance bullet of Current Focus.

LMP is thus retained implicitly in Current Focus, but removed from Work Scope. 
This creates an inconsistency in my mind: if LMP maintenance is in Current Focus, it should 
be in Work Scope. More importantly, if the WG is intentionally reducing its LMP scope 
(e.g., because LMP maintenance activity has wound down), this should be stated 
explicitly. The milestone list still includes draft-ietf-ccamp-dwdm-if-lmp (twice), 
indicating active LMP work remains. The scope text should be reconciled with what 
the WG is actually doing.

"PCE", paragraph 5
> Feb 2026 - Submit DWDM Interface YANG model to IESG for review
>            o draft-ietf-ccamp-dwdm-if-param-yang
> 
> Mar 2026 - Adopt client tunnel YANG model working group draft
> 
> Mar 2026 - Submit Transceiver-Related Information within RSVP-TE Signaling to IESG for
>            review
>            o draft-ietf-ccamp-tsvmode-signaling

The proposed charter includes these three milestones:
Past-dated milestones at the time of charter approval are not a blocking issue, 
but they should either be updated to reflect the actual state (e.g., "Completed" or 
given realistic future dates) or removed. Having multiple already-elapsed milestones 
makes the charter appear stale.

"PCE", paragraph 16
> Jul 2027 - Submit Data Modelling and Gap Analysis of Optical Pluggables in Packet Over
>            Optical Network to IESG for review
>            o draft-ietf-ccamp-actn-poi-pluggable-usecases-gaps

Isn't this a gap analysis/use-case document, and not a protocol or data model specification? 
The charter should be clearer about what normative deliverables are expected from this new work area.

"PCE", paragraph 19
> Jun 2028 - Submit DWDM interface LMP and YANG to IESG for review
>            o draft-ietf-ccamp-dwdm-if-lmp

The milestone list contains draft-ietf-ccamp-dwdm-if-lmp twice:

Here and as May 2027: "Submit DWDM interface LMP and YANG to IESG for review".
Is this a cut-and-paste error?