Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt

"George, Wes" <> Mon, 20 April 2015 18:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1063D1B3015 for <>; Mon, 20 Apr 2015 11:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.625
X-Spam-Level: *
X-Spam-Status: No, score=1.625 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DYnzpsWHR1Ye for <>; Mon, 20 Apr 2015 11:33:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AA33B1B3014 for <>; Mon, 20 Apr 2015 11:33:10 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.11,610,1422939600"; d="scan'208";a="286419848"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 20 Apr 2015 14:24:46 -0400
Received: from ([]) by ([]) with mapi; Mon, 20 Apr 2015 14:33:04 -0400
From: "George, Wes" <>
To: "UTTARO, JAMES" <>, 'Susan Hares' <>
Date: Mon, 20 Apr 2015 14:33:03 -0400
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt
Thread-Index: AdB7mHAuqqjqMItETrybTXE1Lqmasw==
Message-ID: <>
References: <> <> <02e401d072e4$4f5a1cc0$ee0e5640$> <> <> <001f01d07b3f$13ee12f0$3bca38d0$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "''" <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as-migration-04.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Apr 2015 18:33:12 -0000

On 4/20/15, 8:44 AM, "UTTARO, JAMES" <> wrote:

>What would be great is that the features that are being used are
>standardized across vendors. The current approach where each
>implementation varies in behavior will make life difficult.

WG] While I agree that this could potentially simplify things for
operators, the IETF can't force that to happen. Only those specifying
which features they require from their vendors and signing the large
checks to buy the kit can do that. Anyone who wishes to use an RFC as a
club against a vendor is welcome to do so, but changing the language in
the document to require compliance with our version of already-implemented
features that isn't required for interop reasons will not actually have
any effect.



Anything below this line has been added by my company’s mail server, I
have no control over it.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.