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(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf