Re: [address-policy-wg] 2008-09 New Policy Proposal (ASPLAIN Format for the Registration of 4-byte ASNs)
-
To: Thomas Narten narten@localhost
-
From: "Jeffrey A. Williams" jwkckid1@localhost
-
Date: Tue, 21 Oct 2008 12:35:58 -0700
-
Cc: Woeber@localhost, address-policy-wg@localhost
-
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=H8NUpUcl/CXQN+9VY5OoKZ6L9IBblevdknUJh4/NUuKkYI/t9huEARnu+rtZbX/B; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
-
Organization: IDNS and Spokesman for INEGroup
Thomas and all,
Interesting circular argument...
Thomas Narten wrote:
> 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
Regards,
Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
Abraham Lincoln
"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt
"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng. INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
jwkckid1@localhost
My Phone: 214-244-4827
|