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

Suresh Krishnan <suresh.krishnan@ericsson.com> Mon, 13 February 2017 02:53 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F4F1295A8 for <ipv6@ietfa.amsl.com>; Sun, 12 Feb 2017 18:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfW9T3nzUPsi for <ipv6@ietfa.amsl.com>; Sun, 12 Feb 2017 18:53:53 -0800 (PST)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BBA1295A3 for <ipv6@ietf.org>; Sun, 12 Feb 2017 18:53:53 -0800 (PST)
X-AuditID: c6180641-c53ff70000000a06-e9-58a0d96bbfaa
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id 8C.38.02566.B69D0A85; Sun, 12 Feb 2017 22:53:49 +0100 (CET)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0319.002; Sun, 12 Feb 2017 21:53:39 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Fernando Gont <fgont@si6networks.com>
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: <E44F0815-B800-4D09-93AE-D38B8480C220@ericsson.com>
References: <C9FDAEB9-9F79-4186-9C48-5F44E5E07235@gmail.com> <1be095d0-8165-b127-9dbb-5a9d06d7d141@gmail.com> <3F1A2F45-CD1D-4E66-85E7-CC331A78A160@employees.org> <5ff7c3e2-c450-ded4-d68b-e73d0b416364@gmail.com> <95381DDF-9261-4EC9-9626-DB6F9F494729@employees.org> <b886b05d-4c52-5b26-6295-f5a9251175b2@si6networks.com>
In-Reply-To: <b886b05d-4c52-5b26-6295-f5a9251175b2@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
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: <https://mailarchive.ietf.org/arch/msg/ipv6/eXNvNRJkyyC4ozCtz8tcO6fdf0I>
Cc: 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=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 <fgont@si6networks.com> wrote:
> 
> On 02/12/2017 07:21 PM, otroan@employees.org 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.
> 
> [...]
> 
>   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.

Thanks
Suresh