Subject: [netmod] WGLC: draft-ietf-netmod-geo-location-04

From: Kent Watsen <[email-masked]>
Date: Mon, 9 Mar 2020 22:30:09 +0000

This message begins an almost two-week WGLC for draft-ietf-netmod-geo-location-04 ending on March 22nd (the day before the NETMOD sessions).  Here is a direct link to the HTML version of the draft:

	https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors. Objections, concerns, and suggestions are also welcomed at this time.

Thank you,
NETMOD Chairs

---

From: Kent Watsen <[email-masked]>
Date: Thu, 26 Mar 2020 18:46:44 +0000

Dear All,

This WGLC has received zero responses, which is insufficient to progress the document at this time.  The WGLC is therefore being extended  for another week, now ending April 1st (the day before our Virtual Meeting on April 2nd).  

Again, positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcomed.  This is useful and important, even from authors.  Objections, concerns, and suggestions are also welcomed at this time.

FWIW, the YANG Doctor review was completed on 3/23 (thanks Mahesh) with the “Ready with Nits” status: https://datatracker.ietf.org/doc/review-ietf-netmod-geo-location-04-yangdoctors-lc-jethanandani-2020-03-23.

Kent // as shepherd and co-chair

> On Mar 9, 2020, at 6:30 PM, Kent Watsen <[email-masked]> wrote:
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Christian Hopps <[email-masked]>
Date: Thu, 26 Mar 2020 19:23:57 -0400

> On Mar 26, 2020, at 2:46 PM, Kent Watsen <[email-masked]> wrote:
> 
> Dear All,
> 

Well OK.

As author, I support this work. It has undergone multiple reviews, and revisiions, and I think it's ready to ship.

It was well supported during the adoption call, maybe it's covid getting in the way of things.

Thanks,
Chris.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 26 Mar 2020 23:35:31 -0700

As someone who has reviewed the draft, I want to say I support the work. The draft is short and easy to read.

Thanks.

> On Mar 26, 2020, at 11:46 AM, Kent Watsen <[email-masked]> wrote:
> 
> Dear All,
> 
> FWIW, the YANG Doctor review was completed on 3/23 (thanks Mahesh) with the “Ready with Nits” status: https://datatracker.ietf.org/doc/review-ietf-netmod-geo-location-04-yangdoctors-lc-jethanandani-2020-03-23 <https://datatracker.ietf.org/doc/review-ietf-netmod-geo-location-04-yangdoctors-lc-jethanandani-2020-03-23>.
> 
>> On Mar 9, 2020, at 6:30 PM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 	https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04 <https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04>
>>

---

From: tom petch <[email-masked]>
Date: Fri, 27 Mar 2020 17:09:08 +0000

Kent

Not Ready

I thought that so obvious that it was not worth saying:-)

e.g.
IANA considerations does not register the namespace so there is no module
Security Considerations does not use template (which other grouping modules such as Kent's do)
No YANG version
Wrong prefix for ietf-yang-types
No reference clause for yang types
A wholesale lack of YANG reference clauses; perhaps half a dozen needed
No Normative reference for yang-types
Insufficient information for IANA - I infer they are being asked to create a registry but details seem lacking compared to the requirements in RFC8126

At which point I stop and await a fresh revision before having another go.

Tom Petch

________________________________________
From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Sent: 26 March 2020 18:46

Dear All,

On Mar 9, 2020, at 6:30 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Thank you,
NETMOD Chairs

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 27 Mar 2020 10:37:07 -0700

Hi Tom,

Not questioning the Not Ready status for the overall draft, but on the issues you raise about the yang model ...

> On Mar 27, 2020, at 10:09 AM, tom petch <[email-masked]> wrote:
> 
> Kent
> 
> Not Ready
> 

Which version statement were you referring to? There is one in the model with the date 2019-02-17. 

> Wrong prefix for ietf-yang-types

Does the prefix have to be the same as what the model declares? None of the tools complain about it. 

> No reference clause for yang types

Yes, as pointed out in the review. 

> No Normative reference for yang-types

Yes, as pointed out in the review. 

> At which point I stop and await a fresh revision before having another go.

Mahesh Jethanandani 
[email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Fri, 27 Mar 2020 13:39:04 -0400

> On Mar 27, 2020, at 1:09 PM, tom petch <[email-masked]> wrote:
> 
> Kent
> 
> Not Ready
> 

Will add.

> Security Considerations does not use template (which other grouping modules such as Kent's do)

I've pinged Kent for a pointer.

> No YANG version

This means it defaults to 1.0 I thought.

> Wrong prefix for ietf-yang-types

Will change the groupings use from "types" to "yang".

> No reference clause for yang types

Do you mean inside the import ietf-yang-types statement?

> A wholesale lack of YANG reference clauses; perhaps half a dozen needed

I can see 2 places I might could put these, in the "astronomical-body" leaf that references the IAU and in the "geodetic-system" for the default value. We are creating an IANA registry for the values in geodetic-system though so perhaps you are asking for an IANA reference instead? I don't see 4 more obvious places for external references, could you help point them out?

> No Normative reference for yang-types

We add normative document references for imported modules that are not mentioned anywhere else in the actual document? I have no problem doing so, but I haven't done that before.

> Insufficient information for IANA - I infer they are being asked to create a registry but details seem lacking compared to the requirements in RFC8126

Thanks for pointing this out, I'll add this instead of waiting for IANA to complain. :)

Thanks,
Chris.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 Mar 2020 18:32:12 +0000

Chris,

> I've pinged Kent for a pointer.

The template Tom is referring to is from https://tools.ietf.org/html/rfc8407#section-3.7.1.

That said, I have always felt that this template is a starting point that needs to be customized per YANG module (ideally, a separate template instance for each module in the draft).  For instance, if a module defines no "notification” or “rpc" statements, it is better for it to just say that instead of strictly following the template and producing an empty list.

For instance:

	<note: a separate template instance per YANG module in draft>
	https://tools.ietf.org/html/rfc8572#section-9.15. (only defines an rc:yang-data structure)
	https://tools.ietf.org/html/rfc8572#section-9.16 (only defines a couple “rpc” statements)

	<the following are unpublished, so may not be perfect>
	https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-04.html#section-6 (only defines “grouping”)
	https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-04.html#section-5 (only defines “grouping”)

Kent // contributor

---

From: tom petch <[email-masked]>
Date: Sat, 28 Mar 2020 12:36:01 +0000

From: Christian Hopps <[email-masked]>
Sent: 27 March 2020 17:39

> IANA considerations does not register the namespace so there is no module
Will add.
<tp> RFC8344 gets that right - note the reference to RFC6020

I've pinged Kent for a pointer.
<tp> and Kent has responded

This means it defaults to 1.0 I thought.
<tp> RFC8407 template has 1.1 and says that that is a SHOULD
 
Will change the groupings use from "types" to "yang".
<tp> yes please that is a MUST in RFC8407  

Do you mean inside the import ietf-yang-types statement?
<tp> yes that is a SHOULD in RFC8407

I can see 2 places I might could put these, in the "astronomical-body" leaf that references the IAU and in the "geodetic-system" for the default value. We are creating an IANA registry for the values in geodetic-system though so perhaps you are asking for an IANA reference instead? I don't see 4 more obvious places for external references, could you help point them out?
<tp> A good starting point is any reference in the body of the I-D should be in the YANG module too in a reference clause, such as www.iau.org, IS6709, WGS84 and may be more than once for different description clauses.  velocity could include the formula or refer back to RFCXXXX perhaps timestamp too.  RFC8344 has enough (but not too many IMHO).

We add normative document references for imported modules that are not mentioned anywhere else in the actual document? I have no problem doing so, but I haven't done that before.
<tp> Normative reference for an import is MUST in RFC8407 and you will need to add a reference in the body of the I-D to avoid unused reference; RFC8344 s.4 gets that right

Thanks for pointing this out, I'll add this instead of waiting for IANA to complain. :)
<tp> Note the point about naming, a two tier structure with the top level being key.  Historically, many significant registries have been given unfortunate names making the data scattered and hard to find (SNMP).  Whether this should be a top level on its own of whether it should fall under something more generic, such as orphan YANG registries, I would be interested to hear other views on.

Tom Petch

Thanks,
Chris.

---

From: tom petch <[email-masked]>
Date: Sat, 28 Mar 2020 12:38:52 +0000

from: Mahesh Jethanandani <[email-masked]>
Sent: 27 March 2020 17:37
Hi Tom,

<tp>
Mahesh
see my reply to Christian - I think I have covered the points that you raise except why the tools do not give you a warning about them!
tom petch

Mahesh Jethanandani
[email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Sat, 28 Mar 2020 09:39:34 -0400

> On Mar 28, 2020, at 8:36 AM, tom petch <[email-masked]> wrote:
> 

I'll go through the doc, and see what else I might could add. A couple points in the meantime though...

Some of these references (non-normative) in the document are for the comparisons to other work, and they point at other outside normative definitions for similar objects. I think it would be wrong to put references in the YANG module that point away from the definitive work (this document) and towards some other normative standard.

For velocity, referring back to the RFC that defines the module within sub-statements of the module seems rather redundant. The reference at the top of the module is the default reference for the module, if one starts adding the same reference to module sub-statements where does it end?

Other than that, I'll comb through again to look for normative references that aren't yet in the module, and also address your other concerns in a follow up version of the document.

Thanks for the review and comments!

Chris.

---

From: tom petch <[email-masked]>
Date: Sun, 29 Mar 2020 14:58:23 +0000

________________________________________
From: Christian Hopps <[email-masked]>
Sent: 28 March 2020 13:39

<tp>
Christian
Think of an operator trouble shooting a velocity-related incident.  The YANG module is readily available and the description clause and any other part of the leaf definition is on the screen.  If that is all, and it is not enough, then the operator has to 
- pull up the entire YANG module
- scroll to the top and find the RFC  from which the module was extracted
- pull up the RFC and search it in its entirety
Contrast that with a YANG reference clause that says RFC XXXX s.2.3 which the OAM system may already have as a URL.
Likewise if the authority for syntax, semantics etc is a third party such as IAU, then better the reference clause takes the user straight there.
I think that the description clauses are good, often they are too thin, but sometimes more detail is wanted and that is where the YANG reference clause comes to the fore.
YANG modules need to be user-friendly when stand-alone.
Tom Petch

Chris.