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

From: Christian Amsüss <[email-masked]>
Date: Fri, 23 Feb 2018 16:08:34 +0100

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)

---

From: Christian Amsüss <[email-masked]>
Date: Sat, 24 Feb 2018 12:40:27 +0100

Hello Bill and Mert,

during the review of protocol-negotiation, I came up with an idea that
is too far off from the document to go directly into a review. It might
be an overdose of web-linking talking here, so feel free to dismiss it
if need be, but maybe there are ideas in it that can help bring on p-n.

Let me start with examples and then explain what they should mean:

| Req: GET coap://node1/.well-known/core
| Res: 2.05 Content, Payload:
| <>;alt-base="coap+tcp://node1",
| </sensor/temp>;if="core.s"

or when registering at the RD:

| Req: POST /rd?ep=node1&con=coap://node1
| <>;alt-base="coap+tcp://node1",
| </sensor/temp>;if="core.s"
| Res: 2.01 Created, Location: /reg/1234

The endpoint registering at the RD could update the alt-base value(s) of
the link like it would update any other link it manages. (Admittedly,
that part of RD got postponed; might look like PATCH /reg/1234, Payload
{"1": {"href": "", "alt-base": ["coap+tcp://node1:1234"]}} in some
upcoming JSON link patch format).

Resource lookups would stay the same. Asking a server directly for
alternative transports could be done with GET
/.well-known/core?alt-base=* or /.well-known/core?alt-base=coap+ws://*.
This would be a dedicated request rather than piggy-backing onto any
existing one with a new option, but we're doing the same with any of the
other resource metadata as well, and a .well-known/core discovery is
often the first step in interaction anyway.

One way to give the protocol negotiation meaning to this would be only
two normative sentences:

| An "alt-base" attribute on a link means that representations of the link
| target are equally valid if the attribute's value were assigned as Base
| URI of the encapsulating entity (RFC3986 Section 5.1.2) for the purpose
| of resolving relative references in the document. URIs obtained from the
| representation using any alt-base value are all related to the URI
| obtained from the same reference without considering the alt-base
| attribute by the "alternative" relation (and therefore to each other, as
| that relation is transitive).

(I've picked the "alternative" relation here; see my review comments on
the `ol` attribute. If no link relation is deemed suitable and you stay
with `ol`, the second sentence would need to say that they are
"equivalent for all REST operations supported by their protocols".)

The approach of transmitting the URI data in link attributes is
motivated by the RD's desire to not be anything more than a cache of
what can be discovered using .well-known/core discovery.

The explanation of being an "alternative Base URI" rather than a generic
alternative transport could be a middle ground between saying that only
a single URI is available somewhere else and saying that everything on
this address is available there: It only makes statements about the
links in the presented document. This would allow groups of resources to
state their equivalences.

The approach suggested here has some drawbacks: It is a bit more verbose
in terms of transmitted bytes, and requires constrained nodes to
synthesize variable data into payload that we usually take pride in
being able to assemble at build time. If there is interest in the
approach at all, I think we can overcome those.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Feb 2018 13:25:27 +1100

Just a tourist, but can someone explain why this design needs to be so
fundamentally different to RFC 7838?

Making the means by which a resource is identified differ based on the
means of interaction is something we have tried hard to avoid in HTTP.
Or maybe this is the key point of divergence between HTTP and COAP and
any attempt to address this is a lost cause.

On Sat, Feb 24, 2018 at 10:40 PM, Christian Amsüss
<[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>