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 protected]` [email protected]: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 protected]> wrote: > > 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
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
