Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Ted Lemon <> Thu, 27 February 2020 13:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AB943A07A1 for <>; Thu, 27 Feb 2020 05:04:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8-3bjYWTHDKk for <>; Thu, 27 Feb 2020 05:04:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B8003A07D2 for <>; Thu, 27 Feb 2020 05:04:26 -0800 (PST)
Received: by with SMTP id f140so2940146qke.11 for <>; Thu, 27 Feb 2020 05:04:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wKzOcEQKuHHq/z9bWg8gcGbVJyy6Z17tmWcYXOohMqY=; b=0NDzAYP0B3TZPszP8YjdG8Dacudsinbv+DJynv0/a0kIuDSRgqG5XX9j7wngYRHEX4 2FP+zrjccUOm2SDa67gOi+vONW7wrtJ0wablt3inNzHdEbkxuGddGWVsEj3tfYQxWS2X d5eaMFb5EaLASRi+pq6ZQULo9Ly0H6evfkg4v4uT1+GZnV3aI4P9paaUXdOauyYk5aM1 DDAXJF8qs03x9E9GPXu5kKFUnoAeweaB/161BXvEqf4JoEgw4fiZdhU47vBHuwTwxWuQ lI2ELjv2CAryLnvFHml94WKRbuQhIREldAQJIOoEHlr0msQSMHYzlZFmd3rKBmfSB2Lm J1Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wKzOcEQKuHHq/z9bWg8gcGbVJyy6Z17tmWcYXOohMqY=; b=O0ySbw3Yu0q72xXXGrjf+lDAxnxpzcdDmH3x/f9Joyp0m76MDylh8/S1c6/PSH9dTc S5l9Yv37eEgUqnFyQr112NZK4saMFs6OZKWhIMSs2eQaAYF4u8sJQRApRgYXyRywbusg +An/aZG2+YdhcZFcBJlTFOI/gLTs2q7bLSHlZEWV2+YcUxX13VXn2Hwb+qydGuEBdCPi XsC8xoWyhGef1ue6WQe9zQR+whXIOgN5CCtMa3zhDq3Th1B4Md0SXsPXsXUU9PqBzvUZ yQ2dpq4rRn5CTq/kD6gCIfPvLiA1un2EtzFoLlkrgLkHm+05LpiWPeekOA+ZULbKqbSi 9r4Q==
X-Gm-Message-State: APjAAAVck3/OpP6bFSROVXWOCFpFqCJJYlGARyWXjc9fNNj3AWmYV+KB W+GvbH4O4eMtuimQ7wxHuTCyjg==
X-Google-Smtp-Source: APXvYqz4RFMUasUN7lxvcqIp8fEwvd2iclL7TxPCtxgv+k5jXgJI0OnOJhjXUkobPMYBQQRN+iJxnw==
X-Received: by 2002:a05:620a:74c:: with SMTP id i12mr5622755qki.286.1582808665272; Thu, 27 Feb 2020 05:04:25 -0800 (PST)
Received: from ?IPv6:2601:18b:300:36ee:b8ed:c35:a977:7427? ([2601:18b:300:36ee:b8ed:c35:a977:7427]) by with ESMTPSA id 11sm2976096qko.76.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 05:04:24 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
From: Ted Lemon <>
In-Reply-To: <>
Date: Thu, 27 Feb 2020 08:04:22 -0500
Cc: "Maojianwei (Mao)" <>, SPRING WG List <>, "" <>, draft-ietf-spring-srv6-network-programming <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Fernando Gont <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Feb 2020 13:04:33 -0000

This is really not helpful, Fernando, and goes some way toward explaining why communication isn’t happening.

What I reacted to in Brian’s message is that he asked a really simple question that could be readily answered with a pointer to the text in the document where the answer is given.  Since the response was instead to explain in email, that tells me that the spec is incomplete.

Separately, Brian mentioned that there is an issue with RFC8200 that would require an update, that discussions had occurred around this, but then the work never happened.   It’s reasonable to raise an objection to proceeding with work that depends on other work that hasn’t been done.

What I objected to in Maojianwei’s comment is the notion that the document should pass last call to support the industry.  No, the working group should do the work to address the objections that have been raised.   If you find yourself explaining some concept that’s mentioned in the document using text that is not in the document and not in another document referenced by the document, the fix is not to just publish anyway, because it supports the industry.   The fix is to update the document.   A dozen or so +1s should not be taken seriously if the work has not been done and nobody wants to do it.

> On Feb 27, 2020, at 6:11 AM, Fernando Gont <> wrote:
> On 27/2/20 07:27, Ted Lemon wrote:
>> The IETF serves users, not “industry”.  The IETF does not promote. Our job is to make the internet work interoperably. Brian has raised an objection that could be answered, but has not been. It is inappropriate to say that this document has passed last call.
>> In my experience, when it is hard to get consensus in situations like this it is because there is a wish to not address a concern that has been raised, not because the concern could not be addressed or should not have been raised. It may feel unreasonable, and like an imposition, but it is not. It is part of the process.
>> Rather than trying to steamroll over the objection, why not simply answer it?
> As a service to the community, let me explain:
> Essentially, and for some reason, they seem to be meaning to circumvent specs and processes.
> One of their last inventions has been to pretend that IPv6 allows EH insertion/deletion en-route, based on their reading of RFC8200. Based on a curious interpretation of the text, they claim that each waypoint (intermmediate router that received the packet because its address was set as de Destination Address) can insert/remove EHs, and they claim that that's not a violation of RFC8200.
> However, the PSP behavour doesn't even fit in that fictional interpretation of RFC8200.
> What PSP does is that, given:
> ---- B ----- C
> routers, when B realizes, after processing the SRH and setting the Dest Addr to the last segment, SegmentsLeft==0, it removes the SRH.
> This case is not even covered by their fictional interpretation of RFC8200.
> Hence the question is avoided, u<because thye would have no option than admiting they are violating RFC8200..unless... who knows... there might be yet another curious interpretation of the spec that allows it.
> It should eb evident here that the strategy is not really to follow IETF process, gain consensus, formally update specs if/where needed, but rather push whatever they publish, at whatever cost, ignoring the issues raised in this wg, and circumventing IETF process.
> The fact that this behavior is allowed seems to be unfair with participants, and a dis-service to the group.
> Thanks,
> -- 
> Fernando Gont
> e-mail: ||
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1