Forwarding and Control Element Separation (ForCES) Forwarding Element Model
draft-ietf-forces-model-16

[Ballot comment]
I found this document to be at some times very specific (section 9.2 laying IANA considerations for Class Names and IDs) and at other times very abstract. For example when introducing the ID space referred to here in section 3 it is identified as "global within the Network Element and may be issued by IANA." If the ID is global only within the NE, why do they need to be issued by IANA? And, if they do need to be unique outside the NE, why only a "may" here?

The document itself is a nice object-oriented model of how someone might conceptualize a router design. As such, it is well-written and does as good a job as anyone might be asked to do. However, it is the same level of abstraction that helps to make this document possible, which also makes me wonder if we will ever see truly independent and interoperable models, protocols, hardware, FEs, LFBs, etc. for any of this (or enough to matter beyond an academic exercise). I see no reason to hold up this document in particular at this stage, but in general I believe the IESG needs to take a hard look at the work in the WG and question whether it will be able to achieve its goals.

[Ballot comment]
Section 12.

s/[2]/[5]/

(The security considerations includes a reference that is inconsistent with the surrounding
text.  The text refers to RFC 3746, which is reference [5] but [2] is the reference that is
included in the text.  )

[Ballot discuss]
I don't believe this document adequately addresses the requirements in
BCP 70.  Since it seems just about _every_ XML schema coming through
the IESG gets the wrong, let me try a simple explanation:

XML is extensible by default.  XML schema is non-extensible by default.

If you use XML schema, your protocol/model/format is almost certainly
not extensible by default and even if you've done the extra work to
allow extensibility within the schema, extensions tend to be order
sensitive and an ordering model for them may be necessary.  RelaxNG
shares the same problems, except that the RelaxNG interleave pattern
does not suffer from the order sensitivity problem and thus can support
multiple independent extensions.

Getting to this specific document, the following statement in section 4:
---
Each of the library documents MUST conform to the schema presented in
this section.
---
creates a normative dependency on XML schema (which is not properly
documented in the references), and is equivalent to the statement
"library documents are not extensible".

I want to confirm the authors and WG have considered this issue and
this is the intention.  The same issue may apply to other uses of
schema in the document.

This is also missing a normative reference to STD 63 (UTF-8).

[Ballot comment]
The document does not include the standard phrase about keywords required by RFC 2119. The replacement phrase in the introduction does not mention for example 'MUST NOT' although there are a number of instances of 'MUST NOT' in the text.

IANA Last Call comments/questions:

IANA has questions:

- IANA has no registration for a "forces" or "forces:lfbmodel"
namespace, so has no place to put the "forces:lfbmodel:1.0"
namespace. Do you want to register these other namespaces
too?

Action 1:

Upon approval of this document, the IANA will make the following
assignment in the "ns" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration template
Reference
------------------ -----------------------------------------
------------------ ---------------------
forces:lfbmodel:1.0 urn:ietf:params:xml:ns:forces:lfbmodel:1.0
forces:lfbmodel:1.0 [RFC-forces-model-14]


Action 2:

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD

Registry Name: LDF Class Names
Range Registration Procedures Notes
-------- ------------------------ ------
3-65535 Standards Track

>65535 First Come, First Served Requires stable, publically

available document as reference; name must begin with "EXT-"

Identifier LFB Class Name Reference Description
---------- ---------------- -------------- -------------
0 Reserved [RFC-forces-model-14] Reserved
1 FE Object [RFC-forces-model-14] Defines ForCES
Forwarding Element information
2 FE Protocol 2 [draft-forces-protocol-11] Defines
parameters Object for the ForCES protocol operation

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