Gen-ART LC Review of draft-ietf-6man-rfc3484bis-05

Ben Campbell <ben@nostrum.com> Thu, 14 June 2012 21:58 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9200F11E8080; Thu, 14 Jun 2012 14:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsveMV+FzJQ1; Thu, 14 Jun 2012 14:58:47 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B930F21F84AC; Thu, 14 Jun 2012 14:58:47 -0700 (PDT)
Received: from frankenstein.test.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q5ELwk8X082296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jun 2012 16:58:47 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Subject: Gen-ART LC Review of draft-ietf-6man-rfc3484bis-05
Date: Thu, 14 Jun 2012 16:58:46 -0500
Message-Id: <C8476C40-FE78-4712-B76A-88C324715579@nostrum.com>
To: draft-ietf-6man-rfc3484bis.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, The IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jun 2012 21:58:48 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-6man-rfc3484bis-05
Reviewer: Ben Campbell	
Review Date: 2012-06-14
IETF LC End Date: 2012-06-15

Summary: This draft is almost ready for publication as a proposed standard. I have one security consideration question that should be addressed first. I also have some editorial comments that might be worth addressing if there is a revision prior to publication.

Note: As always, reviewing a "bis" draft is difficult for someone who has not been involved in its creation, as one may comment on issues inherited from the original RFC that were not in scope to be fixed in a particular "bis" draft. Apologies in advance if I run afoul of such things.

Major issues:

None


Minor issues:

-- security considerations, 1st paragraph: "This document has no direct impact on Internet infrastructure security."

Can source and/or destination address selection could influence whether data is sent over and encrypted path? In particularly true since section 7 allows the address selection to influence interface selection? If so, it's worth mentioning the fact, and considering whether an encrypted path vs unencrypted path should be considered in the selection rules. Perhaps such decisions should be made prior to following the rules in this draft--but if so it would be helpful to explicitly say that.

Nits/editorial comments:

-- section 3/5, last paragraph: "Whether or not an address is designated a home address or care-of address is outside the scope of this document."

This sentence is confusing since the previous sentence indicated that "... it is sufficient to know whether or not one’s own addresses are designated as home addresses or care-of addresses." Is the point that the _mechanism_ for making that designation is out of scope, even though one needs to know the _results_? Or is this a question about talking about one's own addresses vs the destination addresses?

-- section 4, third paragraph: (starting with "Discussion: ..."

I tend to expect indented paragraphs like this to be parenthetical notes. The "discussion" label reinforces this. It seems like normative statements don't belong in such paragraphs. Can this be promoted to a normal paragraph? (Note that this occurs in several other "discussion" paragraphs as well.)

-- section 4. last paragraph:

Please expand SIIT on first mention.

-- section 5, general:

It would be helpful to define SA, SB prior to use. ( I note that the destination section does this for DA and DB.)

-- section 5, last paragraph:

Since this talks about Rule 2, perhaps it should be moved to immediately after rule 2?

-- section 6, discussion paragraph after Rule 7:

Please expand 6RD and ISATAP on first mention.

-- section 10.6, first paragraph:

Please expand ULAs on first mention.



--