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

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.

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.

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.

I agree with Wes's Discuss 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.

This document includes a informative reference to draft-ietf-mboned-session-announcement-req. draft-ietf-mboned-session-announcement-req has expired and doesn't seem to have gained traction in MBONED.

  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

- 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.