[ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 13 April 2009 12:51 UTC

Return-Path: <owner-ietf-provreg@cafax.se>
X-Original-To: ietfarch-provreg-archive@core3.amsl.com
Delivered-To: ietfarch-provreg-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730873A6D78 for <ietfarch-provreg-archive@core3.amsl.com>; Mon, 13 Apr 2009 05:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level:
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujXgTxZB1vei for <ietfarch-provreg-archive@core3.amsl.com>; Mon, 13 Apr 2009 05:51:07 -0700 (PDT)
Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id CAF643A6B07 for <provreg-archive@ietf.org>; Mon, 13 Apr 2009 05:51:06 -0700 (PDT)
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n3DCbTDp025580 for <ietf-provreg-outgoing@nic.cafax.se>; Mon, 13 Apr 2009 14:37:29 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3DCbS0T023967 for ietf-provreg-outgoing; Mon, 13 Apr 2009 14:37:29 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n3DCbSB2015312 for <ietf-provreg@cafax.se>; Mon, 13 Apr 2009 14:37:28 +0200 (MEST)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n3DCSJ7g019719 for <ietf-provreg@cafax.se>; Mon, 13 Apr 2009 08:28:19 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 13:37:26 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Date: Mon, 13 Apr 2009 08:37:25 -0400
Message-ID: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AD Review Comments: draft-hollenbeck-rfc4934bis-00
Thread-Index: Acm8NJmzYO33/ZvpQjq+pbJCVGlx1Q==
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: ietf-provreg@cafax.se
X-OriginalArrivalTime: 13 Apr 2009 12:37:26.0254 (UTC) FILETIME=[99DDC8E0:01C9BC34]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n3DCbSB2015295
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk

Some feedback from Alexey on the new TLS Usage Profile text in 4934bis.
I now need implementer feedback.

>>  A client MUST close the associated TLS connection if the connection
>>  is not expected to deliver any EPP messages later.  It MUST send a
>>  TLS close_notify alert before closing the connection.
>>
> As an implementor I remain skeptical that existing implementations do 
> that. At least I doubt many IMAP or SMTP servers do that. So maybe you

> should check how existing EPP implementations handle connection
closure.

What are you implementers doing?

> I think the text about how to extract and verify domain information
from 
> X.509 certificates is still missing from your draft. I think that what

> Chris wanted you to do and I am in agreement with him on this.
> I see some text on this in Section 8, but I think it is a bit too
short. 
> Check section 2.2.1 of draft-ietf-sieve-managesieve-09.txt. It
probably 
> contains 80% of what EPP should use.

Comments, please.  I've sent a note to Alexey pushing back on this
because (in my opinion) this puts mandates on client and server
certificate validation behavior that don't affect EPP interoperability.
If I'm wrong, I'd prefer to cite an existing mature reference instead of
cloning text from an unapproved I-D.  Does anybody know of one?

-Scott-