Hi Thomas, I'm not opposed to this work at all. But I think that the extensive use of the word "service" in the document may cause a load of confusion.
As far as I can see, this YANG model is about operating and monitoring the network components and protocols that are used to realize (deliver) the service. This is all information that the network operator (service provider) cares about deeply, and that the equipment vendor must understand. But a lot of it is beyond the concern (or understanding) of the service consumer who has requested the service. If I might compare with the work of L3SM, we need to distinguish between the "service model" on the interface between the customer and the operator, and the "service delivery model" on the northbound interface of an orchestrator". It may be helpful to consider two separate conceptual components: a "service orchestrator" that consumes a service model, and a "network orchestrator" that consumes the model in this document and uses it to work out what to tell protocols, network controller, etc. Perhaps the document could be enhanced by a little extra text explaining how the model will be used. This need not be pages and pages, just a simple statement that, for example, it is expected that this model will be used by the management tools run by network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. Might I ask also that one sentence is removed from the Abstract *before* adoption? This is a living document and contains aspects of object models that have been discussed extensively in the working group with consensus. It is not the place of the authors to claim consensus for the content of the document: that call belongs to the WG chairs in response to targeted questions to the WG. WG adoption is not a measure by which to determine consensus for the content of the document, either. Additionally, the Introduction has: The definition work is undertaken initially by a smaller working group with members representing various vendors and service providers. I'm sure you don't mean to imply any subversion of the IETF process, and I am equally sure that this is just a matter of English usage. I think you need... The definition work was initially undertaken initially by a small group of co-authors with members representing various vendors and service providers. Again, this change needs to be made before adoption. Thanks, Adrian > -----Original Message----- > From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin > Sent: 04 May 2016 15:18 > To: bess@ietf.org > Cc: draft-shah-bess-l2vpn-y...@tools.ietf.org > Subject: [bess] Poll for adoption: draft-shah-bess-l2vpn-yang > > Hello working group, > > This email starts a two-week poll on adopting > draft-shah-bess-l2vpn-yang [1] as a working group document. > > Please state on the list if you support adoption or not (in both cases, > please also state the reasons). > > This poll runs until *May 25th*. > > This call runs in parallel with the adoption call on > draft-brissette-bess-evpn-yang hence the extended period. > > > We are *coincidentally* also polling for knowledge of any other > IPR that applies to this draft, to ensure that IPR has been disclosed > in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > ==> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any > relevant IPR. > > The draft will not be adopted until a response has been received from > each author and contributor. > > If you are not listed as an author or contributor, then please > explicitly respond only if you are aware of any IPR that has not yet > been disclosed in conformance with IETF rules. > > Thank you, > > Martin & Thomas > bess chairs > > [1] https://datatracker.ietf.org/doc/draft-shah-bess-l2vpn-yang > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
