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
