Ballot for charter-ietf-rift
Yes
No Objection
Abstain
Note: This ballot was opened for revision 00-04 and is now closed.
Ballot question: "Is this charter ready for external review?"
I'm always concerned when a charter is specifically based on a document: "The RIFT Working Group is chartered for the following list of items: - A Standards Track specification based on draft-przygienda-rift. The document will include:" What happens if, after chartering, the WG discovers a major issue, and/or decides to rewrite draft-przygienda-rift from scratch? Perhaps it should instead be something like: "A Standards Track specification addressing the requirements in draft-przygienda-rift"? Or moving the document itself into milestones? Note that this is just a comment; I won't be offended if you choose to ignore it :-)
The charter is hard to understand for a non specialist. Expanding acronyms on first use/adding references would help.
I agree with the comments about basing charter deliverables on specific documents. Perhaps the proper term should be "consider as input".
- A YANG module focused on configuration of protocol instances I hope that this work item is - A YANG module focused on configuration and monitoring of protocol instances Editorial - A Standards Track specification based on draft-przygienda-rift. The document will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.) The sentence starting with "- Security and Privacy Considerations, ..." should have a new line.
Not sure if the Threat Analysis and Applicability Statement need to be separate documents or published in an RFC at all.
I THINK I'm happy to see this work go forward, but I am almost sufficiently confused by the current charter to say "not ready for external review yet". Should be easy to fix, though, so not Blocking. (Could you spell out "Clos" on first use? I had to google that) It seemed to me that at least some of the discussion in DCROUTING BOF described some of the reasons why "routing in data centers is different". It would be helpful to me, if there was a mention of at least one or two differences that make new protocol work necessary or desirable. I mean, like, one sentence. It's possible to reverse-engineer that out of the bulleted list a bit further down, but that's kind of new-participant-hostile. The description of the protocol that the working group would deliver is tied to the deliverable based on draft-przygienda-rift, is that right? I had to look at the table of contents for draft-przygienda-rift to figure that out - and even then, I'm not sure. Perhaps - A Standards Track **routing protocol** specification based on draft-przygienda-rift. The document will include: - an Implementation Status section as described in RFC 7942 - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.) ?
I also share Ben and Warren's concern on naming a specific document as the deliverable even though I think it might be the best candidate.
I am a co-author on draft-przygienda-rift and thus a proponent for the WG.