Skip to main content

Last Call Review of draft-ietf-softwire-map-dhcp-08

Request Review of draft-ietf-softwire-map-dhcp
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-10-10
Requested 2014-09-27
Authors Tomek Mrugalski , Ole Trøan , Ian Farrer , Simon Perreault , Wojciech Dec , Congxiao Bao , Leaf Yeh , Xiaohong Deng
Draft last updated 2014-09-29
Completed reviews Genart Last Call review of -08 by Brian E. Carpenter (diff)
Genart Last Call review of -09 by Brian E. Carpenter (diff)
Opsdir Telechat review of -09 by Benoît Claise (diff)
Assignment Reviewer Brian E. Carpenter
State Completed
Review review-ietf-softwire-map-dhcp-08-genart-lc-carpenter-2014-09-29
Reviewed revision 08 (document currently at 12)
Result On the Right Track
Completed 2014-09-29
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

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

Document: draft-ietf-softwire-map-dhcp-08.txt
Reviewer: Brian Carpenter
Review Date: 2014-10-29
IETF LC End Date: 2014-10-10
IESG Telechat date:

Summary:  On the right track

Major Issues:

[I-D.ietf-softwire-map], [I-D.ietf-softwire-map-t] and [I-D.ietf-softwire-lw4over6]
are listed as Informative references. I find it hard to see how an implementer can
implement the DHCPv6 options without consulting those documents, so IMHO they
need to be Normative references.

For example, in section 4.5 we find

>  See [I-D.ietf-softwire-map], Section 5.1 for a description of MAP
>  algorithm, explaining all of the parameters in detail.

I have the same concern for [I-D.ietf-softwire-unified-cpe] when I see

> [I-D.ietf-softwire-unified-cpe]
>  describes client behaviour for the prioritization and handling of
>  multiple mechanisms simultaneously.

I don't see an implementer can develop a generic client without consulting that
document too.

In section 4.1:

> Clients MUST NOT send an OPTION_S46_RULE option.

What happens if they do?

>  o  F-Flag: 1 bit field that specifies whether the rule is to be used
>     for forwarding (FMR).  If set, this rule is used as a FMR, if not
>     set this rule is a BMR.  Note: A BMR rule can also be an FMR rule
>     by setting the F flag.  The BMR rule is determined by a match of
>     the Rule-IPv6-prefix against the CPE's prefix(es).

The logic of the third sentence is so strange that I can't deconstruct it.
Maybe it just means "An FMR can also be used as a BMR." If so, please just say
it. If not, I'm baffled.

Also, in the last sentence, is that an exact match or a longest match?

Are the CPE's prefix(es) the one(s) it uses for its own address(es)
or the ones it can delegate to the customer network?

(I suspect this paragraph is one of the cases that requires the drafts
mentioned above to be normative references. As written, it is virtually
impossible to understand.)

In section 4.5:

There are two references to "the softwire node". Does that mean the CE?
In fact, I think you need some scoping text in the Introduction. I assume that
"DHCPv6 client", "CE", "CPE" and "the softwire node" all mean the same thing;
if so, please be consistent on terminology.  I also assume that these DHCPv6
options must only be used by a DHCPv6 client which is also a C(P)E and
a softwire node. It would be nice to know that from the start.

Minor issues:

To avoid a long discussion with the RFC Editor about the number of authors,
please consider having one author tagged as Editor and the rest as a list of
Contributors, as described in RFC 7322.