Re: [netmod] type equivalence

Andy Bierman <andy@yumaworks.com> Fri, 26 February 2021 16:44 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759AA3A1109 for <netmod@ietfa.amsl.com>; Fri, 26 Feb 2021 08:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt-jY2Ay9bsP for <netmod@ietfa.amsl.com>; Fri, 26 Feb 2021 08:44:53 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BC63A10EB for <netmod@ietf.org>; Fri, 26 Feb 2021 08:44:53 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id p21so14701053lfu.11 for <netmod@ietf.org>; Fri, 26 Feb 2021 08:44:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YUcnZRSS4i350d+cuRYa6FTRF0Q9FcwsG27sgY5bMcY=; b=XpgsRj6w4Nn0hsmls0iRxqzL7gFA16j6b41YHhSbFbcH4b/b4U5P8XxfiviAfQMIxJ rfoQqdnAaqyYq1TiPjjnYqeHYuIQKWRqyimuQneCNTSR0KUSYx/LBiSkyEko98BtAtec fu1I5OI4GgED+20k/Tg1SEPmK95RLvPIs2YWDezaWod30gWhyJDQTAk+EZnKuaKNtn3E WCmApL92LcPLjVY7InR2ysLB7K7bVcKmZ9q8HNxuJCG9pFxqCDszH7p+gECzEUynZa7M TDTh1WA2D0GLOmINsogx6RI/DrvokJvOnPYhA4HPqhSt0M4C/sG6gnm2GAuaCCvsVm3F nJug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YUcnZRSS4i350d+cuRYa6FTRF0Q9FcwsG27sgY5bMcY=; b=nxulmgG5eSnyeI7vbwR5G684EWn/seSys+BaHwrJ1XlNY1LM1xn8elYxSbNf+HEZ+T WBboW+oDo5ndBTjVDxHI1z3hT4yeM3klVuQhaB1JHGFK1oMto78YRDnn5tNAc1KU2djw qWB1hBoQJjp9BVOLRgVjxuoP6goIvUeWC1OuNWKYl9TjsrbwOsac388ylyztEkF5370v 9M7Dpel1flpDcgR2qEjhoVlY9ZDAfFLVyH8Vimzibi5KcBGjq2YrzJUoSuKo8mXykzMG 8bLmTwocQiS53oJp9ZZqnKgd2RzVrKT3SPOVnsHZ7fKoQSh8ZA5jylR5gUiYZhN3UICj QDrA==
X-Gm-Message-State: AOAM533SfssOLvyxFJWXs8ckyZkZMFV/Kjup44YJhci/AdoqWtO6y8Pl a/DJPokRdZsLB9eCmQwGZiSO/4lA3n9n+Umw5uBJgA==
X-Google-Smtp-Source: ABdhPJw7H6n29caRbncaWA1yB3eYzPmAeKbui6CDwwu+UQ8/J1C1J/9OglIlz5Xpt9B4QCL7LBBWaSUlbPzTqAlYRX4=
X-Received: by 2002:a05:6512:39c5:: with SMTP id k5mr2220901lfu.478.1614357890753; Fri, 26 Feb 2021 08:44:50 -0800 (PST)
MIME-Version: 1.0
References: <CABCOCHSeMpgjmws0X5HStsbjvr8h=8tP3-qwAdjYfqcX3=-P5g@mail.gmail.com> <20210226.173010.2304782771110060094.id@4668.se> <MN2PR11MB43668FAFF23A1DBCB643C21CB59D9@MN2PR11MB4366.namprd11.prod.outlook.com> <20210226.173638.580648753389514487.id@4668.se>
In-Reply-To: <20210226.173638.580648753389514487.id@4668.se>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 26 Feb 2021 08:44:39 -0800
Message-ID: <CABCOCHT3jDOqMAc0d4K0QC5kqzE=Fogsb=zVu=AD8-_Tj6QrfA@mail.gmail.com>
To: Martin Björklund <mbj+ietf@4668.se>
Cc: Robert Wilton <rwilton@cisco.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009e782305bc3ffc09"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/M_OVuw8B3QlR7pDbj3z9QnsNn6Q>
Subject: Re: [netmod] type equivalence
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2021 16:44:56 -0000

On Fri, Feb 26, 2021 at 8:36 AM Martin Björklund <mbj+ietf@4668.se> wrote:

> "Rob Wilton (rwilton)" <rwilton@cisco.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Martin Björklund <mbj+ietf@4668.se>
> > > Sent: 26 February 2021 16:30
> > > To: andy@yumaworks.com
> > > Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; netmod@ietf.org
> > > Subject: Re: [netmod] type equivalence
> > >
> > > Andy Bierman <andy@yumaworks.com> wrote:
> > > > On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund <mbj+ietf@4668.se>
> > > wrote:
> > > >
> > > > > "Rob Wilton \(rwilton\)" <rwilton=40cisco.com@dmarc.ietf.org>
> wrote:
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Juergen
> > > > > Schoenwaelder
> > > > > > > Sent: 24 February 2021 20:39
> > > > > > > To: netmod@ietf.org
> > > > > > > Subject: Re: [netmod] type equivalence
> > > > > > >
> > > > > > > Here is an attempt to come up with better wording. If people
> agree
> > > on
> > > > > > > a new wording, I volunteer to submit an errata.
> > > > > > >
> > > > > > > OLD
> > > > > > >
> > > > > > >    o  A "type" statement may be replaced with another "type"
> > > statement
> > > > > > >       that does not change the syntax or semantics of the type.
> > > For
> > > > > > >       example, an inline type definition may be replaced with a
> > > > > typedef,
> > > > > > >       but an int8 type cannot be replaced by an int16, since
> the
> > > syntax
> > > > > > >       would change.
> > > > > > >
> > > > > > > NEW
> > > > > > >
> > > > > > >    o  A "type" statement may be replaced with another "type"
> > > statement
> > > > > > >       that does not change the semantics of the type or the
> > > underlying
> > > > > > >       built-in type.  For example, an inline type definition
> may
> > > be
> > > > > > >       replaced with a semantically equivalent typedef derived
> from
> > > the
> > > > > > >       same built-in type, but an int8 type cannot be replaced
> by
> > > an
> > > > > > >       int16, since the underlying built-in type would change.
> > > > >
> > > >
> > > >
> > > > I think the NEW text captures the original intent and is OK for an
> > > errata.
> > >
> > > +1
> > >
> > >
> > > > I believe the use-case discussed at the time of writing was simply
> > > > replacing an inline
> > > > type with the identical type but within a typedef-stmt instead of
> > > > inline
> > > > within a leaf or leaf-list.
> > > >
> > > > Perhaps this rule is too strict.
> > > > There is a simple way to defeat it:
> > > >
> > > > Change all
> > > >    type foo {  ... }
> > > > to
> > > >    type union {
> > > >       type foo { ... }
> > > >     }
> > > >
> > > > Now you can add new values and semantics without taking away the
> > > original
> > > > syntax and semantics.
> > > >
> > > >  type union {
> > > >       type foo { ... }
> > > >       type bar { ... }   // note new member types added at end of
> list
> > > >     }
> > > >
> > > > But it is not clear that this would be legal or completely BC. It
> > > certainly
> > > > could change the encoding in JSON and CBOR.
> > >
> > > It is not allowed by sec 11 in 7950, since it changes the syntax of
> > > the type.
> > [RW]
> >
> > But the proposed errata removes the text about not changing the
> > syntax, or are you referring to other text?
>
> The new text says that the built-in type cannot change, which it does
> if we add a type to a union.  Hmm, perhaps this isn't clear.
>
>

We do not want to see all types defined with union type wrappers from the
start,
just in case.


I do not know if this change is legal in YANG 1.1 but it should be
considered

  existing:
     type foo {}

  update:
     type union {
        type foo {}
        type bar {}
     }


This specifically implies that all values that used to be accepted are
still accepted with
the exact same syntax and semantics as before.  An old client will not know
about the type bar syntax
or semantics, which means it could read values of type bar set by the
server or new clients.
Not great, but not a disaster either.



> /martin
>
>
>
Andy



> >
> > Rob
> >
> >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > > > [RW]
> > > > > >
> > > > > > Would the text be more clear it is just specified what is
> allowed,
> > > e.g.,
> > > > > >
> > > > > >      o  A "type" statement may be replaced with another "type"
> > > statement
> > > > > >         that resolves to the same underlying built-in type.  For
> > > example,
> > > > > >         ...
> > > > > >
> > > > > >
> > > > > > What does "semantics of the type" cover?
> > > > >
> > > > > Suppose you have:
> > > > >
> > > > >    typedef "timestamp" {
> > > > >      type yang:date-time;
> > > > >      description
> > > > >        "The time that an event occurred";
> > > > >    }
> > > > >
> > > > > then you can't change it to:
> > > > >
> > > > >    typedef "timestamp" {
> > > > >      type yang:date-time;
> > > > >      description
> > > > >        "The time that an event was received.";
> > > > >    }
> > > > >
> > > > > The syntax is the same, but the semantics are different.
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > If I have this type:
> > > > > >
> > > > > >   typedef "timestamp" {
> > > > > >     type "string";
> > > > > >     description
> > > > > >       "The time of day that an event occurred, in any format";
> > > > > >   }
> > > > > >
> > > > > > then can I replace it with this definition:
> > > > > >
> > > > > >   typedef "timestamp" {
> > > > > >     type "string";
> > > > > >     description
> > > > > >       "The time of day, and optionally date, that an event
> > > > > >        occurred, in any format";
> > > > > >   }
> > > > > >
> > > > > >
> > > > > >
> > > > > > Tangentially, it is worth noting the RFC 8342 also writes about
> > > syntactic
> > > > > > constraints covering types:
> > > > > >
> > > > > > 5.3.  The Operational State Datastore (<operational>)
> > > > > >
> > > > > >    Syntactic constraints MUST NOT be violated, including
> > > hierarchical
> > > > > >    organization, identifiers, and type-based constraints.  If a
> node
> > > in
> > > > > >    <operational> does not meet the syntactic constraints, then it
> > > > > >    MUST NOT be returned, and some other mechanism should be used
> to
> > > flag
> > > > > >    the error.
> > > > > >
> > > > > > I'm not sure how clear RFC 8342 section 5.3 is about returning
> > > values
> > > > > > that can be represented by the underlying built-in-type, but are
> > > outside
> > > > > > the value space defined by a range, length, or pattern statement.
> > > > > >
> > > > > > My memory during the discussions was that it is allowed to
> return a
> > > value
> > > > > > outside arange, length, pattern statement, as long as it is
> > > contained
> > > > > > in the value space of the built-in-type.  E.g., cannot return
> 257 in
> > > a
> > > > > > uint8, but can return 11 even if the type range is 1..10.
> > > > > >
> > > > > > But, I'm not sure that is what the text actually states.
> > > > > >
> > > > > > Regards,
> > > > > > Rob
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > /js
> > > > > > >
> > > > > > > On Mon, Feb 22, 2021 at 03:20:02PM +0100, Carsten Bormann
> wrote:
> > > > > > > > On 2021-02-22, at 15:17, Juergen Schoenwaelder
> > > > > <j.schoenwaelder@jacobs-
> > > > > > > university.de> wrote:
> > > > > > > > >
> > > > > > > > > I guess considering the built-in types as incompatible is
> the
> > > most
> > > > > > > > > robust approach. If we agree that RFC 7950 tried to say
> this,
> > > we
> > > > > could
> > > > > > > > > file an errata and propose clearer language.
> > > > > > > >
> > > > > > > > Right.  And we can keep the COMI key-to-URL mapping as is, as
> > > this
> > > > > > > clarification is necessary for its correct functioning.
> > > > > > > >
> > > > > > > > Grüße, Carsten
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 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/>
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > netmod mailing list
> > > > > > > netmod@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > >
> > > > > > _______________________________________________
> > > > > > netmod mailing list
> > > > > > netmod@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > >
>