Fernando, all, Acknowledging that the IESG has received this.
Regards, Alissa Cooper IETF Chair > On Apr 22, 2020, at 10:26 PM, Fernando Gont <fg...@si6networks.com> 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 <fg...@si6networks.com> > Andrew Alston <andrew.als...@liquidtelecom.com> > Sander Steffann <san...@steffann.nl> > > > * 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 <san...@steffann.nl> 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: fg...@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
