MBONE Deployment
charter-ietf-mboned-04

[Ballot block]
I have no general concern about the updated charter but about the milestone " Submit multicast transport guidelines for congestion control to IESG". This has been also noted by the TSVWG chairs.

This is not part of the mboned wg and clearly a work item for the transport area and more specific for the TSVWG. There are pending discussions around this.

I can see that there is strong coordination needed between the multicast community and the transport community.

[Ballot comment]
The change in -02 from "develop tools and protocols" to "develop tools, extend protocols" satisfies my concern nicely.  I also like splitting that bullet into two, putting the out-of-scope stuff into a separate bullet.  Thanks for considering my comments.

[Ballot block]
This should be easy to resolve.
I presume that the milestone for Mtracev2 relates to the new protocol development work item.  But the work item is written abstractly, as though there were nothing currently planned.  If there is already something in the works, such that there's a milestone for it, I think the work item needs to say that explicitly, and make it clear whether this is all, or there might be more.

UPDATE:
I guess the above isn't clear, so let me try a different approach:

  Develop tools and protocols that assist in multicast administration,
  diagnostics, troubleshooting and deployment between/within native
  and non-native environments.

As this is taking the WG from an explicit position of NOT working on protocols to one where certain protocol work is allowed, I'm concerned about how abstract the statement is.  It appears to give the WG a great deal of latitude in developing a broad set of (perhaps many) protocols.  Is that really appropriate?  Do we want to put any further boundaries on it?  Is Mtracev2 one of the proposed protocols?  If so, should we say that?  Do we expect there to be more besides?  One or two?  Many?

[Ballot comment]
So I'm not blocking this charter update, but:

1) This sentence makes me wonder whether it should be scoped a little more because this phrase:

  This activity will include, but not be limited to:

is basically a blank check.

2) Agree with Adrian.

[Ballot comment]
Not issues that are worthy of blocking this recharter, but...

1. A recharter to "reflect what the working group is currently doing" is not (IMHO) the best motivation for a recharter. It would be best to view this as chartering to do what there is consensus to do and what the IESG/community considers to be worth working on. Probably no difference in the outcome :-)

2. How is "the deployment of multicast on the global Internet" going? It seems to me that it might not be doing very well. Should the WG be examining what the current blocks to deployment are and deciding whether specific action is needed to remove these blocks, or (perhaps) that deployment of multicast on the global Internet is not taking off for a good reason? These seem like slightly stronger deliverables than the overview and guidance milestones currently suggested.

[Ballot block]
This should be easy to resolve.
I presume that the milestone for Mtracev2 relates to the new protocol development work item.  But the work item is written abstractly, as though there were nothing currently planned.  If there is already something in the works, such that there's a milestone for it, I think the work item needs to say that explicitly, and make it clear whether this is all, or there might be more.

[Ballot comment]
Minor editorial nit (unchanged from the old charter): the first work item is not a parallel construct to the others (it uses a gerund, while the others don't).  Please change "Documenting" to "Document", to fix that.

[Ballot comment]
Two points to consider, but I am not going to block on these...

1. The opening paragraph limits the role of the WG to multicast in the global Internet.  However, there are numerous times where the WG spends cycles discussing the deployment of multicast protocols in more limited environments.  Should the charter reflect that reality and document that the group spends cycles on the deployment of IP multicast protocols?

2. The last bullet somewhat removes the restriction on the WG doing protocol work.  Should we simply state that protocol work is allowed when: 1) there is not a current WG that covers the work, 2) the work item does not require a dedicated WG, and 3) the work is directly related to multicast deployment/management/operation?