Hi, All, Thank you very much for the comments and discussion, the draft is now updated to -21, addressing most of the comments from Adrian, Nicolai in rtgdir review, and from Tom as well. Please take a look and let us know if anything is wrong. Best wishes, Haomian -----邮件原件----- 发件人: last-call [mailto:last-call-bounces@xxxxxxxx] 代表 Zhenghaomian 发送时间: 2022年12月19日 11:47 收件人: tom petch <ietfc@xxxxxxxxxxxxx>; Nicolai Leymann <n.leymann@xxxxxxxxxx> 抄送: ccamp@xxxxxxxx; draft-ietf-ccamp-l1csm-yang.all@xxxxxxxx; last-call@xxxxxxxx; ccamp-chairs@xxxxxxxx 主题: [Last-Call] 答复: [CCAMP] Rtgdir last call review of draft-ietf-ccamp-l1csm-yang-19 Thank you, all clear now. -----邮件原件----- 发件人: tom petch [mailto:ietfc@xxxxxxxxxxxxx] 发送时间: 2022年12月17日 20:37 收件人: Zhenghaomian <zhenghaomian@xxxxxxxxxx>; Nicolai Leymann <n.leymann@xxxxxxxxxx> 抄送: ccamp@xxxxxxxx; draft-ietf-ccamp-l1csm-yang.all@xxxxxxxx; last-call@xxxxxxxx; ccamp-chairs@xxxxxxxx 主题: Re: [CCAMP] Rtgdir last call review of draft-ietf-ccamp-l1csm-yang-19 <in line> From: Zhenghaomian <zhenghaomian@xxxxxxxxxx> Sent: 17 December 2022 07:20 Subject: 答复: [CCAMP] Rtgdir last call review of draft-ietf-ccamp-l1csm-yang-19 Hi Tom, Thank you for raising these. I captured it in https://github.com/haomianzheng/IETF-ACTN-YANG-Model/issues/125 but do see inline if it is more convenient to you. <much more convenient> I am content with your responses except for <tp2> Haomian -----邮件原件----- 发件人: tom petch [mailto:ietfc@xxxxxxxxxxxxx] 发送时间: 2022年12月16日 20:19 From: CCAMP <ccamp-bounces@xxxxxxxx> on behalf of Nicolai Leymann via Datatracker <noreply@xxxxxxxx> Sent: 12 December 2022 11:09 To: rtg-dir@xxxxxxxx Reviewer: Nicolai Leymann Review result: Ready <tp> Borrowing a suitable e-mail to respond to, there are a lot of changes from -17 to -19 and some new issues. I agree with Nicolai about the ambiguity of P [Haomian] Will remove the usage of P in figure 1. RFC6991 is no longer an import but it is still present in several places. [Haomian] Will remove in Table 1 and reference. I love to keep pointing out that an unrestricted YANG string can be 18446744073709551615 characters long; will boxes be able to support this? will they be able to support YANG keys of this length? [Haomian] No change made. It is just too complicated to restrict the usage of a string, no much input on this... Is there a convention for how the ends are referenced? This has a mix of 'one' and 'other' with '-1' and '-2' [Haomian] No change made. I think it's reasonable to have -1 and -2 in the leaf node of model, but 'one' and 'other' in model description. Please help tweaking the English and feel free to leave explicit proposals. <tp2> In several low level protocols, there is a well-established convention about how the ends of a link are referred to a convention that may look strange when first encountered usually derived from the concept of a public network to which a variety of boxes attach. I am not familiar enough with this technology to know if such exists but if it does not, then what you have is fine. error message about the ids would be better as 'end point IDs' [Haomian] Fixed. uni access type could do with a reference; G.709? [Haomian] To confirm, you mean the 'uni-access-type' in YANG model. We can have double reference to G.709 and MEF63 as indicated in the choice. <tp2> I mean the YANG choice which talks of MEF and of ITU-T. MEF is clear enough, ITU-T is not. Remember that this YANG module will be cut out of the RFC to float freely across cyberspace with no I-D References so the YANG module needs to be self-contained with all the references needed. Tom Petch Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://trac.ietf.org/trac/rtg/wiki/RtgDir This is the second review from Routing Directorate. Overall I think the draft is ready for publication but there a still a few nits. This review takes place in support of CCAMP working group last call. Document: draft-ietf-ccamp-l1csm-yang-19 Reviewer: Nicolai Leymann Review Date: 09 December 2022 IETF LC End Date: Not yet started Intended Status: Draft Standard Nits: either "Layer 1" or "layer 1" should be used consistently throughout the document: - Page 5, First sentence: "The benefit is that the same layer 1 transport network resources are" - Page 6, "The L1CSM YANG data model describes the layer 1 connectivity services" References to "RFCXXX", "RFC XXX" and "RFCYYY" need to be fixed. - (In some cases there is a comment that this needs to be updated but not not in all cases. E.g., Page 9) Page 6, Table has no caption, References need to be fixed ("RFCXXX"/"[RFCYYY]") Some of the comments from Adrians review (e.g., use of "P" as Protcol but also in different context in Figues are not addressed (yet)). _______________________________________________ CCAMP mailing list CCAMP@xxxxxxxx https://www.ietf.org/mailman/listinfo/ccamp -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
