Subject: Re: [core] Review of draft-amsuess-core-transport-indication-02

From: Christian Amsüss <[email-masked]>
Date: Thu, 24 Feb 2022 13:34:35 +0100

Hello Marco,

thanks for the review (and the nudge because it left unprocessed).

On Mon, Nov 29, 2021 at 11:29:04PM +0100, Marco Tiloca wrote:
> * "unify these addresses"
> 
>    Perhaps you mean "unify the coexisting use of their corresponding
> addresses" ?

I really mean unification of different addresses (as in "making several
concrete instances logically into one"). This is more about what is
missing on a high level than about what the document provides.

> * "This document provides terminology"
> 
>    Yes, but it provides also enforceable means/approaches, right? :-) (what
> Section 1.2 refers to as "provisions")

I consider the terminology the more important aspect, but "terminology
and provisions" is what I've changed it to.

> [Section 1.1]
> 
> * Please, add the usual disclaimer "Readers are expected to be familiar with
> ..."

Good point; pulling in 7252 and {6690 or 8288}.

> * I wonder if the last paragraph about the Proxy-Uri option fits better when
> defining the "same-host proxy" above. That's when I was wondering about
> Proxy-Uri as an alternative, just to find it discussed later on.

Maybe -- but I liked to have it out of the way quickly. Plus, I don't
even want to send people in the way of Proxy-Uri; my hope is that people
curious about it find it there anyway, but people who read this
initially (and those tend to skip terminology) won't even get the idea
that Proxy-Uri might be an option at the point where Proxy-Scheme comes
up.

> [Section 1.2]
> 
> * Considering the given explanation, perhaps "No Aliasing" should be "No
> unintended aliasing" ?

The goal is that the mechanism introduces no aliasing (even if the
authors would intend to).

I'd think of it as a bit of a buzzword: All goals (also optimization)
set and label a direction for this document, and may not literally
achieve that. ("Optimization" might also be read to "reach an optimum",
which would need a metric and depending on that we'd fail that in some
metrics when taken literally).

> * "This document will not concern itself with changes in transport
> availability over time ..."
> 
>    Sure, but are the building blocks defined here in principle usable for
> that purpose? Something along these lines is suggested at the end of the
> paragraph.

I was thinking "we won't publish a schedule (but you can sure use
anything established method of keeping tabs on the resource)". Following
this ... mh, Max-Age is orthogonal, so works. Same for Observe, both
directly and through RD. Publishing information on pubsub? Why not. Just
creating a dynlink from </.well-known/core?rel=har-proxy> to somewhere
else? Same.

Thus changed to:

| nor in advertising their availability in advance. Hosts whose
| transport's availability changes over time can utilize any suitable
| mechanism to keep client updated, such as placing a suitable Max-Age
| value on their resources or having them observable.

> * On the mechanics in the first paragraph:
> 
>    - Should the device just carry on and do the same thing if it strangely
> receives a CoAP-over-X request including Proxy-Scheme:X and where it
> recognizes its name in Uri-Host?

You mean if it did not explicitly advertise transport X as a proxy?

It may, but the client can't expect it to.

(Thanks to the criticality of the options, a server that doesn't support
that will send a suitable error).

This should never occur if the client behaves properly (because it
shouldn't just try using arbitrary addresses as a proxy).

>    - It can help to expand about returning 5.05, which is the case unless
> the device is also a forward-proxy other than a same-host proxy.

I've expanded the code, noted the exception, and generally untangled
these sentences.

> [Section 2.3]
> 
> * "Links to proxies may be annotated with additional metadata ..."
> 
>    Simply by using (new) target attributes or are there possible different
> means?

That is the only annotation link format provides (but I don't want to
needlessly reiterate limitations of one way of expressing links).

> [Section 3]
> 
> * Perhaps introduce the device name device0815.example.com before the
> example begins?
> 
> * In the last paragraph, at least some of the text starting from "A
> simplistic client ..." seems to actually refer to the example shown in
> Figure 3 of Section 4.

Yes I should; held for example update (tracked at
<https://gitlab.com/chrysn/transport-indication/-/issues/1>)

> * About the OSCORE interaction point: when mentioning the "Section 4.1.3.2
> requirements" of RFC 8613, does it specifically refer to the omission of
> Uri-Host and Uri-Port? Would it still be possible to use OSCORE while taking
> advantage of a "has-proxy" relation?

It is possible to use OSCORE both with has-proxy and has-unique-proxy.

What 4.1.3.2 brings to the table is that OSCORE requires already that
the Uri-Host, -Port and Proxy-Scheme be ignored after decryption. So it
appears that it almost promotes any advertised `has-proxy` relation to
`has-unique-proxy` -- but only almost: Neither can the client know that
it is not seeing a reverse proxy, nor can it know whether the server may
not outright reject requests without the proper scheme/host/port before
even entering OSCORE processing.

I'm more and more leaning toward answering the question of "whether it's
actionable at all" with "no". No harm done, the server may still go for
has-unique-proxy like every other one might.

> [Nits]

Thanks, applied

> * Section 6.3, s/In figure Figure/In Figure

(Thank you LaTeX...)

BR
Christian

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