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

[Ballot comment]
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.

[Ballot comment]
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)."

[Ballot comment]
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

Changed charter milestone "Submit DWDM interface LMP and YANG to IESG for review", set description to "Submit DWDM interface LMP and YANG to IESG for publication"

Changed charter milestone "Submit Data model for OTN end WDM path computation to IESG for review", set description to "Submit Data model for OTN end WDM path computation to IESG for publication"

Changed charter milestone "Submit Data Model for Ethernet topology to IESG for review", set description to "Submit Data Model for Ethernet topology to IESG for publication"

Changed charter milestone "Submit Data Modelling and Gap Analysis of Optical Pluggables in Packet Over Optical Network to IESG for review", set description to "Submit Data Modelling and Gap Analysis of Optical Pluggables in Packet Over Optical Network to IESG for publication"

Changed charter milestone "Submit YANG Data Model for FlexE Management to IESG for review", set description to "Submit YANG Data Model for FlexE Management to IESG for publication"

Changed charter milestone "Submit DWDM interface LMP and YANG to IESG for review", set description to "Submit DWDM interface LMP and YANG to IESG for publication"

Changed charter milestone "Submit YANG model of OTN topology & Flexi-grid topology to IESG for review", set description to "Submit YANG model of OTN topology & Flexi-grid topology to IESG for publication"

Changed charter milestone ""Submit Integrating YANG Configuration and Management into an ACTN System for Optical Networks to IESG for review", set description to "Submit Integrating YANG Configuration and Management into an ACTN System for Optical Networks to IESG for publication"

Changed charter milestone "Submit YANG modelling for flexi grid draft to IESG for review", set description to "Submit YANG modelling for flexi grid draft to IESG for publication"

Changed charter milestone "Submit Transceiver-Related Information within RSVP-TE Signaling to IESG for review", set description to "Submit Transceiver-Related Information within RSVP-TE Signaling to IESG for publication"

[Ballot block]
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

[Ballot comment]
"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?

[Ballot comment]
Hi all,

Assuming [1], this version looks good to me.

I have only nitty nits this round:

# Format parallelism

OLD:
  Overview:
  ..
  Work scope:
  ..
  Current Focus
  ..
  Coordination:


NEW:
  Overview
  ..
  Work scope
  ..
  Current Focus
  ..
  Coordination

Or

NEW:
  Overview:
  ..
  Work scope:
  ..
  Current Focus:
  ..
  Coordination:


# Publication is the goal, not the review per se

All "Submit xxx to IESG for review” constructs should be "Submit xxx to IESG for publication”.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/ccamp/abha9feKn_3mm17sLf0zFaFPja4/

[Ballot comment]
Hi all,

Thanks for the changes made so far [1]. These are good ones as it insists that the models are technology-specific.

Ketan's proposal [2] makes sense to me.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-ccamp%2Fwithmilestones-08-02.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-ccamp%2Fwithmilestones-08-03.txt&difftype=--hwdiff

[2] https://mailarchive.ietf.org/arch/msg/ccamp/abha9feKn_3mm17sLf0zFaFPja4/

[Ballot block]
Is it possible to make the following work scope more specific as it would seem to enable arbitrary protocol extensions as long as the specification comes from another SDO:

"- Protocol work to support data planes that have already been approved by another Standards Development Organizations (SDOs) (e.g., the ITU-T). However, the specification or modification of data planes is out of scope of this WG."

Changed charter milestone "First version of client signal performance monitoring YANG model working group draft", set description to "Adopt client signal performance monitoring YANG model working group draft", removed draft-zheng-ccamp-client-pm-yang from milestone

Changed charter milestone "First version of YANG model of Ethernet Tunnel Working Group drafts", set description to "Adopt YANG model of Ethernet Tunnel Working Group draft", removed draft-zheng-ccamp-client-tunnel-yang from milestone

Changed charter milestone "First version of client tunnel YANG model working group draft", set description to "Adopt client tunnel YANG model working group draft", removed draft-zheng-ccamp-client-tunnel-yang from milestone

[Ballot comment]
> Definition of data models
> and management objects for network control and management of non-packet
> technology-specific network elements, topologies, and abstractions.

After discussing with Ketan, I am adding this as a note that the ONSEN BoF is
scheduled for IETF 125. If that BoF results in the WG being formed, then
the responsible ADs will come together to discuss how the work around
data modules for abstraction will be handled as we advance.

Separate from that, there is work around data modules for network topology
that is already underway in the IVY WG. Therefore, it is not clear whether
the topology work identified here is different from the work in IVY.
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"YANG", paragraph 2
> as standards track RFCs with an exception of a few documents (e.g., architec
>                                ^^^^^^^^^^^^
The usual collocation for "exception" in this context is "to", not "of". Did
you mean "exception to"?

[Ballot block]
Hi all,

Thank you for preparing this charter refresh.

The proposed updates looks good, overall. However, there is one point that I think needs some discussion:

# Abstractions

CURRENT:
* Definition of 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 data models and management objects for network control and management of non-packet technology-specific network elements, topologies, and abstractions.

As you know, there is an ongoing effort to have a single group in the IETF (ONSEN BoF) to be the focal point for service and network abstractions within the IETF. Also, that is motivated by having more emphasis on operational needs of such abstractions.

I appreciate that group is not on rails yet, but I think this is worth careful consideration.

[Ballot comment]
# How to interpret the following?

CURRENT:
Mar 2026 - First version of client tunnel YANG model working group draft
          o draft-zheng-ccamp-client-tunnel-yang

Apr 2026 - First version of YANG model of Ethernet Tunnel Working Group drafts
          o draft-zheng-ccamp-client-tunnel-yang

Jul 2026 - First version of client signal performance monitoring YANG model working group
          draft
          o draft-zheng-ccamp-client-pm-yang

Does the WG plan to use these Individual I-Ds as WG documents straight?

If that’s not the intent, then consider unlink the drafts from these milestones.

## Also, I guess by “first version” you meant adoption by the WG. If so, please consider updating these to say that.

[Ballot comment]
No objection to this, but I do agree with Eric that an expansion of some of the acronyms may be useful - purely for people who are looking for working groups they may be interested in joining and partaking it and who don't wanna have to jump through hoops trying to figure out all the acryonyms in the charter :)

[Ballot comment]
The term "network slicing" was not mentioned in the descriptive part of the charter however it is in the working group scope. To understand the scope better one need to understand the term better. I would suggest to be more descriptive about it so the scope is better understood.

[Ballot comment]
I understand that this revised charter is based on the existing -08 and inherits therefore some nits:

- many acronyms are not expanded (they do not need because they are in the RFC editor list but I had to jump to that list to understand), unsure whether OEO, ROADM, ... are really useful and current

- the use of "measurement" is also weird in this case but too late to change I guess ;-)

- s/been approved by another Standards Development Organization/been specified by another Standards Development Organization/ ?

- nit: sometimes it is IS-IS, other times it is ISIS ;-)

- s/The CCAMP WG currently works/The CCAMP WG is tasked to work/ ?

All in all, no objection as the rechartering appears more like a refresh/cleanup of the existing charter. But, this is really a broad scope WG.

[Ballot comment]
I understand that this revised charter is based on the existing -08 and inherits therefore some nits:

- many acronyms are not expanded (they do not need because they are in the RFC editor list but I had to jump to that list to understand), unsure whether OEO, ROADM, ... are really useful and current

- the use of "measurement" is also weird in this case but too late to change I guess ;-)

- s/been approved by another Standards Development Organization/been specified by another Standards Development Organization/ ?

- nit: sometimes it is IS-IS, other times it is ISIS ;-)

- s/The CCAMP WG currently works/The CCAMP WG is tasked to work/ ?

All in all, no objection has the rechartering appears more like a refresh/cleanup of the existing charter. But, this is really a broad scope WG.

Other than formatting (whitespace, etc) the change to the charter is:

OLD:
Data plane: This work will document how to use IP and/or MPLS, and related OAM,
to support a data plane method of flow identification and packet forwarding over
Layer 3. Other IETF defined data plane technologies may also be used.

NEW:
Data plane: This work will document how to use IP and/or MPLS, and related OAM,
to support a data plane method of flow identification, and packet treatment
(including, for example, forwarding, service protection, and queuing) over
Layer 3. Other IETF defined data plane technologies may also be used.

The most immediate effect of this is to put queueing in-charter for DETNET.

Added milestone "Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG", due March 2004, from current group milestones

Added milestone "Identify and document a limited set of candidate solutions for signalling and for measurement.  Among candidate control solutions to be considered are the existing GMPLS drafts.", due February 2001, from current group milestones

[Ballot comment]
OLD:
  Definition of management objects (e.g., as part of MIB modules
  or YANG models) and control of OAM techniques relevant to the
  protocols and extensions specified within the WG.


NEW:
  Definition of management objects (e.g., as part of MIB modules
  or YANG models) and control of OAM techniques relevant to the
  protocols and extensions specified within the WG. The OAM work
  will be synchronized with the LIME WG

[Ballot comment]
The fifth bullet strikes me as a bit odd:

- Determine non-packet-specific aspects of traffic engineering
  including for multi-areas/multi-AS/multi-layer scenarios in
  cooperation with the TEAS and PCE working groups.

"Determine" is a weird verb for a work items. Do you mean "Develop protocols for non-packet-specific aspects of TE", or do you mean something else?