IETF Logo Mail Archive

Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00

Tim Bruijnzeels <tim@ripe.net> Mon, 15 July 2013 14:53 UTC

Return-Path: <tim@ripe.net>
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 AA88E11E8131 for <sidr@ietfa.amsl.com>; Mon, 15 Jul 2013 07:53:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao3ISTx65wVw for <sidr@ietfa.amsl.com>; Mon, 15 Jul 2013 07:53:48 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADCE11E8118 for <sidr@ietf.org>; Mon, 15 Jul 2013 07:53:44 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1Uyk9l-00071c-KD; Mon, 15 Jul 2013 16:53:43 +0200
Received: from puppy.ripe.net ([193.0.1.230] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1Uyk9l-0006Zn-Ge; Mon, 15 Jul 2013 16:53:41 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <51E40536.6080808@bbn.com>
Date: Mon, 15 Jul 2013 16:53:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C894960-E4B4-4162-BCC5-D01EFA9EABFD@ripe.net>
References: <24B20D14B2CD29478C8D5D6E9CBB29F6749A84D9@CVA-MB001.centreville.ads.sparta.com> <m2r4f3whgd.wl%randy@psg.com> <95789E5C-80B0-4307-9471-C116DB8219A5@arin.net> <51E2481E.7060103@gmail.com> <B14D9B95-4F0C-4B75-BE3D-20BAD39F48F8@arin.net> <51E40536.6080808@bbn.com>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1508)
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130715 clean
X-RIPE-Spam-Level: ---
X-RIPE-Spam-Report: Spam Total Points: -3.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07197907f7c98e318638b1c1d8f931e11d57
Cc: sidr@ietf.org
Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 14:53:55 -0000

On Jul 15, 2013, at 4:20 PM, Stephen Kent <kent@bbn.com> wrote:

> I agree with John's characterization of the issue being address by this I-D.
> 
> I support this I-D because I don't want the lack of a simple capability like this to
> stand in the way of RPKI deployment in ARIN.
> 

+1

As engineer I don't like having this here. On the other hand legal folk are now insisting that we include a message of the day pointing to terms and conditions in our rsync server. That considered, using a standard way to point to a CPS that includes all this information seems a lot more elegant, and appropriate.

If the document is accepted I think more discussion is needed though on what the RP can do with this information.

Currently our validator accepts, and ignores this. I am not convinced that it is good idea to bother operators with every CPS we encounter. And I am not sure what an operator is supposed to be able to do with this information.. choose to accept/reject all certificates and objects for a certain CPS? I am not in favour of text that is too restrictive.. that said, if this is accepted then I think that discussion needs to be resolved.

Tim

v2.28.0 | Report a Bug | By Email | System Status