Re: [core] Review of draft-ietf-core-protocol-negotiation-07

[Bill Silverajan <[e-mail]>]

Hi Christian,

I'll respond inline to your comments:


Christian Amsüss wrote:
> Hello protocol-negotiation authors,
> hello CoRE group,
>
> I'd like to offer a review and some suggestions to the document
> draft-ietf-core-protocol-negotiation-07. My interest in the document is
> both as a potential implementor, and as co-author of resource-directory,
> which will in part be judged by whether it easily allows extensions as
> suggested in protocol-negotiation.
>
> * Introduction: It would be helpful to have RFC8323 and
>    draft-becker-core-coap-sms-gprs-06 referenced to understand how
>    different transports use CoAP URIs.
>    * Another document that describes a CoAP scheme is
>      draft-bormann-t2trg-slipmux-02 ("Hey coap+uart://ttyUSB0/, do you
>      happen to be available over the network too, just in case you get
>      unplugged?").
The intro has now been changed and a reference to [1] added, which lists 
all the alternative transports being used or being considered for use.
>
> * coap+ws:// does not work like the example with
>    coap+ws://example.org/ws-endpoint/sensors/temperature suggests any
>    more. A more suitable example might be an HTTP proxy URI
>    ('http://proxy.example.org/coap+tcp://eample.org/sensors/temperature').
This is true. One of the original intent of protocol negotiation is to 
overcome URI aliasing and locater/identifier problems. We did not have a 
standard way to terminate the ws endpoint but that has been recently 
solved by RFC 8307 which then paved the way for RFC 8323.

However, I'm not confident of addressing the usage of HTTP proxying as a 
viable use case for multiple transports so it's better to omit the 
WebSocket example in this section.
>
> * The example exchange in "Overcoming Middlebox Issues" confuses me: Why
>    would a client that has already established communication with a
>    server utilize an external service to discover more addresses? With
>    the current draft, this calls for the Alternative-Transport option.
Thanks, this was a legacy example that we overlooked. It has now been 
changed to omit the RD, and a new example added to illustrate how an RD 
can be used to discover non-IP transport endpoints.
>
> * New Resource Directory Parameters:
>
>    * Why is `at` comma separated rather than a repeated parameter? The
>      former indicates limitations on the available characters (at least
>      the comma; is there any other syntax planned a la `;q=0.5`?), and
>      the latter would IMHO be more straight forward to implement.
It was a historic design decision to allow using 'at' as a non-repeating 
parameter in previous versions of the RD, to keep it consistent with the 
other non-repeatable parameters in the registration interface. This 
consequently led to 'at' being a single key-value pair and having a 
comma-separated list of base URIs.

However, now 'at' has been updated as a repeatable parameter after later 
versions of core-rd introduced extra-attrs*, with which we can 
(hopefully) extend.
>    * With changes to the RD in the latest versions, the endpoint lookup
>      looks a bit different. I've taken the examples of this section and
>      created some current ones in the upcoming RD draft ([1]).
>
>      Note that at least for the endpoint lookups, the `at` parameter does
>      not need to be implemented in a PN-aware RD, as it is the default
>      behavior for unknown RD Parameters to accept them on registration
>      and show them in an endpoint lookup.
>
>      I think that with the new behavior of the RD, the `tt` parameter
>      makes more sense in resource lookup than in endpoint lookup; would
>      you consider specifying it for there too?
>
>      Do the examples align with your ideas of how P-N can would work with
>      the latest RD?
>
>      [1]: https://core-wg.github.io/resource-directory/draft-ietf-core-resource-directory.html#rfc.appendix.B
Thank you, that was really very useful. The examples you provided have 
now been taken into -08. I think we'd still need to review how usage of 
'con' and the anchors as used in the current core-rd specification, can 
aid with the discovery of multiple transports for CoAP.

>    * Does `at` mean that *all* URIs on this server can have their
>      prefixes arbitrarily exchanged, or only the advertised links?
>
> * Alternative-Transport option:
>
>    * Does this option state that the requested URI is equivalent to the
>      indicated ones, or all URIs on the host?
These 2 comments are related:

The prevailing design approach was to register endpoint information per 
server, and not per resource. Therefore, the URI scheme and authority 
would differ, but the path is not affected. So they should be regarded 
as equivalent only in the sense that they should point to the same resource.

>    * Why is an option used here? The availability of an alternative
>      transport is a metadatum I think would be very suitable for
>      inclusion in </.well-known/core>. Expression as link metadata would
>      make the unmediated exchange more compatible with the RD-mediated
>      exchange, which right now look very different.
/.well-known/ is the best place for site-wide metadata. The challenge is 
to find some means of expressing transports available per-server in a 
way that does not break the per-resource web linking, so I'm not sure if 
/.well-known/core does that very well. The other way to go if we don't 
use the Alternative-Transport Option is to define a new resource under 
/.well-known/ whose representation contains values of available 
transports. Could that be viable and registered to an RD?
>
> * The 'ol' CoRE Link Attribute: Did you consider using a link relation
>    for this? (Ie. there would be a dedicated link from the described
>    resource to its alternative URIs, rather than the URIs being encoded
>    in target attributes). The "alternate" or "duplicate" registered
>    relations seem to already do the required.
>    
>    (Admittedly, I don't quite see the use case for individual link
>    alternative URIs; if the use case you have in mind answers the
>    question, it might be a good idea to outline that use case.)
The per-resource motivation and usage of attributes is to facilitate 
mapping to OCF's "eps" (described just before section 6.1)
>
>    * "Using CoRE Resource Directory": The example in 6.2 would, on a
>      lookup in a ol-unaware RD, return as shown here:
>
>      Req: GET coap://rd.example.com/rd-lookup/res?ep=node1
>
>      Res: 2.05 Content
>      [...]
>      <coap://node1-address/sensors/light>;if="sensor";
>          ol="http://[FDFD::123]:61616,coap://server2.example.com"
>
>      If the intention is that the href of the link can be re-interpreted
>      as a relative reference based on any of the ol values (btw: again,
>      why comma-separated?), this depends heavily on the serialization and
>      breaks when the serialization needs to be changed (as in the RD that
>      needs to return the absolute reference).
Thanks, this has now been updated. Also "ol" has been made as a 
repeatable attribute upon checking guidance from Section 2.2 in RFC 8288 
about attribute cardinality. Does the example look better to you?

> All things considered, I think that this is a document that should be
> adopted by the WG; it covers a relevant topic and provides good starting
> points for solving it.
>
> Thank you, Bill and Mert, for writing this document

Thank you for the great review!

Best regards,
Bill

[1] draft-silverajan-core-coap-alternative-transports-11