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

[tom petch <[e-mail]>]

From: Jürgen Schönwälder <[e-mail]>
Sent: 24 June 2022 11:02

Tom,

I agree that there should be a reusable typedef for language tags
instead of copying a long pattern around. rfc6991-bis could be a home
for this but work on rfc6991-bis stalled because we could not settle
the debate about IP address types. Perhaps it is easier to roll an
ietf-lang YANG module that initially just defined a language tag TC.


<tp>

Two additional thoughts.  Martin Durst has seen the YANG for language tags in the I2NSF I-D and says that it is 'complete overkill'.  Also, 10 IPR claims have been submitted against I2NSF I-D, albeit for older versions, with 'Possible Royalty/Fee' so I have gone off the idea of using anything from that WG.  I see that others use just a length constraint for the basic format which is hardly worth a type.

Tom Petch
/js

On Fri, Jun 24, 2022 at 09:37:30AM +0000, tom petch wrote:
> 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

--
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>