Slight tweak to the subject line for this narrow focus on YANG
On 24/06/2022 13:28, Martin J. Dürst wrote:
Hello Tom, others,
Thanks for bringing the Yang issues, in particular the leaf_language
definition, to our attention. That leaf_language regular expression is
complete overkill; the same arguments that I gave to Carsten
re. his copied ABNF apply.
It may be too late to fix draft-ietf-i2nsf-nsf-facing-interface-dm, but
if there's still a chance, that would be great. If it's too late for
draft-ietf-i2nsf-nsf-facing-interface-dm, I hope it's not too late for
some other YANG drafts.
I'm glad that Francesca is pushing for language information where it
matters, but we should make sure that this doesn't end up in copying
needlessly complicate regular expressions.
The I2NSF I-D is with the RFC Editor MISSREF as is nsf-monitoring.
-capability has not got language tags while -consumer-facing has and is
still a WG document. IPR claims were submitted this week against all
the I-D with 'Possible Royalty Fee'. Similar claims were submitted
three or four years ago and the inclusion of the Fee led to resistance
about the work being done whereupon the Licensing was changed to be
acceptable. The referenced document in the IPR claim is from 2019. The
referenced sections are the YANG module and the examples and in some
cases the IANA Considerations. The inventor of the unpublished patent
appears to be the same as the IETF partipant who has been driving and
authored much of the I2NSF work. Nothing to do with language tags
except that if the claim is applied to the more recent I-D then it could
cover the regular expression. Having been involved with the I2NSF I-D
for some years, I am no longer surprised by such happenings.
Tom Petch
Regards, Martin.
On 2022-06-24 19:44, tom petch wrote:
Just on the YANG point
On 24/06/2022 11:20, Ira McDonald wrote:
Hi,
Hmm...I knew I should have been silent in this thread...
John - you're right that any future update to RFC 5646 will be carefully
backwards compatible.
And Martin could answer (off list) your question about possible future
changes.
Tom - many copies in YANG or anywhere else is a disturbing idea. Any
computer language
that doesn't have a good mechanism for namespaces, import, and export
isn't
fully baked.
And I know so little about YANG that I don't even know what it can do
here.
Ira,
YANG does have import but it is a bit clunky. The I2NSF have a
cluster of six closely related modules which cries out for a common
module but the WG chose not to use that approach so there is much
replication, much ovelap in their modules e.g. with language tags.
The NETMOD WG produced RFC6991 which provided common types and is used
by almost all YANG modules and 6991bis has just completed WGLC so that
is the natural place to put a language type. 6991 works because it
was based on decades of experience with SMI but other WG are not so
skilled at judging when to create a common module and what to put in
it. The opsawg WG is an interesting case study therein.
So with Francesca raising this issue several times I have asked NETMOD
to include a language tag construction in 6991bis but since the I-D
has a long history and is much overdue, then I expect that they will
be reluctant to act, but I have asked.
Tom Petch
CORE - please delete *all* of your CDDL details for language tags and
just
use one of the
several excellent libraries that correctly parse language tags, when
needed.
All - one of the key ethical reasons for the Internet is fair access to
information for all. The
correct use of language tags is really important. The idea of inferring
human language from
the context is nonsense, because the upper layer context is often the
first
thing discarded.
I will now leave it to Francesca to keep bothering the IESG about
language
tags and return
to my cave and worry about automotive security.
Cheers,
- Ira
*Ira McDonald (Musician / Software Architect)*
*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*
*Co-Chair - TCG Metadata Access Protocol SG*
On Fri, Jun 24, 2022 at 4:54 AM tom petch <daedulus@xxxxxxxxxxxxx>
wrote:
On 23/06/2022 22:08, Ira McDonald wrote:
Hi Carsten,
I take your point about copying from a given RFC.
But the history of IETF Language Tags is RFC 1766 (1995), RFC 3066
(2001),
RFC 4646 (2006), and RFC 5646 (2009). It's a long time since 2009
and,
as
Martin noted, there have been a variety of proposals for updating
language
tags in the past 13 years, so it's reasonably likely that there
will be a
newer
version at some point. And since language tags are now quite
structured,
the chance of not needing syntax changes is fairly low. This draft
RFC
from
CORE wouldn't catch up quickly, presumably.
Probably a left field comment.
I had not heard of, or forgotten about, language tags until the IESG
review of draft-ietf-i2nsf-nsf-facing-interface-dm drew a DISCUSS from
Francesca because the 26 YANG string that were meant to be human
readible had no language tags. She pointed to RFC2277 while saying
that
RFC5646 should be a Normative Reference.
The I-D was revised to include a YANG leaf 'language' with a horrendous
YANG pattern spanning 25 lines.
Two consequences. The pattern, doubtless a gross simplification of
what
it might have been, was wrong and was revised - I have not looked to
see
if it makes sense now but then I did not spot the error in the first
place - so I have the sense that, like trying to specify a pattern for
IPv6 address, language tags are easy to get wrong. Second there is now
a pattern of Francesca throwing DISCUSS at other similar I-D so
language
tags, and their modelling in YANG, could get more attention (at least
while Francesca is on the IESG:-) her comments could have been made
about any number of earlier YANG RFC). The pattern in the I2NSF I-D
cannot be imported into another YANG module, rather each YANG module
that draws a DISCUSS will contain a fresh copy. If ideas evolve, then
there are likely to be many disparate copies.
Tom Petch
Cheers,
- Ira
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
