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

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 12:00:42 +0200

Hi IETFers,

I would like to ask whether there is process steps to retire one's name
from a published RFC.

I consider using such process to retire my name from the RFC that
analyses the 64bit boundary analysis.

For some reason I got in that group, then participated positively to the
discussion, and I let myself tempted to have my name up on the first
page of a published RFC; but finally, after much time and reflexion, I
think I do not agree with the effects of this RFC.

(I know there is common practice to retire one's name from a Work in
Progress Internet Draft - suffices it to ask - but I dont know whether
the same can be done with a published RFC).

Alex

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 19 Apr 2019 06:14:15 -0400

RFCs are not changed after they are published so removing one’s name from a existing RFC cannot be done.

Scott

> On Apr 19, 2019, at 6:00 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi IETFers,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 13:28:23 +0200

Hi Scott,

Thank you for the reply.

> Re: exploring the process of self retiring one's name from an RFC
> 
> "Scott O. Bradner" <[email-masked]> Fri, 19 April 2019 10:14 UTCShow
> header
> 

Errata?

Alex

> 
> Scott
> 
>> On Apr 19, 2019, at 6:00 AM, Alexandre Petrescu
>> <[email-masked]>; wrote:
>> 
>> Hi IETFers,
>> 
>> I would like to ask whether there is process steps to retire one's
>> name from a published RFC.
>> 
>> For some reason I got in that group, then participated positively
>> to the discussion, and I let myself tempted to have my name up on
>> the first page of a published RFC; but finally, after much time and
>> reflexion, I think I do not agree with the effects of this RFC.
>> 
>> (I know there is common practice to retire one's name from a Work
>> in Progress Internet Draft - suffices it to ask - but I dont know
>> whether the same can be done with a published RFC).
>> 
>> Alex
>> 
>

---

From: Jared Mauch <[email-masked]>
Date: Fri, 19 Apr 2019 07:55:37 -0400

> On Apr 19, 2019, at 7:28 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi Scott,
> 
> Thank you for the reply.
> 

Perhaps.  They are requests for comments.  One of the comments may be that technology has changed, or risk profiles (or any number of other assumptions or realities have been bent).  I think retiring authorship isn’t really a useful way, but is the perpetual archive of comments just the e-mail archives or should there be a more prominent way for an author to submit comments for the historical record?

- Jared

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 14:18:11 +0200

Le 19/04/2019 à 13:55, Jared Mauch a écrit :
>>> Re: exploring the process of self retiring one's name from an
>>> RFC "Scott O. Bradner" <[email-masked]> Fri, 19 April 2019 10:14
>>> UTCShow header RFCs are not changed after they are published so
>>> removing one’s name from a existing RFC cannot be done.
>> 
>> Errata?
> 
> Perhaps.  They are requests for comments.  One of the comments may be
> that technology has changed, or risk profiles (or any number of other
> assumptions or realities have been bent).  I think retiring
> authorship isn’t really a useful way, but is the perpetual archive of
> comments just the e-mail archives or should there be a more prominent
> way for an author to submit comments for the historical record?

With respect to questioning the kinds of comments that could be put:

- it's not because the technology has changed that I need my way removed 
from it.

- there is no new risk profiles.

- the reality has bent in the sense that the 64bit boundary seems to be 
imposed now in all new IPv6-over-foo RFCs.  It was so in the past 
(before the RFC), and I was hoping the RFC to change that tendency.  The 
reality is that since that RFC many other IP-over-foo documents have 
been written, and each time the recommendation is still to use 64bit 
IID.  That was not my intention when co-authoring that RFC.  I got into 
it to falsely believe the recommendation would happen in - what was at 
the time - the future.

With respect to improved usefulness of a perpetual archive to insert up 
to date feedback (comments answering the Request for Comments): I think 
it sounds natural and it makes sense.  That can not be the email list of 
the WG having developed the RFC, because it gets shut down.

That perpetual archive can not be a new Internet Draft because that 
expires if not adopted by a WG, which is itself subject to come and go 
of people.

Alex

---

From: Christian Huitema <[email-masked]>
Date: Fri, 19 Apr 2019 07:09:28 -0700

> On Apr 19, 2019, at 5:18 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> - it's not because the technology has changed that I need my way removed from it.
> 
> - the reality has bent in the sense that the 64bit boundary seems to be imposed now in all new IPv6-over-foo RFCs.  It was so in the past (before the RFC), and I was hoping the RFC to change that tendency.  The reality is that since that RFC many other IP-over-foo documents have been written, and each time the recommendation is still to use 64bit IID.  That was not my intention when co-authoring that RFC.  I got into it to falsely believe the recommendation would happen in - what was at the time - the future.
> 
> With respect to improved usefulness of a perpetual archive to insert up to date feedback (comments answering the Request for Comments): I think it sounds natural and it makes sense.  That can not be the email list of the WG having developed the RFC, because it gets shut down.
> 
> That perpetual archive can not be a new Internet Draft because that expires if not adopted by a WG, which is itself subject to come and go of people.

In short, you are asking to remove your name of the authorship of and RFC because if you knew then what you know now, you would not have written the paper that way, nor signed it.

Think about it. 

People change opinion all the time, for lots of reasons. Everybody makes what they think are mistakes. But the record is the record, and you don't get to change it.

You filed an errata to remove your authorship. That errata should be rejected, because the document is not actually erroneous. It states that you were one of the authors at the time of publication, and there is no doubt about that. There is no error.

-- Christian Huitema

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Apr 2019 09:44:41 -0500

I agree with Christian.

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.

Regards,
Behcet

On Fri, Apr 19, 2019 at 9:09 AM Christian Huitema <[email-masked]>
wrote:

> imposed now in all new IPv6-over-foo RFCs.  It was so in the past (before
> the RFC), and I was hoping the RFC to change that tendency.  The reality is
> that since that RFC many other IP-over-foo documents have been written, and
> each time the recommendation is still to use 64bit IID.  That was not my
> intention when co-authoring that RFC.  I got into it to falsely believe the
> recommendation would happen in - what was at the time - the future.
> >
> to date feedback (comments answering the Request for Comments): I think it
> sounds natural and it makes sense.  That can not be the email list of the
> WG having developed the RFC, because it gets shut down.
> >
> expires if not adopted by a WG, which is itself subject to come and go of
> people.
>
> In short, you are asking to remove your name of the authorship of and RFC
> because if you knew then what you know now, you would not have written the
> paper that way, nor signed it.
>
> Think about it.
>
> People change opinion all the time, for lots of reasons. Everybody makes
> what they think are mistakes. But the record is the record, and you don't
> get to change it.
>
> You filed an errata to remove your authorship. That errata should be
> rejected, because the document is not actually erroneous. It states that
> you were one of the authors at the time of publication, and there is no
> doubt about that. There is no error.
>
> -- Christian Huitema
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 19 Apr 2019 11:05:44 -0400

On 4/19/19 10:44 AM, Behcet Sarikaya wrote:

> I agree with Christian.
>
> 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.
That's a bad idea also.   The other authors' opinions in the past may 
not be their opinions now, and submitting their old text today as a new 
draft would presume that their opinions haven't changed.

The RFC is what it is, a record of some people's thoughts as of the time 
it was published.  Anyone who has been around this community very long 
realizes that he or she was once wrong about something he or she wrote 
in the past.   We just need to accept that and move on.

Keith

p.s. The 64-bit boundary was always a dubious idea in much the same way 
as hardwired IPv4 address "classes" were a dubious idea.   I would 
support phasing it out, even with the understanding that prefixes past 
/64 won't work for many existing IP-over-foo mechanisms.   To the extent 
that we can change some of those IP-over-foo mechanisms, it's probably 
worth doing so.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 17:09:12 +0200

Christian,

Le 19/04/2019 à 16:09, Christian Huitema a écrit :
>> - the reality has bent in the sense that the 64bit boundary seems 
>> to be imposed now in all new IPv6-over-foo RFCs.  It was so in the
>>  past (before the RFC), and I was hoping the RFC to change that 
>> tendency.  The reality is that since that RFC many other 
>> IP-over-foo documents have been written, and each time the 
>> recommendation is still to use 64bit IID.  That was not my 
>> intention when co-authoring that RFC.  I got into it to falsely 
>> believe the recommendation would happen in - what was at the time -
>> the future.
>> 
>> With respect to improved usefulness of a perpetual archive to 
>> insert up to date feedback (comments answering the Request for 
>> Comments): I think it sounds natural and it makes sense.  That can
>>  not be the email list of the WG having developed the RFC, because
>>  it gets shut down.
>> 
>> expires if not adopted by a WG, which is itself subject to come and
>> go of people.
> 
> In short, you are asking to remove your name of the authorship of and
> RFC because if you knew then what you know now, you would not have
> written the paper that way, nor signed it.

YEs.

> Think about it.
> 
> People change opinion all the time, for lots of reasons.

But I did not change my mind!  I always wanted the 64bit boundary
removed - then and now and in the future.  I was in the hope that that
RFC would help.

The events happened in such a way that that RFC hurts instead of
helping.  People read it as if it is a recommendation to use 64bit
boundaries.

> Everybody makes what they think are mistakes. But the record is the 
> record, and you don't get to change it.

I agree.

>  rejected, because the document is not actually erroneous. It states
>  that you were one of the authors at the time of publication, and 
> there is no doubt about that. There is no error.

I tend to agree.  Another person told me in private the same thing.

All I can do now, and I did, is to request an errata.  I agree if it is
rejected. I will take greater care next time when opportunities to
author documents arise - they may be worth considering, others should
rather be avoided.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 17:12:25 +0200

Behcet,

Thank you for the reply.

It is a good idea to write new I-Ds, or I-Ds updating old RFCs.

For this RFC in point, I am not main author.  I suppose the other 
authors will not agree if I modify it in the way I want to.  This is 
based on my understanding of their thinking.

Rather, I will stay happy by just having filed that Errata.

I will also tell anybody who asks me what is my thinking about the 64bit 
boundary.

Alex

Le 19/04/2019 à 16:44, Behcet Sarikaya a écrit :
> On Fri, Apr 19, 2019 at 9:09 AM Christian Huitema <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
> 
>      > On Apr 19, 2019, at 5:18 AM, Alexandre Petrescu
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>      >
>     tendency.  The reality is that since that RFC many other IP-over-foo
>     documents have been written, and each time the recommendation is
>     still to use 64bit IID.  That was not my intention when co-authoring
>     that RFC.  I got into it to falsely believe the recommendation would
>     happen in - what was at the time - the future.
>      >
>     not be the email list of the WG having developed the RFC, because it
>     gets shut down.
>      >
>      > That perpetual archive can not be a new Internet Draft because
>     that expires if not adopted by a WG, which is itself subject to come
>     and go of people.
> 
>     In short, you are asking to remove your name of the authorship of
>     and RFC because if you knew then what you know now, you would not
>     have written the paper that way, nor signed it.
> 
>     Think about it.
> 
>     People change opinion all the time, for lots of reasons. Everybody
>     makes what they think are mistakes. But the record is the record,
>     and you don't get to change it.
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Apr 2019 08:22:54 -0700

Without taking a position on this specific case, it seems like there
are some interesting questions here.

Consider the hypothetical case where I falsely obtain an RFC in the
name of some other person (don't worry about how, say they are on
sabbatical and I guess their password). They then rightly object to
the RFC being in their name. What do we do? I'm guessing the answer
is going to be "withdraw the RFC and issue a new one without that
author and with a different number"?

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Apr 2019 17:47:22 +0200

You seem to think the RFC should not apply anymore. So convince your old authors and/or the appropriate WG to move the RFC to Historic status.

Paul

Sent from mobile device

> On Apr 19, 2019, at 17:09, Alexandre Petrescu <[email-masked]> wrote:
> 
> Christian,
> 
>>> - the reality has bent in the sense that the 64bit boundary seems to be imposed now in all new IPv6-over-foo RFCs.  It was so in the
>>> past (before the RFC), and I was hoping the RFC to change that tendency.  The reality is that since that RFC many other IP-over-foo documents have been written, and each time the recommendation is still to use 64bit IID.  That was not my intention when co-authoring that RFC.  I got into it to falsely believe the recommendation would happen in - what was at the time -
>>> the future.
>>> With respect to improved usefulness of a perpetual archive to insert up to date feedback (comments answering the Request for Comments): I think it sounds natural and it makes sense.  That can
>> Everybody makes what they think are mistakes. But the record is the record, and you don't get to change it.
> 
> I agree.
> 
>> that you were one of the authors at the time of publication, and there is no doubt about that. There is no error.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 17:52:37 +0200

Le 19/04/2019 à 17:47, Paul Wouters a écrit :
> You seem to think the RFC should not apply anymore. So convince your
> old authors and/or the appropriate WG to move the RFC to Historic
> status.

I agree with your understanding.  But my co-authors certainly think it 
is not a Historic document but very up to date.

Their untold expectations proved correct (make all IP-over-foo do 64) 
and my untold expectation proved wrong (make all IP-over-foo do variable).

I will not take the time to convince my co-authors.  I rather want to 
separate.

Alex

>>>> <[email-masked]> wrote: With respect to
>>>> questioning the kinds of comments that could be put: - it's not
>>>> because the technology has changed that I need my way removed
>>>> from it. - there is no new risk profiles. - the reality has
>>>> bent in the sense that the 64bit boundary seems to be imposed
>>>> now in all new IPv6-over-foo RFCs.  It was so in the past
>>>> (before the RFC), and I was hoping the RFC to change that
>>>> believe the recommendation would happen in - what was at the
>>>> time - the future. With respect to improved usefulness of a
>>>> perpetual archive to insert up to date feedback (comments
>>>> answering the Request for Comments): I think it sounds natural
>>>> and it makes sense.  That can not be the email list of the WG
>>>> having developed the RFC, because it gets shut down. That
>>>> perpetual archive can not be a new Internet Draft because that 
>>>> expires if not adopted by a WG, which is itself subject to come
>>>> and go of people.
>>> Think about it. People change opinion all the time, for lots of
>>> reasons.
>> 
>> removed - then and now and in the future.  I was in the hope that
>> that RFC would help.
>> 
>>> Everybody makes what they think are mistakes. But the record is
>>> the record, and you don't get to change it.
>> 
>> I agree.
>> 
>>> You filed an errata to remove your authorship. That errata should
>>> be rejected, because the document is not actually erroneous. It
>>> states that you were one of the authors at the time of
>>> publication, and there is no doubt about that. There is no
>>> error.
>> 
>> All I can do now, and I did, is to request an errata.  I agree if
>> it is rejected. I will take greater care next time when
>> opportunities to author documents arise - they may be worth
>> considering, others should rather be avoided.
>> 
>> Alex
>>> -- Christian Huitema
> 
>

---

From: Aaron Falk <[email-masked]>
Date: Fri, 19 Apr 2019 11:59:27 -0400

> think I do not agree with the effects of this RFC.

Sounds like you may want to write an independent submission RFC on why 
you now think RFC7608 is a bad idea.

--aaron

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Apr 2019 12:49:09 -0400 (EDT)

On Fri, 19 Apr 2019, Alexandre Petrescu wrote:

> I agree with your understanding.  But my co-authors certainly think it is not 
> a Historic document but very up to date.

Then I agree with others here, and there is nothing you can or should
do. Plenty of people have their names on documents that turned out to
not work as expected. There is no shame in that. You were part of the
process that led to new and improved protocols. Thanks for that.

Paul

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Apr 2019 12:57:03 -0400

Alex,

With all respect to the other suggestions, Aaron has it right.
Interestingly, he is proposing a solution that has was on the
radar for 30 or 40 years (and I presume is still).   The
solution to a problem with an RFC, _any_ problem, is another
RFC.  Publishing the same document without your name on it is
probably a non-starter, not only because all of your co-authors
would need to agreed, but because the new document would need to
go through the same review, Last Call, and IESG decision process
the first one did and find it hard to imagine that would not end
up requiring some rewriting as well as taking up a lot of time.
But writing a critique and trying to get it published is always
in order.

I would suggest one variation on Aaron's suggestion: rather than
going directly to the Independent Submission Editor, have a
discussion with one of the relevant ADs about a commentary,
revised analysis, or other explanation about possible
sponsorship for publication in the IETF Stream.  If you can get
agreement to do that (and you are willing to put in the work),
you could structure the new document to update with existing one
(not by removing your name but by providing new information to
the community).  Upon publication, that would result in "updated
by" information in the metadata of the original and make your
position much more obvious than simply publishing a critique.
That would be much harder to accomplish with an Independent
Submission because cross-stream updates have historically been
contentious for various good reasons and possibly a few bad
ones.  If the AD(s) are not receptive, the Independent Stream is
an obvious second choice but, as Aaron hints, such a submission
would almost certainly have to be about "why that was a bad
idea" or "why you are more convinced it is a bad idea now than
you concluded at the time".   

Just to get your name removed, or even getting a subsequent
document published to remove it, is likely to be impossible; the
price of the nearest approximations is that you will need to do
some substantive and informative writing.

    john

--On Friday, April 19, 2019 11:59 -0400 Aaron Falk
<[email-masked]> wrote:

>> I consider using such process to retire my name from the RFC
>> that analyses the 64bit boundary analysis.
>> 
>> discussion, and I let myself tempted to have my name up on
>> the first page of a published RFC; but finally, after much
>> time and reflexion, I think I do not agree with the effects
>> of this RFC.
> 
> 
> Sounds like you may want to write an independent submission
> RFC on why you now think RFC7608 is a bad idea.
> 
> --aaron

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 18:01:14 +0200

> author and with a different number"?

This hypothesis is not very far-fetched, albeit there are so many 
enquiring eyes at IETF that it would be difficult to implement it very far.

I have seen it in common early stages of I-D development to put someone
name without really having a true convinced agreement.  Once you put a
name there, it stays there; the text inside may involve very largely,
but the names stay there.

Evolution of text also means wider support.  So it's hard to decide
whether one wants to stay with the momentum, or wants to separate early.

The more time passes, the more obvious is which choice to make, but the
more difficult is to actually make it. (basically after AUTH48 it seems
even an Errata doesnt do it).

An additional complexity is the pseudonyms: how to make sure that the 
names we see in drafts are real names or pseudonyms.  Should a 
technically sound idea in a draft be supported if authored under 
pseudonym.  Is adding a pseudo to an idea killing the idea?

Alex

> 
> -Ekr
> 
> 
> 
> 
> On Fri, Apr 19, 2019 at 8:17 AM Alexandre Petrescu 
> I will also tell anybody who asks me what is my thinking about the 
> 64bit boundary.
> 
> Alex
> 
>> 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.
>> 
>> Regards, Behcet
>> 
>> 
>> On Fri, Apr 19, 2019 at 9:09 AM Christian Huitema
> <[email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>> 
>> 
>> 
>> <[email-masked]
> <mailto:[email-masked]> 
> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
>> wrote:
>>> 
>>> - it's not because the technology has changed that I need
> my way
>> removed from it.
>>> 
> IP-over-foo
> Everybody

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2019 14:02:07 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-

That rather far fetched scenario would involve so many process
failures that there's no way to say what the response would be without
knowing the facts of the specific situation.  If it were malicious,
perhaps to defame the person, or to fake patent priority, there would
be lawyers and law enforcement swarming about and complicating the
situation in ways I wouldn't begin to guess.

I think there are more pressing problems for us to deal with.

Apropos the original question, you don't get to rewrite history.  If
you think an RFC you wrote is wrong, write a draft with or without
the original co-authors saying why and see if you can get support for
publishing it.  That's how the IETF works.

R's,
John

---

From: [email-masked]
Date: Fri, 19 Apr 2019 11:13:48 -0700 (PDT)

> publishing it.  That's how the IETF works.

It's how the world works, when it works. Undo has always been more of a fantasy
than a reality, but thanks to Keller, Fennerty, Tilghman, et al., who
collectively made inexpensive paper widely available cira 1860, any chance
of it working was effectively eliminated.

And then along came digital, reducing the cost of copies to essentially zero.

Of course this hasn't stopped people from trying. And failing. Repeatedly.

Think of it as the world's first blockchain. And like a blockchain, your only
option is to publish a correction of some sort.

				Ned

---

From: Marco Davids <[email-masked]>
Date: Fri, 19 Apr 2019 21:53:02 +0200

Christian Huitema wrote:

 > You filed an errata to remove your authorship.
 > That errata should be rejected

I've been pondering about this. Is there a need for a mechanism to solve 
cases like this? Should we allow authors to distant themselves from 
previous work, by making a brief statement in an errata? Maybe we should.

I think I could live with an errata to RFC7421, stating what was stated 
and leave the RFC itself in tact. The most appropriate status for it 
would probably be: 'Held for Document Update'[1].

Would that work for for you, Alexandre?

-- 
Marco

[1] https://www.rfc-editor.org/errata-definitions/

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Apr 2019 08:13:43 +1200

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.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Apr 2019 08:23:31 +1200

> author and with a different number"?

If such a blatant abuse happened, I've no doubt that the RFC Editor
would act appropriately. "Do the right thing", as Spencer reminds us.

But in this particular case, I could go back through email to find the
bits that Alexandre contributed. The document was intentionally
written as factual analysis, at a given point in time, and not as
a recommendation. It's part of the historical record.

The place for change is draft-ietf-6man-rfc4291bis, which is in
limbo since we haven't found consensus.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Apr 2019 08:29:03 +1200

Alexandre, I have to call you out on this one:

> Their untold expectations proved correct (make all IP-over-foo do 64) 

If that was my opinion, why would I have argued for removing the /64
boundary from draft-ietf-6man-rfc4291bis, and why would I be a co-author
of draft-bourbaki-6man-classless-ipv6?

   Brian

> .

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 23:15:25 +0200

> previous work, by making a brief statement in an errata? Maybe we should.

I think yes.

> would probably be: 'Held for Document Update'[1].

I agree to leave the RFC intact, just w/o my name in it.  I filed an 
Errata about it.

I dont understand 'Held for doc update'.

I do not support this RFC anylonger.

Alex

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Apr 2019 14:42:14 -0700

> Why would the co-authors, the IETF, and the RFC Editor agree to a
> falsification of history?

what you (and i) assume, but which has not been clearly articulated, is
that published rfcs are an archival historical record, not works in
process.  once published, they are frozen.  hence errata etc. are
published separately.

randy

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 23:46:51 +0200

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.
> 
> 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.

> 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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Apr 2019 23:52:25 +0200

> of draft-bourbaki-6man-classless-ipv6?

I do not doubt your intentions with respect to these drafts.

But look how it works: none of these two drafts get through (one is 
limbo one is non a WG item); what gets through is the RFC that is read 
by people as support of /64.  That is not normal.

I do not fully understand the intentions of the other authors, and I 
will not really bother further.

If consensus is what gets an RFC, and that consensus leads to an idea 
that I do not agree with, then I prefer retire from it.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 20 Apr 2019 01:52:14 +0200

> some substantive and informative writing.

John,

Thank you for the suggestion of a separate document.  It makes sense as 
you describe it.  I would be the only author of that new document and, 
if approved, it would express better what  I wanted to say in the first 
place.

I will see whether an opportunity may arise.

Alex

---

From: Tim Chown <[email-masked]>
Date: Sat, 20 Apr 2019 07:24:49 +0000

> On 19 Apr 2019, at 16:47, Paul Wouters <[email-masked]> wrote:
> 

As another author of that RFC, I would object strongly to that.  The (purely informational) draft documents the pros and cons of the 64-bit boundary, why it exists, and impacts of changing it (assumptions made).  It does not preclude any such future change.  

Alex, I recall at the time you had the view you are expressing now, but chose to remain an author.  I think you now have to live with that choice!

But nothing precludes a new draft being written on the subject.

Tim

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 20 Apr 2019 19:47:56 +0200

Le 20/04/2019 à 09:24, Tim Chown a écrit :
>> You seem to think the RFC should not apply anymore. So convince
>> your old authors and/or the appropriate WG to move the RFC to
>> Historic status.
> 
> As another author of that RFC, I would object strongly to that.  The
> (purely informational) draft documents the pros and cons of the
> 64-bit boundary, why it exists, and impacts of changing it
> (assumptions made).  It does not preclude any such future change.
> 
> Alex, I recall at the time you had the view you are expressing now,
> but chose to remain an author.  I think you now have to live with
> that choice!
> 

Tim,

Thank you for the recall of that time; which confirms me I did say it.

I will consider new draft being proposed in the subject.  IT will say 
something like "there is no 64bit boundary, the IIDs are variable length".

I wait a little for the rate limitation.

Alex