Re: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48 Wed, 22 February 2017 07:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73A90129541 for <>; Tue, 21 Feb 2017 23:50:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ju4mFplwidm9 for <>; Tue, 21 Feb 2017 23:50:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 51122129480 for <>; Tue, 21 Feb 2017 23:50:01 -0800 (PST)
Received: from localhost ( [IPv6:2001:8c0:9e04:500::1]) by (Postfix) with ESMTP id 4BECEE6065; Wed, 22 Feb 2017 08:49:59 +0100 (CET)
Date: Wed, 22 Feb 2017 08:49:59 +0100 (CET)
Message-Id: <>
Subject: Re: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <>
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: Wed, 22 Feb 2017 07:50:03 -0000

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

I have to agree. This whole discussion seems utterly unnecessary, not
to mention silly. The acknowledgement should be allowed, end of story.

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

Fully agreed.

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


Steinar Haug, AS2116