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.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?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. 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. 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.Cheers,ElwynSent 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 [email protected]https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
