MBONE Deployment
charter-ietf-mboned-05

[Ballot comment]
As I was convinced to remove my previous BLOCK, I cannot really BLOCK it again.

But, I can only ballot ABSTAIN because I fail to understand *why* the charter does not specify the intended status of each deliverable in order to have a well-defined scope. This is as simple as:
```
.. will include the following work areas *with a publication intended status of standard track except when noted*:
Receive regular reports on the current state of the deployment of multicast technology *(not to be published as a RFC)*
Document deployment of multicast routing in the global Internet *(as an informational RFC)*
Capture the operational experience of those who have deployed and are deploying various multicast technologies *(as an informational RFC)*
Identify, develop, and maintain mechanisms to address transport-layer and security-related gaps that hinder broader multicast deployment....
```

[Ballot block]
I am afraid that citing all existing intended publication statuses is too broad, i.e., there is a lack of technical clarity on the deliverables. Please use a smaller ranges for each work areas. E.g., I guess that `Receive regular reports on the current state of the deployment of multicast technology` is 'not to be published' and `Develop and maintain data models` is standard track.

[Ballot comment]
Please spell out MBONE upon first use.

If one lists all possible document status options, that is better than leaving it blank?  Seems odd.

'procedures to address transport and security gaps inhibiting the deployment of multicast'  Please clarify what it means to address security gaps that inhibit deployment. 

SAAG isn't really a working group, it is a mailing list.

[Ballot comment]
"WG", paragraph 2
> * Document deployment of multicast routing in the global Internet.
>
> * Receive regular reports on the current state of the deployment of multicast
> technology.
>
> * Capture the experience of those who have deployed and are deploying various
> multicast technologies.

My comment is similar to Roman's. These three bullet items are all talking about the deployment of multicast in the Internet. They can be easily collapsed into one.

"WG", paragraph 2
> * Develop and maintain mechanisms and procedures to address transport and
> security gaps inhibiting the deployment of multicast.

I understand developing mechanisms and procedures to address ..." But what does it mean to "maintain"? Is it referring to a -bis of document(s)?

"WG", paragraph 4
> * Develop data models and other automation building blocks related to the
> operation of multicast services.

Similarly, what are "automation building blocks"? Is this referring to service-level models?

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
  "intrinsic", "original"

Ask about any chair changes.

[Ballot comment]
Hi Med, kindly find a few textual proposed alternative writings to help frame the WG objectives.

# The MBONED WG is chartered to produce Standards Track, Informational, Best Current Practices, and Experimental RFCs. The MBONED WG activity will include, but not be limited to:

GV> [proposed]

"
The working group is chartered to produce Standards Track, Informational, Best Current Practices (BCP), and Experimental RFCs as appropriate. The focus of MBONED is practical and deployment-driven, with an emphasis on operational experience and the advancement of multicast technologies in diverse environments.

The scope of MBONED includes, but is not limited to, the following work areas:
"

# Document deployment of multicast routing in the global Internet.

GV> making it more explicit that it is about the state and evolution of multicast routing deployments on the global Internet
"
Documenting the state and evolution of multicast routing deployments in the global Internet.
"

# Receive regular reports on the current state of the deployment of multicast technology.

GV> Added a indicator from whom to receive reports
"
Receiving and sharing regular updates on multicast technology deployment status from the operational community.
"

# Capture the experience of those who have deployed and are deploying various multicast technologies.

GV> formalized more explicit from whom to expect such experiences
"
Capturing and documenting operational experience from network operators deploying multicast technologies.
"

# Develop and maintain mechanisms and procedures to address transport and security gaps inhibiting the deployment of multicast.

GV> Clarified that these are observations that identify hinder deployments
"
Identifying and developing mechanisms to address transport-layer and security-related gaps that hinder broader multicast deployment.
"

# Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects.

GV> unclear if interconnects is referencing multicast-IXP to interconnectivity of multicast enabled networks
"
Defining procedures and best practices for sharing operational data to improve the manageability and interconnectivity of multicast networks.
"

# Develop and maintain tools and protocols that assist in multicast administration, diagnostics, troubleshooting, and deployment between/within native and non-native environments (e.g., Mtrace and Automatic Multicast Tunneling (AMT)).

GV>
"
Developing and maintaining tools, protocols, and procedures that assist with multicast administration, diagnostics, troubleshooting, and interoperability between native and non-native multicast environments (e.g., Mtrace and Automatic Multicast Tunneling (AMT)).
"

# Develop data models and other automation building blocks related to the operation of multicast services.

GV> slightly widen the acceptable scope on automation to include the maintenance of such building blocks
"
Creating and maintaining data models and other automation-enabling components that support the operation of multicast services.
"

# Explore and develop tools and mechanisms applicable to multicast deployment in emerging environments (e.g., decentralized systems and overlay networks) or other contexts where conventional deployment models may not suffice.

GV>
"
Investigating and proposing tools and mechanisms for multicast deployment in emerging use cases, such as decentralized systems, overlay networks, or environments where traditional multicast deployment models may be insufficient.
"

[Ballot comment]
** What is the difference between these two bullet points?

==[ snip ]==
* Document deployment of multicast routing in the global Internet.
* Receive regular reports on the current state of the deployment of multicast technology.
* Capture the experience of those who have deployed and are deploying various multicast technologies.
==[ snip ]==

** What is the concrete deliverables of this scope:

==[ snip ]==
* Explore and develop tools and mechanisms applicable to multicast deployment in emerging environments (e.g., decentralized systems and overlay networks) or other contexts where conventional deployment models may not suffice.
==[ snip ]==

-- The IETF doesn’t develop “tools”

-- What does it mean to “explore … mechanisms”?

-- What does it mean to “develop … mechanisms appliable to multicast development in emerging environments …”?  What are these mechanisms?  This text seems to be describing where the work would be fielded.

** What does it mean to develop requirements for other WGs as it relates to the standards process? 

==[ snip ]==
  The MBONED WG may develop
  requirements and assist in review and feedback of documents in other working
groups responsible for such protocols
==[ snip ]==

[Ballot comment]
I find the top-level statement that cover all the tracks as not really helpful and very misleading. Instead, the type of track should be ideally mentioned against the work-items/work areas instead.

[Ballot comment]
Unsure if this really is a "block", because I support this set of work. However I would like to query how the work on a specific milestone: draft-ietf-mboned-cbacc could usefully engage with CCWG (or TSVWG). The expertise for multicast lies in the mboned group, but the wider review expertise on CC likely resides in CCWG.

[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?