Fernando, all, Acknowledging that the IESG has received this. Regards, Alissa Cooper IETF Chair > On Apr 22, 2020, at 10:26 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: > > IESG, > > As we had promised to the 6man WG and the Spring WG, we are contacting you to formally appeal the declaration of WG consensus to progress draft-ietf-spring-srv6-network-programming. > (we are cc'ing the 6man WG, the Spring WG, and the general IETF list for the sake of transparency and openness). > > * Appellants: > > Fernando Gont <fgont@xxxxxxxxxxxxxxx> > Andrew Alston <Andrew.Alston@xxxxxxxxxxxxxxxxx> > Sander Steffann <sander@xxxxxxxxxxx> > > > * Description of the Dispute > > Recently, Spring WG consensus to progress draft-ietf-spring-srv6-network-programming was declared. However, we believe that major concerns raised as part of the WGLC of this document remained unaddressed at the time WG consensus was declared. Additionally, we believe that the WGLC process has not been handled with appropriate transparency. > > A Working Group Last Call (WGLC) was initiated on December 15, 2019 for the document draft-ietf-spring-srv6-network-programming [WGLC], by one of Spring WG co-chairs, Bruno Decraene. > > During the WGLC process, a number of concerns were raised on the document. While there have been ongoing discussions on some of these concerns, they remained unaddressed at the time consensus was declared, and it is unclear if the version of the document that has been shipped for publication has successfully addressed them, since the working group has not been given the chance to review the document that was shipped to the IESG for publication, with adequate time to comment. Among others, the aforementioned concerns include: > > 1) Participants requested a justification for the need of PSP > (Penultimate Segment Pop). [PSP-R] > > Essentially, there is no general understanding on why PSP is needed. > Additionally, there have been concerns that PSP may be harmful. > Therefore, more analysis is needed both to justify the > specification of PSP, and to identify possible drawbacks associated > with it. > > 2) Participants have argued that PSP violates RFC8200 [IPV6-V] > > Many participants have argued that, while the wording in RFC8200 is > far from perfect, the intent of RFC8200 has been to forbid en-route > header insertion/removal; as such, PSP is in violation of RFC8200. > At the very least, draft-ietf-spring-srv6-network-programming should > note that it is employing one very specific interpretation of RFC8200 > for the WG and the IETF community as a whole to have the necessary > elements to make a decision on this document when reviewing it as > part of the standardization process. > > 3) Participants noted that PSP violates the specification of routing headers [SR-V] > > PSP implies that the penultimate segment firstly processes a routing > header (as implied by RFC8200 and specified by RFC8754) and that, > if the penultimate segment finds that Segments Left == 0, the segment > routing header be removed. This later behaviour deviates from RFC8200 > and RFC8754. As such, the working group should decide whether such > documents should be updated by a separate effort in the relevant > working group (6man). We believe that > draft-ietf-spring-srv6-network-programming cannot proceed specifying > PSP before this issue has been resolved. > > 4) Participants requested a more prescriptive SID format [SID] > > Since SIDs are eventually employed as IPv6 addresses in the > forwarding plane, it may be necessary to specify SIDs in a more > prescriptive way. Namely, require that SIDs result in IPv6 > Unicast Addresses, and that conflicts with e.g. IPv6 reserved > addresses be avoided. > > 5) Participants questioned whether the SID format is deployable > > The draft specifies a SID format, which is automatically an IPv6 > prefix format. Concerns have been raised both on-list and at > an IETF meeting about the required address space needed to deploy > the technology described in the draft. Especially because a > presented example uses a /40, which is more than many networks have. > While discussing the document early on at an IETF meeting [SIZE-V], > better data on this was promised, but never delivered. While > restricting the used prefix sizes is not appropriate in this draft, > the authors, chair and responsible AD have consistently ignored > requests for real-life examples that demonstrate that the draft is > deployable with the current RIR policies, or that cooperation with > RIRs is necessary to make it deployable in the future. This issue was > noted yet once again before WGLC consensus was declared [SIZE-L]. > > > The request for justification of PSP was dismissed by Bruno Decraene, noting that > > "I don't think that the SPRING WG can really evaluate this point > (lack of hardware knowledge, lack of detailed information on the > hardwares). The fact that this has been implemented by some platforms > and deployed by some operators, is, to me, an indication that it is > useful for those cases." [WGLC-O]. > > We note that the same group that allegedly does not have the necessary skills or information for evaluating the need for PSP is the same group that has theoretically reached consensus to proceed with moving draft-ietf-spring-srv6-network-programming forward on the standardization process. > > The concern that this document violates RFC8200 was dismissed [WGLC-O], noting that an associated erratum (#5933) on RFC8200 [ERRATA] "has not been accepted by the responsible AD". However, at the time WG consensus was declared (February 28, 2020), the erratum had not yet been processed by the responsible AD (the associated erratum was processed on March 2, 2020). > > The concerns about whether the SID format is deployable was also discussed off-list with the responsible AD [SID-S]. At first, the AD seemed to be under the impression that enterprises (that often only have a /48 available) do not use technologies such as EVPN, L3VPN and network programming. This misjudgement of the AD has been made clear based on real life examples. However, further requests for better examples for the WG to be able to determine if this technology is deployable have been ignored. > > The rest of the concerns were dismissed without further comments (please see e.g. [SID-O]). > > > In addition to the aforementioned technical issues, a number of procedural concerns have been raised as a result of the WGLC of this document, including: > > 1) Concerns [COI] about the conflict of interest represented by the WGLC > being handled by a Contributor (Bruno Decrane) of > draft-ietf-spring-srv6-network-programming. > > In this respect, Bruno Decraene started the WGLC of this document > [WGLC], and eventually declared the outcome of the WGLC (noting that > he had handled the WGLC process [WGLC-O] because his co-chair was > unavailable), and that the responsible AD (Martin Vigoureux) would > make the formal decision to send the document to the next level. > Later on, the responsible AD (Martin Vigoureux) sent a more terse > notification to the Spring mailing-list [WGLC-O2] declaring WG > consensus to progress the document, while noting that he had > performed the evaluation of the WGLC process himself. > > 2) There was not enough time for the working group to review the draft > version on which consensus was declared. [REVIEW] > > WG consensus [WGLC-O2] was declared for a second time (this time by > Martin Vigoureux, on March 2, 2020, at 18:53 UTC), on version > draft-ietf-spring-srv6-network-programming-11 of the document, > which had been announced on the Spring mailing-list [DRAFT-A] on > March 2, 2020, at 16:47 UTC. > > 3) The shepherd writeup for this document [WRITEUP] seems to be omitting > information and misrepresenting the process that took place in the > working group. At the time consensus was declared on the document > [WGLC-O] [WGLC-O2], all of the concerns listed above remained > unaddressed (e.g., please see [PSP-U] and [IPv6-U]). It took over one > month for the status of the document to be reflected on the > Datatracker. During this period of time, multiple requests were > publicly made about the status of the document [STATUS-1][STATUS-2] > [STATUS-3]. On March 11, 2020, the document shepherd claimed to be > preparing the shepherd's writeup [WRITEUP-2]. Since then, multiple > revisions of the document were published (-11 through -15), > apparently to address some of the concerns that seemed to have been > dismissed during the WGLC and when consensus to move the document > forward was declared. The resulting changes were not publicly > discussed on the mailing-list. When the status of the document was > finally updated in the Datatracker, the responsible AD noted > [WGLC-POST] that revisions published since WG consensus had been > declared addressed objections that had been raised during the WGLC of > the document. However, it is unclear if the version of the document > that has been shipped from the WG has successfully addressed them -- > particularly when some of the aforementioned concerns had been raised > by multiple participants, and the corresponding document updates have > never been subject to discussion on the working group mailing-list. > > While these issues might have simply been the result of mistakes while handling the WGLC of this document, they have been unfortunate in terms of transparency of the process and credibility of the outcome of such process (see e.g. [PROC] and [REVIEW]). > > > * Requested Action > > We request that the document be returned to the SPRING Working Group, such that the aforementioned technical concerns are addressed (and the WG has the chance to confirm they have been addressed), and that, subsequently, a second Working Group Last Call (WGLC) be initiated on the document. Additionally, we request that measures be taken such that possible conflicts of interest are avoided when evaluating this second WGLC. > > > * References > > [COI] https://mailarchive.ietf.org/arch/msg/spring/VK75j1TlsEA1zFcQ_IjC0_g86Og/ > > [DRAFT-A] https://mailarchive.ietf.org/arch/msg/spring/5W_t--Ns12g9zNhItaVe-sglwwY/ > > [ERRATA] https://www.rfc-editor.org/errata/eid5933 > > [IPV6-U] https://mailarchive.ietf.org/arch/msg/spring/zJvAkj4joRypuJ6ibBJFFoxXDD4/ > > [IPV6-V] https://mailarchive.ietf.org/arch/msg/spring/XZ_D_cfPNNzXpi4_ZbuTidMTo4k/ > > [IPV6-V2] https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv1I/ > > [PROC] https://mailarchive.ietf.org/arch/msg/spring/fXdr3-uAFSYGZN2vOGSwC7IJ8Ow/ > > [PSP-R] https://mailarchive.ietf.org/arch/msg/spring/eSP4xVYVgjtCmAMGMkqHedv80jU/ > > [PSP-U] https://mailarchive.ietf.org/arch/msg/spring/EuJwUeIyyXonE0aGHCqwT2fd5G8/ > > [REVIEW] https://mailarchive.ietf.org/arch/msg/spring/1kPMfQIRhf7EoOqA_3jtmo6dbt4/ > > [SID] https://mailarchive.ietf.org/arch/msg/spring/2ApHpreqPTS689pAEyhiZEdTf7k/ > > [SID-O] https://mailarchive.ietf.org/arch/msg/spring/BhIpH8b_Z-08NSq7wre36qAtqPY/ > > [SID-S] Steffann, Sander, private communication. Please contact Sander Steffan at <sander@xxxxxxxxxxx> for further details. > > [SIZE-L] https://mailarchive.ietf.org/arch/msg/spring/_SYsvWXQo9t4o2KbJuEiVS-75B4/ > > [SIZE-V] Colitti, L. Spring wg meeting, IETF 105. https://youtu.be/WuoJWecyATQ?t=1241 > > [SR-V] https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv1I/ > > [STATUS-1] https://mailarchive.ietf.org/arch/msg/spring/odkMyhc1LUd-h6uHp9yNlDgnCTg/ > > [STATUS-2] https://mailarchive.ietf.org/arch/msg/spring/klH4StuD4E8DhVVrgGEBIFUf0sE/ > > [STATUS-3] https://mailarchive.ietf.org/arch/msg/spring/tLL_XuqUNPHzHuzhwL4-AUtVTEQ/ > > [WGLC] https://mailarchive.ietf.org/arch/msg/spring/tFJ742P88QYh9Ns8N97gC8BPWA4/ > > [WGLC-O] https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/ > > [WGLC-O2] https://mailarchive.ietf.org/arch/msg/spring/VxWwLVXBD0gRbUb4nD_NY6lE-MI/ > > [WGLC-POST] https://mailarchive.ietf.org/arch/msg/spring/egaddcV_LVAnJwHFEy98crx9LFg/ > > [WRITEUP] https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/shepherdwriteup/ > > [WRITEUP-2] https://mailarchive.ietf.org/arch/msg/spring/tSWyFOVaKDz2OyLzzckjWhvxE5U/ > > > Yours faithfully, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@xxxxxxxxxxxxxxx > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > >
