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

From: Datatracker on behalf of Elwyn Davies <[email-masked]>
Date: Tue, 05 Mar 2019 16:26:51 -0800

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:

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 06 Mar 2019 19:39:53 +0000

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-masked]> Date: 06/03/2019  00:26  (GMT+00:00) To: [email-masked] Cc: [email-masked], [email-masked], [email-masked] Subject: [Gen-art] Genart last call review of
  draft-ietf-netmod-module-tags-06 Reviewer: Elwyn DaviesReview result: Almost ReadyI am the assigned Gen-ART reviewer for this draft. The General AreaReview Team (Gen-ART) reviews all IETF documents being processedby the IESG for the IETF Chair.  Please treat these comments justlike 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-06Reviewer: Elwyn DaviesReview Date: 2019-03-05IETF LC End Date: 2019-03-03IESG Telechat date: Not scheduled for a telechatSummary: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:NoneMinor issues:Abstract/s1: I would judge that RFC 8407 ought to be normative since it isupdated.S4.2: using the Netmod working group as contact point for the module is notfuture 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 normativeNits/editorial comments:Abstract: s/modules/module's/Abstract:OLD:This document also provides guidance to future model writers, as such, thisdocument updates RFC8407.NEW:This document also provides guidance to future model writers; as such, thisdocument updates RFC8407.ENDSS1.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 aprefix.  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 Section2.1. Thus, new modules can drive the addition of new standard tags to the IANAregistry, 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 usethe prefix defined in Section 2.1. Thus, definitions of new modules can drivethe 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.ENDSS3.2: s/standard/IETF Standard/S3.3: It would be useful to introduce the term 'masking' used later in the YANGmodule 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 RFC8342 which discusses the system origin concept.Major issues:Minor issues:Nits/editorial comments:_______________________________________________Gen-art mailing [email-masked]://www.ietf.org/mailman/listinfo/gen-art

---

From: Christian Hopps <[email-masked]>
Date: Wed, 6 Mar 2019 17:50:00 -0500

Thanks for the review! Comments inline.

> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <[email-masked]> wrote:
> 
> Reviewer: Elwyn Davies

RFC8407 is a BCP not a Standard though so I don't think it's appropriate to make it normative.

> future proof.  I am  not sure what the correct contact ought to be: IESG?

Speaking of 8407 guidelines... It gives guidance here. I will follow it. :)

  "The "contact" statement MUST be present.  If the module is contained
   in a document intended for Standards Track status, then the WG web
   and mailing information SHOULD be present, and the main document
   author or editor contact information SHOULD be present."

> S7.2: [This is a thought that occurred to me...] ought there to be an ietf:

Yes, added.

> S9: I would consider RFCs 8199, 8340, 8342 and 8407 to be normative

8199: Informational
8340: BCP
8407: BCP

8342: Standard, and I think your right, moved to Normative.

> S1.1, para 4: s/e.g./e.g.,/

Updated with your suggestions.

> S2, para 1:
>    > All tags SHOULD begin with a prefix indicating who owns their definition.
> 

The intent was to not put the MUST on users. As the final arbiters of tags, users should be free to do whatever they want and not have implementations or standards superfluously block them from doing so. How about we carry the SHOULD into the typedef in the YANG model as well? That seems reasonable to me, i.e.,

  typedef tag {
    type string {
      length "1..max";
      pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
    }
    description
      "A tag is a type 'string' value that does not include carriage
       return, newline or tab characters. It SHOULD begin with a
       standard prefix.";

> S3.3: It would be useful to introduce the term 'masking' used later in the YANG

How about:

"Tags of any kind can be assigned and removed by the user using normal
configuration mechanisms. In order to remove a tag from the
operational datastore the user adds a matching =masked-tag= entry for
a given module."

> S4.1: I think this usage of RFC 8340 makes it normative.

Covered earlier (BCP).

> 8342 which discusses the system origin concept.

Added.

Thanks,
Chris.

> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Christian Hopps <[email-masked]>
Date: Wed, 6 Mar 2019 17:55:15 -0500

[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-masked]> 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-masked]>
> Date: 06/03/2019 00:26 (GMT+00:00)
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: [Gen-art] Genart last call review of   draft-ietf-netmod-module-tags-06
> 
> Reviewer: Elwyn Davies
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Mar 2019 10:27:18 -0800

On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps <[email-masked]> wrote:

> ....
> The intent was to not put the MUST on users. As the final arbiters of
> tags, users should be free to do whatever they want and not have
> implementations or standards superfluously block them from doing so. How
> about we carry the SHOULD into the typedef in the YANG model as well? That
> seems reasonable to me, i.e.,
>
>   typedef tag {
>     type string {
>       length "1..max";

I strongly agree that a prefix SHOULD be present, not MUST be present.
I also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix
"vendor:"
seems a bit short-sighted)

Andy

---

From: William Lupton <[email-masked]>
Date: Thu, 7 Mar 2019 18:37:23 +0000

This remark might be out of context (I haven't been following the details)
but this reference to prefixes makes me wonder whether there's any way that
registered URN namespaces could be regarded as valid prefixes.
https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

---

From: Christian Hopps <[email-masked]>
Date: Thu, 07 Mar 2019 13:42:47 -0500

> seems a bit short-sighted)

Sounds like you are a strong supporter of the included prefixes registry as well then. :)

Thanks,
Chris.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Mar 2019 10:44:16 -0800

> https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

looks like a great solution and would be less duplication of registries

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Mar 2019 10:48:05 -0800

> Sounds like you are a strong supporter of the included prefixes registry

not really -- in my server implementation the prefix is ignored -- it is
just part of
a unique string. It is supposed to help clients create unique tags.
It is subjective whether vendor:bbf-routing is better than bbf:routing (for
example)

Andy

---

From: Christian Hopps <[email-masked]>
Date: Thu, 07 Mar 2019 14:02:39 -0500

We already have a reviewed and approved prefixes registry.

Given nothing is broken here, and the current solution has been reviewed for 2+ years, and with careful consideration approved by the working group, this does not seem like change that should be considered (or perhaps even suggested) at this very late point in the process.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Mar 2019 20:34:21 +0100

> Given nothing is broken here, and the current solution has been reviewed for 2+ years, and with careful consideration approved by the working group, this does not seem like change that should be co…

It is relatively clear (to me at least) that followup work will be
needed if this gets deployed and used widely. Computer programs
consuming tags are less tolerant than humans consuming tags and the
idea that operators will fix things via configuration likely does not
scale. But perhaps this is not bad, if the issue comes back to us in
~3 years, we know at least that tags are a useful idea.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Alex Campbell <[email-masked]>
Date: Thu, 7 Mar 2019 23:40:32 +0000

In that case, why not make it so the tags are actually valid URIs, similar to XML namespaces?

________________________________
From: netmod <[email-masked]> on behalf of William Lupton <[email-masked]>
Sent: Friday, 8 March 2019 7:37 a.m.
To: Andy Bierman
Cc: Datatracker on behalf of Elwyn Davies; IETF discussion list; NetMod WG; General Area Review Team; [email-masked]
Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06

This remark might be out of context (I haven't been following the details) but this reference to prefixes makes me wonder whether there's any way that registered URN namespaces could be regarded as valid prefixes. https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

On Thu, 7 Mar 2019 at 18:28, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the review! Comments inline.

> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <[email-masked]<mailto:[email-masked]>> wrote:
>
> Reviewer: Elwyn Davies
....

  typedef tag {
    type string {
      length "1..max";

I strongly agree that a prefix SHOULD be present, not MUST be present.
I also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix "vendor:"
seems a bit short-sighted)

Andy

How about:

Covered earlier (BCP).

Added.

Thanks,
Chris.

> [email-masked]<mailto:[email-masked]>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Christian Hopps <[email-masked]>
Date: Thu, 7 Mar 2019 19:16:48 -0500

[to this thread in general, not anyone in particular]

We have done this work over 2 years in the working group. It has been presented multiple times with multiple revisions etc. We have arrived at a solution that works, and has cleared WG LC, and IETF LC.

We have a process we need to follow it. Yes if something is truly broken and has somehow escaped all the previous checks it needs to be addressed. But general musings about how one might do things a little different or a little better are not appropriate at this very late stage, otherwise we never get anything done.

Not getting things done in a timely manner has been a problem highlighted at least with the work in netmod if not the IETF in general, and has been the subject during many meetings at this point, on how to fix it. Endless revisionism is one of the major factors identified as a problem.

Can we please restrict discussions on this document to editorial/minor corrections or changes that have to be made b/c otherwise the solution will not work?

Thanks,
Chris.

> On Mar 7, 2019, at 18:40, Alex Campbell <[email-masked]> wrote:
> 
> From: netmod <[email-masked]> on behalf of William Lupton <wlupton@broadband-forum..org>
> This remark might be out of context (I haven't been following the details) but this reference to prefixes makes me wonder whether there's any way that registered URN namespaces could be regarded as valid prefixes. https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml <https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml>
> On Thu, 7 Mar 2019 at 18:28, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps <[email-masked] <mailto:[email-masked]>> wrote:
> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Reviewer: Elwyn Davies
> .....
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 8 Mar 2019 14:26:46 -0600

Going up to a more general topic (and ignoring the particulars here):

> RFC8407 is a BCP not a Standard though so I don't think it's appropriate to make it normative.

I'm confused by this statement.  BCPs are considered to be standards-track,
and a reference from a PS document to a BCP is not considered a downref.
Is the objection that "best current practices" are just that (practices)
and not part of a mandatory protocol specification?

We do have BCP 195 (RFC 7525), "Recommendations for Secure Use of Transport
Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", which
are indeed recommendations and best practices for use of TLS in general,
and as such can apply to anything using TLS, even existing deployed systems
and protocols.  But we can also have new protocols that say "it is
mandatory to comply with the behavior described in RFC 7525", and to me
that is a normative part of the spec.

So I'd like a better understanding of your stance here.

Thanks,

Ben

---

From: Christian Hopps <[email-masked]>
Date: Sat, 09 Mar 2019 07:26:23 -0500

I will move this reference to normative, I was confused.

Thanks,
Chris.