Re: [apps-discuss] apps-team review of draft-ietf-sidr-rescerts-provisioning-09

[Geoff Huston <[e-mail]>]

We have submitted a new version of this document. It addresses most of the issues raised in the review. A point-by-point response to the review is  as follows:

---------------------------------------------------------------------------
** 
Thank you for this detailed review. We appreciate the care and 
attention to detail that has gone into this review.

We will respond to the review pint a point-by-point basis,
marked by ** delimiters in the test.

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team)
Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-sidr-rescerts-provisioning-09
Title: A Protocol for Provisioning Resource Certificates
Reviewer: Carsten Bormann
Review Date: 2011-04-09

SUMMARY:

This document is ready for publication after a number of relatively
simple changes have been performed.  A slightly larger set of
potentially desirable improvements have also been identified.

PURPOSE:

The draft describes a protocol for provisioning resource certificates.
A resource in this context is an Internet Number Resource (INR), i.e.,
IP Address or Autonomous System (AS) Number.
The protocol is used between a client "Subject" (such as an ISP) and a
server "Issuer" (such as a registry, acting as a CA).

The protocol will thus be used between in a very specialized setting
between members of two closely-knit communities; there is little
danger of properties of this protocol spilling over into mainstream
application protocols.

REVIEW:

Several properties of this protocol represent current practice, but
not necessarily best practice, in application protocol design.
The message transport used is an HTTP POST request, which is used as a
request-response vehicle for carrying around CMS objects which in turn
carry XML-encoded messages that are the subject of this protocol.
Given the specialized status of this protocol, this may be acceptable.

Major Issues:

1.  The media type used for requests and responses cannot be
registered under the name 'application/x-rpki' (section 4.2 of RFC
4288).  Unless significant deployment makes this prohibitive, a
permanent name SHOULD be chosen and the media type be registered
according to RFC 4288 (BCP 13).

**
Accepted

The document now includes an IANA Considerations section that includes a
completed registration template for application/rpki-updown

This template is to be forwarded to the ietf-types folks for their 
review.
**

2.  There is an explicit mandate for serializing the processing of all
requests between one server/client pair, without it being fully clear
what exactly constitutes that pair (i.e., when are two requests from
the *same* client)?  Similarly, it is not quite clear how to "Check
that the XML sender and recipient attributes reference a known client
and this server's system respectively" (the underlying data type is an
xsd:token).

**
Accepted.

The text now clarifies what a "client" is in this context.
**

Details:

3.  There is no such thing as a "HTTP 400 Bad Data" response to an
HTTP POST.  Status code 400 stands for "Bad Request".

**
Accepted

Edit applied
**

4.  It may be worthwhile to mention the use of the Retry-After: HTTP
header with a 503 status.

**
Accepted

Edit applied
**

5.  My ASN.1 is a bit rusty, but the content of 3.1.1.3.2 looks
strange to me and is rejected by asn1c.  Has this been validated?
Same comment for Appendix A.  Remove duplicate definition of
ContentType as well.

**
Accepted

reviewer is correct, this asn.1 is confused.  this particular line is
setting the identifier id-ct-xml to be an alias for the built-in type
name OCTET STRING, which is wrong.  the other definition for id-ct-xml
is correct (the "ct" stands for "content type" and is a hint that this
is supposed to be an object identifier).

the definition in section 3.1.1.3.2 and the second definition of
id-ct-xml in the appendix should be replaced by something like:

RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message

ie, make up a sort-of-human-meaningful identifier that follows the
ASN.1 conventions for type names and just set it to the right type,
which is indeed OCTET STRING.  yes it looks a little odd to have this
sitting all by itself in the definitions with nothing referencing it,
but that appears to be the way cms eContentType is done, see, eg, the
definitions in the roa-format and manifest drafts.

Edit applied
**

6.  re 3.2 Common Message format: The reader's mind should be put at
ease here by quickly pointing to the Relax-NG spec in Annex B.  It
should be clarified that the text in 3.2 is specifying the message
format by way of examples, and that the actual (also normative) format
is specified in Appendix B.

**
Accepted

Edit applied
**

7.  re 3.2 Common Message format: please remove the spaces around the
'=' in 'recipient = "recipient name"' to minimize confusion.

**
Accepted

Edit applied
**

8.  The use of a comma-separated list of URIs (which in turn requires
escaping commas in the URIs themselves) in the attribute "cert_url" in
the context of a class or certificate element is suboptimal.  Allowing
one or more cert_url elements nested in the class element would be
more natural XML.

**
While it may be "more natural" for this reviewer, this is a matter 
of style, and in this case the running code uses the format described
here. The text will remain consistent to the running code.
**

9.  It is unclear why a new convention for the representation for IPv6
addresses needs to be invented. One should simply make use of RFC
5952.  The example given in the text for resource_set_ipv6 does not
conform to either RFC 5952 (it uses upper case, as seems to be
recommended by the somewhat opaque reference to
http://www.w3.org/TR/xmlschema-2/#hexBinary and its canonical form)
nor the new convention (it uses leading zeros).  (The reference to RFC
3779 seems to point to section 2.2.3.6 in that RFC?)

**
Accepted

Edit applied
**

10.  re 3.4: I have trouble understanding:

If any of the req_resource_set attributes are specified in the
request, then any missing req_resource_set attributes are to be
interpreted as specifying the complete set of the corresponding
resource type that match the client's current resource allocation.
If the value of any req_resource_set attributes is the null value
(""), then this indicates that no resources of that resource type are
to be certified with this request.

What is the semantics if none of the req_resource_set attributes are
specified?

**
Accepted

Edits to clarify the text have been made
**


11.  What are the circumstances under which the following SHOULD is
not required, and what can the client rely on to happen in this case?

o  If the resource class is not defined by the server, then the
   server SHOULD return error code 1201.

**
SHOULD has been replaced with MUST
**

12.  (The reviewer got curious why ski is using base64url and all
other binary data are encoded in base64.)

**
because they are used differently.  existing implementations use ski
in filenames, but plain base64 is easier to work with for general use
because it's more widely supported by existing tools.
**


13.  What is the point of limiting the error_response status code to
one quadrillion minus one?  The set of status codes ever standardized
is likely to be smaller, not requiring a 50 bit number.  Right now,
they are all four-digit numbers, which might be a hint to a more
reasonable upper limit.

**
No known point - the texty has been edited to drop the limit
**

14.  There is no way in the schema to include a second description
element, as is require in the description of "description" in 3.6.


**
Accepted

Schema edited to allow >1 description elements
**

15.  The schema allows zero-length certificates throughout -- this
will be caught at the semantic level, but it is probably worthwhile
spending a couple of minLength constraints on the xsd:base64Binary.
Similar comment for the xsd:token in class_name.

**
Accepted

MinLength values added to the schema
**

16.  (There are some indentation idiosyncrasies in the schema, e.g. in
issue_request and in revocation.  The schema might also be improved by
factoring out some common types such as

              xsd:base64Binary { maxLength="512000" }
              xsd:token { maxLength="1024" }

as was done e.g. in draft-ietf-sidr-publication.)

**
Accepted

Schema edited
**


------------------------------------------------------------------------

Geoff

On 12/04/2011, at 11:29 AM, Sandra Murphy wrote:

> Gentlepersons,
> 
> I received the following message indicating that the Apps Review team had reviewed the rescerts-provisioning draft.  The URL points to the review in the apps-discuss mailing list.  It is not clear from the archive that the authors were recipients on the message, even though the tone of the message seems to directed toward the authors.
> 
> The review is long and detailed.  I would appreciate your attention to the review as soon as possible so I can give some reply to the apps-discuss mailing list.
> 
> --Sandy
> 
> 
> ---------- Forwarded message ----------
> Date: Mon, 11 Apr 2011 17:05:01 -0700
> From: SM <[e-mail]>
> To: Sandra Murphy <[e-mail]>
> Cc: Carsten Bormann <[e-mail]>, Chris Morrow <[e-mail]>,
>  Alexey Melnikov <[e-mail]>
> Subject: Re: [apps-discuss] apps-team review of
>  draft-ietf-sidr-rescerts-provisioning-09
> 
> Hi Sandra,
> At 13:30 09-04-2011, Carsten Bormann wrote:
>> I have been selected as the Applications Area Review Team reviewer for
>> this draft (for background on apps-review, please see
>> http://www.apps.ietf.org/content/applications-area-review-team)
>> Please resolve these comments along with any other Last Call comments
>> you may receive. Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>> Document: draft-ietf-sidr-rescerts-provisioning-09
>> Title: A Protocol for Provisioning Resource Certificates
>> Reviewer: Carsten Bormann
>> Review Date: 2011-04-09
> 
> Carsten posted a review of draft-ietf-sidr-rescerts-provisioning-09 at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02448.html I suggest that you follow up on the Apps-discuss mailing list.
> 
> Regards,
> S. Moonesamy