Jason, the type defined below has a value space that consists of the set of prime numbers in the range 0 to 4294967295.
typedef prime { type uint32; description "The set of prime numbers that can be represented in the uint32 range".; } People are way too focused on machine readable constructs but these constructs often only capture a small part of the story. Yes, I can inline this into a leaf definition, but this does not change the value space of the (unnamed) type used by the leaf. leaf prime { type uint32; description "This leaf holds a prime number in the uint32 range"; } /js On Tue, Mar 30, 2021 at 06:47:35PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Thanks Martin. > > Maybe I'm in the minority thinking the definition in RFC7950 is slightly > ambiguous. If anyone else thinks it might be, then let us know. Otherwise I'm > fine to just stick with the 7950 definition. > > That example in 6991 is a typedef which has a description statement. But a > leaf that doesn't use a typedef may have a description for the leaf (not part > of the type) that affects the value space. > > Jason > > > -----Original Message----- > > From: Martin Björklund <mbj+i...@4668.se> > > Sent: Tuesday, March 30, 2021 1:22 PM > > To: Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@nokia.com> > > Cc: ie...@btconnect.com; mbj+i...@4668.se; j.schoenwaelder@jacobs- > > university.de; netmod@ietf.org > > Subject: Re: [netmod] review of state NBC rules in yang-module-versioning- > > 02 > > > > Hi, > > > > "Sterne, Jason (Nokia - CA/Ottawa)" <jason.ste...@nokia.com> wrote: > > > 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 > > > ? > > > > Yes; the definition in RFC 7950 is: > > > > 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. > > > > So line 20 and 30 together defines the set of values permitted byu > > this type. > > > > > 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? > > > > Yes. > > > > > 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 ? > > > > Perhaps a better example is inet:uri from RFC 6991, which is defined > > as: > > > > typedef uri { > > type string; > > description > > "The uri type represents a Uniform Resource Identifier > > (URI) as defined by STD 66. > > > > Objects using the uri type MUST be in US-ASCII encoding, > > and MUST be normalized as described by RFC 3986 Sections > > 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary > > percent-encoding is removed, and all case-insensitive > > characters are set to lowercase except for hexadecimal > > digits, which are normalized to uppercase as described in > > Section 6.2.2.1. > > > > The purpose of this normalization is to help provide > > unique URIs. Note that this normalization is not > > sufficient to provide uniqueness. Two URIs that are > > textually distinct after this normalization may still be > > equivalent. > > > > Objects using the uri type may restrict the schemes that > > they permit. For example, 'data:' and 'urn:' schemes > > might not be appropriate. > > > > A zero-length URI is not a valid URI. This can be used to > > express 'URI absent' where required. > > > > In the value set and its semantics, this type is equivalent > > to the Uri SMIv2 textual convention defined in RFC 5017."; > > reference > > "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax > > RFC 3305: Report from the Joint W3C/IETF URI Planning Interest > > Group: Uniform Resource Identifiers (URIs), URLs, > > and Uniform Resource Names (URNs): Clarifications > > and Recommendations > > RFC 5017: MIB Textual Conventions for Uniform Resource > > Identifiers (URIs)"; > > } > > > > The value space is all legal URIs, even though there is no pattern > > defined. An implementation may hook up a standard uri parser to > > objects of this type. > > > > Are we discussing a real problem here? > > > > > > > > /martin > > > > > > > > > > Jason > > > > > > > -----Original Message----- > > > > From: tom petch <ie...@btconnect.com> > > > > Sent: Tuesday, March 30, 2021 11:51 AM > > > > To: Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@nokia.com>; > > Martin > > > > Björklund <mbj+i...@4668.se>; j.schoenwael...@jacobs-university.de > > > > Cc: netmod@ietf.org > > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > versioning- > > > > 02 > > > > > > > > From: netmod <netmod-boun...@ietf.org> on behalf of Sterne, Jason > > > > (Nokia - CA/Ottawa) <jason.ste...@nokia.com> > > > > 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 <mbj+i...@4668.se> > > > > > Sent: Tuesday, March 30, 2021 2:10 AM > > > > > To: j.schoenwael...@jacobs-university.de > > > > > Cc: Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@nokia.com>; > > > > > netmod@ietf.org > > > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > > > versioning- > > > > > 02 > > > > > > > > > > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> > > 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 > > > > > > netmod@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > -- 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