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

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Apr 2022 01:24:55 +0000

This draft has been moved out of the WG.  Now in shepherd write-up.

Comments:

Section 4 is titled "Internet-Specific Derived Types"
Should it be something like "Internet Protocol Suite Types"?

Many places have "Simplified BSD"
should be "Revised BSD"

The "description" for "email-address" says:
"The canonical format of the domain part of an email-address uses lowercase US-ASCII characters.".  
But I don't see a lowercase-restriction in the pattern.  
Maybe the description could be clarified?

Note: `pyang --strict -Werror --canonical [email-masked]`
[email-masked]:551: error: keyword "length" not in canonical order (see RFC 6020, Section 12)

Kent

> On Mar 24, 2022, at 1:17 PM, tom petch <[email-masked]> wrote:
> 
> From: netmod <[email-masked]> on behalf of Jürgen Schönwälder <[email-masked]>
> Sent: 22 March 2022 07:11
> 
> So we have the following options:
> 
> a) Leave revision-date to be defined in ietf-yang-revisions.
> 
> b) Define revision-date in ietf-yang-types.
> 
> c) Define a date-no-zone type (derived from the date type) which does
>   not have the optional time zone offset.
> 
> <tp>
> 
> Yes, I like c) for its simplicity and its adequacy
> 
> Tom Petch
> 
> 
> I am leaning towards option c), having a generic type for a date
> without a time zone is the most general type we can provide. If
> additional specific revision date semantics are necessary, they can be
> provided in ietf-yang-revisions. (Looking at the definition of the
> type revision-identifier in RFC 8525, this is really date-no-zone.)
> 
> /js
> 
> On Tue, Mar 15, 2022 at 08:42:31AM -0700, Andy Bierman wrote:
>> On Tue, Mar 15, 2022 at 6:01 AM Jürgen Schönwälder <
>> [email-masked]> wrote:
>> 
>>> On Mon, Mar 14, 2022 at 05:21:01PM -0700, Andy Bierman wrote:
>>>> On Mon, Mar 14, 2022 at 4:34 PM Kent Watsen <[email-masked]>
>>> wrote:
>>>> 
>>>>> All,
>>>>> 
>>>>> 1) If you provided WGLC comments on this draft, please review the -12
>>> diff
>>>>> <
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-12.txt> to
>>>>> ensure that the updates made are good.
>>>>> 
>>>>> 2) Juergen notes below that he also removed the "revision-identifier"
>>>>> typedef, as it is better
>>>>> defined in the YANG versioning module.  Any objections?
>>>>> 
>>>>> 
>>>> Sorry for the late comment.
>>>> I think Juergen listed one option as "rename to revision-date and leave
>>> it
>>>> in this module".
>>>> I support this option.
>>>> 
>>>> There is no chance that the revision date format will be changing any
>>> time
>>>> soon.
>>>> This is useful for general applications because revision date is widely
>>>> used.
>>>> 
>>> 
>>> The ietf-yang-library module (RFC 8525) currently uses its own
>>> definition of revision-identifier. While this module could adopt a
>>> common definition, the value of such a change is minor.
>>> 
>>> The question where we place the definition of revision-date is likely
>>> a matter of which role we expect the versioning work to play in the
>>> future. I am relatively neutral on the placement.
>>> 
>>> 
>> Not that important I guess.
>> One would think the "date" typedef already in the draft would be useful,
>> but it isn't, and therefore not used.
>> There is no typedef for the pattern YYYY-MM-DD.
>> 
>> /js
>>> 
>> 
>> Andy
>> 
>> 
>>> 
>>> --
>>> 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/>
>>> 
> 
> --
> 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/>
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Apr 2022 02:06:36 +0000

Hey Kent,
Are you behind on your Emails or choosing to ignore the ongoing discussion of the ip-address, ipv4-address, and ipv6-address types?
Thanks,
Acee

From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Wednesday, April 6, 2022 at 9:25 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

Comments:
·         Section 4 is titled "Internet-Specific Derived Types"
o    Should it be something like "Internet Protocol Suite Types"?
·         Many places have "Simplified BSD"
o    should be "Revised BSD"

·         The "description" for "email-address" says:
o    "The canonical format of the domain part of an email-address uses lowercase US-ASCII characters.".
§  But I don't see a lowercase-restriction in the pattern.
§  Maybe the description could be clarified?

·         Note: `pyang --strict -Werror --canonical [email-masked]<mailto:[email-masked]>`
o    [email-masked]<mailto:[email-masked]>:551: error: keyword "length" not in canonical order (see RFC 6020, Section 12)

Kent

On Mar 24, 2022, at 1:17 PM, tom petch <[email-masked]<mailto:[email-masked]>> wrote:

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Jürgen Schönwälder <[email-masked]<mailto:[email-masked]>>
Sent: 22 March 2022 07:11

<tp>

Tom Petch

/js

On Tue, Mar 15, 2022 at 6:01 AM Jürgen Schönwälder <
[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Mar 14, 2022 at 4:34 PM Kent Watsen <[email-masked]<mailto:[email-masked]>>
wrote:

All,

<

in this module".
I support this option.

soon.

/js

Andy

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

---

From: Jürgen Schönwälder <[email-masked]>
Date: Fri, 8 Apr 2022 17:00:45 +0200

> Should it be something like "Internet Protocol Suite Types"?

I do not care much, I now have:

   3.  Core YANG Types . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Internet Protocol Suite Types . . . . . . . . . . . . . . . .  21

> Many places have "Simplified BSD"

I had already fixed these in the YANG modules, the other two
occurances in the I-D boilerplate are generated by tooling and I will
leave them as is (and this text will be rewritten by the RFC editor
anyway).

> Maybe the description could be clarified?

Canonical format in YANG means you accepted mixed case as valid input
but you report in lowercase as output. The pattern describe the valid
input, not the canonical format subset.

> [email-masked]:551: error: keyword "length" not in canonical order (see RFC 6020, Section 12)

Fixed.

/js