Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

["Rob Wilton (rwilton)" <[e-mail]>]

> -----Original Message-----
> From: netmod <[e-mail]> On Behalf Of Jürgen Schönwälder
> Sent: 12 January 2023 15:46
> To: Italo Busi <Italo.Busi=[e-mail]>
> Cc: [e-mail]
> Subject: Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope
> of a grouping which uses a grouping)
> 
> My take is that arbitrary limites are worse than no limits.
> Robust implementations will reject values that go beyond certain
> implementation and platform specific limits.
> 
> If anything makes sense to standardize, then it is the minimum lengths
> that must be supported, for which we do not really have formal syntax.
[Rob Wilton (rwilton)] 

+1.

It is quite likely that implementations will choose some reasonable limit for most of these unlimited strings, so it isn't really that they are unlimited, but the limit is set by the implementation rather than at the generic API.  Of course, even with YANG, an implementation could deviate all of these unlimited length string leaves to indicate what the actual limit is. Whether this would be genuinely helpful or end up just being noise by hiding "real deviations" in a sea of noise is unclear to me.

And I agree with Juergen, that from an interop perspective, knowing the minimum length that all implementations are expected to support may do more to improve interoperability.  E.g., knowing that all server implementations are expected to support interface descriptions of 256 bytes may be more helpful than knowing that some implementations limit them to 1 Mb.

Rob

// No hats.


> 
> /js
> 
> On Thu, Jan 12, 2023 at 12:38:13PM +0000, Italo Busi wrote:
> > I have seen the comment from Tom about the unrestricted string in YANG on
> other drafts in WG LC or WG adoption poll and I would like to understand what
> is the position of the Netmod WG on this issue
> >
> >
> > Using unrestricted string is quite common practice in existing IETF standard
> YANG models, also as in key attributes (e.g., see RFC8343). However, the
> comments looks valid and it is worthwhile investigating it further
> > From the previous discussion I have understood that Martin does not think
> this is an issue while Andy agrees with Tom …
> >
> > I have a mixed feeling about the resolution but I think this is something to be
> documented either in RFC7950 (update) or in RFC8407 (update)
> >
> > For integers, RFC7950 defines different built-in types for 8-bit, 16-bit and 64-
> bit integers, while for string there is only one type and the length sub-
> statement is optional
> >
> > While it is true that unrestricted strings can cause an implementation to run
> out of memory, it is also true that in some cases it is not trivial to define the
> maximum length for a string attribute
> >
> > Moreover, I am not sure whether restricting the strings would solve the out of
> memory: what happens if a huge YANG list is configured?
> >
> > What is your view/opinion about using the string type in IETF standard YANG
> models?
> >
> > Thanks, Italo
> >
> > From: Andy Bierman <[e-mail]>
> > Sent: mercoledì 21 dicembre 2022 00:30
> > To: Martin Björklund <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [netmod] naming scope of a grouping which uses a grouping
> >
> >
> >
> > On Mon, Dec 19, 2022 at 5:15 AM Martin Björklund
> <[e-mail]<mailto:[e-mail]>> wrote:
> > tom petch <[e-mail]<mailto:[e-mail]>> wrote:
> > > From: Martin Björklund <[e-mail]<mailto:[e-mail]>>
> > > Sent: 19 December 2022 12:18
> > > To: tom petch
> > >
> > > tom petch <[e-mail]<mailto:[e-mail]>> wrote:
> > > > draft-ietf-opsawg-sap-12
> > > > defines a grouping sap-list which uses grouping sap-entry.  The groupings
> are intended for import by service specific modules.  The uses does not include
> a prefix; should it?
> > >
> > > From a YANG perspective this is correct.  Since it references a
> > > grouping in the local module, the prefix is optional.
> > >
> > > <tp>
> > > But it will not be the local module when it is used in other modules which is
> the only reason it is a grou[ing
> >
> > It doesn't matter how sap-list is used; it is well-defined in the
> > module ietf-sap-ntw.  See section 5.4 in RFC 7950.
> >
> >
> > /martin
> >
> >
> > >
> > > module ietf-sap-vpn
> > >  prefix sap-vpn
> > > import ietf-sap-ntw
> > >  prefix sap
> > > container sap-l2vpn
> > >
> > > list l2vpn-service
> > >  uses sap:sap-list
> > > .....
> > >
> > > Does it need to know where to find sap-entry which sap-list 'uses' without a
> prefix?
> > >
> > > Tom Petch
> > >
> > > > The module also has my favourite YANG construct, an unrestricted string
> as a YANG key.
> > >
> > > I don't think that this is a problem.  Or rather, if the theory is
> > > that we need to have restricted length on strings b/c otherwise an
> > > implementation may run out memory, then I don't think this solves that
> > > problem.  But perhaps there is some other reason?
> > >
> >
> > There is an argument to be made that it is better to pick a reasonable length
> > and a reasonable character set for an administrative string (going back to
> SnmpAdminString)
> > That way, every implementation MUST support the same set of strings
> (modulo resource errors).
> >
> > I have the same reaction as Tom when I see 'string' as a key.
> > Really? The server accepts zero-length identifiers, all-whitespace identifiers,
> and much worse...
> > Probably not.
> >
> >
> > >
> > > /martin
> >
> >
> > Andy
> >
> > >
> > > >
> > > > Copying Martin as he performed a YANG Doctor review earlier in 2022.
> > > >
> > > > Tom Petch
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> --
> Jürgen Schönwälder              Constructor 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