IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers
draft-ietf-pim-explicit-tracking-13

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

(Adrian Farrel) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-12-19 for -09)
No email
send info
- If the last two bullets aren't goals then why
mention them?  In particular, if per-host accounting
can be built on this then that does seem to imply
that the routers will be sending this further (see
the discuss point).

- If routers were to log the information here then
those logs would be privacy sensitive and that would
seem like its worth a mention. I realise that you say
that the information can be flushed on reboot, but it
might be no harm to say that it needs care.

- Please see the secdir review [1] which I don't
think got a response. (It may have been
mis-directed.)

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04371.html

(Joel Jaeggli) No Objection

Comment (2013-12-17 for -09)
No email
send info
given 

igmp/mld listening are a gateway function.

and this draft appears to make no specific new requirements of hosts joining or leaving groups, I wonder on what basis two implementations would be considered interoperable on on the basis of this specification.

(Sean Turner) No Objection

(Benoît Claise) Abstain

Comment (2013-12-18 for -09)
No email
send info
I'm with Brian (and Joel) here: how could two implementations inter-operate?
As a prove, I searched for all instances of the RFC 2119 keyword, and I found 2 SHOULD, 1 SHOULD NOT, and 1 MAY. Clearly not enough of a specification. As Brian put it: "internal implementation details that are needed to support explicit tracking."

(Brian Haberman) Abstain

Comment (2013-12-17 for -09)
No email
send info
I have been involved in the discussion of this document for several years.  For the most part, this spec really describes internal implementation details that are needed to support explicit tracking.  In other words, it is unclear where in this spec there is normative text related to interoperability between two (or more) multicast routers.  I don't see a need for this spec even though there are multiple (different!) implementations of the basic functionality.

Barry Leiba Abstain

Comment (2013-12-19 for -09)
No email
send info
For Benoît: lack of 2119 key words isn't proof of anything; one can provide normative text and define a protocol without using those key words.

That said, I'm with the abstainers here: I don't see it.

From the shepherd writeup:
"There are many implementations of explicit tracking already. They
are not based on this document though, but they should be close
in functionality to what is in this document."

I have a two-part question: (1) Do those implementations interoperate with each other and with what's specified in this document, and (2) are those implementations likely to be changed to match what's specified in this document, and what would is mean to do so?

Ignas Bagdonas No Record

Deborah Brungard No Record

Alissa Cooper No Record

Roman Danyliw No Record

Benjamin Kaduk No Record

Suresh Krishnan No Record

Warren Kumari No Record

Mirja Kühlewind No Record

Alexey Melnikov No Record

Alvaro Retana No Record

Adam Roach No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record