Re: [Banana] Charter

[Margaret Cullen <[e-mail]>]

> On Sep 19, 2017, at 1:13 AM, Suresh Krishnan <[e-mail]> wrote:
> 
> Hi all,
>  I think extreme positions on the suitability of the posted charter (“It is perfect” to “It is worthless”) are not likely going to help moving forward. The idea of putting up the proposed charter for review is to bring out opinions and to modify the charter to make it more widely applicable to a larger community. I am glad that we are having this discussion right now on the list.

I agree Suresh.  It’s good to get some feedback on the charter text that we can use to improve it.  It would also be good to get some feedback on proposed improvements, like the proposal I made to add mention of NAT boxes and remove mention of GRE, for instance.  

> If you think the charter does not clearly describe a problem to be solved, that is something that certainly needs to be fixed. The best way to fix the charter is by proposing edits (add/modify/delete) and see if the participants in this ML are fine with those changes. Regarding conflicts, once the charter gets sent to me there will be further levels of review to see if the work conflicts with other ongoing IETF work (e.g. in mptcp) during the IESG Internal Review and the external review by the entire IETF community. So I am not very worried about this part. If people feel that writing down a clear problem statement is a way to make progress I am fine with starting with that too as long as the recommendations specified in the IESG statement at
> 
> https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html
> 
> are understood and followed.

I think this is an excellent statement, and will help us to avoid drawn out processes that exhaust participants and kill new work before it really gets started.

We actually talked during the BOF about the idea of having informal WG material on use cases, and I don’t think I captured that discussion in the charter.  I will extend that to the problem statement, and I will make a specific proposed wording change in another thread.  Perhaps that will help to resolve the concerns that the problem is not properly understood? 

There has also been an issue raised that the charter is insufficiently clear that the items listed (provisioning, signaling and encapsulation protocols) may not be new protocols, but may instead involve the reuse (and possible extension?) of existing protocols.  I will borrow from Nic Leymann’s wording and make a proposed change in another thread to address that concern.

If people have other concerns with the charter, or suggestions to improve it, it would be great to send them now, so that we can send the best possible version of this charter to the IESG and IETF for consideration.

Margaret