Dear colleagues, We'd like to present the view of the RIPE NCC on the discussions on the RPSLng draft. Although it is not explicitly discussed in the draft, the transition issue was thought on. It was decided to use mp-* attributes to ease the transition. That way, the old clients that use the routing registry that supports RPSLng can simply ignore the new attributes and new object classes and continue to work (this is the expected behaviour of clients, RFC2622 sections 10.2 and 10.3). Thus, it is not really necessary to equip the whois server with the capability of detecting if the client is RPSLng capable or not. Perhaps what we need to do is to document these in the draft. At any rate, we think it is useful to change the protocol to allow negotiation of object format, but this is out of scope of RPSLng effort. The relevant effort to change (or, re-design) the protocol is the CRISP effort, please see http://www.ietf.org/html.charters/crisp-charter.html . On the subprotocol issue: IPv4 address family has defaulted to ipv4.unicast generally (in Cisco IOS software, for instance, which is widely used). Therefore the change of the meaning to ipv4.unicast+ipv4.multicast may cause confusion. We have been trying to come up with a solution so that the users of whois database can start using it to publish their IPv6 and multicast policies. The effort started more than a year ago and our users are getting more and more impatient to see a solution. Actually, long ago they started to "document" their IPv6 and multicast policies using alternative methods, please see aut-num: AS12702 as-name: UUNET-EMEA-IPV6 descr: WorldCom EMEA descr: IPv6 only Autonomous System remarks: detailed routingpolicy is documented at remarks: whois.6bone.net due to missing IPv6 support remarks: in the RIPE database: remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-DE remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-FR remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-NL remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-UK admin-c: ABN-RIPE tech-c: ABN-RIPE mnt-by: UUNET-MNT changed: hostmaster@ripe.net 19991004 changed: ehofmann@uu.net 20021122 source: RIPE or aut-num: AS1122 as-name: UNSPECIFIED descr: UK-AS admin-c: UK6107-RIPE tech-c: UK3 import: from AS760 action pref=100; accept ANY export: to AS760 announce AS1122 remarks: ------------------------- remarks: as-in-v6: from AS760 100 accept ANY remarks: as-in-v6: from AS10566 90 accept ANY remarks: ------------------------- remarks: as-out-v6: to AS760 announce AS1122 remarks: as-out-v6: to AS10566 announce AS1122 remarks: ------------------------- mnt-by: UK-MNT mnt-by: AS1853-MNT changed: Erik-Jan.Bos@surfnet.nl 19940314 changed: ripe-dbm@ripe.net 19990701 changed: woeber@cc.univie.ac.at 19990809 changed: woeber@cc.univie.ac.at 19990912 changed: ulrich.kiermayr@univie.ac.at 20020819 source: RIPE or aut-num: AS1938 as-name: FR-RENATER-IRISA descr: Irisa/Inria Rennes remarks: BEGIN IPv4 unicast routing policy import: from AS13019 action pref=1; accept ANY import: from AS20603 action pref=2; accept ANY export: to AS13019 announce AS1938 export: to AS20603 announce AS1938 remarks: END IPv4 unicast routing policy remarks: BEGIN IPv4 multicast routing policy import: from AS2200 accept ANY export: to AS2200 announce AS1938 remarks: END IPv4 multicast routing policy remarks: BEGIN IPv6 routing policy import: from AS2200 action pref=1; accept ANY import: from AS20603 action pref=2; accept ANY export: to AS2200 announce AS1938 export: to AS20603 announce AS1938 remarks: END IPv6 routing policy admin-c: GR1378-RIPE admin-c: CL4104-RIPE tech-c: DL169-RIPE tech-c: RT199-RIPE mnt-by: RENATER-MNT changed: rensvp@renater.fr 19991014 changed: er-transfer@ripe.net 20020919 changed: rensvp@renater.fr 20030620 source: RIPE so it seems like it's time come up with a solution and implement it. We think the current draft meets the needs. Best regards, -- RIPE NCC RPSLng Team Katie, Shane & Engin