Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library
draft-ietf-forces-lfb-lib-12
Yes
(Adrian Farrel)
No Objection
(Barry Leiba)
(Brian Haberman)
(Gonzalo Camarillo)
(Joel Jaeggli)
(Pete Resnick)
(Sean Turner)
(Ted Lemon)
Note: This ballot was opened for revision 11 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -11)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -11)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -11)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -11)
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2013-03-27)
Unknown
A Gen-ART review by Meral included one small editorial suggestion (below). Have the authors considered this change? --- Section 11, the following sentence can be written : "The ForCES protocol document [RFC5810] includes a comprehensive set of security mechanisms and which implementations are required to support, and which deployments can use to meet these needs. " Suggestion: "The ForCES protocol document [RFC5810] includes a comprehensive set of security mechanisms that implementations are required to support to meet these needs."
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -11)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-03-26 for -11)
Unknown
A nit: Section 3.1., paragraph 11: > * Fragments datagrams when necessary to fit into the MTU of the > next network. It is not the 'next network' but rather the MTU of the next link/interface, as the NE instance cannot know the MTU restrictions of the whole network path.
Pete Resnick Former IESG member
No Objection
No Objection
(for -11)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(2013-03-25 for -11)
Unknown
Minor XML typo: OLD: <load library="BaseTypeLibrary", location="..."/> NEW: <load library="BaseTypeLibrary" location="..."/>
Sean Turner Former IESG member
No Objection
No Objection
(for -11)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-03-26 for -11)
Unknown
Apologies in advance, I'm very very ignorant of ForCES. (That'll be clear as you read below;-) - I think the security considerations section should reference 5811 which I think specifies the MTI security for forces. That specifies SCTP/IPsec, which made me wonder how much use that actually gets. - Is it possible to brick an FE by loading in a instances that create an infinite loop? If so, that'd be worth a mention in the security considerations maybe. - I was surprised not to see mention of WiFi/802.11 here and wondered if/how wireless ports might differ from wired and whether or not that ought be represented somewhere in this document. (Is ForCES just not for such devices? That's ok if so, I just wondered and haven't read other ForCES RFcs.) - p6, "LFB Class and LFB Instance - LFBs are categorized by LFB Classes. An LFB Instance represents an LFB Class (or Type) existence. There may be multiple instances of the same LFB Class (or Type) in an FE. An LFB Class is represented by an LFB Class ID, and an LFB Instance is represented by an LFB Instance ID. As a result, an LFB Class ID associated with an LFB Instance ID uniquely specifies an LFB existence." Huh? What's an "existence"? I found this definition unclear fwiw but I think I get that each instance has a class and that the instance and class identifiers together provide a way to uniquely identify an instance. - p6, definition of "ForCES Protocol" says: "This document defines the specifications for this ForCES protocol." but then at the end of the definitions you say "The LFB Class Library is defined by this document." which seems odd. Is the first one a cut'n'paste error? - s3, intro, 1st para, 1st sentence: 5810 isn't the framework, 3746 is or else something has the wrong title;-) - 4.4: I didn't check the schema, I do hope that someone's checked it vs. their code etc. - section 5, last para before 5.1: does this mean that nodes (FEs) MUST ignore XML elements/attributes that they don't understand/expect? If so, saying it that way would be better IMO. - 5.1.1.1 introduces the term "singleton" without defining it, and its not clear to me what it does mean. (That might be because that term has a specific meaning in DTNs e.g. as defined in rfc 4838, that's different but not entirely different and that that confuses me:-) - 5.1.2.1 last para: "This document does not go into the details of how this is implemented; the reader may refer to some relevant references." That doesn't seem very helpful. - 5.1.2.2, typo: "The default value for is 'false'" (occurs more than once) - 5.1.2.2, 3rd last para: how does the FE generate an error for something it doesn't implement if the rule is that FE's ignore unknown XML elements? I'm confused now between this and the text just before the start of 5.1. - 5.3.3, shouldn't you add references for ECMP and RPF? (Good to do even if you're not fully doing the work here, since you do talk about 'em a bit.) - 5.3.3, I'm not clear how e.g. you'd need another LFB to support ECMP but yet but yet 5.3.3.1 says "An ECMP flag is defined in the LPM table to enable the LFB to support ECMP." - 5.4.1, says "Note that all metadata visible to the LFB need to be global and IANA controlled." I'm not sure what you mean by that.
Stewart Bryant Former IESG member
No Objection
No Objection
(2013-03-26 for -11)
Unknown
No objection, but it is a pity that the example is IPv4 and not IPv6 given that IPv4 is in sunset.
Ted Lemon Former IESG member
No Objection
No Objection
(for -11)
Unknown