TIME CHANGE: meeting announcement: 22 December 2004

[James M Galvin]

    [[ MY APOLOGIES!  I had this all ready to go on Monday but I guess I
       got distracted at the moment I was going to send it and then I
       simply forgot I hadn't sent it.  ]]


This meeting will be held at the special time of:

    1130 Los Angeles, San Francisco
    1230 Phoenix
    1430 Washington
    19300 UTC
    2030 Netherlands
    2130 Israel
    0430 Tokyo (the next day)
    0630 Melbourne (the next day)

    (* don't see your timezone listed?  let me know and I'll add it. *)


The teleconference logistics, which do not change from week to week, are
as follows.

    USA Toll Free Number: +1 888-221-7341
    USA Toll Number:      +1 973-935-2305

    Passcode: 599786
    Leader:   JAMES GALVIN

    Jabber:   dnssec-deployment at conference.jabber.org
	      This is a public room.

    If your phone does not have a mute capability, you can use "*6" to
    mute and unmute your connection.

    DIAL OUT:
        1. ISC SIP Bridge - contact me for SIP identifiers


DRAFT AGENDA


  -- Update on .SE activities


  -- DNSSEC Deployment Roadmap

     Please review the document and come prepared with comments,
     suggestions, issues, or whatever for discussion.

     We have one comment from Ed Lewis, distributed to the mailing list
     on November 16.  Note that his comment refers to diagrams found in
     Part of the roadmap.  For your convenience, here is the complete
     text of his comment.


	 I made this comment at the lunch, but I felt the need to repeat
	 it in email.  I don't think that the categorizations of
	 registries into "root, gTLD, ccTLD, and enterprise" is complete
	 nor entirely accurate.  E.g., we are a gTLD and a ccTLD, as
	 well as is Verisign and others.

	 Besides missing the arpa domain, there are also sTLDs to
	 include now too.  And enterprises may be subdivided into those
	 that run DNS for themselves and those running it for others.
	 E.g., ISP's may run DNS for their space and "CNAME hack"
	 delegations to some customers.

	 I suspect that the categorizations are more along the lines of
	 registries that use the shared registry model, those that have
	 other fixed relationships, those that have direct registrant
	 access.  This categorization might better capture the impact of
	 business models on deployment.

	 Or maybe categorizing by those that use EPP, RRP, web portals,
	 or SMTP as a public interface.  This captures one aspect of a
	 technical impact of deployment.  There are other technical
	 impacts - whether the registry generates zones batch or
	 interactive, whether the registry outsources DNS operations,
	 etc.

	 I'm not sure whether a technical categorization is tractable,
	 but I figured I lay it out as an alternative to a business
	 categorization.