On Fri, 11 Jun 2004, The IESG wrote: > The IESG has received a request from the Inter-Domain Multicast Routing WG to > consider the following documents: > > - 'Distance Vector Multicast Routing Protocol ' > <draft-ietf-idmr-dvmrp-v3-11.txt> as a Proposed Standard > - 'Distance Vector Multicast Routing Protocol Applicability Statement ' > <draft-ietf-idmr-dvmrp-v3-as-01.txt> as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2004-06-25. There was some debate about this on the routing-discussion list (among others), and there a number of people seemed to be of the opinion that the right category for DVMRP would be Informational or Historic, not Proposed Standard. I don't think going for PS is the right choice here. DVMRP is already a retired protocol, or one that operators have been retiring (or have retired) for around 5 years now. It's OK for existing deployments which don't want to change to other protocols, but not for new efforts -- and in that case, Informational would seem much more applicable. Such a category would provide guidance for interoperable implementations, but would also be a sign that DVMRP might not be good candidate for deployment. So, I suggest moving the spec to Informational. A couple of comments about the documents themselves (not a proper review, I just skimmed them for 30 minutes): - both documents fail a number of *required* nits, e.g., boilerplate, AS missing Security Considerations, old boilerplates, references not split, etc., the main spec having a line of 90 chars, references in the abstract, etc. applicability statement ----------------------- - this seems weak, especially section 1 on tradeoffs. A number of advantages seem clearly false, as of now (maybe these didn't hold 5 years ago -- Have these been updated to PIM-DM? SSM? I don't think so). This is the most important messaage of the applicability statement document, i.e., where NOT to use them and where to use them, and I don't think the message has come across very clearly. One should not also be hesitant to refer to other protocols for better operation (PIM-SM, -DM, SSM, etc.). main spec --------- - probably needs spelling out why this doesn't need to support IPv6? - IANA considerations seems funny, as these values have already been allocated? Is it necessary to list these here? Just say that as the numbers are already assigned this doc creates no *new* IANA considerations? However, note that as several messages use an IGMP type and this document (and the previous revisions) specify the codes for DVMRP (and that database is maintained by IANA), it might be necessary to specify the allocation criteria (based on RFC2343) for subsequent allocations? - security considerations basically only discusses the lack of anti-replay w/ DVMRP when using IPsec, and leaves out two main things: (1) everything related to security which does not befall under IPsec (i.e., what are the issues when IPsec is not used, or what are the issues even if IPsec is used?), and (2) how do you actually set up the IPsec keying to make it work in an interoperable fashion? (The security ADs are going to bite at (2) at least). - there are some old references, like to an old GRE spec. - this document does not prominently, right out in the introduction, point _loudly_ towards the applicability statement spec. This is especially important if the work goes on for PS. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf