Forward Error Correction Grouping Semantics in Session Description Protocol
draft-ietf-mmusic-fec-grouping-05

[Ballot comment]
Some notes to consider From: "Mark Watson"

>
> Hi,
>
> The following comments rather minor. Sorry for missing the WG last
> call:
>
> 1) Section 3, 3rd para, 1st sentence of third paragraph "When FEC data
> are multiplexed with the original payload stream, the association
> relationship is indicated as specified in RTP Payload for Redundant
> Audio Data (RFC 2198) [4]."
>
> I think RFC2198 is just an example here. The point is that in this
> case
> the relationship between media and FEC is specified within a single
> media component of the SDP. I suggest the following re-wording:
>
> "When FEC data are multiplexed with the original payload stream, the
> association relationship is generally indicated within a single media
> line, for example as specified in "An RTP Payload for Redundant Audio
> Data" (RFC 2198) [4]."
>
> 2) Section 3, 3rd para, 2nd sentence, "As an example, such
> relationship
> can be indicated as in the generic RFC payload format for FEC [5]."
>
> I think this should be "This approach is one of the options
> described in
> "An RTP payload format for generic FEC" [5]."
>
> 3) 4.1, 3rd para, 5th line: the reference to [5] needs to be corrected
> (the title is wrong and the RFC YYYY should be removed or replaced
> with
> the RFC number if it has been allocated).
>
> 4) 4.2, 2nd para, this paragraph appears to place a "SHOULD"
> requirement
> on equipment which does not support this draft, which seems rather
> paradoxical. If anything, this paragraph should contain informative
> text
> which repeats the relevant forward-compatibility requirements of SDP
> (for the case that the grouping attribute is not supported -
> specifically, the attribute is ignored) or of the SDP grouping
> mechanism
> (for the case that just the FEC semantics are not supported -
> specifically, the behaviour in this case appears to be undefined).
>
> 4) Section 9.2, Reference [5], the title is wrong
>

Some notes to consider in Auth 48  From: "Mark Watson"

>
> 1) Section 3, 3rd para, 1st sentence of third paragraph "When FEC data
> are multiplexed with the original payload stream, the association
> relationship is indicated as specified in RTP Payload for Redundant
> Audio Data (RFC 2198) [4]."
>
> I think RFC2198 is just an example here. The point is that in this
> case
> the relationship between media and FEC is specified within a single
> media component of the SDP. I suggest the following re-wording:
>
> "When FEC data are multiplexed with the original payload stream, the
> association relationship is generally indicated within a single media
> line, for example as specified in "An RTP Payload for Redundant Audio
> Data" (RFC 2198) [4]."
>
> 2) Section 3, 3rd para, 2nd sentence, "As an example, such
> relationship
> can be indicated as in the generic RFC payload format for FEC [5]."
>
> I think this should be "This approach is one of the options
> described in
> "An RTP payload format for generic FEC" [5]."
>
> 3) 4.1, 3rd para, 5th line: the reference to [5] needs to be corrected
> (the title is wrong and the RFC YYYY should be removed or replaced
> with
> the RFC number if it has been allocated).
>
> 4) 4.2, 2nd para, this paragraph appears to place a "SHOULD"
> requirement
> on equipment which does not support this draft, which seems rather
> paradoxical. If anything, this paragraph should contain informative
> text
> which repeats the relevant forward-compatibility requirements of SDP
> (for the case that the grouping attribute is not supported -
> specifically, the attribute is ignored) or of the SDP grouping
> mechanism
> (for the case that just the FEC semantics are not supported -
> specifically, the behaviour in this case appears to be undefined).
>
> 4) Section 9.2, Reference [5], the title is wrong
>

[Ballot discuss]
Why is the SDP specification a informative reference?  At a minimum,
  the text in the security considerations ought to make it a normative
  reference.

IANA Last Call Comment:

Upon approval of this document, the IANA will make the following assignments
in the xxx registry located at
http://www.iana.org/assignments/sdp-parameters
table: "group" SDP Attribute

Forward Error Correction FEC [RFC-mmusic-fec-grouping-05]

We understand the above to be the only IANA Actions for this document.

[Ballot discuss]
Why is the SDP specification a normative reference?  At a minimum,
  the text in the security considerations ought to make it a normative
  reference.

[Ballot comment]
Section 3, third paragraph:

  When FEC data are multiplexed with the original payload stream, the
  association relationship is indicated as specified in RTP Payload for
  Redundant Audio Data (RFC 2198) [4]. As an example, such relationship
  can be indicated as in the generic RFC payload format for FEC [5].

I would like to change this to clear that RFC 2198 is an defined for ULP and not necessarily binding for all future FEC schemes that multiplex data and FEC repair data on the same flow.

  When FEC data are multiplexed with the original payload stream, the
  association relationship may for example be indicated as specified in
  RTP Payload for Redundant Audio Data (RFC 2198) [4].  The generic RFC
  payload format for FEC [5] uses that method.
 
Section 5:

There is a lack of reference in the following:
                        It is recommended that the receiver
  SHOULD do integrity check on SDP and follow the security
  considerations of SDP to only trust SDP from trusted sources.

Please change that to:
                        It is recommended that the receiver
  SHOULD do integrity check on SDP and follow the security
  considerations of SDP [3] to only trust SDP from trusted sources.

And move that document into the normative class.

[Ballot comment]
Adapted from Gen-ART review by Francis Dupont:

- in 3 page 3 I suggest to add "(RFC YYYY)" (as it is done in 4.1 page 3)
- in 3 page 3 and in 9.2 page 5 I believe it is "RTP" in place of "RFC"
  (again 4.1 page 3 seems right)
- I'd like to get the name of the I-D for reference [5], BTW it seems to
  be draft-ietf-avt-ulp

[Ballot discuss]
Genuine discuss: is it really OK that the only specfic FEC method is given as an informative reference? Shouldn't there be a mandatory method?

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the ID and
do they believe this ID is sufficiently baked to forward to the
IESG for publication?

Yes.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has had adequate review; I have no concerns.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the document, or have concerns whether there really is a need for
it, etc. If your issues have been discussed in the WG and the
WG has indicated it wishes to advance the document anyway, note
if you continue to have concerns.

I have no concerns.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid consensus.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise what are they upset about.

No.

1.g) Have the chairs verified that the document adheres to _all_ of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

1.h) Does the document a) split references into normative/
informative, and b) are there normative references to IDs,
where the IDs are not also ready for advancement or are otherwise in
an unclear state? (Note: the RFC editor will not publish an RFC
with normative references to IDs, it will delay publication
until all such IDs are also ready for publication as RFCs.)

References have been split. There are no normative references to
internet-drafts.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:


* Technical Summary

This document defines the semantics that allows for grouping of
forward error correction (FEC) streams with the protected payload
streams in Session Description Protocol (SDP). The semantics defined
in this document is to be used with Grouping of Media Lines in the
Session Description Protocol (RFC 3388) to group together "m" lines
in the same session.

* Working Group Summary

The draft is a product of the MMUSIC working group.

* Protocol Quality

The draft extends an existing SDP feature, to support FEC. This
is an obvious use of the grouping feature, and is needed to support the
ULP work ongoing in AVT.