Re: [ire] A question on upRr field

Christopher Browne <cbbrowne@afilias.info> Wed, 20 March 2013 15:35 UTC

Return-Path: <cbbrowne@afilias.info>
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 7D79B21F8C93 for <ire@ietfa.amsl.com>; Wed, 20 Mar 2013 08:35:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.178
X-Spam-Level:
X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_SUB_RAND_LETTRS4=0.799]
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 HTZaat+iYvur for <ire@ietfa.amsl.com>; Wed, 20 Mar 2013 08:35:30 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id DFD1821F8C7D for <ire@ietf.org>; Wed, 20 Mar 2013 08:35:29 -0700 (PDT)
Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from <cbbrowne@afilias.info>) id 1UIL33-0003mp-4d for ire@ietf.org; Wed, 20 Mar 2013 15:35:29 +0000
Received: from mail-we0-f200.google.com ([74.125.82.200]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <cbbrowne@afilias.info>) id 1UIL33-0000Wp-4C for ire@ietf.org; Wed, 20 Mar 2013 15:35:29 +0000
Received: by mail-we0-f200.google.com with SMTP id d7so2681203wer.3 for <ire@ietf.org>; Wed, 20 Mar 2013 08:35:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=GyA0sehROzj4oOc9aVCQU8Bdi9x0kn/EuB840sBrRlM=; b=U6V0Ju/AAxpnaZ7gX0S8F+eACnjsNYBBFvW7CZelGm83ndXz/NUy5xU6D6HqrDL8N1 984dku0ZSwmOdx85hXWPiI/kdKKjh1Nh/6qtAJhDkerzlcaPzp5dKVQztKcuQNC/7bap Xdrjecd2PuHK3guJ8l9wvUjK2x5+9G3zR9Q8eXB2IcwQ3XDCw9mbxTALCrlob7pLJZR8 oZ0whm7qtzB8HSPzt2CQGRZ1ueTMLPpY4pXtlek2U2AOfEmfPrLeUz/9jaSfYJnhkVk2 8uCRXzeSJLbiGarQdOs/W7AHhnahhsNLA6/0H4lrq6uARBiH1lmmwMZK2h8JT2FrrW2d ugQw==
X-Received: by 10.194.173.167 with SMTP id bl7mr11412538wjc.50.1363793723127; Wed, 20 Mar 2013 08:35:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.173.167 with SMTP id bl7mr11412403wjc.50.1363793721711; Wed, 20 Mar 2013 08:35:21 -0700 (PDT)
Received: by 10.194.165.200 with HTTP; Wed, 20 Mar 2013 08:35:21 -0700 (PDT)
In-Reply-To: <7DF76593066AD744A79617DBD0D8A0F210C6FA8A@wds-exc1.okna.nominet.org.uk>
References: <7DF76593066AD744A79617DBD0D8A0F210C6FA8A@wds-exc1.okna.nominet.org.uk>
Date: Wed, 20 Mar 2013 11:35:21 -0400
Message-ID: <CANfbgbb5rySQKi975EiaKTUT6Fk-iQXa-f5k=anOdjy7Ks=G7A@mail.gmail.com>
From: Christopher Browne <cbbrowne@afilias.info>
To: Adrian Cho <Adrian.Cho@nominet.org.uk>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQm9U0Y7F7bdrjNN4SNGrCLH2Zf1JQVG2g1q/TLEaQiUL7C7nMVEFx+BWvctZ0YY7jUsNvZSDq2abgyZhW472Y6DFteMOiUyPfhlOLQH0Dn75HwvMTcAvU/EHyy8hzVLTDOr+4Dr
Cc: "ire@ietf.org" <ire@ietf.org>
Subject: Re: [ire] A question on upRr field
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: Wed, 20 Mar 2013 15:35:30 -0000

On Wed, Mar 20, 2013 at 7:32 AM, Adrian Cho <Adrian.Cho@nominet.org.uk> wrote:
> Hello Gustavo
>
> On Page 7 of
>
> http://www.ietf.org/id/draft-arias-noguchi-dnrd-objects-mapping-02.txt
>
> It says
> An OPTIONAL <upRr> element that contains the identifier of the
>       registrar that last updated the domain name object.  This element
>       MUST NOT be present if the domain has never been modified.
>
> Question
>
> What happens if the domain object is updated internally by the registry? For instance, if a customer service agent put
>
> serverUpdateProhibited status
>
> on a domain.
>
> How do we get this last piece of "change history" into escrow file??
>
> Thanks in advance

This is a place where the terminology of EPP is a bit peculiar.

If you look at RFC 5730, you see that the set of RFCs are characterized
as being motivated for use in registry/registrar interactions.

However, it is curious to observe that the word "registrar" never occurs
in RFCs 5731, 5732, 5733, or 5734.  The word "client" is used instead,
and it just struck me that it is possible that the IRE specifications
should consider the same usage.

Everyone involved in domain registrations understands and generally
expects that the interactions are mostly between registries and
registrars.  However, there do tend to be some other sorts of clients
present that do work that needs to be tracked, so that the set of
clients includes:

a) Registrars, obviously,
b) Registry operators, which could include and require distinguishing between
   "legal operators" and "technical operators"
c) A naming authority such as ICANN or IANA

For the specific case you're talking about, I don't see it as unreasonable
that the escrow would be expected to capture that a change might be made
by the registry operator, which implies that <upRr> mustn't strictly be
required to be a registrar.

In the latest draft, IRE uses the term "registrar" 218 times, and I wonder
if most of those shouldn't be replaced with the term "client."  There is a
fairly different use made of the term "client" in the IRE draft, so
it definitely isn't as simple as merely substituting "client" for "registrar."

At any rate, I don't think all of the "registrars" identified in IRE are
necessarily actually registrars, and the document probably needs
some modification to indicate the possibility of other kinds of parties
being responsible for data in a registry.