IETF 76, RMT WG Minutes
Wednesday, 11 November 2009
===========================
Note Taker: Vincent Roca

WG Progress (Lorenzo)
=====================

 - PUBLISHED
  - RFC 5651 - Layered Coding Transport (LCT) Building Block
  - RFC 5740 - NACK-Oriented Reliable Multicast (NORM) Protocol


 - SUBMITTED FOR PUBLICATION:
  - draft-ietf-rmt-pi-alc-revised-09 (IESG evaluation)
  - draft-ietf-rmt-flute-revised-07 (AD Evaluation)

Magnus: some work needs to be done in FLUTE. There's a long
       comment list. One issue concerns security requirements
       (see discussion below).

  - draft-ietf-rmt-sec-discussion-04 (resubmitted)

 - WORKING GROUP LAST CALL
  - draft-ietf-rmt-simple-auth-for-alc-norm-02

Vincent: Can we see if there's interest in MSEC to review?
       =>  No answers, which suggests that nobody volunteers.
Vincent: So I'll discuss with Brian Weis (MSEC) to see if we can
       ask for feedbacks there.
Lorenzo: No problem.

 - UPDATED DRAFTS:
  - draft-roca-rmt-newfcast-06 (approved as RMT WG item)

Q: why is this document an individual one whereas it's a WG Item?
Vincent: this is my fault, I forgot to ask Magnus/chairs on due time.


Update on ALC (Lorenzo, on behalf of Mark Watson)
http://www.ietf.org/proceedings/09nov/slides/rmt-1.ppt
======================================================

The documents is currently under IESG review. See the slides
for the details.


Update on FCAST (Vincent Roca)
http://www.ietf.org/proceedings/09nov/slides/rmt-3.ppt
======================================================

Vincent introduces the main updates. They essentially concern the
support of NORM (See the slides for the details). The document is
now considered mature.  He therefore suggests to start WGLC.

Lorenzo: How many people reviewed the I-D so far?
Vincent: Gorry Fairhurst provided very good comments one year ago
       (in particular the idea of having checksums that protect
       the Compound Object header).
Lorenzo: Okay. Let's go to the list.


Update on TESLA (Vincent Roca)
http://www.ietf.org/proceedings/09nov/slides/rmt-3.ppt
======================================================

Vincent reminds the group the general context about packet source
authentication and packet integrity verification techniques.
He emphasizes in particular that TESLA does complement group MAC
and digital signature techniques (see simple-auth-for-alc-norm).
TESLA has recently entered RFC Editor Queue.

Vincent: To go back to the discussion of what security protocol
       to mandate in FLUTE, I don't think TESLA is a good solution.
       The reason I see is its intrinsic complexity. I'd rather opt
       for Digital Signatures (same service, but at the price of
       much higher processing load and transmission overhead).
Lorenzo: What do we need exactly? Is "at least one" particular
       technique needed?
Magnus: There are two requirements (described in a BCP): the first
       one is to have a security protocol identified, the second
       one is to make it mandatory to support (but not necessarily
       to use, depends on the use-case).
Lorenzo: Go to the list.


RaptorG (Mike Luby)
http://www.ietf.org/proceedings/09nov/slides/rmt-0.ppt
======================================================

Mike introduces a new version of codes, RaptorG, whose performance
in terms of erasure recovery capabilities are remarkable. Several
other features have been improved, in particular the ability of
encoding/decoding source blocks that are an order of magnitude larger.
See the slides for the details.

Magnus: Is there's any chance this I-D to finish soon, since the RMT
       WG is expected to shut down?
Luby: The draft is in real good shape and can be finished pretty fast.

Vincent: I support this I-D being WG Item, in view of the results.
Lorenzo: Are there other comments? (no answer) Okay, so let's go to
       the list.

Vincent: I sent an email on the list with technical comments. In
       particular how does the Gaussian elimination based technique
       proposed in RFC 5053 lead to linear time decoding? Is it related
       to the "inactivation decoding" technique patented?
Mike: Yes, it's based on an inactivation technique, which makes it
       possible to iteratively decode before finishing with a GE on a much
       smaller system. Look at the RFC 5053, it's already there.
       I'll be happy to provide technical details with actual figures
       to the group in order to illustrate the claims of this presentation.

People
======

Magnus -> Magnus Westerlund
Vincent -> Vincent Roca
Lorenzo -> Lorenzo Vicisano
Mike -> Mike Luby