Re: [Gen-art] (quick) review of draft-ietf-rmt-flute-revised-13.txt

[Vincent Roca <[e-mail]>]

Hello Francis,

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-rmt-flute-revised-13.txt
> Reviewer: Francis Dupont
> Review Date: 20120229
> IETF LC End Date: 20120224
> IESG Telechat date: 20120301
> 
> Summary: Almost Ready
> 
> Important note: due to last comments from the Last Call it seems
> there will be a -14 version...
> 
> Major issues: None
> 
> Minor issues: not a real one (it was inherited from RFC 5775) but
> in the security considerations there is nothing about IPsec/AH
> (BTW people who didn't implement it didn't implement the transport
> mode (for IPsec/ESP) too :-).

Yes, this is done deliberately. We do not mention IPsec/AH at all
and our minimum security requirements are aligned with that of
RFC 5775. For instance RFC5775, Section 5.1.1, says:

  "The ALC sender SHALL use an IPsec SA configured for Encapsulating
   Security Payload (ESP) protocol [RFC4303] operation with the option
   for data origination authentication enabled."

I think the situation is clear enough.


> Nits/editorial comments:
> - ToC page 3 and 9 page 36: Acknowledgements -> Acknowledgments

Done.


> - 1 page 6: please add a reference to RFC2357 (or make it an
>  explicit reference)

I don't understant. We already have a reference to that RFC in section 1, p6:
  "This specification contains part of the definitions necessary to
   fully specify a Reliable Multicast Transport protocol in accordance
   with [RFC2357]."
What is the point?


> - 1.1.3 page 7: I suggest to add the "diode" in the environment
>  where FLUTE can be used (diodes are more common than you can
>  believe :-)
> 
> - 3 page 9 (and other places): e.g. -> , e.g., and i.e. -> , i.e.,

Done.


> - 3.1 page 9: I'd like to get the type (e.g., integer) of fields,
>  for instance I have no idea of what a TSI really looks like.

I've clarified what a TSI looks like as follows:

NEW:
   One of the fields carried in the ALC/LCT header is the Transport
   Session Identifier (TSI), an integer carried in a field of size 16,
   32, or 48 bits (note that the TSI may be carried by other means in
   which case it is absent from the LCT header [RFC5651]).


> - 6 page 27: session ; -> session; and at the next line
>  session. -> session; (only the last item gets a dot)

Right. Done.


> - 7.2.2 page 30: this is the place I am surprised to not get
>  IPsec/AH [RFC4302] as an alternative to IPsec/ESP [RFC4303]
>  when integrity and sender authentication is wanted.

An interesting reference:
	"A Cryptographic Evaluation of IPsec"
	Niels Ferguson and Bruce Schneier
	http://www.schneier.com/paper-ipsec.pdf
Section 3.1:
	"Recommendation 2: Eliminate the AH protocol."

Another reference on the same topic:
	"Avoiding Authentication Header (AH)"
	draft-bhatia-ipsecme-avoiding-ah-00

I don't follow the IPSECME WG and therefore I cannot
say wether there is consensus or not on the topic.
However it seems to me it's not worth adding a reference
to AH. We can do without, using the functionalities already
provided in the "minimum security requirements".


> - 10 page 36:
>  52134 Herzogenrath, Germany ->
>  52134 Herzogenrath
>  Germany

Done.


> - Authors' Addresses page 45: US -> USA
>  (note: the Innovallee; is dubious too)

s/US/USA/: Done:
Concerning the Inovallée, I can't change our official postal address ;-)


> Regards
> 
> [e-mail]
> 
> PS: I expect to get the new version so to have more time
> to read (more) carefully the body of the document (i.e., 3 - 6).


Okay. Thanks Francis.

   Vincent