[lacnog] Fwd: Appeal to the IESG re WGLC of draft-ietf-spring-srv6-network-programming

Alejandro Acosta alejandroacostaalamo en gmail.com
Jue Mayo 7 16:04:04 GMT+3 2020 

Hola Fernando,

   Te comento que yo seguí la novela justo hasta que enviaste este correo.

   ¿Que ha pasado con este tema?.


Alejandro,

P.S Favor no referir nada de Diego M  :-)


On 4/22/20 10:44 PM, Fernando Gont wrote:
> Estimados,
>
> Esta es la primera vez que hago, junto a otros colegas, una apelación 
> ante la IESG.
>
> La apelación está bien detallada, y llena de referencias. Cada uno 
> saque sus propias conclusiones en materia de transparencia y 
> credibilidad del proceso.
>
> Saludos,
> Fernando
>
>
>
>
> -------- Forwarded Message --------
> Subject: Appeal to the IESG re WGLC of 
> draft-ietf-spring-srv6-network-programming
> Date: Wed, 22 Apr 2020 23:26:58 -0300
> From: Fernando Gont <fgont en si6networks.com>
> To: The IESG <iesg en ietf.org>
> CC: Andrew Alston <Andrew.Alston en liquidtelecom.com>, Sander Steffann 
> <sander en steffann.nl>, spring en ietf.org <spring en ietf.org>, 6man en ietf.org 
> <6man en ietf.org>, 'ietf en ietf.org' <ietf en ietf.org>
>
> 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 en si6networks.com>
> Andrew Alston <Andrew.Alston en liquidtelecom.com>
> Sander Steffann <sander en 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 <sander en 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,

Más información sobre la lista de distribución LACNOG