Re: [Gen-art] [core] Genart telechat review of draft-ietf-core-resource-directory-25

[Christian Amsüss <[e-mail]>]

(This is one of the point-to-point follow-up mails on the RD -25
reviews; for the preface, please see the preceding mail on "The various
positions on draft-ietf-core-resource-directory-25" at
<https://mailarchive.ietf.org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>).

> Section 7.1 says: "... can be transported in the subject."  I think
> you should say "subject field" or "subject name".  Do you mean to
> exclude the subject alternative name?

response:

See GENERIC-SUBJECT.

> Section 7.1.1 says:
> 
>    Registrants that are prepared to pick a different identifier when
>    their initial attempt at registration is unauthorized should pick an
>    identifier at least twice as long as the expected number of
>    registrants; registrants without such a recovery options should pick
>    significantly longer endpoint names (e.g. using UUID URNs [RFC4122]).
> 
> I think that the reason for the  recommendation on length is to reduce
> the likelihood of name collision.  However, it is not clear to me why
> this is linked in any way to authorization failures on the first
> attempt to register.

response:

With growing numbers of participants, the chances some collision happening
stays at a constant level even with the 2n length due to the birthday paradox,
which is why the collision on the initial attempt is highlighted.

A bit of clarifying information was added in
https://github.com/core-wg/resource-directory/pull/248, without attempting to
verbosely lay out the whole background.

> Nits: [...]

resonse:

All addressed in https://github.com/core-wg/resource-directory/pull/246

> IDnits reports:
> 
>  == There are 3 instances of lines with non-ascii characters in the
>     document.

response:

Two of them are in an author's name, the third is in an example and relevant
there (as it talks about variations of a representation containing non-ascii
charactes).

>  == There are 1 instance of lines with multicast IPv4 addresses in the
>     document.  If these are generic example addresses, they should be
>     changed to use the 233.252.0.x range defined in RFC 5771

response:

That instance is a suggestion to IANA, it will be replaced with the actually
assigned address.

>  == There are 3 instances of lines with non-RFC3849-compliant IPv6
>     addresses in the document.  If these are example addresses, they
>     should be changed.

response:

see GENERIC-FFxxDB