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: Iván Arce <iarce@fundacionsadosky.org.ar>
Organization: Fundación 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
- Status of <draft-ietf-6man-default-iids-16.txt> i… Bob Hinden
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fred Baker
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fred Baker
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Sander Steffann
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Lorenzo Colitti
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Enno Rey
- Re: Status of <draft-ietf-6man-default-iids-16.tx… t.petch
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Brian E Carpenter
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Joel M. Halpern
- Re: Status of <draft-ietf-6man-default-iids-16.tx… otroan
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fernando Gont
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fernando Gont
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fernando Gont
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Sander Steffann
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fernando Gont
- Re: Status of <draft-ietf-6man-default-iids-16.tx… otroan
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fernando Gont
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Brian E Carpenter
- Re: Status of <draft-ietf-6man-default-iids-16.tx… otroan
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Brian E Carpenter
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fernando Gont
- Be professional and respectful (was Re: Status of… Suresh Krishnan
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Alissa Cooper
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Suresh Krishnan
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Suresh Krishnan
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fernando Gont
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Bless, Roland (TM)
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Sander Steffann
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Suresh Krishnan
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Alexandre Petrescu
- Re: Status of <draft-ietf-6man-default-iids-16.tx… 神明達哉
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Bob Hinden
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Suresh Krishnan
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fernando Gont
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fred Baker
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Fernando Gont
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Iván Arce
- Re: Status of <draft-ietf-6man-default-iids-16.tx… sthaug
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Alexandre Petrescu
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Lorenzo Colitti
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Suresh Krishnan
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Iván Arce
- Re: Status of <draft-ietf-6man-default-iids-16.tx… Lorenzo Colitti