home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rwhois / rwhois-minutes-95dec.txt < prev    next >
Encoding:
Text File  |  1996-06-03  |  3.7 KB  |  78 lines
  1. CURRENT MEETING REPORT
  2.  
  3.  
  4. Minutes of the RWhois Operational Development Working Group(RWHOIS)
  5.  
  6. Reported by Mark Kosters, InterNIC
  7.  
  8.  
  9. Agenda
  10.   o Release Status
  11.   o What's required to make rwhois operational
  12.      - Current Implementation shortfalls
  13.      - less dated InterNIC data dumps
  14.      - Planned Steps
  15.   o Changes to 1.0 of the protocol
  16.   o Security Concerns
  17.   o Linkage of the Guardian Object
  18.   o Integration of rwhois/whois++
  19.   o Plea for volunteers
  20.  
  21. Scott Williamson started the session with a review of the current releases.
  22. The client is in beta 2, the server is in beta 6 and is available
  23. at ftp://rs.internic.net/pub/rwhois. As for new developments, it was
  24. mentioned that a Tk implementation of the client is development and Scott 
  25. Williamson is building a Java server. As a FYI, the RWhois development
  26. web page has moved to Thomson Technology under the URL 
  27. http://dmeister.labs.thomtech.com/rwhois.html.  It was recommended by the 
  28. group that a document ought to be created that demonstrated the 
  29. usefulness/potential of rwhois.
  30.  
  31. Discussion ensued about what is required to make rwhois move from an
  32. experimental status to operational. First, the implementation needs to be
  33. made more reliable and have more documentation. It was noted that many
  34. sites still have the example bogus data in their current operational
  35. server set and the InterNIC needs to make updates to the rwhois data
  36. set on a more frequent basis. Additionally the secondary code needs
  37. to be integrated into the server. It was mentioned that OCLC may
  38. be interested in funding this activity.
  39.  
  40. Questions where brought up about the frequency of pulling up data from
  41. leaf servers and pruning that data so it only comes from one level down. It 
  42. was agreed the we need to have operational experience before coming to
  43. a conclusion. It was noted that the soa record needs to be emphasized
  44. more to make pullups work.
  45.  
  46. Changes to 1.0 of the protocol then mentioned. First is the addition
  47. of a capabilities id in the banner to increase efficiency. _OLD and
  48. _NEW tags need to be added to the -register directive and the
  49. identifier from the -register directive needs to be dropped. Additionally,
  50. rwhois no longer is required to conform rfc954 requirements.
  51.  
  52. Security Concerns  were next with clear-text passwd and pgp implementations
  53. being worked on. It was suggested to look at the results of the CAT Working
  54. group. Another alternative is the guardian object that is under development
  55. by the InterNIC is being looked at as a possible drop in. The current
  56. draft is ftp://rs.internic.net/policy/internic/internic-gen-1.txt. The key
  57. to this document is that a guardian only person to modify the particular 
  58. record. There are two types of registering asymmetric - after the fact,
  59. or symmetric - during the time of registration. Discussion ensued on
  60. type type of enforcement ought to be placed on the pgp keyrings for
  61. degrees of trust. One idea was to have a attribute for what keyserver 
  62. you should extract the key from and to follow the work of the pgpix working
  63. group. Another idea as integrating the dns security working group's output. 
  64.  
  65. Integration of the whois++ and rwhois protocols where then mentioned
  66. and there has been discussion of using the strengths of both and integrating
  67. clients to use both protocols. Scott Williamson is looking into this.
  68.  
  69. Randy Conrad then brought up using the idea of distributing handles via
  70. DNS. Another alternative as placing postfixes on the handles themselves
  71. (ie handle-cc, handle-ripe, or handle (internic)). 
  72.  
  73. The working group then concluded with a plea for volunteers to help
  74. develop implementations or to improve on the existing implementations.
  75. Right now the server is hard to install, and there is no verification 
  76. that the server is built correctly. A bulk loader also needs to be
  77. developed as well as a web interface.
  78.