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

Suresh Krishnan <> Wed, 22 February 2017 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 255E0129A41 for <>; Wed, 22 Feb 2017 08:01:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OGJY33IMGuMe for <>; Wed, 22 Feb 2017 08:01:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48C45129A40 for <>; Wed, 22 Feb 2017 08:01:38 -0800 (PST)
X-AuditID: c618062d-14208980000009d8-f1-58adc62860bc
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 80.42.02520.826CDA85; Wed, 22 Feb 2017 18:11:04 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Wed, 22 Feb 2017 11:01:35 -0500
From: Suresh Krishnan <>
To: =?utf-8?B?SXbDoW4gQXJjZQ==?= <>
Subject: Re: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48
Thread-Topic: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48
Thread-Index: AQHShIxiJjS77zK8rE2q/EsZxi/mxaF0QEiAgAARBoCAAD0+gIAAEWaAgAA8zoCAALfZAA==
Date: Wed, 22 Feb 2017 16:01:35 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_413206B7-91EA-4ACB-91EE-C72D5013B2AE"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyuXSPt67GsbURBo/O6Fhsfb+PzeLJqjds Fre/NrBa3H62hs3i5dn3TA6sHo+7VzF57Jx1l91jyZKfTB4fDvWwB7BEcdmkpOZklqUW6dsl cGXcXf+OpWBmJ2NF3+61zA2My0u7GDk5JARMJFr+TmfqYuTiEBJYzyix8PoXNghnOaNEzw+Q DCcHG1DVhp2fwWwRAQeJrqaV7CBFzAKTGSVe31zJCpIQFnCT2LtyNxtEkbvE1p+PoRrCJL5d 2QBWwyKgKrGv+x1YDa+AvcStM9fZQWwhgUtMEl+nK4DYnALeEqvfHgWrZxQQk/h+ag3YHGYB cYlbT+YzQZwtIvHw4mk2CFtU4uXjf6wQtpLEx9/zoY6bwijRvHQLC8QyQYmTM5+wTGAUmYVk 1ixkdbOQ1EEUaUssW/iaGcLWlNjfvRwqbirx+uhHRgjbWmLGr4NsELaixJTuh+wLGDlWMXKU Fhfk5KYbGWxiBEbkMQk23R2M96d7HmIU4GBU4uE16FsTIcSaWFZcmXuIUQWo9dGG1RcYpVjy 8vNSlUR4/y9eGyHEm5JYWZValB9fVJqTWnyIUZqDRUmcN271/XAhgfTEktTs1NSC1CKYLBMH p1QDo9liHa+NMoucNuikBU3avrZlH2t/6lFtv5SwCdZf5gWeL171aF+br6zcuUd+k9Qy9gZ9 XP510idRVxu3SrlLsTXtKuc332dVV5k7TV6ion9xfasRN9dN7593+2LWnI9ZpXS09WQXk0PR z0xl6aiNk2NnObKu17Z4xtliWvPN6rX3qb0lnmvmKrEUZyQaajEXFScCAN6DICfQAgAA
Archived-At: <>
Cc: Fernando Gont <>, 6man WG <>, Robert Hinden <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Feb 2017 16:01:41 -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

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.


> On Feb 22, 2017, at 12:03 AM, Iván Arce <> wrote:
> 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]
> [2]
> [3]
> El 21/2/17 a las 22:25, Fred Baker escribió:
>> On Feb 21, 2017, at 4:23 PM, Fernando Gont <>
>> wrote:
>>> 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. 
>> -------------------------------------------------------------------- 
>> IETF IPv6 working group mailing list Administrative
>> Requests: 
>> --------------------------------------------------------------------
> -- 
> Iván Arce
> Director del Programa STIC
> Fundación Dr. Manuel Sadosky
> TE: (+54-11) 4328-5164
> GPG fingerprint: 4D97 3003 76C9 9DA4 7209  7982 0A1D 10BE CEA9 1B6E