home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 97aug / ride-minutes-97aug.txt < prev    next >
Text File  |  1997-10-10  |  9KB  |  168 lines
  1.  
  2. RIDE BOF Meeting Minutes (Wednesday 9:00-11:30am, August 13th)
  3. Reported by Wilfried Woeber <woeber@cc.univie.ac.at>
  4.  
  5. The sesssion started with a review of the agenda. It was asked what the
  6. position of the IESG and the area directors of APPS and OPS is for the
  7. status of the group since the group already met for the second time.
  8. Keith Moore (area director APPS) stated that he was not convinced yet to
  9. form a WG. John Curran (area director OPS) suggested to review the
  10. charter, and to think about potentially structuring the work around a
  11. somewhat larger set of documents. Therefore a second review of the draft
  12. charter was added to the agenda. Furthermore, the relation between coredb
  13. and this group was clarified. This group viewed the regional IP
  14. registries as it's primary constituency. This doesn't preclude the use of
  15. the work of this group by the coredb developers, but at the same time
  16. means that no special consideration is given to the coredb work.
  17.  
  18. A short presentation and discussion of the latest revision of the RIDE
  19. classes draft followed. The main changes to the previous version can be
  20. summarized as follows:
  21.  
  22.   . The layout of the document was changed on request of the group
  23.   . Added recommendation on the use of the attributes:
  24.     - required / optional - single / multiple
  25.   . Added host object (as required by InterNIC)
  26.  
  27. The next agenda item was the discussion of a proposal on how to handle
  28. RIDE references. The proposal was presented and triggered a lengthy
  29. discussion on the issues involved and helped us to decide on setting
  30. priorities for the work of the group.
  31.  
  32. The principle of the proposed reference mechanism is summarized below:
  33.  
  34.   . Define a globally unique component.
  35.   . Define a local identifier for every object
  36.     Clarification: IDs can be regarded as the equivalent of Handles
  37.   . The combination of local and global identifier will create a
  38.     globally unique key for every registry object
  39.   . Use (part of) "your" domain name as the (by definition) of the unique
  40.     registry identifier
  41.   . an example is the following NIC Handle:
  42.     KH1-ARIN
  43.     KH1 is the local identifier
  44.     ARIN is the globally unique identifier
  45.     
  46.   An object reference can now be resolved using the following procedure:  
  47.     
  48.   . Register, possibly in DNS, where to send a query to
  49.   . Query the appropriate server, using the local identifier
  50.   . Problems and advantages
  51.     - no central authority is required, this could be an advantage
  52.       as well as a disadvantage
  53.     - peer registry has to decide about validity of reg.id.
  54.       and data obtained
  55.     - alternate mechanism: subtree of registries.int.
  56.       managed by IANA
  57.  
  58. The consequences of DNS going bad for a "mission critical" function
  59. specifically when there are already problems on the net were discussed.
  60. Given the finite number of registries, it might be feasible to use a flat
  61. table structure. It was suggested to put a note into the document,
  62. stating that an implementation might do clever things to optimize the
  63. system and to make it more stable by using the DNS for generating a local
  64. structure containing the required information.
  65.  
  66. Another issue was the impact of the scheme on the user agent(s) and the
  67. implementation at a particular registry. One could implement all this
  68. without changes to the user agents, which is one of the goals of the
  69. group. This doesn't mean that user agents could not be designed to take
  70. direct advantage of the scheme. It was proposed to avoid that rathole by
  71. separating structure from implementation details. These details, as well
  72. as other implementation hints should go to an appendix of the document,
  73. maybe even to a different doc.
  74.  
  75. The mapping between the registry identifier and the local representation
  76. was also discussed. It was suggested to make that a local problem for the
  77. registry.
  78.  
  79. Another remark suggested that we shouldn't overload DNS and take a look
  80. at the new SRV stuff in DNS. This brought us to the point how and if we
  81. should store authoritative information on were to find information
  82. regarding IP numbers, AS numbers or TLD information. It was suggested
  83. that IANA could do this, however, there were concerns raised since this
  84. is not a "strictly mechanical" assignment process. Assignment simply
  85. offers uniqueness but does not indicate any level of authority. John
  86. Curran then asked what the priorities were of the prospective WG? It was
  87. decided that this particular item could be considered one of the lower
  88. priority items. We decided that the charter should contain a prioritized
  89. list of items that we want to accomplish.
  90.  
  91. The following agenda item was a strawman proposal for the protocols and
  92. formats. It was intended to get the discussion started on the topic. The
  93. proposal helped us to iron out the requirements for the protocol and some
  94. details for the draft charter. The strawman proposal was presented and is
  95. described below including the amendments made by the group:
  96.  
  97.   Requirements and preconditions
  98.   
  99.   . initial customers are: regional registries, 
  100.                            routing regsitries,
  101.                            domain registries.
  102.   . simple to implement to gain support.
  103.   . the system is solely for interaction between registries
  104.     and does NOT replace any of the existing systems.
  105.   . exchange data amongst the existing registries 
  106.     and resolve references.
  107.   . make proper provisions for supporting extensions or new protocol
  108.     versions.
  109.   . consistency and security issues for the registries should not 
  110.     become more complicated or difficult (we should not make it worse).
  111.   . timing is important,
  112.     i.e. we need results *now*, yesterday would even be better.
  113.   . implementation at a larger registry might generate high load at
  114.     some servers.
  115.   
  116.   What are the required operations?
  117.   . retrieval of full data set for a particular object type,
  118.   . retrieval of differences after the last retrieval of the data set
  119.   . resolving a reference
  120.   . accept updates? 
  121.     This functionality was removed by the group. The group considered it
  122.     as too much for now. It would make the system to complicated. It was
  123.     recommended to add a line to the charter that we would only deal with
  124.     getting information out of a registry and not the other way around.
  125.   
  126.   The formats
  127.   
  128.   . all data in 7bit ASCII
  129.     It would be nice to have internationalization support, but none of
  130.     the current registries was using something else then 7bit US ASCII. 
  131.     Furthermore, in an operational and international envirnonment, the
  132.     use of another character set then one's local character set on a
  133.     simple system at the middle of the night fixing an operational
  134.     problem was considered to be too challenging. Note that this doesn't
  135.     preclude registries from adding comments to the information being
  136.     presented to point to a local language version of the information.
  137.  
  138. The presentation included some more detailed discussion of some of the
  139. items. One of the topics that came up was DNSSEC. It was recommended that
  140. we should make sure that we are compatible with DNSSEC, however a comment
  141. was made that this should probably not be an issue since DNSSEC is
  142. supposed to have no operational impact and be transparent to the users. It
  143. was agreed that we should at least check these assumptions when we decide
  144. to use the DNS for certain functionality.
  145.  
  146. The whole business of version negotiation was also discussed in more
  147. detail. It was proposed to replace version negotiation by capabilities
  148. announcement and negotiation. However, the group felt that this solution,
  149. while a good idea in general, could be too complicated for what we are
  150. aiming for. It was proposed to stay with a simple straight forward
  151. mechanism right now. 
  152.  
  153. It was suggested to use an existing protocol, which was already
  154. explicitly mentioned in the draft charter as a possibility. This could be
  155. more practical than defining a new one. Implementation time could be cut.
  156. Also, for a new protocol proposal, we would have to defend the
  157. "limited-security" point of view. We concluded that we needed first a
  158. requirements document which would allow us to start the search for an
  159. existing protocol that would suit our needs or that we could adapt an
  160. existing protocol or define a new one.. 
  161.  
  162. Finally the group went line by line through the proposed charter. Wording
  163. was changed for clarification and priorities were set. Many small, but
  164. nevertheless important changes were made to reflect the discussions
  165. earlier during the meeting. It was decided to make a revision of the
  166. charter and mail it to the list for a last review.
  167.  
  168.