[RTG-DIR] RtgDir review: draft-bchv-rfc6890bis-04

Dan Frost <frost@mm.st> Mon, 06 March 2017 10:21 UTC

Return-Path: <frost@mm.st>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 89B11129430; Mon, 6 Mar 2017 02:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mm.st header.b=MkK738kR; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=L8Ej0iat
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9rMdU1Dkp5Q2; Mon, 6 Mar 2017 02:21:54 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22365129482; Mon, 6 Mar 2017 02:21:54 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 19B8C20983; Mon, 6 Mar 2017 05:21:53 -0500 (EST)
Received: from web5 ([]) by compute6.internal (MEProxy); Mon, 06 Mar 2017 05:21:53 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=mm.st; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=pC6W2i4oKXeIztCxXZAO2FodAqA=; b=MkK738kR56emg2HzJFXV0 Jb3TfB/zQAl8lMnis1TtJXv0Z13pUWz4FdkTj7wqcGBIEpzdWIQmTcppb1l+7DNp XWV7a5s+CaVFEQBFhy5bxfF+0EL73nin8wDAQw9/585NVbHjVD2KUDvTSJCZVu+O WadsdRQK0lb2ZPRL7nKCFE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=smtpout; bh=pC6W2i4oKXeIztCxXZAO2FodA qA=; b=L8Ej0iatkn2w7wBti8bIdJu5b8/JfwpK6D3KDEGnRUb1WR/mtm/zWwIl1 cFw2HtQdl1ZV+TpzqzWFPRGvP/6igGCKaR0jsn7YR5V6GN9BCAH87HAXPFskikEw 6ASA1th3B/yCTO7jRAhHgS1iUUMOKIOvYvrTIoWem6a1sgAlNY=
X-ME-Sender: <xms:QTi9WJ2Aipbbl5dpYJ-vZiwFfWSaIX2RLBDYA4VNeI2YjBSoKoIiFg>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id E311A6AC15; Mon, 6 Mar 2017 05:21:52 -0500 (EST)
Message-Id: <1488795712.121267.901697504.1EDD2548@webmail.messagingengine.com>
From: Dan Frost <frost@mm.st>
To: draft-bchv-rfc6890bis@ietf.org, rtg-ads@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-9f47d516
Date: Mon, 06 Mar 2017 10:21:52 +0000
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/o0wVKmUiLodDQbcaDPeRQ0hLpFM>
Cc: rtg-dir@ietf.org
Subject: [RTG-DIR] RtgDir review: draft-bchv-rfc6890bis-04
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Mar 2017 10:21:55 -0000


I have been selected as the Routing Directorate reviewer for this draft.
 The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see

Although these comments are primarily for the use of the Routing ADs, it
 would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document:  draft-bchv-rfc6890bis-04
 Reviewer: Dan Frost
 Review Date: 2017-03-06
 IETF LC End Date: 2017-03-10
 Intended Status: Best Current Practices


I have some minor concerns about this document that I think should be
resolved before publication.


This draft aims to update the guidelines governing special-purpose IPv4
and IPv6 address block registrations (things like link-local, localhost,
and RFC1918 private-addressing) provided by RFC 6890.

Overall the draft is in good shape and the content is clear. However,
there are some structural issues that, while not critical, would make
the document easier to understand if addressed.

Major Issues:

No major issues found.

Minor Issues:

The main issue I found when reading the document is that it's not
obvious whether this is intended to be read as a patch on top of RFC
6890 or as a replacement for it. Since it proposes to obsolete RFC 6890,
presumably it's the latter. But in some ways it reads more like a patch.

More specifically, the abstract and introductory text focuses more on
the patch aspect (the clarification of the "global" field), and in so
doing, drops the overall context and v4/v6 balance of RFC 6890. The
abstract, for instance, only mentions v6.

If the authors do intend for this draft to replace RFC 6890, I think it
would substantially improve readability to frame this document first and
foremost as a complete reference on special-purpose address block
registration, and to single out the "global" clarification issue in its
own section.

Moreover, the manner in which this draft addresses the "global" issue is
also not obvious. Specifically, it doesn't explicitly call out  the
precise changes it makes over RFC 6890. The introduction states that it
"augments the fields contained within the registries in order to address
the confusion raised by the definition of "global"." What does this mean
exactly? As far as I can tell, the only change it makes is renaming the
field from "Global" to "Globally Reachable".

In sum, my recommendation would be to (1) frame the document as a
reference on special-purpose registration generally; (2) detail the
"global" issue in its own section; and (3) be explicit in that section
about the changes made over RFC 6890 and how they resolve the issue.


The IPv6 Special-Purpose Address Registry URL listed at the beginning of
Section 3.2 has a typo("www,iana.org" with a comma after the www).