On Fri, Jan 13, 2023 at 10:10 AM Italo Busi <italo.b...@huawei.com> wrote:
> Thanks Andy > > > > I agree with your statement “yang-identifier SHOULD be used instead of > string for key leafs” and that “yang-identifier is always the most > appropriate type to use for a key” > > > > The issue is that there are many YANG models either published as RFC or in > progress which are using string for key leafs. IMHO, it would be better to > change the type from string to yang-identifier at least in the YANG models > which are under development > > > IMO not an issue worth any NBC changes. > I am wondering whether documenting the outcome of this discussion in an > I-D, updating RFC8407, would be useful to provide clear guidelines to IETF > WGs > > > > What do you think? > The appropriate types should be picked during the design process. It should already be clear that 'pattern' and 'length' are available to modify the 'string' type. yang-identifier is too restrictive and 'string' is not restrictive enough. > > > BTW, what about using uri for key leafs (see for example RFC8345)? > > > > I think there are other cases where uri could be an appropriate type to > use for a key … > > > It's just another 'pattern' to check to the YANG compiler. If 'uri' is appropriate then use it. Same goes for 'uuid'. > Thanks, Italo > Andy > > > *From:* Andy Bierman <a...@yumaworks.com> > *Sent:* venerdì 13 gennaio 2023 16:17 > *To:* Italo Busi <italo.b...@huawei.com> > *Cc:* Jürgen Schönwälder <j.schoenwael...@jacobs-university.de>; > netmod@ietf.org > *Subject:* Re: [netmod] Use of unrestricted string in YANG (was RE: > naming scope of a grouping which uses a grouping) > > > > > > > > On Fri, Jan 13, 2023 at 3:32 AM Italo Busi <italo.b...@huawei.com> wrote: > > Andy, Carsten, Jürgen, Tom, > > > > Thanks for your feedbacks > > > > If I understand correctly: > > - Andy, Carsten and Jürgen agree that using unrestricted string for > non-key attributes makes sense > - Andy has a concern only about using unrestricted string for key > attributes and his proposal is to use the yang-identifier (which does not > bound the maximum length of the string) instead > > > > Is my understanding correct? > > > > I would say that yang-identifier SHOULD be used instead of string for key > leafs. > > That does not mean yang-identifier is always the most appropriate type to > use for a key. > > > > I think that what I have understood would make sense > > > > Any other opinion or suggestion? > > > > Thanks, Italo > > > > > > Andy > > > > > > *From:* Andy Bierman <a...@yumaworks.com> > *Sent:* giovedì 12 gennaio 2023 19:24 > *To:* Jürgen Schönwälder <j.schoenwael...@jacobs-university.de>; Andy > Bierman <a...@yumaworks.com>; Italo Busi <italo.b...@huawei.com>; > netmod@ietf.org > *Subject:* Re: [netmod] Use of unrestricted string in YANG (was RE: > naming scope of a grouping which uses a grouping) > > > > > > > > On Thu, Jan 12, 2023 at 8:33 AM Jürgen Schönwälder < > j.schoenwael...@jacobs-university.de> wrote: > > On Thu, Jan 12, 2023 at 07:08:05AM -0800, Andy Bierman wrote: > > > > Just because the escaped string is "safe" inside a NETCONF protocol > message > > does not mean it is safe to use in other tools. Data (especially list > keys) > > gets moved > > between software programs. Unrestricted strings increase the risk of data > > injection attacks. > > > > Sorry, broken code that does not handle inputs of unexpected length > can't be secured by standardizing arbitrary limits. The only option is > to fix the broken code. Code that fails to validate its inputs can't > be fixed by arbitrary limits and the pure hope that the broken code > will never see something causing it to crash. > > > > > > My statement is about the risk of using unconstrained values in strings, > not the length. > > It is my preference to avoid characters in leaf keys that are known to > cause problems > > with shells and other tools. > > > > It is a tradeoff. You can have the freedom to construct all-whitespace key > leafs, > > but at the risk of implementations not handling it correctly. The > designer(s) should pick the most > > appropriate type, based on priorities. > > > > /js > > > > Andy > > > > -- > 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
