[Ballot comment]
I was interested to read...

  The current work of the working group is around operational support
  and additional extensions and optimizations of TRILL for the
  properties of the networks on which it is deployed.

Do we have a list of the networks in which TRILL is deployed?

---

  (1) Following on from the TRILL OAM requirements (RFC 6905), specify a
  framework and specific protocols for the handling of Operations,
  Administration, and Maintenance (OAM) in networks using TRILL,
  focusing on fault management and performance and taking into
  consideration existing OAM mechanisms that might apply to TRILL.

I should like it if the WG did not feel the need to invent new OAM protocols when existing ones do the job. The text doesn't say that the WG will do that, but it does leave the door pretty wide open.

---

[Ballot comment]
I was interested to read...

  The current work of the working group is around operational support
  and additional extensions and optimizations of TRILL for the
  properties of the networks on which it is deployed.

Do we have a list of the networks in which TRILL is deployed?

[Ballot block]
This will probably be the quickest block cleared ever, but I wanted to make sure we're all on the same page:

The IS-IS cleartext password authentication mechanism is not being considered "security" - right :)  You're talking about RFC 5310-based authentication?

[Ballot comment]
Following discussions with the IESG, I will ask the community during external review.

=======

I would like to understand the long term strategy for the TRILL WG.

Each version of the TRILL charter takes the protocol closer to a full function network layer mirroring all of the functions that we find in IP and MPLS. If the IETF has embarked on the strategy of developing an alternate full function network layer with open eyes, then I am fine with us continuing, but I think it is worthwhile consciously establishing that this is our goal.

It also seems to me that at some stage we need to have some discussions with the IEEE about whether it is in the best interests of the industry to continue this work in IETF, or whether the industry would be better served by the transfer all or part of the project to them.

A TRILL re-charter is a watershed moment to consider these issues, and the purpose of this block it to cause the IESG to pause for a moment and consciously review the issues above.

If it is the view of the IESG that it is in the best interests of the industry for TRILL to continue on its current trajectory I will withdraw the block.

[Ballot comment]
After discussion with Ted and Stewart (as the AD for PWE3), I would like to tighten the text as follows:

OLD
(4) Specify protocols for TRILL over pseudowires and TRILL over IP tunnels, for example to connect branch office TRILL switches to a central TRILL campus over the Internet.
NEW
(4) Specify protocols for TRILL over pseudowires using existing Pseudowire Emulation End-to-End (PWE3) standards, for example to connect branch office TRILL switches to a central TRILL campus over the Internet.

[Ballot block]
I would like to understand the long term strategy for the TRILL WG.

Each version of the TRILL charter takes the protocol closer to a full function network layer mirroring all of the functions that we find in IP and MPLS. If the IETF has embarked on the strategy of developing an alternate full function network layer with open eyes, then I am fine with us continuing, but I think it is worthwhile consciously establishing that this is our goal.

It also seems to me that at some stage we need to have some discussions with the IEEE about whether it is in the best interests of the industry to continue this work in IETF, or whether the industry would be better served by the transfer all or part of the project to them.

A TRILL re-charter is a watershed moment to consider these issues, and the purpose of this block it to cause the IESG to pause for a moment and consciously review the issues above.

If it is the view of the IESG that it is in the best interests of the industry for TRILL to continue on its current trajectory I will withdraw the block.

[Ballot comment]
A terminology comment:

  (1) Following on from the TRILL OAM requirements (RFC 6905), specify a
  framework and specific protocols for the handling of Operations,
  Administration, and Maintenance (OAM) in networks using TRILL,
  focusing on fault management and performance and taking into
  consideration existing OAM mechanisms that might apply to TRILL.

I have a concern with the terms OAM framework and OAM protocols.
OAM is not about extra protocols. This is about in band, data plane management.
Btw, this is in line with RFC6905 (from what I call recall from the table of content).

RFC 6291 and RFC 6905 speak about "OAM functions".

Proposal:
  (1) Following on from the TRILL Administration, and Maintenance (OAM)
  requirements (RFC 6905), specify OAM functions for TRILL data plane
  management, focusing on fault management and performance and taking
  into consideration existing OAM mechanisms that might apply to TRILL.

Not really a block, but please correct this, or let's discuss it.

[Ballot comment]
A terminology comment:

  (1) Following on from the TRILL OAM requirements (RFC 6905), specify a
  framework and specific protocols for the handling of Operations,
  Administration, and Maintenance (OAM) in networks using TRILL,
  focusing on fault management and performance and taking into
  consideration existing OAM mechanisms that might apply to TRILL.

I have a concern with the terms OAM framework and OAM protocols.
OAM is not about extra protocols. This is about in band, data plane management.
Btw, this is in line with RFC6905 (from what I call recall from the table of content).

RFC 6291 and RFC 6905 speak about "OAM functions".

Proposal:
  (1) Following on from the TRILL Administration, and Maintenance (OAM)
  requirements (RFC 6905), specify OAM functions for TRILL data plane management,
  focusing on fault management and performance and taking into
  consideration existing OAM mechanisms that might apply to TRILL.

Not really a block, but please correct this, or let's discuss it.

[Ballot comment]
A terminology comment:

  (1) Following on from the TRILL OAM requirements (RFC 6905), specify a
  framework and specific protocols for the handling of Operations,
  Administration, and Maintenance (OAM) in networks using TRILL,
  focusing on fault management and performance and taking into
  consideration existing OAM mechanisms that might apply to TRILL.

I have a concern with the terms OAM framework and OAM protocols.
OAM is not about extra protocols. This is about in band, data plane management.
Btw, this is in line with RFC6905 (from what I call recall from the table of content).

RFC 6291 and RFC 6905 speak about "OAM functions".

Proposal:
  (1) Following on from the TRILL Administration, and Maintenance (OAM)
  requirements (RFC 6905), specify OAM functions for TRILL data plane management,
  focusing on fault management and performance and taking into
  consideration existing OAM mechanisms that might apply to TRILL.

Not really a block, but please correct this, or let's discuss it.

[Ballot block]
I would like to discuss item 4 in the list of work items.

> (4) Specify protocols for TRILL over pseudowires and TRILL over IP
> tunnels, for example to connect branch office TRILL switches to a
> central TRILL campus over the Internet.

I am unclear how an "IP tunnel" is not an IP pseudowire.

I see three potential meanings for "protocols":
- Trill protocols to use PWs as virtual links in the Trill network
- Protocols to set up PWs
- Protocols to encapsulate Trill in PWs
Which of these is intended? I would think that the second and third belong in the PWE3 working group.

[Ballot block]
I readily admit that this is way out of my area of expertise, but something seems missing in this charter. I don't understand the deliverables. (I wouldn't have understood the deliverables of the previous charter either, but it was done before my time.) I can't figure out from the list of 1 through 8 which of these items are actual protocol work (sounds like maybe 2, 4, 5, and 6 might be), which ones are "applicability statements" (in the sense of putting together existing protocol pieces to form a system; 1 and 3 sound like they are, but some of 2, 4, 5, and 6 might be too), and which are strictly informational (maybe 7 and 8, maybe others). I'd like some clarifications of what the plans for this WG are.