RE: Conformance with ICANN Redemption Grace Periods

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Protocol extension if needed for ICANN registries.  It's certainly not a
general-purpose feature that should be added to the core protocol.

-Scott-

> -----Original Message-----
> From: Ram Mohan [mailto:rmohan@afilias.info]
> Sent: Thursday, October 17, 2002 5:20 PM
> To: ietf-provreg@cafax.se
> Subject: Conformance with ICANN Redemption Grace Periods
> 
> 
> Scott,
> As you may have noticed, in the Bucharest ICANN meeting, the 
> Board resolved
> to have registries adopt the proposed Redemption Grace Period
> (http://www.icann.org/bucharest/redemption-topic.htm) policy.
> 
> Embedded in the document are the following, which may have an 
> impact on EPP.
> I forward to provreg to determine if any of these need to be 
> factored into
> our thinking.  (New capability, may or may not need a 
> command; new domain
> status if agreed to, will require some remapping)
> 
> -ram
> >>Creation of New "RESTORE" Capability
> 
> The Technical Steering Group proposes the creation of a new "RESTORE"
> capability that can be provided by a registry to registrars 
> via one or more
> of the following methods: a modification of the 
> registry/registrar protocol,
> an administration website, a fax service, or a telephone service. The
> RESTORE capability will only affect names that are within the 
> Delete Pending
> Period. In other words, all RESTORE requests for names not in 
> the Delete
> Pending Period will be ignored.
> 
> >> Registry Transparency Requirements for Deleted Names
> 
> In order to ensure fairness to all registrants and 
> registrars, the Technical
> Steering Group proposes that deleted and restored names 
> should be handled as
> openly and transparently as feasible. Original registrants 
> and those wishing
> to be "next in line" to register a name that is being deleted 
> should be able
> to tell when a name was deleted and when it will be "returned 
> to the pool"
> of names available for registration.
> 
> Accordingly, under the proposal, a registry Whois check on a 
> name that is
> within the Delete Pending Period would return at least the following
> information:
> 
>   Domain Name: example.com
>   Sponsoring Registrar: exampleregistrar.com
>   Domain Status: DELETE PENDING PERIOD
>   Delete Requested: 31-may-2002
> 
> ----- Original Message -----
> From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
> To: <ietf-provreg@cafax.se>
> Sent: Thursday, October 17, 2002 2:51 PM
> Subject: FW: IESG Review Comments
> 
> 
> > Forwarded with Patrik's permission for the benefit of the 
> WG, these are
> the
> > comments received back from the IESG's review of the EPP 
> documents.  I'll
> be
> > editing the documents shortly to incorporate the IESG's 
> suggested text
> > changes and others received from the WG over the last few weeks.
> >
> > I've added annotations to number the comments in this 
> message.  We're
> still
> > trying to obtain clarifications for comments 6 and 8.
> >
> > -Scott-
> >
> > -----Original Message-----
> > From: Patrik Fältström [mailto:paf@cisco.com]
> > Sent: Tuesday, October 15, 2002 5:17 AM
> > To: Scott Hollenbeck
> > Cc: Jaap Akkerhuis; Edward Lewis
> > Subject: Discuss on epp documents
> >
> >
> > [Ooopss....I forgot to click on "send", this window has been sitting
> > for a week in my laptop behind the window with the mailboxes....I AM
> > SORRY]
> >
> >  From IESG:
> >
> > Steve:
> >
> > 1.
> >   > <draft-ietf-provreg-epp-07.txt>  Do we put mailing list 
> names and
> > URLs in RFCs?
> >
> > 2.
> >   I'd like a stronger Security Considerations section, 
> though I think
> >   it can be added by an RFC Editor note. In particular, I want it to
> >   say that EPP "MUST NOT be used over a transport mechanism 
> that does
> >   not provide confidentiality", or "All transport mappings for EPP
> >   MUST provide confidentiality and integrity". (I think 
> that that's what
> >   they intend, but it's not clear enough.)
> >
> > 3.
> >   > <draft-ietf-provreg-epp-domain-05.txt>
> >   What is an "authorization token"? It's not defined, but 
> it's mandated
> >   by the security considerations. (I suspect it's what is 
> discussed in
> >   2.6, but it doesn't use the same words.)
> >
> > 4.
> >   > <draft-ietf-provreg-epp-contact-05.txt>
> >   What is an "authorization token"? It's not defined, but 
> it's mandated
> >   by the security considerations. (I suspect it's what is 
> discussed in
> >   2.8, but it doesn't use the same words.)
> >
> > 5.
> >   > <draft-ietf-provreg-epp-tcp-05.txt>
> >   The Security Considerations section seems to require TLS client
> >   authentication, which in turn requires client 
> certificates. Is this
> >   intended? If so, great! But in that case, what is the 
> fate, if any,
> >   of the EPP login/password command? Is it still needed? Is it still
> >   legal? What does it mean? Must the identities agree? (The 
> requirement
> >   for server authentication is excellent, but some more 
> text mentioning
> >   the need to validate the certificate chain is probably a 
> good idea.)
> >
> > Scott:
> > note:
> >
> > 6.
> > draft-ietf-provreg-epp-07.txt sec 2.1
> >        I think it would be good to be a bit more strict about
> >        the use of congestion control protocols specifically require
> >        the use of an IETF standards track congestion control
> >        protocol such as TCP or SCTP
> >
> >        i.e. change the following line:
> >        - The transport mapping MUST manage congestion.
> >
> >        to:
> >        - The transport mapping MUST only be to an IETF standards
> >        track congestion control protocol such as TCP or SCTP.
> >
> > Bert: document: draft-ietf-provreg-epp-07.txt
> >
> > 7.
> > page 12, example greeting has:
> >
> >      S: <svID>Example EPP server epp.example.tld</svID>
> >
> > in an example greeting. Did we not decide at some point
> > that examples should be of the form: epp.example.org ??
> >
> > Patrik answers:
> >
> >  > We should follow RFC 2606 which states that:
> >  >
> >  > 3. Reserved Example Second Level Domain Names
> >  >
> >  > The Internet Assigned Numbers Authority (IANA) also
> >  > currently has the
> >  > following second level domain names reserved which can be used as
> >  > examples.
> >  >
> >  > example.com
> >  > example.net
> >  > example.org
> >  >
> >  >
> >  > I.e. using "tld" as an example top level domain is wrong.
> >  >
> >  > Can you please have a discuss on this?
> >  >
> > Sure... it seemed more like a small nit to me, in any event, such a
> > discuss I think can be cleared with a RFC-Editor note.
> >
> > Randy:
> >
> > 8.
> > why do domain/contact/.. not have granular information 
> about privacy?
> >
>