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 <noreply@xxxxxxxx>
>Sent: Wednesday, September 15, 2021 11:37 PM
>To: secdir@xxxxxxxx
>Cc: alto@xxxxxxxx; draft-ietf-alto-unified-props-new.all@xxxxxxxx; last-
>call@xxxxxxxx
>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."
>
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
