Subject: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48

From: Bob Hinden <[email-masked]>
Date: Sat, 11 Feb 2017 09:28:40 -0800

Hi,

<draft-ietf-6man-default-iids-16.txt> is currently in AUTH48.  According to the datatracker it has been in the RFC Editor queue for 54 days.  Everything is done, except there is an impasse over a change to the Acknowledgement Section.  One of the authors has proposed adding:

   Fernando Gont would like to thank Nelida Garcia and Guillermo Daniel
   Gont for their love and support, and Jorge Oscar Gont and Diego
   Armando Maradona for their inspiration.

Some of the other authors don’t think this change is appropriate for AUTH48, but the author proposing this has insisted on adding this text.

Please respond with either support or non-support for this proposed change by 18 February 2017.  I think it is unfortunate to add extra delay over this change, but after consulting with our AD, I think the best course is to ask the working group.

Thanks,

Bob (Document Shepard)

---

From: Fred Baker <[email-masked]>
Date: Sat, 11 Feb 2017 10:14:58 -0800

I take it these are family members of Fernando's? If so, this is common in books, but not in RFCs.

> On Feb 11, 2017, at 9:28 AM, Bob Hinden <[email-masked]> wrote:
> 
> Hi,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Sat, 11 Feb 2017 10:15:01 -0800

---

From: Sander Steffann <[email-masked]>
Date: Sat, 11 Feb 2017 21:51:53 +0100

Hi Fred,

> Op 11 feb. 2017, om 19:15 heeft Fred Baker <[email-masked]> het volgende geschreven:
> 

If Diego Maradona is a family member I'm impressed ;-)

Cheers,
Sander

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 11 Feb 2017 13:11:11 -0800

On Sat, Feb 11, 2017 at 9:28 AM, Bob Hinden <[email-masked]> wrote:

> Please respond with either support or non-support for this proposed change
> by 18 February 2017.  I think it is unfortunate to add extra delay over
> this change, but after consulting with our AD, I think the best course is
> to ask the working group.
>

Do not support.

---

From: Enno Rey <[email-masked]>
Date: Sun, 12 Feb 2017 09:47:55 +0100

Hi,

On Sat, Feb 11, 2017 at 09:28:40AM -0800, Bob Hinden wrote:
> Some of the other authors don???t think this change is appropriate for AUTH48, but the author proposing this has insisted on adding this text.
> 

"The ITU works in a formal, diplomatic style, suitable for international infrastructure and government representatives. The IETF works in an informal, casual style, suitable for innovation and creativity."
(Brian Carpenter: Network Geeks, p. 137).

I think in that spirit we should be conservative when striving for technical strictness but liberal when writing April 1st RFCs, doing Scotch BoFs and tolerating unsual acknowledgement sections...

I support it.

thanks

Enno

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: t.petch <[email-masked]>
Date: Sun, 12 Feb 2017 11:27:01 +0000

Do not support

Tom Petch

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Feb 2017 07:56:48 +1300

Hi,

I don't think this is a WG matter and I don't think it's the IETF's business
either. It seems to me that this matter is in the scope of the RFC Editor to
decide, if the authors can't, since it's about the style and contents of an RFC.
IMHO, it has nothing to do with its technical content or with the fact that
it's an IETF stream document.

Regards
   Brian Carpenter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 12 Feb 2017 14:52:26 -0500

The RFC Editor clearly has final call.

However, I think this is an inappropriate use of the technical 
acknowledgements section of the document.  The purpose of that section 
is to acknowledge direct contributions to the document, such as 
performing significant review, providing useful pieces of text that do 
not rise to the level of document authorship, and other similar issues.
We do not, for example, acknowledge all of the supporting developments 
and research, all of the open source implementations (or vendor 
implementations) that help us confirm that things work before 
publication, and the myriad other aspects that contribute to making an 
RFC from the IETF.

Yours,
Joel

---

From: [email-masked]
Date: Sun, 12 Feb 2017 21:19:27 +0100

Brian,

> it's an IETF stream document.

What makes you think that?
Is that described in RFC process somewhere?

From RFC7221:
      REMINDER:  Once a working group adopts a draft, the document is owned
      by the working group and can be changed however the working group
      decides, within the bounds of IETF process and the working group
      charter.  Absent explicit agreement, adopting a document does not
      automatically mean that the working group has agreed to all of its
      content.  So a working group (or its charter) might explicitly
      dictate the basis for retaining, removing, or modifying some or
      all of a draft's content, technical details, or the like.
      However, in the absence of such constraints, it is worth having
      the adoption process include a sub-process of gathering working
      group concerns about the existing draft and flagging them
      explicitly.
...
      It is a responsibility of the Working Group Chairs to ensure that
      document authors make modifications in accord with working group
      rough consensus.  Authors/editors are solely chosen by the Chairs
      -- although the views of the working group should be considered --
      and are subject to replacement for a variety of reasons, as the
      Chairs see fit.

The document is the output of the working group.
While the authors have some flexibility during AUTH48 under the guidance of the RFC Editor, ADs and document shepherd, it is certainly not the place to add personal messages. The editors of a working document are expected to represent the working group.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Sun, 12 Feb 2017 17:33:11 -0300

> I take it these are family members of Fernando's? If so, this is common in books, but not in RFCs.

These are Acknowledgements of an RFC you've written (RFC1812):

---- cut here ----
Acknowledgments

   O that we now had here
   But one ten thousand of those men in England
   That do no work to-day!

   What's he that wishes so?
   My cousin Westmoreland? No, my fair cousin:
   If we are mark'd to die, we are enow
   To do our country loss; and if to live,
   The fewer men, the greater share of honour.
   God's will! I pray thee, wish not one man more.
   By Jove, I am not covetous for gold,
   Nor care I who doth feed upon my cost;
   It yearns me not if men my garments wear;
   Such outward things dwell not in my desires:
   But if it be a sin to covet honour,
   I am the most offending soul alive.
   No, faith, my coz, wish not a man from England:
   God's peace! I would not lose so great an honour
   As one man more, methinks, would share from me
   For the best hope I have. O, do not wish one more!
   Rather proclaim it, Westmoreland, through my host,
   That he which hath no stomach to this fight,
   Let him depart; his passport shall be made
   And crowns for convoy put into his purse:
   We would not die in that man's company
   That fears his fellowship to die with us.
   This day is called the feast of Crispian:
   He that outlives this day, and comes safe home,
   Will stand a tip-toe when the day is named,
   And rouse him at the name of Crispian.
   He that shall live this day, and see old age,
   Will yearly on the vigil feast his neighbours,
   And say 'To-morrow is Saint Crispian:'
   Then will he strip his sleeve and show his scars.
   And say 'These wounds I had on Crispin's day.'
   Old men forget: yet all shall be forgot,
   But he'll remember with advantages
   What feats he did that day: then shall our names.
   Familiar in his mouth as household words
   Harry the king, Bedford and Exeter,
   Warwick and Talbot, Salisbury and Gloucester,

Baker                       Standards Track                   [Page 173]

RFC 1812         Requirements for IP Version 4 Routers         June 1995

   Be in their flowing cups freshly remember'd.
   This story shall the good man teach his son;
   And Crispin Crispian shall ne'er go by,
   From this day to the ending of the world,
   But we in it shall be remember'd;
   We few, we happy few, we band of brothers;
   For he to-day that sheds his blood with me
   Shall be my brother; be he ne'er so vile,
   This day shall gentle his condition:
   And gentlemen in England now a-bed
   Shall think themselves accursed they were not here,
   And hold their manhoods cheap whiles any speaks
   That fought with us upon Saint Crispin's day.

                                   -- William Shakespeare

   This memo is a product of the IETF's Router Requirements Working
   Group.  A memo such as this one is of necessity the work of many more
   people than could be listed here.  A wide variety of vendors, network
   managers, and other experts from the Internet community graciously
   contributed their time and wisdom to improve the quality of this
   memo.  The editor wishes to extend sincere thanks to all of them.

   The current editor also wishes to single out and extend his heartfelt
   gratitude and appreciation to the original editor of this document;
   Philip Almquist.  Without Philip's work, both as the original editor
   and as the Chair of the working group, this document would not have
   been produced.  He also wishes to express deep and heartfelt
   gratitude to the previous editor, Frank Kastenholz.  Frank changed
   the original document from a collection of information to a useful
   description of IP technology - in his words, a "snapshot" of the
   technology in 1991.  One can only hope that this snapshot, of the
   technology in 1994, is as clear.

   Philip Almquist, Jeffrey Burgan, Frank Kastenholz, and Cathy
   Wittbrodt each wrote major chapters of this memo.  Others who made
   major contributions to the document included Bill Barns, Steve
   Deering, Kent England, Jim Forster, Martin Gross, Jeff Honig, Steve
   Knowles, Yoni Malachi, Michael Reilly, and Walt Wimer.

   Additional text came from Andy Malis, Paul Traina, Art Berggreen,
   John Cavanaugh, Ross Callon, John Lekashman, Brian Lloyd, Gary
   Malkin, Milo Medin, John Moy, Craig Partridge, Stephanie Price, Yakov
   Rekhter, Steve Senum, Richard Smith, Frank Solensky, Rich Woundy, and
   others who have been inadvertently overlooked.

   Some of the text in this memo has been (shamelessly) plagiarized from
   earlier documents, most notably RFC-1122 by Bob Braden and the Host

Baker                       Standards Track                   [Page 174]

RFC 1812         Requirements for IP Version 4 Routers         June 1995

   Requirements Working Group, and RFC-1009 by Bob Braden and Jon
   Postel.  The work of these earlier authors is gratefully
   acknowledged.

   Jim Forster was a co-chair of the Router Requirements Working Group
   during its early meetings, and was instrumental in getting the group
   off to a good start.  Jon Postel, Bob Braden, and Walt Prue also
   contributed to the success by providing a wealth of good advice
   before the group's first meeting.  Later on, Phill Gross, Vint Cerf,
   and Noel Chiappa all provided valuable advice and support.

   Mike St.  Johns coordinated the Working Group's interactions with the
   security community, and Frank Kastenholz coordinated the Working
   Group's interactions with the network management area.  Allison
   Mankin and K.K.  Ramakrishnan provided expertise on the issues of
   congestion control and resource allocation.

   Many more people than could possibly be listed or credited here
   participated in the deliberations of the Router Requirements Working
   Group, either through electronic mail or by attending meetings.
   However, the efforts of Ross Callon and Vince Fuller in sorting out
   the difficult issues of route choice and route leaking are especially
   acknowledged.

   The editor thanks his employer, Cisco Systems, for allowing him to
   spend the time necessary to produce the 1994 snapshot.
--- cut her ----

I guess I "crossed the line" with my two-line acks.

P.S.: And no, I'm not "objecting" what *you* wrote in the Acks.

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

---

From: Fernando Gont <[email-masked]>
Date: Sun, 12 Feb 2017 18:10:24 -0300

On 02/11/2017 02:28 PM, Bob Hinden wrote:
> Hi,
> 
> <draft-ietf-6man-default-iids-16.txt> is currently in AUTH48.
> According to the datatracker it has been in the RFC Editor queue for
> 54 days.  Everything is done, except there is an impasse over a
> change to the Acknowledgement Section.  One of the authors has
> proposed adding:
> 
> Some of the other authors don’t think this change is appropriate for
> AUTH48, but the author proposing this has insisted on adding this
> text.

Your description is not quite accurate.

I added this text along with other modifications during AUTH48. Three
out of four co-authors approved the document, and only one co-author
(Alissa Cooper) refused to approve the document unless this text was tossed.

I never "insisted" in adding the text. I added the text, and everyone
else (modulo Alissa) approved the document.

Alissa's rationale was, essentially:

* this make me feel uncomfortable, because I will have to explain why I
didn't add a similar ack for my people

* this will set a precedent in RFCs -- which is not really true. Plenty
of my RFCs have similar notes, and for instance, please take a look at
RFC1812.

I should say that I was quite surprised by Alissa's position on this
(even more when I did 98% of all the edits in the document, and quite a
few times I had to insist on co-authors joining the wg discussions,
since I was the only author involved in them).

Me, I have always tried, to the extent that is possible, to give enough
credit when it's deserved, because I understand that the product of my
work heavily relies on the work, help, and support of other people.

If you look at past RFCs I have co-authored, you will not only find
acknowledgements similar to the ones I added to this document, but will
also find:

* credit to folks that implemented what's being specified in the document.

* explicit credit for ideas that were incorporated based on the findings
of specific individuals

* credits to folks that have provided connectivity or access to systems
that were of use to test things or evaluate things being discussed in a
document

* that folks that provided extremely detailed feedback are singled out
(that's the reason for the fist two separate paragraphs in this RFC).

In the past, there have been cases in which I offered folks to be
incorporated as co-authors because they had provided so much feedback
and proposed text, that crediting them in any of the above ways was
simply unfair. There have been cases, where folks never ended up editing
a document, but since the contents weres so heavily based on
brainstorming that we'd perform routinely, they were among the
co-authors list. There was also at least one case when I asked
the RFC-Ed if I could explicitly credit her for the edits, because her
edits helped so much in improving the document (in that case, she kindly
said "please no, I'm just doing my work).

I'm kind of astonished that people are voicing opinions on this topic
without even asking anything along the lines of "could you explain
what/how they contributed?". It would seem that some people seem to
think that if there's a relationship with the people being Ack'ed (or
the last name is shared), then I should not be allowed to credit them,
which is quite curious (and wrong).

On the other hand, plenty of RFCs have notes (in the Acknowledgements
setion) giving credit e.g. to grants (e.g. "This work was supported by
grant #..."). I don't really understand the basis on which someone
throwing money at some project deserves more credit than other people
providing any other kind of support.

But in any case, the first two people I ack'ed (Nelida Garcia and
Guillermo Gont), did provide funding, too. (In fact, it was thanks to
them that I attended my first IETF meeting). And Guillermo, in
particular, helped me in producing the diffs that were once included in
the document, but later removed.

I understand and respect that people are entitled to have an opinion
regarding anything in life. Now, their ability to just toss
acknowledgents because "I do not support" or "I don't like it" seems
like something else. It doesn't feel right of fair for people to decide
to toss deserved acknowledgements just because "they don't like it".

And since I have seen (in an Acks section) virtually everything from
acknowledging funding organizations and grants to a piece of play by
Shakespeare (in RFC1812), a decision to toss deserved credit simply
seems arbitrary to me.

And yes, it's a shame the extra delay, and particularly, the reason for
it. -- feels even worse for the guy that did virtually all the edits in
the document (me).

I think pretty much everything I have to say on the topic is said above.
So I will not comment further, unless required.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 12 Feb 2017 18:33:28 -0300

> publication, and the myriad other aspects that contribute to making an

I usually ack those, too.

e.g., from RFC5927:
---- cut here ----
   Markus Friedl, Chad Loder, and the author of this document produced
   and tested in OpenBSD [OpenBSD] the first implementation of the
   counter-measure described in Section 7.2.  This first implementation
   helped to test the effectiveness of the ideas introduced in this
   document, and has served as a reference implementation for other
   operating systems.
---- cut here ----

e.g., RFC7217:
---- cut here ----
   Hannes Frederic Sowa produced a reference implementation of this
   specification for the Linux kernel.
---- cut here ----

Clearly, it's at the author's discretion whether to Ack those things.
Me, I think that a reference implementation is so important that it does
deserve credit.

I'd note, too, that many RFCs have credits to funding/grants. I wonder
why who threw money deserves more credit than who implemented a spec, or
who provided support in different ways.

Cheers,

---

From: Sander Steffann <[email-masked]>
Date: Sun, 12 Feb 2017 22:34:29 +0100

Hi Fernando & WG,

> work heavily relies on the work, help, and support of other people.

Just to be clear: while I'm surprised about your acknowledgements, I don't oppose them. If they are important to you as one of the the authors then they deserve to be mentioned. Who am I to judge who deserves to be acknowledged by you?

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Sun, 12 Feb 2017 18:43:58 -0300

On 02/12/2017 06:34 PM, Sander Steffann wrote:
> Hi Fernando & WG,
> 
>> Me, I have always tried, to the extent that is possible, to give
>> enough credit when it's deserved, because I understand that the
>> product of my work heavily relies on the work, help, and support of
>> other people.
> 
> Just to be clear: while I'm surprised about your acknowledgements, I
> don't oppose them. If they are important to you as one of the the
> authors then they deserve to be mentioned. Who am I to judge who
> deserves to be acknowledged by you?

That is exactly the point (What's next, otherwise? "Hey... I don't care
who funded your work, toss it!"? "I don't like that you credit that
guy.. I think he's just your friend..toss it!"?).

Thanks for the comment, and your understanding,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: [email-masked]
Date: Sun, 12 Feb 2017 22:50:14 +0100

Fernando,

[...]

> work heavily relies on the work, help, and support of other people.

I encourage you to read up on the IETF process.
The document is not yours. When a document is adopted by a working group change control is turned over to the working group.

[...]

> said "please no, I'm just doing my work).

The authors serve at the pleasure of the working group chairs.

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Sun, 12 Feb 2017 19:07:44 -0300

> The document is not yours. When a document is adopted by a working group change control is turned over to the working group.

I never challenged that. For instance, what's in the upcoming RFC does
not reflect 100% my view -- of course, it reflects what seemed to be wg
consensus, and I never tried to change that.

It is the first time that I see a "consensus call" on acknowledgements.
That's it.

But certainly, whatever the outcome, I'll respect it.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Feb 2017 11:08:58 +1300

> Is that described in RFC process somewhere?

As I read RFC4844 section 4.4, this sort of general content issue would
clearly be the responsibility of the RFC Editor. As far as I can see,
the RFC Editor's style guide doesn't cover it specifically.

> From RFC7221:

That's about the IETF RFC stream, and making sure that the technical content
has WG and IETF consensus. So IMHO this issue lies entirely outside the question
of WG consensus. The RFC series is not just for the IETF.

Regards
    Brian

---

From: [email-masked]
Date: Sun, 12 Feb 2017 23:21:25 +0100

Brian,

> of WG consensus. The RFC series is not just for the IETF.

This document is on the IETF RFC stream. I am not familiar with this separation between "technical" content and other content.
Where do you have that from?
This doesn't seem to fall within: "...uniform style and content for RFCs across all streams.  This includes, but is not limited to, acceptable
   language, use of references, and copyright rules."

The main concern here is the change during AUTH48, more than the exact change. Why the author chose to add this and has done with many documents at this point in the process is unknown to me. This seems to me to be in conflict with the working group's document ownership and change control. (Of course you can argue that's also problematic when the IESG edits documents without the working group's involvement as well.)

Cheers,
Ole
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Feb 2017 12:00:43 +1300

> Where do you have that from?

It just seems obvious to me that this isn't a question that belongs in the WG process.
It's got nothing to do with the technical content of the document.

> The main concern here is the change during AUTH48, more than the exact change. Why the author chose to add this and has done with many documents at this point in the process is unknown to me. This…

If it was a technical issue, I would of course agree violently. But it's cosmetic,
so why on earth would the WG even care?

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sun, 12 Feb 2017 20:36:04 -0300

On 02/12/2017 07:21 PM, [email-masked] wrote:
> 
> The main concern here is the change during AUTH48, more than the
> exact change. Why the author chose to add this and has done with many
> documents at this point in the process is unknown to me. 

I can comment on this one:

Typically, documents take too much energy, and I don't take care too
much care about details, because documents change all the time. When it
comes to Acknowledgements, the only "acks" that I typically keep up to
date are those regarding folks that sent comments (because otherwise I
forget and then it's a pain to remember or look up their names).

In AUTH48, it's the last chance to read the document, and I do a full
re-read -- at times, it has been a long time since doing a full
review... so for example I get to catch errors or editorial nits that
have been there for a long time -- and that I just didn't find before
because I was just doing patches to the document, rather than full reviews.

When a document is just about to be done, I also think of the people
that provided help beyond the usual reviews, or implementations of the
document that really made a difference, etc.

e.g., in RFC6274 you can find:
--- cut here ---
   The author wishes to thank Alfred Hoenes for providing very thorough
   reviews of earlier versions of this document, thus leading to
   numerous improvements.
[..]
   The author would like to thank Randall Atkinson and Roque Gagliano,
   who generously answered a number of questions.
--- cut here ---

(besides the credits for the usual reviews).

in RFC7872, you can find:
---- cut here ----
   The authors would like to thank Fred Baker for his guidance in
   improving this document.

   Fernando Gont would like to thank Jan Zorz of Go6 Lab
   <http://go6lab.si/> and Jared Mauch of NTT America for providing
   access to systems and networks that were employed to produce some of
   the measurement results presented in this document.  Additionally, he
   would like to thank SixXS <https://www.sixxs.net> for providing IPv6
   connectivity.
---- cut here ----

in RFC7217 you can find:
---- cut here ----

   The algorithm specified in this document has been inspired by Steven
   Bellovin's work ([RFC1948]) in the area of TCP sequence numbers.

[...]

---- cut here ----

In many (if not most/all) of these cases, the acks were added during
AUTH48, when I just got the time to think about the people that had
provided significative help/support.

It never crossed my mind that someone could have concerns with this. As
a guy that reads RFCs, I couldn't care less about the Acks.. could never
have "concerns". So the stage at which these were added was never a
factor -- i.e., not that I thought "oh, let's add these now so that
nobody figures".

My understanding is that the Acks are editorial changes, and not
technical changes, so there was not even a need for the authors to agree
on them.

> This seems
> to me to be in conflict with the working group's document ownership
> and change control. (Of course you can argue that's also problematic
> when the IESG edits documents without the working group's involvement
> as well.)

Not just IESG.

It's quite usual for the RFC Editor to apply *lots* of changes on the
technical content of the document, which at times change the technical
meaning of the document.

Me, I can't believe that someone can object a sentence that says "Gont
would like to thank X for their love and support". -- I even asked if
removing the word "love" would get Alissa's approval, and the answer was
"no". I will obviously respect whatever decision is taken. But that
doesn't make the topic or the objection to the text less ridiculous.

Thanks,

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 13 Feb 2017 01:31:04 +0000

Hi Fernando,
  This was a chance for the other members of the WG (and not the authors) to comment on the change, since the authors could not agree. Several of your comments you made in this thread have been over the line and disrespectful. Please keep the discussion professional, respectful and to the point.

Thanks
Suresh

> On Feb 12, 2017, at 6:36 PM, Fernando Gont <[email-masked]> wrote:
>

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 12 Feb 2017 21:42:42 -0500

Hi,

I had been refraining from commenting on this so that the rest of the WG could have a chance to do so without hearing from the authors, but at this point I feel it’s probably better to represent my own line of thinking on this. Here are the relevant excerpts from my messages to the rest of the authors and document approval chain during AUTH48:

   Message 1:

> I don’t believe thanking family members is an appropriate addition to the Acknowledgments during AUTH48. If this text had been in the document when it was still up for IETF consensus, we could have had a proper discussion with the full community about whether we want to start adding family member acknowledgments to RFCs. But that didn’t happen, so it’s not appropriate to add this text now. I think there is a long-standing precedent that Acknowledgments is a place to recognize people who made technical or editorial contributions or who reviewed the document for technical content or editorial style, or to provide transparency about where authors’ funding comes from if that is not otherwise clear.

   Message 2:

> My main objection to this text is that it was added during AUTH48. Since RFCs are consensus documents of the IETF, I think it’s important for the community to have the opportunity to review the substantive content of the document before it gets approved. I think the content you added is substantive in that it can set a precedent for what gets published in the RFC series going forward. I don’t recall previously seeing a standards track RFC where individuals are acknowledged for their love of the author. If you have examples, please share them.

> 
> If this text had been added prior to the document’s approval, I would have argued during community discussion that it makes me uncomfortable as a co-author to have people thanked in the document for their love. As I said before, I think the scope of acknowledgments is more limited than that, and by having you thank people for their love it raises the question of why I am not doing the same, or conversely it puts the burden on me to have to explain to the people who love me why I am not acknowledging them in this document. That is not a predicament that I care to be in as the author of an RFC. But we didn’t have that discussion with the community because the document is already approved.

Subsequent to sending message 2, I learned that this is at least the 10th document in which Fernando has inserted similar acknowledgment text during AUTH48. Those documents and the associated text are listed at the bottom of this message. The bulk of these documents were single-author documents, so no other IETF participant would have been alerted to the text prior to publication since it was not included in the versions of the documents that were put out for community review. Nor were they all working group documents, as default-iids is. But since to my eye this raises a novel question of editorial style for which the community has not provided guidance to the RFC Editor, I thought it would be important to surface it to the community in some way.

Of course, people in the WG and the community are free to disagree with any of the premises stated above — that this is a substantive change to the document content, that even non-technical content deserves community review, that what gets written in acknowledgments is not precedent-setting, that the existing precedent is what I think it is, etc. But I did not feel comfortable approving the document without having that discussion in the community. It was up to Suresh, Bob, and Ole to decide what to do from there. I will certainly go along with whatever the rough consensus ends up being.

Alissa

   ---

   1) RFC 6528:

   Fernando Gont wishes to thank Jorge Oscar Gont, Nelida Garcia, and
     Guillermo Gont for their love and support

   2) RFC 6633:

   Fernando Gont wishes to thank Jorge Oscar Gont, Nelida Garcia, and
     Guillermo Gont for their love and support.

   3) RFC 6946:

   Finally, the author wishes to thank Nelida Garcia and Guillermo Gont
     for their love and support.

   4) RFC 6980:

   Finally, the author would like to thank his brother, friend, and
     colleague, Guillermo Gont, for his love and support.

   5) RFC 7217:

   Finally, the author wishes to thank Nelida Garcia and Guillermo Gont
     for their love and support.

   6) RFC 7359:

   The author wishes to express deep and heartfelt gratitude to Enrique
     Garcia and Vicenta Tejedo, for their precious love and support.

   7) RFC 7739:

   The author would like to thank Buffy for her love and support.

   8) RFC 7872:

   Fernando Gont would like to thank Nelida Garcia and Guillermo Gont
     for their love and support.

   9) RFC 7943 (independent stream):

   Fernando Gont would like to thank Nelida Garcia and Guillermo Gont
     for their love and support, and Diego Armando Maradona for his magic
     and inspiration.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 13 Feb 2017 02:46:18 +0000

Hi Fernando,

> On Feb 12, 2017, at 5:07 PM, Fernando Gont <[email-masked]> wrote:
> 

To be precise, this is a consensus call on a *text change* in AUTH48 where all the authors did not agree.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 13 Feb 2017 02:53:22 +0000

Hi Fernando,

> a guy that reads RFCs, I couldn't care less about the Acks.

Either you care or you don’t. You cannot have it both ways. If you do not care about the Acks, I am not sure we are having this discussion and taking a chunk of everyone’s time.

> . could never

The fact that you keep forgetting to mention is that the point is not about whether you need to agree with your co-authors on the acknowledgements. It is about all the authors signing off on the changes in AUTH48.

> technical content of the document, which at times change the technical

Yes. And if one of the author’s doesn’t agree and another one cannot live without them, we will be having the same discussion about these changes.

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Feb 2017 01:10:31 -0300

On 02/12/2017 11:53 PM, Suresh Krishnan wrote:
>> 
>> In many (if not most/all) of these cases, the acks were added
>> during AUTH48, when I just got the time to think about the people
>> that had provided significative help/support.
>> 
>> It never crossed my mind that someone could have concerns with
>> this. As a guy that reads RFCs, I couldn't care less about the
>> Acks.
> 
> Either you care or you don’t. You cannot have it both ways. If you do
> not care about the Acks, I am not sure we are having this discussion
> and taking a chunk of everyone’s time.

What I meant is that, when reading an RFC, I don't care about what's in
the Acks. As an author, I try to give credit where I think is deserved.

In this particular case, my impression was that the decision to not
approve the document with the Acks was arbitrary. It was an editorial
change or, as Brian said, just "cosmetics". Given that there does not
seem to be any rules for writing Acknowledgements, and that the change
was editorial, I was puzzled for the author approval of an RFC to be
delayed for that. To be honest, it wasn't even clear to me what the
objection was. That's why I took your option of consulting the wg (if
you let go arbitrary decisions, you don't know where that stops).

Based on this discussion, the lesson that I've learned is that, during
AUTH48, an Acknowledgement cannot be added, unless all authors agree (or
not even, I guess). I'll make sure to put more energy on the
Acknowledgments of documents at an earlier stage next time, so that, if
anything, this discussion happens at such an earlier stage.

Thanks,

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 13 Feb 2017 10:49:18 +0100

Hi,

I don't support the addition. IMHO the Acknowledgment section
should reflect acknowledgments with respect to contributions to
the technical content of that RFC.

Regards,
 Roland

---

From: Sander Steffann <[email-masked]>
Date: Mon, 13 Feb 2017 11:19:23 +0100

Hi Brian,

> It's got nothing to do with the technical content of the document.

I fully agree. The text explicitly starts with "Fernando Gont would like to thank" which makes it clear that this is a personal thing from one of the authors, not something representing working group consensus.

> so why on earth would the WG even care?

I fully agree. The document is a working group document, but Fernando has put a lot of work in it on behalf of this working group. That that same working group is now criticising him for adding an innocent bit of personal text in the acknowledgements doesn't feel right to me. Why would we need consensus on a explicitly personal acknowledgement anyway?

Cheers,
Sander

PS: Random Stream of consciousness: Where has the IETF gone where people worked together to do cool stuff, where April fools RFCs and Shakespeare quotes were appreciated? It feels so hostile at the moment, and that is worrying me. I hope we can all relax a bit, appreciate each other's work and opinions and focus on improving this cool internet thing we have engineered!

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 13 Feb 2017 11:10:28 +0000

Hi Fernando,

> On Feb 12, 2017, at 11:10 PM, Fernando Gont <[email-masked]> wrote:
> 
> AUTH48, an Acknowledgement cannot be added, unless all authors agree

Yes. I think your understanding is correct.

> (or

Yes, please.

Thanks
Suresh

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 13 Feb 2017 15:00:00 +0100

Le 11/02/2017 à 18:28, Bob Hinden a écrit :
> Please respond with either support or non-support for this proposed
> change by 18 February 2017.  I think it is unfortunate to add extra
> delay over this change, but after consulting with our AD, I think
> the best course is to ask the working group.

I do not support this, because it's late.

But I will ask whether some goal-line comm technology involves IPv6? 
And whether genealogy "DOI-like" references exist?

Alex

>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: 神明達哉 <[email-masked]>
Date: Mon, 13 Feb 2017 10:14:36 -0800

> the best course is to ask the working group.

Regarding this particular inquiry, I generally agree with Brian:
neither of the following seems to be something that the wg should
bother in the first place:
- whether the added text is appropriate for RFCs
- whether making this particular change to this particular document at
  AUTH48 is acceptable

But, the following point made me think it may be a bit subtler than my
initial and general observation:

At Sun, 12 Feb 2017 21:42:42 -0500,
Alissa Cooper <[email-masked]> wrote:

>> Subsequent to sending message 2, I learned that this is at least the
>> 10th document in which Fernando has inserted similar acknowledgment
>> text during AUTH48.

If this is true (I didn't check it myself), I think it's reasonable to
ask whether the author doesn't exploit the AUTH48 stage to add some
specific text with avoiding possible discussions on the text at the wg
or with the IESG.  Even if the text itself is minor or even considered
not part of the wg/IETF business, an attitude that might look like
hiding a secret motivation from the process wouldn't be appreciated,
as it might make those authors look less trustworthy in general.  In
that sense, I think it's fair to say the text in question should have
been in drafts while they were discussed in the wg.

Again, for this particular case, I don't think I'm a right person to
say support or non-support.

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Tue, 21 Feb 2017 11:43:31 -0800

Hi,

I went through the responses to the call regarding <draft-ietf-6man-default-iids-16.txt> .  The question in the email was:

    Please respond with either support or non-support for this proposed change by
    18 February 2017.  I think it is unfortunate to add extra delay over this
    change, but after consulting with our AD, I think the best course is to ask the
    working group.

My summary of the responses is:

Fred Baker                 non-support
Lorenzo Colitti            non-support
Enno Rey                   support
t.pech                     non-support
Brian Carpenter            Doesn’t think it’s a w.g. decision
Joel Halpern               non-support
Sander Steffan             support
Roland Bless               non-support
Alexandre Petrescu         non-support
神明達哉                    Didn’t indicate a position

By my count there is 6 non-support and 2 in support of the acknowledgement paragraph (not counting the response from the authors Fernando and Alissa).

Based on this, Suresh should notify the RFC Editor to remove the acknowledgement paragraph.

Bob

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 21 Feb 2017 20:44:28 +0000

> On Feb 21, 2017, at 2:43 PM, Bob Hinden <[email-masked]> wrote:
> 
> Hi,
> 

Thanks Bob. Will let the RFC Editor know and proceed with publication.

Regards
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Feb 2017 21:23:39 -0300

> Thanks Bob. Will let the RFC Editor know and proceed with publication.

Just out of curiosity:

Is a statement like "I do not support" *without any rationale* of value?

And, are statements like "I do not support this, because we only do X in
the 'Acnkowledgements' section" of any value, when it should be obvious
to anyone that RFCs have contained virtually *anything*? -- please check
the "Acknowledgements" section of RFC1812 for an example, but there are
many others.

I ask because, essentially, folks that have argued against the
Acknowledgement I added fall into one of these two camps: no rationale
for objecting (other than "I do not support", "too late") or claiming
that Acks follow "guidelines" that evidence shows that it's not true.

As noted, I will go with whatever the wg decides. But I'm curious about
the above.

Thanks,

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Feb 2017 17:25:55 -0800

> Is a statement like "I do not support" *without any rationale* of value?

I think it's a fact. People, myself among them, said they didn't support it. The discussion, or at least most of it, was public.

I'll repeat my rationale. If one is filing an individual submission, and especially one through the independent stream, I suppose one can say in it pretty much what one wants. If we're discussing a working group draft, we are documenting the consensus of a working group. I don't recall the working group reviewing an acknowledgement of the members of a family or a particular Argentine athlete (Diego Maradona); that text came in without review or consensus during AUTH48. Further, if one reviews the ~8000 RFCs that have already made it through the mill, none come to mind that contain such an acknowledgement. The people acknowledged in RFCs are people who commented on or otherwise made some contribution to the document.

Speaking for myself, I think the acknowledgement is out of place in a working group product, especially if there is no obvious consensus supporting it. Bob ran a poll, and reports the consensus as he perceives it. As working group chair he is empowered to determine what that consensus is. From my perspective, his report on that is the end of the discussion, not a data point in the middle of it, nor the start of a new one. That's his job, and the power we give him.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Feb 2017 23:03:36 -0300

On 02/21/2017 10:25 PM, Fred Baker wrote:
> I think it's a fact. People, myself among them, said they didn't
> support it. The discussion, or at least most of it, was public.
> 
> I'll repeat my rationale. If one is filing an individual submission,
> and especially one through the independent stream, I suppose one can
> say in it pretty much what one wants. If we're discussing a working
> group draft, we are documenting the consensus of a working group. I
> don't recall the working group reviewing an acknowledgement of the
> members of a family

So, may I ask: what's the basis for assessing that?  Are you a family
member of every "Baker" out there?  And, besides, does that mean that if
you have a family member that happens to work in the same industry,
you're not allowed to Ack him/her?

Did anyone bother to ask, e.g., what was the rationale for adding the
acknowledgement I added?  Tell you what: two of the people that you
guessworked as my family members have funded my work. In fact, they even
funded the first IETF meeting I attended, at a time in which I was
unemployed.

> or a particular Argentine athlete (Diego
> Maradona); that text came in without review or consensus during
> AUTH48. Further, if one reviews the ~8000 RFCs that have already made
> it through the mill, none come to mind that contain such an
> acknowledgement. The people acknowledged in RFCs are people who
> commented on or otherwise made some contribution to the document.

Nobody bothered to ask what the ack was about. For instance, I noted
during AUTH48 (before this was made public) that two of the people I was
acking provided funding. -- and I've seen plenty of funding acks in
RFCs. (should I have said "money" or "funding" instead of "support"?
Would that have been acceptable?). -- and please note, I offered to
remove the (concerning, it seems) word "love", but that didn't make any
difference.

Besides, as I noted before, RFC1812 includes an excerpt from *a
Shakespeare's play* in the "Acknowledgements" section. Is that supposed
to be more "in place" than the text I added?

Bottom-line: I'm kind of surprised about this discussion. I don't know
when the Acks section of an RFC became a substantive part of a spec that
the wg cares about. That said, I've AUTH48-approved the document without
the Ack.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Iván Arce <[email-masked]>
Date: Wed, 22 Feb 2017 02:03:33 -0300

Hello

Since when personal acknowledgements require WG consensus?
What are the guidelines or IETF procedures that regulate what an
author can or cannot put in the Acknowledgement section?

I've looked for answers to those questions and found none.

"Guidelines for RFC authors"[1] certainly says nothing about it.

The "How to write an RFC" tutorial[2] given at several IETF meetings
says nothing specific about the Acknowledgements section of RFCs.
However, it does say a few things about what the RFC Editor does edit:

   * At least, for correct syntax and punctuation.
   * Ideally, to improve clarity, consistency, and quality
      of the prose.
   * To maintain consistent format and style.
     - Using the format and style that many, many years of
       experience have been found to work well.

 and:

   The RFC Editor checks many things
     * Header format and content
     * Title format
     * Abstract length and format
     * Table of Contents
     * Required sections are present
     * No uncaught IANA actions
     * Spell check
     * ABNF/MIB/XML passes mechanical checker
     * Citations match references
     * Most recent RFC/I-D cited
     * Pure ASCII, max 72 char lines, hyphens, etc.
     * Headers and footer
     * Remove “widows”
     * References split into Normative, Informative
     * Boilerplate

Note that there are very specific things mentioned in the above list but
NOT the acknowledgements section of an RFC.

Furthermore, regarding AUTH48 the tutorial says:

   * Last-minute editorial changes allowed – But should not be
     technically substantive or too extensive.
     Else, must get OK from AD, WG chair.

It is very clear that the addition of a paragraph to the
Acknowledgements section cannot be considered "technically substantive"
nor "too extensive" and therefore "OK from AD and/or WG chair" should
not be required.

But the tutorial isn't normative, so in search for normative text I
found RFC 7322 "RFC Style Guide" [3] which is just Informational but
does cover the Acknowledgements Section in 4.10:

   4.10.  Acknowledgements Section

   This optional section may be used instead of, or in addition to, a
   Contributors section.  It is often used by authors to publicly thank
   those who have provided feedback regarding a document and to note any
   documents from which text was borrowed.

Which notes what the section is often used for but does not indicate nor
limit what it could be used for. It does not preclude acknowledging
family members or not acknowledging anyone but simply adding portions of
a Shakespeare play, biblical citations or food recipees.

One could seriously wonder the motives of an author that adds portions
of a Shakespeare play or a food recipe to the Acknowledgements section
of an RFC at or before AUTH48, but lobbying to have the RFC Editor
strike down those paragraphs seems like excessive zeal, particularly if
there is no existing normative for it.

Basic common sense would indicate that the Acknowledgements section of
an RFC is certainly one in which the WG, the AD and the RFC Editor could
be quite "liberal in what they accept".

Perhaps there is precedent for this case? I've read/lurked in IETF
mailing lists for more 15 years and cannot recall one, but then again I
am not terribly mindful of what is normally debated in them. If anybody
does remember similar cases in the past I'd be curious to learn about
them, off or on list.

I think the paragraphs I quoted above from several sources are quite
lenient and certainly much more ambiguous about whats acceptable than
RFC 2460 is about the insertion of Extension Headers by intermediate nodes.

And yet this is an actual thread in the 6man mailing list.

Until now I've been following this "discussion" in the mailing lists in
amazement, I could not fathom how or why the just.appointed IETF chair,
who also happens to be co-author of the document, could possibly think
that questioning the addition of a single paragraph in the
acknowledgements section of an RFC made sense or was necessary action,
and how AD or WG could possibly think this should be open for a public
discussion.

Although I've known Fernando Gont for several years, occasionally
collaborated with him, and known the personal and cultural context in
which those mentions were made, I choose not to engage in this thread
because I thought it was ridiculous but after reading several follow up
emails I felt necessary to express my opinion

To be clear: This whole discussion is not about any technical changes
whatsoever, it is about a section for which, as far as I know, there are
no normative directions or procedures for content.

Just questioning the author motives for adding acknowledgements to his
relatives and putting him in the position of having to justify them is,
by itself, a bit insulting. This may be shocking to many in the list
that aren't familiar with the idiosyncrasies and culture of our country
-as Fernando, I was born and live in Argentina- but in Argentina as in
many other developing countries, family plays an important role in
supporting one's career and not just in an abstract manner but with very
tangible economic contributions.

On the other hand, the characterization of Diego Armando Maradona merely
as an athlete or a football player is also lacking but not surprising.
You see, it is extremely difficult to explain the multi-faceted figure
of Maradona and his cultural influence in our country during  the past
40 years. In Argentina, he is certainly an athlete, a former football
player, the greatest in our sports history but also a father, a son, a
recovering addict, a national hero, a national villain, a rebel, a kid
from the slums that made it out of poverty by virtue and discipline, a
leader, a football coach, a business man, a pop philosopher and several
other things. He is unequivocally an inspiring figure to many, not
unlike Muhammad Ali, the boxer, or Usain Bolt, the runner...but I digress
.
In summary, I believe that nitpicking on the Acknowledgments section of
an RFC while allowing for traditions like the April 1st RFCs or being
much more flexible on the actual technical contents of several drafts
and standards does not set a good precedent here.  If this is really
considered an actual issue for discussion, I'd like to suggest an
alternative solution:

Simply let the acknowledgments stand and initiate work on an RFC that
would either update or replace RFC 7322 with normative guidance.

Baring that, I sincerely hope the RFC Editor brings back the sanity and
common sense that I find lacking in this whole affair.

sincerely,

-ivan

[1] https://www.ietf.org/id-info/guidelines.html
[2] https://www.ietf.org/proceedings/62/slides/editor-0.pdf
[3] https://www.rfc-editor.org/rfc/rfc7322.txt

El 21/2/17 a las 22:25, Fred Baker escribió:
> members of a family or a particular Argentine athlete (Diego
> Speaking for myself, I think the acknowledgement is out of place in a
> working group product, especially if there is no obvious consensus
> supporting it. Bob ran a poll, and reports the consensus as he
> perceives it. As working group chair he is empowered to determine
> what that consensus is. From my perspective, his report on that is
> the end of the discussion, not a data point in the middle of it, nor
> the start of a new one. That's his job, and the power we give him. 

-- 
Iván Arce
Director del Programa STIC
Fundación Dr. Manuel Sadosky
http://www.fundacionsadosky.org.ar
TE: (+54-11) 4328-5164
GPG fingerprint: 4D97 3003 76C9 9DA4 7209  7982 0A1D 10BE CEA9 1B6E

---

From: [email-masked]
Date: Wed, 22 Feb 2017 08:49:59 +0100 (CET)

> and how AD or WG could possibly think this should be open for a public

I have to agree. This whole discussion seems utterly unnecessary, not
to mention silly. The acknowledgement should be allowed, end of story.

> and standards does not set a good precedent here.

Fully agreed.

> If this is really

Agreed.

Steinar Haug, AS2116

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 22 Feb 2017 11:53:34 +0100

Hi Fernando,

For my part, I think there may be a risk of too much binding of personal
matters to professional matters.  In some cases, distinct values could
be leveraged more if separated, in other cases if converged.  That too 
are facets of privacy :-)

Alex

Le 22/02/2017 à 01:23, Fernando Gont a écrit :
>>> I went through the responses to the call regarding
>>> <draft-ietf-6man-default-iids-16.txt> .  The question in the
>>> email was:
>>>
>>> Please respond with either support or non-support for this
>>> proposed change by 18 February 2017.  I think it is unfortunate
>>> to add extra delay over this change, but after consulting with
>>> our AD, I think the best course is to ask the working group.
>>>
>>> Fred Baker                 non-support Lorenzo Colitti
>>> non-support Enno Rey                   support t.pech
>>> non-support Brian Carpenter            Doesn’t think it’s a w.g.
>>> decision Joel Halpern               non-support Sander Steffan
>>> support Roland Bless               non-support Alexandre Petrescu
>>> non-support 神明達哉                    Didn’t indicate a position
>>>
>>> By my count there is 6 non-support and 2 in support of the
>>> acknowledgement paragraph (not counting the response from the
>>> authors Fernando and Alissa).
>>>
> And, are statements like "I do not support this, because we only do X
> in the 'Acnkowledgements' section" of any value, when it should be
> obvious to anyone that RFCs have contained virtually *anything*? --
> please check the "Acknowledgements" section of RFC1812 for an
> example, but there are many others.
>
> Acknowledgement I added fall into one of these two camps: no
> rationale for objecting (other than "I do not support", "too late")
> or claiming that Acks follow "guidelines" that evidence shows that
> it's not true.
>
> As noted, I will go with whatever the wg decides. But I'm curious
> about the above.
>
> Thanks,
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Feb 2017 21:34:53 +0900

> I've looked for answers to those questions and found none.

I suspect we'll find that the reasons we don't have answers yet is because
this has never been a problem before. Now that it has been, we may end up
creating more process to prevent it. Sic transit gloria mundi :-)

FWIW, I opposed the proposed change because it is very clearly out of line
with the intention of the AUTH48 state.
https://www.rfc-editor.org/pubprocess/#auth48 says the authors are given
"to look over their document for errors".

Personally, every time I have been a document author I have strived to make
as few changes in AUTH48 as possible, because I felt that changing too much
was tantamount to abusing the trust of the working group and of the IETF in
whose names the document is published. The magic words are:

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.

I think acknowledgements to Diego Armando Maradona, your favourite deity,
sponsors, or the tooth fairy are all fine - as long as they are legitimate
expressions of WG consensus. Even if from a process perspective there is no
further WG stage beyond AUTH48, we as authors should always remember that
the documents are not ours, they're the WGs and the IETF's.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Feb 2017 16:01:35 +0000

Hi Iván,
  I would like to clarify a few things here 

a) It is not about the text, it is about the timing. This was done in AUTH48 where all the authors need to approve the changes.

b) Your comments about RFC1812 and April 1st RFCs are not relevant here because they are not equivalent.

RFC1812: The draft that became RFC1812 contained the Shakespeare text when it went through the WG process. Please see

https://tools.ietf.org/html/draft-ietf-rreq-cidr-02

April 1st RFCs: These are not IETF stream RFCs. They are published at the discretion of the RFC Editor.

"  This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment. “

For more information about the streams and differences between them, please take a look at RFC4844 Section 5. Basically, the IETF has very little say on what goes through the Independent Stream (other than checking for conflicts).

c) The reason you don’t find authoritative guidance for everything is because we either have not seen the situation before or it does not happen frequently enough to warrant making up process for it. Checking with the WG was a common sense decision for a WG document. The only other solution that would have been fair is to let the document sit around in AUTH48 until the authors converged. This was not a realistic option for me since I am holding another document (RFC-to-be-8065) due to a reference to this document. So, if you think that you have a fair and expedient solution that is different, please feel free to propose it. I am all for learning and improving.

Thanks
Suresh

> On Feb 22, 2017, at 12:03 AM, Iván Arce <[email-masked]> wrote:
> 
> Hello
>

---

From: Iván Arce <[email-masked]>
Date: Wed, 22 Feb 2017 18:05:14 -0300

Hi Suresh

Thanks for your clarifications, I've commented them below

El 22/2/17 a las 13:01, Suresh Krishnan escribió:
> Hi Iván, I would like to clarify a few things here
> 
> a) It is not about the text, it is about the timing. This was done in
> AUTH48 where all the authors need to approve the changes.

I beg to differ. I believe this is both about the timing AND about the
content.

Had the acknowledgments been to an IETF elder of the tribe, a regular of
the 6man mailing list or some random university or government
organization I seriously doubt anybody would have objected them. To me
at least, it is evident that what triggered the objection was not the
timing but the content of the acknowledgements.

In any case, even if it wasn't about it, the fact that the "not
technically substantive" content was quoted verbatim in the call for
support/not support *made it* about the content and not about the
timing. The message below seem to be about the text not the timing:

  "Some of the other authors don’t think this change is appropriate
   for  AUTH48, but the author proposing this has insisted on adding
   this text.
   Please respond with either support or non-support for this proposed
   change by 18 February 2017."

With regards to the timing, I agree that according to all existing data
I've found, including the documents I cited, all authors need to approve
changes in AUTH48. But it is also truth that the document that describes
AUTH48 also says that the document should get OK from the AD, WG chair
IF the changes introduced in AUTH48 are "technically substantive" or
"too extensive".

That condition is not met here.

The matter has been exposed to a process that is not stated anywhere and
that, in my opinion, was unnecessary, discretionary and wrong.

Unnecessary because it could have been addressed directly by the RFC
editor with or without the authors involvement.

Discretionary because, and we seem to agree on this, there was no
previously stated procedure to follow in a case like this and the case
was handle in an ad hoc fashion.

And wrong because, in my opinion of course, setting precedent of seeking
WG consensus for striking down (or not) text in the Acknowledgements
section of an RFC signals an overly zealous stance on a technically
irrelevant matter.

> here because they are not equivalent.

Indeed, they are not equivalent but that does not make them irrelevant.
You just chose to dismiss the comments on the basis of a lack of
equivalence.  My intention was to point out that there is a tradition of
being lenient, joyful and flexible on certain content. But hey, its
okay, I am not planning to engage in a contest of nitpickery over this.

> c) The reason you don’t find authoritative guidance for everything is
> because we either have not seen the situation before or it does not
> happen frequently enough to warrant making up process for it.

I wasn't looking authoritative guidance for everything, I was looking
authoritative guidance *specifically* for this. You are confirming that
there is none and that this is quite an infrequent situation. It would
have been great if somebody could recollect a similar situation that
could be used for comparison or guidance.

> Checking with the WG was a common sense decision for a WG document.

There is nothing of common sense in checking with the WG about not
"technically substantive" nor "too extensive" changes.

Come on, these were an author's personal acknowledgements. You can
rationalize this as much as you want, I am not going be to convinced and
we can all live with that.

> The only other solution that would have been fair is to let the
> document sit around in AUTH48 until the authors converged. This was
> not a realistic option for me since I am holding another document
> (RFC-to-be-8065) due to a reference to this document. So, if you
> think that you have a fair and expedient solution that is different,
> please feel free to propose it. I am all for learning and improving.

I have already proposed it

Be flexible, be liberal in what you accept, let the text stand on this
one, publish it as is, take note for the future, provide future guidance
to authors.

If you want to codify what the Acknowledgements section should say or
what changes added in AUTH48 that aren't "technically substantive" nor
"too extensive" require AD or WG approval when authors don't converge on
the final text...

write a draft :)

Frankly I don't have much more to say about this topic, I've already
posted one message more than I originally intended. this one is the last
one.

thanks for your time

regards,

-ivan

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 08:04:26 +0900

> that, in my opinion, was unnecessary, discretionary and wrong.

Please bear in mind that the majority of the people that posted on this
thread disagree with you on that matter. If they agreed with you, then they
would have supported the change.