Larry, Good to hear from you. Comments inline. I think we can converge on something that we can all live with by just adding a transition issue appendix and deciding what needs to go into it. Curtis In message <1063981473.3370.23.camel@ablate.merit.edu>, "Larry J. Blunk" writes :
Pekka and Curtis, Thanks for the feedback. Sorry for not responding sooner (I've been trying to absorb everything and formulate a response). I've been updating the draft to reflect many of your comments (thanks, Pekka).
On Fri, 2003-09-19 at 03:21, Pekka Savola wrote:
On Thu, 18 Sep 2003, Curtis Villamizar wrote:
You seem not to be missing something. The mp-* and non- mp-* entries will be in the same database.
Probably yes, in the longer term; that helps some scenarios but doesn't eliminate the issues.
I think there indeed needs to be some text to clarify the use of mp-* and non mp-* entries. Should the document recommend the use of non-mp entries to express v4 policies for existing non-RPSLng compliant tools? Should this be mandatory or optional? And perhaps more controversily, if there are mp- attributes present in an object, should the non-mp attributes be ignored by RPSLng compliant tools to reduce the possibility for conflicts.
This is strictly a transition issue and a strong recommendation to specify non mp-* for IPv4 should be made for initial transition purposes. See comments below about eliminating this need with better server code. Any such recommendation should be in an appendix on transition issues, not in the main body of the document.
Further should there be clarification on the case where an import, export, or default attribute references a route-set/filter-set/etc. which contains mp- attributes? Should RPSLng compliant tools ignore the mp- attributes in this case (as non-RPSLng compliant tools would do).
For backwards compatibility the ipv4 unicast policy will be in the same database but at least initially expressed as non- mp-* policy statements.
Right.
One option I thought about would be to change the mp-members, mp-filter, mp-peer, mp-peering, and interface attributes to be IPv6 specific. In other words, rename them to something like members6, filter6, peer6, peering6, and interface6 (well, perhaps not the interface attribute since it introduces new functionality). This would preserve explicit support for backward compatibility with IPv4 as one would need to continue to express IPv4 prefixes and policy info in the existing RPSL attributes.
I think backward compatibility in these attributes is more important than the import, export, and default attributes as I believe one is more likely to reference another org's route-set, filter-set, etc., than another org's aut-num object.
-Larry Blunk Merit
It would be best if old clients could be recognized. This would mean conversion to new server code only before mp-* could be freely used. At that point when an old client is recognized all mp-* attributes can be returned with s/mp-// as long as they apply to IPv4. With the server code hiding the mp- stuff a query that hits an mp-import or import that referenced an mp-filter or filter would alway be returning just a import and filter to the older client. This is not so much an issue for the spec as it is for the implementation and a transition consideration for deployment. It doesn't hurt to mention the issues in the spec, but there is no need to change the spec. There is always a need to make a smooth transition. Rather than change the spec to make mp-peer etc into peer6 etc, leave the spec as is but for early transition only accept a mp-peer if it is specifies a non-IPv4-unicast peering. When the server code is updated in enough places you can accept a mp-peer that specifies ipv4 but return a plain peering to older clients.