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

[Fernando Gont]

Finalmente llegó la respuesta de IESG :-)

Explicando lo inexplicable....


-------- Forwarded Message --------
Subject: Re: Appeal to the IESG re WGLC of 
draft-ietf-spring-srv6-network-programming
Date: Wed, 3 Jun 2020 02:16:10 -0300
From: Fernando Gont <fgont at si6networks.com>
To: IETF Chair <chair at ietf.org>, Andrew Alston 
<Andrew.Alston at liquidtelecom.com>, Sander Steffann <sander at steffann.nl>
CC: spring at ietf.org <spring at ietf.org>, 6man at ietf.org <6man at ietf.org>, 
IESG <iesg at ietf.org>, ietf at ietf.org <ietf at ietf.org>

Dear IESG,

Please find my responses in-line....

On 2/6/20 21:44, IETF Chair wrote:
> 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. 

To be quite honest, if the process with which this document has passed 
WGLC does not warrant that the document be returned to the WG, I must 
admit I have no idea whatsoever the conditions under which a document 
would be returned to a working group.

Specifically, the issues raised during WGLC were dismissed, WGLC 
consensus was declared, and WG participants were contacted off-list in 
the hopes of making them happy with the document. That, together with 
the Shepherd's write-up omitting virtually all such issues make for a 
perfect example of lack of transparency in the process.



> 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.

The consensus declared on Spring WG literally dismissed  the technical 
concerns raised on the appeal. So I'm not sure how you could possibly 
argue that the changes applied to the document are the result of WG 
consensus, when in fact it is evident that the raised issues were 
dismissed while judging 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.

I'm curious of how precious IETF cycles are spent when a WG decides to 
ship a document specifying a behavior (PSP) for which the authors 
rejected to provide a rationale.

Ironically, PSP seems to aim at nodes that are not able to ignore 
packets that contain a RH with a SegmentsLeft == 0, when RFC8200 itself 
requires that nodes be able to do so.



> 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.

Did they ever try? I haven't seen a single email on the spring, 6man, or 
ietf@ lists asking for volunteers. -- other groups do so when in the 
need for such volunteers.



> 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.

As noted in the Appeal, one of Spring WG co-chairs was the first to 
declare WG consensus to progress the document. Then consensus was later 
declared (again) by the AD.

The process doesn't seem to have enjoyed the most minimum sign of 
transparency.



> 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).

Is the established process that first comments are dismissed, then 
consensus is declared, and when it's clear that an Appeal is coming, the 
AD contacts folks that raised objections to try to make them happy with 
the I-D?

This seems to be backwards, to be honest.



> 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.

The [WRITEUP] literally omits most of the major objections raised 
against this document.

Once again, that doesn't talk very well about the transparency of the 
process.




> 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. 

A use-case is not a justification regarding why the behavior is needed 
in the first place.



> The 3rd paragraph of
> Section 4.16.1 in the latest version of the document captures some of
> when PSP might be used.

Ironically, the request for such clarification was dismissed by the 
co-chair when declaring WG Consensus. Yet, the text you mentioned was 
added, which does *not* justify the need for PSP, since nodes are 
required by RFC8200 to ignore RHs with a SegmentsLeft == 0.




> 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]. 

Do you think it talks about transparency of the process to dismiss this 
objection *before* the relevant erratum was formally processed by the 
INT AD?




> 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).

Not just that. It would seem to me this document violates the IPv6 
addressing architecture itself (RFC4291).



[....]
> 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.

I'm curious how a WG can ship a document without this basic analysis 
that is crucial for the deployability of this specification.




> 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. 

A description of when something could be used is not a justification for 
specifying the behavior.

Apparently, the motivation for PSP is to accommodate nodes that 
deliberately violate RFC8200 by being unable to skip RHs with 
SegmentsLeft == 0.


Note: I fail to see your analysis regarding technical objection #3: Your 
analysis focuses on RFC8200 (the focus of technical objection #2), but 
doesn't even mention RFC8754 (the relevant RFC for technical objection #3).

For the sake of transparency, while I haven't talked to my fellow 
Appellants about your response, I for one plan to Appeal to the IAB to 
resolve this issue. That said, I'd appreciate your response to the 
comments made above.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492