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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Mon, 11 March 2019 02:18 UTC

Return-Path: <vishnupavan@gmail.com>
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 213DF130E66; Sun, 10 Mar 2019 19:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Uamo2_nw60KM; Sun, 10 Mar 2019 19:18:48 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A1F127918; Sun, 10 Mar 2019 19:18:48 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id h11so2830319pgl.0; Sun, 10 Mar 2019 19:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vvs01KJLK8YggAINYRoeibzGT0BgkoECcoKAoEfqvy4=; b=C1n3lB/pmlT5cS74f/MBVjHkHZHlZKGZB8rEvf5dC/oKTGJHr9n/zTtZSVpg7QpukN jISFoJ0OgCavpw/+IBZ/EFTGrr0R4V1ItlKUGzaM5o0mLj12eAWMC5TzgTvOSQ4mkVWE /a47RaH6eyzsNzzn6A7K2kQ5i6apa9nevjGrLEJ9ptqzhzIkpv8iGcQzlvj9Gj7EUlsy Ut1dYiBu0zUAO4OJXV7VDm4ns0Oc2CWfIK5p4UZJxqgnUBONEzK86h4fJ367vJS4iCwV 5WP0tl8Bf1gfjxt5nYOghMsP5g17aFNrr8bQWzX7frHv/fn0h2yOyH2mfQT2bRmEJNp5 hcTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vvs01KJLK8YggAINYRoeibzGT0BgkoECcoKAoEfqvy4=; b=PhhbC0Hg5PZ3s2ipMvC71z+PXwm1Y5K7kaDOgfZefXIk9vdmovgzdvNO2LJX28e/LN SwTbbtQjaSiZefka/YYCmySfvJaqcLycNzMAT9P95Saba2kBYJfwcOl7/mb3B//qI7ew UR8v0mgq/zcmCE0xtKapl37OSTHktAPoVCb1sxLnVd5koRpC/s+T8oWLVyIXowbceTsZ 8OTFxM/+d+CfKOxyZWa3rE7QbHkTyda9FZKvU9EoW1P8+4SKepeWAi4j+Z+xTWZpUqam lQBPu6g3bJ+zZQwkIynlwYmOSebua/yBpNKT0RaLIpCkRLqB8TpZ6KXnUTIxlXyHuBlB LYOQ==
X-Gm-Message-State: APjAAAUyKM7zqEF8iPoNhNB8OWwUwdqgpzwbnU67Cjk79vB0sdYK6dX+ dieFBJAzeKCXOl2RORqC1+qZrsX/aJF4H6zLdEI=
X-Google-Smtp-Source: APXvYqw7GV16D51siaFq63QUlESSORZABswSYD6IdZAMH2n4U5DpNQslib7WMa4QO0j01qiySidGepAxHKJf+w+xs+Y=
X-Received: by 2002:a63:4962:: with SMTP id y34mr28672661pgk.425.1552270727847; Sun, 10 Mar 2019 19:18:47 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <ced37bb2-6048-b8b8-595e-9ff637f2a5b7@labn.net>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Sun, 10 Mar 2019 21:18:36 -0500
Message-ID: <CA+YzgTtZSmROKuOXoZugWDV4CQyUmn_gOy7ErfiivQ-LkTVb3A@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Cc: Igor Bryskin <Igor.Bryskin@huawei.com>, "xufeng.liu.ietf@gmail.com" <xufeng.liu.ietf@gmail.com>, "BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>, "draft-ietf-teas-yang-te-topo@ietf.org" <draft-ietf-teas-yang-te-topo@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005424410583c83151"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/exWFzt4GbGE5PzKuN3raaG6BjjA>
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 02:18:52 -0000

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
>