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.