Thanks for the quick review, Russ, and good catches here.
On one item, though:
> If both cases are to be supported, the upper case letters need to be
> added to the ABNF to permit them.
Actually not: quoted letters in ABNF are case-insensitive, so “a” matches both lowercase a and uppercase A.
Barry
On Wed, Jan 6, 2021 at 4:41 PM Russ Housley via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Russ Housley
Review result: Almost Ready
I reviewed this document as part of the IoT Directorate's effort to
IoT-related IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the Internet Area Directors.
Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.
Document: draft-ietf-core-dev-urn-09
Reviewer: Russ Housley
Review Date: 2021-01-06
IETF LC End Date: 2020-12-02
IESG Telechat date: 2021-01-21
A review from the IoT Directorate was requested on 2021-01-05, which is
after the IETF Last Call ended. I assume that the Internet ADs want
this review to help inform them during IESG Evaluation.
Summary: Almost Ready
Major Concerns:
Section 3.2 says:
The optional underscore-separated components following the hexstring
are strings depicting individual aspects of a device.
Not all of the DEV URN forms contain a hexstring; however, all of them
are allowed to end with underscore-separated components. I suggest:
The optional underscore-separated components at the end of the
DEV URN depict individual aspects of a device.
Section 3.2.1 says:
... and a MAC address could be represented either with
uppercase or lowercase hexadecimal digits.
This is not allowed by the ABNF:
hexstring = 1*(hexdigit hexdigit)
hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
If both cases are to be supported, the upper case letters need to be
added to the ABNF to permit them.
Section 4.2 says:
...
64-bit identifier that consists of 8 byte family code, 48 bit
identifier unique within a family, and 8 bit CRC code [OW].
The math does not work. I suspect: s/8 byte/8 bit/
Section 6 says:
... An implementation of the DEV URN MUST NOT
change these properties from what they were intended.
It is not clear to me the meaning of "they" in this sentence.
Please clarify.
Minor Concerns:
Section 3.2 says:
DEV URNs do not use r-, q-, or f-components.
I would have liked a bit more context here. I suggest:
DEV URNs do not use r-, q-, or f-components as defined in [RFC8141].
Section 3.2.1 refers to "BASE64". Please add an informative reference
to RFC 4648 to be clear.
Section 4.1 uses the term "Ethernet" in two places. I think both of
them should be replaced by "MAC-48".
Nits:
Section 3.2 says:
However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV URNs
do not support percent-encoding.
This does not seem like a "however" statement to me. Perhaps, it is
a "Note that" statement. Or, just drop "However".
Section 4.1: s/rests within the IEEE/
/rests with the IEEE Registration Authority/
Section 7 includes: "publicly available specification that can
be pointed to." It is sufficient to say: ""publicly available
specification."
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
