Skip to main content

Last Call Review of draft-ietf-6man-stable-privacy-addresses-06
review-ietf-6man-stable-privacy-addresses-06-genart-lc-campbell-2013-04-25-00

Request Review of draft-ietf-6man-stable-privacy-addresses
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-04-26
Requested 2013-04-17
Authors Fernando Gont
I-D last updated 2013-04-25
Completed reviews Genart Last Call review of -06 by Ben Campbell (diff)
Genart Last Call review of -16 by Ben Campbell (diff)
Secdir Last Call review of -14 by Vincent Roca (diff)
Opsdir Last Call review of -16 by Tim Chown (diff)
Assignment Reviewer Ben Campbell
State Completed
Request Last Call review on draft-ietf-6man-stable-privacy-addresses by General Area Review Team (Gen-ART) Assigned
Reviewed revision 06 (document currently at 17)
Result Almost ready
Completed 2013-04-25
review-ietf-6man-stable-privacy-addresses-06-genart-lc-campbell-2013-04-25-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-stable-privacy-addresses-06

Reviewer: Ben Campbell
Review Date: 2013-04-25
IETF LC End Date: 2013-04-16

Summary: This draft is almost ready for publication as a proposed standard.
There are a few minor issues which should be considered first, described in the
review.

Major issues:

None.

Minor issues:

-- section 3, third paragraph from end:

The paragraph suggests that changing the number of network interfaces should be
rare. I think it's quite common in practice for the sorts of hosts likely to
move between subnets regularly. For example, my Macbook Pro uses an external
(Thunderbolt attached) ethernet interface which regularly gets disconnected and
reconnected. Same might hold true for a USB attached wireless modem. And I have
any number of VPNs which may be active or not at any given time.

-- section 3, 2nd paragraph from end:

You describe the affects of including Network_ID in some detail. It would be
helpful to note the consequences of _not_ including it.

Nits/editorial comments:

-- section 1, 4th paragraph: "Therefore, it is vital..."

That seems a bit overstated. We're not talking about breaking the Internet
here, are we?

-- 1, 6th paragraph: "Also, they result in increased complexity..."

What sort of complexity? Implementation complexity? It's a bit confusion
because the previous sentences already talk about increased complexity of
specific sorts. It would help to mention what sort of additional complexity is
referred to here.

-- 1, paragraph 11: "This document does not update..."

How is adding an alternative algorithm _not_ an update?

--1, paragraph 12: "... may already address"

Is the "already addressing" part in question? Or is it a matter of addressing
it in some circumstances, but not others? If the latter, it would help to
elaborate.

-- 6, last paragraph: "... may mitigate..."

Not sure? Or only under some circumstances?

-- references:
 RFC1948 is obsoleted by 6528. Is there a reason to reference the obsolete
 version?