Subject: Re: Last Call: 'Distance Vector Multicast Routing Protocol' to Proposed Standard

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Jun 2004 09:32:11 +0300 (EEST)

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
> [email-masked] or [email-masked] 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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf