Re: [mpls] Closed: MPLS Working Group Last Call on draft-ietf-mpls-mna-requirements

Loa Andersson <loa@pi.nu> Thu, 19 October 2023 09:21 UTC

Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A049C1522DB for <mpls@ietfa.amsl.com>; Thu, 19 Oct 2023 02:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHBkk2THBxxT for <mpls@ietfa.amsl.com>; Thu, 19 Oct 2023 02:21:19 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7C4C1522CB for <mpls@ietf.org>; Thu, 19 Oct 2023 02:21:17 -0700 (PDT)
Received: from [192.168.1.241] (c-adee71d5.1063529-0-69706f6e6c79.bbcust.telenor.se [213.113.238.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4BEFC35D1C0; Thu, 19 Oct 2023 11:21:15 +0200 (CEST)
Message-ID: <f8758d1f-5789-48d0-866d-73cfe3be93bb@pi.nu>
Date: Thu, 19 Oct 2023 11:20:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-CA
To: Joel Halpern <jmh@joelhalpern.com>, mpls@ietf.org
References: <2ded21ed-f70c-4361-a6a9-36df027194fd@pi.nu> <5bc17d3b-48ce-44c8-aa8a-d52e761b00b7@pi.nu> <027701da00e7$20622800$61267800$@olddog.co.uk> <d8fa818f-8d19-4999-8ea4-0cbab8e11cfa@pi.nu> <98cf7f72-417b-eccf-347f-0f7cf01ce530@joelhalpern.com>
From: Loa Andersson <loa@pi.nu>
In-Reply-To: <98cf7f72-417b-eccf-347f-0f7cf01ce530@joelhalpern.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/HRHUxQQ-zorSMUsfZoF4Yu_ktOo>
Subject: Re: [mpls] Closed: MPLS Working Group Last Call on draft-ietf-mpls-mna-requirements
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Oct 2023 09:21:23 -0000

Joel,

You are right, I'm listed as an author for e.g. 
"draft-song-mpls-extension-header", whether there is a conflict of 
interest when it comes to shepherding the 
draft-ietf-mpls-mna-requirements I'm not entirely clear over.

I have asked chairs to discuss this in their meeting 2023-10-24.

/Loa

On 2023-10-17 19:44, Joel Halpern wrote:
> There seems to be a statement in this email that Loa, as chair, is 
> asserting that we have a rough consensus on the need for a PSD 
> solution.   As far as I know, that has not been asked, nor judged.  As 
> far as I know, we were discussing whether there are use cases that 
> demonstrate a sufficient need for PSD.
> 
> I also note that ass Loa is a co-author on a PSD proposal, I woul dhope 
> to see any chair ruling on such a matter from the other two MPLS chairs.
> 
> Yours,
> 
> Joel M. Halpern
> 
> On 10/17/2023 1:29 PM, Loa Andersson wrote:
>> Adrian,
>>
>> Inline plz.
>>
>> On 2023-10-17 12:46, Adrian Farrel wrote:
>>> Hi Loa, all,
>>>
>>>> This working group last call is now closed.
>>>>
>>>> The MPLS working group chairs believe that WGLC reflects a consensus
>>>> to progress the document
>>>
>>> To be clear, you are declaring me in the rough when I said "A few 
>>> comments
>>> below that indicate, I think, that this work is not yet stable."
>>> I appreciate that the authors will, as part of the WGLC resolution 
>>> process,
>>> attempt to address and respond to my comments, but claiming the current
>>> situation as consensus to progress would be a bit like me saying 
>>> "Every word
>>> in this document should be different" and you saying "We have 
>>> consensus to
>>> publish this document once every word has been changed."
>>
>> I don't quite understand what you are saying, I said "progress the 
>> document", but the intent was not to send it to the IESG for 
>> publication, rather the intent to direct the work with reviewers, the 
>> rest of the working group to post a new version of the document that 
>> we can working group last call in a not to distant future.
>>>
>>> When comments and questions are minor, the reviewer may say "I agree to
>>> publication once my issues have been addressed." When comments are 
>>> many or
>>> major, the reviewer may say "I don't think this work is stable" and, 
>>> in that
>>> case, I think that the normal process is to discuss and revise, at 
>>> the end
>>> of which the reviewer may say, "I'm OK now" (and the chairs can call
>>> consensus) or a further WGLC will be required. You did indicate, in your
>>> email, that you might trigger a second WGLC, in which case I think you
>>> probably agree that you don't have consensus yet.
>>
>> This tricky, and I might misuse the terminology, I used the rough 
>> consensus to indicate two things
>>
>> - we have a consensus to continue working on the document
>> - we have a consensus to include PSD in the requirments
>>>
>>> I also think that no one addressed my comment
>>>      I'm not sure that it is really
>>>      necessary to publish this work as an RFC, and I think we should be
>>>      careful to make the requirements rigid while we are still 
>>> working on
>>>      use cases and solutions. That doesn't mean we shouldn't try to 
>>> reach
>>>      agreement, but that we should be flexible to allow the creation 
>>> of new
>>>      requirements or the clarification of what we have documented.
>>>      Publication of an RFC at this stage might be too set in stone.
>>
>> I think there was at least one comment saying that they thought an MNA 
>> requirement is important, and over the years I have had ADs that time 
>> and again said "show me the requirements". But if the resolution of 
>> this comment is that we don't want the IESG to publish this document 
>> so be it, it is still important when we discuss which solutions we 
>> will develop.
>>>
>>> But perhaps you consider that in the rough, too. With respect to 
>>> this, you
>>> did say in another email "As for the rest of your mail I will bring 
>>> it to
>>> the MNA chairs meeting 2023-10-03 for discussion." But I don't 
>>> believe I saw
>>> any follow-up to this.
>>
>> That discussion was overtaken by other things arising from this 
>> sometimes frustrating discussion.
>>
>> /Loa
>>>
>>> Best,
>>> Adrian
>>>
>>>
>>>
>>

-- 
Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64