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@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
