Skip to main content

Last Call Review of draft-ietf-6man-rfc3484bis-
review-ietf-6man-rfc3484bis-genart-lc-campbell-2012-06-19-00

Request Review of draft-ietf-6man-rfc3484bis
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-06-15
Requested 2012-06-07
Authors Dave Thaler , Richard P. Draves , Arifumi Matsumoto , Tim Chown
I-D last updated 2012-06-19
Completed reviews Genart Last Call review of -?? by Ben Campbell
Genart Telechat review of -?? by Ben Campbell
Assignment Reviewer Ben Campbell
State Completed
Request Last Call review on draft-ietf-6man-rfc3484bis by General Area Review Team (Gen-ART) Assigned
Completed 2012-06-19
review-ietf-6man-rfc3484bis-genart-lc-campbell-2012-06-19-00
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.

--