[CCAMP]Re: WG last call on draft-ietf-ccamp-rfc9093-bis-11

["Sergio Belotti (Nokia)" <[e-mail]>]

Hi Daniele, Italo,

I would have a comment/doubt on point 2 :
If I'm not wrong transmitter-tuning-range has been defined in the context of wdm-tunnel to use this grouping  under tx-tune-constraints, to set all the constraint fro the tunnel.
It is not used in Optical Impairment (where frequency range is in fact a capability) . So I would say rw would be correct.

Cheers
Thanks

Sergio

From: Daniele Ceccarelli (dceccare) <dceccare=[e-mail]>
Sent: Wednesday, November 13, 2024 1:50 PM
To: Italo Busi <[e-mail]>; [e-mail]
Subject: [CCAMP]Re: WG last call on draft-ietf-ccamp-rfc9093-bis-11


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Hi Italo,

The addition of the switching-types seemed to have collected good consensus by TEAS/CCAMP so I'd proceed with it.
Regarding 1) and 2) I think they can be managed as a WG LC comments, while il would be great to update security and IANA considerations according to RFC8407bis.

Thanks
Daniele

From: Italo Busi <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 12, 2024 11:52 PM
To: Daniele Ceccarelli (dceccare) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: WG last call on draft-ietf-ccamp-rfc9093-bis-11

Hi Daniele, chairs and WG,

I was forgetting today is the deadline for this WG LC: thanks Daniele for the reminder

As co-author of this draft, I support moving it forward for publication with the few limitations described in the mail from Daniele which, IMHO, can be addressed in future BC model updates if CCAMP WG agrees to address them

Besides the need to add the switching-types for WSON and flexi-grid which all the people who have replied to my previous e-mail have agreed being in the scope of this I-D, I have also spotted two other minor issues that can be addressed as part of the WG LC:


  1.  I think we can remove the base identity otu-type and its derived identities from this version of the module.

IMHO, they will be needed in future when addressing the limitations of the current versions of the models but they are not used by any dependent model so far.

When addressing in the future the identified limitations, we can consider these definitions as the starting point but have more freedom to change them based on the detailed analysis of the solution. Thanks to datatracker and github the current definitions will not be lost even if removed in the next draft update.

  1.  The attributes defined in the grouping transmitter-tuning-range shall be RO since they represent a capability

Based on the comments I have recently received on other drafts in WG LC or IESG processing, we can also consider the following points or wait for comments later in the publication process (no strong opinion on my side, just an early warning):


  1.  YANG tree: shall we move it to an appendix to follow the guidelines in draft-ietf-netmod-rfc8407bis?
  2.  Security Considerations: shall we update it to follow the new template in draft-ietf-netmod-rfc8407bis?
  3.  IANA Considerations: shall we update it to follow section 3.8.3.1 of draft-ietf-netmod-rfc8407bis?

Italo

From: Daniele Ceccarelli (dceccare) <[e-mail]<mailto:[e-mail]>>
Sent: martedì 22 ottobre 2024 14:01
To: [e-mail]<mailto:[e-mail]>
Subject: [CCAMP]WG last call on draft-ietf-ccamp-rfc9093-bis-11

Hi CCAMP,

-- IMPORTANT PREAMBLE--
We have two drafts which have a very good level of maturity, namely RFC9093bis and Optical Impairment aware topology.
The more we work on them and the more disparate use cases pop up. We requested the authors to have the drafts in a status that is "good enough" to address the vast majority of use cases supported by the industry today so that we can progresse the drafts to the next stage and not hold them potentially for ever.

With the actual version of the drafts we should be able to cover all of the use cases with only the following limitations:


  *   Homogenous muxponders: with the present version of the draft we are not able to support use cases of interoperability between muxponder of different versions, and we can use regenerator always at the lowest level (OTU) since we do not have client information when setting up a tunnel. This information is missing today.
  *   Client mapping compatibility: at the moment we can support optical compatibility with operational model, but we don't support client compatibility.

These use cases and others that might come to your mind, if really needed, can be handled by an update to the RFCs at later stages.
- END PREAMBLE --

That said, this starts a 3 weeks working group last call on draft-ietf-ccamp-rfc9093-bis-11.

The last call will last 3 weeks to provide more time for reviewing, given we're approaching IETF 121 meeting. It will end on Tuesday November 12th . Please indicate your support or concern to the mailing list. Review comments and nits are also welcome.
All the IPR declarations from authors and contributors have been collected and can be found in the CCAMP WIKI page: https://wiki.ietf.org/en/group/ccamp

If anyone is willing to be the shepherd for this draft, please feel free to volunteer (authors excluded).

Thanks
Daniele, Fatai, Luis