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

Lou Berger <lberger@labn.net> Mon, 11 March 2019 03:31 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 53165130E83 for <teas@ietfa.amsl.com>; Sun, 10 Mar 2019 20:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 enObksopv_ma for <teas@ietfa.amsl.com>; Sun, 10 Mar 2019 20:31:26 -0700 (PDT)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 DAAA4130DCB for <teas@ietf.org>; Sun, 10 Mar 2019 20:31:25 -0700 (PDT)
Received: from CMGW (unknown [10.9.0.13]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 2914514060A for <teas@ietf.org>; Sun, 10 Mar 2019 21:02:12 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 3BCdhfVt0eyBx3BCdhCcoH; Sun, 10 Mar 2019 21:02:12 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:CC:To:From: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=67NBaUA3VXwVLBuAcCOtrc/IZ+lzbRiyFj8UgHsfwJw=; b=TPFDTi+5EiuoAtDDOKOAtFljcA xWQBWn9B5x9iokEh8jeDmgQ6hByVRLWuLjn1oasr7vURouXvu553lOprgeEjhiBNEdqDJeQEwQggI On/tsqjdu1pJpRWrg6cFblFAI;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:56352 helo=[11.5.0.30]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1h3BCd-004Ewx-DC; Sun, 10 Mar 2019 21:02:11 -0600
From: Lou Berger <lberger@labn.net>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
CC: Igor Bryskin <igor.bryskin@huawei.com>, draft-ietf-teas-yang-te-topo@ietf.org, teas@ietf.org, xufeng.liu.ietf@gmail.com, "BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>
Date: Sun, 10 Mar 2019 23:02:08 -0400
Message-ID: <1696ab310d0.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <CA+YzgTtZSmROKuOXoZugWDV4CQyUmn_gOy7ErfiivQ-LkTVb3A@mail.gmail.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> <ced37bb2-6048-b8b8-595e-9ff637f2a5b7@labn.net> <CA+YzgTtZSmROKuOXoZugWDV4CQyUmn_gOy7ErfiivQ-LkTVb3A@mail.gmail.com>
User-Agent: AquaMail/1.18.2-1413 (build: 101800200)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------1696ab347e51dee27ceb7a919c"
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: 1h3BCd-004Ewx-DC
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([11.5.0.30]) [72.66.11.201]:56352
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/4rGIIGN35k-xAojAN_mVUCRXLSM>
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: Mon, 11 Mar 2019 03:31:28 -0000

> If a new rev is published now without
> the information-source-instance change (and with all the other changes made
> in rev 19 left intact), would the document skip back to the RFC-Editor's
> queue without any IESG involvement?

I don't believe so, I think we still have to go through redoing the pub 
request and iesg, but as there would be no substantive change it might go 
through faster.

Given where we are today, imo let's get it right and move forward.  if 
dropping the change means that we've have to immediately start on a BIS I 
think dropping it would be the wrong move. If on the other hand the change 
really isn't needed, that it would be good to hear that.

Lou

----------
On March 10, 2019 10:19:27 PM Vishnu Pavan Beeram <vishnupavan@gmail.com> 
wrote:

> Igor,
>
> The only foul that the authors made was to not discuss the diffs on the
> list before submitting rev-19. There was an incorrect assumption made (by
> the authors) that Xufeng's post submission email with details on the diffs
> was sufficient to trigger the necessary discussion. This was an oversight
> and had no intended malice. This practice (of submitting the changes first
> and then triggering a discussion about the diffs) is sort of deemed
> acceptable while the document is being reviewed by the WG or IESG, but not
> while it is sitting in the RFC Editor's queue. In hindsight, given that the
> document was sitting in the RFC Editor's queue, the authors should have
> reached out to the AD/Shepherd for guidance before submission (and I take
> the blame on behalf of the authors for not doing it).
>
>
> Lou, Hi!
>
>>> Do you think we should proceed with publication without this change?
>
> I think the WG would need more details (to weigh in with an informed
> opinion) on how proceeding with publication without this change would
> impact the progress of the document. If a new rev is published now without
> the information-source-instance change (and with all the other changes made
> in rev 19 left intact), would the document skip back to the RFC-Editor's
> queue without any IESG involvement?
>
> Regards,
>
> -Pavan (no hat on)
>
> On Sun, Mar 10, 2019 at 5:08 PM Lou Berger <lberger@labn.net> wrote:
>
>> 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 <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> 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>
>> <ietf-secretariat-reply@ietf.org>
>>
>> *To: *
>>
>> lberger@labn.net, teas-chairs@ietf.org,
>> 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
>> https://www.ietf.org/mailman/listinfo/teas
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
>>
>
>
>
> ----------
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>