home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / can / domain / 9 < prev    next >
Encoding:
Text File  |  1993-01-02  |  4.4 KB  |  100 lines
  1. Newsgroups: can.domain
  2. Path: sparky!uunet!uunet.ca!smd
  3. From: smd@uunet.ca (Sean Doran)
  4. Subject: Re: can.domain
  5. References: <Bzy58H.Fux@uunet.ca> <381@unbc.edu> <C07r77.4ut@uunet.ca> <C081rA.Eu3@wimsey.bc.ca>
  6. Organization: UUNET Canada
  7. Date: Sat, 2 Jan 1993 15:43:17 GMT
  8. Message-ID: <C08H06.6xB@uunet.ca>
  9. Distribution: can
  10. Lines: 88
  11.  
  12. sl@wimsey.bc.ca (Stuart Lynne) writes:
  13.  
  14. >In article <C07r77.4ut@uunet.ca> smd@uunet.ca (Sean Doran) writes:
  15. >>lyndon@unbc.edu (Lyndon Nerenberg) writes:
  16.  
  17. >You can't get registered in .com or .us unless someone is willing to
  18. >support an MX for you.
  19.  
  20. The only requirement for registration in .COM is that you provide at
  21. least two nameservers to be listed in the root zone.  These are
  22. often checked for an SOA record these days.  The NIC doesn't care
  23. about MX records or getting mail to work, nor should they.
  24.  
  25. The US zone requires an MXer to be listed for subdomains that are
  26. directly managed by the US zone coordinators.  They only require a
  27. pair of nameservers to be listed and running for delegated domains
  28. (see RFC 1386, which does some things well, and others badly).
  29.  
  30. I don't like the idea of "artificial domains -- i.e., ones that won't
  31. work on the Internet because they aren't in the DNS -- any more than
  32. you do, but I do like the idea of domain place-holders being made
  33. available for organizations that are planning on future connectivity.
  34.  
  35. There are also organizations which, because of geography or politics,
  36. simply cannot find an Internet mail-forwarder.  There is at least one
  37. such subdomain in CA, and mail to them will work from pathalias-based
  38. UUCP-land, at least.  
  39.  
  40. >Explain why. The mechanism seems to work to produce standards for the IETF.
  41.  
  42. Have you read any IETF mailing lists lately?  The standards process is
  43. far from quick, and one could argue for hours about how good the
  44. standards produced really are.  
  45.  
  46. >But policy should be created by the users.
  47.  
  48. Possibly.  But then we would have to fight about who the users are,
  49. and who among them gets to define policy.  The issues are not simple.
  50.  
  51. >Yes. But we need a policy statement (i.e. guidelines) that are based on
  52. >the users requirements.
  53.  
  54. Again, the requirements of which users?  A policy statement based on
  55. the needs of UUNET would be different from a policy statement based on
  56. the needs of a small UUCP site, ONet, NetNorth or Wimsey.  Someone has
  57. to take policy decisions at some point.  If we have a committee of
  58. everyone (much like the current system) we could duke it out in
  59. private for eons.  If we involve everyone who reads USENET, we could
  60. duke it out in public for eons, and end up with something much like
  61. news.groups.
  62.  
  63. My feeling is that public comment is valuable, and being able to get
  64. our needs across to the Czar is a good thing.  However, our needs
  65. should not drive the Czar's activities, nor bind her or him to an
  66. inflexible position that might cause problems for someone else.
  67.  
  68. Can.domain is perhaps a useful vehicle for public bickering.  A
  69. semipublic/semiprivate mailing list might be useful for some more
  70. detailed (and less heated) discussions about policy.  However, neither
  71. one nor the other should "vote", and neither one nor the other should
  72. be considered a policy-making body.  Policy should be made by the
  73. person who controls the nameservers for the top-level-domain. 
  74.  
  75. If the policy that person generates is bad, then we know who to blame,
  76. and can work at cutting that person off at the knees ("off with a
  77. head").  Such is responsible government. :)
  78.  
  79. At the moment, it's difficult to tell whether to blame John Demco as
  80. the coordinator for CA-DOM for various gripes and problems, or the
  81. committee (and certain members of it) for presenting him with policy
  82. decisions he might not have made on his own.  Given the secretiveness
  83. of the process and of the membership of the committee and
  84. mailing-list, it is hardly surprising that people are frustrated.
  85.  
  86. I have yet to understand why the historical records of the
  87. deliberations of the CA-DOM committee haven't been made public.  Could
  88. it be that some of the members of the committee might be a little
  89. embarassed by some of their comments in the past?  Or is such openness
  90. something they would welcome?
  91.  
  92. Perhaps we could start off with an explanation (for the benefit of
  93. people who don't know) of how the CA-DOM committee makes decisions,
  94. the draft copy of the new CA-DOM rules, and an introduction (again for
  95. the benefit of people who don't know who they are, which is
  96. practically everyone) of the members of the committee, and the
  97. official observers.  
  98.  
  99.     Sean.
  100.