Re: [Idr] Pete Resnick's Discuss on draft-ietf-idr-as-migration-03: (with DISCUSS and COMMENT)

"George, Wes" <> Thu, 19 February 2015 19:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 249F81A003A; Thu, 19 Feb 2015 11:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uMSSgi0Opn0l; Thu, 19 Feb 2015 11:24:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 708D01A0089; Thu, 19 Feb 2015 11:23:51 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.09,610,1418101200"; d="scan'208";a="264162069"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 19 Feb 2015 14:18:10 -0500
Received: from ([]) by ([]) with mapi; Thu, 19 Feb 2015 14:23:50 -0500
From: "George, Wes" <>
To: Pete Resnick <>, The IESG <>
Date: Thu, 19 Feb 2015 14:23:49 -0500
Thread-Topic: Pete Resnick's Discuss on draft-ietf-idr-as-migration-03: (with DISCUSS and COMMENT)
Thread-Index: AdBMeZaxCeAaK7CMSQyKwka6lMrmmQ==
Message-ID: <>
References: <>
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] Pete Resnick's Discuss on draft-ietf-idr-as-migration-03: (with DISCUSS and COMMENT)
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: Thu, 19 Feb 2015 19:24:19 -0000

On 2/18/15, 11:36 PM, "Pete Resnick" <> wrote:

>A procedural DISCUSS, which I expect will be cleared on the call,
>whatever the outcome:
>RFC 2026 says this in section 5 regarding what a BCP is for:
>   Historically Internet standards have generally been concerned with
>   the technical specifications for hardware and software required for
>   computer communication across interconnected networks.  However,
>   since the Internet itself is composed of networks operated by a great
>   variety of organizations, with diverse goals and rules, good user
>   service requires that the operators and administrators of the
>   Internet follow some common guidelines for policies and operations.
>   While these guidelines are generally different in scope and style
>   from protocol standards, their establishment needs a similar process
>   for consensus building.
>That sounds like exactly what this document is doing. Sounds like it
>should be a BCP. Is there a reason it shouldn't be?

WG] as I said when asking the question of the WG, I don't have any
particular religion about what the document status is, because it has
little impact on the document's potential usefulness to its intended
audiences, which I think is the real goal of publishing it in the first
place. This document falls into a bit of a grey area due to the lack of
strict requirement for interop, but I don't agree that it conforms exactly
to the BCP definition you list above. Perhaps the draft is too flexible in
that regard, but I thought that would be a useful thing for implementers
since IETF's usual philosophy is to not be overly prescriptive except
where it is necessary to ensure proper interoperability. PS seemed the
right choice because it is still governing the behavior (albeit optional
and only locally-significant) for what we'd consider a BGP-compliant
implementation. I will note that the companion draft in SIDR is much more
clearly a PS because it normatively alters the protocol behavior, and thus
if idr-as-migration is changed to a lesser status, we have a problem of a
down ref normative reference. Not the biggest problem ever, but worth
considering when discussing potential status changes. I do think that the
normative reference in SIDR-as-migration must remain normative, because
that document is predicated on the idea that it is updating SIDR BGPSec to
allow for a now standardized part of the BGP protocol. It makes less sense
to standardize something in BGPSec to allow for an implementation that is
only a de facto standard. Whether informational or BCP status would raise
that concern is a matter of interpretation that I leave to those on the
IESG that see the document's status as an issue.



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.