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

Suresh Krishnan <> Mon, 13 February 2017 02:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70F4F1295A8 for <>; Sun, 12 Feb 2017 18:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OfW9T3nzUPsi for <>; Sun, 12 Feb 2017 18:53:53 -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 25BBA1295A3 for <>; Sun, 12 Feb 2017 18:53:53 -0800 (PST)
X-AuditID: c6180641-c53ff70000000a06-e9-58a0d96bbfaa
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8C.38.02566.B69D0A85; Sun, 12 Feb 2017 22:53:49 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Sun, 12 Feb 2017 21:53:39 -0500
From: Suresh Krishnan <>
To: Fernando Gont <>
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/mxaFmDj8AgAAXF4CAAB6aAIAAA3qAgAAU2wCAADcjAA==
Date: Mon, 13 Feb 2017 02:53:22 +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=_442E97E2-6D4A-4CD9-8ACA-F4282606BA6A"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyuXSPn27uzQURBvt71CzaLu5jsniy6g2b xcuz75ksJretYHNg8Th47COjx85Zd9k9liz5yeTx4VAPewBLFJdNSmpOZllqkb5dAlfGjnf/ mAreBlQsPfecrYHxk3sXIyeHhICJxIzTfxm7GLk4hATWM0ps/XydESQhJLCcUeLUbhUQmw2o aMPOz0wgtoiApsTc50eAbA4OZoECiZkPFUDCwgJuEntX7maDKHGX2PrzMVR5mMTuOZPA4iwC qhL/v89kBrF5Bewl1iy7ALX3JJNEx56L7CAJTgFniWV9vWA2o4CYxPdTa8AGMQuIS9x6Mp8J 4mgRiYcXT7NB2KISLx//Y4WwlSQ+/p7PDjKUWWAKo8SZ/reMENsEJU7OfMIygVFkFpJZs5DV zUJSB1GkLbFs4WtmCFtTYn/3cqi4qcTrox8ZIWxriRm/DrJB2IoSU7ofsi9g5FjFyFFaXJCT m25kuIkRGIHHJNgcdzDu7fU8xCjAwajEw2vosCBCiDWxrLgy9xCjClDrow2rLzBKseTl56Uq ifCGii6MEOJNSaysSi3Kjy8qzUktPsQozcGiJM57PeR+uJBAemJJanZqakFqEUyWiYNTqoFx 0YS3TQesTT09Lob/sZYoV1iU6FG6YGrKYvnqgr6khLyyg2+PnEibXJ7sffn0QsHk5wYL8koC gq6vjp/HMetC2wPDa+q3fsyS0hBtLfCPqGXz3caj/iSC43/jvz37/wkf4Zi+nEvO5YdNxF+h 9snLi8VEuLr/TpjutEVkf76SpV/knfpJxW5KLMUZiYZazEXFiQCiYAk+yAIAAA==
Archived-At: <>
Cc: 6man WG <>
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: Mon, 13 Feb 2017 02:53:54 -0000

Hi Fernando,

> On Feb 12, 2017, at 6:36 PM, Fernando Gont <> wrote:
> On 02/12/2017 07:21 PM, 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
>   <> 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 <> 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.
> [...]
>   Hannes Frederic Sowa produced a reference implementation of this
>   specification for the Linux kernel.
> ---- 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.

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

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.

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

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.