From nobody Thu Dec  1 02:42:27 2016
Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9BD129C7A for <idr@ietfa.amsl.com>; Thu,  1 Dec 2016 02:42:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.845
X-Spam-Level: **
X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
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 GegkiLYlvAn3 for <idr@ietfa.amsl.com>; Thu,  1 Dec 2016 02:42:24 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 10056129C9B for <idr@ietf.org>; Thu,  1 Dec 2016 02:41:41 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.1.130; 
From: "Susan Hares" <shares@ndzh.com>
To: "'idr wg'" <idr@ietf.org>
Date: Thu, 1 Dec 2016 05:38:34 -0500
Message-ID: <007501d24bbf$11a41b50$34ec51f0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01D24B95.28CE6170"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJLvuE38XB8UIsiReWRPWoGgtwL+w==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xTDIaeJVpEdk72o0P_QbfRtss1I>
Subject: [Idr] draft-psarkar-idr-bgp-ls-node-admin-tag-extension - 1 week period to comment (11/17 - 11/24/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2016 10:42:25 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0076_01D24B95.28CE6170
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The IDR consensus is that the IPR on
draft-psarkar-idr-bgp-ls-node-admin-tag-extension is acceptable.   The
authors should submit the draft as:
draft-ietf-bgp-ls-node-admin-tag-extension.  

 

Sue Hares 


------=_NextPart_000_0076_01D24B95.28CE6170
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>The IDR =
consensus is that the IPR on =
draft-psarkar-idr-bgp-ls-node-admin-tag-extension is =
acceptable.&nbsp;&nbsp; The authors should submit the draft as: =
&nbsp;draft-ietf-bgp-ls-node-admin-tag-extension. =
&nbsp;<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Sue Hares <o:p></o:p></p></div></body></html>
------=_NextPart_000_0076_01D24B95.28CE6170--


From nobody Thu Dec  1 10:11:58 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A441293FF; Thu,  1 Dec 2016 10:11:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148061591478.3056.16701619790365176110.idtracker@ietfa.amsl.com>
Date: Thu, 01 Dec 2016 10:11:54 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6XGjPdftY712QCCWrGgimeOGMIQ>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-node-admin-tag-extension-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2016 18:11:55 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Advertising Node Admin Tags in BGP Link-State Advertisements
        Authors         : Pushpasis Sarkar
                          Hannes Gredler
                          Stephane Litkowski
	Filename        : draft-ietf-idr-bgp-ls-node-admin-tag-extension-00.txt
	Pages           : 11
	Date            : 2016-12-01

Abstract:
   This document describes the protocol extensions to collect node
   administrative tags adevertised in IGP Link State advertisements and
   disseminate the same in BGP Link-State advertisement protocol, to
   facilitate inter-AS TE applications that may need the same node
   administrative tags to associate a subset of network devices spanning
   across more than one AS with a specific functionality.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-node-admin-tag-extension/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-node-admin-tag-extension-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Dec  1 10:47:05 2016
Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4183129410 for <idr@ietfa.amsl.com>; Thu,  1 Dec 2016 10:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 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_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 jbTtkww5wFiq for <idr@ietfa.amsl.com>; Thu,  1 Dec 2016 10:47:00 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0102.outbound.protection.outlook.com [104.47.36.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B2C129538 for <idr@ietf.org>; Thu,  1 Dec 2016 10:46:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vIFY8dcbUyeJ6de6FUzY8dPPQzrW0nzNxk7SK4uY2nE=; b=OLq/ozHGXndj+kkPqfWTIbtQ2JLnNplA84NVCybRQzSijegTWPpOIj2AJkDNBB1CCPDLgZyoS8bQjXp9XYr+EDr133Froj6CVs31SsLpspLVpv5oS5vJ1glwVwwbTSYkzHYmDxxDkyyimG5+CG+usm0pHgtWKXOwcPHVKKX4LJ8=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.33.83] (66.129.241.12) by CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Thu, 1 Dec 2016 18:46:54 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <E6AD17BC-1073-4E6E-9E7A-390C61AA07E0@juniper.net>
Date: Thu, 1 Dec 2016 13:46:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <97E1EB1D-741D-4771-95BF-A3691A65ABCB@juniper.net>
References: <E6AD17BC-1073-4E6E-9E7A-390C61AA07E0@juniper.net>
To: <idr@ietf.org>
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: BN6PR08CA0071.namprd08.prod.outlook.com (10.172.144.33) To CY1PR05MB2508.namprd05.prod.outlook.com (10.167.10.135)
X-MS-Office365-Filtering-Correlation-Id: 2f5796ec-03aa-4816-64b5-08d41a1a6c26
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2508;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 3:7GdAcnifw+Jrl70MFbGQ0AdolDkCUIw+Mbu48fFrg42G7/KHsRuQjkxzKAyHZPNaSIfxvQ9Q3k+oWM6f1j960T/rJGMOBN5/h+ws8l0jk6lXEMf5Wve99B9qnbUVor2S/6EKSNsj3OlQfCEUi7uprLcqq/Dq68ohLqHurwQWQ5VZDe8lDW+uXqFOBvGWYJts5KEo1FxRgvpusweF9FFFrMaFIwAnycYEJOa51wGw7+AkfIKG/WCankbfNG2T3/ZLN2Sv780X55rEmyqjekfMyw==
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 25:pipeXoPxKLdGhKsWeTAAM8FP4gwrBsyfY2Yx8W0RD6cXhBnYpz7mHfn4R780iMHJEPtAtCsXH1dxRt7TsIC8Q/O5Tyw8hw8wHUVtwYG8cZ3gPpQHEo+Olv6z3iaivp/DBdXPyFIxMnMmY5sJmrg3VlKJS8Tvp6vkQqxTnvM+lC+YFSYoldTO0n1DE5st/TZoe5lVtS8ELX8d7mjwEBzxfF7i6KJ8iOwSQzQJZ5epGcuMcuGrnTim3AezqKbyIdFPAHJv8l91Nshu6nXni5jvI6zEGBCiTwniriuOjgQ+8BV3sMVmitMuyDBH6rmvI97qs/fIQO0UEp2uLTyHVE0Kpg8scU1KPgF0t21u2lMwCWOA4+EoxzsZcYzCY5kfWZ2LAwEKmITgCzi2BAPP7lZYEpnYp/q3SU8Hd3qu7O/FmVpogJeoLRvkZEmTdyl9yNrnybdAczD7ZO8T+mvYm7Ws84TD/5ysCcA/6lsDNbEk+SxsVXTpkbpOgcHiL/9Qh/Q7K97o2yGXGfd48Uu2ut6gempoWwvwuPcYOr1aI+phXdPHnIwNVKdPW9aNztdmm+WhLEs4kt7TbJ+01H4Kp99ani2rB0My9hn8Iig9xSyvK6D4OhVeeOUXzGRN3cKlK4gzqRandpQaHi63/wLmdCEcIUzDkHmk6bqEP+mZsSRiEs5sh/WcLWblvPRiuqvqi6pKo0CNLLOObGjdwvy3SqN+6mUJs/ZdHEQIX0+u4dhZh9qAK36zQY+7/MBwmHlt+rxx4Rt/jp+ZhEyUnp4+jaXnn6syYMzeVfl/KLenpjdIFFSHWEogd5YK+NlD53mPyDLFq4ECNA4Siw6KSOjKtK1pZw==
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 31:NdYGFR1UBtwk6xLKhJZEiDx957IiE1r5y8erNEObxj9HjJhEVmuxK+d5MdUZ+AM577UGaV6c9Ey6t+NAUZEkTG6OPyu7Bgk2P8Ivex10G1hQEmFPByd/kculvAyXdGvWulD+Skh1yTJ2KLQtU1uvDkSTz7+X1GZb/XzHCTVgje/DZV6RbwSauz+pzDtpB2SFmGATc2HIKZP/0mj3ZESL4dqVaclhwMwLhpRz7Ryj/VBrMGEzOVU7Sx2VAWuFqK2prm95svJjD69g9K2t1U2+nWqErG/MYgvlMtl7AjitsZw=; 20:zCPMtBCkRGTzDla+D3X9f3LdfUiOcVfG58sarQmxy65y9Q8QHoKCic5TZakknuRfZiyGv7CF2M7fDpk42naSxIBbYo1fBKZqk8qh92BbD5Tvyu5aND7ey10C0wYGRO7l3F6oymSIqbEtvJ7AExkn1h7OZ14ytevB8JAW9ADwgmbtb29LqDnopMA3RvSYLeFEW4eE/6U89+NFxzJcf+TSWtOo3vWGJ8RQCyC45ifNR1hO+y5O7toYAIwcUP2iBC1V9I61vncBNgb+J9B102mIxeI8DqmisvX5poEcTagRzT6NSPt7khgOpGWVpKk/ElImyDv8YbHIaIIKWhAcjHAV8mv5r8DneqN5pwV++INujHoOomZU3m1NQ4ZagRcIkOMdKE+bIoz4MZ5SRtwlvJN2XH2gqO/SHvS9jE0a7bICnNs/ZeZPCb0CKeD2jlw5vQC/9vOst9aFWBZ2Vzf7w2k3p0a327MbU7A9fMTwd36yluK8t+caNYB3VxnLTfldyEBi1K99RYZ25Rk9BbkblHIdwghWy2Irx0VJ+KAj+JbW0LIVl2NMRU7vgZchJna3ZKgJL+MZCCXrmoo7A+jhWWi7cNYFNIoQuuUN2tLZhEMZesw=
X-Microsoft-Antispam-PRVS: <CY1PR05MB2508E9BCCC01F4AFDD795790AA8F0@CY1PR05MB2508.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:CY1PR05MB2508; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2508; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 4:r9df0BRCd/+9SQWO2OWiSkALkuT6v7PzSbCzEg1XiWMzK9i8qWj/W0jWk6gSoe5+/lukk0/k9IUPRKkPq0f/fDXJ0I3AlAMu6jolbQS7myAzdtWFT04xqXuepdqkUD98nwYGlAz1GcGvF8/gErPb5N4jdICYi1OXPaBzz07r6ssb1PswDAZeiOotXfGd//Cf2TcXHq6MsfbeaVuv7UYhWBu6sfAy0aW8+to32VqC8DGPhx85P1wqO8oK223ymwf41Vd8kx/ozvce9UoRfWe/rNqHwaBxK9H4wOAbaEdp6cTd2wjH5tJAxaBIwM1pD2N90qRLISuuVkvojMBl6hCIPt+oUma/VhE1URxwjwZ9Jtbj0lVnRF2ARLFFmRImZX54sd7FUtCs8b0OL/A/ThLHY72bcu5DqLAe8W47UjwMQGkm3vgpt7QR5Ck7z/AybwQrDG9mUnEkNPpbugxDPEkhUjWj2Ir0lhKxChQHNam/FwvbX10NaHYeLV7M2UODJz1ktyOabBla4A0yVzxxTVaj7pgVwyGG32XPzk6nLACDmiEF0PLZuGrnlz8kqOGwfFIfCjwNXdafb6aEH+VFdbvxwU00h4nOpQ4tc06bTAvNgySjWFJXlGqBhpdXzVj8Hdke0LsFAzBcHyyYQnWLbKQly2m6NmMuxlA1TmYNq3Wtp44=
X-Forefront-PRVS: 014304E855
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(199003)(53754006)(377454003)(189002)(24454002)(5423002)(33656002)(8746002)(97736004)(68736007)(47776003)(229853002)(76176999)(66066001)(23726003)(230783001)(50986999)(101416001)(107886002)(7736002)(5660300001)(57306001)(39410400001)(38730400001)(7846002)(77096006)(6486002)(2906002)(6916009)(39450400002)(733004)(2950100002)(6666003)(97756001)(42186005)(305945005)(2351001)(86362001)(105586002)(110136003)(50226002)(36756003)(81156014)(50466002)(81166006)(189998001)(8676002)(83716003)(450100001)(6116002)(3846002)(92566002)(82746002)(46406003)(106356001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2508; H:[172.29.33.83]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2508; 23:L0lM1x8USRQqSPOZoezKcT/27NmXDJBHwMquaM9Lz?= =?us-ascii?Q?zBH9hsSecTtciIYQiqNMSot6H4smxSpkd+QDeypWpBzi4agQWFeP/gGuFHCd?= =?us-ascii?Q?GeHiN8RpfBRWH4zSuqsLloR8g/5W2D+1WZAPK8QKZXtYXrChdoA9mqQ9hpMj?= =?us-ascii?Q?9ta7wlC7soxut3gFVfqiajoYJbDnFqyhmc7MHNF3L+xut+pvCzmw3MsVWyaf?= =?us-ascii?Q?8T2W0kyNohWh9ifm12HrcsUstp+8CVibhn6+xC77N9rtHJ0TgnEOrwqPnbH1?= =?us-ascii?Q?wZhdgn+A6hNIWeprbe4SrlDeua62ZzuhbCdneHqFAjRfRQkxinXW+T5Vn/8H?= =?us-ascii?Q?rEkiB2HCGz1szIVIMJ7c1l5pjTaypJvwRlus6v81+DpzRyjbFbCkL/LyRKUE?= =?us-ascii?Q?OXwMa+6UwLibYhGyOxKpiV7LMI15s0gJ9pGdld0H+9R8n0Gmm4ZCKsOvxGvd?= =?us-ascii?Q?pBeqAM29ljW7UPvtpmpAyJ+nKEpJzXz5Vz+UlNGQLWJLzpMSvJF9/VyPLTwa?= =?us-ascii?Q?28RB8090HJOkJHExGM+6I+CVz8FIg/Mbab16YMa2GaWFCE6h0IS2ypYGPYon?= =?us-ascii?Q?qk2B38+/YhXwl5Nwvgk4o5o1IEP56H7eK92Jra2ITmZ8PFEFQ+6MBxi4wNo6?= =?us-ascii?Q?K/UbXeJxseF0sKiomybUzMvcZDJrXZctLRInw7efhNYOOn8hJnCvWKYZVsOx?= =?us-ascii?Q?/QM65huX5TRx+wgSNqzVHPaEIusGvtmt8cemxzGL+0ks1/kAYIkKe3jet9K/?= =?us-ascii?Q?68j6pz7cgLTFAG46Zf0fbe8YAoBoHLH+qBrdb0EbQR4lamv71oKFlFZeDfmw?= =?us-ascii?Q?AVoBBc6Nwb0LmbSiz1VopQ1e5vqwJyjeMSflK59yg5iCnKXMBC2frFYkMVYx?= =?us-ascii?Q?X/S+2wWDzzzP72r0otAc3alsvnPIY83gjkCOc1R1SC1wYcw1l3AyrgxD9qyj?= =?us-ascii?Q?VXVpfZtKbzI0kzlGtvYoeZzBb4xqxHXoJwGI1NhJI++X8uLua3r8VZx6TAHW?= =?us-ascii?Q?pTSfhqtmXE7uBLB6Gf+aagUI4WyCm/Th+9zgQ0VfQbf4CHS+Zn5YB2N3iDox?= =?us-ascii?Q?CeS0uaErj7dA2dIPVJ4RUHUEzk+g6ajaPgPHU10r+1XOaHpybRDNZvDHv+Xx?= =?us-ascii?Q?8KY4/MAzZiHftY1FQmtEBqZpNAp/ArdLIYd7fq3BF5E+pA42xVpmEvdOYy14?= =?us-ascii?Q?qrgpsl/BJb0wTDMpDveV8h8axw5/zgiypp1Mpgk3FEStAMpabjQ9Uo4Fb4GE?= =?us-ascii?Q?J+G5G6k7QVY+O+NQmXFGb0cY13wM/nGYKRSnYSgtcO4nTm4pnUXGp5YW9SlF?= =?us-ascii?Q?+aiv2kIlnCvqvXNILOT0BZ7i4m8/dgF4Qqiu/hcssNgr80/4D4hUTpWH+g8W?= =?us-ascii?Q?mSNYDbau19A94qjawF2Funs7TwcDM1YuE17Qtn+5ix56Ov/Gx6cizOFFEFmk?= =?us-ascii?Q?EZokj040lgmM5SpIr7CyyTVWPunUUM=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 6:mk5DoOY6hg1h+LxXsvBoq7whGhZpXMwpz85by+qVZ4EWGs5SL3SOy7L8/yOtlhJAP3ro2NGNFEcDN+OCxZp1RWfD7iV8MSx9Cyn0hPhTWUcjdBq5wKwmQLkSubqzqQfJaNtOT00R1ZO0nTdwHmh8G3O6s9nRLhPCH1siJndzm+8QoazOQysG/vet/CH006LVoJdDq06wJS0OR8+F4SU0WKPyuMQhL86GUkOlGKhzZqCT/c//tYOSwiduyl4GVIUvkHMU39kVBTFD/8AKZxeXnfPoh/pCFwb6bSCV8yVUM3Kq/Eg3vihyZvvwTVSwXb5nMEVaqoplEDrQgfSAy3RCSalPARXQfX8EbwtJzHHuESsZUs030FuDgGJYFUpgGPTDl4vuKQZkcLfB8ddhIP8mUz/VjwG8iP9K7WjoSheMe+5ihdA9ZWd2kYlZkOWvXeiO4+5GgYBZh7uucOjGeGdUD2gFcTbIzi7auorP8DEwR+c=; 5:L/togrqfpmOUSXr3oWuKUXZBSwY3uuU9xUnSk8OEuOt5DkErBIr79w+gxNAIBg2zVOXwIUfjrL5Yyj+u8ZPY8pGv/6uWdRMBaOzvly2FT2xcqF+uGDRHexHyvhBArmi4golnQUB0lrjQyOCB/bSf1w==; 24:1ovLoQEsbo5NPSI055MHrDCcGWPkb3grbW1jI4sReR7LzqsSLGQ7g8/gYGLRY3dP5RZJCX2Sg1pLx/O/wQG5BaRXFuyub+lXP53HgyFoFlU=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2508; 7:ch8Z8HJOdSyrFtPmZpNeCM5UbRKu5P/0NLX58btkn1Jux2M1UBy47j+C6rJOPbRJuSXaMM/i+ZoH8CA9sPuHkPtctS3kJbfa14JOqlFxqLffLNLsv+MvC0ostp1uRSnm3GGmH5VlydI1Fcvh2tE3s4E3WjR07Nszv8W3h5fbhnlVQjOt2RTbiSjlmvVy+tBD5AAWpmYIOrvVzHX3ovvbc1x829LxCISAqx6xACFQL80BEFUqigISvgGsZYr+AW0Vl1TBrWTjgCS0h8LFx1wjooyhvbxGFtxbV5SFyKXRvilZg1uNeDy7n0hFEZIvc72Va81qmisNBy5QYCJ/Y9qum8dL213WGzB+vWSgKIyS4CpQ0a022YJFiktEJqtHnqK9ea5/7T7sRoHdy7WAWwUYhjGNV9lmEDF+xr42yN9kqyJEfdyAKqxFtt+tnVDzX5tEWNzzIVEibgRz2SRfBJUpOw==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2016 18:46:54.8146 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2508
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/n9uh0oheX9UQCG50HQkO7ksGQvw>
Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-30-31-129-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2016 18:47:04 -0000

This WGLC has concluded with consensus to publish. We have forwarded the =
document for publication.

--John

> On Nov 16, 2016, at 10:18 AM, John G. Scudder <jgs@juniper.net> wrote:
>=20
> Hi All,
>=20
> As we discussed at our meeting Tuesday, this begins a working group =
last call for draft-ietf-idr-deprecate-30-31-129-00.txt. Please send =
your comments to the list by December 1.=20
>=20
> Because I am optimistically supposing this to be non-controversial, in =
interest of not cluttering up the list with "+1" I'm going to suggest we =
make this one "silence gives assent". If there is any objection, we'll =
revert to normal procedures.
>=20
> Thanks,
>=20
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Thu Dec  1 10:56:52 2016
Return-Path: <pushpasis.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97840129862 for <idr@ietfa.amsl.com>; Thu,  1 Dec 2016 10:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZcIny8T6xJtb for <idr@ietfa.amsl.com>; Thu,  1 Dec 2016 10:56:43 -0800 (PST)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 F1AC0126D73 for <idr@ietf.org>; Thu,  1 Dec 2016 10:56:38 -0800 (PST)
Received: by mail-yb0-x22b.google.com with SMTP id d59so32286155ybi.1 for <idr@ietf.org>; Thu, 01 Dec 2016 10:56:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AnOXxRUMnL0xfKa/ZPRGYSlzOH+WpBl7YrCloacTICk=; b=Usvv898YIiBR/U3kfW/JP4H0HhWDvFBHK69yr3QBe56SfBO2BEuN47094bUNWUK6QH 9KiskI2ewnZzqksGH527z1ovN+h+3QuLM2k0OzbrtosX7xPd0Y3/PVlW8JhQ/M3AgYeI 8phx/DbT878pEmYe9E/M6+dxrnw5YQUIGopa8HoZvSIRvuuK3EffrFIKcYD52KaTamdO mzAYytAvYnZYqia4MHuHapDJoQiOn3YQEUpomIMKvplh8Vb+G5Re9a+eAmmzBOkoDpcr EfdE3G0SaYNeLH9P4uUJA/3oz0g1LZ9Cj6LBflRevuRovNnQ5bpWF47pKAkb9lIwWjKu gFoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AnOXxRUMnL0xfKa/ZPRGYSlzOH+WpBl7YrCloacTICk=; b=CQ8Q4m9KftiklNFKnibD2h6LaQhlLjZPIDdj+/jOUnpGA26bAI51wqPcNquECPf9Rt 1AUqnPreiFrgRouCiMqCSjn6PtER6iN0Aq9FRjKdXI2T3STFzvdXF0QWsSiS4vWkairT 0BNA6WqxMsJWklB2Py0hCY9qNk6gXP6Ysw5A0HIUGrkeLeyPqpqElWyt+fSI2qeVVxcw ciWpdukqr9ANTzUYJUutJpkKTxGDbIZi9udebJILJAjJekavqU4q7cTZIyOW2NVuB0n1 bRYVK3pkC2AeSg2wkieOny7GKwjTVJxNmNRxrqOfiFnnRVgFiE98D+mf33wT/YDOV04V X5SA==
X-Gm-Message-State: AKaTC00mPrD9OEFjOcIeh9N+XzhJOtbnrBAYdkE9aph1VHg9CKGowCRwpcydGDZYtdJhMVUPNC4NVx/7jcbgCg==
X-Received: by 10.37.50.209 with SMTP id y200mr3632163yby.71.1480618598146; Thu, 01 Dec 2016 10:56:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.223.207 with HTTP; Thu, 1 Dec 2016 10:56:37 -0800 (PST)
In-Reply-To: <007501d24bbf$11a41b50$34ec51f0$@ndzh.com>
References: <007501d24bbf$11a41b50$34ec51f0$@ndzh.com>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Date: Thu, 1 Dec 2016 10:56:37 -0800
Message-ID: <CAEFuwkjwNdQcj=C3JrKt8LTAXsP6Su4_S2Mss+CeCf3bDasqog@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a1146dcb8972d6205429d6106
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/v1kH5DjY1E-MZGpo3F9MOpRSsMw>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-psarkar-idr-bgp-ls-node-admin-tag-extension - 1 week period to comment (11/17 - 11/24/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2016 18:56:45 -0000

--001a1146dcb8972d6205429d6106
Content-Type: text/plain; charset=UTF-8

Hi Sue,

Thanks a lot. I have uploaded it as
draft-ietf-idr-bgp-ls-node-admin-tag-extension.

Best regards,
-Pushpasis


On Thu, Dec 1, 2016 at 2:38 AM, Susan Hares <shares@ndzh.com> wrote:

> The IDR consensus is that the IPR on draft-psarkar-idr-bgp-ls-node-admin-tag-extension
> is acceptable.   The authors should submit the draft as:
>  draft-ietf-bgp-ls-node-admin-tag-extension.
>
>
>
> Sue Hares
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>

--001a1146dcb8972d6205429d6106
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Sue,<div><br></div><div>Thanks a lot. I have uploaded i=
t as draft-ietf-idr-bgp-ls-node-admin-tag-extension.</div><div><br></div><d=
iv>Best regards,</div><div>-Pushpasis</div><div><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Dec 1, 2016 at 2:38=
 AM, Susan Hares <span dir=3D"ltr">&lt;<a href=3D"mailto:shares@ndzh.com" t=
arget=3D"_blank">shares@ndzh.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=
=3D"m_-4062948739384419734WordSection1"><p class=3D"MsoNormal">The IDR cons=
ensus is that the IPR on draft-psarkar-idr-bgp-ls-node-<wbr>admin-tag-exten=
sion is acceptable.=C2=A0=C2=A0 The authors should submit the draft as: =C2=
=A0draft-ietf-bgp-ls-node-admin-<wbr>tag-extension. =C2=A0<u></u><u></u></p=
><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p><p class=3D"MsoNormal">Sue =
Hares <u></u><u></u></p></div></div><br>______________________________<wbr>=
_________________<br>
Idr mailing list<br>
<a href=3D"mailto:Idr@ietf.org">Idr@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/idr" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/idr</a><br>
<br></blockquote></div><br></div>

--001a1146dcb8972d6205429d6106--


From nobody Thu Dec  1 20:04:28 2016
Return-Path: <aretana@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433B8129A8C; Thu,  1 Dec 2016 20:04:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level: 
X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 aJwYYB-lBuse; Thu,  1 Dec 2016 20:04:24 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4DD129437; Thu,  1 Dec 2016 20:04:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10626; q=dns/txt; s=iport; t=1480651464; x=1481861064; h=from:to:cc:subject:date:message-id:mime-version; bh=xci/koCLcjq5oSyLOv/XhJ8IoVbhdZVB0laQ3R2sq8c=; b=cKi6kcaMqT3AtlPUQR3h0Cka4HIpGGnoLz4SA4CrK+20/LuRfLT3iha/ p642vmH0LDi44C54j/HEYqz0MI0lnvUXrZBPAj0wsR6ddlPjD8muez7Mg qnb7tKjR7VprzNJl3ImNwDNu25RlQ+43WjlJudRbYFe1CVds4f1zPi9Cm Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQAI8kBY/4kNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNFAQEBAQEfWIENjT+mZIUiggaGIhyBcz8UAQIBAQEBAQEBYh0LhG8?= =?us-ascii?q?jVhIBSgIEMCcEDhmIW6wYgikvixEBAQEBAQEBAQEBAQEBAQEBAQEBAQEchj6Bf?= =?us-ascii?q?Yc+gm0tgjAFlHiFaQGREoFyhHyJS5IJAR83gRkxAQGDJIF+iAYGgSqBDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,284,1477958400";  d="scan'208,217";a="355678875"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2016 04:04:23 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB244M8V023787 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 04:04:23 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Dec 2016 22:04:22 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 1 Dec 2016 22:04:22 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>
Thread-Topic: AD Review of draft-ietf-idr-large-community-09
Thread-Index: AQHSTFEplUv+tL/kGUyk1NyWV0fUzQ==
Date: Fri, 2 Dec 2016 04:04:22 +0000
Message-ID: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: multipart/alternative; boundary="_000_CE1331E43ECA41D7801F05519778E8DAciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZnYZVBTDsmpX2JYAFgOkM3N7XL4>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 04:04:26 -0000

--_000_CE1331E43ECA41D7801F05519778E8DAciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkhDQoNCkkganVzdCBmaW5pc2hlZCByZWFkaW5nIHRoaXMgZG9jdW1lbnQuICBUaGFua3MgZm9y
IHdvcmtpbmcgb24gaXQhDQoNCkkgZG8gaGF2ZSBzb21lIGNvbW1lbnRzIChwbGVhc2Ugc2VlIGJl
bG93KSB0aGF0IEkgd2FudCB0byBzZWUgYWRkcmVzc2VkIGJlZm9yZSBJRVNHIEV2YWx1YXRpb24s
IGJ1dCBJIGFtIHN0YXJ0aW5nIHRoZSBJRVRGIExhc3QgQ2FsbCBhbmQgd2lsbCBzY2hlZHVsZSB0
aGUgZG9jdW1lbnQgaW4gdGhlIG5leHQgYXZhaWxhYmxlIFRlbGVjaGF0Lg0KDQpUaGFua3MhDQoN
CkFsdmFyby4NCg0KDQpDMS4gU2VjdGlvbiAyLiAoQkdQIExhcmdlIENvbW11bml0aWVzIEF0dHJp
YnV0ZSkgc2F5cyB0aGF0IOKAnER1cGxpY2F0ZSBCR1AgTGFyZ2UgQ29tbXVuaXR5IHZhbHVlcyBN
VVNUIE5PVCBiZSB0cmFuc21pdHRlZC4gIEEgcmVjZWl2aW5nIHNwZWFrZXIgTVVTVCBzaWxlbnRs
eSByZW1vdmUgZHVwbGljYXRlIEJHUCBMYXJnZSBDb21tdW5pdHkgdmFsdWVzIGZyb20gYSBCR1Ag
TGFyZ2UgQ29tbXVuaXR5IGF0dHJpYnV0ZS7igJ0gIEdpdmVuIHR3byBpZGVudGljYWwgTGFyZ2Ug
Q29tbXVuaXRpZXMsIHNob3VsZCB0aGUgcmVjZWl2ZXIgcmVtb3ZlIGJvdGgsIG9yIGp1c3Qgb25l
ICh0aGUgZHVwbGljYXRlIG9mIHRoZSBmaXJzdCk/ICBJIHRoaW5rIHRoZSB0ZXh0IGFzIHdyaXR0
ZW4gaXMgc3ViamVjdCB0byBpbnRlcnByZXRhdGlvbi4NCg0KQzIuIFRoZXJlIHNlZW1zIHRvIGJl
IGEgY29udHJhZGljdGlvbiBpbiB0aGUgZXhwZWN0ZWQgdXNlIG9mIHJlc2VydmVkIEdsb2JhbCBB
ZG1pbmlzdHJhdG9yIHZhbHVlcy4gIFNlY3Rpb24gMiBzYXlzIHRoYXQgdGhlIOKAnEdsb2JhbCBB
ZG1pbmlzdHJhdG9yIGZpZWxk4oCmU0hPVUxEIGVpdGhlciBiZSBvbmUgb2YgdGhlIHJlc2VydmVk
IHZhbHVlcyBhcyBkZWZpbmVkIGJlbG93LCBvciBhbiBBdXRvbm9tb3VzIFN5c3RlbSBOdW1iZXIg
KEFTTinigJ0sIGJ1dCBsYXRlciBTZWN0aW9uIDUgc2F5czog4oCcVGhlIGZvbGxvd2luZyBHbG9i
YWwgQWRtaW5pc3RyYXRvciB2YWx1ZXMgYXJlIHJlc2VydmVkOiAwLCA2NTUzNSwgYW5kIDQyOTQ5
NjcyOTUuICBPcGVyYXRvcnMgU0hPVUxEIE5PVCB1c2UgdGhlc2UgR2xvYmFsIEFkbWluaXN0cmF0
b3IgdmFsdWVzLuKAnSAgIElPVzog4oCcU0hPVUxEIHVzZSBvbmUgaWYgdGhlIHJlc2VydmVkIHZh
bHVlc+KAnSBhbmQg4oCcU0hPVUxEIE5PVCB1c2UgdGhlIHJlc2VydmVkIHZhbHVlc+KAnSBjb250
cmFkaWN0IGVhY2ggb3RoZXIuICBJdCBzZWVtcyB0byBtZSB0aGF0IGJlY2F1c2UgMCwgNjU1MzUs
IGFuZCA0Mjk0OTY3Mjk1IGFyZSBhbHJlYWR5IHJlc2VydmVkIEFTTnMsICphbmQqIHRoYXQg4oCc
dGhlIExvY2FsIERhdGEgUGFydHMgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlZmluZWQgYnkg
dGhlIG93bmVyIG9mIHRoZSBBU07igJ0sIHRoZW4gb25seSBhc3NpZ25lZCBBU05zIHNob3VsZCBl
dmVyIGJlIHVzZWQgLS0tICphbmQqIGdpdmVuIHRoYXQgaXQgaXMgbm90IGFuIGVycm9yIHRvIHVz
ZSBhbiB2YWx1ZSwgdGhlbiB0aGVyZSBpcyBubyByZWFsIGFkdmFudGFnZSBpbiByZXNlcnZpbmcg
YW55dGhpbmcgKGFnYWluISkuIFN1Z2dlc3Rpb246IHJlZmVyZW5jZSB0aGUgUkZDcyB3aGVyZSAw
LCA2NTUzNSwgYW5kIDQyOTQ5NjcyOTUgYXJlIHJlc2VydmVkIGFuZCBqdXN0IHNheSB0aGF0IHRo
b3NlIG51bWJlcnMgU0hPVUxEIE5PVCBiZSB1c2VkIGJlY2F1c2UgaWYgYSBTcGVjaWFsIFVzZSBM
YXJnZSBDb21tdW5pdHkgaXMgZXZlciBkZWZpbmVkLCB0aG9zZSB2YWx1ZXMgbWF5IGJlIHVzZWQu
DQoNCkMzLiBJbiBTZWN0aW9uIDY6IHMvR2xvYmFsIEFkbWluaXN0cmF0b3IgZmllbGQgTUFZIGNv
bnRhaW4gYW55IHZhbHVlL0dsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxkIG1heSBjb250YWluIGFu
eSB2YWx1ZSAgICAgVGhhdCDigJxNQVnigJ0gaXMgbm90IG5vcm1hdGl2ZSwgaXQgaXMganVzdCBl
eHByZXNzaW5nIGEgZmFjdC4NCg0KQzQuIEEgTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkM0Mjcx
IHNob3VsZCBleGlzdDsgdGFnIGl0IHRvIHRoZSBmaXJzdCBtZW50aW9uIG9mIEJHUC4NCg0KQzUu
IFJGQzE5OTcgYW5kIFJGQzY3OTMgc2hvdWxkIGJlIEluZm9ybWF0aXZlLg0K

--_000_CE1331E43ECA41D7801F05519778E8DAciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <9D917B1CFDD53E47856CC9BE2D3E6C75@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu
LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7
DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+
DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5r
PSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGkhPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGp1c3QgZmluaXNoZWQgcmVhZGluZyB0aGlzIGRv
Y3VtZW50LiZuYnNwOyBUaGFua3MgZm9yIHdvcmtpbmcgb24gaXQhPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGRvIGhhdmUgc29tZSBjb21tZW50cyAocGxlYXNl
IHNlZSBiZWxvdykgdGhhdCBJIHdhbnQgdG8gc2VlIGFkZHJlc3NlZCBiZWZvcmUgSUVTRyBFdmFs
dWF0aW9uLCBidXQgSSBhbSBzdGFydGluZyB0aGUgSUVURiBMYXN0IENhbGwgYW5kIHdpbGwgc2No
ZWR1bGUgdGhlIGRvY3VtZW50IGluIHRoZSBuZXh0IGF2YWlsYWJsZSBUZWxlY2hhdC48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyE8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFsdmFyby48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DMS4gU2Vj
dGlvbiAyLiAoQkdQIExhcmdlIENvbW11bml0aWVzIEF0dHJpYnV0ZSkgc2F5cyB0aGF0IOKAnER1
cGxpY2F0ZSBCR1AgTGFyZ2UgQ29tbXVuaXR5IHZhbHVlcyBNVVNUIE5PVCBiZSB0cmFuc21pdHRl
ZC4mbmJzcDsgQSByZWNlaXZpbmcgc3BlYWtlciBNVVNUIHNpbGVudGx5IHJlbW92ZSBkdXBsaWNh
dGUgQkdQIExhcmdlIENvbW11bml0eSB2YWx1ZXMgZnJvbQ0KIGEgQkdQIExhcmdlIENvbW11bml0
eSBhdHRyaWJ1dGUu4oCdJm5ic3A7IEdpdmVuIHR3byBpZGVudGljYWwgTGFyZ2UgQ29tbXVuaXRp
ZXMsIHNob3VsZCB0aGUgcmVjZWl2ZXIgcmVtb3ZlIGJvdGgsIG9yIGp1c3Qgb25lICh0aGUgZHVw
bGljYXRlIG9mIHRoZSBmaXJzdCk/Jm5ic3A7IEkgdGhpbmsgdGhlIHRleHQgYXMgd3JpdHRlbiBp
cyBzdWJqZWN0IHRvIGludGVycHJldGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+QzIuIFRoZXJlIHNlZW1zIHRvIGJlIGEgY29udHJhZGljdGlvbiBpbiB0
aGUgZXhwZWN0ZWQgdXNlIG9mIHJlc2VydmVkIEdsb2JhbCBBZG1pbmlzdHJhdG9yIHZhbHVlcy4m
bmJzcDsgU2VjdGlvbiAyIHNheXMgdGhhdCB0aGUg4oCcR2xvYmFsIEFkbWluaXN0cmF0b3IgZmll
bGTigKZTSE9VTEQgZWl0aGVyIGJlIG9uZSBvZiB0aGUgcmVzZXJ2ZWQgdmFsdWVzIGFzIGRlZmlu
ZWQNCiBiZWxvdywgb3IgYW4gQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyIChBU04p4oCdLCBidXQg
bGF0ZXIgU2VjdGlvbiA1IHNheXM6IOKAnFRoZSBmb2xsb3dpbmcgR2xvYmFsIEFkbWluaXN0cmF0
b3IgdmFsdWVzIGFyZSByZXNlcnZlZDogMCwgNjU1MzUsIGFuZCA0Mjk0OTY3Mjk1LiZuYnNwOyBP
cGVyYXRvcnMgU0hPVUxEIE5PVCB1c2UgdGhlc2UgR2xvYmFsIEFkbWluaXN0cmF0b3IgdmFsdWVz
LuKAnSZuYnNwOyZuYnNwOyBJT1c6IOKAnFNIT1VMRCB1c2Ugb25lIGlmIHRoZSByZXNlcnZlZA0K
IHZhbHVlc+KAnSBhbmQg4oCcU0hPVUxEIE5PVCB1c2UgdGhlIHJlc2VydmVkIHZhbHVlc+KAnSBj
b250cmFkaWN0IGVhY2ggb3RoZXIuJm5ic3A7IEl0IHNlZW1zIHRvIG1lIHRoYXQgYmVjYXVzZSAw
LCA2NTUzNSwgYW5kIDQyOTQ5NjcyOTUgYXJlIGFscmVhZHkgcmVzZXJ2ZWQgQVNOcywgKjxiPmFu
ZDwvYj4qIHRoYXQg4oCcdGhlIExvY2FsIERhdGEgUGFydHMgYXJlIHRvIGJlIGludGVycHJldGVk
IGFzIGRlZmluZWQgYnkgdGhlIG93bmVyIG9mIHRoZSBBU07igJ0sIHRoZW4NCiBvbmx5IGFzc2ln
bmVkIEFTTnMgc2hvdWxkIGV2ZXIgYmUgdXNlZCAtLS0gKjxiPmFuZDwvYj4qIGdpdmVuIHRoYXQg
aXQgaXMgbm90IGFuIGVycm9yIHRvIHVzZSBhbiB2YWx1ZSwgdGhlbiB0aGVyZSBpcyBubyByZWFs
IGFkdmFudGFnZSBpbiByZXNlcnZpbmcgYW55dGhpbmcgKGFnYWluISkuIFN1Z2dlc3Rpb246IHJl
ZmVyZW5jZSB0aGUgUkZDcyB3aGVyZSAwLCA2NTUzNSwgYW5kIDQyOTQ5NjcyOTUgYXJlIHJlc2Vy
dmVkIGFuZCBqdXN0IHNheSB0aGF0DQogdGhvc2UgbnVtYmVycyBTSE9VTEQgTk9UIGJlIHVzZWQg
YmVjYXVzZSBpZiBhIFNwZWNpYWwgVXNlIExhcmdlIENvbW11bml0eSBpcyBldmVyIGRlZmluZWQs
IHRob3NlIHZhbHVlcyBtYXkgYmUgdXNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPkMzLiBJbiBTZWN0aW9uIDY6IHMvR2xvYmFsIEFkbWluaXN0cmF0b3IgZmll
bGQgTUFZIGNvbnRhaW4gYW55IHZhbHVlL0dsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxkIG1heSBj
b250YWluIGFueSB2YWx1ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGF0IOKAnE1BWeKAnSBp
cyBub3Qgbm9ybWF0aXZlLCBpdCBpcyBqdXN0IGV4cHJlc3NpbmcgYSBmYWN0LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QzQuIEEgTm9ybWF0aXZlIHJlZmVyZW5j
ZSB0byBSRkM0MjcxIHNob3VsZCBleGlzdDsgdGFnIGl0IHRvIHRoZSBmaXJzdCBtZW50aW9uIG9m
IEJHUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkM1LiBSRkMx
OTk3IGFuZCBSRkM2NzkzIHNob3VsZCBiZSBJbmZvcm1hdGl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_CE1331E43ECA41D7801F05519778E8DAciscocom_--


From nobody Thu Dec  1 22:31:18 2016
Return-Path: <ibagdona.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7931288B8; Thu,  1 Dec 2016 22:31:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JmB2AExiKpMA; Thu,  1 Dec 2016 22:31:16 -0800 (PST)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 772481294B2; Thu,  1 Dec 2016 22:31:16 -0800 (PST)
Received: by mail-pg0-x229.google.com with SMTP id 3so104105287pgd.0; Thu, 01 Dec 2016 22:31:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=AxR641LP+dkIZU/aUSRq6srm0YjQswBBm16Efi+P5t8=; b=06Wi0LbPofsDGvE0z6UWZcjHFHi3/xv9O7kUg48aqYzzQnxh7yF8NPk0rwu8JTC9Qr awCI2ehcjUeptEqKVcjO/vNYEcUqN3Rhx7aNGaN4jhLdfMfHgObC2APd+VJtKYmVnkPm Mz9HnTFB5WvHl2gkodRaL9AxqaLOQfeTS0IFSln+kBF4GBqyF1j1hF6jQIc/Kq4n//qo Yks/C4mle+22DFZRQgDLkjhH2IRBPMq7gtaCObWsEMKsJGysV/QNFqVw9zIygVfnZW3e R0gmpPhgMflilpzee4hvWb0Y5+o5iO0ANjcPiXbAFfoofljrfbKjriBt6BZnX6ofA9+T 2zsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=AxR641LP+dkIZU/aUSRq6srm0YjQswBBm16Efi+P5t8=; b=B35aE8dBO/23fNpUmurPf8JCDR1Zf3ZMFILjQQGHD1gVxODZY8LFCPxZNATDh4qIKi EQHQHGnwnrbaVqr93w0xZQGSA6osr30do2Vgw1UVG3mocQLvrH2f4Niflmif9yyMKuko TGWnfSGxB+Nv5sk199bRI5qYblBQfBK4KNV5AvgILTK0UBtYFr++xEj5ydq7LN0eCjH2 IkGjHvLVVcwb9fd/iS3Ojnzc2WSDUrgE2DneruW/40pfcecBBHrwAYQAIOdnHBkgx34I xa9gpgW9ytUvOyGS/LFeEZfk4SCv0TqEclPyvQRqh+vSSyUyBRMflw+0l6MTmNYHcKc+ XpmQ==
X-Gm-Message-State: AKaTC03MPFJz6xdRF9umfsjTAqeyS9FUpCXVwjIO0PoIfsuPMhm47g3bS2bhqNfO++YidA==
X-Received: by 10.84.218.8 with SMTP id q8mr93057317pli.138.1480660275814; Thu, 01 Dec 2016 22:31:15 -0800 (PST)
Received: from [172.16.184.157] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id g22sm4522955pgn.20.2016.12.01.22.31.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 22:31:15 -0800 (PST)
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com>
From: Ignas Bagdonas <ibagdona.ietf@gmail.com>
Message-ID: <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com>
Date: Fri, 2 Dec 2016 06:31:12 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com>
Content-Type: multipart/alternative; boundary="------------DD3D3E085AC9643C76A8347D"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zW_sBk7WW_hQbOtGHCTxwaCYEEs>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 06:31:18 -0000

This is a multi-part message in MIME format.
--------------DD3D3E085AC9643C76A8347D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Alvaro,

Thank you for your review!


On 02/12/2016 04:04, Alvaro Retana (aretana) wrote:
>
> Hi!
>
> I just finished reading this document.  Thanks for working on it!
>
> I do have some comments (please see below) that I want to see 
> addressed before IESG Evaluation, but I am starting the IETF Last Call 
> and will schedule the document in the next available Telechat.
>
> Thanks!
>
> Alvaro.
>
> C1. Section 2. (BGP Large Communities Attribute) says that “Duplicate 
> BGP Large Community values MUST NOT be transmitted.  A receiving 
> speaker MUST silently remove duplicate BGP Large Community values from 
> a BGP Large Community attribute.” Given two identical Large 
> Communities, should the receiver remove both, or just one (the 
> duplicate of the first)?  I think the text as written is subject to 
> interpretation.
>
The intention is to react on the first instance of the duplicate 
community - analogous to applying RFC7606 to the contents of the large 
community path attribute itself. Would a following text address your 
comment:

A receiving speaker MUST act on the first instance of duplicate BGP 
Large Community value, and MUST silently ignore any other occurrence of 
such duplicated values. Duplicate BGP Large Community values MUST NOT be 
transmitted.

This reverses the receive and transmit handling - ignore any subsequent 
duplicate community values and do not send duplicates. Whether an 
implementation actually removes anything or just ignores is an internal 
matter to the implementation.


> C2. There seems to be a contradiction in the expected use of reserved 
> Global Administrator values.  Section 2 says that the “Global 
> Administrator field…SHOULD either be one of the reserved values as 
> defined below, or an Autonomous System Number (ASN)”, but later 
> Section 5 says: “The following Global Administrator values are 
> reserved: 0, 65535, and 4294967295.  Operators SHOULD NOT use these 
> Global Administrator values.”   IOW: “SHOULD use one if the reserved 
> values” and “SHOULD NOT use the reserved values” contradict each 
> other.  It seems to me that because 0, 65535, and 4294967295 are 
> already reserved ASNs, **and** that “the Local Data Parts are to be 
> interpreted as defined by the owner of the ASN”, then only assigned 
> ASNs should ever be used --- **and** given that it is not an error to 
> use an value, then there is no real advantage in reserving anything 
> (again!). Suggestion: reference the RFCs where 0, 65535, and 
> 4294967295 are reserved and just say that those numbers SHOULD NOT be 
> used because if a Special Use Large Community is ever defined, those 
> values may be used.
>
For section 2: Global Administrator field SHOULD be an Autonomous System 
Number (ASN) or one of the reserved values defined in Section 5.

For section 5: Global Administrator values corresponding to reserved use 
Autonomous System Number values of 0 [RFC7607], 65535 [RFC7300], and 
4294967295 [RFC7300] are reserved.

Would this work?

> C3. In Section 6: s/Global Administrator field MAY contain any 
> value/Global Administrator field may contain any value That “MAY” is 
> not normative, it is just expressing a fact.
>
> C4. A Normative reference to RFC4271 should exist; tag it to the first 
> mention of BGP.
>
> C5. RFC1997 and RFC6793 should be Informative.
>

Will edit those.

Thank you.

Ignas


--------------DD3D3E085AC9643C76A8347D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Hi Alvaro,</p>
    <p>Thank you for your review!<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 02/12/2016 04:04, Alvaro Retana
      (aretana) wrote:<br>
    </div>
    <blockquote
      cite="mid:CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <meta name="Title" content="">
      <meta name="Keywords" content="">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:Calibri;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Calibri;
	color:windowtext;
	font-weight:normal;
	font-style:normal;}
span.msoIns
	{mso-style-type:export-only;
	mso-style-name:"";
	text-decoration:underline;
	color:teal;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:Calibri;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style>
      <div class="WordSection1">
        <p class="MsoNormal"><span style="font-size:11.0pt">Hi!<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt">I just
            finished reading this document.  Thanks for working on it!<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt">I do have
            some comments (please see below) that I want to see
            addressed before IESG Evaluation, but I am starting the IETF
            Last Call and will schedule the document in the next
            available Telechat.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt">Thanks!<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt">Alvaro.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt">C1. Section
            2. (BGP Large Communities Attribute) says that “Duplicate
            BGP Large Community values MUST NOT be transmitted.  A
            receiving speaker MUST silently remove duplicate BGP Large
            Community values from a BGP Large Community attribute.” 
            Given two identical Large Communities, should the receiver
            remove both, or just one (the duplicate of the first)?  I
            think the text as written is subject to interpretation.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
      </div>
    </blockquote>
    The intention is to react on the first instance of the duplicate
    community - analogous to applying RFC7606 to the contents of the
    large community path attribute itself. Would a following text
    address your comment: <br>
    <br>
    A receiving speaker MUST act on the first instance of duplicate BGP
    Large Community value, and MUST silently ignore any other occurrence
    of such duplicated values. Duplicate BGP Large Community values MUST
    NOT be transmitted. <br>
    <br>
    This reverses the receive and transmit handling - ignore any
    subsequent duplicate community values and do not send duplicates.
    Whether an implementation actually removes anything or just ignores
    is an internal matter to the implementation. <br>
    <br>
    <br>
    <blockquote
      cite="mid:CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><span style="font-size:11.0pt">C2. There
            seems to be a contradiction in the expected use of reserved
            Global Administrator values.  Section 2 says that the
            “Global Administrator field…SHOULD either be one of the
            reserved values as defined below, or an Autonomous System
            Number (ASN)”, but later Section 5 says: “The following
            Global Administrator values are reserved: 0, 65535, and
            4294967295.  Operators SHOULD NOT use these Global
            Administrator values.”   IOW: “SHOULD use one if the
            reserved values” and “SHOULD NOT use the reserved values”
            contradict each other.  It seems to me that because 0,
            65535, and 4294967295 are already reserved ASNs, *<b>and</b>*
            that “the Local Data Parts are to be interpreted as defined
            by the owner of the ASN”, then only assigned ASNs should
            ever be used --- *<b>and</b>* given that it is not an error
            to use an value, then there is no real advantage in
            reserving anything (again!). Suggestion: reference the RFCs
            where 0, 65535, and 4294967295 are reserved and just say
            that those numbers SHOULD NOT be used because if a Special
            Use Large Community is ever defined, those values may be
            used.<o:p></o:p></span></p>
      </div>
    </blockquote>
    For section 2: Global Administrator field SHOULD be an Autonomous
    System Number (ASN) or one of the reserved values defined in Section
    5. <br>
    <br>
    For section 5: Global Administrator values corresponding to reserved
    use Autonomous System Number values of 0 [RFC7607], 65535 [RFC7300],
    and 4294967295 [RFC7300] are reserved. <br>
    <br>
    Would this work? <br>
    <br>
    <blockquote
      cite="mid:CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt">C3. In
            Section 6: s/Global Administrator field MAY contain any
            value/Global Administrator field may contain any value    
            That “MAY” is not normative, it is just expressing a fact.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt">C4. A
            Normative reference to RFC4271 should exist; tag it to the
            first mention of BGP.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt">C5. RFC1997
            and RFC6793 should be Informative.<o:p></o:p></span></p>
      </div>
    </blockquote>
    <br>
    Will edit those. <br>
    <br>
    Thank you. <br>
    <br>
    Ignas<br>
    <br>
  </body>
</html>

--------------DD3D3E085AC9643C76A8347D--


From nobody Fri Dec  2 00:42:49 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21201129525; Fri,  2 Dec 2016 00:42:44 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148066816412.29721.1965835415134602483.idtracker@ietfa.amsl.com>
Date: Fri, 02 Dec 2016 00:42:44 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hpT6SERH-AfOn_0FRkmdQr0lLlI>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-as4octet-extcomm-generic-subtype-10.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 08:42:44 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Generic Subtype for BGP Four-octet AS specific extended community
        Authors         : Dhananjaya Rao
                          Pradosh Mohapatra
                          Jeffrey Haas
	Filename        : draft-ietf-idr-as4octet-extcomm-generic-subtype-10.txt
	Pages           : 6
	Date            : 2016-12-01

Abstract:
   Maintaining the current best practices with communities, ISPs and
   enterprises that are assigned a 4-octet AS number may want the BGP
   UPDATE messages they receive from their customers or peers to include
   a 4-octet AS specific BGP extended community.  This document defines
   a new sub-type within the four-octet AS specific extended community
   to facilitate this practice.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-as4octet-extcomm-generic-subtype/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as4octet-extcomm-generic-subtype-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Dec  2 01:24:34 2016
Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97AE129BB3 for <idr@ietfa.amsl.com>; Fri,  2 Dec 2016 01:24:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level: 
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
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 YqSElsnHOcRp for <idr@ietfa.amsl.com>; Fri,  2 Dec 2016 01:24:31 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 26B321295A0 for <idr@ietf.org>; Fri,  2 Dec 2016 01:24:31 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.10.116; 
From: "Susan Hares" <shares@ndzh.com>
To: "'Pushpasis Sarkar'" <pushpasis.ietf@gmail.com>
References: <007501d24bbf$11a41b50$34ec51f0$@ndzh.com> <CAEFuwkjwNdQcj=C3JrKt8LTAXsP6Su4_S2Mss+CeCf3bDasqog@mail.gmail.com>
In-Reply-To: <CAEFuwkjwNdQcj=C3JrKt8LTAXsP6Su4_S2Mss+CeCf3bDasqog@mail.gmail.com>
Date: Fri, 2 Dec 2016 04:21:21 -0500
Message-ID: <001a01d24c7d$72367440$56a35cc0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01D24C53.89610880"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQE7cm38Wxykn4lMS06FXtFzjOE1IQKg6Ys9og0OfOA=
X-Authenticated-User: skh@ndzh.com 
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/IN58WWuuQGGtU2AmSPyShzZFML0>
Cc: 'idr wg' <idr@ietf.org>
Subject: Re: [Idr] draft-psarkar-idr-bgp-ls-node-admin-tag-extension - 1 week period to comment (11/17 - 11/24/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 09:24:33 -0000

This is a multipart message in MIME format.

------=_NextPart_000_001B_01D24C53.89610880
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Pushpasis:=20

=20

If there exist 2 implementations for this draft, please let me know.  We =
can go rapidly into the final stages before WG LC.=20

=20

Sue=20

=20

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Pushpasis Sarkar
Sent: Thursday, December 1, 2016 1:57 PM
To: Susan Hares
Cc: idr wg
Subject: Re: [Idr] draft-psarkar-idr-bgp-ls-node-admin-tag-extension - 1 =
week period to comment (11/17 - 11/24/2016)

=20

Hi Sue,

=20

Thanks a lot. I have uploaded it as =
draft-ietf-idr-bgp-ls-node-admin-tag-extension.

=20

Best regards,

-Pushpasis

=20

=20

On Thu, Dec 1, 2016 at 2:38 AM, Susan Hares <shares@ndzh.com> wrote:

The IDR consensus is that the IPR on =
draft-psarkar-idr-bgp-ls-node-admin-tag-extension is acceptable.   The =
authors should submit the draft as:  =
draft-ietf-bgp-ls-node-admin-tag-extension. =20

=20

Sue Hares=20


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

=20


------=_NextPart_000_001B_01D24C53.89610880
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 14 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Pushpasis: <o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>If there exist 2 implementations for this draft, please let me =
know.=C2=A0 We can go rapidly into the final stages before WG LC. =
<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Sue <o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
Idr [mailto:idr-bounces@ietf.org] <b>On Behalf Of </b>Pushpasis =
Sarkar<br><b>Sent:</b> Thursday, December 1, 2016 1:57 PM<br><b>To:</b> =
Susan Hares<br><b>Cc:</b> idr wg<br><b>Subject:</b> Re: [Idr] =
draft-psarkar-idr-bgp-ls-node-admin-tag-extension - 1 week period to =
comment (11/17 - 11/24/2016)<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal>Hi =
Sue,<o:p></o:p></p><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Thanks a lot. I have uploaded it as =
draft-ietf-idr-bgp-ls-node-admin-tag-extension.<o:p></o:p></p></div><div>=
<p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Best regards,<o:p></o:p></p></div><div><p =
class=3DMsoNormal>-Pushpasis<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal>On Thu, =
Dec 1, 2016 at 2:38 AM, Susan Hares &lt;<a =
href=3D"mailto:shares@ndzh.com" =
target=3D"_blank">shares@ndzh.com</a>&gt; =
wrote:<o:p></o:p></p><div><div><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The IDR =
consensus is that the IPR on =
draft-psarkar-idr-bgp-ls-node-admin-tag-extension is =
acceptable.&nbsp;&nbsp; The authors should submit the draft as: =
&nbsp;draft-ietf-bgp-ls-node-admin-tag-extension. =
&nbsp;<o:p></o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Sue Hares =
<o:p></o:p></p></div></div><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><br>______________________________________=
_________<br>Idr mailing list<br><a =
href=3D"mailto:Idr@ietf.org">Idr@ietf.org</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/idr" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/idr</a><o:p></o:p=
></p></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div></body></html>
------=_NextPart_000_001B_01D24C53.89610880--


From nobody Fri Dec  2 03:41:05 2016
Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76395129D85 for <idr@ietfa.amsl.com>; Fri,  2 Dec 2016 03:41:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.798
X-Spam-Level: 
X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 p5doV2JBv413 for <idr@ietfa.amsl.com>; Fri,  2 Dec 2016 03:41:02 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D9565129DD0 for <idr@ietf.org>; Fri,  2 Dec 2016 03:39:59 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id E82081E341; Fri,  2 Dec 2016 06:43:20 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <148066816412.29721.1965835415134602483.idtracker@ietfa.amsl.com>
Date: Fri, 2 Dec 2016 06:39:57 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <923B7CD5-944B-498A-895D-0948F8BA35C4@pfrc.org>
References: <148066816412.29721.1965835415134602483.idtracker@ietfa.amsl.com>
To: idr wg <idr@ietf.org>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/UuaVgqBM2C8f6EEhdMOjb9uoUnc>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as4octet-extcomm-generic-subtype-10.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 11:41:04 -0000

This update solely exists to act as a tombstone for the work and to =
request IANA to deprecate their former assignments.

Chairs, please continue with the request with IANA.

-- Jeff

> On Dec 2, 2016, at 3:42 AM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Inter-Domain Routing of the IETF.
>=20
>        Title           : Generic Subtype for BGP Four-octet AS =
specific extended community
>        Authors         : Dhananjaya Rao
>                          Pradosh Mohapatra
>                          Jeffrey Haas
> 	Filename        : =
draft-ietf-idr-as4octet-extcomm-generic-subtype-10.txt
> 	Pages           : 6
> 	Date            : 2016-12-01
>=20
> Abstract:
>   Maintaining the current best practices with communities, ISPs and
>   enterprises that are assigned a 4-octet AS number may want the BGP
>   UPDATE messages they receive from their customers or peers to =
include
>   a 4-octet AS specific BGP extended community.  This document defines
>   a new sub-type within the four-octet AS specific extended community
>   to facilitate this practice.
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> =
https://datatracker.ietf.org/doc/draft-ietf-idr-as4octet-extcomm-generic-s=
ubtype/
>=20
> There's also a htmlized version available at:
> =
https://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtyp=
e-10
>=20
> A diff from the previous version is available at:
> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-as4octet-extcomm-generi=
c-subtype-10
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Fri Dec  2 05:46:57 2016
Return-Path: <aretana@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EDC1296BB; Fri,  2 Dec 2016 05:46:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level: 
X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 qgH_yhRmjlLU; Fri,  2 Dec 2016 05:46:53 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAAEA129436; Fri,  2 Dec 2016 05:46:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21174; q=dns/txt; s=iport; t=1480686412; x=1481896012; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mv6P5f7bs5OO6lmMHzpbbp70Z7Vekw/wmfk4HSUIoiI=; b=W2ls88kh4sv2T10zVjqNQ+anYxRnpJEtSvfhXk36/7qveLP9vcl0XFjb vw/fHO6KdzikzCO+CuNqJdjsCID9GZzv6kRowSy3hVYh4wvZEIcDQTfbf T2E3WNpIDRiJobkbJij3yLSsK7ilI3U36FO8OVOP2ArykX4+R8/kYdA84 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQCyekFY/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnNFAQEBAQEfWoEGB40/lwuHc4dnhSKCBoYiAhqBfj8UAQIBAQE?= =?us-ascii?q?BAQEBYiiEaQEEASNWBQsCAQgONAICAh8RJQIEAQ0FFIhBAw8IrHOCKS+HEA2Dc?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARyGPoF9gl6CSIIYgm0tgjAFlHqFNDUBjTW?= =?us-ascii?q?DXpA5iUyIQAEfN4EZMQEBgySBfnKGQQaBKoENAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,729,1477958400";  d="scan'208,217";a="355747060"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 13:46:51 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uB2DkpgE027850 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 13:46:51 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 07:46:50 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 2 Dec 2016 07:46:50 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Ignas Bagdonas <ibagdona.ietf@gmail.com>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>
Thread-Topic: AD Review of draft-ietf-idr-large-community-09
Thread-Index: AQHSTFEplUv+tL/kGUyk1NyWV0fUzaD0l0wAgAAl5QA=
Date: Fri, 2 Dec 2016 13:46:50 +0000
Message-ID: <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com>
In-Reply-To: <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: multipart/alternative; boundary="_000_8B6BA07AD6364D8C8B02A5CB05538AAFciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Ij2LxmBbG9jtua43yq9gr2xWul4>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 13:46:56 -0000

--_000_8B6BA07AD6364D8C8B02A5CB05538AAFciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T24gMTIvMi8xNiwgMTozMSBBTSwgIklnbmFzIEJhZ2RvbmFzIiA8aWJhZ2RvbmEuaWV0ZkBnbWFp
bC5jb20+IHdyb3RlOg0KDQoNCg0KSWduYXM6DQoNCg0KDQpIaSENCg0KDQoNCj4gPiBDMS4gU2Vj
dGlvbiAyLiAoQkdQIExhcmdlIENvbW11bml0aWVzIEF0dHJpYnV0ZSkgc2F5cyB0aGF0IOKAnER1
cGxpY2F0ZSBCR1AgTGFyZ2UgQ29tbXVuaXR5DQoNCj4gPiB2YWx1ZXMgTVVTVCBOT1QgYmUgdHJh
bnNtaXR0ZWQuICBBIHJlY2VpdmluZyBzcGVha2VyIE1VU1Qgc2lsZW50bHkgcmVtb3ZlIGR1cGxp
Y2F0ZSBCR1AgTGFyZ2UNCg0KPiA+IENvbW11bml0eSB2YWx1ZXMgZnJvbSBhIEJHUCBMYXJnZSBD
b21tdW5pdHkgYXR0cmlidXRlLuKAnSAgR2l2ZW4gdHdvIGlkZW50aWNhbCBMYXJnZQ0KDQo+ID4g
Q29tbXVuaXRpZXMsIHNob3VsZCB0aGUgcmVjZWl2ZXIgcmVtb3ZlIGJvdGgsIG9yIGp1c3Qgb25l
ICh0aGUgZHVwbGljYXRlIG9mIHRoZSBmaXJzdCk/ICBJIHRoaW5rIHRoZQ0KDQo+ID4gdGV4dCBh
cyB3cml0dGVuIGlzIHN1YmplY3QgdG8gaW50ZXJwcmV0YXRpb24uDQoNCj4NCg0KPiBUaGUgaW50
ZW50aW9uIGlzIHRvIHJlYWN0IG9uIHRoZSBmaXJzdCBpbnN0YW5jZSBvZiB0aGUgZHVwbGljYXRl
IGNvbW11bml0eSAtIGFuYWxvZ291cyB0byBhcHBseWluZw0KDQo+IFJGQzc2MDYgdG8gdGhlIGNv
bnRlbnRzIG9mIHRoZSBsYXJnZSBjb21tdW5pdHkgcGF0aCBhdHRyaWJ1dGUgaXRzZWxmLiBXb3Vs
ZCBhIGZvbGxvd2luZyB0ZXh0IGFkZHJlc3MNCg0KPiB5b3VyIGNvbW1lbnQ6DQoNCj4NCg0KPiBB
IHJlY2VpdmluZyBzcGVha2VyIE1VU1QgYWN0IG9uIHRoZSBmaXJzdCBpbnN0YW5jZSBvZiBkdXBs
aWNhdGUgQkdQIExhcmdlIENvbW11bml0eSB2YWx1ZSwgYW5kDQoNCj4gTVVTVCBzaWxlbnRseSBp
Z25vcmUgYW55IG90aGVyIG9jY3VycmVuY2Ugb2Ygc3VjaCBkdXBsaWNhdGVkIHZhbHVlcy4gRHVw
bGljYXRlIEJHUCBMYXJnZQ0KDQo+IENvbW11bml0eSB2YWx1ZXMgTVVTVCBOT1QgYmUgdHJhbnNt
aXR0ZWQuDQoNCj4NCg0KPiBUaGlzIHJldmVyc2VzIHRoZSByZWNlaXZlIGFuZCB0cmFuc21pdCBo
YW5kbGluZyAtIGlnbm9yZSBhbnkgc3Vic2VxdWVudCBkdXBsaWNhdGUgY29tbXVuaXR5IHZhbHVl
cw0KDQo+IGFuZCBkbyBub3Qgc2VuZCBkdXBsaWNhdGVzLiBXaGV0aGVyIGFuIGltcGxlbWVudGF0
aW9uIGFjdHVhbGx5IHJlbW92ZXMgYW55dGhpbmcgb3IganVzdCBpZ25vcmVzIGlzDQoNCj4gYW4g
aW50ZXJuYWwgbWF0dGVyIHRvIHRoZSBpbXBsZW1lbnRhdGlvbi4NCg0KDQoNClJlbW92aW5nIGFu
ZCBpZ25vcmluZyBhcmUgb2J2aW91c2x5IGRpZmZlcmVudCB0aGluZ3PigKYgIFRoZSB0ZXh0IGFi
b3ZlIGlzIGZpbmUgd2l0aCBtZSwgYnV0IEkgd291bGQgYXNrOiB3aGF0IGRvIHRoZSBjdXJyZW50
IGltcGxlbWVudGF0aW9ucyBkbz8gIElmIHRoZXkgcmVtb3ZlIChhcyBvcmlnaW5hbGx5IHNwZWNp
ZmllZCksIHRoZW4gSSB3b3VsZCBzdWdnZXN0IHlvdSBrZWVwIHRoYXQuDQoNCg0KDQoNCg0KDQoN
Cj4gPiBDMi4gVGhlcmUgc2VlbXMgdG8gYmUgYSBjb250cmFkaWN0aW9uIGluIHRoZSBleHBlY3Rl
ZCB1c2Ugb2YgcmVzZXJ2ZWQgR2xvYmFsIEFkbWluaXN0cmF0b3INCg0KPiA+IHZhbHVlcy4gIFNl
Y3Rpb24gMiBzYXlzIHRoYXQgdGhlIOKAnEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxk4oCmU0hP
VUxEIGVpdGhlciBiZSBvbmUgb2YgdGhlIHJlc2VydmVkDQoNCj4gPiB2YWx1ZXMgYXMgZGVmaW5l
ZCBiZWxvdywgb3IgYW4gQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyIChBU04p4oCdLCBidXQgbGF0
ZXIgU2VjdGlvbiA1IHNheXM6IOKAnFRoZQ0KDQo+ID4gZm9sbG93aW5nIEdsb2JhbCBBZG1pbmlz
dHJhdG9yIHZhbHVlcyBhcmUgcmVzZXJ2ZWQ6IDAsIDY1NTM1LCBhbmQgNDI5NDk2NzI5NS4gIE9w
ZXJhdG9ycyBTSE9VTEQNCg0KPiA+IE5PVCB1c2UgdGhlc2UgR2xvYmFsIEFkbWluaXN0cmF0b3Ig
dmFsdWVzLuKAnSAgIElPVzog4oCcU0hPVUxEIHVzZSBvbmUgaWYgdGhlIHJlc2VydmVkIHZhbHVl
c+KAnSBhbmQNCg0KPiA+IOKAnFNIT1VMRCBOT1QgdXNlIHRoZSByZXNlcnZlZCB2YWx1ZXPigJ0g
Y29udHJhZGljdCBlYWNoIG90aGVyLiAgSXQgc2VlbXMgdG8gbWUgdGhhdCBiZWNhdXNlIDAsDQoN
Cj4gPiA2NTUzNSwgYW5kIDQyOTQ5NjcyOTUgYXJlIGFscmVhZHkgcmVzZXJ2ZWQgQVNOcywgKmFu
ZCogdGhhdCDigJx0aGUgTG9jYWwgRGF0YSBQYXJ0cyBhcmUgdG8gYmUNCg0KPiA+IGludGVycHJl
dGVkIGFzIGRlZmluZWQgYnkgdGhlIG93bmVyIG9mIHRoZSBBU07igJ0sIHRoZW4gb25seSBhc3Np
Z25lZCBBU05zIHNob3VsZCBldmVyIGJlIHVzZWQgLS0tDQoNCj4gPiAqYW5kKiBnaXZlbiB0aGF0
IGl0IGlzIG5vdCBhbiBlcnJvciB0byB1c2UgYW4gdmFsdWUsIHRoZW4gdGhlcmUgaXMgbm8gcmVh
bCBhZHZhbnRhZ2UgaW4gcmVzZXJ2aW5nDQoNCj4gPiBhbnl0aGluZyAoYWdhaW4hKS4gU3VnZ2Vz
dGlvbjogcmVmZXJlbmNlIHRoZSBSRkNzIHdoZXJlIDAsIDY1NTM1LCBhbmQgNDI5NDk2NzI5NSBh
cmUgcmVzZXJ2ZWQNCg0KPiA+IGFuZCBqdXN0IHNheSB0aGF0IHRob3NlIG51bWJlcnMgU0hPVUxE
IE5PVCBiZSB1c2VkIGJlY2F1c2UgaWYgYSBTcGVjaWFsIFVzZSBMYXJnZSBDb21tdW5pdHkgaXMN
Cg0KPiA+IGV2ZXIgZGVmaW5lZCwgdGhvc2UgdmFsdWVzIG1heSBiZSB1c2VkLg0KDQo+DQoNCj4g
Rm9yIHNlY3Rpb24gMjogR2xvYmFsIEFkbWluaXN0cmF0b3IgZmllbGQgU0hPVUxEIGJlIGFuIEF1
dG9ub21vdXMgU3lzdGVtIE51bWJlciAoQVNOKSBvciBvbmUgb2YNCg0KPiB0aGUgcmVzZXJ2ZWQg
dmFsdWVzIGRlZmluZWQgaW4gU2VjdGlvbiA1Lg0KDQo+DQoNCj4gRm9yIHNlY3Rpb24gNTogR2xv
YmFsIEFkbWluaXN0cmF0b3IgdmFsdWVzIGNvcnJlc3BvbmRpbmcgdG8gcmVzZXJ2ZWQgdXNlIEF1
dG9ub21vdXMgU3lzdGVtDQoNCj4gTnVtYmVyIHZhbHVlcyBvZiAwIFtSRkM3NjA3XSwgNjU1MzUg
W1JGQzczMDBdLCBhbmQgNDI5NDk2NzI5NSBbUkZDNzMwMF0gYXJlIHJlc2VydmVkLg0KDQo+DQoN
Cj4gV291bGQgdGhpcyB3b3JrPw0KDQoNCg0KUXVlc3Rpb24gZm9yIHlvdTogIGRvIHlvdSB3YW50
IHRoZSBvcGVyYXRvcnMgdG8gdXNlIDAsIDY1NTM1LCBhbmQgNDI5NDk2NzI5NSB3aGVuZXZlciB0
aGV5IHdhbnQgKHdoaWNoIGlzIHdoYXQgdGhlIG5ldyB0ZXh0IHNheXMpLCBPUiwgZG8geW91IHdh
bnQgdGhlbSBub3QgdG8gdXNlIHRoZW0gYmVjYXVzZSB0aGV5IGNvdWxkIGJlIHVzZWQgbGF0ZXIg
Zm9yIGEgc3BlY2lhbCBwdXJwb3NlICh3aGljaCBpcyB3aGF0IHRoZSBvcmlnaW5hbCB0ZXh0IHNl
ZW1lZCB0byBpbmRpY2F0ZSk/Pw0KDQoNCg0KSeKAmW0gaGF2aW5nIGEgaGFyZCB0aW1lIHdpdGgg
dGhpcyBkb2N1bWVudCDigJxyZXNlcnZpbmfigJ0gYW55IHZhbHVlIGJlY2F1c2UgdGhlIG51bWJl
ciBzcGFjZSBpcyBub3QgcmVhbGx5IG9uZSB3aGVyZSB2YWx1ZXMgYXJlIGFzc2lnbmVkIChpbiB0
aGUgdHlwaWNhbCBJQU5BIHNlbnNlOiBjcmVhdGUgYSByZWdpc3RyeSwgZXRjLiDigJMgYW5kIEkg
ZG91YnQgeW91IHdhbnQgdG8gbWFrZSBpdCB0aGF0IHdheSnigKZidXQgdGhlIGNvbnRlbnRzIGNh
biBiZSAoU0hPVUxEKSB3aGF0IGlzIGNvbnRhaW5lZCBpbiBhbiBhbHJlYWR5IGV4aXN0aW5nIHJl
Z2lzdHJ5IChBU05zKSB0aGF0IGhhcyBkaXN0cmlidXRlZCBjb250cm9sLg0KDQoNCg0KQXNzdW1p
bmcgdGhhdCB5b3Ugd291bGQgcHJlZmVyIHRoZSBvcGVyYXRvcnMgTk9UIHRvIHVzZSAwLCA2NTUz
NSwgYW5kIDQyOTQ5NjcyOTUsIHRoZW4gaGVyZeKAmXMgbXkgc3VnZ2VzdGlvbjoNCg0KDQoNCk9M
RD4gKFNlY3Rpb24gMikNCg0KICAgVGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxkIGlzIGlu
dGVuZGVkIHRvIGFsbG93IGRpZmZlcmVudA0KDQogICBBdXRvbm9tb3VzIFN5c3RlbXMgdG8gZGVm
aW5lIEJHUCBMYXJnZSBDb21tdW5pdGllcyB3aXRob3V0IGNvbGxpc2lvbi4NCg0KICAgVGhpcyBm
aWVsZCBTSE9VTEQgZWl0aGVyIGJlIG9uZSBvZiB0aGUgcmVzZXJ2ZWQgdmFsdWVzIGFzIGRlZmlu
ZWQNCg0KICAgYmVsb3csIG9yIGFuIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlciAoQVNOKS4gIElm
IGl0IGlzIGEgcmVzZXJ2ZWQNCg0KICAgdmFsdWUsIHRoZW4gdGhlIExvY2FsIERhdGEgUGFydHMg
YXJlIGFzIGRlZmluZWQgYnkgdGhlIHJlc2VydmVkDQoNCiAgIHZhbHVlLiAgSWYgaXQgaXMgYW4g
QVNOIHRoZW4gdGhlIExvY2FsIERhdGEgUGFydHMgYXJlIHRvIGJlDQoNCiAgIGludGVycHJldGVk
IGFzIGRlZmluZWQgYnkgdGhlIG93bmVyIG9mIHRoZSBBU04uDQoNCg0KDQpORVc+DQoNCiAgIFRo
ZSBHbG9iYWwgQWRtaW5pc3RyYXRvciBmaWVsZCBpcyBpbnRlbmRlZCB0byBhbGxvdyBkaWZmZXJl
bnQNCg0KICAgQXV0b25vbW91cyBTeXN0ZW1zIHRvIGRlZmluZSBCR1AgTGFyZ2UgQ29tbXVuaXRp
ZXMgd2l0aG91dCBjb2xsaXNpb24uDQoNCiAgIFRoaXMgZmllbGQgU0hPVUxEIGJlIGFuIEF1dG9u
b21vdXMgU3lzdGVtIE51bWJlciAoQVNOKS4gIFRoZSB1c2Ugb2YNCg0KICAgUmVzZXJ2ZWQgQVNO
cyAoMCBbUkZDNzYwN10sIDY1NTM1IGFuZCA0Mjk0OTY3Mjk1IFtSRkM3MzAwXSkgaXMgTk9UDQoN
CiAgIFJFQ09NTUVOREVELg0KDQoNCg0K4oCmYW5kIHRoZW4gZWxpbWluYXRlIFNlY3Rpb24gNeKA
pg0KDQoNCg0KSWYgeW91IHJlYWxseSB3YW50IG9wZXJhdG9ycyBub3QgdG8gdXNlIHRoZSBSZXNl
cnZlZCBBU05zIGV2ZXIgYmVjYXVzZSBhIHNwZWNpYWwgdXNlIG1heSBiZSB0aG91Z2ggdXAgbGF0
ZXIsIHRoZW4gdXNlIOKAnE1VU1QgTk9U4oCdIGFib3ZlLg0KDQoNCg0KDQoNClRoYW5rcyENCg0K
DQoNCkFsdmFyby4NCg==

--_000_8B6BA07AD6364D8C8B02A5CB05538AAFciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <E5D7759CA8EA434C8C2EF950D549C237@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OkNhbGlicmk7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNv
LXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRv
d3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4u
RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNh
bGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1z
dHlsZTpub3JtYWw7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFp
biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
UGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLm1zb0lucw0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu
MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1
NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPk9uIDEyLzIvMTYsIDE6MzEgQU0sICZxdW90O0lnbmFzIEJhZ2Rv
bmFzJnF1b3Q7ICZsdDtpYmFnZG9uYS5pZXRmQGdtYWlsLmNvbSZndDsgd3JvdGU6PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPklnbmFzOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGkhPC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgQzEuIFNlY3Rpb24gMi4gKEJHUCBMYXJnZSBDb21tdW5p
dGllcyBBdHRyaWJ1dGUpIHNheXMgdGhhdCDigJxEdXBsaWNhdGUgQkdQIExhcmdlIENvbW11bml0
eQ0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IHZhbHVlcyBNVVNUIE5P
VCBiZSB0cmFuc21pdHRlZC4mbmJzcDsgQSByZWNlaXZpbmcgc3BlYWtlciBNVVNUIHNpbGVudGx5
IHJlbW92ZSBkdXBsaWNhdGUgQkdQIExhcmdlDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mZ3Q7ICZndDsgQ29tbXVuaXR5IHZhbHVlcyBmcm9tIGEgQkdQIExhcmdlIENvbW11bml0eSBh
dHRyaWJ1dGUu4oCdJm5ic3A7IEdpdmVuIHR3byBpZGVudGljYWwgTGFyZ2UNCjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBDb21tdW5pdGllcywgc2hvdWxkIHRoZSByZWNl
aXZlciByZW1vdmUgYm90aCwgb3IganVzdCBvbmUgKHRoZSBkdXBsaWNhdGUgb2YgdGhlIGZpcnN0
KT8mbmJzcDsgSSB0aGluayB0aGUNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg
Jmd0OyB0ZXh0IGFzIHdyaXR0ZW4gaXMgc3ViamVjdCB0byBpbnRlcnByZXRhdGlvbi48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIGludGVudGlvbiBpcyB0byByZWFj
dCBvbiB0aGUgZmlyc3QgaW5zdGFuY2Ugb2YgdGhlIGR1cGxpY2F0ZSBjb21tdW5pdHkgLSBhbmFs
b2dvdXMgdG8gYXBwbHlpbmcNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgUkZD
NzYwNiB0byB0aGUgY29udGVudHMgb2YgdGhlIGxhcmdlIGNvbW11bml0eSBwYXRoIGF0dHJpYnV0
ZSBpdHNlbGYuIFdvdWxkIGEgZm9sbG93aW5nIHRleHQgYWRkcmVzcw0KPC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jmd0OyB5b3VyIGNvbW1lbnQ6IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jmd0OyBBIHJlY2VpdmluZyBzcGVha2VyIE1VU1QgYWN0IG9uIHRoZSBmaXJz
dCBpbnN0YW5jZSBvZiBkdXBsaWNhdGUgQkdQIExhcmdlIENvbW11bml0eSB2YWx1ZSwgYW5kDQo8
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE1VU1Qgc2lsZW50bHkgaWdub3JlIGFu
eSBvdGhlciBvY2N1cnJlbmNlIG9mIHN1Y2ggZHVwbGljYXRlZCB2YWx1ZXMuIER1cGxpY2F0ZSBC
R1AgTGFyZ2UNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ29tbXVuaXR5IHZh
bHVlcyBNVVNUIE5PVCBiZSB0cmFuc21pdHRlZC4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mZ3Q7IFRoaXMgcmV2ZXJzZXMgdGhlIHJlY2VpdmUgYW5kIHRyYW5zbWl0IGhhbmRs
aW5nIC0gaWdub3JlIGFueSBzdWJzZXF1ZW50IGR1cGxpY2F0ZSBjb21tdW5pdHkgdmFsdWVzDQo8
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFuZCBkbyBub3Qgc2VuZCBkdXBsaWNh
dGVzLiBXaGV0aGVyIGFuIGltcGxlbWVudGF0aW9uIGFjdHVhbGx5IHJlbW92ZXMgYW55dGhpbmcg
b3IganVzdCBpZ25vcmVzIGlzDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFu
IGludGVybmFsIG1hdHRlciB0byB0aGUgaW1wbGVtZW50YXRpb24uIDxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij5SZW1vdmluZyBhbmQgaWdub3JpbmcgYXJlIG9idmlvdXNseSBkaWZmZXJl
bnQgdGhpbmdz4oCmJm5ic3A7IFRoZSB0ZXh0IGFib3ZlIGlzIGZpbmUgd2l0aCBtZSwgYnV0IEkg
d291bGQgYXNrOiB3aGF0IGRvIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBkbz8mbmJzcDsg
SWYgdGhleSByZW1vdmUgKGFzIG9yaWdpbmFsbHkgc3BlY2lmaWVkKSwgdGhlbiBJIHdvdWxkIHN1
Z2dlc3QgeW91IGtlZXAgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBDMi4gVGhlcmUgc2VlbXMg
dG8gYmUgYSBjb250cmFkaWN0aW9uIGluIHRoZSBleHBlY3RlZCB1c2Ugb2YgcmVzZXJ2ZWQgR2xv
YmFsIEFkbWluaXN0cmF0b3INCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0
OyB2YWx1ZXMuJm5ic3A7IFNlY3Rpb24gMiBzYXlzIHRoYXQgdGhlIOKAnEdsb2JhbCBBZG1pbmlz
dHJhdG9yIGZpZWxk4oCmU0hPVUxEIGVpdGhlciBiZSBvbmUgb2YgdGhlIHJlc2VydmVkDQo8L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgdmFsdWVzIGFzIGRlZmluZWQgYmVs
b3csIG9yIGFuIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlciAoQVNOKeKAnSwgYnV0IGxhdGVyIFNl
Y3Rpb24gNSBzYXlzOiDigJxUaGUNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg
Jmd0OyBmb2xsb3dpbmcgR2xvYmFsIEFkbWluaXN0cmF0b3IgdmFsdWVzIGFyZSByZXNlcnZlZDog
MCwgNjU1MzUsIGFuZCA0Mjk0OTY3Mjk1LiZuYnNwOyBPcGVyYXRvcnMgU0hPVUxEDQo8L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgTk9UIHVzZSB0aGVzZSBHbG9iYWwgQWRt
aW5pc3RyYXRvciB2YWx1ZXMu4oCdJm5ic3A7Jm5ic3A7IElPVzog4oCcU0hPVUxEIHVzZSBvbmUg
aWYgdGhlIHJlc2VydmVkIHZhbHVlc+KAnSBhbmQNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgJmd0OyDigJxTSE9VTEQgTk9UIHVzZSB0aGUgcmVzZXJ2ZWQgdmFsdWVz4oCdIGNv
bnRyYWRpY3QgZWFjaCBvdGhlci4mbmJzcDsgSXQgc2VlbXMgdG8gbWUgdGhhdCBiZWNhdXNlIDAs
DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgNjU1MzUsIGFuZCA0Mjk0
OTY3Mjk1IGFyZSBhbHJlYWR5IHJlc2VydmVkIEFTTnMsICphbmQqIHRoYXQg4oCcdGhlIExvY2Fs
IERhdGEgUGFydHMgYXJlIHRvIGJlDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7
ICZndDsgaW50ZXJwcmV0ZWQgYXMgZGVmaW5lZCBieSB0aGUgb3duZXIgb2YgdGhlIEFTTuKAnSwg
dGhlbiBvbmx5IGFzc2lnbmVkIEFTTnMgc2hvdWxkIGV2ZXIgYmUgdXNlZCAtLS0NCjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAqYW5kKiBnaXZlbiB0aGF0IGl0IGlzIG5v
dCBhbiBlcnJvciB0byB1c2UgYW4gdmFsdWUsIHRoZW4gdGhlcmUgaXMgbm8gcmVhbCBhZHZhbnRh
Z2UgaW4gcmVzZXJ2aW5nDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg
YW55dGhpbmcgKGFnYWluISkuIFN1Z2dlc3Rpb246IHJlZmVyZW5jZSB0aGUgUkZDcyB3aGVyZSAw
LCA2NTUzNSwgYW5kIDQyOTQ5NjcyOTUgYXJlIHJlc2VydmVkDQo8L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgYW5kIGp1c3Qgc2F5IHRoYXQgdGhvc2UgbnVtYmVycyBTSE9V
TEQgTk9UIGJlIHVzZWQgYmVjYXVzZSBpZiBhIFNwZWNpYWwgVXNlIExhcmdlIENvbW11bml0eSBp
cw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGV2ZXIgZGVmaW5lZCwg
dGhvc2UgdmFsdWVzIG1heSBiZSB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jmd0OyBGb3Igc2VjdGlvbiAyOiBHbG9iYWwgQWRtaW5pc3RyYXRvciBmaWVsZCBTSE9VTEQg
YmUgYW4gQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyIChBU04pIG9yIG9uZSBvZg0KPC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgcmVzZXJ2ZWQgdmFsdWVzIGRlZmluZWQgaW4g
U2VjdGlvbiA1LiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRm9yIHNl
Y3Rpb24gNTogR2xvYmFsIEFkbWluaXN0cmF0b3IgdmFsdWVzIGNvcnJlc3BvbmRpbmcgdG8gcmVz
ZXJ2ZWQgdXNlIEF1dG9ub21vdXMgU3lzdGVtDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mZ3Q7IE51bWJlciB2YWx1ZXMgb2YgMCBbUkZDNzYwN10sIDY1NTM1IFtSRkM3MzAwXSwgYW5k
IDQyOTQ5NjcyOTUgW1JGQzczMDBdIGFyZSByZXNlcnZlZC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jmd0OyBXb3VsZCB0aGlzIHdvcms/IDxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij5RdWVzdGlvbiBmb3IgeW91OiZuYnNwOyBkbyB5b3Ugd2FudCB0aGUgb3BlcmF0
b3JzIHRvIHVzZSAwLCA2NTUzNSwgYW5kIDQyOTQ5NjcyOTUgd2hlbmV2ZXIgdGhleSB3YW50ICh3
aGljaCBpcyB3aGF0IHRoZSBuZXcgdGV4dCBzYXlzKSwgT1IsIGRvIHlvdSB3YW50IHRoZW0gbm90
IHRvIHVzZSB0aGVtIGJlY2F1c2UgdGhleSBjb3VsZCBiZSB1c2VkIGxhdGVyIGZvciBhIHNwZWNp
YWwgcHVycG9zZSAod2hpY2ggaXMNCiB3aGF0IHRoZSBvcmlnaW5hbCB0ZXh0IHNlZW1lZCB0byBp
bmRpY2F0ZSk/PzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SeKAmW0gaGF2aW5nIGEgaGFyZCB0aW1lIHdp
dGggdGhpcyBkb2N1bWVudCDigJxyZXNlcnZpbmfigJ0gYW55IHZhbHVlIGJlY2F1c2UgdGhlIG51
bWJlciBzcGFjZSBpcyBub3QgcmVhbGx5IG9uZSB3aGVyZSB2YWx1ZXMgYXJlIGFzc2lnbmVkIChp
biB0aGUgdHlwaWNhbCBJQU5BIHNlbnNlOiBjcmVhdGUgYSByZWdpc3RyeSwgZXRjLiDigJMgYW5k
IEkgZG91YnQgeW91IHdhbnQgdG8gbWFrZSBpdCB0aGF0IHdheSnigKZidXQNCiB0aGUgY29udGVu
dHMgY2FuIGJlIChTSE9VTEQpIHdoYXQgaXMgY29udGFpbmVkIGluIGFuIGFscmVhZHkgZXhpc3Rp
bmcgcmVnaXN0cnkgKEFTTnMpIHRoYXQgaGFzIGRpc3RyaWJ1dGVkIGNvbnRyb2wuPC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij5Bc3N1bWluZyB0aGF0IHlvdSB3b3VsZCBwcmVmZXIgdGhlIG9wZXJhdG9ycyBO
T1QgdG8gdXNlIDAsIDY1NTM1LCBhbmQgNDI5NDk2NzI5NSwgdGhlbiBoZXJl4oCZcyBteSBzdWdn
ZXN0aW9uOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T0xEJmd0OyAoU2VjdGlvbiAyKTwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBUaGUgR2xvYmFsIEFkbWluaXN0cmF0b3Ig
ZmllbGQgaXMgaW50ZW5kZWQgdG8gYWxsb3cgZGlmZmVyZW50PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQXV0b25vbW91cyBTeXN0ZW1zIHRvIGRl
ZmluZSBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgd2l0aG91dCBjb2xsaXNpb24uPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhpcyBmaWVsZCBTSE9V
TEQgZWl0aGVyIGJlIG9uZSBvZiB0aGUgcmVzZXJ2ZWQgdmFsdWVzIGFzIGRlZmluZWQ8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBiZWxvdywgb3Ig
YW4gQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyIChBU04pLiZuYnNwOyBJZiBpdCBpcyBhIHJlc2Vy
dmVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg
dmFsdWUsIHRoZW4gdGhlIExvY2FsIERhdGEgUGFydHMgYXJlIGFzIGRlZmluZWQgYnkgdGhlIHJl
c2VydmVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz
cDsgdmFsdWUuJm5ic3A7IElmIGl0IGlzIGFuIEFTTiB0aGVuIHRoZSBMb2NhbCBEYXRhIFBhcnRz
IGFyZSB0byBiZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7
Jm5ic3A7IGludGVycHJldGVkIGFzIGRlZmluZWQgYnkgdGhlIG93bmVyIG9mIHRoZSBBU04uPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk5FVyZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxk
IGlzIGludGVuZGVkIHRvIGFsbG93IGRpZmZlcmVudDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEF1dG9ub21vdXMgU3lzdGVtcyB0byBkZWZpbmUg
QkdQIExhcmdlIENvbW11bml0aWVzIHdpdGhvdXQgY29sbGlzaW9uLjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZmllbGQgU0hPVUxEIGJl
IGFuIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlciAoQVNOKS4gJm5ic3A7VGhlIHVzZSBvZg0KPC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7UmVzZXJ2ZWQgQVNO
cyAoMCBbUkZDNzYwN10sIDY1NTM1IGFuZCA0Mjk0OTY3Mjk1IFtSRkM3MzAwXSkgaXMgTk9UDQo8
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDtSRUNPTU1FTkRF
RC48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPuKApmFuZCB0aGVuIGVsaW1pbmF0ZSBTZWN0aW9uIDXigKY8
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPklmIHlvdSByZWFsbHkgd2FudCBvcGVyYXRvcnMgbm90IHRvIHVz
ZSB0aGUgUmVzZXJ2ZWQgQVNOcyBldmVyIGJlY2F1c2UgYSBzcGVjaWFsIHVzZSBtYXkgYmUgdGhv
dWdoIHVwIGxhdGVyLCB0aGVuIHVzZSDigJxNVVNUIE5PVOKAnSBhYm92ZS48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhh
bmtzITwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWx2YXJvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_8B6BA07AD6364D8C8B02A5CB05538AAFciscocom_--


From nobody Fri Dec  2 05:57:22 2016
Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C0A129722; Fri,  2 Dec 2016 05:57:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 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_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 b8Xd3o5N481A; Fri,  2 Dec 2016 05:57:18 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0100.outbound.protection.outlook.com [104.47.40.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7371296BF; Fri,  2 Dec 2016 05:57:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lvkunf7i3Agb3nE0Ddpm2hMeJbgZF3XDwYfyaFfV+UM=; b=b+JmpJLgFWRcJdLB2BHhy0DW4oF11jlObPkjEJp5JIu/T+2PZGX/wBpHEH3gBF/SZmSWwmwOLHwW/L0DX/dQ1t5dgBPnelTGZ9MQgbJkY5jrbOU1YOXAAx69AfyT93IdE7eknXRlUZ6/XOk9WM3eoshvsYuVEKJ88NFegIC6Te0=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from mhamas-sslvpn-nc.jnpr.net (66.129.241.13) by SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Fri, 2 Dec 2016 13:57:14 +0000
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
Date: Fri, 2 Dec 2016 08:57:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <AAC9E38F-BF0D-41D7-8871-9B89D31BC37B@juniper.net>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.13]
X-ClientProxiedBy: SN1PR17CA0070.namprd17.prod.outlook.com (10.163.3.166) To SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20)
X-MS-Office365-Filtering-Correlation-Id: 2c358a3d-cd6a-49c0-83c2-08d41abb1f8b
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR05MB2511;
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 3:U+UWl4bGnmL42mNQv05O4AjNnqo/wFgERPbWJ6KvyBPy85ZaRJBXkqIi9ojCjx/Dn7l+ZOdpwaX+gHU8MpM4mN9+CbJ41hgjlhCl/F8RqrOnkzWAmjB+Qya5gAgDYvP2p8+kc+8SuDNZcGWp7kZl+EHaCsZxsMoBcnhPibl78IYlEWLVaAbIoxdWilD76LKwha07kR9UY+IoGVuLEHiICRmN9UzKMZjj5MNVlpZm044pOCe5r8Jg/nYEzQBhZx+NgmA2o4gO+fMdM3C1qtEEAw==
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 25:mykcPBZhxL58tut6C25TMgxxBujK00JCkfJp9EoLPl9vdaIoUxF6NvTG+iNKZN0wvKje6gwtFSh5ema1nAnDLHUmuvQKUgJiMDj0i/ARBgaeV2qFJYx4EUgHlCL+r24aWh00sJjt0I2Ixbc3PSZEV8A4wsOzpurzVsrwj35VCCTPl8Pl7lDX3NB1gURYEe07wWaZ8HpQhR80T5V391Yd4xCizHWrW4MFN9TbccHvHA4IAuI8ntN4Pg5/fIg1TNfm/jY/ig16YiY3vFD/+3hNyrsIrl/uAldHsQm7xqLFTzhoZ6+1eGK4mo46pSkORLcZWJ4wefODMQycc+D0iqoyuCE34FgAHcAsd2JvIDHBsCxImlHF7sAQuaJqrx+skoZtVjZxxFojMCg6FgfnkO7Jxxn4mr3Fb3OfbDWAi5VZTSPaw/qAd4y9VGb2WHCvFniEzMAq+XnkWrnzZGCDmNLjda+ScAd8ActXpm+72gSglNtxYWMS8RzlUk34G2FMKEqgmUaH5HxvQMG9B7poeiMg+t/FEyrAObOOGIupdDiBePiLFdJWne7XCinVbzYqHcSY+5CwPY3OKvWnMrFTmFX75VBXz7Ufbh1bNd0uAJUsVs6cvHVoMz2mSikAd3N1ffPK6G1MY8vJQSSbseCnin8Zqq4imgiRFhp4q8EyoUzg44LPX4KgMoqBJiGVZZ+Y8f5kdp8z66I7nU1qTXj1ABKHhyJf5/lY/q97WbPKNJxqjJA=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 31:UXEOUocWKl8hIJSlzk+xUBRdQH6Vc1Jbix8+rWHomguWFi480Jgpvv+/JuKv0ZI9iQeqI3z9NF7HDVTkD3lzdY3FNg4E1RmtXyep6TAcV85YsR5Zxzo/4fNbavSjO+VHfiXcnm3zrB1+VM2U9LeXu4OHH6UDC9XjWJ3+aAwxHdb3Jw6L6eDO8zmLfKkxWs9yrU1I9MfHr2LDyena6R6Huylv7WDthhzo06whOWfFHAtYIfWGRjXHc6z16BOmiR/d29XCbAHmZqjAtVoTOheUCQ==; 20:F9Qf876GobStxPlaK8HBiMb4fKMTRrl9hWoQNbSXpHsMP2fcqqgCCx8inpTa7LqgSiTjptisbD52WUYYh5/oCi0lrrNnOq9B3FzeLueZU81N+auT+z8FA7VGojr8bF5wuwYqm+nlwB5qH6puTtRjsfZSI0UypTXtFQ1lIgptDpUHOrMOhjWr4Y3lyqX1mznV35Jv3id5avTGSVbKrkuNeJD5Jlaaw8W9F6peltgvz3Mcz4bUy20AIfWcns/H6zrkHf6kIrAT4kV/M/X3vl97c1FhhuGE4DtMaTM+P3m3BvQrbjOx4dw5qfgdul7nUh+unxpj0xWaukefnUSaSW2FRU3FIvJ1HWETINPWFBQnancuwa1XnhC1LeKvy+qXzntZfexA/+zgQxQDJRwzlAb4YJxxTKQzZX86U26GN9MFko/j3JGWNiuKGHsDKROqzGb8uOinwFpTz4/OGflnnMtcFWx62rj5cfD0EI3qWdYJP53RXInf5KVbta/JdPzJx3d0PWJDsgC9U8JijruA/z/fs8nSRkRc4fPuxi9pc/7CGkd9SKiALnpFhRNoe2KaJnx78harVgifEmYsEVWnfLK/OHzxi8oxEovdvb03UcD1scs=
X-Microsoft-Antispam-PRVS: <SN2PR05MB25113252FFDCCD02E76B37D1AA8E0@SN2PR05MB2511.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:SN2PR05MB2511; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2511; 
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 4:JLhpcbiSyauyu/7zYkteJcmTOhgCTBuHwUtfLXrPrSTgH1CnqMJ4Tyo2fT5x2Arx8/AYbXIVwWITMBb6WozQ4jhVy4LvS3gma890MtvkH6P6J7WlE8OdQqND95YptxZZRcN6JQzSStr8R6uvPY0b5E9oGY6TuoaWtwxyE9LSszYISF7vd9dSGxH6IPcsmsz3XSD3Rcq7nCzPQ9W/FVTa2noVy6Ig0XC20tfzBJWfr3qBvLatil0geMCRop1W4dwFqLRzI9qvUTHNrX2a+IDzMxbWmXxwh8YASnXggA1g1CkOV2rmxwhO0sgUxt/xnsXqgfMmfPw1Lbx75fQU9WVW2sqhqhv87H2hoBKFVyPdnS/K2MJqsy6ktVWH81y7gLig+MeNsPQsA80XNe4pCNRmDfZ40Y8IMCenAhjv1FXHAaxLtsppK++UQQkxYYTWptz04sIAESyycDGbGoq+IPsl5QJcn7DNIMHESXW3Bc0OATPmmRmmvDFMcqo1lqmeaf2srjUIyt6e6uhku/6I2rPvk02Yr6YgKwnHcJQ9ZP3oc/917TJMGpWRp3RJQGjpokwdCl24qh0r+C7mBllvvpO3ewcMlx7fCO+nUzXr3SHvsqUCo6u1TGE7ne3axdwfHHXPHKL3Pjwoe5B4CgPB01YGYw==
X-Forefront-PRVS: 0144B30E41
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(76104003)(189002)(377454003)(24454002)(33656002)(92566002)(6916009)(68736007)(2950100002)(57306001)(229853002)(86362001)(47776003)(110136003)(97736004)(36756003)(733004)(39410400001)(50226002)(230783001)(6486002)(69596002)(6116002)(81156014)(81166006)(8746002)(23676002)(6512004)(39450400002)(76176999)(50986999)(6506004)(8676002)(3846002)(6666003)(105586002)(106356001)(101416001)(42186005)(39060400001)(5660300001)(53416004)(38730400001)(50466002)(2906002)(7736002)(305945005)(83716003)(82746002)(7846002)(66066001)(189998001)(4326007)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2511; H:mhamas-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjJQUjA1TUIyNTExOzIzOjJLa09YLy94S3JuVWtyUkxOUVRWY2k1UFFj?= =?utf-8?B?aHQwWXpwZUdSZ2pmZEdIeVJwWEszY0RKR3VSbW9KVENjdVpBT3ZTdmxvaExU?= =?utf-8?B?VXVHMnZoKzJJY21IOW9qSG1EQ1FVWVpJMVJRSDlJZXJXUkxHRGw3aitnbnlS?= =?utf-8?B?ZlZLOTdmY242K3ZMZENoUzlJLzloS3ZXTytwK3BrTXlKbzd5NDQ2MzIvUjJZ?= =?utf-8?B?VzRKR1J2NU5NK1YvanRBRUJQbVdpd0JUdmZlTFlhbnJ2YTNrWlVRVmhLMWRK?= =?utf-8?B?a2FQeUhDQWxGTTVwWUZYcjdXNGdBN0FTWXdiWEhXR2x3NEdwNmE0VkgxMlRy?= =?utf-8?B?VnFNV3JKVllhREVraUNwU2tTejRzNzJEZStRdEZxVngwOXE4U3MzTjNSN2Rj?= =?utf-8?B?aXp3cnlTZlpYRElReEU1Z255OWxxY2xNb1FhaS9FeXhQRjRkamg4a2o5TzJh?= =?utf-8?B?eExJMldpZURCSVhHRXBGRkxWQ0I2aXg4WTFVcHR6SUgxTHNuQ2RGNUF2Vnpw?= =?utf-8?B?MXlyT2lmVFRjc0FPbVREcytvNEwvKzg0b1lhUmM0VkpDY1NCNEE1VTczVlpY?= =?utf-8?B?ZDl0SVdsWXFhVE1WbUc1Qml3ajJKbFRrTEtFNE5ZTk9ZY3FOMXE5a1pQcXZp?= =?utf-8?B?RWtaQkpaQWl6UXJ0VUgrQ1ZpdU5tcmgvZHdVc2RyUXpjZmJiWUpFeDRaUVVs?= =?utf-8?B?RHdUR1AzRXl5YytiZ1UxSlBldXQrMXJFRUh3T2F6SSt3WnBTNmU3aUIrYStJ?= =?utf-8?B?NG5RQWNlaU5ralJNRUlFdFAzelRiVUZSdTVHOXB4aWVhbEpMZXE1dTFJTHVX?= =?utf-8?B?RkdiRERxNVg1Q0oxSHZhdlNGVFFvalkrTDZ1ampoTk5GNU5pSEdEM2FaVnV4?= =?utf-8?B?YlJHT1h6ZFRZZHZnS2FCTnJuMWlxZkNBRHdVK2NnbjdkcFFzZlVOK2V5Vmpt?= =?utf-8?B?Q0QybGVHaTlnNVJIeGRQWUxmY0w5WXhuSXZNaDZiRlUwbmZYQ1YwUXN6OEhX?= =?utf-8?B?K1o4cmJzWVJmc1lSeTFaVEplZGtQQ2xMNGZPcXcyMUVMKy9CZDRQeXVzaG5Q?= =?utf-8?B?Q1g3eTZJNFJtZld2ZFRSNU0yUFQyOWVsS3lORER4dGw2OTYzTkZJNEZqWUxk?= =?utf-8?B?TnBjNFNDZElJMzExZURwZGo3NFozTC9VUy9sMEovSkpOYitudGR5N2hZUnZF?= =?utf-8?B?dDcrdVY0WUVMUEFPNDdyZjE2MmdGSTJ3cXgwNVRXZjFZbFJ6a2lDRG9DNnlL?= =?utf-8?B?TXQ3Z202ekl6bDlDbjlaQmFGYjYyMlFabndLbFFreWlOQjFRc001eVUxNWg5?= =?utf-8?B?dEE1amlJcWk1dlVGMHM5dDdERTN5ZmVGREFXRmRPbFdYTEQvTnJqaFN6ZzdV?= =?utf-8?B?SHFHWGxpL0hzem5aSXBBTGxrTXpVM1JzWGVpLzd1bGl6VGo2QWExc1RhVVdz?= =?utf-8?B?Vnd3eDJ4eVRVYm9xQnBibHdHZ0JSL1lDOThSY0lLTDZ6R2NhRVBpeGF1cXd5?= =?utf-8?B?bFBLL3RCZFZOT3FmOXhZTytNTnp2N2VWZ1RtSHJOMkhMNHpGWXR1UzNqYzNp?= =?utf-8?B?MnVib28xL0dDS0ZUWXNXbXdWK2tvRml3WWNhejdIanJqajk5bEJtY3o1cGZ1?= =?utf-8?B?YzhTbUVWOVlNOCtmQVFlZnZjZ3lKQml5SjhodUpseTF3UWxtbnZja3JHNEls?= =?utf-8?B?SkRpWEVUUjFnMjFPK295WGxXZEJMQ2FhYWQzWXltRnJTY3hPMVpjS2lBaUxh?= =?utf-8?B?U044N0NpVjI5blFDam5LZzVzMENWUk9sbTM0Mmh3bXBKYmc5LzBjRDFEQWJs?= =?utf-8?B?ajZGOWpCQkY2eTZDaU1WSUpWQWRxNStNM0JONlFwaitjQjl2c3AyU0t4UlYy?= =?utf-8?Q?bBwHD5O/6a+xIZ24MNsb4vOvFCesAB5z?=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 6:+cxpX84e7/nG7aEy4L+vN39VscUbC0h1tpwE4tdqUNTcTtp6RryUiWZ1C4YBzbM00f3Xjl/2UrESB3kgF6AgXVfDHi4W40sF9Etl+x1eJeQ7Yzyjfp08ljtkwFg/JQmRvhiJgYjmk1X7LS0dfIoehTxClv39wGa8csKvXuRPB3S/YGFN7Cjorh04vcJdiMHuN2YBmRRookJ1WaaK6xM7wvsX3Voq5v7ZvoldNwBrJFrMwGK+88bHLTAbaKRZOCFvbAHiPqzz53ZXfuwTiSVhaoNb3oTPgkvMLLADMosM/rhELQzXo2qmVdSN6pU9C9f7/6syaV3Hp7pjP1IRzxJ8Xz8NSZ8oBdOYbByygS7s8PFZ0V8eVTEpqrFLp4GOVl5BKmsbmx5A3DrmaWO+aYCn8TWBa/XmLnme/WQbpZW4hJjo3IOGrq7wUNTEbheL52lnabRHDdPQAJBhe/A7/2TUtvZgC5ri1dDzJWtcjG6rqKnsB82M9/4FvlDe3QoLqhw/; 5:HZM4Y5HtpOR5L6Kc58dZQKGdkbpqwBXB0O64cFM3UPYLRw0Z1oEsy0MaVqexslIdepawbEwF0d5JWhSEYluF8iTjSXOvzI9WTHCAvx1B3bAQp2fBg0RUwDrWTnlKQQQ8PDpLv7v52Mp8gOm+pnaNXw==; 24:6P/P4dM9TMnRc4f1s0QEO4FeDiGBz0BE7Sh6fXWLD1YWbvkdp/7dpPYyVtmvWlCf+YXQwzl1wQ1+BM4jr9UfcSyC6yergR2QUGaTTf7YOwQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 7:/9yI6ZKPCur38a5RpJ0BIAbkm6PuMRdOP0cRxZygS2DYS4t5+2I/HlAeJorGVuSv9lHKgG01aAjhuQ9TObFDWeSIQn5A1ylQVU9SBrz1lixpJvA1PVjNZb7NoF9vJaGKW7IzdbnB8S26kLNW46xQP1H3AHiZTjdCw0lUqUBU8b8YTy9cK9b1EMk8TRgLf0JtfgHUjynjAlTo9cQAgrOxZ3CmAe5/6tho3W7IS7UGwUUB/uAet7YRtSGOq/IoqOUBjcJFoaMDRqBQK2Huy/7Zt2/ejJZpRJrEItMaiOdwO476eCxMmFSUgfV9mjUECIGC1bv5aG4SGQ/NtePyy76eGPHKloFx4J8bMlrr/euZ1hW3TbT6OSe1SpWLPNjAuebZbU82vU3w/C5cdYb1O0HOjseX5z4IJdwlhH9zFhmSPOV962DKYDg3WGSOmoCzjuME3LCCy3r22H4C7YT8IATDVw==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2016 13:57:14.9500 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2511
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/b5vGmlXOVsLR79REHhVJkZXLK9M>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 13:57:21 -0000

On Dec 2, 2016, at 8:46 AM, Alvaro Retana (aretana) <aretana@cisco.com> =
wrote:
> Removing and ignoring are obviously different things=E2=80=A6  The =
text above is fine with me, but I would ask: what do the current =
implementations do?  If they remove (as originally specified), then I =
would suggest you keep that.

What do you think would be a good minimal change to clarify? How about =
changing the word "duplicate" to "redundant"?

OLD:
   Duplicate BGP Large Community values MUST NOT be transmitted.  A
   receiving speaker MUST silently remove duplicate BGP Large Community
   values from a BGP Large Community attribute.

NEW:
   Duplicate BGP Large Community values MUST NOT be transmitted.  A
   receiving speaker MUST silently remove redundant BGP Large Community
   values from a BGP Large Community attribute.

--John=


From nobody Fri Dec  2 06:01:48 2016
Return-Path: <aretana@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C051294C4; Fri,  2 Dec 2016 06:01:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level: 
X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 9rjrsZO7n5R9; Fri,  2 Dec 2016 06:01:46 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B3D1294BF; Fri,  2 Dec 2016 06:01:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9306; q=dns/txt; s=iport; t=1480687305; x=1481896905; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NUdbg6bq6G6bAf3+FKJD0UwSKMpZKWE3wHLM8h57K6U=; b=fe6YQkRcFzlmWCH3QuDi8k10FsMQqcTYHhbiqiQsBGYEKX2U1+E+ouQo y5v5ymlpGkP5CTRHtZAJnKYra3dcbMG34PUiAmz/ERfiupd+XIv2msRN4 ghIiyot2vtJqqhJu4GUTxX+pNF9agmo9+zQ6t+oTXs8Z8Uw9jDTwgW1RP 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQDBfUFY/4sNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNFAQEBAQEfWoEGB40/pmWFIoIGhiICGoF+PxQBAgEBAQEBAQFiKIR?= =?us-ascii?q?pBiNWEAIBCD8DAgICMBQRAgQOBRSIW6x1gikviw0BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEchj6BfYJeh00tgjAFlHqFaQGRE5A5jgCEDAEfN4EZMQEBhSJyhkEGgSq?= =?us-ascii?q?BDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.33,729,1477958400";  d="scan'208,217";a="355861910"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2016 14:01:44 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uB2E1h4M012184 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 14:01:44 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 08:01:43 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 2 Dec 2016 08:01:43 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "John G. Scudder" <jgs@juniper.net>
Thread-Topic: AD Review of draft-ietf-idr-large-community-09
Thread-Index: AQHSTFEplUv+tL/kGUyk1NyWV0fUzaD0l0wAgAAl5QCAAFayAP//rXUA
Date: Fri, 2 Dec 2016 14:01:43 +0000
Message-ID: <45E0BA2C-D626-4C8C-85BC-42792C8B062B@cisco.com>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com> <AAC9E38F-BF0D-41D7-8871-9B89D31BC37B@juniper.net>
In-Reply-To: <AAC9E38F-BF0D-41D7-8871-9B89D31BC37B@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: multipart/alternative; boundary="_000_45E0BA2CD6264C8C85BC42792C8B062Bciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/tZdF8As-oXW2fJe0vWwLGajujeo>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 14:01:48 -0000

--_000_45E0BA2CD6264C8C85BC42792C8B062Bciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhdCB3b3JrcyBmb3IgbWUgdG9vLg0KDQpPbiAxMi8yLzE2LCA4OjU3IEFNLCAiSm9obiBHLiBT
Y3VkZGVyIiA8amdzQGp1bmlwZXIubmV0PG1haWx0bzpqZ3NAanVuaXBlci5uZXQ+PiB3cm90ZToN
Cg0KT24gRGVjIDIsIDIwMTYsIGF0IDg6NDYgQU0sIEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIDxh
cmV0YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+PiB3cm90ZToNClJlbW92
aW5nIGFuZCBpZ25vcmluZyBhcmUgb2J2aW91c2x5IGRpZmZlcmVudCB0aGluZ3PigKYgIFRoZSB0
ZXh0IGFib3ZlIGlzIGZpbmUgd2l0aCBtZSwgYnV0IEkgd291bGQgYXNrOiB3aGF0IGRvIHRoZSBj
dXJyZW50IGltcGxlbWVudGF0aW9ucyBkbz8gIElmIHRoZXkgcmVtb3ZlIChhcyBvcmlnaW5hbGx5
IHNwZWNpZmllZCksIHRoZW4gSSB3b3VsZCBzdWdnZXN0IHlvdSBrZWVwIHRoYXQuDQoNCldoYXQg
ZG8geW91IHRoaW5rIHdvdWxkIGJlIGEgZ29vZCBtaW5pbWFsIGNoYW5nZSB0byBjbGFyaWZ5PyBI
b3cgYWJvdXQgY2hhbmdpbmcgdGhlIHdvcmQgImR1cGxpY2F0ZSIgdG8gInJlZHVuZGFudCI/DQoN
Ck9MRDoNCiAgIER1cGxpY2F0ZSBCR1AgTGFyZ2UgQ29tbXVuaXR5IHZhbHVlcyBNVVNUIE5PVCBi
ZSB0cmFuc21pdHRlZC4gIEENCiAgIHJlY2VpdmluZyBzcGVha2VyIE1VU1Qgc2lsZW50bHkgcmVt
b3ZlIGR1cGxpY2F0ZSBCR1AgTGFyZ2UgQ29tbXVuaXR5DQogICB2YWx1ZXMgZnJvbSBhIEJHUCBM
YXJnZSBDb21tdW5pdHkgYXR0cmlidXRlLg0KDQpORVc6DQogICBEdXBsaWNhdGUgQkdQIExhcmdl
IENvbW11bml0eSB2YWx1ZXMgTVVTVCBOT1QgYmUgdHJhbnNtaXR0ZWQuICBBDQogICByZWNlaXZp
bmcgc3BlYWtlciBNVVNUIHNpbGVudGx5IHJlbW92ZSByZWR1bmRhbnQgQkdQIExhcmdlIENvbW11
bml0eQ0KICAgdmFsdWVzIGZyb20gYSBCR1AgTGFyZ2UgQ29tbXVuaXR5IGF0dHJpYnV0ZS4NCg0K
LS1Kb2huDQo=

--_000_45E0BA2CD6264C8C85BC42792C8B062Bciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <4F972BA671A06846ADB2D4EDF245EBDC@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE
ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K
CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl
cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTph
cHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsN
Cglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4
dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJ
e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug
V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx
LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OkNhbGlicmkiPlRoYXQgd29ya3MgZm9yIG1lIHRvby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90
ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRk
aW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGlu
Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5PbiAx
Mi8yLzE2LCA4OjU3IEFNLCAmcXVvdDtKb2huIEcuIFNjdWRkZXImcXVvdDsgJmx0OzxhIGhyZWY9
Im1haWx0bzpqZ3NAanVuaXBlci5uZXQiPmpnc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+T24gRGVjIDIsIDIwMTYsIGF0IDg6NDYg
QU0sIEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpICZsdDs8YSBocmVmPSJtYWlsdG86YXJldGFuYUBj
aXNjby5jb20iPmFyZXRhbmFAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1s
ZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f
QkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlJlbW92aW5n
IGFuZCBpZ25vcmluZyBhcmUgb2J2aW91c2x5IGRpZmZlcmVudCB0aGluZ3PigKYmbmJzcDsmbmJz
cDtUaGUgdGV4dCBhYm92ZSBpcyBmaW5lIHdpdGggbWUsIGJ1dCBJIHdvdWxkIGFzazogd2hhdCBk
byB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgZG8/Jm5ic3A7Jm5ic3A7SWYgdGhleSByZW1v
dmUgKGFzIG9yaWdpbmFsbHkNCiBzcGVjaWZpZWQpLCB0aGVuIEkgd291bGQgc3VnZ2VzdCB5b3Ug
a2VlcCB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+V2hhdCBk
byB5b3UgdGhpbmsgd291bGQgYmUgYSBnb29kIG1pbmltYWwgY2hhbmdlIHRvIGNsYXJpZnk/IEhv
dyBhYm91dCBjaGFuZ2luZyB0aGUgd29yZCAmcXVvdDtkdXBsaWNhdGUmcXVvdDsgdG8gJnF1b3Q7
cmVkdW5kYW50JnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+T0xEOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4m
bmJzcDsmbmJzcDsgRHVwbGljYXRlIEJHUCBMYXJnZSBDb21tdW5pdHkgdmFsdWVzIE1VU1QgTk9U
IGJlIHRyYW5zbWl0dGVkLiZuYnNwOyZuYnNwO0E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHJlY2Vp
dmluZyBzcGVha2VyIE1VU1Qgc2lsZW50bHkgcmVtb3ZlIGR1cGxpY2F0ZSBCR1AgTGFyZ2UgQ29t
bXVuaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s
YXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB2YWx1ZXMgZnJvbSBhIEJHUCBMYXJnZSBDb21t
dW5pdHkgYXR0cmlidXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+TkVXOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4m
bmJzcDsmbmJzcDsgRHVwbGljYXRlIEJHUCBMYXJnZSBDb21tdW5pdHkgdmFsdWVzIE1VU1QgTk9U
IGJlIHRyYW5zbWl0dGVkLiZuYnNwOyZuYnNwO0E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHJlY2Vp
dmluZyBzcGVha2VyIE1VU1Qgc2lsZW50bHkgcmVtb3ZlIHJlZHVuZGFudCBCR1AgTGFyZ2UgQ29t
bXVuaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s
YXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB2YWx1ZXMgZnJvbSBhIEJHUCBMYXJnZSBDb21t
dW5pdHkgYXR0cmlidXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+LS1Kb2huPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_45E0BA2CD6264C8C85BC42792C8B062Bciscocom_--


From nobody Fri Dec  2 06:31:02 2016
Return-Path: <ibagdona.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A276129FAC; Fri,  2 Dec 2016 06:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JDH-YkdNebC8; Fri,  2 Dec 2016 06:30:57 -0800 (PST)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 5C0D1129FA8; Fri,  2 Dec 2016 06:30:57 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id d2so53129854pfd.0; Fri, 02 Dec 2016 06:30:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=9Dq+o0S0YYg7/nbZyd4lun20R99tHIIJ7a/5uFEwsLs=; b=GUFLBk/wqEOjpc3WOpm8wJfUEecCsphNJoXY7QKIvWmLA9hZTf/g8AzRPcVmLm4h3g dV/VrlYFJnurX6rW55/vN78z3AFFMuW2wiNTrL5zB4YDRCgKrUbsRmiNtWi/UpVtsGBw k7Nb3koyjS9IQ7UwtFtyOgHqQ7a40MwNBcIeQy3cQw8OJmr+a3r+P60803owBTiq+wjQ v1W90/8Ed/Kikfp0jng6NuM3BHHvd6pOlIrynYAH2cygLxQ+Yt5C4tnKRJfUVjFOCMQ9 gLQvTmRIsF+hP29DUzqcovEwFsgeSVutQMscXurg6LKVJBA1r7XtQ/H5beqXF6IybBbV Fh7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=9Dq+o0S0YYg7/nbZyd4lun20R99tHIIJ7a/5uFEwsLs=; b=Yh74nickXadI3aVmfhOBMdFA0oNtveA/Ud/QpQmrdXSVTKaiUCsCBEh6o5wUdFgowW GnbJ/NQnskiKkZQWeFpIlNmZ36Fvg/dC2wvFQAjjxENKI/Fy3Kibvf/TTZS5sI8M6cYe 9dN2ZGYukshvW+77lBtbRocXDORJMp8n9v36wdpojiyw+iYTjPusL9IC3PGFAyQSOdok zdRfTxR9KYTBD6/Y7WNU5bX7qW5vigBpQeemeXClr3x3DQzO+Gnroix4Ajsr7oteh65Q T0pXilLuM9GIFNrFp863/ODnUbp4OO09vUufUdrMJBZ2OfHiGm1s1o5HXX0l6JB5d1BY vKhQ==
X-Gm-Message-State: AKaTC03QnLETAwstXbaHpXgP7dCelc40mlGyk/w0IPccEwaQsqnxgVIfvSQZzYUxDTrmKg==
X-Received: by 10.84.216.20 with SMTP id m20mr97139135pli.126.1480689056678; Fri, 02 Dec 2016 06:30:56 -0800 (PST)
Received: from [172.16.184.157] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id b71sm8324628pfj.62.2016.12.02.06.30.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 06:30:56 -0800 (PST)
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
From: Ignas Bagdonas <ibagdona.ietf@gmail.com>
Message-ID: <419db8cd-e4ae-a191-bfd3-8e35ca76b0cd@gmail.com>
Date: Fri, 2 Dec 2016 14:30:52 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
Content-Type: multipart/alternative; boundary="------------49A8A1F331DCF15197B60807"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WM6ny_-BytRddof0dNyuSHvxiI4>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 14:31:00 -0000

This is a multi-part message in MIME format.
--------------49A8A1F331DCF15197B60807
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Alvaro,


> > The intention is to react on the first instance of the duplicate 
> community - analogous to applying
>
> > RFC7606 to the contents of the large community path attribute 
> itself. Would a following text address
>
> > your comment:
>
> >
>
> > A receiving speaker MUST act on the first instance of duplicate BGP 
> Large Community value, and
>
> > MUST silently ignore any other occurrence of such duplicated values. 
> Duplicate BGP Large
>
> > Community values MUST NOT be transmitted.
>
> >
>
> > This reverses the receive and transmit handling - ignore any 
> subsequent duplicate community values
>
> > and do not send duplicates. Whether an implementation actually 
> removes anything or just ignores is
>
> > an internal matter to the implementation.
>
> Removing and ignoring are obviously different things…  The text above 
> is fine with me, but I would ask: what do the current implementations 
> do?  If they remove (as originally specified), then I would suggest 
> you keep that.
>

The implementations that I am familiar with do interpret first instance 
of the community value and do not react (=ignore) any other instances of 
the same community value on the receive side. Whether it is truly first 
instance as it appears on the wire or the first instance of the sorted 
received community is an implementation detail, the outcome is that 
single community value is interpreted only once. Therefore on the 
transmit side there are no duplicate values. This is based on decoding, 
processing, and then encoding the community attribute and not forwarding 
it as a binary object only - I am not aware of any implementation that 
does that. Could anyone familiar with implementations that behave 
differently please speak up?


> > > C2. There seems to be a contradiction in the expected use of 
> reserved Global Administrator
>
> > > values.  Section 2 says that the “Global Administrator 
> field…SHOULD either be one of the reserved
>
> > > values as defined below, or an Autonomous System Number (ASN)”, 
> but later Section 5 says: “The
>
> > > following Global Administrator values are reserved: 0, 65535, and 
> 4294967295.  Operators SHOULD
>
> > > NOT use these Global Administrator values.”   IOW: “SHOULD use one 
> if the reserved values” and
>
> > > “SHOULD NOT use the reserved values” contradict each other.  It 
> seems to me that because 0,
>
> > > 65535, and 4294967295 are already reserved ASNs, *and* that “the 
> Local Data Parts are to be
>
> > > interpreted as defined by the owner of the ASN”, then only 
> assigned ASNs should ever be used ---
>
> > > *and* given that it is not an error to use an value, then there is 
> no real advantage in reserving
>
> > > anything (again!). Suggestion: reference the RFCs where 0, 65535, 
> and 4294967295 are reserved
>
> > > and just say that those numbers SHOULD NOT be used because if a 
> Special Use Large Community is
>
> > > ever defined, those values may be used.
>
> >
>
> > For section 2: Global Administrator field SHOULD be an Autonomous 
> System Number (ASN) or one of
>
> > the reserved values defined in Section 5.
>
> >
>
> > For section 5: Global Administrator values corresponding to reserved 
> use Autonomous System
>
> > Number values of 0 [RFC7607], 65535 [RFC7300], and 4294967295 
> [RFC7300] are reserved.
>
> >
>
> > Would this work?
>
> Question for you:  do you want the operators to use 0, 65535, and 
> 4294967295 whenever they want (which is what the new text says), OR, 
> do you want them not to use them because they could be used later for 
> a special purpose (which is what the original text seemed to indicate)??
>

Communities - any type, standard, extended, large, wide - for practical 
cases are aligned with AS numbers. As there are reserved AS numbers that 
potentially could be used for some future extensibility functionality, 
in the same way community values equal to those AS numbers are reserved 
for potential future extensibility - it is a mechanism to ensure 
functional parity of the namespaces for AS numbers and community values. 
My personal interpretation of the new text for sections 2 and 5 is that 
reserved values could be present in the global administrator field but 
then in that case local parts have specific, predefined meaning and are 
not used for arbitrary values (that meaning is not defined today 
though). Therefore as AS number values of 0, 65535 and 0xffffffff are 
reserved and should not be used as defined today (this is the key part - 
today), corresponding community values should follow the same procedure.


> I’m having a hard time with this document “reserving” any value 
> because the number space is not really one where values are assigned 
> (in the typical IANA sense: create a registry, etc. – and I doubt you 
> want to make it that way)…but the contents can be (SHOULD) what is 
> contained in an already existing registry (ASNs) that has distributed 
> control.
>
Indeed the intention is not to define a new registry if that can be 
avoided. Community values follow AS number values (technically it is 
just an uint32_t number that has an interpretation of AS number value).



> Assuming that you would prefer the operators NOT to use 0, 65535, and 
> 4294967295, then here’s my suggestion:
>
Yes, the intention is exactly that - reserved values should not be used.

> OLD> (Section 2)
>
>    The Global Administrator field is intended to allow different
>
>    Autonomous Systems to define BGP Large Communities without collision.
>
>    This field SHOULD either be one of the reserved values as defined
>
>    below, or an Autonomous System Number (ASN).  If it is a reserved
>
>    value, then the Local Data Parts are as defined by the reserved
>
>    value.  If it is an ASN then the Local Data Parts are to be
>
>    interpreted as defined by the owner of the ASN.
>
> NEW>
>
>    The Global Administrator field is intended to allow different
>
>    Autonomous Systems to define BGP Large Communities without collision.
>
>    This field SHOULD be an Autonomous System Number (ASN).  The use of
>
>    Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT
>
>    RECOMMENDED.
>
> …and then eliminate Section 5…
>
> If you really want operators not to use the Reserved ASNs ever because 
> a special use may be though up later, then use “MUST NOT” above.
>

Personally I agree with this text.


Ignas


--------------49A8A1F331DCF15197B60807
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Alvaro,</p>
    <p><br>
      <o:p></o:p></p>
    <blockquote
      cite="mid:8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com"
      type="cite">
      <div class="WordSection1">&gt; The intention is to react on the
        first instance of the duplicate community - analogous to
        applying
        <p class="MsoPlainText">&gt; RFC7606 to the contents of the
          large community path attribute itself. Would a following text
          address
        </p>
        <p class="MsoPlainText">&gt; your comment: <o:p></o:p></p>
        <p class="MsoPlainText">&gt;<o:p> </o:p></p>
        <p class="MsoPlainText">&gt; A receiving speaker MUST act on the
          first instance of duplicate BGP Large Community value, and
        </p>
        <p class="MsoPlainText">&gt; MUST silently ignore any other
          occurrence of such duplicated values. Duplicate BGP Large
        </p>
        <p class="MsoPlainText">&gt; Community values MUST NOT be
          transmitted. <o:p></o:p></p>
        <p class="MsoPlainText">&gt;<o:p> </o:p></p>
        <p class="MsoPlainText">&gt; This reverses the receive and
          transmit handling - ignore any subsequent duplicate community
          values
        </p>
        <p class="MsoPlainText">&gt; and do not send duplicates. Whether
          an implementation actually removes anything or just ignores is
        </p>
        <p class="MsoPlainText">&gt; an internal matter to the
          implementation. <o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">Removing and ignoring are obviously
          different things…  The text above is fine with me, but I would
          ask: what do the current implementations do?  If they remove
          (as originally specified), then I would suggest you keep that.<o:p></o:p></p>
      </div>
    </blockquote>
    <br>
    The implementations that I am familiar with do interpret first
    instance of the community value and do not react (=ignore) any other
    instances of the same community value on the receive side. Whether
    it is truly first instance as it appears on the wire or the first
    instance of the sorted received community is an implementation
    detail, the outcome is that single community value is interpreted
    only once. Therefore on the transmit side there are no duplicate
    values. This is based on decoding, processing, and then encoding the
    community attribute and not forwarding it as a binary object only -
    I am not aware of any implementation that does that. Could anyone
    familiar with implementations that behave differently please speak
    up? <br>
     <br>
    <br>
    <blockquote
      cite="mid:8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoPlainText">&gt; &gt; C2. There seems to be a
          contradiction in the expected use of reserved Global
          Administrator
        </p>
        <p class="MsoPlainText">&gt; &gt; values.  Section 2 says that
          the “Global Administrator field…SHOULD either be one of the
          reserved
        </p>
        <p class="MsoPlainText">&gt; &gt; values as defined below, or an
          Autonomous System Number (ASN)”, but later Section 5 says:
          “The
        </p>
        <p class="MsoPlainText">&gt; &gt; following Global Administrator
          values are reserved: 0, 65535, and 4294967295.  Operators
          SHOULD
        </p>
        <p class="MsoPlainText">&gt; &gt; NOT use these Global
          Administrator values.”   IOW: “SHOULD use one if the reserved
          values” and
        </p>
        <p class="MsoPlainText">&gt; &gt; “SHOULD NOT use the reserved
          values” contradict each other.  It seems to me that because 0,
        </p>
        <p class="MsoPlainText">&gt; &gt; 65535, and 4294967295 are
          already reserved ASNs, *and* that “the Local Data Parts are to
          be
        </p>
        <p class="MsoPlainText">&gt; &gt; interpreted as defined by the
          owner of the ASN”, then only assigned ASNs should ever be used
          ---
        </p>
        <p class="MsoPlainText">&gt; &gt; *and* given that it is not an
          error to use an value, then there is no real advantage in
          reserving
        </p>
        <p class="MsoPlainText">&gt; &gt; anything (again!). Suggestion:
          reference the RFCs where 0, 65535, and 4294967295 are reserved
        </p>
        <p class="MsoPlainText">&gt; &gt; and just say that those
          numbers SHOULD NOT be used because if a Special Use Large
          Community is
        </p>
        <p class="MsoPlainText">&gt; &gt; ever defined, those values may
          be used.<o:p></o:p></p>
        <p class="MsoPlainText">&gt;<o:p> </o:p></p>
        <p class="MsoPlainText">&gt; For section 2: Global Administrator
          field SHOULD be an Autonomous System Number (ASN) or one of
        </p>
        <p class="MsoPlainText">&gt; the reserved values defined in
          Section 5. <o:p></o:p></p>
        <p class="MsoPlainText">&gt;<o:p> </o:p></p>
        <p class="MsoPlainText">&gt; For section 5: Global Administrator
          values corresponding to reserved use Autonomous System
        </p>
        <p class="MsoPlainText">&gt; Number values of 0 [RFC7607], 65535
          [RFC7300], and 4294967295 [RFC7300] are reserved.
          <o:p></o:p></p>
        <p class="MsoPlainText">&gt;<o:p> </o:p></p>
        <p class="MsoPlainText">&gt; Would this work? <o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">Question for you:  do you want the
          operators to use 0, 65535, and 4294967295 whenever they want
          (which is what the new text says), OR, do you want them not to
          use them because they could be used later for a special
          purpose (which is what the original text seemed to indicate)??</p>
      </div>
    </blockquote>
    <br>
    Communities - any type, standard, extended, large, wide - for
    practical cases are aligned with AS numbers. As there are reserved
    AS numbers that potentially could be used for some future
    extensibility functionality, in the same way community values equal
    to those AS numbers are reserved for potential future extensibility
    - it is a mechanism to ensure functional parity of the namespaces
    for AS numbers and community values. My personal interpretation of
    the new text for sections 2 and 5 is that reserved values could be
    present in the global administrator field but then in that case
    local parts have specific, predefined meaning and are not used for
    arbitrary values (that meaning is not defined today though).
    Therefore as AS number values of 0, 65535 and 0xffffffff are
    reserved and should not be used as defined today (this is the key
    part - today), corresponding community values should follow the same
    procedure.  <br>
    <br>
    <br>
    <blockquote
      cite="mid:8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">I’m having a hard time with this
          document “reserving” any value because the number space is not
          really one where values are assigned (in the typical IANA
          sense: create a registry, etc. – and I doubt you want to make
          it that way)…but the contents can be (SHOULD) what is
          contained in an already existing registry (ASNs) that has
          distributed control.</p>
      </div>
    </blockquote>
    <div class="WordSection1">
      <p class="MsoPlainText"><o:p>Indeed the intention is not to define
          a new registry if that can be avoided. Community values follow
          AS number values (technically it is just an uint32_t number
          that has an interpretation of AS number value).  <br>
        </o:p></p>
    </div>
    <br>
    <br>
    <blockquote
      cite="mid:8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoPlainText">Assuming that you would prefer the
          operators NOT to use 0, 65535, and 4294967295, then here’s my
          suggestion:</p>
      </div>
    </blockquote>
    Yes, the intention is exactly that - reserved values should not be
    used. <br>
    <br>
    <blockquote
      cite="mid:8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoPlainText">OLD&gt; (Section 2)</p>
        <p class="MsoPlainText">   The Global Administrator field is
          intended to allow different<o:p></o:p></p>
        <p class="MsoPlainText">   Autonomous Systems to define BGP
          Large Communities without collision.<o:p></o:p></p>
        <p class="MsoPlainText">   This field SHOULD either be one of
          the reserved values as defined<o:p></o:p></p>
        <p class="MsoPlainText">   below, or an Autonomous System Number
          (ASN).  If it is a reserved<o:p></o:p></p>
        <p class="MsoPlainText">   value, then the Local Data Parts are
          as defined by the reserved<o:p></o:p></p>
        <p class="MsoPlainText">   value.  If it is an ASN then the
          Local Data Parts are to be<o:p></o:p></p>
        <p class="MsoPlainText">   interpreted as defined by the owner
          of the ASN.<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">NEW&gt; </p>
        <p class="MsoPlainText">   The Global Administrator field is
          intended to allow different<o:p></o:p></p>
        <p class="MsoPlainText">   Autonomous Systems to define BGP
          Large Communities without collision.<o:p></o:p></p>
        <p class="MsoPlainText">   This field SHOULD be an Autonomous
          System Number (ASN).  The use of
        </p>
        <p class="MsoPlainText">   Reserved ASNs (0 [RFC7607], 65535 and
          4294967295 [RFC7300]) is NOT
        </p>
        <p class="MsoPlainText">   RECOMMENDED.</p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">…and then eliminate Section 5…</p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">If you really want operators not to use
          the Reserved ASNs ever because a special use may be though up
          later, then use “MUST NOT” above.</p>
      </div>
    </blockquote>
    <br>
    Personally I agree with this text.  <br>
    <br>
    <br>
    Ignas<br>
    <br>
  </body>
</html>

--------------49A8A1F331DCF15197B60807--


From nobody Fri Dec  2 07:30:12 2016
Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AF112953C; Fri,  2 Dec 2016 07:30:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level: 
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 KCEHBO4zOHGC; Fri,  2 Dec 2016 07:30:08 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA701294E7; Fri,  2 Dec 2016 07:30:08 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 155C31E341; Fri,  2 Dec 2016 10:33:30 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_EAA0D612-4221-4967-ACCA-AA94BA02A7BE"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <419db8cd-e4ae-a191-bfd3-8e35ca76b0cd@gmail.com>
Date: Fri, 2 Dec 2016 10:30:07 -0500
Message-Id: <477C42EC-359B-41DC-BCEC-9130A245DD67@pfrc.org>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com> <419db8cd-e4ae-a191-bfd3-8e35ca76b0cd@gmail.com>
To: Ignas Bagdonas <ibagdona.ietf@gmail.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CI4svCmz4cYlsW6XPy5Odfim9CE>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 15:30:11 -0000

--Apple-Mail=_EAA0D612-4221-4967-ACCA-AA94BA02A7BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Dec 2, 2016, at 9:30 AM, Ignas Bagdonas <ibagdona.ietf@gmail.com> =
wrote:
>=20
>> Removing and ignoring are obviously different things=E2=80=A6  The =
text above is fine with me, but I would ask: what do the current =
implementations do?  If they remove (as originally specified), then I =
would suggest you keep that.
>>=20
>=20
> The implementations that I am familiar with do interpret first =
instance of the community value and do not react (=3Dignore) any other =
instances of the same community value on the receive side. Whether it is =
truly first instance as it appears on the wire or the first instance of =
the sorted received community is an implementation detail, the outcome =
is that single community value is interpreted only once. Therefore on =
the transmit side there are no duplicate values. This is based on =
decoding, processing, and then encoding the community attribute and not =
forwarding it as a binary object only - I am not aware of any =
implementation that does that. Could anyone familiar with =
implementations that behave differently please speak up?=20

Implementations that tend toward memory conserving typically implement =
it this way:
- Sort the elements.  (They have set semantics, so order is irrelevant.)
- Remove duplicate entries (redundant as John says)
- Having done the above, check against a data store for a previously =
existing version.  If it exists, simply bump its refcount.

The above gives the property of "discard redundant on receive".  If a =
similar canonicalization is done on entries that are to be sent with =
routes, it also removes duplicates/redundant entries on send.

Modern languages in many cases provide "set" semantics and would =
similarly give the above properties a bit more automatically.

That said, implementations need neither use modern languages (or =
mechanisms in those languages) or might not be memory conserving.  Thus, =
the text recommending removing redundant entries is still a good idea.

-- Jeff


--Apple-Mail=_EAA0D612-4221-4967-ACCA-AA94BA02A7BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Dec 2, 2016, at 9:30 AM, Ignas Bagdonas &lt;<a =
href=3D"mailto:ibagdona.ietf@gmail.com" =
class=3D"">ibagdona.ietf@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"Singleton"><blockquote =
cite=3D"mid:8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com" type=3D"cite" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
background-color: rgb(255, 255, 255);" class=3D""><div =
class=3D"WordSection1"><p class=3D"MsoPlainText">Removing and ignoring =
are obviously different things=E2=80=A6&nbsp; The text above is fine =
with me, but I would ask: what do the current implementations do?&nbsp; =
If they remove (as originally specified), then I would suggest you keep =
that.<o:p class=3D""></o:p></p></div></blockquote><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);" =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: =
rgb(255, 255, 255); float: none; display: inline !important;" =
class=3D"">The implementations that I am familiar with do interpret =
first instance of the community value and do not react (=3Dignore) any =
other instances of the same community value on the receive side. Whether =
it is truly first instance as it appears on the wire or the first =
instance of the sorted received community is an implementation detail, =
the outcome is that single community value is interpreted only once. =
Therefore on the transmit side there are no duplicate values. This is =
based on decoding, processing, and then encoding the community attribute =
and not forwarding it as a binary object only - I am not aware of any =
implementation that does that. Could anyone familiar with =
implementations that behave differently please speak up?<span =
class=3D"Apple-converted-space">&nbsp;</span></span></div></div></blockquo=
te></div><br class=3D""><div class=3D"">Implementations that tend toward =
memory conserving typically implement it this way:</div><div class=3D"">- =
Sort the elements. &nbsp;(They have set semantics, so order is =
irrelevant.)</div><div class=3D"">- Remove duplicate entries (redundant =
as John says)</div><div class=3D"">- Having done the above, check =
against a data store for a previously existing version. &nbsp;If it =
exists, simply bump its refcount.</div><div class=3D""><br =
class=3D""></div><div class=3D"">The above gives the property of =
"discard redundant on receive". &nbsp;If a similar canonicalization is =
done on entries that are to be sent with routes, it also removes =
duplicates/redundant entries on send.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Modern languages in many cases provide =
"set" semantics and would similarly give the above properties a bit more =
automatically.</div><div class=3D""><br class=3D""></div><div =
class=3D"">That said, implementations need neither use modern languages =
(or mechanisms in those languages) or might not be memory conserving. =
&nbsp;Thus, the text recommending removing redundant entries is still a =
good idea.</div><div class=3D""><br class=3D""></div><div class=3D"">-- =
Jeff</div><div class=3D""><br class=3D""></div></body></html>=

--Apple-Mail=_EAA0D612-4221-4967-ACCA-AA94BA02A7BE--


From nobody Fri Dec  2 07:36:54 2016
Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402A91294E5 for <idr@ietfa.amsl.com>; Fri,  2 Dec 2016 07:36:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 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_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 4ILEWDdQbxWk for <idr@ietfa.amsl.com>; Fri,  2 Dec 2016 07:36:50 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0102.outbound.protection.outlook.com [104.47.40.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D8612951E for <idr@ietf.org>; Fri,  2 Dec 2016 07:36:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gc+JjkTxKzd/w3vMtT10FjIH/rCDG/a2wJonBQ7DLPY=; b=funlyWktPxXPKd0qiABgB4YrPPw6JGKp3fWUYAfl7RmnYjh+b7+bZ6ejzTYTzfhdLucSelWnn1tDUmrbl3NTftaTt29CGG8HdieT8YHQ/k5ya9+pTEOniRyN3itk9JAygnonYYYiZb+uxjkiPB8tCNl9wRETLqhDD3nDlE0FVAE=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from mhamas-sslvpn-nc.jnpr.net (66.129.241.13) by BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Fri, 2 Dec 2016 15:36:47 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <923B7CD5-944B-498A-895D-0948F8BA35C4@pfrc.org>
Date: Fri, 2 Dec 2016 10:36:42 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <7B22AFC3-9294-419B-B26F-BAF5C74F793A@juniper.net>
References: <148066816412.29721.1965835415134602483.idtracker@ietfa.amsl.com> <923B7CD5-944B-498A-895D-0948F8BA35C4@pfrc.org>
To: Jeffrey Haas <jhaas@pfrc.org>
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.241.13]
X-ClientProxiedBy: SN1PR17CA0046.namprd17.prod.outlook.com (10.163.3.142) To BN3PR05MB2498.namprd05.prod.outlook.com (10.167.3.27)
X-MS-Office365-Filtering-Correlation-Id: 81040a40-31dc-49aa-2b16-08d41ac90776
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR05MB2498;
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 3:cCi24ZL6sIIbBmSBVxrhrnvsANVp4fKoU+FeMA8YJwUQ4niLI2tQsP+e3eJ0kFNep8sfkGL7MpyPsmp9TX+t2FBzQUHqNxq89xyhbUeZVHpxnpAEJGNK+wMjBcwBoLdXN9T2Du1LzsyVwQsIhUX+SEXaxkIDn/t7D5I+/1UEZN/RQi4rktNEA+tnurJNn1sC3A8iZXnq/unjtQ8+FaHqOW9sycWV8soRTRpmOc+Z5of8RAbwhhArT0SKdqtEfCeuT44k5rFrFQlAwIcKhWpS4A==
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 25:9/y8qsFx+oyYLM9g2q3tJFEfNX0q5c40hKUgHiUkG+sJViuomU3QzzF52fJK6wVnBLrrOKrJvGeP+PvqH31IxLbvDCAX0CJ2ds51T125qG9dGQD9yLiUOejjUc9TGfz9xQspufHn9VE00/wl667Oslb5fgJ16af2MFWtZ77U8A0aEXGoY6TDPLyYyLNp4v+jKDbtmXFgmcPK1E3Eo8i7xS1QDnPJhGyPLnQZA3nJk4KPhjAYn+XTg3i1c0qpmRPElucYMFM181wg3Q85qGaDFcDhc2FoFXZa/SesfroZbX+bSskM+v/WJoqfCmRtu7i4u8WGJI9UtuV1Y4K3kmD3ck8n2XcBuKNYA+r03IY0gYe4+Cvw7qhNRU8LHiN3RqTjrXMnlZ9m8M+/g2o2b+wWVnCsd0DmEV2ePprwoVkTQuKIDNaVUx7r12Yxu9UWtgzRi1PHzUy8sCy5oT5CX4dqH5/GWRnvmDnF59edC6CSbKapAIvATuoFkLwgl7TwQMMNqVmPOPQ65StMA67MYb/Pvk1khOPAvf1inuap3GdPHleXkSvOiG3JhMo4/rN8sOTWeEPZiKOdTJu5/g0vJa8r8ObotYfU4oUKn3eggAzwP5TL0I849KU1Mfl48qhLMmuqjuZBHCxtbopx5xwsxRxFBhN3lga3XWMxNjiYUH0nku1X1cy9enSTMrjUnF9/YW87XeDP5JTOZTtfzoXc7G0dxHUL0P/naETdhdEtizfyMmYn4pzJblhzQzgOMjXoSmKniHgVjoyltrFKpRIEwcISCtVSvQzm6nrBBtOjTIv18A42YP8FfLwYiJsDNNbM6g0hOq520P5df/ySYKmaBRZ8anyi2tZBUshggiD8RAmhsRhL0o53WcEWB7Xi/PyQqXCP
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 31:3lfXWpXyIA0z+9FF7MEHRfd699H3GPAMmImJBjvBL1m450T3WqmSbGKCAzBoUEfDk5F7+4lTevxA2cx1DrMuz0nJmsUOOaPp7g6kua0B8kjrwU45Krh0BgTwD1hLoE/LrcKRNznZVmHa37xpbnD93ccJY/KHyMbTtfs/hjsG96ylwnBFrlQfMO/N7kn6YFfMXZstgcxvpnSLgd71dBBL2D23V5tR15vEJJ8TdIdYECT2pwDkbl0ne3aK/GFhaNswlX2Y7d56QAquTE0xQtddkQ==; 20:vDtPiFVsibuHBCxfvGbkTsdy1hnMGwfDkS8XviIHg/QdQXeeZTmQJADGzlRWpktZwHJWE8O/H1PfrZsk2mT0TEpBpSIMHd+TCTB1goU29BWHdb6kjW/xxGzFuAFXpTVduvwIqRyJPCnX7nBpKqdeNb0tVlHQl3xeTwOFxMiAL5t7Sp0yS05bzk+Sw7ZNvchsMC5PlxH6MZeUghVNTORBqPZ7RqGg6fKksAuXsi5oH/re2cbrB2NL9q/RdIqRYOchRD66qV7gq8CMxSha0BK2DOsYhdPvch00J4YewKYRH7/WeUjQOWz+t/+3zFEek5nySW/Eh8GJKn2YXJqDUDC71ERCyQO95a/h2ywFj03LsN71NLkLp3U2RNfbl/C1bC3P+9spZsjbCW85TqNcyDPkZh43DuH84GOKm2B8Z2q0n25fhjDwwi1bhkOR44mgFyFYL/mxeYAIaRZH/I3xPNwvU0NAp5X4rN0YC1EGz+HiC8nYbWO5kyivD+4XdlGDACrJF9+di4h2a5ikr0sg6xrPyLllBKqioZRUI6SiVDDum2TJwWQv0M8B3f9IJBSLdM2IGBqoPVrv+kQUUva7NbXtJa+5mAr5f13mBwZUnyjE76s=
X-Microsoft-Antispam-PRVS: <BN3PR05MB2498BF5FC4CAA708745C4C06AA8E0@BN3PR05MB2498.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(120809045254105);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:BN3PR05MB2498; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2498; 
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 4:gY1lT/XfeqyzFyk56341hevg88RCbJCPnnHcPQozmxb+Ac2l980JeSiEldbMeoUPp5pDmnRc14YWIqqYQL9avxTv+/JSZ1EX8zAR/qZWZvO1oBqHOLxacseStgzgGqfpW5xwOndlNdOQJHUBNBu0C2LGsHafLQUuvhc6ju4Uc3LcxHzQ7ht1eqKH6HQ3VztKOJT0JzzKEGysP4xeImvpkcsCfpRBCJ9AjxmGk/yEQj71OOBw8XwSL3esgAKrc29TYu0jF/Q94YRzcQvR9g51vyncQaPPcOtDl1saZMhryoHM0Fx5b0SIzaUK+YrcCDKtXXJnLvRKhySP6kSZ4a1ZfLayy/PBVMWHmf0XhbjkYZEy6cvcJPx07qytseX8sGVdvDZBTjQntyub5g8Abbnevh2CH4k5XMif46IBEvoPK4Iz8GLvyJ2SuoCCQQ0j4lajfvm8V9EVfB5J8epGV49P7snUXFWELeVQ57KdEgPuUlDo4VJoJiWs3U8nON5Nr4yff66k5bgEbWNtKlfhl5k/dPSiAFZ6yv2nqGrYhTIPaW+NxkXRmaqWTIulqIT0CqFYh8tauSIWvFWnpvL68kDo79MqnzhVW4RpduN53l59gRY1VmeqKq1d6ht//z9ryFzP+Bw55614IRg8mrkOM7Hmbw==
X-Forefront-PRVS: 0144B30E41
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(51914003)(189002)(377424004)(199003)(377454003)(68736007)(69596002)(39450400002)(66066001)(6506004)(53416004)(106356001)(733004)(189998001)(6512004)(39410400001)(6486002)(105586002)(8746002)(97756001)(33656002)(101416001)(110136003)(81156014)(229853002)(50986999)(50226002)(76176999)(42186005)(3846002)(38730400001)(6116002)(23726003)(81166006)(92566002)(83716003)(57306001)(46406003)(305945005)(36756003)(6666003)(6916009)(8676002)(82746002)(2950100002)(7736002)(50466002)(7846002)(2906002)(47776003)(5660300001)(97736004)(230783001)(86362001)(4326007)(41533002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2498; H:mhamas-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2498; 23:pQC2k2EIVvduiy3KkDZxVETQ0haM9tCkhWVoSrBkS?= =?us-ascii?Q?Tbrhyd0GfIkj9niAeldicN7VDGpaY+7NaadtG7hSClx6M+o2z6Nh9i+1R7U4?= =?us-ascii?Q?bZ18HUUpHWBTT3deLliNXHnkP6bL0qfWpaxpuLxsgF7ZfK357M+K/v+l5otb?= =?us-ascii?Q?xlEiNvN5RdGhxaBV5gZbtEPBfgJoS78cWoiZLWKpRWDKyfAh0F2UTijy4/Qg?= =?us-ascii?Q?w83eXzQZMIcUOna1LUqlsI0SrbysfaCKk9Eat8/yyVCjR+d3AF02pqEWaRBb?= =?us-ascii?Q?gAMpR6gPZK1ri6qeiTqR/PWh+r24kvEZ2I3+vAUg/wjTWp4aYZuMecarJYZ1?= =?us-ascii?Q?cuyFH3JwRC8J72WX5L/j17QHfm7H1gitAKaptYEsjwT9JPjyHqeDiCU/rWPJ?= =?us-ascii?Q?4wgwkHwru/hNERtdIWqe2iyBOwJLHSY8uuy++yKgJxLkmjXKgb0oMiXBe940?= =?us-ascii?Q?eeokD5RoXahk58AfJs5PJlB0+eROJTSrL6OhXUou003MVMkjTSJRNBr9fX5M?= =?us-ascii?Q?03gA/wWKPK04aaIrNwDIaigPFFxnmNE5UkjMQPIp5dp729L2FrJhyRNKkwXC?= =?us-ascii?Q?uYBfcRgTb/NIg5eJDJGH7aexWgfHUHS+E3m652VTGEeZUodgUOaVwlE6v6k9?= =?us-ascii?Q?BW8F0f4jPoN7HR4aF92s8OMhfVuytLLthz1aFRnoRgyHm29wBK7/EKeEJF25?= =?us-ascii?Q?YPBcjvaTl10IxMXT4vqCqaM9KGf5cg299MEc3opquzCVA47ca7QX7XnlaQg7?= =?us-ascii?Q?M4EJxhJBK3EjiMZtWzaKQexRFwBD35fwuqlLyOWnTs9w8gIg8ML/bbHSg7My?= =?us-ascii?Q?lgzz01wi5HXBp99Ng+jQ1Mv7r0xqfoPF/2mJ3gPaotXKKCQp8IIVc9OFYTHG?= =?us-ascii?Q?BFetNhqFYalBkgecd+EWOiPVV1RrEtQI931IPlWbGEpKbT0zAmkvdkXWmdRO?= =?us-ascii?Q?TOw2VuZbJoeIq1SOvj43Eq3eMLdLmrPyXP/dgDNeS4fLWC5TeGNoXDQ6hKTP?= =?us-ascii?Q?v8qkdqCWr2txAThMEjkFyHqyK6vCmJFSzMZHpOXkbCKlGVUGvMqoGDp2SWfR?= =?us-ascii?Q?XM/Sv4foo9Uj9LPIZaWJ4+yajRt4oi6fPpX836nF3NVCOSHFqQDF+/lQ9C7N?= =?us-ascii?Q?T4boUiFlVUeTfMN0PqXqYbx8YlCaYCLAY1w2BnkGyYPFsVhPTQGs0yIepRmp?= =?us-ascii?Q?06xDXuPMkccU8tBtueSVxeJo3k8Nz2d7lRWRBs9VMgXyVLWxiAt8ftVdACqs?= =?us-ascii?Q?RuRsLpgACTAxNN4EBZd/Cb9XUio747Ehc32QoXUktY7grN7qnc6rBbhPpN4b?= =?us-ascii?Q?4KHYXqNorVkyET64D4ZUyB5OXOu2W8Qy7NjrBio2woBJI8Zu5S7RY/0Jr6fB?= =?us-ascii?Q?icKv3ZF/ZieIrxoMEhDS29gLN4GSuQo3nmQym8ZEVfakaZ1xknuFPrtyKrtX?= =?us-ascii?Q?HoBML7Ce41ZBcVFaNikMswkFOLsdjk=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 6:RLC6i3/5mmKFHQfWdAGxZsYxG+CBsbdPYt27Jr+RTTNU+g0FWvavnuTvGIXmuJ1wdHIrrcOk8+lGgwJP4zuervdrvwewSstIMeJYQVvlCk33p2X12vbm3kZ3bZOnO9Po5LnS5/zHVOJVMUriwPWZ5DI9JKC1Utl1uN+/+4z39YT9glBR7PEW1Rymi/hmrhSYLIvxEw8fMAXfFRuHUoDU8MHgQGTrMPr2cRtQSwNqBSER3nF1jWTElRWPCs5UAaC8KYJ20xV1fXctXdvPgR89L44tdJXB3sp+vaV/z5MHhJpudCTLhrpDklbxeoNOEVX2BoUnhETzUrQNQxW3beu9gKIVT3yW2rSZwE1GE10AlO6deUPZnbTDeRZ699gfONILSCju/CxSBFhYNvupIY+Vl6SZPUo6Hcoy4slZSiegQxpeHl7iJAYSqQPEXq7vOVPtIQrKZd1+WIXDiOGADO+kqw==; 5:MP1dLZYvZyTkILIOrBE3Gfejuy8fXootKhyaMI0bWnnTdPmcw9s1dq7guaiMkTVy/4qNmAh2fugXicgIlPU3AjdTmJ+H8fD3wpenXSu0Gm5nbCPgUI+W6U9CU3/CSXVuieZZJ3ZhoF0fVG/vXCnbzA==; 24:B7JNtFu8JeS2H/JseK1XiPJuzZxW9Smx0UAjtJdk9QZZRF3+C8ujFURRbkq7WOORwFyAJpuaVvRiB2mzu4cYx+2iWANAcI0UhNCaJZTxggk=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2498; 7:6/kWRufnnnBhjRzzCUVt4+8QguX/TiXcgnqd8NbsxB+l65xjupqfxCrpO6gZqb6k1Q7qhTZ70LwaW0jw3TD+Vy9MaXN8cpqh9SXFUF1gTumx1CcDrsH66rc4FQwexm2wCDmDt6z1WfkyeQEJP+IoXvRUBh27qS61gQwIti2M7WX0HgeWN1KKu+kmyPUkhO4nlUolYJzHdWvpPtqYABSihcIYZdd6rl7p3MYNKFrlwwY2xKt4PZSfU2rjMtXQ6s4fGqfirQ/YGnnz2a53U40AzOrZAenGcLn7QSWnqwQeGrpGoiepB76jtYR6vE0uwI5w5dsnkRzJkqCo2Zf4cseSupvTx2ihfCGw6PRu7lwLYuvROCg/bKRnvahsR2qSI0D7HcZOahuMNdo4vMkAVDXRJC5BvdxSesmUDcYEq1HvOK7DbIwIm1GNVwp5TQqh853mE5Ypb4jWDYYz5F04DxpkCQ==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2016 15:36:47.6741 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2498
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zHI2Q7IaZiQvaLBotkFY3wB6wUE>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as4octet-extcomm-generic-subtype-10.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 15:36:53 -0000

Done. Also moved status to "dead".

Thanks for the update.

--John

> On Dec 2, 2016, at 6:39 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>=20
> This update solely exists to act as a tombstone for the work and to =
request IANA to deprecate their former assignments.
>=20
> Chairs, please continue with the request with IANA.
>=20
> -- Jeff
>=20
>> On Dec 2, 2016, at 3:42 AM, internet-drafts@ietf.org wrote:
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> This draft is a work item of the Inter-Domain Routing of the IETF.
>>=20
>>       Title           : Generic Subtype for BGP Four-octet AS =
specific extended community
>>       Authors         : Dhananjaya Rao
>>                         Pradosh Mohapatra
>>                         Jeffrey Haas
>> 	Filename        : =
draft-ietf-idr-as4octet-extcomm-generic-subtype-10.txt
>> 	Pages           : 6
>> 	Date            : 2016-12-01
>>=20
>> Abstract:
>>  Maintaining the current best practices with communities, ISPs and
>>  enterprises that are assigned a 4-octet AS number may want the BGP
>>  UPDATE messages they receive from their customers or peers to =
include
>>  a 4-octet AS specific BGP extended community.  This document defines
>>  a new sub-type within the four-octet AS specific extended community
>>  to facilitate this practice.
>>=20
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> =
https://datatracker.ietf.org/doc/draft-ietf-idr-as4octet-extcomm-generic-s=
ubtype/
>>=20
>> There's also a htmlized version available at:
>> =
https://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtyp=
e-10
>>=20
>> A diff from the previous version is available at:
>> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-as4octet-extcomm-generi=
c-subtype-10
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Fri Dec  2 07:40:37 2016
Return-Path: <lambert@psc.edu>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE01F129468; Fri,  2 Dec 2016 07:40:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.198
X-Spam-Level: 
X-Spam-Status: No, score=-7.198 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_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=psc.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 02FZm5Xt1Hlb; Fri,  2 Dec 2016 07:40:34 -0800 (PST)
Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.70.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0634E129588; Fri,  2 Dec 2016 07:40:30 -0800 (PST)
Received: from [192.168.101.69] (c-67-186-19-193.hsd1.pa.comcast.net [67.186.19.193]) (authenticated bits=0) by mailer2.psc.edu (8.13.8/8.13.8) with ESMTP id uB2FeQiv017401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2016 10:40:28 -0500
DMARC-Filter: OpenDMARC Filter v1.3.1 mailer2.psc.edu uB2FeQiv017401
Authentication-Results: mailer2.psc.edu; dmarc=none header.from=psc.edu
Authentication-Results: mailer2.psc.edu; spf=pass smtp.mailfrom=lambert@psc.edu
DKIM-Filter: OpenDKIM Filter v2.10.3 mailer2.psc.edu uB2FeQiv017401
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=psc.edu; s=default; t=1480693228; bh=cYQO+sVO8D5vD69M0QvmcLmzNcGtJyrYoHeqCF29DwQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=HMpcS/4bNxP9SwebJLBTSBIIHRpX6dqFf/cgV8orkHOKViPx54vR+v4A3azjacs5T /jwfzVdXlTrWLeftlinPa5LZOY8gr3cE1rkktBk692olUwVJMhT1QoRvUVrF2fXGFM gXNo6Ap5bbKz6F841xO1bUdKEqDHDVKuDwhYSdV4=
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: Michael H Lambert <lambert@psc.edu>
In-Reply-To: <AAC9E38F-BF0D-41D7-8871-9B89D31BC37B@juniper.net>
Date: Fri, 2 Dec 2016 10:40:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A889AAA-05C6-4036-B05A-316FEB2C84E2@psc.edu>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com> <AAC9E38F-BF0D-41D7-8871-9B89D31BC37B@juniper.net>
To: "John G. Scudder" <jgs@juniper.net>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/epTCtJIdwvX5_ubM92J75LkCUkE>
Cc: "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 15:40:36 -0000

> On 2 Dec 2016, at 08:57, John G. Scudder <jgs@juniper.net> wrote:
>=20
> On Dec 2, 2016, at 8:46 AM, Alvaro Retana (aretana) =
<aretana@cisco.com> wrote:
>> Removing and ignoring are obviously different things=E2=80=A6  The =
text above is fine with me, but I would ask: what do the current =
implementations do?  If they remove (as originally specified), then I =
would suggest you keep that.
>=20
> What do you think would be a good minimal change to clarify? How about =
changing the word "duplicate" to "redundant"?
>=20
> OLD:
>   Duplicate BGP Large Community values MUST NOT be transmitted.  A
>   receiving speaker MUST silently remove duplicate BGP Large Community
>   values from a BGP Large Community attribute.
>=20
> NEW:
>   Duplicate BGP Large Community values MUST NOT be transmitted.  A
>   receiving speaker MUST silently remove redundant BGP Large Community
>   values from a BGP Large Community attribute.

Just for clarification:  Does "speaker" in this context refer to a BGP =
speaker implementing large communities, and, by inference, excludes BGP =
speakers not supporting large communities?

Thanks,

Michael


From nobody Fri Dec  2 07:44:36 2016
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0681295B3; Fri,  2 Dec 2016 07:44:35 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Sender: <iesg-secretary@ietf.org>
Message-ID: <148069347536.29616.12975541589374339643.idtracker@ietfa.amsl.com>
Date: Fri, 02 Dec 2016 07:44:35 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/H5pNoXs3qHrLH0aI5BXRLEx2HYI>
Cc: idr@ietf.org, idr-chairs@ietf.org, draft-ietf-idr-deprecate-30-31-129@ietf.org, shares@ndzh.com
Subject: [Idr] Last Call: <draft-ietf-idr-deprecate-30-31-129-00.txt> (Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 234) to Proposed Standard
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: ietf@ietf.org
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 15:44:35 -0000

The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and
   234'
  <draft-ietf-idr-deprecate-30-31-129-00.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-12-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document requests IANA to mark BGP path attribute values 30, 31,
   129, 241, 242, and 243 as "deprecated".




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-30-31-129/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-30-31-129/ballot/


No IPR declarations have been submitted directly on this I-D.





From nobody Fri Dec  2 07:45:14 2016
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D49FC12971E; Fri,  2 Dec 2016 07:45:12 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Sender: <iesg-secretary@ietf.org>
Message-ID: <148069351286.29733.16760347659573353664.idtracker@ietfa.amsl.com>
Date: Fri, 02 Dec 2016 07:45:12 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/J7CS1bwJGVXAHZFyOrRB5na7Lc8>
Cc: idr@ietf.org, draft-ietf-idr-large-community@ietf.org, idr-chairs@ietf.org
Subject: [Idr] Last Call: <draft-ietf-idr-large-community-09.txt> (BGP Large Communities) to Proposed Standard
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: ietf@ietf.org
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 15:45:13 -0000

The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'BGP Large Communities'
  <draft-ietf-idr-large-community-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-12-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document describes the BGP Large Communities attribute, an
   extension to BGP-4.  This attribute provides a mechanism to signal
   opaque information within separate namespaces to aid in routing
   management.  The attribute is suitable for use with four-octet
   Autonomous System Numbers.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ballot/


No IPR declarations have been submitted directly on this I-D.





From nobody Fri Dec  2 07:45:36 2016
Return-Path: <job@ntt.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955CB1297F1; Fri,  2 Dec 2016 07:45:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.831
X-Spam-Level: 
X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 GNQjtiDKWDJS; Fri,  2 Dec 2016 07:45:17 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696BC129468; Fri,  2 Dec 2016 07:45:02 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1cCq1C-0003ud-8R (job@us.ntt.net); Fri, 02 Dec 2016 15:44:59 +0000
Date: Fri, 2 Dec 2016 16:44:54 +0100
From: Job Snijders <job@ntt.net>
To: Michael H Lambert <lambert@psc.edu>
Message-ID: <20161202154454.GH47164@Vurt.local>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com> <AAC9E38F-BF0D-41D7-8871-9B89D31BC37B@juniper.net> <8A889AAA-05C6-4036-B05A-316FEB2C84E2@psc.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8A889AAA-05C6-4036-B05A-316FEB2C84E2@psc.edu>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VXeMGhCvKq7HBQGWSUi3DmqZNro>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 15:45:28 -0000

On Fri, Dec 02, 2016 at 10:40:25AM -0500, Michael H Lambert wrote:
> > On 2 Dec 2016, at 08:57, John G. Scudder <jgs@juniper.net> wrote:
> > 
> > On Dec 2, 2016, at 8:46 AM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:
> >> Removing and ignoring are obviously different things…  The text
> >> above is fine with me, but I would ask: what do the current
> >> implementations do?  If they remove (as originally specified), then
> >> I would suggest you keep that.
> > 
> > What do you think would be a good minimal change to clarify? How
> > about changing the word "duplicate" to "redundant"?
> > 
> > OLD:
> >   Duplicate BGP Large Community values MUST NOT be transmitted.  A
> >   receiving speaker MUST silently remove duplicate BGP Large Community
> >   values from a BGP Large Community attribute.
> > 
> > NEW:
> >   Duplicate BGP Large Community values MUST NOT be transmitted.  A
> >   receiving speaker MUST silently remove redundant BGP Large Community
> >   values from a BGP Large Community attribute.
> 
> Just for clarification:  Does "speaker" in this context refer to a BGP
> speaker implementing large communities, and, by inference, excludes
> BGP speakers not supporting large communities?

This only applies to BGP speakers who understand the Large Community. To
speakers without Large Community support, it will just be an optional
transitive attribute which is passed on in verbatim.

Kind regards,

Job


From nobody Fri Dec  2 08:45:52 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E00E1297C2; Fri,  2 Dec 2016 08:45:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148069714751.29737.9901551729505628094.idtracker@ietfa.amsl.com>
Date: Fri, 02 Dec 2016 08:45:47 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/X4Cb_MYSXMNEAAkj9j7e_KVJGrc>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-large-community-10.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 16:45:47 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : BGP Large Communities
        Authors         : Jakob Heitz
                          Job Snijders
                          Keyur Patel
                          Ignas Bagdonas
                          Nick Hilliard
	Filename        : draft-ietf-idr-large-community-10.txt
	Pages           : 9
	Date            : 2016-12-02

Abstract:
   This document describes the BGP Large Communities attribute, an
   extension to BGP-4.  This attribute provides a mechanism to signal
   opaque information within separate namespaces to aid in routing
   management.  The attribute is suitable for use with four-octet
   Autonomous System Numbers.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-large-community-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Dec  2 08:50:24 2016
Return-Path: <pushpasis.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693B312985A for <idr@ietfa.amsl.com>; Fri,  2 Dec 2016 08:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QtCnd6d6qN0L for <idr@ietfa.amsl.com>; Fri,  2 Dec 2016 08:50:18 -0800 (PST)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (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 0FA081297F3 for <idr@ietf.org>; Fri,  2 Dec 2016 08:50:18 -0800 (PST)
Received: by mail-yb0-x235.google.com with SMTP id v132so40511629yba.0 for <idr@ietf.org>; Fri, 02 Dec 2016 08:50:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rvyPGfyIXvbAjXLP76RH4g8VecpByYzXaUQs+avtQUY=; b=TCdWxMwK1NXs676TN8abCwxaCU8YJz3SdDuH5lSd0QB8v//ylBxZdJ53WvkLB7r+50 8NJyarnRVcOyTt9UapseUeuLj/CYuWqShjuV0yDVACYDCYxCP+xnLLopmvroGsQZQyeS W0G5eHO/Eov4spQsHX6P+Te9fUCIIp1hp4bKe8iE5Jt3RjNs8WFLrETtsYtp0GRxpS8Y 9ZEo69gDQWw//3ius4rCO8Nq6rJulQgckyz2QSj88Lqk6A68/t4eAzxrckfcZ38RkfAR s0EwtZAioObgrQypOsNVKKqweSdfs80KDvY9wL3k8OHOa4+4KvrRxmw/K5MHhqn17JTY DkKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rvyPGfyIXvbAjXLP76RH4g8VecpByYzXaUQs+avtQUY=; b=AU/x61DpsGEkzbFR5DBd1gAhGxRsL8HJH6gFjoxO9+F7JduTbKe45QSKbIZzLU9Y42 m9Llayj1swdrmkVYZIW02Mh7EItE4c3CE4fm4yzeakFlwv8OnU9oVrKhari/KprmFi2i zVChRe6M3nLK4l0IPWvjOU7Jd42/ia0EFO3MmzDlskzMmIi5PxrCCSK1+oFFNhV3Ydms XCUbjcS2aC6hX3ZAj0ZWw/CsmLaYyz7izv/ldYdI7W4MNR5HYyuAcmQt4rWmt3dg31IX NoZPasvp6feS9t8UmYc/FLNuWVSFYiXWMoOekevS+UTaPMxvSSo0kEfrhhFnP1KSEaJT 4bjg==
X-Gm-Message-State: AKaTC01E1Gpu6+ygcJdMfJHoc+AYNhlzBIRGDE2ugLF2KeVmebXF+ilyjHEfdPY4+4L6xbpofkhPt0i/XI+mAw==
X-Received: by 10.37.83.134 with SMTP id h128mr19290929ybb.122.1480697417249;  Fri, 02 Dec 2016 08:50:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.223.207 with HTTP; Fri, 2 Dec 2016 08:50:16 -0800 (PST)
In-Reply-To: <001a01d24c7d$72367440$56a35cc0$@ndzh.com>
References: <007501d24bbf$11a41b50$34ec51f0$@ndzh.com> <CAEFuwkjwNdQcj=C3JrKt8LTAXsP6Su4_S2Mss+CeCf3bDasqog@mail.gmail.com> <001a01d24c7d$72367440$56a35cc0$@ndzh.com>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Date: Fri, 2 Dec 2016 08:50:16 -0800
Message-ID: <CAEFuwkhG2XmY3zCrbBwXaYpj1B9Y4DzyMTeu6WzZHrYM1G7r3A@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a113e5d10933af40542afbbfb
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bS8tlOAe_1iMWB-fx1WgYQurRS4>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] draft-psarkar-idr-bgp-ls-node-admin-tag-extension - 1 week period to comment (11/17 - 11/24/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 16:50:22 -0000

--001a113e5d10933af40542afbbfb
Content-Type: text/plain; charset=UTF-8

Hi Susan,

I dont know if there are any implementations around already... :(  Maybe
someone on this list can update..

Thanks and Regards
-Pushpasis

On Fri, Dec 2, 2016 at 1:21 AM, Susan Hares <shares@ndzh.com> wrote:

> Pushpasis:
>
>
>
> If there exist 2 implementations for this draft, please let me know.  We
> can go rapidly into the final stages before WG LC.
>
>
>
> Sue
>
>
>
> *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of *Pushpasis Sarkar
> *Sent:* Thursday, December 1, 2016 1:57 PM
> *To:* Susan Hares
> *Cc:* idr wg
> *Subject:* Re: [Idr] draft-psarkar-idr-bgp-ls-node-admin-tag-extension -
> 1 week period to comment (11/17 - 11/24/2016)
>
>
>
> Hi Sue,
>
>
>
> Thanks a lot. I have uploaded it as draft-ietf-idr-bgp-ls-node-
> admin-tag-extension.
>
>
>
> Best regards,
>
> -Pushpasis
>
>
>
>
>
> On Thu, Dec 1, 2016 at 2:38 AM, Susan Hares <shares@ndzh.com> wrote:
>
> The IDR consensus is that the IPR on draft-psarkar-idr-bgp-ls-node-admin-tag-extension
> is acceptable.   The authors should submit the draft as:
>  draft-ietf-bgp-ls-node-admin-tag-extension.
>
>
>
> Sue Hares
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
>

--001a113e5d10933af40542afbbfb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Susan,<div><br></div><div>I dont know if there are any =
implementations around already... :( =C2=A0Maybe someone on this list can u=
pdate..=C2=A0</div><div><br></div><div>Thanks and Regards</div><div>-Pushpa=
sis</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
 Fri, Dec 2, 2016 at 1:21 AM, Susan Hares <span dir=3D"ltr">&lt;<a href=3D"=
mailto:shares@ndzh.com" target=3D"_blank">shares@ndzh.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vl=
ink=3D"purple"><div class=3D"m_187752129888638617WordSection1"><p class=3D"=
MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:#1f497d">Pushpasis: <u></u><u></u></span></p><=
p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></span=
></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&qu=
ot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">If there exist 2 imp=
lementations for this draft, please let me know.=C2=A0 We can go rapidly in=
to the final stages before WG LC. <u></u><u></u></span></p><p class=3D"MsoN=
ormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=
t;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></span></p><p class=
=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&qu=
ot;,&quot;sans-serif&quot;;color:#1f497d">Sue <u></u><u></u></span></p><p c=
lass=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibr=
i&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></span></=
p><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&qu=
ot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font=
-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Idr [m=
ailto:<a href=3D"mailto:idr-bounces@ietf.org" target=3D"_blank">idr-bounces=
@ietf.org</a>] <b>On Behalf Of </b>Pushpasis Sarkar<br><b>Sent:</b> Thursda=
y, December 1, 2016 1:57 PM<br><b>To:</b> Susan Hares<br><b>Cc:</b> idr wg<=
br><b>Subject:</b> Re: [Idr] draft-psarkar-idr-bgp-ls-node-<wbr>admin-tag-e=
xtension - 1 week period to comment (11/17 - 11/24/2016)<u></u><u></u></spa=
n></p><div><div class=3D"h5"><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p=
><div><p class=3D"MsoNormal">Hi Sue,<u></u><u></u></p><div><p class=3D"MsoN=
ormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">Thanks a l=
ot. I have uploaded it as draft-ietf-idr-bgp-ls-node-<wbr>admin-tag-extensi=
on.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u>=
</p></div><div><p class=3D"MsoNormal">Best regards,<u></u><u></u></p></div>=
<div><p class=3D"MsoNormal">-Pushpasis<u></u><u></u></p></div><div><p class=
=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div></div><div><p class=3D"MsoNorm=
al"><u></u>=C2=A0<u></u></p><div><p class=3D"MsoNormal">On Thu, Dec 1, 2016=
 at 2:38 AM, Susan Hares &lt;<a href=3D"mailto:shares@ndzh.com" target=3D"_=
blank">shares@ndzh.com</a>&gt; wrote:<u></u><u></u></p><div><div><p class=
=3D"MsoNormal">The IDR consensus is that the IPR on draft-psarkar-idr-bgp-l=
s-node-<wbr>admin-tag-extension is acceptable.=C2=A0=C2=A0 The authors shou=
ld submit the draft as: =C2=A0draft-ietf-bgp-ls-node-admin-<wbr>tag-extensi=
on. =C2=A0<u></u><u></u></p><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p>=
<p class=3D"MsoNormal">Sue Hares <u></u><u></u></p></div></div><p class=3D"=
MsoNormal" style=3D"margin-bottom:12.0pt"><br>_____________________________=
_<wbr>_________________<br>Idr mailing list<br><a href=3D"mailto:Idr@ietf.o=
rg" target=3D"_blank">Idr@ietf.org</a><br><a href=3D"https://www.ietf.org/m=
ailman/listinfo/idr" target=3D"_blank">https://www.ietf.org/mailman/<wbr>li=
stinfo/idr</a><u></u><u></u></p></div><p class=3D"MsoNormal"><u></u>=C2=A0<=
u></u></p></div></div></div></div></div></blockquote></div><br></div>

--001a113e5d10933af40542afbbfb--


From nobody Fri Dec  2 09:14:56 2016
Return-Path: <heas@shrubbery.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E4912952F; Fri,  2 Dec 2016 09:14:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level: 
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 WfUOeidUodoH; Fri,  2 Dec 2016 09:14:53 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F22129598; Fri,  2 Dec 2016 09:14:53 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 7DD7F7A673; Fri,  2 Dec 2016 17:14:53 +0000 (UTC)
Date: Fri, 2 Dec 2016 17:14:53 +0000
From: heasley <heas@shrubbery.net>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Message-ID: <20161202171453.GG3403@shrubbery.net>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OdOcvulUBt2vwzKP7ahfZfh3teY>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 17:14:55 -0000

Fri, Dec 02, 2016 at 01:46:50PM +0000, Alvaro Retana (aretana):
> On 12/2/16, 1:31 AM, "Ignas Bagdonas" <ibagdona.ietf@gmail.com> wrote:
> > > C2. There seems to be a contradiction in the expected use of reserved Global Administrator
> 
> > > values.  Section 2 says that the “Global Administrator field…SHOULD either be one of the reserved
> 
> > > values as defined below, or an Autonomous System Number (ASN)”, but later Section 5 says: “The
> 
> > > following Global Administrator values are reserved: 0, 65535, and 4294967295.  Operators SHOULD
> 
> > > NOT use these Global Administrator values.”   IOW: “SHOULD use one if the reserved values” and
> 
> > > “SHOULD NOT use the reserved values” contradict each other.  It seems to me that because 0,
> 
> > > 65535, and 4294967295 are already reserved ASNs, *and* that “the Local Data Parts are to be
> 
> > > interpreted as defined by the owner of the ASN”, then only assigned ASNs should ever be used ---
> 
> > > *and* given that it is not an error to use an value, then there is no real advantage in reserving
> 
> > > anything (again!). Suggestion: reference the RFCs where 0, 65535, and 4294967295 are reserved
> 
> > > and just say that those numbers SHOULD NOT be used because if a Special Use Large Community is
> 
> > > ever defined, those values may be used.
> 
> > For section 2: Global Administrator field SHOULD be an Autonomous System Number (ASN) or one of
> 
> > the reserved values defined in Section 5.
> 
> > For section 5: Global Administrator values corresponding to reserved use Autonomous System
> 
> > Number values of 0 [RFC7607], 65535 [RFC7300], and 4294967295 [RFC7300] are reserved.
> 
> > Would this work?
> 
> Question for you:  do you want the operators to use 0, 65535, and 4294967295 whenever they want (which is what the new text says), OR, do you want them not to use them because they could be used later for a special purpose (which is what the original text seemed to indicate)??
> 
> I’m having a hard time with this document “reserving” any value because the number space is not really one where values are assigned (in the typical IANA sense: create a registry, etc. – and I doubt you want to make it that way)…but the contents can be (SHOULD) what is contained in an already existing registry (ASNs) that has distributed control.

0 and 4294967295 are reserved ASNs, as is 65535 and 65535 is used by RFC 1997
communities for well-known communities.  It is the intention to use 65535 if
in the future it is desirable to define large well-known communities.  The
other two should not be used because they are invalid ASNs and could lead to
collision.  This all seems prudent to me.

> Assuming that you would prefer the operators NOT to use 0, 65535, and 4294967295, then here’s my suggestion:
> 
> OLD> (Section 2)
> 
>    The Global Administrator field is intended to allow different
> 
>    Autonomous Systems to define BGP Large Communities without collision.
> 
>    This field SHOULD either be one of the reserved values as defined
> 
>    below, or an Autonomous System Number (ASN).  If it is a reserved
> 
>    value, then the Local Data Parts are as defined by the reserved
> 
>    value.  If it is an ASN then the Local Data Parts are to be
> 
>    interpreted as defined by the owner of the ASN.
> 
> NEW>
> 
>    The Global Administrator field is intended to allow different
> 
>    Autonomous Systems to define BGP Large Communities without collision.
> 
>    This field SHOULD be an Autonomous System Number (ASN).  The use of
> 
>    Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT
> 
>    RECOMMENDED.
> 
> 
> 
> …and then eliminate Section 5…

no, do not eliminate section 5.

> 
> 
> If you really want operators not to use the Reserved ASNs ever because a special use may be though up later, then use “MUST NOT” above.
> 


From nobody Fri Dec  2 09:17:31 2016
Return-Path: <heas@shrubbery.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DA21294F6; Fri,  2 Dec 2016 09:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level: 
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 a05zOPQGCnCG; Fri,  2 Dec 2016 09:17:28 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0991294F4; Fri,  2 Dec 2016 09:17:28 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 1B5717A692; Fri,  2 Dec 2016 17:17:28 +0000 (UTC)
Date: Fri, 2 Dec 2016 17:17:28 +0000
From: heasley <heas@shrubbery.net>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Message-ID: <20161202171728.GH3403@shrubbery.net>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VpZPOnWnuCpA1QWFnq-HMydEOJs>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 17:17:30 -0000

Fri, Dec 02, 2016 at 04:04:22AM +0000, Alvaro Retana (aretana):
> C3. In Section 6: s/Global Administrator field MAY contain any value/Global Administrator field may contain any value     That “MAY” is not normative, it is just expressing a fact.

The intent was to indicate to implementers that the field may be of any
value and therefore should not be constrained.  Is it not then normative?
or should that be expressed in another manner?


From nobody Fri Dec  2 09:28:38 2016
Return-Path: <job@ntt.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553B51295CE; Fri,  2 Dec 2016 09:28:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.831
X-Spam-Level: 
X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 h0MPI7GgCHOU; Fri,  2 Dec 2016 09:28:34 -0800 (PST)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220681295B6; Fri,  2 Dec 2016 09:28:34 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1cCrdP-0000y9-Pc (job@us.ntt.net); Fri, 02 Dec 2016 17:28:32 +0000
Date: Fri, 2 Dec 2016 18:28:28 +0100
From: Job Snijders <job@ntt.net>
To: heasley <heas@shrubbery.net>
Message-ID: <20161202172828.GA26987@hanna.meerval.net>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com> <20161202171453.GG3403@shrubbery.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20161202171453.GG3403@shrubbery.net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BSwGT634TCgkF2DbW_U0lmoUu9A>
Cc: "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 17:28:35 -0000

On Fri, Dec 02, 2016 at 05:14:53PM +0000, heasley wrote:
> 0 and 4294967295 are reserved ASNs, as is 65535 and 65535 is used by
> RFC 1997 communities for well-known communities.  It is the intention
> to use 65535 if in the future it is desirable to define large
> well-known communities.  The other two should not be used because they
> are invalid ASNs and could lead to collision.  This all seems prudent
> to me.
> 
> > Assuming that you would prefer the operators NOT to use 0, 65535,
> > and 4294967295, then here’s my suggestion:
> > 
> > OLD> (Section 2)
> > 
> >    The Global Administrator field is intended to allow different
> >    Autonomous Systems to define BGP Large Communities without collision.
> >    This field SHOULD either be one of the reserved values as defined
> >    below, or an Autonomous System Number (ASN).  If it is a reserved
> >    value, then the Local Data Parts are as defined by the reserved
> >    value.  If it is an ASN then the Local Data Parts are to be
> >    interpreted as defined by the owner of the ASN.
> > 
> > NEW>
> > 
> >    The Global Administrator field is intended to allow different
> >    Autonomous Systems to define BGP Large Communities without collision.
> >    This field SHOULD be an Autonomous System Number (ASN).  The use of
> >    Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT
> >    RECOMMENDED.
> > 
> > …and then eliminate Section 5…
> 
> no, do not eliminate section 5.

The text that used to be section 5 is better served through a separate
document I think. Jon Mitchell and myself are working on a document to
assist in that matter. This document is not published yet.

The first sentence of section 5 was moved into the section 2. The second
sentence says what the document is _not_, and a forward looking
statement of what could happen. There is no cost to removing that if we
carry that torch over into a new document. Let me know if you want to
help work on draft-mitchell-idr-large-communities-registry.

Kind regards,

Job


From nobody Fri Dec  2 09:34:44 2016
Return-Path: <heas@shrubbery.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99F31296DB; Fri,  2 Dec 2016 09:34:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level: 
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 C3WTUq8mMy1U; Fri,  2 Dec 2016 09:34:41 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F176128B38; Fri,  2 Dec 2016 09:34:41 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 341057A703; Fri,  2 Dec 2016 17:34:41 +0000 (UTC)
Date: Fri, 2 Dec 2016 17:34:41 +0000
From: heasley <heas@shrubbery.net>
To: Job Snijders <job@ntt.net>
Message-ID: <20161202173441.GI3403@shrubbery.net>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com> <20161202171453.GG3403@shrubbery.net> <20161202172828.GA26987@hanna.meerval.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20161202172828.GA26987@hanna.meerval.net>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/D8frUQcWie1L6Id_hBsyGfWnw28>
Cc: heasley <heas@shrubbery.net>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 17:34:43 -0000

Fri, Dec 02, 2016 at 06:28:28PM +0100, Job Snijders:
> On Fri, Dec 02, 2016 at 05:14:53PM +0000, heasley wrote:
> > 0 and 4294967295 are reserved ASNs, as is 65535 and 65535 is used by
> > RFC 1997 communities for well-known communities.  It is the intention
> > to use 65535 if in the future it is desirable to define large
> > well-known communities.  The other two should not be used because they
> > are invalid ASNs and could lead to collision.  This all seems prudent
> > to me.
> > 
> > > Assuming that you would prefer the operators NOT to use 0, 65535,
> > > and 4294967295, then here’s my suggestion:
> > > 
> > > OLD> (Section 2)
> > > 
> > >    The Global Administrator field is intended to allow different
> > >    Autonomous Systems to define BGP Large Communities without collision.
> > >    This field SHOULD either be one of the reserved values as defined
> > >    below, or an Autonomous System Number (ASN).  If it is a reserved
> > >    value, then the Local Data Parts are as defined by the reserved
> > >    value.  If it is an ASN then the Local Data Parts are to be
> > >    interpreted as defined by the owner of the ASN.
> > > 
> > > NEW>
> > > 
> > >    The Global Administrator field is intended to allow different
> > >    Autonomous Systems to define BGP Large Communities without collision.
> > >    This field SHOULD be an Autonomous System Number (ASN).  The use of
> > >    Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT
> > >    RECOMMENDED.
> > > 
> > > …and then eliminate Section 5…
> > 
> > no, do not eliminate section 5.
> 
> The text that used to be section 5 is better served through a separate
> document I think. Jon Mitchell and myself are working on a document to
> assist in that matter. This document is not published yet.

seems silly to spread it across 2 documents.  it is not a complex subject
and its already been expressed that there is no desire to specify any
well-knowns at this time.

> The first sentence of section 5 was moved into the section 2. The second
> sentence says what the document is _not_, and a forward looking
> statement of what could happen. There is no cost to removing that if we
> carry that torch over into a new document. Let me know if you want to
> help work on draft-mitchell-idr-large-communities-registry.
> 
> Kind regards,
> 
> Job


From nobody Fri Dec  2 09:37:43 2016
Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41ED312943A; Fri,  2 Dec 2016 09:37:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level: 
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 5kY4NUT-Ikft; Fri,  2 Dec 2016 09:37:41 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 88C181295F2; Fri,  2 Dec 2016 09:37:40 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 2EAAA1E341; Fri,  2 Dec 2016 12:41:02 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_690F219A-53E7-42F6-B727-BE3996ABC76B"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <20161202171453.GG3403@shrubbery.net>
Date: Fri, 2 Dec 2016 12:37:38 -0500
Message-Id: <38F120F9-E057-404D-AF32-8BD392C20759@pfrc.org>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com> <20161202171453.GG3403@shrubbery.net>
To: heasley <heas@shrubbery.net>, "Alvaro Retana (aretana)" <aretana@cisco.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/uzeO7gXffCChbuRBIqgbXsqx6Gs>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 17:37:42 -0000

--Apple-Mail=_690F219A-53E7-42F6-B727-BE3996ABC76B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Dec 2, 2016, at 12:14 PM, heasley <heas@shrubbery.net> wrote:
>=20
>> I=E2=80=99m having a hard time with this document =E2=80=9Creserving=E2=
=80=9D any value because the number space is not really one where values =
are assigned (in the typical IANA sense: create a registry, etc. =E2=80=93=
 and I doubt you want to make it that way)=E2=80=A6but the contents can =
be (SHOULD) what is contained in an already existing registry (ASNs) =
that has distributed control.
>=20
> 0 and 4294967295 are reserved ASNs, as is 65535 and 65535 is used by =
RFC 1997
> communities for well-known communities.  It is the intention to use =
65535 if
> in the future it is desirable to define large well-known communities.  =
The
> other two should not be used because they are invalid ASNs and could =
lead to
> collision.  This all seems prudent to me.

As I'd unfortunately learned this year, people still operationalize the =
use of even regular communities in the low and high value (0/65535) =
global admins in RFC 1997 communities.

Given the huge push for "parity" with 1997, being too restrictive in =
this document seems unwise.=20

We have two audiences that any cautions need to be made to:
- For developers, if you're not cautious about your wording on reserved =
values, they keep you from configuring stuff in those ranges.
- For operators, you want to tell them "these values either are not =
globally unique and have the possibility of collisions, or may run afoul =
of future compatibility mechanisms for well known communities in rfc =
1997 space".

-- Jeff


--Apple-Mail=_690F219A-53E7-42F6-B727-BE3996ABC76B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Dec 2, 2016, at 12:14 PM, heasley &lt;<a =
href=3D"mailto:heas@shrubbery.net" class=3D"">heas@shrubbery.net</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"Singleton"><blockquote type=3D"cite" style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;" class=3D"">I=E2=80=99m having a hard =
time with this document =E2=80=9Creserving=E2=80=9D any value because =
the number space is not really one where values are assigned (in the =
typical IANA sense: create a registry, etc. =E2=80=93 and I doubt you =
want to make it that way)=E2=80=A6but the contents can be (SHOULD) what =
is contained in an already existing registry (ASNs) that has distributed =
control.<br class=3D""></blockquote><br style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;" class=3D"">0 and 4294967295 are reserved ASNs, as is =
65535 and 65535 is used by RFC 1997</span><br style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;" class=3D"">communities for well-known communities. =
&nbsp;It is the intention to use 65535 if</span><br style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;" class=3D"">in the future it is desirable to define =
large well-known communities. &nbsp;The</span><br style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;" class=3D"">other two should not be used because they =
are invalid ASNs and could lead to</span><br style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;" class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;" class=3D"">collision. &nbsp;This all seems prudent =
to me.</span></div></div></blockquote></div><br class=3D""><div =
class=3D"">As I'd unfortunately learned this year, people still =
operationalize the use of even regular communities in the low and high =
value (0/65535) global admins in RFC 1997 communities.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Given the huge push for =
"parity" with 1997, being too restrictive in this document seems =
unwise.&nbsp;</div><div class=3D""><br class=3D""></div><div class=3D"">We=
 have two audiences that any cautions need to be made to:</div><div =
class=3D"">- For developers, if you're not cautious about your wording =
on reserved values, they keep you from configuring stuff in those =
ranges.</div><div class=3D"">- For operators, you want to tell them =
"these values either are not globally unique and have the possibility of =
collisions, or may run afoul of future compatibility mechanisms for well =
known communities in rfc 1997 space".</div><div class=3D""><br =
class=3D""></div><div class=3D"">-- Jeff</div><div class=3D""><br =
class=3D""></div></body></html>=

--Apple-Mail=_690F219A-53E7-42F6-B727-BE3996ABC76B--


From nobody Fri Dec  2 09:43:45 2016
Return-Path: <aretana@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545301296A5; Fri,  2 Dec 2016 09:43:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level: 
X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 dRTGyvZTt925; Fri,  2 Dec 2016 09:43:42 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6EC1270B4; Fri,  2 Dec 2016 09:43:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6528; q=dns/txt; s=iport; t=1480700621; x=1481910221; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rwXCvHfghn3bf5qlztZD23zxCTBusEkGnLMauc3GDV8=; b=YeHsni+g3H2KHapdRnF0WptwpjYatdu8rTDoSdz75M2LdMRk+wy2dvdt /ixHEujiUmg0X7ZZlvfhv4BwRlxz0yK9g7ez2uViTzfQKIa/V9xGCimgI gh688feXarY4pT26JB6FZZW/z9O/yWf6UrMplvb3ptwTrgrUNKoI7FzE5 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQB3skFY/5NdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNFAQEBAQEfWoEGB40/lwuPWoUiggaGIgIaggA/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGkBBAEjVgULAgEIQgICAjAlAgQOBRSIUwisQYIpL4sCAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHIY+gX0IglaHTS2CMAWUeoVpAZETCpAvjgCEDAEfN4EZMQEBgyS?= =?us-ascii?q?BfnKHcYENAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,287,1477958400";  d="scan'208,217";a="180827216"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 17:43:32 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uB2HhWoN030415 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 17:43:32 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 11:43:32 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 2 Dec 2016 11:43:32 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: heasley <heas@shrubbery.net>
Thread-Topic: [Idr] AD Review of draft-ietf-idr-large-community-09
Thread-Index: AQHSTFEplUv+tL/kGUyk1NyWV0fUzaD1S9wA//+zdoA=
Date: Fri, 2 Dec 2016 17:43:32 +0000
Message-ID: <EE92A222-EE20-4407-B978-0CE565B69D52@cisco.com>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <20161202171728.GH3403@shrubbery.net>
In-Reply-To: <20161202171728.GH3403@shrubbery.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: multipart/alternative; boundary="_000_EE92A222EE204407B9780CE565B69D52ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/AfszXj-szEp2_9S8v8UXDh0zjJE>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 17:43:44 -0000

--_000_EE92A222EE204407B9780CE565B69D52ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T24gMTIvMi8xNiwgMTI6MTcgUE0sICJoZWFzbGV5IiA8aGVhc0BzaHJ1YmJlcnkubmV0PiB3cm90
ZToNCg0KDQoNCkhpIQ0KDQoNCg0KPiBGcmksIERlYyAwMiwgMjAxNiBhdCAwNDowNDoyMkFNICsw
MDAwLCBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKToNCg0KPg0KDQo+ID4gQzMuIEluIFNlY3Rpb24g
Njogcy9HbG9iYWwgQWRtaW5pc3RyYXRvciBmaWVsZCBNQVkgY29udGFpbiBhbnkgdmFsdWUvR2xv
YmFsIEFkbWluaXN0cmF0b3INCg0KPiA+IGZpZWxkIG1heSBjb250YWluIGFueSB2YWx1ZSAgICAg
VGhhdCDigJxNQVnigJ0gaXMgbm90IG5vcm1hdGl2ZSwgaXQgaXMganVzdCBleHByZXNzaW5nIGEg
ZmFjdC4NCg0KPg0KDQo+IFRoZSBpbnRlbnQgd2FzIHRvIGluZGljYXRlIHRvIGltcGxlbWVudGVy
cyB0aGF0IHRoZSBmaWVsZCBtYXkgYmUgb2YgYW55DQoNCj4gdmFsdWUgYW5kIHRoZXJlZm9yZSBz
aG91bGQgbm90IGJlIGNvbnN0cmFpbmVkLiAgSXMgaXQgbm90IHRoZW4gbm9ybWF0aXZlPw0KDQo+
IG9yIHNob3VsZCB0aGF0IGJlIGV4cHJlc3NlZCBpbiBhbm90aGVyIG1hbm5lcj8NCg0KDQoNCklu
IFNlY3Rpb24gMiwgd2hlcmUgdGhlIExhcmdlIENvbW11bml0eSBpcyBkZWZpbmVkLCBpdCBhbHJl
YWR5IHNheXMgdGhpczog4oCcVGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxk4oCmU0hPVUxE
IGJlIGFuIEF1dG9ub21vdXMgU3lzdGVtIE51bWJlciAoQVNOKS7igJ0gIFRoZSDigJxTSE9VTETi
gJ0gbGVhdmVzIHRoZSBkb29yIG9wZW4gZm9yIGl0IHRvIGJlIGFueXRoaW5nLg0KDQoNCg0KVGhl
IHRleHQgYWJvdmUsIHdoaWNoIGNvbWVzIGxhdGVyLCBpcyBqdXN0IHJlcGVhdGluZyB0aGUgZmFj
dCBhbHJlYWR5IGNvdmVyZWQgaW4gU2VjdGlvbiAyLg0KDQoNCg0KQWx2YXJvLg0K

--_000_EE92A222EE204407B9780CE565B69D52ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <FB66021E5FCA944BBF765C6C162E61D7@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN
CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0
Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1z
dHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0
ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLlBs
YWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZh
bWlseTpDYWxpYnJpO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29s
b3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN
Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx
LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u
MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdj
b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PbiAxMi8y
LzE2LCAxMjoxNyBQTSwgJnF1b3Q7aGVhc2xleSZxdW90OyAmbHQ7aGVhc0BzaHJ1YmJlcnkubmV0
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGkhPC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mZ3Q7IEZyaSwgRGVjIDAyLCAyMDE2IGF0IDA0OjA0OjIyQU0gJiM0MzswMDAwLCBB
bHZhcm8gUmV0YW5hIChhcmV0YW5hKTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZndDsgJmd0OyBDMy4gSW4gU2VjdGlvbiA2OiBzL0dsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxk
IE1BWSBjb250YWluIGFueSB2YWx1ZS9HbG9iYWwgQWRtaW5pc3RyYXRvcg0KPC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGZpZWxkIG1heSBjb250YWluIGFueSB2YWx1ZSZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGF0IOKAnE1BWeKAnSBpcyBub3Qgbm9ybWF0aXZlLCBp
dCBpcyBqdXN0IGV4cHJlc3NpbmcgYSBmYWN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jmd0OyBUaGUgaW50ZW50IHdhcyB0byBpbmRpY2F0ZSB0byBpbXBsZW1lbnRlcnMgdGhh
dCB0aGUgZmllbGQgbWF5IGJlIG9mIGFueTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+Jmd0OyB2YWx1ZSBhbmQgdGhlcmVmb3JlIHNob3VsZCBub3QgYmUgY29uc3RyYWlu
ZWQuJm5ic3A7Jm5ic3A7SXMgaXQgbm90IHRoZW4gbm9ybWF0aXZlPzxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBvciBzaG91bGQgdGhhdCBiZSBleHByZXNzZWQg
aW4gYW5vdGhlciBtYW5uZXI/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIFNlY3Rp
b24gMiwgd2hlcmUgdGhlIExhcmdlIENvbW11bml0eSBpcyBkZWZpbmVkLCBpdCBhbHJlYWR5IHNh
eXMgdGhpczog4oCcVGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxk4oCmU0hPVUxEIGJlIGFu
IEF1dG9ub21vdXMgU3lzdGVtIE51bWJlciAoQVNOKS7igJ0mbmJzcDsgVGhlIOKAnFNIT1VMROKA
nSBsZWF2ZXMgdGhlIGRvb3Igb3BlbiBmb3IgaXQgdG8gYmUgYW55dGhpbmcuPC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij5UaGUgdGV4dCBhYm92ZSwgd2hpY2ggY29tZXMgbGF0ZXIsIGlzIGp1c3QgcmVwZWF0
aW5nIHRoZSBmYWN0IGFscmVhZHkgY292ZXJlZCBpbiBTZWN0aW9uIDIuDQo8L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPkFsdmFyby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_EE92A222EE204407B9780CE565B69D52ciscocom_--


From nobody Fri Dec  2 11:30:28 2016
Return-Path: <heas@shrubbery.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE99129841; Fri,  2 Dec 2016 11:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level: 
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 45tY50zdT8AE; Fri,  2 Dec 2016 11:30:10 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE345129604; Fri,  2 Dec 2016 11:28:51 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 0B4D47A99E; Fri,  2 Dec 2016 19:28:51 +0000 (UTC)
Date: Fri, 2 Dec 2016 19:28:51 +0000
From: heasley <heas@shrubbery.net>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Message-ID: <20161202192850.GB30634@shrubbery.net>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <20161202171728.GH3403@shrubbery.net> <EE92A222-EE20-4407-B978-0CE565B69D52@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <EE92A222-EE20-4407-B978-0CE565B69D52@cisco.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lhSuLJnj-6HfYgqxJ8gnXAWZscM>
Cc: heasley <heas@shrubbery.net>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 19:30:27 -0000

Fri, Dec 02, 2016 at 05:43:32PM +0000, Alvaro Retana (aretana):
> On 12/2/16, 12:17 PM, "heasley" <heas@shrubbery.net> wrote:
> > Fri, Dec 02, 2016 at 04:04:22AM +0000, Alvaro Retana (aretana):
> 
> > > C3. In Section 6: s/Global Administrator field MAY contain any value/Global Administrator
> 
> > > field may contain any value     That “MAY” is not normative, it is just expressing a fact.
> 
> > The intent was to indicate to implementers that the field may be of any
> 
> > value and therefore should not be constrained.  Is it not then normative?
> 
> > or should that be expressed in another manner?
> 
> In Section 2, where the Large Community is defined, it already says this: “The Global Administrator field…SHOULD be an Autonomous System Number (ASN).”  The “SHOULD” leaves the door open for it to be anything.
> 
> The text above, which comes later, is just repeating the fact already covered in Section 2.

ok.  I'd still leave it as it was, but whatever.


From nobody Fri Dec  2 11:53:19 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16D12007C; Fri,  2 Dec 2016 11:53:15 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148070839557.31734.14021922589145223478.idtracker@ietfa.amsl.com>
Date: Fri, 02 Dec 2016 11:53:15 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jhU-avaOzyC8_RfNPc5bbdgknac>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-packet-rate-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 19:53:15 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : BGP Flow Specification Packet-Rate Action
        Authors         : Wesley Eddy
                          Justin Dailey
                          Gilbert Clark
	Filename        : draft-ietf-idr-flowspec-packet-rate-01.txt
	Pages           : 5
	Date            : 2016-12-02

Abstract:
   This document defines a new type of traffic filtering action for the
   BGP flow specification.  The new packet-rate action allows specifying
   a rate-limit in number of packets per second.  This is intended to be
   used in combatting some types of denial of service attacks where the
   packet rate is more important than the raw bitrate of the attack
   traffic.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-packet-rate/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-flowspec-packet-rate-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-packet-rate-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Dec  2 13:24:02 2016
Return-Path: <jheitz@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D79129401; Fri,  2 Dec 2016 13:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level: 
X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 52v88H_YqQhJ; Fri,  2 Dec 2016 13:23:50 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8377B129409; Fri,  2 Dec 2016 13:23:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16084; q=dns/txt; s=iport; t=1480713830; x=1481923430; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uBog0WMqIq0wkEdRQ0PWoFTS/bgvc0KEFLSocB95bWg=; b=OnppCHNc44qZXQwMybaa62VHeFZW9FU+Y4RaULXOYyeI5wgT/VNDerxv QUY0WJ6igEBuTNM2u1N7FU44mHc0bokJhLP6rXRk7TTOEAXrc1xLEZ8Rg ueHrdAdTWGR7Zta5Q/ul6Tnywg1NTgxLSqGH7Kyzoj43MUel5MKGIJJ6J Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AQAT5kFY/4QNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNFAQEBAQEfWoEGBwGNPpcLh3OHZ4UiggaGIgIaggM/FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEEIwpMEAIBCA4DBAEBKAMCAgIfERQJCAIEAQ0FCAyIQQMXrEiCK?= =?us-ascii?q?YdCDYNmAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIY+hFuCSII3gk6CXQWIZmKLMoU?= =?us-ascii?q?0NQGJWoNbg1WBe4R8iUuJTIQ0hAwBHzeBGYNcHIFdcodxAYEMAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,288,1477958400";  d="scan'208,217";a="355249991"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2016 21:23:42 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uB2LNg3S023265 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2016 21:23:42 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 15:23:41 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 2 Dec 2016 15:23:41 -0600
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Ignas Bagdonas <ibagdona.ietf@gmail.com>
Thread-Topic: [Idr] AD Review of draft-ietf-idr-large-community-09
Thread-Index: AQHSTFEplUv+tL/kGUyk1NyWV0fUzaD0l0wAgAAl5QCAAGAfAIAAEI6A///6qJA=
Date: Fri, 2 Dec 2016 21:23:40 +0000
Message-ID: <44c0a3d7e3414775ab2b7ef237999953@XCH-ALN-014.cisco.com>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com> <419db8cd-e4ae-a191-bfd3-8e35ca76b0cd@gmail.com> <477C42EC-359B-41DC-BCEC-9130A245DD67@pfrc.org>
In-Reply-To: <477C42EC-359B-41DC-BCEC-9130A245DD67@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.107.147.71]
Content-Type: multipart/alternative; boundary="_000_44c0a3d7e3414775ab2b7ef237999953XCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/E8gGnEPZTQa49pspyXZU9amjZWI>
Cc: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 21:23:55 -0000

--_000_44c0a3d7e3414775ab2b7ef237999953XCHALN014ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Y29tbXVuaXRpZXMgKG9mIGFueSBraW5kKSBhcmUgc3RvcmVkIGluIGEgdGFibGUuDQpSb3V0ZXMg
dGhhdCBoYXZlIGNvbW11bml0aWVzIGF0dGFjaGVkIGp1c3Qga2VlcCBhIHJlZmVyZW5jZSB0byB0
aGUgY29tbXVuaXR5Lg0KU3VwcG9zZSB0aHJlZSByb3V0ZXMgYXJlIHJlY2VpdmVkIHdpdGggdGhl
IGNvbW11bml0eSBhdHRyaWJ1dGVzOg0KKDE6MSwgMjoyKSwgKDI6MiwgMToxKSwgKDE6MSwgMTox
LCAyOjIpIHJlc3BlY3RpdmVseS4NClRoZSBzeXN0ZW0gd2lsbCBzdG9yZSBvbmx5ICgxOjEsIDI6
MikgYW5kIHRoZSB0aHJlZSByb3V0ZXMgd2lsbCByZWZlcmVuY2UgdGhhdCBvbmUgY29tbXVuaXR5
Lg0KDQpUaGVyZWZvcmUsIGR1cGxpY2F0ZXMgYXJlIHJlbW92ZWQgYW5kIG9yZGVyIG9mIHRyYW5z
bWlzc2lvbiBpcyBvZiBubyBzaWduaWZpY2FuY2UuDQoNClRoYW5rcywNCkpha29iLg0KDQpGcm9t
OiBKZWZmcmV5IEhhYXMgW21haWx0bzpqaGFhc0BwZnJjLm9yZ10NClNlbnQ6IEZyaWRheSwgRGVj
ZW1iZXIgMDIsIDIwMTYgNzozMCBBTQ0KVG86IElnbmFzIEJhZ2RvbmFzIDxpYmFnZG9uYS5pZXRm
QGdtYWlsLmNvbT4NCkNjOiBBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSA8YXJldGFuYUBjaXNjby5j
b20+OyBkcmFmdC1pZXRmLWlkci1sYXJnZS1jb21tdW5pdHlAaWV0Zi5vcmc7IGlkci1jaGFpcnNA
aWV0Zi5vcmc7IGlkckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJZHJdIEFEIFJldmlldyBvZiBk
cmFmdC1pZXRmLWlkci1sYXJnZS1jb21tdW5pdHktMDkNCg0KDQpPbiBEZWMgMiwgMjAxNiwgYXQg
OTozMCBBTSwgSWduYXMgQmFnZG9uYXMgPGliYWdkb25hLmlldGZAZ21haWwuY29tPG1haWx0bzpp
YmFnZG9uYS5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNClJlbW92aW5nIGFuZCBpZ25vcmlu
ZyBhcmUgb2J2aW91c2x5IGRpZmZlcmVudCB0aGluZ3PigKYgIFRoZSB0ZXh0IGFib3ZlIGlzIGZp
bmUgd2l0aCBtZSwgYnV0IEkgd291bGQgYXNrOiB3aGF0IGRvIHRoZSBjdXJyZW50IGltcGxlbWVu
dGF0aW9ucyBkbz8gIElmIHRoZXkgcmVtb3ZlIChhcyBvcmlnaW5hbGx5IHNwZWNpZmllZCksIHRo
ZW4gSSB3b3VsZCBzdWdnZXN0IHlvdSBrZWVwIHRoYXQuDQoNClRoZSBpbXBsZW1lbnRhdGlvbnMg
dGhhdCBJIGFtIGZhbWlsaWFyIHdpdGggZG8gaW50ZXJwcmV0IGZpcnN0IGluc3RhbmNlIG9mIHRo
ZSBjb21tdW5pdHkgdmFsdWUgYW5kIGRvIG5vdCByZWFjdCAoPWlnbm9yZSkgYW55IG90aGVyIGlu
c3RhbmNlcyBvZiB0aGUgc2FtZSBjb21tdW5pdHkgdmFsdWUgb24gdGhlIHJlY2VpdmUgc2lkZS4g
V2hldGhlciBpdCBpcyB0cnVseSBmaXJzdCBpbnN0YW5jZSBhcyBpdCBhcHBlYXJzIG9uIHRoZSB3
aXJlIG9yIHRoZSBmaXJzdCBpbnN0YW5jZSBvZiB0aGUgc29ydGVkIHJlY2VpdmVkIGNvbW11bml0
eSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwsIHRoZSBvdXRjb21lIGlzIHRoYXQgc2luZ2xl
IGNvbW11bml0eSB2YWx1ZSBpcyBpbnRlcnByZXRlZCBvbmx5IG9uY2UuIFRoZXJlZm9yZSBvbiB0
aGUgdHJhbnNtaXQgc2lkZSB0aGVyZSBhcmUgbm8gZHVwbGljYXRlIHZhbHVlcy4gVGhpcyBpcyBi
YXNlZCBvbiBkZWNvZGluZywgcHJvY2Vzc2luZywgYW5kIHRoZW4gZW5jb2RpbmcgdGhlIGNvbW11
bml0eSBhdHRyaWJ1dGUgYW5kIG5vdCBmb3J3YXJkaW5nIGl0IGFzIGEgYmluYXJ5IG9iamVjdCBv
bmx5IC0gSSBhbSBub3QgYXdhcmUgb2YgYW55IGltcGxlbWVudGF0aW9uIHRoYXQgZG9lcyB0aGF0
LiBDb3VsZCBhbnlvbmUgZmFtaWxpYXIgd2l0aCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBiZWhhdmUg
ZGlmZmVyZW50bHkgcGxlYXNlIHNwZWFrIHVwPw0KDQpJbXBsZW1lbnRhdGlvbnMgdGhhdCB0ZW5k
IHRvd2FyZCBtZW1vcnkgY29uc2VydmluZyB0eXBpY2FsbHkgaW1wbGVtZW50IGl0IHRoaXMgd2F5
Og0KLSBTb3J0IHRoZSBlbGVtZW50cy4gIChUaGV5IGhhdmUgc2V0IHNlbWFudGljcywgc28gb3Jk
ZXIgaXMgaXJyZWxldmFudC4pDQotIFJlbW92ZSBkdXBsaWNhdGUgZW50cmllcyAocmVkdW5kYW50
IGFzIEpvaG4gc2F5cykNCi0gSGF2aW5nIGRvbmUgdGhlIGFib3ZlLCBjaGVjayBhZ2FpbnN0IGEg
ZGF0YSBzdG9yZSBmb3IgYSBwcmV2aW91c2x5IGV4aXN0aW5nIHZlcnNpb24uICBJZiBpdCBleGlz
dHMsIHNpbXBseSBidW1wIGl0cyByZWZjb3VudC4NCg0KVGhlIGFib3ZlIGdpdmVzIHRoZSBwcm9w
ZXJ0eSBvZiAiZGlzY2FyZCByZWR1bmRhbnQgb24gcmVjZWl2ZSIuICBJZiBhIHNpbWlsYXIgY2Fu
b25pY2FsaXphdGlvbiBpcyBkb25lIG9uIGVudHJpZXMgdGhhdCBhcmUgdG8gYmUgc2VudCB3aXRo
IHJvdXRlcywgaXQgYWxzbyByZW1vdmVzIGR1cGxpY2F0ZXMvcmVkdW5kYW50IGVudHJpZXMgb24g
c2VuZC4NCg0KTW9kZXJuIGxhbmd1YWdlcyBpbiBtYW55IGNhc2VzIHByb3ZpZGUgInNldCIgc2Vt
YW50aWNzIGFuZCB3b3VsZCBzaW1pbGFybHkgZ2l2ZSB0aGUgYWJvdmUgcHJvcGVydGllcyBhIGJp
dCBtb3JlIGF1dG9tYXRpY2FsbHkuDQoNClRoYXQgc2FpZCwgaW1wbGVtZW50YXRpb25zIG5lZWQg
bmVpdGhlciB1c2UgbW9kZXJuIGxhbmd1YWdlcyAob3IgbWVjaGFuaXNtcyBpbiB0aG9zZSBsYW5n
dWFnZXMpIG9yIG1pZ2h0IG5vdCBiZSBtZW1vcnkgY29uc2VydmluZy4gIFRodXMsIHRoZSB0ZXh0
IHJlY29tbWVuZGluZyByZW1vdmluZyByZWR1bmRhbnQgZW50cmllcyBpcyBzdGlsbCBhIGdvb2Qg
aWRlYS4NCg0KLS0gSmVmZg0KDQo=

--_000_44c0a3d7e3414775ab2b7ef237999953XCHALN014ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg
NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIjsNCglwYW5vc2UtMToyIDExIDYgOSA0IDUg
NCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3Nl
LTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O
b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0K
CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRD
aGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q29u
c29sYXM7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBw
bGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7DQoJY29s
b3I6IzcwMzBBMDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJ
dGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt
dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD
b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5jb21tdW5pdGllcyAob2YgYW55
IGtpbmQpIGFyZSBzdG9yZWQgaW4gYSB0YWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+Um91dGVz
IHRoYXQgaGF2ZSBjb21tdW5pdGllcyBhdHRhY2hlZCBqdXN0IGtlZXAgYSByZWZlcmVuY2UgdG8g
dGhlIGNvbW11bml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5TdXBwb3NlIHRocmVlIHJvdXRlcyBhcmUg
cmVjZWl2ZWQgd2l0aCB0aGUgY29tbXVuaXR5IGF0dHJpYnV0ZXM6PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+
KDE6MSwgMjoyKSwgKDI6MiwgMToxKSwgKDE6MSwgMToxLCAyOjIpIHJlc3BlY3RpdmVseS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtj
b2xvcjojNzAzMEEwIj5UaGUgc3lzdGVtIHdpbGwgc3RvcmUgb25seSAoMToxLCAyOjIpIGFuZCB0
aGUgdGhyZWUgcm91dGVzIHdpbGwgcmVmZXJlbmNlIHRoYXQgb25lIGNvbW11bml0eS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xv
cjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UaGVyZWZvcmUsIGR1cGxpY2F0ZXMg
YXJlIHJlbW92ZWQgYW5kIG9yZGVyIG9mIHRyYW5zbWlzc2lvbiBpcyBvZiBubyBzaWduaWZpY2Fu
Y2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss
c2VyaWY7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29s
b3I6IzcwMzBBMCI+SmFrb2IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEplZmZyZXkgSGFhcyBbbWFpbHRv
OmpoYWFzQHBmcmMub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRGVjZW1iZXIgMDIs
IDIwMTYgNzozMCBBTTxicj4NCjxiPlRvOjwvYj4gSWduYXMgQmFnZG9uYXMgJmx0O2liYWdkb25h
LmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQWx2YXJvIFJldGFuYSAoYXJldGFu
YSkgJmx0O2FyZXRhbmFAY2lzY28uY29tJmd0OzsgZHJhZnQtaWV0Zi1pZHItbGFyZ2UtY29tbXVu
aXR5QGlldGYub3JnOyBpZHItY2hhaXJzQGlldGYub3JnOyBpZHJAaWV0Zi5vcmc8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFtJZHJdIEFEIFJldmlldyBvZiBkcmFmdC1pZXRmLWlkci1sYXJnZS1j
b21tdW5pdHktMDk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiBEZWMgMiwgMjAxNiwgYXQgOTozMCBBTSwgSWduYXMgQmFnZG9uYXMgJmx0OzxhIGhy
ZWY9Im1haWx0bzppYmFnZG9uYS5pZXRmQGdtYWlsLmNvbSI+aWJhZ2RvbmEuaWV0ZkBnbWFpbC5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5SZW1vdmluZyBhbmQgaWdub3JpbmcgYXJlIG9idmlvdXNseSBkaWZmZXJlbnQgdGhpbmdz
4oCmJm5ic3A7IFRoZSB0ZXh0IGFib3ZlIGlzIGZpbmUgd2l0aCBtZSwgYnV0IEkgd291bGQgYXNr
OiB3aGF0IGRvIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBkbz8mbmJzcDsNCiBJZiB0aGV5
IHJlbW92ZSAoYXMgb3JpZ2luYWxseSBzcGVjaWZpZWQpLCB0aGVuIEkgd291bGQgc3VnZ2VzdCB5
b3Uga2VlcCB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPHNwYW4gc3R5
bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBJIGFtIGZhbWls
aWFyIHdpdGggZG8gaW50ZXJwcmV0IGZpcnN0IGluc3RhbmNlIG9mIHRoZSBjb21tdW5pdHkgdmFs
dWUgYW5kIGRvIG5vdCByZWFjdCAoPWlnbm9yZSkgYW55IG90aGVyIGluc3RhbmNlcyBvZiB0aGUg
c2FtZSBjb21tdW5pdHkgdmFsdWUgb24gdGhlIHJlY2VpdmUgc2lkZS4gV2hldGhlciBpdCBpcyB0
cnVseSBmaXJzdCBpbnN0YW5jZQ0KIGFzIGl0IGFwcGVhcnMgb24gdGhlIHdpcmUgb3IgdGhlIGZp
cnN0IGluc3RhbmNlIG9mIHRoZSBzb3J0ZWQgcmVjZWl2ZWQgY29tbXVuaXR5IGlzIGFuIGltcGxl
bWVudGF0aW9uIGRldGFpbCwgdGhlIG91dGNvbWUgaXMgdGhhdCBzaW5nbGUgY29tbXVuaXR5IHZh
bHVlIGlzIGludGVycHJldGVkIG9ubHkgb25jZS4gVGhlcmVmb3JlIG9uIHRoZSB0cmFuc21pdCBz
aWRlIHRoZXJlIGFyZSBubyBkdXBsaWNhdGUgdmFsdWVzLiBUaGlzIGlzIGJhc2VkIG9uDQogZGVj
b2RpbmcsIHByb2Nlc3NpbmcsIGFuZCB0aGVuIGVuY29kaW5nIHRoZSBjb21tdW5pdHkgYXR0cmli
dXRlIGFuZCBub3QgZm9yd2FyZGluZyBpdCBhcyBhIGJpbmFyeSBvYmplY3Qgb25seSAtIEkgYW0g
bm90IGF3YXJlIG9mIGFueSBpbXBsZW1lbnRhdGlvbiB0aGF0IGRvZXMgdGhhdC4gQ291bGQgYW55
b25lIGZhbWlsaWFyIHdpdGggaW1wbGVtZW50YXRpb25zIHRoYXQgYmVoYXZlIGRpZmZlcmVudGx5
IHBsZWFzZSBzcGVhayB1cD88c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkltcGxlbWVudGF0aW9ucyB0aGF0
IHRlbmQgdG93YXJkIG1lbW9yeSBjb25zZXJ2aW5nIHR5cGljYWxseSBpbXBsZW1lbnQgaXQgdGhp
cyB3YXk6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4tIFNvcnQgdGhlIGVsZW1lbnRzLiAmbmJzcDsoVGhleSBoYXZlIHNldCBzZW1hbnRpY3MsIHNv
IG9yZGVyIGlzIGlycmVsZXZhbnQuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+LSBSZW1vdmUgZHVwbGljYXRlIGVudHJpZXMgKHJlZHVuZGFudCBh
cyBKb2huIHNheXMpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4tIEhhdmluZyBkb25lIHRoZSBhYm92ZSwgY2hlY2sgYWdhaW5zdCBhIGRhdGEgc3Rv
cmUgZm9yIGEgcHJldmlvdXNseSBleGlzdGluZyB2ZXJzaW9uLiAmbmJzcDtJZiBpdCBleGlzdHMs
IHNpbXBseSBidW1wIGl0cyByZWZjb3VudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFib3ZlIGdpdmVzIHRoZSBwcm9wZXJ0eSBvZiAm
cXVvdDtkaXNjYXJkIHJlZHVuZGFudCBvbiByZWNlaXZlJnF1b3Q7LiAmbmJzcDtJZiBhIHNpbWls
YXIgY2Fub25pY2FsaXphdGlvbiBpcyBkb25lIG9uIGVudHJpZXMgdGhhdCBhcmUgdG8gYmUgc2Vu
dCB3aXRoIHJvdXRlcywgaXQgYWxzbyByZW1vdmVzIGR1cGxpY2F0ZXMvcmVkdW5kYW50IGVudHJp
ZXMgb24gc2VuZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+TW9kZXJuIGxhbmd1YWdlcyBpbiBtYW55IGNhc2VzIHByb3ZpZGUgJnF1b3Q7c2V0
JnF1b3Q7IHNlbWFudGljcyBhbmQgd291bGQgc2ltaWxhcmx5IGdpdmUgdGhlIGFib3ZlIHByb3Bl
cnRpZXMgYSBiaXQgbW9yZSBhdXRvbWF0aWNhbGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHNhaWQsIGltcGxlbWVudGF0aW9ucyBu
ZWVkIG5laXRoZXIgdXNlIG1vZGVybiBsYW5ndWFnZXMgKG9yIG1lY2hhbmlzbXMgaW4gdGhvc2Ug
bGFuZ3VhZ2VzKSBvciBtaWdodCBub3QgYmUgbWVtb3J5IGNvbnNlcnZpbmcuICZuYnNwO1RodXMs
IHRoZSB0ZXh0IHJlY29tbWVuZGluZyByZW1vdmluZyByZWR1bmRhbnQgZW50cmllcyBpcyBzdGls
bCBhIGdvb2QgaWRlYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+LS0gSmVmZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_44c0a3d7e3414775ab2b7ef237999953XCHALN014ciscocom_--


From nobody Fri Dec  2 14:14:38 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DD8129441; Fri,  2 Dec 2016 14:14:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148071687253.31853.14552018502880631556.idtracker@ietfa.amsl.com>
Date: Fri, 02 Dec 2016 14:14:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/U_E0blyYHBxnBKpRt4gBo7H3Pl0>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-large-community-11.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 22:14:32 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : BGP Large Communities
        Authors         : Jakob Heitz
                          Job Snijders
                          Keyur Patel
                          Ignas Bagdonas
                          Nick Hilliard
	Filename        : draft-ietf-idr-large-community-11.txt
	Pages           : 9
	Date            : 2016-12-02

Abstract:
   This document describes the BGP Large Communities attribute, an
   extension to BGP-4.  This attribute provides a mechanism to signal
   opaque information within separate namespaces to aid in routing
   management.  The attribute is suitable for use with four-octet
   Autonomous System Numbers.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-large-community-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Dec  2 14:21:24 2016
Return-Path: <job@ntt.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6369812944C; Fri,  2 Dec 2016 14:21:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.831
X-Spam-Level: 
X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 9gBf_CR9ZICL; Fri,  2 Dec 2016 14:21:20 -0800 (PST)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6110E129429; Fri,  2 Dec 2016 14:21:20 -0800 (PST)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1cCwCl-000GmH-47 (job@us.ntt.net); Fri, 02 Dec 2016 22:21:20 +0000
Date: Fri, 2 Dec 2016 23:21:15 +0100
From: Job Snijders <job@ntt.net>
To: idr@ietf.org, aretana@cisco.com, idr-chairs@ietf.org
Message-ID: <20161202222115.GC75304@Vurt.local>
References: <148071687263.31853.8873601487550836492.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <148071687263.31853.8873601487550836492.idtracker@ietfa.amsl.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YAMRXyl13fFG14O8RRCiWkHYejI>
Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 22:21:22 -0000

Hi all,

Apologies for the noise. The following URL is the relevant diff which
shows the changes to address Alvaro's feedback. A sentence too many was
removed in -10.

    https://www.ietf.org//rfcdiff?url1=draft-ietf-idr-large-community-09&url2=draft-ietf-idr-large-community-11

Kind regards,

Job

On Fri, Dec 02, 2016 at 02:14:32PM -0800, internet-drafts@ietf.org wrote:
> 
> A new version of I-D, draft-ietf-idr-large-community-11.txt
> has been successfully submitted by Job Snijders and posted to the
> IETF repository.
> 
> Name:		draft-ietf-idr-large-community
> Revision:	11
> Title:		BGP Large Communities
> Document date:	2016-12-02
> Group:		idr
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-idr-large-community-11.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-idr-large-community-11
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-11
> 
> Abstract:
>    This document describes the BGP Large Communities attribute, an
>    extension to BGP-4.  This attribute provides a mechanism to signal
>    opaque information within separate namespaces to aid in routing
>    management.  The attribute is suitable for use with four-octet
>    Autonomous System Numbers.
> 
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 


From nobody Sat Dec  3 02:17:18 2016
Return-Path: <david.freedman@uk.clara.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FE912967B for <idr@ietfa.amsl.com>; Sat,  3 Dec 2016 02:17:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 H3JLHYd88TEn for <idr@ietfa.amsl.com>; Sat,  3 Dec 2016 02:17:15 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.141]) by ietfa.amsl.com (Postfix) with ESMTP id D7091129665 for <idr@ietf.org>; Sat,  3 Dec 2016 02:17:14 -0800 (PST)
Received: from [85.158.136.83] by server-5.bemta-5.messagelabs.com id A5/5F-02084-9AB92485; Sat, 03 Dec 2016 10:17:13 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRWlGSWpSXmKPExsUSsELzi+7K2U4 RBl+2SVu8uv2MyYHRY8mSn0wBjFGsmXlJ+RUJrBm/725hL7jPWHFz2zyWBsbtjF2MXBxCAgeZ JG4tm8jaxcgJ5KxhlNh2gAfEZhMwkpiwbj9LFyMHh4iAosTKT8kgYWGBMInDN5Ywg9giAuESs y5sZoKw9SROflzCCFLOIqAiMeG3EkiYV8Be4ua8v2DTGQVkJb40rgZrZRYQl2j6shIsLiEgIL Fkz3lmCFtU4uXjf6wQNToSC3Z/YoOwbSXm3v/CBGFrSyxb+JoZYr6gxMmZT1gmMArOQjJ2FpL 2WUjaZyFpn4WkfQEj6ypG9eLUorLUIl0jvaSizPSMktzEzBxdQwNTvdzU4uLE9NScxKRiveT8 3E2MwABnAIIdjN//OB1ilORgUhLlrcpyihDiS8pPqcxILM6ILyrNSS0+xCjDwaEkweszCygnW JSanlqRlpkDjDWYtAQHj5II7/qZQGne4oLE3OLMdIjUKUZjjgPvVzxl4tj3bd1TJiGWvPy8VC lxXhmQSQIgpRmleXCDYCngEqOslDAvI9BpQjwFqUW5mSWo8q8YxTkYlYR5JUGm8GTmlcDtewV 0ChPQKR3X7UFOKUlESEkBk8od7+fhBU/aM2dETtt59pHX9qn/zjKx8a3zfnuw1lZxwYtwVo5H mzaIvNtr6sB2atJZZ5OLVdEKzbsnV068cSQ34UMS54odP9hZLUR9TN/lCds2ZKTa+Yg11LwXN 9qfrNN6KWBx3uv/jiGuLGca4u+uaonZ4VH2rUTh3DxZh2v37kz6q56Yq8RSnJFoqMVcVJwIAP nGu5D8AgAA
X-Env-Sender: david.freedman@uk.clara.net
X-Msg-Ref: server-10.tower-36.messagelabs.com!1480760233!74050279!1
X-Originating-IP: [80.168.41.244]
X-StarScan-Received: 
X-StarScan-Version: 9.0.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16353 invoked from network); 3 Dec 2016 10:17:13 -0000
Received: from staff02.mail.eu.clara.net (HELO staff02.mail.eu.clara.net) (80.168.41.244) by server-10.tower-36.messagelabs.com with SMTP; 3 Dec 2016 10:17:13 -0000
Received: from [80.168.41.252] (port=47148 helo=SRVGREXCAS02.claranet.local) by staff02.mail.eu.clara.net (staff02.mail.eu.clara.net [80.168.41.244]:25) with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1cD7NZ-00036m-7U  for idr@ietf.org (return-path <david.freedman@uk.clara.net>); Sat, 03 Dec 2016 10:17:13 +0000
Received: from SRVGREXMB01.claranet.local ([fe80::64bc:5d10:5203:a830]) by SRVGREXCAS02.claranet.local ([::1]) with mapi id 14.03.0319.002; Sat, 3 Dec 2016 10:14:25 +0000
From: David Freedman <david.freedman@uk.clara.net>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
Thread-Index: AdJNTgXIg6oTqyNoQkmKlN+gSmWq4A==
Date: Sat, 3 Dec 2016 10:14:24 +0000
Message-ID: <C6F2701F-9DBD-49DD-B56C-D9C0BDBCFD0E@uk.clara.net>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C2565F65D06AD541BB180933F0D61AC4@claranet.local>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/rAVnPMAORQhqIgwaSVEpiMDMN-k>
Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Dec 2016 10:17:17 -0000

last minute nit: if we are going to recommend that particular reserved ASNs=
 are avoided for the global administrator, can we please include AS_TRANS (=
RFC6793), there is probably a certain irony in not doing so.

Dave =


From nobody Sat Dec  3 02:53:17 2016
Return-Path: <david.freedman@uk.clara.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CE31296A7 for <idr@ietfa.amsl.com>; Sat,  3 Dec 2016 02:53:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qKTHyraPsTK0 for <idr@ietfa.amsl.com>; Sat,  3 Dec 2016 02:53:13 -0800 (PST)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACDB1296A4 for <idr@ietf.org>; Sat,  3 Dec 2016 02:53:13 -0800 (PST)
Received: from [85.158.139.163] by server-11.bemta-5.messagelabs.com id FC/B6-09407-814A2485; Sat, 03 Dec 2016 10:53:12 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJIsWRWlGSWpSXmKPExsUSsELzq67EEqc Ig5fTmS1e3X7G5MDosWTJT6YAxijWzLyk/IoE1ozm5VNYC45yV7x5M4G5gXEuZxcjF4eQwEEm ifMr37B1MXICOWsYJVouWoPYbAJGEhPW7WfpYuTgEBFQlFj5KRkkLCwQJnH4xhJmEFtEIFxi1 oXNTBC2kcTes6/B4iwCKhKfdt8As3kF7CU+bZ3NBDHeXmL1vh9gNqeAg8SD190sIDajgKzEl8 bVYPXMAuISTV9WsoLYEgICEkv2nGeGsEUlXj7+xwpRoyOxYPcnNghbW2LZwtdQuwQlTs58wjK BUWgWklGzkLTMQtIyC0nLAkaWVYwaxalFZalFuoaWeklFmekZJbmJmTm6hgamermpxcWJ6ak5 iUnFesn5uZsYgUFez8DAuIPxUb/fIUZJDiYlUd6qLKcIIb6k/JTKjMTijPii0pzU4kOMMhwcS hK83IuBcoJFqempFWmZOcB4g0lLcPAoifDyg6R5iwsSc4sz0yFSpxgVpcR5dy0CSgiAJDJK8+ DaYDF+iVFWSpiXkYGBQYinILUoN7MEVf4VozgHo5Iw70SQKTyZeSVw018BLWYCWtxx3R5kcUk iQkqqgdFIyU5yX8pC9QuFyiIXj951Vyvl+WrOZJm1R3DJyRVaf7ZZdWmrSHo0XBBUKTzrW/nA qlKfuaYxRHor60L9J9Ot6/9nMrLafvmW+FdVaU1+xobWv3edpPzq/8pemKT/t4U/OmXCw0oHp hSjwMXVO6QnPDc4Pe+lnntD9ONAh79e1/4LcRyyUWIpzkg01GIuKk4EAKdlSGvsAgAA
X-Env-Sender: david.freedman@uk.clara.net
X-Msg-Ref: server-7.tower-188.messagelabs.com!1480762392!76842112!1
X-Originating-IP: [80.168.41.245]
X-StarScan-Received: 
X-StarScan-Version: 9.0.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3339 invoked from network); 3 Dec 2016 10:53:12 -0000
Received: from staff03.mail.eu.clara.net (HELO staff03.mail.eu.clara.net) (80.168.41.245) by server-7.tower-188.messagelabs.com with SMTP; 3 Dec 2016 10:53:12 -0000
Received: from [80.168.41.252] (port=41609 helo=SRVGREXCAS02.claranet.local) by staff03.mail.eu.clara.net (staff03.mail.eu.clara.net [80.168.41.245]:25) with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1cD7wN-0006nt-Cf  for idr@ietf.org (return-path <david.freedman@uk.clara.net>); Sat, 03 Dec 2016 10:53:11 +0000
Received: from SRVGREXMB01.claranet.local ([fe80::64bc:5d10:5203:a830]) by SRVGREXCAS02.claranet.local ([::1]) with mapi id 14.03.0319.002; Sat, 3 Dec 2016 10:47:45 +0000
From: David Freedman <david.freedman@uk.clara.net>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
Thread-Index: AdJNTgXIg6oTqyNoQkmKlN+gSmWq4AABKgA3
Date: Sat, 3 Dec 2016 10:47:44 +0000
Message-ID: <2F606B9F-5966-4A28-9671-BAC5D2759863@uk.clara.net>
References: <C6F2701F-9DBD-49DD-B56C-D9C0BDBCFD0E@uk.clara.net>
In-Reply-To: <C6F2701F-9DBD-49DD-B56C-D9C0BDBCFD0E@uk.clara.net>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hL4VqF41vHcvYY__FL8-sLtBf4U>
Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Dec 2016 10:53:15 -0000

just had an offlist conversation with job, and he has recommended that I el=
aborate on this point as it may be non obvious to some.

The GA is intended to be an ASN, but IMHO AS_TRANS is not an ASN, it is a s=
ignal between peers in an OPEN exchange and a signal between hops that info=
rmation is missing in some way, it is not an ASN in the sense that it shoul=
d (or perhaps now even *could*) be used by anybody as a local ASN for a rou=
ter.

As such I'm aware of code that exists which discriminates against AS_TRANS,=
 there are various libraries which handle data structures like ASNs (which =
could be used in , say , creating or validating a GA field) which would be =
very unhappy if fed AS_TRANS as their initial input.

I understand we want to progress the draft , and that and a line has to be =
drawn between what could be unwise in implementations , vs what could be un=
wise to be seen on the internet , and that a registry can exist for the lat=
ter , but this is something I feel strongly should live on the former side =
, and if a list of values is going to be specified in the draft , I feel th=
is should be in it (irony aside).

Dave=20

> On 3 Dec 2016, at 10:14, David Freedman <david.freedman@uk.clara.net> wro=
te:
>=20
> last minute nit: if we are going to recommend that particular reserved AS=
Ns are avoided for the global administrator, can we please include AS_TRANS=
 (RFC6793), there is probably a certain irony in not doing so.
>=20
> Dave


From nobody Sat Dec  3 05:31:15 2016
Return-Path: <farmer@umn.edu>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79AA129664 for <idr@ietfa.amsl.com>; Sat,  3 Dec 2016 05:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.696
X-Spam-Level: 
X-Spam-Status: No, score=-6.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.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 1fUtswJXQA9C for <idr@ietfa.amsl.com>; Sat,  3 Dec 2016 05:31:10 -0800 (PST)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602DD1297BF for <idr@ietf.org>; Sat,  3 Dec 2016 05:31:10 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id D527B9FE for <idr@ietf.org>; Sat,  3 Dec 2016 13:31:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTtefppWp6Um for <idr@ietf.org>; Sat,  3 Dec 2016 07:31:09 -0600 (CST)
Received: from mail-qt0-f198.google.com (mail-qt0-f198.google.com [209.85.216.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 9ED1161A for <idr@ietf.org>; Sat,  3 Dec 2016 07:31:09 -0600 (CST)
Received: by mail-qt0-f198.google.com with SMTP id x26so190508817qtb.6 for <idr@ietf.org>; Sat, 03 Dec 2016 05:31:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q0qYCHCYz/1lYA9FuKWY1jp5EVoc7Tk0oTmEM8j8aaU=; b=V/vCezuUYmJitMwnRdnsBemwEhfmkOxI8vOXCNcMXrWQ2U9KgskSwGAUSVH9DqDU4Z D4wJuvPusjQ28on7ozbLG4SyY4nJ2LWohYb9zWRB9bCItji4qhI1yMGv6K7BpAAfE3e9 vi7og0VgHBaOvd/n1u10F6GZDf2DbHq1+/SHoQq5hpgWouRTkYqaUB2B5lC0pUndy4eS gvDY5epRRneF1KC/vomwTD/V318J7tDm/esPUA1i+5FBddBOdW5SPBzahw/5CRf9lxlP xAFR3OnvXKDBQOWd+XB7BLGURad0M5j2KJYw+pVfd1RHIR/qqEoZ9OPXLgX1rjRRXe6L 1EPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q0qYCHCYz/1lYA9FuKWY1jp5EVoc7Tk0oTmEM8j8aaU=; b=gHCcO4zeR7+QOGeRq27y1KrMZhVljndJS8qA5FRgIpOTaEI0FWZQsHv2nC2ld7bWqg s/A/GaKQmx6TXZhT4rnsOjfPVu4Vct2cduojdoOS2uZlmFuQhEw36IPmItIZKTkhyCfe jc8tmsGQYr6apkPgTTMutW1Fs2rESeTJpmlY+j0Hjqme5Y3bxmtyMyqb2plIkZINHESA lmviEAIopNxrVVxXA09Dsajv2nRPsaRJOXTfPVqa18a9WYXtEX4XW5jgBPHYNmFaJPRe Ylg7SmfhHhmuTNQHH7hY93M2rnr34mQfE4uvZOUmyCv0KZiYsZRVfYyDzYKwM6PqJONB RTBQ==
X-Gm-Message-State: AKaTC01GDnbEBU3l+PXzaLNY9VaLWTaG2Z8jk4xh8MKH9neSTu3Z6/KSzM5zbOcjKSEUoLUTHV8lSjGkXAks3NMi7bVECVXUksricUIvXpd8xJOxTPfq1T2f6fhvv/QXoSXKfe+5tnpUyy7qvA==
X-Received: by 10.55.76.150 with SMTP id z144mr41202137qka.194.1480771868982;  Sat, 03 Dec 2016 05:31:08 -0800 (PST)
X-Received: by 10.55.76.150 with SMTP id z144mr41202126qka.194.1480771868786;  Sat, 03 Dec 2016 05:31:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.36.198 with HTTP; Sat, 3 Dec 2016 05:31:08 -0800 (PST)
In-Reply-To: <2F606B9F-5966-4A28-9671-BAC5D2759863@uk.clara.net>
References: <C6F2701F-9DBD-49DD-B56C-D9C0BDBCFD0E@uk.clara.net> <2F606B9F-5966-4A28-9671-BAC5D2759863@uk.clara.net>
From: David Farmer <farmer@umn.edu>
Date: Sat, 3 Dec 2016 07:31:08 -0600
Message-ID: <CAN-Dau1iZ+ARQeedtKuJJvGvt-=DHbGQa2vrnDnUy=Lq7jh0oQ@mail.gmail.com>
To: David Freedman <david.freedman@uk.clara.net>
Content-Type: multipart/alternative; boundary=001a114a88683b996b0542c111ff
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Dec 2016 13:31:13 -0000

--001a114a88683b996b0542c111ff
Content-Type: text/plain; charset=UTF-8

I read the new language as a general recommendation, with emphasis on the
three specific examples, and not necessary limited the the three listed
examples, therefore the recommendation already applies to AS_TRANS
[RFC6793].

  The use of Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is
NOT RECOMMENDED.

If the intent is to be generic, as I am interpreting it, then maybe this
could be clarified a bit by adding a reference to the IANA Special-Purpose
ASN Registry with a minor tweak of the language.

   ...([IANA.SpecialAS], and particularly 0 [RFC7607], 65535 and 4294967295
[RFC7300])...

   [IANA.SpecialAS]
             IANA, "Special-Purpose Autonomous System (AS) Numbers",
              <http://www.iana.org/assignments/
              iana-as-numbers-special-registry/>.

Otherwise, if it is intended to apply to only the specified ASNs then maybe
that should be clarified and AS_TRANS [RFC6793] added.

  The use of the following Reserved ASNs is NOT RECOMMENDED, 0 [RFC7607],
23456 [RFC6793], 65535 and 4294967295 [RFC7300].

I prefer the recommendation be generic, with emphasis on 0, 65535, and
4294967295, but not limited to those three.  That way the recommendation
applies to new ASNs added to the IANA Special-Purpose ASN Registry without
have to update this specification each time a new Reserved ASN is added.

Thanks.

On Sat, Dec 3, 2016 at 4:47 AM, David Freedman <david.freedman@uk.clara.net>
wrote:

> just had an offlist conversation with job, and he has recommended that I
> elaborate on this point as it may be non obvious to some.
>
> The GA is intended to be an ASN, but IMHO AS_TRANS is not an ASN, it is a
> signal between peers in an OPEN exchange and a signal between hops that
> information is missing in some way, it is not an ASN in the sense that it
> should (or perhaps now even *could*) be used by anybody as a local ASN for
> a router.
>
> As such I'm aware of code that exists which discriminates against
> AS_TRANS, there are various libraries which handle data structures like
> ASNs (which could be used in , say , creating or validating a GA field)
> which would be very unhappy if fed AS_TRANS as their initial input.
>
> I understand we want to progress the draft , and that and a line has to be
> drawn between what could be unwise in implementations , vs what could be
> unwise to be seen on the internet , and that a registry can exist for the
> latter , but this is something I feel strongly should live on the former
> side , and if a list of values is going to be specified in the draft , I
> feel this should be in it (irony aside).
>
> Dave
>
> > On 3 Dec 2016, at 10:14, David Freedman <david.freedman@uk.clara.net>
> wrote:
> >
> > last minute nit: if we are going to recommend that particular reserved
> ASNs are avoided for the global administrator, can we please include
> AS_TRANS (RFC6793), there is probably a certain irony in not doing so.
> >
> > Dave
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>



-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

--001a114a88683b996b0542c111ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I read the new language as a general recommendation, =
with emphasis on the three specific examples, and not necessary limited the=
 the three listed examples, therefore the recommendation=C2=A0already appli=
es to AS_TRANS [RFC6793].=C2=A0</div><div>=C2=A0<br></div><div>=C2=A0 The u=
se of Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT RE=
COMMENDED.<br></div><div><br></div><div>If the intent is to be generic, as =
I am interpreting it, then maybe this could be clarified a bit by adding a =
reference to the IANA Special-Purpose ASN Registry with a minor tweak of th=
e language.<div><br>=C2=A0 =C2=A0...([IANA.SpecialAS], and particularly 0 [=
RFC7607], 65535 and 4294967295 [RFC7300])...</div><div><br>=C2=A0 =C2=A0[IA=
NA.SpecialAS]<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA, &quo=
t;Special-Purpose Autonomous System (AS) Numbers&quot;,<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"http://www.iana.org/assig=
nments/">http://www.iana.org/assignments/</a><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 iana-as-numbers-special-registry/&gt;.</div><div><=
br></div><div>Otherwise, if it is intended to apply to only the specified A=
SNs then maybe that should be clarified and AS_TRANS [RFC6793] added.</div>=
<div><br></div><div>=C2=A0 The use of the following Reserved ASNs is NOT RE=
COMMENDED, 0 [RFC7607], 23456 [RFC6793], 65535 and 4294967295 [RFC7300].</d=
iv><div><br></div><div>I prefer the recommendation be generic, with emphasi=
s on 0, 65535, and 4294967295, but not limited to those three.=C2=A0 That w=
ay the recommendation applies to new ASNs added to the IANA Special-Purpose=
 ASN Registry without have to update this specification each time a new Res=
erved ASN is added.</div><div><br></div><div>Thanks.</div></div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Dec 3, 2016 at=
 4:47 AM, David Freedman <span dir=3D"ltr">&lt;<a href=3D"mailto:david.free=
dman@uk.clara.net" target=3D"_blank">david.freedman@uk.clara.net</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">just had an offlist conversat=
ion with job, and he has recommended that I elaborate on this point as it m=
ay be non obvious to some.<br>
<br>
The GA is intended to be an ASN, but IMHO AS_TRANS is not an ASN, it is a s=
ignal between peers in an OPEN exchange and a signal between hops that info=
rmation is missing in some way, it is not an ASN in the sense that it shoul=
d (or perhaps now even *could*) be used by anybody as a local ASN for a rou=
ter.<br>
<br>
As such I&#39;m aware of code that exists which discriminates against AS_TR=
ANS, there are various libraries which handle data structures like ASNs (wh=
ich could be used in , say , creating or validating a GA field) which would=
 be very unhappy if fed AS_TRANS as their initial input.<br>
<br>
I understand we want to progress the draft , and that and a line has to be =
drawn between what could be unwise in implementations , vs what could be un=
wise to be seen on the internet , and that a registry can exist for the lat=
ter , but this is something I feel strongly should live on the former side =
, and if a list of values is going to be specified in the draft , I feel th=
is should be in it (irony aside).<br>
<br>
Dave<br>
<br>
&gt; On 3 Dec 2016, at 10:14, David Freedman &lt;<a href=3D"mailto:david.fr=
eedman@uk.clara.net">david.freedman@uk.clara.net</a>&gt; wrote:<br>
&gt;<br>
&gt; last minute nit: if we are going to recommend that particular reserved=
 ASNs are avoided for the global administrator, can we please include AS_TR=
ANS (RFC6793), there is probably a certain irony in not doing so.<br>
&gt;<br>
&gt; Dave<br>
<br>
______________________________<wbr>_________________<br>
Idr mailing list<br>
<a href=3D"mailto:Idr@ietf.org">Idr@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/idr" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/idr</a><br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>David Farmer=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <a href=3D"mailto:Email%3Afarm=
er@umn.edu" target=3D"_blank">Email:farmer@umn.edu</a><br>Networking &amp; =
Telecommunication Services<br>Office of Information Technology<br>Universit=
y of Minnesota=C2=A0=C2=A0 <br>2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 Phone: 612-626-0815<br>Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: =
612-812-9952<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D </div>
</div>

--001a114a88683b996b0542c111ff--


From nobody Sun Dec  4 18:16:57 2016
Return-Path: <jheitz@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7E41296A2 for <idr@ietfa.amsl.com>; Sun,  4 Dec 2016 18:16:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.418
X-Spam-Level: 
X-Spam-Status: No, score=-17.418 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 EMbhO6p8Ssb3 for <idr@ietfa.amsl.com>; Sun,  4 Dec 2016 18:16:54 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437E4129477 for <idr@ietf.org>; Sun,  4 Dec 2016 18:16:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2227; q=dns/txt; s=iport; t=1480904214; x=1482113814; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nTQUTXvsduBMxsU9ITXC79L5WIAhJyO8ARoFI25MZdo=; b=iwc32/spHqPQoY/LQUTRGCGLCwnVttwTA8nSb0wkqS1UYsd5uW0ATIxB tarSLt8pigWHc7fMt9heZd+tveJ/cRlZCPm3OHmgVZlFHHsl0TH2EcVHN r+WSwAQMLmhldO+Wppsc+KuDLu3CqsN4yIFbaLv0JggmmXozm5iU0V6qy o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBWzURY/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAR9agQaNR5cJlH2CCB4LhXkCgh0/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDAQEBODQJAgULAgEIGB0BECcLJQEBBA4FFIhTCA6uLYsuAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBFwWGPoF9gl6EGS+DMYIwBZpmAZEWgXKEfYlOjgKEDAE?= =?us-ascii?q?fN4EZIw4BAYMkgX5yAYYgK4IQAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,302,1477958400"; d="scan'208";a="355715250"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2016 02:16:53 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uB52Gru3029482 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Dec 2016 02:16:53 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 4 Dec 2016 20:16:52 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Sun, 4 Dec 2016 20:16:52 -0600
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: David Freedman <david.freedman@uk.clara.net>
Thread-Topic: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
Thread-Index: AdJNTgXIg6oTqyNoQkmKlN+gSmWq4AABKgA3AFK9s4Y=
Date: Mon, 5 Dec 2016 02:16:52 +0000
Message-ID: <61F9CE83-702E-401C-B4C4-D2A9352447A8@cisco.com>
References: <C6F2701F-9DBD-49DD-B56C-D9C0BDBCFD0E@uk.clara.net>, <2F606B9F-5966-4A28-9671-BAC5D2759863@uk.clara.net>
In-Reply-To: <2F606B9F-5966-4A28-9671-BAC5D2759863@uk.clara.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/tg_gVjNwrFWklo4dTRUHo7Rkqos>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2016 02:16:56 -0000

No new text is required to cover this: 23456 is not an ASN.
Besides, if anyone were to put it into a large community, no harm would be =
done other than what would happen if any other unassigned ASN were used.

About reserving values, we don't reserve values because the values are unus=
able, but because we may want to use them for other purposes later. There i=
s no need to reserve another value. 3 is more than enough.

Thanks,
Jakob.


> On Dec 3, 2016, at 2:53 AM, David Freedman <david.freedman@uk.clara.net> =
wrote:
>=20
> just had an offlist conversation with job, and he has recommended that I =
elaborate on this point as it may be non obvious to some.
>=20
> The GA is intended to be an ASN, but IMHO AS_TRANS is not an ASN, it is a=
 signal between peers in an OPEN exchange and a signal between hops that in=
formation is missing in some way, it is not an ASN in the sense that it sho=
uld (or perhaps now even *could*) be used by anybody as a local ASN for a r=
outer.
>=20
> As such I'm aware of code that exists which discriminates against AS_TRAN=
S, there are various libraries which handle data structures like ASNs (whic=
h could be used in , say , creating or validating a GA field) which would b=
e very unhappy if fed AS_TRANS as their initial input.
>=20
> I understand we want to progress the draft , and that and a line has to b=
e drawn between what could be unwise in implementations , vs what could be =
unwise to be seen on the internet , and that a registry can exist for the l=
atter , but this is something I feel strongly should live on the former sid=
e , and if a list of values is going to be specified in the draft , I feel =
this should be in it (irony aside).
>=20
> Dave=20
>=20
>> On 3 Dec 2016, at 10:14, David Freedman <david.freedman@uk.clara.net> wr=
ote:
>>=20
>> last minute nit: if we are going to recommend that particular reserved A=
SNs are avoided for the global administrator, can we please include AS_TRAN=
S (RFC6793), there is probably a certain irony in not doing so.
>>=20
>> Dave
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From nobody Tue Dec  6 07:52:39 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC2F1294F0; Tue,  6 Dec 2016 07:52:33 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148103955345.1834.13037904512798298305.idtracker@ietfa.amsl.com>
Date: Tue, 06 Dec 2016 07:52:33 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Go69S2xeCI69z0grem1Cct_nI4U>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-flowspec-label-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 15:52:33 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Carrying Label Information for BGP FlowSpec
        Authors         : Qiandeng Liang
                          Susan Hares 
                          Jianjie You
                          Robert Raszuk
                          Dan Ma 
	Filename        : draft-ietf-idr-bgp-flowspec-label-01.txt
	Pages           : 10
	Date            : 2016-12-06

Abstract:
   This document specifies a method in which the label mapping
   information for a particular FlowSpec rule is piggybacked in the same
   Border Gateway Protocol (BGP) Update message that is used to
   distribute the FlowSpec rule.  Based on the proposed method, the
   Label Switching Routers (LSRs) (except the ingress LSR) on the Label
   Switched Path (LSP) can use label to indentify the traffic matching a
   particular FlowSpec rule; this facilitates monitoring and traffic
   statistics for FlowSpec rules.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-label/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-label-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-flowspec-label-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Dec  6 08:34:12 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9C0129476; Tue,  6 Dec 2016 08:34:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148104204756.1842.18149052569004984036.idtracker@ietfa.amsl.com>
Date: Tue, 06 Dec 2016 08:34:07 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/r3omxRzvRQ5Ucb0GE2QsI9oiyWw>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-mpls-match-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 16:34:07 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : BGP Flow Specification Filter for MPLS Label
        Authors         : Lucy Yong
                          Susan Hares
                          Qiandeng Liang
                          Jianjie You
	Filename        : draft-ietf-idr-flowspec-mpls-match-01.txt
	Pages           : 8
	Date            : 2016-12-06

Abstract:
   This draft proposes BGP flow specification rules that are used to
   filter MPLS labeled packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-mpls-match/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-flowspec-mpls-match-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-mpls-match-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Dec  8 01:48:54 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6CD129CDB; Thu,  8 Dec 2016 01:48:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148119053036.6907.13632564264559046336.idtracker@ietfa.amsl.com>
Date: Thu, 08 Dec 2016 01:48:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/eLg3axx8G2UtnnRRBjFuo0sP6IY>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-aspath-orf-12.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 09:48:50 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Analysis of Existing work for I2NSF
        Authors         : Susan Hares
                          Keyur Patel
	Filename        : draft-ietf-idr-aspath-orf-12.txt
	Pages           : 7
	Date            : 2016-12-08

Abstract:
   This document defines a new Outbound Router Filter type for BGP,
   termed "Aspath Outbound Route Filter", that can be used to perform
   aspath based route filtering.  This ORF-type supports aspath based
   route filtering as well as regular expression based matching, for
   address groups.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-aspath-orf/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-aspath-orf-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Dec  8 05:44:10 2016
Return-Path: <arjen@us.ntt.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E108512A03C for <idr@ietfa.amsl.com>; Thu,  8 Dec 2016 05:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.497
X-Spam-Level: 
X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 keBOnw_QkzYq for <idr@ietfa.amsl.com>; Thu,  8 Dec 2016 05:44:07 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DAB12A03D for <idr@ietf.org>; Thu,  8 Dec 2016 05:44:07 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <arjen@us.ntt.net>) id 1cEyzV-0003BY-Pc (arjen@us.ntt.net) for idr@ietf.org; Thu, 08 Dec 2016 13:44:06 +0000
From: "Arjen Zonneveld" <arjen@us.ntt.net>
To: idr@ietf.org
Date: Thu, 08 Dec 2016 14:44:03 +0100
Message-ID: <3DF71C75-EF0F-4BE4-8809-12F61A22A396@us.ntt.net>
In-Reply-To: <20161130204903.GH10210@Vurt.local>
References: <148052490104.3081.2049626653192295584.idtracker@ietfa.amsl.com> <20161130204903.GH10210@Vurt.local>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate Trial (1.9.6r5310)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Wyhs6VKqjppkEqgizXGBzsQN8jw>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-shutdown-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 13:44:09 -0000

Hi all,

On 30 Nov 2016, at 21:49, Job Snijders wrote:

> Hi all,
>
> I manually created a PCAP file to show what the shutdown communication
> looks like on the wire. This file can be used to test wireshark, 
> tcpdump
> and other packet analysers.
>
> 	http://instituut.net/~job/shutdown.pcap
>
https://code.wireshark.org/review/#/c/19144/ has a patch to analyse the 
Shutdown Communication packet with wireshark/tshark.

Kind regards,
Arjen


From nobody Fri Dec  9 12:33:25 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 461A1129535; Fri,  9 Dec 2016 12:33:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148131560425.4618.6040339806713157537.idtracker@ietfa.amsl.com>
Date: Fri, 09 Dec 2016 12:33:24 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OzGTsPdhgNwRSZBHk93gQQa_yY4>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-08.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 20:33:24 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Notification Message support for BGP Graceful Restart
        Authors         : Keyur Patel
                          Rex Fernando
                          John Scudder
                          Jeff Haas
	Filename        : draft-ietf-idr-bgp-gr-notification-08.txt
	Pages           : 7
	Date            : 2016-12-09

Abstract:
   The current BGP Graceful Restart mechanism limits the usage of BGP
   Graceful Restart to BGP protocol messages other than a BGP
   NOTIFICATION message.  This document defines an extension to the BGP
   Graceful Restart that permits the Graceful Restart procedures to be
   performed when the BGP speaker receives a BGP NOTIFICATION Message or
   the Hold Time expires.  This document also defines a new BGP
   NOTIFICATION Cease Error subcode whose effect is to request a full
   session restart instead of a Graceful Restart.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sat Dec 10 11:40:09 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D09BF129493; Sat, 10 Dec 2016 11:40:03 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148139880384.3845.8443698676004819288.idtracker@ietfa.amsl.com>
Date: Sat, 10 Dec 2016 11:40:03 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QvQWu7rxcuGOhyo4ypslaZSdWnc>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-09.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 19:40:04 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Notification Message support for BGP Graceful Restart
        Authors         : Keyur Patel
                          Rex Fernando
                          John Scudder
                          Jeff Haas
	Filename        : draft-ietf-idr-bgp-gr-notification-09.txt
	Pages           : 7
	Date            : 2016-12-10

Abstract:
   The current BGP Graceful Restart mechanism limits the usage of BGP
   Graceful Restart to BGP protocol messages other than a BGP
   NOTIFICATION message.  This document defines an extension to the BGP
   Graceful Restart that permits the Graceful Restart procedures to be
   performed when the BGP speaker receives a BGP NOTIFICATION Message or
   the Hold Time expires.  This document also defines a new BGP
   NOTIFICATION Cease Error subcode whose effect is to request a full
   session restart instead of a Graceful Restart.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sat Dec 10 11:42:08 2016
Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAEA1289B0; Sat, 10 Dec 2016 11:42:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 1VPNfBkZjNsZ; Sat, 10 Dec 2016 11:42:03 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0136.outbound.protection.outlook.com [104.47.36.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190191294EF; Sat, 10 Dec 2016 11:41:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8S/inG4tx4iqQIaJIczjnp7gEC4t+DregHdKp4LSBTE=; b=ZSQSknHkKYmdZ3dKsPdQOoAoPc2FFiPbOVaBLjLTpOVT+F2iZNrcgs+/tsIrhjSzI/jsjE7QEE1eKcXS9x6RlgLJFD1eYGZD466JpaadoWihtqaS/7Qb/5iR8PBa4Rga3syLI8rHx6tg0votqtshtj3RWJBjQ2n8RH1gqD92YoM=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.104.147] (66.129.239.15) by CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Sat, 10 Dec 2016 19:41:57 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_215E5693-C012-4402-9223-69F958EF621D"
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <CANK0pbaDkpcjcpDyUa=kVOd5kgAHG+47VirZjNbGqrXZUusgEg@mail.gmail.com>
Date: Sat, 10 Dec 2016 14:41:51 -0500
Message-ID: <9017447E-CCC5-41E1-87AA-E046AB362B5C@juniper.net>
References: <CANK0pbZbZ6ja_F=x91wz4wZ6nd+4as6oX26kE3V5ekopjO9Bpw@mail.gmail.com> <C1F6ED1A-DCA0-4A0D-B6F0-9DF0C320E4EB@juniper.net> <CANK0pbaDkpcjcpDyUa=kVOd5kgAHG+47VirZjNbGqrXZUusgEg@mail.gmail.com>
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.239.15]
X-ClientProxiedBy: MWHPR02CA0009.namprd02.prod.outlook.com (10.168.209.147) To CO2PR05MB2502.namprd05.prod.outlook.com (10.166.95.148)
X-MS-Office365-Filtering-Correlation-Id: aff6d6b6-2c3e-430c-f2ae-08d421349ab0
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR05MB2502;
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 3:sbLTSArnVy/Wl71BzzFD5DYQp82kAkLmRrEAUNPZsDcgt5rJHTKMsnLgafOdBn1hr9PY4Wb3PWa4ao2f50ZHgQg03cNX8c+eF2+05hL3OX2i3AY31/t6oHrdl4zRTuxO/FyO1KGhNaP87TnxmPR/Qo5FGpQqci8OpkTr9tLaw+Qwv+ZqPIbZuKowYaaHpeFM9mo3KQN1AN/x7iIkYxDe9Ux3qFRKSZ7GMifbUXpRoDB7t8EvB2PQNVscxBlOmudFxIpQU4Ppf+8aqXXuLpO2lQ==
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 25:IKTPwfA/gwEMwsuuPEjENSH0Bse7SHCVAVZhxk9sT?= =?us-ascii?Q?c1+EwprNLBO7FrWP1eiURtjdJPK7oxADvVX+cqhgYwGU6zofYp6roRMpuUUo?= =?us-ascii?Q?U0lfDUtt407pRZuCkAMQmcKpEl9gvlH/piZqmyu6dbfZa6GmMhTY53R3xkLH?= =?us-ascii?Q?diXzykyY78jvfQQqPfPazx4wEg1wdqRMubKyvkhVN7B0Wg4vRCgJ1UH7Tsse?= =?us-ascii?Q?v0EP0c46jJgNKZQOQf8plqwp05BMWiIvP6IKK9yND3rIu3AruyxcY2aZqj2z?= =?us-ascii?Q?0+8P14AQOZ3mJxNObSKYiy5FgjfXPcGmjrjN5XxSw75rAtUOvFIFUQBq7mfc?= =?us-ascii?Q?uTlOGhAsYzdLymeOAWHTeWKbdneiH1RPuy67vmmH0dXpOVxl2cekPxhslNXF?= =?us-ascii?Q?ZdVmAacLSN0fji5JuluFgbkNC5LnR0qX+DpRdSMlY9weyq6gjUIgZNzLOiGP?= =?us-ascii?Q?A53LP4hscZtAEg6LKvRwag5heei/viMYGi6fdMtWYU2Tdg3iS8nr+8XAQ8J8?= =?us-ascii?Q?QiFDfUNPt1eXb3pfuFF6wEeDURB3me5kgCO80tPWuH7pkF1e8wl+4QV8KBMi?= =?us-ascii?Q?r0AM2hDZxSXuOC+j/q2j7l94/Xx8tDxiTQ5HCHVzdJAXjC8YWKUjAMJCCALg?= =?us-ascii?Q?Z9E1dZ7o3uu2uo4U2ZdouqGIlJ5DaZfzfBZY1p+pWqa6CnK27oOZTKpEqK4E?= =?us-ascii?Q?KLX9dcU8lqI2li10IeR+0J8RF7VQ0fJURd5YU4uaTB0NZ4J0ApKnSja41yZa?= =?us-ascii?Q?QatRHzwPxO2B5SAcheUdHAuxGMKKRGMDd1wJ0zstIrVR4DMh/N17p76u3xKw?= =?us-ascii?Q?KffziV1UF5rXNbBTJQl5pqFJ57PG/O69He4Gy5PD4O7wmAZFgZ12JD1E8WYG?= =?us-ascii?Q?+hLPxi6DhVmODAHqpKsbgaXi5rNh92IB1pq7iXjaoKJZWZd+4VAw8SXWCWr5?= =?us-ascii?Q?cDZIo+7xDT/g3gp4ItdMp5731loMp8hMW+sk4tmF53wyItMVb6sqe/tlOzhY?= =?us-ascii?Q?F+DEZVvmv5oEciclFf0eBom?=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 31:k609C3HEXTnVMoaPWE7RXglzM0gngT9rlWI/xrvOaLxaZu8CA8UrB4nWlRLaPmTZh8a1b1cDdONRboE4ZJfJtAaWnVpmHFAva7KeJK/b6lw1AbFUGXZXjLHfiaVjPBWpjfeSFpUy/x/tp9C9+SMT4/BEZmFcqHWjrcUBJkzNe5+rNxCgFnDP6eY1f2CIx9H3w6mSSlnwkwb0209C613ebDkekwzIYsmd8p8s9MeI2PRpYJNHvNZFZKW4Fc7uwJXFJGSMCdVxQUg7WwHD+Q5tsY08txv6Be8/w89hUOJXDpY=; 20:mABFx8d3RoVl1aN13vuYa8r/dY6mMQ2P8zMCe+0oaxBYbGU8TKAYp4S88sECahfpCe2Pw6Ke4+dOUtaBNHOh9Jcz/ig+11Yu0LUGocoAB1NFsTy6k8ZGUxrEE6e3uBhC1Kjihv3H3MHgKv9ynhPxWV6KRTlT1W/e7Ys5L6jDJy8ig9x7iTwVz5s16Z2T2o7nr72nXS0o/usP8pwfkhiwA2zaIR4wyATy8WJXlmKv6RsyEqDLodZH+SIGsjH+oy/4JWCuv5XO39N31X9QIIG6WMR2Go4PfBU+/NrgJf/bTAHdqKdJcz0HcUOPLALVIZF0bVWP9aOoC/k/pERa0hRFUCLGY76nSloOXlYKWMwrUmzETPt6CkncmYWkixv+wY2JK8eMkSwUAMX+wvEcgEB/ZUikKIkLEfOIvJMct5YmB3mpjcHwpxcHUoTHkbb/Mqf2zdQVKq0N4ow6LeCEfIkAp/dTNjJE2SHv5X3tFexGbXM0FOf5vG0fvJzqeHOblRTD
X-Microsoft-Antispam-PRVS: <CO2PR05MB2502C85A8ABF2F5724AB1C8DAA860@CO2PR05MB2502.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:CO2PR05MB2502; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2502; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 4:VmDeK6IiojkX/ZHUEXJImSlewWxOOaQuUhkW8D8TAiprJKQHcVd4Sxkq+2EOJqe/AwXEcg1lj9MpO9i2FaUh+4BgHyBWUpkr4tM50Hb7CfkSJmrF10uHJTY6OQC5Zb68cfFNMpmEMQnPbP+QVRtgbfbmRyw04GdA4UtQODCFKp6NeOo5zCAI+S07VETicsByWe4XR2DedH+TgcHyo9UfL6FHm6WvQr0e0YWX2wvFlvtoB+ZFQCRXUMkJgHrvxDaXPTeGtkqHCltPXk9QpqOnQFSYWJ8utXDv8SyUeMnjxFB5/WkL4deQs7Bpy9ir7FKcD7PSZzog7qpUAnLDhskAUDgk1iH3iTLrLHfSEUNoXUd6sSJb4WIMJvNzI10oaU4X7zVJq/HEU1/pj5IS4f9WSNHJZNyJxZUs5Kn+cbkM0Hh0eMAqgTGKKkzSu8aiMIO9vVNdwvGpE9eiVwKBthK/0/Tn2gcXNGFIvyfXLtZ4dzqPHj/EFloMU8U9RnPzBkZI8bhZ49TbiUKaTR9p/9APB8w21iU6ClOrORpcTSC6Gto9XqFgjJP/aZbNdrBxvdbdcKunklH4z4OxSy5AMChXa2sog5kS2xFlhThrktfULtIKj47fkBc3Qqa99DWxpYAIA2KEG66FgGDM/VSP7M+hfg==
X-Forefront-PRVS: 0152EBA40F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(7916002)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(24454002)(51444003)(25584004)(199003)(377454003)(189002)(260700001)(189998001)(7736002)(5660300001)(50986999)(101416001)(68736007)(105586002)(69556001)(33656002)(512954002)(76176999)(50226002)(2950100002)(2906002)(6916009)(3846002)(110136003)(6666003)(38730400001)(106356001)(229853002)(36756003)(4326007)(6486002)(77096006)(42186005)(6116002)(81166006)(92566002)(15650500001)(8676002)(230783001)(66066001)(81156014)(90366009)(97736004)(83716003)(57306001)(86362001)(82746002)(84326002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2502; H:[172.29.104.147]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2502; 23:JAFU+dKMuBSWPhVJmuiFkuE81UQlrGqrzHzMZBl6B?= =?us-ascii?Q?80HYsztEB73c7ySPNqmBaH8uMWktHNUwUD2JxISzRnUnEDohPErNCUeo9gEm?= =?us-ascii?Q?2TtMhfXh+HDAW7QLIzw0zJEFrv8nMzRnR29v5crMzWSFtZSAr8ok3rF8cIsE?= =?us-ascii?Q?MmX4NyshhHOnFzs0nwsNuplsLrnzf0gtOCiXXMPwUpig7STjA3DH4O+6lMod?= =?us-ascii?Q?rGzMsakkWcBOA1alxjjcfgNIc6ZTKKvyet8AaHuwJsbdqglp9uSQRoKmLN+F?= =?us-ascii?Q?wfaIhh1boZcY4JUrQYLyOLlz3qq3e8B3WGwownWEvyYPwEIXU8NmXjNiVjJv?= =?us-ascii?Q?cYF8bpDgRvS9KPR4b6r35vWy3hMeCaA5IcrzoGvX8g6T1x7RoCP9LTNSzATd?= =?us-ascii?Q?y9MWGvvNQPxL/k2a1i3tlYa1Z9uJESdTkRRabMTnrgVOI2BRENXgejE7Ynvm?= =?us-ascii?Q?pXU82ChEtEpHqxCHgaZxQky01CuNc5HqiRoN6PPgcWMtPx+qaDWbzvZTiO+x?= =?us-ascii?Q?7MFe/bZqnbFzd/IZiEmS4qJr4vdEXwdbJCMu5dJEH6okDTZ92k035WnET0gw?= =?us-ascii?Q?byDbxUsMWYDo6fAK+VqR2bpNByAkeP3OM17X7ktc75MAXj13X91v4V071DhW?= =?us-ascii?Q?loTOUQSDSA57JePOqxO3JtySICQtTNdj0oT04F/sYR4A7XuEcicg5ZbtOxJo?= =?us-ascii?Q?o1pcHqk0U4ZeIEZj4bjy0NwdqDP11N9RZ7acGglQauHzAYAM5WO5JzD23pTj?= =?us-ascii?Q?IcCBBpFvhbKZNZjXxMcwSqeRfPG32zZMBqm02SshwDBgue+LY6EdSGjDCLy4?= =?us-ascii?Q?9lInf/Zy6mXbeBGtunGkxTfcAJBKa24wy7Q/K7qD/wTqJE6s6UNLbUY5DY9n?= =?us-ascii?Q?HSr1xpfl5rUCCCDWNEkKc1/KYK/OSGono2VKEIIl5I5ZncjVAN4G44s9FY/B?= =?us-ascii?Q?2lEO0PLEFc2Q974rCtzvl/IziSdTZsdRYgB6Wm5KoAMJbf8alpgpisAvc8Ac?= =?us-ascii?Q?qkwBvmPT+KZQ9M+hDspMxNw4NUEKJyVbyC95mvq0x01fBIdmbshU1KbKtw4T?= =?us-ascii?Q?c4RaX6mSRqnna0qcZA1tQDvwbiSb1wW1HRkxeeLhTIiK7304LA8rn1m9kiD3?= =?us-ascii?Q?z2T7/g/V/rDPx21OmDrHUm3OkNxIh/L6+AFPW4W5T6ipojv5jSLhmlp5MuwZ?= =?us-ascii?Q?kiMuFAei4bhOw3/N2sTCLoB8awNECqfCyRlrEEeqk1c1bIHefWAr6BzGM5hF?= =?us-ascii?Q?d/dHarPnXTf3PVOMsuNi4AtAwCzjZvmhTTXcsS6EE78ICm6jP0/liCtVyfKO?= =?us-ascii?Q?CYdDPu/eFKTqcQqlE5fLCkSZ91teU/aISbl/ciyOiQV5OJib5i52kv7IHth4?= =?us-ascii?Q?4fEVR9Af9gW1+P3e7l+yQAETw3fj8bN5f0JNJhG7yb0bVhV?=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 6:rTekE+bcrjESoEDw0zIJRUDCta73Kudxu5U9TPVPWOk79yASar3CDL/4xbqj1vbMywCWrK0vnIK797jYWivYynvxLorLsSuc9vSIR1zORMRgMasSwSDEwZ4PkL5rakIQR19h4mlQcGVXZMhQ1acaAk7XFzzNc/nXNEpt58/+OkDu5KN7AztPsRCYYtPrIPE33hzMO6yh0MLCcIFrTnSdSWUAcm3zTHYwQn3QeveCyG0or4i+n7aKHYZOHWubGrTwu9gRD19EqKQoyh3om3Dy0Jrd2FXRYbJVaPzjAGs1LKBTOyyxRH6SII5rYAZd0oT1FVD3Xvv3Z/iNM3wK1wGmiUEWcUWF+L0EtEJtunLGMRKwh2ULxi9OUcCNSphvJdUNztLjzooOvZKpsncxgsRTcGUZfXvqKRoU/qp/rjxlJQWV5fihlAGKik8qbiM7zCjXNsMtzhicYCCe6IE71ZIpV7VTR0V8YOXrpvN+860ydruNhVeK6mkzyMIj+Yb8Oi6p; 5:p49ZodL+j2vYFGYDX9uIoKMOBbWvgGc7x7ZvmNPfyWkJoDURKwUG7CkA0XRXPJ73EW2NJdYdjbbsDzg29Zfc07DBucYwKfQAB9WAtYGKs9AKwgdA2z6fo6vrjf3wtWyJk6PceM2mIObYa5J1/Shr7Q==; 24:Pz4EDLmsLqnym5/xKnavYFv1Fd2EBvuWDDzhzxd6xJkL3txbctiXclEtdz5XtIBQKZyKAaUs13f4I/uuaXSgZE7ZhZO+ZHh+VLzMBH8OvVQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2502; 7:OTQapr0p3Anv1hHadn2Z8IKaPilQcjJDkZMNkMmf3fJKJclZP83VKibNzkEKiiF+gyL4wllANauhIHanMswVMzL7Kunjcfn5BWVKfhPWiGqKZTV905OwC6cGJRTkVS25nNs5lkndEHf+Q/9CaXh5BeF93k482engpJCCCYrWR5emxamchbqqhK3sYZD3atJgphjHKbl8DoJuJVb5RDbxqw6BPJQoL70UT40HS7foqYS5Piozt0QRoIt2kIeSGQRbnlXzjhGqiz7V6hDWQG1DDD9aZMyqCcNNR/sC7s7qAnh6dcLJhOxevmTsN2vxLh+AMzC/rT2vVXZmO/RxfCC7AwnUGfJ6CEcDggfoFPdijmQR0+ksuqKKFK8MAlyOKDTk8vNYac8Xn3UAvCAMbEpi7RQRj8dGTYDkA5pLpDwYAKgwE4U0WGcCd2ezmkVv30yfwsWIeHfZivqLJJ1r9lKGOw==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2016 19:41:57.2597 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2502
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/i-xr3kyqPdH2kl4qZQb0Dn3lBgc>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, rtg-dir@ietf.org, draft-ietf-idr-bgp-gr-notification.all@ietf.org, idr@ietf.org
Subject: Re: [Idr] RtgDir review: draft-ietf-idr-bgp-gr-notification-07
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 19:42:06 -0000

--Apple-Mail=_215E5693-C012-4402-9223-69F958EF621D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Belatedly closing the loop on this. Comments in line.=20

I note we did a WGLC on this about a year ago :-o . I think this =
revision captures all the change requests that came out of that and from =
the review. I will follow up to the old WGLC thread, too.

Thanks,

--John

> On Sep 15, 2016, at 4:44 AM, Emmanuel Baccelli =
<Emmanuel.Baccelli@inria.fr> wrote:
>=20
> Hi John,
>=20
> see comments inline.
>=20
> On Tue, Sep 13, 2016 at 8:43 PM, John G. Scudder <jgs@juniper.net =
<mailto:jgs@juniper.net>> wrote:
> Hi Emmanuel,
>=20
> Thanks for your review. My questions and comments are in line below.
>=20
> --John
>=20
>=20
>=20
> > Abstract:
> > - for clarity, append at the end of last sentence "and for force a =
full
> > reset"?
>=20
> Changed (in the source, not yet published as 08 pending this =
discussion) to "This document also defines a new BGP NOTIFICATION Cease =
Error subcode whose effect is to request a full session restart instead =
of a Graceful Restart. "
>=20
>=20
> Fine with me.
> =20
>=20
> > - recall that reserved/unspecified fields must be zeroed (and =
ignored)?
>=20
> While this is a good suggestion as general practice, it seems beyond =
the scope of the present draft. If others disagree and think it's OK for =
the present draft to introduce clarifications and modifications to RFC =
4724 beyond the definition of Notification support, I'd be happy to =
draft some text. But for now, I'd say it's better to hold this for a =
4724bis.
>=20
>=20
> OK. This was just a suggestion. However, see next comment below.
> =20
>=20
> > - in Address family flags: remove "deprecated" specification text
>=20
> To be clear, you are suggesting this text should be removed?
>=20
> "The usage of second most significant bit "N" (which was defined in a
> previous draft version of this specification) is deprecated. This bit =
MUST
> be advertised as 0 and MUST be ignored upon receipt."
>=20
> I am inclined to keep it since as it says, a previous version of the =
draft did spec such a flag and we have past experience indicating that =
this can cause problems when early implementations operate with more =
recent ones.  What's your reason for wanting to remove the text?
>=20
>=20
> I see. But on the other hand, in the long term, you are writing an =
RFC, and in my opinion, it is awkward and confusing to have this kind of =
text and reference to an early draft version in an RFC.
> One solution could be to remove the N bit in the figure and recall =
that as per RFC4724 all reserved bits must be set to zero?
> The good side is it could fix your problem without referring to "prior =
versions of the draft".
> The bad side would be that it is not so great to have exactly the same =
piece of spec duplicated from RFC4724.
> I'm not sure there is a perfect solution here.

On consideration, this doesn't seem as though it's one of the cases =
where we need to leave a warning for implementors for all time. Although =
this is sometimes called for when there has been a rush to implement an =
earlier draft, this doesn't seem to be the case for this one. So, in -09 =
I've taken a more radical approach to addressing your concern, namely to =
remove all text related to the AF flags (implicitly: leaving them alone, =
as per RFC 4724). This has the pleasant effect of further simplifying =
the document. Thanks!

If anyone objects to this change, please speak up.
=20
> > Section 4:
> > - "When a BGP speaker resets its session due to a HOLDTIME expiry, =
it
> > should generate..."
> >  =3D> s/should/SHOULD
>=20
> I am not inclined to use of the all-caps RFC 2119 language since this =
is not a new requirement imposed by the current specification, it's =
merely restating an existing requirement. That is, the word "should" is =
being used in its normal English sense. To elaborate, it's my practice =
whenever using SHOULD in the RFC 2119 sense, to spend a little effort =
considering under what circumstances an implementor might ignore the =
"SHOULD"  and then discuss those in a "MAY"  clause. I think doing that =
would be outside the scope of this document. If the word "should" causes =
readers pain, I'm happy to revise the sentence in a way that uses a =
different word.
>=20
>=20
> No strong opinion on that. I let specialists talk it over, if needed. =
Else, let's do what you propose.
> =20
> > Section 4.1:
> > - the last paragraph of section 4.2 of RFC4724 states that support =
for the
> > stale route retain timer is a MAY.
> > It seems appropriate to specify upfront that this timer is now a =
MUST?
>=20
> It wasn't our intention to make the timer mandatory. Is there a reason =
you think it has to be? (As a practical matter, as far as I know all =
implementations do support the timer, but I think that's beside the =
point.)
>=20
>=20
> When one reads the current spec:
> on one hand, I understand that you MUST do something when this timer =
fires,
> on the other hand, in RFC4724, this timer MAY be used.
> So one naturally wonders what happens if this timer is not =
implemented: can it cause problems?

I don't think so, or rather I don't think the present spec changes =
whether or not problems could occur. To try to clarify the situation, I =
added the word "optional" in -09: "the optional timer mentioned in the =
final paragraph of [RFC4724] S. 4.2". Hopefully this helps the reader =
understand this was a deliberate choice without requiring a long =
explanation.

> I was thus suggesting that making this timer mandatory would be =
clearer.
> If all the implementations you know about have this timer, it seems =
like it's a really good idea to have it anyway.
> But there again, I let specialists talk it over.
>=20
> Best,
>=20
> Emmanuel
>=20


--Apple-Mail=_215E5693-C012-4402-9223-69F958EF621D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Belatedly closing the loop on this. Comments in =
line.&nbsp;<div class=3D""><br class=3D""></div><div class=3D"">I note =
we did a WGLC on this about a year ago :-o . I think this revision =
captures all the change requests that came out of that and from the =
review. I will follow up to the old WGLC thread, too.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Thanks,</div><div =
class=3D""><br class=3D""></div><div class=3D"">--John<br class=3D""><div =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Sep 15, 2016, at 4:44 AM, Emmanuel Baccelli &lt;<a =
href=3D"mailto:Emmanuel.Baccelli@inria.fr" =
class=3D"">Emmanuel.Baccelli@inria.fr</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><meta =
http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" =
class=3D""><div dir=3D"ltr" class=3D"">Hi John,<div class=3D""><br =
class=3D""></div><div class=3D"">see comments inline.<br class=3D""><div =
class=3D"gmail_extra"><br class=3D""><div class=3D"gmail_quote">On Tue, =
Sep 13, 2016 at 8:43 PM, John G. Scudder <span dir=3D"ltr" =
class=3D"">&lt;<a href=3D"mailto:jgs@juniper.net" target=3D"_blank" =
class=3D"">jgs@juniper.net</a>&gt;</span> wrote:<br class=3D""><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">Hi Emmanuel,<br class=3D"">
<br class=3D"">
Thanks for your review. My questions and comments are in line below.<br =
class=3D"">
<br class=3D"">
--John<br class=3D"">
<span class=3D"gmail-"><br class=3D""></span><br class=3D"">
<span class=3D"gmail-"><br class=3D"">
&gt; Abstract:<br class=3D"">
&gt; - for clarity, append at the end of last sentence "and for force a =
full<br class=3D"">
&gt; reset"?<br class=3D"">
<br class=3D"">
</span>Changed (in the source, not yet published as 08 pending this =
discussion) to "This document also defines a new BGP NOTIFICATION Cease =
Error subcode whose effect is to request a full session restart instead =
of a Graceful Restart. "<br class=3D"">
<span class=3D"gmail-"><br class=3D""></span></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">Fine with me.</div><div =
class=3D"">&nbsp;</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
<span class=3D"gmail-"><br class=3D"">
&gt; - recall that reserved/unspecified fields must be zeroed (and =
ignored)?<br class=3D"">
<br class=3D"">
</span>While this is a good suggestion as general practice, it seems =
beyond the scope of the present draft. If others disagree and think it's =
OK for the present draft to introduce clarifications and modifications =
to RFC 4724 beyond the definition of Notification support, I'd be happy =
to draft some text. But for now, I'd say it's better to hold this for a =
4724bis.<br class=3D"">
<span class=3D"gmail-"><br class=3D""></span></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">OK. This was just a =
suggestion. However, see next comment below.</div><div =
class=3D"">&nbsp;</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
<span class=3D"gmail-"><br class=3D"">
&gt; - in Address family flags: remove "deprecated" specification =
text<br class=3D"">
<br class=3D"">
</span>To be clear, you are suggesting this text should be removed?<br =
class=3D"">
<br class=3D"">
"The usage of second most significant bit "N" (which was defined in a<br =
class=3D"">
previous draft version of this specification) is deprecated. This bit =
MUST<br class=3D"">
be advertised as 0 and MUST be ignored upon receipt."<br class=3D"">
<br class=3D"">
I am inclined to keep it since as it says, a previous version of the =
draft did spec such a flag and we have past experience indicating that =
this can cause problems when early implementations operate with more =
recent ones.&nbsp; What's your reason for wanting to remove the text?<br =
class=3D"">
<span class=3D"gmail-"><br class=3D""></span></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">I see. But on the other =
hand, in the long term, you are writing an RFC, and in my opinion, it is =
awkward and confusing to have this kind of text and reference to an =
early draft version in an RFC.</div><div class=3D"">One solution could =
be to remove the N bit in the figure and recall that as per RFC4724 all =
reserved bits must be set to zero?</div><div class=3D"">The good side is =
it could fix your problem without referring to "prior versions of the =
draft".</div><div class=3D"">The bad side would be that it is not so =
great to have exactly the same piece of spec duplicated from =
RFC4724.</div><div class=3D"">I'm not sure there is a perfect solution =
here.</div></div></div></div></div></div></blockquote><div><br =
class=3D""></div>On consideration, this doesn't seem as though it's one =
of the cases where we need to leave a warning for implementors for all =
time. Although this is sometimes called for when there has been a rush =
to implement an earlier draft, this doesn't seem to be the case for this =
one. So, in -09 I've taken a more radical approach to addressing your =
concern, namely to remove all text related to the AF flags (implicitly: =
leaving them alone, as per RFC 4724). This has the pleasant effect of =
further simplifying the document. Thanks!</div><div><br =
class=3D""></div><div>If anyone objects to this change, please speak =
up.</div><div>&nbsp;<br class=3D""><blockquote type=3D"cite" =
class=3D""><div dir=3D"ltr" class=3D""><div class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><span class=3D"gmail-">
&gt; Section 4:<br class=3D"">
&gt; - "When a BGP speaker resets its session due to a HOLDTIME expiry, =
it<br class=3D"">
&gt; should generate..."<br class=3D"">
&gt;&nbsp; =3D&gt; s/should/SHOULD<br class=3D"">
<br class=3D"">
</span>I am not inclined to use of the all-caps RFC 2119 language since =
this is not a new requirement imposed by the current specification, it's =
merely restating an existing requirement. That is, the word "should" is =
being used in its normal English sense. To elaborate, it's my practice =
whenever using SHOULD in the RFC 2119 sense, to spend a little effort =
considering under what circumstances an implementor might ignore the =
"SHOULD"&nbsp; and then discuss those in a "MAY"&nbsp; clause. I think =
doing that would be outside the scope of this document. If the word =
"should" causes readers pain, I'm happy to revise the sentence in a way =
that uses a different word.<br class=3D"">
<span class=3D"gmail-"><br class=3D""></span></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">No strong opinion on =
that. I let specialists talk it over, if needed. Else, let's do what you =
propose.</div><div class=3D"">&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><span class=3D"gmail-">
&gt; Section 4.1:<br class=3D"">
&gt; - the last paragraph of section 4.2 of RFC4724 states that support =
for the<br class=3D"">
&gt; stale route retain timer is a MAY.<br class=3D"">
&gt; It seems appropriate to specify upfront that this timer is now a =
MUST?<br class=3D"">
<br class=3D"">
</span>It wasn't our intention to make the timer mandatory. Is there a =
reason you think it has to be? (As a practical matter, as far as I know =
all implementations do support the timer, but I think that's beside the =
point.)<br class=3D"">
<span class=3D"gmail-"><br class=3D""></span></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">When one reads the =
current spec:</div><div class=3D"">on one hand, I understand that you =
MUST do something when this timer fires,</div><div class=3D"">on the =
other hand, in RFC4724, this timer MAY be used.</div><div class=3D"">So =
one naturally wonders what happens if this timer is not implemented: can =
it cause problems?</div></div></div></div></div></blockquote><div><br =
class=3D""></div>I don't think so, or rather I don't think the present =
spec changes whether or not problems could occur. To try to clarify the =
situation, I added the word "optional" in -09: "the optional timer =
mentioned in the final paragraph of [RFC4724] S. 4.2". Hopefully this =
helps the reader understand this was a deliberate choice without =
requiring a long explanation.<div><br class=3D""></div><blockquote =
type=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><div class=3D""><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">I was =
thus suggesting that making this timer mandatory would be =
clearer.</div><div class=3D"">If all the implementations you know about =
have this timer, it seems like it's a really good idea to have it =
anyway.</div><div class=3D"">But there again, I let specialists talk it =
over.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Best,</div><div class=3D""><br class=3D""></div><div =
class=3D"">Emmanuel</div></div><br class=3D""></div></div></div>
</blockquote></div><br class=3D""></div></div></body></html>=

--Apple-Mail=_215E5693-C012-4402-9223-69F958EF621D--


From nobody Sat Dec 10 11:50:55 2016
Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06D412949B for <idr@ietfa.amsl.com>; Sat, 10 Dec 2016 11:50:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 aH6k1-lmbTTX for <idr@ietfa.amsl.com>; Sat, 10 Dec 2016 11:50:52 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0127.outbound.protection.outlook.com [104.47.32.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 47F5C129493 for <idr@ietf.org>; Sat, 10 Dec 2016 11:50:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vxEpBVVvGT1zpaUKmJt/CBmuOJ9BOhcxEF58G04WJH8=; b=iEL7NDYAZdFt8NBqY8vaaS2l/HeRPZhXfNg5FeCqPLsVEbjoy9BX0VH5uf0PvhOiH0yJnriPwylWVQDCdAtU6TlN2xZ/OtWpkgsqI97asSUNf1z3tZzuTyKhIupGQb3phejITkZ+v6oVtKaXJdhzC+MoNWH7mILEmWBmu13Lc94=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.104.147] (66.129.239.15) by SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Sat, 10 Dec 2016 19:50:49 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_D1077BE1-570D-42C9-BE40-976EC995196B"
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Scudder <jgs@juniper.net>
In-Reply-To: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com>
Date: Sat, 10 Dec 2016 14:50:43 -0500
Message-ID: <F5977A01-0018-432C-B829-6A7B4695A667@juniper.net>
References: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com>
To: Susan Hares <shares@ndzh.com>
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.239.15]
X-ClientProxiedBy: BY2PR16CA0019.namprd16.prod.outlook.com (10.164.126.157) To SN2PR05MB2511.namprd05.prod.outlook.com (10.166.213.20)
X-MS-Office365-Filtering-Correlation-Id: ed7c8d0c-e426-4bc1-f427-08d42135d7f0
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR05MB2511;
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 3:uhrO6SuXsM9DcrK1Y2V2uJ+i6c12QxbaN3HeJGTFNFrMKnJHcxjdiTVyccQqt+WFKmlb5kWkuvw2sb7yF0gXYIgN8dvaunJvgvH5Tnvj67XZDfMXJrcYuCYoN1JMvDCzcW+/9f2ZwcLKJNFUAwwg8OileN+pLTEvBbRcJ/0TiryTgfGSb5dxqVjcay0jQv4kjYLxZjPxGYLSvTSeCwwfCOeTDHSQkUxvAtMYdZiFklaQgRlottLDtYGjYBR+NtgoWi5qpYx3jRtiLh17DQPb/g==
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2511; 25:sdaBI1hDONRr53aq6ZmPUmTor1HrqJH2674a2blph?= =?us-ascii?Q?OtIuikorFZi3oOxUgFJLaVLMVGJtZGMToDhCwYr1H6V1LoQo6ksYdsx6beNA?= =?us-ascii?Q?G8g16EdeTd+JknSEa/JXrntmKbmMkq7tuNGKssfkLZqelC7OIlWkTa9zATwL?= =?us-ascii?Q?ZOh3zHvQAF5IY/MX/az/d/kY6URqXC9rV2E0yFp2koFQBVjU9QII+JHFh0iO?= =?us-ascii?Q?OpzaBzZeYgm/yuJRKOnKJr/x6C5byipzU1LeOvzYy/9V4yBecG7BH70yR5eF?= =?us-ascii?Q?DgNN1BRMaF677MELA9r6VwU+4S8whFFey+kk9h/aspA+cvwc16+TASRYU5QE?= =?us-ascii?Q?UYwqG0zdk85iQwXqN6mVpHq0IAYj4rdDrNqp9HVKeCQMtbOFlgcjD6yytSP7?= =?us-ascii?Q?OTnTUPyALkM9h2zv93/namQKAbDdWjdV7UM9IKmkRRDccoQkeeaXjI3S/9/f?= =?us-ascii?Q?n2cPT1QI/xI0+W4lTxmVjFORNfG31dtfvhYYTXBtLSM37UqpenCJHEFIbbxk?= =?us-ascii?Q?dlE/TObYPBnZsx7Q6dNiwbmDXZNvlEi4VjCOlJjG7GBGCtSu8u+mfSAgVpuJ?= =?us-ascii?Q?Gdh7PHDTNippA1sf2OpFu/7Df4INyvRiK3WKQSW4M+bg9+GXVQm3EMfNvrxa?= =?us-ascii?Q?pHEskU0BsOkNlH2fjQL/MIQ7kktiOz8oPwaGpZpJkMeaK20xY34Hybv6uPk2?= =?us-ascii?Q?4wb1Xn3q2fhdK52h/tAboIgdlJDTmoZ85Tu/MY27NVX9rFYbtdkzPjDUEK1I?= =?us-ascii?Q?RObDB8rOvG/geqEEQKh2iEe+zpmrTDd+WDh3adWQamUByfTvrTDCDvC5/s6X?= =?us-ascii?Q?HHztNh2MYyBrJMYUQr50atWN9dzSZJnQAvDHMF0J37ggXQ8sSrcUSvAwN5Z2?= =?us-ascii?Q?tq6k3lrwHb4DRyNmZWyH2YCmGjfxJyoLf0n+WpEobt6rJkpuTg7pEkgk2oj1?= =?us-ascii?Q?JiQA9+3QqW7UofeC7j+qTEkP1XnZPjDumYmPDz2JZ7NUszbBxlNh1lllLSLl?= =?us-ascii?Q?11bj97yuq9rEs4HVtZBf6lWPt8BXbUJwTR5lk9GzI3/Hg=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 31:IIEVHk0WQ+vRv5NqJJdyz441zwo+yeC0dRO4QkQA1tc8dMWOgP3XKGVhnl0KmLqsee8W7NnjMOH1UTexyn0mYBG0mGMCQEeKC8+P9fs9KyrfcsgdnWTJvIfgPIbQvttmdoAVF0SbZsjUEne5MfH9S7YcbhcBd8Nuh7YGPA9CpbXInkHoqQqyNB9sx2HbbajiXWIRDt8pzWTzXz5KxdkWHP6ZevdvrrKPt3rAQX0r9WsjIFODy3Jv3bVweifGV0nhwfZn4AF5JzkfITOtv+/ZRUGAqXa+36zlT8l5F761F2I=; 20:lIe+bnFWPsDT8p/SHEDukQ00oLGNFES0vXr0ZnpBVCTm1/1f++Ugu9Gy/AcCW5boGS7vSvizFRPpzNVU7eA3qQXA5lKzJ74l4y25+P51OLzf27H6ak36Mtm/D7FQPbKiDYQbkKwvlv/s8m8yDbrU3PYRr1k0t8qDd2WMaujWpz+FKrrUILdeK1+YPFXwkDDyCsFF+bThyzzDu9RR9GpM6fxqPNVjiFQ7lvQDhW3wSMi596YfS/Ytf1Lsvl65916OFf7qz51oeHx3AEs+4i6nh2MjbBvOxF6OrokokZiywhoEMt18yLXvCvlzuJr+Aey2iRHM7+rrZ6fGY3b0/weVsHrnLMUMaDJsq5r7+F+pPMoCfCXpphWDvzCg7FERxhksgtNYzHchsSbzvySAcAgpfVkbpXVGjD2pqVgRiYYAOdTuWjenFAloQwjAA5PSv6cLfZ7mcc8HI+xUBA6L9aOvIfKbelGAZ95srfIsINJmT/hOCW1daBUn+x/wnNxuycji
X-Microsoft-Antispam-PRVS: <SN2PR05MB25113E426C9A1062BC54BE74AA860@SN2PR05MB2511.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:SN2PR05MB2511; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2511; 
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 4:/M4Gy+rzhsgJDGmaoFYg03tT5Vjoy9b1Md5ep828tVHPHXHPEaIuub9v0ECxuf3/Ew04qS4sLhjEKlqx4yOaenha57RLbNa77GiM8bFfPNo3ffbDxAXF9BGZre7yPZxMaFKJ9rB4JOs3hi7KXQqq4xsa4PpwC3YITG0OoZyCX3a8ZCTpNEy/KvzEvqVeGqicBxmZ4Ba95PO4/ofx48kR31TfM+ZbimXmOnoMxey8odkqPQe0Lq7gvkVAc1CIo+3hJSi/lPfI6z6HbVGmTuJjjfwAGODUx7GGhWPaZVk0evRN+jF9d3XcnBdn+vtSniAKtSqismx11rJbcQKRvf7wCi0CwGTdwUSSLd/c6T5AgefA1WXhEvzQSULdmCCCdAJ4jwsyK4INVGfp79NmS0bICAsOxbogeoC0QO6zm19n+iN+x+3SqQNhkMW0UKF2lsWbS92S+nAH5vjdLS1rAOm86exZoR08PqAI40EMh16iHgXzTWXJXqFVe7vIyBPue31BP3/m/4FkIErxWEceYAYxMq9L53+mwMTVqvai2k6c2dMQbPRNuD7Y5UhJta/4IUiEF14Er3kiMS+fLgJsYwwRHg==
X-Forefront-PRVS: 0152EBA40F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(7916002)(39860400002)(39840400002)(39450400003)(39410400002)(39850400002)(5423002)(189002)(24454002)(51444003)(199003)(69234005)(377454003)(53754006)(7110500001)(38730400001)(189998001)(6486002)(77096006)(83716003)(84326002)(42186005)(92566002)(90366009)(82746002)(81166006)(50226002)(3846002)(8676002)(6116002)(81156014)(97736004)(86362001)(2906002)(606005)(15650500001)(2420400007)(10710500007)(4326007)(68736007)(230783001)(512874002)(101416001)(7906003)(50986999)(36756003)(76176999)(7736002)(6666003)(5660300001)(106356001)(2950100002)(6916009)(110136003)(66066001)(33656002)(57306001)(69556001)(105586002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2511; H:[172.29.104.147]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2511; 23:4UDbxGFlfD+g7FJVNqerTUKAXrwHu9fW3OCjqYm6V?= =?us-ascii?Q?mD2N8oocKSiUMyp1czGo8jdNMSqWOH5OKNFLCl1enViAZuUnJ0580egEsEA5?= =?us-ascii?Q?gYMpaVjzIti493YTwc+tmRC5HDzJ1l+y7NcSQJf8fl2lIJjdcOcrQbqF3iOd?= =?us-ascii?Q?uTqWHMeeO0A9FzPHb7s3tO/auB93T4xPBTMgblYIUjTzkXsyB6Q8ABqQmMp5?= =?us-ascii?Q?5HXvj+BPfpagv+53NSH6bTY6dIQXxHiNgekgt8TU/ZeSmVhZpKO3doGn41jU?= =?us-ascii?Q?6yrtz6h8MbONItYqWfg3ut4bUltyvNhcSdDX2EudGC6P7UIQwqQzSOxHFNi2?= =?us-ascii?Q?wPr0kcje5x/Mo+NPQrSwFkqunTEIZpoj9+Tj9mhGQV2JQOkWRHsY9D5FhIDQ?= =?us-ascii?Q?Y5SnpHqxbfdXsOoQgEGYziItRUkHoOzIRGPiLN/z9OpfGKzWu1/dxWyyM+rw?= =?us-ascii?Q?H4ovyRsuw1EDuHDERfRKewV0MFfrNkd6YHitZjIcQ5MwquklORkGPJ034cD9?= =?us-ascii?Q?FUkNWTowbIhSuYK9be4DdE1jR6RBRerhJ5UAXqAnEReCdw+f9yElEgQ4v4bd?= =?us-ascii?Q?GLgTqxLisSjHkskc6obxSpIIVC+6GsTBgkC6DilB6dOoZBdk6BZTHiYo9hPX?= =?us-ascii?Q?nqDZMlkuDmVmvF8z34EVrYmLkaO5dC7ZNsEq/gXzNwAXHUmfXz2qabctmdkf?= =?us-ascii?Q?NLAifFXEcbO6cr8Y6TXjKspkDJHP5qb7HsbD3x7xTOdtnSB/gVWb6v8bit9m?= =?us-ascii?Q?TyXLXEyty5HpLeM4jwvPO3g6Mjlw7zbXceQuUOIK+viQOX6NJTm85yrZWfna?= =?us-ascii?Q?10zDM819/tafpxWoVDSEwU8YDUduV+jNxqkaNIkZhQ4oyb2ZCItOAmBt0+u3?= =?us-ascii?Q?SR15GILQqEL4ifX/wUTzvPqHiNU5+V8PgkBYAMcOc7wtaIkY2x74Q/wy4/1j?= =?us-ascii?Q?hBjTMFzAlkajIaU5IThw/PA8ut/dRnbPJnbX6YX6DvwC5Yz/e62YHVY+t3kx?= =?us-ascii?Q?cjR+si5qcS3NSxW2LXWSdgVmH7YJXzuP8m4sih1RjcZmyZQpLbbW7iEzyFsC?= =?us-ascii?Q?EC7Ve5PhJR5VgFaH19CUDQyzaxa5jBqJPHz9KlowOo5Hlu0mV54ltbekDNQg?= =?us-ascii?Q?KuhJfpF4au3dqArsMm/w2UQFbhmHwRNXq8suiur4U0UXpmJKVRh2k+La22+v?= =?us-ascii?Q?cLSQlkpVc+BYH6eKMAxyIU9NA3WsxuQ2QBHHQuihIog93bmJ4YuPBB8x5Hm9?= =?us-ascii?Q?qJMZnSdc5fWyADbBC+DzA39b6fPRDfuVD/W0+ZJxYuhIf8ZUtmGIKci78stR?= =?us-ascii?Q?2Us/fEqGqnhZViqPGcxwtmSSnAXLbjrR6YVD6zLoV7Z4KDZS+JX0Apf0wLZ6?= =?us-ascii?Q?K/IYAqTmut51Cy6pyetcwiB9gs7fAVBl1lG+rs79o6untkDLjQwvRl+JuSIT?= =?us-ascii?Q?iyLo4fuI9zHgYNeRYRme+XYjLQkH44fFoD9B3qLzqzpVu1SaFaZVq4p1eHv8?= =?us-ascii?Q?KCysx4h50zJTHtox2TpfIu43Ahjicmj5Wg=3D?=
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 6:G2evqT00dbWw6BipwhFljkwyhHQoBaqJbPju359ahp8f1bAu/o+G+409A7YJDU9ENvYQR8jMy2LOUR7BYC0Xs3fomdl7ZBi49Ja/HQK53J4fJHsKfnB7XVExkb8unwN3zZvTCq7/MnkxnWgRvFkWYlqbzxOWGMjUTEJQ1bkyDZNcgU5A9c+dDUu58YBuEmkK7zXXlORJjRzxzwHP6xdO4fC6SllPp0Ozt4IKXF9fYAkYfacPVqOM4dgKT7kadndrjzW22I6QX1CgJjNN1JnXCcPprTXmKdoIliTl9bcpq+qqv0a7fphSOh1aHyo9vmE8lnc/NSCfQEveIHfgi98MhOEbvqctGWptGIqMSmw8jSCCW3FtY/ebQf0DqpIN79dUBtt9L3y/I+h0wwUcEaZJrsZtG/JrEJp6XsEtvGHUhxZ37o7pQ2nTadBkMZ7v6VjagFS9UIMOyE+PLlF0SOxCGg==; 5:ElmHJmNc4TfuC8eV0LgvxWSXoeh26Vb3vpo3FGMunxZGG1wXXhKgKqHvKqxMAlGMxVtFq9FnIv4NaShU4UAk+yaEXWrIlw1LVArKZ6w4B4ork6KaJ0q+5Xt8ikd0Fcp3ds5i4MUoe4NQ+kPlRtI5Eg==; 24:8oQhNsSjCzobSHfzZ7T90oB2idjjw8aeimYVnEdcHcnECjVwmFmQ9brqNR8fVN2BU4y0uWND1vybpzB1PL83hSDJ8rmCaUkg9t3suH6mp7k=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2511; 7:xcsZhSeQBCJHuu04hefhSOJRJ6uMz6JCwV1CG+KI3OWTgU0hqF9ysy+eiA+FSN3YsZIYYnc6KPODKo/1kUSuuXFlcLmgNlvEr191N4hWMfHmW6yZ1q/rK/LHMjyKHMeoDB13KOHLAoLQ6SqyWrO8IEz17/j1N6E+FzZ78wswPuHtqVpFfGD3LjWqSdTtR/Ev0UQfdsmuePMCgSf3dFUQjMvw2NA9G14xM32EMcqJ0ZgmDBeIdMZd8bqY2lttMypJWW+MRaxhYIMsFe1D0U20N2fOyfV0xFkotLnGwKnkkSuG4QcVU91wg7Z5V2Bt0R02VHRajRWO7Z1oHMR6sLg7YPTgIrWeGS49nyHgpTXwIKdX37AZSdfJNxDEUcA55wnRt7vpR1zPLiiToDpp7P6SaLx5VfR8J95dl/zrUk0dpEoZSqw4UVlMuF3krtlrnVPJP+d/zibSCahtiLIKv0HDAA==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2016 19:50:49.9112 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2511
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6mF2RqV2fnGUdePT1c0M0SrCVTA>
Cc: idr wg <idr@ietf.org>
Subject: [Idr] Old WGLC for draft-ietf-idr-bgp-gr-notification [was: Re: WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14]
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 19:50:55 -0000

--Apple-Mail=_D1077BE1-570D-42C9-BE40-976EC995196B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Hi Everybody,

My mistake, the WGLC wasn't in 2015, it was in 2014 and the last traffic =
to the thread was 2015 :-o. I think that under the circumstances we =
probably have to do another one, although I leave the final decision to =
my co-chair.

FYI the diff from the version that was originally WGLC'd to the current =
one =
is:https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-idr-bgp-gr-notification-=
02&url2=3Ddraft-ietf-idr-bgp-gr-notification-09. I believe this resolves =
all issues that were raised.

Thanks,

--John

> On May 27, 2014, at 1:19 PM, Susan Hares <shares@ndzh.com> wrote:
>=20
> Working Group,
> =20
> This is to begin a 2 week WG LC for =
draft-ietf-idr-bgp-gr-notification-02.txt which will end on 6/10/2014.  =
Please put within your comments:  =E2=80=9Csupport=E2=80=9D or =
=E2=80=9Cno-support=E2=80=9D for WG LC.=20
> =20
> Jeff Haas comments that the most recent changes reflect implementation =
experience and some word smithing.  There is also a minor clarification =
in the NOTIFICATION message with respect to including a data byte so the =
original reason for the event can be propagated.  (See sec. 3.1 in the =
diff.)
> =20
> The abstract is below.=20
> =20
> Sue Hares
> =20
> =20
> ----------
> =20
> Abstract:
>    The current BGP Graceful Restart mechanism limits the usage of BGP
>    Graceful Restart to BGP protocol messages other than a BGP
>    NOTIFICATION message.  This document defines an extension to the =
BGP
>    Graceful Restart that permits the Graceful Restart procedures to be
>    performed when the BGP speaker receives a BGP NOTIFICATION Message.
>    This document also defines a new BGP NOTIFICATION Cease Error =
subcode
>    to prevent BGP speakers supporting the extension defined in this
>    document from performing a Graceful Restart.


--Apple-Mail=_D1077BE1-570D-42C9-BE40-976EC995196B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Hi Everybody,<div class=3D""><br class=3D""></div><div =
class=3D"">My mistake, the WGLC wasn't in 2015, it was in 2014 and the =
last traffic to the thread was 2015 :-o. I think that under the =
circumstances we probably have to do another one, although I leave the =
final decision to my co-chair.</div><div class=3D""><br =
class=3D""></div><div class=3D"">FYI the diff from the version that was =
originally WGLC'd to the current one is:https://<a =
href=3D"http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-idr-bgp-gr-notificat=
ion-02&amp;url2=3Ddraft-ietf-idr-bgp-gr-notification-09" =
class=3D"">www.ietf.org/rfcdiff?url1=3Ddraft-ietf-idr-bgp-gr-notification-=
02&amp;url2=3Ddraft-ietf-idr-bgp-gr-notification-09</a>. I believe this =
resolves all issues that were raised.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Thanks,</div><div class=3D""><br =
class=3D""></div><div class=3D"">--John</div><div class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
May 27, 2014, at 1:19 PM, Susan Hares &lt;<a =
href=3D"mailto:shares@ndzh.com" class=3D"">shares@ndzh.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"WordSection1" style=3D"page: WordSection1; font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; =
font-family: Calibri, sans-serif;" class=3D""><span style=3D"font-size: =
10pt; font-family: 'Courier New';" class=3D"">Working Group,<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 10pt; font-family: 'Courier New';" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">This is to begin a 2 week WG LC for =
draft-ietf-idr-bgp-gr-notification-02.txt which will end on 6/10/2014. =
&nbsp;Please put within your comments:&nbsp; =E2=80=9Csupport=E2=80=9D =
or =E2=80=9Cno-support=E2=80=9D for WG LC.<span =
class=3D"Apple-converted-space">&nbsp;</span><o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 10pt; font-family: 'Courier New';" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">Jeff Haas comments that the most recent changes reflect =
implementation experience and some word smithing.&nbsp; There is also a =
minor clarification in the NOTIFICATION message with respect to =
including a data byte so the original reason for the event can be =
propagated.&nbsp; (See sec. 3.1 in the diff.)<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 10pt; font-family: 'Courier New';" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">The abstract is below.<span =
class=3D"Apple-converted-space">&nbsp;</span><o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 10pt; font-family: 'Courier New';" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">Sue Hares<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span style=3D"font-size: 10pt; =
font-family: 'Courier New';" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D""><o:p class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: =
0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">----------<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span style=3D"font-size: 10pt; =
font-family: 'Courier New';" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">Abstract:<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span style=3D"font-size: 10pt; =
font-family: 'Courier New';" class=3D"">&nbsp;&nbsp; The current BGP =
Graceful Restart mechanism limits the usage of BGP<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">&nbsp;&nbsp; Graceful Restart to BGP protocol messages other =
than a BGP<o:p class=3D""></o:p></span></div><div style=3D"margin: 0in =
0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">&nbsp;&nbsp; NOTIFICATION message.&nbsp; This document =
defines an extension to the BGP<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span style=3D"font-size: 10pt; =
font-family: 'Courier New';" class=3D"">&nbsp;&nbsp; Graceful Restart =
that permits the Graceful Restart procedures to be<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">&nbsp;&nbsp; performed when the BGP speaker receives a BGP =
NOTIFICATION Message.<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span style=3D"font-size: 10pt; =
font-family: 'Courier New';" class=3D"">&nbsp;&nbsp; This document also =
defines a new BGP NOTIFICATION Cease Error subcode<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">&nbsp;&nbsp; to prevent BGP speakers supporting the extension =
defined in this<o:p class=3D""></o:p></span></div><div style=3D"margin: =
0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 10pt; font-family: 'Courier New';" =
class=3D"">&nbsp;&nbsp; document from performing a Graceful =
Restart.</span></div></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_D1077BE1-570D-42C9-BE40-976EC995196B--


From nobody Sat Dec 10 19:05:33 2016
Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A930212943E for <idr@ietfa.amsl.com>; Sat, 10 Dec 2016 19:05:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 iThzoD0bjRSD for <idr@ietfa.amsl.com>; Sat, 10 Dec 2016 19:05:29 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0126.outbound.protection.outlook.com [104.47.37.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C133E126D74 for <idr@ietf.org>; Sat, 10 Dec 2016 19:05:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=njZsQS1eyyb6j2f/d0wlfQHxzqFoyoZucvZN+eUuxx8=; b=WEE1yi1mTEV2O2vu2nDkxA+JDVdBZmaNldtVKNUSDk+Nlfq5abl2kMrc4cu4Y9DFMbdkgMjf+gShLcSiQMdGt3IbuFhx6tAipHSmu8kLfp2yQt38uHu9DGZIAddSpRIAqOuyVUUxyGV2jCBcriq7wLouX4LiqXBgcjWbcwIwi2c=
Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Sun, 11 Dec 2016 03:05:28 +0000
Received: from CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) by CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) with mapi id 15.01.0771.011; Sun, 11 Dec 2016 03:05:26 +0000
From: John Scudder <jgs@juniper.net>
To: John Scudder <jgs@juniper.net>
Thread-Topic: [Idr] Old WGLC for draft-ietf-idr-bgp-gr-notification [was: Re: WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14]
Thread-Index: AQHSU1tsrSWzHj+8AUOoeRl/po+riw==
Date: Sun, 11 Dec 2016 03:05:26 +0000
Message-ID: <76AD4ADF-A14F-4CD4-BF43-8DD01E60E390@juniper.net>
References: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> <F5977A01-0018-432C-B829-6A7B4695A667@juniper.net>
In-Reply-To: <F5977A01-0018-432C-B829-6A7B4695A667@juniper.net>
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=jgs@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [75.151.14.9]
x-microsoft-exchange-diagnostics: 1; CY1PR05MB2507; 7:bdjJgcYQ7/3WYMDRmLThslmSvcMM7r3UrSXNdJQWBDpKhPMX5A1+pam2kfvb2V/yxohNkAFxdnEG7SjlKx1amM+olgua2TOjImS/GuTm4OKmgBZqPVeS4wyGp39t1r8v+Gy6yVXyFD6z0Qlw7hvJ+XUtOhFeL4VI0B5A9BUwWnmZZbCyJwA657YitCCUuz6B9Ns0i7UigZdoGaDvmJ5mh9sMOoFQ+sjjhsJ82CdNvdIehAhOgHXgfXR3UFY/PtUv83xHGjgmaQQWM9STL04iq5ZmprvzagckgAAUnag6u22Mh79aiM4mdEYl4tk9vFYgBdP+MbiZlgpljm2FyubBxrWXLc+Ojqii+cpMeJyTw/6IUpxKkXo1DtNYsZm/PAhcgifVx4N9tZk/Og5YkoYee8s+ZE2FLRlKN4yRxz3pMyS6L32r/ej696s85N/J2DACVN9eVyIX6VS1T6FdL8eKRA==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39860400002)(39450400003)(39840400002)(39850400002)(69234005)(53754006)(51444003)(24454002)(377454003)(5423002)(189002)(199003)(6436002)(8936002)(3660700001)(83716003)(6512006)(36756003)(1941001)(229853002)(2420400007)(66066001)(6486002)(6506006)(606005)(38730400001)(122556002)(77096006)(6862003)(5660300001)(2950100002)(81166006)(81156014)(99286002)(110136003)(106356001)(10710500007)(7906003)(68736007)(3280700002)(6200100001)(8676002)(106116001)(105586002)(4326007)(2906002)(7736002)(82746002)(54356999)(92566002)(50986999)(33656002)(86362001)(189998001)(76176999)(7110500001)(2900100001)(101416001)(97736004)(15650500001)(3846002)(102836003)(230783001)(6116002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2507; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
x-ms-office365-filtering-correlation-id: a74fc765-0fe4-4ae7-a8c6-08d421728ea4
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR05MB2507;
x-microsoft-antispam-prvs: <CY1PR05MB25071D369AACBD41A006F1ECAA990@CY1PR05MB2507.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR05MB2507; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2507; 
x-forefront-prvs: 0153A8321A
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_76AD4ADFA14F4CD4BF438DD01E60E390junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2016 03:05:26.8586 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2507
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XLKpJN2OtE3tzY_e6CbUv-ygqUg>
Cc: idr wg <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] Old WGLC for draft-ietf-idr-bgp-gr-notification [was: Re: WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14]
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Dec 2016 03:05:32 -0000

--_000_76AD4ADFA14F4CD4BF438DD01E60E390junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QnkgdGhlIHdheSwgSSB3b3VsZCBsaWtlIHRvIGVuY291cmFnZSBpbXBsZW1lbnRvcnMgdG8gdXBk
YXRlIHRoZSAocXVpdGUgZGF0ZWQpIGltcGxlbWVudGF0aW9uIHJlcG9ydCBhdCBodHRwczovL3Ry
YWMuaWV0Zi5vcmcvdHJhYy9pZHIvd2lraS9kcmFmdC1pZXRmLWlkci1iZ3AtZ3Itbm90aWZpY2F0
aW9uJTIwaW1wbGVtZW50YXRpb25zDQoNClRoYW5rcywNCg0KLS1Kb2huDQoNCk9uIERlYyAxMCwg
MjAxNiwgYXQgMjo1MCBQTSwgSm9obiBTY3VkZGVyIDxqZ3NAanVuaXBlci5uZXQ8bWFpbHRvOmpn
c0BqdW5pcGVyLm5ldD4+IHdyb3RlOg0KDQpIaSBFdmVyeWJvZHksDQoNCk15IG1pc3Rha2UsIHRo
ZSBXR0xDIHdhc24ndCBpbiAyMDE1LCBpdCB3YXMgaW4gMjAxNCBhbmQgdGhlIGxhc3QgdHJhZmZp
YyB0byB0aGUgdGhyZWFkIHdhcyAyMDE1IDotby4gSSB0aGluayB0aGF0IHVuZGVyIHRoZSBjaXJj
dW1zdGFuY2VzIHdlIHByb2JhYmx5IGhhdmUgdG8gZG8gYW5vdGhlciBvbmUsIGFsdGhvdWdoIEkg
bGVhdmUgdGhlIGZpbmFsIGRlY2lzaW9uIHRvIG15IGNvLWNoYWlyLg0KDQpGWUkgdGhlIGRpZmYg
ZnJvbSB0aGUgdmVyc2lvbiB0aGF0IHdhcyBvcmlnaW5hbGx5IFdHTEMnZCB0byB0aGUgY3VycmVu
dCBvbmUgaXM6aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtaWRy
LWJncC1nci1ub3RpZmljYXRpb24tMDImdXJsMj1kcmFmdC1pZXRmLWlkci1iZ3AtZ3Itbm90aWZp
Y2F0aW9uLTA5PGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtaWRy
LWJncC1nci1ub3RpZmljYXRpb24tMDImdXJsMj1kcmFmdC1pZXRmLWlkci1iZ3AtZ3Itbm90aWZp
Y2F0aW9uLTA5Pi4gSSBiZWxpZXZlIHRoaXMgcmVzb2x2ZXMgYWxsIGlzc3VlcyB0aGF0IHdlcmUg
cmFpc2VkLg0KDQpUaGFua3MsDQoNCi0tSm9obg0KDQpPbiBNYXkgMjcsIDIwMTQsIGF0IDE6MTkg
UE0sIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+
IHdyb3RlOg0KDQpXb3JraW5nIEdyb3VwLA0KDQpUaGlzIGlzIHRvIGJlZ2luIGEgMiB3ZWVrIFdH
IExDIGZvciBkcmFmdC1pZXRmLWlkci1iZ3AtZ3Itbm90aWZpY2F0aW9uLTAyLnR4dCB3aGljaCB3
aWxsIGVuZCBvbiA2LzEwLzIwMTQuICBQbGVhc2UgcHV0IHdpdGhpbiB5b3VyIGNvbW1lbnRzOiAg
4oCcc3VwcG9ydOKAnSBvciDigJxuby1zdXBwb3J04oCdIGZvciBXRyBMQy4NCg0KSmVmZiBIYWFz
IGNvbW1lbnRzIHRoYXQgdGhlIG1vc3QgcmVjZW50IGNoYW5nZXMgcmVmbGVjdCBpbXBsZW1lbnRh
dGlvbiBleHBlcmllbmNlIGFuZCBzb21lIHdvcmQgc21pdGhpbmcuICBUaGVyZSBpcyBhbHNvIGEg
bWlub3IgY2xhcmlmaWNhdGlvbiBpbiB0aGUgTk9USUZJQ0FUSU9OIG1lc3NhZ2Ugd2l0aCByZXNw
ZWN0IHRvIGluY2x1ZGluZyBhIGRhdGEgYnl0ZSBzbyB0aGUgb3JpZ2luYWwgcmVhc29uIGZvciB0
aGUgZXZlbnQgY2FuIGJlIHByb3BhZ2F0ZWQuICAoU2VlIHNlYy4gMy4xIGluIHRoZSBkaWZmLikN
Cg0KVGhlIGFic3RyYWN0IGlzIGJlbG93Lg0KDQpTdWUgSGFyZXMNCg0KDQotLS0tLS0tLS0tDQoN
CkFic3RyYWN0Og0KICAgVGhlIGN1cnJlbnQgQkdQIEdyYWNlZnVsIFJlc3RhcnQgbWVjaGFuaXNt
IGxpbWl0cyB0aGUgdXNhZ2Ugb2YgQkdQDQogICBHcmFjZWZ1bCBSZXN0YXJ0IHRvIEJHUCBwcm90
b2NvbCBtZXNzYWdlcyBvdGhlciB0aGFuIGEgQkdQDQogICBOT1RJRklDQVRJT04gbWVzc2FnZS4g
IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbnNpb24gdG8gdGhlIEJHUA0KICAgR3JhY2Vm
dWwgUmVzdGFydCB0aGF0IHBlcm1pdHMgdGhlIEdyYWNlZnVsIFJlc3RhcnQgcHJvY2VkdXJlcyB0
byBiZQ0KICAgcGVyZm9ybWVkIHdoZW4gdGhlIEJHUCBzcGVha2VyIHJlY2VpdmVzIGEgQkdQIE5P
VElGSUNBVElPTiBNZXNzYWdlLg0KICAgVGhpcyBkb2N1bWVudCBhbHNvIGRlZmluZXMgYSBuZXcg
QkdQIE5PVElGSUNBVElPTiBDZWFzZSBFcnJvciBzdWJjb2RlDQogICB0byBwcmV2ZW50IEJHUCBz
cGVha2VycyBzdXBwb3J0aW5nIHRoZSBleHRlbnNpb24gZGVmaW5lZCBpbiB0aGlzDQogICBkb2N1
bWVudCBmcm9tIHBlcmZvcm1pbmcgYSBHcmFjZWZ1bCBSZXN0YXJ0Lg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRy
QGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2lkcg0K

--_000_76AD4ADFA14F4CD4BF438DD01E60E390junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <E725D71EB6FD67469A2408D4D9B1E1F4@junipernetworks.onmicrosoft.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PjwvZGl2Pg0KPGRpdj5CeSB0aGUgd2F5LCBJIHdvdWxkIGxpa2UgdG8gZW5jb3VyYWdlIGlt
cGxlbWVudG9ycyB0byB1cGRhdGUgdGhlIChxdWl0ZSBkYXRlZCkmbmJzcDtpbXBsZW1lbnRhdGlv
biByZXBvcnQgYXQmbmJzcDs8YSBocmVmPSJodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9pZHIv
d2lraS9kcmFmdC1pZXRmLWlkci1iZ3AtZ3Itbm90aWZpY2F0aW9uJTIwaW1wbGVtZW50YXRpb25z
Ij5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9pZHIvd2lraS9kcmFmdC1pZXRmLWlkci1iZ3At
Z3Itbm90aWZpY2F0aW9uJTIwaW1wbGVtZW50YXRpb25zPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+VGhhbmtzLDxicj4NCjxicj4NCi0tSm9objwvZGl2Pg0KPGRpdj48L2Rpdj4N
CjxkaXY+PGJyPg0KT24gRGVjIDEwLCAyMDE2LCBhdCAyOjUwIFBNLCBKb2huIFNjdWRkZXIgJmx0
OzxhIGhyZWY9Im1haWx0bzpqZ3NAanVuaXBlci5uZXQiPmpnc0BqdW5pcGVyLm5ldDwvYT4mZ3Q7
IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2
PkhpIEV2ZXJ5Ym9keSwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPk15IG1pc3Rha2UsIHRoZSBXR0xDIHdhc24ndCBpbiAyMDE1LCBpdCB3YXMgaW4g
MjAxNCBhbmQgdGhlIGxhc3QgdHJhZmZpYyB0byB0aGUgdGhyZWFkIHdhcyAyMDE1IDotby4gSSB0
aGluayB0aGF0IHVuZGVyIHRoZSBjaXJjdW1zdGFuY2VzIHdlIHByb2JhYmx5IGhhdmUgdG8gZG8g
YW5vdGhlciBvbmUsIGFsdGhvdWdoIEkgbGVhdmUgdGhlIGZpbmFsIGRlY2lzaW9uIHRvIG15IGNv
LWNoYWlyLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+RllJIHRoZSBkaWZmIGZyb20gdGhlIHZlcnNpb24gdGhhdCB3YXMgb3JpZ2luYWxs
eSBXR0xDJ2QgdG8gdGhlIGN1cnJlbnQgb25lIGlzOmh0dHBzOi8vPGEgaHJlZj0iaHR0cDovL3d3
dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1pZHItYmdwLWdyLW5vdGlmaWNhdGlv
bi0wMiZhbXA7dXJsMj1kcmFmdC1pZXRmLWlkci1iZ3AtZ3Itbm90aWZpY2F0aW9uLTA5IiBjbGFz
cz0iIj53d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtaWRyLWJncC1nci1ub3Rp
ZmljYXRpb24tMDImYW1wO3VybDI9ZHJhZnQtaWV0Zi1pZHItYmdwLWdyLW5vdGlmaWNhdGlvbi0w
OTwvYT4uDQogSSBiZWxpZXZlIHRoaXMgcmVzb2x2ZXMgYWxsIGlzc3VlcyB0aGF0IHdlcmUgcmFp
c2VkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh
c3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+LS1Kb2huPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N
CjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+
T24gTWF5IDI3LCAyMDE0LCBhdCAxOjE5IFBNLCBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnNoYXJlc0BuZHpoLmNvbSIgY2xhc3M9IiI+c2hhcmVzQG5kemguY29tPC9hPiZndDsgd3Jv
dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0
aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl
OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7
IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v
cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i
Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBO
ZXcnOyIgY2xhc3M9IiI+V29ya2luZyBHcm91cCw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48
L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx
MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFz
cz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9
Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog
Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog
MTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj5UaGlzIGlzIHRvIGJl
Z2luIGEgMiB3ZWVrIFdHIExDIGZvciBkcmFmdC1pZXRmLWlkci1iZ3AtZ3Itbm90aWZpY2F0aW9u
LTAyLnR4dCB3aGljaCB3aWxsIGVuZCBvbiA2LzEwLzIwMTQuICZuYnNwO1BsZWFzZSBwdXQgd2l0
aGluIHlvdXIgY29tbWVudHM6Jm5ic3A7IOKAnHN1cHBvcnTigJ0gb3Ig4oCcbm8tc3VwcG9ydOKA
nSBmb3IgV0cgTEMuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu
OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp
LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm
b250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0
OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh
c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJp
ZXIgTmV3JzsiIGNsYXNzPSIiPkplZmYgSGFhcyBjb21tZW50cyB0aGF0IHRoZSBtb3N0IHJlY2Vu
dCBjaGFuZ2VzIHJlZmxlY3QgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSBhbmQgc29tZSB3b3Jk
IHNtaXRoaW5nLiZuYnNwOyBUaGVyZSBpcyBhbHNvIGEgbWlub3IgY2xhcmlmaWNhdGlvbiBpbiB0
aGUgTk9USUZJQ0FUSU9OIG1lc3NhZ2Ugd2l0aCByZXNwZWN0IHRvIGluY2x1ZGluZw0KIGEgZGF0
YSBieXRlIHNvIHRoZSBvcmlnaW5hbCByZWFzb24gZm9yIHRoZSBldmVudCBjYW4gYmUgcHJvcGFn
YXRlZC4mbmJzcDsgKFNlZSBzZWMuIDMuMSBpbiB0aGUgZGlmZi4pPG86cCBjbGFzcz0iIj48L286
cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i
Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBO
ZXcnOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u
dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm
b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+VGhl
IGFic3RyYWN0IGlzIGJlbG93LjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9
Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog
Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog
MTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIi
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw
LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp
ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6
ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj5TdWUgSGFyZXM8bzpwIGNsYXNzPSIiPjwvbzpwPjwv
c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z
aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7
IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg
c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh
bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj48bzpwIGNs
YXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu
IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu
cy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1m
YW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4tLS0tLS0tLS0tPG86cCBjbGFzcz0iIj48
L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7
IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz
cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmll
ciBOZXcnOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+
DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg
Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+
QWJzdHJhY3Q6PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh
bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw
cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IFRo
ZSBjdXJyZW50IEJHUCBHcmFjZWZ1bCBSZXN0YXJ0IG1lY2hhbmlzbSBsaW1pdHMgdGhlIHVzYWdl
IG9mIEJHUDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy
Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp
YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0
OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBHcmFj
ZWZ1bCBSZXN0YXJ0IHRvIEJHUCBwcm90b2NvbCBtZXNzYWdlcyBvdGhlciB0aGFuIGEgQkdQPG86
cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw
aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt
c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt
aWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IE5PVElGSUNBVElPTiBt
ZXNzYWdlLiZuYnNwOyBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBC
R1A8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog
MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg
c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u
dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgR3JhY2VmdWwg
UmVzdGFydCB0aGF0IHBlcm1pdHMgdGhlIEdyYWNlZnVsIFJlc3RhcnQgcHJvY2VkdXJlcyB0byBi
ZTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250
LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBwZXJmb3JtZWQg
d2hlbiB0aGUgQkdQIHNwZWFrZXIgcmVjZWl2ZXMgYSBCR1AgTk9USUZJQ0FUSU9OIE1lc3NhZ2Uu
PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp
biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh
bnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt
ZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1l
bnQgYWxzbyBkZWZpbmVzIGEgbmV3IEJHUCBOT1RJRklDQVRJT04gQ2Vhc2UgRXJyb3Igc3ViY29k
ZTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw
aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250
LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyB0byBwcmV2ZW50
IEJHUCBzcGVha2VycyBzdXBwb3J0aW5nIHRoZSBleHRlbnNpb24gZGVmaW5lZCBpbiB0aGlzPG86
cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw
aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt
c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt
aWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50IGZyb20g
cGVyZm9ybWluZyBhIEdyYWNlZnVsIFJlc3RhcnQuPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8
c3Bhbj5JZHIgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzpJ
ZHJAaWV0Zi5vcmciPklkckBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyPC9hPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_76AD4ADFA14F4CD4BF438DD01E60E390junipernet_--


From nobody Mon Dec 12 04:53:31 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E117129A8A; Mon, 12 Dec 2016 04:53:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148154720718.22400.13789076069574917611.idtracker@ietfa.amsl.com>
Date: Mon, 12 Dec 2016 04:53:27 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5FtI5xW6DjfTc2TjCGi5mz-vXS8>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-prefix-sid-04.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 12:53:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Segment Routing Prefix SID extensions for BGP
        Authors         : Stefano Previdi
                          Clarence Filsfils
                          Acee Lindem
                          Keyur Patel
                          Arjun Sreekantiah
                          Saikat Ray
                          Hannes Gredler
	Filename        : draft-ietf-idr-bgp-prefix-sid-04.txt
	Pages           : 16
	Date            : 2016-12-12

Abstract:
   Segment Routing (SR) architecture allows a node to steer a packet
   flow through any topological path and service chain by leveraging
   source routing.  The ingress node prepends a SR header to a packet
   containing a set of "segments".  Each segment represents a
   topological or a service-based instruction.  Per-flow state is
   maintained only at the ingress node of the SR domain.

   This document describes the BGP extension for announcing BGP Prefix
   Segment Identifier (BGP Prefix SID) information.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-prefix-sid-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Dec 12 10:43:44 2016
Return-Path: <rjsparks@nostrum.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136C41294A9; Mon, 12 Dec 2016 10:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level: 
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
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 hcty4R984-4Q; Mon, 12 Dec 2016 10:43:37 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 81312129484; Mon, 12 Dec 2016 10:43:34 -0800 (PST)
Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBCIhX8r038117 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 12 Dec 2016 12:43:34 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local
To: General Area Review Team <gen-art@ietf.org>, draft-ietf-idr-large-community.all@ietf.org, idr@ietf.org, ietf@ietf.org
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <07906876-6e21-2df9-c7a0-1270e76fea4e@nostrum.com>
Date: Mon, 12 Dec 2016 12:43:33 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------C170FFA7834C9F647083ECCD"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TS4Knt2iRq1EKbNBFkEyfGk0pfw>
Subject: [Idr] Genart LC review: draft-ietf-idr-large-community-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 18:43:40 -0000

This is a multi-part message in MIME format.
--------------C170FFA7834C9F647083ECCD
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-idr-large-community-11
Reviewer: Robert Sparks
Review Date: 12 Dec 2016
IETF LC End Date: 16 Dec 2016
IESG Telechat date: 5 Jan 2017

Summary: Ready with nits

First a question (I don't know if this should lead to a change in the 
document). You say the use of reserved ASNs is NOT RECOMMENDED and later 
that the attribute MUST NOT be considered malformed if it has a reserved 
ASN in it. Is it clear what a recipient is supposed to do if one of 
these reserved ANSs shows up here? If so (for my own education) could 
you point me to where that's described?

Nits:

Section 11.3 in the references is only referenced by the implementation 
status section which you instruct the rfc-editor to delete. Do you 
intend for the reference to also be deleted? If so, save yourself a 
round-trip with the RFC-editor and add instructions now. If not, you'll 
need to find a way to work a reference in that won't be deleted.

David Farmer makes a suggestion at 
https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s 
that looks reasonable to me. Please consider it.

The security consideration section start out with a sentence that 
strongly implies the reader might learn something about the security 
considerations for this document by reading RFC1997. That document's 
security considerations section says only that "Security issues are not 
discussed in this memo." I suggest simply deleting this first sentence. 
Please also consider if there are other BGP documents with substantive 
security considerations sections that you can point to instead.


--------------C170FFA7834C9F647083ECCD
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>I am the assigned Gen-ART reviewer for this draft. The General Area
      <br>
      Review Team (Gen-ART) reviews all IETF documents being processed
      <br>
      by the IESG for the IETF Chair.  Please treat these comments just
      <br>
      like any other last call comments.
      <br>
      <br>
      For more information, please see the FAQ at
      <br>
      <br>
      <a class="moz-txt-link-rfc2396E"
        href="http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq">&lt;http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&gt;</a>.
      <br>
      <br>
      Document:
      draft-ietf-idr-large-community-11<br>
      Reviewer:
      Robert Sparks<br>
      Review Date:
      12 Dec 2016<br>
      IETF LC End Date:
      16 Dec 2016<br>
      IESG Telechat date: 5 Jan 2017<br>
      <br>
      Summary:
      Ready with nits</p>
    <p>First a question (I don't know if this should lead to a change in
      the document). You say the use of reserved ASNs is NOT RECOMMENDED
      and later that the attribute MUST NOT be considered malformed if
      it has a reserved ASN in it. Is it clear what a recipient is
      supposed to do if one of these reserved ANSs shows up here? If so
      (for my own education) could you point me to where that's
      described?<br>
    </p>
    <p>Nits:</p>
    <p>Section 11.3 in the references is only referenced by the
      implementation status section which you instruct the rfc-editor to
      delete. Do you intend for the reference to also be deleted? If so,
      save yourself a round-trip with the RFC-editor and add
      instructions now. If not, you'll need to find a way to work a
      reference in that won't be deleted.</p>
    <p>David Farmer makes a suggestion at
      <a class="moz-txt-link-freetext" href="https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s">https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s</a>
      that looks reasonable to me. Please consider it.</p>
    <p>The security consideration section start out with a sentence that
      strongly implies the reader might learn something about the
      security considerations for this document by reading RFC1997. That
      document's security considerations section says only that
      "Security issues are not discussed in this memo." I suggest simply
      deleting this first sentence. Please also consider if there are
      other BGP documents with substantive security considerations
      sections that you can point to instead.
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
    </p>
  </body>
</html>

--------------C170FFA7834C9F647083ECCD--


From nobody Mon Dec 12 11:12:07 2016
Return-Path: <job@ntt.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C893512961C; Mon, 12 Dec 2016 11:12:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.831
X-Spam-Level: 
X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 8AP_SDEN8F5n; Mon, 12 Dec 2016 11:12:03 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85FB12949F; Mon, 12 Dec 2016 11:12:03 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1cGW14-0002Qc-4C (job@us.ntt.net); Mon, 12 Dec 2016 19:12:03 +0000
Date: Mon, 12 Dec 2016 20:11:59 +0100
From: Job Snijders <job@ntt.net>
To: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <20161212191159.GF75593@Vurt.local>
References: <07906876-6e21-2df9-c7a0-1270e76fea4e@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <07906876-6e21-2df9-c7a0-1270e76fea4e@nostrum.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xCwocmynIf2-dLOw-6_Uqm42uN4>
Cc: idr@ietf.org, General Area Review Team <gen-art@ietf.org>, draft-ietf-idr-large-community.all@ietf.org, ietf@ietf.org
Subject: Re: [Idr] Genart LC review: draft-ietf-idr-large-community-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 19:12:06 -0000

Dear Robert,

On Mon, Dec 12, 2016 at 12:43:33PM -0600, Robert Sparks wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.

Thank you for taking the time to review this document! 

> Document: draft-ietf-idr-large-community-11
> Reviewer: Robert Sparks
> Review Date: 12 Dec 2016
> IETF LC End Date: 16 Dec 2016
> IESG Telechat date: 5 Jan 2017
> 
> Summary: Ready with nits
> 
> First a question (I don't know if this should lead to a change in the
> document). You say the use of reserved ASNs is NOT RECOMMENDED and
> later that the attribute MUST NOT be considered malformed if it has a
> reserved ASN in it. Is it clear what a recipient is supposed to do if
> one of these reserved ANSs shows up here? If so (for my own education)
> could you point me to where that's described?

If two ASNs agree to exchange Large Communities with each other where
the mutually agreed upon Global Administrator value happens to be a
reserved ASN, that is something for those two networks to decide. The
key point here is that implementations must not impose any restrictions
on the uint32 value in the Global Administrator field. It is entirely at
the operator's discretion what to do with any Large Community, this
applies to reserved and non-reserved values.

The document recommends people to use their globally unique ASN, but
this will not be enforced through implementations. 

The security section refers to "Network administrators should note the
recommendations in Section 11 of BGP Operations and Security [RFC7454]."
There is some wisdom there to be gleaned.

> Nits:
> 
> Section 11.3 in the references is only referenced by the implementation
> status section which you instruct the rfc-editor to delete. Do you intend
> for the reference to also be deleted? If so, save yourself a round-trip with
> the RFC-editor and add instructions now. If not, you'll need to find a way
> to work a reference in that won't be deleted.

Yes, the intention is that the reference to RFC7942 is to be deleted
before publication.

This is my mistake: I mistook the hyperlink in
https://tools.ietf.org/html/rfc7942#section-2.1 to be a reference, but
its just an automagically converted hyperlink. We'll remove the
reference in the next version.

> David Farmer makes a suggestion at
> https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s that
> looks reasonable to me. Please consider it.

I do not believe there is consensus at this moment to make a blanket
recommendation based on the contents of the registry (whatever they
may be in the future), but rather work with the precise and concise
approach which is currently described.

Jakob Heitz responded to the suggestion to extend the reserved Global
Administrator values, but for some reason I can't find that email in the
IETF IDR archive, I've copy+pasted it here:

-------------
	Date: Mon, 05 Dec 2016 03:16:52 +0100
	From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
	To: David Freedman <david.freedman@uk.clara.net>
	Cc: "idr@ietf.org" <idr@ietf.org>
	Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt

    No new text is required to cover this: 23456 is not an ASN.
    Besides, if anyone were to put it into a large community, no harm
    would be done other than what would happen if any other unassigned
    ASN were used.

    About reserving values, we don't reserve values because the values
    are unusable, but because we may want to use them for other purposes
    later. There is no need to reserve another value. 3 is more than
    enough.

	Thanks,
	Jakob.
--------------

In addition to the above, although the document does not define any
Special-Use BGP Large Communities, the Global Administrator values
specified in Section 2 (0, 65535, 4294967295) could be used if there is
a future need for them. The purpose of recommending that these values
are not to be used is not because there is harm in doing so, but to
leave the door open for future things (should they ever arise). From
this perspective a blanket reservation based on the ASN registry
wouldn't make sense for me.

> The security consideration section start out with a sentence that
> strongly implies the reader might learn something about the security
> considerations for this document by reading RFC1997. That document's
> security considerations section says only that "Security issues are
> not discussed in this memo."

The reference to RFC 1997 was meant to leverage 20 years of experience
with implementing and operating networks which use RFC 1997 communities.
I agree that the security section of RFC 1997 is somewhat sparse, but
the principle still applies: RFC 1997 and Large Communities have similar
security implications, even if they are not properly documented in RFC
1997.

> I suggest simply deleting this first sentence. Please also consider if
> there are other BGP documents with substantive security considerations
> sections that you can point to instead.

A reference to RFC 7454 is included, I am not aware of other specific
resources that can be pointed at. 

Kind regards,

Job


From nobody Mon Dec 12 11:52:53 2016
Return-Path: <rjsparks@nostrum.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FB812948D; Mon, 12 Dec 2016 11:52:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level: 
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
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 Dsseq3Npi0g7; Mon, 12 Dec 2016 11:52:42 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 73E75129464; Mon, 12 Dec 2016 11:52:42 -0800 (PST)
Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBCJqffj045168 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 12 Dec 2016 13:52:41 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local
To: Job Snijders <job@ntt.net>
References: <07906876-6e21-2df9-c7a0-1270e76fea4e@nostrum.com> <20161212191159.GF75593@Vurt.local>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <8dc27460-a500-3948-0a61-da4dd2baf66b@nostrum.com>
Date: Mon, 12 Dec 2016 13:52:41 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <20161212191159.GF75593@Vurt.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/msWDqQWg-s_qXoV-sPjQId_PJuU>
Cc: idr@ietf.org, General Area Review Team <gen-art@ietf.org>, draft-ietf-idr-large-community.all@ietf.org, ietf@ietf.org
Subject: Re: [Idr] Genart LC review: draft-ietf-idr-large-community-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 19:52:44 -0000

On 12/12/16 1:11 PM, Job Snijders wrote:
> Dear Robert,
>
> On Mon, Dec 12, 2016 at 12:43:33PM -0600, Robert Sparks wrote:
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by
>> the IESG for the IETF Chair.  Please treat these comments just like
>> any other last call comments.
> Thank you for taking the time to review this document!
>
>> Document: draft-ietf-idr-large-community-11
>> Reviewer: Robert Sparks
>> Review Date: 12 Dec 2016
>> IETF LC End Date: 16 Dec 2016
>> IESG Telechat date: 5 Jan 2017
>>
>> Summary: Ready with nits
>>
>> First a question (I don't know if this should lead to a change in the
>> document). You say the use of reserved ASNs is NOT RECOMMENDED and
>> later that the attribute MUST NOT be considered malformed if it has a
>> reserved ASN in it. Is it clear what a recipient is supposed to do if
>> one of these reserved ANSs shows up here? If so (for my own education)
>> could you point me to where that's described?
> If two ASNs agree to exchange Large Communities with each other where
> the mutually agreed upon Global Administrator value happens to be a
> reserved ASN, that is something for those two networks to decide. The
> key point here is that implementations must not impose any restrictions
> on the uint32 value in the Global Administrator field. It is entirely at
> the operator's discretion what to do with any Large Community, this
> applies to reserved and non-reserved values.
>
> The document recommends people to use their globally unique ASN, but
> this will not be enforced through implementations.
Thanks for the explanation. It would have avoided the question if the 
document said that - consider explicitly adding the key point you point to.
>
> The security section refers to "Network administrators should note the
> recommendations in Section 11 of BGP Operations and Security [RFC7454]."
> There is some wisdom there to be gleaned.
>
>> Nits:
>>
>> Section 11.3 in the references is only referenced by the implementation
>> status section which you instruct the rfc-editor to delete. Do you intend
>> for the reference to also be deleted? If so, save yourself a round-trip with
>> the RFC-editor and add instructions now. If not, you'll need to find a way
>> to work a reference in that won't be deleted.
> Yes, the intention is that the reference to RFC7942 is to be deleted
> before publication.
>
> This is my mistake: I mistook the hyperlink in
> https://tools.ietf.org/html/rfc7942#section-2.1 to be a reference, but
> its just an automagically converted hyperlink. We'll remove the
> reference in the next version.
>
>> David Farmer makes a suggestion at
>> https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s that
>> looks reasonable to me. Please consider it.
> I do not believe there is consensus at this moment to make a blanket
> recommendation based on the contents of the registry (whatever they
> may be in the future), but rather work with the precise and concise
> approach which is currently described.
>
> Jakob Heitz responded to the suggestion to extend the reserved Global
> Administrator values, but for some reason I can't find that email in the
> IETF IDR archive, I've copy+pasted it here:
>
> -------------
> 	Date: Mon, 05 Dec 2016 03:16:52 +0100
> 	From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
> 	To: David Freedman <david.freedman@uk.clara.net>
> 	Cc: "idr@ietf.org" <idr@ietf.org>
> 	Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
>
>      No new text is required to cover this: 23456 is not an ASN.
>      Besides, if anyone were to put it into a large community, no harm
>      would be done other than what would happen if any other unassigned
>      ASN were used.
>
>      About reserving values, we don't reserve values because the values
>      are unusable, but because we may want to use them for other purposes
>      later. There is no need to reserve another value. 3 is more than
>      enough.
>
> 	Thanks,
> 	Jakob.
> --------------
>
> In addition to the above, although the document does not define any
> Special-Use BGP Large Communities, the Global Administrator values
> specified in Section 2 (0, 65535, 4294967295) could be used if there is
> a future need for them. The purpose of recommending that these values
> are not to be used is not because there is harm in doing so, but to
> leave the door open for future things (should they ever arise). From
> this perspective a blanket reservation based on the ASN registry
> wouldn't make sense for me.
  WFM, but please get your chairs to chase down why the message didn't 
make it to the archive.
>
>> The security consideration section start out with a sentence that
>> strongly implies the reader might learn something about the security
>> considerations for this document by reading RFC1997. That document's
>> security considerations section says only that "Security issues are
>> not discussed in this memo."
> The reference to RFC 1997 was meant to leverage 20 years of experience
> with implementing and operating networks which use RFC 1997 communities.
Well, sure, but where is that 20 years of experience written down for 
the next implementer or operator?
The existing pointer essentially has the semantic of "if you need to 
know you already know"...
> I agree that the security section of RFC 1997 is somewhat sparse, but
> the principle still applies: RFC 1997 and Large Communities have similar
> security implications, even if they are not properly documented in RFC
> 1997.
So, I _think_ your intent was to document them here.
>
>> I suggest simply deleting this first sentence.
I still think that's the right thing to do.
>>   Please also consider if
>> there are other BGP documents with substantive security considerations
>> sections that you can point to instead.
> A reference to RFC 7454 is included, I am not aware of other specific
> resources that can be pointed at.
>
> Kind regards,
>
> Job


From nobody Mon Dec 12 11:57:25 2016
Return-Path: <jheitz@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EBE12956A; Mon, 12 Dec 2016 11:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.418
X-Spam-Level: 
X-Spam-Status: No, score=-17.418 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 BgPEvMuYmVmD; Mon, 12 Dec 2016 11:57:21 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090FC1294C7; Mon, 12 Dec 2016 11:57:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6698; q=dns/txt; s=iport; t=1481572641; x=1482782241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TppuIxMQ4DjSjFR7u0aY5zF92O6wPA57EFh00Iabs0Y=; b=dVS6Cn+vrV0d3gQEkFYISsfHOAO/kvQSLVS3qHUPrHcZefCFWre+DzLG BWRzy/MuNFwzxqOmsQWqz3aC73xX3wOFsQ+2ihE8AlZwQ95quzIbyyNRb vpictI67vPuvS35zTBTz0t9hbRlalC4WvkxVTA1mjosbkjfZmT0uRpbYU w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAQAqAE9Y/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9agQYHjUKXFJUEgggpgkKDNgKBdz8UAQIBAQEBAQE?= =?us-ascii?q?BYiiEaAEBAQQ6LRIMBAIBCBEDAQEBAR4JBzIUCQgCBAENBQgMAohVDq4Qiw8BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYY+hFuEGhEBhX0FiGOSCAGGTopOgXyFAIl?= =?us-ascii?q?TjguEDgEfN2I9g16BfnIBhWGBIYENAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,338,1477958400"; d="scan'208";a="358415391"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2016 19:57:19 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uBCJvJcC011472 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Dec 2016 19:57:19 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 13:57:19 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 12 Dec 2016 13:57:19 -0600
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Job Snijders <job@ntt.net>, Robert Sparks <rjsparks@nostrum.com>
Thread-Topic: [Idr] Genart LC review: draft-ietf-idr-large-community-11
Thread-Index: AQHSVKerCdDPBKsVM06yo0IndsoqH6EFEn6A//+lWXA=
Date: Mon, 12 Dec 2016 19:57:19 +0000
Message-ID: <4c2a0eab4665481782abef13cfbdca43@XCH-ALN-014.cisco.com>
References: <07906876-6e21-2df9-c7a0-1270e76fea4e@nostrum.com> <20161212191159.GF75593@Vurt.local>
In-Reply-To: <20161212191159.GF75593@Vurt.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.162.196]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/eXaEgQ3oSc5CdYC0_Nrve5xwWnA>
Cc: "idr@ietf.org" <idr@ietf.org>, General Area Review Team <gen-art@ietf.org>, "draft-ietf-idr-large-community.all@ietf.org" <draft-ietf-idr-large-community.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [Idr] Genart LC review: draft-ietf-idr-large-community-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 19:57:23 -0000

A little more context regarding reserved communities:

The RFC 1997 reserved community values 65535:* will be
presented to the routing policy when received, just like
any other community values. The routing policy can match
on them and set or delete them, just like any other
community values.

The only difference is that the router takes the
action prescribed by an assigned reserved community value,
in most cases. I.e., it is not even required that the
routing software take the prescribed action. The routing
policy could do it just as well.

This carries over to large communities.

Thanks,
Jakob.


> -----Original Message-----
> From: Job Snijders [mailto:job@ntt.net]
> Sent: Monday, December 12, 2016 11:12 AM
> To: Robert Sparks <rjsparks@nostrum.com>
> Cc: General Area Review Team <gen-art@ietf.org>; draft-ietf-idr-large-com=
munity.all@ietf.org; idr@ietf.org;
> ietf@ietf.org
> Subject: Re: [Idr] Genart LC review: draft-ietf-idr-large-community-11
>=20
> Dear Robert,
>=20
> On Mon, Dec 12, 2016 at 12:43:33PM -0600, Robert Sparks wrote:
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed by
> > the IESG for the IETF Chair.  Please treat these comments just like
> > any other last call comments.
>=20
> Thank you for taking the time to review this document!
>=20
> > Document: draft-ietf-idr-large-community-11
> > Reviewer: Robert Sparks
> > Review Date: 12 Dec 2016
> > IETF LC End Date: 16 Dec 2016
> > IESG Telechat date: 5 Jan 2017
> >
> > Summary: Ready with nits
> >
> > First a question (I don't know if this should lead to a change in the
> > document). You say the use of reserved ASNs is NOT RECOMMENDED and
> > later that the attribute MUST NOT be considered malformed if it has a
> > reserved ASN in it. Is it clear what a recipient is supposed to do if
> > one of these reserved ANSs shows up here? If so (for my own education)
> > could you point me to where that's described?
>=20
> If two ASNs agree to exchange Large Communities with each other where
> the mutually agreed upon Global Administrator value happens to be a
> reserved ASN, that is something for those two networks to decide. The
> key point here is that implementations must not impose any restrictions
> on the uint32 value in the Global Administrator field. It is entirely at
> the operator's discretion what to do with any Large Community, this
> applies to reserved and non-reserved values.
>=20
> The document recommends people to use their globally unique ASN, but
> this will not be enforced through implementations.
>=20
> The security section refers to "Network administrators should note the
> recommendations in Section 11 of BGP Operations and Security [RFC7454]."
> There is some wisdom there to be gleaned.
>=20
> > Nits:
> >
> > Section 11.3 in the references is only referenced by the implementation
> > status section which you instruct the rfc-editor to delete. Do you inte=
nd
> > for the reference to also be deleted? If so, save yourself a round-trip=
 with
> > the RFC-editor and add instructions now. If not, you'll need to find a =
way
> > to work a reference in that won't be deleted.
>=20
> Yes, the intention is that the reference to RFC7942 is to be deleted
> before publication.
>=20
> This is my mistake: I mistook the hyperlink in
> https://tools.ietf.org/html/rfc7942#section-2.1 to be a reference, but
> its just an automagically converted hyperlink. We'll remove the
> reference in the next version.
>=20
> > David Farmer makes a suggestion at
> > https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s t=
hat
> > looks reasonable to me. Please consider it.
>=20
> I do not believe there is consensus at this moment to make a blanket
> recommendation based on the contents of the registry (whatever they
> may be in the future), but rather work with the precise and concise
> approach which is currently described.
>=20
> Jakob Heitz responded to the suggestion to extend the reserved Global
> Administrator values, but for some reason I can't find that email in the
> IETF IDR archive, I've copy+pasted it here:
>=20
> -------------
> 	Date: Mon, 05 Dec 2016 03:16:52 +0100
> 	From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
> 	To: David Freedman <david.freedman@uk.clara.net>
> 	Cc: "idr@ietf.org" <idr@ietf.org>
> 	Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-com=
munity-11.txt
>=20
>     No new text is required to cover this: 23456 is not an ASN.
>     Besides, if anyone were to put it into a large community, no harm
>     would be done other than what would happen if any other unassigned
>     ASN were used.
>=20
>     About reserving values, we don't reserve values because the values
>     are unusable, but because we may want to use them for other purposes
>     later. There is no need to reserve another value. 3 is more than
>     enough.
>=20
> 	Thanks,
> 	Jakob.
> --------------
>=20
> In addition to the above, although the document does not define any
> Special-Use BGP Large Communities, the Global Administrator values
> specified in Section 2 (0, 65535, 4294967295) could be used if there is
> a future need for them. The purpose of recommending that these values
> are not to be used is not because there is harm in doing so, but to
> leave the door open for future things (should they ever arise). From
> this perspective a blanket reservation based on the ASN registry
> wouldn't make sense for me.
>=20
> > The security consideration section start out with a sentence that
> > strongly implies the reader might learn something about the security
> > considerations for this document by reading RFC1997. That document's
> > security considerations section says only that "Security issues are
> > not discussed in this memo."
>=20
> The reference to RFC 1997 was meant to leverage 20 years of experience
> with implementing and operating networks which use RFC 1997 communities.
> I agree that the security section of RFC 1997 is somewhat sparse, but
> the principle still applies: RFC 1997 and Large Communities have similar
> security implications, even if they are not properly documented in RFC
> 1997.
>=20
> > I suggest simply deleting this first sentence. Please also consider if
> > there are other BGP documents with substantive security considerations
> > sections that you can point to instead.
>=20
> A reference to RFC 7454 is included, I am not aware of other specific
> resources that can be pointed at.
>=20
> Kind regards,
>=20
> Job


From nobody Mon Dec 12 12:32:38 2016
Return-Path: <jheitz@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCB0129491; Mon, 12 Dec 2016 12:32:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.418
X-Spam-Level: 
X-Spam-Status: No, score=-17.418 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 kGFCgybm6pQf; Mon, 12 Dec 2016 12:32:29 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566A7126D73; Mon, 12 Dec 2016 12:32:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1315; q=dns/txt; s=iport; t=1481574749; x=1482784349; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uXr+dyGFgisN1HZySOoDtWL3XcPVIESO5WqVFE5xEWs=; b=hnJz/Aq5z/tLSyjPSc6M/Rd+86+jKrVv56I9z9seHltDebxwR9LU2eeT VrAJMEaso0zgj7KwilwvBEQE/Y5XJGr1to6We+DwqGkTZK4SfJOghDoXd 5UKPMkCYa+bMWTnO9aRSoUQ1pHlO84IkOtGqq1acYckI1vcWlB3dbgTTl U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQB8CE9Y/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9agQYHjUKXFJUEgggphXgCgXg/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEDATo/BQsCAQgOAwMBAh8QMh0IAgQBDQUIDIhPCA6uGosOAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWGPoRbhBoQAgFNhS8FiGOSCAGRHIF8hQCJU44LhA4?= =?us-ascii?q?BHzdiPYNegX5yAYcCgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.33,338,1477958400"; d="scan'208";a="172033979"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2016 20:32:28 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uBCKWSna010787 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Dec 2016 20:32:28 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 14:32:27 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 12 Dec 2016 14:32:27 -0600
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Robert Sparks <rjsparks@nostrum.com>, Job Snijders <job@ntt.net>
Thread-Topic: [Idr] Genart LC review: draft-ietf-idr-large-community-11
Thread-Index: AQHSVKerCdDPBKsVM06yo0IndsoqH6EFEn6AgAALYID//5724A==
Date: Mon, 12 Dec 2016 20:32:27 +0000
Message-ID: <f4a5b4be6cb94663ae5c98b7780f122e@XCH-ALN-014.cisco.com>
References: <07906876-6e21-2df9-c7a0-1270e76fea4e@nostrum.com> <20161212191159.GF75593@Vurt.local> <8dc27460-a500-3948-0a61-da4dd2baf66b@nostrum.com>
In-Reply-To: <8dc27460-a500-3948-0a61-da4dd2baf66b@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.162.196]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CgPCQbLjj_udd_tvmuj8zb3v0TE>
Cc: "idr@ietf.org" <idr@ietf.org>, General Area Review Team <gen-art@ietf.org>, "draft-ietf-idr-large-community.all@ietf.org" <draft-ietf-idr-large-community.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [Idr] Genart LC review: draft-ietf-idr-large-community-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 20:32:32 -0000

> >
> > Jakob Heitz responded to the suggestion to extend the reserved Global
> > Administrator values, but for some reason I can't find that email in th=
e
> > IETF IDR archive, I've copy+pasted it here:
> >
> > -------------
> > 	Date: Mon, 05 Dec 2016 03:16:52 +0100
> > 	From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
> > 	To: David Freedman <david.freedman@uk.clara.net>
> > 	Cc: "idr@ietf.org" <idr@ietf.org>
> > 	Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-c=
ommunity-11.txt
> >
> >      No new text is required to cover this: 23456 is not an ASN.
> >      Besides, if anyone were to put it into a large community, no harm
> >      would be done other than what would happen if any other unassigned
> >      ASN were used.
> >
> >      About reserving values, we don't reserve values because the values
> >      are unusable, but because we may want to use them for other purpos=
es
> >      later. There is no need to reserve another value. 3 is more than
> >      enough.
> >
> > 	Thanks,
> > 	Jakob.
> > --------------
> >

>   WFM, but please get your chairs to chase down why the message didn't
> make it to the archive.

It shows up in the other archive:
https://www.ietf.org/mail-archive/web/idr/current/msg17255.html


Thanks,
Jakob.


From nobody Tue Dec 13 16:12:30 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8A2129407; Tue, 13 Dec 2016 16:12:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.39.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148167434857.10859.14815880012208481023.idtracker@ietfa.amsl.com>
Date: Tue, 13 Dec 2016 16:12:28 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zYXixoMc2bTRKeFtKOmgdhuLA6Q>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-14.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2016 00:12:28 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Extended Message support for BGP
        Authors         : Randy Bush
                          Keyur Patel
                          Dave Ward
	Filename        : draft-ietf-idr-bgp-extended-messages-14.txt
	Pages           : 5
	Date            : 2016-12-13

Abstract:
   The BGP specification mandates a maximum BGP message size of 4096
   octets.  As BGP is extended to support newer AFI/SAFIs, there is a
   need to extend the maximum message size beyond 4096 octets.  This
   document updates the BGP specification by providing an extension to
   BGP to extend its current message size from 4096 octets to 65535
   octets.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-extended-messages-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Dec 13 16:13:26 2016
Return-Path: <randy@psg.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982A8129407 for <idr@ietfa.amsl.com>; Tue, 13 Dec 2016 16:13:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.797
X-Spam-Level: 
X-Spam-Status: No, score=-9.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ECztH4IlXZCC for <idr@ietfa.amsl.com>; Tue, 13 Dec 2016 16:13:24 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 879DC1294DF for <idr@ietf.org>; Tue, 13 Dec 2016 16:13:24 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1cGxCE-0005Wi-S6 for idr@ietf.org; Wed, 14 Dec 2016 00:13:23 +0000
Date: Wed, 14 Dec 2016 09:13:21 +0900
Message-ID: <m2shprz7tq.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: idr@ietf.org
In-Reply-To: <148167434857.10859.14815880012208481023.idtracker@ietfa.amsl.com>
References: <148167434857.10859.14815880012208481023.idtracker@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/b4TyPjj0tZqCCQaxTrbkkLDLdCA>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-extended-messages-14.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2016 00:13:25 -0000

just a refresh


From nobody Wed Dec 14 01:00:34 2016
Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876B612952F for <idr@ietfa.amsl.com>; Wed, 14 Dec 2016 01:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.096
X-Spam-Level: 
X-Spam-Status: No, score=-107.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no
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 SzUIWaScvQn1 for <idr@ietfa.amsl.com>; Wed, 14 Dec 2016 01:00:31 -0800 (PST)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 853831294FD for <idr@ietf.org>; Wed, 14 Dec 2016 01:00:30 -0800 (PST)
X-MAILFROM: <zhang.zheng@zte.com.cn>
X-RCPTTO: <idr@ietf.org>
X-FROMIP: 10.30.3.20
X-SEG-Scaned: 1
X-Received: unknown,10.30.3.20,20161214165828
Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 14 Dec 2016 08:58:28 -0000
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uBE8xrKh034413; Wed, 14 Dec 2016 16:59:53 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
In-Reply-To: <f4a5b4be6cb94663ae5c98b7780f122e@XCH-ALN-014.cisco.com>
To: "Idr" <idr-bounces@ietf.org>, robert@raszuk.net, idr@ietf.org
MIME-Version: 1.0
Sensitivity: 
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF716322A9.48ACEC54-ON48258089.002B5092-48258089.00316E72@zte.com.cn>
From: zhang.zheng@zte.com.cn
Date: Wed, 14 Dec 2016 16:59:59 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-12-14 16:59:34, Serialize complete at 2016-12-14 16:59:34
Content-Type: multipart/alternative; boundary="=_alternative 00316E7048258089_="
X-MAIL: mse01.zte.com.cn uBE8xrKh034413
X-HQIP: 127.0.0.1
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/iAd-vOqq7ukyQssc2I8QufGtwq4>
Cc: zhu.xiaolong@zte.com.cn, shen.yiming@zte.com.cn, zhu.tong@zte.com.cn
Subject: [Idr]  One question about "Terminal Action bit" in RFC5575
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2016 09:00:32 -0000

This is a multipart message in MIME format.
--=_alternative 00316E7048258089_=
Content-Type: text/plain; charset="US-ASCII"

Hi all,

    About RFC5575, it seems like that the definition of "Terminal 
Action bit" is blurred. 

    In section 7, the "Terminal Action bit" is defined as follows:
Terminal Action (bit 47): When this bit is set, the traffic filtering 
engine will apply any subsequent filtering rules (as defined by the 
ordering procedure).  If not set, the evaluation of the traffic filter 
stops when this rule is applied.

    How can routers do when many rules that define variant actions 
are applied to a same flow?

   For example, there are four rules that can be applied to one same flow. 

And the sequence has been determined as below. When router executes rule 
1,
the "Terminal Action Bit" is set. It indicated that next rule should be 
executed. When router execute rule 2, which action should be executed? 
Only redirect? Or/and traffic-marking? Which traffic-rate should be 
selected?

rule 1

   traffic-rate: 10Mbps

   traffic-marking: DSCP=10

   traffic-action: T=1 S=1 


rule 2

   traffic-rate: 20Mbps

   redirect: nexthop = 192.168.1.2

   traffic-action: T=0 S=0 


rule 3

   traffic-rate: 30Mbps

   traffic-marking: DSCP=30

   redirect: nexthop = 192.168.2.2

   traffic-action: T=1 S=1 
 

rule 4

   traffic-rate: 40Mbps

   traffic-marking: DSCP=40

   traffic-action: T=0 S=0 


--=_alternative 00316E7048258089_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Hi all,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; About RFC5575, it seems
like that the definition of &quot;Terminal </font>
<br><font size=2 face="sans-serif">Action bit&quot; is blurred. </font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; In section 7, the &quot;Terminal
Action bit&quot; is defined as follows:</font>
<br><font size=2 face="sans-serif">Terminal Action (bit 47): When this
bit is set, the traffic filtering </font>
<br><font size=2 face="sans-serif">engine will apply any subsequent filtering
rules (as defined by the </font>
<br><font size=2 face="sans-serif">ordering procedure). &nbsp;If not set,
the evaluation of the traffic filter </font>
<br><font size=2 face="sans-serif">stops when this rule is applied.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; How can routers do when
many rules that define variant actions </font>
<br><font size=2 face="sans-serif">are applied to a same flow?</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;For example, there are
four rules that can be applied to one same flow. </font>
<br><font size=2 face="sans-serif">And the sequence has been determined
as below. When router executes rule 1,</font>
<br><font size=2 face="sans-serif">the &quot;Terminal Action Bit&quot;
is set. It indicated that next rule should be </font>
<br><font size=2 face="sans-serif">executed. When router execute rule 2,
which action should be executed? </font>
<br><font size=2 face="sans-serif">Only redirect? Or/and traffic-marking?
Which traffic-rate should be </font>
<br><font size=2 face="sans-serif">selected?</font>
<br>
<br><font size=2 face="sans-serif">rule 1</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-rate: 10Mbps</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-marking: DSCP=10</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-action: T=1 S=1
</font>
<br>
<br>
<br><font size=2 face="sans-serif">rule 2</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-rate: 20Mbps</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;redirect: nexthop = 192.168.1.2</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-action: T=0 S=0
</font>
<br>
<br>
<br><font size=2 face="sans-serif">rule 3</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-rate: 30Mbps</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-marking: DSCP=30</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;redirect: nexthop = 192.168.2.2</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-action: T=1 S=1
&nbsp;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">rule 4</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-rate: 40Mbps</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-marking: DSCP=40</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;traffic-action: T=0 S=0
</font>
<br>
<br>
--=_alternative 00316E7048258089_=--


From nobody Wed Dec 14 02:59:21 2016
Return-Path: <c@tix.at>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC88C129D30; Wed, 14 Dec 2016 02:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 SzDH0DErfRXW; Wed, 14 Dec 2016 02:59:17 -0800 (PST)
Received: from mail.hated.at (mail.hated.at [86.59.35.235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03FA129D31; Wed, 14 Dec 2016 02:59:15 -0800 (PST)
Received: from 80-110-80-178.cgn.dynamic.surfer.at ([80.110.80.178] helo=[192.168.66.245]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1cH77f-0003iZ-1v; Wed, 14 Dec 2016 11:49:21 +0100
From: Christoph Loibl <c@tix.at>
Message-Id: <5DB3C819-FEAE-48A7-A755-E1683E410D16@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B0A33760-352C-41EC-9FFD-72861888968F"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Wed, 14 Dec 2016 11:58:53 +0100
In-Reply-To: <OF716322A9.48ACEC54-ON48258089.002B5092-48258089.00316E72@zte.com.cn>
To: zhang.zheng@zte.com.cn
References: <OF716322A9.48ACEC54-ON48258089.002B5092-48258089.00316E72@zte.com.cn>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ocEWmA5MKPBo9FH_1Znat_AR2CQ>
Cc: zhu.xiaolong@zte.com.cn, idr@ietf.org, robert@raszuk.net, shen.yiming@zte.com.cn, Idr <idr-bounces@ietf.org>, zhu.tong@zte.com.cn
Subject: Re: [Idr] One question about "Terminal Action bit" in RFC5575
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2016 10:59:20 -0000

--Apple-Mail=_B0A33760-352C-41EC-9FFD-72861888968F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

Your example perfectly makes sense to me, and I understand that there =
are several sections in RFC5575 that are a little unclear. RFC5575 does =
not explain what should happen in your case, nor does it explain =
anything in case of action-interference.

This is why we currently working on a rfc557bis that should help us to =
fix those problems and improve interoperability for flowspec. Have a =
look at:

https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/ =
<https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/>
Section 7.6. Rules on Traffic Action Interference

During writing this section we were actually discussing single flowspec =
NLRIs with conflicting actions like:

rule 1
    traffic-rate: 10Mbps
    traffic-rate: 20Mbps

or

rule 1
   redirect: A
   redirect: B

I think we shall extend this section to also explain your case. =
Currently this is not explained even in our submitted draft =
draft-hr-idr-rfc5575bis =
<https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/> latest =
revision. In that case it may make sense to have a "latest" action wins =
behaviour. I suggest the following behaviour (this is nowhere written =
yet):

Suggestion: In your example the action for a flow matching all your =
rules should be a merge of rule 1 and rule 2:

> rule 1=20
>=20
>    traffic-rate: 10Mbps=20
>=20
>    traffic-marking: DSCP=3D10=20
>=20
>    traffic-action: T=3D1 S=3D1=20
>=20

after this rule 2 gets applied

>=20
> rule 2=20
>=20
>    traffic-rate: 20Mbps=20
>=20
>    redirect: nexthop =3D 192.168.1.2=20
>=20
>    traffic-action: T=3D0 S=3D0=20
>=20


The resulting action for that flow is:

    traffic-rate: 20Mbps
    traffic-marking: DSCP=3D10
    redirect: nexthop =3D 192.168.1.2

Since on the second rule the terminal-bit is 0 there is no other rule to =
be evaluated.

To the "latest" applied action wins. However this is only one suggested =
behaviour. There are plenty of other options. It should also be =
considered that implementing such a behaviour may not be trivial.

Christoph


> On 14 Dec 2016, at 09:59, zhang.zheng@zte.com.cn wrote:
>=20
>=20
> Hi all,=20
>=20
>     About RFC5575, it seems like that the definition of "Terminal=20
> Action bit" is blurred.=20
>=20
>     In section 7, the "Terminal Action bit" is defined as follows:=20
> Terminal Action (bit 47): When this bit is set, the traffic filtering=20=

> engine will apply any subsequent filtering rules (as defined by the=20
> ordering procedure).  If not set, the evaluation of the traffic filter=20=

> stops when this rule is applied.=20
>=20
>     How can routers do when many rules that define variant actions=20
> are applied to a same flow?=20
>=20
>    For example, there are four rules that can be applied to one same =
flow.=20
> And the sequence has been determined as below. When router executes =
rule 1,=20
> the "Terminal Action Bit" is set. It indicated that next rule should =
be=20
> executed. When router execute rule 2, which action should be executed?=20=

> Only redirect? Or/and traffic-marking? Which traffic-rate should be=20
> selected?=20
>=20
> rule 1=20
>=20
>    traffic-rate: 10Mbps=20
>=20
>    traffic-marking: DSCP=3D10=20
>=20
>    traffic-action: T=3D1 S=3D1=20
>=20
>=20
> rule 2=20
>=20
>    traffic-rate: 20Mbps=20
>=20
>    redirect: nexthop =3D 192.168.1.2=20
>=20
>    traffic-action: T=3D0 S=3D0=20
>=20
>=20
> rule 3=20
>=20
>    traffic-rate: 30Mbps=20
>=20
>    traffic-marking: DSCP=3D30=20
>=20
>    redirect: nexthop =3D 192.168.2.2=20
>=20
>    traffic-action: T=3D1 S=3D1  =20
>                  =20
>=20
> rule 4=20
>=20
>    traffic-rate: 40Mbps=20
>=20
>    traffic-marking: DSCP=3D40=20
>=20
>    traffic-action: T=3D0 S=3D0=20
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

--=20
Christoph Loibl
c@tix.at <mailto:c@tix.at> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | =
http://www.nextlayer.at <http://www.nextlayer.at/>

--Apple-Mail=_B0A33760-352C-41EC-9FFD-72861888968F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Hi,<div class=3D""><br class=3D""></div><div class=3D"">Your =
example perfectly makes sense to me, and I understand that there are =
several sections in RFC5575 that are a little unclear. RFC5575 does not =
explain what should happen in your case, nor does it explain anything in =
case of action-interference.</div><div class=3D""><br =
class=3D""></div><div class=3D"">This is why we currently working on a =
rfc557bis that should help us to fix those problems and improve =
interoperability for flowspec. Have a look at:</div><div class=3D""><br =
class=3D""></div><div class=3D""><a =
href=3D"https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/" =
class=3D"">https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/</a></=
div><div class=3D"">Section&nbsp;<span style=3D"font-family: 'PT Mono', =
Monaco, monospace; font-size: 14px; orphans: 2; widows: 2; =
background-color: rgb(255, 253, 245);" class=3D"">7.6.  Rules on Traffic =
Action Interference</span><br style=3D"font-family: 'PT Mono', Monaco, =
monospace; font-size: 14px; orphans: 2; widows: 2;" class=3D""></div><div =
class=3D""><span style=3D"font-family: 'PT Mono', Monaco, monospace; =
font-size: 14px; orphans: 2; widows: 2; background-color: rgb(255, 253, =
245);" class=3D""><br class=3D""></span></div><div class=3D"">During =
writing this section we were actually discussing single flowspec NLRIs =
with conflicting actions like:</div><div class=3D""><br =
class=3D""></div><div class=3D"">rule 1</div><div class=3D"">&nbsp; =
&nbsp; traffic-rate: 10Mbps</div><div class=3D"">&nbsp; &nbsp; =
traffic-rate: 20Mbps</div><div class=3D""><br class=3D""></div><div =
class=3D"">or</div><div class=3D""><br class=3D""></div><div =
class=3D"">rule 1</div><div class=3D"">&nbsp; &nbsp;redirect: =
A</div><div class=3D"">&nbsp; &nbsp;redirect: B</div><div class=3D""><br =
class=3D""></div><div class=3D"">I think we shall extend this section to =
also explain your case. Currently this is not explained even in our =
submitted draft&nbsp;<a =
href=3D"https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/" =
class=3D"">draft-hr-idr-rfc5575bis</a>&nbsp;latest revision. In that =
case it may make sense to have a "latest" action wins behaviour. I =
suggest the following behaviour (this is nowhere written yet):</div><div =
class=3D""><br class=3D""></div><div class=3D"">Suggestion: In your =
example the action for a flow matching all your rules should be a merge =
of rule 1 and rule 2:</div><div class=3D""><br class=3D""></div><div =
class=3D""><blockquote type=3D"cite" class=3D""><font size=3D"2" =
face=3D"sans-serif" class=3D"">rule 1</font>&nbsp;<br class=3D""><br =
class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-rate: 10Mbps</font>&nbsp;<br class=3D""><br class=3D""><font=
 size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; &nbsp;traffic-marking: =
DSCP=3D10</font>&nbsp;<br class=3D""><br class=3D""><font size=3D"2" =
face=3D"sans-serif" class=3D"">&nbsp; &nbsp;traffic-action: T=3D1 =
S=3D1&nbsp;</font><br class=3D""><br class=3D""></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">after this rule 2 gets =
applied</div><br class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">rule =
2</font>&nbsp;<br class=3D""><br class=3D""><font size=3D"2" =
face=3D"sans-serif" class=3D"">&nbsp; &nbsp;traffic-rate: =
20Mbps</font>&nbsp;<br class=3D""><br class=3D""><font size=3D"2" =
face=3D"sans-serif" class=3D"">&nbsp; &nbsp;redirect: nexthop =3D =
192.168.1.2</font>&nbsp;<br class=3D""><br class=3D""><font size=3D"2" =
face=3D"sans-serif" class=3D"">&nbsp; &nbsp;traffic-action: T=3D0 =
S=3D0&nbsp;</font><br class=3D""><br class=3D""></blockquote></div><div =
class=3D""><br class=3D""></div><div class=3D"">The resulting action for =
that flow is:</div><div class=3D""><br class=3D""></div><div =
class=3D"">&nbsp; &nbsp; traffic-rate: 20Mbps</div><div class=3D"">&nbsp; =
&nbsp; traffic-marking: DSCP=3D10</div><div class=3D"">&nbsp; &nbsp; =
redirect: nexthop =3D 192.168.1.2</div><div class=3D""><br =
class=3D""></div><div class=3D"">Since on the second rule the =
terminal-bit is 0 there is no other rule to be evaluated.</div><div =
class=3D""><br class=3D""></div><div class=3D"">To the "latest" applied =
action wins. However this is only one suggested behaviour. There are =
plenty of other options. It should also be considered that implementing =
such a behaviour may not be trivial.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Christoph</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
14 Dec 2016, at 09:59, <a href=3D"mailto:zhang.zheng@zte.com.cn" =
class=3D"">zhang.zheng@zte.com.cn</a> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">Hi =
all,</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp; About RFC5575, it seems
like that the definition of "Terminal </font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">Action =
bit" is blurred. </font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp; In section 7, the "Terminal
Action bit" is defined as follows:</font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">Terminal =
Action (bit 47): When this
bit is set, the traffic filtering </font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">engine =
will apply any subsequent filtering
rules (as defined by the </font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">ordering =
procedure). &nbsp;If not set,
the evaluation of the traffic filter </font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">stops =
when this rule is applied.</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp; How can routers do when
many rules that define variant actions </font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">are =
applied to a same flow?</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;For example, there are
four rules that can be applied to one same flow. </font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">And the =
sequence has been determined
as below. When router executes rule 1,</font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">the =
"Terminal Action Bit"
is set. It indicated that next rule should be </font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">executed. =
When router execute rule 2,
which action should be executed? </font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">Only =
redirect? Or/and traffic-marking?
Which traffic-rate should be </font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" =
class=3D"">selected?</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">rule =
1</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-rate: 10Mbps</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-marking: DSCP=3D10</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-action: T=3D1 S=3D1
</font>
<br class=3D"">
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">rule =
2</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-rate: 20Mbps</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;redirect: nexthop =3D 192.168.1.2</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-action: T=3D0 S=3D0
</font>
<br class=3D"">
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">rule =
3</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-rate: 30Mbps</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-marking: DSCP=3D30</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;redirect: nexthop =3D 192.168.2.2</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-action: T=3D1 S=3D1
&nbsp;</font>
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">rule =
4</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-rate: 40Mbps</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-marking: DSCP=3D40</font>
<br class=3D"">
<br class=3D""><font size=3D"2" face=3D"sans-serif" class=3D"">&nbsp; =
&nbsp;traffic-action: T=3D0 S=3D0
</font>
<br class=3D"">
<br class=3D"">_______________________________________________<br =
class=3D"">Idr mailing list<br class=3D""><a href=3D"mailto:Idr@ietf.org" =
class=3D"">Idr@ietf.org</a><br =
class=3D"">https://www.ietf.org/mailman/listinfo/idr<br =
class=3D""></div></blockquote></div><br class=3D""><div class=3D"">
<div class=3D"">--&nbsp;<br class=3D"">Christoph Loibl<br class=3D""><a =
href=3D"mailto:c@tix.at" class=3D"">c@tix.at</a>&nbsp;| CL8-RIPE | =
PGP-Key-ID: 0x4B2C0055 |&nbsp;<a href=3D"http://www.nextlayer.at" =
class=3D"">http://www.nextlayer.at</a></div>

</div>
<br class=3D""></div></body></html>=

--Apple-Mail=_B0A33760-352C-41EC-9FFD-72861888968F--


From nobody Wed Dec 14 06:20:35 2016
Return-Path: <rjsparks@nostrum.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936471299E8; Wed, 14 Dec 2016 06:20:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level: 
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
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 KAzuSu8SXs7D; Wed, 14 Dec 2016 06:20:13 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 012711296D0; Wed, 14 Dec 2016 06:20:12 -0800 (PST)
Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBEEK811012009 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 14 Dec 2016 08:20:09 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, Job Snijders <job@ntt.net>
References: <07906876-6e21-2df9-c7a0-1270e76fea4e@nostrum.com> <20161212191159.GF75593@Vurt.local> <8dc27460-a500-3948-0a61-da4dd2baf66b@nostrum.com> <f4a5b4be6cb94663ae5c98b7780f122e@XCH-ALN-014.cisco.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <a3758712-fae6-9ca0-b6d8-a59e1b68181e@nostrum.com>
Date: Wed, 14 Dec 2016 08:20:10 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <f4a5b4be6cb94663ae5c98b7780f122e@XCH-ALN-014.cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nMY__YA15Gc7AbsLt9uvs6jYGBE>
Cc: "idr@ietf.org" <idr@ietf.org>, General Area Review Team <gen-art@ietf.org>, "draft-ietf-idr-large-community.all@ietf.org" <draft-ietf-idr-large-community.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [Idr] Genart LC review: draft-ietf-idr-large-community-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2016 14:20:14 -0000

On 12/12/16 2:32 PM, Jakob Heitz (jheitz) wrote:
>>> Jakob Heitz responded to the suggestion to extend the reserved Global
>>> Administrator values, but for some reason I can't find that email in the
>>> IETF IDR archive, I've copy+pasted it here:
>>>
>>> -------------
>>> 	Date: Mon, 05 Dec 2016 03:16:52 +0100
>>> 	From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
>>> 	To: David Freedman <david.freedman@uk.clara.net>
>>> 	Cc: "idr@ietf.org" <idr@ietf.org>
>>> 	Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt
>>>
>>>       No new text is required to cover this: 23456 is not an ASN.
>>>       Besides, if anyone were to put it into a large community, no harm
>>>       would be done other than what would happen if any other unassigned
>>>       ASN were used.
>>>
>>>       About reserving values, we don't reserve values because the values
>>>       are unusable, but because we may want to use them for other purposes
>>>       later. There is no need to reserve another value. 3 is more than
>>>       enough.
>>>
>>> 	Thanks,
>>> 	Jakob.
>>> --------------
>>>
>>    WFM, but please get your chairs to chase down why the message didn't
>> make it to the archive.
> It shows up in the other archive:
> https://www.ietf.org/mail-archive/web/idr/current/msg17255.html
There was an issue (for about 200 messages) in the indexing in the 
mailarchive tool that has been repaired.
This particular message is at
<https://mailarchive.ietf.org/arch/msg/idr/tg_gVjNwrFWklo4dTRUHo7Rkqos>

Thanks again for spotting the issue.
>
>
> Thanks,
> Jakob.


From nobody Thu Dec 15 01:34:06 2016
Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B393129B33 for <idr@ietfa.amsl.com>; Thu, 15 Dec 2016 01:34:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.096
X-Spam-Level: 
X-Spam-Status: No, score=-107.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no
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 XwQ9RMHmC9xm for <idr@ietfa.amsl.com>; Thu, 15 Dec 2016 01:34:01 -0800 (PST)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id C61F9129C58 for <idr@ietf.org>; Thu, 15 Dec 2016 01:34:00 -0800 (PST)
X-MAILFROM: <zhang.zheng@zte.com.cn>
X-RCPTTO: <idr@ietf.org>
X-FROMIP: 192.168.168.120
X-SEG-Scaned: 1
X-Received: unknown,192.168.168.120,20161215173242
Received: from unknown (HELO out1.zte.com.cn) (192.168.168.120) by localhost with SMTP; 15 Dec 2016 09:32:42 -0000
X-MAILFROM: <zhang.zheng@zte.com.cn>
X-RCPTTO: <robert@raszuk.net>
X-FROMIP: 10.30.3.20
X-SEG-Scaned: 1
X-Received: unknown,10.30.3.20,20161215172936
Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 15 Dec 2016 09:29:36 -0000
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uBF9Xj7b092636; Thu, 15 Dec 2016 17:33:45 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
In-Reply-To: <5DB3C819-FEAE-48A7-A755-E1683E410D16@tix.at>
To: Christoph Loibl <c@tix.at>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFD9436B83.1BA7CF11-ON4825808A.0032742A-4825808A.003488B4@zte.com.cn>
From: zhang.zheng@zte.com.cn
Date: Thu, 15 Dec 2016 17:34:21 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-12-15 17:33:45, Serialize complete at 2016-12-15 17:33:45
Content-Type: multipart/alternative; boundary="=_alternative 003488B24825808A_="
X-MAIL: mse01.zte.com.cn uBF9Xj7b092636
X-HQIP: 127.0.0.1
X-HQIP: 127.0.0.1
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/7nIR38yF5kVnjxQoZHP0JAc7m_E>
Cc: zhu.xiaolong@zte.com.cn, idr@ietf.org, robert@raszuk.net, shen.yiming@zte.com.cn, Idr <idr-bounces@ietf.org>, zhu.tong@zte.com.cn
Subject: Re: [Idr] One question about "Terminal Action bit" in RFC5575
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2016 09:34:05 -0000

This is a multipart message in MIME format.
--=_alternative 003488B24825808A_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGkgQ2hyaXN0b3BoLA0KDQogICAgVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXNwb25z
ZS4gR2xhZCB0byBoZWFyIHRoYXQgdGhlIFJGQyANCndpbGwgYmUgcmV2aXNlZCBDbGVhcmx5Lg0K
DQogICAgRnJvbSB5b3VyIHNwZWNpZmljYXRpb24sIEkgaGF2ZSB0d28gcXVlc3Rpb25zIGZvciBp
dDoNCg0KMSwgSWYgaXQgaXMgdmFsaWQgdGhhdCBkZWZpbmUgdGhlIHNhbWUgYWN0aW9uIHdpdGgg
ZGlmZmVyZW50IA0KdmFsdWVzIGluIG9uZSBzYW1lIHJ1bGU/DQoNCjIsIFdoYXShr3MgdGhlIGJl
bmVmaXQgb2YgIlRlcm1pbmFsIEFjdGlvbiBiaXQiPyBJIHRoaW5rIHRoYXQgeW91ciANCmFjdGlv
biBtZXJnaW5nIG1heSBiZSBvbmUgb2YgdGhlIHNvbHV0aW9ucy4gQnV0IHRoZSBuZXR3b3JrIG1h
bmFnZXIgDQpjYW5ub3QgZ2V0IHRoZSByZXN1bHQgZnJvbSB0aGUgc2FtZSBydWxlIGRpcmVjdGx5
LiBJdCBtYXkgY2F1c2UgdGhlIA0KY29uZnVzaW9uIG9mIG5ldHdvcmsgbWFuYWdlciwgaXNuJ3Qg
aXQ/DQoNClRoYW5rcywNClNhbmR5DQoNCkNocmlzdG9waCBMb2libCA8Y0B0aXguYXQ+INC009og
MjAxNi8xMi8xNCAxODo1ODo1MzoNCg0KPiBIaSwNCj4gDQo+IFlvdXIgZXhhbXBsZSBwZXJmZWN0
bHkgbWFrZXMgc2Vuc2UgdG8gbWUsIGFuZCBJIHVuZGVyc3RhbmQgdGhhdCANCj4gdGhlcmUgYXJl
IHNldmVyYWwgc2VjdGlvbnMgaW4gUkZDNTU3NSB0aGF0IGFyZSBhIGxpdHRsZSB1bmNsZWFyLiAN
Cj4gUkZDNTU3NSBkb2VzIG5vdCBleHBsYWluIHdoYXQgc2hvdWxkIGhhcHBlbiBpbiB5b3VyIGNh
c2UsIG5vciBkb2VzIA0KPiBpdCBleHBsYWluIGFueXRoaW5nIGluIGNhc2Ugb2YgYWN0aW9uLWlu
dGVyZmVyZW5jZS4NCj4gDQo+IFRoaXMgaXMgd2h5IHdlIGN1cnJlbnRseSB3b3JraW5nIG9uIGEg
cmZjNTU3YmlzIHRoYXQgc2hvdWxkIGhlbHAgdXMgDQo+IHRvIGZpeCB0aG9zZSBwcm9ibGVtcyBh
bmQgaW1wcm92ZSBpbnRlcm9wZXJhYmlsaXR5IGZvciBmbG93c3BlYy4gDQo+IEhhdmUgYSBsb29r
IGF0Og0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHItaWRy
LXJmYzU1NzViaXMvDQo+IFNlY3Rpb24gNy42LiBSdWxlcyBvbiBUcmFmZmljIEFjdGlvbiBJbnRl
cmZlcmVuY2UNCj4gDQo+IER1cmluZyB3cml0aW5nIHRoaXMgc2VjdGlvbiB3ZSB3ZXJlIGFjdHVh
bGx5IGRpc2N1c3Npbmcgc2luZ2xlIA0KPiBmbG93c3BlYyBOTFJJcyB3aXRoIGNvbmZsaWN0aW5n
IGFjdGlvbnMgbGlrZToNCj4gDQo+IHJ1bGUgMQ0KPiAgICAgdHJhZmZpYy1yYXRlOiAxME1icHMN
Cj4gICAgIHRyYWZmaWMtcmF0ZTogMjBNYnBzDQo+IA0KPiBvcg0KPiANCj4gcnVsZSAxDQo+ICAg
IHJlZGlyZWN0OiBBDQo+ICAgIHJlZGlyZWN0OiBCDQo+IA0KPiBJIHRoaW5rIHdlIHNoYWxsIGV4
dGVuZCB0aGlzIHNlY3Rpb24gdG8gYWxzbyBleHBsYWluIHlvdXIgY2FzZS4gDQo+IEN1cnJlbnRs
eSB0aGlzIGlzIG5vdCBleHBsYWluZWQgZXZlbiBpbiBvdXIgc3VibWl0dGVkIGRyYWZ0IGRyYWZ0
LQ0KPiBoci1pZHItcmZjNTU3NWJpcyBsYXRlc3QgcmV2aXNpb24uIEluIHRoYXQgY2FzZSBpdCBt
YXkgbWFrZSBzZW5zZSB0bw0KPiBoYXZlIGEgImxhdGVzdCIgYWN0aW9uIHdpbnMgYmVoYXZpb3Vy
LiBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyANCj4gYmVoYXZpb3VyICh0aGlzIGlzIG5vd2hlcmUg
d3JpdHRlbiB5ZXQpOg0KPiANCj4gU3VnZ2VzdGlvbjogSW4geW91ciBleGFtcGxlIHRoZSBhY3Rp
b24gZm9yIGEgZmxvdyBtYXRjaGluZyBhbGwgeW91ciANCj4gcnVsZXMgc2hvdWxkIGJlIGEgbWVy
Z2Ugb2YgcnVsZSAxIGFuZCBydWxlIDI6DQo+IA0KPiBydWxlIDEgDQo+IA0KPiAgICB0cmFmZmlj
LXJhdGU6IDEwTWJwcyANCj4gDQo+ICAgIHRyYWZmaWMtbWFya2luZzogRFNDUD0xMCANCj4gDQo+
ICAgIHRyYWZmaWMtYWN0aW9uOiBUPTEgUz0xIA0KDQo+IA0KPiBhZnRlciB0aGlzIHJ1bGUgMiBn
ZXRzIGFwcGxpZWQNCj4gDQo+IA0KPiBydWxlIDIgDQo+IA0KPiAgICB0cmFmZmljLXJhdGU6IDIw
TWJwcyANCj4gDQo+ICAgIHJlZGlyZWN0OiBuZXh0aG9wID0gMTkyLjE2OC4xLjIgDQo+IA0KPiAg
ICB0cmFmZmljLWFjdGlvbjogVD0wIFM9MCANCg0KPiANCj4gVGhlIHJlc3VsdGluZyBhY3Rpb24g
Zm9yIHRoYXQgZmxvdyBpczoNCj4gDQo+ICAgICB0cmFmZmljLXJhdGU6IDIwTWJwcw0KPiAgICAg
dHJhZmZpYy1tYXJraW5nOiBEU0NQPTEwDQo+ICAgICByZWRpcmVjdDogbmV4dGhvcCA9IDE5Mi4x
NjguMS4yDQo+IA0KPiBTaW5jZSBvbiB0aGUgc2Vjb25kIHJ1bGUgdGhlIHRlcm1pbmFsLWJpdCBp
cyAwIHRoZXJlIGlzIG5vIG90aGVyIA0KPiBydWxlIHRvIGJlIGV2YWx1YXRlZC4NCj4gDQo+IFRv
IHRoZSAibGF0ZXN0IiBhcHBsaWVkIGFjdGlvbiB3aW5zLiBIb3dldmVyIHRoaXMgaXMgb25seSBv
bmUgDQo+IHN1Z2dlc3RlZCBiZWhhdmlvdXIuIFRoZXJlIGFyZSBwbGVudHkgb2Ygb3RoZXIgb3B0
aW9ucy4gSXQgc2hvdWxkIA0KPiBhbHNvIGJlIGNvbnNpZGVyZWQgdGhhdCBpbXBsZW1lbnRpbmcg
c3VjaCBhIGJlaGF2aW91ciBtYXkgbm90IGJlIA0KdHJpdmlhbC4NCj4gDQo+IENocmlzdG9waA0K
PiANCj4gT24gMTQgRGVjIDIwMTYsIGF0IDA5OjU5LCB6aGFuZy56aGVuZ0B6dGUuY29tLmNuIHdy
b3RlOg0KPiANCj4gDQo+IEhpIGFsbCwgDQo+IA0KPiAgICAgQWJvdXQgUkZDNTU3NSwgaXQgc2Vl
bXMgbGlrZSB0aGF0IHRoZSBkZWZpbml0aW9uIG9mICJUZXJtaW5hbCANCj4gQWN0aW9uIGJpdCIg
aXMgYmx1cnJlZC4gDQo+IA0KPiAgICAgSW4gc2VjdGlvbiA3LCB0aGUgIlRlcm1pbmFsIEFjdGlv
biBiaXQiIGlzIGRlZmluZWQgYXMgZm9sbG93czogDQo+IFRlcm1pbmFsIEFjdGlvbiAoYml0IDQ3
KTogV2hlbiB0aGlzIGJpdCBpcyBzZXQsIHRoZSB0cmFmZmljIGZpbHRlcmluZyANCj4gZW5naW5l
IHdpbGwgYXBwbHkgYW55IHN1YnNlcXVlbnQgZmlsdGVyaW5nIHJ1bGVzIChhcyBkZWZpbmVkIGJ5
IHRoZSANCj4gb3JkZXJpbmcgcHJvY2VkdXJlKS4gIElmIG5vdCBzZXQsIHRoZSBldmFsdWF0aW9u
IG9mIHRoZSB0cmFmZmljIGZpbHRlciANCj4gc3RvcHMgd2hlbiB0aGlzIHJ1bGUgaXMgYXBwbGll
ZC4gDQo+IA0KPiAgICAgSG93IGNhbiByb3V0ZXJzIGRvIHdoZW4gbWFueSBydWxlcyB0aGF0IGRl
ZmluZSB2YXJpYW50IGFjdGlvbnMgDQo+IGFyZSBhcHBsaWVkIHRvIGEgc2FtZSBmbG93PyANCj4g
DQo+ICAgIEZvciBleGFtcGxlLCB0aGVyZSBhcmUgZm91ciBydWxlcyB0aGF0IGNhbiBiZSBhcHBs
aWVkIHRvIG9uZSBzYW1lIA0KZmxvdy4gDQo+IEFuZCB0aGUgc2VxdWVuY2UgaGFzIGJlZW4gZGV0
ZXJtaW5lZCBhcyBiZWxvdy4gV2hlbiByb3V0ZXIgZXhlY3V0ZXMgcnVsZSANCjEsIA0KPiB0aGUg
IlRlcm1pbmFsIEFjdGlvbiBCaXQiIGlzIHNldC4gSXQgaW5kaWNhdGVkIHRoYXQgbmV4dCBydWxl
IHNob3VsZCBiZSANCj4gZXhlY3V0ZWQuIFdoZW4gcm91dGVyIGV4ZWN1dGUgcnVsZSAyLCB3aGlj
aCBhY3Rpb24gc2hvdWxkIGJlIGV4ZWN1dGVkPyANCj4gT25seSByZWRpcmVjdD8gT3IvYW5kIHRy
YWZmaWMtbWFya2luZz8gV2hpY2ggdHJhZmZpYy1yYXRlIHNob3VsZCBiZSANCj4gc2VsZWN0ZWQ/
IA0KPiANCj4gcnVsZSAxIA0KPiANCj4gICAgdHJhZmZpYy1yYXRlOiAxME1icHMgDQo+IA0KPiAg
ICB0cmFmZmljLW1hcmtpbmc6IERTQ1A9MTAgDQo+IA0KPiAgICB0cmFmZmljLWFjdGlvbjogVD0x
IFM9MSANCj4gDQo+IA0KPiBydWxlIDIgDQo+IA0KPiAgICB0cmFmZmljLXJhdGU6IDIwTWJwcyAN
Cj4gDQo+ICAgIHJlZGlyZWN0OiBuZXh0aG9wID0gMTkyLjE2OC4xLjIgDQo+IA0KPiAgICB0cmFm
ZmljLWFjdGlvbjogVD0wIFM9MCANCj4gDQo+IA0KPiBydWxlIDMgDQo+IA0KPiAgICB0cmFmZmlj
LXJhdGU6IDMwTWJwcyANCj4gDQo+ICAgIHRyYWZmaWMtbWFya2luZzogRFNDUD0zMCANCj4gDQo+
ICAgIHJlZGlyZWN0OiBuZXh0aG9wID0gMTkyLjE2OC4yLjIgDQo+IA0KPiAgICB0cmFmZmljLWFj
dGlvbjogVD0xIFM9MSANCj4gDQo+IA0KPiBydWxlIDQgDQo+IA0KPiAgICB0cmFmZmljLXJhdGU6
IDQwTWJwcyANCj4gDQo+ICAgIHRyYWZmaWMtbWFya2luZzogRFNDUD00MCANCj4gDQo+ICAgIHRy
YWZmaWMtYWN0aW9uOiBUPTAgUz0wIA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gSWRyIG1haWxpbmcgbGlzdA0KPiBJZHJAaWV0Zi5vcmcN
Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCj4gDQo+IC0tIA0K
PiBDaHJpc3RvcGggTG9pYmwNCj4gY0B0aXguYXQgfCBDTDgtUklQRSB8IFBHUC1LZXktSUQ6IDB4
NEIyQzAwNTUgfCBodHRwOi8vd3d3Lm5leHRsYXllci5hdA0K
--=_alternative 003488B24825808A_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIDwvZm9udD48Zm9udCBzaXpl
PTI+PHR0PkNocmlzdG9waDwvdHQ+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij4sPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz
cDsgJm5ic3A7IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yDQp5b3VyIHJlc3BvbnNlLiBHbGFkIHRv
IGhlYXIgdGhhdCB0aGUgUkZDIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z
ZXJpZiI+d2lsbCBiZSByZXZpc2VkIENsZWFybHkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp
emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IEZyb20geW91ciBzcGVjaWZpY2F0
aW9uLA0KSSBoYXZlIHR3byBxdWVzdGlvbnMgZm9yIGl0OjwvZm9udD4NCjxicj4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MSwgSWYgaXQgaXMgdmFsaWQgdGhhdCBkZWZpbmUg
dGhlIHNhbWUNCmFjdGlvbiB3aXRoIGRpZmZlcmVudCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9InNhbnMtc2VyaWYiPnZhbHVlcyBpbiBvbmUgc2FtZSBydWxlPzwvZm9udD4NCjxicj4N
Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MiwgV2hhdKGvcyB0aGUgYmVuZWZp
dCBvZiAmcXVvdDtUZXJtaW5hbA0KQWN0aW9uIGJpdCZxdW90Oz8gSSB0aGluayB0aGF0IHlvdXIg
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hY3Rpb24gbWVyZ2lu
ZyBtYXkgYmUgb25lIG9mIHRoZSBzb2x1dGlvbnMuDQpCdXQgdGhlIG5ldHdvcmsgbWFuYWdlciA8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmNhbm5vdCBnZXQgdGhl
IHJlc3VsdCBmcm9tIHRoZSBzYW1lDQpydWxlIGRpcmVjdGx5LiBJdCBtYXkgY2F1c2UgdGhlIDwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Y29uZnVzaW9uIG9mIG5l
dHdvcmsgbWFuYWdlciwgaXNuJ3QNCml0PzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i
c2Fucy1zZXJpZiI+U2FuZHk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5DaHJp
c3RvcGggTG9pYmwgJmx0O2NAdGl4LmF0Jmd0OyDQtNPaIDIwMTYvMTIvMTQNCjE4OjU4OjUzOjxi
cj4NCjxicj4NCiZndDsgSGksPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7
IDxicj4NCiZndDsgWW91ciBleGFtcGxlIHBlcmZlY3RseSBtYWtlcyBzZW5zZSB0byBtZSwgYW5k
IEkgdW5kZXJzdGFuZCB0aGF0IDxicj4NCiZndDsgdGhlcmUgYXJlIHNldmVyYWwgc2VjdGlvbnMg
aW4gUkZDNTU3NSB0aGF0IGFyZSBhIGxpdHRsZSB1bmNsZWFyLiA8YnI+DQomZ3Q7IFJGQzU1NzUg
ZG9lcyBub3QgZXhwbGFpbiB3aGF0IHNob3VsZCBoYXBwZW4gaW4geW91ciBjYXNlLCBub3IgZG9l
cw0KPGJyPg0KJmd0OyBpdCBleHBsYWluIGFueXRoaW5nIGluIGNhc2Ugb2YgYWN0aW9uLWludGVy
ZmVyZW5jZS48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0
OyBUaGlzIGlzIHdoeSB3ZSBjdXJyZW50bHkgd29ya2luZyBvbiBhIHJmYzU1N2JpcyB0aGF0IHNo
b3VsZCBoZWxwIHVzDQo8YnI+DQomZ3Q7IHRvIGZpeCB0aG9zZSBwcm9ibGVtcyBhbmQgaW1wcm92
ZSBpbnRlcm9wZXJhYmlsaXR5IGZvciBmbG93c3BlYy4gPGJyPg0KJmd0OyBIYXZlIGEgbG9vayBh
dDo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oci1pZHItcmZjNTU3NWJpcy88L3R0
PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgU2VjdGlvbiA3LjYuIFJ1bGVzIG9u
IFRyYWZmaWMgQWN0aW9uIEludGVyZmVyZW5jZTwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9
Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7IER1cmluZyB3cml0aW5nIHRoaXMgc2VjdGlvbiB3ZSB3ZXJl
IGFjdHVhbGx5IGRpc2N1c3Npbmcgc2luZ2xlIDxicj4NCiZndDsgZmxvd3NwZWMgTkxSSXMgd2l0
aCBjb25mbGljdGluZyBhY3Rpb25zIGxpa2U6PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
Pjx0dD4mZ3Q7IDxicj4NCiZndDsgcnVsZSAxPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
Pjx0dD4mZ3Q7ICZuYnNwOyAmbmJzcDsgdHJhZmZpYy1yYXRlOiAxME1icHM8L3R0PjwvZm9udD4N
Cjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNwOyB0cmFmZmljLXJhdGU6IDIw
TWJwczwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7IG9y
PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgcnVsZSAx
PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOyAmbmJzcDtyZWRp
cmVjdDogQTwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDsgJm5i
c3A7cmVkaXJlY3Q6IEI8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJy
Pg0KJmd0OyBJIHRoaW5rIHdlIHNoYWxsIGV4dGVuZCB0aGlzIHNlY3Rpb24gdG8gYWxzbyBleHBs
YWluIHlvdXIgY2FzZS4gPGJyPg0KJmd0OyBDdXJyZW50bHkgdGhpcyBpcyBub3QgZXhwbGFpbmVk
IGV2ZW4gaW4gb3VyIHN1Ym1pdHRlZCBkcmFmdCBkcmFmdC08YnI+DQomZ3Q7IGhyLWlkci1yZmM1
NTc1YmlzIGxhdGVzdCByZXZpc2lvbi4gSW4gdGhhdCBjYXNlIGl0IG1heSBtYWtlIHNlbnNlDQp0
bzxicj4NCiZndDsgaGF2ZSBhICZxdW90O2xhdGVzdCZxdW90OyBhY3Rpb24gd2lucyBiZWhhdmlv
dXIuIEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nDQo8YnI+DQomZ3Q7IGJlaGF2aW91ciAodGhpcyBp
cyBub3doZXJlIHdyaXR0ZW4geWV0KTo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0
PiZndDsgPGJyPg0KJmd0OyBTdWdnZXN0aW9uOiBJbiB5b3VyIGV4YW1wbGUgdGhlIGFjdGlvbiBm
b3IgYSBmbG93IG1hdGNoaW5nIGFsbCB5b3VyDQo8YnI+DQomZ3Q7IHJ1bGVzIHNob3VsZCBiZSBh
IG1lcmdlIG9mIHJ1bGUgMSBhbmQgcnVsZSAyOjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9
Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7IHJ1bGUgMSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7
ICZuYnNwO3RyYWZmaWMtcmF0ZTogMTBNYnBzIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsg
Jm5ic3A7dHJhZmZpYy1tYXJraW5nOiBEU0NQPTEwIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJz
cDsgJm5ic3A7dHJhZmZpYy1hY3Rpb246IFQ9MSBTPTEgPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+
PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgYWZ0ZXIgdGhpcyBydWxlIDIgZ2V0cyBh
cHBsaWVkPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsg
PGJyPg0KJmd0OyBydWxlIDIgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt0cmFm
ZmljLXJhdGU6IDIwTWJwcyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3JlZGly
ZWN0OiBuZXh0aG9wID0gMTkyLjE2OC4xLjIgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAm
bmJzcDt0cmFmZmljLWFjdGlvbjogVD0wIFM9MCA8YnI+DQo8L3R0PjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBUaGUgcmVzdWx0aW5nIGFjdGlvbiBmb3IgdGhh
dCBmbG93IGlzOjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQom
Z3Q7ICZuYnNwOyAmbmJzcDsgdHJhZmZpYy1yYXRlOiAyME1icHM8L3R0PjwvZm9udD4NCjxicj48
Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNwOyB0cmFmZmljLW1hcmtpbmc6IERTQ1A9
MTA8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNwOyBy
ZWRpcmVjdDogbmV4dGhvcCA9IDE5Mi4xNjguMS4yPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6
ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgU2luY2Ugb24gdGhlIHNlY29uZCBydWxlIHRoZSB0ZXJt
aW5hbC1iaXQgaXMgMCB0aGVyZSBpcyBubyBvdGhlciA8YnI+DQomZ3Q7IHJ1bGUgdG8gYmUgZXZh
bHVhdGVkLjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7
IFRvIHRoZSAmcXVvdDtsYXRlc3QmcXVvdDsgYXBwbGllZCBhY3Rpb24gd2lucy4gSG93ZXZlciB0
aGlzIGlzIG9ubHkNCm9uZSA8YnI+DQomZ3Q7IHN1Z2dlc3RlZCBiZWhhdmlvdXIuIFRoZXJlIGFy
ZSBwbGVudHkgb2Ygb3RoZXIgb3B0aW9ucy4gSXQgc2hvdWxkDQo8YnI+DQomZ3Q7IGFsc28gYmUg
Y29uc2lkZXJlZCB0aGF0IGltcGxlbWVudGluZyBzdWNoIGEgYmVoYXZpb3VyIG1heSBub3QgYmUg
dHJpdmlhbC48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0
OyBDaHJpc3RvcGg8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0K
Jmd0OyBPbiAxNCBEZWMgMjAxNiwgYXQgMDk6NTksIHpoYW5nLnpoZW5nQHp0ZS5jb20uY24gd3Jv
dGU6PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgPGJy
Pg0KJmd0OyBIaSBhbGwsIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEFib3V0
IFJGQzU1NzUsIGl0IHNlZW1zIGxpa2UgdGhhdCB0aGUgZGVmaW5pdGlvbiBvZg0KJnF1b3Q7VGVy
bWluYWwgPGJyPg0KJmd0OyBBY3Rpb24gYml0JnF1b3Q7IGlzIGJsdXJyZWQuIDxicj4NCiZndDsg
PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEluIHNlY3Rpb24gNywgdGhlICZxdW90O1Rlcm1pbmFs
IEFjdGlvbiBiaXQmcXVvdDsgaXMNCmRlZmluZWQgYXMgZm9sbG93czogPGJyPg0KJmd0OyBUZXJt
aW5hbCBBY3Rpb24gKGJpdCA0Nyk6IFdoZW4gdGhpcyBiaXQgaXMgc2V0LCB0aGUgdHJhZmZpYyBm
aWx0ZXJpbmcNCjxicj4NCiZndDsgZW5naW5lIHdpbGwgYXBwbHkgYW55IHN1YnNlcXVlbnQgZmls
dGVyaW5nIHJ1bGVzIChhcyBkZWZpbmVkIGJ5IHRoZQ0KPGJyPg0KJmd0OyBvcmRlcmluZyBwcm9j
ZWR1cmUpLiAmbmJzcDtJZiBub3Qgc2V0LCB0aGUgZXZhbHVhdGlvbiBvZiB0aGUgdHJhZmZpYw0K
ZmlsdGVyIDxicj4NCiZndDsgc3RvcHMgd2hlbiB0aGlzIHJ1bGUgaXMgYXBwbGllZC4gPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgSG93IGNhbiByb3V0ZXJzIGRvIHdoZW4gbWFu
eSBydWxlcyB0aGF0IGRlZmluZSB2YXJpYW50DQphY3Rpb25zIDxicj4NCiZndDsgYXJlIGFwcGxp
ZWQgdG8gYSBzYW1lIGZsb3c/IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Rm9y
IGV4YW1wbGUsIHRoZXJlIGFyZSBmb3VyIHJ1bGVzIHRoYXQgY2FuIGJlIGFwcGxpZWQNCnRvIG9u
ZSBzYW1lIGZsb3cuIDxicj4NCiZndDsgQW5kIHRoZSBzZXF1ZW5jZSBoYXMgYmVlbiBkZXRlcm1p
bmVkIGFzIGJlbG93LiBXaGVuIHJvdXRlciBleGVjdXRlcw0KcnVsZSAxLCA8YnI+DQomZ3Q7IHRo
ZSAmcXVvdDtUZXJtaW5hbCBBY3Rpb24gQml0JnF1b3Q7IGlzIHNldC4gSXQgaW5kaWNhdGVkIHRo
YXQgbmV4dA0KcnVsZSBzaG91bGQgYmUgPGJyPg0KJmd0OyBleGVjdXRlZC4gV2hlbiByb3V0ZXIg
ZXhlY3V0ZSBydWxlIDIsIHdoaWNoIGFjdGlvbiBzaG91bGQgYmUgZXhlY3V0ZWQ/DQo8YnI+DQom
Z3Q7IE9ubHkgcmVkaXJlY3Q/IE9yL2FuZCB0cmFmZmljLW1hcmtpbmc/IFdoaWNoIHRyYWZmaWMt
cmF0ZSBzaG91bGQgYmUNCjxicj4NCiZndDsgc2VsZWN0ZWQ/IDxicj4NCiZndDsgPGJyPg0KJmd0
OyBydWxlIDEgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt0cmFmZmljLXJhdGU6
IDEwTWJwcyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtbWFya2lu
ZzogRFNDUD0xMCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtYWN0
aW9uOiBUPTEgUz0xIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHJ1bGUgMiA8YnI+
DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtcmF0ZTogMjBNYnBzIDxicj4N
CiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7cmVkaXJlY3Q6IG5leHRob3AgPSAxOTIuMTY4
LjEuMiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtYWN0aW9uOiBU
PTAgUz0wIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHJ1bGUgMyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtcmF0ZTogMzBNYnBzIDxicj4NCiZndDsg
PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dHJhZmZpYy1tYXJraW5nOiBEU0NQPTMwIDxicj4NCiZn
dDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7cmVkaXJlY3Q6IG5leHRob3AgPSAxOTIuMTY4LjIu
MiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtYWN0aW9uOiBUPTEg
Uz0xICZuYnNwOyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBydWxlIDQg
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt0cmFmZmljLXJhdGU6IDQwTWJwcyA8
YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtbWFya2luZzogRFNDUD00
MCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtYWN0aW9uOiBUPTAg
Uz0wIDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCiZndDsgSWRyIG1haWxpbmcgbGlzdDxicj4NCiZndDsgSWRy
QGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2lkcjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7IC0t
IDxicj4NCiZndDsgQ2hyaXN0b3BoIExvaWJsPGJyPg0KJmd0OyBjQHRpeC5hdCB8IENMOC1SSVBF
IHwgUEdQLUtleS1JRDogMHg0QjJDMDA1NSB8IGh0dHA6Ly93d3cubmV4dGxheWVyLmF0PC90dD48
L2ZvbnQ+DQo=
--=_alternative 003488B24825808A_=--



From nobody Thu Dec 15 07:57:06 2016
Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0751296CD; Thu, 15 Dec 2016 07:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RMeAxkffTngM; Thu, 15 Dec 2016 07:57:00 -0800 (PST)
Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 D08DB1296D5; Thu, 15 Dec 2016 07:56:59 -0800 (PST)
Received: by mail-qk0-x242.google.com with SMTP id t184so121409qkd.1; Thu, 15 Dec 2016 07:56:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OM0jTW6xo6/kztpqQa+xW9GSeqCMXiC84wV9Cz0b/yw=; b=HMwFvDO+WxAaTlw8oee4PaScaNS/RbC4f5KRL61Vm7G1bgtgLGJ8tBfJdHOPnAqTvC dI5WJgc9gj61+S/T0dLRsaq9mMlsWnfPT/oU2oEDeXfjQeI/B4I166DWVj7bw5pNtUr9 pLGNoMS2ZLD1viQlH61AP6FusC+DyZOdEkFD6/HYXiMF5N7RmVmyj/QXg56XWX99B4hM uq1GtOlxbKzlgkSjmCTbgorNyXCHMaCn7JX3oG84CgYZmP2iUf3qIZAM4wBoouEhX18x KLAH4vpJEHzrOfgjHAVzcUMOrxPN0SZ3PhKR0UjFKgFkq/B4k1CEcuHahMDHk5KtPsGI 7JmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OM0jTW6xo6/kztpqQa+xW9GSeqCMXiC84wV9Cz0b/yw=; b=dENagqF3plpbiRP5yr2FLwHqbh97UyLgjQSyzBp4Dc5h/+Q1y81jM4Am6gcivgwkzz i3ZPw76MTOxptO6sU8Q8LBfbSA0qLalmD0EgKrH1uJgDyREPtXK5S16tD0I7bxAlIOVg 4pj9AWXE5cLXglk9CV7G0CHCid/3U8U/hUQfXa0C0esCbEh43qMtXwC/yr25sCwKLgid ZXjI7S35jK6rU466s7d2Oh5OGer5lp6w1kMafy0i9TPs3vELaxMqnNjzmccl1Gia/ApW 6MhPXgO2GUq1Xr3F0KuQ9fVwUpqgLgh34FTf74R64sFTRYTURl4ucmS0Nuy0vgKAxVKl cJqQ==
X-Gm-Message-State: AIkVDXJiu09J8U5gpD3XG+3w47nd47kg3slwT/krDvXaaj0FyMgPzoctyMfHvElgxKaVq7JDcLWReahE/4Zw+Q==
X-Received: by 10.55.156.81 with SMTP id f78mr1810108qke.123.1481817418990; Thu, 15 Dec 2016 07:56:58 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.16.50 with HTTP; Thu, 15 Dec 2016 07:56:58 -0800 (PST)
In-Reply-To: <OFD9436B83.1BA7CF11-ON4825808A.0032742A-4825808A.003488B4@zte.com.cn>
References: <5DB3C819-FEAE-48A7-A755-E1683E410D16@tix.at> <OFD9436B83.1BA7CF11-ON4825808A.0032742A-4825808A.003488B4@zte.com.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 15 Dec 2016 16:56:58 +0100
X-Google-Sender-Auth: J7XLPDV3YdLhjagcScWfIKIeyGY
Message-ID: <CA+b+ERk8Jb6m_m9E5KfVS24Y8vYcP1foOHh6Nv_2Zzkx7OYvqQ@mail.gmail.com>
To: "zhang.zheng" <zhang.zheng@zte.com.cn>
Content-Type: multipart/alternative; boundary=94eb2c075ab4e187d50543b4800f
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/HJhymtLu9DtPsUdTdCRQDIB3FH0>
Cc: zhu.xiaolong@zte.com.cn, idr wg <idr@ietf.org>, shen.yiming@zte.com.cn, Idr <idr-bounces@ietf.org>, zhu.tong@zte.com.cn
Subject: Re: [Idr] One question about "Terminal Action bit" in RFC5575
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2016 15:57:04 -0000

--94eb2c075ab4e187d50543b4800f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Sandy,

=E2=80=8B=E2=80=8B>
2, What=E2=80=99s the benefit of "Terminal Action bit"?

The meaning of this flag was to indicate requirement analogy of "continue"
statement when executing your traffic filtering actions on the matched
traffic. Example - you may want to redirect to a vrf with or without
remarking the traffic with different. Not really much more to it.

Best regards,
R.





On Thu, Dec 15, 2016 at 10:34 AM, <zhang.zheng@zte.com.cn> wrote:

>
> Hi Christoph,
>
>     Thank you very much for your response. Glad to hear that the RFC
> will be revised Clearly.
>
>     From your specification, I have two questions for it:
>
> 1, If it is valid that define the same action with different
> values in one same rule?
>
> =E2=80=8B=E2=80=8B
> 2, What=E2=80=99s the benefit of "Terminal Action bit"? I think that your
> action merging may be one of the solutions. But the network manager
> cannot get the result from the same rule directly. It may cause the
> confusion of network manager, isn't it?
>
> Thanks,
> Sandy
>
> Christoph Loibl <c@tix.at> =E5=86=99=E4=BA=8E 2016/12/14 18:58:53:
>
> > Hi,
> >
> > Your example perfectly makes sense to me, and I understand that
> > there are several sections in RFC5575 that are a little unclear.
> > RFC5575 does not explain what should happen in your case, nor does
> > it explain anything in case of action-interference.
> >
> > This is why we currently working on a rfc557bis that should help us
> > to fix those problems and improve interoperability for flowspec.
> > Have a look at:
> >
> > https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/
> > Section 7.6. Rules on Traffic Action Interference
> >
> > During writing this section we were actually discussing single
> > flowspec NLRIs with conflicting actions like:
> >
> > rule 1
> >     traffic-rate: 10Mbps
> >     traffic-rate: 20Mbps
> >
> > or
> >
> > rule 1
> >    redirect: A
> >    redirect: B
> >
> > I think we shall extend this section to also explain your case.
> > Currently this is not explained even in our submitted draft draft-
> > hr-idr-rfc5575bis latest revision. In that case it may make sense to
>
> > have a "latest" action wins behaviour. I suggest the following
> > behaviour (this is nowhere written yet):
>
> >
> > Suggestion: In your example the action for a flow matching all your
> > rules should be a merge of rule 1 and rule 2:
> >
> > rule 1
> >
> >    traffic-rate: 10Mbps
> >
> >    traffic-marking: DSCP=3D10
> >
> >    traffic-action: T=3D1 S=3D1
>
> >
> > after this rule 2 gets applied
> >
> >
> > rule 2
> >
> >    traffic-rate: 20Mbps
> >
> >    redirect: nexthop =3D 192.168.1.2
> >
> >    traffic-action: T=3D0 S=3D0
>
> >
> > The resulting action for that flow is:
> >
> >     traffic-rate: 20Mbps
> >     traffic-marking: DSCP=3D10
> >     redirect: nexthop =3D 192.168.1.2
> >
> > Since on the second rule the terminal-bit is 0 there is no other
> > rule to be evaluated.
> >
> > To the "latest" applied action wins. However this is only one
> > suggested behaviour. There are plenty of other options. It should
> > also be considered that implementing such a behaviour may not be trivia=
l.
> >
> > Christoph
> >
> > On 14 Dec 2016, at 09:59, zhang.zheng@zte.com.cn wrote:
> >
> >
> > Hi all,
> >
> >     About RFC5575, it seems like that the definition of "Terminal
> > Action bit" is blurred.
> >
> >     In section 7, the "Terminal Action bit" is defined as follows:
> > Terminal Action (bit 47): When this bit is set, the traffic filtering
> > engine will apply any subsequent filtering rules (as defined by the
> > ordering procedure).  If not set, the evaluation of the traffic filter
> > stops when this rule is applied.
> >
> >     How can routers do when many rules that define variant actions
> > are applied to a same flow?
> >
> >    For example, there are four rules that can be applied to one same
> flow.
> > And the sequence has been determined as below. When router executes rul=
e
> 1,
> > the "Terminal Action Bit" is set. It indicated that next rule should be
> > executed. When router execute rule 2, which action should be executed?
> > Only redirect? Or/and traffic-marking? Which traffic-rate should be
> > selected?
> >
> > rule 1
> >
> >    traffic-rate: 10Mbps
> >
> >    traffic-marking: DSCP=3D10
> >
> >    traffic-action: T=3D1 S=3D1
> >
> >
> > rule 2
> >
> >    traffic-rate: 20Mbps
> >
> >    redirect: nexthop =3D 192.168.1.2
> >
> >    traffic-action: T=3D0 S=3D0
> >
> >
> > rule 3
> >
> >    traffic-rate: 30Mbps
> >
> >    traffic-marking: DSCP=3D30
> >
> >    redirect: nexthop =3D 192.168.2.2
> >
> >    traffic-action: T=3D1 S=3D1
> >
> >
> > rule 4
> >
> >    traffic-rate: 40Mbps
> >
> >    traffic-marking: DSCP=3D40
> >
> >    traffic-action: T=3D0 S=3D0
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >
> > --
> > Christoph Loibl
> > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at
>

--94eb2c075ab4e187d50543b4800f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small">Hi Sandy,</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small"><div class=3D"gmail_default" style=3D"display:inlin=
e">=E2=80=8B=E2=80=8B&gt;=C2=A0</div><span style=3D"font-family:sans-serif"=
>2, What=E2=80=99s the benefit of &quot;Terminal Action bit&quot;?</span><b=
r></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small"><span style=3D"font-family:sans-serif"><br></spa=
n></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small"><span style=3D"font-family:sans-serif">The meani=
ng of this flag was to indicate requirement analogy of &quot;continue&quot;=
 statement when executing your traffic filtering actions on the matched tra=
ffic. Example - you may want to redirect to a vrf with or without remarking=
 the traffic with different. Not really much more to it.</span></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small"><span style=3D"font-family:sans-serif"><br></span></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small"><span style=3D"font-family:sans-serif">Best regards,</span></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small"><span style=3D"font-family:sans-serif">R.=C2=A0</span=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small"><span style=3D"font-family:sans-serif"><br></span=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small"><span style=3D"font-family:sans-serif"><br></span=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small"><span style=3D"font-family:sans-serif"><br></span=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small"><span style=3D"font-family:sans-serif"><br></span=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, De=
c 15, 2016 at 10:34 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:zhang.zhen=
g@zte.com.cn" target=3D"_blank">zhang.zheng@zte.com.cn</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><font size=3D"2" face=3D"sans-serif">Hi </font><font size=3D"2"><tt>Chr=
istoph</tt></font><font size=3D"2" face=3D"sans-serif">,</font>
<br>
<br><font size=3D"2" face=3D"sans-serif">=C2=A0 =C2=A0 Thank you very much =
for
your response. Glad to hear that the RFC </font>
<br><font size=3D"2" face=3D"sans-serif">will be revised Clearly.</font>
<br>
<br><font size=3D"2" face=3D"sans-serif">=C2=A0 =C2=A0 From your specificat=
ion,
I have two questions for it:</font>
<br>
<br><font size=3D"2" face=3D"sans-serif">1, If it is valid that define the =
same
action with different </font>
<br><font size=3D"2" face=3D"sans-serif">values in one same rule?</font>
<br>
<br><font size=3D"2" face=3D"sans-serif"><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;display:inline">=
=E2=80=8B=E2=80=8B</div>2, What=E2=80=99s the benefit of &quot;Terminal
Action bit&quot;? I think that your </font>
<br><font size=3D"2" face=3D"sans-serif">action merging may be one of the s=
olutions.
But the network manager </font>
<br><font size=3D"2" face=3D"sans-serif">cannot get the result from the sam=
e
rule directly. It may cause the </font>
<br><font size=3D"2" face=3D"sans-serif">confusion of network manager, isn&=
#39;t
it?</font>
<br>
<br><font size=3D"2" face=3D"sans-serif">Thanks,</font>
<br><font size=3D"2" face=3D"sans-serif">Sandy</font>
<br>
<br><font size=3D"2"><tt>Christoph Loibl &lt;<a href=3D"mailto:c@tix.at" ta=
rget=3D"_blank">c@tix.at</a>&gt; =E5=86=99=E4=BA=8E 2016/12/14
18:58:53:<br>
<br>
&gt; Hi,</tt></font>
<br><span class=3D"gmail-"><font size=3D"2"><tt>&gt; <br>
&gt; Your example perfectly makes sense to me, and I understand that <br>
&gt; there are several sections in RFC5575 that are a little unclear. <br>
&gt; RFC5575 does not explain what should happen in your case, nor does
<br>
&gt; it explain anything in case of action-interference.</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; This is why we currently working on a rfc557bis that should help us
<br>
&gt; to fix those problems and improve interoperability for flowspec. <br>
&gt; Have a look at:</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; <a href=3D"https://datatracker.ietf.org/doc/draft-hr-idr-rfc5575bis/" =
target=3D"_blank">https://datatracker.ietf.org/<wbr>doc/draft-hr-idr-rfc557=
5bis/</a></tt></font>
<br><font size=3D"2"><tt>&gt; Section 7.6. Rules on Traffic Action Interfer=
ence</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; During writing this section we were actually discussing single <br>
&gt; flowspec NLRIs with conflicting actions like:</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; rule 1</tt></font>
<br><font size=3D"2"><tt>&gt; =C2=A0 =C2=A0 traffic-rate: 10Mbps</tt></font=
>
<br><font size=3D"2"><tt>&gt; =C2=A0 =C2=A0 traffic-rate: 20Mbps</tt></font=
>
<br><font size=3D"2"><tt>&gt; <br>
&gt; or</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; rule 1</tt></font>
<br><font size=3D"2"><tt>&gt; =C2=A0 =C2=A0redirect: A</tt></font>
<br><font size=3D"2"><tt>&gt; =C2=A0 =C2=A0redirect: B</tt></font>
<br></span><font size=3D"2"><tt><span class=3D"gmail-">&gt; <br>
&gt; I think we shall extend this section to also explain your case. <br>
&gt; Currently this is not explained even in our submitted draft draft-<br>=
</span>
&gt; hr-idr-rfc5575bis latest revision. In that case it may make sense
to<div><div class=3D"gmail-h5"><br>
&gt; have a &quot;latest&quot; action wins behaviour. I suggest the followi=
ng
<br>
&gt; behaviour (this is nowhere written yet):</div></div></tt></font>
<br><div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5"><font size=3D"2"><t=
t>&gt; <br>
&gt; Suggestion: In your example the action for a flow matching all your
<br>
&gt; rules should be a merge of rule 1 and rule 2:</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; rule 1 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-rate: 10Mbps <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-marking: DSCP=3D10 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-action: T=3D1 S=3D1 <br>
</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; after this rule 2 gets applied</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; <br>
&gt; rule 2 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-rate: 20Mbps <br>
&gt; <br>
&gt; =C2=A0 =C2=A0redirect: nexthop =3D 192.168.1.2 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-action: T=3D0 S=3D0 <br>
</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; The resulting action for that flow is:</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; =C2=A0 =C2=A0 traffic-rate: 20Mbps</tt></font>
<br><font size=3D"2"><tt>&gt; =C2=A0 =C2=A0 traffic-marking: DSCP=3D10</tt>=
</font>
<br><font size=3D"2"><tt>&gt; =C2=A0 =C2=A0 redirect: nexthop =3D 192.168.1=
.2</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; Since on the second rule the terminal-bit is 0 there is no other <br>
&gt; rule to be evaluated.</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; To the &quot;latest&quot; applied action wins. However this is only
one <br>
&gt; suggested behaviour. There are plenty of other options. It should
<br>
&gt; also be considered that implementing such a behaviour may not be trivi=
al.</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; Christoph</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; On 14 Dec 2016, at 09:59, <a href=3D"mailto:zhang.zheng@zte.com.cn" ta=
rget=3D"_blank">zhang.zheng@zte.com.cn</a> wrote:</tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; <br>
&gt; Hi all, <br>
&gt; <br>
&gt; =C2=A0 =C2=A0 About RFC5575, it seems like that the definition of
&quot;Terminal <br>
&gt; Action bit&quot; is blurred. <br>
&gt; <br>
&gt; =C2=A0 =C2=A0 In section 7, the &quot;Terminal Action bit&quot; is
defined as follows: <br>
&gt; Terminal Action (bit 47): When this bit is set, the traffic filtering
<br>
&gt; engine will apply any subsequent filtering rules (as defined by the
<br>
&gt; ordering procedure).=C2=A0 If not set, the evaluation of the traffic
filter <br>
&gt; stops when this rule is applied. <br>
&gt; <br>
&gt; =C2=A0 =C2=A0 How can routers do when many rules that define variant
actions <br>
&gt; are applied to a same flow? <br>
&gt; <br>
&gt; =C2=A0 =C2=A0For example, there are four rules that can be applied
to one same flow. <br>
&gt; And the sequence has been determined as below. When router executes
rule 1, <br>
&gt; the &quot;Terminal Action Bit&quot; is set. It indicated that next
rule should be <br>
&gt; executed. When router execute rule 2, which action should be executed?
<br>
&gt; Only redirect? Or/and traffic-marking? Which traffic-rate should be
<br>
&gt; selected? <br>
&gt; <br>
&gt; rule 1 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-rate: 10Mbps <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-marking: DSCP=3D10 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-action: T=3D1 S=3D1 <br>
&gt; <br>
&gt; <br>
&gt; rule 2 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-rate: 20Mbps <br>
&gt; <br>
&gt; =C2=A0 =C2=A0redirect: nexthop =3D 192.168.1.2 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-action: T=3D0 S=3D0 <br>
&gt; <br>
&gt; <br>
&gt; rule 3 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-rate: 30Mbps <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-marking: DSCP=3D30 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0redirect: nexthop =3D 192.168.2.2 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-action: T=3D1 S=3D1 =C2=A0 <br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>
&gt; <br>
&gt; rule 4 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-rate: 40Mbps <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-marking: DSCP=3D40 <br>
&gt; <br>
&gt; =C2=A0 =C2=A0traffic-action: T=3D0 S=3D0 <br>
&gt; <br>
&gt; ______________________________<wbr>_________________<br>
&gt; Idr mailing list<br>
&gt; <a href=3D"mailto:Idr@ietf.org" target=3D"_blank">Idr@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/idr" target=3D"_blank=
">https://www.ietf.org/mailman/<wbr>listinfo/idr</a></tt></font>
<br><font size=3D"2"><tt>&gt; <br>
&gt; -- <br>
&gt; Christoph Loibl<br>
&gt; <a href=3D"mailto:c@tix.at" target=3D"_blank">c@tix.at</a> | CL8-RIPE =
| PGP-Key-ID: 0x4B2C0055 | <a href=3D"http://www.nextlayer.at" target=3D"_b=
lank">http://www.nextlayer.at</a></tt></font>
</div></div></blockquote></div><br></div></div>

--94eb2c075ab4e187d50543b4800f--


From nobody Fri Dec 16 00:25:36 2016
Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A9C129568 for <idr@ietfa.amsl.com>; Fri, 16 Dec 2016 00:25:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.096
X-Spam-Level: 
X-Spam-Status: No, score=-107.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
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 ByRUqORPLpya for <idr@ietfa.amsl.com>; Fri, 16 Dec 2016 00:25:31 -0800 (PST)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E7F261294DF for <idr@ietf.org>; Fri, 16 Dec 2016 00:25:30 -0800 (PST)
X-MAILFROM: <zhang.zheng@zte.com.cn>
X-RCPTTO: <rraszuk@gmail.com>
X-FROMIP: 10.30.3.20
X-SEG-Scaned: 1
X-Received: unknown,10.30.3.20,20161216162403
Received: from unknown (HELO mse01.zte.com.cn) (10.30.3.20) by localhost with (AES256-SHA encrypted) SMTP; 16 Dec 2016 08:24:03 -0000
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id uBG8P1C4044310; Fri, 16 Dec 2016 16:25:01 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
In-Reply-To: <CA+b+ERk8Jb6m_m9E5KfVS24Y8vYcP1foOHh6Nv_2Zzkx7OYvqQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFCE474E4F.507BC2C5-ON4825808B.002C95B8-4825808B.002E3CCC@zte.com.cn>
From: zhang.zheng@zte.com.cn
Date: Fri, 16 Dec 2016 16:25:34 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-12-16 16:25:01, Serialize complete at 2016-12-16 16:25:01
Content-Type: multipart/alternative; boundary="=_alternative 002E3CC94825808B_="
X-MAIL: mse01.zte.com.cn uBG8P1C4044310
X-HQIP: 127.0.0.1
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/a0bNT4TsYDmn70rQtgmk2PUORyU>
Cc: zhu.xiaolong@zte.com.cn, idr wg <idr@ietf.org>, shen.yiming@zte.com.cn, rraszuk@gmail.com, Idr <idr-bounces@ietf.org>, zhu.tong@zte.com.cn
Subject: Re: [Idr] One question about "Terminal Action bit" in RFC5575
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2016 08:25:35 -0000

This is a multipart message in MIME format.
--=_alternative 002E3CC94825808B_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

SGkgUm9iZXJ0LA0KDQogICAgVGhhbmsgeW91IGZvciB5b3VyIHJlc3BvbnNlLiBJIHVuZGVyc3Rh
bmQgdGhlIG1lYW5pbmcgb2YgeW91ciANCmV4YW1wbGUuIEJ1dCBJIGFtIG5vdCBrbm93biB2ZXJ5
IGNsZWFybHkgYWJvdXQgd2hlcmUgdGhpcyBmdW5jdGlvbiANCndpbGwgYmUgdXNlZC4gSWYgd2Ug
d2FudCB0byByZWRpcmVjdCBvbmUgZmxvdyB0byBvbmUgdnJmLCB3aHkgZG9uJ3QgDQp3ZSBkZWZp
bmUgdGhlIGFzc29jaWF0ZWQgYWN0aW9ucyBpbiB0aGUgdnJm4oCZcyBydWxlcz8gT25jZSB0aGVy
ZSBpcyANCnNvbWV0aGluZyB3cm9uZyB3aXRoIG9uZSBmbG93LCBpdCBtYXkgYmUgaGFyZCB0byBm
aW5kIG91dCB0aGUgd3JvbmcgDQpydWxlLCBiZWNhdXNlIG1hbnkgcnVsZXMgbWF5IGluZmx1ZW5j
ZSB0aGUgZmxvd+KAmXMgYWN0aW9uLCBpc24ndCBpdD8NCg0KVGhhbmtzLA0KU2FuZHkNCg0KcnJh
c3p1a0BnbWFpbC5jb20g5YaZ5LqOIDIwMTYvMTIvMTUgMjM6NTY6NTg6DQoNCj4gSGkgU2FuZHks
DQo+IA0KPiDigIvigIs+IDIsIFdoYXTigJlzIHRoZSBiZW5lZml0IG9mICJUZXJtaW5hbCBBY3Rp
b24gYml0Ij8NCj4gDQo+IFRoZSBtZWFuaW5nIG9mIHRoaXMgZmxhZyB3YXMgdG8gaW5kaWNhdGUg
cmVxdWlyZW1lbnQgYW5hbG9neSBvZiANCj4gImNvbnRpbnVlIiBzdGF0ZW1lbnQgd2hlbiBleGVj
dXRpbmcgeW91ciB0cmFmZmljIGZpbHRlcmluZyBhY3Rpb25zIA0KPiBvbiB0aGUgbWF0Y2hlZCB0
cmFmZmljLiBFeGFtcGxlIC0geW91IG1heSB3YW50IHRvIHJlZGlyZWN0IHRvIGEgdnJmIA0KPiB3
aXRoIG9yIHdpdGhvdXQgcmVtYXJraW5nIHRoZSB0cmFmZmljIHdpdGggZGlmZmVyZW50LiBOb3Qg
cmVhbGx5IA0KPiBtdWNoIG1vcmUgdG8gaXQuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFIuIA0K
PiANCj4gT24gVGh1LCBEZWMgMTUsIDIwMTYgYXQgMTA6MzQgQU0sIDx6aGFuZy56aGVuZ0B6dGUu
Y29tLmNuPiB3cm90ZToNCj4gDQo+IEhpIENocmlzdG9waCwgDQo+IA0KPiAgICAgVGhhbmsgeW91
IHZlcnkgbXVjaCBmb3IgeW91ciByZXNwb25zZS4gR2xhZCB0byBoZWFyIHRoYXQgdGhlIFJGQyAN
Cj4gd2lsbCBiZSByZXZpc2VkIENsZWFybHkuIA0KPiANCj4gICAgIEZyb20geW91ciBzcGVjaWZp
Y2F0aW9uLCBJIGhhdmUgdHdvIHF1ZXN0aW9ucyBmb3IgaXQ6IA0KPiANCj4gMSwgSWYgaXQgaXMg
dmFsaWQgdGhhdCBkZWZpbmUgdGhlIHNhbWUgYWN0aW9uIHdpdGggZGlmZmVyZW50IA0KPiB2YWx1
ZXMgaW4gb25lIHNhbWUgcnVsZT8gDQo+IA0KPiDigIvigIsyLCBXaGF04oCZcyB0aGUgYmVuZWZp
dCBvZiAiVGVybWluYWwgQWN0aW9uIGJpdCI/IEkgdGhpbmsgdGhhdCB5b3VyIA0KPiBhY3Rpb24g
bWVyZ2luZyBtYXkgYmUgb25lIG9mIHRoZSBzb2x1dGlvbnMuIEJ1dCB0aGUgbmV0d29yayBtYW5h
Z2VyIA0KPiBjYW5ub3QgZ2V0IHRoZSByZXN1bHQgZnJvbSB0aGUgc2FtZSBydWxlIGRpcmVjdGx5
LiBJdCBtYXkgY2F1c2UgdGhlIA0KPiBjb25mdXNpb24gb2YgbmV0d29yayBtYW5hZ2VyLCBpc24n
dCBpdD8gDQo+IA0KPiBUaGFua3MsIA0KPiBTYW5keSANCj4gDQo+IENocmlzdG9waCBMb2libCA8
Y0B0aXguYXQ+IOWGmeS6jiAyMDE2LzEyLzE0IDE4OjU4OjUzOg0KPiANCj4gPiBIaSwgDQo+ID4g
DQo+ID4gWW91ciBleGFtcGxlIHBlcmZlY3RseSBtYWtlcyBzZW5zZSB0byBtZSwgYW5kIEkgdW5k
ZXJzdGFuZCB0aGF0IA0KPiA+IHRoZXJlIGFyZSBzZXZlcmFsIHNlY3Rpb25zIGluIFJGQzU1NzUg
dGhhdCBhcmUgYSBsaXR0bGUgdW5jbGVhci4gDQo+ID4gUkZDNTU3NSBkb2VzIG5vdCBleHBsYWlu
IHdoYXQgc2hvdWxkIGhhcHBlbiBpbiB5b3VyIGNhc2UsIG5vciBkb2VzIA0KPiA+IGl0IGV4cGxh
aW4gYW55dGhpbmcgaW4gY2FzZSBvZiBhY3Rpb24taW50ZXJmZXJlbmNlLiANCj4gPiANCj4gPiBU
aGlzIGlzIHdoeSB3ZSBjdXJyZW50bHkgd29ya2luZyBvbiBhIHJmYzU1N2JpcyB0aGF0IHNob3Vs
ZCBoZWxwIHVzIA0KPiA+IHRvIGZpeCB0aG9zZSBwcm9ibGVtcyBhbmQgaW1wcm92ZSBpbnRlcm9w
ZXJhYmlsaXR5IGZvciBmbG93c3BlYy4gDQo+ID4gSGF2ZSBhIGxvb2sgYXQ6IA0KPiA+IA0KPiA+
IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhyLWlkci1yZmM1NTc1Ymlz
LyANCj4gPiBTZWN0aW9uIDcuNi4gUnVsZXMgb24gVHJhZmZpYyBBY3Rpb24gSW50ZXJmZXJlbmNl
IA0KPiA+IA0KPiA+IER1cmluZyB3cml0aW5nIHRoaXMgc2VjdGlvbiB3ZSB3ZXJlIGFjdHVhbGx5
IGRpc2N1c3Npbmcgc2luZ2xlIA0KPiA+IGZsb3dzcGVjIE5MUklzIHdpdGggY29uZmxpY3Rpbmcg
YWN0aW9ucyBsaWtlOiANCj4gPiANCj4gPiBydWxlIDEgDQo+ID4gICAgIHRyYWZmaWMtcmF0ZTog
MTBNYnBzIA0KPiA+ICAgICB0cmFmZmljLXJhdGU6IDIwTWJwcyANCj4gPiANCj4gPiBvciANCj4g
PiANCj4gPiBydWxlIDEgDQo+ID4gICAgcmVkaXJlY3Q6IEEgDQo+ID4gICAgcmVkaXJlY3Q6IEIg
DQo+ID4gDQo+ID4gSSB0aGluayB3ZSBzaGFsbCBleHRlbmQgdGhpcyBzZWN0aW9uIHRvIGFsc28g
ZXhwbGFpbiB5b3VyIGNhc2UuIA0KPiA+IEN1cnJlbnRseSB0aGlzIGlzIG5vdCBleHBsYWluZWQg
ZXZlbiBpbiBvdXIgc3VibWl0dGVkIGRyYWZ0IGRyYWZ0LQ0KPiA+IGhyLWlkci1yZmM1NTc1Ymlz
IGxhdGVzdCByZXZpc2lvbi4gSW4gdGhhdCBjYXNlIGl0IG1heSBtYWtlIHNlbnNlIHRvDQo+IA0K
PiA+IGhhdmUgYSAibGF0ZXN0IiBhY3Rpb24gd2lucyBiZWhhdmlvdXIuIEkgc3VnZ2VzdCB0aGUg
Zm9sbG93aW5nIA0KPiA+IGJlaGF2aW91ciAodGhpcyBpcyBub3doZXJlIHdyaXR0ZW4geWV0KToN
Cj4gDQo+ID4gDQo+ID4gU3VnZ2VzdGlvbjogSW4geW91ciBleGFtcGxlIHRoZSBhY3Rpb24gZm9y
IGEgZmxvdyBtYXRjaGluZyBhbGwgeW91ciANCj4gPiBydWxlcyBzaG91bGQgYmUgYSBtZXJnZSBv
ZiBydWxlIDEgYW5kIHJ1bGUgMjogDQo+ID4gDQo+ID4gcnVsZSAxIA0KPiA+IA0KPiA+ICAgIHRy
YWZmaWMtcmF0ZTogMTBNYnBzIA0KPiA+IA0KPiA+ICAgIHRyYWZmaWMtbWFya2luZzogRFNDUD0x
MCANCj4gPiANCj4gPiAgICB0cmFmZmljLWFjdGlvbjogVD0xIFM9MSANCj4gDQo+ID4gDQo+ID4g
YWZ0ZXIgdGhpcyBydWxlIDIgZ2V0cyBhcHBsaWVkIA0KPiA+IA0KPiA+IA0KPiA+IHJ1bGUgMiAN
Cj4gPiANCj4gPiAgICB0cmFmZmljLXJhdGU6IDIwTWJwcyANCj4gPiANCj4gPiAgICByZWRpcmVj
dDogbmV4dGhvcCA9IDE5Mi4xNjguMS4yIA0KPiA+IA0KPiA+ICAgIHRyYWZmaWMtYWN0aW9uOiBU
PTAgUz0wIA0KPiANCj4gPiANCj4gPiBUaGUgcmVzdWx0aW5nIGFjdGlvbiBmb3IgdGhhdCBmbG93
IGlzOiANCj4gPiANCj4gPiAgICAgdHJhZmZpYy1yYXRlOiAyME1icHMgDQo+ID4gICAgIHRyYWZm
aWMtbWFya2luZzogRFNDUD0xMCANCj4gPiAgICAgcmVkaXJlY3Q6IG5leHRob3AgPSAxOTIuMTY4
LjEuMiANCj4gPiANCj4gPiBTaW5jZSBvbiB0aGUgc2Vjb25kIHJ1bGUgdGhlIHRlcm1pbmFsLWJp
dCBpcyAwIHRoZXJlIGlzIG5vIG90aGVyIA0KPiA+IHJ1bGUgdG8gYmUgZXZhbHVhdGVkLiANCj4g
PiANCj4gPiBUbyB0aGUgImxhdGVzdCIgYXBwbGllZCBhY3Rpb24gd2lucy4gSG93ZXZlciB0aGlz
IGlzIG9ubHkgb25lIA0KPiA+IHN1Z2dlc3RlZCBiZWhhdmlvdXIuIFRoZXJlIGFyZSBwbGVudHkg
b2Ygb3RoZXIgb3B0aW9ucy4gSXQgc2hvdWxkIA0KPiA+IGFsc28gYmUgY29uc2lkZXJlZCB0aGF0
IGltcGxlbWVudGluZyBzdWNoIGEgYmVoYXZpb3VyIG1heSBub3QgYmUgDQp0cml2aWFsLiANCj4g
PiANCj4gPiBDaHJpc3RvcGggDQo+ID4gDQo+ID4gT24gMTQgRGVjIDIwMTYsIGF0IDA5OjU5LCB6
aGFuZy56aGVuZ0B6dGUuY29tLmNuIHdyb3RlOiANCj4gPiANCj4gPiANCj4gPiBIaSBhbGwsIA0K
PiA+IA0KPiA+ICAgICBBYm91dCBSRkM1NTc1LCBpdCBzZWVtcyBsaWtlIHRoYXQgdGhlIGRlZmlu
aXRpb24gb2YgIlRlcm1pbmFsIA0KPiA+IEFjdGlvbiBiaXQiIGlzIGJsdXJyZWQuIA0KPiA+IA0K
PiA+ICAgICBJbiBzZWN0aW9uIDcsIHRoZSAiVGVybWluYWwgQWN0aW9uIGJpdCIgaXMgZGVmaW5l
ZCBhcyBmb2xsb3dzOiANCj4gPiBUZXJtaW5hbCBBY3Rpb24gKGJpdCA0Nyk6IFdoZW4gdGhpcyBi
aXQgaXMgc2V0LCB0aGUgdHJhZmZpYyBmaWx0ZXJpbmcgDQo+ID4gZW5naW5lIHdpbGwgYXBwbHkg
YW55IHN1YnNlcXVlbnQgZmlsdGVyaW5nIHJ1bGVzIChhcyBkZWZpbmVkIGJ5IHRoZSANCj4gPiBv
cmRlcmluZyBwcm9jZWR1cmUpLiAgSWYgbm90IHNldCwgdGhlIGV2YWx1YXRpb24gb2YgdGhlIHRy
YWZmaWMgZmlsdGVyIA0KDQo+ID4gc3RvcHMgd2hlbiB0aGlzIHJ1bGUgaXMgYXBwbGllZC4gDQo+
ID4gDQo+ID4gICAgIEhvdyBjYW4gcm91dGVycyBkbyB3aGVuIG1hbnkgcnVsZXMgdGhhdCBkZWZp
bmUgdmFyaWFudCBhY3Rpb25zIA0KPiA+IGFyZSBhcHBsaWVkIHRvIGEgc2FtZSBmbG93PyANCj4g
PiANCj4gPiAgICBGb3IgZXhhbXBsZSwgdGhlcmUgYXJlIGZvdXIgcnVsZXMgdGhhdCBjYW4gYmUg
YXBwbGllZCB0byBvbmUgc2FtZSANCmZsb3cuIA0KPiA+IEFuZCB0aGUgc2VxdWVuY2UgaGFzIGJl
ZW4gZGV0ZXJtaW5lZCBhcyBiZWxvdy4gV2hlbiByb3V0ZXIgZXhlY3V0ZXMgDQpydWxlIDEsIA0K
PiA+IHRoZSAiVGVybWluYWwgQWN0aW9uIEJpdCIgaXMgc2V0LiBJdCBpbmRpY2F0ZWQgdGhhdCBu
ZXh0IHJ1bGUgc2hvdWxkIA0KYmUgDQo+ID4gZXhlY3V0ZWQuIFdoZW4gcm91dGVyIGV4ZWN1dGUg
cnVsZSAyLCB3aGljaCBhY3Rpb24gc2hvdWxkIGJlIGV4ZWN1dGVkPyANCg0KPiA+IE9ubHkgcmVk
aXJlY3Q/IE9yL2FuZCB0cmFmZmljLW1hcmtpbmc/IFdoaWNoIHRyYWZmaWMtcmF0ZSBzaG91bGQg
YmUgDQo+ID4gc2VsZWN0ZWQ/IA0KPiA+IA0KPiA+IHJ1bGUgMSANCj4gPiANCj4gPiAgICB0cmFm
ZmljLXJhdGU6IDEwTWJwcyANCj4gPiANCj4gPiAgICB0cmFmZmljLW1hcmtpbmc6IERTQ1A9MTAg
DQo+ID4gDQo+ID4gICAgdHJhZmZpYy1hY3Rpb246IFQ9MSBTPTEgDQo+ID4gDQo+ID4gDQo+ID4g
cnVsZSAyIA0KPiA+IA0KPiA+ICAgIHRyYWZmaWMtcmF0ZTogMjBNYnBzIA0KPiA+IA0KPiA+ICAg
IHJlZGlyZWN0OiBuZXh0aG9wID0gMTkyLjE2OC4xLjIgDQo+ID4gDQo+ID4gICAgdHJhZmZpYy1h
Y3Rpb246IFQ9MCBTPTAgDQo+ID4gDQo+ID4gDQo+ID4gcnVsZSAzIA0KPiA+IA0KPiA+ICAgIHRy
YWZmaWMtcmF0ZTogMzBNYnBzIA0KPiA+IA0KPiA+ICAgIHRyYWZmaWMtbWFya2luZzogRFNDUD0z
MCANCj4gPiANCj4gPiAgICByZWRpcmVjdDogbmV4dGhvcCA9IDE5Mi4xNjguMi4yIA0KPiA+IA0K
PiA+ICAgIHRyYWZmaWMtYWN0aW9uOiBUPTEgUz0xICAgDQo+ID4gICAgICAgICAgICAgICAgICAg
DQo+ID4gDQo+ID4gcnVsZSA0IA0KPiA+IA0KPiA+ICAgIHRyYWZmaWMtcmF0ZTogNDBNYnBzIA0K
PiA+IA0KPiA+ICAgIHRyYWZmaWMtbWFya2luZzogRFNDUD00MCANCj4gPiANCj4gPiAgICB0cmFm
ZmljLWFjdGlvbjogVD0wIFM9MCANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IElkciBtYWlsaW5nIGxpc3QNCj4gPiBJZHJAaWV0
Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkciANCj4g
PiANCj4gPiAtLSANCj4gPiBDaHJpc3RvcGggTG9pYmwNCj4gPiBjQHRpeC5hdCB8IENMOC1SSVBF
IHwgUEdQLUtleS1JRDogMHg0QjJDMDA1NSB8IGh0dHA6Ly93d3cubmV4dGxheWVyLmF0IA0KDQo=
--=_alternative 002E3CC94825808B_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJvYmVydCw8L2ZvbnQ+DQo8
YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgVGhh
bmsgeW91IGZvciB5b3VyIHJlc3BvbnNlLg0KSSB1bmRlcnN0YW5kIHRoZSBtZWFuaW5nIG9mIHlv
dXIgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5leGFtcGxlLiBC
dXQgSSBhbSBub3Qga25vd24gdmVyeSBjbGVhcmx5DQphYm91dCB3aGVyZSB0aGlzIGZ1bmN0aW9u
IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+d2lsbCBiZSB1c2Vk
LiBJZiB3ZSB3YW50IHRvIHJlZGlyZWN0DQpvbmUgZmxvdyB0byBvbmUgdnJmLCB3aHkgZG9uJ3Qg
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj53ZSBkZWZpbmUgdGhl
IGFzc29jaWF0ZWQgYWN0aW9ucyBpbg0KdGhlIHZyZuKAmXMgcnVsZXM/IE9uY2UgdGhlcmUgaXMg
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zb21ldGhpbmcgd3Jv
bmcgd2l0aCBvbmUgZmxvdywgaXQgbWF5DQpiZSBoYXJkIHRvIGZpbmQgb3V0IHRoZSB3cm9uZyA8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnJ1bGUsIGJlY2F1c2Ug
bWFueSBydWxlcyBtYXkgaW5mbHVlbmNlDQp0aGUgZmxvd+KAmXMgYWN0aW9uLCBpc24ndCBpdD88
L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNhbmR5PC9mb250Pg0K
PGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+cnJhc3p1a0BnbWFpbC5jb20g5YaZ5LqOIDIwMTYv
MTIvMTUgMjM6NTY6NTg6PGJyPg0KPGJyPg0KJmd0OyBIaSBTYW5keSw8L3R0PjwvZm9udD4NCjxi
cj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyDigIvigIsmZ3Q7Jm5ic3A7MiwgV2hh
dOKAmXMgdGhlIGJlbmVmaXQgb2YgJnF1b3Q7VGVybWluYWwgQWN0aW9uIGJpdCZxdW90Oz88L3R0
PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBUaGUgbWVhbmlu
ZyBvZiB0aGlzIGZsYWcgd2FzIHRvIGluZGljYXRlIHJlcXVpcmVtZW50IGFuYWxvZ3kgb2YgPGJy
Pg0KJmd0OyAmcXVvdDtjb250aW51ZSZxdW90OyBzdGF0ZW1lbnQgd2hlbiBleGVjdXRpbmcgeW91
ciB0cmFmZmljIGZpbHRlcmluZw0KYWN0aW9ucyA8YnI+DQomZ3Q7IG9uIHRoZSBtYXRjaGVkIHRy
YWZmaWMuIEV4YW1wbGUgLSB5b3UgbWF5IHdhbnQgdG8gcmVkaXJlY3QgdG8gYSB2cmYNCjxicj4N
CiZndDsgd2l0aCBvciB3aXRob3V0IHJlbWFya2luZyB0aGUgdHJhZmZpYyB3aXRoIGRpZmZlcmVu
dC4gTm90IHJlYWxseSA8YnI+DQomZ3Q7IG11Y2ggbW9yZSB0byBpdC48L3R0PjwvZm9udD4NCjxi
cj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHMsPC90dD48L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFIuJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+
PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgT24gVGh1LCBEZWMgMTUsIDIwMTYgYXQg
MTA6MzQgQU0sICZsdDt6aGFuZy56aGVuZ0B6dGUuY29tLmNuJmd0OyB3cm90ZTo8L3R0PjwvZm9u
dD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBIaSBDaHJpc3RvcGgsIDxi
cj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9y
IHlvdXIgcmVzcG9uc2UuIEdsYWQgdG8gaGVhcg0KdGhhdCB0aGUgUkZDIDxicj4NCiZndDsgd2ls
bCBiZSByZXZpc2VkIENsZWFybHkuIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7
IEZyb20geW91ciBzcGVjaWZpY2F0aW9uLCBJIGhhdmUgdHdvIHF1ZXN0aW9ucyBmb3IgaXQ6DQo8
YnI+DQomZ3Q7IDxicj4NCiZndDsgMSwgSWYgaXQgaXMgdmFsaWQgdGhhdCBkZWZpbmUgdGhlIHNh
bWUgYWN0aW9uIHdpdGggZGlmZmVyZW50IDxicj4NCiZndDsgdmFsdWVzIGluIG9uZSBzYW1lIHJ1
bGU/IDxicj4NCiZndDsgPGJyPg0KJmd0OyDigIvigIsyLCBXaGF04oCZcyB0aGUgYmVuZWZpdCBv
ZiAmcXVvdDtUZXJtaW5hbCBBY3Rpb24gYml0JnF1b3Q7Pw0KSSB0aGluayB0aGF0IHlvdXIgPGJy
Pg0KJmd0OyBhY3Rpb24gbWVyZ2luZyBtYXkgYmUgb25lIG9mIHRoZSBzb2x1dGlvbnMuIEJ1dCB0
aGUgbmV0d29yayBtYW5hZ2VyDQo8YnI+DQomZ3Q7IGNhbm5vdCBnZXQgdGhlIHJlc3VsdCBmcm9t
IHRoZSBzYW1lIHJ1bGUgZGlyZWN0bHkuIEl0IG1heSBjYXVzZSB0aGUNCjxicj4NCiZndDsgY29u
ZnVzaW9uIG9mIG5ldHdvcmsgbWFuYWdlciwgaXNuJ3QgaXQ/IDxicj4NCiZndDsgPGJyPg0KJmd0
OyBUaGFua3MsIDxicj4NCiZndDsgU2FuZHkgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENocmlzdG9w
aCBMb2libCAmbHQ7Y0B0aXguYXQmZ3Q7IOWGmeS6jiAyMDE2LzEyLzE0IDE4OjU4OjUzOjxicj4N
CiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpLCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IFlvdXIgZXhhbXBsZSBwZXJmZWN0bHkgbWFrZXMgc2Vuc2UgdG8gbWUsIGFuZCBJIHVuZGVyc3Rh
bmQgdGhhdA0KPGJyPg0KJmd0OyAmZ3Q7IHRoZXJlIGFyZSBzZXZlcmFsIHNlY3Rpb25zIGluIFJG
QzU1NzUgdGhhdCBhcmUgYSBsaXR0bGUgdW5jbGVhci4NCjxicj4NCiZndDsgJmd0OyBSRkM1NTc1
IGRvZXMgbm90IGV4cGxhaW4gd2hhdCBzaG91bGQgaGFwcGVuIGluIHlvdXIgY2FzZSwgbm9yDQpk
b2VzIDxicj4NCiZndDsgJmd0OyBpdCBleHBsYWluIGFueXRoaW5nIGluIGNhc2Ugb2YgYWN0aW9u
LWludGVyZmVyZW5jZS4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGlzIGlzIHdo
eSB3ZSBjdXJyZW50bHkgd29ya2luZyBvbiBhIHJmYzU1N2JpcyB0aGF0IHNob3VsZCBoZWxwDQp1
cyA8YnI+DQomZ3Q7ICZndDsgdG8gZml4IHRob3NlIHByb2JsZW1zIGFuZCBpbXByb3ZlIGludGVy
b3BlcmFiaWxpdHkgZm9yIGZsb3dzcGVjLg0KPGJyPg0KJmd0OyAmZ3Q7IEhhdmUgYSBsb29rIGF0
OiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LWhyLWlkci1yZmM1NTc1YmlzLyA8YnI+DQomZ3Q7ICZndDsgU2VjdGlv
biA3LjYuIFJ1bGVzIG9uIFRyYWZmaWMgQWN0aW9uIEludGVyZmVyZW5jZSA8YnI+DQomZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IER1cmluZyB3cml0aW5nIHRoaXMgc2VjdGlvbiB3ZSB3ZXJlIGFj
dHVhbGx5IGRpc2N1c3Npbmcgc2luZ2xlDQo8YnI+DQomZ3Q7ICZndDsgZmxvd3NwZWMgTkxSSXMg
d2l0aCBjb25mbGljdGluZyBhY3Rpb25zIGxpa2U6IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgcnVsZSAxIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IHRyYWZmaWMtcmF0ZTog
MTBNYnBzIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IHRyYWZmaWMtcmF0ZTogMjBNYnBz
IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgb3IgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyBydWxlIDEgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtyZWRpcmVjdDog
QSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3JlZGlyZWN0OiBCIDxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgSSB0aGluayB3ZSBzaGFsbCBleHRlbmQgdGhpcyBzZWN0aW9uIHRv
IGFsc28gZXhwbGFpbiB5b3VyIGNhc2UuDQo8YnI+DQomZ3Q7ICZndDsgQ3VycmVudGx5IHRoaXMg
aXMgbm90IGV4cGxhaW5lZCBldmVuIGluIG91ciBzdWJtaXR0ZWQgZHJhZnQgZHJhZnQtPGJyPg0K
Jmd0OyAmZ3Q7IGhyLWlkci1yZmM1NTc1YmlzIGxhdGVzdCByZXZpc2lvbi4gSW4gdGhhdCBjYXNl
IGl0IG1heSBtYWtlIHNlbnNlDQp0bzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgaGF2ZSBhICZxdW90O2xhdGVzdCZxdW90OyBhY3Rpb24gd2lu
cyBiZWhhdmlvdXIuIEkgc3VnZ2VzdCB0aGUNCmZvbGxvd2luZyA8YnI+DQomZ3Q7ICZndDsgYmVo
YXZpb3VyICh0aGlzIGlzIG5vd2hlcmUgd3JpdHRlbiB5ZXQpOjwvdHQ+PC9mb250Pg0KPGJyPjxm
b250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFN1Z2dl
c3Rpb246IEluIHlvdXIgZXhhbXBsZSB0aGUgYWN0aW9uIGZvciBhIGZsb3cgbWF0Y2hpbmcgYWxs
DQp5b3VyIDxicj4NCiZndDsgJmd0OyBydWxlcyBzaG91bGQgYmUgYSBtZXJnZSBvZiBydWxlIDEg
YW5kIHJ1bGUgMjogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBydWxlIDEgPGJyPg0K
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dHJhZmZpYy1yYXRlOiAxME1i
cHMgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dHJhZmZpYy1t
YXJraW5nOiBEU0NQPTEwIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu
YnNwO3RyYWZmaWMtYWN0aW9uOiBUPTEgUz0xIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyBhZnRlciB0aGlzIHJ1bGUgMiBnZXRzIGFwcGxpZWQgPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgcnVsZSAyIDxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtcmF0ZTogMjBNYnBzIDxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3JlZGlyZWN0OiBuZXh0aG9w
ID0gMTkyLjE2OC4xLjIgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i
c3A7dHJhZmZpYy1hY3Rpb246IFQ9MCBTPTAgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IFRoZSByZXN1bHRpbmcgYWN0aW9uIGZvciB0aGF0IGZsb3cgaXM6IDxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyB0cmFmZmljLXJhdGU6IDIw
TWJwcyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyB0cmFmZmljLW1hcmtpbmc6IERTQ1A9
MTAgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgcmVkaXJlY3Q6IG5leHRob3AgPSAxOTIu
MTY4LjEuMiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNpbmNlIG9uIHRoZSBzZWNv
bmQgcnVsZSB0aGUgdGVybWluYWwtYml0IGlzIDAgdGhlcmUgaXMgbm8gb3RoZXINCjxicj4NCiZn
dDsgJmd0OyBydWxlIHRvIGJlIGV2YWx1YXRlZC4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyBUbyB0aGUgJnF1b3Q7bGF0ZXN0JnF1b3Q7IGFwcGxpZWQgYWN0aW9uIHdpbnMuIEhvd2V2
ZXIgdGhpcyBpcw0Kb25seSBvbmUgPGJyPg0KJmd0OyAmZ3Q7IHN1Z2dlc3RlZCBiZWhhdmlvdXIu
IFRoZXJlIGFyZSBwbGVudHkgb2Ygb3RoZXIgb3B0aW9ucy4gSXQgc2hvdWxkDQo8YnI+DQomZ3Q7
ICZndDsgYWxzbyBiZSBjb25zaWRlcmVkIHRoYXQgaW1wbGVtZW50aW5nIHN1Y2ggYSBiZWhhdmlv
dXIgbWF5IG5vdA0KYmUgdHJpdmlhbC4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBD
aHJpc3RvcGggPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBPbiAxNCBEZWMgMjAxNiwg
YXQgMDk6NTksIHpoYW5nLnpoZW5nQHp0ZS5jb20uY24gd3JvdGU6IDxicj4NCiZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpIGFsbCwgPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IEFib3V0IFJGQzU1NzUsIGl0IHNlZW1zIGxpa2Ug
dGhhdCB0aGUgZGVmaW5pdGlvbg0Kb2YgJnF1b3Q7VGVybWluYWwgPGJyPg0KJmd0OyAmZ3Q7IEFj
dGlvbiBiaXQmcXVvdDsgaXMgYmx1cnJlZC4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyAmbmJzcDsgJm5ic3A7IEluIHNlY3Rpb24gNywgdGhlICZxdW90O1Rlcm1pbmFsIEFjdGlvbiBi
aXQmcXVvdDsNCmlzIGRlZmluZWQgYXMgZm9sbG93czogPGJyPg0KJmd0OyAmZ3Q7IFRlcm1pbmFs
IEFjdGlvbiAoYml0IDQ3KTogV2hlbiB0aGlzIGJpdCBpcyBzZXQsIHRoZSB0cmFmZmljIGZpbHRl
cmluZw0KPGJyPg0KJmd0OyAmZ3Q7IGVuZ2luZSB3aWxsIGFwcGx5IGFueSBzdWJzZXF1ZW50IGZp
bHRlcmluZyBydWxlcyAoYXMgZGVmaW5lZA0KYnkgdGhlIDxicj4NCiZndDsgJmd0OyBvcmRlcmlu
ZyBwcm9jZWR1cmUpLiZuYnNwOyBJZiBub3Qgc2V0LCB0aGUgZXZhbHVhdGlvbiBvZiB0aGUNCnRy
YWZmaWMgZmlsdGVyIDxicj4NCiZndDsgJmd0OyBzdG9wcyB3aGVuIHRoaXMgcnVsZSBpcyBhcHBs
aWVkLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgSG93IGNh
biByb3V0ZXJzIGRvIHdoZW4gbWFueSBydWxlcyB0aGF0IGRlZmluZQ0KdmFyaWFudCBhY3Rpb25z
IDxicj4NCiZndDsgJmd0OyBhcmUgYXBwbGllZCB0byBhIHNhbWUgZmxvdz8gPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7Rm9yIGV4YW1wbGUsIHRoZXJlIGFyZSBm
b3VyIHJ1bGVzIHRoYXQgY2FuIGJlIGFwcGxpZWQNCnRvIG9uZSBzYW1lIGZsb3cuIDxicj4NCiZn
dDsgJmd0OyBBbmQgdGhlIHNlcXVlbmNlIGhhcyBiZWVuIGRldGVybWluZWQgYXMgYmVsb3cuIFdo
ZW4gcm91dGVyIGV4ZWN1dGVzDQpydWxlIDEsIDxicj4NCiZndDsgJmd0OyB0aGUgJnF1b3Q7VGVy
bWluYWwgQWN0aW9uIEJpdCZxdW90OyBpcyBzZXQuIEl0IGluZGljYXRlZCB0aGF0DQpuZXh0IHJ1
bGUgc2hvdWxkIGJlIDxicj4NCiZndDsgJmd0OyBleGVjdXRlZC4gV2hlbiByb3V0ZXIgZXhlY3V0
ZSBydWxlIDIsIHdoaWNoIGFjdGlvbiBzaG91bGQgYmUNCmV4ZWN1dGVkPyA8YnI+DQomZ3Q7ICZn
dDsgT25seSByZWRpcmVjdD8gT3IvYW5kIHRyYWZmaWMtbWFya2luZz8gV2hpY2ggdHJhZmZpYy1y
YXRlIHNob3VsZA0KYmUgPGJyPg0KJmd0OyAmZ3Q7IHNlbGVjdGVkPyA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7IHJ1bGUgMSA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDt0cmFmZmljLXJhdGU6IDEwTWJwcyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZuYnNwOyAmbmJzcDt0cmFmZmljLW1hcmtpbmc6IERTQ1A9MTAgPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dHJhZmZpYy1hY3Rpb246IFQ9MSBTPTEg
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgcnVsZSAyIDxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtcmF0ZTog
MjBNYnBzIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3JlZGly
ZWN0OiBuZXh0aG9wID0gMTkyLjE2OC4xLjIgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyAmbmJzcDsgJm5ic3A7dHJhZmZpYy1hY3Rpb246IFQ9MCBTPTAgPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgcnVsZSAzIDxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtcmF0ZTogMzBNYnBzIDxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtbWFya2luZzogRFNDUD0z
MCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtyZWRpcmVjdDog
bmV4dGhvcCA9IDE5Mi4xNjguMi4yIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5i
c3A7ICZuYnNwO3RyYWZmaWMtYWN0aW9uOiBUPTEgUz0xICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsNCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgcnVsZSA0IDxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtcmF0ZTogNDBNYnBzIDxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3RyYWZmaWMtbWFya2lu
ZzogRFNDUD00MCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDt0
cmFmZmljLWFjdGlvbjogVD0wIFM9MCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAm
Z3Q7IElkciBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgSWRyQGlldGYub3JnPGJyPg0KJmd0
OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIDxicj4NCiZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7IENocmlzdG9waCBMb2li
bDxicj4NCiZndDsgJmd0OyBjQHRpeC5hdCB8IENMOC1SSVBFIHwgUEdQLUtleS1JRDogMHg0QjJD
MDA1NSB8IGh0dHA6Ly93d3cubmV4dGxheWVyLmF0DQo8L3R0PjwvZm9udD4NCg==
--=_alternative 002E3CC94825808B_=--


From nobody Fri Dec 16 11:10:30 2016
Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AB2129B95 for <idr@ietfa.amsl.com>; Fri, 16 Dec 2016 11:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 5tFzw__LMRSL for <idr@ietfa.amsl.com>; Fri, 16 Dec 2016 11:10:26 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0108.outbound.protection.outlook.com [104.47.41.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639BA129B87 for <idr@ietf.org>; Fri, 16 Dec 2016 11:10:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UTRRwZUEjqlcaT3Skc0FHwtzI2Kp/8UI+XljldDzEtM=; b=iHGoaRLeCbaIoGFoAu9TSLlsrd4bsEqYvVuquLsPzK/8f25r518GNP7uVJPkDkXqHlJRDMYVPQtKhyG01Vr1v+etOatL/BcMRnd91gfzekgY2DBq6+vy3+j33YnkG5vkh2QsosM0xdO1fxiozsOT+LU+MVwQluaHvWPmOCm/EVA=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; 
Received: from [172.29.107.193] (66.129.239.13) by CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.5; Fri, 16 Dec 2016 19:10:21 +0000
From: John Scudder <jgs@juniper.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B477DFE8-96FB-4F83-A578-D420FCCC0162"
Date: Fri, 16 Dec 2016 14:10:12 -0500
References: <2530302c-cab3-09b1-6c2d-39c2bd84ecf6@rfc-editor.org>
To: <idr@ietf.org>
Message-ID: <1A34F52B-0644-4B0E-81C9-74F24D68D9AE@juniper.net>
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Originating-IP: [66.129.239.13]
X-ClientProxiedBy: MWHPR10CA0055.namprd10.prod.outlook.com (10.169.238.17) To CO2PR05MB2504.namprd05.prod.outlook.com (10.166.95.150)
X-MS-Office365-Filtering-Correlation-Id: 4a884e94-459f-4e53-680b-08d425e72f38
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR05MB2504;
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 3:Xjdb+ND/bTOt6zgO/BsSwF0m+adddsiAHpqoZJFU6g/i0vUfJSUF2zX9aOm6sMoWWoVruAkfjqcUIGFAfT5zkBRD3nITJaM6nA98jzpT/3RrVtpPN6dmYBXELHCI5ZxgVSJCfDZwArhumRWqgQg6OP4TapMqcU/I3mSjgQ02O/w/9ETlklk0flUY9C1Z2QfAnuTyZNvkr5G5sAWiAmHd5bYm7Fy8ZcKRVsY0CdjtUsvkhct2Cnx0RE8qcMNO3f3hlrC41NqRYeCH0c6WoG89JQ==; 25:wfMwOGhug3H804jQ4AroLdzfVpGhlBajyjaz8g4MvrFe3W57/pYucYUTwyFkde84n59VC8aCuFWthxaMGgsbc2YZuxM0EHBY7SvPRk3Rt9B+MBYhtcsUsEY+W3fgKh8jWG05G2KwDudcQ1en47GmdePHm3kfG7vA8YoYCMLrz6d4t/85fuzh/GWArc7J4s5BTY83/tqPRy3LWQJPX3VrWI0tqDKogMcyiDml1RfqUzXBaq89IgCyf58/V/tzHpU9HSdEU3Ie4yvXwBQIfhYKx2rDFWnkNYU2INd7wMAQaqN+yYJGWhIs2IiTCjNr1u+QoubDQitQySDFicg0vZIImMA2UQ3YCCXTEXHUY35IS0q98DJVkwCq9r84Uu31httJjAwlCLqf+qaceqSqnCU/xB9YRLxH2e0ND/fYX2pweyfGBrxYYqgaHS0GEjv8xyff+5w7UaCM98vY0XrVkpO7sg==
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 31:O8mRDPRWeykvkIVJL3IEspjsrWoM1L/0Oz3xgzySTZN/d8dv3ed+TVSsLIt0KFTmWPehuFJ6Spu7vOm5MyPUvZhNkhHEyrhNYD+UITBM7eSADlyg2YWVYSN2BYO/9S/S95ZzPMsh/aZAvG52OPb5RyUyZYKGS4306RSpmAaE8QP66LHDKj2ozd5EiOl0+k3N/4C/oBn/jevuV0TjieOGiNE0JNWEVLkrqNt9bR0IOv9Urt7Vqw6o3KCngBVcSA+dwAJKbXkY0YQFiuhHQRGRgEV+H5XAYeuyGOwClrlq1cc=; 20:TpBxp87IQe1B5PEP7uXnH6ldxYoag8M9sGYmD6QNEt70o4rk07UkmJ9DYdC9ZdQYvcKYGw3Q6WNA785VzhFMHcZToRK/uH1nddFLqdV/xYKf+FDwRP+FBghZiR/XtfYFsbcUM+ukVECav9VEHfEoAEZgMU6pwDlRdqZjxDJ27bkRC/au8TvQ5E5ul9hk0EtpnOFGdcPdZGcUK62J8nIlaCYOWXtY+bI7SyJHgytotTumF5CtIhDmq3MUFZZ7ScvRGKb8E9ZUnGhDolZ+/r7SGCJjSg3e9lEtmQ9ETYHTurds51+CTir/v9KTcn48vRGldta5Wc+7fx5dxfttyoyWvvy3dwLNh9CIdvfdjp0aduT63s2aMUXtDbihvS+I+nBQX2EaxN9dbaMcl858qPMU5EtZ86M+c4Lox1bjM4LSUTsVqyK9uBMUhsiKVgaSj3cp+U4bO9z2FKY1+SQkdFOoPWZve3QUvUJwTqUt2tvY/BBXm97yOGfvBG5vwAfI71D2
X-Microsoft-Antispam-PRVS: <CO2PR05MB2504242A2CCB9EDA2E6F33D4AA9C0@CO2PR05MB2504.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CO2PR05MB2504; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2504; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 4:EHqkn2nwHxc5Xix3V/Cu6vo5j7JHCRRVU2/62lPkTlFfp/FpgxHvEuvSwueQX5m7P37b5OJLrT/WYrJ49POZ5bjbTazu4APR+fhlXF4DRK8WWdbeKs9HeOtbuRWfAXc8ltpRXRRaUedsfRNRI/T2GCygew5lzbF8mg4u8t0uN3H+WhD4DdpJ76G1XQVsvHNxTkDvK9y8OVdwWPZ645KEtif3lxGrL+PojjKqf3RuK8K9qaMhEWPDTiFEr735jL8lwwWP9OhbuUCOOhUJdFIGnGTL3rpQ1b18yjH485O0go1twGfKxeyn9xnSa0ujZrw4DCSmD0YKAWOSZHbbVY/O4sJEOK3P4xddb61QcG4HClnIImjct1OC1z/IOzey0V1h0/ZOWyyii+ER1wpkUkKLpgzTO3h0M+dlIQUkYito0cOai6Sv31UfitKQafk6VTa82kLxWqrawNdgUOf+8XKkvJEJ5NCvCXlx8Jd7G76tEoVPFZvK5aIiFWGQbWAvGEzWV9tLKqipssPhzFKYKIPB+Xxc1tQV8xgZl21dohCxqYe+7n+sWKvJkDYQWvoYcrYBtS7u5ndbEay9dEwFxM8H5KHsPl+Tgtc/TQO3Xk7s5aM=
X-Forefront-PRVS: 01583E185C
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(7916002)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(377454003)(53754006)(199003)(189002)(33656002)(36756003)(50986999)(106356001)(2351001)(76176999)(69556001)(82746002)(83716003)(86362001)(6916009)(90366009)(6666003)(606005)(25786008)(260700001)(101416001)(105586002)(5660300001)(110136003)(66066001)(97736004)(6486002)(77096006)(8676002)(38730400001)(6116002)(3846002)(7906003)(68736007)(7736002)(512954002)(189998001)(42186005)(2906002)(92566002)(50226002)(81156014)(57306001)(107886002)(81166006)(450100001)(84326002)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2504; H:[172.29.107.193]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2504; 23:JlDvn0YqRPg2MLVudfgQrnu2MqjSNhLOvfptjEMJd?= =?us-ascii?Q?rU142mW9kui0LaAfhA/kuWuQznouXyJyLql0yd5fa3rRfRVrQOefEfHwTJ+l?= =?us-ascii?Q?gjykn243gzQe72fVi9k9EW9/dGSI6ufDdKDx7yFaOfpMaBeNXrtmQIogilUK?= =?us-ascii?Q?P/G+wdKb8sw5qnr7WGYG1fUnvsY754pXqFDUrpIFcE67ZR+zgjWE3EKgojLv?= =?us-ascii?Q?jamuDvUrweSjJweuMqrZdT/8pYkmXU+fp8qjznmZ2i6/FXoh0kdtd+Bk3KCz?= =?us-ascii?Q?pvf/r58CWVIPrtnsr/AgsJ69AduDUxX5OZuVhtthZLZK1SNAvjpd9DEtdO/8?= =?us-ascii?Q?P77rNx8l4kqOogyLViUHUG1vJzo3ecmp0BGdGXZp4BMKc7vq7LXoYoUJ8rTw?= =?us-ascii?Q?qaJaBLYXKUXrkaATaO3P0tjN8lHIClfqJnTmpeBkwaDlH6nT0CDPpXyYDTbK?= =?us-ascii?Q?q5wfPFxhKKI/EPscL5uslqzOWVB2sZcygT6kCNMEFU2aXNlKkzuobptHjhsb?= =?us-ascii?Q?AsdPT8+xE62Qi6Hnu1g61uW4tRZZUEY+uUNJ5RkrPA6DrfQyTSlejy2PMhxV?= =?us-ascii?Q?Ay8nLGF1LiqCNy2f3OJ7eF06ATZ9+AtPCsxTSesbECpVibXsbF64vA2hY+zG?= =?us-ascii?Q?VUayESs0fhGTV/1Kr8i07owsx/xlNvWUbavkTROH4Ml/+QvugGcZKfjftBBH?= =?us-ascii?Q?iaLfTrnizminKebY2fdMRX9KMBmtm3ExQRBSp8h5mnnPvTntUg7fBRre+MNK?= =?us-ascii?Q?hRcYXj0qIWCv4xjrmjRpuB806J+ejw6000F0inR2vHrME9lg7UOVxwxO69gU?= =?us-ascii?Q?uIU8rMUcXQYcdkT4oNoBMEx1mao36e49NIaG9Op5vjUhZ9fMNlKsTaN8+Qhx?= =?us-ascii?Q?LDjf7MLFTtaIxnnLpqMovpxQiFmGcEmEB8TUbLe0kFmvpaXH49XVIs8zRE/d?= =?us-ascii?Q?GYulkaGobLxlBvq/irBUc2/mSdSffSFLJgGMqrLOCy6viAKIU/yh8KiDdYJa?= =?us-ascii?Q?Tl65B/OjJNKPiEgaUeQ8dkFXQdF6x5nzYWpvruLbV8+yMPisQlIPcHcceprz?= =?us-ascii?Q?V/A5dSx4JVsKnt6Fdck5L1szZkAK21MFT8/52cQ71pPjGSuzTkJrtAUn3loV?= =?us-ascii?Q?m8JJnkqruq79PhFztZeODEI4G/2okHGuMho3gsvbCkuYwQflMgowbEoXO7x5?= =?us-ascii?Q?zNWJZh+zFLRY3xv/6xtEgD7xPvrOi7ViKZlmwR0qaIPKBc+ra1/xBnc+9WZM?= =?us-ascii?Q?niBuTqIwBNzbJURo7jYfVTxGgrQ6EAfuU1KprvKOEGT6gODwqPx85+fwlKMI?= =?us-ascii?Q?Jth/pY7eQYl+wQg5CVNaNSOBuRXepmPNbjt2UgtaUEuvDRcZIoWheIHT7kA5?= =?us-ascii?Q?z9c6A=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 6:hevWy/CrPDx+Ev1CVzjq6i5VgTdtWfm1JC/3XQDNff519qVYKjvcKj/7CEdOld6RQXd11468hajKckIM6lkaEw896j+/FDypfFMedn3PRcHNrjcWVJh9g2Tv14/LMxjXumA7FUcIOWfafL9W4TUX065NdjnjbGfMW5pynqCC+OMeERBpMs1xL5f34d3xkYRBIvFf8pQ1G5RcZgfNI94ZeoBRlqXgM/nj9Xw1sTUrUvXhmaVC566BuojO+1PYTdVhxdQkvUqCIA+oBc23AgiLExeoFGzzKCK+0xYPWX7w4cMaRmun+efMTFAE7UyZ0QOWaz5g0iS4abTJjR2a+m8r1/gZ5jy/kV7NL01iAZ9lv0WDJVPhrlxzWd+07RGAUUA3upyiHbDrPFmm3mgkR4R5/M+xqfBqv0nkkbCI8sZFcyIi9Xic8+siGDv2qfEY+qY45g+fL8nfDESv8GEUJSHWuA==; 5:8lU5an8n1bfiM+uSRUg1I50x0Cq62JUAW93ekQ+O1T0MzpHBmve1UAkEAyafTZz3z59EE3xhvWVmBt2vOP5TyQ78SXeb7GxPXiTykIpHOZPYMvtAyMHMSIX7KQvEIstaYTZ/+jit1DVGCwvUqL8fKF5CpY6bEmLDAr3IAhjZyTM=; 24:IRvqlGr+/KR5/MnuFo7GWaAH+0VVw2KEHbHgPpCMdw3gIqzddZ10J1B5irvxBZ1PH6DDxjDuPWw0vjIgJjJQ0EAbf0G3LIq59+Kj2m7d1no=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2504; 7:G9wjtjTjhzaw9IVdL+1qptsxn5GpEzok5WTpsLVf5PDlBwiXaiIVzlEAUFCL7aGW18C5SXaKTfdwSAhQLOOaqtZa76XzDwz9UcIxWSJyN9MtHrbjRyNDaUJetL2F21E1y6son1pqZ1CYdI2mMkS8DxdOMm6DKouX3DnSwqJjzPypSUnjHeDSLUsxQ8Uj+H0MoaqwaVCtCUl/Z2szDxCUvKuoTJw4FA3CRPYSMr5LtJplJZ7+JupBpqqzlFJvN/AI+n33jU4g7PO/A192MPMAJPxESqkt772MZoPiXb+EZCMdTWF/gQbrzLmR8YEcFrYcOH3zraRUUNHMU9Fr8lUj5HKuTW2Ha0t/SPwYr1kVY6SV3vvEUPEzKlvz6Yr5lk1iurAHQMLgzvJKBUr8YNIdLwGuPGDWHMXslXnPPCtjXEe73IMPIp0d+uKNMUBeoYMVdiFmUdnomdE8FpFl1M2WZw==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2016 19:10:21.8564 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2504
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nYHNN4XiOY1RQKB3eWrmZiwof78>
Subject: [Idr] Internet Draft authors, news you can use [was: The RFC Format docs are now RFCs]
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2016 19:10:29 -0000

--Apple-Mail=_B477DFE8-96FB-4F83-A578-D420FCCC0162
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Everybody,

=46rom the maybe-you-didn't-notice department comes this exciting =
information about RFC formats and formatting. This will probably end up =
mattering for everyone who authors Internet Drafts, which is many of =
you. There's plenty of holiday reading for you below. To whet your =
appetite, this excerpt from the abstract of RFC 7990, "RFC Format =
Framework" (emphasis mine):=20

"the canonical format of the RFC Series will be transitioning from =
plain-text ASCII to XML using the xml2rfc version 3 vocabulary; =
different publication formats will be rendered from that base document. =
With these changes comes an increase in complexity for authors, =
consumers, and the publisher of RFCs."=20

Enjoy!

--John

> Begin forwarded message:
>=20
> From: "Heather Flanagan (RFC Series Editor)" <rse@rfc-editor.org>
> Subject: The RFC Format docs are now RFCs
> Date: December 16, 2016 at 12:14:27 PM EST
> To: rfc-interest@rfc-editor.org, ietf@ietf.org
>=20
> Hello all,
>=20
> The RFC Format requirements documents were published this morning. =
This represents an enormous amount of work on the part of the RFC Format =
Design Team, and an enormous amount of patience and feedback from the =
community. Of course, the work isn't quite done - all of these RFCs will =
undergo a -bis cycle so we can document the "as built" instead of just =
the "as proposed." But regardless of the amount of work still to come, =
this is a big milestone for the project!=20
> So, thank you all, and stay tuned for the next steps of code =
development, testing, and collecting feedback!
>=20
> -Heather Flanagan, RSE
> The RFC Format Design Team:
>=20
> Nevil Brownlee (ISE)
> Heather Flanagan (RSE)
> Tony Hansen
> Joe Hildebrand
> Paul Hoffman
> Ted Lemon
> Julian Reschke
> Adam Roach
> Alice Russo
> Robert Sparks (Tools Team liaison)
> Dave Thaler
>=20
> The RFCs, in suggested reading order:
> "RFC Format Framework " - https://www.rfc-editor.org/info/rfc7990 =
<https://www.rfc-editor.org/info/rfc7990>
> "The "xml2rfc" Version 3 Vocabulary" - =
https://www.rfc-editor.org/info/rfc7991 =
<https://www.rfc-editor.org/info/rfc7991>
> "HTML Format for RFCs" - https://www.rfc-editor.org/info/rfc7992 =
<https://www.rfc-editor.org/info/rfc7992>
> "Cascading Style Sheets (CSS) Requirements for RFCs" - =
https://www.rfc-editor.org/info/rfc7993 =
<https://www.rfc-editor.org/info/rfc7993>
> "Requirements for Plain-Text RFCs" - =
https://www.rfc-editor.org/info/rfc7994 =
<https://www.rfc-editor.org/info/rfc7994>
> "PDF Format for RFCs" - https://www.rfc-editor.org/info/rfc7995 =
<https://www.rfc-editor.org/info/rfc7995>
> "SVG Drawings for RFCs: SVG 1.2 RFC" - =
https://www.rfc-editor.org/info/rfc7996 =
<https://www.rfc-editor.org/info/rfc7996>
> "The Use of Non-ASCII Characters in RFCs" - =
https://www.rfc-editor.org/info/rfc7997 =
<https://www.rfc-editor.org/info/rfc7997>
> ""xml2rfc" Version 3 Preparation Tool Description" - =
https://www.rfc-editor.org/info/rfc7997 =
<https://www.rfc-editor.org/info/rfc7997>

--Apple-Mail=_B477DFE8-96FB-4F83-A578-D420FCCC0162
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Hi Everybody,<div class=3D""><br class=3D""></div><div =
class=3D"">=46rom the maybe-you-didn't-notice department comes this =
exciting information about RFC formats and formatting. This will =
probably end up mattering for everyone who authors Internet Drafts, =
which is many of you. There's plenty of holiday reading for you below. =
To whet your appetite, this excerpt from the abstract of RFC 7990, "RFC =
Format Framework" (emphasis mine):&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">"the canonical format of the RFC Series =
will be transitioning from plain-text ASCII to XML using the xml2rfc =
version 3 vocabulary; different&nbsp;publication formats will be =
rendered from that base document. <b class=3D"">With these changes comes =
an increase in complexity for authors</b>, consumers,&nbsp;and the =
publisher of RFCs."&nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D"">Enjoy!</div><div class=3D""><br class=3D""></div><div =
class=3D"">--John</div><div class=3D""><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">Begin forwarded =
message:</div><br class=3D"Apple-interchange-newline"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;" class=3D""><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif; =
color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">From: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D"">"Heather Flanagan (RFC Series =
Editor)" &lt;<a href=3D"mailto:rse@rfc-editor.org" =
class=3D"">rse@rfc-editor.org</a>&gt;<br class=3D""></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;" class=3D""><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif; =
color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Subject: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D""><b class=3D"">The RFC Format =
docs are now RFCs</b><br class=3D""></span></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" =
class=3D""><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b =
class=3D"">Date: </b></span><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" =
class=3D"">December 16, 2016 at 12:14:27 PM EST<br =
class=3D""></span></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span =
style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">To: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D""><a =
href=3D"mailto:rfc-interest@rfc-editor.org" =
class=3D"">rfc-interest@rfc-editor.org</a>, <a =
href=3D"mailto:ietf@ietf.org" class=3D"">ietf@ietf.org</a><br =
class=3D""></span></div><br class=3D""><div class=3D"">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" =
class=3D"">
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""><p class=3D"">Hello=
 all,</p><p class=3D"">The RFC Format requirements documents were =
published this
      morning. This represents an enormous amount of work on the part of
      the RFC Format Design Team, and an enormous amount of patience and
      feedback from the community. Of course, the work isn't quite done
      - all of these RFCs will undergo a -bis cycle so we can document
      the "as built" instead of just the "as proposed." But regardless
      of the amount of work still to come, this is a big milestone for
      the project! <br class=3D"">
    </p><p class=3D"">So, thank you all, and stay tuned for the next =
steps of code
      development, testing, and collecting feedback!</p><p =
class=3D"">-Heather Flanagan, RSE<br class=3D"">
    </p><p class=3D"">The RFC Format Design Team:</p>
    <ul class=3D"">
      <li class=3D"">Nevil Brownlee (ISE)</li>
      <li class=3D"">Heather Flanagan (RSE)</li>
      <li class=3D"">Tony Hansen</li>
      <li class=3D"">Joe Hildebrand</li>
      <li class=3D"">Paul Hoffman</li>
      <li class=3D"">Ted Lemon</li>
      <li class=3D"">Julian Reschke</li>
      <li class=3D"">Adam Roach</li>
      <li class=3D"">Alice Russo</li>
      <li class=3D"">Robert Sparks (Tools Team liaison)</li>
      <li class=3D"">Dave Thaler </li>
    </ul><p class=3D""><br class=3D"">
    </p><p class=3D"">The RFCs, in suggested reading order:<br class=3D"">=

    </p>
    <ul class=3D"">
      <li class=3D"">"RFC Format Framework " -
        <a href=3D"https://www.rfc-editor.org/info/rfc7990" =
class=3D"moz-txt-link-freetext">https://www.rfc-editor.org/info/rfc7990</a=
></li>
      <li class=3D"">"The "xml2rfc" Version 3 Vocabulary" -
        <a href=3D"https://www.rfc-editor.org/info/rfc7991" =
class=3D"moz-txt-link-freetext">https://www.rfc-editor.org/info/rfc7991</a=
></li>
      <li class=3D"">"HTML Format for RFCs" -
        <a href=3D"https://www.rfc-editor.org/info/rfc7992" =
class=3D"moz-txt-link-freetext">https://www.rfc-editor.org/info/rfc7992</a=
></li>
      <li class=3D"">"Cascading Style Sheets (CSS) Requirements for =
RFCs" -
        <a href=3D"https://www.rfc-editor.org/info/rfc7993" =
class=3D"moz-txt-link-freetext">https://www.rfc-editor.org/info/rfc7993</a=
></li>
      <li class=3D"">"Requirements for Plain-Text RFCs" -
        <a href=3D"https://www.rfc-editor.org/info/rfc7994" =
class=3D"moz-txt-link-freetext">https://www.rfc-editor.org/info/rfc7994</a=
></li>
      <li class=3D"">"PDF Format for RFCs" -
        <a href=3D"https://www.rfc-editor.org/info/rfc7995" =
class=3D"moz-txt-link-freetext">https://www.rfc-editor.org/info/rfc7995</a=
></li>
      <li class=3D"">"SVG Drawings for RFCs: SVG 1.2 RFC" -
        <a href=3D"https://www.rfc-editor.org/info/rfc7996" =
class=3D"moz-txt-link-freetext">https://www.rfc-editor.org/info/rfc7996</a=
></li>
      <li class=3D"">"The Use of Non-ASCII Characters in RFCs" -
        <a href=3D"https://www.rfc-editor.org/info/rfc7997" =
class=3D"moz-txt-link-freetext">https://www.rfc-editor.org/info/rfc7997</a=
></li>
      <li class=3D"">""xml2rfc" Version 3 Preparation Tool Description" =
-
        <a href=3D"https://www.rfc-editor.org/info/rfc7997" =
class=3D"moz-txt-link-freetext">https://www.rfc-editor.org/info/rfc7997</a=
></li>
    </ul>
  </div>

</div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_B477DFE8-96FB-4F83-A578-D420FCCC0162--


From nobody Sat Dec 17 04:01:29 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA993129474; Sat, 17 Dec 2016 04:01:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148197608669.11691.1779978995232151866.idtracker@ietfa.amsl.com>
Date: Sat, 17 Dec 2016 04:01:26 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dnBHaFdxcuG3ZRa1OlI5HPOOgLc>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-deprecate-30-31-129-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2016 12:01:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 234
        Author          : Job Snijders
	Filename        : draft-ietf-idr-deprecate-30-31-129-01.txt
	Pages           : 3
	Date            : 2016-12-17

Abstract:
   This document requests IANA to mark BGP path attribute values 30, 31,
   129, 241, 242, and 243 as "deprecated".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-30-31-129/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-deprecate-30-31-129-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-deprecate-30-31-129-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Dec 18 12:25:54 2016
Return-Path: <joelja@bogus.com>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 437851296B5; Sun, 18 Dec 2016 12:25:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Joel Jaeggli" <joelja@bogus.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148209275326.6354.7053840631804958155.idtracker@ietfa.amsl.com>
Date: Sun, 18 Dec 2016 12:25:53 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZKdl5rgYBvDzmuYqEw64tIFvhmE>
Cc: idr@ietf.org, draft-ietf-idr-large-community@ietf.org, idr-chairs@ietf.org
Subject: [Idr] Joel Jaeggli's Yes on draft-ietf-idr-large-community-11: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Dec 2016 20:25:53 -0000

Joel Jaeggli has entered the following ballot position for
draft-ietf-idr-large-community-11: Yes

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-idr-large-community/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

High-time we did this thanks.

I think the network reviewers suggestion to leave in the implmentation
status is a fine one. it does naturally capture only a moment in time. 
but since it points to useful examples of implmentation that's good.



From nobody Mon Dec 19 11:07:09 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D34931295B4; Mon, 19 Dec 2016 11:07:04 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148217442486.12876.12055459116674694688.idtracker@ietfa.amsl.com>
Date: Mon, 19 Dec 2016 11:07:04 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1fJhiSzGyhRCweDGfQeNt1JLCIc>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-aspath-orf-13.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2016 19:07:05 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : AS Path Based Outbound Route Filter for BGP-4
        Authors         : Susan Hares
                          Keyur Patel
	Filename        : draft-ietf-idr-aspath-orf-13.txt
	Pages           : 7
	Date            : 2016-12-19

Abstract:
   This document defines a new Outbound Router Filter type for BGP,
   termed "Aspath Outbound Route Filter", that can be used to perform
   aspath based route filtering.  This ORF-type supports aspath based
   route filtering as well as regular expression based matching, for
   address groups.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-aspath-orf/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-aspath-orf-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-aspath-orf-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Dec 19 11:54:15 2016
Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D79B12960B for <idr@ietfa.amsl.com>; Mon, 19 Dec 2016 11:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level: 
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
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 Mr4TqgYMQHce for <idr@ietfa.amsl.com>; Mon, 19 Dec 2016 11:54:13 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C22C812960A for <idr@ietf.org>; Mon, 19 Dec 2016 11:54:12 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.7.237; 
From: "Susan Hares" <shares@ndzh.com>
To: "'John Scudder'" <jgs@juniper.net>
References: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> <F5977A01-0018-432C-B829-6A7B4695A667@juniper.net> <76AD4ADF-A14F-4CD4-BF43-8DD01E60E390@juniper.net>
In-Reply-To: <76AD4ADF-A14F-4CD4-BF43-8DD01E60E390@juniper.net>
Date: Mon, 19 Dec 2016 14:50:57 -0500
Message-ID: <012a01d25a31$38005950$a8010bf0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_012B_01D25A07.4F2B89D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHj8zmFvh1jk/WZ0RLUyz06hRSFGgMC6nFTANxaQOagzYAwYA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/sRlVKBaoao84mVUnZvMOR_MhfXo>
Cc: 'idr wg' <idr@ietf.org>
Subject: Re: [Idr] Old WGLC for draft-ietf-idr-bgp-gr-notification [was: Re: WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14]
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2016 19:54:14 -0000

This is a multipart message in MIME format.

------=_NextPart_000_012B_01D25A07.4F2B89D0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

John:=20

=20

This draft was waiting for 2 implementations.  We were waiting for a =
confirmation from Cisco.   Perhaps Jakob can help us with the status the =
implementation of draft-ietf-idr-bgp-gr-notification in IOS =
implementation. =20

=20

Sue=20

=20

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder
Sent: Saturday, December 10, 2016 10:05 PM
To: John Scudder
Cc: idr wg; Susan Hares
Subject: Re: [Idr] Old WGLC for draft-ietf-idr-bgp-gr-notification [was: =
Re: WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to =
6/10/14]

=20

By the way, I would like to encourage implementors to update the (quite =
dated) implementation report at =
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-gr-notification%20=
implementations

=20

Thanks,

--John


On Dec 10, 2016, at 2:50 PM, John Scudder <jgs@juniper.net> wrote:

Hi Everybody,=20

=20

My mistake, the WGLC wasn't in 2015, it was in 2014 and the last traffic =
to the thread was 2015 :-o. I think that under the circumstances we =
probably have to do another one, although I leave the final decision to =
my co-chair.

=20

FYI the diff from the version that was originally WGLC'd to the current =
one =
is:https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-idr-bgp-gr-notification=
-02 =
<http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-idr-bgp-gr-notification-02=
&url2=3Ddraft-ietf-idr-bgp-gr-notification-09> =
&url2=3Ddraft-ietf-idr-bgp-gr-notification-09. I believe this resolves =
all issues that were raised.

=20

Thanks,

=20

--John

=20

On May 27, 2014, at 1:19 PM, Susan Hares <shares@ndzh.com> wrote:

=20

Working Group,

=20

This is to begin a 2 week WG LC for =
draft-ietf-idr-bgp-gr-notification-02.txt which will end on 6/10/2014.  =
Please put within your comments:  =E2=80=9Csupport=E2=80=9D or =
=E2=80=9Cno-support=E2=80=9D for WG LC.=20

=20

Jeff Haas comments that the most recent changes reflect implementation =
experience and some word smithing.  There is also a minor clarification =
in the NOTIFICATION message with respect to including a data byte so the =
original reason for the event can be propagated.  (See sec. 3.1 in the =
diff.)

=20

The abstract is below.=20

=20

Sue Hares

=20

=20

----------

=20

Abstract:

   The current BGP Graceful Restart mechanism limits the usage of BGP

   Graceful Restart to BGP protocol messages other than a BGP

   NOTIFICATION message.  This document defines an extension to the BGP

   Graceful Restart that permits the Graceful Restart procedures to be

   performed when the BGP speaker receives a BGP NOTIFICATION Message.

   This document also defines a new BGP NOTIFICATION Cease Error subcode

   to prevent BGP speakers supporting the extension defined in this

   document from performing a Graceful Restart.

=20

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


------=_NextPart_000_012B_01D25A07.4F2B89D0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 14 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>John: <o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>This draft was waiting for 2 implementations.=C2=A0 We were waiting =
for a confirmation from Cisco. =C2=A0=C2=A0Perhaps Jakob can help us =
with the status the implementation of draft-ietf-idr-bgp-gr-notification =
in IOS implementation. =C2=A0<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Sue <o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><div><div =
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
Idr [mailto:idr-bounces@ietf.org] <b>On Behalf Of </b>John =
Scudder<br><b>Sent:</b> Saturday, December 10, 2016 10:05 =
PM<br><b>To:</b> John Scudder<br><b>Cc:</b> idr wg; Susan =
Hares<br><b>Subject:</b> Re: [Idr] Old WGLC for =
draft-ietf-idr-bgp-gr-notification [was: Re: WG LC =
draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to =
6/10/14]<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal>By the =
way, I would like to encourage implementors to update the (quite =
dated)&nbsp;implementation report at&nbsp;<a =
href=3D"https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-gr-notific=
ation%20implementations">https://trac.ietf.org/trac/idr/wiki/draft-ietf-i=
dr-bgp-gr-notification%20implementations</a><o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Thanks,<br><br>--John<o:p></o:p></p></div><div><p =
class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>On Dec 10, 2016, at =
2:50 PM, John Scudder &lt;<a =
href=3D"mailto:jgs@juniper.net">jgs@juniper.net</a>&gt; =
wrote:<o:p></o:p></p></div><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoNormal>Hi Everybody, <o:p></o:p></p><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>My mistake, the WGLC wasn't in 2015, it was in 2014 =
and the last traffic to the thread was 2015 :-o. I think that under the =
circumstances we probably have to do another one, although I leave the =
final decision to my co-chair.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>FYI the diff from the version that was originally =
WGLC'd to the current one is:https://<a =
href=3D"http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-idr-bgp-gr-notifica=
tion-02&amp;url2=3Ddraft-ietf-idr-bgp-gr-notification-09">www.ietf.org/rf=
cdiff?url1=3Ddraft-ietf-idr-bgp-gr-notification-02&amp;url2=3Ddraft-ietf-=
idr-bgp-gr-notification-09</a>. I believe this resolves all issues that =
were raised.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Thanks,<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>--John<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoNormal>On May 27, 2014, at 1:19 PM, Susan Hares &lt;<a =
href=3D"mailto:shares@ndzh.com">shares@ndzh.com</a>&gt; =
wrote:<o:p></o:p></p></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p =
class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Working Group,</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>This is to begin a =
2 week WG LC for draft-ietf-idr-bgp-gr-notification-02.txt which will =
end on 6/10/2014. &nbsp;Please put within your comments:&nbsp; =
=E2=80=9Csupport=E2=80=9D or =E2=80=9Cno-support=E2=80=9D for WG =
LC.<span class=3Dapple-converted-space>&nbsp;</span></span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>Jeff Haas comments =
that the most recent changes reflect implementation experience and some =
word smithing.&nbsp; There is also a minor clarification in the =
NOTIFICATION message with respect to including a data byte so the =
original reason for the event can be propagated.&nbsp; (See sec. 3.1 in =
the diff.)</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>The abstract is =
below.<span class=3Dapple-converted-space>&nbsp;</span></span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>Sue =
Hares</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>----------</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Abstract:</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; The =
current BGP Graceful Restart mechanism limits the usage of =
BGP</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; =
Graceful Restart to BGP protocol messages other than a BGP</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; =
NOTIFICATION message.&nbsp; This document defines an extension to the =
BGP</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; =
Graceful Restart that permits the Graceful Restart procedures to =
be</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; =
performed when the BGP speaker receives a BGP NOTIFICATION =
Message.</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; This =
document also defines a new BGP NOTIFICATION Cease Error =
subcode</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; to =
prevent BGP speakers supporting the extension defined in =
this</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; =
document from performing a Graceful Restart.</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p>=
</span></p></div></div></blockquote></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div></blockquote><blockquo=
te style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoNormal>_______________________________________________<br>Idr =
mailing list<br><a href=3D"mailto:Idr@ietf.org">Idr@ietf.org</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/idr">https://www.ietf.org/m=
ailman/listinfo/idr</a><o:p></o:p></p></div></blockquote></div></body></h=
tml>
------=_NextPart_000_012B_01D25A07.4F2B89D0--


From nobody Wed Dec 21 22:30:57 2016
Return-Path: <jie.dong@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98841293EC; Wed, 21 Dec 2016 22:30:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.32
X-Spam-Level: 
X-Spam-Status: No, score=-7.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 lj3Dd9nWpbqg; Wed, 21 Dec 2016 22:30:51 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF411294F9; Wed, 21 Dec 2016 22:30:50 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDB02805; Thu, 22 Dec 2016 06:30:48 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 22 Dec 2016 06:30:47 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 22 Dec 2016 14:30:42 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Solicit review comments on draft-dong-pce-discovery-proto-bgp-06
Thread-Index: AdJcGv2xOMFgKKmPTFmp5RqGgPlWUg==
Date: Thu, 22 Dec 2016 06:30:42 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C92793566993@NKGEML515-MBX.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.130.151.75]
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C92793566993NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.585B7319.005A, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8f3c87582e65688bd43ba48ef4a5e9e8
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/e9h2bUOMUyNH8-nE12XZtPtcdeI>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: [Idr] Solicit review comments on draft-dong-pce-discovery-proto-bgp-06
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2016 06:30:53 -0000

--_000_76CD132C3ADEF848BD84D028D243C92793566993NKGEML515MBXchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

draft-dong-pce-discovery-proto-bgp defines extensions to BGP for the advert=
isement of PCE discovery information. After several revisions, the draft is=
 now getting stable. As suggested by the PCE chair, the authors would like =
to collect review comments also from the IDR WG.

Here is the link to the latest version:

https://tools.ietf.org/html/draft-dong-pce-discovery-proto-bgp-06

Comments are welcome.

Best regards,
Jie (on behalf of coauthors)


--_000_76CD132C3ADEF848BD84D028D243C92793566993NKGEML515MBXchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"#0563C1" vlink=3D"#954F72" style=3D"text-justi=
fy-trim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US">Dear all, <o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">draft-dong-pce-discovery-proto-=
bgp defines extensions to BGP for the advertisement of PCE discovery inform=
ation. After several revisions, the draft is now getting stable. As suggest=
ed by the PCE chair, the authors would
 like to collect review comments also from the IDR WG. <o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Here is the link to the latest =
version: <o:p>
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><a href=3D"https://tools.ietf.o=
rg/html/draft-dong-pce-discovery-proto-bgp-06">https://tools.ietf.org/html/=
draft-dong-pce-discovery-proto-bgp-06</a><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Comments are welcome.<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Best regards,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Jie (on behalf of coauthors)<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_76CD132C3ADEF848BD84D028D243C92793566993NKGEML515MBXchi_--


From nobody Thu Dec 29 15:45:53 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F1D1296FD; Thu, 29 Dec 2016 15:45:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148305515206.30266.395384322080624399.idtracker@ietfa.amsl.com>
Date: Thu, 29 Dec 2016 15:45:52 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QTmCsywaJkpwF0Fkm6q8rUHrseA>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-deprecate-30-31-129-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Dec 2016 23:45:52 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Deprecation of BGP Path Attribute values 30, 31, 129, 241, 242, and 243
        Author          : Job Snijders
	Filename        : draft-ietf-idr-deprecate-30-31-129-02.txt
	Pages           : 3
	Date            : 2016-12-29

Abstract:
   This document requests IANA to mark BGP path attribute values 30, 31,
   129, 241, 242, and 243 as "deprecated".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-30-31-129/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-deprecate-30-31-129-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-deprecate-30-31-129-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Dec 29 18:49:08 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B31129450; Thu, 29 Dec 2016 18:49:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148306614259.30266.6594976251638187780.idtracker@ietfa.amsl.com>
Date: Thu, 29 Dec 2016 18:49:02 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KPLJN5ug_v36iU_oxbhRbuop7Do>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-05.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2016 02:49:02 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : Dissemination of Flow Specification Rules for L2 VPN
        Authors         : Weiguo Hao
                          Qiandeng Liang
                          Stephane Litkowski
                          Shunwan Zhuang
	Filename        : draft-ietf-idr-flowspec-l2vpn-05.txt
	Pages           : 13
	Date            : 2016-12-29

Abstract:
   This document defines BGP flow-spec extension for Ethernet traffic
   filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for
   dissemination traffic filtering information in an L2VPN environment.
   A new subset of component types and extended community also are
   defined.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-l2vpn/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-l2vpn-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Dec 29 22:53:42 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2964F126BF7; Thu, 29 Dec 2016 22:53:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148308081412.30274.12144761765551096274.idtracker@ietfa.amsl.com>
Date: Thu, 29 Dec 2016 22:53:34 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kif2OnYzLL0UGFa97c9l34U42EU>
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-10.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2016 06:53:34 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing of the IETF.

        Title           : IPv6 Extensions for Route Target Distribution
        Authors         : Keyur Patel
                          Robert Raszuk
                          Martin Djernaes
                          Jie Dong
                          Mach(Guoyi) Chen
	Filename        : draft-ietf-idr-bgp-ipv6-rt-constrain-10.txt
	Pages           : 6
	Date            : 2016-12-29

Abstract:
   The current route target distribution specification as described in
   [RFC 4684] defines Route Target NLRIs of maximum length of 12 bytes.
   The IPv6 specific Route Target extended community is defined in [RFC
   5701] as length of 20 bytes.  Since the current specification only
   supports prefixes of maximum length of 12 bytes, the lack of an IPv6
   specific Route Target reachability information may be a problem when
   an operator wants to use this application in a pure IPv6 environment.
   This document defines an extension that allows BGP to exchange longer
   length IPv6 Route Target prefixes.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ipv6-rt-constrain/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ipv6-rt-constrain-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ipv6-rt-constrain-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/