Subject: [netmod] RFC 6991 and ২০২২-০১-০৩T২১:৪০:০০

From: Carsten Bormann <[email-masked]>
Date: Mon, 3 Jan 2022 22:05:15 +0100

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.

Happy new year ২০২২ (*), anyway :-)

Grüße, Carsten

(*) (I know we are in ১৪২৮ in at least some of the calendars that would use this writing system…)

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 3 Jan 2022 22:25:36 +0100

> 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.

/js

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Jan 2022 00:03:17 +0100

Hi Jürgen,

> 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).
(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).

(Background: We are wrangling with regexps in JSONPATH and date/time formats in SEDATE, and I’d like to make sure what we do there fits with what we can learn from YANG.)

Grüße, Carsten

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 4 Jan 2022 01:15:08 +0100

> (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 re…

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Jan 2022 01:27:29 +0100

> any other characters representing digits.

Probably.

I keep a little unscientific list of regexp uses in RFCs, and the YANG RFCs are unusual in actually using \d (and clearly not expecting the actual semantics of \d to be used), so this is how I noticed the issue.

> two capital letters T and Z. ;-)

I’m not criticizing the decision to go for upper-case here (case-insensitivity is a remnant from the 1960s/1970s that really needs to be expunged).

I was just commenting how first referencing the unmodified RFC 3339 rules (which pointlessly by default is case-insensitive here) in the description statement and then silently changing the allowable characters via the pattern statement is probably not the best way the pattern and description statements can interact.

I need to read 6991-bis...

Grüße, Carsten

---

From: tom petch <[email-masked]>
Date: Mon, 10 Jan 2022 12:14:32 +0000

From: netmod <[email-masked]> on behalf of Jürgen Schönwälder <[email-masked]>
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

/js

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 10 Jan 2022 13:57:48 +0100

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

Since rfc6991-bis refers to the port number definition, this should be
a no brainer once there is an RFC replacing 793.
 
> -IEEE 802 is now 802-2014

This is more complicated since I usually can't check easily what is in
the new document...
 
> while RFC7950 changed the rules for an identifier from those in RFC6020.

For clarity and to avoid misunderstandings, can you elaborate what the
concern here is?

/js

-- 
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/>

---

From: tom petch <[email-masked]>
Date: Mon, 10 Jan 2022 16:34:41 +0000

________________________________________
From: Jürgen Schönwälder <[email-masked]>
Sent: 10 January 2022 12:57
To: tom petch
Cc: [email-masked]
Subject: Re: References Re: [netmod]  RFC 6991

<tp>
The definition of 'identifier' in RFC7950 is not the same as the definition of 'identifier' in RFC6020 and rfc7991-bis quotes the latter and not the former.  I am not clear what the best way forward is.

Tom Petch 

/js

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 10 Jan 2022 21:49:53 +0100

> The definition of 'identifier' in RFC7950 is not the same as the definition of 'identifier' in RFC6020 and rfc7991-bis quotes the latter and not the former.  I am not clear what the best way forwar…

It helps me and likely also others if we can nail things down and be
explicit. Are you talking about:

RFC 6020:

   ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
   identifier          = (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / ".")

RFC 7991:

   identifier          = (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / ".")

The yang-identifier defined in draft-ietf-netmod-rfc6991-bis-09.txt
did not change and it still references RFC 6020. What exactly is your
concern or proposal? Do you propose to change the definition of
yang-identifier to reference RFC 7950 and to drop the second pattern
(which would be an allowed change according to YANG update rules)? Or
do you propose to add a new definition of a yang-identifier-1.1?

/js

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Jan 2022 23:15:08 +0100

> RFC 7991:

7991 The "xml2rfc" Version 3 Vocabulary. P. Hoffman. December 2016.
     (Format: TXT, HTML) (Obsoletes RFC7749) (Status: INFORMATIONAL)
     (DOI: 10.17487/RFC7991) 

I knew this is all connected, but I think you meant RFC 7950.

Anyway, a YANG module that makes use of the new (1.1) freedom to name something xmlfoo strikes me as somewhat malicious.  But of course the knowledge that you weren’t supposed to do that may wane over time…  Dropping the second pattern makes it easy for referencing modules to import that change, consciously or accidentally.  How bad will the accidents be?  There needs to be a YANG module that uses the identifier in the first place.

Grüße, Carsten

---

From: tom petch <[email-masked]>
Date: Tue, 11 Jan 2022 14:49:02 +0000

From: Jürgen Schönwälder <[email-masked]>
Sent: 10 January 2022 20:49

RFC 6020:

RFC 7991:

<tp2>
As I recall, the issue came up in YANG 1.1 that XML identifiers were  no longer restricted in their first three letters by their SDO and so the limitation in YANG 1.0 was removed from YANG 1.1 (as you quote above).  It then looks anomalous to me to retain that restriction in the type definition when it has been removed from the language definition.  My preference would be to remove that restriction from the definition of 'identifier' in 6991-bis but I am not sure whether or not there are consequences I am missing, hence my diffidence.

As you say, RFC6020 s.10 would appear to allow it.

Tom Petch

/js

---

From: tom petch <[email-masked]>
Date: Tue, 11 Jan 2022 15:20:10 +0000

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 <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 10 January 2022 12:14
Subject: [netmod] References Re:   RFC 6991

Jürgen

Tom Petch

/js

---

From: Jürgen Schönwälder <[email-masked]>
Date: Wed, 12 Jan 2022 08:46:56 +0100

On Tue, Jan 11, 2022 at 02:49:02PM +0000, tom petch wrote:

> As I recall, the issue came up in YANG 1.1 that XML identifiers were
> no longer restricted in their first three letters by their SDO and
> so the limitation in YANG 1.0 was removed from YANG 1.1 (as you
> quote above).  It then looks anomalous to me to retain that
> restriction in the type definition when it has been removed from the
> language definition.  My preference would be to remove that
> restriction from the definition of 'identifier' in 6991-bis but I am
> not sure whether or not there are consequences I am missing, hence
> my diffidence.

I agree and I propose to remove the restriction

       A YANG identifier MUST NOT start with any possible
       combination of the lowercase or uppercase character
       sequence 'xml'.

in order to align the definition of an identifier in YANG 1.1. I will
add text that YANG 1 modules using this typedef may still have this
restriction. If people have an issue with this, please speak up now.

/js