On Wed, Oct 5, 2022 at 4:03 AM Ladislav Lhotka <ladislav.lhotka= 40nic...@dmarc.ietf.org> wrote:
> > > Dne 05. 10. 22 v 12:01 tom petch napsal(a): > > From: netmod <netmod-boun...@ietf.org> on behalf of Jeffrey Haas < > jh...@pfrc.org> > > Sent: 03 October 2022 20:41 > > > > [I had promised Mahesh that I'd take my comments here, but I realize > that this > > is a topic that likely will result in no short term solutions. It may > also > > result in no action whatsoever.] > > > > YANG strings are bounded in length, theoretically, but that length limit > > isn't small. > > > > When strings are used solely as leaf values, the length limit largely > isn't > > a matter of concern, in my opinion. However, when they're used as keys, > it > > introduces some code practicalities that may be worth discussing. > > > > One item of practicality is simply the length and its impact on > underlying > > data structures. If you were storing such things in something like a > > PATRICIA tree, many implementations behave better when the key is of a > > bounded length.* > > > > A secondary consideration is that since unicode is used, character > lengths > > in terms of storage may vary. Implementations that internally store > strings > > as UTF-8 have to be wary of truncation considerations. > > > > A tertiary consideration is that in mechanisms like gNMI, long keys end > up > > bloating PDUs. > > > > Loosely framing this as a very old English joke: YANG Doctor, it hurts > when > > I do this! YANG Doctor: Well... don't do that! > > > > For many things that have naturally short string names (e.g. interface > > names), this mostly isn't an issue. However, for things that may take > > user-supplied strings as their key in configuration, this is somewhat > more > > problematic.* > > > > Most implementations likely don't take unbounded inputs to the maximum > > length of a YANG string for such things. Technically in such situations, > > they're non-conformant if that's the case, or if they don't provide a > > deviation specifying the length of the string. > > > > Why raise this? While I only coincidentally participate in YANG module > > implementation at the moment, I remember similar headaches in MIBs making > > the lives of implementors problematic. > > > > What should be done, if anything? It seems like those with deeper > expertise > > may want to recommend a reasonable length limit for strings that will be > > used as keys. Perhaps define a specific typedef for such things. And, > once > > defined, the YANG doctors might consider recommending them in their > reviews. > > > > Such things may already be good practice, but perhaps I'm not aware of > it. > > > > <tp> > > I am forever pointing out to authors of modules just how big a string > can be and the usual reaction is that they do not care. Occasionally the > response is to ask what it should be. Dunno, that is your decision. > > > > I seem to recall carrying across the SMI type with a restricted length > into YANG but was unable to convince others. > > I would still be against setting a hard limit in YANG itself, primarily > because it is not clear what this general limit should be. Module > authors might of course consider restricting key length to something > that is appropriate for a particular key leaf. > > Nobody is suggesting any changes to YANG. Just the addition of more typedefs in a YANG module. BBF has its own basic types: https://github.com/BroadbandForum/yang/blob/master/standard/common/bbf-yang-types.yang OpenConfig has its own clone: https://github.com/openconfig/public/blob/master/release/models/types/openconfig-yang-types.yang The operational POV is not "do whatever you want". It is "pick something useful and implement it". The length "64" is not random. https://www.rfc-editor.org/rfc/rfc7950.html#section-6.2 > Lada > Andy > > > > > Tom Petch > > > > -- Jeff > > > > * As a matter of fact, it was performing a code review against exactly > this > > point that raised this consideration. > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > yang-doctors mailing list > > yang-doct...@ietf.org > > https://www.ietf.org/mailman/listinfo/yang-doctors > > -- > Ladislav Lhotka, CZ.NIC > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > 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
