Subject: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07

From: Greg Shepherd <[email-masked]>
Date: Tue, 11 May 2010 10:35:34 -0700

This starts the working group last call for draft-ietf-fecframe-framework-07

http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/

PLEASE read, review, and FEEDBACK to the list promptly, both with
issues AND with votes of approval by Monday, May 17th. We cannot move
forward without your input.

Thank you,
Greg (YESI'MSHOUTINGINCAPS) Shepherd

---

From: "Orly Peck" <[email-masked]>
Date: Sun, 16 May 2010 08:43:38 +0300

I approve.
Thanks,
Orly.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Shepherd
Sent: Tuesday, May 11, 2010 8:36 PM
To: [email-masked]
Subject: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07

This starts the working group last call for
draft-ietf-fecframe-framework-07

Thank you,
Greg (YESI'MSHOUTINGINCAPS) Shepherd
_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: Greg Shepherd <[email-masked]>
Date: Sun, 16 May 2010 06:39:04 -0700

Thanks Orly!

Can the rest of you please read and comment asap?

Thanks,
Greg

---

From: Vincent Roca <[email-masked]>
Date: Mon, 17 May 2010 17:55:55 +0200

Mark, all,

Since I already provided extensive comments on the previous version,
I only gave a quick look to version 07.
I'm happy with the new definitions (section 2) which are IMHO of utmost
importance to harmonize the vocabulary used in all the FECFRAME I-Ds
and to clarify the architectural concepts.

Therefore I support this version.

** A few easy to fix typos for draft-ietf-fecframe-framework-07:

* in section 2 (Definitions):

   - in definition of "Application protocol", the sentence mentions
   "protocols" with a final "s", but only provides a single example.
   Using singular is probably sufficient, otherwise use "protocol(s)".

   - in definition of "FEC Scheme", I suggest (parenthesis misplacement):
   "(or in the context of RMT, with the RMT FEC Building Block)."

   - the 'Encoding symbol' definition appears twice (in the
   "source symbol" definition the 1st time).

   - there's an orphan "s" in 'Source Block' definition. BTW, the
   notion of source block is already defined above. I'd remove it
   from the general subsection to keep it in the RFC5052 specific
   part.

** a few additional comments for section 10 (security considerations)

   - Nothing is said about the possibility of forging the FEC Scheme
   Specific Information, another way of launching a DoS.

   - This section refers to "source transport payloads", which is no
   longer one of the official terms defined in section 2.

   - If integrity protection is required, I don't think it makes
   sense to apply it within the "Source Protocol" (application).
   As you explain, integrity MUST be verified by the receiver ASAP,
   before launching FEC decoding. Even if the FECFRAME instance is
   able to check the integrity of source symbols before launching
   decoding, it will not cover the explicit Source FEC Payload ID
   (if used) which is a big issue.
   To summarize: if integrity is a MUST, this MUST be done in lower
   layers, within the  transport or IPsec (or similar) layers.

   - this section could be improved (it's a little bit light IMHO)
   but we can also wait for the secdir review.

Regards,

    Vincent

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 18 May 2010 10:10:25 -0700

Thanks Vincent!

Okay, that's two respondents. I can't move this forward without a few
more of you responding. Please read and send your notes and/or
approval to the list so we can move this to Pub Req ASAP!

Thanks,
Greg

---

From: "Watson, Mark" <[email-masked]>
Date: Tue, 25 May 2010 08:21:13 -0700

Well, in case it's not obvious - though I guess it is - I agree that this should go forward.

...Mark

---

From: Thomas Stockhammer <[email-masked]>
Date: Tue, 25 May 2010 17:23:55 +0200

Mark, Greg, all

I support this version to move forward ...

Thomas

>>> but we can also wait for the secdir review.

---
Dr. Thomas Stockhammer (CEO) || [email-masked] || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 25 May 2010 08:28:14 -0700

Thanks for jumping in here! Okay, I think we have enough feedback now
to proceed. I'll post the shepherding doc this week.

Greg

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 26 May 2010 14:20:38 -0700

Ditto, let's finish this so other drafts can be concluded as well.

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Stockhammer
> Sent: Tuesday, May 25, 2010 11:24 AM
> To: Watson, Mark
> Cc: [email-masked]
> Subject: Re: [Fecframe] WG Last-call: draft-ietf-fecframe-framework-07
> 
> Mark, Greg, all
> 
> Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 –
> Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.
> 
> 
> 
>