Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

From: Kent Watsen <[email-masked]>
Date: Mon, 2 Oct 2017 20:06:34 +0000

The Last Call for this document has completed with *no* responses, other than Benoit's question regarding if it should be a BCP, which also had no responses, other than my own wondering if YANG (and hence the guidelines) was stable enough.

Lou and I discussed.  It is our opinion that, given the nature of this document, the WG implicitly supports it already.  So, really, the only thing that matters, is if there are any issues/concerns.  Since no issues/concerns were raised, we choose to declare the Last Call successful.  As for promoting it to a BCP, there appears to be no consensus to do so at this time.   Accordingly, as the document shepherd, I plan to send the shepherd write-up (with these comments included) to the AD in the next few days.

Looking forwards, we've created a new GitHub repo called "guidelines-next" (modeled after yang-next) to capture on-going comments/suggestions for future updates to the document: https://github.com/netmod-wg/guidelines-next.

Kent (and Lou)

---

From: "t.petch" <[email-masked]>
Date: Tue, 3 Oct 2017 12:23:50 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
Sent: Monday, October 02, 2017 9:06 PM

> The Last Call for this document has completed with *no* responses,
other than Benoit's question regarding if it should be a BCP, which also
had no responses, other than my own wondering if YANG (and hence the
guidelines) was stable enough.
>
> Lou and I discussed.  It is our opinion that, given the nature of this
document, the WG implicitly supports it already.  So, really, the only
thing that matters, is if there are any issues/concerns.  Since no
issues/concerns were raised, we choose to declare the Last Call
successful.  As for promoting it to a BCP, there appears to be no
consensus to do so at this time.   Accordingly, as the document
shepherd, I plan to send the shepherd write-up (with these comments
included) to the AD in the next few days.

Kent

The trouble is that a number of other things have been going on, mostly
NMDA and the
ramifications thereof, and so this one never moved up my todo list.

Yes, it is an I-D that matters, the timing is unfortunate.

Tom Petch

> Looking forwards, we've created a new GitHub repo called
"guidelines-next" (modeled after yang-next) to capture on-going
comments/suggestions for future updates to the document:
https://github.com/netmod-wg/guidelines-next.
>
> Kent (and Lou)
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Alexander Clemm" <[email-masked]>
Date: Mon, 16 Oct 2017 22:48:27 -0700

(Resending, apologies in case of duplicates)

I have reviewed some parts of the draft and have just a few comments as
well:

-	One area where guidelines are missing, but where guidance would be
needed, concerns how to model return values from RPCs, as well as how to
model the handling of RPC error conditions.  This is an area where I think
YANG itself could need some improvement, and in its absence good guidelines
would be even more important.  
-	It would be also useful to provide guidelines regarding how to
augment/extend groupings.  This is a common scenario and what to do is not
necessarily intuitive, so I am sure many users would appreciate guidelines
here.  
-	Section 3.4: It would be good to provide a guideline regarding lines
that exceed 70 columns (from the pyang tree output), at least mention that
authors need to manually address this issue  
-	Section 3.7: Personally, I think the security considerations as
currently stated, while well-intended, introduce a bit too much red tape.
Specifically, this concerns having to list nodes individually - this can
lead to defining many "trees" while missing the "forest".  The guidelines
are a bit "rubbery" here, by the way, stating that data nodes MUST be
individually listed and discussed, at the same time only if they "could be
especially disruptive" - what does that mean - so maybe the requirement
should simply be a "SHOULD" here?  
-	Observation: there is no mention/guideline canonical order of YANG
statements.  

Thanks
--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Tuesday, September 12, 2017 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

This starts a two-week working group last call on:

    Guidelines for Authors and Reviewers of YANG Data Model Documents
    https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...

Thank you,
NETMOD WG Chairs

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Oct 2017 18:30:13 +0000

Hi Alex,

> (Resending, apologies in case of duplicates)

Resending? This is the first time I'm seeing these.  Did you send 
them when the Last Call was open before?  The Last Call closed a 
couple weeks ago  ;)

I don't want to reopen rfc6087bis for anything less than Errata at
this point (or promoting it to a BCP, but that's a different thing
altogether).  It seems that some of your suggestions could go into
the new "guidelines-next" issue tracker [1].  We may also consider
adding information to the FAQ [2].  Regarding Security Considerations,
I think that a "node" can be the root of a subtree, and the rubbery-
ness is likely from [3] and can be addressed separately.

[1] https://github.com/netmod-wg/guidelines-next/issues
[2] https://github.com/netmod-wg/FAQ/wiki
[3] http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines

What do you think?

Kent // shepherd

Thanks
--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Tuesday, September 12, 2017 11:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

    Guidelines for Authors and Reviewers of YANG Data Model Documents
    https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D14&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iR7m1fbjxuH4HW0Ws7SS-jWBlHsFIVCZEbG2vxMtmno&s=mQRtxCYVsN0ttmets8w-8a-VBh3vh9rJj_NJVhtGa4k&e=

Thank you,
NETMOD WG Chairs

_______________________________________________
netmod mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iR7m1fbjxuH4HW0Ws7SS-jWBlHsFIVCZEbG2vxMtmno&s=NeFF02cR18ZWLxBX0kSsjAolx0QUWN4ChF3_GJc9WMc&e=

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 17 Oct 2017 19:49:26 +0000

Hi Kent

Two quick replies, inline, <ALEX>

Thanks
--- Alex

> Sent: Tuesday, October 17, 2017 11:30 AM
> To: Alexander Clemm <[email-masked]>; [email-masked]
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
> 
> Hi Alex,
> 
> Resending? This is the first time I'm seeing these.  Did you send them when
> the Last Call was open before?  The Last Call closed a couple weeks ago  ;)

<ALEX> I suspected there was a problem with my mailer.  So I am glad I resent them. No, the comments are "fresh", not from weeks ago
</ALEX>

> 
> I don't want to reopen rfc6087bis for anything less than Errata at this point (or
> promoting it to a BCP, but that's a different thing altogether).  It seems that
> some of your suggestions could go into the new "guidelines-next" issue
> tracker [1].  We may also consider adding information to the FAQ [2].
> Regarding Security Considerations, I think that a "node" can be the root of a
> subtree, and the rubbery- ness is likely from [3] and can be addressed
> separately.

<ALEX> I saw other comments on the list just yesterday, and was encouraged off-line to send my comments and also to review more documents;-)  so I just went ahead and did.  Sure, I have no problems to not hold up the draft - as commented on the other thread, I would like to see drafts progress faster, not slower, even if it means some churn further down the road.  That said, I do think that guidelines re: RPC modeling, and extending/augmenting groupings are currently lacking and needing improvement at some point.  

Re: rubbery-ness, no, this is taken from this draft, not from 6087.  

--- Alex
</ALEX>

> YANG itself could need some improvement, and in its absence good
> guidelines would be even more important.
> Specifically, this concerns having to list nodes individually - this can lead to
> defining many "trees" while missing the "forest".  The guidelines are a bit
> "rubbery" here, by the way, stating that data nodes MUST be individually
> listed and discussed, at the same time only if they "could be especially
> disruptive" - what does that mean - so maybe the requirement should simply
> be a "SHOULD" here?
>     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-
> 2D14&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> =iR7m1fbjxuH4HW0Ws7SS-
> jWBlHsFIVCZEbG2vxMtmno&s=mQRtxCYVsN0ttmets8w-8a-
> VBh3vh9rJj_NJVhtGa4k&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuh
> r6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> =iR7m1fbjxuH4HW0Ws7SS-
> jWBlHsFIVCZEbG2vxMtmno&s=NeFF02cR18ZWLxBX0kSsjAolx0QUWN4ChF3_
> GJc9WMc&e=
> 
> 
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 17 Oct 2017 23:06:44 +0000

I was also encouraged to provide comments.  A couple (new?) minor ones...

Section 3.4:
- If a tree diagram is included for an augmented model, it SHOULD contain the integrated of the augmented model.  I.e., use the pyang -f command to generate the tree so that you can explicitly see the schema elements imported 

Side comment: if a YANG module contains extension structures (like YANG-Data) these should also be shown in the tree, but I understand why you might not want to make that a requirement of this document.

Section 3.10: There should be a normative set of YANG validation tools which are run on upload of an Internet draft.   Errors and warnings found later (and perhaps through tools a user doesn't have) should not result in a module being given an error designation.

Thanks,
Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Oct 2017 08:22:28 +0200

> Section 3.10: There should be a normative set of YANG validation tools which are run on upload of an Internet draft.   Errors and warnings found later (and perhaps through tools a user doesn't have…

I disagree. An error is an error regardless when or how it was
detected.

/js

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Oct 2017 08:44:14 +0200 (CEST)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> - If a tree diagram is included for an augmented model, it SHOULD
> contain the integrated of the augmented model.  I.e., use the pyang
> -f command to generate the tree so that you can explicitly see the
> schema elements imported  

I agree that it would be good if 3.4 talks about this case.

But I think that the recommendation should be that the "imported tree"
just shows the structure (containers and lists), but not all other
nodes.  For an example of what I mean, see Section 2 of RFC 7277.

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 18 Oct 2017 12:35:36 +0000

> From: Juergen Schoenwaelder, October 18, 2017 2:22 AM
> 
> > Section 3.10: There should be a normative set of YANG validation tools which
> are run on upload of an Internet draft.   Errors and warnings found later (and
> perhaps through tools a user doesn't have) should not result in a module being
> given an error designation.
> >
> 
> I disagree. An error is an error regardless when or how it was detected.

What I am trying to avoid is YANG errors being discovered via validation tools for which the model author has no access to before a submitted draft is accepted.   However this can be accomplished is fine with me.

One solution is to ensure the RFC upload process has access to all tools currently used for model validation.  

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Oct 2017 15:55:15 +0200

> What I am trying to avoid is YANG errors being discovered via validation tools for which the model author has no access to before a submitted draft is accepted.   However this can be accomplished i…

I think this generally can't be avoided but then this should also not
be a common problem as things are getting more stable.

> One solution is to ensure the RFC upload process has access to all tools currently used for model validation.

This is a reasonable request to make for the tool makers. Having a
notion of normative YANG validation tools (with specific versions -
this will come next) is, however, an idea that should be avoided.

/js

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 18 Oct 2017 14:09:21 +0000

On 10/18/17, 8:35 AM, "netmod on behalf of Eric Voit (evoit)"
<[email-masked] on behalf of [email-masked]> wrote:

>What I am trying to avoid is YANG errors being discovered via validation
>tools for which the model author has no access to before a submitted
>draft is accepted.   However this can be accomplished is fine with me.
>

Right now YANG validation errors and warnings do not block submittal. This
good since there are some very annoying false positives in the draft YANG
validation. For example, submodule validation is broken even if the module
and submodule are in the same draft. Additionally, the status validation
spouts out false warnings. I reported the first problem and it was blown
off. 

Thanks,
Acee

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 20 Oct 2017 12:51:02 +0000

Regarding validation, section 3.10 refers to pyang tool. Since the set of tools might change in the future, shouldn't the reference be to the yangvalidator url or something along those lines (instead of an exhaustive list which may change)?

I think there is a nit in section 2.4, the '.' after [I-D.ietf-netmod-revised-datastores] should be removed or replaced by a comma.

Regards,
Reshad.
________________________________________
From: netmod <[email-masked]> on behalf of Eric Voit (evoit)
Sent: Tuesday, October 17, 2017 7:06 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

Section 3.4:

Thanks,
Eric