Forwarding and Control Element Separation (ForCES) Forwarding Element Model
draft-ietf-forces-model-16
Yes
(Ross Callon)
No Objection
(Chris Newman)
(Cullen Jennings)
(Jari Arkko)
(Jon Peterson)
(Lars Eggert)
(Magnus Westerlund)
(Pasi Eronen)
(Ron Bonica)
(Russ Housley)
(Tim Polk)
Abstain
(David Ward)
Note: This ballot was opened for revision 16 and is now closed.
Dan Romascanu Former IESG member
Yes
Yes
(2008-09-24)
Unknown
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.
Ross Callon Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
(was Discuss)
No Objection
No Objection
(2008-10-09)
Unknown
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.
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2008-10-08)
Unknown
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. )
David Ward Former IESG member
Abstain
Abstain
()
Unknown