Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

t.petch <ietfc@btconnect.com> Mon, 13 February 2017 17:40 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256D11296DA; Mon, 13 Feb 2017 09:40:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=btconnect.onmicrosoft.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 y7ig7kzcfCUa; Mon, 13 Feb 2017 09:40:39 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0106.outbound.protection.outlook.com [104.47.2.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F431129685; Mon, 13 Feb 2017 09:40:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZdAnYNtx5mbNvXlvN7VzqV2upcja6ead7Fp2ReP5n/4=; b=ci0SG71XyKXapABfcBcu5gnjyixscYYfAdD2XNX1OaD/OESJVZm4KsKAkP71VtH5wfFKb0x2SZWRQvi6iiAP5yZKWojVLnknMdJZH07TBi7im4gXjeJ7Vv2H5W/VhtJ4USIyOHfYlp3axhUdWEUCQgoy1d7ee5yR7XPvE3QX2uM=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
Received: from pc6 (81.135.210.62) by DB6PR0701MB3000.eurprd07.prod.outlook.com (10.168.84.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Mon, 13 Feb 2017 17:40:36 +0000
Message-ID: <00d501d2861f$ee827180$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Tal Mizrahi <talmi@marvell.com>, <6man@ietf.org>, <draft-ietf-6man-rfc2460bis@tools.ietf.org>, <6man-chairs@ietf.org>
References: <67ab3d39d55840c8a207e2104e6020cd@IL-EXCH01.marvell.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
Date: Mon, 13 Feb 2017 17:05:56 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.135.210.62]
X-ClientProxiedBy: VI1PR09CA0060.eurprd09.prod.outlook.com (10.174.49.28) To DB6PR0701MB3000.eurprd07.prod.outlook.com (10.168.84.138)
X-MS-Office365-Filtering-Correlation-Id: 68fba706-e086-4988-0d3e-08d454376b68
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DB6PR0701MB3000;
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 3:bavTtYTgN8SF0PW/V2ABmGsH+8GXnIKuAKyaIcHxZvni7y4Gty3KgK7JO0ReLXJ0AT1RegeeEWYLknxLKQPRE+b0MfIKRUjpwNLqT1WOJYWyzNFymPEo/JAHMq0Vw2G0aVXX5wVDQ7ZPfRsxoNH1wn9yDRJ48iLxJgPQI2jNxsd+UTWFvDnEvbGRavXZTP6dy8y3OJfo0KKfzSHLUSwmd+lRyygKusl3K1oa8UZF1DHqlSd4EnAu044mRIvy28sEzr4LcDrnoh9IFvJ4iUO+lw==; 25:JBcDuDaN5KgedhdM0pxxEjx8jdlfF7ok9r5pH8VpfsiJAZUsDDwCFT2c2HbIJaMPBEeARRk+yy2gwmD4RngwniItyRTlg4+4vRyax1TK9kAkESxWYoe/fwE8smdICwsbMTIOIhbEvWKuhKBBqjhTnYcZdvd6GCZGisanIv8OURUmjBPkcyMnqfawNKKtaDBFREY14TCSqNHjLSTG8ehD5HNi34ovplkhhtDnNqTKhwG/NFONXCXk4ahlmWTYDYdQ+40jPxI7a9pZRiYDR9lBO4ADMY3gRIC+iq0SXHtZT7UQHRTDwa8pOpCSbhl+NtRQo5t/nO21sO2MCA9+6++xWScwhR5axOZZ5E55Bsln94N9RArRypa133P/VtKZKU1NTTuwZE1GTrHdANrf2+0miYpmnHBdlA+tloAJQ3QcjvtYrS3tRgl3fDKbsMGYGNylb7BtBXg7gA4lM3tq0oWslA==
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 31:DVH2V4S1PU86qoZM/AiBXU9uAi5xRavkQ642L5SnzbvObbxVleom2pJRqpuCUTwn35a39D7U1FNOzYiO5oXDrMYWHlO/vyxwiJlysYrV6j0ceVhi5z1OAw7TktYqvArlstfmwZwzCSjVMzWO3+RAU32+bQoipKSkhsk2inVY1bZKrZhWOFVwZ3vm5+iDK2nOK2rvMw94+XwYA0HR3SVNZxS17EQo6BPtKfLkIqqPxSo4yBFaww6l+Zn1kXlGloN4k6cRsalGYNQfsz2Mj+Clz86CaBQI8K6aynYWn+mosGw=
X-Microsoft-Antispam-PRVS: <DB6PR0701MB3000E5B1C2CEC195D48CD2DCA0590@DB6PR0701MB3000.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(100405760836317)(95692535739014)(17755550239193);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:DB6PR0701MB3000; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB3000;
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 4:b68ptHQJNq1TEmr7cK9XFBGtwVJPpfvp/ysTUPdkw9b9Xu2DRzxnCwFuhYTVYU6leM726g0NlqbSdBTWoRr9Tq8gOgCnKMmp8IFJkuJGNFZWr6QAg52ke+oFwOXC7eJwfbAlQkj+ZlleJQ67jBBo9OKjmSHn0Z626vfWmLflegQkSif/InnTIOevpx3O+i1Y8vl6XNaieGMBDdJHU1t66e0gJY6gjr7Rg6zZmSuaJKjv4p/6TCO/3/9/KACFGESzO5eTIrSPYXDdgKL987sW5rWn7MjXqzsR0T4K/DjMg317AY7zsBnnj3zwdd1aiGZ807XCpSCU4pn0N2IdVmdyu6FdFzDRpkXScP+lh9In0Gmh5ULq6forcvmLiLa/t5Q19w3J5wOa7Z/+CWB1U0x4/oo80mwr2eHkkNgR3SVZ8SA6TNWeKF0SdOQYndjQOZ2njldiRJg/no5IBv/4Bjz4LoBXH13GPZjkBpeshHGdWw+eCaYHTAiRNqdDIVjW9sAlIVuVg0wtQRjKcqcmUCDfW0QyK9N+DP9Yv3Nq1x3O1f6E+jL7CxujpIPWeapNSz9xQtKw9Iyy4Z0OTailM1waUw3bm1dIV6mBkEtstxr1pcKjfQ1oDepSgwB/M8o/gR9X+ZIbTgaJ6m2gaO3Ls/+AQ4AxVnhs4sK6Yat0uo8r4tzIz4wjg+8T25/V+wC2haH9YyFH5aUBt5dQgm+YygE40kusde0JA8ky4dbadFis5To=
X-Forefront-PRVS: 02176E2458
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(24454002)(13464003)(199003)(189002)(377454003)(8676002)(2870700001)(97736004)(54075001)(50226002)(81156014)(2906002)(81166006)(62236002)(7736002)(38730400002)(42186005)(189998001)(47776003)(5820100001)(6496005)(305945005)(44716002)(50466002)(81686999)(9686003)(68736007)(81816999)(6486002)(76176999)(50986999)(44736005)(84392002)(106356001)(61296003)(86362001)(2201001)(25786008)(101416001)(14496001)(230783001)(6116002)(1556002)(3846002)(92566002)(105586002)(33646002)(229853002)(5660300001)(6246003)(53546003)(53936002)(6666003)(4720700003)(116806002)(66066001)(23676002)(1456003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB3000; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjMwMDA7MjM6VlBDUFNPd09BYzhRZkxkckxxeVF0NGdG?= =?utf-8?B?WU1kbjczTUhtaHRTU0tsV3g0NEhIWjQ1K09VTEQ4RGtudkFaM0wwdklFdUpI?= =?utf-8?B?dzdTc29JV0tkME9ILzBJVkVKb1VwNDdON3hLWk5qY1QxTVJRNUZRY1VPRUlD?= =?utf-8?B?VU1nNFpLWWwvUTJ5UnM2UDlMaEtGRU0yOWJobmUyWHBqS2hSREN6NHJ2dUJT?= =?utf-8?B?ejNkZmVBYnBDL3ZuR0l5RjVhQXFtelIyK3dhUVI2bnU5a0xvaGtGVGpvRmpE?= =?utf-8?B?Y2VEWk5XSGVuZ2YzRnY3TDV6N3NiYkl1ZEpBamhhUTFyQ1VsTWY3c3NHVEVL?= =?utf-8?B?NXZTMmduem1heDhSUnN0QWZTdUFrQXpkRmxPcU9nWGR1aFBOc1NkbjJxSVhF?= =?utf-8?B?RzQ3bE56S21CTjRlQld0bnZCb05WOHBrVUpoT0tMbGExVmp3R2Nub3p6aTBa?= =?utf-8?B?MUgybHZnNmdFbzMwY003a3lBMm1YU2pzV1MvZ1lvRTQ2Z0FzTWwzYjZSZG1I?= =?utf-8?B?RXpPSktlbS9zeEc1UThWTG03aG9KOGFLRnBHRnBQeUhjSW1RNDFPSXkvL2h1?= =?utf-8?B?aUs2aEw4SmNUaGgwZCtGZ1JxbVcxdkJ4RjB0cCtEYUlkZmh0d01ZNkxaVFRO?= =?utf-8?B?bmhBY2QyMDBkZUs0dE5DM29naVdLcVlDQWk4TlZYOFNvVjVSaDZjekJ6MXRi?= =?utf-8?B?MkZqdFpyZFZGV3FVcHBpK29DaTRCdENMa0lFamZreXRNaDVkRHBKM0VqVFND?= =?utf-8?B?eSsxc3dJamo2NGg0M0UvZTJGME83WTUyUGNKM0IzRkFacXZ5M2xOdHA3ZVo0?= =?utf-8?B?c1krVDdZK0NoYUQzcGxlVmV6a2R5UHBSc08wTm9WUmgrdkJaV292VDl2TEFT?= =?utf-8?B?RG5ickpuRGRsbDZrWFZXSXBFRlF2bDNzdFAvcXkyeW5YRTR2UUVRa1RPTW5D?= =?utf-8?B?aGYrWFp0dzdsa3RxMCsxZUJPbFYvZnBXVkpRSTZLaXpGc0I0ZWVHU0lBYmhI?= =?utf-8?B?ckFZeXFMd0RZTDhJRXlpRk5DSXVPRG8yOXVSVmIxTFVnRzlUb2ExZ0Q1RzFL?= =?utf-8?B?b1JqN1l6dnYwcHovSG9yWHM2SWUzdWZiOW9IVndSVDRETTQ1YUo5Z1lVSkln?= =?utf-8?B?V2xEOHVwNWo5blBibWdlRGkxN25iVHpHdlVaclp2bEkzQVprVUpwNzRVRG1V?= =?utf-8?B?dHZzR0pnMk9aTGZpa2JYQTZtblV3bkVWRk0vMVM2dlRBU3ByZlpuRnFmamhp?= =?utf-8?B?S24vcU1UcTRMOU96MVlKemluZ0pkYWpTN1FNc2NVMVkzMVhTWU5XcTB3U2Yy?= =?utf-8?B?ZitjMXhpekwxY1MySGlwbnd2NzlhQWh2TVJocUxXUDFjYmowdDVHekVTUWRR?= =?utf-8?B?b1BTM2JHM0R0WGlydXI4bDdVcXRGVUN2Ym5GVmJBUjQ1UU9QRjJGTCtWSW1z?= =?utf-8?B?VkdYVXU4emdxdzNVV2w2Q3duT2MzTjhaQkxxclhYWGpqcWJCMTA0WEUvY25S?= =?utf-8?B?Tzc0cDFNYU9ObHVyWTRzcmN5SW5QQmhwbytCbHMzWDB0SEUwSTZSK2l4K0Zs?= =?utf-8?B?M3FsczQrQ0ZPRWVxanMxRlRjd3F3SFUyNFdHbXpRTFpvWVlXNkpYVWgyTENy?= =?utf-8?B?WjZ2YjlFbU9HbzlkNTVJMFM5OEFqdXJmWnZLZlp4d3hPRVZzVHIrNVFhM1J2?= =?utf-8?B?RGVOQnRyUlRwTlZoRWtra3FxbDl4MHRwOUkrTGl5bmRpVFp2ZUNjT2dMdXZK?= =?utf-8?B?ZVFkSkxEZ0xZWkpLdngyMEtEOUVXSUo0Rnd4cEoxZlVqNzdKQmhueDkydXB6?= =?utf-8?B?aEs0citEZ1NXbE15QXpHWHRhekovSzBmY21wY2c4dEhpUXhWV1JkdkhuYzJN?= =?utf-8?B?VXZlUGpqWTloWXF2aTZERGtOeEM5VzgvaUxUb1VOQ21wcWduZHlMQkhHdXJF?= =?utf-8?B?QWlVUlM1dTlWY1l0TlVPOVBwUWM5L2NYaVBMQTJvOUZONFcvMHA0Qi92eEJh?= =?utf-8?B?T3BjKzJHck9kQWNsOFgrVUpwR2FMRWhIYSsrc01BPT0=?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 6:tF4hOwcCGWHeGn0GAla6RxeOPA2vAGABxNNv1DkmVLCL/TKMNjqQRUbzEqlrscFnD2OJPKhei2f4HYNObh7FVAFmx9/S0dZKemaXJFDGsVr3mxfba4cenqpdEnCoNAf0quXcJpryWllpMQ+eufQaEDmx1X1qHRrq9ITn3cE+/0F5yyDTb1s1PSR5zeh7I7UAL/UHjRD1d/oeZqh4rIk1M40AU2ebb7+hPrGDxM9BDcAGBzyntcYJWHeawb8mxrrgld1GYkUeWd9npX09gwQpYBgef7Gf7X5yKrghgtU4St6k6xQMdRsgI+B5V0WklBGSwf0qZvwRsvflv3eZU8uBpXL/LWfeh+O4tTyZXgBgBCYxNgrdZAaGufYExkjXcgWet1bt0EEUeljM3aO+yCI1mw==; 5:tWLzfmh+f1TH+334KxlgOI9DE8GDpYIJnlfT4d9Lt8oL/uHrIpnXetjCdzzOHrsA0H0H1/FXhVRCadEZfNVW494s4QJq9zwAPJfrov84SbwILMdpiCltV8EjPSH34FnhFJbs9audvhW+zLPqewPoOw==; 24:+njYJfCywGVUfPwFb4x4Kv/M4cSpNibBXa/gJP8o+CSQX/hDagnvMAizBmIvdEjOTIXhUU40VCmrSOplwktORhbnGMBU2ROSa6BWKnOsJJ8=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 7:ohjhC2UiRq9GSZSGY/Y9tIs3yhVD8hKDuA0jjEHMjceij8BMIwkzvgLd6rqcBkN21HU3OQcbleY3WFi3g2+YJIoUU2UvHzxaM/yq5yU1uWV/4TMLkZ9EzSebFPrFFvKZqNdxiO4mLn4bnfGPT9m41b6HTDNFPbyevr4p0F4yFoyaGqXP6kO83NnrGGyDM6zk4c8r3zAJ82MikoMC2UQYVP04ZFIIPaROZWR0kU0UdA5kPfOq9PZkPNcp0XLFHrb7vLcDIbd9i3ovg+0fVdXnWZnSx7ocacossU21zu7EGnkAAPv91UGV6ASdXTud8XWfwi+ruJzudJ4PeUMkAQbQqTBba74GjouAoRrDXnDiZGldHMrUNcWCMfDoqa2TuwkvJGrg+g7MEErHSc0PnPJA5eXjV1jXXHXnRdNXbDZ2WX278L0/w/wtaJoPgqEfhsWzjw62hYWaGb//iz3XdRxr7RyLzuDLPMgIoXBL9W3Yu+r5h4D252+LzVNKo6IFkm49gaUy2LaEFJDOkzwUiqC3+g==
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2017 17:40:36.0892 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB3000
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Yh2dORdo2Egj6vMvwcut-UZqtKI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2017 17:40:43 -0000

----- Original Message -----
From: "Tal Mizrahi" <talmi@marvell.com>
To: <6man@ietf.org>rg>; "IETF Discussion list" <ietf@ietf.org>rg>;
<draft-ietf-6man-rfc2460bis@tools.ietf.org>rg>; <6man-chairs@ietf.org>
Sent: Monday, February 13, 2017 1:43 PM
> Hi,
>
> Good discussion regarding the text about the hop-by-hop extension.

Most of the discussion I have seen has been about the text about
Extension Headers, not about hop-by-hop specifically.

That is, the question is should anything at all be allowed for Extension
Headers by way of processing (sensu lato) with hop-by-hop being the one
and only recognised exception where processing is clearly needed?

WG Last Call said yes, or at least left the text in the I-D ambivalent;
IETF Last Call is seeing if this ambivalence has the consensus of the
IETF.

Tom Petch

> In my opinion there is a valid use case for intermediate nodes that
insert/remove/modify/process hop-by-hop extensions. Examples: IOAM, INT.
> Since there is a use case, I believe we need explicit text about
intermediate handling of hop-by-hop extensions.
>
> This [somewhat] reminds me of the discussion a few years ago about the
IPv6/UDP zero checksum. The WG ended up defining that “Zero checksum is
permitted in IPv6/UDP *if* [……..] and the possible consequences are
[……..]”.
>
> I would argue that regarding hop-by-hop extension handling we also
need to define that “Hop-by-hop extensions can be
inserted/removed/modified/processed by intermediate nodes *if* [……..]
and the possible consequences are [……..]”.
>
> Cheers,
> Tal.
>
>
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Smith
> Sent: Monday, February 13, 2017 3:52 AM
> To: Brian E Carpenter
> Cc: 6man@ietf.org; IETF Discussion list; Leddy, John; Pete Resnick;
神明達哉; Suresh Krishnan; draft-ietf-6man-rfc2460bis@tools.ietf.org;
6man-chairs@ietf.org
> Subject: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt>
(Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
>
> ________________________________
>
>
> On 13 Feb. 2017 11:40 am, "Brian E Carpenter"
<brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:
> John,
>
> On 13/02/2017 12:05, Leddy, John wrote:
> > I’m trying to understand how a ban of this functionality would work.
Is it targeted at vendor products, precluding them from implementing the
functionality?
> It's targetted at interoperability across the Internet. We can never
stop
> people doing whatever they please inside a private domain, obviously.
> As always, there are no protocol police.
>
> > If there is a technical problem that can be solved by using EH
insertion within a domain where there are no harmful side effects, it
should be able to be used.
> > In a software networking world where functionality is being deployed
that is not from traditional network vendors; solutions that solve
problems efficiently will get deployed.
> We had a lot of this conversation in a slightly different form prior
to
> RFC 6437. It proved impossible to specify "local domain" rules that
could
> reach consensus. I think we'd have the same problem trying to write
rules
> for header insertion/deletion within a domain. But in any case, that
isn't
> the target for RFC2460bis: the target is the Internet.
>
> We also know that this statement from RFC1918 hasn't been 100%
effective:
>
>
>
>    Because private addresses have no global meaning, routing
information
>
>    about private networks shall not be propagated on inter-enterprise
>
>    links, and packets with private source or destination addresses
>
>    should not be forwarded across such links.
>
> and we still don't have enough deployment of BCP38 which would also
help enforce that.
>
> If it is possible to plug a device into the Internet I think it is
better to assume somebody probably will (and you won't be there to stop
them) and design to that assumption.
>
> (All the recent "IoT" botnets and corresponding attacks are a result
of assuming those devices will only be connected to Private Internets,
and therefore they don't have to be individually "Internet proof"
(conceptually similar to a "water proof" watch).)
>
> Regards,
> Mark.
>
>
>
>     Brian
>
> >
> > John Leddy
> >
> > From: ietf <ietf-bounces@ietf.org<mailto:ietf-bounces@ietf.org>> on
behalf of "Eric Vyncke (evyncke)"
<evyncke@cisco.com<mailto:evyncke@cisco.com>>
> > Date: Sunday, February 12, 2017 at 3:56 PM
> > To: Suresh Krishnan
<suresh.krishnan@gmail.com<mailto:suresh.krishnan@gmail.com>>, 神明達哉
<jinmei@wide.ad.jp<mailto:jinmei@wide.ad.jp>>
> > Cc: "6man@ietf.org<mailto:6man@ietf.org>"
<6man@ietf.org<mailto:6man@ietf.org>>, IETF Discussion list
<ietf@ietf.org<mailto:ietf@ietf.org>>, Pete Resnick
<presnick@qti.qualcomm.com<mailto:presnick@qti.qualcomm.com>>,
"draft-ietf-6man-rfc2460bis@tools.ietf.org<mailto:draft-ietf-6man-rfc246
0bis@tools.ietf.org>"
<draft-ietf-6man-rfc2460bis@tools.ietf.org<mailto:draft-ietf-6man-rfc246
0bis@tools.ietf.org>>t;>,
"6man-chairs@ietf.org<mailto:6man-chairs@ietf.org>"
<6man-chairs@ietf.org<mailto:6man-chairs@ietf.org>>
> > Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt>
(Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
> >
> > Suresh, Jinmei and Fernando,
> >
> > I fully agree with you Suresh, the goal of an IETF last call is to
get NEW discussion and to re-do the lengthy discussions we had on 6MAN
WG.
> >
> > -éric