Forwarding and Control Element Separation (ForCES) Model Extension
draft-ietf-forces-model-extension-05
Yes
(Adrian Farrel)
(Alia Atlas)
No Objection
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Richard Barnes)
(Spencer Dawkins)
Note: This ballot was opened for revision 04 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -04)
Unknown
Alia Atlas Former IESG member
Yes
Yes
(for -04)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2014-09-02 for -04)
Unknown
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 IESG member
No Objection
No Objection
(for -04)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -04)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -04)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-09-02 for -04)
Unknown
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 IESG member
No Objection
No Objection
(for -04)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -04)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-09-04 for -04)
Unknown
- 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 IESG member
No Objection
No Objection
(2014-09-04 for -04)
Unknown
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!