Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05

"George, Wes" <wesley.george@twcable.com> Tue, 18 September 2012 20:21 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE6921E8042 for <sidr@ietfa.amsl.com>; Tue, 18 Sep 2012 13:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.462
X-Spam-Level:
X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttMF4suy40Vp for <sidr@ietfa.amsl.com>; Tue, 18 Sep 2012 13:21:57 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6951F21E8040 for <sidr@ietf.org>; Tue, 18 Sep 2012 13:21:57 -0700 (PDT)
X-SENDER-IP: 10.136.163.13
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.80,445,1344225600"; d="scan'208";a="422334172"
Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 18 Sep 2012 16:21:18 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 18 Sep 2012 16:21:55 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "sidr@ietf.org" <sidr@ietf.org>
Date: Tue, 18 Sep 2012 16:21:55 -0400
Thread-Topic: WGLC for draft-ietf-sidr-bgpsec-protocol-05
Thread-Index: Ac2TN5E+gtWY3jVQTo2aIJ20K9PIbgCmdL0w
Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59235EFAAF6F@PRVPEXVS15.corp.twcable.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 18 Sep 2012 20:21:58 -0000

Nits:
Multiple sections have "musts" and "shoulds" that are not 2119-formatted (lower-case) - please ensure that this is intentional

Substantial:

Any reason why we're using "good" and "not good"  for validation state instead of valid/invalid (and unknown)? I'd think that consistency between this and the language in the origin validation stuff would be helpful unless we have a specific reason not to use the same language. And I realize that there isn't really an "unknown" status as the result of trying to validate a BGPSec update, but as far as the implementation is concerned, standard BGP updates (those without BGPSec) are considered unknown, and it might be good to explicitly state that as a part of the validation algorithm.

I'm awaiting co-author review of the I-D version of the email I wrote about AS-Migration, and am hoping to have it posted next week sometime. I think that we need to discuss the considerations from that issue to ensure that no changes need to be made in the protocol spec document/design before we progress this. There's been some discussion of using pcount=0 to manage some parts of this, but that would have to be covered in the update validation and origination algorithm if we choose to solve the problem that way. Also I'm not completely certain that pcount will solve the use case completely. I'm not opposed to using the draft as a follow-on to the protocol draft (update it) to handle this specific case, but I'd like to have WG consensus that this is the route we should take rather than incorporating any solution for this use case into the current document since it is still in draft.

Thanks,

Wes George


> -----Original Message-----
> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of
> Murphy, Sandra
> Sent: Saturday, September 15, 2012 7:45 AM
> To: sidr@ietf.org
> Subject: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05
>
> This starts a working group last call for draft-ietf-sidr-bgpsec-
> protocol-05.  The draft is available at
> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/
>
> Please review this draft to see if you think it is ready for
> publication.  Send end comments to the list.
>
> The WGLC will end on 29 September 2012.
>
> --Sandy, speaking as wg co-chair
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

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.