[netmod] More references was re: References Re: RFC 6991

[tom petch <[e-mail]>]

In reviewing YANG modules recently I have kept an eye on the typedef defined therein to see if any seem worthy of more general use by including them in rfc6991-bis.  There are plenty of them but none of the ones I menton below stand out as obvious candidates for inclusion.

dhc-dhcpv6-yang has a more sophisticated variant of duid than RFC6991

interface-ref is quite widely used, with a definition in RFC8343

vlan-id has generated some discussion and what I now expect to see is an import from the IEEE dot1q-types as in detnet-yang.  It might be useful to point users to ther IEEE module but that may be one for a RFC8284-bis

Likewise there are several flavours of  node identifiers arising out of the work in TEAS and CCAMP as in the modules teas-te and teas-types but again, more for a 8294-bis

vtnid and vpnid I see cropping up but ditto.

detnet-yang has several but they seem parochial apart from such as MPLS operations; ditto again

'area' as in LSR protocols would seem a candidate but the format is different for the two protocols so it would probably be a mistake to have a 'common' definition since there isn't one!

the I2NSF I-D have several typedef and they tend to relate to the upper layers and so are closer to RFC6991.
i2nsf-consumer-facing -interface has its own flavour of time
i2nsf-nsf-facing-dm defines day, month and time
i2nsf-nsf-monitoring has login role, severity, log-action

admin-status occurs in more than one place.

Tom Petch

From: netmod <[e-mail]> on behalf of tom petch <[e-mail]>
Sent: 10 January 2022 12:14
Subject: [netmod] References Re:   RFC 6991

From: netmod <[e-mail]> on behalf of Jürgen Schönwälder <[e-mail]>
Sent: 04 January 2022 00:15
Subject: Re: [netmod]  RFC 6991 and ২০২২-০১-০৩T২১:৪০:০০

Jürgen

Looking at the references in rfc6991-bis I see two that might be updated

-RFC793 is being obsoleted by 793bis and is with the IESG and so not likely to cause a delay

-IEEE 802 is now 802-2014

while RFC7950 changed the rules for an identifier from those in RFC6020.

Tom Petch









On Tue, Jan 04, 2022 at 12:03:17AM +0100, Carsten Bormann wrote:
> Hi Jürgen,
>
> On 2022-01-03, at 22:25, Jürgen Schönwälder <[e-mail]> wrote:
> >
> > On Mon, Jan 03, 2022 at 10:05:15PM +0100, Carsten Bormann wrote:
> >> Does my little example of the approximate current time (২০২২-০১-০৩T২১:৪০:০০) match RFC 6991 date-and-time?
> >>
> >> I think it does, but I’m also pretty sure that wasn’t intended.
> >> There are a few more cases of \d in RFC 6991, where the equivalent definitely wouldn’t work.
> >>
> >
> > The example may pass the pattern but it likely does not statisfy the
> > additional requirements spelled out in the description statement.
>
> I understand that, but there are two observations:
>
> (1) as noted, the pattern is too permissive (unnecessarily so, as \d can simply be replaced with [0-9] to match Section 5.6 of RFC 3339).

There are always discussions about how strict pattern should be. If
you look at draft-ietf-netmod-rfc6991-bis-08, you will see that
changes were already proposed to tighten the pattern to exclude some
invalid numbers - at the expense of readability, the usual trade-off.

That said, perhaps it is a good idea to replace the remaining uses of
\d in ietf-yang-types where we really mean [0-9] to clearly exclude
any other characters representing digits.

> (2) but you cannot ignore the pattern, as it also is more restrictive than the description indicates (it requires capital T and, if present, capital Z — see the note in Section 5.6 on how such a restriction of the case-insensitive RFC 3339 format is allowed, but then the assertion "The profile is defined by the date-time production in Section 5.6 of RFC 3339.” in the YANG description statement is, err, not the whole story).

Yes, both, the pattern statement(s) and the description statement are
relevant. I have no direct access to ISO 8601 so I can't check what it
actually says about t and z. Wikipedia gives this little bit of
information:

  In ISO 8601:2004 it was permitted to omit the "T" character by
  mutual agreement as in "200704051430", but this provision was
  removed in ISO 8601-1:2019. Separating date and time parts with
  other characters such as space is not allowed in ISO 8601, but
  allowed in its profile RFC 3339.

  [https://en.wikipedia.org/w/index.php?title=ISO_8601&oldid=1062916554]

If we would have allowed t and z for YANG's date-and-time, then we may
have created another incompatibility with the XSD dateTime definition,
which I think only allows T and Z. Given that we are in 2022, it may
be reasonably safe to assume that systems can create or process the
two capital letters T and Z. ;-)

/js

--
Juergen Schoenwaelder           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