Re: [art] [Last-Call] Artart last call review of draft-ietf-core-problem-details-05

Ira McDonald <blueroofmusic@gmail.com> Fri, 24 June 2022 10:21 UTC

Return-Path: <blueroofmusic@gmail.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8EFC15CF56; Fri, 24 Jun 2022 03:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru93Knx5bnSm; Fri, 24 Jun 2022 03:21:50 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D9EC15CF55; Fri, 24 Jun 2022 03:21:50 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id h7so1878704vsr.11; Fri, 24 Jun 2022 03:21:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=krxyzeYqeBRAVMb8OLplsP6vj3uyP1nEJqukH0QbxYc=; b=Rfgs1tHboQ/3cKArlPgF0aX4F2s145tJNPlmXk++ruzi+A8E54jPYGQWy8uRtQ68A4 1evppu+TsTE6wuB4KgwE8yuLXmFRGfvsiZaWS4vBqhoyKnohdhpMXGf25ZJiHmBM8xGE tjfEVY8UmVEkgCUCw/sMn/2I/QmL45tpTF8oyrfe/i+eL3jukrGlzQcszmqdyeaeCWIc nuasU3Pqd4qfa38IaS8F4UtGg5jOa+d2oC/PUb+bNqupxlM+RfWNpQ9Ej/j2uOIlyse2 PW4gaXib1E4AZGv3hzkyiivhSDCipiraE8PfmodkVXyh4/kWiClDscRy4HxcgerccXza CRng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=krxyzeYqeBRAVMb8OLplsP6vj3uyP1nEJqukH0QbxYc=; b=ov9Jb0COjZUkUmJmaSe1IUMi5beyTNkLB8PGSRSKflXP/x8wIdd2s7NFufYfOdub0G 9cUseScK6VGjsOa0LWl1MCDnMbEIUJSCVUX2VEm/7BLvjqqwPwmhRUSVAAl9eEuPKrFC sufLjV2z+qDTqHYWlNnOMJs3XJ6iiGUkEz/QrybWgfF6rHcSykmm5BQTzVBQYsUKLaxp 24fLH6beHnLKotyLOv1bz25hFaZ762Aa6nOCPooI5/ACAzTAK8C/nUkuDKWp5YO09a+T W56xBZmp99y0vajsTh40N7EjAcVfBnl5pWx4cjbGJli2yTbdK5n5mcid4YX34nOt0FNg fyCQ==
X-Gm-Message-State: AJIora8V05AgEiKvMlDGFiJgKb1XwjowyEWi8mkMIY1pQulPNiJr86w4 aPvigU1q8SF8KyLU2LvjSPhk+vxP3TmYcdofy9s=
X-Google-Smtp-Source: AGRyM1s1+l2MCjrRFBQELIHzeNKNGNbmwrEeBFWqgujLQsO75BHh5Efua2UItZYBlSTtDTgJJA82PQR70tGQduaf8Go=
X-Received: by 2002:a05:6102:3047:b0:34c:2d9:e3db with SMTP id w7-20020a056102304700b0034c02d9e3dbmr19539374vsa.3.1656066109621; Fri, 24 Jun 2022 03:21:49 -0700 (PDT)
MIME-Version: 1.0
References: <165511479760.19573.12671700576299137749@ietfa.amsl.com> <63D13796-758D-469B-AFA8-3050C9F87819@tzi.org> <dde9d36c-61e5-afcc-e15a-787c99d5fba9@it.aoyama.ac.jp> <CAN40gSuhSAOH3WRPETXU4s1468eXb_g-=sfWFmXXTvekEddqYQ@mail.gmail.com> <034DDF0F-FEF2-456B-B9ED-76B8F2B6C4BF@tzi.org> <CAN40gSuGJOChjAY9fFD5Gwqn9CaLH09-m5MKb5Gfg8HH9WYjvA@mail.gmail.com> <0359E066-79F3-4AAB-92A5-30B5E01D16CE@tzi.org> <CAN40gSuR12WE=NC-MqGvCX1z+XNVn+5X94VFH1qHE373gbQR_w@mail.gmail.com> <62B57BC0.9080706@btconnect.com>
In-Reply-To: <62B57BC0.9080706@btconnect.com>
From: Ira McDonald <blueroofmusic@gmail.com>
Date: Fri, 24 Jun 2022 06:20:47 -0400
Message-ID: <CAN40gSsg+nbDejC2d34wpLhecUnGTEZL6RAHjT5UUKTJWRS7Uw@mail.gmail.com>
To: tom petch <daedulus@btconnect.com>
Cc: Carsten Bormann <cabo@tzi.org>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Harald Alvestrand <harald@alvestrand.no>, Applications and Real-Time Area Discussion <art@ietf.org>, Core WG mailing list <core@ietf.org>, draft-ietf-core-problem-details.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="000000000000304bda05e22ef0cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/INz6bSybOW4CsPr8HebgaEG8LBE>
Subject: Re: [art] [Last-Call] Artart last call review of draft-ietf-core-problem-details-05
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2022 10:21:51 -0000

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.

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@btconnect.com> 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@tzi.org> wrote:
> >
> >> On 2022-06-23, at 13:13, Ira McDonald <blueroofmusic@gmail.com> 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://github.com/core-wg/core-problem-details/pull/40/commits/bbe72e2
> >>
> >> (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
> >
>