Re: [secdir] SECDIR review of draft-mahesh-etsi-urn-03

[Chris Lonvick <[e-mail]>]

Hi Mahesh,

Thanks for setting me straight. The edits you propose look good to me.

Best regards,
Chris

On 7/24/18 4:37 PM, Mahesh Jethanandani wrote:
> Hi Chris,
>
>> On Jul 23, 2018, at 6:02 PM, Chris Lonvick <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Hi,
>>
>> I have reviewed this document as part of the security directorate's 
>> ongoing effort to review all IETF documents being processed by the 
>> IESG. These comments were written primarily for the benefit of the 
>> security area directors. Document editors and WG chairs should treat 
>> these comments just like any other last call comments.
>>
>> The summary of the review is Ready with Issues.
>>
>> I am not that familiar with creating and maintaining URNs so please 
>> set me straight and move on if I'm off base here.
>>
>> Section 2, "URN Specification for ETSI" contains the following:
>>
>> "ETSI will manage resource classes using the "etsi" NID and will be 
>> the authority for managing resources and associated subsequent 
>> strings. ETSI will guarantee the uniqueness of the strings 
>> themselves, or it may permit secondary responsibility for certain 
>> defined resources."
>>
>> But then says:
>>
>> "ETSI may allow for use of experimental type values for testing 
>> purposes only. Note that using experimental types may create 
>> collision as multiple users may use the same values for different 
>> resources and specific strings."
>>
>> It looks like RFC 8141 gives guidance that experimental use of URN 
>> namespaces is to be done using RFC 6963 (URNs for "Examples".) RFC 
>> 8184 does not address establishing or using namespaces under the 
>> subsequent strings for experimental use, but I could see that the 
>> registered owner of the namespace could make a designation for that 
>> purpose. That being said, I think that the two statements above are 
>> in conflict in the document and should be clarified.
>
> Not necessarily.
>
> RFC6963 says that there are three types of namespaces, formal, 
> informal and experimental. What this draft is requesting for is the 
> formal namespace. The RFC also says that experimental namespaces are 
> by definition unregistered. That there is no issuing authority for 
> experimental URNs. The owner of the NID therefore is not required to 
> keep track of experimental namespaces.
>
>>
>> Perhaps it would be better to reconstruct the second paragraph to say 
>> something like:
>>
>> "ETSI may allow for use of experimental type values for testing 
>> purposes only. Some experimentation may be controlled by ETSI within 
>> a subsequent string to ensure that there will be no namespace 
>> collisions among participants. Other experimentation may be 
>> controlled within a secondary namespace that may allow collisions, 
>> but this experimental use will be constrained. All other 
>> experimentation must follow the guidance set forth in RFC 6963.”
>
> How about this?
>
> OLD:
>
> ETSI may allow for use of experimental type values for testing 
> purposes only. Note that using experimental types may create collision 
> as multiple users may use the same values for different resources and 
> specific strings.
>
> NEW:
>
> ETSI may allow for use of experimental type values for testing 
> purposes only. Note that using experimental types may create collision 
> as multiple users may use the same values for different resources and 
> specific strings. All experimentation must follow the guidance set 
> forth in RFC 6963.
>
>>
>> Just as a nit, the Security Considerations section should be revised 
>> as it seems to be a bit unclear.
>> Current:
>>     There are no additional security considerations other than those
>>     described above, and are normally associated with the use and
>>     resolution of URNs in general, which are described in Function
>>     Requirements for URN [RFC1737 <https://tools.ietf.org/html/rfc1737>], Uniform Resource Names (URNs)
>>     [RFC8141 <https://tools.ietf.org/html/rfc8141>].
>>
>> Suggested:
>>     There are no additional security considerations other than those
>>     described above, and_those_  normally associated with the use and
>>     resolution of URNs in general._These a__re generally_  described in Function_al_
>>     Requirements for_Uniform Resource Names_  [RFC1737 <https://tools.ietf.org/html/rfc1737>],_and_  Uniform Resource Names (URNs)
>>     [RFC8141 <https://tools.ietf.org/html/rfc8141>].
> Ok.
> Thanks.
>> Best regards, Chris 
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>