From alexey.melnikov@isode.com Fri May 3 07:14:41 2013 Return-Path: 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 B84B321F87D0 for ; Fri, 3 May 2013 07:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEryF2v6dPO1 for ; Fri, 3 May 2013 07:14:37 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0990821F86D3 for ; Fri, 3 May 2013 07:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1367590474; d=isode.com; s=selector; i=@isode.com; bh=ZSHz15Ks9BPT0AIPU+DulTieDdaKvpwwxmRBS5GUpsg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=YWC2fSxAUw6optRyyAqS1rqHwEuh6lrug49Uj6LzuKxSfcvm0c9r9g6OZ1p3TQ8/7K6Byk A/Din5VdzofZyBWbkLG8EaYI8BNj6BXg08oyZ9N5TQR+O2E8J7sJQxxmNvkndmYBncmtSC 3VcDapIRNYwUx6UPbz8rzq9YShElAGM=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 3 May 2013 15:14:34 +0100 Message-ID: <5183C65F.1080001@isode.com> Date: Fri, 03 May 2013 15:14:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "sidr@ietf.org" References: <24B20D14B2CD29478C8D5D6E9CBB29F65C2350DF@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F65C2350DF@Hermes.columbia.ads.sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] wg adoption call for draft-rogaglia-sidr-multiple-publication-points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 14:14:41 -0000 On 12/03/2013 17:54, Murphy, Sandra wrote: > The authors of draft-rogaglia-sidr-multiple-publication-points have requested wg adoption. > > See http://tools.ietf.org/html/draft-rogaglia-sidr-multiple-publication-points > > Please do respond to the list as to whether you support the wg adopting this as a work item. Note that you do not need to comment on the content of this draft at this time. You are asked to indicate if you think that this is work that the wg should be doing and whether this draft is an acceptable starting point. Adding whether you can/will review or not is useful. > > This adoption call will end on Tuesday, March 26, 2013 (extra time because many of those in the wg are busy at the ietf this week). Multiple people voiced their support for adopting the document as the starting point for the discussion. Nobody voiced their opposition to adopting the document. WG participants have spoken, so the document is now adopted by the WG. Best Regards, Alexey, on behalf of SIDR WG chairs. From stbryant@cisco.com Mon May 6 05:30:43 2013 Return-Path: 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 ECF6C21F8EAC for ; Mon, 6 May 2013 05:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.299 X-Spam-Level: X-Spam-Status: No, score=-109.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slKmDZhOpPKm for ; Mon, 6 May 2013 05:30:38 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 56E6321F8EA5 for ; Mon, 6 May 2013 05:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7975; q=dns/txt; s=iport; t=1367843437; x=1369053037; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=b3i8UH3FQEKLrwtNavKuXttPO09CX1u6ptwXhe9X4LY=; b=DUiAewFXlOUJeUJUBCnAT76Kuo/85mdtF+V3A92pbTBz5D+5dr5zN2nM o2BJ3rddDlYrcpY5tcDdBFtjINwafcaN12NAU3vbZtoLv5FEMYB50BR0I Z3SIpMiSJikcQrOD95cx+HU41cOTVBmbtu1unItRNYQJUQVWRtRV6br/+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMGAFShh1GQ/khN/2dsb2JhbAA2GoMHN4katWiBBBZ0gh8BAQEEeA0EHAMBAgoWDwkDAgECATsCCAYBDAYCAQGICAwzvnmNZIE8GAaDTQOXLpE0gw55 X-IronPort-AV: E=Sophos;i="4.87,621,1363132800"; d="scan'208,217";a="13764553" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 06 May 2013 12:30:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r46CUYIi016325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 May 2013 12:30:34 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r46CUW59009255; Mon, 6 May 2013 13:30:33 +0100 (BST) Message-ID: <5187A268.5010703@cisco.com> Date: Mon, 06 May 2013 13:30:32 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "sidr-chairs@tools.ietf.org" , sidr wg list References: <20130506122439.12042B1E003@rfc-editor.org> In-Reply-To: <20130506122439.12042B1E003@rfc-editor.org> X-Forwarded-Message-Id: <20130506122439.12042B1E003@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------010100000603060207070500" Subject: [sidr] Fwd: [Errata Rejected] RFC6487 (3168) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 12:30:43 -0000 This is a multi-part message in MIME format. --------------010100000603060207070500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Whilst this change was supported by one author and one of the chairs, it is a technical change and thus outside the scope of change permitted in an errata. The correct approach is for a member of the WG to produce a short update draft and test that this has WG and IETF consensus. Please can the chairs drive this process. - Stewart -------- Original Message -------- Subject: [Errata Rejected] RFC6487 (3168) Date: Mon, 6 May 2013 05:24:39 -0700 From: RFC Errata System To: , , , CC: , , The following errata report has been rejected for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3168 -------------------------------------- Status: Rejected Type: Technical Reported by: David Mandelberg Date Reported: 2012-03-26 Rejected by: Stewart Bryant (IESG) Section: 4.8 Original Text ------------- or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized [RFC5280]. Corrected Text -------------- or non-critical. A certificate-using system MUST reject the certificate if it encounters an extension not explicitly mentioned in this document. This is in contrast to RFC 5280 which allows non-critical extensions to be ignored. Notes ----- Other sections of the same document contradict the original section 4.8: Section 1: Any extensions not explicitly mentioned MUST be absent. The same applies to the CRLs used in the RPKI, that are also profiled in this document. Section 8: Certificate Extensions: This profile does not permit the use of any other critical or non-critical extensions. --VERIFIER NOTES-- This is a technical change to the RFC and needs to be addressed though the IETF consensus process and rather than via the errata process. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG . --------------010100000603060207070500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Whilst this change was supported by one author and one of the chairs,
it is a technical change and thus outside the scope of change
permitted in an errata.

The correct approach is for a member of the WG to produce a
short update draft and test that this has WG and IETF consensus.

Please can the chairs drive this process.

- Stewart


-------- Original Message --------
Subject: [Errata Rejected] RFC6487 (3168)
Date: Mon, 6 May 2013 05:24:39 -0700
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: <dmandelb@bbn.com>, <gih@apnic.net>, <ggm@apnic.net>, <robertl@apnic.net>
CC: <stbryant@cisco.com>, <iesg@ietf.org>, <rfc-editor@rfc-editor.org> 


The following errata report has been rejected for RFC6487,
"A Profile for X.509 PKIX Resource Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3168

--------------------------------------
Status: Rejected
Type: Technical

Reported by: David Mandelberg <dmandelb@bbn.com>
Date Reported: 2012-03-26
Rejected by: Stewart Bryant (IESG)

Section: 4.8

Original Text
-------------
   or non-critical.  A certificate-using system MUST reject the

   certificate if it encounters a critical extension it does not

   recognize; however, a non-critical extension MAY be ignored if it is

   not recognized [RFC5280].

Corrected Text
--------------
   or non-critical.  A certificate-using system MUST reject the

   certificate if it encounters an extension not explicitly mentioned

   in this document.  This is in contrast to RFC 5280 which allows

   non-critical extensions to be ignored.

Notes
-----
Other sections of the same document contradict the original section 4.8:



Section 1:



   Any extensions not explicitly mentioned MUST be absent.  The same

   applies to the CRLs used in the RPKI, that are also profiled in this

   document.



Section 8:



   Certificate Extensions:

         This profile does not permit the use of any other critical or

         non-critical extensions.
 --VERIFIER NOTES-- 
   This is a technical change to the RFC and needs to be addressed though the IETF consensus process and rather than via the errata process.

--------------------------------------
RFC6487 (draft-ietf-sidr-res-certs-22)
--------------------------------------
Title               : A Profile for X.509 PKIX Resource Certificates
Publication Date    : February 2012
Author(s)           : G. Huston, G. Michaelson, R. Loomans
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

.


--------------010100000603060207070500-- From stbryant@cisco.com Mon May 6 06:16:36 2013 Return-Path: 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 39A8D21F8F17 for ; Mon, 6 May 2013 06:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZFoCgsguWz4 for ; Mon, 6 May 2013 06:16:30 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 555F321F8FAF for ; Mon, 6 May 2013 06:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1754; q=dns/txt; s=iport; t=1367846190; x=1369055790; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=d3bl9WLclkHPGECSH6PZDnkrQstOcyjbGGOreIuw6vY=; b=U8kXKRE0XIvO8iTlS0e0FRVbgoMykaqStdwxiNvwnLQlbaokSkfgpNbH 556obQA7Iv0fW8S0S+oM9ISLzWdDLoCHsAFMEDGKdAfCTiJka/9XdtPFe CRkN9QDpLmzyOOLbBrgUr4+C0swh8YTfK/IxHpY4kjWaZHzRPa1G5SR8f M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAIysh1GQ/khL/2dsb2JhbABQgwe8UoJngQQWdIIfAQEBBDhAARALDgoJFg8JAwIBAgFFBg0BBwEBiAi/V41kgU0Hg1MDly6RNIMO X-IronPort-AV: E=Sophos;i="4.87,621,1363132800"; d="scan'208";a="13298516" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 06 May 2013 13:16:20 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r46DGIqu016771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 May 2013 13:16:18 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r46DGFe1011499; Mon, 6 May 2013 14:16:15 +0100 (BST) Message-ID: <5187AD1F.7010109@cisco.com> Date: Mon, 06 May 2013 14:16:15 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: David Mandelberg References: <20120403182631.92C0072E004@rfc-editor.org> <0B52207B-078C-4651-BEB2-3A667934E6B7@apnic.net> <1333560064.10619.36.camel@titan> In-Reply-To: <1333560064.10619.36.camel@titan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sandra.Murphy@sparta.com, morrowc@ops-netman.net, sidr@ietf.org, ggm@apnic.net, RFC Errata System Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3174) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 13:16:36 -0000 On 04/04/2012 18:21, David Mandelberg wrote: > On Wed, 2012-04-04 at 09:27 +1000, Geoff Huston wrote: >> I'm tending to a "reject". Section 4.8.3 does not precisely apply to CRLs, so to accept this would then require a further errata notice to amend this errata to narrow down the scope of the AIA further. > AKI, not AIA. I just meant that the CRL AKI should have the same format > and meaning as in 4.8.3, i.e. it should use the SHA-1 hash of the > issuer's public key with neither authorityCertIssuer nor > authorityCertSerialNumber fields present. Maybe the errata should be > rejected and resubmitted with text copied and edited from 4.8.3, instead > of referencing 4.8.3? > > >> Given that the text already says: "The algorithm used in CRLs issued under this profile is specified in [RFC6485]." then I'm not not what futerhe specification is required here. > What part of RFC6485 says anything about CRL AKIs? The closest I can > find is in Section 2: > > NOTE: The exception to the above hashing algorithm is the use > of SHA-1 [SHS] when Certification Authorities (CAs) generate > authority and subject key identifiers [RFC6487]. > > That maybe could be interpreted as saying that CRL AKIs should use > SHA-1, but it doesn't say that authorityCertIssuer and > authorityCertSerialNumber must be absent. It also doesn't explicitly say > what to take the SHA-1 of when generating a CRL AKI. > As far as I can see the thread died at this point. I have rejected the errata. I see two ways forward, either submit a new errata that describes the correction in a way that has consensus, or roll the change into the update required to address the issue raised in errata 3168. - Stewart From achi@bbn.com Mon May 6 08:03:12 2013 Return-Path: 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 6B0FD21F93EB for ; Mon, 6 May 2013 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eg0DaI1As4o for ; Mon, 6 May 2013 08:03:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E121F93EF for ; Mon, 6 May 2013 08:03:06 -0700 (PDT) Received: from dhcp89-089-010.bbn.com ([128.89.89.10]:54365 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UZMwR-000Muw-2D; Mon, 06 May 2013 11:03:03 -0400 Message-ID: <5187C623.7070600@bbn.com> Date: Mon, 06 May 2013 11:02:59 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: stbryant@cisco.com References: <20130506122439.12042B1E003@rfc-editor.org> <5187A268.5010703@cisco.com> In-Reply-To: <5187A268.5010703@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr-chairs@tools.ietf.org" , sidr wg list Subject: Re: [sidr] Fwd: [Errata Rejected] RFC6487 (3168) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 15:03:12 -0000 Is this really a technical change? The document has two places that state X, and one place (citing 5280) that states Y. This erratum replaces the Y statement with X. All implementers have already implemented X since it's the stricter form of Y. X = no other extensions are allowed Y = non-critical extensions MAY be ignored If this truly is a technical change, then we should have an update doc. But I'm just trying to minimize needless words. Andrew On 5/6/2013 8:30 AM, Stewart Bryant wrote: > > Whilst this change was supported by one author and one of the chairs, > it is a technical change and thus outside the scope of change > permitted in an errata. > > The correct approach is for a member of the WG to produce a > short update draft and test that this has WG and IETF consensus. > > Please can the chairs drive this process. > > - Stewart > > > -------- Original Message -------- > Subject: [Errata Rejected] RFC6487 (3168) > Date: Mon, 6 May 2013 05:24:39 -0700 > From: RFC Errata System > To: , , , > > CC: , , > > > > The following errata report has been rejected for RFC6487, > "A Profile for X.509 PKIX Resource Certificates". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3168 > > -------------------------------------- > Status: Rejected > Type: Technical > > Reported by: David Mandelberg > Date Reported: 2012-03-26 > Rejected by: Stewart Bryant (IESG) > > Section: 4.8 > > Original Text > ------------- > or non-critical. A certificate-using system MUST reject the > > certificate if it encounters a critical extension it does not > > recognize; however, a non-critical extension MAY be ignored if it is > > not recognized [RFC5280]. > > Corrected Text > -------------- > or non-critical. A certificate-using system MUST reject the > > certificate if it encounters an extension not explicitly mentioned > > in this document. This is in contrast to RFC 5280 which allows > > non-critical extensions to be ignored. > > Notes > ----- > Other sections of the same document contradict the original section 4.8: > > > > Section 1: > > > > Any extensions not explicitly mentioned MUST be absent. The same > > applies to the CRLs used in the RPKI, that are also profiled in this > > document. > > > > Section 8: > > > > Certificate Extensions: > > This profile does not permit the use of any other critical or > > non-critical extensions. > --VERIFIER NOTES-- > This is a technical change to the RFC and needs to be addressed though the IETF consensus process and rather than via the errata process. > > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG > > . > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From internet-drafts@ietf.org Thu May 9 14:15:41 2013 Return-Path: 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 6AA1821F92BC; Thu, 9 May 2013 14:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl0p7E2D8Zch; Thu, 9 May 2013 14:15:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FD921F9227; Thu, 9 May 2013 14:15:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130509211534.13864.74859.idtracker@ietfa.amsl.com> Date: Thu, 09 May 2013 14:15:34 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-policy-qualifiers-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 21:15:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Policy Qualifiers in RPKI Certificates Author(s) : Andrew Lee Newton Geoff Huston Filename : draft-ietf-sidr-policy-qualifiers-00.txt Pages : 4 Date : 2013-05-09 Abstract: This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of RPKI resource certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-policy-qualifiers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-policy-qualifiers-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Fri May 10 17:38:20 2013 Return-Path: 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 961E921F905B; Fri, 10 May 2013 17:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.933 X-Spam-Level: X-Spam-Status: No, score=-101.933 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQO2bLdkFUG4; Fri, 10 May 2013 17:38:20 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2B91021F9057; Fri, 10 May 2013 17:38:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CB67E6210C; Fri, 10 May 2013 17:38:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130511003804.CB67E6210C@rfc-editor.org> Date: Fri, 10 May 2013 17:38:04 -0700 (PDT) Cc: sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] RFC 6945 on Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 00:38:20 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6945 Title: Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol Author: R. Bush, B. Wijnen, K. Patel, M. Baer Status: Standards Track Stream: IETF Date: May 2013 Mailbox: randy@psg.com, bertietf@bwijnen.net, keyupate@cisco.com, baerm@tislabs.com Pages: 25 Characters: 52515 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sidr-rpki-rtr-protocol-mib-07.txt URL: http://www.rfc-editor.org/rfc/rfc6945.txt This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From danny@tcb.net Sat May 11 19:34:06 2013 Return-Path: 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 72F1121F8956 for ; Sat, 11 May 2013 19:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2fkgM3kiBG4 for ; Sat, 11 May 2013 19:34:00 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id AA98621F871D for ; Sat, 11 May 2013 19:34:00 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 27611300015 for ; Sun, 12 May 2013 02:34:00 +0000 (UTC) Received: from new-host.home (pool-71-171-117-166.clppva.fios.verizon.net [71.171.117.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id A8569300010; Sat, 11 May 2013 20:33:58 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <5187C623.7070600@bbn.com> Date: Sat, 11 May 2013 22:33:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130506122439.12042B1E003@rfc-editor.org> <5187A268.5010703@cisco.com> <5187C623.7070600@bbn.com> To: Andrew Chi X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat May 11 20:34:00 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 518eff9842071669715695 X-DSPAM-Factors: 27, 2013+at, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Cc*sidr+wg, 0.01000, the+#+#+of, 0.01000, Cc*wg+#+sidr, 0.01000, 2013+#+11, 0.01000, based+on, 0.01000, Cc*sidr+#+list, 0.01000, Cc*wg+list, 0.01000, on+the, 0.01000, is+a, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, need+to, 0.01000, need+to, 0.01000, Subject*Re+sidr, 0.01000, From*Danny+McPherson, 0.01000, Cc*sidr+#+#+sidr, 0.01000, Cc*sidr+ietf.org, 0.01000, trying+to, 0.01000, they+#+#+#+the, 0.01000, we+should, 0.01000, Cc*wg+#+#+ietf.org, 0.01000, Cc*list+#+ietf.org, 0.01000, would+#+#+to, 0.01000 Cc: sidr wg list , sidr-chairs@tools.ietf.org Subject: Re: [sidr] [Errata Rejected] RFC6487 (3168) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 02:34:06 -0000 On May 6, 2013, at 11:02 AM, Andrew Chi wrote: > Is this really a technical change? The document has two places that = state X, and one place (citing 5280) that states Y. This erratum = replaces the Y statement with X. All implementers have already = implemented X since it's the stricter form of Y. >=20 > X =3D no other extensions are allowed > Y =3D non-critical extensions MAY be ignored >=20 > If this truly is a technical change, then we should have an update = doc. But I'm just trying to minimize needless words. Andrew,=20 Would an implementer need to know the difference when writing code based = on the current standards track RFC, or would they need to read the = erratum? -danny= From stbryant@cisco.com Mon May 13 07:48:41 2013 Return-Path: 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 5817621F871D for ; Mon, 13 May 2013 07:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvipo-lAARPf for ; Mon, 13 May 2013 07:48:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9571121F87FB for ; Mon, 13 May 2013 07:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1274; q=dns/txt; s=iport; t=1368456515; x=1369666115; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=X2X9eol0Ot3uOBiqYourJgSPF9dDI21VDP0aFnIGuh4=; b=gqTwz8XlxCeTSA2wm1rxmF3PUEOd34favl3iTQEJrrufad+xUuBpqCCt YVxpW4gQRTLEwoEmqEZQDgScs8Dx8UuHiY1QP6abowT1xZBaet8BTWI9+ XvqMm/0FU2CEwgf0LwOqlghms0r4HNmsKbf7vR1F/IEVHjkkXIl6sStCK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMD8kFGQ/khN/2dsb2JhbABagwe9cYJwgQMWdIIfAQEBBDhAARALGAkWDwkDAgECAUUGDQEHAQGICLtVjygHg1UDlyyRNYMQ X-IronPort-AV: E=Sophos;i="4.87,662,1363132800"; d="scan'208";a="154060023" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 13 May 2013 14:48:33 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4DEmVxW024017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 May 2013 14:48:31 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r4DEmU8b003295; Mon, 13 May 2013 15:48:30 +0100 (BST) Message-ID: <5190FD3E.5020100@cisco.com> Date: Mon, 13 May 2013 15:48:30 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Danny McPherson References: <20130506122439.12042B1E003@rfc-editor.org> <5187A268.5010703@cisco.com> <5187C623.7070600@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr-chairs@tools.ietf.org, sidr wg list Subject: Re: [sidr] [Errata Rejected] RFC6487 (3168) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 14:48:41 -0000 On 12/05/2013 03:33, Danny McPherson wrote: > On May 6, 2013, at 11:02 AM, Andrew Chi wrote: > >> Is this really a technical change? The document has two places that state X, and one place (citing 5280) that states Y. This erratum replaces the Y statement with X. All implementers have already implemented X since it's the stricter form of Y. >> >> X = no other extensions are allowed >> Y = non-critical extensions MAY be ignored >> >> If this truly is a technical change, then we should have an update doc. But I'm just trying to minimize needless words. > Andrew, > Would an implementer need to know the difference when writing code based on the current standards track RFC, or would they need to read the erratum? > > -danny > That is indeed the key question. Errata (only) document obvious mistakes in the original text, and are rarely read by implementers since few know of there existence. By contrast an update will be flagged to them in the metadata. In this case my assessment was that the matter was technical and outside the scope of an errata a view I confirmed with others on the IESG. The update does not need to be a big document, but it will (if published) have WG and IETF consensus for the change it makes. - Stewart From internet-drafts@ietf.org Wed May 22 08:45:00 2013 Return-Path: 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 96AE721F8756; Wed, 22 May 2013 08:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dkqPeNuLBYN; Wed, 22 May 2013 08:44:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83F21F854D; Wed, 22 May 2013 08:44:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130522154453.11626.51280.idtracker@ietfa.amsl.com> Date: Wed, 22 May 2013 08:44:53 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-multiple-publication-points-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:45:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Multiple Repository Publication Points support in the Re= source Public Key Infrastructure (RPKI) Author(s) : Roque Gagliano Terry Manderson Carlos Martinez Cagnazzo Filename : draft-ietf-sidr-multiple-publication-points-00.txt Pages : 13 Date : 2013-05-22 Abstract: The Resource Public Key Infrastructure (RPKI) depends on Relying Parties (RP) ability to access its Trust Anchors' certificate specified in the different "Trust Anchor Locator (TAL)" files and the Repository Objects located at the Certificate Authorities (CA) repositories hosted in its respective publication point. This document updates [RFC6490] by allowing multiple URI associated to a single public key in a TAL file and introduces the concept of multiple repository publication point operators for every CA in the RPKI. This document provides also recommendation for the RP behavior when analyzing signed objects that include multiple publications points. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-multiple-publication-points There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-multiple-publication-points-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wesley.george@twcable.com Wed May 29 06:59:58 2013 Return-Path: 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 466FF21F92BB for ; Wed, 29 May 2013 06:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKM6fL5VqkZs for ; Wed, 29 May 2013 06:59:54 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3D521F91B2 for ; Wed, 29 May 2013 06:59:53 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,764,1363147200"; d="scan'208,217";a="80369248" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 29 May 2013 09:58:22 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 29 May 2013 09:59:53 -0400 From: "George, Wes" To: "sidr wg list (sidr@ietf.org)" Date: Wed, 29 May 2013 09:59:52 -0400 Thread-Topic: review/adoption of draft-george-sidr-as-migration Thread-Index: Ac5cdMghzmOwFN1URiWI1fI09OtChQ== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73PRVPEXVS15cor_" MIME-Version: 1.0 Subject: [sidr] review/adoption of draft-george-sidr-as-migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:59:58 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73PRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All - I have not received any feedback regarding this draft since I posted = the revision incorporating the solution into it in February. Perhaps it's t= ime to call WG adoption so that it can move forward? http://tools.ietf.org/html/draft-george-sidr-as-migration-01 Thanks, Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73PRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All – I have not received any feedback regardi= ng this draft since I posted the revision incorporating the solution into i= t in February. Perhaps it’s time to call WG adoption so that it can m= ove forward?

 

http://tools.ietf.org/html/draft-george-sidr-as-migrat= ion-01

 

Thanks,

 

Wes George


This E-mail and any of its a= ttachments 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 a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73PRVPEXVS15cor_-- From randy@psg.com Thu May 30 06:38:14 2013 Return-Path: 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 AED4821F90C3 for ; Thu, 30 May 2013 06:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn29aAVaaUY6 for ; Thu, 30 May 2013 06:38:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9480D21F8FED for ; Thu, 30 May 2013 06:38:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Ui33S-000GFH-AR; Thu, 30 May 2013 13:38:10 +0000 Date: Thu, 30 May 2013 06:38:10 -0700 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73@PRVPEXVS15.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] review/adoption of draft-george-sidr-as-migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 13:38:14 -0000 > All - I have not received any feedback regarding this draft since I > posted the revision incorporating the solution into it in > February. Perhaps it's time to call WG adoption so that it can move > forward? i thought i had previously supported adoption. but, just in case, i do so now. randy From rogaglia@cisco.com Thu May 30 08:44:36 2013 Return-Path: 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 A789A21F9436 for ; Thu, 30 May 2013 08:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIXa7chSk+99 for ; Thu, 30 May 2013 08:44:31 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0352721F929F for ; Thu, 30 May 2013 08:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13025; q=dns/txt; s=iport; t=1369928666; x=1371138266; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ddhkMA4HbuyhiUx/807Cv3matvW83p02AGpjTIkcXlY=; b=Vm+g9dx0Vqsn3MJWK3co6zqBKq2h2i0Kgo3CM4KO8ChzDFmAhzyo2eRL GCrcSSG7Kwlp7uq7x7zPf2FskI0AXQEHbmK8XAxvFyML7q/1ExIy9NMZB 2z8Rash/edCHp1jcUngRVyFf5BYCEbBQZPvJN7Fq2xrjmjHtLm0e1ph8S E=; X-Files: smime.p7s : 4459 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FANlyp1GtJXHB/2dsb2JhbABZgkVEMLlUiDt+FnSCIwEBAQMBAQEBawQHBQsCAQgiJAIlCyUCBA4FCAYNh2wGDLtOjVoQgQEtBAeCdmEDkACBLIc7kBeDD4FxNg X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="p7s'?scan'208,217";a="216793097" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 30 May 2013 15:44:24 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4UFiO6b005424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 15:44:24 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.15]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 30 May 2013 10:44:23 -0500 From: "Roque Gagliano (rogaglia)" To: "George, Wes" Thread-Topic: [sidr] review/adoption of draft-george-sidr-as-migration Thread-Index: AQHOXUyOyXB9njV5wUySjq73F/58qA== Date: Thu, 30 May 2013 15:44:23 +0000 Message-ID: References: <2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [144.254.17.107] Content-Type: multipart/signed; boundary="Apple-Mail=_C79C2248-AA7D-4E9D-ABFE-316DB4701243"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] review/adoption of draft-george-sidr-as-migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:44:36 -0000 --Apple-Mail=_C79C2248-AA7D-4E9D-ABFE-316DB4701243 Content-Type: multipart/alternative; boundary="Apple-Mail=_7E2FDBAB-6796-49B8-B70C-E376254BB6DA" --Apple-Mail=_7E2FDBAB-6796-49B8-B70C-E376254BB6DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi George,=20 Thanks for writing this document, I think it is very good work! One comment before sending my support email. The document is intended as = "Informational" but do have requirement language. Is this what you = intended? Personally, I would rather all requirements to be moved to the = requirements document so we have one unique point to read. We could = publish then this document even as a "BCP" on a specific practice. Does = point 3.15 of the BGPSEC requirements document seams not to cover your = own requirements in Section 4. Do you think we can move the BGPSEC = specific requirements to the other document? Regards, Roque On May 29, 2013, at 3:59 PM, "George, Wes" = wrote: > All =96 I have not received any feedback regarding this draft since I = posted the revision incorporating the solution into it in February. = Perhaps it=92s time to call WG adoption so that it can move forward? > =20 > http://tools.ietf.org/html/draft-george-sidr-as-migration-01 > =20 > Thanks, > =20 > Wes George >=20 > 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. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_7E2FDBAB-6796-49B8-B70C-E376254BB6DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = George, 

Thanks for writing this document, I = think it is very good work!

One comment before = sending my support email. The document is intended as = "Informational" but do have requirement language. Is this what you = intended?

Personally, I would rather all requirements = to be moved to the requirements document so we have one unique point to = read. We could publish then this document even as a "BCP" on a specific = practice. Does point 3.15 of the BGPSEC requirements document seams = not to cover your own requirements in Section 4. Do you think we can = move the BGPSEC specific requirements to the other = document?

Regards,
Roque

=
On May 29, 2013, at 3:59 PM, "George, Wes" <wesley.george@twcable.com>= ; wrote:

All =96 I have not received any feedback = regarding this draft since I posted the revision incorporating the = solution into it in February. Perhaps it=92s time to call WG adoption so = that it can move forward?

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.
_______________________________________________
sid= r mailing list
sidr@ietf.org
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 693A821F9735 for ; Thu, 30 May 2013 09:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQt8n8tSvf5v for ; Thu, 30 May 2013 09:14:26 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id EB0C821F9739 for ; Thu, 30 May 2013 09:14:25 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,772,1363147200"; d="scan'208,217";a="83770460" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 30 May 2013 12:13:10 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 30 May 2013 12:14:19 -0400 From: "George, Wes" To: "Roque Gagliano (rogaglia)" Date: Thu, 30 May 2013 12:14:18 -0400 Thread-Topic: [sidr] review/adoption of draft-george-sidr-as-migration Thread-Index: AQHOXUyOyXB9njV5wUySjq73F/58qJkd5MhA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230433EF68FA@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73@PRVPEXVS15.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD59230433EF68FAPRVPEXVS15cor_" MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] review/adoption of draft-george-sidr-as-migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:14:30 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD59230433EF68FAPRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com] The document is intended as "Informational" but do have requirement languag= e. Is this what you intended? [WEG] originally, it was just covering the problem statement. This last rev= ision added the solution, and thus required some normative language to guid= e the implementation. That probably means the doc type needs to change, but= I was looking to the WG for feedback on how to proceed (whether this shoul= d remain a standalone document as companion to the BGPSec protocol draft, o= r be integrated into it, or what). Last meeting, it sounded like the prefer= ence was to have this remain a standalone document, but I didn't hear any r= eal guidance on whether it should formally update the BGPSec document or no= t. Personally, I would rather all requirements to be moved to the requirements= document so we have one unique point to read. We could publish then this d= ocument even as a "BCP" on a specific practice. Does point 3.15 of the BGPS= EC requirements document seams not to cover your own requirements in Sectio= n 4. Do you think we can move the BGPSEC specific requirements to the other= document? [WEG] I have no objection to moving section 4 to sidr-bgpsec-reqs to add to= 3.15. I documented them here because as noted above, originally this was a= problem statement, and so it seemed important to ensure that any solutions= could be evaluated against their success in meeting these requirements tha= t are specific to AS-migration and aliasing. Wes On May 29, 2013, at 3:59 PM, "George, Wes" > wrote: All - I have not received any feedback regarding this draft since I posted = the revision incorporating the solution into it in February. Perhaps it's t= ime to call WG adoption so that it can move forward? http://tools.ietf.org/html/draft-george-sidr-as-migration-01 Thanks, Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr * Persona Not Validated - 1368524010073 > * Issuer: Symantec Corporation - Unverified --_000_2671C6CDFBB59E47B64C10B3E0BD59230433EF68FAPRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Roque Gagl= iano (rogaglia) [mailto:rogaglia@cisco.com]

<= p class=3DMsoNormal> 

The document is intended as "Informational" but do have re= quirement language. Is this what you intended?

[WEG] originally, it was just cov= ering the problem statement. This last revision added the solution, and thu= s required some normative language to guide the implementation. That probab= ly means the doc type needs to change, but I was looking to the WG for feed= back on how to proceed (whether this should remain a standalone document as= companion to the BGPSec protocol draft, or be integrated into it, or what)= . Last meeting, it sounded like the preference was to have this remain a st= andalone document, but I didn’t hear any real guidance on whether it = should formally update the BGPSec document or not.

 

Personally, I would rather all requirements to be moved to the requirement= s document so we have one unique point to read. We could publish then this = document even as a "BCP" on a specific practice. Does point = 3.15 of the BGPSEC requirements document seams not to cover your own requir= ements in Section 4. Do you think we can move the BGPSEC specific requireme= nts to the other document?

= [WEG] I have no objection to moving section 4 to sidr= -bgpsec-reqs to add to 3.15. I documented them here because as noted above,= originally this was a problem statement, and so it seemed important to ens= ure that any solutions could be evaluated against their success in meeting = these requirements that are specific to AS-migration and aliasing.

 

Wes

=  



All – I have not received any feedback regarding this draft since I = posted the revision incorporating the solution into it in February. Perhaps= it’s time to call WG adoption so that it can move forward?

 

http://tools.ietf.org/html/draft-= george-sidr-as-migration-01

 

Thanks,=

 

Wes George

<= o:p> 

This E-mail and any of its attachments may contain Time War= ner Cable proprietary information, which is privileged, confidential, or su= bject 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 a= nd may be unlawful. If you have received this E-mail in error, please notif= y the sender immediately and permanently delete the original and any copy o= f this E-mail and any printout.
______________________________________= _________
sidr mailing list
sidr@ietf.org
https://www.ietf.= org/mailman/listinfo/sidr

 

* Persona Not Validated - 1368524010073 <rogaglia@cisco.com>
* Issuer: Symantec Corporation - = Unverified

 

= --_000_2671C6CDFBB59E47B64C10B3E0BD59230433EF68FAPRVPEXVS15cor_-- From randy@psg.com Thu May 30 10:46:47 2013 Return-Path: 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 CDC1021F8EBD for ; Thu, 30 May 2013 10:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARTlj6+T-QIl for ; Thu, 30 May 2013 10:46:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0F521F8EBB for ; Thu, 30 May 2013 10:46:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Ui6vz-000H7f-RQ; Thu, 30 May 2013 17:46:43 +0000 Date: Thu, 30 May 2013 10:46:43 -0700 Message-ID: From: Randy Bush To: "Roque Gagliano (rogaglia)" In-Reply-To: References: <2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73@PRVPEXVS15.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] review/adoption of draft-george-sidr-as-migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:46:47 -0000 > The document is intended as "Informational" but do have requirement > language. normative language in an info doc is perfectly normal and acceptable. this doc does not create protcol, protocol data elements, ... it says HOW to do some tricks with already defined protocol and pdus. so info seems not unreasonable to me. btw, this is a *really* cute bit of work. randy From rogaglia@cisco.com Fri May 31 02:26:52 2013 Return-Path: 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 5237C21F83EF for ; Fri, 31 May 2013 02:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ijBGrc4EiLz for ; Fri, 31 May 2013 02:26:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A589021F973A for ; Fri, 31 May 2013 02:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7054; q=dns/txt; s=iport; t=1369992406; x=1371202006; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DQbiH1nqJAfmQhwzAjepB3FHAzl7GjA98e0OZ3u/Sjc=; b=OfRiB6izVrTvFg0oaKGzgl3JQYNfnFm2A4duxlwiQkKuNO8KMJ0vo+XL 1e9DIqqkU/KzolUrVBNb/Ub8Fp4D1aw0zAGfImxYAH2cHSJxqjBLxEb6h ocf4mOhjP4BP8HxsDdgleXw99DW3HttTzgTjrTadkks+Us53OoKR9XmIr c=; X-Files: smime.p7s : 4459 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQFAF5rqFGtJXG//2dsb2JhbABagwmDJbt0gQEWdIIjAQEBAwF5BQsCAQgiJAIwJQIEDgUIBod5BrtPjmsxB4J2YQOQAIEsl1KDD4In X-IronPort-AV: E=Sophos;i="4.87,777,1363132800"; d="p7s'?scan'208";a="217109592" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 31 May 2013 09:26:45 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4V9Qjvv025144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 May 2013 09:26:45 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.15]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 31 May 2013 04:26:45 -0500 From: "Roque Gagliano (rogaglia)" To: Randy Bush Thread-Topic: [sidr] review/adoption of draft-george-sidr-as-migration Thread-Index: AQHOXUyOyXB9njV5wUySjq73F/58qA== Date: Fri, 31 May 2013 09:26:44 +0000 Message-ID: References: <2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73@PRVPEXVS15.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.72] Content-Type: multipart/signed; boundary="Apple-Mail=_FD05A56E-A8F6-45A9-9967-E550B5F12360"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] review/adoption of draft-george-sidr-as-migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 09:26:52 -0000 --Apple-Mail=_FD05A56E-A8F6-45A9-9967-E550B5F12360 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Randy, On May 30, 2013, at 7:46 PM, Randy Bush wrote: >> The document is intended as "Informational" but do have requirement >> language. > > normative language in an info doc is perfectly normal and acceptable. > > this doc does not create protcol, protocol data elements, ... it says > HOW to do some tricks with already defined protocol and pdus. so info > seems not unreasonable to me. That is why I was proposing moving it to BCP. > > btw, this is a *really* cute bit of work. +1 Roque > randy --Apple-Mail=_FD05A56E-A8F6-45A9-9967-E550B5F12360 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/ xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28 ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB 8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4 e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9 5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4 OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi dE0HbYQwggb/MIIF56ADAgECAhAYf+/XztcT+E2kExj0ut5oMA0GCSqGSIb3DQEBBQUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzA1 MTQwMDAwMDBaFw0xNDA1MTUyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQgLSAxMzY4NTI0MDEwMDczMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20xDzAN BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/aDENz/1kQVeEyPK5cHw3n9c4ErU13WONPXjL7 fHYj0Yr/DSGbdyiWZ001bkIMPxvJbxv4r5EaTq72gHxhTF/frLoM5+sEKAErBPuOqpAAYlxo4uyK U1pQzPy+3rtlVRStNUAJZHVN4kYtHRghGoBCkqh2JoSBMCgc41Mr1UvS3dI4kp5lKEqutKjoDtdc /O4Kee/CLzEy0D8QNOF7OSjrPmed1jsAxxqsv9EHMJvG9z/CIXF2Q/kYf24ozeujCPZVaOTjWVsd BsZSNUaD9LyeGQBtGCXq7e0rUEFPZfsdxUoBoVeTYRYIcloFuiG4QQsvjr6rlFZDbXEhOWOJnRsC AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU+K3xGZv+qs21HN5cJGWwMOyfwHcwHQYDVR0R BBYwFIEScm9nYWdsaWFAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90 JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1 dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1 dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA A4IBAQA9KvHI6pN0/W4MJl3cATuTU0cdkjZBvfztljunVmn72rij+hJKzSg8lGawguiccFWVqqEl sMIAinuB1zqFe1ILchliltXEj5vPI+HyGxn5akhQuzk7/hmAfs00CC1hbC1HB8r+b7R2s/bkJ7YY fpE0lMd7exB62MccwKh5yFCgxIvxG/irFLjNicpW/C6ixzmuPoKQO9Rs5H9oBnYVxtGpORPt6H5+ DINZOpsbDcnNgi3mIpSK0lapSzVUueOWBJwS5sfjOLe5pBbpvarrZp0zs0gADupX5u1bH0DpSwj1 zN5wP/p5f2h0L2i4rpaU05LLgBzh0JTy+zidLpU8NgAhMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAYf+/XztcT+E2k Exj0ut5oMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDUzMTA5MjY0NFowIwYJKoZIhvcNAQkEMRYEFI6J/v5hnPD1/gV+4QakpECrfaZf MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAYf+/XztcT+E2kExj0ut5oMIHOBgsqhkiG9w0BCRACCzGBvqCB uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC EBh/79fO1xP4TaQTGPS63mgwDQYJKoZIhvcNAQEBBQAEggEAq2lxqxAyBUlPlH34Le6jUg6pbIN8 vwx8mRIDjMExm9b4dRTOPWtYvEJc3JHvrNxT8/6egffjKeIOyL3U6LA98CEUqZkhBMtx72WHeRL1 zb3WPgXwNNU7aFf2M+vrxpFZQwboCcD8Ny6Lk7QZ5+FpeSF8T6WvwQQml/e4e/fdfvEyLH+afh5/ c2In94L+aDqO8WctBJCxp6OWeYL0n51nYx1X9w7ffBAHK1DTLNM2AGitRmc3Wj1lafh44DBEJYe+ 5K3C8WowLqUHIXwD5D/hc14y22fW24a8E3yBxqjAQmUvKla4/u4Dmw9GVFij/iMAtgQwtVSK7RW0 kY1qscfmEAAAAAAAAA== --Apple-Mail=_FD05A56E-A8F6-45A9-9967-E550B5F12360-- From rogaglia@cisco.com Fri May 31 02:30:09 2013 Return-Path: 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 40B1A21F973A for ; Fri, 31 May 2013 02:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECRJuhz7hN8c for ; Fri, 31 May 2013 02:30:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7D221F96FB for ; Fri, 31 May 2013 02:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20870; q=dns/txt; s=iport; t=1369992604; x=1371202204; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/8qsi+OMnES5jdQ/Wnoq04DmVR+UrxnfJtx91Q9KIoY=; b=mr3/gMBMsRrN5YRG2TOQso35k7ndATSiPTYxBBzQxnkLkbhG7ku/jreX Q5P8Jl421uRyTUSnCdjO7NOqr06PeWYqxmMwl1HUZUJGfS6UVdfe4qDhe PcffqY8CWGPLeIrKaULV8658mEFBRaBu9kFyv90WcF8v3UedM8P+m4iBV w=; X-Files: smime.p7s : 4459 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAMdrqFGtJXHA/2dsb2JhbABagkVEMLYuiDuBARZ0giMBAQEDAQEBAWsEBwULAgEIFQMKHQcCJQsUEQIEDgUIBg2HbAYMu0SNaoEBFhcEBgEJgm1hA5AAgSyHO5AXgw+BagcXBhk X-IronPort-AV: E=Sophos;i="4.87,777,1363132800"; d="p7s'?scan'208,217";a="217110593" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 31 May 2013 09:30:03 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4V9U3Mh024007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 May 2013 09:30:03 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.15]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 31 May 2013 04:30:02 -0500 From: "Roque Gagliano (rogaglia)" To: "George, Wes" Thread-Topic: [sidr] review/adoption of draft-george-sidr-as-migration Thread-Index: AQHOXUyOyXB9njV5wUySjq73F/58qA== Date: Fri, 31 May 2013 09:30:02 +0000 Message-ID: References: <2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59230433EF68FA@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230433EF68FA@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.72] Content-Type: multipart/signed; boundary="Apple-Mail=_C399681A-CF04-46AD-A06F-7B42A3F47182"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] review/adoption of draft-george-sidr-as-migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 09:30:09 -0000 --Apple-Mail=_C399681A-CF04-46AD-A06F-7B42A3F47182 Content-Type: multipart/alternative; boundary="Apple-Mail=_86DC3D6D-D552-4785-A03B-7C1DA19EB2EA" --Apple-Mail=_86DC3D6D-D552-4785-A03B-7C1DA19EB2EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Wes, If we follow that strategy (make sure requirements are listed in BGPSEC = req. document and change status to BCP for this document), I support = adoption. r. On May 30, 2013, at 6:14 PM, "George, Wes" = wrote: > From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com]=20 >=20 > =20 > The document is intended as "Informational" but do have requirement = language. Is this what you intended? > [WEG] originally, it was just covering the problem statement. This = last revision added the solution, and thus required some normative = language to guide the implementation. That probably means the doc type = needs to change, but I was looking to the WG for feedback on how to = proceed (whether this should remain a standalone document as companion = to the BGPSec protocol draft, or be integrated into it, or what). Last = meeting, it sounded like the preference was to have this remain a = standalone document, but I didn=92t hear any real guidance on whether it = should formally update the BGPSec document or not. > =20 > Personally, I would rather all requirements to be moved to the = requirements document so we have one unique point to read. We could = publish then this document even as a "BCP" on a specific practice. Does = point 3.15 of the BGPSEC requirements document seams not to cover your = own requirements in Section 4. Do you think we can move the BGPSEC = specific requirements to the other document? > [WEG] I have no objection to moving section 4 to sidr-bgpsec-reqs to = add to 3.15. I documented them here because as noted above, originally = this was a problem statement, and so it seemed important to ensure that = any solutions could be evaluated against their success in meeting these = requirements that are specific to AS-migration and aliasing. > =20 > Wes > =20 > On May 29, 2013, at 3:59 PM, "George, Wes" = wrote: >=20 >=20 > All =96 I have not received any feedback regarding this draft since I = posted the revision incorporating the solution into it in February. = Perhaps it=92s time to call WG adoption so that it can move forward? > =20 > http://tools.ietf.org/html/draft-george-sidr-as-migration-01 > =20 > Thanks, > =20 > Wes George > =20 > 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. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > =20 > * Persona Not Validated - 1368524010073 > * Issuer: Symantec Corporation - Unverified > =20 --Apple-Mail=_86DC3D6D-D552-4785-A03B-7C1DA19EB2EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Wes,

If = we follow that strategy (make sure requirements are listed in BGPSEC = req. document and change status to BCP for this document), I support = adoption.

r.

On May 30, = 2013, at 6:14 PM, "George, Wes" <wesley.george@twcable.com>= ; wrote:

From: Roque Gagliano (rogaglia) = [mailto:rogaglia@cisco.com] 

 
The document is intended = as "Informational" but do have requirement language. Is this what you = intended?
[WEG] originally, it was just covering the problem = statement. This last revision added the solution, and thus required some = normative language to guide the implementation. That probably means the = doc type needs to change, but I was looking to the WG for feedback on = how to proceed (whether this should remain a standalone document as = companion to the BGPSec protocol draft, or be integrated into it, or = what). Last meeting, it sounded like the preference was to have this = remain a standalone document, but I didn=92t hear any real guidance on = whether it should formally update the BGPSec document or = not.
[WEG] I have no objection to moving section 4 to = sidr-bgpsec-reqs to add to 3.15. I documented them here because as noted = above, originally this was a problem statement, and so it seemed = important to ensure that any solutions could be evaluated against their = success in meeting these requirements that are specific to AS-migration = and aliasing.
 
Wes
On = May 29, 2013, at 3:59 PM, "George, Wes" <wesley.george@twcable.com> = wrote:
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.
* Persona Not Validated - 1368524010073 <rogaglia@cisco.com>
* Issuer: = Symantec Corporation - Unverified
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 2D06B21F967F for ; Fri, 31 May 2013 04:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Svo7tBrFH4w for ; Fri, 31 May 2013 04:02:39 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id CEFFE21F949D for ; Fri, 31 May 2013 04:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1369998157; d=isode.com; s=selector; i=@isode.com; bh=CZa6DN5rsDPFHA7Dfxz4TahhaAyLS3GKkbg+UBG22xw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=BB/eZz/qClLSY9DQ8XwPDXN08K4aTaX2sVYohjzEDMLF1HvBcE15fCYCMRDcFSMdeTbfRI SS6HqksD4R7PYJvPC6acnwf8aRy129mkpOASjQ/xpmDCvfj2rTUK2RKd9XawH0KolwJLVS +mpy92fJx8s69edI0BaPPu6UwAnxTo4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 31 May 2013 12:02:37 +0100 Message-ID: <51A88357.1010109@isode.com> Date: Fri, 31 May 2013 12:02:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: sidr wg MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Subject: [sidr] Results of acceptance call on draft-ymbk-rpki-grandparenting-02 in December 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 11:02:44 -0000 Hi, I am sorry I procrastinated for so long to close the acceptance call. Below are the questions I've asked on the mailing list: > 1) Is the problem described/solved by > draft-ymbk-rpki-grandparenting-02 actually a problem that the WG needs > to address? (Answer: yes or no. Additional information is welcomed, > but I don't want people to repeat the whole discussion.) > > 2) If you answered "yes" to the question #1, please also answer the > following question: > > Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to > become a WG document? Please choose one of the following: > > > a) Ready for Adoption (whether or not you have some specific issues > with it. Also, this answer is unrelated to whether this should be a > separate draft or a part of an existing draft). > > b) Needs more work BEFORE Adoption > > c) Should not be adopted. In particular this mean that you don't > believe any amount of work on the proposed draft will address your > issues. So any solution to this problem should be a new draft written > from scratch. > > d) Abstain/don't care > > > 3) If you answered "a" or "b" above, please also answer the following > question: > > Does this need to be in a standalone draft, or can it be incorporated > into another existing WG draft? When answering this question please > only base your answer on technical reasons, in particular please leave > the decision on who is going to edit the document (if it is > standalone) to WG chairs. Summary of results: Responded: 7 people Q1: Yes - 5 (or 5.5 :-)) Q2: Adopt: 1, Need more work: 2 (1.5), Don't adopt: 4 Q3: Standalone: 2, Fold into existing: 1 (others didn't respond or don't=20 care) So, there is a problem to be solved, but people don't want to use the=20 existing draft as the starting point. There is no WG agreement to accept=20 draft-ymbk-rpki-grandparenting as a WG document. (Randy can continue to=20 work on draft-ymbk-rpki-grandparenting as he sees fit.) Alexey, On behalf of SIDR WG Chairs. ------------- Raw data: Brian Dickson: Q1: Yes, there is a problem alluded to that might need to be solved. Q2: C - no, this draft is not the place to solve the problem Warren Kumari: Q1: Yes, it is a problem that I believe the WG should address=85. I don't=20 think it is the most important issue on our plate but I do think it is=20 worth addressing. Q2: a. I believe that 1: starting from somewhere is useful (and this is=20 somewhere) and 2: once the WG owns the doc it can make whatever changes=20 it wants (well, is able to reach consensus on :-P) Q3: What? There is no "Abstain/don't care" option for 3? ;-) Byron Ellacott: Q1: No (with a 'but' under q.2). IOW, there IS a problem, but it's not one for a technical working group=20 to resolve, it's one for bilateral business relationships to resolve. Q2: Don't adopt (c). Terry Manderson: Q1: Yes. Q2: Don't adopt (c). Stephen Kent: Q1: Yes Q2: Needs more work before adopting Q3: I don't recall another, extant WG draft with which this might be=20 combined. Wes George: Q1: Yes, but I tend to agree that it's not a technical problem. Q2: b. (need more work) The text itself is ok, but we need to resolve #3=20 before adoption. Q3: It needs to be incorporated into an existing draft. This text is covering a very specific gotcha with some helpful=20 recommendations and no actual requirements. It currently reads like an=20 orphaned section of another draft, probably the operational=20 considerations (origin-ops) draft. Andy Newton: Q1: At present, I think not. While this is interesting, I don't think=20 the IETF is the venue for this document as the subject is not technical. Q3: Should it be adopted, I think it should be standalone. From randy@psg.com Fri May 31 06:13:13 2013 Return-Path: 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 2001721F9455 for ; Fri, 31 May 2013 06:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeJBa7gxTDpe for ; Fri, 31 May 2013 06:13:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BF22C21F86F4 for ; Fri, 31 May 2013 06:13:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UiP8n-000LDn-Un; Fri, 31 May 2013 13:13:10 +0000 Date: Fri, 31 May 2013 06:13:09 -0700 Message-ID: From: Randy Bush To: "Roque Gagliano (rogaglia)" In-Reply-To: References: <2671C6CDFBB59E47B64C10B3E0BD59230433EF5B73@PRVPEXVS15.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] review/adoption of draft-george-sidr-as-migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 13:13:13 -0000 >>> The document is intended as "Informational" but do have requirement >>> language. >> >> normative language in an info doc is perfectly normal and acceptable. >> >> this doc does not create protcol, protocol data elements, ... it says >> HOW to do some tricks with already defined protocol and pdus. so info >> seems not unreasonable to me. > > That is why I was proposing moving it to BCP. PBP, proposed best practice? randy From Sandra.Murphy@sparta.com Fri May 31 09:40:12 2013 Return-Path: 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 2618721F8956 for ; Fri, 31 May 2013 09:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3znUn6ILAWCv for ; Fri, 31 May 2013 09:40:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id EFCD221F86AE for ; Fri, 31 May 2013 09:40:06 -0700 (PDT) Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r4VGMEim016522 for ; Fri, 31 May 2013 11:22:14 -0500 Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r4VGME9T022447 for ; Fri, 31 May 2013 11:22:14 -0500 Received: from CVA-MB001.centreville.ads.sparta.com ([fe80::58b4:c7c2:f9d:dff9]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::8ca8:7aea:3db9:1972%11]) with mapi id 14.02.0342.003; Fri, 31 May 2013 12:22:50 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: meeting request for IETF87 Thread-Index: Ac5eGqoW/Zqx+erETnK7I35VTGOn4g== Date: Fri, 31 May 2013 16:22:49 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6748D6195@CVA-MB001.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] meeting request for IETF87 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 16:40:12 -0000 Meeting time for IETF87 has been requested.=0A= =0A= This time the request was for two slots - 1.5 hr and 1 hr.=0A= =0A= The total time is what we usually request, but breaking into two sessions m= ight make it possible to consult together after one session and before the = second.=0A= =0A= If anyone thinks anything should be changed, please do speak up now. (Dead= line is Monday 24:00 UTC.)=0A= =0A= --Sandy=0A= =0A= =0A=