From watson@qualcomm.com  Tue Jul  6 10:39:35 2010
Return-Path: <watson@qualcomm.com>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB163A690E for <fecframe@core3.amsl.com>; Tue,  6 Jul 2010 10:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DALskxaDjTz0 for <fecframe@core3.amsl.com>; Tue,  6 Jul 2010 10:39:34 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id F32A43A683A for <fecframe@ietf.org>; Tue,  6 Jul 2010 10:39:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1278437974; x=1309973974; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Watson,=20Mark"=20<watson@qualcomm.com>|To:=20D avid=20Harrington=20<ietfdbh@comcast.net>|CC:=20"fecframe @ietf.org"=20<fecframe@ietf.org>|Date:=20Tue,=206=20Jul =202010=2010:39:34=20-0700|Subject:=20Re:=20[Fecframe]=20 AD=20Review:=20draft-ietf-fecframe-framework-07 |Thread-Topic:=20[Fecframe]=20AD=20Review:=20draft-ietf-f ecframe-framework-07|Thread-Index:=20AcsdMjLfjZ/O9du9RDyd RkK/cUDnNw=3D=3D|Message-ID:=20<E747F7B2-8512-4204-B94C-9 DDC468909FB@qualcomm.com>|References:=20<EE0C850812984F0E AB8D18AE381BE58B@23FX1C1>|In-Reply-To:=20<EE0C850812984F0 EAB8D18AE381BE58B@23FX1C1>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=UPyRhnkODUEztQQVdjxR3TxxKfnVadXTzYep0UX7CUU=; b=Hfvk7AIZH8LXeRHLkZ7p3JoXeH/m+k6RCsLi5DezheRXaivyRahhsGo2 fdIuxHxgpacMuP3hW+KLMevAJ3rAsILDGPlVJtSUiep0ObEDO5d2DUNNe 77xj2M1/RkSQbP9xgA9myyNftT7Gfy66ddqJvdyWm662UbtwThhyVlnlp k=;
X-IronPort-AV: E=McAfee;i="5400,1158,6035"; a="46484718"
Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 06 Jul 2010 10:39:34 -0700
X-IronPort-AV: E=Sophos;i="4.53,546,1272870000"; d="scan'208";a="38581954"
Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Jul 2010 10:39:34 -0700
Received: from nasanexhc04.na.qualcomm.com (172.30.48.17) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 6 Jul 2010 10:39:36 -0700
Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.0.694.0; Tue, 6 Jul 2010 10:39:36 -0700
Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Tue, 6 Jul 2010 10:39:29 -0700
From: "Watson, Mark" <watson@qualcomm.com>
To: David Harrington <ietfdbh@comcast.net>
Date: Tue, 6 Jul 2010 10:39:34 -0700
Thread-Topic: [Fecframe] AD Review: draft-ietf-fecframe-framework-07
Thread-Index: AcsdMjLfjZ/O9du9RDydRkK/cUDnNw==
Message-ID: <E747F7B2-8512-4204-B94C-9DDC468909FB@qualcomm.com>
References: <EE0C850812984F0EAB8D18AE381BE58B@23FX1C1>
In-Reply-To: <EE0C850812984F0EAB8D18AE381BE58B@23FX1C1>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "fecframe@ietf.org" <fecframe@ietf.org>
Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-framework-07
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2010 17:39:35 -0000

Dave,

Thanks for the comments. I have just submitted a new draft (-09) to address=
 these.

Thanks,

Mark

On Jun 23, 2010, at 4:58 AM, David Harrington wrote:

> Hi,
>=20
> I reviewed this document.
> Overall it appears to be in good shape but needs some editorial
> fix-ups.
>=20
> I am new as your Responsible AD. Let's get off on the right foot. You
> will find that your documents will get processed much faster if you at
> least spell-check them and grammar check them and idnits check them
> before sending them to me.=20
>=20
> I strongly recommend putting the definitions/abbreviations into
> alphabetical order. That would make it easier for people to find a
> definition if they are redaing later and want to doublecheck a
> definition. Doing would have also helped prevent having the duplicate
> definition of source block (bottom of page 6 and top of page 8).
>=20
> FEC Source Packet defition includes (resp. receiver) and (resp.
> received from); if you want to keep the parenthesized info here, at
> least spell out response. Personally, I think the definition would be
> easier to read without these parenthetical additions in the middle.
> use a second sentence to say "A FEC Source Packet is also the payload
> sent to a response receiver."
>=20
> Code rate - I don't find "the k/n ratio, i.e." at all necessary. The
> text following i.e., says it all. "k/n" is never used in the document
> except here. If you really think mentioning k/n is important, then add
> it after the rest of the text, with "This is often referred to as the
> k/n ratio."
>=20
> section 3 is also definitions; just include this paragraph in section
> 2.
>=20
> you should have run a spell-checker on the document. There are quite a
> few misspelled words.
> See http://tools.ietf.org/tools/idspell/webservice
>=20
> in section 4, "Since this is an interface internal" seems to be a
> run-on sentence; it is a bit hard to parse and might benefit from a
> rewrite into smaller sentecnes. Yu might try putting the example into
> a separate sentence after this sentence. or you could change
> s/explicitly, except to say that ADU/explicitly. ADU/
>=20
> in 5.3, s/may eb/may be/
> in 5.3, I'm not quite sure how to change "they may be buffered are
> delivered"
> should are be an or or an and?
> in 6.3 "the a"
> in 6.3 "of some kind" can proabbly be eliminated
> s/then in applications/in applications/
> s/length 2 bytes/length of 2 bytes/
> s/construction source/construction. Source/
>=20
> in 6.3.1, you mention wraparound from 65535 to 0, but there is no
> place in the dcoument that says the range is 0 to 65535.
>=20
> s/Configuation/Configuration/
> in 6.5 "known as the FEC repair flow(s). - that's not what you called
> them in the definitions section.
>=20
> s/as describe/as decribed/
> s/Defintion/Definition/
>=20
> "for this flow definition (ie.e. tuple) - please be consistent in your
> use of terminology. Use the terms defined in section 2.
>=20
> in 6.5 s/may/MAY/
>=20
> in 6.6, s/"name"_production/"name" production/
> s/"value"_production/"value" production/
>=20
> in 7, paragraph 2, I found the comaprisons of time versus block size
> jarring. I am not sure hwo to best reword this. Maybe FEC i sgenerally
> applied to data in relatively small blocks of time, and ... over
> longer periods of time will likely ...
>=20
> s/Applicatinos which used/Applications which use/
>=20
> section 8 is so concise I have no idea what it means. This is a
> framework. I can understand when a protocol supports specific
> transports, but saying a framework does seems out of place. Please
> expand this.
>=20
> s/result link-layer/result of link-layer/
>=20
> in section 9, s/this section implements/section 9.1 specifies/
>=20
> in section10, s/distribute and decode data/distribute and decode
> encrypted data/=20
>=20
> Mark, can you get me a revised ID so I can request an IETF Last Call?
>=20
> Chairs, we will need an expert for the "IETF Consensus" FEC Encoding
> IDs. Can you send me recommendations in a separate email?
>=20
> Thanks,
> dbh
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe


From root@core3.amsl.com  Tue Jul  6 10:45:02 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: fecframe@ietf.org
Delivered-To: fecframe@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 825CF3A688A; Tue,  6 Jul 2010 10:45:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100706174502.825CF3A688A@core3.amsl.com>
Date: Tue,  6 Jul 2010 10:45:02 -0700 (PDT)
Cc: fecframe@ietf.org
Subject: [Fecframe] I-D Action:draft-ietf-fecframe-framework-09.txt
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2010 17:45:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the FEC Framework Working Group of the IETF.


	Title           : Forward Error Correction (FEC) Framework
	Author(s)       : M. Watson
	Filename        : draft-ietf-fecframe-framework-09.txt
	Pages           : 38
	Date            : 2010-07-06

This document describes a framework for using forward error
correction (FEC) codes with applications in public and private IP
networks to provide protection against packet loss.  The framework
supports applying Forward Error Correction to arbitrary packet flows
over unreliable transport and is primarily intended for real-time, or
streaming, media.  This framework can be used to define Content
Delivery Protocols that provide Forward Error Correction for
streaming media delivery or other packet flows.  Content Delivery
Protocols defined using this framework can support any FEC Scheme
(and associated FEC codes) which is compliant with various
requirements defined in this document.  Thus, Content Delivery
Protocols can be defined which are not specific to a particular FEC
Scheme and FEC Schemes can be defined which are not specific to a
particular Content Delivery Protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-framework-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-fecframe-framework-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-07-06103857.I-D@ietf.org>


--NextPart--

From ietfdbh@comcast.net  Fri Jul  9 16:10:14 2010
Return-Path: <ietfdbh@comcast.net>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6243A684A for <fecframe@core3.amsl.com>; Fri,  9 Jul 2010 16:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.846
X-Spam-Level: 
X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPH9gOsI54iO for <fecframe@core3.amsl.com>; Fri,  9 Jul 2010 16:10:08 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 94C7C3A685A for <fecframe@ietf.org>; Fri,  9 Jul 2010 16:10:07 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id fyeU1e00A0bG4ec5AzACRr; Fri, 09 Jul 2010 23:10:12 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta03.westchester.pa.mail.comcast.net with comcast id fzAC1e0042JQnJT3PzACed; Fri, 09 Jul 2010 23:10:12 +0000
From: "David Harrington" <ietfdbh@comcast.net>
To: <fecframe@ietf.org>
Date: Fri, 9 Jul 2010 19:10:15 -0400
Message-ID: <C18B558F0B474A23821F296A5330312B@23FX1C1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acsfu+PpmYDTf6smTlqIDPLox25AFQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
Subject: [Fecframe] AD Review: draft-ietf-fecframe-sdp-elements-06
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jul 2010 23:10:15 -0000

Hi,

I have reviewed draft-ietf-fecframe-sdp-elements-06 and have some
comments.
I am new to fecframe, so some of these questions might be stupid ;-)

1) is section 3 really needed? Can't we just use a pointer to the
framework doc?
It is generally considered a bad practice to carry lots of duplicative
text between documents because it becomes a maintenance problem
keeping them in sync.

2) in 3.2, there is a paragraph that discusses the purpose of this
document. I recommend keeponig a clear differentiation between the
fecframe description and the discussions specific to this document.

3) Is this specification related to RFC5052 or to fecframe framework
or to both? If this is relevant to one of these, why bother to mention
the other in this document? It seems apparent that this SDP spec is
related to framework, since you devote section 3.2 to describing
framework. (I know this paragraph is just copied from framework, but
it certainly seems unnecessary here, even if a background on framework
is justified.)

4) in 3.3, the last sentence is not needed, since this is an
implementation internal detail, right?

5) in 3.3, 2b, why is the zero start only a SHOULD rather than a MUST?
If the numbering isn't actually critical enough to require a MUST, why
does it require a SHOULD? (also mentioned in 5.3)

6) in 3.3., 2b, Would the standard be tighter if we didn't have
wildcards? why is wildcarding needed? It is unclear from the wording.
Does this wildcardng get sent on the wire? or is ti just internal to
an application?

7) section 3.3 says Each instance of FEC framework MUST provide the
following FEC Framework Configuration Information, and lists 6 things.
But then there is no claer demarcation between the list of six things
and the FSSI which is not required by the FEC framework. You should
have a clear separation of what is FEC-framework and what is this
specification.

8) the list of items in 3.3 uses different wording that section 5.5 in
the framework document. (ee what I mean about maintaining sync?) In
fact, you list six thibsg as being required by FEC framework, but FEC
framework only lists 5.

9) I think section 4 (the beginnig part is too light. framework
doesn't even mention session descriptors. I had to look in 5052 to
find any mention of session descriptors, and even there it is only
mentioned in the security considerations. I ralize I am new to the
topic, but I think you should describe what a session descriptor is
used for before definign a specific SDP data model.

10) section 4.1 does not provide a reference to the existing <proto>
identifiers, or to any background on transport protocols and SDP media
descriptions.

11) in 4.1, why do we need to duplicate all the <proto> identifiers
with FEC/<proto>? why not just use <proto>? There is no discussion of
why this is necessary.

12) section 4.2 describes what framework says about multiple flows,
and what 4756bis says about additive repair flows.This seems highly
redundant with the other documents and totally unnecessary.  Is
anything in this section about what THIS spefication (sdp-elements) is
defining - the specific SDP description of parameters of configuration
information?

I am beginning to wonder if we really only needed one document that
contained all the info in 4756bis, framework, and this doc.

13) in section 4.4, where is MANDATORY defined? It is not an RFC2119
keyword. It is not from RFC5234. 

14) in section 4.4, "The OPTIONAL 'tag-len' parameter is used to
specify the length of the
   Explicit Source FEC Payload ID field (in bytes) and MUST be used
   according to the requirements listed in Section 4.2." 

It is not very clear whether tag-len MUST be used or is OPTIONAL. 

Section 4.2 doesn't even mention tag-len.


15) in 4.5, is the MUST NOT a normative statement being defined here,
or is this normative behavior defined in framework?

16) the terminology section of framework defines "repair data flow";
you refer to "repair flow", which is not defined in framework
(although framework uses "repair flow" 15 times without defining it).
4756bis uses "repair flow" and never uses "repair data flow"

These documents MUST be consistent in the use of terminology. 

17) the use of RFC2119 keywords to specify compliance is very uneven. 
"receivers are encouraged", "decoder may", "the dafault unit is"
These should and other places should be specified using RFC2119
keywords.

18) alterntive units may be defined int he future by registering them
with IANA. This stamenet needs to identify the registry in which they
will be registered, and the process for registering ala RFC5226.

I question why we need this at all.

19) section 4.7 makes a bunch of recommendations. What happens to
introperability if some do and some don't? This is a standard we are
writing; why not specify this so that the behavior is predictable and
interoperable? 

If you keep the RECOMMENDED (which is the same as  a SHOULD):
   SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

You should specify under which conditions an alternative is
acceptable.

20) section 5 starst to discuss answer offer model considerations, and
provides some SDP examples that can be used for fecframe. Thsi seems
to change the focus from the fecframe to offer/answer discussion,
which seems odd in a document entitled SDP for Fecframe. I think this
isnjust a wording/style issue, btu I find it incongruous. Would it be
good to seperate the operational considerations frmo the examples?

21) section 5.1 specifies that receivers SHOULD NOT send responses,
but it doesn't discuss why this is a SHOULD NOT.

22) section 5.2 seems inconsistent with itself. "sender offers all"
versus "some options MAY be offered only to ..." 
I think this needsn to be tightened up, using RFC2119 keywords, so it
is clearer what behavior is required for compliance and what is not.

23) I found it rather confusing why SDP elements for fecframe are
defined in multiple documents. The IESG raised a similar concern when
faced with 4756bis and 3388bis. Is there a roadmap someplace that
specifies which document is responsible for which logical pieces, so a
reader can make sense of 4756bis, 3388bis, framework, and
fecframe-sdp? The current documents don't seem very clear on that.

24) in 5.3.1, the figure shows a source flow 0, but then refers to it
in text as S1. 

25) missing examples for tag-len and preference-lvl.

26) is the address space used in the examples from address space
reserved for examples? There is no reference for an rFC wit example
addresses (that I recognize)

27) the first part of 7 really isn't needed, since A Begen is the
author of this specifiation, so it's obvious who to consult.

28) in 7.1, please identify the IANA registry in which this should be
regitered.

29) in 7.2, "See this document" won't be meaningful if it is read from
a registry.
It would be nice to provide a one-liner description.

30) security considerations seems awfully light to me. You might want
to add a pointer to the secCons of framework, which is a bit more
detailed, to supplement what you have.






From abegen@cisco.com  Fri Jul  9 18:50:23 2010
Return-Path: <abegen@cisco.com>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBDF3A659A for <fecframe@core3.amsl.com>; Fri,  9 Jul 2010 18:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wemV-0+idIk0 for <fecframe@core3.amsl.com>; Fri,  9 Jul 2010 18:50:22 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8CCDA3A68D9 for <fecframe@ietf.org>; Fri,  9 Jul 2010 18:50:21 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKZuN0xAZnwN/2dsb2JhbACgSnGkHJo+gl6CSQSDeYZ9
X-IronPort-AV: E=Sophos;i="4.55,176,1278288000"; d="scan'208";a="130668317"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2010 01:50:26 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6A1oQNX019051; Sat, 10 Jul 2010 01:50:26 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 9 Jul 2010 18:50:25 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 9 Jul 2010 18:50:26 -0700
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540C8F22CE@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <C18B558F0B474A23821F296A5330312B@23FX1C1>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] AD Review: draft-ietf-fecframe-sdp-elements-06
Thread-Index: Acsfu+PpmYDTf6smTlqIDPLox25AFQAFkSsg
References: <C18B558F0B474A23821F296A5330312B@23FX1C1>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "David Harrington" <ietfdbh@comcast.net>, <fecframe@ietf.org>
X-OriginalArrivalTime: 10 Jul 2010 01:50:25.0929 (UTC) FILETIME=[44470790:01CB1FD2]
Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-sdp-elements-06
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Jul 2010 01:50:23 -0000

Thanks David, I will try to submit a revision before Monday's deadline.

-acbegen

> -----Original Message-----
> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On =
Behalf Of David Harrington
> Sent: Friday, July 09, 2010 7:10 PM
> To: fecframe@ietf.org
> Subject: [Fecframe] AD Review: draft-ietf-fecframe-sdp-elements-06
>=20
> Hi,
>=20
> I have reviewed draft-ietf-fecframe-sdp-elements-06 and have some
> comments.
> I am new to fecframe, so some of these questions might be stupid ;-)
>=20
> 1) is section 3 really needed? Can't we just use a pointer to the
> framework doc?
> It is generally considered a bad practice to carry lots of duplicative
> text between documents because it becomes a maintenance problem
> keeping them in sync.
>=20
> 2) in 3.2, there is a paragraph that discusses the purpose of this
> document. I recommend keeponig a clear differentiation between the
> fecframe description and the discussions specific to this document.
>=20
> 3) Is this specification related to RFC5052 or to fecframe framework
> or to both? If this is relevant to one of these, why bother to mention
> the other in this document? It seems apparent that this SDP spec is
> related to framework, since you devote section 3.2 to describing
> framework. (I know this paragraph is just copied from framework, but
> it certainly seems unnecessary here, even if a background on framework
> is justified.)
>=20
> 4) in 3.3, the last sentence is not needed, since this is an
> implementation internal detail, right?
>=20
> 5) in 3.3, 2b, why is the zero start only a SHOULD rather than a MUST?
> If the numbering isn't actually critical enough to require a MUST, why
> does it require a SHOULD? (also mentioned in 5.3)
>=20
> 6) in 3.3., 2b, Would the standard be tighter if we didn't have
> wildcards? why is wildcarding needed? It is unclear from the wording.
> Does this wildcardng get sent on the wire? or is ti just internal to
> an application?
>=20
> 7) section 3.3 says Each instance of FEC framework MUST provide the
> following FEC Framework Configuration Information, and lists 6 things.
> But then there is no claer demarcation between the list of six things
> and the FSSI which is not required by the FEC framework. You should
> have a clear separation of what is FEC-framework and what is this
> specification.
>=20
> 8) the list of items in 3.3 uses different wording that section 5.5 in
> the framework document. (ee what I mean about maintaining sync?) In
> fact, you list six thibsg as being required by FEC framework, but FEC
> framework only lists 5.
>=20
> 9) I think section 4 (the beginnig part is too light. framework
> doesn't even mention session descriptors. I had to look in 5052 to
> find any mention of session descriptors, and even there it is only
> mentioned in the security considerations. I ralize I am new to the
> topic, but I think you should describe what a session descriptor is
> used for before definign a specific SDP data model.
>=20
> 10) section 4.1 does not provide a reference to the existing <proto>
> identifiers, or to any background on transport protocols and SDP media
> descriptions.
>=20
> 11) in 4.1, why do we need to duplicate all the <proto> identifiers
> with FEC/<proto>? why not just use <proto>? There is no discussion of
> why this is necessary.
>=20
> 12) section 4.2 describes what framework says about multiple flows,
> and what 4756bis says about additive repair flows.This seems highly
> redundant with the other documents and totally unnecessary.  Is
> anything in this section about what THIS spefication (sdp-elements) is
> defining - the specific SDP description of parameters of configuration
> information?
>=20
> I am beginning to wonder if we really only needed one document that
> contained all the info in 4756bis, framework, and this doc.
>=20
> 13) in section 4.4, where is MANDATORY defined? It is not an RFC2119
> keyword. It is not from RFC5234.
>=20
> 14) in section 4.4, "The OPTIONAL 'tag-len' parameter is used to
> specify the length of the
>    Explicit Source FEC Payload ID field (in bytes) and MUST be used
>    according to the requirements listed in Section 4.2."
>=20
> It is not very clear whether tag-len MUST be used or is OPTIONAL.
>=20
> Section 4.2 doesn't even mention tag-len.
>=20
>=20
> 15) in 4.5, is the MUST NOT a normative statement being defined here,
> or is this normative behavior defined in framework?
>=20
> 16) the terminology section of framework defines "repair data flow";
> you refer to "repair flow", which is not defined in framework
> (although framework uses "repair flow" 15 times without defining it).
> 4756bis uses "repair flow" and never uses "repair data flow"
>=20
> These documents MUST be consistent in the use of terminology.
>=20
> 17) the use of RFC2119 keywords to specify compliance is very uneven.
> "receivers are encouraged", "decoder may", "the dafault unit is"
> These should and other places should be specified using RFC2119
> keywords.
>=20
> 18) alterntive units may be defined int he future by registering them
> with IANA. This stamenet needs to identify the registry in which they
> will be registered, and the process for registering ala RFC5226.
>=20
> I question why we need this at all.
>=20
> 19) section 4.7 makes a bunch of recommendations. What happens to
> introperability if some do and some don't? This is a standard we are
> writing; why not specify this so that the behavior is predictable and
> interoperable?
>=20
> If you keep the RECOMMENDED (which is the same as  a SHOULD):
>    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
>=20
> You should specify under which conditions an alternative is
> acceptable.
>=20
> 20) section 5 starst to discuss answer offer model considerations, and
> provides some SDP examples that can be used for fecframe. Thsi seems
> to change the focus from the fecframe to offer/answer discussion,
> which seems odd in a document entitled SDP for Fecframe. I think this
> isnjust a wording/style issue, btu I find it incongruous. Would it be
> good to seperate the operational considerations frmo the examples?
>=20
> 21) section 5.1 specifies that receivers SHOULD NOT send responses,
> but it doesn't discuss why this is a SHOULD NOT.
>=20
> 22) section 5.2 seems inconsistent with itself. "sender offers all"
> versus "some options MAY be offered only to ..."
> I think this needsn to be tightened up, using RFC2119 keywords, so it
> is clearer what behavior is required for compliance and what is not.
>=20
> 23) I found it rather confusing why SDP elements for fecframe are
> defined in multiple documents. The IESG raised a similar concern when
> faced with 4756bis and 3388bis. Is there a roadmap someplace that
> specifies which document is responsible for which logical pieces, so a
> reader can make sense of 4756bis, 3388bis, framework, and
> fecframe-sdp? The current documents don't seem very clear on that.
>=20
> 24) in 5.3.1, the figure shows a source flow 0, but then refers to it
> in text as S1.
>=20
> 25) missing examples for tag-len and preference-lvl.
>=20
> 26) is the address space used in the examples from address space
> reserved for examples? There is no reference for an rFC wit example
> addresses (that I recognize)
>=20
> 27) the first part of 7 really isn't needed, since A Begen is the
> author of this specifiation, so it's obvious who to consult.
>=20
> 28) in 7.1, please identify the IANA registry in which this should be
> regitered.
>=20
> 29) in 7.2, "See this document" won't be meaningful if it is read from
> a registry.
> It would be nice to provide a one-liner description.
>=20
> 30) security considerations seems awfully light to me. You might want
> to add a pointer to the secCons of framework, which is a bit more
> detailed, to supplement what you have.
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe

From abegen@cisco.com  Mon Jul 12 14:38:20 2010
Return-Path: <abegen@cisco.com>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE823A6B6B for <fecframe@core3.amsl.com>; Mon, 12 Jul 2010 14:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnkqTcDwcYKf for <fecframe@core3.amsl.com>; Mon, 12 Jul 2010 14:38:19 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 54D773A6A62 for <fecframe@ietf.org>; Mon, 12 Jul 2010 14:38:19 -0700 (PDT)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEANsnO0yrRN+K/2dsb2JhbACgOHGkf5p7hScEg3uGfw
X-IronPort-AV: E=Sophos;i="4.55,190,1278288000"; d="scan'208";a="343235031"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 12 Jul 2010 21:38:27 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6CLcRij024919; Mon, 12 Jul 2010 21:38:27 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 12 Jul 2010 14:38:27 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Jul 2010 14:38:16 -0700
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540C9A762D@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <C18B558F0B474A23821F296A5330312B@23FX1C1>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] AD Review: draft-ietf-fecframe-sdp-elements-06
Thread-Index: Acsfu+PpmYDTf6smTlqIDPLox25AFQCN7lYQ
References: <C18B558F0B474A23821F296A5330312B@23FX1C1>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "David Harrington" <ietfdbh@comcast.net>, <fecframe@ietf.org>
X-OriginalArrivalTime: 12 Jul 2010 21:38:27.0570 (UTC) FILETIME=[9045C520:01CB220A]
Subject: Re: [Fecframe] AD Review: draft-ietf-fecframe-sdp-elements-06
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2010 21:38:20 -0000

I addressed most of the comments in the new version. Some comments are =
inline.=20

> 1) is section 3 really needed? Can't we just use a pointer to the
> framework doc?
> It is generally considered a bad practice to carry lots of duplicative
> text between documents because it becomes a maintenance problem
> keeping them in sync.

Some of the text is actually better repeated here so that a reader can =
follow the discussion from this spec only. I tried to reduce the overlap =
in the new version, though.
=20
> 5) in 3.3, 2b, why is the zero start only a SHOULD rather than a MUST?
> If the numbering isn't actually critical enough to require a MUST, why
> does it require a SHOULD? (also mentioned in 5.3)

The requirement comes from the framework draft (page 25). I am fine to =
change it to MUST, if agreed.
=20
> 6) in 3.3., 2b, Would the standard be tighter if we didn't have
> wildcards? why is wildcarding needed? It is unclear from the wording.
> Does this wildcardng get sent on the wire? or is ti just internal to
> an application?

I removed that part as the relevant text exists in the framework draft =
page 24.
=20
> 11) in 4.1, why do we need to duplicate all the <proto> identifiers
> with FEC/<proto>? why not just use <proto>? There is no discussion of
> why this is necessary.

FEC/proto is needed in case Explicit Source FEC Payload ID is used. If =
that is not used meaning that source packets are untouched, using proto =
is just fine as stated in the text.
=20
> 16) the terminology section of framework defines "repair data flow";
> you refer to "repair flow", which is not defined in framework
> (although framework uses "repair flow" 15 times without defining it).
> 4756bis uses "repair flow" and never uses "repair data flow"
>=20
> These documents MUST be consistent in the use of terminology.

Agreed. The framework draft should fix its definition.

I also think it should be "source flow", not "source data flow" to be =
more consistent with "repair flow". The framework draft uses both but =
should stick with one.
=20
> 23) I found it rather confusing why SDP elements for fecframe are
> defined in multiple documents. The IESG raised a similar concern when
> faced with 4756bis and 3388bis. Is there a roadmap someplace that
> specifies which document is responsible for which logical pieces, so a
> reader can make sense of 4756bis, 3388bis, framework, and
> fecframe-sdp? The current documents don't seem very clear on that.

3388bis is the general grouping framework for SDP, not 1:1 related to =
fecframe. 4756bis is the grouping semantics for fecframe but it was =
completed as a separate draft from this draft as their scopes were =
different.

However, if you think it is a good idea and WG agrees, we can move this =
draft into the framework draft. As both are almost complete, there won't =
be much delay to do the integration.
=20
> 24) in 5.3.1, the figure shows a source flow 0, but then refers to it
> in text as S1.

They do not necessarily need to match, they are different things in the =
SDP. But anyway, I tried to match the figures to the examples better.

> 26) is the address space used in the examples from address space
> reserved for examples? There is no reference for an rFC wit example
> addresses (that I recognize)

Yes, they are the ones suggested to use in RFCs.

-acbegen

From root@core3.amsl.com  Mon Jul 12 14:45:03 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: fecframe@ietf.org
Delivered-To: fecframe@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 5968B3A6B9D; Mon, 12 Jul 2010 14:45:03 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100712214503.5968B3A6B9D@core3.amsl.com>
Date: Mon, 12 Jul 2010 14:45:03 -0700 (PDT)
Cc: fecframe@ietf.org
Subject: [Fecframe] I-D Action:draft-ietf-fecframe-sdp-elements-07.txt
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2010 21:45:03 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the FEC Framework Working Group of the IETF.


	Title           : Session Description Protocol (SDP) Elements for FEC Framework
	Author(s)       : A. Begen
	Filename        : draft-ietf-fecframe-sdp-elements-07.txt
	Pages           : 19
	Date            : 2010-07-12

This document specifies the use of Session Description Protocol (SDP)
to describe the parameters required to signal the Forward Error
Correction (FEC) Framework Configuration Information between the
sender(s) and receiver(s).  This document also provides examples that
show the semantics for grouping multiple source and repair flows
together for the applications that simultaneously use multiple
instances of the FEC Framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-sdp-elements-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-fecframe-sdp-elements-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-07-12143550.I-D@ietf.org>


--NextPart--

From abegen@cisco.com  Mon Jul 12 15:04:46 2010
Return-Path: <abegen@cisco.com>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED91B3A6B63 for <fecframe@core3.amsl.com>; Mon, 12 Jul 2010 15:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVJMmXQq8Kms for <fecframe@core3.amsl.com>; Mon, 12 Jul 2010 15:04:44 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BA3573A687A for <fecframe@ietf.org>; Mon, 12 Jul 2010 15:04:44 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArsFAKcuO0yrR7Hu/2dsb2JhbACTdoxCcaRkmn2FJwSDe4Z/
X-IronPort-AV: E=Sophos;i="4.55,190,1278288000"; d="scan'208";a="225267349"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 12 Jul 2010 22:04:53 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6CM4r8A009131 for <fecframe@ietf.org>; Mon, 12 Jul 2010 22:04:53 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Jul 2010 15:04:52 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
x-cr-hashedpuzzle: BJso CDjz CaLj CkY7 C2nz DP/L DhCq DtYN EBM3 E88j Gmb4 H00x IlvA JJ0Y Jz2e KdWC; 1; ZgBlAGMAZgByAGEAbQBlAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {606C2A0F-28EA-43B1-B12B-99AC19BD0730}; YQBiAGUAZwBlAG4AQABjAGkAcwBjAG8ALgBjAG8AbQA=; Mon, 12 Jul 2010 22:04:24 GMT; UwBEAFAAIABxAHUAZQBzAHQAaQBvAG4AIABpAG4AIAB0AGgAZQAgAGYAcgBhAG0AZQB3AG8AcgBrACAAZAByAGEAZgB0AA==
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
x-cr-puzzleid: {606C2A0F-28EA-43B1-B12B-99AC19BD0730}
Content-class: urn:content-classes:message
Date: Mon, 12 Jul 2010 15:04:24 -0700
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540C9A7655@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SDP question in the framework draft
Thread-Index: Acsfu+PpmYDTf6smTlqIDPLox25AFQAFuXEA
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: <fecframe@ietf.org>
X-OriginalArrivalTime: 12 Jul 2010 22:04:52.0669 (UTC) FILETIME=[4110AED0:01CB220E]
Subject: [Fecframe] SDP question in the framework draft
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2010 22:04:46 -0000

When I was revising the SDP draft today, I saw the following part in the =
framework draft.

This seems to be a more complete definition for the FSSI containers. My =
question is whether we should move this to the SDP draft or not.

What do you think?

-acbegen

Page: 26 of =
http://tools.ietf.org/id/draft-ietf-fecframe-framework-09.txt

   FEC Scheme-specific information elements MAY be encoded into a text
   string for transport within Content Delivery Protocols as according
   to the following ABNF [RFC5234]:

          scheme-specific-info  =3D [ element *( ',' element ) ]
          element               =3D name ':' value
          name                  =3D token
          token                 =3D 1*<any CHAR except CTLs or =
separators>
          value                 =3D *<any CHAR except CTLs or =
separators>
          separators            =3D "(" | ")" | "<" | ">" | "@"
                                | "," | ";" | ":" | "\" | <">
                                | "/" | "[" | "]" | "?" | "=3D"
                                | "{" | "}" | SP | HT

From gjshep@gmail.com  Tue Jul 13 10:41:11 2010
Return-Path: <gjshep@gmail.com>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138A73A6902 for <fecframe@core3.amsl.com>; Tue, 13 Jul 2010 10:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJVG6XjdgAo6 for <fecframe@core3.amsl.com>; Tue, 13 Jul 2010 10:41:08 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 5BF413A6B40 for <fecframe@ietf.org>; Tue, 13 Jul 2010 10:41:05 -0700 (PDT)
Received: by ywa8 with SMTP id 8so528890ywa.31 for <fecframe@ietf.org>; Tue, 13 Jul 2010 10:41:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=tIc+5DJgWTxxtq7AG3xzZUrL9Xql5v4SNrSG51QW3Ns=; b=OlihAfIpAF1U1AFlNwiRerm/jCZELUEIuAOf/sGajKx7+RS8R4HM3SkbuSD6pjWjS1 m7toluSfuWLF7g+eLjv/jUnilCqC6sPt8BRXnOurZubns2lhAmyf+RiE0FFLUgKf6wbS +/YGSuJ+/A30ZLZxyOvUkEPSn2lThAkmE6erk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=Z0eESd7oCknOgwMNaPqIe9y36QyocMt8rR5pjEtQRK6zxS9RBSo/8J5Ci7uTlerRbN VU2ZhCfFDKb204Rraa7vGM/xxxT2UiMsPuPbqT3Rm3ZcSCsm3ss4+na//Fd2RqFcfXNh 52GFj6vq49oNsbJEliRcUN6h/xDus5VjVHvX8=
MIME-Version: 1.0
Received: by 10.100.254.15 with SMTP id b15mr17472800ani.144.1279042871187;  Tue, 13 Jul 2010 10:41:11 -0700 (PDT)
Received: by 10.231.171.130 with HTTP; Tue, 13 Jul 2010 10:41:11 -0700 (PDT)
Date: Tue, 13 Jul 2010 10:41:11 -0700
Message-ID: <AANLkTimqbUGP2QZjMM8sQnHGH4JadrRkGrXdhn8nh2mN@mail.gmail.com>
From: Greg Shepherd <gjshep@gmail.com>
To: fecframe@ietf.org
Content-Type: multipart/alternative; boundary=0016369fa374fd6b00048b485f1f
Subject: [Fecframe] Call for Agenda Items
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: gjshep@gmail.com
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jul 2010 17:41:11 -0000

--0016369fa374fd6b00048b485f1f
Content-Type: text/plain; charset=ISO-8859-1

Please send me your request for an agenda slot ASAP. This meeting should be
quick as we are very close to wrapping up the work. I'll be updating our
milestones before the meeting and we can go over that as well.

Safe travels,
Greg

--0016369fa374fd6b00048b485f1f
Content-Type: text/html; charset=ISO-8859-1

Please send me your request for an agenda slot ASAP. This meeting should be quick as we are very close to wrapping up the work. I&#39;ll be updating our milestones before the meeting and we can go over that as well.<br><br>
Safe travels,<br>Greg<br>

--0016369fa374fd6b00048b485f1f--

From gjshep@gmail.com  Thu Jul 22 08:56:57 2010
Return-Path: <gjshep@gmail.com>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34EB43A67B8 for <fecframe@core3.amsl.com>; Thu, 22 Jul 2010 08:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.41
X-Spam-Level: 
X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gzaga6zM-WS for <fecframe@core3.amsl.com>; Thu, 22 Jul 2010 08:56:56 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 469503A6889 for <fecframe@ietf.org>; Thu, 22 Jul 2010 08:56:56 -0700 (PDT)
Received: by gxk1 with SMTP id 1so4994380gxk.31 for <fecframe@ietf.org>; Thu, 22 Jul 2010 08:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type; bh=8yrCG65zp5egUtmeH/yqPj+P8TQBsH7eKu2N/sT2EcE=; b=TvScMDWodrL+IWMno1wNdMQr12jGasI/Bjf1Iy/iCUaysAv05WGbbgg35uB9jH8Yvz J/LYCedqj9riMGbDuuCXmgbsevAP7sYuaOskNNDuy1Zvi6EBthKQJxGeh0spS7IoDK8m +9ofezh66/WRBlWL0+PYXLmiXNeRrqF4fyV0w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=MOO316wbLn4NxLl0X7ERLHcYVTu6vRJd1X8A9MFiek8qB5+A1oHElD7ak3SnkXf1+e 9HImkiZbpRTkHftzfhdAgDnkXltl9luys4gTtD/bXDVub/DEq2RGD1LHCFWgPJ3LE29t FX5faEUKYJc3qNPq9NRk5rk7tL+mRvXAs+zhQ=
MIME-Version: 1.0
Received: by 10.101.28.26 with SMTP id f26mr2367499anj.149.1279814233408; Thu,  22 Jul 2010 08:57:13 -0700 (PDT)
Received: by 10.231.171.149 with HTTP; Thu, 22 Jul 2010 08:57:09 -0700 (PDT)
In-Reply-To: <AANLkTimqbUGP2QZjMM8sQnHGH4JadrRkGrXdhn8nh2mN@mail.gmail.com>
References: <AANLkTimqbUGP2QZjMM8sQnHGH4JadrRkGrXdhn8nh2mN@mail.gmail.com>
Date: Thu, 22 Jul 2010 08:57:09 -0700
Message-ID: <AANLkTimzmSQS3kJ7itbt2dSeLbMM6YYA=Y=k=9d2AgW4@mail.gmail.com>
From: Greg Shepherd <gjshep@gmail.com>
To: fecframe@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Fecframe] Call for Agenda Items
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: gjshep@gmail.com
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jul 2010 15:56:57 -0000

Here's is a draft agenda for next week. Please send me any
updates/corrections as I'll be posting this later today.

Safe travels,
Greg
-------

IETF 78, Maastricht, Netherlands
FECFrame WG Meeting

Thurs, July 29, 2010
1300 - 0.8 Rome

Welcome / Agenda Bashing			10min
Chair

draft-roca-fecframe-rs				10min
Vincent Roca

Current Drafts Status				10min
Chair

Updated WG Milestones				10min
Chair

Wrap

On Tue, Jul 13, 2010 at 10:41 AM, Greg Shepherd <gjshep@gmail.com> wrote:
> Please send me your request for an agenda slot ASAP. This meeting should be
> quick as we are very close to wrapping up the work. I'll be updating our
> milestones before the meeting and we can go over that as well.
>
> Safe travels,
> Greg
>