I'm not sure if I agree with what you call "tough luck", but I've omitted them from the response, as more arguing on those wouldn't seem to be productive. On Fri, 12 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309111134070.10628-100000@netcore.fi>, Pekka Savola writes:
In message <Pine.LNX.4.44.0309101200110.30657-100000@netcore.fi>, Pekka Sav
On Wed, 10 Sep 2003, Curtis Villamizar wrote: ola
writes: [...]
However, there seem to be a number of (more or less) textual inaccuracies
and confusion in the document, which should be settled prior to publication.
I think there are the three most important issues here are:
* issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what?
Not an issue. If only IPv4 policy is specified by a given statement, then either the old form or the new form can be used. Currently multiple import, export, and default statements can appear. Their effects are additive. The effect of adding mp-* statements specifying ipv4 using the longer syntax is the same as adding more of the existing import, export, and default statements.
I'm not sure if I see it as the same. The user running RPSL tool must check both the traditional and RPSLng entries. This is a change. More likely than not, depending on the transition/co-existence plan, he will also have to maintain records on both old and new. This is bound to cause inconsistencies in the data.
The transition is quite easy. The change adds mp-* but does not depricate (ever) the use of the non mp- forms. Just keep all the IPv4 unicast policy in the old form until conversion is considered complete. If it is never certain that conversion is complete, keep the IPv4 unicast in the old form indefinitely.
"until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right? But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach. As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features. Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only. But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure. Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng! We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details..
* issue 5) and others-- whether the document needs to specify all the relevant modifications explicitly, or not. IMHO, Stds Track document should describe every change, not just say something like "other attributes are modified in a similar fashion" (or something to that effect)
There is no need to repeat lengthy syntax descriptions contained in the base RFC if a straightforward modification is being made. The example you gave points to text that is perfectly clear. The existing <filter> accepts IPv4 addresses. The <mp-filter> allows either IPv4 or IPv6 addresses to be specified. Perhaps this statement could be worded differently, but the syntax definitely should not be repeated. The syntax definition in RPSL remains authoritative except the additions defined here and no definitions that are not being changed should be included.
I'm not sure if all those modifications are completely straightfoward.
That's fine. Sometimes when something has been in use for a while the people that have been using it won't see an ambiguity or ommission because they already know how things work. Please be specific if there are instances of this.
I think I've already pointed out some of those. All in all, I think *at least* the document should mention which things are being changed, and how (e.g. as a list, even if not "repeating lengthy discussions").
I don't see Updates like that at all. What you're describing would seem closer to "Obsoletes". This spec DOES make changes/additions to the existing sec, e.g. at rp-attribute next-hop.
It makes additions only. For example, IPv6 changes to next-hop only apply to IPv6 static routes.
But still, it changes the rp-attribute.
2) one important aspect to consider is interaction with old specification , that is:
Keeping this in mind, the "import:", "export:", and "default:" attributes implicitly specify IPv4 unicast policy and remain as defined previously in RPSL, and new multi-protocol (prefixed with the string "mp-") attributes are introduced. These will be described below.
==> so, should one get information from both the RPSLng multiprotocol attributes and the old ones? What if they conflict? Maybe some words wo uld be useful on how to effectively transition/co-exist with both RPSL and RPSLng?
See prior note. Not an issue.
Not so sure on that.
Its deployed so obviously it works. We're not talking about something no one has ever tried. This is documenting a set of extensions that are in use.
Being used by a few people and being used as widely as RPSL is used today are two different things. It is obviously not being used widely if RIPE just got it's test version of the database and the tools out a month or something like that ago. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings