Re: [secdir] secdir review of draft-ietf-mpls-hsmp-04

["Adrian Farrel" <[e-mail]>]

Charlie,

Thanks for the time and the nits. Work will be done.

Adrian

> -----Original Message-----
> From: iesg [mailto:[e-mail]] On Behalf Of Charlie Kaufman
> Sent: 01 December 2013 07:11
> To: [e-mail]; [e-mail];
[e-mail]
> Subject: [secdir] secdir review of draft-ietf-mpls-hsmp-04
> 
> I have reviewed this document as part of the security directorate's ongoing
effort
> to review all IETF documents being processed by the IESG.  These comments
> were written primarily for the benefit of the security area directors.
Document
> editors and WG chairs should treat these comments just like any other last
call
> comments.
> 
> This document defines a new variation of MPLS for multipoint to multipoint
> communication. The document does not state why anyone would prefer this
> new variation over the existing one, though I can guess a few reasons. The new
> variation is less efficient in that packets sent travel over many links twice
instead
> of once and packet delivery has longer latency in that most packets travel
over
> more links from their original source to ultimate destination. The two
advantages
> I can imagine are (1) in almost all cases, all packets will arrive at all
destinations in
> the same order (in the original protocol, packets from different sources could
> arrive at different destinations in different orders); and (2) the root of the
> multicast tree could filter messages - for example, to throttle the total
volume of
> messages from a single source. A third possible use that seems to be disavowed
> by the document is to allow members of the multicast group to signal their
status
> only to the root node. It would be nice if the document was more explicit
about
> what this protocol was for, but it doesn't affect security considerations.
> 
> The document correctly notes that there are no new security considerations
> beyond those discussed in the protocol that this competes with. That protocol
is
> defined in RFC6388 and RFC6425.
> 
> Nits:
> 
> Last sentence of abstract reads "The communication among the leaf nodes are
> not allowed." I believe the grammar is incorrect, but more importantly I
believe it
> should read "Direct communication among the leaf nodes is not allowed."
> because communication among the leaf nodes is supported by this protocol with
> all packets being relayed by the root node.
> 
> Near the end of the introduction  is the phrase "except that it follows the
node of
> reverse downstream path of the tree". I believe the word 'node' is incorrect
> here, though I don't know what was intended.
> 
> Page 11: "In some scenario," should be "In some scenarios,"
> 
> 	--Charlie