Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library
draft-ietf-forces-lfb-lib-12

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."

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.

Minor XML typo:

OLD: <load library="BaseTypeLibrary", location="..."/>
NEW: <load library="BaseTypeLibrary" location="..."/>

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.

No objection, but it is a pity that the example is IPv4 and not IPv6
given that IPv4 is in sunset.