Re: [Dime] AD review of draft-ietf-dime-local-keytran-09

[Glen Zorn <[e-mail]>]

On 5/16/2011 9:14 PM, Romascanu, Dan (Dan) wrote:

> 
> 
> Hi, 
> 
> I have reviewed draft-ietf-dime-local-keytran-09. The document is in
> good shape, I have a small number of issues which seem simple to respond
> and fix if necessary, so I suggest that you do it before submitting the
> document to IETF Last Call. 
> 
> Technical Issues are marked T and Editorial issues are marked E. 
> 
> Technical:
> 
> T1: Is there any special reason for skipping decimal value (4) in the
> enumeration in Section 3.1.1? If there is none I suggest to move RSA-KEM
> from (5) to (4). 

OK.

> 
> T2: Are there any special recommendations for the experts who will be in
> charge in the future with the "Expert Review" policy as per [RFC5226]
> for AVP types? 

Do you mean values for the Key-Type AVP?  No such recommendations would
come from me; we had originally specified the policy as "First Come,
First Served"
(http://www.potaroo.net/ietf/all-ids/draft-wu-dime-local-keytran-03.txt)
on the simple theory that anybody who wanted to register, use & deploy
e.g. rot13 would get what they deserved ;-).  IIRC, one of the dime
Chairs suggested the expert review policy, so maybe they have some
suggestions.

...

> T3. In section  5.2: 
> 
>    'once values have been assigned, they MUST NOT be deleted, replaced,
> modified or deprecated.' 
> 
> It is not clear why we do not allow for values to be deprecated.
> Assuming that a cryptographic delivery method was deprecated, why would
> not marking the AVP as deprecated be allowed, as long as the value
> cannot be deleted, replaced or modified? 

Sure, why not.

> 
> Editorial: 
> 
> E1: Why is RSA-KEM not expanded and explained in Section 2.2. -
> Technical Terms and Acronyms?

Would you like the whole thing expanded or just KEM?

...