Skip to main content

Last Call Review of draft-ietf-dime-4over6-provisioning-03
review-ietf-dime-4over6-provisioning-03-genart-lc-housley-2015-07-12-00

Request Review of draft-ietf-dime-4over6-provisioning
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-07-20
Requested 2015-07-09
Authors Cathy Zhou , Tom Taylor , Qiong Sun , Mohamed Boucadair
I-D last updated 2015-07-12
Completed reviews Genart Last Call review of -03 by Russ Housley (diff)
Opsdir Last Call review of -03 by Tim Chown (diff)
Assignment Reviewer Russ Housley
State Completed
Request Last Call review on draft-ietf-dime-4over6-provisioning by General Area Review Team (Gen-ART) Assigned
Reviewed revision 03 (document currently at 06)
Result Almost ready
Completed 2015-07-12
review-ietf-dime-4over6-provisioning-03-genart-lc-housley-2015-07-12-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>.

This review is in response to a request for early Gen-ART review.

Document: draft-ietf-dime-4over6-provisioning-03
Reviewer: Russ Housley
Review Date: 2015-07-12
IETF LC End Date: 2015-07-20
IESG Telechat date: unknown

Summary: Almost Ready

Major Concerns:

None


Minor Concerns:

In section 2.4, please replace "the MAP-E document" with a reference to
[I-D.ietf-softwire-map].

The Security Considerations section talks about two concerns: (1)
man-in-the-middle modification of the AVP contents leading to
misconfiguration, and (2) disclosure of subscriber addresses allowing
the attacker to track subscriber activity.  If I have understood
these properly, the second one is more of a privacy consideration.
Please consider moving this to a separate section on privacy
considerations.

Returning to the first part of the security considerations, please say
more about the possible consequences of a man-in-the-middle making
modifications to the AVP contents.  Is there anything that the
implementer can do to make the attack more difficult to accomplish
or raise the likelihood of detection?


Other Comments:

Section 2.6 begins this way: "It appears that two items are common to
the different transition methods and the corresponding AVPs to carry
them can be reused...".  By the time this document achieves consensus
and it is ready to be published as an RFC, there is no longer a need
for such a soft touch.  I suggest: "There are two items that are common
to the different transition methods, and the corresponding AVPs to carry
them can be reused..."

Section 3.3 says:

   64-Multicast-Attributes AVP MUST include at least the ASM-mPrefix64
   AVP or the SSM-mPrefix64 AVP.

   Both the ASM-mPrefix64 AVP and the SSM-mPrefix64 AVP MAY be present.

Would it be more clear to say it this way?

   64-Multicast-Attributes AVP MUST include the ASM-mPrefix64 AVP or the
   SSM-mPrefix64 AVP, and it MAY include both.

Please provide labels for Figures 5, 6, and 7.  Based on the other figures,
they should probably be:
	- Figure 5: LW4over6-Binding AVP
	- Figure 6: MAP-E-Attributes AVP
	- Figure 7: MAP-Mapping-Rule AVP