Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 08 January 2019 14:34 UTC

Return-Path: <kaduk@mit.edu>
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 11C65130EE7; Tue, 8 Jan 2019 06:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
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 Tt0SgSWaiY45; Tue, 8 Jan 2019 06:34:04 -0800 (PST)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730092.outbound.protection.outlook.com [40.107.73.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1610130ED6; Tue, 8 Jan 2019 06:34:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eCgP/zhET3gEwgzTr4ewEeVsJAx6awflNLprV0TVOVU=; b=KcK7NNBc1jJNQfRbBG4z+peO1ZnRnjH+VIx3aWwVHdC6HGLzMxz43wCNcd13r7EaQvzCpXkW00JKlfuGwKILlDEAzMb62gDA28vEvyPDbm0RkoGHMJKnwyaNvRcqz0Yr+k/9AEkQzm5vwEkNxDVzHKSRV8VfM0jfUvLtUQUkNZw=
Received: from BL0PR0102CA0056.prod.exchangelabs.com (2603:10b6:208:25::33) by MWHPR0101MB2959.prod.exchangelabs.com (2603:10b6:301:2b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Tue, 8 Jan 2019 14:34:01 +0000
Received: from DM3NAM03FT013.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::209) by BL0PR0102CA0056.outlook.office365.com (2603:10b6:208:25::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1495.6 via Frontend Transport; Tue, 8 Jan 2019 14:34:01 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT013.mail.protection.outlook.com (10.152.82.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Tue, 8 Jan 2019 14:33:58 +0000
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x08EXtfB014904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 8 Jan 2019 09:33:57 -0500
Date: Tue, 8 Jan 2019 08:33:55 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Peter Psenak <ppsenak@cisco.com>
CC: "Acee Lindem (acee)" <acee@cisco.com>, The IESG <iesg@ietf.org>, "draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org" <draft-ietf-ospf-ospfv3-segment-routing-extensions@ietf.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Message-ID: <20190108143354.GX28515@kduck.kaduk.org>
References: <154398144445.4943.7198735398003216566.idtracker@ietfa.amsl.com> <5C079200.1030701@cisco.com> <20181217055358.GC94620@kduck.kaduk.org> <69190220-4994-f9c9-4adf-5016abf3a39b@cisco.com> <03e6354b-c606-fc4a-bbf2-3d59fa1cb774@cisco.com> <20181222042939.GW94620@kduck.kaduk.org> <8D31ADF0-FA83-4B23-805E-76145BF914C1@cisco.com> <f3dff5f1-434c-431d-15a3-5fa7462f5572@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <f3dff5f1-434c-431d-15a3-5fa7462f5572@cisco.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39860400002)(136003)(2980300002)(199004)(189003)(126002)(426003)(8936002)(5660300001)(33656002)(50466002)(9686003)(106002)(39060400002)(446003)(6246003)(11346002)(75432002)(47776003)(55016002)(7696005)(186003)(476003)(4326008)(478600001)(2870700001)(356004)(26005)(76176011)(53546011)(26826003)(956004)(2486003)(106466001)(93886005)(2906002)(53416004)(23676004)(104016004)(229853002)(86362001)(88552002)(14444005)(36906005)(8676002)(336012)(316002)(786003)(246002)(54906003)(305945005)(486006)(6916009)(1076003)(58126008)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR0101MB2959; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1;
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT013; 1:euBxxTY0UDvkPWWYUTa4WlRFmeNhbsTDdqs8uE1NqRwRPkPqN17/kFwPryY3WDF+D5Gi+PS8Rlo8QIYDThQmbn5lMTI3eFrFB8kobzMH3QE0L0O7YCUBYPW1sVkUXa/f
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 75092f29-6dd6-4a2b-0079-08d6757654dd
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:MWHPR0101MB2959;
X-Microsoft-Exchange-Diagnostics: 1; MWHPR0101MB2959; 3:M0nOA9gZqWolIbG/ngeNy6zlSJdL/L36CVKlUPLLnCP7OENFMJk43JhUKWvmihfZ59kzwVad33eREXoqEnIcK3nFvxzT+yciAWFxVivsE+wT2KkSSM75Tn0dlkngfUxVFCKnZx5IvyBX9v0Ltmddqwm1QHllRUDLylTgCveS3b9Lyj3ykdbOcmgKGmnzuZO77Oz7MZeBuixFsQdGugPzxH7IEGd9OMZKX//8rT2DUqU9t0Saxl9QQGmbdNIfsER3nisXqFKXb1rcn6FxnKkTJjhvjpzUn/+F820IODbBqOR2+Dzid2/LpEMzVXM/63Ziaz6kCEvayN7LRJV0BTEafoh/MIYKmnR0IZdx+hvzLic2HLCiF3f+QkextJ8E3TPi; 25:CqQ22MkI+qabKgHdQW4IGHdsJev7EOiv2t2kXJuaLNi4yLeQ+8qWOxmAWh7PcgYAsqfDhAPcRBSQvUh6IwEMmKqdzSpko5ZX20e/+WBnOrsQY0WgqEDRMwH44CuIEGT9CKm29hcnzuXazZGrMxOlYRpES76uM4mZo5xR9WQ3XjWzIaJrSatvGtT7JXpOCN8xM1hvvupRoUIcq5iI981ZUwL8aq35VqhNBaLk1EtTTGiGKvobn/f//Gla+oQHSukae984HhE6SUAIvFyyXFryPylZQ+TZOTcuyV19+XS7z/PKS8sd4TIBu/dC5bU6NnWvT+NWysNhBjfxGBLmeo5Juw==
X-MS-TrafficTypeDiagnostic: MWHPR0101MB2959:
X-Microsoft-Exchange-Diagnostics: 1; MWHPR0101MB2959; 31:a63COTz1GdLtn1W7FOEXSkCQAvPPVqmY82edb2SgrGkUWov2eq18PLXD48TIlngY5oGxgUIeGGoQ6D+h+IL8cm68cg3pERk5ytjhMFKkRMZcpH3gwB2QGDyKV5Cic/+MRB/tV+8/hsYi7U2x2IqQ99rTdY6+CSJoLXs8nrRbgnl3jZ8L3th71KJFUNj7AD2FPBX5afR3WiqMRTGd+MhTWAjsAVkNm4lwf2wPbNfIhSA=; 20:IufC0xMI6Gg8tusRuQWE1RYs/LltxjBAeagvhEeeui7D7NJukkYEusuzTd/mbOF+/yvBZ7Kk5oeJR/GJ9Lermqf4SLKTEHCQ0mbCh7HB48//uknSBY4+iN0Jt0ppRUZOc8nTIuyFgefdxDLIyghBaTKzDvNCwXbEaQDrHKiB7NTci0/uMZjuqSvc82qeiYiRNU/b6+CRVAp057Gbdd7SEzA6DkM9T1LGFzjjK7WCbkk+7W/vvsSCa1ppknv5VTHKWX0PZAYzaKGL2aPZDi6gaNQLAhsaAtUoxJ1h4B5dJgYXMdl8dVWnRiHxkWJbDtiJk4nsvAx1wNRu8FJNqwSeKS8c599nNSbNPB4+mkGep1Gg1Bc567TtXziqIS0qSnG+617JVdEutiPjRBfXCeJgL1eH91qsqIhWrnGYXKfEK5k63aceVC/1j/S+diwe7bC48Btp8UMaxTl9ytNU+d+kk2n0httpfkRS6S7r/vkAco3hiqpk5q64Qn1ZJYPfcMsh
X-Microsoft-Antispam-PRVS: <MWHPR0101MB29592A15EAEB57102D32E7CBA08A0@MWHPR0101MB2959.prod.exchangelabs.com>
X-Microsoft-Exchange-Diagnostics: 1; MWHPR0101MB2959; 4:HFQlCX6f0SFjP+8gvWVppKVqO6jcKIxVrA4hHQJDyBQI+lXPJuf1/hekN9xzidoYCqUfn9drLIWA6mteEncugvsOV87DBPin+MJ4k0w7gMwArBH5snpx6WVMF6jsE0+nw7GsF43KKfXZi1g1svV35w2YVaVWlP3FWlJmmZwBDOqzAwMB7xEXLlQTU7ajG/1kwPX0D4TEsJFDxxtXOz2X7hO6O5zKpQcuqgknjBIf9zJwNa+9pt3ecc4LhElq6mi21d5yGCixg5+RSHYevA8hs3vg/g6pY+gk47fqbhbEa7ubkRYSogS7aLhzxe1Zozmo
X-Forefront-PRVS: 0911D5CE78
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjAxMDFNQjI5NTk7MjM6bFQ0TTFSR3pwNE95U0srcGRxbjZNK0ZT?= =?utf-8?B?OTRYS21LZXRoVDl5QS9qeVFlK0E2d29scmlNRzArSk1Ibk9RYXRtUE42MkRL?= =?utf-8?B?U1hsT1Y1THRiZ240c3AvUFhUc0h2SnBsK2dSOGRibXlGc0pNOWIvZXF4bGxJ?= =?utf-8?B?WUgzSHZqV0tneFdXMEE4VjJtbWNGaExpTkQ4eHJnOE4ranBNVjJ6elBGWnlw?= =?utf-8?B?cHY0dGtndTM2Zllpbm43VnVlbFhIN2J5YnAzSVNCWWgxbFUvQm5aZ2ZESDd6?= =?utf-8?B?NVBCdXU2dWh2eVI3MUVKYTlLczFiYlVGZEowNkFBdTVwS3lBdmlqMG9aSDJm?= =?utf-8?B?NFRYWnI4ejY1YlNaY1hvbml1YThvL0RMT2RFQnV4aXk3TXZQYnNSSi9jbk5K?= =?utf-8?B?RXUvRXJRRVUveGd0V0k5VGxKU2FvSitrZCtzeVQxVHh0a1VYZnJkR2huMzhj?= =?utf-8?B?VU94dkpUanRhQ05KZW0vUW5sSWNKcGI1dzRlbDNlT0Z2SEhLS0pSUU9VeEhD?= =?utf-8?B?YllWYmFXdEttWG1MdzJKcnoxd1FyUHRjNEY5dXhCMEZNMSt5UkNKMjNXQitY?= =?utf-8?B?MHhTNjgweDkwUU9uMVhycW1Bb1l0cVBodnBzYkV3RUJ0M1Rhck1JOVFtd2Fp?= =?utf-8?B?RkdmTmJBS3RLLzZHMCtPS1J1d3M2S3FxVUhrMENkZXVYN2diZDBCVDk0dnlD?= =?utf-8?B?WHhOYXlOSlBjb0NBVjJEd0g4cWxQTHEvb0lDWHRBTkhOZTdJZVdndFdJNGxZ?= =?utf-8?B?alg2TkxFUm1BRjZGdlhxblhhc29RemlDWEVPTGlMZ0M3UTliNUp5a25TSVhz?= =?utf-8?B?eXA3OHlrSC84WEd1bEVhdEJoM09CektYaHNOV29pTTEwV2dHbGFMcHV5S29a?= =?utf-8?B?REFzZXpPL1FSZ2FLalVNczF2a2NjL2c5MmNwZGhwRU1VNlExcFU4YXlReDlV?= =?utf-8?B?L1lOcWZvT0wyUitJd3pqUUpUVk00dXIyWmRHd3cxc3dZR0RKMFZLazRDRVlq?= =?utf-8?B?U0RWQnNWVm9SNXZQa3ZaajM1S1kzMTNWT2IrQ0tOSXZ1b3hJN1RsRHZLL3N1?= =?utf-8?B?MVpZeUtZMmVxckhrWlI4VEdRTUFBZlF1V3RSbTQ1SjFvYy9wZTA4c0NEWjB1?= =?utf-8?B?ZGV3ZUlmUlBheDk1ZFRMNGhiZ2dEUThKNjExWVoreWRUcnBjTVk5ejNKR2N4?= =?utf-8?B?aS91Qk5QU0VraGJQN3pKQnB2T2kzNkJVelo1bXhZeCtJWDZnSHVDa0FjdUNP?= =?utf-8?B?Tlk1ckhSSnY3MkljZDh1QU14WGVFMWRDSTlabDNjV04yN2NLSGVKLzFla3N6?= =?utf-8?B?eDNNOElqYW1HMmpIcnBwVGRlZVRTdG9MeGExSE9FalR2ZlMzU1BRV3RpYTB4?= =?utf-8?B?RDdVd2ZEV2lqbytjMVdmRk9FYUlFRjRPWjB6emhzOFJxWGJoQnErQzJxMWpG?= =?utf-8?B?alhnTllLOHF3d1paZEluQXg5eDdRa1oxWjRHQlg4a3A0N0FxM0F2cCtyNTNY?= =?utf-8?B?L0lvbTVRWXdNdWhGMlEwZS9sVnVnemRjZWFvUEdBNm5KcURBZWZqN292VU5x?= =?utf-8?B?ZExWbHpCYXozc3hqMUVMR3ozVUQzNG5TbDhySDZvYXNDaFUzWGRqSi9FR0x3?= =?utf-8?B?UE5PL3ZHTVRoUUhjSEdWMjlQZmp3VFp3NFVVS0g5S0sxYVdQQTJZenpvc045?= =?utf-8?B?L2VVQlgvKzV5OWZXN2EvdUJqMDNXVVBPNzh1dVpZM0t6dWd1QjFqVFdkZ2hq?= =?utf-8?B?ZGNoNlJsTUcxU0ZLMVA1VmdnPT0=?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: vxNlYginrCkXwdAhGDHLu/ovWMKU/JnSrsA0LA49rk7gccfk9N0I0jtZdjYH6jRubxjVfJ+dew77h4rAgLjoqKZLTnPOODuolTHG6YvFzHz6a5pbdmAoUIwvL6J9Ux5VY+x6PxD6a9XqDfe5iejHGk/1RY5UgkWCoYBN4i8wkAVVt7IJ54r1fhSqWE9Fe9X1DoHvVU/C5BmfGSBqtAGmm3Bu/2v8oQdbZTgTn43HwJ+LP0wuhMOeRhwk+ojRWbDeTuIMr1L3M+RlJZFsDAfv13d55IdjC/p7f0QjUNtMg7THPVOaKHvrdHis/KEkQOwR
X-Microsoft-Exchange-Diagnostics: 1; MWHPR0101MB2959; 6:gD69k9tW3slzg1T490lAX/AdN/PqUbWpgW+W5U8ZQumWJeViqmDS8mw/HAFHEc3RC7i+Rc7kbmlwOmtBxwUbyuZBlMJz56p7jwUwOtC8e/k0KPjxVLyHYD4cpeTw/AUU9B9VfV90eGTXoqZfD+rJgmzZqBoHDfx1JPd97dW/INtTeYsymVvXD9e9+072tKxZSMj2lOHYC+jFIKBZdbzWm0rP/pcVQCPSx/MUCoDLnpdtZniS0mcw5yXWomuxhaON23Jeqw/N9koVmOASQut+a5/IYN+Fzp78ejL9gZ1tF/V/NngF5S1V5ym7rgP9uRzRyGksH+te8EYqLrMDoyyNY8bq2hhBZJPuXxnR8CWbawz9C/Ba3v7q6Zu8NxWWvPUDYt8I7CVs/N0Q/fpOWY+yS2v9ya92I7vM4rMw+2j+9EmodfRI1KmTjr2e9lTIUfwyfEpbbuQwipI7BQLIWAPuFQ==; 5:2HZQ7MhfRWJ+BIMHFg7OAjst9Ja6jPMeQER9HTD3wHFkNb5HneKwbgbAXTYiZqcmEJrF5KbsfM1Bl2mxynLxZpF9+fV37PM+e71Dhm7OHQOC3uSw8PwVKeMZHKmyHn+uDEGtA+x/u30w8wxdhcVm/m89RrBjAph8q0AW1NfTE9tdtxnV9MBkOIbQEZf9GUMseiUWtDfWX9nuNWrx2AaYZw==; 7:oWg9BjAFgsTWurSjErTgn70DyupjnhdV1N9MnsZJtGSdJdU0LN2TaISet9HSiwzBr5F1cNAxxwMijSwld45Utb4N02m4TVddX8xFqpPMQLh/tMvTeHY+NsA3chVDEN6GCqtCNX4DrQD25qlXnBW1wA==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2019 14:33:58.8770 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 75092f29-6dd6-4a2b-0079-08d6757654dd
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0101MB2959
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/vq0ScJl8U_mwp0rM9xmoVNU9xSQ>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with DISCUSS and 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: Tue, 08 Jan 2019 14:34:14 -0000

Hi Peter,

Happy new year, and my apologies to all for the heavy overlap between this
message and the reply to Acee sent just a few moments ago.
(inline)

On Tue, Jan 08, 2019 at 09:13:52AM +0100, Peter Psenak wrote:
> Hi Benjamin,
> 
> please see inline:
> 
> 
> On 22/12/2018 15:34 , Acee Lindem (acee) wrote:
> > Hi Ben,
> >
> > See inline.
> >
> > ´╗┐On 12/21/18, 11:29 PM, "Benjamin Kaduk" <kaduk@mit.edu>; wrote:
> >
> >     On Thu, Dec 20, 2018 at 01:07:59PM +0100, Peter Psenak wrote:
> >     > Hi Benjamin,
> >     >
> >     > are you ok with my responses and proposed changed text for the range?
> >     >
> >     > thanks,
> >     > Peter
> >     >
> >     > On 17/12/2018 12:32 , Peter Psenak wrote:
> >     > > Hi Benjamin,
> >     > >
> >     > > please see inline (##PP):
> >     > >
> >     > > On 17/12/2018 06:53 , Benjamin Kaduk wrote:
> >     > >> Sorry for the slow reply -- you caught me right as I was leaving for
> >     > >> vacation.
> >     > >>
> >     > >> On Wed, Dec 05, 2018 at 09:53:20AM +0100, Peter Psenak wrote:
> >     > >>> Hi Benjamin,
> >     > >>>
> >     > >>> please see inline:
> >     > >>>
> >     > >>> On 05/12/18 04:44 , Benjamin Kaduk wrote:
> >     > >>>> ----------------------------------------------------------------------
> >     > >>>> DISCUSS:
> >     > >>>> ----------------------------------------------------------------------
> >     > >>>>
> >     > >>>> What is the extensibility model for the "AF" (address family) field
> >     > >>>> in the
> >     > >>>> OSPFv3 Extended Prefix Range TLV?  That is, what do we need to say
> >     > >>>> about
> >     > >>>> current implementations' behavior to allow future changes?  (I also a
> >     > >>>> little bit wonder if we really need a full eight bits, but that's
> >     > >>>> basically
> >     > >>>> aesthetic.)
> >     > >>>
> >     > >>> I don't think OSPFv3 will ever support other then IPv6 or IPv4 AF. Also
> >     > >>> the text says:
> >     > >>>
> >     > >>> "Prefix encoding for other address families is beyond the scope
> >     > >>>   of this specification."
> >     > >>
> >     > >> Perhaps it would be better encoded in a 1-bit field (rather than an 8-bit
> >     > >> one), then?  That would at least make the (lack of) semantics of the
> >     > >> other
> >     > >> 7 bits more clear, as the usual "MUST set to zero on transmit and
> >     > >> ignore on
> >     > >> receipt".
> >     > >
> >     > > ##PP
> >     > > it's too late now to change the encoding. This draft has several years
> >     > > of history and there are implementation shipping. Changing the encoding
> >     > > would cause the backward compatibility issues.
> >
> >     I didn't think I was suggesting changing the bits on the wire -- in an
> >     8-octet field, we're encoding the values 0 and 1 as:
> >
> >     00000000
> >     00000001
> >
> >     I'm proposing to change the eight bits to be specified as "the first seven
> >     bits are always set to 0 but should be ignored on receipt; the eighth bit
> >     represents the 0 or 1 value".  This makes it clear what needs to happen if
> >     there's a need to use any of those seven bits (an Update to this document)
> >     and also makes it more clear that there are not expected to be any
> >     additional AFs defined anytime soon.
> 
> currently the draft only supports 0 and 1. It says:
> 
> "Prefix encoding for other address families is beyond the scope of this 
> specification."

Well, that would seem to imply that even though this specification doesn't
touch them, there is a possibility of using this for future additional
address families.  So I think you need to say more about where it would be
in scope to do that work; this could involve making a registration in an
IANA registry for new family types, or a future IETF document that updates
this one, or probably some other mechanisms that I'm not thinking of right
now.

> Given that we have other RFCs where 8-bit field is used for AF, can we 
> leave it as we have it please?

There are ways to resolve my discuss position that do not involve changing
the encoding or its description, yes.  But see above.

(And it would make the discussion of how to proceed easier if we had a
clear and solid answer about whether future extensions should be permitted
or not.)

-Benjamin