Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks
draft-ietf-multimob-igmp-mld-tuning-06

[Ballot comment]
I very much agree with Adrian's DISCUSS related to asking authors about IPR. Please do.

Both the ballot writeup and the shepherd report are really inadequate. "Nothing worth noting outside ordinary WG process" is not helpful at all to the rest of the IESG to understand the history of this document. The answers in the shepherd report really give little information. The one answer of any substance was where it says, "There is a strong consensus behind this solution." Again, that sounds like a reason for Standards Track.

I agree that the Appendix should probably be in the main body.

The RFC Editor note removes the 2119 language. Note however:

4.4.  Tuning Startup Query Interval

  The [Startup Query Interval] is the interval between General Queries
  sent by a Querier on startup.  The default value is 1/4 of [Query
  Interval]; however, in this document it is RECOMMENDED that the use
  of its shortened value such as 1 second since the shorter value would
  contribute to shortening handover delay for mobile hosts in, e.g.,
  the base solution with PMIPv6 [10].  Note that the [Startup Query
  Interval] is a static value and cannot be changed by any external
  signal.  Therefore operators who maintain routers and wireless links
  MUST properly configure this value.

The MUST here isn't specifying a protocol behavior. You probably mean "need to". But do you really mean that the value MUST be 1 second?

4.6

  Thus the effects of the
  IGMP/MLD message transmission through a tunnel link SHOULD be
  considered during the parameter setting.

What interoperability problem occurs if they are not considered? Instead of SHOULD, "ought to".

6.

  This document assumes that both multicast routers and mobile hosts
  MUST be IGMPv3/MLDv2 capable

That MUST isn't a directive for this document. Instead of "MUST be", "are".

[Ballot discuss]
Discuss updated after email exchanges (some points are agreed and just need a revised I-D, some points still to be discussed to completion)

I like this document: thank you. However, I have some small issues.

I think the first of my Discuss issues is a small procedural
question that can be resolved through process rather than changes
to the document. Thus the actions should come from the AD, chairs,
and shepherd.

The subsequent issues are for the authors.

I have seen a response from Qin Wu and Hitoshi Asaeda. Just waiting for Hui Liu and then I can remove this from the Discuss.

---

The Shepherd write-up says...

  (7) Has each author confirmed that any and all appropriate IPR
  disclosures required for full conformance with the provisions of BCP 78
  and BCP 79 have already been filed. If not, explain why.

  There have been no IPR disclosures filed on this document

This is not an answer to the question that was asked.

To be precise in my question: have the authors been asked and confirmed that there is no IPR to be disclosed, or is the shepherd deducing this from the absence of dsiclosures?

---

I don't understand the last sentence in Section 1

  The proposed behavior interoperates with
  the IGMPv3 and MLDv2 protocols.

How could the behavior not interoperate with these protocols since you
are directly describing the protocols?

Maybe it would be better to replace this sentence with...

  This document does not make any changes to the IGMPv3 and MLDv2
  protocls and only suggests optimal settings for the configurable
  parameters of the protocols in mobile and wireless environments.

Of course, if my suggested text is not true, we have a bigger issue to
address :-)

---

Is Appendix A normative? It includes advice and RFC2119 language. There
is no reference to the Appendix from the body of the text, and no
explanation in the Appendix itself as to why it is not in the main part
of the document. Please clarify.

[Ballot discuss]
I feel more strongly than Robert about the status of this document. This is introducing particular protocol parameter values that will effect performance and interoperability of the protocol. The recommendations are put in the form of some 2119 language. And the shepherd report says that there was strong consensus behind the solution. I don't understand why it is not Standards Track.

[Ballot comment]
I very much agree with Adrian's DISCUSS related to asking authors about IPR. Please do.

Both the ballot writeup and the shepherd report are really inadequate. "Nothing worth noting outside ordinary WG process" is not helpful at all to the rest of the IESG to understand the history of this document. The answers in the shepherd report really give little information. The one answer of any substance was where it says, "There is a strong consensus behind this solution." Again, that sounds like a reason for Standards Track.

I agree that the Appendix should probably be in the main body.

The 2119 language in this document has lots of problems and should be reviewed. Examples:

3.

  ... a large number of the reply messages sent
  from all member hosts MAY cause network congestion or consume network
  bandwidth.

  ...messages MAY be lost during transmission.

4.1

  This shorter interval contributes to quick synchronization
  of the membership information tracked by the router but MAY consume
  battery power of mobile hosts.

MAY is for protocol options. None of these are protocol options. Almost none of the MAYs are used correctly.

4.4.  Tuning Startup Query Interval

  The [Startup Query Interval] is the interval between General Queries
  sent by a Querier on startup.  The default value is 1/4 of [Query
  Interval]; however, in this document it is RECOMMENDED that the use
  of its shortened value such as 1 second since the shorter value would
  contribute to shortening handover delay for mobile hosts in, e.g.,
  the base solution with PMIPv6 [10].  Note that the [Startup Query
  Interval] is a static value and cannot be changed by any external
  signal.  Therefore operators who maintain routers and wireless links
  MUST properly configure this value.

The MUST here isn't specifying a protocol behavior. You probably mean "need to". But do you really mean that the value MUST be 1 second?

4.6

  Thus the effects of the
  IGMP/MLD message transmission through a tunnel link SHOULD be
  considered during the parameter setting.

What interoperability problem occurs if they are not considered? Instead of SHOULD, "ought to".

6.

  This document assumes that both multicast routers and mobile hosts
  MUST be IGMPv3/MLDv2 capable

That MUST isn't a directive for this document. Instead of "MUST be", "are".

[Ballot discuss]
Discuss updated after email exchanges (some points are agreed and just need a revised I-D, some points still to be discussed to completion)

I like this document: thank you. However, I have some small issues.

I think the first of my Discuss issues is a small procedural
question that can be resolved through process rather than changes
to the document. Thus the actions should come from the AD, chairs,
and shepherd.

The subsequent issues are for the authors.

---

The Shepherd write-up says...

  (7) Has each author confirmed that any and all appropriate IPR
  disclosures required for full conformance with the provisions of BCP 78
  and BCP 79 have already been filed. If not, explain why.

  There have been no IPR disclosures filed on this document

This is not an answer to the question that was asked.

To be precise in my question: have the authors been asked and confirmed that there is no IPR to be disclosed, or is the shepherd deducing this from the absence of dsiclosures?

---

I don't understand the last sentence in Section 1

  The proposed behavior interoperates with
  the IGMPv3 and MLDv2 protocols.

How could the behavior not interoperate with these protocols since you
are directly describing the protocols?

Maybe it would be better to replace this sentence with...

  This document does not make any changes to the IGMPv3 and MLDv2
  protocls and only suggests optimal settings for the configurable
  parameters of the protocols in mobile and wireless environments.

Of course, if my suggested text is not true, we have a bigger issue to
address :-)

---

Is Appendix A normative? It includes advice and RFC2119 language. There
is no reference to the Appendix from the body of the text, and no
explanation in the Appendix itself as to why it is not in the main part
of the document. Please clarify.

[Ballot discuss]
I like this document: thank you. However, I have some small issues.

I think the first two of my Discuss issues are small procedural
questions that can be resolved through process rather than changes
to the document. Thus the actions should come from the AD, chairs,
and shepherd.

The subsequent issues are for the authors.

---

The Shepherd write-up says...

  (7) Has each author confirmed that any and all appropriate IPR
  disclosures required for full conformance with the provisions of BCP 78
  and BCP 79 have already been filed. If not, explain why.

  There have been no IPR disclosures filed on this document

This is not an answer to the question that was asked.

---

Was this document sent for review by the PIM working group (that is now
responsible for MLD and IGMP maintenance)? The shepherd write-up tends
to imply not.

While, as an Informational RFC that does not change the protocol, that
is not strictly necessary, it would have made good sense. I see that one
of the PIM WG chairs is acknowledged for his comments, so perhaps this
received wider review.

---

I don't understand the last sentence in Section 1

  The proposed behavior interoperates with
  the IGMPv3 and MLDv2 protocols.

How could the behavior not interoperate with these protocols since you
are directly describing the protocols?

Maybe it would be better to replace this sentence with...

  This document does not make any changes to the IGMPv3 and MLDv2
  protocls and only suggests optimal settings for the configurable
  parameters of the protocols in mobile and wireless environments.

Of course, if my suggested text is not true, we have a bigger issue to
address :-)

---

I couldn't work out whether Section 5 is suggesting a change to common
implementation practice, a change to the behavior described in the
IGMP/MLD specs, or the setting of a configuration parameter. Could you
clarify?

---

Is Appendix A normative? It includes advice and RFC2119 language. There
is no reference to the Appendix from the body of the text, and no
explanation in the Appendix itself as to why it is not in the main part
of the document. Please clarify.

[Ballot comment]
Did you consider PS for this document? Operational/interop experience might suggest changed values.

Small thing: Consider pointing out that as you start talking about Max Resp Code values larger than 12.8 seconds,
the exponential representation in 4.1.1 of RFC3376 kicks in so the granularity of changes you can indicate
becomes coarser.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks) to Informational RFC





The IESG has received a request from the Multicast Mobility WG (multimob)

to consider the following document:

- 'Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless

  Networks'

  as an Informational RFC



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-03-20. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  IGMP and MLD are the protocols used by hosts and multicast routers to

  exchange their IP multicast group memberships with each other.  This

  document describes the ways of IGMPv3 and MLDv2 protocol optimization

  for mobility, and aims to become a guideline for tuning of IGMPv3/

  MLDv2 Queries and timer and counter values.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-multimob-igmp-mld-tuning/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-multimob-igmp-mld-tuning/ballot/





No IPR declarations have been submitted directly on this I-D.

Note changed to 'Behcet Sarikaya (sarikaya2012@gmail.com) is the document shepherd.
Note: document is on the telechat 5 days before the LC ends. I'd like to complete this doc while I'm on the IESG, and handle additional last call comments (if any) in Paris IESG meeting. We'll hand it off to Brian if there's anything substantial.
'

I have reviewed this draft.

Thanks for writing the draft, I think it provides solid advice. There are a couple issues in the draft but I have decided to send the draft forward for an IETF last call. But I would appreciate a quick response of my issues and if necessary, a draft update this week.

A couple of comments below:

> Therefore, in this document it is RECOMMENDED that adjacent upstream
>    multicast routers enable the explicit tracking function for IP
>    multicast communications on wireless and mobile networks, if they
>    have enough resources.

But draft-ietf-pim-explicit-tracking is an informational reference. I think you should loosen the language above (maybe "it is recommended ...") unless you want to introduce a normative reference and possible wait until the other document is approved as an RFC.

>    This document proposes 150 seconds for the [Query Interval] value by
>    changing the Querier's Query Interval Code (QQIC) field specified in
>    the IGMP/MLD Query message, for the case that a router enabling the
>    explicit tracking function sends General Query and potentially
>    operates a large number of member hosts such as more than 200 hosts
>    on the wireless link.  This longer interval value contributes to
>    minimizing traffic of Report messages and battery power consumption
>    for mobile hosts.
>
>    On the other hand, this document also proposes 60 to 90 seconds for
>    the [Query Interval] value for the case that a router enabling the
>    explicit tracking function attaches to a wireless link having higher
>    capacity of the resource.  This shorter interval contributes to quick
>    synchronization of the membership information tracked by the router
>    but MAY consume battery power of mobile hosts.

I had some trouble parsing the recommendations here. Are you recommending 150 seconds when explicit tracking is in use? Or only when there are > 200 hosts? And in the second paragraph, what do you mean by "having higher capacity of the resource"? What resource? Did you just mean to say "... a wireless link with higher capacity"?

>    a gradual manner until it exceeds the mobile host's lifetime.

Perhaps you meant mobile host's binding lifetime? :-) Or some MLD lifetime value in the hosts? And what do you do if the various mobile hosts have different lifetimes?

> For a router
>    that attaches to a wireless link having higher capacity of the
>    resource or reliable condition

Just say "having higher capacity or is known to be reliable".

>    When a receiver host connects directly through a wireless link to a
>    foreign access router or a home router, the tuning of the IGMP/MLD
>    protocol parameters SHOULD be the same as suggested in the previous
>    sections.  The example of this scenario occurs when route
>    optimization is adopted in MIPv6 [8] or Mobile IP [11], or when in
>    Proxy Mobile IPv6 (PMIPv6) [7], the mobile access gateway, whose role
>    is similar to the one of a foreign router, acts as a multicast
>    router.

I do not understand what route optimization has to do with this, given that it does not support multicast... Suggest deleting the route optimization part and just leaving the PMIP part of the last sentence.


> between host and home router is used to exchange IGMP/MLD messages
>    such as [8][11].

... such as in [8][11].


>    This document assumes that both multicast routers and mobile hosts
>    MUST be IGMPv3/MLDv2 capable, regardless whether the protocols are
>    the full or lightweight version.  And this document does not consider
>    interoperability with older version protocols.  The main reason not
>    being interoperable with older IGMP/MLD protocols is that the
>    explicit tracking function does not work properly with older IGMP/MLD
>    protocols.


Please expand this a bit. Explicit tracking in the routers does not work well when older IGMP/MLD versions are in the hosts? How widespread are those older implementations? Can you provide some further advice?

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational
Yes
Yes
(2) 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

Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

The abstract is OK

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?
No

Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?
No
Personnel

Who is the Document Shepherd? Who is the Responsible Area
Director?
Document Shepherd is Behcet Sarikaya Responsible Area
Director is Jari Arkko

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The chairs have reviewed the document and it is ready for publication

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

I have no concerns on the document
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

There have been no IPR disclosures filed on this document

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There have been no IPR disclosures filed on this document

(9) 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 a strong consensus behind this solution

(10) 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 publicly available.)

Nobody has threatened to appeal and the document has the backing of
the WG as a whole

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No ID nit errors/warnings are present on the document

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document meets the review criteria

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) 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 plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no actions for IANA in this document.  However, an IANA
considerations section stating that does exist.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No formal language segments exist