Subject: Alvaro Retana's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 19 Oct 2020 11:56:21 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-6man-rfc4941bis-11: No Objection

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-6man-rfc4941bis/

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

§3.3 (Generation of Randomized Interface Identifiers) starts by saying that the
"subsections specify example algorithms".  Are these algorithms just examples? 
Digging through the archive, it looks like they are: "It's one possible
algorithm, and not necessarily the recommended one." [1]

However, §3.4 (Generating Temporary Addresses) says this:

   6.  New temporary addresses MUST be created by appending a randomized
       interface identifier (generated as described in Section 3.3 of
       this document) to the prefix that was received.

IOW, it makes the algorithms in §3.3 mandatory ("MUST...as described in Section
3.3").

Please clarify the text one way or the other: by eliminating "examples" from
§3.3, or removing the text in parenthesis in §3.4.

[1] https://mailarchive.ietf.org/arch/msg/ipv6/OVdexfOXgdDM4r1QZ3iQcA_oWVQ

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 13:30:39 -0300

Hello, Alvaro,

Thanks so much for your comments! In-line....

On 19/10/20 15:56, Alvaro Retana via Datatracker wrote:
[....]
> "subsections specify example algorithms".  Are these algorithms just examples?

FWIW, the spirit is that algorithm is Section 3.4 is employed, and that 
the randomized IIDs to be used as described in Section 3.4 are generated 
in such a way that they comply with the requirements in Section 3.1.

As long as the IIDs comply with such requirements, it doesn't really 
matter which specific algorithm you employ for generating the IIDs.
At the end of the day, Section 3.3.2 is simply a PRNG. And so is Section 
3.3.1.

Furthermore, the goal of this document implies that it should be 
impossible for an external entity to tell what's the algorithm that was 
employed to generate the IIDs.

> §3.3, or removing the text in parenthesis in §3.4.

How about changing that paragraph as:

OLD:

NEW:
   6.  New temporary addresses MUST be created by appending a randomized
       interface identifier to the prefix that was received. The
       randomized interface identifier MUST comply with the design
       guidelines from Section 3.1. Section 3.3 specify some example
       algorithms that comply with the aforementioned design goals.

Xor, one might simply
NEW:
   6.  New temporary addresses MUST be created by appending a randomized
       interface identifier (see Section 3.3 of this document) to the
       prefix that was received.

or even remove the parenthesis (although the two other options are 
probably better).

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 20 Oct 2020 11:34:59 -0700

On October 20, 2020 at 12:30:54 PM, Fernando Gont
([email-masked](mailto:[email-masked])) wrote:

Fernando:

Hi!

> > Please clarify the text one way or the other: by eliminating "examples"
> > from §3.3, or removing the text in parenthesis in §3.4.
>

I'm ok with this suggestion, except for the "MUST comply with the
design guidelines from Section 3.1" part.  There's no interoperability
required to justify normatively pointing at §3.1, most of the bullets
there don't apply to the generation of random IIDs, and I don't see a
strong reference to §3.1 anywhere else in the text.

I would be very happy by simply changing that second "MUST" to "must".

Having said that, my comment was non-blocking, so I trust you and the
Responsible AD to make the right decision.

Thanks!

Alvaro.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 15:51:40 -0300

Hello, Alvaro,

On 20/10/20 15:34, Alvaro Retana wrote:
[....]
> Responsible AD to make the right decision.

Ok. Question for Erik: which of the three proposed changes (or Alvaro's 
suggested s/MUST/must/) would be best for you?

Thanks!

Cheers,