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.

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

Reply via email to