Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Sep 2014 14:00:34 +1300

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-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.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 Sep 2014 21:19:52 -0400

Hm.   I am a bit puzzled.   These are DHCP options.   This document just says what the format of the options is.   Do you really think the DHCP server implementor needs to understand that in order to follow this document?   I see the MAP and lw4over6 documents as depending on this one, rather than vice versa.   IOW, the pointers you're saying are normative are actually back-references to the documents that normatively reference _this_ document.

Aside from that, I have no argument with the points you've raised; hopefully the authors will address them.   Thanks for the timely and thorough review!

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 Sep 2014 21:22:02 -0400

On Sep 28, 2014, at 9:19 PM, Ted Lemon <[email-masked]> wrote:
> Do you really think the DHCP server implementor needs to understand that in order to follow this document?

Er, by "that" here I was referring to the meaning of the MAP bits.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Sep 2014 15:24:16 +1300

On 29/09/2014 14:19, Ted Lemon wrote:
> Hm.   I am a bit puzzled.   These are DHCP options.   This document just says what the format of the options is.   Do you really think the DHCP server implementor needs to understand that in order to follow this document?

I was thinking of the client side. I could be wrong though. It depends on
how the client side is implemented, I guess: it could just be a DHCPv6
engine that is blind to the content of the options, which it passes
on to the softwire code.

    Brian

> I see the MAP and lw4over6 documents as depending on this one, rather than vice versa.   IOW, the pointers you're saying are normative are actually back-references to the documents that normatively reference _this_ document.
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 Sep 2014 22:33:04 -0400

> engine that is blind to the content of the options, which it passes

Whether or not there is a special hack in the DHCP client, from the perspective of writing the standard it is simply a protocol engine that implements the spec, which I think can be done without reference to MAP or lw4over6.   It shouldn't matter from the perspective of this draft whether the DHCP client and A+P tunneling/mapping agent are implemented as a monolithic hunk of code or as two distinct and logically separate agents.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 1 Oct 2014 02:29:15 +0000

Hi Brian,
   Thanks for the review. I will follow up with the authors on this. I 
had a concern about the author list as well and I recorded it in the 
Shepherd writeup. The number of authors is high because the document is 
a merge of competing documents and we felt that going with the long 
author list is a better alternative than sending out separate documents 
with mostly redundant option definitions. In my reading of RFC7322, it 
is the IESG's call (as the stream-approving body) to see if this is 
acceptable? Am I reading it right?

Regards
Suresh

On 09/28/2014 09:00 PM, Brian E Carpenter wrote:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
>