Re: [CCAMP] WG last call on draft-ietf-ccamp-mw-topo-yang-05

[Italo Busi <[e-mail]>]

Hi all,

I have read the document (as contributor) and I think it is ready to move forward

I just have a couple of comments that IMHO could be addressed as part of the WG LC together with the comments below:

1)      While reading the comment below about the 'mw-tp-option' and the 'mw-link-option' choices, I have realized that also this model would be impacted by the on-going discussion we are having within CCAM WG about the possibility to support a single multi-technology topology instance

      I would suggest to align this model to follow the guidelines we are planning to propose in the upcoming updates for flexi-grid and OTN topology drafts

      In particular, if the proposed guidelines are agreed by the CCAMP WG, I would propose to:
*       Add a 'mw-node' presence container to indicate that the node is MW-capable
*       Update the 'mw-link-choice' container to 'mw-link" presence container to indicate that the link is a MW link: the mw-link-option can then be marked as mandatory as proposed by the editors below
*       Update the 'mw-tp-choice' container to 'mw-tp' presence container to indicate that the TP is a MW TP: the mw-tp-option can then be marked as mandatory as proposed by the editors below

2)      The units "Kbps" for the mw-bandwidth attribute is sometimes ambiguous: it is better to be more specific using "kilobits" or "kilobytes"

      Moreover, for alignment with other YANG models in IETF, please consider also the possibility to change the measurement unit from "Kbps" to "bits/second" (see e.g., RFC 8343)

Thanks, Italo

> -----Original Message-----
> From: Scott Mansfield <[e-mail]>
> Sent: martedì 4 luglio 2023 15:41
> To: tom petch <[e-mail]>; Zhenghaomian
> <zhenghaomian=[e-mail]>; [e-mail]
> Cc: CCAMP Working Group <[e-mail]>
> Subject: Re: [CCAMP] WG last call on draft-ietf-ccamp-mw-topo-yang-05
>
> Tom,
> Thank you for your comprehensive review of the last-call draft.  Please see
> comments and resolutions to your comments inline below (marked by
> <editors></editors>
>
> Let us know if this is satisfactory, or if there is more clarification needed.
>
> Regards,
> -scott.
>
> Snip...
>
> <tp3>
> A follow up to an earlier comment of mine relating to
>        leaf actual-transmitted-level {
>           type decimal64 {
>             fraction-digits 1;
>             range "0..99";
> I was unsure if the maximum value was then 99.9 or 99.0 so I asked on the
> NETMOD list and the answer is 99.0.  I note that the same construct is used in
> RFC8561 so I assume that 99.0 is a magic number in microwave.
>
> <editors>
> The leaf actual-transmitted-level is read-only data, that can take on several
> different values including negative values.  So, since this is not configuration
> data, the editors suggest simply removing the range statement, and modifying
> the description to provide guidance on how to interpret the value.
> </editors>
>
>
> <tp2>
> One more thought.  The Appendices would benefit from a reference to RFC8792.
>
> <editors>
> Agreed, since the tool to fold the text in the examples is used.  Add {{?RFC8792}}
> </editors>
>
>
> <tp>
> 8561 is an import so must be a Normative reference
>
>   "ETSI EN 302 217-1 -
>   "ETSI EN 301 129   -
> need adding as references as a URL so I can see if they are accessible
>
> <editors>
> Add {{!RFC8561}}
>
> Add the following to the markdown for the ETSI references to the Normative
> reference section:
>   EN 302 217-1:
>     title: Fixed Radio Systems; Characteristics and requirements for point-to-point
> equipment and antennas; Part 1: Overview, common characteristics and
> requirements not related to access to radio spectrum
>     author:
>       org: ETSI
>     date: June 2021
>     seriesinfo: ETSI EN 302 217-1
>     target:
> https://www.etsi.org/deliver/etsi_en/302200_302299/30221701/03.03.00_20<https://www.etsi.org/deliver/etsi_en/302200_302299/30221701/03.03.00_20/en_30221701v030300a.pdf>
> /en_30221701v030300a.pdf
>
>   EN 301 129:
>     title: Transmission and Multiplexing (TM); Digital Radio Relay Systems (DRRS);
> Synchronous Digital Hierarchy (SDH); System performance monitoring
> parameters of SDH DRRS
>     author:
>       org: ETSI
>     date: May 1999
>     seriesinfo: ETSI EN 301 129
>     target:
> https://www.etsi.org/deliver/etsi_en/301100_301199/301129/01.01.02_60/e<https://www.etsi.org/deliver/etsi_en/301100_301199/301129/01.01.02_60/en_301129v010102p.pdf>
> n_301129v010102p.pdf
>
> </editors>
>
> 1.1
> should include
> ctp
> rlt
> rltp
> snir
> <editors>
> ctp: Carrier Termination Point
> rlt: Radio Link terminal
> rltp: Radio Link Termination Point
> snir: Signal Noise Interference Ratio
> </editors>
>
> carries, in various configurations/modes.  T perhaps 'carriers'
>
> .  The supporting carriers are identified by its termination points /its/their/
> <editors> Yes, fix the typos.
> </editors>
>
> s.3.3
> L2 ethernet
> Is there an Ethernet that is a different layer?
> <editors>
> There is a distinction between L2 ethernet and L1 ethernet in the microwave
> area, so suggest no change to the use of L2 ethernet.
> </editors>
>
> s.3.4
> augmented by the microwave topology model a reference would be useful
> <editors> The microwave topology model is the model being defined by this ID.
> So no reference is needed. Maybe change the wording to "augmented by THIS
> microwave topology model"  (note: all caps only for emphasis, not for draft)
> </editors>
>
> module
> snir
>             fraction-digits 1;
>             range "0..99";
> I imagine that that excludes 99.9 or 99.1 etc
>
> actual transmitted level
> ditto
> <editors>
> For snir and action-transmitted-level:  Same as point 1, remove the range
> statement and update the description statement.
> </editors>
>
> when choices specify mw-tp mw-link is one of the choice mandatory?
> <editors>
> Agreed, should make each choice statement mandatory, that would enforce one
> option to be chosen when configuring.
> </editors>
>
> apply only for networks with an          microwave network topology type
> /an/a/
> <editors>
> Fix typo
> </editors>
>
> A.1
> 10.10.10.1
> is not an address for documentation use
> A.2
> dirro
> B.1
> ditto
> <editors>
> Agreed, use https://www.rfc-editor.org/rfc/rfc3330.txt, so addresses like
> 192.0.2.1 & 192.0.2.2 in the examples.
> </editors>
>
> The authors would like to thank ...
> <editors>
> We will add thanks and acknowledgements.
> </editors>
>
> Regards,
> -scott. (on the behalf of the Authors of the microwave topology draft)
>