On 29/06/2022 15:55, Francesca Palombini wrote:
Hi Tom,
(reducing the CC, adding i18ndir, and changing the subject)
I do my AD review during balloting with the typical ART topics in mind: https://trac.ietf.org/trac/art/wiki/TypicalARTAreaIssues . And yes, that has provoked a number of DISCUSS on YANG documents that included human readable text. In some cases, it was explained to me by the authors that those were not necessary and that clarifications was enough for me to remove the DISCUSS. I do hope that bringing attention to the issue improves the documents (and please let me know if any of you believe that it does not), however I am no i18n expert, and I am happy to get i18n opinions on the best way to “fix it”.
Martin, all: if you have advice on what to recommend authors of YANG drafts coming my way, let me know.
Thanks for bringing the language tag issue to 6991bis – it is best to address it early than getting stuck with a DISCUSS at a later stage :) And I only see documents that I am not responsible for at a very late stage, during IESG evaluation (and often too late to request i18ndir review or opinion).
Francesca
I am conscious that I have been using your name a lot in the past few
weeks - months? - without copying you on any of my posts and that is
discourteous. My apologies; I was going to address you directly but
should have done so earlier.
Much of YANG comes from SMI and SMI has a datatype intended for messages
to operators and such like but YANG does not. The YANG type 'string'
allows a length of 18446744073709551615 and almost any Unicode character
(RFC7950 s.9.4) and is much used for messages and identifiers without
constraint. I have commented on that many times and the usual response
is 'Fine with us'. Mmmm... seeing you raise an issue is good news. (I
think that there are many YANG modules already in RFC that would benefit
from your approach).
You flagged a DISCUSS against the I2NSF I-D and got a revised I-D with a
complex and invalid regex which was edited into a complex and valid
regex. There was no discussion on any list AFAICT about this regex and
the pdf that the I2NSF authors provided with the revised I-D simply said
it had been added with no explanation as to how it was derived; such is
I2NSF.
I then saw the issue about language tags with regard to
core-problem-details and camped onto that. I think Carsten wished I had
not but the major gains for me were Martin's comment - a name I would
turn to for advice in this matter - that the regex was too complex, and
Carsten's much simpler constraint on length (and not character set) for
language tag in the I-D in question.
If a YANG type for language tag needed to be as complex as I2NSF had,
then it needed to be in 6991-bis but if it can be as simple as Carsten's
then it need not, IMHO. This is good news because 6991-bis is somewhate
overdue and has ground to a halt because of a dispute over IP addresses
where those who perhaps had not read RFC6991 assumed they knew what they
were getting from the name of the type whereas the RFC has always been
clear that the simple, ip-address format includes a zone (RFC6991 s.4);
indeed the precursor to RFC6991, RFC6021, did not offer a no-zone
alternative. This issue has come up many times with YANG doctors and
again I have flagged it to many authors of YANG modules, some of whom
have gone for no-zone, others (tcpm-yang, currently in IESG review) kept
the zone. It was one such comment on an LSR I-D that brought this issue
to the attention of the authors of a number of YANG modules which in
turn has created this impasse on 6991-bis.
So, belatedly, two questions for art. When is a language tag needed? I
saw your comment against one I-D and your satisfaction that in this
case, no tag was needed. I do not know what the criteria are, in general.
Second, what is a suitable constraint on a YANG string to be a language
tag? If Carsten's length constraint is adequate, then I would advise
authors to RYO as opposed to waiting for 6991-bis; if something more
complex is needed, especially if it involves restricting the choice of
characters, then it probably belongs in 6991-bis.
Longer term I could imagine an IANA-maintained YANG module of language
tags but with YANG, maintenance by IANA is not as simple as it was with SMI.
Tom Petch
Francesca
From: tom petch <daedulus@xxxxxxxxxxxxx>
Date: Friday, 24 June 2022 at 12:45
To: Ira McDonald <blueroofmusic@xxxxxxxxx>
Cc: Carsten Bormann <cabo@xxxxxxx>, Martin J. Dürst <duerst@xxxxxxxxxxxxxxx>, Harald Alvestrand <harald@xxxxxxxxxxxxx>, Applications and Real-Time Area Discussion <art@xxxxxxxx>, Core WG mailing list <core@xxxxxxxx>, draft-ietf-core-problem-details.all@xxxxxxxx <draft-ietf-core-problem-details.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Re: [Last-Call] [art] Artart last call review of draft-ietf-core-problem-details-05
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
*Ira McDonald (Musician / Software Architect)*
On Thu, Jun 23, 2022 at 2:34 PM Carsten Bormann <cabo@xxxxxxx> wrote:
On 2022-06-23, at 13:13, Ira McDonald <blueroofmusic@xxxxxxxxx> wrote:
Hi Carsten,
OK - you need to get this CORE document published quickly.
Thank you.
But I still think that detailed CDDL would be a long-term mistake, for
the reason
that Martin cited - i.e., copying/transforming grammars among RFCs is
fragile.
Well, the RFC is immutable, so the act of making a copy cannot by itself
be fragile.
What got us to now propose blunting that grammar is the strong
impression
that there may be less consensus about the grammar defined by RFC 5646
than
we thought. So it seems the grammar in RFC 5646 is fragile, not the
act of
copying it out...
https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-49f3e3be3435cd25&q=1&e=93f41461-c9f8-43b4-a55e-379df39a4e0b&u=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fcore-problem-details%2Fpull%2F40%2Fcommits%2Fbbe72e2
(I’m making a point about copying here as I believe copying out snippets
of CDDL from RFCs and other specifications will be a significant part of
CDDL 2.0.)
Grüße, Carsten
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
