Re: exploring the process of self retiring one's name from an RFC

[Alexandre Petrescu <[e-mail]>]

Brian,

I want to thank you for the work on this RFC and your invitation to me
to join.  It was a great experience, and I learned a lot.

It's just that it turned out diferently than why I accepted at the time.

The consensus was there, the RFC got through its way in that difficult
maze of 6MAN.  The consensus-building was a success.  But it is not what
I meant.

Le 19/04/2019 à 22:13, Brian E Carpenter a écrit :
> On 20-Apr-19 02:44, Behcet Sarikaya wrote: ...> Alex, my suggestion 
> is to write a new draft call it draft-someone-rfcxxxbis with the 
> current text on the RFC minus you as the author.
>> Maybe you can not submit it you need to ask one of the co-authors 
>> to submit. That draft may quickly be progressed to become a new RFC
>> to supersede RFCxxx.
> 
> Why would the co-authors, the IETF, and the RFC Editor agree to a 
> falsification of history? I suggest re-reading the novel "1984" for 
> further elaboration of this point. Deleting authors is a very 
> Stalinist approach to history.

Stalin did not request that, I did; I requested it, and only about me.

It's as when I request google to delete a reference to me saying
something I discover is wrong. (e.g. the use of MCP term in some
document).  Or when I request a site to delete all data about me.

> Brian (co-author of RFC7421, which by the way makes no 
> recommendations whatever)

Indeed, the RFC makes no recommendation.  That is probably an advantage
and also an inconvenient.  Because people do read it the way they like it.

I have not seen one single reference to this RFC that reads it the way I
wanted it to be read.

Look at what happens now to the IPv6-over-OCB draft.  It is requested to
put 64 there, just to progress it.  It is at least the 3rd IP-over-foo
I-D to be requested so, since that RFC was published.  I suspect this
suggestion is coming from readers of this paragraph in the RFC:
> Numerous IPv6-over-foo documents make mandatory statements with 
> respect to the 64-bit length of the IID to be used during the 
> Stateless Autoconfiguration.  These documents include [RFC2464] 
> (Ethernet), [...].

When people read it, people feel like a new IPv6-over-foo  should get in
that long line, just to be part of this RFC.

That is not what I meant.

You may think that is only me suspecting that way, but look at how
RFC7421 is cited.

8504:
> The current IPv6 Address Architecture is based on a 64-bit boundary 
> for subnet prefixes.  The reasoning behind this decision is 
> documented in [RFC7421].

I meant RFC to give a reason to _not_ do boundary, not to do boundary.

8065:
> ideally all 64 bits of the IID should be used, although historically 
> some bits have been excluded for reasons discussed in [RFC7421].

For me, the main goal of that RFC was to no longer talk about 64 bit
IID; the goal was not to motivate some bits in it.

7934:
> In IPv6, a single link [64bit, my note] provides over four billion 
> times more address space than the whole IPv4 Internet [RFC7421].

RFC  should have stated these billions is way too much of what a largest
Ethernet subnet can do.  RFC should not have been a reason to support
the 64 bit boundary.

7707:
> [RFC7421] discusses the "default" /64 boundary for host subnets and 
> the assumptions surrounding it.  While there are reports of sites 
> implementing IPv6 subnets of size /112 or smaller to reduce concerns
>  about the above attack, such smaller subnets are likely to make 
> address-scanning attacks more feasible, in addition to encountering 
> the issues with non-/64 host subnets discussed in [RFC7421].

... 'encountering the issues'... as if non-64 was something wrong.  It
was not my goal to say so.

All these are wrong citations and uses of this RFC.

I wish I did not make part of authors giving people reason to continue
with this 64.

Alex



> 
>