home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rps / rps-minutes-96jun.txt < prev    next >
Text File  |  1996-10-07  |  7KB  |  173 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.  
  4.  
  5. The Routing Policy System Working Group met on Monday, June 24 and 
  6. Tuesday, June 25. Daniel Karrenberg and Cengiz Alaettinoglu chaired 
  7. the meetings. Elise Gerich took the minutes. 
  8.  
  9. 1.The first presentation was given by Alaettinoglu to describe as-set 
  10. and route-set classes within the policy language. Slides of this 
  11. presentation are available at ftp.isi.edu/rps/montreal-ietf. 
  12.  
  13. The following questions and answers followed the policy language 
  14. presentation:
  15.  
  16. a) Are as-set names aliases for aut-nums? 
  17. The answer is no, they are not.
  18.  
  19. b) What rules prevent malicious or bogus information from being 
  20. registered in the database?
  21. The response was that the language has clear and conservative 
  22. semantics of as-set and route-set membership even in the presence of 
  23. bogus information registered in the database. The database software 
  24. can further ensure bogus information is not registered on the first place.
  25.  
  26. c) The general question was asked as to whether the working group felt 
  27. that set names led to any confusion. 
  28. The working group consensus was that it had no problem with the 
  29. proposed naming of the sets.
  30.  
  31. 2. The second presentation addressed changes to policy specification 
  32. language. The slides are included with those noted in the first agenda 
  33. topic. 
  34.  
  35. One of the questions that was asked was, "What is the best format for 
  36. expressing the date?" The consensus is the ISO standard YYYYMMDD; 
  37. for example, 19960819 
  38.  
  39. Another resolution was the line continuation would be treated in a 
  40. fashion that is consistent with RFC 822. 
  41.  
  42. Questions that were asked after this presentation were: 
  43.  
  44. a) In the current implementation can you intermix comments and policy 
  45. information?
  46. The response was you have to do hashing to make a comment. 
  47.  
  48. b) Is it the intention to permit comments instead of having multiple as-
  49. in lines?
  50. The answer was yes.
  51.  
  52. There was some discussion about this issue of comments. Some folks felt 
  53. that comments (hashing) should be part of the language and not a part 
  54. of the tool implementation. The chairs were going to take the comments 
  55. into consideration. 
  56.  
  57. The export-components of the route class specification was discussed 
  58. and is intended to make aggregation simpler. This proposal generated a 
  59. fair amount of discussion. Most of the speakers indicated that it is 
  60. already possible to express this in the aut-num object and that it is 
  61. unnecessary to introduce a special knob. It was also agreed that it made 
  62. aggregation simpler. There was not a clear decision as to whether to 
  63. proceed with this change.
  64.  
  65. The proposal to suggest that domain names be used instead of IP 
  66. addresses was another topic which generated a lot of interest. There 
  67. was overwhelming support for the continued use of IP addresses and the 
  68. decision was to abandon the idea to identify routers by domain name. It 
  69. was proposed that there could be a label in the language for names, and 
  70. the Chairs indicated that they would consider the idea. 
  71.  
  72. The topic of specific operators generated the following questions: 
  73.  
  74. a) Why not use > for exclusive?
  75. This was an unpopular idea.
  76.  
  77. b) Will multi-line pairs be returned as a single line or multi-line? 
  78. What you register is what will be returned. 
  79.  
  80. c) How will the existing tools be affected? 
  81. The tools are being updated along the way. 
  82.  
  83. d) Should aut-num be called aut-sys?
  84. Not a big deal; no reason to change.
  85.  
  86. e) Proposal to accept more specific policy specification instead of basing 
  87. what takes precedence on ordering. 
  88. Much discussion took place with the decision being that the working 
  89. group supports maintaining specification ordering. 
  90.  
  91.  
  92. 3)The Dictionary Object was introduced by Alaettinoglu. 
  93.  
  94. The presentation slides are available in ftp.isi.edu/rps/montreal-ietf. 
  95.  
  96. Some comments that will be taken into consideration were: a) Use 
  97. current conventions instead of introducing new syntax. One example of 
  98. this is asx:int format which is somewhat standard.
  99. b) Use an integer rather than a label (3561 instead of as3561) c) Replace 
  100. the += with .=. The community is more used to that notation.
  101. d) Define format for wildcards.
  102. e) Define way to do exact match.
  103.  
  104. 4) The inet-rtr object was discussed. The peer attribute is in early draft 
  105. stages.
  106.  
  107. Some input as to what is needed was suggested by the working group. 
  108. The suggestions included: a) ability to define multiple ip addresses b) 
  109. ability to specify loop back addresses c) ability to register ip addresses 
  110. in advance of installation 
  111.  
  112. The working group strongly supported specifying masks by mask length.
  113.  
  114. A proposal was made to change 'ifaddr' to 'interface-addr', but this 
  115. was defeated by the working group. 
  116.  
  117. A question was whether the specification was generic or specific to only 
  118. one implementation. Alaettinoglu stated at least three router 
  119. configuration are supported. 
  120.  
  121. The plan is to close RPSL specification on this at the next IETF meeting.
  122.  
  123. 5) Plans to transition from the RIPE-181 specification to the RPSL were 
  124. introduced by Jerry Winters. Slides are also available from 
  125. ftp.isi.edu/rps/montreal-ietf. 
  126.  
  127. One concern that was expressed was that an implementation might 
  128. precede the acceptance of RPSL as an RFC. The working group seemed 
  129. unconcerned that the implementation may precede formal publication 
  130. of the RFC.
  131.  
  132. The meeting adjourned until Tuesday.
  133.  
  134.  
  135.  
  136. ======================= Tuesday 
  137. ===================================== 
  138.  
  139. The only agenda topic on Tuesday had to do with tool development. For 
  140. a good description of the tools, refer to the presentation slides at 
  141. ftp.isi.edu/rps/montreal-ietf. 
  142.  
  143.  
  144. 1.route object editor - Alaettinoglu
  145. The route object editor was developed on a SUN SPARC running Solaris 
  146. and has been ported to freeBSD.
  147.  
  148. 2. prtraceroute, relayd and irrv meets prpath - Ramesh Govindan 
  149.  
  150. The purpose of relayd is to run the database software locally and to be 
  151. able to simulate the results of policy changes in routers and the routing 
  152. registry.
  153.  
  154. 3. cidr advisor - Alaettinoglu
  155.  
  156. Now does proxy integration and some functionality have changed since 
  157. Dallas meeting. This tool promotes "safe aggregates." 
  158.  
  159. This will be part of 3.4 RAToolSet distribution. As with all of the RA 
  160. tools, it can be configured to look at a set of registries.
  161.  
  162. The following action items were taken:
  163. 1) finish up the RPSL spec before next IETF 2) write a transition from 
  164. RIPE-181 to RPSL document effort to be lead by Jerry Winters and Brian 
  165. Renaud 3) write a guide lines for tool implementers document effort to 
  166. be lead by Daniel Karrenberg.
  167. 4) write a tutorial on RPSL
  168. effort to be lead by Cengiz Alaettinoglu. 
  169.  
  170. Meeting was adjourned.
  171.  
  172.  
  173.