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?
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
