Subject: [Gen-art] Gen-ART LC review of draft-ietf-csi-send-cert

From: Roni Even <[email-masked]>
Date: Sun, 2 May 2010 10:50:56 +0300

I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft

 (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-csi-send-cert-03

Reviewer: Roni Even

Review Date: 2010-05-02

IETF LC End Date: 2010-05-14

IESG Telechat date: (if known):

Summary: This draft is roughly ready for publication as a Proposed Standard.

I have some comments and nits:

Comments: 

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 there
are.

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."
3.	In section 7 there are TBA1, TBA2 and TBA3, who will assign values
for these IDs.

Nits:

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.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 3 May 2010 18:56:59 -0400

Hi Roni,
   Thanks for the review. Please see responses inline.

On 10-05-02 03:50 AM, Roni Even wrote:
> intentional it may be good to have a section on changes from RFC 3971 
> and list these specific changes with backward interoperability issues if 
> there are.
> 
>    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

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 
anticipated updates."

> 
>  
> 
> Nits:
> 
>    1. Section 5  has “an end user could local SEND deployment “ it looks

Will fix these.

Thanks
Suresh