Distance Vector Multicast Routing Protocol Applicability Statement
draft-ietf-idmr-dvmrp-v3-as-01
Discuss
Yes
(Bill Fenner)
No Objection
(Cullen Jennings)
(Lars Eggert)
(Lisa Dusseault)
(Ross Callon)
(Ted Hardie)
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.
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
Dan Romascanu Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2006-07-17)
Unknown
There is no separation of references in Normative and Informative. Section 5 in draft-ietf-idmr-dvmrp-v3-11 seems incomplete. It refers to a few MIB documents, but it is not clear if these MIB modules are considered to be sufficent for the management of a DVMPRPv3 device or network, or further work would be needed for a fully managed solution. The reference [Thal97] has an unknown status. The reference [McCl00] seems to refer to a IPv4 only solution.
Magnus Westerlund Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2006-07-20)
Unknown
Protocol document: As I understand this document covers only IPv4. I think that should be stated up front to clarify that in all the places it says "IP address" an IPv4 address is implied. What about DVMRP for IPv6? Section 3.1: - "DVMRP protocol packets should be sent with the Precedence field in the IP header set to Internetwork Control (hexadecimal 0xc0 for the Type of Service Octet) [Post81]." I this procedure needs to be updated to take RFC 2474 into consideration. Section 3.2.1: Bitorder of the capability flags are depicted as inverse to the others. This makes it unclear if the bit 7 is the left most in field and should go into bit 8 of the second 32 bit word of the common header or the 15th bit. 7 6 5 4 3 2 1 0 U U N S M G P L +---+---+---+---+----+---+---+---+ |0 |0 |X | 0 | 1 |1 |1 | 0 | +---+---+---+---+----+---+---+---+ Figure 2 - Probe Capability Flags
Russ Housley Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2006-07-19)
Unknown
draft-ietf-idmr-dvmrp-v3-as-01 does not contain a security considerations section, Please add one that summarizes the negative impact if the applicability statement is ignored. The security considerations of draft-ietf-idmr-dvmrp-v3-11 suggest the usage of IPsec and then describe the impact of multicast addresses. However, the old version of the IPsec Architecture and AH are referenced. The support for multicast is not complete, and it is a work item in the MSEC WG. I do not see how IPsec can be used without this work being finished. Since DVMRP can be used without IPsec, it would be valuable to spell out the security risks of using DVMRP without IPsec. In particular, ithe ramifications of forged messages and the impact of making neighbor information accessible via the tracing and troubleshooting support ought to be discussed. Perhaps some of the security needs could be provided by packet filtering. If so, please provide more information and recommendations.
Bill Fenner Former IESG member
Yes
Yes
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2006-07-20)
Unknown
From Gen-ART review by Joel Halpern:
The following minor comments should be considered if there is other reason to revise the document.
Protocol:
In section 2.4 on Designated Forwarder, in the event of a metric tie, the rotuer with the lowest IP address is the designated forwarder. I believe that this is the router whose interface to the mutli-access network has the lowest IP address. (Not, for example, the lowest loopback address, etc.) A few extra words here would be a good idea.
Section 2.5.1 talks about learning local group membership from IGMP. Shouldn't there be some mention of source specific membership here? (Or am I confused and that has gone away?)
I am guessing that the 3 octet network mask technique is used here for backwards compatibility, even though a network prefix length would be shorter? (The protocol goes to significant lengths to save bytes, and the text does not say why that is not used.)
Section 3.4.5 introduces the term "flash update." While I have seen this in implementations, it is not a widely used term in our specifications. An explanation would be a good idea.
Applicability Statement:
It would have been nice to see a clearer statement of why one would use this rather than either PIM-DM or M-OSPF. (There is probably more, but one piece of the answer is the support for tunnels in DVMRP.)
Given that restarting routers can, via the generation ID, cause significant amounts of graft, graft-ack, and prune messages, should this applicability statement say something about assuming underlying stability of the network?
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2006-07-20)
Unknown
I agree with Russ' comments on the security considerations section. In addition, I would note that saying "use IPsec" is typically insufficient in terms of explaining how to secure a protocol. Such statements would have to be complemented with guidance on how the keys are set up, how policy entries are set up, who should be authorized to do what, whether there are any limitations when the security mechanism is turned on, etc. I'm curious if someone has actually implemented and interoperated this protocol with IPsec, given earlier/current routing area mandates on implementation reports before documents can be approved.
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown