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

From: Marco Tiloca <[email-masked]>
Date: Mon, 29 Nov 2021 23:29:04 +0100

Hi,

As promised, please find below a review of this draft.

Best,
/Marco

-----------------------

[Abstract]

* "unify these addresses"

    Perhaps you mean "unify the coexisting use of their corresponding 
addresses" ?

* "This document provides terminology"

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

[Section 1.1]

* Please, add the usual disclaimer "Readers are expected to be familiar 
with ..."

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

[Section 1.2]

* Considering the given explanation, perhaps "No Aliasing" should be "No 
unintended aliasing" ?

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

[Section 2]

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

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

[Section 2.3]

* "Links to proxies may be annotated with additional metadata ..."

    Simply by using (new) target attributes or are there possible 
different means?

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

[Appendix B]

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

[Nits]

* Section 1, s/indepenent/independent

* Section 1.1
--- s/many application/many applications
--- s/contentuous/contentious

* Section 2, s/is can be used/can be used

* Section 2.1
--- s/it may also/the server may also
--- s/unless they contain/unless that contains

* Section 2.3, s/renew their justification/to renew its justification

* Section 3
--- s/the latter see/for the latter see
--- s/interchangable/interchangeable
--- s/one one hand/on one hand

* Section 6.1
--- s/distrinction/distinction
--- s/accomodate/accommodate

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

* Section 6.4, s/indepependently/independently

* Section 7.2, s/would attackers/would allow attackers

* Appendix B, s/correctnes/correctness

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)