Paul Wouters <[email protected]> writes: > On Tue, 8 Oct 2019, Ladislav Lhotka wrote: > >>> Speaking for myself, as long as we are not populating RFCs with >>> obsoleted DNS data or just create RFC with copies of IANA registries, >>> I'm fine with helping on a document. But not if it is a blind copy >>> and paste from IANA (whether at DNSOP or OPSAWG) >> >> I still have difficulties to understand this objection. IANA registries >> (presumably) serve some purpose, and the only way for using them in YANG >> data models currently is to translate them to YANG. > > What I meant was something like this: > > https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-07https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 > > > > typedef encryption-algorithm-type { > type uint16; > description > "The encryption algorithm is specified with a 16-bit > number extracted from IANA Registry. The acceptable > values MUST follow the requirement levels for > encryption algorithms for ESP and IKEv2."; > reference > "IANA Registry- Transform Type 1 - Encryption > Algorithm Transform IDs. RFC 8221 - Cryptographic > Algorithm Implementation Requirements and Usage > Guidance for Encapsulating Security Payload (ESP) > and Authentication Header (AH) and RFC 8247 - > Algorithm Implementation Requirements and Usage > Guidance for the Internet Key Exchange Protocol > Version 2 (IKEv2)."; > } > > > Wouldn't this define what you need, without hardcoding all the valid > values from the snapshot of the IANA registry? > > This would instruct the implementor to go to the IANA registry, notice > there what is obsoleted/deprecated, and they will know they will have > to check IANA when doing a release update. > > Am I misunderstanding something?
This may be acceptable for humans but tools cannot do much with it. One benefit of an explicit enumeration is that tools can generate sensible code from it, e.g. to provide the user with the list of available choices. Lada > > Paul -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
