[netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-module-tags-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/



--
DISCUSS:
--

I think this document does introduce new security considerations,
specifically the ability for one user to remove ("mask") tags from being
visible to other users.  A malicious user could interfere with the
operations of other users/entities, especially in the case mentioned in
an example where multiple semi-independent clients use tags to indicate
modules to avoid that may be broken.


--
COMMENT:
--

Section 2

Similarly to Alissa's DISCUSS, perhaps "registered prefix" is better
than "standard prefix".

Section 2.4

Similarly, "future registration" or "future use" seem to be better fits
for the intended sentiment.

Section 3.2

I may be misreading, but this seems to be encouraging implementations to
add new ietf:-prefixed tags that are not necessarily registered or
specified in IETF-consensus documents.

Section 7.2

   This registry allocates prefixes that have the standard prefix
   "ietf:".  [...]

The registry name just talks about "tags"; are we really allocating
*prefix*es?


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Alexey Melnikov via Datatracker]

Alexey Melnikov has entered the following ballot position for
draft-ietf-netmod-module-tags-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/



--
DISCUSS:
--

This is generally a fine document, but after checking RFC 7950 syntax for
strings I question why you think you need non ASCII tags. There are so many
problems that can arise from that. For example, how would IANA be able to
enforce uniqueness of Unicode tags written in different Unicode
canonicalisation forms?




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Alvaro Retana's No Objection on draft-ietf-netmod-module-tags-07: (with COMMENT)

[Alvaro Retana via Datatracker]

Alvaro Retana has entered the following ballot position for
draft-ietf-netmod-module-tags-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/



--
COMMENT:
--

(1) Along the same lines of Alissa's DISCUSS, which I support.

§6.1: "For standardized modules new tags MUST be assigned in the IANA registry
defined below, see Section 7.2."  What is a "standardized module"?  It sounds
like a Standards Track document, but (as Alissa pointed out) the registration
policy is only IETF Review.

(2) §7.1: "All YANG module tags SHOULD begin with one of the prefixes in this
registry."  That statement along with the text in §2.4:

   Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is
   reserved for future standardization.  These tag values are not
   invalid, but simply reserved in the context of standardization.

...seem to indicate that a tag with any format can be used.  Is that true?  Is
that the intent?  If so, then it seems to me that vendor/user tags could simply
forgo the standardized prefix.  I guess this is ok...it just makes me wonder
about the need to even define those prefixes.

(3) I'm not sure what, but I think it may be wise to give the would-be DEs for
the new registry in §7.1 some more guidance on the allocation of new prefixes. 
The only current guidance is this: "Prefix entries in this registry should be
short strings consisting of lowercase ASCII alpha-numeric characters and a
final ":" character."


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adam Roach's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Alissa Cooper]

> On Apr 10, 2019, at 9:45 PM, Adam Roach via Datatracker  
> wrote:
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-netmod-module-tags-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This is a "discuss discuss" that I plan to clear once the IESG has considered
> the topic during tomorrow's telechat.
> 
> This document has a normative reference to RFC 8199, which is informational.
> This downref was not mentioned in the IETF Last Call announcement
> , and RFC 8199 
> doesn't
> yet appear in the downref registry 
> .
> 
> Per RFC 8067, this doesn't require running another IETF last call; however, as
> it wasn't part of the IETF last call discussion, the IESG is required to
> evaluate whether the downref is appropriate.

This change was made in the latest version in response to the Gen-ART review. I 
think the reference is appropriate and I don’t think another last call is 
required.

Alissa

> 
> 
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Gen-art] Genart last call review of draft-ietf-netmod-module-tags-06

[Alissa Cooper]

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  wrote:
> 
> 
> 
>> On Mar 7, 2019, at 17:50, Elwyn Davies > > 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 mailto:cho...@chopps.org>>
>> Date: 06/03/2019 22:55 (GMT+00:00)
>> To: Elwyn Davies mailto:elw...@dial.pipex.com>>
>> Cc: gen-...@ietf.org , Christian Hopps 
>> mailto:cho...@chopps.org>>, 
>> draft-ietf-netmod-module-tags@ietf.org 
>> , "> >" mailto:i...@ietf.org>

[netmod] Alissa Cooper's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS and COMMENT)

[Alissa Cooper via Datatracker]

Alissa Cooper has entered the following ballot position for
draft-ietf-netmod-module-tags-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/



--
DISCUSS:
--

This is a minor thing, but people get really confused about it so I'd like to
discuss it. This document allows for minting new "IETF Standard" tags by
publishing documents that are not standards of any kind. That is, because the
registry specified in 7.2 has its allocation policy as IETF Review, that means
that informational documents can be used to register new "IETF Standard" tags.
This seems ripe for creating further confusion about what is and is not an IETF
"standard." Could these tags simply be called "IETF tags"?


--
COMMENT:
--

I strongly encourage you to follow the advice of the Gen-ART reviewer and
include a contact or change controller field in the registry defined in 7.1.
For a registry where you expect other SDOs to be making registrations, this
field can be critical if the registry entries need to be updated years after
they are created. See RFC 8126 Section 9.5.

Adam noted that RFC 8199 is now a downref, based on changes made in the -07,
after IETF last call. I think this is fine and does not require another last
call.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod