> On Mar 7, 2019, at 17:50, Elwyn Davies <[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]> > Date: 06/03/2019 22:55 (GMT+00:00) > To: Elwyn Davies <[email protected]> > Cc: [email protected], Christian Hopps <[email protected]>, > [email protected], "<[email protected]>" > <[email protected]>, [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]> 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]> > > Date: 06/03/2019 00:26 (GMT+00:00) > > To: [email protected] > > Cc: [email protected], [email protected], > > [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>. > > > > 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] > > https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > 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
