Hi guys,
Let's take this model for a leaf (line numbers for reference):
10 leaf foo {
20 type uint8 {
30 range "5..101";
40 }
50 }
When I've been talking about "type" I've only been talking about line 20. The
base type of the leaf.
But are you guys considering that the term "type" includes 20 and 30 ?
I'm not sure that RFC7950 is terribly clear when it mentions "data type" below.
Isn't that a bit ambiguous as to whether it includes line 30 or not?
In the example above I think the value space is 5..101. Is that correct?
But what about a description like this ?
10 leaf bar {
20 type uint8 {
30 range "5..101";
40 }
50 description "actually only takes values 5..88 in all current supported
implementations";
60 }
That description isn't a substatement of the "type" statement. Is the value
space 5..101 or 5..88 ?
Jason
> -----Original Message-----
> From: tom petch <[email protected]>
> Sent: Tuesday, March 30, 2021 11:51 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>; Martin
> Björklund <[email protected]>; [email protected]
> Cc: [email protected]
> Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-
> 02
>
> From: netmod <[email protected]> on behalf of Sterne, Jason
> (Nokia - CA/Ottawa) <[email protected]>
> Sent: 30 March 2021 13:13
> Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-
> 02
>
> Hi guys,
>
> The text in 7950 doesn't mention anything about semantics in the
> description. That is part of what made me feel it isn't accurate or complete.
>
> It also doesn't mention constraints like range or pattern. It only mentions
> the
> type.
>
> <tp>
> I am with Martin and Juergen on this one. You pick on two of the ten
> substatements for type but all are part of the definition of a type and are
> relevant in defining the value space; and elsewhere in the RFC, e.g.
> decimal64, there are explicit descriptions of the value space. Whereas if you
> take, say, uint32 what more do you need to say to describe the value space?
>
> Tom Petch
>
> Jason
>
> > -----Original Message-----
> > From: Martin Björklund <[email protected]>
> > Sent: Tuesday, March 30, 2021 2:10 AM
> > To: [email protected]
> > Cc: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>;
> > [email protected]
> > Subject: Re: [netmod] review of state NBC rules in yang-module-
> versioning-
> > 02
> >
> > Juergen Schoenwaelder <[email protected]> wrote:
> > > On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason (Nokia -
> > CA/Ottawa) wrote:
> > > > Hi all,
> > > >
> > > > I took a look at section "3.1.2 Backwards-compatibility rules for config
> > false and output data" of https://tools.ietf.org/html/draft-ietf-netmod-
> > yang-module-versioning-02.
> > > >
> > > > Here are some suggestions (mostly just editorial - I agree with the
> > general spirit of what's in here).
> > > >
> > > > (A) Valuespace
> > > >
> > > > Valuespace is defined in module versioning 02:
> > > > o Valuespace: The valuespace of a leaf or leaf-list is the set of
> > > > values that the schema node may have according to the type and
> > > > constraint statements of the YANG model.
> > > >
> > > > It seems to be a more complete definition than "value space" in
> RFC7950
> > (which doesn't seem to take into account "range", "pattern", etc
> > statements):
> > > >
> > > > o value space: For a data type; the set of values permitted by the
> > > >
> > > > data type. For a leaf or leaf-list instance; the value space of
> > > >
> > > > its data type.
> > > >
> > > > Should we mention that this definition replaces/supercedes that of
> 7950
> > (at least for the scope of the module versioning doc) ?
> > >
> > > Please no. RFC 7950 says data type and for me this includes everything
> > > that defines a type, including the semantics carried in the type's
> > > description statement.
> > >
> > > We do not need to fix what is not broken. Why do we need a new
> > > definition at all? If definitions in RFC 7950 are broken, then we
> > > need to fix it in YANG next.
> >
> > +1. I don't think the text in RFC 7950 is broken. It is better if
> > the new document refers to the defintion in RFC 7950, rather than
> > providing its own defintion with new words.
> >
> >
> > /martin
> >
> >
> >
> > >
> > > /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/>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
