Hi Tom, I submitted a new revision of the draft which addresses your comments. Thank you.
Cheers, Med > -----Message d'origine----- > De : t.petch [mailto:[email protected]] > Envoyé : mercredi 7 février 2018 17:48 > À : BOUCADAIR Mohamed IMT/OLN > Cc : [email protected]; [email protected] > Objet : Re: [OPSAWG] Opsdir early review of draft-ietf-opsawg-nat-yang-10 > > Med > > Looks good. Two loose ends. > > On RFC6052 being a Normative reference from RFC7915 and so not needing > further citing, well yes, I suppose so:-) > > On idnits and RFC7050, you cannot have an RFC style reference such as > [RFCnnnn] in the YANG module, with the underlying <a href= ... > in the > html version, because the YANG module must be capable of existing > outside the RFC, in plain text and not in HTML. This is what > " Section 5.1 of [RFC7050]). " > looks like to me, an attempt to create an HTML anchor that cannot exist > in plain text YANG module. I do not know if idnits is clever enough to > recognise a YANG (or MIB or ... ) module and know that RFC style > references cannot appear in it, although the character string 'RFC nnnn' > or 'RFCnnnn' can do so. > > So if you have RFC nnnn in Normative or Informative References, you must > have [RFCnnnn] somewhere in the text of the RFC outside the YANG module; > and vice versa. > > Tom Petch > > ----- Original Message ----- > From: <[email protected]> > To: "t.petch" <[email protected]> > Cc: <[email protected]>; <[email protected]> > Sent: Wednesday, February 07, 2018 12:35 PM > Subject: RE: [OPSAWG] Opsdir early review of > draft-ietf-opsawg-nat-yang-10 > > > > Hi Tom, > > > > Thank you for the careful review. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : t.petch [mailto:[email protected]] > > > Envoyé : mercredi 7 février 2018 13:01 > > > À : BOUCADAIR Mohamed IMT/OLN > > > Cc : [email protected]; [email protected] > > > Objet : Re: [OPSAWG] Opsdir early review of > draft-ietf-opsawg-nat-yang-10 > > > > > > While you are at it, you might like to note > > > > > > s1.1 > > > / A NAPT my use /A NAPT may use / > > > > [Med] Fixed. > > > > > > > > feature siit { > > > description > > > ...... > > > The translator must support the stateless address mapping > > > algorithm defined in RFC6052, which is the default > behavior."; > > > reference > > > "RFC 7915: IP/ICMP Translation Algorithm"; > > > > > > If the algorithm in RFC6052 must be supported, I would expect this > to > > > appear in the Reference clause > > > > > > > [Med] RFC6052 is not cited because it is already listed as a normative > reference in "RFC 7915: IP/ICMP Translation Algorithm". I thought this > is redundant. No? > > > > > list nat64-prefixes { > > > ..... > > > Destination-based Pref64::/n is discussed in > > > Section 5.1 of [RFC7050]). For example: > > > 192.0.2.0/24 is mapped to 2001:db8:122:300::/56. > > > 198.51.100.0/24 is mapped to 2001:db8:122::/48."; > > > reference > > > "Section 5.1 of RFC7050."; > > > > > > I see no RFC7050 in the Reference section of the I-D > > > > [Med] Fixed. > > > > What is strange, is that when I run idnits, I do have this error: > > > > Checking references for intended status: Proposed Standard > > -------------------------------------------------------------------- > -------- > > > > (See RFCs 3967 and 4897 for information about using normative > references > > to lower-maturity documents in RFCs) > > > > == Unused Reference: 'RFC7050' is defined on line 3585, but no > explicit > > reference was found in the text > > '[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery > of...' > > > > It seems that idnits does not look at the citations in the YANG > module. > > > > I made this change to cite that RFC outside the YANG module: > > > > OLD: > > o Stateful NAT64 > > > > NEW: > > o Stateful NAT64 (including with destination-based Pref64::/n > > RFC7050]) > > > > > > > > leaf logging-enable { > > > .... > > > reference > > > "Section 2.3 of RFC 6908 and REQ-12 of RFC6888."; > > > } > > > > > > I see no RFC6908 in the Reference section of the I-D > > > > > > > [Med] Fixed. Thanks. > > > > Idem as above. I made this change to make idnits happy: > > > > OLD: > > This YANG module allows to instruct a NAT function to enable the > > logging feature. > > > > NEW: > > This YANG module allows to instruct a NAT function to enable the > > logging feature (Section 2.3 of [RFC6908] and REQ-12 of [RFC6888]). > > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: <[email protected]> > > > To: "Joe Clarke" <[email protected]>; "Tim Chown" > <[email protected]> > > > Cc: <[email protected]>; <[email protected]>; > > > <[email protected]> > > > Sent: Wednesday, February 07, 2018 8:14 AM > > > Subject: Re: [OPSAWG] Opsdir early review of > > > draft-ietf-opsawg-nat-yang-10 > > > > > > > > > > Hi Joe, all, > > > > > > > > Thanks. Lets' then go that path. > > > > > > > > A new version which addresses the comments from Tim (remove the > NPTv6 > > > part + some minor edits) is available at: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/?include_tex > > > t=1 > > > > > > > > Tim, thank you for identifying this issue at this stage of the > > > publication process. > > > > > > > > One logistic question for the NPTv6 document, though: Should it be > > > published (1) as draft-ietf-ospawg-* given that its content was part > of > > > the document that was accepted by the WG and that passed the WGLC or > (2) > > > as an individual document that will be handed to the AD together > with > > > draft-ietf-opsawg-nat-yang? > > > > > > > > Cheers, > > > > Med > > > > > > > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
