Hi Jeff, From: yang-doctors <yang-doctors-boun...@ietf.org> on behalf of Jeff Haas <jh...@pfrc.org> Date: Wednesday, October 5, 2022 at 9:53 AM To: Ladislav Lhotka <ladislav.lho...@nic.cz> Cc: tom petch <ie...@btconnect.com>, "netmod@ietf.org" <netmod@ietf.org>, YANG Doctors <yang-doct...@ietf.org> Subject: Re: [yang-doctors] [netmod] Length on keys in YANG
Lada, On Oct 5, 2022, at 7:03 AM, Ladislav Lhotka <ladislav.lho...@nic.cz<mailto:ladislav.lho...@nic.cz>> wrote: 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. IETF doesn't have to formally impose upper limits via language constraint. This is more a matter of establishing reasonable best practices and minimal tooling for such. It may even be a matter of having a few useful typedefs: yang-key32 (length 1..32) yang-key64 (length 1..64) yang-key128 (length 1..128) yang-key256 (length 1..256) I agree in principle. Why wouldn’t these be string32, etc, since the leaves in question are of type string. We don’t need “yang-“ since they will be prefixed with “yang-types:” or some other module. Thanks, Acee The usual quote I cite for these sort of things is, "constants are usually wrong". We ran into this in various VPN MIBs and that caused my implementation interesting grief when the key, a vrf name, was artificially constrained to be shorter than what our implementation permitted. In MIBs, you were stuck. In YANG, when necessary, you could deviate. However, in picking some possibly "reasonable" length, we at least call out to module reviewers that: - The key should be of limited size. - Pay attention... is this long enough? -- Jeff
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
