Xian, This is not accurate I'm afraid. We have presented the original (pre-split) draft at almost every meeting for the past several years, and have had WG consensus on it's acceptance as a WG document on both list and in meetings. as well as We have discussed the split at the last three consecutive IETF meetings, and explicitly asked the chairs in Vancouver. This document is simply the core framework split from the /already accepted/ working group document, and the chairs had agreed to accept the core document as a draft given that the parent doc had already been accepted and (assuming near content parity).
So yeah, there's been quite a bit of discussion on this over a number of years. :P I'm not sure that issuing an applicability draft first is mandatory SOP; there are a number of drafts that simply have an applicability section within the draft (as ours does): presenting applicability, requirements and framework sequentially. With regard to our (now public) conversation, you've misinterpreted. Last IETF we discussed moving the applicability section into the a single document with you (without conclusion I might note), which has nothing to do with this draft. We tentatively agreed to move ahead with merging the already extant applicability section of our draft into yours as well as assuming co-authorship. We also agreed that the *framework* must provide the capability to create general extensions for MPLS & GMPLS etc (thus /passing mention/ of GMPLS AND the reference to *YOUR* document. cheersm -ed On Thu, Oct 18, 2012 at 2:23 AM, Zhangxian (Xian) <[email protected]>wrote: > Hi, PCE'er, > > I just noticed that this WG document has been updated without any WG > decisions/discussions. As I recall, there is no sufficient discussion > during last IETF meeting, nor any public email discussion, with regard to > how to proceed with this WG document. As a young engineer involved in IETF > work, a standard way for updating a WG document, from what I observe, > should it be that any modifications are based on the WG discussion? > > During last IETF meeting, I presented a proposal with regard to > "stateful PCE" work. To state again, we would like to see this work follows > a standard PCE WG procedure. By saying a standard procedure, I mean that > "stateful PCE" should be driven by applicability/framework/requirements, > then protocol extensions. Just to give a few examples which is currently > listed as PCE WG drafts as well as RFCs: pcep extension for gmpls, > inter-layer, hierarchical PCE and P2MP etc. All of them moved forward with > applicability/framework/requirements first. There must be a valid reason > for this rationale, right? I do not see why we should treat this draft as > an exception. > > Unfortunately, we were not given sufficient time for a WG discussion > on our proposal. However, as suggested by Ed., a bunch of us (Ramon, Oscar, > Fatai, Young and me) had an offline discussion with him, and the group > roughly agreed to move forward to the direction that we proposed above. > > However, I don’t see this draft is moving to that direction from the > updated WG draft, even though one of our suggestions (i.e., GMPLS should be > covered) is partially captured in the updated WG draft. > > Therefore, I would like to request more discussion in the PCE list on > how to move forward stateful PCE topic. > > > Regards, > > Xian > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: 2012年10月16日 6:08 > To: [email protected] > Cc: [email protected] > Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working Group > of the IETF. > > Title : PCEP Extensions for Stateful PCE > Author(s) : Edward Crabbe > Jan Medved > Ina Minei > Robert Varga > Filename : draft-ietf-pce-stateful-pce-02.txt > Pages : 49 > Date : 2012-10-15 > > Abstract: > The Path Computation Element Communication Protocol (PCEP) provides > mechanisms for Path Computation Elements (PCEs) to perform path > computations in response to Path Computation Clients (PCCs) requests. > > Although PCEP explicitly makes no assumptions regarding the > information available to the PCE, it also makes no provisions for > synchronization or PCE control of timing and sequence of path > computations within and across PCEP sessions. This document > describes a set of extensions to PCEP to enable stateful control of > MPLS-TE and GMPLS tunnels via PCEP. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
