Re: [Pearg] Research Group Last Call for draft-irtf-pearg-numeric-ids-history-03

[Fernando Gont <[e-mail]>]

Hi, Kris,

Looks like I had failed to respond to this one. -- my apologies for that!

In-line...

On 16/11/20 14:51, Kris Shrishak wrote:
[...]
> Comments:
> 
> - I am not sure if it is within the scope of this document, but when I
> am reading a document as a history, then I am also interested in why
> certain choices were made and not only the order in which they were
> made. Maybe mailing lists can give us some insight on this. For
> instance, the use of global counters for IPv6 when the issue of global
> counters for TCP Initial Sequence Numbers was already raised well before
> RFC2460 was published. It could just be that the authors and the WG were
> unaware or did not consider the issue relevant.

In some cases it's hard to tell.

I'd argue that, in many cases, some issue was discussed within some 
group, but not within another.  For example, you normally have very 
different sets of people participating in transport protocols and 
internet protocols -- I've done both, but I'd say that's rather unusual.

Then the issue was electro-political: RFC7939 was originally meant to be 
Std Track. But then there was the argument that if RFC2460 was formally 
updated, it wouldn't be possible to elevate it to Internet Standard. So 
the track was changed to Informational, and then the recomendation to 
use global counters was removed from what became RFC8200.

When we published RFC7217, the group rejected the idea to formally 
replace the traditional "Modified EUI-64 scheme" (also known as "embed 
your MAC address in the Interface Identifier"). However, well into 
post-Snowden times, the idea got harder to reject, I guess.




> - Section 1: "Recent history indicates that ... specification or
> selected by implementers."
> 
> If recent history refers to the examples preceding this paragraph or to
> the timelines presented in the following sections, then the framing of
> this sentence can make it explicit. Maybe something along the lines of
> "these examples indicate" will add clarity. Otherwise, a reference to a
> couple of recent RFCs can substantiate the claim of recent history.

I've applied the suggested change ("These examples indicate...")



> Chris Wood [1] also raised this issue a while back in the context of
> https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-02
> 
> - Section 1, 5, 6, 10: I am not quite sure what "negative security and
> privacy properties" means. Maybe it is just me, but this could be
> formulated differently. An example formulation, similar to RFC 7217,
> could be "negatively affect the privacy and security properties".

What we meant was "bad properties". FWIW, I've applied your suggested 
edit in several places.

Thanks!

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