Appeal to the IESG re WGLC of draft-ietf-spring-srv6-network-programming (Fernando Gont, Andrew Alston, and Sander Steffann, 2020-04-22) - 2020-04-22
Response - 2020-06-03
From: IETF Chair <chair@ietf.org>
Subject: Re: Appeal to the IESG re WGLC of draft-ietf-spring-srv6-
network-programming
Date: June 2, 2020 at 8:44:29 PM EDT
To: Fernando Gont <fgont@si6networks.com>, Andrew Alston
<Andrew.Alston@liquidtelecom.com>, Sander Steffann
<sander@steffann.nl>
Cc: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org"
<6man@ietf.org>, IESG <iesg@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
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 interpr
etations 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_g86
Og/
[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/UBvebWMkDTj7QDBkkGOflrT1t
4o/
[RFC 2418]
https://tools.ietf.org/html/rfc2418
[RFC 4858]
https://tools.ietf.org/html/rfc4858
[SID]
https://mailarchive.ietf.org/arch/msg/spring/2ApHpreqPTS689pAEyhiZEdTf
7k/
[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/