Forwarding and Control Element Separation (ForCES) Protocol Extensions
draft-ietf-forces-protoextension-06

In the IANA section, given that the forces WG is finishing up, would it be better to use Expert Review and provide guidance instead of requiring a specification?  

In Sec 3.2.3: Instead of "We do not propose the cause string be standardized.", what about "The cause string is not standardized by this document."

-- Section 2.1 --
Note that "monotonocally" does not imply incrementing by one, which is what you appear to mean.  I suggest:

NEW
   o  Send up to 10000 ForCES PL requests, incrementing the index by
      one each time, and stop when the needed 2000 entries are
      retrieved.
END

In the last sentence of the section, please change the dash to a comma.

-- Section 3.2.3 --
It appears that you intend the cause string to be consumed by humans, and not to be machine-readable.  Is that correct?  It would be good to add a sentence to say that explicitly. That sets expectations appropriately, and avoids questions about comparing strings and other such ugliness.

-- Section 3.3 --

   The last message which carries the EOT flag to go the CE MUST NOT
   carry any data.

This is an important English usage point that affects the clarity of that sentence: is there only one message that carries the EOT flag, and it's the last one (case 1)?  Or can multiple messages carry the EOT flag, and you're talking about the last one that does (case 2)?  I think you mean case 1, but it's unclear.  You need one of these instead (and pay attention to the commas):

CASE 1
   The last message to go to the CE, which carries the EOT flag,
   MUST NOT carry any data.

CASE 2
   The last message to go to the CE that carries the EOT flag
   MUST NOT carry any data.

END

-- Section 4 --
Pearl Liang is not a programming language; her name has an "a" in it.

-- Section 5 --
Commenting on Alia's comment, actually, Specification Required is an appropriate policy, which also requires a designated expert.  The specification can be an RFC (in the IETF stream or otherwise), or a document published elsewhere... even on a web site.

That said, this section does have to provide guidance for the designated expert about what to consider when evaluating a registration request.  Please don't leave that out.

Just checking on some of the IANA actions.  The current TLV types registry shows 0x117 and 0x118 as unassigned.  Can I assume that since those values are explicitly listed in 3.1 and 3.2 that IANA and the designated experts have approved those values for this document?

You may want to expand FE on first use of the acronym in the introduction.  I do see it comes later in the definitions, so it's up to you(non-blockng comment/nit), but may be easier for the reader.

Thanks for the discussion on the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg04953.html

The abstract doesn't really say what the document is about.  It would be nice to note what extensions are being created here.

Just one question. 

In this text: 3.3.  Large Table Dumping

   The protocol document [RFC5810] does not adequately describe how a
   GET response to such a large message is delivered.  The text in this
   section clarifies.  We limit the discussion to a table object only.

Is this about a GET response to a large message, or a large GET response to a message? The following paragraph seems to be about a large GET response.