Ballot for charter-ietf-lisp
Yes
No Objection
Note: This ballot was opened for revision 03-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
I support Jari's concerns about clarity for what is on Standards Track and what is intended for Experimental. I also have some concerns about the "The scope of the LISP technology is recognized to range from unicast and multicast overlays at Layer 2 as well as at Layer 3, including NAT traversal, VPNs, and supporting mobility as a general feature, independently of whether it is a mobile user or a migrating Virtual Machine (VM), hence being applicable in both Data Centers and public Internet environments." as that seems to basically claim that LISP is recognized and intended to solve all those problems in a Standards track way - even when there are already clear and deployed standardized ways to do so. I'd prefer to change "recognized" to "potentially applicable" or at a minimum "recognized to potentially range"
I agree with Joel in that some more detail on the deliverables would be nice — also, some of the expected interactions should be called out; for example, for the multicast item I would expect interaction with the pim WG, etc.
- One advantage of doing a late review is that much has been said. I basically agree with all comments made the IESG so far. In particular with Jari: the charter is basically an initial promise. As such it should contain the right expectations (ex: standards track), and ideally the milestones (however, we don't have a clear consensus with the IESG on the milestones, so I won't insist). - "Besides this main focus, the LISP WG may work on the following items:" "May" is weird, when you have already adopted a WG. Ex: draft-ietf-lisp-yang-01.txt - Finally, - Management models: Support for managing the LISP protocol and deployments that include data models, as well as allowing for programmable management interfaces. These management methods should be considered for both the data-plane, control plane, and mapping system components. We speak about the management of the experimental RFCs or the new standards track document? Please clarify
I agree with Terry that priorities should be spelled out. This is important given the number of potential new work items that keep popping up on the LISP mailing list.
I had asked a clarification on which parts of the work of the WG will be going standards track and which parts experimental. The answer and suggested edits to the charter have made it clearer. Thank you. For what it is worth, I believe the working group should not put the entire list of work items (9 previous RFCs to be re-worked plus 7 new ones) targeting standards track. The new charter text has language that the situation will be evaluated for the new charter items, but at least my read of it gives a default answer of "standards track". In my view there are work items that would benefit from being targeted for an experimental round before made standards, and I thought the charter should have said that. There was pushback for my suggestion to do that, however. I do not plan to stand in the way of the working group making this charter update, but I wanted to be on record that the I didn't think this was a good idea.
I am sympathetic to the idea that we should curating the existing work with an eye towards what worked and what didn't. I would personally like to see the new work items more fleshed out with respect to what the deliverables are supposed to look like, mostly the mobile and multicast items need to be fleshed out I think.
This text "The LISP WG is chartered to continue work on the LISP base protocol with the main objective to develop a standard solution based on the completed Experimental RFCs and the experience gained from early deployments." might be clearer if it said "a standards-track solution".
I'm happy to see the encryption work item. Thanks for working on that.
I think it is appropriate to take the both the experimental RFCs with early deployment experience and develop them into PS. Can the priority of that work be highlighted in the charter as more than just the "main"? eg it IS the number one priority, forsaking all others. ... And clearly once that is achieved a charter mod can certainly occur to readdress the priority balance. My rationale is that while there may be fluctuations in the base spec there is a product/user base in existence, a following raft (10) of draft WG documents and even more Individual submissions, that could be impacted by any necessary changes in moving from Experimental to PS. I don't object to the additional scope of items, in fact I encourage it - but in a sane balance of making the base spec robust with reward of working on shiny new things in a way that informs the Experimental ==> PS tango. So these additional scope of "may" be worked need not be listed as a priority and the WG can establish its own ordering with that in mind. I concur with others, having an explicit list of the WG (or liaison group) interactions spelled out here early would be beneficial to those target WGs and the sanity of the chairs and ADs in cross area coordination.