Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-00.txt

Patrick Mevzek <pm@dotandco.com> Mon, 18 May 2015 14:17 UTC

Return-Path: <patrick@shaktot.patoche.org>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2863A1A8ACE for <eppext@ietfa.amsl.com>; Mon, 18 May 2015 07:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.388
X-Spam-Level: *
X-Spam-Status: No, score=1.388 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_66=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqCBvWKCilZH for <eppext@ietfa.amsl.com>; Mon, 18 May 2015 07:17:37 -0700 (PDT)
Received: from shaktot.patoche.org (shaktot.patoche.org [212.85.152.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50E11A8AB9 for <eppext@ietf.org>; Mon, 18 May 2015 07:16:02 -0700 (PDT)
Received: from shaktot.patoche.org (localhost.localdomain [127.0.0.1]) by shaktot.patoche.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t4IEFqKW000543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 May 2015 16:15:52 +0200
Received: (from patrick@localhost) by shaktot.patoche.org (8.14.3/8.14.3/Submit) id t4IEFqmH000542; Mon, 18 May 2015 16:15:52 +0200
Date: Mon, 18 May 2015 16:15:51 +0200
From: Patrick Mevzek <pm@dotandco.com>
To: eppext@ietf.org
Message-ID: <20150518141551.GA10658@home.patoche.org>
References: <20150504162934440371144@cnnic.cn> <20150517001433.GA26237@home.patoche.org> <2015051812000406846958@cnnic.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2015051812000406846958@cnnic.cn>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: shaktot_dot_patoche_dot_org on 212.85.152.86
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/a11fmtYGsmTOj2EVNf459_ut1lY>
Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-00.txt
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 May 2015 14:17:39 -0000

Linlin Zhou <zhoulinlin@cnnic.cn> 2015-05-18 05:59
> > - there should be some explanations on what happens for a domain
> > name
> > with a reseller that get transfered to another registrar (where
> > obvisouly the given previous reseller would not exist). Will the
> > reseller info be automatically removed after the transfer
> > finishes?
> >
> If a domain is transfered to a new registrar, the registrar or
> reseller will do a domian update operation to update the
> corresponding reseller information.

Not necessarily possible, if the new registrar does not use at all the
resellerext EPP extension… and I doubt that a registry could mandate
all registrars to use it.
And even if he uses the extension, what mandates him to update the 
domain? Technically, nothing. If the reseller info is displayed 
somewhere (whois, escrow, etc…), then a wrong information would be 
shown.

This is the same problem as a transfer with secDNS information.

So it will probably be a registry policy, but we may have some 
scenarios where the reseller info will be kept through the transfer, 
and other scenarios where it will be wiped out (and if the new 
registrar wants to specify its own reseller he will do a domain:update
afterwards).
But maybe the draft should have a sentence about that.

2 other points while I'm at it and implementing your other draft:
- I will post comments later on your other drafts
- I believe there should be somewhere an explanation on how your two 
  drafts articulate between themselves. My understanding is that 
registrars will create reseller objets with the reseller mapping I-D,
and then create domains with the resellerID for the reseller object
they created previsouly. If that is not what is intended, some
clarifications should be added somewhere.


-- 
Patrick Mevzek