Re: [sidr] New version draft-ietf-sidr-bgpsec-protocol

"George, Wes" <wesley.george@twcable.com> Mon, 07 July 2014 16:40 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BC21A0352 for <sidr@ietfa.amsl.com>; Mon, 7 Jul 2014 09:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.285
X-Spam-Level: **
X-Spam-Status: No, score=2.285 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50NZHkoqo5E4 for <sidr@ietfa.amsl.com>; Mon, 7 Jul 2014 09:40:22 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7558F1A0344 for <sidr@ietf.org>; Mon, 7 Jul 2014 09:40:21 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.01,619,1400040000"; d="scan'208,217";a="392717099"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 Jul 2014 12:40:19 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 7 Jul 2014 12:40:20 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Matthew Lepinski <mlepinski.ietf@gmail.com>, "sidr@ietf.org" <sidr@ietf.org>
Date: Mon, 07 Jul 2014 12:40:19 -0400
Thread-Topic: [sidr] New version draft-ietf-sidr-bgpsec-protocol
Thread-Index: Ac+aAiOLOBNyil3zTDuLZ7O41ge1ig==
Message-ID: <CFE041BA.21BB6%wesley.george@twcable.com>
References: <CANTg3aC2z=YiTbMMr3XXQZjfjiQM0=55Odt_8Ci9OT=7RpB-pQ@mail.gmail.com>
In-Reply-To: <CANTg3aC2z=YiTbMMr3XXQZjfjiQM0=55Odt_8Ci9OT=7RpB-pQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.3.140616
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CFE041BA21BB6wesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/xbfXnqJYX7TnapH3pMmDAwKTB4Y
Subject: Re: [sidr] New version draft-ietf-sidr-bgpsec-protocol
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jul 2014 16:40:23 -0000

From: Matthew Lepinski <mlepinski.ietf@gmail.com<mailto:mlepinski.ietf@gmail.com>>
Date: Friday, July 4, 2014 at 6:16 PM
To: "sidr@ietf.org<mailto:sidr@ietf.org>" <sidr@ietf.org<mailto:sidr@ietf.org>>
Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol

I submitted a new version of the bgpsec protocol document. This revision includes a fair number of editorial changes but does not include any normative changes.

Now that the BGPSEC requirements document is essentially done, I look forward to discussing the protocol document again in Toronto. In particular, between now and the Toronto meeting I will write up (and send to the list) a brief comparison between the requirements in the final version of the reqs draft and what we deliver in the protocol document.

The only open issue in the protocol document that I am aware of is the following:

[snip]

Matt -

One additional change I think is necessary is to add a reference to ietf-sidr-as-migration. This is effectively an extension of the BGPSec protocol that is contained in a separate document. If the BGPSec doc was already done, I'd most likely be using the metadata of as-migration to update RFCnnnn so that the link would exist from the BGPSec protocol doc in addition to the normative reference to -protocol from as–migration, but in the current form where it's trivial to update the -protocol draft, I think that should instead be accomplished by a forward reference, and then the two documents will simply be part of the group of interdependent docs that get released for BGPSec (assuming of course that -as–migration passes LC).

That said, my quick scan of –protocol didn't reveal an obvious place to insert that reference, so if you or others have ideas of where it should go, I'm happy to contribute a few lines of wrapper text.

Thanks,

Wes

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.