Re: [Teas] Fwd: IETF WG state changed for draft-ietf-teas-yang-te-topo

Lou Berger <lberger@labn.net> Sun, 10 March 2019 22:07 UTC

Return-Path: <lberger@labn.net>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C18127598 for <teas@ietfa.amsl.com>; Sun, 10 Mar 2019 15:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3fAL9viAeQU for <teas@ietfa.amsl.com>; Sun, 10 Mar 2019 15:07:46 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7672A12782C for <teas@ietf.org>; Sun, 10 Mar 2019 15:07:44 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id CCA3E215C5B for <teas@ietf.org>; Sun, 10 Mar 2019 16:07:42 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 36behtyDkD8Rp36behGbjm; Sun, 10 Mar 2019 16:07:42 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: $(_cmae_reason
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=e3x/lSuDJb7U5gQRMhn9YymRWe63nVJxAW+wkuMO6Pw=; b=lwGrg7yqsCMu1NfI5aAsCb5qCh O128cuV2ZMudGQQnBRbvbzH2l3wh9CrhMYasuQhTGzt+uFaW7uaRf8knwIS3kSWSiOJIpOvX2p78P bSZGTh1xuiwUqymzn2Rc8CwlR;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:42390 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1h36be-002trf-9S; Sun, 10 Mar 2019 16:07:42 -0600
To: Igor Bryskin <Igor.Bryskin@huawei.com>, "xufeng.liu.ietf@gmail.com" <xufeng.liu.ietf@gmail.com>
Cc: "teas@ietf.org" <teas@ietf.org>, "draft-ietf-teas-yang-te-topo@ietf.org" <draft-ietf-teas-yang-te-topo@ietf.org>, "BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>
References: <155189817187.307.659471814489604970.idtracker@ietfa.amsl.com> <6800dd59-ee76-9985-ec6c-060d9ee9d498@labn.net> <CAEz6PPSHsPz0G80nANavYoM-Z6E_ar2nB+P0yoGeAVRBgBVDOw@mail.gmail.com> <a4919a8c-daf0-0056-938d-37f91e8b0932@labn.net> <0C72C38E7EBC34499E8A9E7DD00786391C6B1B1C@sjceml521-mbx.china.huawei.com> <ba01d39b-1213-7462-2c80-8749a6fd340a@labn.net> <etPan.5c857298.71b896f2.28d2@localhost>
From: Lou Berger <lberger@labn.net>
Message-ID: <ced37bb2-6048-b8b8-595e-9ff637f2a5b7@labn.net>
Date: Sun, 10 Mar 2019 18:07:40 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <etPan.5c857298.71b896f2.28d2@localhost>
Content-Type: multipart/alternative; boundary="------------FA7034FF9421245EEB2CBC1E"
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1h36be-002trf-9S
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:42390
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/VGf2oTzRqyXokgrKJ561USYJ8eg>
Subject: Re: [Teas] Fwd: IETF WG state changed for draft-ietf-teas-yang-te-topo
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Mar 2019 22:07:50 -0000

Igor,

On 3/10/2019 4:22 PM, Igor Bryskin wrote:
> Hi Xufeng,
>
> I believe every time we published an update for the document we 
> provided a summary of the changes since the previous revision.
> Could you find the one for the latest update?
>
> Lou,
> Since the document was put into the RFC  Editor queue we have made far 
> more serious change - we replaced the dependency on te-tunnel model  
> with the dependency on te-types model. You knew about our intention 
> long time ago, as well as that the document would need in this case 
> another close look by WG. You have not warned us about the problem, 
> nor pulled the document out of the queue then.

Correct. This has been widely discussed, at the last IETF and on list.

> Now you are focused on the most trivial change (almost as harmful as 
> changing Tarek's association from CSCO to Jniper), which could be 
> easily reviewed by the WG along with consequences of the depency 
> change. Why is that?

The change in dependency was basically and editorial change, it was to 
reflect where the module was being defined.  An affiliation change is 
also not considered to be a substantive technical change by the IETF, 
remember we contribute to the IETF as individuals, so such affiliation 
changes are non problematic.  Most importantly,  the RFC editor was 
consulted *prior* to agreeing to this change, to ensure that it was an 
acceptable change while in the editor queue and that the reference 
change didn't require that it be pulled -- this was all coordinated with 
the Shepherd/AD/RFC-Editor and authors before it was discussed with the 
WG at the last IETF.

The reason that the technical change forced this reset is simply that it 
happened without any discussion with the IESG.

Once a document is submitted for publication, they own it - not the WG.  
Once our AD was notified that this change was made, the only question 
she had for me (as Shepherd/co-chair, Pavan was consulted but recused 
himself as he is a co-author) was if to send it back to the WG or remove 
the change and immediately start on a bis.  The former seemed the more 
reasonable.  At this point, we can always go the BIS route if that's 
what the WG decides.

Please also keep in mind that the WG owns the technical content of a WG 
document, not the authors or editors.  Authors and editors have a lot of 
leeway in how to gauge or build consensus, including making a change in 
an active WG document and then discussing it with the WG.  Ultimately it 
is WG last call that ensures that a document represents WG consensus 
prior to publication submission. It is true that technical changes also 
happen during IESG processing, and it is IETF last call that ensures the 
final technical comment matches IETF consensus - and it the AD that 
ensures the content matches IETF consensus.

A technical change, no matter how small, post all LCs and in the RFC 
editor queue initiated by the authors, without any coordination, is a 
serious process fowl.  Deborah was fully within her rights to reject 
this change and present the Chairs with the option of doing what we're 
doing or proceeding with RFC publication without the change.  BTW the 
formal version of this is documented in RFCs2418 and 4858.

Do you think we should proceed with publication without this change?  If 
so, please respond to the 2nd LC stating this.

Lou

(as Shepherd and Co-chair)

>
> Igor
>
>
>
> Thanks,
> Igor
> *From:*Lou Berger
> *To:*Igor Bryskin,Xufeng Liu,
> *Cc:*TEAS WG,draft-ietf-teas-yang-te-topo@ietf.org,
> *Date:*2019-03-09 15:56:11
> *Subject:*Re: [Teas] Fwd: IETF WG state changed for 
> draft-ietf-teas-yang-te-topo
>
> Hi Igor, (and authors)
>
>     Can you point to where in the archive this discussion took place - 
> https://mailarchive.ietf.org/arch/browse/teas/?q=source%20instance 
> isn't yielding helpful information.  It's also fine for the authors to 
> make the case for the change now if a suitable reference can't be found.
>
> Lou
>
> PS For future reference, technical changes are generally now allowed 
> once a document has been approved by the IESG, and even more rarely 
> once in the RFC editor queue.  (This is nothing new - I remember 
> having quite a discussion back when Jon P. was RFC editor and having 
> to convince him that moving the '|' in a packet format half a bit over 
> in a drawing didn't require moving the doc out of the RFC editor queue 
> even though half bits clearly didn't match the text.)
>
> On 3/8/2019 3:56 PM, Igor Bryskin wrote:
>>
>> Hi Lou,
>>
>> We have had quite a bit of  private discussions between the 
>> co-anthers, and I believe, we provided a summary to the WG.
>>
>> In our opinion it is a very simple, straightforward, yet quite useful 
>> addition. It was brought  to our attention by the model implementers 
>> that for a given topological element (e.g. TE link) there could be 
>> more than one instance of the same source of where the information 
>> has come from. For example, there could be more  than one instance of 
>> OSPF-TE protocol running in the network, and it is useful for the 
>> client application to understand which instance discovered/provided 
>> information for which TE links.  Before the change the model could 
>> only indicate the type of the information source (OSPF-TE protocol), 
>> but not its specific instance, hence the addition of the instance leaf.
>>
>> Regards,
>>
>> Igor (and co-authors)
>>
>> *From:*Lou Berger [mailto:lberger@labn.net]
>> *Sent:* Friday, March 08, 2019 2:53 PM
>> *To:* Xufeng Liu
>> *Cc:* TEAS WG; draft-ietf-teas-yang-te-topo@ietf.org
>> *Subject:* Re: [Teas] Fwd: IETF WG state changed for 
>> draft-ietf-teas-yang-te-topo
>>
>> Xufeng,
>>
>>     Can you (or other authors) discuss the motivations/issue 
>> addressed by the information-source-instance?-- Perhaps I missed it, 
>> but I believe  this was a change made without WG discussion.
>>
>> Thank you,
>>
>> Lou
>>
>> On 3/8/2019 2:25 PM, Xufeng Liu wrote:
>>
>>     Hi Lou,
>>
>>     The change summary has been posted to the WG mailing list
>>     (https://mailarchive.ietf.org/arch/msg/teas/sQ2wMTXYXwniUujt29fysqHwwpI).
>>     Please advise if the authors need to do anything further.
>>
>>     Thanks,
>>
>>     - Xufeng
>>
>>     On Wed, Mar 6, 2019 at 4:21 PM Lou Berger <lberger@labn.net
>>     <mailto:lberger@labn.net>> wrote:
>>
>>         All,
>>
>>             The recent versions of the te-topology doc had
>>         sufficiently significant technical changes that our AD and I,
>>         with input from the authors, agreed that the document should
>>         come back to the WG and to rerun a full last call process. 
>>         The key changes in rev -19 were:
>>
>>         - Referencing the te-types document and updates to point to
>>         its module
>>
>>         - introduction of information-source-instance
>>
>>         The second change is a technical change resulting from
>>         implementation experience, so is a good change, but as it is
>>         a substantive technical change the document has to come out
>>         of the RFC editor queue to accept it.
>>
>>         Authors,
>>
>>             Can you send out a message summarizing all changes.
>>
>>         We will then restart the WG LC process.
>>
>>         Thank you,
>>
>>         Lou (as Shepherd/co-chair)
>>
>>         -------- Forwarded Message --------
>>
>>         *Subject: *
>>
>>         	
>>
>>         IETF WG state changed for draft-ietf-teas-yang-te-topo
>>
>>         *Date: *
>>
>>         	
>>
>>         Wed, 06 Mar 2019 10:49:31 -0800
>>
>>         *From: *
>>
>>         	
>>
>>         IETF Secretariat <ietf-secretariat-reply@ietf.org>
>>         <mailto:ietf-secretariat-reply@ietf.org>
>>
>>         *To: *
>>
>>         	
>>
>>         lberger@labn.net <mailto:lberger@labn.net>,
>>         teas-chairs@ietf.org <mailto:teas-chairs@ietf.org>,
>>         draft-ietf-teas-yang-te-topo@ietf.org
>>         <mailto:draft-ietf-teas-yang-te-topo@ietf.org>
>>
>>
>>
>>
>>         The IETF WG state of draft-ietf-teas-yang-te-topo has been
>>         changed to "WG
>>         Document" from "Submitted to IESG for Publication" by Deborah
>>         Brungard:
>>
>>         https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
>>
>>         _______________________________________________
>>         Teas mailing list
>>         Teas@ietf.org <mailto:Teas@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/teas
>>