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: <mohamed.boucad...@orange.com> To: "t.petch" <ie...@btconnect.com> Cc: <draft-ietf-opsawg-nat-yang....@ietf.org>; <opsawg@ietf.org> 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:ie...@btconnect.com] > > Envoyé : mercredi 7 février 2018 13:01 > > À : BOUCADAIR Mohamed IMT/OLN > > Cc : draft-ietf-opsawg-nat-yang....@ietf.org; opsawg@ietf.org > > 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: <mohamed.boucad...@orange.com> > > To: "Joe Clarke" <jcla...@cisco.com>; "Tim Chown" <tim.ch...@jisc.ac.uk> > > Cc: <ops-...@ietf.org>; <draft-ietf-opsawg-nat-yang....@ietf.org>; > > <opsawg@ietf.org> > > 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
