Note: This ballot was opened for revision 15 and is now closed.
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
Comment (2008-09-24 for -)
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
Comment (2008-10-09 for -)
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
Comment (2008-10-08 for -)
(The security considerations includes a reference that is inconsistent with the
surrounding text. The text refers to RFC 3746, which is reference  but 
is the reference that is included in the text. )