Conformance with ICANN Redemption Grace Periods

["Ram Mohan" <rmohan@afilias.info>]

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?
>