Forwarding and Control Element Separation (ForCES) Model Extension
RFC 7408

Note: This ballot was opened for revision 04 and is now closed.

(Adrian Farrel; former steering group member) Yes

Yes ( for -04)
No email
send info

(Alia Atlas; former steering group member) Yes

Yes ( for -04)
No email
send info

(Barry Leiba; former steering group member) (was Discuss) No Objection

No Objection (2014-09-02 for -04)
No email
send info
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.)

(Benoît Claise; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2014-09-02 for -04)
No email
send info
Please take a look at the nits from the Sec-dir review and respond:
http://www.ietf.org/mail-archive/web/secdir/current/msg04993.html

(Richard Barnes; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-09-04 for -04)
No email
send info
- 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
"<do more logging> if <person/addr/whatever> BecomesEqualTo
<AdrianFarrel>"

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

(Ted Lemon; former steering group member) No Objection

No Objection (2014-09-04 for -04)
No email
send info
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!