Separate attributes vs context-aware software [RE: RPS WG...]

Pekka Savola writes:
>> I rather see progress towards a pusblished standard, although it
>> doesn't do everything exactly the way I want it, than that we
>> reopen all the discussions again unless a lot of people changed
>> their minds.

> For what it's worth, I, as an operator, have roughly the same
> opinion.

Me too.

> I'd like to see a standardized solution soon (I accept the current
> draft proposal if that's the rough consensus), but on the other
> hand, I'd like it to be as simple as possible to use.

Exactly.

The mp-import/mp-export stuff personally doesn't bother me at all, but
I heard a fellow operator complain about the expected size increase of
their AS object.

What about the following compromise:

*) Leave both export/import and mp-export/mp-import in RPSLng (same
   for default/mp-default)
*) Add a "mp-default-afs" attribute that defines what "import/export"
   means.  It would default to ipv4.unicast only.

That way, no existing tools break - import/export will still be used
for IPv4 unicast policy like today.  ISPs can add mp-{im,ex}port to
document IPv6 and multicast policies.  As long as "The majority of
providers support IPv4 unicast only" (as Curtis pointed out, and which
is still the case for our set of peers, even though we ARE an
"academic" network), people just add mp- attributes for the minority
of peerings that need it.

Over time, Pekka's vision of congruent unicast/multicast (and/or
IPv4/IPv6 unicast, but that doesn't matter) topologies may come true.

At that point, people can start modifying their "mp-default-afs", and
collapse many mp-{im,ex}port attributes into {im,ex}port attributes.
If their peers still use non-RPSLng-compliant tools, then they will
misinterpret {im,ex}port as IPv4 unicast-only, but that is probably
not very relevant - IPv4 unicast is all those peers' tools can handle.

In some cases it will be necessary to specifically exclude default
address families, but maybe that could be done with AF-specific NOT
ANY policies or something.

Makes sense?
-- 
Simon.