DHCPv6 Prefix Delegation for Network Mobility (NEMO)
draft-ietf-mext-nemo-pd-07

[Ballot comment]
There are a bunch of places where references are not given as citations.

s/RFC3775bis/[I-D.ietf-mext-rfc3775bis]/
s/RFC 3315/[RFC3315]/
s/RFC 3633/[RFC3633]/

---

Nit: Section 3.1

Suddenly you use "Delegating Router"

---

Nit:

MIPv6, HoA, and CoA are used without explanation.

BU is used without explanation (you can fix this a couple of lines
earlier)

---

Section 7. I love the use of RFC 2119 language :-)

[Ballot discuss]
I think the Abstract and, in particular, the Introduction need a little
work. Neither of them says what this document is, what it contains, or
why I should read it. The Introduction, which is no more than the
Abstract with citations should also set some scenery. Probably a couple
of paragraphs from section 3?

---

According to Section 2, [I-D.ietf-mext-rfc3775bis] and [RFC4885] are
normative references.

---

Section 3.3

s/must/MUST/ ?

---

Section 4

  While the MR
  is away from home, the IPsec security mechanism mandated by MIPv6
  MUST be used to secure the DHCPv6 signaling.

I think this needs a reference to the MIPv6 document that mandates IPsec

[Ballot comment]
in 3.3 paragraph 2 sentence, should "DHCPv6" be "DHCPv6PD"?  Current sentence is:

        However, an HA may choose not to respond to the Solicit
  messages from the MR because the HA does not provide DHCPv6.

In section 4 paragraph 3 theer is some awkward wording. Suggestion:

OLD
  We use the same format than that used by of [RFC4877].
NEW
  We use the same format used by [RFC4877].

Some other editorial issues were identified in Donald Eastlake's secdir review:

Section 3.1, page 5, "...currently used by the is about to expire..."
? perhaps "...by the Mobile Node..."

"an Mobile" -> "a Mobile"

Various acronyms, such as BU, HoA, while usually explained when first
used, are missing from Section 2. HoA is not explained at all. Even
better would be to vastly reduce the overuse of acronyms throughout
this document.

[Ballot comment]
There are a bunch of places where references are not given as citations.

s/RFC3775bis/[I-D.ietf-mext-rfc3775bis]/
s/RFC 3315/[RFC3315]/
s/RFC 3633/[RFC3633]/

---

Nit: Section 3.1

Suddenly you use "Delegating Router"

---

Nit:

MIPv6, HoA, and CoA are used without explanation.

BU is used without explanation (you can fix this a couple of lines
earlier)

---

Section 7. I love the use of RFC 2119 language :-)

[Ballot discuss]
I think the Abstract and, in particular, the Introduction need a little
work. Neither of them says what this document is, what it contains, or
why I should read it. The Introduction, which is no more than the
Abstract with citations should also set some scenery. Probably a couple
of paragraphs from section 3?

---

According to Section 2, [I-D.ietf-mext-rfc3775bis] and [RFC4885] are
normative references.

---

Section 3.3

s/must/MUST/ ?

---

Section 4

  While the MR
  is away from home, the IPsec security mechanism mandated by MIPv6
  MUST be used to secure the DHCPv6 signaling.

I think this needs a reference to the MIPv6 document that mandates IPsec

[Ballot comment]
I would state more clearly that explicit mode is not supported if DHCPv6-PD is going to be used. Current text is Section 3.1 says it in a way but the wording like:

  delegation.  Since the MR may not have yet requested any prefixes,
  implicit BU signaling MUST be used.  While using the NEMO Basic
  Support protocol with DHCPv6PD, implicit BU signaling is the default
  mode of operation.

..leaves room for interpretation that the MR may start in explicit mode and then still request for more prefixes usinf DHCPv6-PD. Is this correct?

[Ballot discuss]
The OPS-DIR review by Jouni Korkonen raised a number of issues that require clarification - please see them listed below, the first two are included in the DISCUSS, the third is a (valid) editorial clarification, so I placed it in the COMMENT.

1. In Section 3.1 the MR has two DHCPv6 functions: 1) client and 2) relay.
During the operation described in Section 3.1 the MR internal DHCPv6 client sends a message to MR internal DHCPv6 relay using some goofy method (which is of course not described). If I understand it correctly all this is to please RFC3315, which does not allow a client to start DHCPv6 exchange directly using DHCPv6 server's unicast address before the server has sent a OPTION_UNICAST to the client. Is this correct? If not, go to 2nd comment.

If yes then.. while the attempt would be humble not to break existing RFCs I find it ridiculous. Especially when in Section 3.3 it is stated that DHCPv6 server (which is always collocated in HA) implementation has to be modified anyway. Then why to see the trouble on the MR side having the client-relay workaround, which presumably still needs some MR side modifications to work anyway (like the undefined client-relay communication and running two DHCPv6 instances in the same box)? Just accept the fact that this would work better in Section 3.1 case having the DHCPv6 client in MR send an unicast message to the DHCPv6 server in HA. Both MR & HA side DHCPv6 implementations are not off the shelf implementations anyway and always collocated with MR/HA.

(We recently had a similar case when trying to get DHCPv6 working over existing unmodified 3G network. because we had to add new options to DHCPv6 client and get it running over PPP interface, we made also a small modification to the client to send messages to server's unicast address. At the same time we made a trivial change in the server to accept unicast messages. That we could justify & accept in a special case we had i.e. no desire to run relay+client combination on the end host, no site-scoped multicast support and client & server were always at the ends of point to point links.)


2. Is the solution designed or supposed to work if a node behind the MR initiates a DHCPv6-PD exchange? I would like to see some text what happens when a MR receives a DHCPv6-PD request from one of its downstream interfaces (as there is a relay in MR).

[Ballot discuss]
I think that [I-D.ietf-mext-rfc3775bis] should be a Normative reference, considering some cases how it is referenced (search for "rfc3775bis" - sometimes used without a proper reference).

I have reviewed this document.

I think it is in good shape and can move forward. I did have a couple of smaller issues that I hope will you address in the next couple of days (even if I have asked for a Last Call to be started).

There are references to RFC3775bis, stated as "... .as specified in RFC3775bis ...". This should use proper reference style and I also believe that the reference should be a normative one. (Or you could just refer to RFC 3775 and avoid any possible RFC Editor queue delays before 3775bis is published.)

> peer-address  A non-link-local address from the MR egress interface
>                (e.g., home address) used to send packets between the
>                HA and the MR

Is there ever a situation where something else than a home address would be used here? If a home address were not used, how would the home agent/DHCP server be able to make the necessary changes in the binding cache, for instance?

> The DHCPv6 messages exchanged between the MR and the HA MAY also be
> used for other DHCPv6 functions in addition to DHCPv6PD.  For
> example, the HA MAY assign global addresses to the MR and MAY pass
> other configuration information such as a list of available  DNS
> recursive name servers [RFC3646] to the MR using the same DHCPv6
> messages as used for DHCPV6PD.

The rest is fine, but I wonder if talking about global address assignment will be confusing here. The reader will start wondering if this means home address assignment, and as we know we do not have a full solution for that in terms of setting up both the address and the associated security state.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd is Julien Laganier, MEXT co-chair. He
        has personally done a thorough review of the document. He
        believe the document is ready for forwarding to IESG for
        publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

        The document was given adequate reviews. The Document Shepherd has
        no concerns about the depth or breadth of these reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        The Document Shepherd has no such concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

        The Document Shepherd has no such concerns.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

There is WG consensus behind this document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

        Yes.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        There are no such sections.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

  One aspect of network mobility support is the assignment of a prefix
  or prefixes to a Mobile Router (MR) for use on the links in the NEMO.
  DHCPv6 prefix delegation can be used for this configuration task.

    Working Group Summary

  The normal WG process was followed and the document has been discussed for
  several years. The document as it is now, reflects WG consensus, with
  nothing special worth noting.

    Document Quality

  The document was thoroughly reviewed by Jean-Michel Combes, Michaela
  Vanderveen, and Julien Laganier.