On Fri, Jan 13, 2023 at 8:19 AM Rob Wilton (rwilton) <rwilton= 40cisco....@dmarc.ietf.org> wrote:
> > > > -----Original Message----- > > From: netmod <netmod-boun...@ietf.org> On Behalf Of Jürgen Schönwälder > > Sent: 12 January 2023 15:46 > > To: Italo Busi <Italo.Busi=40huawei....@dmarc.ietf.org> > > Cc: netmod@ietf.org > > 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 <a...@yumaworks.com> > > > Sent: mercoledì 21 dicembre 2022 00:30 > > > To: Martin Björklund <mbj+i...@4668.se> > > > Cc: ie...@btconnect.com; netmod@ietf.org > > > Subject: Re: [netmod] naming scope of a grouping which uses a grouping > > > > > > > > > > > > On Mon, Dec 19, 2022 at 5:15 AM Martin Björklund > > <mbj+i...@4668.se<mailto:mbj%2bi...@4668.se>> wrote: > > > tom petch <ie...@btconnect.com<mailto:ie...@btconnect.com>> wrote: > > > > From: Martin Björklund <mbj+i...@4668.se<mailto:mbj%2bi...@4668.se>> > > > > Sent: 19 December 2022 12:18 > > > > To: tom petch > > > > > > > > tom petch <ie...@btconnect.com<mailto:ie...@btconnect.com>> 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 > > > netmod@ietf.org<mailto:netmod@ietf.org> > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > Jürgen Schönwälder Constructor 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 > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
