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
>
> [email protected]
>
> 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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
