Re: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48 Sun, 12 February 2017 22:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD786128BA2 for <>; Sun, 12 Feb 2017 14:21:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7f5Ilck9ao-p for <>; Sun, 12 Feb 2017 14:21:29 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id 13F37126BF6 for <>; Sun, 12 Feb 2017 14:21:28 -0800 (PST)
Received: from ([]) by with ESMTP; 12 Feb 2017 22:21:28 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 71AE4D788B; Sun, 12 Feb 2017 14:21:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=nIRvpmSLu1WaBQs2nFIg3RmdlOQ=; b= aquh7QwXj4MI7RVkR58vvSy/hzEC0RzEd//ZdExypoOqnSYCIiMpKx4G3+ZzZXSN /7424y7B/DuIxA9lVNUuEksJUDYSWQD1rjwGb8lOVocqJRVcZtHL6HUUKatwRcKf qWDP78ZvIf5Y0FzoXIRL2y/qZ6UBGYTf5DYMDury6vU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=W6DQstCyCimUeX2ZqlitvwP 6Du1SaIT/Q1Dvy96Iee8Xv3u3LE6ZN+cdsj1sECghvwynqecGrG2tr1rFqgEpWsm chWYjweWA8WWqAc4JzDLj0zPfBeRqZarRHtExVO7PLye6OTFPEeI5Dr2TT30yI4x oTQEGWBwVLrib1W9EJoI=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id 4503BD788A; Sun, 12 Feb 2017 14:21:28 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id BCBF7899DFF5; Sun, 12 Feb 2017 23:21:26 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_ECA13F81-6FE9-45EB-AF12-EDC3D00FE24D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48
Date: Sun, 12 Feb 2017 23:21:25 +0100
In-Reply-To: <>
To: Brian E Carpenter <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: 6man WG <>
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: Sun, 12 Feb 2017 22:21:31 -0000


>>> I don't think this is a WG matter and I don't think it's the IETF's business
>>> either. It seems to me that this matter is in the scope of the RFC Editor to
>>> decide, if the authors can't, since it's about the style and contents of an RFC.
>>> IMHO, it has nothing to do with its technical content or with the fact that
>>> it's an IETF stream document.
>> What makes you think that?
>> Is that described in RFC process somewhere?
> As I read RFC4844 section 4.4, this sort of general content issue would
> clearly be the responsibility of the RFC Editor. As far as I can see,
> the RFC Editor's style guide doesn't cover it specifically.
>> From RFC7221:
> That's about the IETF RFC stream, and making sure that the technical content
> has WG and IETF consensus. So IMHO this issue lies entirely outside the question
> of WG consensus. The RFC series is not just for the IETF.

This document is on the IETF RFC stream. I am not familiar with this separation between "technical" content and other content.
Where do you have that from?
This doesn't seem to fall within: "...uniform style and content for RFCs across all streams.  This includes, but is not limited to, acceptable
   language, use of references, and copyright rules."

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