Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
RFC 3915

Note: This ballot was opened for revision 04 and is now closed.

(Ted Hardie) Yes

(Harald Alvestrand) No Objection

Comment (2004-05-27)
No email
send info
Reviewed by Kent Crispin, Gen-ART

This draft is in quite good shape, and I was hard pressed to find 
anything to complain about.  One small nit.  The draft says:

  More detailed information describing the information required to be
  provided in a restore report is available from ICANN.

I spent 5 minutes trying to find that information on the ICANN web
site, and I couldn't find the authoritative description.  It should be
referenced, if it exists.

I don't see this as a reason to hold up publication, however.

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) (was Discuss) No Objection

Comment (2004-05-27)
No email
send info
I cleared the my Discuss - Ted and Scott are writing an RFC Editor note to better
clarify "As with other domains" to tighten the coupling to EPP's mechanims.  My
Discuss note was:

  "As with other domain object updates, redemption of a deleted domain
  object MUST be restricted to the sponsoring client."

The method of accomplishing this is actually left looser than we usually
do in protocols, even though there's a MUST implement mechanism in
RFC 3730 - why isn't a login with SASL actually shown (since this is a MUST
implement as part of 3730), and then there could be alternatives beyond this?

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

Comment (2004-05-27)
No email
send info
Reference:
   [11]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         2279, January 1998.
Should probably be updated to point to RFC3629 instead of 2279 ??

(Alex Zinin) No Objection

(Scott Hollenbeck) Recuse