Forward Error Correction (FEC) Framework Extension to Sliding Window Codes
draft-ietf-tsvwg-fecframe-ext-08

[Ballot comment]
I tried to deduplicate my comments with the ones already in the
datatracker.

Section 1

It seems like the executive summary of this document would be "now you can
allocate FEC Encoding IDs that use sliding windows".  It might be helpful
to mention explicitly that the use of a sliding window is indicated through
the Encoding ID, with no other signaling.

Section 2

It might be helpful to indicate that a Payload ID includes positional
information as opposed to just content-type information.


Thank you for providing the summary in Section 3!

Section 5.3

  o  MUST define the management of the decoding window, consisting of a
      system of linear equations (in case of a linear FEC code);

I don't think this is the right way to phrase things; it implies that the
system of linear equations is always the information needed to manage the
decoding window, then trying to walk back that statement in a
parenthetical.  It seems better to just state the hard requiremnt for
window management, and make a separate sentence for what this means in the
linear system case.

Section 10

While I agree with the claim that the the security considerations are
basically unchanged for block-based and sliding-window FEC schemes, I do
find the security considerations of RFC 6363 to be slightly lacking.
In particular, its list of possible attack goals seem to omit some
possibilities that come up pretty often, like trying to corrupt source
flows to modify the receiver application's behavior (as opposed to just
denying service) and the arguably degenerate attack of just dropping lots
of traffic (for denial of service).
It's unclear that any of these are significant enough to merit specific
mention in this document, though.

Section 13

              This document being an extension to [RFC6363], the authors
  would also like to thank Mark Watson as the main author this RFC.

nit: "main author of that RFC" (noting in particular the "that", since
the "of" was already mentioned)

[Ballot comment]
Just a nit:

§3: "The possibility of having feedbacks from receivers(s) is considered out of scope, although such a mechanism may exist within the application (e.g., through RCTP control messages);"

Should RCTP be RTCP?

[Ballot comment]
Thanks for the work involved in developing this document. I have only a handful
of editorial comments.

---------------------------------------------------------------------------

Abstract:

>  in a backward compatible way.  During multicast/broadcast real-time

Nit: "...backward-compatible..."

---------------------------------------------------------------------------

§1:

>  the transport or application layer, is an efficient technique to

Nit: remove comma

>  separately defined FEC schemes.  Any CDP defined according to the

Nit: "...separately-defined..."

---------------------------------------------------------------------------

§2:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].
>
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>  "OPTIONAL" in this document are to be interpreted as described in BCP
>  14 [RFC2119] [RFC8174] when, and only when, they appear in all
>  capitals, as shown here.

It is not necessary to include boilerplate from both RFC 2119 and RFC 8174.
Please remove the first of these two paragraphs.

---------------------------------------------------------------------------

§3:

>  an ADU to symbols mapping process that is FEC Scheme specific (see

"...ADU-to-symbols..."

"...FEC-Scheme..."

>  symbols.  After source symbol to ADU mapping, when lost ADUs are

"...source-symbol-to-ADU..."

>  o  ADUs to source symbols mapping: in order to manage variable size

"...ADUs-to-source-symbols..."

>    FEC Scheme dependant and must be defined in the associated

"...FEC-Scheme-dependent..."
(note both insertion of hyphens and spelling of "dependent")

>    prepended with a flow identifier (1 byte) during the ADU to source
>    symbols mapping (see above).  The flow identifiers are also shared

"...ADU-to-source-symbols..."

---------------------------------------------------------------------------

§4.2:

>      ADU to source symbols mapping as well as the encoding window

"...ADU-to-source-symbols..."

>      and MUST be detailed there.  Appendix A provides non normative

"...non-normative..."

---------------------------------------------------------------------------

Appendix A:

>  new ADU is available at the sender, after the ADU to source symbol

"...ADU-to-source-symbol..."

[Ballot comment]
Thanks to the work involved in developing this document. I have only a handful
of editorial comments.

---------------------------------------------------------------------------

Abstract:

>  in a backward compatible way.  During multicast/broadcast real-time

Nit: "...backward-compatible..."

---------------------------------------------------------------------------

§1:

>  the transport or application layer, is an efficient technique to

Nit: remove comma

>  separately defined FEC schemes.  Any CDP defined according to the

Nit: "...separately-defined..."

---------------------------------------------------------------------------

§2:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].
>
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>  "OPTIONAL" in this document are to be interpreted as described in BCP
>  14 [RFC2119] [RFC8174] when, and only when, they appear in all
>  capitals, as shown here.

It is not necessary to include boilerplate from both RFC 2119 and RFC 8174.
Please remove the first of these two paragraphs.

---------------------------------------------------------------------------

§3:

>  an ADU to symbols mapping process that is FEC Scheme specific (see

"...ADU-to-symbols..."

"...FEC-Scheme..."

>  symbols.  After source symbol to ADU mapping, when lost ADUs are

"...source-symbol-to-ADU..."

>  o  ADUs to source symbols mapping: in order to manage variable size

"...ADUs-to-source-symbols..."

>    FEC Scheme dependant and must be defined in the associated

"...FEC-Scheme-dependent..."
(note both insertion of hyphens and spelling of "dependent")

>    prepended with a flow identifier (1 byte) during the ADU to source
>    symbols mapping (see above).  The flow identifiers are also shared

"...ADU-to-source-symbols..."

---------------------------------------------------------------------------

§4.2:

>      ADU to source symbols mapping as well as the encoding window

"...ADU-to-source-symbols..."

>      and MUST be detailed there.  Appendix A provides non normative

"...non-normative..."

---------------------------------------------------------------------------

Appendix A:

>  new ADU is available at the sender, after the ADU to source symbol

"...ADU-to-source-symbol..."

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4332



COMMENTS
S 1.
>      However [RFC6363] only considers block FEC schemes defined in
>      accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681],
>      [RFC6816] or [RFC6865]).  These codes require the input flow(s) to be
>      segmented into a sequence of blocks.  Then FEC encoding (at a sender
>      or an encoding middlebox) and decoding (at a receiver or a decoding
>      middlebox) are both performed on a per-block basis.  This approach

This text could probably be clearer. I think what this means is that
say you have a flow that's a sequence of symbols S_1..... S_n and then
you segment it into a set of blocks (E.g., S_1...S_b, S_b+1.. S_n) and
then each block is separately encoded into a set of packets with its
own FEC. And that that's bad. Is that correct?


S 2.
>      The following list of definitions and abbreviations is copied from
>      [RFC6363], adding only the Block/sliding window FEC Code and
>      Encoding/Decoding Window definitions (tagged with "ADDED"):
> 
>      Application Data Unit (ADU):  The unit of source data provided as
>          payload to the transport layer.

It would be helpful to give an example. I am assuming that I should be
thinking something like "compressed video frame"?


S 3.
> 
>      The FECFRAME architecture is illustrated in Figure 1 from the
>      sender's point of view, in case of a block FEC Scheme.  It shows an
>      application generating an ADU flow (other flows, from other
>      applications, may co-exist).  These ADUs, of variable size, must be
>      somehow mapped to source symbols of fixed size.  This is the goal of

Is the requirement that the source symbols be of fixed size just a
simplification? It's not a generic requirement of ECCs, right?


S 4.3.
>      4.  The FEC Scheme uses the received FEC Payload IDs (and derived FEC
>          Source Payload IDs when the Explicit Source FEC Payload ID field
>          is not used) to insert source and repair packets into the
>          decoding window in the right way.  If at least one source packet
>          is missing and at least one repair packet has been received and
>          the rank of the associated linear system permits it, then FEC

This bit about the rank of the linear system seems kind of like
misplaced concreteness for a framework document.

[Ballot comment]
These are a couple of minor items that weren't worth delaying IESG Evaluation for the draft, but just so you know about them along with anything else you hear during IESG Evaluation ...

Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC6363, but the
    abstract doesn't seem to directly say this.  It does mention RFC6363
    though, so this could be OK.

I don't feel strongly about asking you to change this to "this document updates RFC 6363" in the abstract, but tastes differ. I find the current phrasing clear for human readers, but I've heard rumors that some people scrape Abstracts looking for specific text. I'll trust you to do the right thing.

In Section 2. when you add the new boilerplate, you delete the old one, so

OLD

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in BCP
  14 [RFC2119] [RFC8174] when, and only when, they appear in all
  capitals, as shown here.

NEW

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in BCP
  14 [RFC2119] [RFC8174] when, and only when, they appear in all
  capitals, as shown here.

In 13.  Acknowledgments, it looks like there's a missing "of"

  The authors would like to thank Christer Holmberg, David Black, Gorry
  Fairhurst, and Emmanuel Lochin for their valuable feedbacks on this
  document.  This document being an extension to [RFC6363], the authors
  would also like to thank Mark Watson as the main author this RFC.
                                                          ^ of

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.  This is an updated version of RFC 6363 which is a Proposed Standard itself.  It is correctly indicated in the header as Standards Track.


(2) 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

  RFC 6363 describes a framework for using Forward Error Correction
  (FEC) codes to provide protection against packet loss.  The framework
  supports applying FEC to arbitrary packet flows over unreliable
  transport and is primarily intended for real-time, or streaming,
  media.  However FECFRAME as per RFC 6363 is restricted to block FEC
  codes.  The present document extends FECFRAME to support FEC Codes
  based on a sliding encoding window, in addition to Block FEC Codes,
  in a backward compatible way.  During multicast/broadcast real-time
  content delivery, the use of sliding window codes significantly
  improves robustness in harsh environments, with less repair traffic
  and lower FEC-related added latency.

Working Group Summary

RFC 6363 was a product of the former FECFRAME working group, which closed several years ago.  FECFRAME was in the TSV area.  When several original FECFRAME participants proposed updates/extensions to support new types of codes (with benefits for some real world applications), between the Area Directors and the TSVWG, it was agreed that the work should be done in TSVWG, and two documents including this one were adopted.  Several FECFRAME participants are either authors/editors listed on the documents, or participated in reviews.  Other than this history, there were no other significant issues or events of interest in the working group process on this document.


Document Quality

There have been implementations.  The implementations were reported to the working group, and the documents benefited from the implementation and testing experience.


Personnel

The document shepherd is Wesley Eddy (wes@mti-systems.com), and the responsible AD is Spencer Dawkins.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document has been fully reviewed, and is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.


(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors have confirmed that they have no disclosures to make.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no IPR disclosures.


(9) 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? 

The subset of the working group that is interested in FECFRAME seems to have consensus on the document.  The document has also been a topic of discussion in the IRTF Network Coding Research Group since this is a FEC technology, and there does not appear to be any contention there.


(10) 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 publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No issues.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A


(13) Have all references within this document been identified as
either normative or informative?

Yes.


(14) 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 plan for their completion?

All normative references are PS or BCP.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

It updates RFC 6363.  As explained in the document (in the introduction, and specifically near the top of page 4), it extends but does not replace RFC 6363, so "updates" carries the right semantics.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section is complete.  New registries are not required, only new entry in the existing FECFRAME encoding IDs registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tsvwg-fecframe-ext-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

IANA QUESTION --> In the IANA Considerations section of this document, the authors say:

"A FEC Scheme for use with this FEC Framework is identified via its FEC Encoding ID. It is subject to IANA registration in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry. All the rules of [RFC6363], Section 11, apply and are not repeated here."

Is a new FEC Encoding ID needed for the Framework Extension to Sliding Window Codes? Is a new entry needed in the FEC Framework (FECFRAME) FEC Encoding IDs registry on the Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs registry page required? If so, what are the details of the new registration?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-09-24):

From: The IESG
To: IETF-Announce
CC: tsvwg-chairs@ietf.org, draft-ietf-tsvwg-fecframe-ext@ietf.org, tsvwg@ietf.org, wes@mti-systems.com, spencerdawkins.ietf@gmail.com, David Black , Wesley Eddy
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Forward Error Correction (FEC) Framework Extension to Sliding Window Codes) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Forward Error Correction (FEC)
Framework Extension to Sliding Window
  Codes'
  as Proposed Standard

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 2018-09-24. 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


  RFC 6363 describes a framework for using Forward Error Correction
  (FEC) codes to provide protection against packet loss.  The framework
  supports applying FEC to arbitrary packet flows over unreliable
  transport and is primarily intended for real-time, or streaming,
  media.  However FECFRAME as per RFC 6363 is restricted to block FEC
  codes.  The present document extends FECFRAME to support FEC Codes
  based on a sliding encoding window, in addition to Block FEC Codes,
  in a backward compatible way.  During multicast/broadcast real-time
  content delivery, the use of sliding window codes significantly
  improves robustness in harsh environments, with less repair traffic
  and lower FEC-related added latency.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ballot/


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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard.  This is an updated version of RFC 6363 which is a Proposed Standard itself.  It is correctly indicated in the header as Standards Track.


(2) 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

  RFC 6363 describes a framework for using Forward Error Correction
  (FEC) codes to provide protection against packet loss.  The framework
  supports applying FEC to arbitrary packet flows over unreliable
  transport and is primarily intended for real-time, or streaming,
  media.  However FECFRAME as per RFC 6363 is restricted to block FEC
  codes.  The present document extends FECFRAME to support FEC Codes
  based on a sliding encoding window, in addition to Block FEC Codes,
  in a backward compatible way.  During multicast/broadcast real-time
  content delivery, the use of sliding window codes significantly
  improves robustness in harsh environments, with less repair traffic
  and lower FEC-related added latency.

Working Group Summary

RFC 6363 was a product of the former FECFRAME working group, which closed several years ago.  FECFRAME was in the TSV area.  When several original FECFRAME participants proposed updates/extensions to support new types of codes (with benefits for some real world applications), between the Area Directors and the TSVWG, it was agreed that the work should be done in TSVWG, and two documents including this one were adopted.  Several FECFRAME participants are either authors/editors listed on the documents, or participated in reviews.  Other than this history, there were no other significant issues or events of interest in the working group process on this document.


Document Quality

There have been implementations.  The implementations were reported to the working group, and the documents benefited from the implementation and testing experience.


Personnel

The document shepherd is Wesley Eddy (wes@mti-systems.com), and the responsible AD is Spencer Dawkins.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document has been fully reviewed, and is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.


(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors have confirmed that they have no disclosures to make.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are no IPR disclosures.


(9) 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? 

The subset of the working group that is interested in FECFRAME seems to have consensus on the document.  The document has also been a topic of discussion in the IRTF Network Coding Research Group since this is a FEC technology, and there does not appear to be any contention there.


(10) 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 publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No issues.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A


(13) Have all references within this document been identified as
either normative or informative?

Yes.


(14) 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 plan for their completion?

All normative references are PS or BCP.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The header should indicate that it "Updates: 6363".  This was discussed on the WG mailing list, and it was agreed that it could be fixed during AD review.  As explained in the document (in the introduction, and specifically near the top of page 4), it extends but does not replace RFC 6363, so "updates" carries the right semantics.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section is complete.  New registries are not required, only new entry in the existing FECFRAME encoding IDs registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A