These policies allow= for the transfer of INRs of flexible size, including subordinate blocks.

The policies (rightly so) discourage unnecessary fragmentation of INRs= .

So, to make this issue easier to follow, lets ta= ke a fictional example (using RFC1918 space per standard practice a la example.com) and show the problem that resul= ts.

Let's say someone had a right-to-use on 10.0.0.0/8.

Now suppose they want to trans= fer (sell) a /24 out of this space, to an unrelated party.

(Since= binary trees don't have any particular affinity, the choice of /24 is = both arbitrary and irrelevant for this example.)

For illustrative purposes, suppose that it is 10.20.30.0/24.

Regardless of how long= the transfer takes to process, and how long it takes RP caches to sync up,= at some point in the future, the RPKI needs to represent the "new wor= ld order".

So, what ways does 3779 support encoding of both the or= iginal block (minus the /24), and the new block?

The new block is= easy - it is 10.20.30.0/24. The new o= wner could be in the same IRR, or a different IRR. The new owner would anno= unce, in BGP (and BGPSEC), 10.20.30.0/24.

What about the old block?

It must be encoded = in one of 4 ways:

10.0.0.0/= 8
two ranges (10.0.0.0-10.20.29.255 and 10.20.31.0-10.255.255.2= 55)
a bunch of prefixes (16 in total) of lengths 9 through 24

<= a href=3D"http://10.0.0.0/12">10.0.0.0/12
10.16.0.0/14

even larger n= umber of prefixes that form any sort of binary decomposition of the above 1= 6 prefixes

However, the RP/RPKI rules mean that it is n= ot possible to have the original owner advertise 10.0.0.0/8, if methods 2, 3, or 4 are used.

On the other hand, restricting INR transfers to methods= 2, 3, or 4, result in each INR causing the need for an additional (N-M) pr= efixes, if the original prefix length is M and the transfered prefix length= is N.

And lastly, if method 1 is used, it is impossible to pr= event the original owner from producing an ROA that would validate, which c= overs the "transfered" INR.

This creates= a Hobson's choice: either accept the inability to protect against subs= equent (accidental or malicious) hijacking of transfered INRs, or accept th= e need for routing table bloat.

=3D=3D=3D=3D=3D ALTERNATIVES =3D=3D=3D=3D=3D

There is an alternative - replace 3779, and the rules of inh= eritance in the RPKI, with something that supports "holes".

What is a hole? The definitive assertion of the non-routeability (or non-ow= nership) of longer prefixes within a block.

This w= ould need to be "glued" onto a parent block, and remain attached = to any delegation of a block containing the "hole".

Prefixes shorter than the "hole" would be val= id (e.g. an ROA with maximum prefix length < prefix length of enclosed h= ole(s)).

Prefixes the same size or longer than the= "hole" would be invalid. Neither a CA (delegation) nor an ROA wo= uld be permissible if it covered the range of a "hole" without in= cluding the explicit hole, or made permissible a routing announcement anywh= ere inside the "hole".

Examples of "new world order" allowable ROAs = of a hypothetical 3779-bis would be:

10.0.0.0/8 le 23 =A0=3D> would allow covering prefix 10.20.30.0/23 (which is shorter than 10.20.30.0/24) but not allow conflicting prefix 10.20.30.0/24

10.128.0.0/9 le 32 =3D> has no = overlap with the "hole" at 10.20= .30.0/24

10.20.32.0/19 l= e 32 =3D> has no overlap with the "hole"

10.20.31.0/24 le 32 =3D> adjac= ent to, but no overlap with, the "hole"

10.20.29.0/24 le 32 =3D> adjacent to, but no overl= ap with, the "hole"

10.20.0.0/16 le 23 =3D> covers = "hole", but only permits prefixes shorter than (covering) the &qu= ot;hole"

In this alternate representation sch= eme, any necessary prefixes by either party could be registered (in RPKI) v= ia ROAs, and announced, without presenting either a security risk to either= party (of hijacking) or placing a burden on the global BGP table (of prefi= xes dictated by RPKI fragmentation of parent blocks of transfered INRs).

The old owner could (continue to) announce 10.0.0.0/8.

The new owner could announce 10.20.30.0/24.

Nobody would ha= ve to worry about conflicting announcements of 10.20.30.0/24 (or longer).

The current RPKI scheme cannot represent this, because = RFC 3779 cannot represent this.

And as a consequence, it is impos= sible to encode in origin validation logic, so RPs are not able to enjoy th= e benefits.

Until such a fix is implemented (in 3779, all the RPKI = documents that incorporate 3779, and all the RP-related docs), the only rea= sonable conclusion is that these are fatal flaws (from the perspective of o= perators).

Brian

--0016e6dd8d6984468d04c9ac7419-- From internet-drafts@ietf.org Fri Sep 14 10:20:01 2012 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 5BEB121F8528; Fri, 14 Sep 2012 10:20:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6h2a9rblJSTt; Fri, 14 Sep 2012 10:20:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCDF21F8459; Fri, 14 Sep 2012 10:20:00 -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.34 Message-ID: <20120914172000.28146.16211.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 10:20:00 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-03.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: Fri, 14 Sep 2012 17:20: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 : Threat Model for BGP Path Security Author(s) : Stephen Kent Andrew Chi Filename : draft-ietf-sidr-bgpsec-threats-03.txt Pages : 26 Date : 2012-09-14 Abstract: This document describes a threat model for the context in which BGP path security mechanisms will be developed. It assumes the context established by the SIDR WG charter, as of April 19, 2011. The charter established two goals for the SIDR work: o Enabling an AS to verify the authorization of an origin AS to The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-threats-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From achi@bbn.com Fri Sep 14 10:27:39 2012 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 3CA5821F8462 for ; Fri, 14 Sep 2012 10:27:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThhYpX49vdtd for ; Fri, 14 Sep 2012 10:27:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 597D521F845D for ; Fri, 14 Sep 2012 10:27:38 -0700 (PDT) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:64574 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TCZfm-000Lbr-TG; Fri, 14 Sep 2012 13:27:23 -0400 Message-ID: <505368F7.5040107@bbn.com> Date: Fri, 14 Sep 2012 13:27:19 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Danny McPherson References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com>

<503C904F.2040609@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg Subject: Re: [sidr] Some comments on draft-ietf-sidr-bgpsec-threats-02 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, 14 Sep 2012 17:27:39 -0000 On 8/28/2012 11:19 AM, Danny McPherson wrote: > Thanks for the thoughtful reply Steve, I'll get back to you in short order on these responses - but if an updated I-D appears in the interim I'll try to apply comments only to the revision. Thanks for your comments, Danny. The bgpsec-threats-03 I just uploaded includes a substantial number of edits based on this discussion (mostly by Steve, with a couple mine). From achi@bbn.com Fri Sep 14 10:40:32 2012 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 21AB521F851C for ; Fri, 14 Sep 2012 10:40:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2fPFJQ-JPD0 for ; Fri, 14 Sep 2012 10:40:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A340821F84F8 for ; Fri, 14 Sep 2012 10:40:31 -0700 (PDT) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:64587 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TCZsU-000Los-4L; Fri, 14 Sep 2012 13:40:30 -0400 Message-ID: <50536C0B.9000704@bbn.com> Date: Fri, 14 Sep 2012 13:40:27 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Chi References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com>

<503C904F.2040609@bbn.com> <505368F7.5040107@bbn.com> In-Reply-To: <505368F7.5040107@bbn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg Subject: Re: [sidr] Some comments on draft-ietf-sidr-bgpsec-threats-02 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, 14 Sep 2012 17:40:32 -0000 On 9/14/2012 1:27 PM, Andrew Chi wrote: > Thanks for your comments, Danny. The bgpsec-threats-03 I just uploaded > includes a substantial number of edits based on this discussion (mostly > by Steve, with a couple mine). My bad, there might be some version skew as not all edits made it into -03; expect more text in the next rev. From ietf-secretariat@ietf.org Fri Sep 14 11:17:14 2012 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 57D6D21F8549; Fri, 14 Sep 2012 11:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgpL5Prv7WQl; Fri, 14 Sep 2012 11:17:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67921F853E; Fri, 14 Sep 2012 11:17:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120914181713.8337.93189.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 11:17:13 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [sidr] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS 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, 14 Sep 2012 18:17:14 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfre= g.py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations The IETF is holding a block of rooms at the Hotel Okura. The Hotel is not c= urrently ready to accept reservations but we hope to be able to provide boo= king details early next week (the week of 17 September). 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From brian.peter.dickson@gmail.com Fri Sep 14 11:32:00 2012 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 DE8F721F8554 for ; Fri, 14 Sep 2012 11:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZhLQ3Bgmdwh for ; Fri, 14 Sep 2012 11:31:59 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C81221F8545 for ; Fri, 14 Sep 2012 11:31:58 -0700 (PDT) Received: by weyu54 with SMTP id u54so2789588wey.31 for ; Fri, 14 Sep 2012 11:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YdwnLm/1HSGiNZTepldPAzAIGdFCouQGwhMV3k57IZ4=; b=Q/PztFMlC6mxv2+200j82SpC9+f7d5oFSXBgN03F96uR8HIOyWFdXZaJzaHEnIKgdk 8BpLdvsQ2IxPeCJz8A5hOEQL3RsELn/Tn4OFQkaesRNyGsXvtKeOqpLERtm9GTLUcQlD pwOc4wJltC6ph0m0qf43Bop0HLOHyw0feCfkI7951M4O2Z4RUDyaRGv+/LyZxTGZw5Ho V5oz6WJ0x+i2lqB3EMn4gGyvakR34J3D2vqbBNutb4zxKTteo1KHAGONDRio9hR1f7bM wMvUk5h90/0cMw7Hork17hV5j/v+E/J7nVORAI6MUBbufVTQmxLrVWARPNNpipPYlwue Fdmg== MIME-Version: 1.0 Received: by 10.216.132.25 with SMTP id n25mr1843457wei.25.1347647509606; Fri, 14 Sep 2012 11:31:49 -0700 (PDT) Received: by 10.223.61.12 with HTTP; Fri, 14 Sep 2012 11:31:44 -0700 (PDT) In-Reply-To: <50524582.1050704@bbn.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com> <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com> <503D141F.1060404@bbn.com> <3A791D9E-4F16-4481-94AE-BD38A5389593@verisign.com>

<50461289.1040907@bbn.com> <50464081.4020305@bbn.com> <5050C546.9070304@bbn.com> <33A96E17-0CBF-4E17-A0D8-55FE3369142F@apnic.net> <50524582.1050704@bbn.com> Date: Fri, 14 Sep 2012 14:31:44 -0400 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: multipart/alternative; boundary=0016e6dd8d6917b27e04c9ada3ea Cc: sidr@ietf.org Subject: Re: [sidr] RPKI <-> allocation consistency 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, 14 Sep 2012 18:32:01 -0000 --0016e6dd8d6917b27e04c9ada3ea Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Sep 13, 2012 at 4:43 PM, Stephen Kent wrote: > Brian,**** > > > If we allow a reasonable time for RPs to have fetched the not-yet-valid > objects, then when they "turn the crank" to process local caches after th= e > objects have become valid, the RPs would accept them. But, I've never hea= r > anyone suggest that one ought to try to impose a global, coordinated, RPK= I > object processing time on all RPs. (That, in itself would be a security > concern.) So there may be limits here as to how much the overlap can be > reduced by this strategy. > I'm not suggesting polling-based, synchronous processing of anything. Clearly, that would be foolish. While the implementation is up to the implementer(s), I'd expect event-driven scheduling of processing of changes of state. E.g. set up queues ordered by start or end date/time. Recall, this validation is on the RPKI cache validation side. It is outside of the scope of RPKI-RTR protocol, with the expectation that state changes on the validation would get pushed to routers. Pre-publishing means that local validation would merely need to occur in the overlap window. As long as the new and old objects have been pushed to the router with any amount of overlap, there is no risk of validation failure on received updates. > **** > > Also, are there any other examples you can cite where every network > operator is expected to perform some activity, at the same time (relative > to UTC), every day, around the world? > NETWORK operator? No. But there are plenty of other activities driven by certificate expirations, either passively or actively, which require overlapping (pre-published) objects in order to avoid validation failure. DNSSEC, TLS/SSL, pretty much any certificate-based protocol or security mechanism. > What is the accepted norm for clock sync among all ISPs today, and what > processes rely on the extant precision and accuracy of synchronized clock= s > at all ISPs? > NTP, stratum 3 or better. BGP neighbors normally expect each others' clocks to be NTP synchronized, for reasons of trouble-shooting instances of accidental or malicious issues. Logs are useless if their time is not accurate to the millisecond. (Some peering contracts actually require this.) Transit relationships typically require accurate measurement of traffic, both volumetrically and with accurate time. Failure to implement measurement and billing using accurate (NTP) time, is a huge liability. Customers expect to be able to correlate their own measurements with their providers - again, without NTP, this is likely to incur L8/L9 problems. Additionally, virtually every network link requires accurate line-clock, either supplied by the network, or by the end devices. Nearly all network links and/or routers have line-clocking derived (directly or indirectly) from Stratum-1 sources. This can be achieved in a number of ways, either special NTP feeds, or BITS, or TTL, or via transmission gear with integrated cesium clocks and/or GPS receivers. Failure to have synchronized line-clocking is probably the #1 source of network problems during implementation of peering links. Drifting clocks will cause errors and/or outages, guaranteed. > Not being an operator, I really don't know the answers to these questions= . > Maybe these are questions you should have asked and gotten the answers to, prior to designing the RPKI? (Sorry, cheap shot.) > **** > > Anyway, if we were to adopt your suggestion, the benefit might be that th= e > overlap interval need be determined primarily by the time needed to > accommodate skew in RPs posting, fetching, and processing RPKI objects. > Overlap times are only required when there is "live transfer" of INRs, correct? So, mostly (>>99.99999% of the INRs will never have this issue, as 99.999% won't transfer, and of the transfers, 99.99% won't be "live") moot. So, even supposing that such incidents occur, there are two limits to consider: (1) The minimum (actual) overlap interval between the old and new (2) The proscribed maximum overlap interval beyond which one or the other should be rejected So, the discussion would really need to focus on lower bounds and upper bounds for (2). Lower bounds impact mandatory actions by cache operators, or alternatively, risk to operators/RPs of RPKI-induced outages Upper bounds impact the security of the system, and/or window of opportunity for hijacking. > Rather the overlap interval would be a function of what folks consider t= o > be a comfortable interval to accommodate human processes (and errors) for > the INR transfers.**** > > ** ** > > I don=92t know that this time scale as being one that requires carefully > coordinated clocks at all RPs, especially since we don't have a candidate > overlap interval value on the table. Moreover, since there is an overlap > interval in either case, it=92s not immediately clear how hard we should = work > to reduce it. What overlap interval did you envision? > To paraphrase Vin Diesel (in pretty much any movie he's been in): "Not my problem." What I envision is, the authors of SIDR I-Ds/RFCs proposing intervals, and then discussing/justifying them. Brian --0016e6dd8d6917b27e04c9ada3ea Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 13, 2012 at 4:43 PM, Stephen= Kent <kent@bbn.com> wrote:

=20 =20 =20
=20
Brian,

=A0If= =A0 we allow a reasonable time for RPs to have fetched the not-yet-valid objects, then when they "turn the crank" to process local= caches after the objects have become valid, the RPs would accept them. But, I've never hear anyone suggest that one ought to try to impose a global, coordinated, RPKI object processing time on all RPs. (That, in itself would be a security concern.) So there may be limits here as to how much the overlap can be reduced by this strategy.

I'm not suggesting polling-based, synchronou= s processing of anything. Clearly, that would be foolish.

While the implementation is up to the implementer(s), I'd ex= pect event-driven scheduling of processing of changes of state. E.g. set up= queues ordered by start or end date/time.

Recall,= this validation is on the RPKI cache validation side. It is outside of the= scope of RPKI-RTR protocol, with the expectation that state changes on the= validation would get pushed to routers.

Pre-publishing means that local validation would merely= need to occur in the overlap window. As long as the new and old objects ha= ve been pushed to the router with any amount of overlap, there is no risk o= f validation failure on received updates.

=A0
=20
Also, are there any other examples you can cite where every network operator is expected to perform some activity, at the same time (relative to UTC), every day, around the world?

NETWORK operator? No. But= there are plenty of other activities driven by certificate expirations, ei= ther passively or actively, which require overlapping (pre-published) objec= ts in order to avoid validation failure. DNSSEC, TLS/SSL, pretty much any c= ertificate-based protocol or security mechanism.

=A0
=A0What is t= he accepted norm for clock sync among all ISPs today, and what processes rely on the extant precision and accuracy of synchronized clocks at all ISPs?

NTP, stratum 3 or better.

BGP neighbors normally expect each others' clocks to be NTP sync= hronized, for reasons of trouble-shooting instances of accidental or malici= ous issues. Logs are useless if their time is not accurate to the milliseco= nd.

(Some peering contracts actually require this.)

Transit relationships typically require accurate measurement of traffic,= both volumetrically =A0and with accurate time. Failure to implement measur= ement and billing using accurate (NTP) time, is a huge liability.

Customers expect to be able to correlate their own measurements with t= heir providers - again, without NTP, this is likely to incur L8/L9 problems= .

Additionally, virtually every network link requi= res accurate line-clock, either supplied by the network, or by the end devi= ces. Nearly all network links and/or routers have line-clocking derived (di= rectly or indirectly) from Stratum-1 sources. This can be achieved in a num= ber of ways, either special NTP feeds, or BITS, or TTL, or via transmission= gear with integrated cesium clocks and/or GPS receivers.

Failure to have synchronized line-clocking is probably = the #1 source of network problems during implementation of peering links. D= rifting clocks will cause errors and/or outages, guaranteed.
=A0
Not being an operator, I really don't know the answers to these questions.

Maybe these are questio= ns you should have asked and gotten the answers to, prior to designing the = RPKI? (Sorry, cheap shot.)

=A0

Anyway, if we were to adopt your suggestion, the benefit might be that the overlap interval need be determined primarily by the time needed to accommodate skew in RPs posting, fetching, and processing RPKI objects.

Overlap = times are only required when there is "live transfer" of INRs, co= rrect? So, mostly (>>99.99999% of the INRs will never have this issue= , as 99.999% won't transfer, and of the transfers, 99.99% won't be = "live") moot.

So, even supposing that such incidents occur, there are= two limits to consider:
(1) The minimum (actual) overlap interva= l between the old and new
(2) The proscribed maximum overlap inte= rval beyond which one or the other should be rejected

So, the discussion would really need to focus on lower = bounds and upper bounds for (2).
Lower bounds impact mandatory ac= tions by cache operators, or alternatively, risk to operators/RPs of RPKI-i= nduced outages

Upper bounds impact the security of the system, and/or window of oppor= tunity for hijacking.
=A0

Rather the overlap interval would be a functio= n of what=A0 folks consider to be a comfortable inter= val to accommodate human processes (and errors) for the INR transfers.<= /p>
=A0

I don=92t know that this time scale as being one that requires carefully coordinated clocks at all RPs, especially since we don't have a candidate overlap interval value on the table. Moreover, since there is an overlap interval in either case, it=92s not immediately clear how hard we should work to reduce it. What overlap interval did you envision?

To parap= hrase Vin Diesel (in pretty much any movie he's been in):=A0

= "Not my problem."

What I envision is, th= e authors of SIDR I-Ds/RFCs proposing intervals, and then discussing/justif= ying them.

Brian=A0

--0016e6dd8d6917b27e04c9ada3ea-- From Sandra.Murphy@sparta.com Sat Sep 15 04:44:04 2012 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 EE07821F84F8 for ; Sat, 15 Sep 2012 04:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIB5DMj7YKQN for ; Sat, 15 Sep 2012 04:44:04 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5E621F8468 for ; Sat, 15 Sep 2012 04:44:03 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q8FBi1Db008570 for ; Sat, 15 Sep 2012 06:44:02 -0500 Received: from kraven.huntsville.ads.sparta.com (kraven.huntsville.sparta.com [157.185.63.137]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q8FBi1X1015887 for ; Sat, 15 Sep 2012 06:44:01 -0500 Received: from CMA-MB003.columbia.ads.sparta.com ([fe80::94ee:521e:9fc9:ebc3]) by kraven.huntsville.ads.sparta.com ([2002:9db9:3f89::9db9:3f89]) with mapi id 14.01.0379.000; Sat, 15 Sep 2012 06:45:14 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: WGLC for draft-ietf-sidr-bgpsec-protocol-05 Thread-Index: Ac2TN5E+gtWY3jVQTo2aIJ20K9PIbg== Date: Sat, 15 Sep 2012 11:45:13 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 11:44:05 -0000 This starts a working group last call for draft-ietf-sidr-bgpsec-protocol-0= 5. The draft is available at http://tools.ietf.org/html/draft-ietf-sidr-bg= psec-protocol-05 and https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpse= c-protocol/ Please review this draft to see if you think it is ready for publication. = Send end comments to the list. =20 The WGLC will end on 29 September 2012. --Sandy, speaking as wg co-chair= From internet-drafts@ietf.org Mon Sep 17 07:04:31 2012 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 F1B8621F8697; Mon, 17 Sep 2012 07:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E9MxdiWZVQd; Mon, 17 Sep 2012 07:04:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4A821F8686; Mon, 17 Sep 2012 07:04:30 -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.34 Message-ID: <20120917140430.12970.80904.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 07:04:30 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-01.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: Mon, 17 Sep 2012 14:04:31 -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 : Definitions of Managed Objects for the RPKI-Router Proto= col Author(s) : Randy Bush Bert Wijnen Keyur Patel Michael Baer Filename : draft-ietf-sidr-rpki-rtr-protocol-mib-01.txt Pages : 21 Date : 2012-09-17 Abstract: 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 RPKI Router protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-rtr-protocol-mib-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Sep 17 09:45:58 2012 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 C5F1821F86FC; Mon, 17 Sep 2012 09:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQzEciRQAZJL; Mon, 17 Sep 2012 09:45:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC4E21F8522; Mon, 17 Sep 2012 09:45:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120917164558.2730.23040.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 09:45:58 -0700 Cc: sidr@ietf.org Subject: [sidr] Last Call: (BGP Prefix Origin Validation) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 16:45:59 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'BGP Prefix Origin Validation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-10-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-pfx-validate/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-pfx-validate/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1569/ From ietf-secretariat@ietf.org Mon Sep 17 12:56:20 2012 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 B54F821E8044; Mon, 17 Sep 2012 12:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4UhwGWYibXz; Mon, 17 Sep 2012 12:56:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3640221E8037; Mon, 17 Sep 2012 12:56:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120917195620.22823.34712.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 12:56:20 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [sidr] IETF Large Interim Meeting - Accommodations Information 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, 17 Sep 2012 19:56:20 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations - Information now available! 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfre= g.py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting ve= nue) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Reservations cut-off date: 21 September 2012 Guest Cancellation: - Reservations may=C2=A0be changed up to 1 week prior to the event with= out penalty. - 50% of reservation value penalty for cancellation less than 14 days a= nd greater than 7 days prior to event. - 80% of reservation value penalty for cancellation less than 7 days an= d greater than 3 days prior to event. - 100% of reservation value penalty for cancellation less than 3 days p= rior to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be= charged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From achi@bbn.com Mon Sep 17 14:37:57 2012 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 4CC3421E804A for ; Mon, 17 Sep 2012 14:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQCT5-+5LJZ6 for ; Mon, 17 Sep 2012 14:37:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B5ABD21E803D for ; Mon, 17 Sep 2012 14:37:56 -0700 (PDT) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:57272 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TDj0i-0002tp-Az; Mon, 17 Sep 2012 17:37:44 -0400 Message-ID: <50579828.6070206@bbn.com> Date: Mon, 17 Sep 2012 17:37:44 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Chi References: <24B20D14B2CD29478C8D5D6E9CBB29F625F5604B@Hermes.columbia.ads.sparta.com>

<503C904F.2040609@bbn.com> <505368F7.5040107@bbn.com> <50536C0B.9000704@bbn.com> In-Reply-To: <50536C0B.9000704@bbn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg Subject: Re: [sidr] Some comments on draft-ietf-sidr-bgpsec-threats-02 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, 17 Sep 2012 21:37:57 -0000 On 9/14/2012 1:40 PM, Andrew Chi wrote: > On 9/14/2012 1:27 PM, Andrew Chi wrote: >> Thanks for your comments, Danny. The bgpsec-threats-03 I just uploaded >> includes a substantial number of edits based on this discussion (mostly >> by Steve, with a couple mine). > > My bad, there might be some version skew as not all edits made it into > -03; expect more text in the next rev. > Never mind, it looks like I got my wires crossed twice. Danny and others, the -03 is ready for your review and any further comments. -Andrew From ietf-secretariat@ietf.org Tue Sep 18 12:01:58 2012 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 6F9D821E8103; Tue, 18 Sep 2012 12:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE2gWA4GHP33; Tue, 18 Sep 2012 12:01:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FA221E80C1; Tue, 18 Sep 2012 12:01:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120918190157.21518.15763.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 12:01:57 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [sidr] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS 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: Tue, 18 Sep 2012 19:01:58 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations - Reservations Cutoff: 21 September 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfreg= .py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting ven= ue) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet but excludes = 5% city tax. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Reservations cut-off date: 21 September 2012 Guest Cancellation: - Reservations may be changed up to 1 week prior to the event without pe= nalty. (You can change, not cancel, the reservation, i.e. change arrival, departure dates or name, up to 1 week without penalty but not cancel the reservation without penalty.) - 50% of reservation value penalty for cancellation less than 14 days an= d greater than 7 days prior to event. If you cancel, not change, the reserv= ation less than 14 days but more than 7 days prior to the event you will be= charged 50% of the total reservation fee. - 80% of reservation value penalty for cancellation less than 7 days and= greater than 3 days prior to event. If you cancel, not change, the reserva= tion less than 7 days prior to the event you will be charged 80% of the tot= al reservation fee. - 100% of reservation value penalty for cancellation less than 3 days pr= ior to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be = charged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From wesley.george@twcable.com Tue Sep 18 13:21:58 2012 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 1BE6921E8042 for ; Tue, 18 Sep 2012 13:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttMF4suy40Vp for ; Tue, 18 Sep 2012 13:21:57 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6951F21E8040 for ; Tue, 18 Sep 2012 13:21:57 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,445,1344225600"; d="scan'208";a="422334172" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 18 Sep 2012 16:21:18 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 18 Sep 2012 16:21:55 -0400 From: "George, Wes" To: "Murphy, Sandra" , "sidr@ietf.org" Date: Tue, 18 Sep 2012 16:21:55 -0400 Thread-Topic: WGLC for draft-ietf-sidr-bgpsec-protocol-05 Thread-Index: Ac2TN5E+gtWY3jVQTo2aIJ20K9PIbgCmdL0w Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59235EFAAF6F@PRVPEXVS15.corp.twcable.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 20:21:58 -0000 Nits: Multiple sections have "musts" and "shoulds" that are not 2119-formatted (l= ower-case) - please ensure that this is intentional Substantial: Any reason why we're using "good" and "not good" for validation state inst= ead of valid/invalid (and unknown)? I'd think that consistency between this= and the language in the origin validation stuff would be helpful unless we= have a specific reason not to use the same language. And I realize that th= ere isn't really an "unknown" status as the result of trying to validate a = BGPSec update, but as far as the implementation is concerned, standard BGP = updates (those without BGPSec) are considered unknown, and it might be good= to explicitly state that as a part of the validation algorithm. I'm awaiting co-author review of the I-D version of the email I wrote about= AS-Migration, and am hoping to have it posted next week sometime. I think = that we need to discuss the considerations from that issue to ensure that n= o changes need to be made in the protocol spec document/design before we pr= ogress this. There's been some discussion of using pcount=3D0 to manage som= e parts of this, but that would have to be covered in the update validation= and origination algorithm if we choose to solve the problem that way. Also= I'm not completely certain that pcount will solve the use case completely.= I'm not opposed to using the draft as a follow-on to the protocol draft (u= pdate it) to handle this specific case, but I'd like to have WG consensus t= hat this is the route we should take rather than incorporating any solution= for this use case into the current document since it is still in draft. Thanks, Wes George > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Murphy, Sandra > Sent: Saturday, September 15, 2012 7:45 AM > To: sidr@ietf.org > Subject: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 > > This starts a working group last call for draft-ietf-sidr-bgpsec- > protocol-05. The draft is available at > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ > > Please review this draft to see if you think it is ready for > publication. Send end comments to the list. > > The WGLC will end on 29 September 2012. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable 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. From Sandra.Murphy@sparta.com Tue Sep 18 14:02:24 2012 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 9E58421E8044 for ; Tue, 18 Sep 2012 14:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ycfd-vFhIsGA for ; Tue, 18 Sep 2012 14:02:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id E7EC821E8041 for ; Tue, 18 Sep 2012 14:02:23 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q8IL2Mg3030746; Tue, 18 Sep 2012 16:02:22 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q8IL2MVV018177; Tue, 18 Sep 2012 16:02:22 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Tue, 18 Sep 2012 17:03:31 -0400 From: "Murphy, Sandra" To: "George, Wes" , "sidr@ietf.org" Thread-Topic: WGLC for draft-ietf-sidr-bgpsec-protocol-05 Thread-Index: Ac2TN5E+gtWY3jVQTo2aIJ20K9PIbgCmdL0wAAPG+j4= Date: Tue, 18 Sep 2012 21:03:30 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F78EE0@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com>, <2671C6CDFBB59E47B64C10B3E0BD59235EFAAF6F@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59235EFAAF6F@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 21:02:24 -0000 >There's been some discussion of using pcount=3D0 to manage =0A= >some parts of this, but that would have to be covered in the =0A= >update validation and origination algorithm if we choose to =0A= >solve the problem that way.=0A= =0A= The use of pcount=3D0 was hoped/expected to require NO changes in the updat= e validation algorithm. If you have discovered places where it would requi= re changes, it will indeed be interesting to see and discuss.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of George, We= s [wesley.george@twcable.com]=0A= Sent: Tuesday, September 18, 2012 4:21 PM=0A= To: Murphy, Sandra; sidr@ietf.org=0A= Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05=0A= =0A= Nits:=0A= Multiple sections have "musts" and "shoulds" that are not 2119-formatted (l= ower-case) - please ensure that this is intentional=0A= =0A= Substantial:=0A= =0A= Any reason why we're using "good" and "not good" for validation state inst= ead of valid/invalid (and unknown)? I'd think that consistency between this= and the language in the origin validation stuff would be helpful unless we= have a specific reason not to use the same language. And I realize that th= ere isn't really an "unknown" status as the result of trying to validate a = BGPSec update, but as far as the implementation is concerned, standard BGP = updates (those without BGPSec) are considered unknown, and it might be good= to explicitly state that as a part of the validation algorithm.=0A= =0A= I'm awaiting co-author review of the I-D version of the email I wrote about= AS-Migration, and am hoping to have it posted next week sometime. I think = that we need to discuss the considerations from that issue to ensure that n= o changes need to be made in the protocol spec document/design before we pr= ogress this. There's been some discussion of using pcount=3D0 to manage som= e parts of this, but that would have to be covered in the update validation= and origination algorithm if we choose to solve the problem that way. Also= I'm not completely certain that pcount will solve the use case completely.= I'm not opposed to using the draft as a follow-on to the protocol draft (u= pdate it) to handle this specific case, but I'd like to have WG consensus t= hat this is the route we should take rather than incorporating any solution= for this use case into the current document since it is still in draft.=0A= =0A= Thanks,=0A= =0A= Wes George=0A= =0A= =0A= > -----Original Message-----=0A= > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of= =0A= > Murphy, Sandra=0A= > Sent: Saturday, September 15, 2012 7:45 AM=0A= > To: sidr@ietf.org=0A= > Subject: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05=0A= >=0A= > This starts a working group last call for draft-ietf-sidr-bgpsec-=0A= > protocol-05. The draft is available at=0A= > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and=0A= > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/=0A= >=0A= > Please review this draft to see if you think it is ready for=0A= > publication. Send end comments to the list.=0A= >=0A= > The WGLC will end on 29 September 2012.=0A= >=0A= > --Sandy, speaking as wg co-chair=0A= > _______________________________________________=0A= > sidr mailing list=0A= > sidr@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sidr=0A= =0A= 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.=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From wesley.george@twcable.com Wed Sep 19 10:15:59 2012 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 3C4E821F86E4 for ; Wed, 19 Sep 2012 10:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6gZ20G4HKe7 for ; Wed, 19 Sep 2012 10:15:58 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 683A621F8526 for ; Wed, 19 Sep 2012 10:15:58 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,450,1344225600"; d="scan'208";a="422834099" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Sep 2012 13:15:16 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 19 Sep 2012 13:15:55 -0400 From: "George, Wes" To: "Murphy, Sandra" , "sidr@ietf.org" Date: Wed, 19 Sep 2012 13:15:54 -0400 Thread-Topic: WGLC for draft-ietf-sidr-bgpsec-protocol-05 Thread-Index: Ac2TN5E+gtWY3jVQTo2aIJ20K9PIbgCmdL0wAAPG+j4AKlMiMA== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59235EFAB75F@PRVPEXVS15.corp.twcable.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com>, <2671C6CDFBB59E47B64C10B3E0BD59235EFAAF6F@PRVPEXVS15.corp.twcable.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F78EE0@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F78EE0@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:15:59 -0000 > From: Murphy, Sandra [mailto:Sandra.Murphy@sparta.com] > Sent: Tuesday, September 18, 2012 5:04 PM > To: George, Wes; sidr@ietf.org > Subject: RE: WGLC for draft-ietf-sidr-bgpsec-protocol-05 > > The use of pcount=3D0 was hoped/expected to require NO changes in the > update validation algorithm. If you have discovered places where it > would require changes, it will indeed be interesting to see and discuss. [WEG] use of pcount=3D0 for AS migration may not require changes to the *al= gorithm* itself, as much as it will simply require discussion of the proces= s for handling pcount=3D0 in the cases where it is used and the neighbor is= not a transparent route-server, since currently that case is discussed spe= cifically in the draft, and there is a specific recommendation that pcount= =3D0 updates be dropped if they didn't come from a known route-server neigh= bor. That said, I'm not convinced it completely solves the problem, as I (hopefu= lly) articulated in my pending draft, and *that* may require algorithm chan= ges. Wes 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. From danny@tcb.net Thu Sep 20 07:42:22 2012 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 CB2A121F87EA for ; Thu, 20 Sep 2012 07:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.716 X-Spam-Level: X-Spam-Status: No, score=-102.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEDN6+9obZ8h for ; Thu, 20 Sep 2012 07:42:22 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 66CE221F8798 for ; Thu, 20 Sep 2012 07:42:22 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0303D3780F4; Thu, 20 Sep 2012 08:42:22 -0600 (MDT) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 20 Sep 2012 08:42:21 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=216.168.230.7; client-port=39166; syn-fingerprint=65535:53:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> Date: Thu, 20 Sep 2012 10:42:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1278) Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 14:42:22 -0000 Sandy,=20 I don't understand how we can WG LC this document when the requirements = document isn't complete, and the requirements document isn't complete = because we're still working out the threats document. =20 Can you explain the logic here? -danny On Sep 15, 2012, at 7:45 AM, Murphy, Sandra wrote: > This starts a working group last call for = draft-ietf-sidr-bgpsec-protocol-05. The draft is available at = http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and = https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >=20 > Please review this draft to see if you think it is ready for = publication. Send end comments to the list. =20 >=20 > The WGLC will end on 29 September 2012. >=20 > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From turners@ieca.com Thu Sep 20 14:47:04 2012 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 EF68E21E809C for ; Thu, 20 Sep 2012 14:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.915 X-Spam-Level: X-Spam-Status: No, score=-100.915 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2JReIUlL3fA for ; Thu, 20 Sep 2012 14:47:03 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [67.18.36.18]) by ietfa.amsl.com (Postfix) with ESMTP id E58E921E8049 for ; Thu, 20 Sep 2012 14:47:02 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 4453122CB6AE8; Thu, 20 Sep 2012 16:47:02 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 3964322CB6AC8 for ; Thu, 20 Sep 2012 16:47:02 -0500 (CDT) Received: from [108.18.174.220] (port=49401 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TEoaK-0000Iu-Pk for sidr@ietf.org; Thu, 20 Sep 2012 16:47:00 -0500 Message-ID: <505B8ED3.8020505@ieca.com> Date: Thu, 20 Sep 2012 17:46:59 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "sidr@ietf.org" References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:49401 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 21:47:04 -0000 Here's my review: One biggie: 1) MUST have an "IANA Considerations" section even if it says "none". But, I think you've Flags and Info Types to register right? Algs are getting done elsewhere ;) One not so biggie but a required formatting thing: 1) s9: If all references are normative, put "Normative" in the section title. A bunch of nits mixed in with requests for additional clarifications (i.e., no biggies): 1) s1: r/must have an/needs an 2) s1: r/does not require/does not need 3) s2: r/[4]that/[4] that 4) s2, bits 2 and 3 as well as the fourth octet: normally this should would be a must any reason it's not a must?: These reserved bits should be set to zero by the sender and ignored by the receiver. 5) s2: contains the following: If there does not exist at least one version of BGPSEC that is supported by both peers in a BGP session, then the use of BGPSEC has not been negotiated. (That is, in such a case, messages containing the BGPSEC_Path_Signatures MUST NOT be sent.) Should this paragraph say something about the BGP NOTIFICATION message with the Error Code 2 (OPEN Message Error) and the OPEN Message Error SubCode 4 (Unsupported Optional Parameter) or is it the SubCode 7 (Unsupported Capability) MUST be returned if both don't support bgpsec? 6) s2, Figure: If the AFI is 2 octets can we do the following: +---------------------------------------+ | AFI | + + | | +---------------------------------------+ so people won't ask what's in the blank line ;) 7) s2: Is there a reference for AFI that we can point to? 8) s2: ? r/speaker must include two/speaker includes two 9) s2: r/it has also advertises/it has also advertised 10) s2: r/(see RFC 4893)./[RFC 4893] - and add a reference. 11) s2: X2 (aligns with earlier sentences) r:/its open message/its BGP OPEN message/ 12) s3: r/new optional/new OPTIONAL 13) High-Level Diagram of the BGPSEC_Path_Signatures Attribute BGPSEC_Path_Signatures figure: I might be reading way to much in to this but I don't want people to get the impression that signature X and Y for alg 1 and 2 are the same. You might draw that conclusion from this: | +-----------------+ +-----------------+ | | | Sig Block 1 | | Sig Block 2 | | | +-----------------+ +-----------------+ | | | Alg Suite 1 | | Alg Suite 2 | | | | SKI X | | SKI X | | | | Sig Length X | | Sig Length X | | | | Signature X | | Signature X | | | | SKI Length Y | | SKI Length Y | | | | SKI Y | | SKI Y | | | | Sig Length Y | | Sig Length Y | | | | Signature Y | | Signature Y | | | | ... | | .... | | | +-----------------+ +-----------------+ | Maybe in Sig Block 1 r/X/X1 and r/Y/Y1 and in Sig block 2 r/X/X2 and r/Y/Y2? 14) s3: If it does include the AS_PATH attribute what happens: That is, update messages that contain the BGPSEC_Path_Signatures attribute MUST NOT contain the AS_PATH attribute. 15) s3.1: Should probably add some ascii art for the flags: +-+-+-+-+-+-+-+-+ |C| Reserved | +-+-+-+-+-+-+-+-+ 16) s3.1: r/These bits MUST be set to zero by the sender. /These bits MUST be set to zero by the sender and ignored by the recipient. 17) s3.1/3.2: Are the editor's notes going to get removed at some point or are we planning on keeping it? 18) s3.3: Probably worth adding the the SKI is copied from the signers certificate and need not be generated. Or, is that implementation specific? 19) s4: In the last paragraph should the "must" be "MUST" x2. It's in a "Note" paragraph so I could see not use MUST, but in that case maybe r/must possess/needs and r/must/needs to. If you use the MUST strike "Note" - I don't think requirements should appear in Note paragraphs (though they often do). 20) s4.1: I'd just strike "Note that" from the those two paragraphs (x3). 21) s4.2: If we're going to keep NOT RECOMMENDED then you need to add it to the conventions. Put it after RECOMMENDED so the nit checker won't barf on it. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [8]. Actually, the RFC editor is going to move the requirements language to the mainbody so might as well do it now. Just slap it in as s1.1. 22) s4.3: MUST instead of must: Members of autonomous system confederations [3] must additionally follow the instructions in this section for processing BGPSEC update messages. 23) s4.3: r/it must remove all /it MUST remove all ? r/confederation members must make /confederation members MUST make ? 24) s5.2: I think there a link missing to how you determine whether the certificate is valid in the following: To do this, consult the valid RPKI end-entity certificate data and look up all valid (AS, SKI, Public Key) triples in which the AS matches the AS number in the corresponding Secure_Path segment. To me that means do the RPKI certificate checks in RFC 6487 as augmented by s3.3 of draft-ietf-sidr-bgpsec-pki-profiles. Probably just adding a pointer to [11] would wfm. To do this, consult the valid RPKI end-entity certificate data and look up all valid (AS, SKI, Public Key) triples, see Section 3.3 of [11], in which the AS matches the AS number in the corresponding Secure_Path segment. or something like that. 25) s6.1, 1st para: r/must/needs to X2 26) s6.1, 2nd para, 2nd sentence: I think the bit about the 'new' algorithm being specified in [12] should be deleted. It doesn't say anything about 'new' algorithm right now and the 3rd paragraph says if and when the new alg is chosen that draft will be updated. 27) s6.1: r/the future the mandatory/the future mandatory That's it for now. spt On 9/15/12 7:45 AM, Murphy, Sandra wrote: > This starts a working group last call for draft-ietf-sidr-bgpsec-protocol-05. The draft is available at http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ > > Please review this draft to see if you think it is ready for publication. Send end comments to the list. > > The WGLC will end on 29 September 2012. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From ietf-secretariat@ietf.org Fri Sep 21 06:17:47 2012 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 1193C21F880C; Fri, 21 Sep 2012 06:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbnflMjE5-O5; Fri, 21 Sep 2012 06:17:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E19421F87E5; Fri, 21 Sep 2012 06:17:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921131746.9793.61038.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 06:17:46 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [sidr] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS 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, 21 Sep 2012 13:17:47 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations - Reservations Cutoff: 21 September 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfreg.= py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting venu= e) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet but excludes 5= % city tax. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Reservations cut-off date: 21 September 2012 Guest Cancellation: - Reservations may be changed up to 1 week prior to the event without pen= alty. (You can change, not cancel, the reservation, i.e. change arrival, departure dates or name, up to 1 week without penalty but not cancel the reservation without penalty.) - 50% of reservation value penalty for cancellation less than 14 days and= greater than 7 days prior to event. If you cancel, not change, the reserva= tion less than 14 days but more than 7 days prior to the event you will be = charged 50% of the total reservation fee. - 80% of reservation value penalty for cancellation less than 7 days and = greater than 3 days prior to event. If you cancel, not change, the reservat= ion less than 7 days prior to the event you will be charged 80% of the tota= l reservation fee. - 100% of reservation value penalty for cancellation less than 3 days pri= or to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be c= harged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From Sandra.Murphy@sparta.com Fri Sep 21 07:31:09 2012 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 0B7F321F85F7 for ; Fri, 21 Sep 2012 07:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIFPkrtHwvfR for ; Fri, 21 Sep 2012 07:31:08 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A01921F8705 for ; Fri, 21 Sep 2012 07:31:08 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q8LEV62i020116 for ; Fri, 21 Sep 2012 09:31:06 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q8LEV508024023 for ; Fri, 21 Sep 2012 09:31:06 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 21 Sep 2012 10:32:12 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: meeting registration for interim 29 Sep 2012 Thread-Index: AQHNmAWr2yH8wM+vf0GlHqPcY6n69w== Date: Fri, 21 Sep 2012 14:32:12 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F7BE53@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] meeting registration for interim 29 Sep 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, 21 Sep 2012 14:31:09 -0000 The IETF Secretariat announced the interim meeting details on Tues. There = is a registration process for this meeting, much the same as for a regular = IETF meeting. See the Secretariat's message http://www.ietf.org/mail-archi= ve/web/sidr/current/msg05067.html. Registration is at http://www.ietf.org/= registration/lim2012/ietfreg.py. You MUST register with the IETF for this = meeting.=0A= =0A= For planning purposes, please do also indicate your plans to attend by send= ing a message to sidr-chairs+reg09292012@ietf.org. In particular, please = do mention if you plan on participating in person or remotely.=0A= =0A= This is for the sidr meeting planning purposes only; it DOES NOT take the p= lace of the IETF registration announced 18 Sep. You MUST register for the= interim meeting with the IETF at http://www.ietf.org/registration/lim2012/= ietfreg.py.=0A= =0A= --Sandy= From Sandra.Murphy@sparta.com Fri Sep 21 07:34:20 2012 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 0B51521F884B for ; Fri, 21 Sep 2012 07:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.566 X-Spam-Level: X-Spam-Status: No, score=-101.566 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, MISSING_SUBJECT=1.762, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8IT24G6vAKc for ; Fri, 21 Sep 2012 07:34:19 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7B021F8705 for ; Fri, 21 Sep 2012 07:34:19 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q8LEYIYM020146 for ; Fri, 21 Sep 2012 09:34:18 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q8LEYIU0024091 for ; Fri, 21 Sep 2012 09:34:18 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 21 Sep 2012 10:35:25 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Index: Ac2YBlYwJMbKAA+IR0u8O4RPhAWXaA== Date: Fri, 21 Sep 2012 14:35:24 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F7BE6B@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] (no subject) 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, 21 Sep 2012 14:34:20 -0000 For remote participation in the past, we have used webex.=0A= =0A= We've heard that there are going to be people expert in Meetecho at the mee= ting in Amsterdam. This might be a good opportunity for us to try Meetecho= as a remote participation tool.=0A= =0A= Is there anyone who has a preference for webex vs Meetecho that would influ= ence the choice?=0A= =0A= (If we try to use Meetecho, webex is likely to serve as a backup.)=0A= =0A= --Sandy= From Sandra.Murphy@sparta.com Fri Sep 21 08:03:42 2012 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 20D4321F8836 for ; Fri, 21 Sep 2012 08:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTTGoWHqAMzJ for ; Fri, 21 Sep 2012 08:03:41 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2CA21F8830 for ; Fri, 21 Sep 2012 08:03:41 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q8LF3bM8020493 for ; Fri, 21 Sep 2012 10:03:37 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q8LF3aoC025027 for ; Fri, 21 Sep 2012 10:03:36 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 21 Sep 2012 11:04:43 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: remote participation possibilities in the interim meeting Thread-Index: AQHNmApuMMNgjvti90GKkSkxH13YsQ== Date: Fri, 21 Sep 2012 15:04:43 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F7BEA5@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] remote participation possibilities in the interim meeting 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, 21 Sep 2012 15:03:42 -0000 Correcting lack of subject.=0A= =0A= And the attached should have been signed off as:=0A= =0A= --Sandy, speaking as co-chair=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com]=0A= Sent: Friday, September 21, 2012 10:35 AM=0A= To: sidr@ietf.org=0A= Subject: [sidr] (no subject)=0A= =0A= For remote participation in the past, we have used webex.=0A= =0A= We've heard that there are going to be people expert in Meetecho at the mee= ting in Amsterdam. This might be a good opportunity for us to try Meetecho= as a remote participation tool.=0A= =0A= Is there anyone who has a preference for webex vs Meetecho that would influ= ence the choice?=0A= =0A= (If we try to use Meetecho, webex is likely to serve as a backup.)=0A= =0A= --Sandy=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From danny@tcb.net Fri Sep 21 15:20:24 2012 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 F2DBF21F8623 for ; Fri, 21 Sep 2012 15:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILYc7CqZ5xhr for ; Fri, 21 Sep 2012 15:20:23 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3E68321F8622 for ; Fri, 21 Sep 2012 15:20:23 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 75F522680A3; Fri, 21 Sep 2012 16:20:22 -0600 (MDT) Received: from dul1dmcphers-m2.home (pool-71-171-124-149.clppva.fios.verizon.net [71.171.124.149]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 21 Sep 2012 16:20:22 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.171.124.149; client-port=51317; syn-fingerprint=65535:48:1:64:M1460,N,W1,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Fri, 21 Sep 2012 18:20:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6D70F892-6696-488D-9EBB-B23C6327C3A3@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> To: Sandra Murphy , Chris Morrow , alexey.melnikov@isode.com X-Mailer: Apple Mail (2.1278) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 22:20:24 -0000 =09 I do not intend to review this document in it's current state and am = confused how we can WG LC it while the threat and [presumably = subsequent] requirements documents are still being developed by the WG.=20= I would like an explanation from the chairs regarding what the intention = is here. -danny On Sep 20, 2012, at 10:42 AM, Danny McPherson wrote: >=20 > Sandy,=20 > I don't understand how we can WG LC this document when the = requirements document isn't complete, and the requirements document = isn't complete because we're still working out the threats document. =20 >=20 > Can you explain the logic here? >=20 > -danny >=20 > On Sep 15, 2012, at 7:45 AM, Murphy, Sandra wrote: >=20 >> This starts a working group last call for = draft-ietf-sidr-bgpsec-protocol-05. The draft is available at = http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and = https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >>=20 >> Please review this draft to see if you think it is ready for = publication. Send end comments to the list. =20 >>=20 >> The WGLC will end on 29 September 2012. >>=20 >> --Sandy, speaking as wg co-chair >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Fri Sep 21 16:14:00 2012 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 C93BA21E8096 for ; Fri, 21 Sep 2012 16:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X4VY3ins81o for ; Fri, 21 Sep 2012 16:14:00 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6E921E8092 for ; Fri, 21 Sep 2012 16:14:00 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so4794699vbb.31 for ; Fri, 21 Sep 2012 16:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cyJLMgluxC5AZCPCmtHs0YjC2X07wlsobQO4ZScYl2s=; b=Io83BGYQzJhvdIllQqGcnJFHU/JvCCrQEgzCwRjZThEaHEAyYdTrTKk3V0e6oLqm6r Tka44QhI58IcGq3UDc/7D9UXI+VEOs3mubA84gySqvcLY+p/Q9zdKupMHo8413n/gfO7 Po1iqeeeosxvEeWc8i/oBhwaHFYi/yI1sEWM6fhGQ3uaZl21s0IOvYWwzUTA5WXS/vrI Gog7CFLyDfUrCDJMGTOv/GcT5DB0ggHHQbDVVKfhM3O75cMhWdNLXrNNVYPytqltn43w RnPHa+SC0uRDDrwJBz4foHMnn38BzhPfEDaZAGEXKFlqzIxnZ826X5LTvMWuocIeKjVl pEPQ== MIME-Version: 1.0 Received: by 10.220.220.203 with SMTP id hz11mr3820605vcb.50.1348269239627; Fri, 21 Sep 2012 16:13:59 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Fri, 21 Sep 2012 16:13:59 -0700 (PDT) In-Reply-To: <6D70F892-6696-488D-9EBB-B23C6327C3A3@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <6D70F892-6696-488D-9EBB-B23C6327C3A3@tcb.net> Date: Fri, 21 Sep 2012 19:13:59 -0400 X-Google-Sender-Auth: UKkYps4Q6CxwMsO13kU0fgXqkfU Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: Chris Morrow , Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 23:14:00 -0000 On Fri, Sep 21, 2012 at 6:20 PM, Danny McPherson wrote: > > I do not intend to review this document in it's current state and am confused how we can WG LC it while the threat and [presumably subsequent] requirements documents are still being developed by the WG. > > I would like an explanation from the chairs regarding what the intention is here. I believe the hope was to stir up some discussion, interest and readers prior to the interim meeting next saturday. As with all WGLC's perhaps this document needs to wait on something else, or isn't ready yet, or has other considerations to deal with... or is ready to fly like a baby birdie. we won't know without some discussion, and I believe there will be a bunch more of that in 8 days time. -chris > On Sep 20, 2012, at 10:42 AM, Danny McPherson wrote: > >> >> Sandy, >> I don't understand how we can WG LC this document when the requirements document isn't complete, and the requirements document isn't complete because we're still working out the threats document. >> >> Can you explain the logic here? >> >> -danny >> >> On Sep 15, 2012, at 7:45 AM, Murphy, Sandra wrote: >> >>> This starts a working group last call for draft-ietf-sidr-bgpsec-protocol-05. The draft is available at http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >>> >>> Please review this draft to see if you think it is ready for publication. Send end comments to the list. >>> >>> The WGLC will end on 29 September 2012. >>> >>> --Sandy, speaking as wg co-chair >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kotikalapudi.sriram@nist.gov Fri Sep 21 16:19:29 2012 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 A1FB021E8092 for ; Fri, 21 Sep 2012 16:19:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx2wz8oQNOiP for ; Fri, 21 Sep 2012 16:19:28 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECA121E805A for ; Fri, 21 Sep 2012 16:19:28 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Fri, 21 Sep 2012 19:19:17 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 21 Sep 2012 19:19:22 -0400 From: "Sriram, Kotikalapudi" To: "sidr wg list (sidr@ietf.org)" Date: Fri, 21 Sep 2012 19:19:21 -0400 Thread-Topic: New Version Notification for draft-sriram-replay-protection-design-discussion-00.txt Thread-Index: Ac2YT4fJC0t5HA0aQJeHmSOjvzko+g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-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: Fri, 21 Sep 2012 23:19:29 -0000 VGhpcyBzdWJtaXNzaW9uIGlzIGFuIGluZm9ybWF0aXZlIGRlc2lnbiBkaXNjdXNzaW9uIGRvY3Vt ZW50IHRoYXQgcHJvdmlkZXMgaW5zaWdodHMgDQppbnRvIHRoZSBvcGVyYXRpb24gb2YgbXVsdGlw bGUgYWx0ZXJuYXRpdmUgbWV0aG9kcyBmb3IgcmVwbGF5LWF0dGFjayBwcm90ZWN0aW9uLiANCldl IGhvcGUgdGhhdCB0aGUgU0lEUiBXRyB3aWxsIHRha2UgdGhlIGluc2lnaHRzIGFuZCB0cmFkZS1v ZmZzIHByZXNlbnRlZCBoZXJlIGFzIGlucHV0IA0KZm9yIGRlY2lkaW5nIG9uIHRoZSBjaG9pY2Ug b2YgYSBtZWNoYW5pc20gZm9yIHByb3RlY3Rpb24gZnJvbSByZXBsYXkgYXR0YWNrcy4NCkl0IGlz IG1lYW50IHRvIGJlIGEgY29tcGFuaW9uIGRvY3VtZW50IHRvIHRoZSBzdGFuZGFyZHMgdHJhY2sg DQpJLUQuLWlldGYtc2lkci1iZ3BzZWMtcm9sbG92ZXIgdGhhdCB3aWxsIHNwZWNpZnkgYSBtZXRo b2QgdG8gYmUgdXNlZCANCndpdGggQkdQU0VDIGZvciByZXBsYXktYXR0YWNrIHByb3RlY3Rpb24u DQoNCkEgc2V0IHNsaWRlcyB3aXRoIGZpZ3VyZXMgdGhhdCBpcyByZWZlcmVuY2VkIGluIHRoZSBk b2N1bWVudCBjYW4gYmUgZm91bmQgYXQ6DQpodHRwOi8vd3d3Lm5pc3QuZ292L2l0bC9hbnRkL3Vw bG9hZC9yZXBsYXktZGlzY3Vzc2lvbi5wZGYgDQoodGhlIGZpZ3VyZXMgYXJlIGhlbHBmdWwgYnV0 IG5vdCBuZWNlc3NhcnkgdG8gcmVhZCB0aGUgZG9jdW1lbnQpLg0KDQpDb21tZW50cyB3ZWxjb21l Lg0KDQpTcmlyYW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50 OiBGcmlkYXksIFNlcHRlbWJlciAyMSwgMjAxMiA3OjAxIFBNDQpUbzogc3JpcmFtLmlldGZAZ21h aWwuY29tDQpDYzogTW9udGdvbWVyeSwgRG91Z2xhczsgU3JpcmFtLCBLb3Rpa2FsYXB1ZGkNClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3JpcmFtLXJlcGxheS1w cm90ZWN0aW9uLWRlc2lnbi1kaXNjdXNzaW9uLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1zcmlyYW0tcmVwbGF5LXByb3RlY3Rpb24tZGVzaWduLWRpc2N1c3Npb24tMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEtvdGlrYWxhcHVkaSBTcmly YW0gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0 LXNyaXJhbS1yZXBsYXktcHJvdGVjdGlvbi1kZXNpZ24tZGlzY3Vzc2lvbg0KUmV2aXNpb246CSAw MA0KVGl0bGU6CQkgRGVzaWduIERpc2N1c3Npb24gYW5kIENvbXBhcmlzb24gb2YgUmVwbGF5LUF0 dGFjayBQcm90ZWN0aW9uIE1lY2hhbmlzbXMgZm9yIEJHUFNFQw0KQ3JlYXRpb24gZGF0ZToJIDIw MTItMDktMjINCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2Vz OiAxNw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zcmlyYW0tcmVwbGF5LXByb3RlY3Rpb24tZGVzaWduLWRpc2N1c3Npb24tMDAudHh0 DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt c3JpcmFtLXJlcGxheS1wcm90ZWN0aW9uLWRlc2lnbi1kaXNjdXNzaW9uDQpIdG1saXplZDogICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNyaXJhbS1yZXBsYXktcHJvdGVj dGlvbi1kZXNpZ24tZGlzY3Vzc2lvbi0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhlIEJHUFNFQyBw cm90b2NvbCByZXF1aXJlcyBhIG1ldGhvZCBmb3IgcHJvdGVjdGlvbiBmcm9tIHJlcGxheQ0KICAg YXR0YWNrcywgYXQgbGVhc3QgdG8gY29udHJvbCB0aGUgd2luZG93IG9mIGV4cG9zdXJlLiAgSW4g dGhlIGNvbnRleHQNCiAgIG9mIEJHUFNFQywgYSByZXBsYXkgYXR0YWNrIG9jY3VycyB3aGVuIGFu IGFkdmVyc2FyeSBzdXBwcmVzc2VzIGENCiAgIHByZWZpeCB3aXRoZHJhd2FsIChpbXBsaWNpdCBv ciBleHBsaWNpdCkgb3IgcmVwbGF5cyBhIHByZXZpb3VzbHkNCiAgIHJlY2VpdmVkIEJHUFNFQyBh bm5vdW5jZW1lbnQgZm9yIGEgcHJlZml4IHRoYXQgaGFzIHNpbmNlIGJlZW4NCiAgIHdpdGhkcmF3 bi4gIFRoaXMgaW5mb3JtYXRpb25hbCBkb2N1bWVudCBwcm92aWRlcyBkZXNpZ24gZGlzY3Vzc2lv bg0KICAgYW5kIGNvbXBhcmlzb24gb2YgbXVsdGlwbGUgYWx0ZXJuYXRpdmUgcmVwbGF5LWF0dGFj ayBwcm90ZWN0aW9uDQogICBtZWNoYW5pc21zIHdlaWdoaW5nIHRoZWlyIHByb3MgYW5kIGNvbnMu ICBJdCBpcyBtZWFudCB0byBiZSBhDQogICBjb21wYW5pb24gZG9jdW1lbnQgdG8gdGhlIHN0YW5k YXJkcyB0cmFjayBJLUQuLWlldGYtc2lkci1iZ3BzZWMtDQogICByb2xsb3ZlciB0aGF0IHdpbGwg c3BlY2lmeSBhIG1ldGhvZCB0byBiZSB1c2VkIHdpdGggQkdQU0VDIGZvcg0KICAgcmVwbGF5LWF0 dGFjayBwcm90ZWN0aW9uLg0KDQo= From Sandra.Murphy@sparta.com Fri Sep 21 16:26:43 2012 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 477DB21E8037 for ; Fri, 21 Sep 2012 16:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBtRJYkKNpNv for ; Fri, 21 Sep 2012 16:26:42 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF5121E8034 for ; Fri, 21 Sep 2012 16:26:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q8LNQdaB025026; Fri, 21 Sep 2012 18:26:39 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q8LNQcGW004318; Fri, 21 Sep 2012 18:26:39 -0500 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%21]) with mapi id 14.01.0355.002; Fri, 21 Sep 2012 19:27:45 -0400 From: "Murphy, Sandra" To: Danny McPherson , Chris Morrow , "alexey.melnikov@isode.com" Thread-Topic: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 Thread-Index: Ac2TN5E+gtWY3jVQTo2aIJ20K9PIbgEKBiOAAEJH9ID//8xkPg== Date: Fri, 21 Sep 2012 23:27:45 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F7BFF7@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> , <6D70F892-6696-488D-9EBB-B23C6327C3A3@tcb.net> In-Reply-To: <6D70F892-6696-488D-9EBB-B23C6327C3A3@tcb.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org wg" Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 23:26:43 -0000 The protocol, threats and requirements documents are definitely tied togeth= er and will progress together. The three documents have been in the workin= g group for the same length of time, so you'd think that they, being so tie= d, would have had equal attention and be equally mature.=0A= =0A= On the non-process, reality side of things: The newest protocol draft came= out on 7 Sep and I asked the working group to "look at this draft right aw= ay" because it would be discussed at the interim meeting. After eight days= with no comments, a wglc seemed a good idea. Sad that our lives need a wg= lc to produce participation, but it is what it is.=0A= =0A= --Sandy= From brian.peter.dickson@gmail.com Fri Sep 21 17:18:08 2012 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 748E221F84F0 for ; Fri, 21 Sep 2012 17:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYDmJj78uqFB for ; Fri, 21 Sep 2012 17:18:07 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 103D721F84EF for ; Fri, 21 Sep 2012 17:18:03 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1206764wgb.13 for ; Fri, 21 Sep 2012 17:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TcidZSw3tkqMlxN9zQ/RdwK+yDpzeMXiTfQQTS2lNrI=; b=NJXJsA3VdGphNv6aDZeijeUyXVNW09ctiiKcpIrsZAmhPQeED+6evQ6e+4VOyjRcjY ottGaeoVSjKe9+ysqPKs9/zqeE6ES9fi42jTOyA44iCO/RRg4q3brl6+dS4Gj8rpAzEK zM8lXW4IHrh8ow7ZaaAtpVr2IiDlhFpTtDdmnYhAfbZkhmOaTfMEGEFn2iyFBEzsi3if aAzaa7N/iZPZRAS0DuVl+7P9iTGI0q09yKBm6jvUswTNDB8CIIhLLXvuE8Oml14LTSfw RZBPN0yLMa3YoF/XXuRpizmPHh6UFtTOB06t6yhhEUZjdds/0TArjplNpOiXIlxLig/v fQnQ== MIME-Version: 1.0 Received: by 10.180.100.37 with SMTP id ev5mr59612wib.5.1348273082918; Fri, 21 Sep 2012 17:18:02 -0700 (PDT) Received: by 10.223.145.133 with HTTP; Fri, 21 Sep 2012 17:18:02 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <6D70F892-6696-488D-9EBB-B23C6327C3A3@tcb.net> Date: Fri, 21 Sep 2012 20:18:02 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d041826d62ae6ed04ca3f4a28 Cc: Chris Morrow , "sidr@ietf.org wg" , Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 00:18:08 -0000 --f46d041826d62ae6ed04ca3f4a28 Content-Type: text/plain; charset=ISO-8859-1 IMHO, attempting to generate discussion on a document by doing WGLC, is completely bass-ackwards. I don't believe it is at all appropriate to WGLC a document prior to substantive review and maturity. I.e. the chairs should ask FIRST, informally, if folks think we're ready to WGLC, and wait a bit for answers. The bar for saying "no" should be fairly low, and only in the absence of lots of positive "hum" should WGLC proceed. I would suggest the chairs review the processes adopted in other (more mature) WGs, such as dnsext, for better processes and procedures. E.g. commitment of >=5 reviewers to review, prior to WGLC. This excludes authors, of course, from the review process. It has worked very well there, IMHO. Given that, as Danny notes, the entire content of -protocol depends on -requirements, which itself depends on -threats, I have to concur with him - "NO" to proceeding at this time. So, to be clear: - I don't think that, even if it were otherwise ready, that it wold be appropriate to WGLC the -protocol doc - I do not believe the -protocol doc is ready to go (independent of the gating issue) There are several areas that are not adequately settled, especially in the pcount=0 and transition areas. Consider this a formal request to bounce this document out of WGLC. It would be fine to discuss on the interim meeting, and there does not need to be a WGLC just to get discussion. Brian On Fri, Sep 21, 2012 at 7:13 PM, Christopher Morrow wrote: > On Fri, Sep 21, 2012 at 6:20 PM, Danny McPherson wrote: > > > > I do not intend to review this document in it's current state and am > confused how we can WG LC it while the threat and [presumably subsequent] > requirements documents are still being developed by the WG. > > > > I would like an explanation from the chairs regarding what the intention > is here. > > I believe the hope was to stir up some discussion, interest and > readers prior to the interim meeting next saturday. As with all WGLC's > perhaps this document needs to wait on something else, or isn't ready > yet, or has other considerations to deal with... or is ready to fly > like a baby birdie. we won't know without some discussion, and I > believe there will be a bunch more of that in 8 days time. > > -chris > > > On Sep 20, 2012, at 10:42 AM, Danny McPherson wrote: > > > >> > >> Sandy, > >> I don't understand how we can WG LC this document when the requirements > document isn't complete, and the requirements document isn't complete > because we're still working out the threats document. > >> > >> Can you explain the logic here? > >> > >> -danny > >> > >> On Sep 15, 2012, at 7:45 AM, Murphy, Sandra wrote: > >> > >>> This starts a working group last call for > draft-ietf-sidr-bgpsec-protocol-05. The draft is available at > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ > >>> > >>> Please review this draft to see if you think it is ready for > publication. Send end comments to the list. > >>> > >>> The WGLC will end on 29 September 2012. > >>> > >>> --Sandy, speaking as wg co-chair > >>> _______________________________________________ > >>> sidr mailing list > >>> sidr@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sidr > >> > >> _______________________________________________ > >> sidr mailing list > >> sidr@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidr > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --f46d041826d62ae6ed04ca3f4a28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable IMHO, attempting to generate discussion on a document by doing WGLC, is com= pletely bass-ackwards.

I don't believe it is at all appropriate = to WGLC a document prior to substantive review and maturity.

I.e. th= e chairs should ask FIRST, informally, if folks think we're ready to WG= LC, and wait a bit for answers.
The bar for saying "no" should be fairly low, and only in the abs= ence of lots of positive "hum" should WGLC proceed.

I woul= d suggest the chairs review the processes adopted in other (more mature) WG= s, such as dnsext, for better processes and procedures.
E.g. commitment of >=3D5 reviewers to review, prior to WGLC. This exclud= es authors, of course, from the review process.
It has worked very well = there, IMHO.

Given that, as Danny notes, the entire content of -prot= ocol depends on -requirements, which itself depends on -threats, I have to = concur with him - "NO" to proceeding at this time.

So, to be clear:
- I don't think that, even if it were otherwise= ready, that it wold be appropriate to WGLC the -protocol doc
- I do not= believe the -protocol doc is ready to go (independent of the gating issue)=

There are several areas that are not adequately settled, especially in = the pcount=3D0 and transition areas.

Consider this a formal request = to bounce this document out of WGLC.

It would be fine to discuss on = the interim meeting, and there does not need to be a WGLC just to get discu= ssion.

Brian

On Fri, Sep 21, 2012 at 7:13 PM= , Christopher Morrow <morrowc.lists@gmail.com> wrote:<= br>

On Fri, Sep 21, 2012 at 6:20 PM, Danny McPherson <danny@tcb.net> wrote:
>
> I do not intend to review this document in it's current state and = am confused how we can WG LC it while the threat and [presumably subsequent= ] requirements documents are still being developed by the WG.
>
> I would like an explanation from the chairs regarding what the intenti= on is here.

I believe the hope was to stir up some discussion, interest and
readers prior to the interim meeting next saturday. As with all WGLC's<= br> perhaps this document needs to wait on something else, or isn't ready yet, or has other considerations to deal with... or is ready to fly
like a baby birdie. we won't know without some discussion, and I
believe there will be a bunch more of that in 8 days time.

-chris

> On Sep 20, 2012, at 10:42 AM, Danny McPherson wrote:
>
>>
>> Sandy,
>> I don't understand how we can WG LC this document when the req= uirements document isn't complete, and the requirements document isn= 9;t complete because we're still working out the threats document.
>>
>> Can you explain the logic here?
>>
>> -danny
>>
>> On Sep 15, 2012, at 7:45 AM, Murphy, Sandra wrote:
>>
>>> This starts a working group last call for draft-ietf-sidr-bgps= ec-protocol-05. =A0The draft is available at http://tools.= ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ >>>
>>> Please review this draft to see if you think it is ready for p= ublication. =A0Send end comments to the list.
>>>
>>> The WGLC will end on 29 September 2012.
>>>
>>> --Sandy, speaking as wg co-chair
>>> _______________________________________________
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--f46d041826d62ae6ed04ca3f4a28-- From christopher.morrow@gmail.com Fri Sep 21 17:20:39 2012 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 E6BAF21F853F for ; Fri, 21 Sep 2012 17:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lBD1qYRERwb for ; Fri, 21 Sep 2012 17:20:38 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E270E21F84F2 for ; Fri, 21 Sep 2012 17:20:37 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4916132vcb.31 for ; Fri, 21 Sep 2012 17:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Dzbii+l6SJ492elBEulyIbkwCtIR2HdgMCAxr7BGzlA=; b=TiVrH9UcMWSyJ6UDW4RO7fySx+stOaU9hTWGBx6Zn/SyvdyNrLjROC8eLqiAO6SPaf Ibe5AAvhU8wmzxYnY2YhAE7mI69RwnPneNgvoH/cwVngW9c1hNmbunA6ulEiFP1/aeDL T184bh3x4jZ4d9t7XN5UZAkn7Vw5n1BFUWZpIntHdI690Xu48JChXn2EJNRRrF3fGJcO DGRnRHsyKZMKU0EYnfipU6IyKqsY/NZSN3WAftiaLwfHiyAOtFPO1OJHrFlsrEPajPRs p3AhgEjhN+GdhBI9brhEuAs9sIan3mkrj6cPbOe9Chb4XRsiyi5SxImdxez2dPfWc+dH oeow== MIME-Version: 1.0 Received: by 10.220.240.18 with SMTP id ky18mr3865292vcb.54.1348273233106; Fri, 21 Sep 2012 17:20:33 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Fri, 21 Sep 2012 17:20:33 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <6D70F892-6696-488D-9EBB-B23C6327C3A3@tcb.net>

Date: Fri, 21 Sep 2012 20:20:33 -0400 X-Google-Sender-Auth: hSRhT_Jn3EKhK4GTNeBq3bDSFM8 Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: Chris Morrow , "sidr@ietf.org wg" , Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 00:20:39 -0000 On Fri, Sep 21, 2012 at 8:18 PM, Brian Dickson wrote: > I don't believe it is at all appropriate to WGLC a document prior to > substantive review and maturity. it's on it's 5th revision, with substantive discussion along the way... From brian.peter.dickson@gmail.com Fri Sep 21 17:24:47 2012 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 E157221E8049 for ; Fri, 21 Sep 2012 17:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.741 X-Spam-Level: X-Spam-Status: No, score=-3.741 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx62AM4ZXpjB for ; Fri, 21 Sep 2012 17:24:47 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6780E21E8053 for ; Fri, 21 Sep 2012 17:24:43 -0700 (PDT) Received: by weyx48 with SMTP id x48so2456456wey.31 for ; Fri, 21 Sep 2012 17:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vXQmJ33P9XUQQA1HNKAUjQbfGNeXQVAwYuWll5dfVAw=; b=Jd5ikt1t2ZqleC6gCkVprylImGMopGLnf6zkzXFnaF5oJ5qbb96/thGhj0vjP60qfA 9JZ+mREZ5nqZY06SpIkia8xcry4Bhk736iUNKIIqH/BMREe1BisglDrScLlPRgFwltuu MRm8PSzJivyf/MlwOwS0oCtaJc+CrCrDY4tiphVhsEYaU/Rm8Gk7QtF59d3ssnMA/EUb AG9Z7B2qNaJIO3epgd/hlkNIRjgZ4dQLkumiPRQykSZPoOvo9KMUm9GXPlaQ49qX5uks SxCDNR6O+Pd97F+317n9f8DQYhwuM+Hr3CIqQP2zLSNw4vg7XUH0VBVWZLr/W6TgWou5 pySA== MIME-Version: 1.0 Received: by 10.216.145.88 with SMTP id o66mr3792816wej.169.1348273477568; Fri, 21 Sep 2012 17:24:37 -0700 (PDT) Received: by 10.223.145.133 with HTTP; Fri, 21 Sep 2012 17:24:37 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F7BFF7@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <6D70F892-6696-488D-9EBB-B23C6327C3A3@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F625F7BFF7@Hermes.columbia.ads.sparta.com> Date: Fri, 21 Sep 2012 20:24:37 -0400 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=0016e6d646a6b0c85304ca3f6168 Cc: Chris Morrow , "sidr@ietf.org wg" Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 00:24:48 -0000 --0016e6d646a6b0c85304ca3f6168 Content-Type: text/plain; charset=ISO-8859-1 With all due respect, Sandy, what are you smoking? If there is a dependency that goes "A, then B, then C", then CLEARLY "C" needs to bake longer than "B", and "B" longer than "A". Maybe not strictly relative elapsed time, but certainly there would need to be a post-A significant time before "B" finishes. Ditto for B->C. In most cases, effort on C and B is likely to be potentially wasted prior to A, and worse, it leads to work on "C" and "B" resulting in wrong-headed decisions concerning "A", precisely *because* of the work on "B" and "C" would otherwise be wasted. The history of tech is littered with (frequently DOD subcontractors') wasted efforts that end up bloating projects or putting them into dead-end paths. ADA, anyone? Let's look at the reality, rather than the theory, when evaluating documents' progress and status, please. Especially when one is "chair" of a WG. I don't think putting any sort of time pressure is appropriate when we are talking about a critical infrastructure security protocol. Brian On Fri, Sep 21, 2012 at 7:27 PM, Murphy, Sandra wrote: > The protocol, threats and requirements documents are definitely tied > together and will progress together. The three documents have been in the > working group for the same length of time, so you'd think that they, being > so tied, would have had equal attention and be equally mature. > > On the non-process, reality side of things: The newest protocol draft > came out on 7 Sep and I asked the working group to "look at this draft > right away" because it would be discussed at the interim meeting. After > eight days with no comments, a wglc seemed a good idea. Sad that our lives > need a wglc to produce participation, but it is what it is. > > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --0016e6d646a6b0c85304ca3f6168 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable With all due respect, Sandy, what are you smoking?

If there is a dep= endency that goes "A, then B, then C", then CLEARLY "C"= needs to bake longer than "B", and "B" longer than &qu= ot;A". Maybe not strictly relative elapsed time, but certainly there w= ould need to be a post-A significant time before "B" finishes. Di= tto for B->C.

In most cases, effort on C and B is likely to be potentially wasted pri= or to A, and worse, it leads to work on "C" and "B" res= ulting in wrong-headed decisions concerning "A", precisely *becau= se* of the work on "B" and "C" would otherwise be waste= d.

The history of tech is littered with (frequently DOD subcontractors'= ;) wasted efforts that end up bloating projects or putting them into dead-e= nd paths. ADA, anyone?

Let's look at the reality, rather than th= e theory, when evaluating documents' progress and status, please. Espec= ially when one is "chair" of a WG.

I don't think putting any sort of time pressure is appropriate when= we are talking about a critical infrastructure security protocol.

B= rian

On Fri, Sep 21, 2012 at 7:27= PM, Murphy, Sandra <Sandra.Murphy@sparta.com> wrote:=

The protocol, threats and requirements docum= ents are definitely tied together and will progress together. =A0The three = documents have been in the working group for the same length of time, so yo= u'd think that they, being so tied, would have had equal attention and = be equally mature.

On the non-process, reality side of things: =A0The newest protocol draft ca= me out on 7 Sep and I asked the working group to "look at this draft r= ight away" because it would be discussed at the interim meeting. =A0Af= ter eight days with no comments, a wglc seemed a good idea. =A0Sad that our= lives need a wglc to produce participation, but it is what it is.

--Sandy

___________________________________= ____________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--0016e6d646a6b0c85304ca3f6168-- From brian.peter.dickson@gmail.com Fri Sep 21 17:28:49 2012 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 ACB3921F8501 for ; Fri, 21 Sep 2012 17:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5-X3KLg5UpG for ; Fri, 21 Sep 2012 17:28:48 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2443721F84D7 for ; Fri, 21 Sep 2012 17:28:47 -0700 (PDT) Received: by wibcb5 with SMTP id cb5so2069194wib.1 for ; Fri, 21 Sep 2012 17:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1eO9gHw30Q4DHGJ3xyR051x0avp9zMZKTjgZrDm72sk=; b=jafkOxeZ4dhNWeuFmnxX5y+hiKysrvvxvRpDGXLHujUiHIIvuAEirOaSh6sMzif8pd aQw2A59G+jdjhGvWxCEk7p77NLy863jSm/NECBFFSFZddr6SOlRmSfkboRlfYZdOOJE0 jsxJrpyAyKMrd1woscRbbLB6g+O9MFtKUnJMYl0Cpi6GDadxISIJ5iZzIf7CgYIedf/6 KpGuflvc+8qh8t1SL3So4ghipZ3oEFW3n4uVXaWy7hoWftskFMzMi3ax26vWKTTaPRo3 QzscKDdAZ0fuG4w14OKrIUsnhjrFEa2PzFH0kGMCLweDtlimsaays0Pmg+KRlnQmqnmT oU+Q== MIME-Version: 1.0 Received: by 10.216.145.88 with SMTP id o66mr3797383wej.169.1348273727276; Fri, 21 Sep 2012 17:28:47 -0700 (PDT) Received: by 10.223.145.133 with HTTP; Fri, 21 Sep 2012 17:28:47 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.com> <6D70F892-6696-488D-9EBB-B23C6327C3A3@tcb.net>

Date: Fri, 21 Sep 2012 20:28:47 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=0016e6d646a69308bb04ca3f7024 Cc: Chris Morrow , "sidr@ietf.org wg" , Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 00:28:49 -0000 --0016e6d646a69308bb04ca3f7024 Content-Type: text/plain; charset=ISO-8859-1 Discussion yes, revisions, not so much, and in particular, -threats is not done. WGLC is inappropriate prior to -threats completion in WG. Plus, -threats has not adequately accommodated criticism. Doing s/BGPSEC/ANOTHER_NAME/g does not qualify as "substantive", IMHO. There was no review post -05 publication. Review prior to that point is not relevant, IMHO. At a minimum, those whose comments were in theory addressed, should be given the opportunity, each and every one of them, to speak up and be heard. It is the job of the chairs to track issues and confirm with commentators that revisions are adequate. I am not a chair. Brian On Fri, Sep 21, 2012 at 8:20 PM, Christopher Morrow wrote: > On Fri, Sep 21, 2012 at 8:18 PM, Brian Dickson > wrote: > > > I don't believe it is at all appropriate to WGLC a document prior to > > substantive review and maturity. > > it's on it's 5th revision, with substantive discussion along the way... > --0016e6d646a69308bb04ca3f7024 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Discussion yes, revisions, not so much, and in particular, -threats is not = done. WGLC is inappropriate prior to -threats completion in WG.

Plus= , -threats has not adequately accommodated criticism. Doing s/BGPSEC/ANOTHE= R_NAME/g does not qualify as "substantive", IMHO.

There was no review post -05 publication. Review prior to that point is= not relevant, IMHO.

At a minimum, those whose comments were in theo= ry addressed, should be given the opportunity, each and every one of them, = to speak up and be heard.

It is the job of the chairs to track issues and confirm with commentato= rs that revisions are adequate.

I am not a chair.

Brian

On Fri, Sep 21, 2012 at 8:20 PM, Christopher M= orrow <morrowc.lists@gmail.com> wrote:

On Fri, Sep 21, 2012 at 8:= 18 PM, Brian Dickson
<brian.peter.dickson@gm= ail.com> wrote:

> I don't believe it is at all appropriate to WGLC a document prior = to
> substantive review and maturity.

it's on it's 5th revision, with substantive discussion along = the way...

--0016e6d646a69308bb04ca3f7024-- From randy@psg.com Fri Sep 21 17:32:08 2012 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 1B43621F853D for ; Fri, 21 Sep 2012 17:32:08 -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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4fatijcamq5 for ; Fri, 21 Sep 2012 17:32:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B38D621F84FA for ; Fri, 21 Sep 2012 17:32:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TFDde-000PoZ-Ed; Sat, 22 Sep 2012 00:32:06 +0000 Date: Sat, 22 Sep 2012 09:32:05 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F7BFF7@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F706AF@CMA-MB003.columbia.ads.sparta.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 Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 00:32:08 -0000 > The newest protocol draft came out on 7 Sep and I asked the working > group to "look at this draft right away" because it would be discussed > at the interim meeting. After eight days with no comments, a wglc > seemed a good idea. Sad that our lives need a wglc to produce > participation, but it is what it is. i note that you got one actual reivew, which is good. the only other stuff i have seen is people telling the chairs what the process should be, embarrassing. i promise a detailed re-read in the next days. randy From christopher.morrow@gmail.com Fri Sep 21 17:52:02 2012 Return-Path: