APPSDIR review of draft-vegoda-cotton-rfc5735bis-02

S Moonesamy <> Sun, 03 June 2012 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53CB621F864E; Sun, 3 Jun 2012 03:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.48
X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lq7Woxy0P-zn; Sun, 3 Jun 2012 03:36:26 -0700 (PDT)
Received: from ( [IPv6:2001:470:f329:1::1]) by (Postfix) with ESMTP id 8760021F864C; Sun, 3 Jun 2012 03:36:26 -0700 (PDT)
Received: from ([]) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id q53AaABq014765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jun 2012 03:36:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail2010; t=1338719782;; bh=y9PVa/WtjvsS3hSnTEaXN+g8/pjUlEFRkSATR57t5T4=; h=Date:To:From:Subject:Cc; b=l0AV58x7rFeX5jP+R4hr8C5DJXK8iV7Ji7jwop+OTvONezJB0fzEr30NvBtV6wlge TOPWo01aqsf20xPmscuwNMfARchmdlpAmQGvLd617ZX3OWCzsKRSjyD5Q+3NWGAbh1 pXtnqn8Dkp8iwiwegYK0NzW2h/P8SdVxowElMxdE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1338719782;; bh=y9PVa/WtjvsS3hSnTEaXN+g8/pjUlEFRkSATR57t5T4=; h=Date:To:From:Subject:Cc; b=V5Y2kbRlB3w1jrLWmFAJ7sWm6S7aHeemcjqcd5uz0pfGB8cbkmvKoSX8+bVWVFEau Zi1bhBcFiYdUFIIvjXpxbiM6+jSg23F5gsaydbpKtVUmyfHIGey9TBjvfptIiN3ABO vsm8d9wfGPF7isQJ1CvpeVj1iZc7jatF1DMaTPQ0=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Sun, 03 Jun 2012 03:18:10 -0700
From: S Moonesamy <>
Subject: APPSDIR review of draft-vegoda-cotton-rfc5735bis-02
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Mailman-Approved-At: Mon, 04 Jun 2012 08:23:35 -0700
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Jun 2012 10:36:28 -0000

I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on APPSDIR, please see ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft.  The review 
is not copied to the IESG as the Last Call has not been announced yet.

Document: draft-vegoda-cotton-rfc5735bis-02
Title: Special Use IPv4 Addresses
Reviewer: S. Moonesamy
Review Date: June 3, 2012

Summary: This document is almost ready for publication as a BCP.

The draft describes the global and other specialized IPv4 address 
blocks that have been assigned by IANA.  It is an update of RFC 5735 
to include the Shared IPv4 address space which was assigned about the 
publication of RFC 5735.  The proposal does not have any impact on 
Application-related protocols.

Major issues: None

Minor issues:

In Section 1:

   "Section 4 of this document describes that assignment process."

Section 4 contains a summary table without any assignment process 
description.  Where is the assignment process described?

In Section 5:

   "The domain name and IP address spaces involve policy issues (in
    addition to technical issues) so that the requirements of [RFC2860]
    do not apply generally to those spaces."

The wording is different from what is in RFC 2860.

   "Immediately before the RFC is published, the IANA will, in
    consultation with the Regional Internet Registries, make the
    necessary assignment and notify the RFC Editor of the particulars
    for inclusion in the RFC as published."

There is no mention of "Regional Internet Registries" in RFC 2860.

I suggest dropping Section 5 as according to Abstract this draft is 
about documenting Special Use IPv4 addresses.

In Section 7:

   "Security policy SHOULD NOT blindly filter all of these address spaces
    without due consideration, and network operators are encouraged to
    review this document, and references contained therein, and determine
    what security policies should be associated with each of these address
    blocks within their specific operating environments."

The recommendation is not clear.  The recommendation seems more 
appropriate for network operators instead of "Security policy" as 
they have the awareness to make such decisions.

Given the recommendation about due consideration and reviewing all 
the references, these references would have to be normative.  It is 
easier to remove the RFC 2119 boilerplate and use a "should not" to 
reduce the amount of required reading.


Why does this draft update RFC 6441?

S. Moonesamy