Re: [Lsr] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

stefano previdi <stefano@previdi.net> Fri, 07 December 2018 10:36 UTC

Return-Path: <stefano@previdi.net>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F3F12D4EF for <lsr@ietfa.amsl.com>; Fri, 7 Dec 2018 02:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=previdi-net.20150623.gappssmtp.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 vuAqVOkXRc3t for <lsr@ietfa.amsl.com>; Fri, 7 Dec 2018 02:36:45 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 D4C6712D4E6 for <lsr@ietf.org>; Fri, 7 Dec 2018 02:36:40 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id c126so4005426wmh.0 for <lsr@ietf.org>; Fri, 07 Dec 2018 02:36:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=previdi-net.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7vT7irE0kVcHNtMIzU0ZlbTql23FbrjSjm6o4+f1siA=; b=TNrzYxNcFJayqspgGMdWNNMFSrCg7HIHPpxWlXQWXDZlxyt30GbiZMgk5BZhOr9y50 3Yu8H7gOsyZEDw108zLBqQTN4qYA3jvPnPB53cgqZCTaHXd7u4uJN+GLh1LuJxq3u/9l fqe9dcOAEwwlWEkvqtYyL/kSe2Foj4Nj8sqeVK1S7c2YzfOGc4aPStnWqpIaCh7iV9mG WMqrcobNOGouzeIZiP10r3ue3Qa6ihuSWYCrA8TWelRiitV0PEGzP/YizGyk39kmIK3C ixfOKtnA2Gan2nvjad2LCQE3sEYdMhKiu8z1FoIGyR93/WUqMzwsyZ4iZqDmMwOta3GG 7H6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7vT7irE0kVcHNtMIzU0ZlbTql23FbrjSjm6o4+f1siA=; b=kB7FuJkbAGOZnr9CegydHtSqXcd1Ylbddf8OB9OmQTdz/apyvwEr9iCwWVFbfKMhSF PAXqicyrwN3sDWes/HCqx5ZuqsG2AMe11cPCikkEET+oJOaT+0hDn2/YTzaBooQKJ7LT MFfMHmGn76WAzh902A7ucujQU60N7MUZWg7/FxW4ToP7KvdoCE+QdWGYnTJS7d0OfEpu isATt61fOS0sWpUNAEccVWL3p1VgD5vZ657PlyWp9hr0kcF9rdn5XGi4mzg/TzqGiFah FfeO5zndbxz2mLbFZUA8b1U1vNohPe4h+PI3v57VJvrk0m/jjUy102GDWjBTrT7toqNP KBsA==
X-Gm-Message-State: AA+aEWbJMqcf/GjX4HN3w0BTX4lugt+MH/gpDm9F4L4fqUTdreQvzgbc nDvgROaDJTCMYoGQDhZjqEkLdg==
X-Google-Smtp-Source: AFSGD/UqMOYI5q4kfWuPplbGaH0D00+tYz93q1fXh14CoMxvxl05E6BmUzfneGCTFG6o2g4RWhjH3A==
X-Received: by 2002:a1c:8089:: with SMTP id b131mr1738277wmd.141.1544178999216; Fri, 07 Dec 2018 02:36:39 -0800 (PST)
Received: from [192.168.1.4] (net-5-95-98-64.cust.vodafonedsl.it. [5.95.98.64]) by smtp.gmail.com with ESMTPSA id v132sm3532011wme.20.2018.12.07.02.36.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Dec 2018 02:36:38 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: text/plain; charset=utf-8
From: stefano previdi <stefano@previdi.net>
In-Reply-To: <67ec6658191947d694362a7d88056514@XCH-ALN-001.cisco.com>
Date: Fri, 7 Dec 2018 11:37:09 +0100
Cc: "Acee Lindem (acee)" <acee@cisco.com>, Christian Hopps <chopps@chopps.org>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "draft-ietf-lsr-isis-rfc7810bis.all@ietf.org" <draft-ietf-lsr-isis-rfc7810bis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Yoshifumi Nishida <nishida@wide.ad.jp>, "tsv-art@ietf.org" <tsv-art@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <69CCE4B8-6A9B-425D-839D-E98579168570@previdi.net>
References: <154403709395.31955.8914260506541556177@ietfa.amsl.com> <347556ed4ea34fa7844085e5a6639f13@XCH-ALN-001.cisco.com> <CAMMESswDdqQHAiWJgoO5kuLQXU12+bwUeofW9Rsa04mkVt=X=g@mail.gmail.com> <67ec6658191947d694362a7d88056514@XCH-ALN-001.cisco.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/cg7ieer9fI7exXj5biqf6jAPheI>
Subject: Re: [Lsr] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2018 10:36:48 -0000

Hi All,


> On Dec 7, 2018, at 11:01 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:
> 
> Alvaro –
>  
> I am not in agreement with your POV.
>  
> The work undertaken for this revision was very specifically to address Errata ID: 5293 (https://www.rfc-editor.org/errata_search.php?rfc=7810) . This was deemed critical because the format of several sub-TLVs was incorrectly specified and we learned that this resulted in an interoperability problem because some implementations chose to include the unneeded reserved field and used a sub-TLV length of 5 whereas other implementations omitted the Reserved field and used the specified length of 4. We wanted to fasttrack this change to avoid further interoperability issues.
>  
> Just prior to preparing for last call Errata ID: 5486 (https://www.rfc-editor.org/errata/eid5486) was posted. As this was only an editorial change we decided to address that as well.
>  
> There was never an intent to review/alter any other portion of the document. Rather we constrained the changes precisely so that we could publish a corrected version of the RFC ASAP.


correct. This also was pointed out at the time of editing and submission of this draft. The WG agreed to move on without res-pinning th whole reviwe process exactly for the reasons above.


> Your argument that since we are obsoleting RFC 7810 the entire document is fair game is not consistent with the agreed upon scope of the changes.
> The WG never agreed to open up the document for general revision and I do not believe it should be within the purview of IESG review to alter the scope of the work the WG agreed to take on.
>  
> Suggesting that rather than issue a new version of RFC7810 we should issue a smaller document only with the corrections is a viable option – but IMO makes an unnecessary mess of things.
>  
> As an aside, it is quite frustrating to me that it is almost 9 months since this work was started and we still have yet to complete it. Taking this long to publish a non-controversial and much needed editorial revision is much too long. Though I appreciate we are getting closer, I think this does not speak well of us as an organization. Opening up the document to general review can do nothing but delay this further – making it more likely that additional non-interoperable implementations may be written.


+1.

Thanks.
s.


>  
> Yoshi (or any other IETF participant) is free at any time to raise questions about RFC7810/RFC7471 and the WG can decide whether it agrees that changes are needed. But that is not within the scope of this work.
>  
>    Les
>  
>  
>  
> From: Alvaro Retana <aretana.ietf@gmail.com> 
> Sent: Thursday, December 06, 2018 9:55 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; Acee Lindem (acee) <acee@cisco.com>om>; Christian Hopps <chopps@chopps.org>
> Cc: lsr@ietf.org; lsr-chairs@ietf.org; draft-ietf-lsr-isis-rfc7810bis.all@ietf.org; ietf@ietf.org; Yoshifumi Nishida <nishida@wide.ad.jp>jp>; tsv-art@ietf.org
> Subject: RE: Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03
>  
> On December 5, 2018 at 7:52:00 PM, Les Ginsberg (ginsberg) (ginsberg@cisco.com) wrote:
>  
> Les:
>  
> You are right in pointing out that the changes made to rfc7810 are the ones mentioned in the appendix.  That was the motivation that originated this work.
>  
> However, this document doesn’t just modify rfc7810, it formally declares it Obsolete.  That indicates that we (the WG, etc.) are opening up the whole document for review/comments…which obviously means that Yoshi’s comments are not out of scope.  The WG didn’t change anything else (which is ok), but the IETF Last Call exists to include cross-area review and to allow others (e.g. non-WG participants) to comment.  
>  
> In any case, it seems to me that Yoshi’s comments are clarifying questions which may not require changes to the document itself. But I’ll leave that discussion/decision to him and to the TSV ADs.
>  
>  
> Note that if what is wanted (by the WG) is to Update rfc7810 (and not Obsolete it), and constrain the text to be reviewed/commented on, then this is not the right document.  That document would have contained only the changes.  We’re still in time to change the direction.  I’m explicitly cc’ing the lsr-chairs so they can make any needed clarification.
>  
> Thanks!
>  
> Alvaro.
>  
>  
> I can appreciate that this may the first time you have looked at RFC7810 - let alone the bis draft. As a result you have commented on content which is common to the bis draft and the RFC it is modifying (RFC 7810). 
> 
> While your questions in isolation may be interesting, I believe they are out of scope for the review of the bis draft. What the bis draft is doing is addressing two modest errata - details of which can be found in https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-03#appendix-A 
> Comments on content not related to those changes is out of scope. 
> 
> If you have an interest in this topic and want to comment on the substance of RFC 7810 and its companion document for OSPF RFC 7471, I encourage you to do so. Note that all of your comments (save the one on Security) are also applicable to RFC 7471 - so any agreed upon modification would need to be made to both documents. But I do not want to even start discussing such changes in the context of reviewing the bis draft changes. I hope you can understand why.