Subject: [multimob] AD Evaluation: draft-ietf-multimob-handover-optimization

From: Brian Haberman <[email-masked]>
Date: Thu, 17 Oct 2013 10:50:23 -0400

All,
     I have completed my AD evaluation of
draft-ietf-multimob-handover-optimization and found it to be quite
readable.  Thank you.

     I have a few issues that I would like to see resolved prior to
requesting IETF Last Call for this document.  Feel free to discuss them
with me if clarifications are needed.

1. Introduction:

* In the 2nd paragraph, I don't see the benefit to referencing a draft
that has been expired for 3 years.  I would suggest dropping the reference.

* In the 3rd paragraph : s/can help mitigating/can help mitigate

* The last paragraph is not needed and can be deleted.

2. Several places in the beginning of the document, there are references
to RFC 2710 but not RFC 3810.  RFC 6224 uses both and section 4.1.1
explicitly discusses RFC 3810 (albeit indirectly as MLDv2).  I would
suggest referencing both, add 3810 to the Normative References, and
properly reference 3810 in the appropriate places in section 4.

3. The reference to draft-ietf-multimob-pmipv6-ropt can be updated to be
RFC 7028.

4. Section 1.1

* The 2nd requirement is not a protocol requirement and should be
deleted.  It is trying to mandate implementation/deployment behavior.

* The "on" in requirement 3 can be removed.

* Would it make sense to add an additional requirement that this
experimental approach not impact deployments of legacy implementations
of RFC 5213 and RFC 6224?

5. Section 4.1.2 : It would be clearer if the description of the message
formats that are borrowed from 2710 and 3810 refer to those formats by
the terms used in the RFC.  For example, the Multicast Membership
Context field should refer to (or be called) the Multicast Address
Record (from 3810).

6. Sections 4.3.1.2 and 4.3.2.2

* Why are the sequence numbers 8-bit fields?  The sequence fields in
other PMIPv6 messages are 16-bit.

* I would suggest adding references for the options allowed in these
messages (Mobile Node Identifier, Home Network Prefix, and Active
Multicast Subscription).

Regards,
Brian

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 18 Oct 2013 12:29:34 +0200

Hi Brian,

Thanks for your review and comments. We have prepared a revised version
(-05), attached to this e-mail but not yet posted to the I-D repository.
Please see below our responses. Once you are happy with them, we can
post -05 version.

> that has been expired for 3 years.  I would suggest dropping the reference.

[Authors] OK, done.

> * In the 3rd paragraph : s/can help mitigating/can help mitigate

[Authors] OK, done.

> * The last paragraph is not needed and can be deleted.

[Authors] OK, done. We originally added this because during the IESG
evaluation of RFC7028 we got a comment requesting to add such a
paragraph there.

> properly reference 3810 in the appropriate places in section 4.

[Authors] OK, done.

> 3. The reference to draft-ietf-multimob-pmipv6-ropt can be updated to be

[Authors] OK, done.

> deleted.  It is trying to mandate implementation/deployment behavior.

[Authors] OK, done.

> * The "on" in requirement 3 can be removed.

[Authors] OK, done.

> of RFC 5213 and RFC 6224?

[Authors] Good point, it makes sense. We have added it.

> Context field should refer to (or be called) the Multicast Address

[Authors] We think we already do this:

   Multicast Membership Context:

      Multicast subscription information corresponding to a single
      subscribed multicast address.  For MLDv2, the format of this field
      follows the Multicast Address Record format as defined in
      [RFC3810].

[Authors] But if you think that it is clearer to just use the RFC 3810
name (Multicast Address Record) for the field, we can update it.

> other PMIPv6 messages are 16-bit.

[Authors] We believe that 8 bits are enough for this sequence space,
which is enough for the purpose of the subscription query/response, as
it is not expected to be used as often as PBU/PBA. Using 16-bit values
would require at least extending the size of the Subscription Response
message, and we thought that it was a better trade-off to use a 8-bit
value.

> messages (Mobile Node Identifier, Home Network Prefix, and Active

[Authors] OK, done.

Thanks!

Carlos

---

From: Brian Haberman <[email-masked]>
Date: Fri, 18 Oct 2013 13:43:23 -0400

Hi Carlos,
     I have pared down the points to just those needing a response...

> evaluation of RFC7028 we got a comment requesting to add such a

This time around, I will do my best to stop such silliness. :)

> name (Multicast Address Record) for the field, we can update it.

You are right.  The existing text is sufficient.

> message, and we thought that it was a better trade-off to use a 8-bit

Ok.  This is nothing to worry about now.  Don't be surprised if someone
during IETF Last Call or IESG Review asks for text in the document
explaining why the sequence number spaces have different sized.

Go ahead and submit the new version and I will move it along in the
publication process.

Regards,
Brian

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 18 Oct 2013 20:37:06 +0200

Hi Brian,

Thanks for the quick response. We have just submitted the -05 revision.

Thanks,

Carlos