Forwarding and Control Element Separation (ForCES) Model Extension
draft-ietf-forces-model-extension-05

[Ballot comment]
I would like to suggest that the authors consider the following as a replacement abstract:

  This memo extends the Forwarding and Control Element
  Separation (ForCES) model defined in RFC 5812
  to allow complex datatypes for metadata, optional default values
  for datatypes, and optional access types for structures.  It fixes an
  issue with Logical Functional Block (LFB) inheritance.  It also
  introduces two new features: LFB properties, and a new event
  condition, BecomesEqualTo.

This is really none of my business, so feel free to ignore this suggestion.  The reason I make the suggestion is that the purpose of an abstract is to help people who would be interested in a document to find it, and for people generally to understand specifically what the document does.  The current abstract is really just a shorter version of the introduction, with a lot of text explaining things a person interested in the document would already know, and that a newcomer could find out by reading RFC 5812 and other ForCES documents.  This text obscures the information that would allow the reader to identify the specific purpose of this document.  I think the above paragraph conveys what needs to be said, and is easier for both domain experts and newcomers to digest.

Otherwise the document looks good—thanks for doing this work!

[Ballot comment]
I would like to suggest that the authors consider the following as a replacement abstract:

  This memo extends the Forwarding and Control Element
  Separation (ForCES) model defined in RFC 5812
  to allow complex datatypes for metadata, optional default values
  for datatypes, and optional access types for structures.  It fixes an
  issue with Logical Functional Block (LFB) inheritance.  It also
  introduces two new features: LFB properties, and a new event
  condition, BecomesEqualTo.

This is really none of my business, so feel free to ignore this suggestion.  The reason I make the suggestion is that the purpose of an abstract is to help people who would be interested in a document to find it, and for people generally to understand specifically what the document does.  The current abstract is really just a shorter version of the introduction, with a lot of text explaining things a person interested in the document would already know, and that a newcomer could find out by reading RFC 5812 and other ForCES documents.  This text obscures the information that would allow the reader to identify this document as one to read.  I think the above paragraph conveys what needs to be said, and is easier for both domain experts and newcomers to digest.

Otherwise the document looks good—thanks for doing this work!

[Ballot comment]

- abstract and intro: I bet the "two years now" is no longer
true - yep, its 4 years;-)

- 2.1 - How does supporting more complex metadata stack up
with RFC 7258? Is that worth a mention in the security
considerations? By "that" I mean the potential for additional
more complex structured metadata to "better" leak private
information? 

- maybe the above 7258-related point applies to 2.4 as well,
though that might be a bit of a stretch? What I'm wondering
is if this means I can now add a kind of privacy unfriendly
trigger that I couldn't previously.  That'd be something like
" if  BecomesEqualTo
"

Note: for both of the above points, I don't remember enough
about forces to be honest, and you should definitely not take
this to be something where you have to placate the AD.  And
additionally, this is a minor extention of exactly the kind
envisaged in 7258 itself so we ought not go overboard. In
other words, feel free to respond with one or both of: a) "no
that's just silly, what have you been smoking?" or b) "yeah
maybe, but this isn't the right place to think about the
privacy impact of forces."

[Ballot comment]
Moved from "discuss"; this is now non-blocking.  If we can get an appsdir XML review "soon enough", that would be nice.
I have a small concern, as it's full of modified XML, and the shepherd writeup already notes a copy/paste error in that area (albeit in a caption).  It's possible that a substantive error also got through, but I'm satisfied enough with the level of review that this shouldn't block the progress of the document if appsdir can't produce a review right away.

-- Section 1 --
The last sentence puzzles me: I get what you mean by saying what XML libraries (why capitalize "Libraries"?) shouldn't generate, but I don't understand what you mean about parsing the library. I think you mean "unable to parse the generated XML," yes?

-- Section 5 --

  IANA has registered a new XML namespace, as per the guidelines in RFC
  3688 [RFC3688].

It doesn't appear that they have.  Am I missing something?

-- Section 6 --

  Thus the security considerations defined in [RFC5812] applies to this
  document as well as the changes proposed here are simply constructs
  to write XML library definitions, as where in [RFC5812] and clarifies
  the inheritance issue of the initial model and both have no effect on
  security semantics with the protocol.

I'm afraid I can't make any sense out of that sentence.  Can you please rewrite it?  (Really, I honestly can't figure it out, though I'm pretty sure you're saying that there are no new security considerations here.)

[Ballot discuss]
I'd like to check whether the document has had a thorough review by one or more XML experts, as it's full of modified XML, and the shepherd writeup already notes a copy/paste error in that area (albeit in a caption).  The shepherd writeup makes no mention of review by any XML specialists.

[Ballot comment]
-- Section 1 --
The last sentence puzzles me: I get what you mean by saying what XML libraries (why capitalize "Libraries"?) shouldn't generate, but I don't understand what you mean about parsing the library. I think you mean "unable to parse the generated XML," yes?

-- Section 5 --

  IANA has registered a new XML namespace, as per the guidelines in RFC
  3688 [RFC3688].

It doesn't appear that they have.  Am I missing something?

-- Section 6 --

  Thus the security considerations defined in [RFC5812] applies to this
  document as well as the changes proposed here are simply constructs
  to write XML library definitions, as where in [RFC5812] and clarifies
  the inheritance issue of the initial model and both have no effect on
  security semantics with the protocol.

I'm afraid I can't make any sense out of that sentence.  Can you please rewrite it?  (Really, I honestly can't figure it out, though I'm pretty sure you're saying that there are no new security considerations here.)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-forces-model-extension-03.  Authors should review the comments below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments:

IANA understands that upon approval of this document, there is a single action which IANA must complete.

In the IETF XML Registry, located at:

http://www.iana.org/assignments/xml-registry/

the following entry is to be added to the NS registry:

ID: forces:lfbmodel:1.1
URI: urn:ietf:params:xml:ns:forces:lfbmodel:1.1
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ForCES Model Extension) to Proposed Standard


The IESG has received a request from the Forwarding and Control Element
Separation WG (forces) to consider the following document:
- 'ForCES Model Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-09. This last call period is longer
than usual to allow for overlap with IETF-90. Exceptionally, comments
may be sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  Forwarding and Control Element Separation (ForCES) defines an
  architectural framework and associated protocols to standardize
  information exchange between the control plane and the forwarding
  plane in a ForCES Network Element (ForCES NE).  RFC5812 has defined
  the ForCES Model that provides a formal way to represent the
  capabilities, state, and configuration of forwarding elements within
  the context of the ForCES protocol, so that control elements (CEs)
  can control the FEs accordingly.  More specifically, the model
  describes the logical functions that are present in a forwarding
  element (FE), what capabilities these functions support, and how
  these functions are or can be interconnected.

  RFC5812 has been around for two years and experience in its use has
  shown room for small extensions without a need to alter the protocol
  while retaining backward compatibility with older xml libraries.
  This document update RFC5812 and extends the model to allow complex
  datatypes for metadata, optional default values for datatypes,
  optional access types for structures and fixes an issue with LFB
  inheritance.  The document also introduces two new features a new
  event condition BecomesEqualTo and LFB properties.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-forces-model-extension/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-forces-model-extension/ballot/

No IPR declarations have been submitted directly on this I-D.

AD review
=======

Hi Evangelos,

Thanks for holding the pen on this.

I have done my usual AD review. Normally the purpose of the review is to catch issues that might surface in IETF last call and IESG evaluation, but in this case I feel I am also reviewing in place of ForCES WG last call as there was complete silence from the WG at that time and, indeed, I rather feel that a number of the comments I make below should have been caught by an active and engaged working group.

Although most of my comments are editorial in nature, many of them significantly impact on the utility and purpose of the document, so I believe they need to be addressed before the document can advance. So I've place the I-D in "Revised I-D state" and will wait to see a new version.

Cheers,
Adrian

====

Can you clarify for me whether, after the publication of this document
as an RFC, the extensions it defines are part of the ForCES model. That
is, if you were to implement ForCES from scratch after its publication,
would you be expected to include these features?

If the answer is "yes" then this probably updates 5812. If "no" then we
need to work some language to explain that the extensions are options.

I think, looking at, for example, Section 3.1, that this document is
making specific changes to 5812 as well as potentially defining some
additions. That means it really does update 5812.

To handle this you need:
- An "updates" tag in the metadata at the head of the file
- To make the statement in the Abstract "This document updates RFC 5812
  by defining foo..."
- Add a section (probably Section 1.1 inside the Introduction) that is
  called "Updates to RFC 5812" and provides an overview of the changes
  and additions (you can use forward pointers into the rest of the
  document).

---

The nits noted by the Shepherd in his write-up need to be fixed.

---

Abstract
  RFC5812 has defined
  the ForCES Model provides a formal way
Maybe
  RFC5812 has defined
  the ForCES Model that provides a formal way

---

Abstract
Please expand "FE" on first use.

---

Section 1.2

I am not a not a fan of repeating material from other documents. At best
it means that the reviewer has to cross-check to make sure you haven't
introduced any inconsistencies. At worst it means that an update or fix
to one document has to be reproduced in the other document.

Since I doubt that it makes sense to read this document without a
thorough understanding of 5812 I think you could replace this section
with a simple set of pointers such as:

  This document uses the terminology defined in the ForCES Model in
  [RFC5812].  In particular, the reader is expected to be familiar with
  the following terms:

  - FE Model
  - LFB (Logical Functional Block) Class (or type)
  - LFB Instance
  - LFB Model
  - Element
  - Attribute
  - LFB Metadata
  - ForCES Component
  - LFB Class Library

---

The RFC Editor will want to place the Introduction as Section 1 in this
document. It would be good if you could make this change before the
document reaches them so that you can fix any related issues that may
arise.

---

Please be sure to expand all abbreviations that are not shown as "well
known" in the list at http://www.rfc-editor.org/rfc-style-guide/
abbrev.expansion.txt on first use in the main body of text.

---

In the Introduction, you say...

  Additionally backward
  compatibility is ensured as xml libraries produced with the earlier
  schema are still valid with the new one.

How will an old implementation in the field that uses the old schema
react to an xml library produced with the new schema?

---

Section 3
Is this a "proposal" or does the WG have consensus?

---

Section 3.1

  However there are cases where complex metadata are used in the
  datapath, for example two simple use cases can be seen in the
  OpenFlow switch 1.1 [OpenFlowSpec1.1] and beyond:

  1.  The Action Set metadata follows a packet inside the Flow Tables.
      The Action Set metadata is an array of actions to be performed at
      the end of the pipeline.

  2.  When a packet is received from a controller it may be accompanied
      by a list of actions to be performed on it prior to be sent on
      the flow table pipeline which is also an array.

There are several issues with this text.

a. Are you saying that the use case is "to be able to do what OpenFlow
  does"? Or is there some specific function that you need to be able to
  perform in the context of ForCES?

b. "The Action Set metadata follows a packet inside the Flow Tables" is
  really hard to parse. It might, I suppose, make sense if I read the
  OpenFlow specification, but perhaps you could use just a few more
  words to explain what a Flow Table is, what a pipeline is, and what
  it means to "follow a packet".

c. Isn't OpenFlow 1.1 rather an old version to be referencing? As you
  are making it a normative reference, it might be best to try to be
  up-to-date.

d. I think s/prior to be sent/prior to being sent/

e. Probably s/flow table/Flow Table/

---

Figure 5

I think there are some indentation issues the fixing of which could make
the schema fragment easier to read.

---

Section 3.2

  Additionally it appends to the declaration...

What is "it"?

---

Section 3.2

I think that I can work out what is meant to happen with Figure 5, but
it would be cleaner if you gave the "before and after" fragments as you
have done in the previous two cases.

---

Section 3.2

Great and really helpful that you have provided an example in Figure 6,
but you need to briefly note it somewhere in the text.

---

Section 3.3
  In the original schema, the access type can be only be defined on
  components of LFB and not on components in structs or arrays.

s/be only/only/
s/LFB/an LFB/

---

Section 3.3

  If by accident an
  access type for a component in a capability is defined, the access
  type MUST NOT be taken into account and MUST always be considered as
  read-only.

It is polite of you, but "by accident" gives the impression that it can
be done "on purpose" with a different result. I think you need:

  The access type for a component in a capability is always read-only
  per [RFC5812]. If an access type is provided for a component in a
  capability it MUST be ignored.

---

Section 3.3

The example in Figure 9 helpfully shows the higher-level access type
that applies to the whole struct as well as an example of the fine-grain
access type applied to one of the components. However, the schema
fragments in Figures 7 and 8 do not show the higher-level access type. I
think it would be helpful if they did.

As per Figure 6, it is great to have an example, but the text needs to
make reference to it.

---

Section 3.4

  This event condition is particular useful

s/particular/particularly/

---

Section 3.5

  Experience however has proven valuable at least for debug
  reasons, to have statistics per LFB instance to monitor sent/received
  messages and errors for communication between CE and FE.

That's a bit garbled. How about...

  Experience has shown that, at least for debug reasons, it would be
  useful to have statistics per LFB instance to monitor sent/received
  messages and errors in communication between CE and FE.

---

Section 3.6

  This document augments the derivedFrom part of the LFB class
  definition with a mandatory version attribute when the derivedFrom
  field is used.

I don't see how this is backward compatible as described in the
Introduction. There you say that XML libraries produced with the earlier
schema are still valid with the new one. But this text and schema
fragment seems to require that the version attribute is present which
would mean that a user of the new schema would reject an older XML
library.

---

Section 3.6

Again, the example needs to be referred to from the text.

---

Section 3.7

  The following validation rules have been appended in the original
  schema in [RFC5812]:

This is too ambiguous. In most sections when you use the past tense
and refer to 5812 you are talking about stuff that is already in that
RFC. However, if I take that interpretation of this text then this
section is completely empty. So you must mean something else.

---

Section 4

How am I supposed to read this section compared to Section 4.9 of 5812?
There is no introductory text, and no explanation.

I suspect that this is a complete replacement of Section 4.9 of 5812 in
which case this document really does update 5812 in a fairly significant
way.

Or should you have incremented the model number?

---

6.  IANA Considerations

  This specification requests that LFB Component ID 0 to be reserved.

This statement is almost completely unhelpful to IANA!

Which registry contains the LFB Component IDs?
What information do you want IANA to record?

Section 3.5 says both "reserve" which has specific meaning according to
RFC 5226 and "for LFB properties" which seems to mean you want a
specific assignment. Although Section 3.5 does talk about "disallowing"
the value zero.

Maybe you want a registry for Component ID values? Or maybe you are
making a generic statement about the use of Component ID zero. In the
former case you have some IANA work to do. In the latter case, you need
to clarify the statement in 3.5 and change Section 6 to say that no IANA
action is required.

In the latter case, wouldn't this also be a good thing to capture in
3.7?

---

Of course, what you say in Section 7 is true, but have you considered
how the extensions in this document change the vulnerabilities described
in 5812? I think a little text on each extension/change to say whether
it increases or decreases the risks would be nice.

---

Section 8.2

RFC 2119 should be a normative reference (or at least that is how you
have used it in section 1.1).

1. Summary

The document shepherd is Jamal Hadi Salim
The responsible Area Director is Adrian Farrel

This document extends the ForCES Model document (RFC 5812) to
allow complex datatypes for metadata, optional default values for
datatypes, optional access types for structures and fixes an issue
with LFB inheritance.  The document also introduces two new features:
a new event condition BecomesEqualTo and the concept of LFB properties.

2. Review and Consensus

The extensions are straightforward, and there was no difficulty in coming
to consensus on all points described. There were earlier extensions in
earlier versions of the document that were removed based on discussions
in the WG for the sake of simplicity. At least one implementation has
validated some of the features described in the document. 
We believe the working group is solidly behind this document.
The shepherd validated the sanity of the new extensions to the XML schema
in section 4.

3. Intellectual Property

The author has confirmed conformance with BCP 78/79.
There are no IPR disclosures on the document.

4. Other Points

a) The document does not pass the full ID Nits test.
There is one error where a reference to the pre-RFC 7121 is used.
There a few editorial nit warnings.
The author has been notified to fix these issues on any new release
coming up from any other feedback.
b) There is a typo on the caption on section 4 XML (a clear cutnpaste
error from a recycled draft).
The author has been notified to fix this on the next possible opportune.