Subject: Re: [mile] [IANA #985228] expert review for draft-ietf-mile-rolie (well-known-uris)

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Fri, 27 Oct 2017 18:30:53 +0000

This was caught by the MILE filter for having too many recipients. I'm forwarding it directly to MILE get it through. Apologies if this appears twice in the list.

Stephen Banghart

-----Original Message-----
From: Banghart, Stephen A. (Fed) 
Sent: Friday, October 27, 2017 2:14 PM
To: [email-masked]' <[email-masked]>
Cc: [email-masked]; Waltermire, David A. (Fed) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; 'Ben Campbell' <[email-masked]>; 'Adam Roach' <[email-masked]>
Subject: RE: [IANA #985228] expert review for draft-ietf-mile-rolie (well-known-uris)

Sabrina,

We have made several changes to the IANA section to address both your comments and IESG comments. I've listed them here:

We've changed the /.well-known registration from "rolie/servicedocument to "rolie" in order to conform to RFC5785 registration requirements.

We've removed the /.well-known registration for "rolie/categorydocument" following IESG review.

We've updated text in the ROLIE URN Parameters Section. The first paragraph received clarifying textual changes following IESG review. The second paragraph (regarding Designated Experts) has been changed to the following: 

"Registration in the ROLIE URN Parameters registry is via the
          Specification Required policy <xref target="RFC8126"/>.
          Registration requests must be sent to both the MILE WG mailing
          list ([email-masked]) and IANA. IANA will forward registration
          requests to the Designated Expert."

With regards to the /.well-known registration for "rolie", we believe that the registration does provide site-wide metadata and URI links to additional metadata. The Service Document that is retrieved from the .well-known location allows consumers to retrieve the top-level ROLIE metadata for the site, and provides the head for linking into the rest of the ROLIE repository.

ROLIE is intended to be used by automated systems, for these systems, locating a URL can be particularly difficult. This registration provides a consistent and standard way for automated systems to locate ROLIE repositories given a hostname and port.

The DNS SRV records are a potential solution for fully automated discovery, we've added text to the draft clarifying that we will standardize this feature in the future. We've also added text that covers the justifications for the .well-known registration.

I hope this clears up your comments/concerns.

Thanks,
Stephen Banghart

> -----Original Message-----
> From: Sabrina Tanamal via RT [mailto:[email-masked]]
> Sent: Monday, October 16, 2017 3:42 PM
> Cc: [email-masked]; Banghart, Stephen A. (Fed) 
> <[email-masked]>; Waltermire, David A. (Fed) 
> <[email-masked]>; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: [IANA #985228] expert review for draft-ietf-mile-rolie 
> (well-known-
> uris)
> 
> Dear Authors/Chairs/ADs:
> 
> Please see the comments from the designated expert below.
> 
> Thank you,
> 
> Sabrina Tanamal
> IANA Services Specialist
> 
> ---
> 
> This draft proposes registration of a well-known URI, 
> "rolie/servicedocument".
> 
> That syntax does not conform to the requirements of RFC5785, Section 3:
> 
> """
> Registered names MUST conform to the segment-nz production in[RFC3986].
> """
> 
> I'd suggest registering just "rolie" and specifying that "/servicedocument"
> under it is used for this purpose, and that other paths under "rolie" 
> can be reserved using other standards-track documents.
> 
> However, it is not clear why such a well-known URI is needed. RFC5785
> states:
> 
> """
> [W]ell-known URIs are not intended for general information retrieval 
> or establishment of large URI namespaces on the Web. Rather, they are 
> designed to facilitate discovery of information on a site when it 
> isn't practical to use other mechanisms; for example, when discovering 
> policy that needs to be evaluated before a resource is accessed, or 
> when using multiple round- trips is judged detrimental to performance.
> 
> As such, the well-known URI space was created with the expectation 
> that it will be used to make site-wide policy information and other 
> metadata available directly (if sufficiently concise), or provide 
> references to other URIs that provide such metadata.
> """
> 
> This draft doesn't explain why using a URL to locate a service 
> document isn't sufficient; in other words, why is it necessary to 
> reserve name space on every Web server existent for this function?
> 
> The draft does mention:
> 
> """
> A mechanism to determine which host and port to use is not specified 
> in this document. Use of a mechanism such as DNS SRV Records [RFC2782] 
> can provide a secure and reliable discovery mechanism for determining 
> a specific host and port to use for retrieving a Service Document for 
> a given DNS domain.
> """
> 
> ... but it does not specify how to use DNS SRV to achieve this goal, 
> leading me to believe that this is underspecified and not a strong 
> motivation for the well- known URI.
> 
> Is there some context about this proposed use that I've overlooked?
> ---8<---