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

[Kent Watsen <[e-mail]>]

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 [e-mail]`
[e-mail]:551: error: keyword "length" not in canonical order (see RFC 6020, Section 12)


Kent



> On Mar 24, 2022, at 1:17 PM, tom petch <[e-mail]> wrote:
> 
> From: netmod <[e-mail]> on behalf of Jürgen Schönwälder <[e-mail]>
> 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 <
>> [e-mail]> 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 <[e-mail]>
>>> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   [phone]         <https://www.jacobs-university.de/>
>>> 
> 
> --
> Jürgen Schönwälder              Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod