Elwyn, thanks for your review. Christian, thanks for your responses. I think all of Elwyn’s comments have been addressed in the latest version. I entered a DISCUSS ballot on a different point related to the “IETF standard” tags.
Alissa > On Mar 7, 2019, at 8:02 PM, Christian Hopps <[email protected]> wrote: > > > >> On Mar 7, 2019, at 17:50, Elwyn Davies <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi, Christian. >> >> Thanks for the quick response. >> >> I understand your intent, but the intent and the specification appear to be >> in conflict. >> >> The pattern for tags is >> pattern '[a-zA-Z_][a-zA-Z0-9-_]*:[S ]+'; >> >> This REQUIRES two character strings separated by a colon unless I have >> totally forgotten how to read such patterns. Thus all tags have a prefix of >> the form [a-zA-Z_][a-zA-Z0-9-_]* and a part after the colon that is >> essentially unconstrained. > > Your right the pattern was wrong and needs to be fixed. > >> S2 limits the values of the prefixes to those defined in the IANA registry >> of s7.1.. Further the values of the second part are constrained by the s7.2 >> registry if the prefix is ietf:. >> >> So, what should a YANG parser do when building datastores as per RFC 8342 if >> a tag prefix is not one of the ones in the s7.1 registry? Likewise if the >> prefix is ietf: and the whole tag is not in the s7.2 registry? > > A YANG server should never place any restrictions on the tag values. There’s > need for this limiting and well known justification not to (applying Postel’s > Law/Robustness principle here). > >> If you want to make the presence of the prefix a SHOULD then I think you >> need to adapt the pattern to make the whole prefix part optional. However >> that doesn't get away from describing what the parser should do if it finds >> a prefix it doesn't know about. > > Assuming the pattern is fixed, do we really have to call out the fact that > something marked as a SHOULD should not be treated as a MUST? That seems like > what your asking for, perhaps I’m missing the point though. Are you just > asking for a blurb saying parsers must not restrict tag values? That seems > like restating but if it moves things forward I’m amiable. :) > >> Additionally, I am not clear how the parser knows which tags should be >> marked as 'system' in the datastore as mentioned in the YANG module >> comments. > > B/c it (the server) put them there, not the user. > >> Maybe it is that the ietf prefix and s7.2 value leads the tags to be marked >> as system tags but what should happen if it isn't in the s7.2 list? Should >> the parser ignore such tags, throw a fault and refuse to parse the module or >> maybe treat them as user tags even if they are ietf prefixed? >> >> Also if new prefixes are defined by other SDOs, as envisaged in the last >> paragraph of s7.1, could or would these also be system tags? Should there >> then be a flag or value in the registry to flag that tags with this prefix >> should be marked as system or otherwise? >> >> Thus also brings up another issue for the s7.1 registry. If another >> organisation is defining a prefix there really need to be contact and >> reference fields in the registry to specify the organisation maintaining >> this prefix, especially if such a prefix had its own equivalent of the s7.2 >> registry, and the document that introduces the prefix. >> >> I suggest the authors discuss the appropriate status for the three RFCs that >> I suggested should be normative and you disagreed with your AD. It is a >> rather odd situation where a standards ltrack document is updating an >> informational or BCP document, and also needing knowledge of items described >> in BCPs. With the revised policy on downrefs, this can be handled I believe. > > We are updating the BCP guidelines (RFC8407) , but nothing is relying on them > that I see. I would have thought text that updates informative text is > treated as informative, this could be my ignorance showing. > > RFC8340 being informative is what all the other yang documents (including > RFCs) I’ve seen do as well. > > RFC8199 is informative, the values themselves are normative only in the sense > that they are being reserved. Again, maybe I’m wrong. I’d prefer to be told > so and then I’ll just move the reference. > > I guess I don’t understand things well enough is all. Can you be specific > about the objections with each of the 3 references? > > Thanks, > Chris. > >> >> Cheers, >> Elwyn >> >> Sent from Samsung tablet. >> >> -------- Original message -------- >> From: Christian Hopps <[email protected] <mailto:[email protected]>> >> Date: 06/03/2019 22:55 (GMT+00:00) >> To: Elwyn Davies <[email protected] <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]>, Christian Hopps >> <[email protected] <mailto:[email protected]>>, >> [email protected] >> <mailto:[email protected]>, "<[email protected] >> <mailto:[email protected]>>" <[email protected] <mailto:[email protected]>>, >> [email protected] <mailto:[email protected]> >> Subject: Re: [Gen-art] [netmod] Genart last call review of >> draft-ietf-netmod-module-tags-06 >> >> [I covered this in the previous reply I just sent, and updated the model >> text in response too..] >> >> The intent here is to not restrict users of tags where we don't have to. The >> prefix is only intended to avoid collision between disconnected groups >> (designers, implementers and users), since users are the final group to >> add/modify/use the tags we don't need to restrict them (and so we shouldn't). >> >> Thanks, >> Chris. >> >> > On Mar 6, 2019, at 2:39 PM, Elwyn Davies <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Hi. >> > >> > After completing my review, I realized that there was a further minor >> > issue related to the possible values of tag prefixes, possible values of >> > standardized prefixes and behaviour of implementations in the face of tag >> > prefixes or values that are not in the relevant registries. >> > >> > I think that the text in s2 should be reinforced to emphasise that the >> > only prefixes that should be expected are those in the IANA registry >> > defined in s7.1. >> > >> > Either a new section or possibly in s3 text should be added to define the >> > behaviour of YANG implementations that encounter tags with prefixes that >> > are not in the s7.1 registry and tags with prefix ietf: that are not in >> > the s7.2 registry. >> > >> > Regards, >> > Elwyn Davies >> > >> > >> > >> > >> > >> > Sent from Samsung tablet. >> > >> > -------- Original message -------- >> > From: Datatracker on behalf of Elwyn Davies >> > <[email protected] <mailto:[email protected]>> >> > Date: 06/03/2019 00:26 (GMT+00:00) >> > To: [email protected] <mailto:[email protected]> >> > Cc: [email protected] >> > <mailto:[email protected]>, [email protected] >> > <mailto:[email protected]>, [email protected] <mailto:[email protected]> >> > Subject: [Gen-art] Genart last call review of >> > draft-ietf-netmod-module-tags-06 >> > >> > Reviewer: Elwyn Davies >> > Review result: Almost Ready >> > >> > I am the assigned Gen-ART reviewer for this draft. The General Area >> > Review Team (Gen-ART) reviews all IETF documents being processed >> > by the IESG for the IETF Chair. Please treat these comments just >> > like any other last call comments. >> > >> > For more information, please see the FAQ at >> > >> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq >> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>. >> > >> > Document: draft-ietf-netmod-module-tags-06 >> > Reviewer: Elwyn Davies >> > Review Date: 2019-03-05 >> > IETF LC End Date: 2019-03-03 >> > IESG Telechat date: Not scheduled for a telechat >> > >> > Summary: >> > Almost ready. There are a couple of minor issues and a small number of >> > nits. >> > Apologies for the slightly late delivery of the review. >> > >> > Major issues: >> > None >> > >> > Minor issues: >> > Abstract/s1: I would judge that RFC 8407 ought to be normative since it is >> > updated. >> > >> > S4.2: using the Netmod working group as contact point for the module is not >> > future proof. I am not sure what the correct contact ought to be: IESG? >> > >> > S7.2: [This is a thought that occurred to me...] ought there to be an ietf: >> > security tag? >> > >> > S9: I would consider RFCs 8199, 8340, 8342 and 8407 to be normative >> > >> > Nits/editorial comments: >> > Abstract: s/modules/module's/ >> > >> > Abstract: >> > OLD: >> > This document also provides guidance to future model writers, as such, this >> > document updates RFC8407. >> > >> > NEW: >> > This document also provides guidance to future model writers; as such, this >> > document updates RFC8407. >> > >> > ENDS >> > >> > S1.1, title: s/use cases of/use cases for/ >> > >> > S1.1, para 1: s/documents progression/document's development/ >> > >> > S1.1, paras 2, 3 and 5: Suggest s/E.g./For example/ >> > >> > S1.1, para 4: s/e.g./e.g.,/ >> > >> > S2, para 1: >> > > All tags SHOULD begin with a prefix indicating who owns their >> > definition. >> > >> > If I read correctly, the YANG definition in s4.2 REQUIRES that all tags >> > have a >> > prefix. For clarity, it would better if this read: >> > All tags MUST begin with a prefix; it is intended that this prefix >> > SHOULD >> > [or maybe 'should'] indicate >> > the ownership or origination of the definition. >> > >> > S2, para 1: s/yang type/YANG type/ (I think) >> > >> > S2.2: s/follwing/following/ >> > >> > S3.1, para 2: >> > OLD: >> > If the module definition is IETF standards track, the tags MUST also be >> > Section >> > 2.1. Thus, new modules can drive the addition of new standard tags to the >> > IANA >> > registry, and the IANA registry can serve as a check against duplication. >> > >> > NEW: >> > If the module is defined in an IETF standards track document, the tags >> > MUST use >> > the prefix defined in Section 2.1. Thus, definitions of new modules can >> > drive >> > the addition of new standard tags to the IANA registry defined in Section >> > 7.2, >> > and the IANA registry can serve as a check against duplication. >> > >> > ENDS >> > >> > S3.2: s/standard/IETF Standard/ >> > >> > S3.3: It would be useful to introduce the term 'masking' used later in the >> > YANG >> > module definition. >> > >> > S4.1: I think this usage of RFC 8340 makes it normative. >> > >> > S4.2, extension module-tag definition: This should contain a pointer to RFC >> > 8342 which discusses the system origin concept. >> > >> > Major issues: >> > >> > Minor issues: >> > >> > Nits/editorial comments: >> > >> > >> > _______________________________________________ >> > Gen-art mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/gen-art >> > <https://www.ietf.org/mailman/listinfo/gen-art> >> > _______________________________________________ >> > netmod mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/netmod >> > <https://www.ietf.org/mailman/listinfo/netmod> >> >> >> _______________________________________________ >> Gen-art mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
