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

Brian E Carpenter <> Sun, 12 February 2017 23:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C879A12943A for <>; Sun, 12 Feb 2017 15:00:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OKODejERC4Z6 for <>; Sun, 12 Feb 2017 15:00:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40ACC126BF6 for <>; Sun, 12 Feb 2017 15:00:49 -0800 (PST)
Received: by with SMTP id 19so6111285pfo.3 for <>; Sun, 12 Feb 2017 15:00:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tuVm+7Xqq2WYRTzjIy8R8MBI9v/2GofKGJOy5a22qfw=; b=oKBaSZ2RM1RtdLYM7FpO/dAdFz/P/sc87JqwgrYtYYSf4vOdA16P95FPD/hpOl9klq iLasocnMyfBVLcioz8h74Mc+SzmrWVxrg9L1laLXgr5MXc3GpIyUHeGuRmtZC8lSN/l2 w5SCl1P8qDPf4iPVrQ86AaOGS5W9wT5tr/YUzl5oy/rS9dpwBeAiuiaOWK6NSGuCf/uK Bod/L40jYiASvy3z/39LIQEmx+E5tfG/njxJIkFJB8BU6p4dMtUMs58h7/YLTLom2ZDb YGsIK3WJSQjeIWQM9bhktaAj+y0DJ2nSW6kB4N8VlwAHpphvWvDVH99U9D325wibAoio Qm0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=tuVm+7Xqq2WYRTzjIy8R8MBI9v/2GofKGJOy5a22qfw=; b=HsM3v5870OkqGxWi67nIO8mrNWQRJvDFLsjQSqjiik1j0CX+88YVbWsaSyghXP9yIr scVnEc6xjss7ENmJn4fGWoNjus/qle0PR+af/SmSrAWoNTDaZX/gYr/cVQR3IwibpEYv 6iJ54JWfT/WmSCIG27+gWbKlCWsKnHRXnrqoRjZUBnb7N25lf2H+EFP4S5r5/LF1BS9C 2y6nMdwLrn2QVaJOQPmU6O0AcuguDKlu3SGhYor+DSoSiO7Nor0R/Vck68Yi2GYTb7U7 KENLPE9xCZWftPiYSadWZ+owGPNSdBIunUjSvwspah4b+Dv17QhlF7YXgjEepVF7sIdB OAkw==
X-Gm-Message-State: AMke39lTvAMtTUAMam+38qwx58AmtNQC92g5uCNuQ/7XnIXaIaV3z92fs7KydGbs10B6jw==
X-Received: by with SMTP id f29mr5953033plj.10.1486940448572; Sun, 12 Feb 2017 15:00:48 -0800 (PST)
Received: from ?IPv6:2406:e007:6e60:1:28cc:dc4c:9703:6781? ([2406:e007:6e60:1:28cc:dc4c:9703:6781]) by with ESMTPSA id c64sm16711090pfa.45.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Feb 2017 15:00:48 -0800 (PST)
Subject: Re: Status of <draft-ietf-6man-default-iids-16.txt> in AUTH48
References: <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Mon, 13 Feb 2017 12:00:43 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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 23:00:51 -0000

On 13/02/2017 11:21, wrote:
> Brian,
>>>> 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?

It just seems obvious to me that this isn't a question that belongs in the WG process.
It's got nothing to do with the technical content of the document.

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

If it was a technical issue, I would of course agree violently. But it's cosmetic,
so why on earth would the WG even care?