[address-policy-wg] 2008-09 New Policy Proposal (ASPLAIN Format for the Registration of 4-byte ASNs)

Hi Wilfried.

> the reason for having to use the PDP is the fact that registration
> format "ASDOT" is explicitely prescribed in the AS# distribution-
> policy doc. This was a conscious (but maybe unwise) decision, taken
> at a time when there was no (standards) rfc available.

Sorry but I did miss this detail. I do think it is unfortunate to tie
this sort of detail into things that require PDPs to change.

> This has already been explained somewhere on the list(s) iirc.

> > Also, this issue goes beyond RIPE and is about development of an
> > industry standard. It is not a RIPE-specific issue. There are more
> > appropriate other fora for developing industry standards. RIPE (and
> > indeed all RIRs) should defer to other industry bodies for development
> > of technical standards.
> > 
> > Note that the IETF is currently finalizing the document
> > draft-ietf-idr-as-representation-01.txt already. Indeed, the IESG will
> > be formally considering it this week, so with a little bit of luck, it
> > will be an RFC in a month.
> > 
> > At that point, it would be fine for RIPE to adopt that standard, but I
> > would hope that it could do so without requiring a PDP. (Does RIPE
> > generally need a PDP before it is allowed to start using an IETF
> > standards?)

> I presume in general the answer would be NO to your (question). But
> please stop bashing RIPE for respecting its own internal procedures.

Wouldn't it be better then to use the PDP to undo the previous
requirement, but leave it as an operational matter as to what the
exact format should be? Coupled, of course, with a _suggestion_ as to
the preferred format as opposed to a _requirement_? I.e., undo the
previous requirement but not replace it with another firm/inflexible
requirement?

In general, isn't this how these sorts of details are worked out?

> > Let's keep things simple please!

> Indeed, but I guess you would not recommend to "simply" change a
> formally adopted policy document, would you? This could be seen as
> a nasty precedent...

No, of course not. So looking forward, what can be done so that future
changes like this will not require a PDP to make further (minor)
updates? I would think it best not to require the use of PDPs to
handle these sorts of things.

Thomas