Methods to Convey Forward Error Correction (FEC) Framework Configuration Information
RFC 6695

Received changes through RFC Editor sync (changed abstract to 'The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for the FEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).

This document doesn't define any new signaling protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.')

[Ballot discuss]
Updated based on -08.

My original discuss was about whether the MTI is PGP or CMS.  The paragraph in question was (in -06):

  SAP messages are carried over UDP over IP with destination UDP
  port being 9875 and source UDP port being any available number,
  as described in RFC2974. The SAP message(s) SHOULD contain an
  authentication header and MAY employ cryptography. One
  cryptography method suggested by this specification is the usage
  of Group Cryptography as specified in GDOI [RFC3547].

It's now been changed to (in -08):

  SAP messages are carried over UDP over IP with destination UDP
  port being 9875 and source UDP port being any available number,
  as described in RFC2974. The SAP message(s) should contain an
  authentication header using PGP authentication.

There still isn't an MTI.  If you're going to say PGP is the MTI then the last sentence should say so (and you'll need a normative reference to PGP).

[Ballot discuss]
Updated based on -08.

My original discuss was about whether the MTI is PGP or CMS.  The paragraph in question was (in -06):

  SAP messages are carried over UDP over IP with destination UDP
  port being 9875 and source UDP port being any available number,
  as described in RFC2974. The SAP message(s) SHOULD contain an
  authentication header and MAY employ cryptography. One
  cryptography method suggested by this specification is the usage
  of Group Cryptography as specified in GDOI [RFC3547].

It's now been changed to (in -08):

  SAP messages are carried over UDP over IP with destination UDP
  port being 9875 and source UDP port being any available number,
  as described in RFC2974. The SAP message(s) should contain an
  authentication header using PGP authentication.

There still isn't a MTI.  If you're going to say PGP is the MTI then the last sentence should say so (and you'll need a normative reference to PGP).

[Ballot comment]
It would help to explicitly state in the document that the list of unicast mechanisms discussed is not intended to be a complete list.

The document  does not state its purpose clearly.

[Ballot comment]
The Gen-ART Review by Peter McCann on 2-Nov-2011 suggests many
  editorial improvements.  Please consider them.  The review can be
  found here:

    http://www.ietf.org/mail-archive/web/gen-art/current/msg06888.html

[Ballot comment]
Ari Keränen helped me review this, and he had a couple of comments:

Many of the internal references ("see section x") are referring to
apparently wrong sections.

1. Introduction

    This document describes how to use various signaling protocols to
    communicate the Configuration information between sender and
    receiver(s). The configuration information may be encoded in any
    compatible format such as SDP [RFC4566], XML etc.

I found this statement confusing considering that only SDP encoding is
defined (right?). The same statement is found also later in the draft.

[Ballot comment]
I agree with other discusses in that the purpose of the draft should be clarified.

Also, introductions should not contain normative language. Normative terminology is not even introduced before Section 2.

[Ballot comment]
I really don't see the point of raising a further Discuss on this document since my concerns overlap extensively with those already raised.

However, one point really bothered me...

The Abstract says:

  This document describes how to use existing signaling protocols to
  determine and dynamically communicate the Configuration information
  between sender(s) and receiver(s).

I would expect the Absatrct to state clearly which protocols. But I read on and found in the Introduction:

  This document describes how to use various signaling protocols to
  communicate the Configuration information between sender and
  receiver(s). The configuration information may be encoded in any
  compatible format such as SDP [RFC4566], XML etc. A signaling
  protocol could be utilised by any FEC scheme and/or any Content
  Delivery Protocol (CDP).

So I realised that the document is attempting to give an abstract description of how one might use *a* signaling protocol for the tasks identified, but without actually doing the protocol specification. Fair enough - although that clearly makes it an Informational framework.

This view was confirmed by Section 5 that is clearly abstract, and by Section 5.2 that says:

  This document describes leveraging any signaling protocol that is
  already used by the unicast application, for exchanging the FEC
  Framework Configuration Information between two nodes.

But in Section 5.1:

  This specification describes using Session Announcement Protocol
  (SAP) version 2 [RFC2974] as the signaling protocol to multicast the
  configuration information from one sender to many receivers.

Which is not abritrary at all.

To make this actionable I suggest you work out very clearly what the purpose of the document is and capture that both in the Abstract and the Introduction. It would also help if you clearly defined what *you* mean by a signaling protocol because people at different layers of the stack have very different understandings of the term.

[Ballot discuss]
Even if this document was written properly as a protocol document (see Wes's Discuss comment), there is no explanation of what about this document is experimental in the first place. There is no description about what is being experimented on, why it is an experiment, and what the results of the experiment might be. Such an explanation should appear in the Introduction.

[Ballot discuss]
Even if this document was written properly as a protocol document (see Wes's Discuss comment), there is no explanation of what about this document is experimental in the first place. There is no description about what is being experimented on, why it is an experiment, and what the results of the experiment might be.

[Ballot comment]
s5 contains the following:

  The SAP message(s) SHOULD contain an
  authentication header and MAY employ cryptography.

I think you mean "MAY employ encryption."

I too am scratching my head about the GDOI reference.  Further, RFC 3547 was recently obsoleted by RFC 6407.  There were a fair number of changes.  I'm unclear whether you should update the reference or keep the reference to the obsoleted RFC.  Are there any implementations of the newer or older GDOI mechanism?

[Ballot discuss]
I see that authentication is a SHOULD.  I went and looked at RFC 2974 and it says either PGP or CMC can be used.  Don't you have to pick a MUST implement?

[Ballot comment]
It's not clear what this document is trying to acheive. Parts of it seem to
be considerations that a CDP specification should take into account when
defining how FCCI is disributed. Section 5.2, which calls out a few
unicast mechanisms, has this flavor in particular. It's almost a survey,
and while the descriptions call out important aspects a CDP should consider,
they are not sufficiently detailed for a CDP to point to this document to
define how these mechanisms would be used. Section 5.1, on
the other hand, tries to define how an (abstract?) CDP would utilize
multicast SAP, adding a few requirements beyond the base SAP specification.

Please consider restructuring (perhaps even renaming) the document to make
its goals clearer.

[Ballot discuss]
(It would help to read the comments below before reading these DISCUSS points)

1) In several sections (5.1 in particular) it's very hard to tell which
  requirements are new requirements on an implementation defined in this
  draft and which are restatements of requirements from other RFCs. Some
  of these restatements leave out important context (an example is the
  deletion requirement in 5.1.2 of this document vs the description of
  explicit deletion in section 4 of RFC2974). Please explicitly call out
  each instance where you are just restating a requirement, and consider
  just pointing to the actual definition of behavior instead of restating
  it.

2) Is the list of unicast mechanisms intended to be complete? Is it intended
  to constrain CDPs to choose only between them instead of inventing something
  new?

[Ballot comment]
- What does "MAY employ cryptography" mean? You
already said SHOULD to the authentication header
so what kind of non cryptographic authentication
header do you have in mind? RFC 2974 defines PGP
and CMS options so presumably the SHOULD means
that you've gotta do one of those unless you have
a good reason.

- Is it clear how one would use GDOI to manage
keys for a SAP authentication header?

- I agree with Wes' discuss.

[Ballot discuss]
It's not clear in what sense this is Experimental.  It seems to be more of an Informational document, as it is not particularly prescriptive as a protocol or mechanism.  For instance, I don't think it would be possible to create compatible implementations based solely on this document; many decisions are punted on.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Methods to convey FEC Framework Configuration Information) to Experimental RFC


The IESG has received a request from the FEC Framework WG (fecframe) to
consider the following document:
- 'Methods to convey FEC Framework Configuration Information'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  FEC Framework document [FECARCH] defines the FEC Framework
  Configuration Information necessary for the FEC framework operation.
  This document describes how to use existing signaling protocols to
  determine and dynamically communicate the Configuration information
  between sender(s) and receiver(s).






The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-fecframe-config-signaling/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-fecframe-config-signaling/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::Point Raised - writeup needed.
discussion of the use of a signaling protocol required. RSVP should; else implementation-dependent. See other comments in emails.

State changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation::AD Followup.
I have asked the shepherd/chair to review the changes to -05- and verify WG consensus on the changes.

AD Review updated for version 05

I have requested the shepherd review and approve these changes, and if the changes are kept, the chair should to do a one-week WG last call on these changes to verify consensus.

1) please check id-nits. There are some reported problems with references, and
example addresses.

2) Why is this document being requested to be published as Experimental? Is
there a lack of WG consensus for this design, or the protocols discussed? If so,
the concerns that prevent consensus from being reached should be discussed,
probably with an explanation in the Introduction that this is an Experimental
proposal, not a standard.
modified in 05 to Proposed Standard - is WG ok with this change?

3) fixed.

4) In the last paragraph of 5.1, when a delete has been received, the receiver
SHOULD no longer use the config info. Why is this not a MUST?

changed to MUST - does WG agree?

5) fixed

6) OK

7) fixed

State changed to AD Evaluation::Revised ID Needed from Publication Requested.
I have performed AD Review on draft-ietf-fecframe-config-signaling-04.

-- Technical and/or process concerns:

1) please check id-nits. There are some reported problems with references, and example addresses.

2) Why is this document being requested to be published as Experimental? Is there a lack of WG consensus for this design, or the protocols discussed? If so, the concerns that prevent consensus from being reached should be discussed,
probably with an explanation in the Introduction that this is an Experimental proposal, not a standard.

3) In section 5.1, provide a reference explaining the UDP port 9875. If this is IANA-assigned, please describe this in the IANA Considerations section.

4) In the last paragraph of 5.1, when a dleete has been received, the receiver SHOULD no longer use the config info. Why is this not a MUST?

5) in 5.2, the assertion is made that using a generic protocol is "under investigation and may be covered by a separate document." Where is this under investigation? What document do you think will cover this?

6) It helps IANA if you identify by URL the registry you want modified (http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xml RTSP/1.0 Option Tags), and include the specific fields that require filling.

7) The IANA considerations refer to section 4.2.2, but there is no section 4.2.2 in this document.

Editorial comments:
"Independent of what all encoding formats supported by an FEC scheme," should be reworded.

section 5 uses a numbering scheme of (i), (b), (c). I suspect the first should be (a).

I don't understand the topology pictured in Figure 1. I understand the text, but the figure doesn't convey the topology very well.

The "simpler method" description in section 5.1.1 could use some English language cleanup.

I have performed AD Review on draft-ietf-fecframe-config-signaling-04.

-- Technical and/or process concerns:

1) please check id-nits. There are some reported problems with references, and example addresses.

2) Why is this document being requested to be published as Experimental? Is there a lack of WG consensus for this design, or the protocols discussed? If so, the concerns that prevent consensus from being reached should be discussed,
probably with an explanation in the Introduction that this is an Experimental proposal, not a standard.

3) In section 5.1, provide a reference explaining the UDP port 9875. If this is IANA-assigned, please describe this in the IANA Considerations section.

4) In the last paragraph of 5.1, when a dleete has been received, the receiver SHOULD no longer use the config info. Why is this not a MUST?

5) in 5.2, the assertion is made that using a generic protocol is "under investigation and may be covered by a separate document." Where is this under investigation? What document do you think will cover this?

6) It helps IANA if you identify by URL the registry you want modified (http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xml RTSP/1.0 Option Tags), and include the specific fields that require filling.

7) The IANA considerations refer to section 4.2.2, but there is no section 4.2.2 in this document.

Editorial comments:
"Independent of what all encoding formats supported by an FEC scheme," should be reworded.

section 5 uses a numbering scheme of (i), (b), (c). I suspect the first should be (a).

I don't understand the topology pictured in Figure 1. I understand the text, but the figure doesn't convey the topology very well.

The "simpler method" description in section 5.1.1 could use some English language cleanup.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

I, Greg Shepherd as the document shepherd have personally reviewed
this document and believe it to be ready for forwarding to the IESG.

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

The document has had adequate review both from within and from outside
the FECFrame working group.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

There are no concerns regarding the need for additional expanded review.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no specific concerns with this document.

(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 WG consensus for this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

There is no discontent.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

There are no significant nits of any kind.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Normative and informative references are split with two reference to
drafts that are currently in the editor's queue or will be soon.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Section 7 describes the IANA considerations, and is consistent with
the rest of the document, referring to the details discussed in
section 4.2.2 and 3.8.1.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The xml code validates correctly

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document describes how to use existing signaling protocols to
determine and dynamically communicate the Configuration information
between sender(s) and receiver(s) compliant with the FEC Framework
document.

Working Group Summary
There were no seriously contentious issues during the WG process.

Document Quality
The Working Group feedback covered both the quality of the document
itself as well as the technical issues with the content of the
document.

Personal
Document Shepherd - Greg Shepherd
Responsible Area Director - David Harrington