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

[Jari Arkko <[e-mail]>]

Many thanks for your very useful review, Russ!

Some discussion inline, but I have a set of tentative changes at https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.diff.html

I plan to submit a new version, as soon as I’ve gone through the new full thread. The changes so far only relate to your comments, Russ.

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

Yes. I changed this.

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

As pointed out by Barry, this is indeed possible. I’m not entirely sure how necessary it was to restrict the subtypes to lower case — RFC 8141 is clear that types can be both cases — but I’ve tentatively done that.

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

Good catch! Corrected.

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

I made a small change, but I’m not sure how else to express this. We are talking about whether identifiers are modifiable for instance. The whole paragraph reads now:

On most devices, the user can display device identifiers. Depending
on circumstances, device identifiers may or may not be modified or
tampered with by the user. An implementation of the DEV URN MUST NOT change
such limitations or behaviour from what they were intended. In particular, a device
identifier that is intended to be immutable should not become mutable
as a part of implementing the DEV URN type. More generally, nothing in
this document should be construed to override what the relevant device
specifications have already said about the identifiers.

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

That would be good. Changed.

> Section 3.2.1 refers to "BASE64".  Please add an informative reference
> to RFC 4648 to be clear.

Good idea. Done.

> Section 4.1 uses the term "Ethernet" in two places.  I think both of
> them should be replaced by "MAC-48”.

Right. Done.

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

Ok (I have not yet considered John’s comments).

> Section 4.1: s/rests within the IEEE/
>              /rests with the IEEE Registration Authority/

Thanks.

> Section 7 includes: "publicly available specification that can
> be pointed to."  It is sufficient to say: ""publicly available
> specification.”

Ok. Changed.

Jari