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.
/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 <[email protected]> on behalf of tom petch > <[email protected]> > Sent: 24 March 2022 17:17 > To: Andy Bierman; Jürgen Schönwälder > Cc: [email protected] > Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11 > > From: netmod <[email protected]> on behalf of Jürgen Schönwälder > <[email protected]> > 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 protected]> 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 protected]> > > > 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 protected] > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- 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 protected] https://www.ietf.org/mailman/listinfo/netmod
