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

Suresh Krishnan <Suresh@kaloom.com> Thu, 20 December 2018 05:44 UTC

Return-Path: <Suresh@kaloom.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 CD885130FF8; Wed, 19 Dec 2018 21:44:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.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 NxOYigHB8l8u; Wed, 19 Dec 2018 21:44:18 -0800 (PST)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670127.outbound.protection.outlook.com [40.107.67.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DF0130E16; Wed, 19 Dec 2018 21:44:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pekJhDdMGFeCn8rlLyKJmCa+MTINRODYfa64IfGgoUg=; b=sQKdCgkDa7UYK4qj9TLFd+x8zUk26PoLum9zKy49afEkyfftiPaDsDaEFo2JBFzgN8z/0iyNRvF06kFeZH7abXENzKcM0veflRODRv4GVEhpwiKKu0xmBiHeftGE7gAHKCMkF7r2AHq2uhZzRF+dOP23DYtwajIQ79uZAeM0MB0=
Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM (52.132.44.159) by YTOPR0101MB2060.CANPRD01.PROD.OUTLOOK.COM (52.132.49.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.22; Thu, 20 Dec 2018 05:44:14 +0000
Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::5166:4dc:8313:30d0]) by YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::5166:4dc:8313:30d0%6]) with mapi id 15.20.1425.025; Thu, 20 Dec 2018 05:44:14 +0000
From: Suresh Krishnan <Suresh@kaloom.com>
To: "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: AQHUmBSG6Rzyix0Lm0yLgi4C8qB8xaWHCCqggAAVv4A=
Date: Thu, 20 Dec 2018 05:44:14 +0000
Message-ID: <A63B8724-C84D-4A92-A747-865B377A6AD8@kaloom.com>
References: <154527669905.1822.11138986536679857134.idtracker@ietfa.amsl.com> <fdce9dee40c1440587f87618e9accd0d@XCH-ALN-001.cisco.com>
In-Reply-To: <fdce9dee40c1440587f87618e9accd0d@XCH-ALN-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com;
x-originating-ip: [45.19.110.76]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2060; 6:pwwhxLwjsGvkTJk/zmkZeB2Oh/2kA38ys9WpkzqQeP1brvwIFASuG5Ui0ahhhF/r2qI/xeef+c6NWIeLnWEEPRrRdbvmjz2meO9a4u0+RHB7yhR3Rby3peKQ/vIJcNUCwqpZ0BFBi+APVvDvP5lX6LIOsbh7Hm3AA8mLyso7+36tibT7ahiZ3dHuiIn/uKgowfXEK5K93ysMQ1rPeWtE8t/QAfPffMAvX+2J04yMeDPYia6oddS1tyZNRHwHBeT664USRO7ocrq83c5ds4Xrfa+upbpScfRHjmFXfk4O0r93VSN8tyKzDuOpKtQhjb8Fs0Hi1b9iJ2qMZcxurWTGH+ZoBNQ2oPVEzcQC9Zogsz8vNBbLtQzbS71hU2QGcTnycdevin9Uri3QYqlLj0i0/e8OhmMWEQFeaw8K+O+1VXJX87wRPgCzDUsK6ljJAKIH+6C4R45fgB4Ux1C64jIG2A==; 5:h61DIMihxk65yaw7xm0A3nJUVc77m1JwtczQMskZDKkuc/uCz61VmcfIiLDfG79qwezPaWptyRjB1CLNIFjrZH+aEUmOneomFw7Ma8XwTHTTULccZ+3TDUMYJ+41TKwU0COF+tO+Vmcyl3luaKVowgoxD4HsO1YTjcvco/0Un94=; 7:Fr/CLhkOSuuo6pm0N3XHfu3HpG/8Rf8T5wqLM3fVO9S/lG+hFNyyvFTXnJDxEw/qUnRSwpBkfnckp/1AmS/VICYKUigqUhskf1t5A1TuS1D3IejTGGYllgNg3P9QIZ19x4T+eHf1OMpxMbEY36wGMg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 750ace71-2cf3-401c-61c8-08d6663e2cfc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB2060;
x-ms-traffictypediagnostic: YTOPR0101MB2060:
x-microsoft-antispam-prvs: <YTOPR0101MB20601601E0760165F07E874CB4BF0@YTOPR0101MB2060.CANPRD01.PROD.OUTLOOK.COM>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(999002)(5005026)(6040522)(2401047)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(3002001)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(2016111802025)(6043046)(201708071742011)(7699051)(76991095); SRVR:YTOPR0101MB2060; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB2060;
x-forefront-prvs: 0892FA9A88
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400004)(396003)(346002)(366004)(136003)(376002)(13464003)(51914003)(199004)(189003)(316002)(305945005)(82746002)(54906003)(86362001)(6916009)(26005)(6436002)(3846002)(6116002)(256004)(66066001)(71200400001)(83716004)(2906002)(5660300001)(7736002)(71190400001)(6486002)(102836004)(6246003)(53546011)(186003)(229853002)(6306002)(53936002)(25786009)(33656002)(6512007)(6506007)(76176011)(2616005)(476003)(508600001)(8676002)(81156014)(99286004)(72206003)(446003)(81166006)(39060400002)(11346002)(486006)(14454004)(68736007)(8936002)(966005)(36756003)(106356001)(97736004)(80792005)(4326008)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:YTOPR0101MB2060; H:YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: zDEMab+P8mPK+T15eQb7b3VWYx9xap/APDj66FX2IMXVk52cpOOD9uZuuTgz5TrrwF6haxRQo4pSbP+70vfDR59IHcB5imz/BaP5XMCddRNQukU0ycx/v8bCOm8llN/BAgtEWF9BOmFJy0ZxiqBSNBbupi9qJ/HL6AhLhbgpxExKVMI7wDB/u7imkZYcZx/ShzFu0vjTuos59hjvd8xpZygGQM03qwf/AoBEnXq/Q2QrG2XmsqW1V8foJJMK8aYCGXbCftvnk7sR0jo5CCL77AHDTsKmQix8MCYzmUr66Ii3foo0pOz/YHKdaFGWW2Sl
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <06144886423E414E92DBEB6DC1155A2D@CANPRD01.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: kaloom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 750ace71-2cf3-401c-61c8-08d6663e2cfc
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2018 05:44:14.7016 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2060
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/TDfZ9U91ngHeH5WKOomjQZ525ho>
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 05:44:22 -0000

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.

> 
> 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