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

Vincent Roca <vincent.roca@inria.fr> Mon, 12 March 2012 11:26 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4A721F8645 for <gen-art@ietfa.amsl.com>; Mon, 12 Mar 2012 04:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.249
X-Spam-Level:
X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu6s01lIT2Kx for <gen-art@ietfa.amsl.com>; Mon, 12 Mar 2012 04:26:19 -0700 (PDT)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFAB21F861D for <gen-art@ietf.org>; Mon, 12 Mar 2012 04:26:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.73,570,1325458800"; d="scan'208";a="135573723"
Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.0.11]) ([82.236.155.50]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 12 Mar 2012 12:26:17 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <201202292215.q1TMF7n9056089@givry.fdupont.fr>
Date: Mon, 12 Mar 2012 12:26:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F70342DE-A102-410A-82CA-C843740D4E7A@inria.fr>
References: <201202292215.q1TMF7n9056089@givry.fdupont.fr>
To: Francis Dupont <Francis.Dupont@fdupont.fr>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 12 Mar 2012 05:09:01 -0700
Cc: Vincent Roca <vincent.roca@inria.fr>, gen-art@ietf.org, draft-ietf-rmt-flute-revised.all@tools.ietf.org
Subject: Re: [Gen-art] (quick) review of draft-ietf-rmt-flute-revised-13.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 11:26:20 -0000

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>gt;.
> 
> 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
> 
> Francis.Dupont@fdupont.fr
> 
> 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