Re: [Lsr] Suresh Krishnan's No Objection on draft-ietf-lsr-isis-rfc7810bis-04: (with COMMENT)

"Acee Lindem (acee)" <acee@cisco.com> Thu, 20 December 2018 10:38 UTC

Return-Path: <acee@cisco.com>
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 9433D130DF2; Thu, 20 Dec 2018 02:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 mFGK5nM2TNES; Thu, 20 Dec 2018 02:38:52 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCE0130E1B; Thu, 20 Dec 2018 02:38:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5378; q=dns/txt; s=iport; t=1545302332; x=1546511932; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fL5xo+u3xLqDEBXV7yP/7YBQQUPA2950Akm7nbO6Z+o=; b=XywQzMofd76W5qeLAdhG2H2uCa8uX7IMcNYZ1jGrqPXMhXAz8HI6iO0n 2UkKOTmq/qfQkcxOOrMwn6zX7gGKhixagGYECkJYip/lohzQtqnqYuhw9 WQDo1NMrTxokeKsPcek5mGLy92PjnCRbhx0MGVHtJAEEAXzg7Ht2iQfhC c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAACPcBtc/51dJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVopZoECJwqDc4gZi3yCDYkVjkgUgWcLAQEjhEkCFyqCKiI0CQ0BAwEBAgEBAm0cDIU8AQEBAQIBIxFFDAQCAQgRBAEBAQICJgICAh8RFQgIAgQBDQWDIgGBaQMNCA+nYIEvhEFAgwENghgFgQuLNBeBf4ERJx+CTIJXRwIBAgGBKgESATaCcTGCJgKJRwEDgXeVSDMJAocPhyKDMhiBX4UfgzGHLYlMhHuBEooLAhEUgScfOGVYEQhwFWUBgkGCJxcSbQEIh1aFP0ExAYwogR+BHwEB
X-IronPort-AV: E=Sophos;i="5.56,376,1539648000"; d="scan'208";a="494385065"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2018 10:38:50 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id wBKAcoc8025803 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Dec 2018 10:38:50 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 20 Dec 2018 05:38:49 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Thu, 20 Dec 2018 05:38:49 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Suresh Krishnan <suresh@kaloom.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-lsr-isis-rfc7810bis@ietf.org" <draft-ietf-lsr-isis-rfc7810bis@ietf.org>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-lsr-isis-rfc7810bis-04: (with COMMENT)
Thread-Index: AQHUmBSGbVMnKmOaUESluXKYHvKPqqWHXtiAgAAS5AD///58AA==
Date: Thu, 20 Dec 2018 10:38:49 +0000
Message-ID: <F68B4FEA-46A3-47EF-AEBA-E7978A29AA7C@cisco.com>
References: <154527669905.1822.11138986536679857134.idtracker@ietfa.amsl.com> <fdce9dee40c1440587f87618e9accd0d@XCH-ALN-001.cisco.com> <A63B8724-C84D-4A92-A747-865B377A6AD8@kaloom.com>
In-Reply-To: <A63B8724-C84D-4A92-A747-865B377A6AD8@kaloom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <C30FC860057E92428BFE43F4D7D3AE5C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.146, xch-rtp-006.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/S0YuK5rx59talExNuwQkIYyO0Ps>
Subject: Re: [Lsr] Suresh Krishnan's No Objection on draft-ietf-lsr-isis-rfc7810bis-04: (with COMMENT)
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: Thu, 20 Dec 2018 10:38:55 -0000

Hi Suresh,

On 12/20/18, 12:44 AM, "Suresh Krishnan" <suresh@kaloom.com> wrote:

    Hi Les,
      Thanks for the quick response. Comments inline.
    
    > On Dec 19, 2018, at 11:36 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:
    > 
    > Suresh -
    > 
    > Inline.
    > 
    >> -----Original Message-----
    >> From: Suresh Krishnan <suresh@kaloom.com>
    >> Sent: Wednesday, December 19, 2018 7:32 PM
    >> To: The IESG <iesg@ietf.org>
    >> Cc: draft-ietf-lsr-isis-rfc7810bis@ietf.org; Ketan Talaulikar (ketant)
    >> <ketant@cisco.com>; aretana.ietf@gmail.com; lsr-chairs@ietf.org; Ketan
    >> Talaulikar (ketant) <ketant@cisco.com>; lsr@ietf.org
    >> Subject: Suresh Krishnan's No Objection on draft-ietf-lsr-isis-rfc7810bis-04:
    >> (with COMMENT)
    >> 
    >> Suresh Krishnan has entered the following ballot position for
    >> draft-ietf-lsr-isis-rfc7810bis-04: No Objection
    >> 
    >> When responding, please keep the subject line intact and reply to all
    >> email addresses included in the To and CC lines. (Feel free to cut this
    >> introductory paragraph, however.)
    >> 
    >> 
    >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    >> for more information about IESG DISCUSS and COMMENT positions.
    >> 
    >> 
    >> The document, along with other ballot positions, can be found here:
    >> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/
    >> 
    >> 
    >> 
    >> ----------------------------------------------------------------------
    >> COMMENT:
    >> ----------------------------------------------------------------------
    >> 
    >> * Backward compatibility
    >> 
    >> There is text in Appendix A that provides guidance to implementers on how
    >> to
    >> handle TLVs with length 5 from RFC7810. I think this would be much more
    >> helpful
    >> inside the main body of the document. I was wondering how the backward
    >> compatibility was handled until I read through the Appendix that lists the
    >> *diffs*.
    >> 
    > 
    > [Les:] I REALLY do not want to do this.
    > 
    > There is no intent to legitimize two different encodings. Implementations which encoded the problematic sub-TLVs with a length of 5 and a reserved byte were wrong - though obviously based on the flawed text in RFC 7810 it wasn't easy for a reader to realize that.
    
    No worries. My comment was not blocking :-), but the document certainly does not clearly reflect your position. Either you want to support the old implementations or not. I am fine with either way but the text in the appendix is certainly leaning the other way towards backward compatibility. As long as the guidance is consistent, I certainly have no issues.

We only know of one implementation that has the wrong encoding and we have fixed that one.

Thanks,
Acee
    
    > 
    > The obligation is on the implementations which used the 5 byte encoding to correct themselves and use the 4 byte encoding.
    > There is no obligation on conformant implementations to be "generous" and allow for interoperating with implementations which used the 5 byte encodings.
    > There might be business value in doing so - but that is outside the purview of specification. We use the appendix only to suggest that "generosity" be considered.
    
    This is where you lost me. What is the actual guidance you want to provide? You said earlier “There is no intent to legitimize two different encodings” and then say here that implementations should be generous. That does sound like a “MAY” to me.
    
    > 
    > The main body of the document should not be cluttered with this. It needs to serve as the normative specification independent of the prior existence of RFC 7810.
    
    Sure. Your call.
    
    Thanks
    Suresh