Subject: [pim] draft-ietf-pim-explicit-tracking pim 3rd wglc

From: Stig Venaas <[email-masked]>
Date: Wed, 04 Sep 2013 11:51:03 -0700

This is the third, and hopefully final, working group last call for this
draft. A number of changes were made in response to the 2nd WGLC, and we
would like the WG to review the latest version to make sure we are happy
with the latest revision.

The draft is at
http://tools.ietf.org/html/draft-ietf-pim-explicit-tracking-07

The previous WGLC was for revision 05. To see the changes click on
the links at the page at the link above, or use this link

http://tools.ietf.org/rfcdiff?url1=draft-ietf-pim-explicit-tracking-05.txt&url2=draft-ietf-pim-explicit-tracking-07.txt

Please state whether you are happy with these changes, or if you want
any additional changes, by Friday September 13th.

Stig

---

From: "John McLendon" <[email-masked]>
Date: Wed, 4 Sep 2013 19:23:03 +0000

Speaking only for myself, I'm good with this latest draft.

John...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Wednesday, September 04, 2013 2:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: [pim] draft-ietf-pim-explicit-tracking pim 3rd wglc

The draft is at

Stig

_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 11 Sep 2013 06:07:18 +0000

Hi Hitoshi,

    I have read through the latest revision and it is in much better shape. Thanks a lot for taking care of my suggestions.

    I still have couple of small questions and suggestions:

* In Introduction, in following sentence:

   Also, a querier router periodically sends IGMP/MLD General Query
   messages within the General Query timer interval (i.e. [Query
   Interval] value defined in [2][3]).

Should we use 'every' instead of 'within the'? It will become:

   Also, a querier router periodically sends IGMP/MLD General Query
   messages every General Query timer interval (i.e. [Query
   Interval] value defined in [2][3]).

* In Introduction, in following sentence:

   IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can
   provide the ability to keep track of the downstream (adjacent)
   multicast membership state to multicast routers, yet the
   specifications are not clearly given. 

Should we use 'in mulicast routers' instead of 'to multicast routers'. It will become:

   IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can
   provide the ability to keep track of the downstream (adjacent)
   multicast membership state in multicast routers, yet the
   specifications are not clearly given. 

* In Introduction, in following sentence:

   Particularly when a router needs to maintain a large number of
   member hosts, this resource requirement could have an impact. 

Can we elaborate a little on the 'impact' we are referring here? What kind of impact? Is it impact on router functionality or something else?

* In section 3, the draft describes the new multicast membership state information a multicast router conforming to this draft creates. For implementors, should not this draft also mention when or under what conditions to remove this membership state?

* In section 4, in following sentence:

   All member hosts joining the identical
   channel then reply their own states after acquiring these query
   messages. 

Will it be better to add a 'with' between 'reply' and 'their'? It will become:

   All member hosts joining the identical
   channel then reply with their own states after acquiring these query
   messages. 

* In section 4, in second para, it is exaplained that if router receives one or more replies from the downstream members, it can stop retransmitting the specific query message. In my understanding, this should be reworeded to say that the groups or sources for which downstream members exist, should not be included in subsequent specific query messages. If there is no such group or source available, router can stop sending specific query message.

* In section 4, in last para, in following sentence:

   For the latter
   case, when the querier suppresses the specific query message
   transmission, and expects that the State-Change Report sender is not
   the sole member of the channel, it does not send the specific query
   and none of the routers on the same LAN receive a Current-State
   Report message from the corresponding member hosts. 

This sentence is too big and is not clear enough. Can we please divide this into multiple sentences?

* In section 5, in para 4 :

   Furthermore, if operators believe that their link is fairly robust or
   that they can configure the [Robustness Variable] value appropriately
   so that the chances of unsolicited messages being lost are
   sufficiently low, and if the querier router is always the forwarder
   router in their link, they will set smaller LMQC/LLQC and shorter
   LMQI/LLQI (and hence shorter LMQT/LLQT) with the specific query
   suppression or enable the specific query suppression in a robust link
   state (Section 4) for their routers.

This whole para is one single sentence. Someone reading it may be lost. So in my opinion, it is better to divide this into multiple sentences.

Another suggestion is that we do not really need the part "and if the querier router is always the forwarder router in their link," in this sentence. I am not sure why is this required here?

* In Security consideration, do you think it will be good to mention about 'IPSec' usage for IGMP/MLD messages as well?

Regards,
Bharat Joshi
http://bite-the-bytes.blogspot.com/
________________________________________
From: [email-masked] [[email-masked]] on behalf of Stig Venaas [[email-masked]]
Sent: Thursday, September 05, 2013 12:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: [pim] draft-ietf-pim-explicit-tracking pim 3rd wglc

The draft is at

Stig

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Stig Venaas <[email-masked]>
Date: Mon, 16 Sep 2013 11:35:06 -0700

Hi

The only comments asking for changes were the ones below.
Hitoshi, please do one final revision where you incorporate
the changes you like based on the below comments. It looks
mostly editorial.

Once you've done that we'll ask for publication.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 16 Sep 2013 11:35:22 -0700

Hi

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 17 Sep 2013 23:33:31 +0900 (JST)

Hi Stig,

> Once you've done that we'll ask for publication.

I'll submit the revised one.
Bharat, thanks for your detail comments.

Regards,
--
Hitoshi Asaeda