Re: [Iot-directorate] Iotdir telechat review of draft-ietf-core-dev-urn-09

[Barry Leiba <[e-mail]>]

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 <
[e-mail]> 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."
>
>
>
>