Subject: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

From: Kent Watsen <[email-masked]>
Date: Fri, 4 Feb 2022 02:54:07 +0000

Dear NETMOD WG,

This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11 ending on Friday, February 18th.  Here is a direct link to the HTML version of the draft:

	https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html

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,
Kent (as co-chair)

---

From: Reshad Rahman <[email-masked]>
Date: Mon, 14 Feb 2022 14:05:12 +0000 (UTC)

I have reviewed this document, no concerns. I believe it is ready for publication.
Regards,Reshad.
    On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen <[email-masked]> wrote:  
 
 Dear NETMOD WG,

Thank you,
Kent (as co-chair)

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

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Feb 2022 22:42:36 +0000

Thank you Reshad for your reply.

All, the WGLC is set to close in three days, but first there needs to be more responses…can others provide comments too?   Especially authors of other drafts in progress ;)

Thanks, 
Kent  (and Lou)

> On Feb 14, 2022, at 9:05 AM, Reshad Rahman <[email-masked]> wrote:
> 
> Regards,
> Reshad.
>     https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 14 Feb 2022 16:49:00 -0600

I have followed the discussions on this draft and believe it is ready for publication.

---

From: "maqiufang (A)" <[email-masked]>
Date: Tue, 15 Feb 2022 12:12:04 +0000

Hi, all
I have read the document and support the publication of this work.
I have only one comment: It seems that Table 2 doesn’t list all the types defined in “ietf-inet-types” YANG module, e.g., protocol-number, ip-address-link-local, ip-address-and-prefix… Should this be fixed?

Best Regards,
Qiufang

From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Tuesday, February 15, 2022 6:43 AM
To: Reshad Rahman <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

Thanks,
Kent  (and Lou)

On Feb 14, 2022, at 9:05 AM, Reshad Rahman <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Reshad.

On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Dear NETMOD WG,

Thank you,
Kent (as co-chair)

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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 15 Feb 2022 14:37:40 +0100

+1

B.

On 2/14/2022 11:49 PM, Mahesh Jethanandani wrote:
>> This message begins a two-week WGLC for 
>> draft-ietf-netmod-rfc6991-bis-11 ending on Friday, February 18th.  
>> Here is a direct link to the HTML version of the draft:
>>
>> 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,
>> Kent (as co-chair)
>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 15 Feb 2022 16:42:22 +0000

I have reviewed this document. I believe it is in good shape and ready to proceed toward publication. 

Cheers,
Charles

> On Feb 3, 2022, at 6:54 PM, Kent Watsen <[email-masked]> wrote:
> 
> Dear NETMOD WG,
>

---

From: Jürgen Schönwälder <[email-masked]>
Date: Fri, 18 Feb 2022 17:22:57 +0100

On Tue, Feb 15, 2022 at 12:12:04PM +0000, maqiufang (A) wrote:

> I have only one comment: It seems that Table 2 doesn’t list all the
> types defined in “ietf-inet-types” YANG module, e.g.,
> protocol-number, ip-address-link-local, ip-address-and-prefix…
> Should this be fixed?

Yes, this should be fixed. When the initial version was produced,
there was quite some concern about consistency with SMIv2 definitions
and this lead to the tables. Meanwhile, I assume the purpose of the
tables is more to provide a quick overview. Hence I propose to split
the tables into (i) tables that provide an overview of all types
defined in the YANG modules and (ii) tables that detail equivalent
SMIv2 types where they exist (short tables). For the overview tables,
I suggest to add some more information. I am thinking of overview
tables like these (keep scrolling, there is more text below):

* ietf-yang-types

  | Typedef               | Type              | Introduced |
  |-----------------------+-------------------+------------|
  | counter32             | uint32            | RFC 6021   |
  | zero-based-counter32  | uint32            | RFC 6021   |
  | counter64             | uint64            | RFC 6021   |
  | zero-based-counter64  | uint64            | RFC 6021   |
  | gauge32               | uint32            | RFC 6021   |
  | gauge64               | uint64            | RFC 6021   |
  |-----------------------+-------------------+------------|
  | object-identifier     | string            | RFC 6021   |
  | object-identifier-128 | object-identifier | RFC 6021   |
  |-----------------------+-------------------+------------|
  | date-and-time         | string            | RFC 6021   |
  | date                  | string            | RFC XXXX   |
  | time                  | string            | RFC XXXX   |
  |-----------------------+-------------------+------------|
  | hours32               | int32             | RFC XXX    |
  | minutes32             | int32             | RFC XXX    |
  | seconds32             | int32             | RFC XXX    |
  | centiseconds32        | int32             | RFC XXX    |
  | milliseconds32        | int32             | RFC XXX    |
  | microseconds32        | int32             | RFC XXX    |
  | microseconds64        | int64             | RFC XXX    |
  | nanoseconds32         | int32             | RFC XXX    |
  | nanoseconds64         | int64             | RFC XXX    |
  | timeticks             | int32             | RFC 6020   |
  | timestamp             | timeticks         | RFC 6020   |
  |-----------------------+-------------------+------------|
  | phys-address          | string            | RFC 6020   |
  | mac-address           | string            | RFC 6020   |
  |-----------------------+-------------------+------------|
  | xpath1.0              | string            | RFC 6020   |
  | hex-string            | string            | RFC 6991   |
  | uuid                  | string            | RFC 6991   |
  | dotted-quad           | string            | RFC 6991   |
  | yang-identifier       | string            | RFC 6991   |
  | revision-identifier   | date              | RFC XXXX   |
  |-----------------------+-------------------+------------|
  | percent-i32           | int32             | RFC XXXX   |
  | percent-u32           | uint32            | RFC XXXX   |
  | percent               | uint8             | RFC XXXX   |
  |-----------------------+-------------------+------------|

* ietf-inet-types

  | Typedef                 | Type         | Introduced |
  |-------------------------+--------------+------------|
  | ip-version              | enum         | RFC 6021   |
  | dscp                    | uint8        | RFC 6021   |
  | ipv6-flow-label         | uint32       | RFC 6021   |
  | port-number             | uint16       | RFC 6021   |
  | protocol-number         | uint8        | RFC XXXX   |
  | as-number               | uint32       | RFC 6021   |
  |-------------------------+--------------+------------|
  | ip-address              | union        | RFC 6021   |
  | ipv4-address            | string       | RFC 6021   |
  | ipv6-address            | string       | RFC 6021   |
  | ip-address-no-zone      | union        | RFC 6991   |
  | ipv4-address-no-zone    | ipv4-address | RFC 6991   |
  | ipv6-address-no-zone    | ipv6-address | RFC 6991   |
  | ip-address-link-local   | union        | RFC XXXX   |
  | ipv4-address-link-local | ipv4-address | RFC XXXX   |
  | ipv6-address-link-local | ipv6-address | RFC XXXX   |
  | ip-prefix               | union        | RFC 6021   |
  | ipv4-prefix             | string       | RFC 6021   |
  | ipv6-prefix             | string       | RFC 6021   |
  | ip-address-and-prefix   | union        | RFC XXXX   |
  | ipv4-address-and-prefix | string       | RFC XXXX   |
  | ipv6-address-and-prefix | string       | RFC XXXX   |
  |-------------------------+--------------+------------|
  | domain-name             | string       | RFC 6021   |
  | host-name               | domain-name  | RFC XXXX   |
  | host                    | union        | RFC 6021   |
  |-------------------------+--------------+------------|
  | uri                     | string       | RFC 6021   |
  | email-address           | string       | RFC XXXX   |
  |-------------------------+--------------+------------|

In future versions we may add a column indicating the status, but
right now all definitions are current, so I rather not add noise.
(Instead of the column 'Introduced' one could have a column 'Revision'
listing the revision date but somehow pointing to the RFC feels more
valuable for modules that we publish in RFCs. And even better would be
to produce such tables from annotations, perhaps the versioning people
solve that problem.)

While putting these tables together, I noticed that we are not
consistent with the naming. We have percent-i32 and percent-u32 and I
think this is pretty neat since the name indicates that these are
signed and unsigned (int32 and uint32) types. We also have hours32,
minutes32, seconds32, etc. but here the name provides no clue whether
the number is signed. Hence, I suggest to use the naming scheme that
is used for the percent types:

  hours32               -> hours-i32
  minutes32             -> minutes-i32
  seconds32             -> seconds-i32
  centiseconds32        -> centiseconds-i32
  milliseconds32        -> milliseconds-i32
  microseconds32        -> microseconds-i32
  microseconds64        -> microseconds-i64
  nanoseconds32         -> nanoseconds-i32
  nanoseconds64         -> nanoseconds-i64

/js

-- 
Jürgen Schönwälder              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: Martin Björklund <[email-masked]>
Date: Fri, 18 Feb 2022 17:39:14 +0100 (CET)

Hi,

I didn't find any discussion about the new percent types in the list
archives.  Do we really need three types for percent?  We can now
express 4294967295 percent, but not 10.5 percent.

The new tables look good.  s/6020/6021/g though.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Feb 2022 09:11:08 -0800

> express 4294967295 percent, but not 10.5 percent.

IMO it is a mistake to have too many ways to do the same thing.
We already have the "units" statement to add details like "percent" and
"centiseconds".
(And there are RFCs already that define types this way.)

uint8 and int32 and uint32 for percent? Plus the units approach?
I suppose the use-case for uint32 is "measurement of percentage over 2
billion percent".
IMO the units-stmt is sufficient, but there should be a documented
consistent approach
(maybe updating RFC 8407).

> The new tables look good.  s/6020/6021/g though.

Andy

---

From: Vladimir Vassilev <[email-masked]>
Date: Fri, 18 Feb 2022 22:51:29 +0100

On 18/02/2022 18.11, Andy Bierman wrote:
>
>
> On Fri, Feb 18, 2022 at 8:39 AM Martin Björklund <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
> We already have the "units" statement to add details like "percent" 
> and "centiseconds".

+1

How about adding decimal64 as an option? Then 10.5 is solved.

/Vladimir

---

From: Kent Watsen <[email-masked]>
Date: Mon, 28 Feb 2022 23:34:19 +0000

Thank you everyone that participated, the Last Call for this draft is closed successfully!

Authors, please let the chairs know when the issues have been resolved and the draft is ready to be progressed for IESG review.

Kent

> On Feb 3, 2022, at 9:54 PM, Kent Watsen <[email-masked]> wrote:
> 
> Dear NETMOD WG,
>