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

[Christian Amsüss <[e-mail]>]

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?").

* 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').

* 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.

* 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.

  * 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

  * 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?

  * 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.

* 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.)

  * "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).

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
Christian

-- 
You don't become great by trying to be great. You become great by
wanting to do something, and then doing it so hard that you become great
in the process.
  -- Marie Curie (as quoted by Randall Munroe)