IETF Logo Mail Archive

Re: [ire] New version (4) of the spec and new draft on DNRD (1)

"Hollenbeck, Scott" <shollenbeck@verisign.com> Fri, 14 December 2012 18:57 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: ire@ietfa.amsl.com
Delivered-To: ire@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B155721F8AD0 for <ire@ietfa.amsl.com>; Fri, 14 Dec 2012 10:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.254
X-Spam-Level:
X-Spam-Status: No, score=-6.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 hsegEeH9tbwU for <ire@ietfa.amsl.com>; Fri, 14 Dec 2012 10:57:50 -0800 (PST)
Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9A221F8AA9 for <ire@ietf.org>; Fri, 14 Dec 2012 10:57:48 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUMt2rITPur+mbQfVv6Gim78d/Iefp/W1@postini.com; Fri, 14 Dec 2012 10:57:50 PST
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qBEIvlB6029578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Dec 2012 13:57:47 -0500
Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 13:57:47 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: Francisco Obispo <fobispo@isc.org>
Thread-Topic: [ire] New version (4) of the spec and new draft on DNRD (1)
Thread-Index: AQHN2imRi6zvW6WRSs6IEhQPZFwOd5gYo9sw
Date: Fri, 14 Dec 2012 18:57:46 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D6C87D1@BRN1WNEXMBX02.vcorp.ad.vrsn.com>
References: <C41D7AF7FCECBE44940E9477E8E70D7A0D7437F6@BRN1WNEXMBX02.vcorp.ad.vrsn.com> <148D81EC-63B1-4C71-B630-B50686BE82B4@isc.org> <831693C2CDA2E849A7D7A712B24E257F0D6C873C@BRN1WNEXMBX02.vcorp.ad.vrsn.com> <52028659-1C67-4D62-9927-354A2A02F751@isc.org>
In-Reply-To: <52028659-1C67-4D62-9927-354A2A02F751@isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ire@ietf.org" <ire@ietf.org>
Subject: Re: [ire] New version (4) of the spec and new draft on DNRD (1)
X-BeenThere: ire@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <ire.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ire>, <mailto:ire-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ire>
List-Post: <mailto:ire@ietf.org>
List-Help: <mailto:ire-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ire>, <mailto:ire-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2012 18:57:50 -0000

> -----Original Message-----
> From: Francisco Obispo [mailto:fobispo@isc.org]
> Sent: Friday, December 14, 2012 1:34 PM
> To: Hollenbeck, Scott
> Cc: Gould, James; ire@ietf.org
> Subject: Re: [ire] New version (4) of the spec and new draft on DNRD
> (1)
> 
> 
> On Dec 14, 2012, at 10:29 AM, "Hollenbeck, Scott"
> <shollenbeck@verisign.com> wrote:
> 
> > The EPP fields are intended to capture the value of the <clID>
> element provided with the <login> command of the client (in the context
> of a client-server relationship) that performed the create or update
> action. The clID, crID, and upID values don't tell you anything about
> the client's role.
> 
> So clID -> Sposoring Client, which means: a user that was able to login
> via an EPP <login> command, which is consider to sponsor the domain
> name right?

EPP doesn't refer to clients as "users" since that word has anthropomorphic meaning and clients don't have to be human. It does say this about the "sponsor" word (in section 1.1 of RFC 5730):

"A protocol client that is authorized to manage an existing object is described as a "sponsoring" client throughout this document."

Scott

v2.23.0 | Report a Bug | By Email