Subject: Re: [alto] Secdir last call review of draft-ietf-alto-unified-props-new-18

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 19 Oct 2021 16:36:58 +0000

Hello Paul,

Thanks a lot for your review. A new version is under edition to address your comments. 
Please see inline how we plan to address them. Can you let us know whether the proposed updates meet your expectations? 
Best regards,
Sabine and co-authors

>-----Original Message-----
>From: Paul Wouters via Datatracker <[email-masked]>
>Sent: Wednesday, September 15, 2021 11:37 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; last-
>[email-masked]
>Subject: Secdir last call review of draft-ietf-alto-unified-props-new-18
>
>Reviewer: Paul Wouters
>Review result: Has Nits
>
>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 Has Nits
>
>This document extends RFC 7285 (the ALTO protocol) with some new
>registries and values. As such, there is no real change to the protocol, only to
>the possible information conveyed via the ALTO protocol. Therefor it is
>appropriate to refer to RFC 7285 for the Security Considerations, as is done in
>this document.
[ [SR] ] 
[ [SR] ] Do you mean we should keep the security section of this document as it is or should we shorten it?
>
>While extensions to a protocol don't necessitate an Updates: clause, in this
>case I think it should because the document addresses shortcomings in the
>original protocol. That is, new implementations are expected to really require
>implementing this new document as part of the "core specification". Thus
>implementers reading 7285 should really be warned to also read (and
>implement) this document.

[ [SR] ] we do not oppose entities against endpoints therefore this extension does not intend to replace endpoints by entities. Both are useful, as some use cases can live with the base protocol. A discussion thread has just started on this point and we will like to have your conclusions on the exposed points of view
>
>The IANA considerations are quite verbose. Usually, this section only contains
>the minimal information for an IANA operator to read to implement the
>requested changes. In this case there is lots of text on justifying things that
>are better omitted or written out in another section.
[ [SR] ] 
[ [SR] ] We have identified some paragraphs and text that are more considerations than specifications:
---------- 12.2.2.  ALTO Entity Domain Type Registration Process
----- para 3 item 5 "Media type of defining information resource:" removed redundant text. 
----- para 3 item 6 "Knowing the media type..." removed

----------- 12.3.  ALTO Entity Property Type Registry
----- para 4: removed last sentence
----- para 4 - item 2 removed last sentence

>
>The new IANA registries do not all seem to allow for private use registrations?
>This means technically any new value cannot be tested unless by violating the
>RFC. At least, that is my reading but I'm a little confused by it.
[ [SR] ] 
[ [SR] ] we agree, all new IANA registries should allow for private registrations. 
While this has been done for entoty property types in section 5.2.1, we will  add private use for Entity Domain Types, and plan to update the document accordingly as follows.

---------- Section 5.1.1.  Entity Domain Type -  paragraph 4, 
borrowing from RFC 7285.  

OLD
   ..... Each entity domain type
   MUST be registered with the IANA, following the procedure specified
   in Section 12.2.2 of this document..... 

NEW
.....  Entity domain type identifiers prefixed with "priv:" are reserved for Private Use
[RFC5226] without a need to register with IANA.

All other entity domain types appearing in an HTTP request or
response with an "application/alto-*" media type 
 MUST be registered with the IANA, following the procedure 
specified  in Section 12.2.2 of this document.

 For an endpoint domain type identifier with the "priv:" prefix, an additional
string (e.g., company identifier or random string) MUST follow (i.e.,
"priv:" only is not a valid entity domain type identifier) to reduce potential collisions.  
A Private Use entity domain type identifier and its associated internal specification MUST apply to all property maps  of an IRD. 
.....

---------- Section 5.1.2.  Entity Domain Name
The 3rd paragraph will be modified as follows:

OLD
   Each entity domain is identified by a unique entity domain name which
   is a string of the following format:

       EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType

   Where the presence and construction of component:

       "[ [ ResourceID ] '.' ]"

   depends on the category of entity domain.

NEW
   Each entity domain is identified by a unique entity domain name which
   is a string of the following format:

       EntityDomainName ::= [ [ ResourceID ] '.' ] [ "priv:" ] EntityDomainType

   Where 

*  the presence and construction of component:

       "[ [ ResourceID ] '.' ]"

   depends on the category of entity domain.

* the component [ "priv:" ] is present when the entity domain type is defined for Private Use.

---------- Section 12.2 ALTO Entity Domain Type Registry

--- After paragraph 2, we will add a 1-sentence paragraph: "As specified in Section 5.1.1, identifiers prefixed with "priv:" are
reserved for Private Use without a need to register with IANA."

--- Table 2 will have an additional line
Identifier -> priv:
Intended Semantics -> Private use

---------- 5.2.1.  Entity Property Type - paragraph 3
add sentence in the end:
"A Private Use entity domain type identifier and its associated internal specification MUST apply to all property maps  of an IRD. "

---------- 5.2.2.  Entity Property Name
OLD
EntityPropertyName ::= [ ResourceID ] '.' EntityPropertyType

NEW
EntityPropertyName ::= [ ResourceID ] '.'  [ "priv:" ] EntityPropertyType

---------- Section 12.3.  ALTO Entity Property Type Registry
--- After paragraph 1, we will add a 1-sentence paragraph: "As specified in Section 5.2.1, identifiers prefixed with "priv:" are
reserved for Private Use without a need to register with IANA."

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Wed, 20 Oct 2021 09:37:51 +0000

Hello Paul, 
Thanks a lot for your feedback. You will see the updates in version 19
Best regards,
Sabine

>From: Paul Wouters <[email-masked]>
>Sent: Tuesday, October 19, 2021 8:48 PM
>To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
><[email-masked]>
>Cc: [email-masked]; [email-masked];
>[email-masked]; [email-masked]
>Subject: Re: [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-
>new-18
>
>On Tue, 19 Oct 2021, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:
>
>> Please see inline how we plan to address them. Can you let us know
>whether the proposed updates meet your expectations?
>
>That looks good, thanks!
>
>>> appropriate to refer to RFC 7285 for the Security Considerations, as
>>> is done in this document.
>> [ [SR] ]
>I meant it is good as is.
>
>>> While extensions to a protocol don't necessitate an Updates: clause,
>>> in this case I think it should because the document addresses
>>> shortcomings in the original protocol. That is, new implementations
>>> are expected to really require implementing this new document as part
>>> of the "core specification". Thus implementers reading 7285 should
>>> really be warned to also read (and
>> [ [SR] ] we do not oppose entities against endpoints therefore this
>> extension does not intend to replace endpoints by entities. Both are
>> useful, as some use cases can live with the base protocol. A
>> discussion thread has just started on this point and we will like to
>> have your conclusions on the exposed points of view
>
>An RFC update does not mean "do not implement what was in the older one".
>Update really means that one should read (and ideally implement) both
>documents to get the updated picture of what the IETF believes should be
>implemented. If this is just an optional extension, then Update: is not needed.
>But if it modifies the previous document to clarify or extend in a way that is
>core to the protocol, it should probably Update: the previous RFC so
>implementers know there is more to take into account than just that core
>older document.
>
>Thanks. I think it will look better. Generally, think of this Section as something
>only the IANA operator will read to actually perform the registry updates and
>that any other reader will skip the section entirely.
>
>Paul