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

[tom petch <[e-mail]>]

A fresh belated thought.

The I2NSF I-D drew a DISCUSS from Francesca because the strings did not have language tags as per RFC2277.  This was added along with a 25-line pattern for the language tag, much simplified.  The string was wrong which led to a revised pattern.  Meanwhile other I2NSF I-D drew the same DISCUSS and were similarly revised so we have multiple 25-line patterns (which may now be right).

With Francesca on the IESG, I can see many YANG I-D attracting the same comment so rather than having dozens of copies of the pattern, an importable type, suitably checked by an expert (Martin Durst comes to mind) would seem prudent.

RFC6991-bis would seem the place to put it but it really needs to be now, not next year.

Tom Petch 

________________________________________
From: netmod <[e-mail]> on behalf of tom petch <[e-mail]>
Sent: 24 March 2022 17:17
To: Andy Bierman; Jürgen Schönwälder
Cc: [e-mail]
Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

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