Subject: [Fecframe] AD Review: draft-ietf-fecframe-sdp-elements-06

From: "David Harrington" <[email-masked]>
Date: Fri, 9 Jul 2010 19:10:15 -0400

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: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 9 Jul 2010 18:50:26 -0700

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

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Friday, July 09, 2010 7:10 PM
> To: [email-masked]
> Subject: [Fecframe] AD Review: draft-ietf-fecframe-sdp-elements-06
> 
> Hi,
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 12 Jul 2010 14:38:16 -0700

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

> text between documents because it becomes a maintenance problem

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.
 
> 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.
 
> Does this wildcardng get sent on the wire? or is ti just internal to

I removed that part as the relevant text exists in the framework draft page 24.
 
> with FEC/<proto>? why not just use <proto>? There is no discussion of

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.
 
> 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.
 
> 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.
 
> 24) in 5.3.1, the figure shows a source flow 0, but then refers to it

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.

> addresses (that I recognize)

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

-acbegen