Hi, Alia, Please find one or two questions inline.
On Jul 23, 2016, at 7:59 PM, Alia Atlas <[email protected]<mailto:[email protected]>> wrote: Please note that the question asked if, given the IETF's mission to make the Internet work & work better, what is the correct answer. I personally do not see that multiple solutions in this space help. When one considers the amount of added complexity on top - considers 3x extensions, 3x work to implement, and reduced interoperability, and so on. I should also be clear. If these drafts were published as Informational (I don't see any experiment to be run or answered), then there are at least 5 additional aspects that would happen. 1) Each would contain a paragraph at the start of the document that says roughly "This document describes an approach considered by the NVO3 Working Group, but the Working Group was unable to come to consensus on one approach. This approach is documented for information here. " Just trying to understand — from a process perspective: how does this play with a Charter (i.e., the “contract between a working group and the IETF to perform a set of tasks” [RFC 2418]) that says “one or more data plane encapsulation format(s)”? 2)No Standards Track work could refer to it. This would not be a permitted down-reference. Not having heard from a not-permitted down-ref before, I am curious. I always thought that the downref consensus call belongs in the citing document, not in the cited document. How does this work? Do you have a precedence of a “not be a permitted down-reference”? 3) It would be clear that gaining consensus on anything even mildly contentious is highly unlikely. I do not see any conflicts plane work happening. s/conflicts plane/control-plane/ ? 4) With the exception, possibly, of some Standards Track OAM work that can be commonly used, there would be nothing left for the Working Group to do. 5) Considering the lack of progress and discussion on all these drafts, I would question whether the drafts will be ready for publication in a reasonable time-frame. You said above “5 additional aspects that would happen”. I’m not clear on this one, what is the aspect that would happen in #5? That you would question it, or something else? Thanks, — Carlos. I would greatly appreciate hearing from more people and specifically non-authors on this matter. The consensus in the room was screaming clear. I am startled by the difference so far on the mailing list. I am, of course, quite happy & willing to listen to good reasoning on this matter. However, if NVO3 were to have no standards track work to do, I am quite likely to close it within the year. Regards, Alia On Jul 22, 2016 9:11 PM, "Linda Dunbar" <[email protected]<mailto:[email protected]>> wrote: +1. Besides, IETF already has specified many encapsulations, is it really that bad having one extra? Linda From: nvo3 [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Anoop Ghanwani Sent: Friday, July 22, 2016 7:55 AM To: Bocci, Matthew (Nokia - GB) Cc: NVO3 Subject: Re: [nvo3] Consensus call on moving forward with a single encap. On Thu, Jul 21, 2016 at 7:52 AM, Bocci, Matthew (Nokia - GB) <[email protected]<mailto:[email protected]>> wrote: Please respond to this email on the NVO3 list by 29th July 2016: - Given the IETF's mission, should NVO3 move forward on the standards track with a single encapsulation on the standards track? If not, please explain your concern in detail. While the world would be a better place with only one encapsulation, I think it's better to stick with the original path of allowing the 3 encapsulations as experimental. The NVO3 charter says: >>> Based on these requirements the WG will select, extend, and/or develop one or more data plane encapsulation format(s). >>> Based on the charter, the WG has gone through the process of accepting to work on 3 encapsulations. What do we know now that we did not know back then? If we were going to progress only a single encapsulation, I think there would have been more critical feedback and strong suggestions for changing that "winning" encapsulation to accommodate what the other encapsulations perceive as their relative strengths. And we risk opening up that discussion now and delaying progress even more. Otherwise, not having a standard has not been a hinderance for getting protocols deployed in the past, and I suspect that if the developers of these encapsulations care enough, we will see deployments of all of them regardless of whether or not we progress them within the working group. Thanks, Anoop _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
