Re: [NSI-RRP] FW: I-D ACTION:draft-hollenbeck-grrp-reqs-03.txt

From: Eric Schaetzlein (eric@schlund.de)
Date: Tue Aug 29 2000 - 14:17:55 EDT

  • Next message: Hollenbeck, Scott: "RE: [NSI-RRP] FW: I-D ACTION:draft-hollenbeck-grrp-reqs-03.txt"

    On 2000/08/29, Hollenbeck, Scott wrote:
    > Eric,
    >
    > If we assume that "company.tld" and "subsidiary.tld" are available and that
    > the Registry is authoritative for ".tld"...
    >
    > 1. Company registers "company.tld" through Registrar X: This works.
    >
    > 2. Subsidiary registers "subsidiary.tld" through Registrar Y: This works.
    >
    > 3. Registrar Y can register "product.tld" for either company or subsidiary
    > if it's available. This works.
    >
    > 4. Registrar Y can register "ns1.subsidiary.tld". This works.
    >
    > 5. Why should registrar Y be able to register a name server
    > (ns1.subsidiary.company.tld) in a domain (company.tld) sponsored by
    > Registrar X?

    Well, simply because they are to register the domain "product.tld"
    and cannot do so until the nameserver is registered.
    I mean, from a reality standpoint, why should Registrar Y depend on Registrar X
    to depend the still-available domain "product.tld"?

    > Registrar X can register "ns1.subsidiary.company.tld" because
    > it sponsors the registration of "company.tld". Subsidiary can (and I
    > believe should) register the name server through Registrar X.

    But this is a heck more complicated to explain to a customer if you are Registrar Y.

    > This seems a lot less uglier to me than allowing multiple registrars to
    > manage the name servers in an SLD like "company.tld".

    Why don't we try to sum up all possibilities that could happen in that case?
    Basically, a nameserver is owned by the zone-c or the nameserver operator, and not
    the Registrar. And nameservers are shared between lots of different domains, in many
    different Registries and between different Registrars.
    That's where the gRRP model - IMHO - does not catch the concept of a nameserver
    in the real world.

    >
    > Scott Hollenbeck
    > Network Solutions, Inc. Registry
    >
    > -----Original Message-----
    > From: Eric Schaetzlein [mailto:eric@schlund.de]
    > Sent: Tuesday, August 29, 2000 11:16 AM
    > To: Hollenbeck, Scott
    > Cc: rrp@nsiregistry.com
    > Subject: Re: [NSI-RRP] FW: I-D ACTION:draft-hollenbeck-grrp-reqs-03.txt
    >
    >
    > On 2000/08/29, Hollenbeck, Scott wrote:
    > > Eric,
    > >
    > > Thanks for the clarification.
    > >
    > > I don't like the idea of severing the relationship between a name server
    > and
    > > the server's parent domain when the registry is authoritative for the
    > > server's and domain's TLD. I can see some ugly situations where one
    > > registrar is responsible for example.com and another is responsible for
    > > ns1.example.com. If example.com needs to be deleted by one registrar what
    > > happens to ns1.example.com, whose registrar might not want to cooperate?
    >
    > But on the other hand, this is quite ugly too:
    >
    > Registrar X Registrar Y
    > |- company.tld |- subsidiary.tld
    >
    > The mothercompany registers with Registrar X.
    > The subsidiary registers with Registrar Y.
    > Registrar Y is to register (product.tld, ns1.subsidiary.company.tld,
    > ns1.subsidiary.tld)
    > This fails, even if product.tld is available.
    >
    > The point is, if a domain name is available, any registrar should be able to
    > register it.
    > ---------
    > See http://www.nsiregistry.com/maillist/rrp/
    > for message archives and subscription management information.

    Mit freundlichen Gruessen

    Eric Schaetzlein

    --
    Eric Schaetzlein		Schlund + Partner AG	Tel:  +49 721 91374 50
    Leiter Domain Services		Erbprinzenstr. 4-12	Fax:  +49 721 91374 20
    				D-76133 Karlsruhe	Mail:  eric@schlund.de
    

    --------- See http://www.nsiregistry.com/maillist/rrp/ for message archives and subscription management information.



    This archive was generated by hypermail 2b29 : Tue Aug 29 2000 - 14:18:20 EDT