Dear Fernando, Andrew, and Sander: The IESG has reviewed your appeal to the declaration of WG consensus to progress draft-ietf-spring-srv6-network-programming. Based on our review of the technical and process-related points presented, we do not believe there is a basis for returning the document to the SPRING WG for a second working group last call. In drawing this conclusion we reviewed the discussions about this document and related technical issues that have taken place in the SPRING WG and in the 6MAN WG. While we do not believe the document needs to be returned to the SPRING WG, there are some actions that we consider necessary to address some of the concerns you have raised. These actions are detailed later on. Martin Vigoureux was not involved in processing this appeal. As detailed in RFC 2418 (IETF Working Group Guidelines and Procedures) [RFC 2418], working groups have a good amount of flexibility, including operational aspects related to how last calls are handled, up to and including whether a working group last call is needed or not. It is common for documents that change as a result of reviews at different stages of the process to continue on the publication path without further rigorous discussion and approval by the whole WG. This point is especially true when the changes are in line with previously identified WG consensus. Furthermore, the ability for a working group to reach consensus is not dependent on an absolute level of knowledge about relevant implementations or deployment details. Working groups come to conclusions based on the knowledge available in the group. The full IETF document publication process, including IETF Last Call and IESG Evaluation, aims to provide thorough review across all aspects of a protocol, its usage, and deployment. In relation to procedural concern 1, our understanding of the process that occurred is that Martin Vigoureux, as Responsible AD, evaluated the WG last call consensus on this document because one co-chair was unavailable and the other co-chair is listed in the document as a contributor. Ideally every working group would be chaired by multiple chairs who are not also involved with active documents in the working group, or other documents related to them, but given the IETF’s voluntary participation this is not always feasible. The particularly contentious debates in the SPRING WG have made it extremely difficult to identify participants to fill chair and shepherd roles who are free of potential perceived conflicts and willing to manage the consensus process. Having the Responsible AD make the consensus call in the WG does not violate the IETF process and was a reasonable choice under the circumstances. Having said that, a named contributor handling the WG process can be perceived as a potential conflict of interest. As was discussed in the mailing list following the original query [COI], the contentious nature of this document has made the situation much more apparent. In relation to procedural concern 2, related to the WG not having enough time to review the changes included in draft-ietf-spring-srv6-network-programming-11, it is unfortunate that this version was published just hours before the consensus call [WGLC-O2]. Upon examination of the changes [diff-10-11], it is clear that the additional text is in line with the expressed rough consensus, and that it tries to address some of the technical issues pointed out in your appeal (more details below). The further changes up to the current version [diff-11-15] also address the same topic. There are no changes that impact the consensus of the WG related to the normative behavior that the document specifies. In relation to procedural concern 3, about the contents of the Shepherd's Writeup, we first want to reinforce that the objective of such writeup [RFC 4858] is to inform the Responsible Area Director, and the rest of the IESG, of any issues that they should be aware of prior to IESG Evaluation. As such, the Writeup can change over time. We note that the current version [WRITEUP] talks about the rough nature of the discussion and does cover most of the technical points presented in this appeal. In relation to technical point 1, the justification for the need of PSP, we have observed several attempts at explanation in the WG discussions. To pick just one example, the “SRv6 PSP use case” thread [PSP-USE-CASE] begins a discussion with an explanation of IP-tunnel capable nodes on the edge of an SR domain. The 3rd paragraph of Section 4.16.1 in the latest version of the document captures some of when PSP might be used. In relation to technical points 2 and 3, the claim that the PSP behavior (in Section 4.16.1 of the document) violates RFC 8200 is clearly the most significant issue presented. The charter of the SPRING WG states it should avoid modification to existing data planes. A strict literal reading of the text in RFC 8200 does not forbid the kind of extension header manipulation described in Section 4.16.1, and the latest version includes a statement to this effect. To be specific, the text from RFC 8200 that the draft relies upon is the explicit differentiation between a Destination Address and the “ultimate recipient” described in Section 3, and the use in Section 4 of the phrase “identified in the Destination Address field of the IPv6 header“. This text in RFC 8200 has been discussed in the 6man WG multiple times, including at the most recent 6man interim [6MAN-MINUTES]. The draft-ietf-6man-rfc2460bis consensus process resulted in the text in RFC 8200; contentious as interpretations of this text may yet be, the draft in question is not inconsistent with a strict literal reading, as noted by Suresh Krishnan (INT AD at the time) in the 3 mail archive links Martin Vigoureux included in his call of WG consensus [WGLC-02]. Martin Vigoureux evaluated the working group’s consensus on whether to use this reading [WGLC-8200], and no change to RFC 8200 was under discussion. Any change to RFC 8200 would require a consensus document from the 6man WG. In relation to technical point 4, a more prescriptive SID format, the request [SID] was replied to on a different thread [SID-R]. However, some points remain unaddressed by the document and therefore need some discussion and clarification including the nature and extent of any restrictions on IPv6 addresses that may be SIDs under the format described in Section 3.1 (the LOC, FUNCT, and ARG portions of the IPv6 address). Somewhat surprising to the casual reader, the SRv6 Endpoint Behaviors registry set up in section 9.2 states that these values are not necessarily related to the FUNCT portion of the address. An editorial clarification, including one or more illustrative examples, is required. In relation to technical point 5, the deployability of SIDs as related to their address size, the document does not list any requirement nor make general recommendation for the LOC prefix sizes that may be used by operators. There is no example showing the use of a /40 LOC prefix. One example provided in Section 3.2 shows two 128-bit SIDs, with up to 63 LOC prefix bits in common, and discusses routing in the network based on /64s. Some discussion or, at a minimum, illustrative examples are needed. While we do not believe the document needs to be returned to the SPRING WG, there are some actions that we consider necessary to address some of the concerns you have raised. Once a document leaves a WG it becomes the AD's responsibility. To manage the actions detailed below and guide the document through the rest of the process, in line with RFC 4858 [RFC 4858], we are asking Martin Vigoureux, as Responsible AD, to assign a new Document Shepherd. Specifically, related to technical points 4 and 5 of your appeal, the Shepherd is asked to work with the authors to add clarifying text related to the SID format and corresponding deployment recommendations, including examples and any requirements related to the address-space needed. These topics were raised on the WG’s mailing list, but some of the answers and discussions are not reflected in the document. These clarifications will be helpful as the document progresses. In relation to technical point 1, the 3rd paragraph of Section 4.16.1 in the latest version of the document provides some description of when PSP might be used. The appointed Shepherd is asked to work with the authors to provide additional justification, guidelines for its use, and/or further clarify the existing text. This topic was discussed on the WG’s mailing list, but it is not reflected in the document. The document Shepherd is asked to confirm that SID format and deployment concerns have been adequately addressed. While the deployment aspects may be explored in depth in separate documents a high level summary or cursory example might suffice for this document. The IESG expects the actions mentioned above for the Shepherd, including guiding any relevant discussions, to be carried out before the IETF Last Call of this document starts. All of these actions are intended to clarify the contents of the document, in line with the existing WG consensus. This note represents the consensus of the IESG related to the appeal presented, and not a thorough review of the document in question, nor an implicit endorsement. As the document moves forward, the community and the IESG are expected to provide their usual level of review. Thank you! The IESG [[ References ]] [6MAN-MINUTES] https://datatracker.ietf.org/doc/minutes-interim-2020-6man-02-202005051500/ [COI] https://mailarchive.ietf.org/arch/msg/spring/VK75j1TlsEA1zFcQ_IjC0_g86Og/ [diff-10-11] https://www.ietf.org/rfcdiff?url1=draft-ietf-spring-srv6-network-programming-10&url2=draft-ietf-spring-srv6-network-programming-11 [diff-11-15] https://www.ietf.org/rfcdiff?url1=draft-ietf-spring-srv6-network-programming-11&url2=draft-ietf-spring-srv6-network-programming-15 [PSP-USE-CASE] https://mailarchive.ietf.org/arch/msg/spring/UBvebWMkDTj7QDBkkGOflrT1t4o/ [RFC 2418] https://tools.ietf.org/html/rfc2418 [RFC 4858] https://tools.ietf.org/html/rfc4858 [SID] https://mailarchive.ietf.org/arch/msg/spring/2ApHpreqPTS689pAEyhiZEdTf7k/ [SID-R] https://mailarchive.ietf.org/arch/msg/spring/ Dhtemt1hHArvlMy_ibGE4am05dw/ [WGLC-O2] https://mailarchive.ietf.org/arch/msg/spring/VxWwLVXBD0gRbUb4nD_NY6lE-MI/ [WGLC-8200] https://mailarchive.ietf.org/arch/msg/spring/CmT-8nSZs8O8i9N9dD8gHd6uHAo/ [WRITEUP] https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/shepherdwriteup/ > 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 > > > >
