Re: [apps-discuss] The state of 'afs' URi scheme

"t.petch" <> Tue, 01 February 2011 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 768C33A6B58; Tue, 1 Feb 2011 07:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.386
X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bl7RkKPT9kQ8; Tue, 1 Feb 2011 07:37:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0B6313A6CF4; Tue, 1 Feb 2011 07:37:51 -0800 (PST)
Received: from (HELO pc6) ([]) by with SMTP id BPC96881; Tue, 01 Feb 2011 15:41:06 +0000 (GMT)
Message-ID: <01b301cbc21d$868081c0$>
From: "t.petch" <>
To: "Mykyta Yevstifeyev" <>, "Ben Niven-Jenkins" <>
References: <> <> <> <> <> <><> <><><><> <>
Date: Tue, 1 Feb 2011 15:37:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4D482991.018E, actions=tag
X-Junkmail-Status: score=10/50,
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4D482992.0237, ss=1, fgs=0, ip=, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc:, URI <>,
Subject: Re: [apps-discuss] The state of 'afs' URi scheme
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Feb 2011 15:37:53 -0000

----- Original Message -----
From: "Mykyta Yevstifeyev" <>
To: "Ben Niven-Jenkins" <>
Cc: <>rg>; "URI" <>rg>; <>
Sent: Tuesday, February 01, 2011 4:27 PM

> 01.02.2011 17:23, Ben Niven-Jenkins wrote:
> > Mykyta,
> >
> > On 1 Feb 2011, at 15:02, Mykyta Yevstifeyev wrote:
> >> Ben,
> >>
> >> Such action might be performed by simple request of IESG.  RFC 4395 says:
> >>
> >> Transition from 'provisional' to 'historical' may be
> >>    requested by anyone authorized to update the provisional
> >>    registration.
> >>
 >> Since that is not clear who is authorized to change it, IESG should be
considered for such action (there is not this in the document, this is my
opinion).  So IMO IESG should issue the community call on reclassification and
then request this action from IANA.
> >>
> >> And in this way there won't be what you say - unnecessary docs.
> > So you've saved an I-D being written but still used IESG time which could be
much better spent on other things that actually provide value to the community.

> I really do not consider the action I propose as that 'requires great
> amount of time'.  Moreover, there is a strong consensus it is not used
> and will not be used so no problems will appear, IMO.

I have said it before, and I will go on saying it.

The time of an AD is precious, we depend on them for the IETF to happen,
so creating unnecessary work for them, by requests, by unproductive I-Ds
or any means is detrimental to the whole of the IETF.

Doing that to the IESG simply magnifies the effect by an order of magnitude.

Tom Petch

> > Also, you failed to answer the question I asked though, namely:
> >>> What is the real value and benefit in doing all the work to move them to
historic? No one uses them so no one benefits from tweaking the category they
are placed in IMO.
> > Unless there is a good answer to that question to justify changing their
classification, I don't see any point in spending time discussing how one might
go about reclassifying them.
> You should better ask the authors of RFC 4395 this, but not me.  If this
> wasn't needed, it wouldn't appear here.
> Mykyta Yevstifeyev
> > Ben