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

Brian E Carpenter <> Sun, 12 February 2017 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1DB712942F for <>; Sun, 12 Feb 2017 14:09:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 LQBTNUtLJpWc for <>; Sun, 12 Feb 2017 14:09:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 607DB128BA2 for <>; Sun, 12 Feb 2017 14:09:03 -0800 (PST)
Received: by with SMTP id v184so7927491pgv.1 for <>; Sun, 12 Feb 2017 14:09:03 -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=ZKUA3kxsXMAxqYvnVLfpGZgT9516d+8nISN3nGR3sEg=; b=XY8fNpyMD9L59NZZoSHpchn5ZqTFrTildedSyTrJ2KjSC9adtfsl5y/xffoSnyGJ4r vcW+sEvC8aU0W8Kdzrge4hXnp2TedxvDkEU4F9pqrlH+xwYYPw8OAUZXMfADpWeH6YhT Co0YQxVJeG5jlX1bd+Mz7rHFNwkhQLPgF+TKY+0TYZTaVRYjME2l68r4tzcp+CCFsUPM 7CR/Vo7eJVMhbzfKzwPNTmkzU5ZhmSHBmst6/R209bTz6oNtJSUfFSwp9+a61r3odZc0 o5Dt7ypk/oR8kC18ieqlOaYkMFky9+fz1957fHhVMqO0eJVeEOqiTdTFUVlbyI54a9/J MyAQ==
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=ZKUA3kxsXMAxqYvnVLfpGZgT9516d+8nISN3nGR3sEg=; b=MgzhwtHumjX0NwcKA8FZxfZ1O5awfewBsV3exatxba1I5kegHktU0s36sx4Q4yCIWl AftcdBxNj9cHek+IlQFlO06TrPUP4dIn7R9vYtfNspWfpxNzYBLwCAH+1PcnJ4Eg/88V 0JbuEjt5yetWXy4NBL+V45FgE2uWaWTSdg+Hl2JgLj4iZ4z2O/yR2Qt4exXXC12XgGUH 9Dya9M2/uQ2xzAiSwx8Jm1GqwzaRymWoSriXW+fx3nxGBeeXpy8vjoSDLnxOVbVyiXdP UzrynAntBKVtuDXtFWS7/PMIap/ZeAD9EO2Uw4B1Impgs+hM0iJeZs9Yj5iisSU6ONUl VwFg==
X-Gm-Message-State: AMke39li0oQ4pbTDWtn83q4bz5ebf2uhSfSbI/QQioj7SJIFq+6SK7Bv1AbBKixijU/RlQ==
X-Received: by with SMTP id 62mr12983532pgj.22.1486937342755; Sun, 12 Feb 2017 14:09:02 -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 b67sm16627046pfj.81.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Feb 2017 14:09:02 -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 11:08:58 +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 22:09:05 -0000

On 13/02/2017 09:19, 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.