[lacnog] Fwd: Appeal to the IESG re WGLC of draft-ietf-spring-srv6-network-programming
alejandroacostaalamo en gmail.com
Jue Mayo 7 16:04:04 GMT+3 2020
Te comento que yo seguí la novela justo hasta que enviaste este correo.
¿Que ha pasado con este tema?.
P.S Favor no referir nada de Diego M :-)
On 4/22/20 10:44 PM, Fernando Gont wrote:
> 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.
> -------- Forwarded Message --------
> Subject: Appeal to the IESG re WGLC of
> 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>
> 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
> (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
> 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
> [ERRATA] https://www.rfc-editor.org/errata/eid5933
> [SID-S] Steffann, Sander, private communication. Please contact Sander
> Steffan at <sander en steffann.nl> for further details.
> [SIZE-V] Colitti, L. Spring wg meeting, IETF 105.
> Yours faithfully,
Más información sobre la lista de distribución LACNOG