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

Fernando Gont <fgont@si6networks.com> Sun, 12 February 2017 23:36 UTC

Return-Path: <fgont@si6networks.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 3A848129436 for <ipv6@ietfa.amsl.com>; Sun, 12 Feb 2017 15:36:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 6-SVZOtY9Y3i for <ipv6@ietfa.amsl.com>; Sun, 12 Feb 2017 15:36:40 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FBA1293FE for <ipv6@ietf.org>; Sun, 12 Feb 2017 15:36:39 -0800 (PST)
Received: from [IPv6:2001:1291:200:42e::2] (cl-1071.udi-01.br.sixxs.net [IPv6:2001:1291:200:42e::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 755FE81DC6; Mon, 13 Feb 2017 00:36:35 +0100 (CET)
Subject: Re: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48
To: otroan@employees.org, Brian E Carpenter <brian.e.carpenter@gmail.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>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <b886b05d-4c52-5b26-6295-f5a9251175b2@si6networks.com>
Date: Sun, 12 Feb 2017 20:36:04 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <95381DDF-9261-4EC9-9626-DB6F9F494729@employees.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mNF4cT6KBG1lmixYHTtFZ2jdENo>
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: Sun, 12 Feb 2017 23:36:42 -0000

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.. 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,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492