Re: [netmod] What operational values can NMDA return?

[Martin Björklund <[e-mail]>]

"Rob Wilton \(rwilton\)" <rwilton=[e-mail]> wrote:
> 
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder <[e-mail]>
> > Sent: 26 February 2021 14:28
> > To: Rob Wilton (rwilton) <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [netmod] type equivalence
> > 
> > On Fri, Feb 26, 2021 at 12:21:26PM +0000, Rob Wilton (rwilton) wrote:
> > >
> > > Tangentially, it is worth noting the RFC 8342 also writes about
> > syntactic
> > > constraints covering types:
> > >
> > > 5.3.  The Operational State Datastore (<operational>)
> > >
> > >    Syntactic constraints MUST NOT be violated, including hierarchical
> > >    organization, identifiers, and type-based constraints.  If a node in
> > >    <operational> does not meet the syntactic constraints, then it
> > >    MUST NOT be returned, and some other mechanism should be used to flag
> > >    the error.
> > >
> > > I'm not sure how clear RFC 8342 section 5.3 is about returning values
> > > that can be represented by the underlying built-in-type, but are
> > > outside
> > > the value space defined by a range, length, or pattern statement.
> > >
> > > My memory during the discussions was that it is allowed to return a
> > value
> > > outside arange, length, pattern statement, as long as it is contained
> > > in the value space of the built-in-type.  E.g., cannot return 257 in a
> > > uint8, but can return 11 even if the type range is 1..10.
> > >
> > > But, I'm not sure that is what the text actually states.
> > 
> > Perhaps this requires a separate thread. Perhaps 'syntactic
> > constraints' was not a good choice and yes different people might
> > understand 'type-based constraints' differently. RFC 7950 says:
> > 
> >    The following properties are true in all data trees:
> > 
> >    o  All leaf data values MUST match the type constraints for the leaf,
> >       including those defined in the type's "range", "length", and
> >       "pattern" properties.
> [RW] 
> 
> But RFC 8342 also states:
> 
>    <operational> SHOULD conform to any constraints specified in the data
>    model, but given the principal aim of returning "in use" values, it
>    is possible that constraints MAY be violated under some circumstances
>    (e.g., an abnormal value is "in use", the structure of a list is
>    being modified, or remnant configuration (see Section 5.3.1) still
>    exists).  Note that deviations SHOULD be used when it is known in
>    advance that a device does not fully conform to the <operational>
>    schema.
> 
>    Only semantic constraints MAY be violated.  These are the YANG
>    "when", "must", "mandatory", "unique", "min-elements", and
>    "max-elements" statements; and the uniqueness of key values.
> 
>    Syntactic constraints MUST NOT be violated, including hierarchical
>    organization, identifiers, and type-based constraints.  If a node in
>    <operational> does not meet the syntactic constraints, then it
>    MUST NOT be returned, and some other mechanism should be used to flag
>    the error.
> 
> The first paragraph to me suggests that it is right to return an
> abnormal value.
> 
> E.g., perhaps the IPv6 MTU is only allowed to be configured to values
> greater than 1280, but due to a bug, what actually gets programmed is
> 1000.  Should the device return the "in use" MTU value?  My
> understanding of the NMDA architecture is that it should.

No, you have to read the full text.  The 3rd paragraph makes it clear
that 1000 is not legal in this case.

(You know what Juergen says, you MUST NOT have any bugs :)

> However, the second paragraph doesn't list length, pattern, or range
> as constraints that can be violated, so perhaps it is not allowed.
> But I'm not convinced that is what was originally intended ...

I think it was.


/martin




> 
> Regards,
> Rob
> 
>   
> 
> 
> 
> > 
> > So I am not sure about returning 11 for a range 1..10.
> > 
> > /js
> > 
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod