On Tue, Mar 30, 2021 at 10:22 AM Martin Björklund <[email protected]> wrote:
> Hi, > > "Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]> 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 think RFC 7950 is clear in this regard. What concerns me is the idea that a "new YANG" can be defined that overrides RFC 7950 (in any way) without actually updating the YANG version number, or without any formal development of a new YANG language version. > 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? > > No, because it is clear that description-stmt semantics are just as normative as a pattern-stmt semantics or range-stmt semantics, etc. > > /martin > > Andy > > > > > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
