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

Iván Arce <iarce@fundacionsadosky.org.ar> Wed, 22 February 2017 05:03 UTC

Return-Path: <iarce@fundacionsadosky.org.ar>
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 AC48B1295D6 for <ipv6@ietfa.amsl.com>; Tue, 21 Feb 2017 21:03:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fundacionsadosky.org.ar
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 E7GKEVLWxVaF for <ipv6@ietfa.amsl.com>; Tue, 21 Feb 2017 21:03:38 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CAE1295CA for <ipv6@ietf.org>; Tue, 21 Feb 2017 21:03:38 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id s186so514471qkb.1 for <ipv6@ietf.org>; Tue, 21 Feb 2017 21:03:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fundacionsadosky.org.ar; s=google; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RuYMmx0kcsWHBRlzhLAiSTvKM1c4fjwtyU0hKwfB/yE=; b=RDJi9riukdCAoUFcnFTTNNNIX+iDbr8Ma2QLs6DkUAgCBNw/5T1OhNP6h8FDWOzbl1 b+7Erp+NhAhVJKREIrEkUJO4ANF/IaTFq08CyRVlW42aMjFsf461jF4mWacwa9izO6E4 qdyI0Qr40gLJW+80M32KIZBs1gWqkTfeP/L1A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=RuYMmx0kcsWHBRlzhLAiSTvKM1c4fjwtyU0hKwfB/yE=; b=OooCroVO6hgXsB3vVk0EPe2c5qdux524FTyPTlhXefwLqcF3nUuxGfRgH0/+6SY3fk dpx3jMbT7dFJFxZohShMzPN5yfxhl7v8+L7rEBFwNInTEb6i8yKoC+BCWHBP1krOejfV c813vv1pi4WewiHrg/hYCPa9paNUabpd8hSQ02bAXLEIUCV39wLXRGhi0oSk/51dNAqQ YC/N3/ITtfncMnAWO96cpfY9foD30Ny0Kr+TeR6CNZWNyg8owh1B5IW5rdwItkNMRcek QwLT/94ldeb5J37nXC33pZPO1PH41UwfjggALRRRv8Bm+9J6iNl5VdKiQz85DYnePxL2 QzFg==
X-Gm-Message-State: AMke39nMTaXc943T+/dqTNpQ1sJ3MVdTPolzgBwyW6MtuAXSg5XkIu7nPs/4xzQ7/+HNKQ==
X-Received: by 10.55.74.19 with SMTP id x19mr14691298qka.155.1487739816879; Tue, 21 Feb 2017 21:03:36 -0800 (PST)
Received: from [192.168.100.103] ([186.158.218.178]) by smtp.googlemail.com with ESMTPSA id o9sm83483qtg.7.2017.02.21.21.03.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 21:03:36 -0800 (PST)
Subject: Re: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48
To: Fred Baker <fredbaker.ietf@gmail.com>, Fernando Gont <fgont@si6networks.com>
References: <C9FDAEB9-9F79-4186-9C48-5F44E5E07235@gmail.com> <E580FFBB-7A17-4B48-92CC-E95BB9887743@gmail.com> <5F61B219-A2C2-471E-9DB0-3B604D101317@ericsson.com> <c5e05727-f05f-b451-0066-9dcffd65d231@si6networks.com> <31594A30-7A2B-4F3E-9F18-F890DE50BFCF@gmail.com>
From: =?UTF-8?Q?Iv=c3=a1n_Arce?= <iarce@fundacionsadosky.org.ar>
Organization: =?UTF-8?Q?Fundaci=c3=b3n_Dr._Manuel_Sadosky?=
Message-ID: <edae0117-0dee-92a0-6ec9-60a2e17a2012@fundacionsadosky.org.ar>
Date: Wed, 22 Feb 2017 02:03:33 -0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 Lightning/4.7.7
MIME-Version: 1.0
In-Reply-To: <31594A30-7A2B-4F3E-9F18-F890DE50BFCF@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Cdsb_tkK3g6E-r7CwQgvTHqqUSE>
Cc: Robert Hinden <bob.hinden@gmail.com>, 6man WG <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
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: Wed, 22 Feb 2017 05:03:40 -0000

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ó:
> 
> On Feb 21, 2017, at 4:23 PM, Fernando Gont <fgont@si6networks.com>
> 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 ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 


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