Thanks for the review. Please see responses inline.
On 10-05-02 03:50 AM, Roni Even wrote:
The first two comments are about changes from RFC 3971, if they are
intentional it may be good to have a section on changes from RFC 3971
and list these specific changes with backward interoperability issues if
1. In section 4 second paragraph “SEND certificates MUST include the
IP Resources extension for IPv6 Address …” Section 6.3.1 of RFC
3971 says “Router Authorization Certificates are X.509v3
certificates, as defined in RFC 3280, and SHOULD contain at least
one instance of the X.509 extension for IP addresses, as defined
in RFC 3779.” So why is it a MUST here.
2. The same paragraph has “Certified IPv6 address space SHOULD be
expressed using either addressPrefix or addressesOrRange
elements.” . Section 6.3.1 in RFC 3971 says “The X.509 IP address
extension MUST contain at least one addressesOrRanges element” as
for the addressPrefix according to this section “The X.509 IP
address extension MAY contain additional IPv6 subnet prefixes,
expressed as either an addressPrefix or an addressRange.”
We are basing ourselves on the work done at the sidr working group
regarding resource certificates. The MUSTs and SHOULDs are derived from
draft-ietf-sidr-res-certs rather than RFC3971. I will come up with a
proposal on how to resolve this discrepancy.
3. In section 7 there are TBA1, TBA2 and TBA3, who will assign values
for these IDs.
The EKUs are assigned by the pkix working group. I will be adding the
following text to the IANA considerations section.
"The EKUs are registered in an arc delegated by IANA to the PKIX Working
Group. No further action by IANA is necessary for this document or any
1. Section 5 has “an end user could local SEND deployment “ it looks
like there is a missing word in this sentence
2. In section 5 expand ULA.
Will fix these.
Ietf mailing list