Routing In Fat Trees
charter-ietf-rift-01

[Ballot comment]
Thanks for considering my comments during internal review.

I did have one other suggestion - the first deliverable doesn't actually say it's for a routing protocol. Perhaps

s/A Standards Track specification/A Standards Track routing protocol specification/

?

[Ballot block]
I appreciate the work on a threat analysis, I'd like to see something in the charter that includes security mitigations in the protocol resulting from the threat analysis work.  Can you adjust the text to include this?

Perhaps something like:

OLD:
- A Standards Track specification that 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.)

- A YANG module focused on configuration and monitoring of protocol instances

- An Applicability Statement that describes how to deploy and configure the
protocol in networks with different topologies

- A Security Threat Analysis document that describes the attack vectors and
mitigations that shall be sent for publication at the same time as the
protocol specification

NEW:
- A Standards Track specification that 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 mitigations
  for the protocol as identified in the threat analysis document.

- A YANG module focused on configuration and monitoring of protocol instances

- An Applicability Statement that describes how to deploy and configure the
protocol in networks with different topologies

- A Security Threat Analysis document that describes the attack vectors and
mitigations that shall be sent for publication at the same time as the
protocol specification

[Ballot comment]
- 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.

[Ballot comment]
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.

[Ballot comment]
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 :-)

[Ballot comment]
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.)
 
?