From idr-bounces@ietf.org Mon Oct 09 07:44:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GWtVE-0008LM-S3; Mon, 09 Oct 2006 07:41:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GWtVD-0008LG-S6
	for idr@ietf.org; Mon, 09 Oct 2006 07:40:59 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWtV7-00026h-Nl
	for idr@ietf.org; Mon, 09 Oct 2006 07:40:59 -0400
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J6V00KTP9V6UC@szxga03-in.huawei.com> for
	idr@ietf.org; Mon, 09 Oct 2006 19:42:42 +0800 (CST)
Received: from M55527 ([10.111.12.134])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J6V000449V55T@szxga03-in.huawei.com> for
	idr@ietf.org; Mon, 09 Oct 2006 19:42:42 +0800 (CST)
Date: Mon, 09 Oct 2006 19:31:20 +0800
From: Mach Chen <mach@huawei.com>
Subject: Re: [Idr] draft-ietf-idr-as-pathlimit-02 status, path forward
To: Yakov Rekhter <yakov@juniper.net>, idr@ietf.org
Message-id: <009001c6eb96$7150a490$860c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <200609261812.k8QICQg95521@merlot.juniper.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: skh@nexthop.com, yakov@juniper.net
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Yes
----- Original Message ----- 
From: "Yakov Rekhter" <yakov@juniper.net>
To: <idr@ietf.org>
Cc: <skh@nexthop.com>; <yakov@juniper.net>
Sent: Wednesday, September 27, 2006 2:12 AM
Subject: [Idr] draft-ietf-idr-as-pathlimit-02 status, path forward


> Folks,
> 
> This e-mail is to find if there is a consensus within the IDR WG for a
> request for an early allocation of a new BGP attribute code point
> as specified in draft-ietf-idr-as-pathlimit-02.
> 
> Please send your comments on this request. The deadline for comments
> is Oct 10, 2006.
> 
> Yakov.
> 
> P.S. Please remember that silence does not count (either way).
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www1.ietf.org/mailman/listinfo/idr
>

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



From idr-bounces@ietf.org Mon Oct 09 08:11:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GWty6-0000kQ-BV; Mon, 09 Oct 2006 08:10:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GWty5-0000kJ-AP
	for idr@ietf.org; Mon, 09 Oct 2006 08:10:49 -0400
Received: from rose.ctd.hcltech.com ([202.54.64.23])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWty3-0000rP-Bu
	for idr@ietf.org; Mon, 09 Oct 2006 08:10:49 -0400
X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited]
Content-Class: urn:content-classes:message
Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com
	with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Oct 2006 17:40:40 +0530
Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19)
	id <T58XBQWN>; Mon, 9 Oct 2006 17:40:40 +0530
Message-ID: <434F1CE611459F45BBC351FEB5A83F43021D9332@kavithai.ctd.hcltech.com>
From: "Kavitha G  - TLS ,Chennai" <KavithaG@hcl.in>
To: <idr@ietf.org>
Date: Mon, 9 Oct 2006 17:39:04 +0530 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-OriginalArrivalTime: 09 Oct 2006 12:10:40.0637 (UTC)
	FILETIME=[F00B52D0:01C6EB9B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d9238570526f12788af3d33c67f37625
Subject: [Idr] 4-Byte ASN - subtype for extended community
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0418947209=="
Errors-To: idr-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0418947209==
Content-Class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6EB9B.B6725AE6"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6EB9B.B6725AE6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="Windows-1252"

For BGP 4-octet AS, what is the sub-type value to be used in extended
communities?

=20

In the draft 4-octet AS specific Extended community, the subtype are =
given
for Route Target and Route Origin.=20

When there is no support for BGP-MPLS-VPN, how this 4-octet AS specific =
can
be sent in the extended community attribute. [i.e., For general 4-octet =
AS
number in extended comm, which is used similar to community attribute]=20

=20

Is there a subtype mentioned for this kind of extended community usage =
or is
it planned for future drafts=20

=20

Thanks,

Kavitha

=20

=20

=20
DISCLAIMER=20
The contents of this e-mail and any attachment(s) are confidential and =
intended for the=20

named recipient(s) only. It shall not attach any liability on the =
originator or HCL or its=20

affiliates. Any views or opinions presented in this email are solely =
those of the author and=20

may not necessarily reflect the opinions of HCL or its affiliates. Any =
form of reproduction,=20

dissemination, copying, disclosure, modification, distribution and / or =
publication of this=20

message without the prior written consent of the author of this e-mail =
is strictly=20

prohibited. If you have received this email in error please delete it =
and notify the sender=20

immediately. Before opening any mail and attachments please check them =
for viruses and=20

defect.

------_=_NextPart_001_01C6EB9B.B6725AE6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset="Windows-1252"

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>For BGP 4-octet AS, what is the sub-type value to be =
used in
extended communities?</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In the draft 4-octet AS specific Extended community, =
the subtype
are given for Route Target and Route Origin. </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>When there is no support for BGP-MPLS-VPN, how this =
4-octet AS
specific can be sent in the extended community attribute. [i.e., For =
general 4-octet
AS number in extended comm, which is used similar to community =
attribute] </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Is there a subtype mentioned for this kind of =
extended
community usage or is it planned for future drafts </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Kavitha</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<div><p><font size=3D"1">
<a><b>DISCLAIMER:<br>=20
The contents of this e-mail and any attachment(s) are confidential and =
intended for the=20

named recipient(s) only. It shall not attach any liability on the =
originator or HCL or its=20

affiliates. Any views or opinions presented in this email are solely =
those of the author and=20

may not necessarily reflect the opinions of HCL or its affiliates. Any =
form of reproduction,=20

dissemination, copying, disclosure, modification, distribution and / or =
publication of this=20

message without the prior written consent of the author of this e-mail =
is strictly=20

prohibited. If you have received this email in error please delete it =
and notify the sender=20

immediately. Before opening any mail and attachments please check them =
for viruses and=20

defect.
</a>

</font></p></div>
</body>

</html>

------_=_NextPart_001_01C6EB9B.B6725AE6--


--===============0418947209==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0418947209==--




From idr-bounces@ietf.org Mon Oct 09 09:51:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GWvUm-0003Po-76; Mon, 09 Oct 2006 09:48:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvUl-0003Pj-Cq
	for idr@ietf.org; Mon, 09 Oct 2006 09:48:39 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWvUj-0004CL-2V
	for idr@ietf.org; Mon, 09 Oct 2006 09:48:39 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id
	k99DmU1Z093154; Mon, 9 Oct 2006 06:48:30 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k99DmUu61917;
	Mon, 9 Oct 2006 06:48:30 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Message-Id: <200610091348.k99DmUu61917@merlot.juniper.net>
To: "Kavitha G - TLS ,Chennai" <KavithaG@hcl.in>
Subject: Re: [Idr] 4-Byte ASN - subtype for extended community 
In-Reply-To: Your message of "Mon, 09 Oct 2006 17:39:04 +0530."
	<434F1CE611459F45BBC351FEB5A83F43021D9332@kavithai.ctd.hcltech.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <94795.1160401710.1@juniper.net>
Date: Mon, 09 Oct 2006 06:48:30 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Kavitha,

> For BGP 4-octet AS, what is the sub-type value to be used in extended
> communities?
>
> In the draft 4-octet AS specific Extended community, the subtype are
> given for Route Target and Route Origin.
> 
> When there is no support for BGP-MPLS-VPN, how this 4-octet AS specific 
> can be sent in the extended community attribute. [i.e., For general 
> 4-octet AS number in extended comm, which is used similar to community 
> attribute]

The IANA would need to create a registry (as specified in the
IANA Consideration section of draft-rekhter-as4octet-ext-community),
and then one would need to request an assignment from that registry.
  
Yakov.

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



From idr-bounces@ietf.org Mon Oct 09 14:47:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GX071-0004f0-NR; Mon, 09 Oct 2006 14:44:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GX071-0004es-2f; Mon, 09 Oct 2006 14:44:27 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GX071-0000Cr-0q; Mon, 09 Oct 2006 14:44:27 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GX06z-0003Ik-PC; Mon, 09 Oct 2006 14:44:26 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 81DFB175A8;
	Mon,  9 Oct 2006 18:43:55 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1GX06V-0006wb-4J; Mon, 09 Oct 2006 14:43:55 -0400
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>, idr@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
Date: Mon, 09 Oct 2006 14:43:55 -0400
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: 
Subject: [Idr] Last Call: 'Canonical representation of 4-byte AS numbers' to
 Informational RFC (draft-michaelson-4byte-as-representation) 
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

The IESG has received a request from an individual submitter to consider
the following document:

- 'Canonical representation of 4-byte AS numbers '
   <draft-michaelson-4byte-as-representation-01.txt> as an Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-06.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-01.txt


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



From idr-bounces@ietf.org Mon Oct 09 16:12:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GX1T0-0004xj-1Q; Mon, 09 Oct 2006 16:11:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GX1Sy-0004x6-9q; Mon, 09 Oct 2006 16:11:12 -0400
Received: from mailhost.jlc.net ([199.201.159.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GX1Sv-0002FM-10; Mon, 09 Oct 2006 16:11:12 -0400
Received: by mailhost.jlc.net (Postfix, from userid 104)
	id 03A964AC9F; Mon,  9 Oct 2006 16:11:07 -0400 (EDT)
Date: Mon, 9 Oct 2006 16:11:06 -0400
From: John Leslie <john@jlc.net>
To: iesg@ietf.org
Message-ID: <20061009201106.GD46025@verdi>
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: idr@ietf.org
Subject: [Idr] Re: Last Call: 'Canonical representation of 4-byte AS
	numbers' to Informational RFC
	(draft-michaelson-4byte-as-representation)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

The IESG <iesg-secretary@ietf.org> wrote:
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> 
> - 'Canonical representation of 4-byte AS numbers '
>    <draft-michaelson-4byte-as-representation-01.txt> as an Informational
> RFC

   While I entirely agree with the author that using ":" to separate the
high-order 16 bits from the low-order 16 bits would be a bad idea, I'm
not confident that using "." would be problem-free.

   The draft already mentions possible confusion with floating-point
numbers; I also see possible confusion in searching.

   Before trying to designate a "standard" representation, IMHO, we should
make sure there's a problem to be solved, and consider how likely our
"solution" is to prevail.

   And there's a particularly obvious alternative: simply continuing the
decimal notation used now. We've already adapted to five-digit decimal
numbers without a whimper: is there really any reason to believe six
digits will prove unworkable?

--
John Leslie <john@jlc.net>

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



From idr-bounces@ietf.org Tue Oct 10 00:13:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GX8wg-0004iL-4d; Tue, 10 Oct 2006 00:10:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GX8we-0004hs-L3; Tue, 10 Oct 2006 00:10:20 -0400
Received: from monster.hopcount.ca ([199.212.90.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GX8wd-0001mA-Dg; Tue, 10 Oct 2006 00:10:20 -0400
Received: from [67.99.248.2] (helo=[10.111.113.102])
	by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.63 (FreeBSD)) (envelope-from <jabley@ca.afilias.info>)
	id 1GX8wP-0008vW-TP; Tue, 10 Oct 2006 04:10:06 +0000
In-Reply-To: <20061009201106.GD46025@verdi>
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
	<20061009201106.GD46025@verdi>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5ED54533-DC71-46AD-B9EC-DE9FDCC19E54@ca.afilias.info>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@ca.afilias.info>
Subject: Re: [Idr] Re: Last Call: 'Canonical representation of 4-byte AS
	numbers' to Informational RFC
	(draft-michaelson-4byte-as-representation)
Date: Mon, 9 Oct 2006 23:09:59 -0500
To: John Leslie <john@jlc.net>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: idr@ietf.org, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org


On 9-Oct-2006, at 15:11, John Leslie wrote:

>    And there's a particularly obvious alternative: simply  
> continuing the
> decimal notation used now. We've already adapted to five-digit decimal
> numbers without a whimper: is there really any reason to believe six
> digits will prove unworkable?

But then how do you distinguish between a 2-byte only AS number and a  
4-byte AS number which happens to be less than 0.65535?


Joe


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



From idr-bounces@ietf.org Tue Oct 10 09:10:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXHIe-0001ok-AK; Tue, 10 Oct 2006 09:05:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXHIb-0001oc-8y; Tue, 10 Oct 2006 09:05:33 -0400
Received: from sleibrand-ibm.acs.internap.com ([63.251.67.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXHIZ-0007fE-2W; Tue, 10 Oct 2006 09:05:33 -0400
Received: from sleibrand (helo=localhost)
	by sleibrand-ibm.acs.internap.com with local-esmtp (v3.35.1)
	id 1GXHIR-000760-00; Tue, 10 Oct 2006 09:05:23 -0400
Date: Tue, 10 Oct 2006 09:05:23 -0400 (EDT)
From: Scott Leibrand <sleibrand@internap.com>
To: Joe Abley <jabley@ca.afilias.info>
Subject: Re: [Idr] Re: Last Call: 'Canonical representation of 4-byte AS
	numbers' to Informational RFC
	(draft-michaelson-4byte-as-representation)
In-Reply-To: <5ED54533-DC71-46AD-B9EC-DE9FDCC19E54@ca.afilias.info>
Message-ID: <Pine.LNX.4.58.0610100901280.16285@sleibrand-ibm.acs.internap.com>
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
	<20061009201106.GD46025@verdi>
	<5ED54533-DC71-46AD-B9EC-DE9FDCC19E54@ca.afilias.info>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: idr@ietf.org, John Leslie <john@jlc.net>, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

On 10/09/06 at 11:09pm -0500, Joe Abley <jabley@ca.afilias.info> wrote:

> On 9-Oct-2006, at 15:11, John Leslie wrote:
>
> >    And there's a particularly obvious alternative: simply continuing
> > the decimal notation used now. We've already adapted to five-digit
> > decimal numbers without a whimper: is there really any reason to
> > believe six digits will prove unworkable?
>
> But then how do you distinguish between a 2-byte only AS number and a
> 4-byte AS number which happens to be less than 0.65535?

There is no meaningful distinction, is there?  The only distinctions I can
see are for understanding how they'll work for backwards compatibility,
and "less than 65535" seems adequate for that.

I'm agnostic to which notation we should use, but I don't think it matters
all that much, as long as we avoid confusing ourselves.

-Scott



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



From idr-bounces@ietf.org Tue Oct 10 09:37:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXHn0-0005JP-Lh; Tue, 10 Oct 2006 09:36:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXHmz-0005JG-H9; Tue, 10 Oct 2006 09:36:57 -0400
Received: from mail-red.research.att.com ([192.20.225.110])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXHmx-00062l-AE; Tue, 10 Oct 2006 09:36:57 -0400
Received: from bright.research.att.com (bright.research.att.com
	[135.207.20.189])
	by mail-blue.research.att.com (Postfix) with ESMTP id 1706C147BFF;
	Tue, 10 Oct 2006 09:36:53 -0400 (EDT)
Received: (from fenner@localhost)
	by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id
	k9ADaqtk029970; Tue, 10 Oct 2006 06:36:52 -0700
From: Bill Fenner <fenner@research.att.com>
Message-Id: <200610101336.k9ADaqtk029970@bright.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: Joe Abley <jabley@ca.afilias.info>
Subject: Re: [Idr] Re: Last Call: 'Canonical representation of 4-byte AS
	numbers' to Informational RFC
	(draft-michaelson-4byte-as-representation)
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
	<20061009201106.GD46025@verdi>
	<5ED54533-DC71-46AD-B9EC-DE9FDCC19E54@ca.afilias.info>
Date: Tue, 10 Oct 2006 06:36:52 -0700
Versions: dmail (linux) 2.7/makemail 2.14
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: idr@ietf.org, John Leslie <john@jlc.net>, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org


>[If you just use larger decimal values,]
>... how do you distinguish between a 2-byte only AS number and a  
>4-byte AS number which happens to be less than 0.65535?

When is this difference significant?  0.7018 == 7018, an AS number
is an AS number.  There are some AS numbers that can *only* be
represented in 4 bytes, but there isn't a different space for the
4-byte values.

I'm in the "having a common notation is better than not" camp - there is
no perfect notation, but if everyone ends up using the same notation,
it'll improve consistency and reduce confusion.  (I'd be willing to be
convinced "no notation is OK", i.e., people don't have a problem with
using longer and longer decimal strings - we probably don't expect to
get to 4294967295 but some would argue that's too long for people to
easily remember)

  Bill

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



From idr-bounces@ietf.org Tue Oct 10 09:51:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXI0D-0003qj-50; Tue, 10 Oct 2006 09:50:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXI0B-0003qZ-4y; Tue, 10 Oct 2006 09:50:35 -0400
Received: from kremlin.juniper.net ([207.17.137.120])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXI09-0001gw-Qo; Tue, 10 Oct 2006 09:50:35 -0400
Received: from unknown (HELO pi-smtp.jnpr.net) ([10.10.2.36])
	by kremlin.juniper.net with ESMTP; 10 Oct 2006 06:48:07 -0700
X-IronPort-AV: i="4.09,290,1157353200"; 
	d="scan'208"; a="592254705:sNHT35737624"
Received: from antipi.jnpr.net ([10.10.2.34]) by pi-smtp.jnpr.net with
	Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Oct 2006 09:50:31 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Idr] Re: Last Call: 'Canonical representation of 4-byte
	ASnumbers' to Informational
	RFC(draft-michaelson-4byte-as-representation)
Date: Tue, 10 Oct 2006 09:50:31 -0400
Message-ID: <027F28805B2F0E4D955C35859BDC3AA10181096B@antipi.jnpr.net>
In-Reply-To: <200610101336.k9ADaqtk029970@bright.research.att.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] Re: Last Call: 'Canonical representation of 4-byte
	ASnumbers' to Informational
	RFC(draft-michaelson-4byte-as-representation)
Thread-Index: AcbscUSwTCAKmR9HTO+Sl5cLubqsgwAAG2Vw
From: "Bruno Rijsman" <brijsman@juniper.net>
To: "Bill Fenner" <fenner@research.att.com>,
	"Joe Abley" <jabley@ca.afilias.info>
X-OriginalArrivalTime: 10 Oct 2006 13:50:31.0960 (UTC)
	FILETIME=[0D906980:01C6EC73]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: idr@ietf.org, John Leslie <john@jlc.net>, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

I second this, in other words: I am also in favor of simply displaying
4-octet AS numbers as (potentially large) decimal integer numbers.

There is already one widely used implementation that does just that.

The main reason for my preference is that there is no semantic
difference between 333 and 0.333: they both refer to the same autonomous
system. Consider an AS-path with traverses various islands of 2-octet
and 4-octet BGP speakers; it would probably be confusing if the AS
number flipped back and forth from 333 to 0.333.

-- Bruno

> -----Original Message-----
> From: Bill Fenner [mailto:fenner@research.att.com]
> Sent: Tuesday, October 10, 2006 9:37 AM
> To: Joe Abley
> Cc: idr@ietf.org; John Leslie; iesg@ietf.org
> Subject: Re: [Idr] Re: Last Call: 'Canonical representation of 4-byte
> ASnumbers' to Informational
> RFC(draft-michaelson-4byte-as-representation)
>=20
>=20
>=20
> >[If you just use larger decimal values,]
> >... how do you distinguish between a 2-byte only AS number and a =20
> >4-byte AS number which happens to be less than 0.65535?
>=20
> When is this difference significant?  0.7018 =3D=3D 7018, an AS number
> is an AS number.  There are some AS numbers that can *only* be
> represented in 4 bytes, but there isn't a different space for the
> 4-byte values.
>=20
> I'm in the "having a common notation is better than not" camp=20
> - there is
> no perfect notation, but if everyone ends up using the same notation,
> it'll improve consistency and reduce confusion.  (I'd be willing to be
> convinced "no notation is OK", i.e., people don't have a problem with
> using longer and longer decimal strings - we probably don't expect to
> get to 4294967295 but some would argue that's too long for people to
> easily remember)
>=20
>   Bill
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www1.ietf.org/mailman/listinfo/idr
>=20

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



From idr-bounces@ietf.org Tue Oct 10 10:19:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXIPe-0000li-IM; Tue, 10 Oct 2006 10:16:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXIPd-0000jR-3o; Tue, 10 Oct 2006 10:16:53 -0400
Received: from monster.hopcount.ca ([199.212.90.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXIPb-0006oB-Rx; Tue, 10 Oct 2006 10:16:53 -0400
Received: from dhcp2223.nanog.merit.net ([192.35.166.223])
	by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.63 (FreeBSD)) (envelope-from <jabley@ca.afilias.info>)
	id 1GXIPU-000Eqy-Rc; Tue, 10 Oct 2006 14:16:45 +0000
In-Reply-To: <Pine.LNX.4.58.0610100901280.16285@sleibrand-ibm.acs.internap.com>
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
	<20061009201106.GD46025@verdi>
	<5ED54533-DC71-46AD-B9EC-DE9FDCC19E54@ca.afilias.info>
	<Pine.LNX.4.58.0610100901280.16285@sleibrand-ibm.acs.internap.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <45DD7B81-03E4-4D65-8CB8-0078E433A6C9@ca.afilias.info>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@ca.afilias.info>
Subject: Re: [Idr] Re: Last Call: 'Canonical representation of 4-byte AS
	numbers' to Informational RFC
	(draft-michaelson-4byte-as-representation)
Date: Tue, 10 Oct 2006 09:16:40 -0500
To: Scott Leibrand <sleibrand@internap.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: idr@ietf.org, John Leslie <john@jlc.net>, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org


On 10-Oct-2006, at 08:05, Scott Leibrand wrote:

> On 10/09/06 at 11:09pm -0500, Joe Abley <jabley@ca.afilias.info>  
> wrote:
>
>> But then how do you distinguish between a 2-byte only AS number and a
>> 4-byte AS number which happens to be less than 0.65535?
>
> There is no meaningful distinction, is there?

In terms of resource allocation, it seems to me that you only have to  
deal with 32-bit numbers, and no distinction is necessary.

In terms of presentation to an operator, e.g. as part of a "show"  
command, it also seems like whatever is simplest and easier on the  
eye wins.

(I would note that on cisco routers it's perfectly possible to view  
community string attributes as simple 32-bit numbers, but everybody  
seems to prefer the representation of two 16-bit values separated by  
a colon.)

In terms of encoding values into a wire format to include in a BGP  
attribute, though, might it not be important for the router to know  
which was intended? Perhaps not; I'm not a router vendor, and I'm not  
presupposing an answer.


Joe


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



From idr-bounces@ietf.org Tue Oct 10 12:39:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXKby-0001Jb-8W; Tue, 10 Oct 2006 12:37:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXKbw-0001Fm-Ih; Tue, 10 Oct 2006 12:37:44 -0400
Received: from kahuna.telstra.net ([2001:360::4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXKbu-0004g5-MI; Tue, 10 Oct 2006 12:37:44 -0400
Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4])
	by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k9AGbJ28016253;
	Wed, 11 Oct 2006 02:37:22 +1000 (EST) (envelope-from gih@apnic.net)
Message-Id: <7.0.0.16.2.20061011023158.02a94558@apnic.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Wed, 11 Oct 2006 02:37:14 +1000
To: Joe Abley <jabley@ca.afilias.info>, Scott Leibrand <sleibrand@internap.com>
From: Geoff Huston <gih@apnic.net>
Subject: Re: [Idr] Re: Last Call: 'Canonical representation of 4-byte
	AS numbers' to Informational RFC
	(draft-michaelson-4byte-as-representation)
In-Reply-To: <45DD7B81-03E4-4D65-8CB8-0078E433A6C9@ca.afilias.info>
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
	<20061009201106.GD46025@verdi>
	<5ED54533-DC71-46AD-B9EC-DE9FDCC19E54@ca.afilias.info>
	<Pine.LNX.4.58.0610100901280.16285@sleibrand-ibm.acs.internap.com>
	<45DD7B81-03E4-4D65-8CB8-0078E433A6C9@ca.afilias.info>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: idr@ietf.org, John Leslie <john@jlc.net>, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org


>In terms of encoding values into a wire format to include in a BGP
>attribute, though, might it not be important for the router to know
>which was intended? Perhaps not; I'm not a router vendor, and I'm not
>presupposing an answer.

According to draft-ietf-idr-as4bytes-12.txt, the wire format uses 
straightforward 32 bit fields to encode an AS number in "new" BGP.

The notation is in the form of offering guidance to folk relating to 
CLI, Route Registry Objects, Whois Objects, routing requests, ... and 
other places where humans and AS numbers intersect. I'm sure that 
most implementations of such tools would align to the principle of 
being liberal in what they accepts as input, but the notation is 
intended to offer some guidance to implementors and users of a 
default input format and a default output format.

regards,

Geoff





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



From idr-bounces@ietf.org Tue Oct 10 13:15:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXLBF-0003pw-Ug; Tue, 10 Oct 2006 13:14:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXLBE-0003pL-Lu; Tue, 10 Oct 2006 13:14:12 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXLBD-0002c8-FN; Tue, 10 Oct 2006 13:14:12 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 10 Oct 2006 10:14:11 -0700
X-IronPort-AV: i="4.09,291,1157353200"; 
	d="scan'208"; a="45537809:sNHT44440232"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k9AHEBZ7024273; Tue, 10 Oct 2006 13:14:11 -0400
Received: from [10.0.1.2] (rtp-jgs-vpn1.cisco.com [10.82.179.66])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id k9AHE9DN002464;
	Tue, 10 Oct 2006 13:14:10 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p06230916c151848c2527@[10.0.1.2]>
In-Reply-To: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
Date: Tue, 10 Oct 2006 13:14:01 -0400
To: iesg@ietf.org
From: "John G. Scudder" <jgs@cisco.com>
Subject: Re: [Idr] Last Call: 'Canonical representation of 4-byte AS
	numbers' to Informational RFC
	(draft-michaelson-4byte-as-representation)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
DKIM-Signature: a=rsa-sha1; q=dns; l=246; t=1160500451; x=1161364451;
	c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jgs@cisco.com;
	z=From:=22John=20G.=20Scudder=22=20<jgs@cisco.com>
	|Subject:Re=3A=20[Idr]=20Last=20Call=3A=20'Canonical=20representation=20of=204-by
	te=20AS=0A=20numbers'=20to=20Informational=20RFC=20(draft-michaelson-4byte-
	as-representation) |To:iesg@ietf.org;
	X=v=3Dcisco.com=3B=20h=3DOjXQuNGhOTIGgIBYbh28tMSyR40=3D;
	b=i2tx0XdXuKshi/YfNnECkbdUkArRcKQmBX3WN9DORFNLAACh3T7pRG4GCOVNcZggf8WHqyFk
	umLlBDuy/P5OUmU2mLRuNpCWE5Unyle1xCdj+jMNoGPkHJNu5NKGEV5u;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=jgs@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

I'm inclined to agree with others who've expressed a slight 
preference for a simple decimal integer representation.  I think the 
(lack of) technical issues with doing so has already been pretty well 
captured in the conversation.

--John

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



From idr-bounces@ietf.org Wed Oct 11 08:59:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXdes-0006rZ-46; Wed, 11 Oct 2006 08:58:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXdeD-0006KN-Kq; Wed, 11 Oct 2006 08:57:21 -0400
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXdPH-0000Am-PB; Wed, 11 Oct 2006 08:41:56 -0400
Received: from [IPv6:2001:1af8:6::20a:95ff:fecd:987a] (alumange-giga.muada.com
	[IPv6:2001:1af8:6:0:20a:95ff:fecd:987a]) (authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k9BCeQmN043883
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 11 Oct 2006 14:40:26 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
In-Reply-To: <p06230916c151848c2527@[10.0.1.2]>
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
	<p06230916c151848c2527@[10.0.1.2]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <BFA41ABC-06EE-4ABF-99B4-49B6FBA58865@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [Idr] Last Call: 'Canonical representation of 4-byte AS numbers'
	to Informational RFC (draft-michaelson-4byte-as-representation)
Date: Wed, 11 Oct 2006 14:41:45 +0200
To: "John G. Scudder" <jgs@cisco.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,
	ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: idr@ietf.org, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

On 10-okt-2006, at 19:14, John G. Scudder wrote:

> I'm inclined to agree with others who've expressed a slight  
> preference for a simple decimal integer representation.  I think  
> the (lack of) technical issues with doing so has already been  
> pretty well captured in the conversation.

My preference is a lot stronger than this. The main issue is that  
it's customary today in routers to work on AS paths with regular  
expressions, and introducing a new character in AS numbers will  
require changing at least some of those regular expressions (= all  
must be reviewed), while adding digits generally shouldn't.

xx.yy notation is also interpreted as a valid IPv4 address in many  
implementations, for instance, try: ping 17.4752682

Note that there is significant resistance to this on the NANOG list,  
and although this resistance is criticized, nobody is actually  
speaking up in favor of the draft under consideration.

On a related note: what happens to community values? These are 32  
bits long but are often interpreted as AS:nn. If AS is already 32,  
then there are no bits for nn. The obvious answer is to use some kind  
of extended community, but that's something that won't happen over  
night.

Suggestion: introduce a new syntax for community values that is:

[16 low order bits AS * 16 + 4 lowest high order bits AS][some  
character][12 bits nn]

For instance, today you'd see 701:120, with the new notation  
something like 7000001#120 (although 700001#5000 isn't valid while  
701:5000 is). If the RIRs then start giving out 32-bit AS numbers  
starting at 655360 or higher, the high order bits of the AS and the  
nn won't clash for existing AS numbers (= < 40960).

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



From idr-bounces@ietf.org Wed Oct 11 16:06:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXkJ8-0003Gb-5I; Wed, 11 Oct 2006 16:04:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXkJ6-0003Ex-Ry; Wed, 11 Oct 2006 16:04:00 -0400
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXkJ6-0001Ik-Jz; Wed, 11 Oct 2006 16:04:00 -0400
Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com
	[IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k9BK2WqC051713
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 11 Oct 2006 22:02:32 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
In-Reply-To: <200610112032.k9BKWtid071075@workhorse.brookfield.occnc.com>
References: <200610112032.k9BKWtid071075@workhorse.brookfield.occnc.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <17926D0F-52F1-41C7-8ECC-601D72F017AD@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [Idr] Last Call: 'Canonical representation of 4-byte AS numbers'
	to Informational RFC (draft-michaelson-4byte-as-representation)
Date: Wed, 11 Oct 2006 22:03:51 +0200
To: curtis@occnc.com
X-Mailer: Apple Mail (2.752.2)
X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,
	ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: "John G. Scudder" <jgs@cisco.com>, iesg@ietf.org, idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

On 11-okt-2006, at 22:32, Curtis Villamizar wrote:

> How the protocol encodes an atribute does not impact how that
> attribute is displayed in the CLI and therefore how or whether an RE
> syntax could be used in policy statements.

I don't understand how these statements relate to the discussion at  
hand.

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



From idr-bounces@ietf.org Wed Oct 11 16:43:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXkuG-00056M-PV; Wed, 11 Oct 2006 16:42:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXkqa-0002ui-JI; Wed, 11 Oct 2006 16:38:36 -0400
Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXkdU-0003A5-Ro; Wed, 11 Oct 2006 16:25:06 -0400
Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1])
	by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id
	k9BL4Fn3071983; Wed, 11 Oct 2006 17:04:15 -0400 (EDT)
	(envelope-from curtis@workhorse.brookfield.occnc.com)
Message-Id: <200610112104.k9BL4Fn3071983@workhorse.brookfield.occnc.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [Idr] Last Call: 'Canonical representation of 4-byte AS numbers'
	to Informational RFC (draft-michaelson-4byte-as-representation)
In-reply-to: Your message of "Wed, 11 Oct 2006 22:03:51 +0200."
	<17926D0F-52F1-41C7-8ECC-601D72F017AD@muada.com> 
Date: Wed, 11 Oct 2006 17:04:15 -0400
From: Curtis Villamizar <curtis@occnc.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: "John G. Scudder" <jgs@cisco.com>, idr@ietf.org, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: curtis@occnc.com
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org


In message <17926D0F-52F1-41C7-8ECC-601D72F017AD@muada.com>
Iljitsch van Beijnum writes:
>  
> On 11-okt-2006, at 22:32, Curtis Villamizar wrote:
>  
> > How the protocol encodes an atribute does not impact how that
> > attribute is displayed in the CLI and therefore how or whether an RE
> > syntax could be used in policy statements.
>  
> I don't understand how these statements relate to the discussion at  
> hand.


You are right - type first think later is a bad idea.  In any case it
is fine to represent AS as big decimal numbers since there is no real
need to run RE over an adjacent set of numbers in policy statements or
sets of numbers with common values in the top part.  Adding a dot or
colon might upset some REs in existing policy.

Curtis

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



From idr-bounces@ietf.org Wed Oct 11 17:11:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXlLK-00020B-20; Wed, 11 Oct 2006 17:10:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXlLI-0001zI-9Y; Wed, 11 Oct 2006 17:10:20 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXlLF-0000ZG-W3; Wed, 11 Oct 2006 17:10:20 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
	by sj-iport-5.cisco.com with ESMTP; 11 Oct 2006 14:10:17 -0700
X-IronPort-AV: i="4.09,295,1157353200"; 
	d="scan'208"; a="330666407:sNHT54101696"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k9BLAH1T029783; Wed, 11 Oct 2006 14:10:17 -0700
Received: from cisco.com (vaf-lnx1.cisco.com [171.71.142.83])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9BLA8bF002366;
	Wed, 11 Oct 2006 14:10:08 -0700 (PDT)
Received: from vaf-lnx1.cisco.com (localhost.localdomain [127.0.0.1])
	by cisco.com (8.13.1/8.13.1) with ESMTP id k9BLA8OI026514;
	Wed, 11 Oct 2006 14:10:08 -0700
Received: (from vaf@localhost)
	by vaf-lnx1.cisco.com (8.13.1/8.13.1/Submit) id k9BLA0CF026511;
	Wed, 11 Oct 2006 14:10:00 -0700
X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com
	using -f
Date: Wed, 11 Oct 2006 14:10:00 -0700
From: Vince Fuller <vaf@cisco.com>
To: Joe Abley <jabley@ca.afilias.info>
Subject: Re: [Idr] Re: Last Call: 'Canonical representation of 4-byte AS
	numbers' to Informational RFC
	(draft-michaelson-4byte-as-representation)
Message-ID: <20061011211000.GA26236@vaf-lnx1.cisco.com>
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
	<20061009201106.GD46025@verdi>
	<5ED54533-DC71-46AD-B9EC-DE9FDCC19E54@ca.afilias.info>
	<Pine.LNX.4.58.0610100901280.16285@sleibrand-ibm.acs.internap.com>
	<45DD7B81-03E4-4D65-8CB8-0078E433A6C9@ca.afilias.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45DD7B81-03E4-4D65-8CB8-0078E433A6C9@ca.afilias.info>
User-Agent: Mutt/1.4.1i
DKIM-Signature: a=rsa-sha1; q=dns; l=932; t=1160601017; x=1161465017;
	c=relaxed/simple; s=sjdkim7002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=vaf@cisco.com; z=From:Vince=20Fuller=20<vaf@cisco.com>
	|Subject:Re=3A=20[Idr]=20Re=3A=20Last=20Call=3A=20'Canonical=20representation=20o
	f=204-byte=20AS=20numbers'=20to=20Informational=20RFC=20(draft-michaelson-4
	byte-as-representation);
	X=v=3Dcisco.com=3B=20h=3DiIuRmWeB1dLNi256A44RLTpA7nE=3D;
	b=N5+/3P2Weom/EattATfQoUzueuvZ6GVVV//qUHTL/RuN+9hCxzC6vxzeoRR3lElUsiaWrzfS
	rPZV2MAo8zsgYp4Yi0vJh1cZzcW3dvsyYezZcTWJn1PVk7vHYNesn+We;
Authentication-Results: sj-dkim-7.cisco.com; header.From=vaf@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: idr@ietf.org, John Leslie <john@jlc.net>, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

> In terms of resource allocation, it seems to me that you only have to  
> deal with 32-bit numbers, and no distinction is necessary.
> 
> In terms of presentation to an operator, e.g. as part of a "show"  
> command, it also seems like whatever is simplest and easier on the  
> eye wins.
> 
> (I would note that on cisco routers it's perfectly possible to view  
> community string attributes as simple 32-bit numbers, but everybody  
> seems to prefer the representation of two 16-bit values separated by  
> a colon.)

That's because a convention has evolved to structure the community as two
16-bit values, with specific semantic meanings attached to them.

Similarly, the dotted-quad notation for IP addresses once made sense because
class-A/B/C networks assigned structure to the octets.

IMHO, displaying 32-bit ASNs as "x.y" would be a mistake as it would imply
that some structure exists.

	--Vince

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



From idr-bounces@ietf.org Wed Oct 11 20:18:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXoEk-0003qd-A4; Wed, 11 Oct 2006 20:15:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GXoEj-0003qJ-3k; Wed, 11 Oct 2006 20:15:45 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GXkLn-0001bM-Mu; Wed, 11 Oct 2006 16:06:47 -0400
Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1GXk9G-0004o2-UW; Wed, 11 Oct 2006 15:53:55 -0400
Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1])
	by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id
	k9BKWtid071075; Wed, 11 Oct 2006 16:32:55 -0400 (EDT)
	(envelope-from curtis@workhorse.brookfield.occnc.com)
Message-Id: <200610112032.k9BKWtid071075@workhorse.brookfield.occnc.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [Idr] Last Call: 'Canonical representation of 4-byte AS numbers'
	to Informational RFC (draft-michaelson-4byte-as-representation)
In-reply-to: Your message of "Wed, 11 Oct 2006 14:41:45 +0200."
	<BFA41ABC-06EE-4ABF-99B4-49B6FBA58865@muada.com> 
Date: Wed, 11 Oct 2006 16:32:55 -0400
From: Curtis Villamizar <curtis@occnc.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: "John G. Scudder" <jgs@cisco.com>, iesg@ietf.org, idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: curtis@occnc.com
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org


In message <BFA41ABC-06EE-4ABF-99B4-49B6FBA58865@muada.com>
Iljitsch van Beijnum writes:
>  
> On 10-okt-2006, at 19:14, John G. Scudder wrote:
>  
> > I'm inclined to agree with others who've expressed a slight  
> > preference for a simple decimal integer representation.  I think  
> > the (lack of) technical issues with doing so has already been  
> > pretty well captured in the conversation.
>  
> My preference is a lot stronger than this. The main issue is that  
> it's customary today in routers to work on AS paths with regular  
> expressions, and introducing a new character in AS numbers will  
> require changing at least some of those regular expressions (= all  
> must be reviewed), while adding digits generally shouldn't.
>  
> xx.yy notation is also interpreted as a valid IPv4 address in many  
> implementations, for instance, try: ping 17.4752682
>  
> Note that there is significant resistance to this on the NANOG list,  
> and although this resistance is criticized, nobody is actually  
> speaking up in favor of the draft under consideration.
>  
> On a related note: what happens to community values? These are 32  
> bits long but are often interpreted as AS:nn. If AS is already 32,  
> then there are no bits for nn. The obvious answer is to use some kind  
> of extended community, but that's something that won't happen over  
> night.
>  
> Suggestion: introduce a new syntax for community values that is:
>  
> [16 low order bits AS * 16 + 4 lowest high order bits AS][some  
> character][12 bits nn]
>  
> For instance, today you'd see 701:120, with the new notation  
> something like 7000001#120 (although 700001#5000 isn't valid while  
> 701:5000 is). If the RIRs then start giving out 32-bit AS numbers  
> starting at 655360 or higher, the high order bits of the AS and the  
> nn won't clash for existing AS numbers (= < 40960).



How the protocol encodes an atribute does not impact how that
attribute is displayed in the CLI and therefore how or whether an RE
syntax could be used in policy statements.  For example, there are no
dots in the encoding of an IP address nor is there a slash before the
prefix length and there are no spaces between AS numbers or square
brackets around AS sets in the protocol encoding.

Curtis

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



From idr-bounces@ietf.org Thu Oct 12 09:33:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY0dl-0003ri-PU; Thu, 12 Oct 2006 09:30:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GY0dk-0003rd-Jy
	for idr@ietf.org; Thu, 12 Oct 2006 09:30:24 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY0dj-000619-8v
	for idr@ietf.org; Thu, 12 Oct 2006 09:30:24 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id
	k9CDUI1Z063492; Thu, 12 Oct 2006 06:30:22 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k9CDUAu72648;
	Thu, 12 Oct 2006 06:30:10 -0700 (PDT)
	(envelope-from yakov@juniper.net)
Message-Id: <200610121330.k9CDUAu72648@merlot.juniper.net>
To: fenner@research.att.com, rcallon@juniper.net
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <51166.1160659810.1@juniper.net>
Date: Thu, 12 Oct 2006 06:30:10 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: skh@nexthop.com, idr@ietf.org
Subject: [Idr] request for an early allocation
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Bill and Ross,

Please approve a request for an early allocation of a new BGP
attribute code point. The attribute is defined in
draft-ietf-idr-as-pathlimit. The IDR WG has a consensus that
early allocation of the new code point is appropriate.

Yakov.

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



From idr-bounces@ietf.org Thu Oct 12 13:26:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY4Hc-0006ld-Ca; Thu, 12 Oct 2006 13:23:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GY4Hb-0006lV-KR; Thu, 12 Oct 2006 13:23:47 -0400
Received: from monster.hopcount.ca ([199.212.90.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GY4Ha-0000jB-Co; Thu, 12 Oct 2006 13:23:47 -0400
Received: from yxu1a22.hopcount.ca ([199.212.90.22])
	by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.63 (FreeBSD)) (envelope-from <jabley@ca.afilias.info>)
	id 1GY4HI-000K6Q-HX; Thu, 12 Oct 2006 17:23:28 +0000
In-Reply-To: <BFA41ABC-06EE-4ABF-99B4-49B6FBA58865@muada.com>
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org>
	<p06230916c151848c2527@[10.0.1.2]>
	<BFA41ABC-06EE-4ABF-99B4-49B6FBA58865@muada.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2419CF6D-259E-44A5-98BE-970701CAC6F1@ca.afilias.info>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@ca.afilias.info>
Subject: Re: [Idr] Last Call: 'Canonical representation of 4-byte AS numbers'
	to Informational RFC (draft-michaelson-4byte-as-representation)
Date: Thu, 12 Oct 2006 13:23:25 -0400
To: Iljitsch van Beijnum <iljitsch@muada.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: "John G. Scudder" <jgs@cisco.com>, iesg@ietf.org, idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org


On 11-Oct-2006, at 08:41, Iljitsch van Beijnum wrote:

> Note that there is significant resistance to this on the NANOG  
> list, and although this resistance is criticized, nobody is  
> actually speaking up in favor of the draft under consideration.

This was also my observation.

I don't believe I have heard a convincing argument as to why  
HHHH.LLLL is a useful representation, and I've heard plausible  
concern that it is a bad idea.

The overwhelming feedback I heard in St Louis (as well as on the  
list) was that a simple decimal representation of the 32-bit quantity  
was the preferred notation. I have heard nobody point out any  
concerns with that approach.

Regardless of which notation is chosen, it still seems useful to have  
the canonical representation documented.


Joe



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



From idr-bounces@ietf.org Mon Oct 16 22:35:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GZeld-0006yJ-Hy; Mon, 16 Oct 2006 22:33:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GZelc-0006xb-9N
	for idr@ietf.org; Mon, 16 Oct 2006 22:33:20 -0400
Received: from szxga02-in.huawei.com ([61.144.161.54])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZela-0005Nk-Hr
	for idr@ietf.org; Mon, 16 Oct 2006 22:33:20 -0400
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J7900JLKEMITQ@szxga02-in.huawei.com> for
	idr@ietf.org; Tue, 17 Oct 2006 10:51:54 +0800 (CST)
Received: from M55527 ([10.111.12.134])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J7900GTBEMDQW@szxga02-in.huawei.com> for
	idr@ietf.org; Tue, 17 Oct 2006 10:51:54 +0800 (CST)
Date: Tue, 17 Oct 2006 10:32:22 +0800
From: Mach Chen <mach@huawei.com>
Subject: [IDR] Nexthop based Outbound Route Filter
To: idr <idr@ietf.org>
Message-id: <00ee01c6f194$7c114c00$860c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a743e34ab8eb08259de9a7307caed594
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0783874398=="
Errors-To: idr-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0783874398==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_oq9Mtu37j9E4c7lEMy9/Dg)"

This is a multi-part message in MIME format.

--Boundary_(ID_oq9Mtu37j9E4c7lEMy9/Dg)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi folks,

We have posted a new I-D which is about "Nexthop based ORF".

Any feed-back and comments would be most welcome!

Best regards,

Mach


--------------------------------------------------------------------------------

  a.. To: i-d-announce at ietf.org 
  b.. Subject: I-D ACTION:draft-chen-idr-bgp-nexthop-orf-00.txt 
  c.. From: Internet-Drafts at ietf.org 
  d.. Date: Thu, 12 Oct 2006 15:50:02 -0400 
  e.. Cc: 
  f.. List-archive: <http://www1.ietf.org/pipermail/i-d-announce> 
  g.. List-help: <mailto:i-d-announce-request@ietf.org?subject=help> 
  h.. List-id: i-d-announce.ietf.org 
  i.. List-post: <mailto:i-d-announce@ietf.org> 
  j.. List-subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=subscribe> 
  k.. List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=unsubscribe> 
  l.. Reply-to: internet-drafts at ietf.org 

--------------------------------------------------------------------------------

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Nexthop Based Outbound Route Filter for BGP-4 
	Author(s)	: R. Zhang, M. Chen
	Filename	: draft-chen-idr-bgp-nexthop-orf-00.txt
	Pages		: 7
	Date		: 2006-10-12
	
   This document defines a new Outbound Route Filter type for BGP, 
   termed "Nexthop Outbound Route Filter", which can be used to provide 
   Nexthop based route filtering. 


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-chen-idr-bgp-nexthop-orf-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt> 
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce


--------------------------------------------------------------------------------

--Boundary_(ID_oq9Mtu37j9E4c7lEMy9/Dg)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>
<DIV><FONT size=2>Hi folks,</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>We have posted a new I-D which is about "Nexthop based 
ORF".</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Any feed-back and comments would be most welcome!</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Best regards,</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Mach</FONT></DIV>
<DIV><FONT size=2><EM></EM>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV><FONT 
size=3><!--X-Subject-Header-End--><!--X-Head-of-Message--></FONT></DIV>
<UL>
  <LI><EM>To</EM>: <A href="">i-d-announce at ietf.org</A> 
  <LI><EM>Subject</EM>: I-D ACTION:draft-chen-idr-bgp-nexthop-orf-00.txt 
  <LI><EM>From</EM>: <A href="">Internet-Drafts at ietf.org</A> 
  <LI><EM>Date</EM>: Thu, 12 Oct 2006 15:50:02 -0400 
  <LI><EM>Cc</EM>: 
  <LI><EM>List-archive</EM>: &lt;<A 
  href="">http://www1.ietf.org/pipermail/i-d-announce</A>&gt; 
  <LI><EM>List-help</EM>: &lt;<A 
  href="">mailto:i-d-announce-request@ietf.org?subject=help</A>&gt; 
  <LI><EM>List-id</EM>: i-d-announce.ietf.org 
  <LI><EM>List-post</EM>: &lt;<A href="">mailto:i-d-announce@ietf.org</A>&gt; 
  <LI><EM>List-subscribe</EM>: &lt;<A 
  href="">https://www1.ietf.org/mailman/listinfo/i-d-announce</A>&gt;, &lt;<A 
  href="">mailto:i-d-announce-request@ietf.org?subject=subscribe</A>&gt; 
  <LI><EM>List-unsubscribe</EM>: &lt;<A 
  href="">https://www1.ietf.org/mailman/listinfo/i-d-announce</A>&gt;, &lt;<A 
  href="">mailto:i-d-announce-request@ietf.org?subject=unsubscribe</A>&gt; 
  <LI><EM>Reply-to</EM>: <A href="">internet-drafts at ietf.org</A> </LI></UL><!--X-Head-of-Message-End--><!--X-Head-Body-Sep-Begin-->
<DIV>
<HR>
</DIV><!--X-Head-Body-Sep-End--><!--X-Body-of-Message--><PRE>A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Nexthop Based Outbound Route Filter for BGP-4 
	Author(s)	: R. Zhang, M. Chen
	Filename	: draft-chen-idr-bgp-nexthop-orf-00.txt
	Pages		: 7
	Date		: 2006-10-12
	
   This document defines a new Outbound Route Filter type for BGP, 
   termed "Nexthop Outbound Route Filter", which can be used to provide 
   Nexthop based route filtering. 


A URL for this Internet-Draft is:
<A href="">http://www.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt</A>

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit <A href="">https://www1.ietf.org/mailman/listinfo/I-D-announce</A> 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-chen-idr-bgp-nexthop-orf-00.txt".

A list of Internet-Drafts directories can be found in
<A href="">http://www.ietf.org/shadow.html</A> 
or <A href="">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A>

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
</PRE>
<DL>
  <DT><A 
  href="">&lt;ftp://ftp.ietf.org/internet-drafts/draft-chen-idr-bgp-nexthop-orf-00.txt&gt;</A> 

  <DD></DD></DL><PRE>_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
<A href="">https://www1.ietf.org/mailman/listinfo/i-d-announce</A>
</PRE><!--X-Body-of-Message-End--><!--X-MsgBody-End--><!--X-Follow-Ups--></FONT>
<P>
<HR>
</FONT></DIV></BODY></HTML>

--Boundary_(ID_oq9Mtu37j9E4c7lEMy9/Dg)--


--===============0783874398==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0783874398==--




From idr-bounces@ietf.org Wed Oct 18 18:07:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaJ4C-0001Op-6C; Wed, 18 Oct 2006 17:35:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ4A-0001HV-C5
	for idr@ietf.org; Wed, 18 Oct 2006 17:35:10 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaEX8-0005DK-6z
	for idr@ietf.org; Wed, 18 Oct 2006 12:44:46 -0400
Received: from mailout06.yourhostingaccount.com ([65.254.254.64])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaER9-0005Re-W6
	for idr@ietf.org; Wed, 18 Oct 2006 12:38:38 -0400
Received: from scan03.yourhostingaccount.com ([10.1.1.233]
	helo=scan03.yourhostingaccount.com)
	by mailout06.yourhostingaccount.com with esmtp (Exim)
	id 1GaER8-0003Ec-3O for idr@ietf.org; Wed, 18 Oct 2006 12:38:34 -0400
Received: from authsmtp10.yourhostingaccount.com ([10.1.18.10] ident=exim)
	by scan03.yourhostingaccount.com with spamscanlookuphost (Exim)
	id 1GaER7-00030g-PB for idr@ietf.org; Wed, 18 Oct 2006 12:38:33 -0400
Received: from authsmtp10.yourhostingaccount.com ([10.1.18.10]
	helo=authsmtp10.yourhostingaccount.com)
	by scan03.yourhostingaccount.com with esmtp (Exim)
	id 1GaER4-00030J-Gj for idr@ietf.org; Wed, 18 Oct 2006 12:38:32 -0400
Received: from 108.114.2.81.in-addr.arpa ([81.2.114.108] helo=[192.168.0.43])
	by authsmtp10.yourhostingaccount.com with esmtpa (Exim)
	id 1GaER4-0002cV-3F for idr@ietf.org; Wed, 18 Oct 2006 12:38:30 -0400
Message-ID: <45365884.3020601@abelon.com>
Date: Wed, 18 Oct 2006 17:38:28 +0100
From: Neil Matthew <neil@abelon.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: idr@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-EN-UserInfo: e65bfd3d72dfaaaf5ffb0de99fd01ea2:0d98aba8e5f6749be2df7f931a889135
X-EN-AuthUser: neilrm
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Subject: [Idr] draft-ietf-as-pathlimit-02
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Hi Folks

I have a couple of questions regarding this draft.

1. Section 5.1 states that the route's AS_PATHLIMIT MUST NOT be 
modified.  Section 5.2 talks about attaching an AS_PATHLIMIT attribute 
but doesn't say anything about being permitted to remove it.  Am I 
permitted to 'change' a received AS_PATHLIMIT by deleting and 
re-adding?  Some email exchanges in the archive would seem to suggest 
the answer to this is yes.

2. With respect to the use of the ATOMIC_AGGREGATE.  Maybe I'm missing 
something here and I think that this has already been mentioned on the 
list before but it appears that the specified behaviour matches the old 
BGP RFC and not the latest RFC?  Are folks happy with the path-limit 
specification adopting the old style behaviour?  Actually I'd really 
appreciate it if someone could explain why this is required at all! :)

Cheers


Neil


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



From idr-bounces@ietf.org Thu Oct 19 12:19:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GaaZo-0005CR-1m; Thu, 19 Oct 2006 12:17:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GaaZm-00054q-N1
	for idr@ietf.org; Thu, 19 Oct 2006 12:16:58 -0400
Received: from sleibrand-ibm.acs.internap.com ([63.251.67.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaaZd-0000hT-L7
	for idr@ietf.org; Thu, 19 Oct 2006 12:16:58 -0400
Received: from sleibrand (helo=localhost)
	by sleibrand-ibm.acs.internap.com with local-esmtp (v3.35.1)
	id 1GaaZb-0005VC-00; Thu, 19 Oct 2006 12:16:47 -0400
Date: Thu, 19 Oct 2006 12:16:47 -0400 (EDT)
From: Scott Leibrand <sleibrand@internap.com>
To: Neil Matthew <neil@abelon.com>
Subject: Re: [Idr] draft-ietf-as-pathlimit-02
In-Reply-To: <45365884.3020601@abelon.com>
Message-ID: <Pine.LNX.4.58.0610191214420.29963@sleibrand-ibm.acs.internap.com>
References: <45365884.3020601@abelon.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

On 10/18/06 at 5:38pm +0100, Neil Matthew <neil@abelon.com> wrote:

> 2. With respect to the use of the ATOMIC_AGGREGATE.  Maybe I'm missing
> something here and I think that this has already been mentioned on the
> list before but it appears that the specified behaviour matches the old
> BGP RFC and not the latest RFC?  Are folks happy with the path-limit
> specification adopting the old style behaviour?  Actually I'd really
> appreciate it if someone could explain why this is required at all! :)

You may be referring (in part) to a comment I made a while back, which I
don't believe was ever answered:

> I'm also a bit confused by your ATOMIC_AGGREGATE comments.  Hopefully
> you can clarify things for me so that everything that follows is
> irrelevant, but here I go...  :)
>
> While I understand that ATOMIC_AGGREGATE is mandatory when automatically
> aggregating routes, in most cases an aggregate is simply redistributed
> independently into BGP, having originally been tied down to an interface
> (or Null0), while the longer prefix (sometimes with a different AS path)
> is dropped or passed along independently, based on policy or NO_EXPORT.
> My reading of the draft is that if I have a more-specific that I put
> AS_PATHLIMIT on, then any AS who drops the route due to my AS_PATHLIMIT
> will have to change my less-specific route and add ATOMIC_AGGREGATE to
> it. IMO this is a Bad Thing, to have my upstreams modifying my aggregate
> routes.  The draft recommends that if I do this I also advertise the
> ATOMIC_AGGREGATE attribute on my less-specific.  However, this seems to
> be a paradigm shift from the way most of the world uses BGP, in that it
> requires me to automatically aggregate my routes rather than advertising
> the larger aggregate separately as a null tiedown, or to somehow
> configure my null tiedown to be redistributed into BGP with
> ATOMIC_AGGREGATE set (which I don't think I can do on my routers today).
>
> IMO a much cleaner behavior is to simply extend BGP's current behavior
> as follows:
>  - If a route has AS_PATHLIMIT on it and the path limit is met or
> exceeded, drop it the same way you would a route with NO_EXPORT on it,
> without any regard to presence or absence of less specific prefixes.
>  - If routes happen to be aggregated with aggregate-address or similar,
> set AS_SET and ATOMIC_AGGREGATE as you do today.
>  - If an aggregate is created by redistribution from an IGP, don't set
> ATOMIC_AGGREGATE on it, and don't modify it later based on actions taken
> on a route that happens to be a more specific.

-Scott

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



From idr-bounces@ietf.org Fri Oct 27 15:29:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GdXLP-0006sZ-If; Fri, 27 Oct 2006 15:26:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXLO-0006ek-FW
	for idr@ietf.org; Fri, 27 Oct 2006 15:26:18 -0400
Received: from mail-red.research.att.com ([192.20.225.110])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdX8W-00075q-3C
	for idr@ietf.org; Fri, 27 Oct 2006 15:13:04 -0400
Received: from bright.research.att.com (bright.research.att.com
	[135.207.20.189])
	by mail-blue.research.att.com (Postfix) with ESMTP id EADCF147746
	for <idr@ietf.org>; Fri, 27 Oct 2006 15:12:59 -0400 (EDT)
Received: (from fenner@localhost)
	by bright.research.att.com (8.12.11.20060308/8.12.10/Submit) id
	k9RJCxcc024213; Fri, 27 Oct 2006 12:12:59 -0700
From: Bill Fenner <fenner@research.att.com>
Message-Id: <200610271912.k9RJCxcc024213@bright.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: idr@ietf.org
Date: Fri, 27 Oct 2006 12:12:59 -0700
Versions: dmail (linux) 2.7/makemail 2.14
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Subject: [Idr] Early allocation for draft-ietf-idr-as-pathlimit
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org


----- Begin forwarded message:

From: "Amanda Baber via RT" <iana-prot-param@icann.org>
Subject: [IANA #31975] Early allocation request: BGP Path Attribute (bgp-parameters)
Date: Fri, Oct 27 12:01:17 
To: fenner@research.att.com
Reply-to: iana-prot-param@icann.org

Dear Bill,

The following BGP Path Attribute has been assigned according to the Early IANA 
Allocation process:

21   AS_PATHLIMIT

Please see

http://www.iana.org/assignments/bgp-parameters

Thank you for your patience.

Regards,

Amanda Baber
Internet Assigned Numbers Authority (IANA)


On Sat Oct 14 11:42:07 2006, fenner@research.att.com wrote:
> 
> Dear IANA,
> 
>   Per RFC 4020 and RFC 4271, please make an Early allocation for
> the BGP Attribute requested in draft-ietf-idr-as-pathlimit.  Please
> work with the authors and WG chairs as needed.
> 
> Thanks,
>   Bill
> 
> ----- Begin forwarded message:
> 
> From: Yakov Rekhter <yakov@juniper.net>
> Subject: request for an early allocation
> Date: Thu, Oct 12 06:30:10 
> To: fenner@research.att.com, rcallon@juniper.net
> Cc: idr@ietf.org, skh@nexthop.com
> 
> Bill and Ross,
> 
> Please approve a request for an early allocation of a new BGP
> attribute code point. The attribute is defined in
> draft-ietf-idr-as-pathlimit. The IDR WG has a consensus that
> early allocation of the new code point is appropriate.
> 
> Yakov.
> 
> ----- End forwarded message:
> 




----- End forwarded message:

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



From idr-bounces@ietf.org Mon Oct 30 06:01:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeUpg-0007pd-9c; Mon, 30 Oct 2006 05:57:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeUjl-000372-JO
	for idr@ietf.org; Mon, 30 Oct 2006 05:51:25 -0500
Received: from mailout16.yourhostingaccount.com ([65.254.253.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeUjh-00007H-As
	for idr@ietf.org; Mon, 30 Oct 2006 05:51:25 -0500
Received: from scan09.yourhostingaccount.com ([10.1.1.239]
	helo=scan09.yourhostingaccount.com)
	by mailout16.yourhostingaccount.com with esmtp (Exim)
	id 1GeUjg-0005nh-OD for idr@ietf.org; Mon, 30 Oct 2006 05:51:20 -0500
Received: from authsmtp10.yourhostingaccount.com ([10.1.18.10] ident=exim)
	by scan09.yourhostingaccount.com with spamscanlookuphost (Exim)
	id 1GeUjg-0005bO-BQ for idr@ietf.org; Mon, 30 Oct 2006 05:51:20 -0500
Received: from authsmtp10.yourhostingaccount.com ([10.1.18.10]
	helo=authsmtp10.yourhostingaccount.com)
	by scan09.yourhostingaccount.com with esmtp (Exim)
	id 1GeUjf-0005bJ-IF for idr@ietf.org; Mon, 30 Oct 2006 05:51:19 -0500
Received: from 108.114.2.81.in-addr.arpa ([81.2.114.108] helo=[192.168.0.43])
	by authsmtp10.yourhostingaccount.com with esmtpa (Exim)
	id 1GeUjf-0003PT-0G; Mon, 30 Oct 2006 05:51:19 -0500
Message-ID: <4545D919.8050507@abelon.com>
Date: Mon, 30 Oct 2006 10:51:05 +0000
From: Neil Matthew <neil@abelon.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Neil Matthew <neil@abelon.com>
Subject: Re: [Idr] draft-ietf-as-pathlimit-02
References: <45365884.3020601@abelon.com>
In-Reply-To: <45365884.3020601@abelon.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-EN-UserInfo: e65bfd3d72dfaaaf5ffb0de99fd01ea2:0d98aba8e5f6749be2df7f931a889135
X-EN-AuthUser: neilrm
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Time passes...

So, no takers on these?  Point 1 is just me looking for clarification 
but point 2 would appear to be a real issue.  I believe Jeffrey Haas has 
also expressed a concern 
(http://thread.gmane.org/gmane.ietf.idr/4001/focus=4005) so that's at 
least 3 of us!  If this is the way things are to be implemented I'd at 
least like to know why! :)

Cheers

Neil

Neil Matthew wrote:

> Hi Folks
>
> I have a couple of questions regarding this draft.
>
> 1. Section 5.1 states that the route's AS_PATHLIMIT MUST NOT be 
> modified.  Section 5.2 talks about attaching an AS_PATHLIMIT attribute 
> but doesn't say anything about being permitted to remove it.  Am I 
> permitted to 'change' a received AS_PATHLIMIT by deleting and 
> re-adding?  Some email exchanges in the archive would seem to suggest 
> the answer to this is yes.
>
> 2. With respect to the use of the ATOMIC_AGGREGATE.  Maybe I'm missing 
> something here and I think that this has already been mentioned on the 
> list before but it appears that the specified behaviour matches the 
> old BGP RFC and not the latest RFC?  Are folks happy with the 
> path-limit specification adopting the old style behaviour?  Actually 
> I'd really appreciate it if someone could explain why this is required 
> at all! :)
>
> Cheers
>
>
> Neil
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www1.ietf.org/mailman/listinfo/idr
>


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



From idr-bounces@ietf.org Mon Oct 30 08:36:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GeXGf-0006RM-Ac; Mon, 30 Oct 2006 08:33:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GeXGd-0006RE-Kp
	for idr@ietf.org; Mon, 30 Oct 2006 08:33:31 -0500
Received: from monster.hopcount.ca ([199.212.90.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeXGc-0006cr-8g
	for idr@ietf.org; Mon, 30 Oct 2006 08:33:31 -0500
Received: from [64.235.108.48] (helo=[192.168.182.2])
	by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.63 (FreeBSD)) (envelope-from <jabley@ca.afilias.info>)
	id 1GeXGL-000Ar9-Pn; Mon, 30 Oct 2006 13:33:15 +0000
In-Reply-To: <4545D919.8050507@abelon.com>
References: <45365884.3020601@abelon.com> <4545D919.8050507@abelon.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <70D29A01-DF86-47A5-B6E4-C2B2AFA85BDF@ca.afilias.info>
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@ca.afilias.info>
Subject: Re: [Idr] draft-ietf-as-pathlimit-02
Date: Mon, 30 Oct 2006 08:33:06 -0500
To: Neil Matthew <neil@abelon.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Hi Neil,

On 30-Oct-2006, at 05:51, Neil Matthew wrote:

> Time passes...

Thorin sits down and starts singing about gold.

> So, no takers on these?  Point 1 is just me looking for  
> clarification but point 2 would appear to be a real issue.  I  
> believe Jeffrey Haas has also expressed a concern (http:// 
> thread.gmane.org/gmane.ietf.idr/4001/focus=4005) so that's at least  
> 3 of us!  If this is the way things are to be implemented I'd at  
> least like to know why! :)

I've been preoccupied with some other work; I apologise for not being  
behind. Interrupt contention.

> Neil Matthew wrote:
>
>> Hi Folks
>>
>> I have a couple of questions regarding this draft.
>>
>> 1. Section 5.1 states that the route's AS_PATHLIMIT MUST NOT be  
>> modified.  Section 5.2 talks about attaching an AS_PATHLIMIT  
>> attribute but doesn't say anything about being permitted to remove  
>> it.  Am I permitted to 'change' a received AS_PATHLIMIT by  
>> deleting and re-adding?  Some email exchanges in the archive would  
>> seem to suggest the answer to this is yes.

My personal view is that it ought to be possible to remove an  
AS_PATHLIMIT attribute as part of the normal application of local  
policy within an AS, and that the draft should be modified to make  
this more clear.

[If you can do it with other, similar attributes (e.g. the  
NO_ADVERTISE and NO_EXPORT community string attributes) it makes no  
sense to me to prohibit this with AS_PATHLIMIT.]

It follows that removing an AS_PATHLIMIT attribute which is already  
present and then adding a replacement AS_PATHLIMIT attribute ought to  
be possible.

>> 2. With respect to the use of the ATOMIC_AGGREGATE.  Maybe I'm  
>> missing something here and I think that this has already been  
>> mentioned on the list before but it appears that the specified  
>> behaviour matches the old BGP RFC and not the latest RFC?  Are  
>> folks happy with the path-limit specification adopting the old  
>> style behaviour?  Actually I'd really appreciate it if someone  
>> could explain why this is required at all! :)

    BGP requires that a BGP speaker that advertises a less specific
    prefix, but not a more specific prefix that it is using, must
    advertise the less specific prefix with the ATOMIC_AGGREGATE
    attribute.  BGP speakers that do not advertise a more specific  
prefix
    based on the AS_PATHLIMIT must comply with this rule and advertise
    the less specific prefixes with the ATOMIC_AGGREGATE attribute.  To
    help ensure compliance with this, sites that choose to advertise the
    AS_PATHLIMIT path attribute should advertise the ATOMIC_AGGREGATE
    attribute on all less specific covering prefixes.

I think I'd be happy with removing this paragraph altogether,  
although it's before 9am and I have not yet reached my preferred  
caffeine levels so I reserve the right to disagree with myself at  
some later date. :-)


Joe



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



From idr-bounces@ietf.org Mon Oct 30 17:20:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GefRi-00009S-70; Mon, 30 Oct 2006 17:17:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GefQe-0008Fv-SK
	for idr@ietf.org; Mon, 30 Oct 2006 17:16:24 -0500
Received: from colo-dns-ext1.juniper.net ([207.17.137.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GefJF-00084y-CF
	for idr@ietf.org; Mon, 30 Oct 2006 17:08:49 -0500
Received: from magenta.juniper.net (magenta.juniper.net [172.17.28.122])
	by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k9UM8cX84713
	for <idr@ietf.org>; Mon, 30 Oct 2006 14:08:42 -0800 (PST)
	(envelope-from yakov@juniper.net)
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])
	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id k9UM8XE37495
	for <idr@ietf.org>; Mon, 30 Oct 2006 14:08:33 -0800 (PST)
	(envelope-from yakov@juniper.net)
Message-Id: <200610302208.k9UM8XE37495@magenta.juniper.net>
To: idr@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9153.1162246113.1@juniper.net>
Date: Mon, 30 Oct 2006 14:08:33 -0800
From: Yakov Rekhter <yakov@juniper.net>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Subject: [Idr] Update to Internet-Draft and RFC Boilerplate 
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>,
	<mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

fyi
------- Forwarded Message

Date:    Thu, 26 Oct 2006 21:19:59 -0400
From:    IETF Chair <chair@ietf.org>
To:      IETF Announcement list <ietf-announce@ietf.org>
cc:      
Subject: Update to Internet-Draft and RFC Boilerplate 

A small update to BCP 78 was recently approved by the IESG as
RFC 4748, to update the boilerplate (i.e., standard legal text) in 
RFCs and Internet-Drafts to recognize the IETF Trust as a rights 
holder, instead of ISOC.

The actual boilerplate changes are given below this message.

Starting as soon as reasonably possible, all authors of Internet-Drafts 
are requested to use the new boilerplate. The RFC Editor will in any case
be inserting it in all RFCs issued from 2006-11-01. (The rights held by 
ISOC in older RFCs will be administratively transferred to the IETF
Trust.)

The public ID Nits checker already accepts I-Ds with old or new
boilerplate.
The Secretariat has started accepting I-Ds with old or new boilerplate

XML2RFC version 1.32 will generate the new boilerplate.
Users of I-D templates are requested to update them appropriately.

http://www.ietf.org/ID-Checklist.html and
http://www.ietf.org/ietf/1id-guidelines.html are being updated.

Starting December, the public ID Nits checker will issue warnings for 
old boilerplate.

Starting February 2007, the Secretariat will refuse 
the old boilerplate in Internet-Drafts.

We are sorry for the inconvenience, but this change cannot
be avoided.

    IETF Chair
    IETF Secretariat
    TOOLS Team

- --------

Copyright Notice (required for all IETF Documents)

   (Normally placed at the end of the IETF Document.)

NOTE: by convention, the first line of the copyright statement
is usually placed near the beginning of each document. This must
also be updated.

OLD
      "Copyright (C) The Internet Society (year).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.

NEW
      "Copyright (C) The IETF Trust (year).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.


Disclaimer (required in all IETF Documents)

   (Normally placed at the end of the IETF Document after the copyright
   notice.)


OLD
      "This document and the information contained herein are provided
      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
      PARTICULAR PURPOSE."


NEW
      "This document and the information contained herein are provided
      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
      IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
      WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
      ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
      FOR A PARTICULAR PURPOSE."

Exceptions

      In MIB modules, PIB modules and similar material commonly
      extracted from IETF Documents, except for material that is being
      placed under IANA maintenance, the following abbreviated notice
      shall be included in the body of the material that will be
      extracted in lieu of the notices otherwise required by Section 5:

OLD
         "Copyright (C) The Internet Society <year>.  This version of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

NEW
         "Copyright (C) The IETF Trust <year>.  This version of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

      When the MIB or PIB module is the initial version of a module that
      is to be maintained by the IANA, the following abbreviated notice
      shall be included:

OLD
         "Copyright (C) The Internet Society <year>.  The initial
         version of this MIB module was published in RFC XXXX; for full
         legal notices see the RFC itself.  Supplementary information
         may be available at:
         http://www.ietf.org/copyrights/ianamib.html."

NEW
         "Copyright (C) The IETF Trust <year>.  The initial
         version of this MIB module was published in RFC XXXX; for full
         legal notices see the RFC itself.  Supplementary information
         may be available at:
         http://www.ietf.org/copyrights/ianamib.html."

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

------- End of Forwarded Message


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