From sidr-bounces@ietf.org Thu Mar 01 07:26:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMkM6-0003Qn-FK; Thu, 01 Mar 2007 07:25:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMkM5-0003Qh-KK for sidr@ietf.org; Thu, 01 Mar 2007 07:25:53 -0500 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMkM3-0005CC-Sj for sidr@ietf.org; Thu, 01 Mar 2007 07:25:53 -0500 Received: from [169.223.71.11] (11.71.dhcp.conference.apricot.net [169.223.71.11]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id B9EC7D5F31 for ; Thu, 1 Mar 2007 22:25:39 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v624) Content-Transfer-Encoding: 7bit Message-Id: <63ce4394292b9be704f7408c66733df9@apnic.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: sidr@ietf.org From: Terry Manderson Date: Thu, 1 Mar 2007 22:25:36 +1000 X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Sidr] draft-ietf-sidr-res-certs-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org May I respectfully suggest the following updates? I see the meaning as quite clear, but if you would like me to explain - please let me know. in 3.9.5 The distributionPoint MUST contain general names, and MUST NOT contain a nameRelativeToCRLIssuer. The type of the general name MUST be of type URI. In this profile, the scope of the CRL is specified to be all certificates issued by this issuer. The sequence of distributionPoint values MUST contain only a single DistributionPointName set. The DistributionPointName set MAY contain more than one URI value. An RSYNC URI MUST be present in the DistributionPointName set, and reference the most recent instance of this issuer's certificate revocation list. Other access form URIs MAY be used in addition to the RSYNC URI. If there is more than one URI in the sequence, then the order of the URIs in the sequence SHALL be interpreted as the publisher's relative preference for supporting retrieval mechanism services, with the first URI in the sequence being the most preferred service. in 3.9.6 This profile uses a URI form of object identification. The preferred URI access mechanisms is "rsync", and an RSYNC URI MUST be specified with an accessMethod value of id-ad-caIssuers. The URI MUST reference the point of publication of the certificate where this issuer is the subject (the issuer's immediate superior certificate). Other access method URIs referencing the same object MAY also be included in the value sequence of this extension. If there is more than one URI in the sequence, then the order of the URIs in the sequence SHALL be interpreted as the publisher's relative preference for supporting retrieval mechanism services, with the first URI in the sequence being the most preferred service. in 3.9.7 This profile uses a URI form of location identification. The preferred URI access mechanism is "rsync", and an RSYNC URI MUST be specified, with an access method value of id-ad-caRepository when the subject of the certificate is a CA. The RSYNC URI must reference an object collection rather than an individual object and MUST use a trailing '/' in the URI. Other access method URIs that reference the same location MAY also be included in the value sequence of this extension.If there is more than one URI in the sequence, then the order of the URIs in the sequence SHALL be interpreted as the publisher's relative preference for supporting retrieval mechanism services, with the first URI in the sequence being the most preferred service. Cheers Terry -- Terry Manderson email: terry@apnic.net Network Operations Manager, APNIC sip: info@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Mar 01 16:43:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsGo-0004pt-2a; Thu, 01 Mar 2007 15:52:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsEV-00017B-DC; Thu, 01 Mar 2007 15:50:35 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMsET-0002cm-3e; Thu, 01 Mar 2007 15:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id BCCCB2AD4C; Thu, 1 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMsDy-0002ci-Fq; Thu, 01 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-cps-irs-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Template for an Internet Registry's Certification Practice Statement (CPS) for the Internet IP Address and AS Number (PKI) Author(s) : S. Kent, et al. Filename : draft-ietf-sidr-cps-irs-01.txt Pages : 47 Date : 2007-3-1 This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Internet Registry (e.g., NIR or RIR) that is part of the Internet IP Address and Autonomous System (AS) Number Public Key Infrastructure (PKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-cps-irs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-cps-irs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-1104225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-cps-irs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-cps-irs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-1104225.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Wed Mar 07 05:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtVv-000161-PI; Wed, 07 Mar 2007 05:36:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtVu-00015q-EX for sidr@ietf.org; Wed, 07 Mar 2007 05:36:54 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOtVs-0001d4-7O for sidr@ietf.org; Wed, 07 Mar 2007 05:36:54 -0500 Received: from [192.168.1.3] (VDSL-151-118-37-135.DNVR.QWEST.NET [151.118.37.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id D9D8D64362; Wed, 7 Mar 2007 03:36:36 -0700 (MST) In-Reply-To: <20070222231357.6BB533F439@pecan.tislabs.com> References: <20070222231357.6BB533F439@pecan.tislabs.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Sidr] agenda requests Date: Wed, 7 Mar 2007 03:36:41 -0700 To: Sandy Murphy X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On Feb 22, 2007, at 4:13 PM, Sandy Murphy wrote: > It's about time to ask for topics for the agenda. > > The deadline for the wg chairs to submit an agenda is March 7 for > drafts > and March 12 for revisions. So if you wish to speak, it would be > great > to send a request in to both wg chairs (for fault tolerance) soon. Are there plans for a SIDR WG meeting in Prague? -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 07 13:09:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP0ZG-00019V-0O; Wed, 07 Mar 2007 13:08:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP0ZE-00017U-4D for sidr@ietf.org; Wed, 07 Mar 2007 13:08:48 -0500 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP0ZB-00078W-2I for sidr@ietf.org; Wed, 07 Mar 2007 13:08:47 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l27I4vW9025203; Wed, 7 Mar 2007 13:04:59 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAT8aqiX; Wed, 7 Mar 07 13:03:47 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id EA9383F47B; Wed, 7 Mar 2007 12:04:00 -0500 (EST) To: danny@tcb.net, sandy@tislabs.com Subject: Re: [Sidr] agenda requests In-Reply-To: Message-Id: <20070307170400.EA9383F47B@pecan.tislabs.com> Date: Wed, 7 Mar 2007 12:04:00 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org >Are there plans for a SIDR WG meeting in Prague? If you mean, do we plan to meet, there is a meeting slot for sidr that is Monday at 1300 (in the draft agenda, so subject to change). If you mean, do we have a plan for what we discuss in the meeting in Prague, this is a request for agenda topics. There are new versions of three drafts and three brand new drafts, so I think we have fodder for discussion. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 07 18:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5cP-0001D3-5X; Wed, 07 Mar 2007 18:32:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP54t-0006VI-Dz for sidr@ietf.org; Wed, 07 Mar 2007 17:57:47 -0500 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP3RU-0004YO-6U for sidr@ietf.org; Wed, 07 Mar 2007 16:13:23 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l27L9NUU005282 for ; Wed, 7 Mar 2007 16:09:23 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3Ma4hk; Wed, 7 Mar 07 16:07:16 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id DB3153F484; Wed, 7 Mar 2007 14:08:51 -0500 (EST) To: sidr@ietf.org Message-Id: <20070307190851.DB3153F484@pecan.tislabs.com> Date: Wed, 7 Mar 2007 14:08:51 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sandy@tislabs.com Subject: [Sidr] agenda for IETF 68 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org I have just submitted the following agenda. If anyone wants to make any changes or additions, send mail to me and to Geoff. --Sandy Secure Inter-Domain Routing WG (sidr) IETF 68, Prague, CZ MONDAY, March 19, 2007 1300-1500 Afternoon Session I ==================================================== CHAIR(s): Geoff Huston Sandra Murphy AGENDA: 1) Administriva 5 minutes - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html - Scribe? - Blue Sheets - Agenda Bashing 2) New Drafts 60 minutes (a) Architecture 20 minutes An Infrastructure to Support Secure Internet Routing draft-ietf-sidr-arch-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-00.txt Presenter: Richard Barnes (b) Route Originations 20 minutes A Profile for Route Origin Authorizations (ROA) draft-ietf-sidr-roa-format-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-00.txt Presenter: Stephen Kent (c) CPS for ISPs 20 minutes Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Internet IP address and AS Number PKI draft-ietf-sidr-cps-isp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-isp-00.txt Presenter: Derrick Kong 3) Updated Drafts 45 minutes (a) Certificates 20 minutes A Profile for X.509 PKIX Resource Certificates draft-ietf-sidr-res-certs-05.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-05.txt Presenter: Geoff Huston (b) Certificate Policy 15 minutes Certificate Policy (CP) for the Internet IP Address and AS Number (PKI) draft-ietf-sidr-cp-01.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-01.txt Presenter: Karen Seo (c) CPS for Registries 10 minutes Template for an Internet Registry's Certification Practice Statement (CPS) for the Internet IP Address and AS Number (PKI) draft-ietf-sidr-cps-irs-01.txt http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-01.txt Presenter: Derrick Kong 4) General Discussion 10 minutes _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 21 04:36:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwIe-0007l3-AL; Wed, 21 Mar 2007 04:36:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwIc-0007kc-TG for sidr@ietf.org; Wed, 21 Mar 2007 04:36:02 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTwIb-0003wh-Kh for sidr@ietf.org; Wed, 21 Mar 2007 04:36:02 -0400 Received: from [IPv6:2001:df8::16:20a:95ff:fef5:246e] ([IPv6:2001:df8:0:16:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2L8ZVKi040021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 21 Mar 2007 09:35:32 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <09C87E64-BDC9-43DE-8564-18F7577B35AC@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sidr@ietf.org From: Iljitsch van Beijnum Date: Wed, 21 Mar 2007 09:35:56 +0100 X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Sidr] draft-ietf-sidr-arch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org I was looking through draft-ietf-sidr-arch-00.txt and I noticed this: 5.2.2. Multi-homing If a multi-homed subscriber wants multiple ASes to originate routes for prefixes that it holds, then it must explicitly authorize each of them to do so by issuing a ROA for each AS in question. Does this address the solution where multihomer M uses ISPs A and B, and M's prefix is injected into BGP by both A and B and NOT by M? I.e., "inconsistent origin AS", which is frowned upon. If not, the text is unclear. If so, why is there no discussion of the normal situation where the multihomed AS advertises its prefix itself? Same thing for portable allocations without multihoming, although there the situation where the ISP originates the prefix is more common. BTW, it would be helpful if the availability of new drafts would be announced on the list with the draft name in the subject. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 21 05:01:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwgc-0007VY-Uc; Wed, 21 Mar 2007 05:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTwgb-0007VR-T2 for sidr@ietf.org; Wed, 21 Mar 2007 05:00:49 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTwga-0003H8-Mc for sidr@ietf.org; Wed, 21 Mar 2007 05:00:49 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.17.112]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HTwgZ-0005Mf-6O; Wed, 21 Mar 2007 05:00:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <09C87E64-BDC9-43DE-8564-18F7577B35AC@muada.com> References: <09C87E64-BDC9-43DE-8564-18F7577B35AC@muada.com> Date: Wed, 21 Mar 2007 05:00:21 -0400 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [Sidr] draft-ietf-sidr-arch-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 9:35 AM +0100 3/21/07, Iljitsch van Beijnum wrote: >I was looking through draft-ietf-sidr-arch-00.txt and I noticed this: > >5.2.2. Multi-homing > > If a multi-homed subscriber wants multiple ASes to originate routes > for prefixes that it holds, then it must explicitly authorize each of > them to do so by issuing a ROA for each AS in question. > >Does this address the solution where multihomer M uses ISPs A and B, >and M's prefix is injected into BGP by both A and B and NOT by M? >I.e., "inconsistent origin AS", which is frowned upon. This text is saying that generation of multiple ROAs by M will allow A and B to both advertise M's prefix in a verifiable fashion, which should make this case less "frowned upon" :-). >If not, the text is unclear. If so, why is there no discussion of >the normal situation where the multihomed AS advertises its prefix >itself? If M originates the routes, i.e., M's AS number is the origin AS in advertisements, then only one ROA is needed, and it was not classified as "multi-homed" in the document. We will add text to make this distinction clear. >Same thing for portable allocations without multihoming, although >there the situation where the ISP originates the prefix is more >common. OK. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 21 05:45:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxNl-0000BB-P2; Wed, 21 Mar 2007 05:45:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxNl-0000B6-AB for sidr@ietf.org; Wed, 21 Mar 2007 05:45:25 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTxNL-0007cH-KG for sidr@ietf.org; Wed, 21 Mar 2007 05:45:25 -0400 Received: from [130.129.19.200] (dhcp-13c8.ietf68.org[130.129.19.200]) by comcast.net (rwcrmhc14) with ESMTP id <20070321094457m1400hr8kve>; Wed, 21 Mar 2007 09:44:58 +0000 Message-ID: <4600FE9C.7010408@merit.edu> Date: Wed, 21 Mar 2007 05:45:00 -0400 From: Larry Blunk User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: sidr@ietf.org References: <20070307190851.DB3153F484@pecan.tislabs.com> In-Reply-To: <20070307190851.DB3153F484@pecan.tislabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sidr] Comments on ROA presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org The ROA presentation mentioned the option of using "RPSL" for expressing prefix ranges. I just wanted to make it clear that my suggestion was to borrow the "RPSL Range Operator" expression syntax for prefix ranges. This is a very small subset of the RPSL standard. There were comments in the meeting that it would not be possible to employ large scale BGP filtering (i.e. on non-customer peering sessions). There has been some research to suggest that such filtering may in fact be feasible on modern day routers. See -- http://www.nanog.org/mtg-0510/deleskie.html -Larry _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 21 06:19:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxuT-0005VH-FG; Wed, 21 Mar 2007 06:19:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxuR-0005V5-8u for sidr@ietf.org; Wed, 21 Mar 2007 06:19:11 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxuI-0001Yj-3z for sidr@ietf.org; Wed, 21 Mar 2007 06:19:11 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.17.112]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HTxuF-0005ml-43; Wed, 21 Mar 2007 06:18:59 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4600FE9C.7010408@merit.edu> References: <20070307190851.DB3153F484@pecan.tislabs.com> <4600FE9C.7010408@merit.edu> Date: Wed, 21 Mar 2007 06:18:49 -0400 To: Larry Blunk From: Stephen Kent Subject: Re: [Sidr] Comments on ROA presentation Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 5:45 AM -0400 3/21/07, Larry Blunk wrote: > The ROA presentation mentioned the option of using >"RPSL" for expressing prefix ranges. I just wanted >to make it clear that my suggestion was to borrow the >"RPSL Range Operator" expression syntax for prefix ranges. >This is a very small subset of the RPSL standard. Agreed. I didn't mean to suggest otherwise. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 21 09:54:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1Fd-0008Vy-A0; Wed, 21 Mar 2007 09:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1FV-0008Tp-3l for sidr@ietf.org; Wed, 21 Mar 2007 09:53:09 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1FT-0000AX-Ok for sidr@ietf.org; Wed, 21 Mar 2007 09:53:09 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l2LDjhUM022489; Wed, 21 Mar 2007 08:45:44 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l2LDjhUM022489 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1174484744; bh=eaZGEwplYeovHAaEvq2yYFb+mxA=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=iPAR5TZsc8MaKldPuuayGABqshp/mUKDlt C5ZeY1QLS3FeiGqbhRY9bPPtS5WFCmRA5gotYZugFKyCpG+STchg== Message-Id: <200703211345.l2LDjhUM022489@workhorse.brookfield.occnc.com> To: Iljitsch van Beijnum From: Curtis Villamizar Subject: Re: [Sidr] draft-ietf-sidr-arch-00.txt In-reply-to: Your message of "Wed, 21 Mar 2007 09:35:56 BST." <09C87E64-BDC9-43DE-8564-18F7577B35AC@muada.com> Date: Wed, 21 Mar 2007 09:45:43 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org In message <09C87E64-BDC9-43DE-8564-18F7577B35AC@muada.com> Iljitsch van Beijnum writes: > > I was looking through draft-ietf-sidr-arch-00.txt and I noticed this: > > 5.2.2. Multi-homing > > If a multi-homed subscriber wants multiple ASes to originate > routes for prefixes that it holds, then it must explicitly > authorize each of them to do so by issuing a ROA for each AS in > question. > > Does this address the solution where multihomer M uses ISPs A and B, > and M's prefix is injected into BGP by both A and B and NOT by M? > I.e., "inconsistent origin AS", which is frowned upon. > > If not, the text is unclear. If so, why is there no discussion of the > normal situation where the multihomed AS advertises its prefix itself? > > Same thing for portable allocations without multihoming, although > there the situation where the ISP originates the prefix is more > common. > > BTW, it would be helpful if the availability of new drafts would be > announced on the list with the draft name in the subject. If normal means "architecturally pretty" then the multihomed prefix advertised by the true oridinator is normal. No special case is needed for that. Many multihomed enterprises don't have their own AS and have a single prefix. They don't run BGP. Instead each provider conditionally originates the prefix on their end with their AS if the link is up. If normal means "more common" then this might be the normal case. Curtis _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 21 10:15:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1bD-0000zm-JH; Wed, 21 Mar 2007 10:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1bB-0000zW-WE for sidr@ietf.org; Wed, 21 Mar 2007 10:15:34 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1b6-0005sn-IF for sidr@ietf.org; Wed, 21 Mar 2007 10:15:33 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l2LE8G6H022574; Wed, 21 Mar 2007 09:08:16 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l2LE8G6H022574 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1174486096; bh=9xDtKOI3BXEmw+boazcAkbo/4mM=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=rZx4aGOIG2GWONSPg8hNOzfSP4EwSc1wOe X+p2PDEnJvuzmmBor2FIAvtyy7DLBUgLWK5EEBUwZ2refTrTbsmA== Message-Id: <200703211408.l2LE8G6H022574@workhorse.brookfield.occnc.com> To: Larry Blunk From: Curtis Villamizar Subject: Re: [Sidr] Comments on ROA presentation In-reply-to: Your message of "Wed, 21 Mar 2007 05:45:00 EDT." <4600FE9C.7010408@merit.edu> Date: Wed, 21 Mar 2007 10:08:16 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org In message <4600FE9C.7010408@merit.edu> Larry Blunk writes: > > > The ROA presentation mentioned the option of using > "RPSL" for expressing prefix ranges. I just wanted > to make it clear that my suggestion was to borrow the > "RPSL Range Operator" expression syntax for prefix ranges. > This is a very small subset of the RPSL standard. > > There were comments in the meeting that it would not be possible > to employ large scale BGP filtering (i.e. on non-customer peering sessions). > There has been some research to suggest that such filtering may in > fact be feasible on modern day routers. See -- > http://www.nanog.org/mtg-0510/deleskie.html > > -Larry Larry, It was always feasible in "modern routers". There was just a time when not everyone making routers made modern routers. :-) Its more of an operational problem maintaining the prefix lists based on a external database or other OOB means. Some providers can deal with it, others feel that they can't. Religion may play a role here. The other issue is database coverage and accuracy. Fitting prefix lists into memory on the router, searching them quickly, and relatively fast non-disruptive update has been possible for well over a decade or just under a decade on some widely used commercial routers. A simplistic view is that SIDR is just changing the way the prefix list is populated and hopefully will change the coverage and accuracy. Curtis _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Mar 22 04:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIu8-0002im-RW; Thu, 22 Mar 2007 04:44:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIu7-0002iY-Lj for sidr@ietf.org; Thu, 22 Mar 2007 04:44:15 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUIu3-0000Q1-UP for sidr@ietf.org; Thu, 22 Mar 2007 04:44:15 -0400 Received: from [IPv6:2001:df8::16:20a:95ff:fef5:246e] ([IPv6:2001:df8:0:16:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2M8hcmk064042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Mar 2007 09:43:40 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <200703211345.l2LDjhUM022489@workhorse.brookfield.occnc.com> References: <200703211345.l2LDjhUM022489@workhorse.brookfield.occnc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E02ECB2-F23C-45BC-9891-4FC89B7D3D8E@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [Sidr] draft-ietf-sidr-arch-00.txt Date: Thu, 22 Mar 2007 09:44:04 +0100 To: curtis@occnc.com X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On 21-mrt-2007, at 14:45, Curtis Villamizar wrote: >> Does this address the solution where multihomer M uses ISPs A and B, >> and M's prefix is injected into BGP by both A and B and NOT by M? >> I.e., "inconsistent origin AS", which is frowned upon. >> If not, the text is unclear. If so, why is there no discussion of the >> normal situation where the multihomed AS advertises its prefix >> itself? > If normal means "architecturally pretty" then the multihomed prefix > advertised by the true oridinator is normal. No special case is > needed for that. If you mention special cases you must also specify the normal case. These are engineering documents, any time someone has to think about semantics we're in trouble. > Many multihomed enterprises don't have their own AS and have a single > prefix. They don't run BGP. Instead each provider conditionally > originates the prefix on their end with their AS if the link is up. > If normal means "more common" then this might be the normal case. Absolutely not. Last time I checked the first figure for incosistent origin AS were less than 1000 prefixes. The nature of this practice means you'll never see every affected prefix from any one given vantage point but it's pretty obvious that this is NOT a common practice. And why sghould it be? An AS number is much easier to get than address space and running BGP is much simpler than alternative methods to inject/remove prefixes depending on connectivity to a particular ISP. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Mar 22 09:55:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUNkv-0001KW-Ae; Thu, 22 Mar 2007 09:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUNku-0001KR-3t for sidr@ietf.org; Thu, 22 Mar 2007 09:55:04 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUNks-000070-NV for sidr@ietf.org; Thu, 22 Mar 2007 09:55:04 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l2MDliah045124; Thu, 22 Mar 2007 08:47:44 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l2MDliah045124 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1174571264; bh=Rn3f51zRCltS8lt4DaIwckw9/fE=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=d9SRsI0/lAb2lz+qO9jGGpTaNlf8teKoGJ Nvf5WTyILKTX1/Vg9QqcacdYW93iqdt0bM3LHLN0apvGIfIuVAFw== Message-Id: <200703221347.l2MDliah045124@workhorse.brookfield.occnc.com> To: Iljitsch van Beijnum From: Curtis Villamizar Subject: Re: [Sidr] draft-ietf-sidr-arch-00.txt In-reply-to: Your message of "Thu, 22 Mar 2007 09:44:04 BST." <0E02ECB2-F23C-45BC-9891-4FC89B7D3D8E@muada.com> Date: Thu, 22 Mar 2007 09:47:44 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org In message <0E02ECB2-F23C-45BC-9891-4FC89B7D3D8E@muada.com> Iljitsch van Beijnum writes: > > On 21-mrt-2007, at 14:45, Curtis Villamizar wrote: > > >> Does this address the solution where multihomer M uses ISPs A and B, > >> and M's prefix is injected into BGP by both A and B and NOT by M? > >> I.e., "inconsistent origin AS", which is frowned upon. > > >> If not, the text is unclear. If so, why is there no discussion of the > >> normal situation where the multihomed AS advertises its prefix > >> itself? > > > If normal means "architecturally pretty" then the multihomed prefix > > advertised by the true oridinator is normal. No special case is > > needed for that. > > If you mention special cases you must also specify the normal case. > These are engineering documents, any time someone has to think about > semantics we're in trouble. OK. I see your point. IMHO Adding mention of the normal case would be a better fix than removing this text. The remainder of this thread is an aside to the discussion of whats in the draft and so can be disregarded. > > Many multihomed enterprises don't have their own AS and have a single > > prefix. They don't run BGP. Instead each provider conditionally > > originates the prefix on their end with their AS if the link is up. > > If normal means "more common" then this might be the normal case. > > Absolutely not. Last time I checked the first figure for incosistent > origin AS were less than 1000 prefixes. The nature of this practice > means you'll never see every affected prefix from any one given > vantage point but it's pretty obvious that this is NOT a common > practice. Good. Seems less common than it used to be. > And why sghould it be? An AS number is much easier to get than > address space and running BGP is much simpler than alternative > methods to inject/remove prefixes depending on connectivity to a > particular ISP. I suppose my observation of this trend is severely dated and no longer valid. Dating myself again. Enterprises used to have an easier time getting PI space and they didn't trust the Internet so some wanted multiple providers. Though there was no evidence that multiple providers yielded higher availability that two circuits to the same provider. In fact the opposite was true since the provider bought the circuits and with same provider they could insist on diverse paths (and not always get it, but always get charged for it). Curtis _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 26 06:40:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVmb4-000482-Du; Mon, 26 Mar 2007 06:38:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVmb3-00047k-Bg for sidr@ietf.org; Mon, 26 Mar 2007 06:38:41 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVmb1-0000Nc-UD for sidr@ietf.org; Mon, 26 Mar 2007 06:38:41 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 4857F240B8; Mon, 26 Mar 2007 12:38:25 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 73586240B8 for ; Mon, 26 Mar 2007 12:38:24 +0200 (CEST) Received: from [127.0.0.1] (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id 6D2CE2F583 for ; Mon, 26 Mar 2007 12:38:24 +0200 (CEST) Message-ID: <4607A29F.7080502@ripe.net> Date: Mon, 26 Mar 2007 12:38:23 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_05 X-RIPE-Spam-Status: N 0.002444 / -2.9 X-RIPE-Signature: 203ed107a1fc2cd1d89d4320264d6c03 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [Sidr] draft-ietf-sidr-res-certs-05.txt comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Hello, Please find my comments below for discussion. 1. Typo at the bottom of page 6: RSA-SHA-384 OID is {pkcs-1 12}, not {pkcs-1 11} 2. In 3.9.5: Just as with the AIA, CRLDP should not appear in a root certificate. 3.In 4, last paragraph: "... Where two or more CRLs issued by a single CA are present in a certificate repository, the CRL with the highest value of the "CRL Number" field supersedes all other CRLs issued by this CA." When doing a rekey, a CA may have more than one key pair working in parallel, therefore must issue more than one CRL. In this case, the highest CRL number does not supersede all CRLs by that CA. 4. In 4.5, Signature can be RSA-SHA-256 only. Looking back at 3.3, I miss RSA-SHA-384 and RSA-SHA-512 from here. 5. In 5, I miss an introductory paragraph stating something like "a resource certificate request can be either PKCS#10 or CRMF". Without it, it is quite unclear why two different request formats are described below. 6. In 5.1.1, signatureAlgorithm: again RSA-SHA-384 and RSA-SHA-512 options are missing. 7. In 5.2.2, Resource Class: As the subject can also use PKCS#10 which does not have this option, I don't really see why is this field is a MUST. Also, when generating a request, the subject may not be aware of exactly which resource class that request/keypair will be used with, in which case this field cannot be filled in. 8. Section 5.3 starts with "This profile allows the following extensions to appear..." and then goes on describing fields which "MUST be omitted". I find this a bit confusing. 9. Section 5.3 lists the "SubjectInformationAccess" field twice, with slightly different text. I believe the second appearance should be simply omitted. 10. Same duplicate with SubjectAlternateName (also in 5.3). 11. At the very end of 5.3: I think the CA should not alter the SubjectInformationAccess requested by the subject. There is a reason why the subject asked for any particular URL: that is the adress they will be able to publish to. If the CA deliberately changes this, then the subject may end up with an unusable certificate. 12. In 6.1 we see "The only exception to the "no loop" condition would be where a putative trust anchor may issue a self-signed root certificate." This is confusing: "a self-signed certificate" by definition cannot be issued by anyone else but itself. The may be signed by the trust anchor key though. 13. In 6.3.: "... from the Root Trust Anchors via ..." The term "Root Trust Anchor" is strange for me. 14. In the example in Appendix A, the SIA value is syntactically wrong according to 3.9.7, as it does not end with '/'. Also, although it is theoretically not wrong, I miss the '.cer' extension from the end of the AIA value. Cheers, Robert _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 27 17:34:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWJHk-0002za-Km; Tue, 27 Mar 2007 17:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWJHj-0002zN-5y for sidr@ietf.org; Tue, 27 Mar 2007 17:32:55 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWJHg-0008Db-Nv for sidr@ietf.org; Tue, 27 Mar 2007 17:32:55 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l2RLV2ep018282 for ; Tue, 27 Mar 2007 16:31:02 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9iaWEJ; Tue, 27 Mar 07 16:29:59 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 36D543F424; Tue, 27 Mar 2007 17:29:04 -0400 (EDT) To: sidr@ietf.org Message-Id: <20070327212904.36D543F424@pecan.tislabs.com> Date: Tue, 27 Mar 2007 17:29:04 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: sandy@tislabs.com Subject: [Sidr] minutes from IETF68 sidr meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Here are the minutes for the meeting, with many thanks again to Henk. (I'll pick on someone else next time, Henk has served his two terms.) I was able to fill in a comment or two that Henk noted he had missed by checking the archive. Please post modifications/additions to the list by April 9. Apologies to those participating remotely. I started by noting we needed a minute taker and jabber scribe, but did not carry through on getting a scribe "volunteered", as Henk puts it. That, combined with my failure to get slides from presenters for the web site, left remote participants with only the audio feed to rely on. I'll do a better job next time. The audio archive is available at: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ietf68-ch5-mon-noon.mp3 There was one participant who spoke at the mike several times. Neither Henk, nor I, nor two other participants I asked, caught the name or knew the speaker. That speaker is identified as "XX" in the minutes. From the audio feed, his name is phonetically something like EU(oomlat)r-le-ra Row-shan. I'm certain that I butchered that. If anyone recognizes themselves or a friend from this description (you can listen to the audio archive yourself - try the sound bite starting 1:31:26 into the archive), please let me know so the minutes can be amended. (Why 1:30 into the archive? It seems the mics were all on and being recorded in all breaks, so the archive starts with background noise and chatter for the duration of the lunch break.) --Sandy SIDR WG Intro: started a few minutes late, Geoff unable to make it due to health problems, Henk volunteered as scribe. 1. RESCERTS draft. We went from -02 to -05. Geoff has a 1 line summary (see slides), some wording changes, diff of versions on slides, only mentioning those that brought comments from the audience: - Previous language prevented ISP from doing ROAs for same resource subset. Restriction removed. Comment from Steve: In the rewording, did Geoff remove all references to this or did he reword? Language simply taken out, Steve wants to think about it. - Other diffs are on slides but did not raise comments. - Paul Hoffman: rsync: is that an IANA spec? since the Rsync protocol is not - XX? How is this related to RIRs. How is interaction with RIPE DB done? Sandy: we want the RIRs to work on this. - Joe Abley: is rsync: (not a specified protocol) an issue. Sandy: no comments on this issue. Joe: uri that MUST be present, must be a protocol that is specified. Paul Hoffman: not specified, author does not want to bring it to the IETF. There are other protocols that we could use, but they are less popular. - XX? Couldn't find anything in the draft which routes have to be authenticated. Should all 200k routes be certified? Answer: Steve: it is in the architecture document, not here. - XX? Can we do a DOS by overloading the routers with certification checks by inserting false routes? Sandy: the routers don't have to do this. XX?: Is this in scope of draft or to be discussed elsewhere. Sandy: This draft is just certificate formats. We may need an operational use document but this is not in scope of this draft. Joe: this should be seen as a crypto layer added, not a BGP change. 2. Steve Kent/sidr-cp-01.txt - This is a template document, "fill in the right stuff here". - This ID reduces RFC3647 to what is useful for this case. RFC is 100 pages without text filled in, this doc only 47 with text filled in. - Paul: this seems heavily PKI, is this an ownership CP, are there other examples of such we can look at? Steve: I couldn't find any. 3. Steve/cps-rirs-01 - Overview of document - CPS requires a lot of tailoring by a CA. - Status: templates, to provide guidance. - Andrei Robashevsky: Not sure if you are going into this but what is the difference between the rir and isp docs. Steve: deals with different sides of the problem, small difference for RIR/ISP. Minimum security levels for ISPs are a bit lower. That sort of thing. - Paul Hoffman: Since CPS are layer 8 and above, RIRs are very similar. Propose to make this parallel. Steve: it is a template, RIRs to fill in internal procedures. Steve expects that the RIRs want the same starting point, then finetune things. Paul: what about change actual words. Steve: Most CAs follow template as BCP. Paul: be more explicit what can be changed. Steve asks Paul to send the comment to the list. 4. Steve/cps-isp-00: ISP version of the CPS 5. Steve/architecture document/sidr-arch-00.txt - Created in a rush to meet deadline. - PKI section a. Each resource holder is a CA. Because good practice that CA sign only certs, so create an end-entity cert to sign ROA b. Also good because can revoke ROA by revoking EE cert and only need EE private key once - can throw away c. Issues: add discussion of CA certs from multiple allocation sources d. Cert name conventions must be added e. AND WHAT ELSE? - ROA section - Repository system a. Issues: protocol for access b. Need to define access and access controls c. Need more discussion of repository structure d. Need discussion of distribution model RIR will probably maintain a repository of certs they create; but will other ISP's want to maintain their own? Will they want RIR to do it for them? - Discussion of repository section: a. Comment: it seems that you want to set up a repository for certs and don't rely on existing RIR infrastructure. ISPs got used to working with RIRs, why not extend the RIR DBs. Some discussion on what is in the RIR DBs (and what not), and what Certs would add. Certs can be verified. Steve: this is not a replacement of the system, but you can express things with more security. Sandy: an RIR can provide a link between the two (and 3 are considering this). b. Joe: we may need some context to explain interaction between RIPE DB and certs. The RIPE database couples allocation data and routing registry data. It is important to know that this coupling does not exist outside the RIPE region. This cert approach is the correct way. Steve asks Joe to put this in an email. c. Paul Hoffman: why does this need to be a different repository? Steve: whois is not designed for this. Sandy: the RIRs could be a repository, they don't have to be. d. Ruediger Volk: we have to deal with multiple databases of different structure. However, cert data can be mapped on to RPSL, and have existing tools access the data through whois->RPSL->certs. This will improve security, while (slightly modified) existing tools can continue to work. e. Andrei: one of the issues is consistency, how to keep them in sync? At RIR level, all data reflects one authoritative source: the internal RIR DB. CERTS can come from there too. There will be different users of the data and whois/cert. Steve: each RIR has its internal DB, the certs come from there. The internal DBs are not directly accessible, whois is a view. We need a new view though, that supports certs. f. XX: This is different in RIPE region wrt ARIN - Common operations section a. Need to add discuss of cert revocation and renewal b. Need to cite cert profile ID and cite ROA ID c. What else do we need - There is no official WG joke a. A certificate, CRL and ROA walk into an AS b. ... - Joe: how to revoke a ROA if one has lost/thrown away the key. Steve: you are the CA and control the CRL and can revoke the EE that signed the EE. Joe: mnemonic confusion. Sandy: how do you convince ISP when you hand them the ROA that you are the holder of the prefix? Steve: sign with a cert created by the CA that signed the EE cert. Sandy: how far up the chain can that relationship go? Steve: haven't discussed that. - Paul: you answered one of my concerns: You are doing a lot of CA operations instead of End Entity operations with the CA's key which goes against traditional PKI model of doing things. Steve agrees, but here every resource holder has to be a CA. What the CA is doing on behalf of the End Entity is revoking a cert, not signing an object. Paul: more CRL's than usual PKI. Steve: this is not a traditional PKI. - Paul: this document should not be informational. This should be on standards track, this will also allow you to move operational issues here. Steve has no problem with standards track. Sandy: take to list. - Sandy: There is a potential that other companies run repositories, how to make sure that what is uploaded is valid. Steve: this hooks back to the repository access control issue. We mention requirements but this is not complete. Needs another document or text. Sandy: check signature in certificate (or whatever). Steve: checking signature is right thing to do. Sandy: doc says to download certificates and check all signatures. Steve: want to do that anyway, even if repository has checked. - Sandy: draft says creating certificates that overlap is not recommended. Steve: this has to be fixed based on Geoff draft change. Sandy: RIRs sometimes keep half of a large block in reserve when allocating. Joe: what with 2 customers with adjacent /24's. Steve: this last one is in ROA space. Sandy: proxy aggregation is a problem we're not addressing. 6. Steve/ROA document - Last document. Introduction, new document. - Andrei R: ROA contains a list of AS. Steve: previous documents did. Now there is one per AS. Why? In a few slides. - Just one AS per ROA (Randy): in order to keep design simple. Geoff: if one AS#, the ROA authorizes only one ISP. If you need to ROA more, just issue more ROAs. Question from the floor - what do you do during merger? some companies use more than one AS#?. Steve comments that you can issue as many ROAs as you need, for multiple AS or upstreams or whatever. Downside: more things in repository, but disk is cheap. - ROA includes prefixes, not necessary but makes it easier in operations. You don't have to get the cert to find the prefixes. Richard Bones: does ROA prefix have to match EE cert prefix? Steve: yes. - Joe: is this v4 only? No, this is v4 and v6. - Discussion on ASN32. The issue is that the transition AS may pop up in route filters. This can be done by fixing things at the end. This needs text. Ruediger: as a 16 bit system, you cannot distinguish ASN32s. The system won't add security in this case, as anybody can use AS23456. Sandy: an ISP generating filters from certs would be able to adjust for ANS32s it doesn't understand. Steve will add text. - Steve points out that one can create as many ROAs as needed. Sandy: if enterprise is changing ISPs but retaining prefix for a while, it may want to get original ISP to sign ROA for new ISP. Steve: or have original ISP issue CA to enterprise so enterprise can sign ROA. - Discussion of match of ROA prefix to Update NLRI: exact match, or exact and more specific NLRI, or ROA expression of allowed NLRI. - Joe: some allocations are ranges that don't match a cidr boundary. Can't do exact match of NLRI against such a range. - Paul: what about range matching. Steve: ranges don't have to be prefixes. Exact match won't always work for ranges. One thing to do is to discuss what happens with multiple ROAs. This has to be checked and documented. The document doesn't talk about it yet. Take to list. - Sandy: where does stipulation of matching belong? - XX? Matching should allow fast implementation, when building/using large filters. Otherwise it won't work in practice. Need involvement with equipment manufacturers. Sandy: it is not necessarily to do this online, or to do this by building filter lists. Joe: should not get hung up on current router capabilities. Need these certs as a building block for future routers. - Ruediger: it is essential to have true, reliable information. Very hard to check some customer's claims. Revocation feature is also very helpful. End of meeting. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 27 18:21:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWK1h-0007S4-2V; Tue, 27 Mar 2007 18:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWK1g-0007Rw-A9 for sidr@ietf.org; Tue, 27 Mar 2007 18:20:24 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWK1e-0001DR-SS for sidr@ietf.org; Tue, 27 Mar 2007 18:20:24 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l2RMIY1O023545 for ; Tue, 27 Mar 2007 17:18:34 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhqaG2T; Tue, 27 Mar 07 17:17:58 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id EC8873F474; Tue, 27 Mar 2007 18:17:03 -0400 (EDT) To: sidr@ietf.org Message-Id: <20070327221703.EC8873F474@pecan.tislabs.com> Date: Tue, 27 Mar 2007 18:17:03 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sandy@tislabs.com Subject: [Sidr] action items from IETF68 sidr meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Some action items from the meeting: Steve Kent: wants to think about the removal of text dealing with CAs issuing certs for the same resources to two different entities. Sandy: check "rsync:" as a registered URI type. All: should we stick with IETF standardized protocols? Paul: comment to the list about issue of CPS draft being explicit regarding what text in the template can be changed. Joe Abley: comment to the list on the difference between RIPE database combination of allocation data and routing registry data and the database structure in other RIRs. Paul: raise question on the list as to whether the architecture document should be informational or standards track. Steve: add text to document re: 4 bytes ASNs. All: begin a discussion of ROA prefix to UPDATE NLRI matching rules, including what happens with mutliple ROAs. All: add to the architecture draft a discussion of uses of the certificates and ROAs. Did I miss any? --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 28 12:25:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWaxZ-0006U6-Ux; Wed, 28 Mar 2007 12:25:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWaxZ-0006P3-03 for sidr@ietf.org; Wed, 28 Mar 2007 12:25:17 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWaxX-0002nb-NE for sidr@ietf.org; Wed, 28 Mar 2007 12:25:16 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l2SGJrPE005984 for ; Wed, 28 Mar 2007 11:20:07 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAh7aaOl; Wed, 28 Mar 07 11:19:20 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 3D0083F49E; Wed, 28 Mar 2007 12:18:21 -0400 (EDT) To: sandy@tislabs.com, sidr@ietf.org Subject: Re: [Sidr] action items from IETF68 sidr meeting In-Reply-To: <20070327221703.EC8873F474@pecan.tislabs.com> Message-Id: <20070328161821.3D0083F49E@pecan.tislabs.com> Date: Wed, 28 Mar 2007 12:18:21 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org >Sandy: check "rsync:" as a registered URI type. There is no "rsync:" URI scheme listed on the IANA registry: http://www.iana.org/assignments/uri-schemes.html For what it's worth, there also is no "rsync:" URN listed on the IANA URN registry: http://www.iana.org/assignments/urn-namespaces --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 28 13:22:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWbpK-0001eJ-MT; Wed, 28 Mar 2007 13:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWbpJ-0001Zf-Rt for sidr@ietf.org; Wed, 28 Mar 2007 13:20:49 -0400 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWbpH-0006jS-Uu for sidr@ietf.org; Wed, 28 Mar 2007 13:20:49 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l2SIJQhd014120; Wed, 28 Mar 2007 10:19:26 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l2SIJQh7014117; Wed, 28 Mar 2007 10:19:26 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 28 Mar 2007 10:19:26 -0800 (PST) From: "william(at)elan.net" To: Sandy Murphy Subject: Re: [Sidr] action items from IETF68 sidr meeting In-Reply-To: <20070328161821.3D0083F49E@pecan.tislabs.com> Message-ID: References: <20070328161821.3D0083F49E@pecan.tislabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org One other thing to remember is that if URL/URI is registered by means of RFC, it needs to have protocol that is also documented by RFC which rsync is not (its would be possible to get it into informational RFC I suppose) and I have bad feeling that it is not an IETF documented protocol would be bigger issue and without it you may not be able to get SIDR drafts passed IESG or general IETF last-call review (but I'm not sufficiently versed in IETF RFC publication requirements to be certain how big of an issue it is). On Wed, 28 Mar 2007, Sandy Murphy wrote: >> Sandy: check "rsync:" as a registered URI type. > > There is no "rsync:" URI scheme listed on the IANA registry: > http://www.iana.org/assignments/uri-schemes.html > > For what it's worth, there also is no "rsync:" URN listed on the IANA > URN registry: > http://www.iana.org/assignments/urn-namespaces > > --Sandy > > _______________________________________________ > Sidr mailing list > Sidr@ietf.org > https://www1.ietf.org/mailman/listinfo/sidr _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 28 14:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWd5n-0006pG-3t; Wed, 28 Mar 2007 14:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWd5l-0006pB-VN for sidr@ietf.org; Wed, 28 Mar 2007 14:41:53 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWd5k-0003iD-MJ for sidr@ietf.org; Wed, 28 Mar 2007 14:41:53 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HWd5h-0002p6-65; Wed, 28 Mar 2007 14:41:50 -0400 Message-ID: <460AB6EA.3060302@bbn.com> Date: Wed, 28 Mar 2007 14:41:46 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "william(at)elan.net" Subject: Re: [Sidr] action items from IETF68 sidr meeting References: <20070328161821.3D0083F49E@pecan.tislabs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sidr@ietf.org, Sandy Murphy X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org > without > it you may not be able to get SIDR drafts passed IESG or general > IETF last-call review (but I'm not sufficiently versed in IETF RFC > publication requirements to be certain how big of an issue it is). It depends on which draft you're talking about, and whether that draft makes normative or informative reference to rsync. There are two drafts that refer to rsync right now: draft-ietf-sidr-res-certs-01 makes normative references to rsync, e.g. "An rsync URI MUST be present in the DistributionPointName set.". draft-ietf-sidr-arch-00 makes only informative references to rsync, e.g. "Current efforts to implement a repository system use RSYNC [9] as the single access protocol. RSYNC, as used in this implementation, provides all of the above functionality." It seems to me like the former draft will probably get hung up on the issue, while the latter is less likely to. --Richard > > On Wed, 28 Mar 2007, Sandy Murphy wrote: > >>> Sandy: check "rsync:" as a registered URI type. >> >> There is no "rsync:" URI scheme listed on the IANA registry: >> http://www.iana.org/assignments/uri-schemes.html >> >> For what it's worth, there also is no "rsync:" URN listed on the IANA >> URN registry: >> http://www.iana.org/assignments/urn-namespaces >> >> --Sandy >> >> _______________________________________________ >> Sidr mailing list >> Sidr@ietf.org >> https://www1.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > Sidr mailing list > Sidr@ietf.org > https://www1.ietf.org/mailman/listinfo/sidr > > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Mar 29 07:08:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWsSu-0002k9-Lk; Thu, 29 Mar 2007 07:06:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWsSt-0002fK-JV for sidr@ietf.org; Thu, 29 Mar 2007 07:06:47 -0400 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWsSr-0007r2-3f for sidr@ietf.org; Thu, 29 Mar 2007 07:06:47 -0400 Received: from gihm3.apnic.net (dhcp4.potaroo.net [203.10.60.4]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l2TB5qH0039519; Thu, 29 Mar 2007 21:05:53 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070329210136.049451c8@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 29 Mar 2007 21:07:10 +1000 To: "william(at)elan.net" , Sandy Murphy From: Geoff Huston Subject: Re: [Sidr] action items from IETF68 sidr meeting In-Reply-To: References: <20070328161821.3D0083F49E@pecan.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 04:19 AM 29/03/2007, william(at)elan.net wrote: >One other thing to remember is that if URL/URI is registered by >means of RFC, it needs to have protocol that is also documented >by RFC which rsync is not I was in a URI WG meeting some IETF's ago and I thought that this was an historical and not a current constraint. I'm not sure what transpired with this work, so perhaps the best way forward is to establish what we can from the documentation. So if what you are asserting is indeed the case then there should be documentation to support this. Could you please point me to the IETF document where the need you refer to above relating to a published RFC for a URI type is clearly stated? regards, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Mar 30 10:22:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHyr-0004ju-84; Fri, 30 Mar 2007 10:21:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHyq-0004jo-74 for sidr@ietf.org; Fri, 30 Mar 2007 10:21:28 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXHyg-0002BV-BO for sidr@ietf.org; Fri, 30 Mar 2007 10:21:28 -0400 Received: from pc6 (1Cust154.tnt9.lnd4.gbr.da.uu.net [62.188.138.154]) by galaxy.systems.pipex.net (Postfix) with SMTP id A2457E000525; Fri, 30 Mar 2007 15:21:00 +0100 (BST) Message-ID: <03b601c772cd$e5603c60$0601a8c0@pc6> From: "tom.petch" To: "william(at)elan.net" , "Sandy Murphy" , "Geoff Huston" References: <20070328161821.3D0083F49E@pecan.tislabs.com> <7.0.0.16.2.20070329210136.049451c8@apnic.net> Subject: Re: [Sidr] action items from IETF68 sidr meeting Date: Fri, 30 Mar 2007 15:05:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org ----- Original Message ----- From: "Geoff Huston" To: "william(at)elan.net" ; "Sandy Murphy" Cc: Sent: Thursday, March 29, 2007 1:07 PM Subject: Re: [Sidr] action items from IETF68 sidr meeting > At 04:19 AM 29/03/2007, william(at)elan.net wrote: > > >One other thing to remember is that if URL/URI is registered by > >means of RFC, it needs to have protocol that is also documented > >by RFC which rsync is not > > > I was in a URI WG meeting some IETF's ago and I thought that this was > an historical and not a current constraint. I'm not sure what > transpired with this work, so perhaps the best way forward is to > establish what we can from the documentation. So if what you are > asserting is indeed the case then there should be documentation to > support this. Could you please point me to the IETF document where > the need you refer to above relating to a published RFC for a URI > type is clearly stated? > Geoff The guidelines for URI registration are in RFC4395. s2.3 expects the scheme to have a well-defined mapping onto a namespace or protocol or there to be a good explanation of why not. This is not insuperable. There is an individual submission standards-track I-D for SMB (a protocol which could be loaded with issues of being ill-defined, IPR-laden etc) but does, I think, meet the requirements. Tom Petch > regards, > > Geoff > > > > _______________________________________________ > Sidr mailing list > Sidr@ietf.org > https://www1.ietf.org/mailman/listinfo/sidr _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Mar 30 18:04:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXPC0-0003og-NV; Fri, 30 Mar 2007 18:03:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXPBz-0003oa-MN for sidr@ietf.org; Fri, 30 Mar 2007 18:03:31 -0400 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXPBy-0007Yf-04 for sidr@ietf.org; Fri, 30 Mar 2007 18:03:31 -0400 Received: from gihm3.apnic.net (dhcp4.potaroo.net [203.10.60.4]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l2UM37xD015121; Sat, 31 Mar 2007 08:03:08 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070331075833.0157f838@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sat, 31 Mar 2007 08:04:19 +1000 To: "tom.petch" , "william(at)elan.net" , "Sandy Murphy" From: Geoff Huston Subject: Re: [Sidr] action items from IETF68 sidr meeting In-Reply-To: <03b601c772cd$e5603c60$0601a8c0@pc6> References: <20070328161821.3D0083F49E@pecan.tislabs.com> <7.0.0.16.2.20070329210136.049451c8@apnic.net> <03b601c772cd$e5603c60$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org > > >One other thing to remember is that if URL/URI is registered by > > >means of RFC, it needs to have protocol that is also documented > > >by RFC which rsync is not > > > > > > I was in a URI WG meeting some IETF's ago and I thought that this was > > an historical and not a current constraint. I'm not sure what > > transpired with this work, so perhaps the best way forward is to > > establish what we can from the documentation. So if what you are > > asserting is indeed the case then there should be documentation to > > support this. Could you please point me to the IETF document where > > the need you refer to above relating to a published RFC for a URI > > type is clearly stated? > > > >Geoff > >The guidelines for URI registration are in RFC4395. s2.3 expects the scheme to >have a well-defined mapping onto a namespace or protocol or there to be a good >explanation of why not. This is not insuperable. There is an individual >submission standards-track I-D for SMB (a protocol which could be loaded with >issues of being ill-defined, IPR-laden etc) but does, I think, meet the >requirements. thanks Tom I believe that this answers the question - the current process for URI registration is via use of a registration template and an IANA registry, and not via an RFC. regards, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Mar 30 18:10:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXPJ8-0001qB-3N; Fri, 30 Mar 2007 18:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXPJ6-0001q2-N6 for sidr@ietf.org; Fri, 30 Mar 2007 18:10:52 -0400 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXPJ4-0001wx-9j for sidr@ietf.org; Fri, 30 Mar 2007 18:10:52 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l2UN8kMP021512; Fri, 30 Mar 2007 15:08:46 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l2UN8kaH021509; Fri, 30 Mar 2007 15:08:46 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 30 Mar 2007 15:08:46 -0800 (PST) From: "william(at)elan.net" To: Geoff Huston Subject: Re: [Sidr] action items from IETF68 sidr meeting In-Reply-To: <7.0.0.16.2.20070331075833.0157f838@apnic.net> Message-ID: References: <20070328161821.3D0083F49E@pecan.tislabs.com> <7.0.0.16.2.20070329210136.049451c8@apnic.net> <03b601c772cd$e5603c60$0601a8c0@pc6> <7.0.0.16.2.20070331075833.0157f838@apnic.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sidr@ietf.org, Sandy Murphy X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On Sat, 31 Mar 2007, Geoff Huston wrote: > I believe that this answers the question - the current process for URI > registration is via use of a registration template and an IANA registry, and > not via an RFC. My original post specifically said "if it is defined by an RFC", this did not mean its the only way to register an URI. However like I wrote the issue really is that when you're relying on rwhois protocol and you want it in STD protocol you'll almost certain have to have it described by an RFC too, so like it or not somebody needs to write an RFC on rwhois (probably send as individual submission) and that is how it URI can be registered as well. -- William Leibzon Elan Networks william@elan.net _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Mar 30 20:31:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXRU7-0000OL-MC; Fri, 30 Mar 2007 20:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXRU5-0000OG-Ql for sidr@ietf.org; Fri, 30 Mar 2007 20:30:21 -0400 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXRU4-0001fc-E2 for sidr@ietf.org; Fri, 30 Mar 2007 20:30:21 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l2V1SUWm023874; Fri, 30 Mar 2007 17:28:30 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l2V1STvn023871; Fri, 30 Mar 2007 17:28:30 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 30 Mar 2007 17:28:29 -0800 (PST) From: "william(at)elan.net" To: Geoff Huston Subject: Re: [Sidr] action items from IETF68 sidr meeting In-Reply-To: Message-ID: References: <20070328161821.3D0083F49E@pecan.tislabs.com> <7.0.0.16.2.20070329210136.049451c8@apnic.net> <03b601c772cd$e5603c60$0601a8c0@pc6> <7.0.0.16.2.20070331075833.0157f838@apnic.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Sandy Murphy , sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Ups I meant RFC on 'rsync' On Fri, 30 Mar 2007, william(at)elan.net wrote: > On Sat, 31 Mar 2007, Geoff Huston wrote: > >> I believe that this answers the question - the current process for URI >> registration is via use of a registration template and an IANA registry, >> and not via an RFC. > > My original post specifically said "if it is defined by an RFC", > this did not mean its the only way to register an URI. However like > I wrote the issue really is that when you're relying on rwhois protocol and > you want it in STD protocol you'll almost certain have to have it described > by an RFC too, so like it or not somebody needs to write an > RFC on rwhois (probably send as individual submission) and that is > how it URI can be registered as well. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Mar 31 03:09:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXXhJ-0001DE-GS; Sat, 31 Mar 2007 03:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXXhH-0001D9-Pj for sidr@ietf.org; Sat, 31 Mar 2007 03:08:23 -0400 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXXhF-0003LI-VL for sidr@ietf.org; Sat, 31 Mar 2007 03:08:23 -0400 Received: from gihm3.apnic.net (dhcp23.potaroo.net [203.10.60.23]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l2V77T9V020261; Sat, 31 Mar 2007 17:07:29 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070331170706.0434b398@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sat, 31 Mar 2007 17:08:03 +1000 To: "william(at)elan.net" From: Geoff Huston Subject: Re: [Sidr] action items from IETF68 sidr meeting In-Reply-To: References: <20070328161821.3D0083F49E@pecan.tislabs.com> <7.0.0.16.2.20070329210136.049451c8@apnic.net> <03b601c772cd$e5603c60$0601a8c0@pc6> <7.0.0.16.2.20070331075833.0157f838@apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sidr@ietf.org, Sandy Murphy X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 09:08 AM 31/03/2007, william(at)elan.net wrote: >On Sat, 31 Mar 2007, Geoff Huston wrote: > >>I believe that this answers the question - the current process for >>URI registration is via use of a registration template and an IANA >>registry, and not via an RFC. > >My original post specifically said "if it is defined by an RFC", >this did not mean its the only way to register an URI. However like >I wrote the issue really is that when you're relying on rwhois >protocol and you want it in STD protocol you'll almost certain have >to have it described by an RFC too, so like it or not somebody needs >to write an >RFC on rwhois (probably send as individual submission) and that is >how it URI can be registered as well. Perhaps you could refer me to the process document where this is described? thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Mar 31 05:11:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXZbe-0005yg-FA; Sat, 31 Mar 2007 05:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXZbd-0005xF-Si for sidr@ietf.org; Sat, 31 Mar 2007 05:10:41 -0400 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXZbZ-0007En-BH for sidr@ietf.org; Sat, 31 Mar 2007 05:10:41 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l2VA8heT006150; Sat, 31 Mar 2007 02:08:43 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l2VA8g6P006147; Sat, 31 Mar 2007 02:08:43 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 31 Mar 2007 02:08:42 -0800 (PST) From: "william(at)elan.net" To: Geoff Huston Subject: Re: [Sidr] action items from IETF68 sidr meeting In-Reply-To: <7.0.0.16.2.20070331170706.0434b398@apnic.net> Message-ID: References: <20070328161821.3D0083F49E@pecan.tislabs.com> <7.0.0.16.2.20070329210136.049451c8@apnic.net> <03b601c772cd$e5603c60$0601a8c0@pc6> <7.0.0.16.2.20070331075833.0157f838@apnic.net> <7.0.0.16.2.20070331170706.0434b398@apnic.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sidr@ietf.org, Sandy Murphy X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On Sat, 31 Mar 2007, Geoff Huston wrote: > Perhaps you could refer me to the process document where this is described? http://www.iana.org/assignments/uri-schemes.html All "permanent" URI schemes are defined protocol RFCs. Provisional schemes are internet drafts. Procedure defined by RFC4395: http://www.rfc-editor.org/rfc/rfc4395.txt IANA lists URI registration as not through "expert" review with Graham Klyne designated as expert. A quite from RFC with more details is below: ------------- 5.2. Registration Procedures Someone wishing to register a URI scheme SHOULD: 1. Check the IANA URI scheme registry to see whether or not there is already an entry for the desired name. If there is already an entry under the name, choose a different URI scheme name. 2. Prepare a URI scheme registration template, as specified in Section 5.4. The URI scheme registration template may be contained in an Internet Draft, alone or as part of some other protocol specification. The template may also be submitted in some other form (as part of another document or as a stand-alone document), but the contents will be treated as an "IETF Contribution" under the guidelines of RFC 3978 [4]. 3. Send a copy of the template or a pointer to the containing document (with specific reference to the section with the template) to the mailing list uri-review@ietf.org, requesting review. In addition, request review on other mailing lists as appropriate. For example, general discussion of URI syntactical issues could be discussed on uri@w3.org; schemes for a network protocol could be discussed on a mailing list for that protocol. Allow a reasonable time for discussion and comments. Four weeks is reasonable for a permanent registration requests. ------------- http://www.ietf.org/rfc/rfc2026.txt Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. (See Section 7.) ... 7.1.2 Incorporation of Other Specifications Other proprietary specifications may be incorporated by reference to a version of the specification as long as the proprietor meets the requirements of section 10. If the other proprietary specification is not widely and readily available, the IESG may request that it be published as an Informational RFC. ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt An RFC must include separate lists of normative and informative references (see Section 4.7f below.) The distinction between normative and informative references is often important. The IETF standards process and the RFC Editor publication process need to know whether a reference to a work in progress is normative. A standards-track RFC cannot be published until all of the documents that it lists as normative references have been published. In practice, this often results in the simultaneous publication of a group of interrelated RFCs. 2.8 URLs and DNS names in RFCs The use of URLs in RFCs is discouraged, because many URLs are not stable references. Exceptions may be made for normative references in those cases where the URL is demonstrably the most stable reference available. References to long-lived files on ietf.org and rfc-editor.org are generally acceptable. ------------- Unless I'm mistaken no document other then one published by another standards body (i.e. W3) has ever been incorporated as normative reference STD RFC published within last few years. But since you're the one who collects all the docs at pataroo.net I'd expect you to know that better. -- William Leibzon Elan Networks william@elan.net _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr