Editor's note: These minutes have not been edited. The Routing Policy System Working Group met on Monday, June 24 and Tuesday, June 25. Daniel Karrenberg and Cengiz Alaettinoglu chaired the meetings. Elise Gerich took the minutes. 1.The first presentation was given by Alaettinoglu to describe as-set and route-set classes within the policy language. Slides of this presentation are available at ftp.isi.edu/rps/montreal-ietf. The following questions and answers followed the policy language presentation: a) Are as-set names aliases for aut-nums? The answer is no, they are not. b) What rules prevent malicious or bogus information from being registered in the database? The response was that the language has clear and conservative semantics of as-set and route-set membership even in the presence of bogus information registered in the database. The database software can further ensure bogus information is not registered on the first place. c) The general question was asked as to whether the working group felt that set names led to any confusion. The working group consensus was that it had no problem with the proposed naming of the sets. 2. The second presentation addressed changes to policy specification language. The slides are included with those noted in the first agenda topic. One of the questions that was asked was, "What is the best format for expressing the date?" The consensus is the ISO standard YYYYMMDD; for example, 19960819 Another resolution was the line continuation would be treated in a fashion that is consistent with RFC 822. Questions that were asked after this presentation were: a) In the current implementation can you intermix comments and policy information? The response was you have to do hashing to make a comment. b) Is it the intention to permit comments instead of having multiple as- in lines? The answer was yes. There was some discussion about this issue of comments. Some folks felt that comments (hashing) should be part of the language and not a part of the tool implementation. The chairs were going to take the comments into consideration. The export-components of the route class specification was discussed and is intended to make aggregation simpler. This proposal generated a fair amount of discussion. Most of the speakers indicated that it is already possible to express this in the aut-num object and that it is unnecessary to introduce a special knob. It was also agreed that it made aggregation simpler. There was not a clear decision as to whether to proceed with this change. The proposal to suggest that domain names be used instead of IP addresses was another topic which generated a lot of interest. There was overwhelming support for the continued use of IP addresses and the decision was to abandon the idea to identify routers by domain name. It was proposed that there could be a label in the language for names, and the Chairs indicated that they would consider the idea. The topic of specific operators generated the following questions: a) Why not use > for exclusive? This was an unpopular idea. b) Will multi-line pairs be returned as a single line or multi-line? What you register is what will be returned. c) How will the existing tools be affected? The tools are being updated along the way. d) Should aut-num be called aut-sys? Not a big deal; no reason to change. e) Proposal to accept more specific policy specification instead of basing what takes precedence on ordering. Much discussion took place with the decision being that the working group supports maintaining specification ordering. 3)The Dictionary Object was introduced by Alaettinoglu. The presentation slides are available in ftp.isi.edu/rps/montreal-ietf. Some comments that will be taken into consideration were: a) Use current conventions instead of introducing new syntax. One example of this is asx:int format which is somewhat standard. b) Use an integer rather than a label (3561 instead of as3561) c) Replace the += with .=. The community is more used to that notation. d) Define format for wildcards. e) Define way to do exact match. 4) The inet-rtr object was discussed. The peer attribute is in early draft stages. Some input as to what is needed was suggested by the working group. The suggestions included: a) ability to define multiple ip addresses b) ability to specify loop back addresses c) ability to register ip addresses in advance of installation The working group strongly supported specifying masks by mask length. A proposal was made to change 'ifaddr' to 'interface-addr', but this was defeated by the working group. A question was whether the specification was generic or specific to only one implementation. Alaettinoglu stated at least three router configuration are supported. The plan is to close RPSL specification on this at the next IETF meeting. 5) Plans to transition from the RIPE-181 specification to the RPSL were introduced by Jerry Winters. Slides are also available from ftp.isi.edu/rps/montreal-ietf. One concern that was expressed was that an implementation might precede the acceptance of RPSL as an RFC. The working group seemed unconcerned that the implementation may precede formal publication of the RFC. The meeting adjourned until Tuesday. ======================= Tuesday ===================================== The only agenda topic on Tuesday had to do with tool development. For a good description of the tools, refer to the presentation slides at ftp.isi.edu/rps/montreal-ietf. 1.route object editor - Alaettinoglu The route object editor was developed on a SUN SPARC running Solaris and has been ported to freeBSD. 2. prtraceroute, relayd and irrv meets prpath - Ramesh Govindan The purpose of relayd is to run the database software locally and to be able to simulate the results of policy changes in routers and the routing registry. 3. cidr advisor - Alaettinoglu Now does proxy integration and some functionality have changed since Dallas meeting. This tool promotes "safe aggregates." This will be part of 3.4 RAToolSet distribution. As with all of the RA tools, it can be configured to look at a set of registries. The following action items were taken: 1) finish up the RPSL spec before next IETF 2) write a transition from RIPE-181 to RPSL document effort to be lead by Jerry Winters and Brian Renaud 3) write a guide lines for tool implementers document effort to be lead by Daniel Karrenberg. 4) write a tutorial on RPSL effort to be lead by Cengiz Alaettinoglu. Meeting was adjourned.