Skip to main content

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

Yes

(Adrian Farrel)

No Objection

(Jari Arkko)
(Richard Barnes)
(Sean Turner)
(Spencer Dawkins)
(Stewart Bryant)

Abstain


No Record

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

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

Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Adrian Farrel Former IESG member
Yes
Yes (for -09) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2013-12-17 for -09) Unknown
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.
Richard Barnes Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-12-19 for -09) Unknown
- 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
Stewart Bryant Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Barry Leiba Former IESG member
Abstain
Abstain (2013-12-19 for -09) Unknown
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?
Benoît Claise Former IESG member
Abstain
Abstain (2013-12-18 for -09) Unknown
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 Former IESG member
Abstain
Abstain (2013-12-17 for -09) Unknown
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.