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

[Andy Bierman <[e-mail]>]

On Fri, Jan 13, 2023 at 8:19 AM Rob Wilton (rwilton) <rwilton=
[e-mail]> wrote:

>
>
> > -----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.
>
>
One possible implementation strategy is to let the operator decide how to
use up
the device memory and just start failing if it runs out.
Here is the YumaPro implementation-specific internal limits:
https://docs.yumaworks.com/en/latest/cli/netconfd-pro.html#max-strlen

IMO this text in RFC 7950 should apply to string values for identifiers:
https://www.rfc-editor.org/rfc/rfc7950#section-6.2

   Implementations MUST support identifiers up to 64 characters in
   length and MAY support longer identifiers.


This does not prevent a YANG module from using a pattern or length-stmt
that is less than 64 bytes.



> Rob
>
> // No hats.
>
>
> >
> > /js
>


Andy


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