[Anima] Éric Vyncke's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you (and so many friends in the authors' list!) for the work put into
this document; it took a while to get to this stage ;-) The intersection with
MUD is also a nice feature.

I have a couple of DISCUSSes (probably easy to fix) and _several_ COMMENTs and
some nits (after a couple of nits, I stopped marking them). I also stopped
writing COMMENTs after section 5.3.

Regards,

-éric

== DISCUSS ==

TLS is assumed to be used but I failed to find WHICH version of TLS MUST be
used. The only reference in the reference section is version 1.2. Probably
worth to refer to this version in the text as well and use version 1.3 of TLS.

-- Section 2.3.1 --

Does the "serial number" need to be unique per vendor ? I guess so then I
strongly suggest to use a different word than "serial number" (e.g. unique
device ID) as a vendor can have multiple products in its portfolio, each having
a different set of unique "serial numbers".

-- Section 3.3 --

The example 1 does not include the mandatory (per YANG module) serial-number.
It should also state that the cert is not included for saving space in this
document.

-- Section 4.1 --

There are TWO back-off mechanisms: one for the method and one for the proxy but
no description on how those mechanisms interact together.

-- Section 4.3 --

Probably a naive question about GRASP (that I do not know), but in the example
there is "IPPROTO_TCP, 80" that seems to indicate the use of plain HTTP and no
TLS at all. Is it an issue ?

Is there a reason why IPv6 ULA are used rather than the documentation prefix ?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

== COMMENTS ==

-- Section 1 --

Please introduce the MASA acronym used after.

-- Section 1.1 --

> the pledge requires realtime connectivity to the manufacturer
>      service

Why this connection requires "realtime" ? Esp when reading in section 1.3.1
"The bootstrapping process can take minutes to complete"

-- Section 1.2 --

Please use the RFC 8174 boilerplate.

"160-bit SHA-1 hash" I will let the security AD to check whether SHA-1 is
deemed sufficient for this purpose.

- Section 1.5 --

Please explain/refer GRASP acronym.

-- Section 2 --

I wonder what will happen when the device vendor stops maintaining the MASA
on-line?

-- Section 2.2 --

Out of curiosity, why this document uses the word "voucher" as opposed to
"ticket" ?

-- Section 3.4 --

I find a little weird that the included YANG module has a different authors
list than the document itself.

Please refer to RFC 8174.

"RFC YYYY: Voucher Profile for Bootstrapping Protocols" does not seem correct
in a YANG module reference.

-- Section 5 --

The MASA URI synthesis explanation is a duplicate of a previous explanation.
Unsure whether it helps the reader.

...

-- Section 8.4 --

I am afraid that the DNS service names have a length of maximum 15 characters.
But, IANA is of course the source of truth.

-- Appendix A --

Using IPv6 LLA should be enough, I do not see the reason to describe a new
protocol using legacy IPv4 addresses because IPV6 link-local addresses should
work on any decent layer-2 network.

== NITS ==

A lot of "ethernet" and "internet" while those words are usually capitalized as
"Ethernet" or "Internet".

-- Abstract --

Shouldn't the plural form used in "using manufacturer installed X.509
certificate" ?

-- Section 1.5 --

s/Some of the options in this document is the result of requirements/Some of
the options in this document are the result of requirements/ ?

-- Section 2.3.2 --

Please use uppercase in the protocol acronyms in "that MUST be supported,
including ldap, http and ftp"

....

-- Section 5.1 --

"A Pledge that can connect to multiple registries concurrently, SHOULD do so."
lower case for pledge and what is the purpose of the comma in this sentence?
(ok I am not an English native speaker so I can be wrong)