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 <[email protected]>
> > Sent: Tuesday, March 30, 2021 1:22 PM
> > To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>
> > Cc: [email protected]; [email protected]; j.schoenwaelder@jacobs-
> > university.de; [email protected]
> > Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-
> > 02
> >
> > 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'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 <[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
> > >
--
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
