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
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
