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

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 01 Feb 2011 12:15:38 +0200

31.01.2011 16:59, Paul Hoffman wrote:
> On 1/31/11 12:28 AM, Roy T. Fielding wrote:
>> No, there is no reason to have that document either.  We don't need
>> these useless exercises in bit pushing -- there are plenty of other
>> drafts that need writing about actual protocols that were (and are)
>> used on the Web as identifiers.  afs, nfs, tn3270, and mailserver are
>> all examples of schemes that someone once thought might be a good idea,
>> but were in fact never used on the Internet.  They are obsolete.
>
> +1
>
> On 1/31/11 3:20 AM, Mykyta Yevstifeyev wrote:
> > Since these schemes are in Provisional category, it means that they are
> > 'waiting for specification'. If no-one specifies them, they should be
> > moved to Historical. That's clear, IMO.
>
> -1
>
> Mykyta, you are approximately the only person who seems to have a 
> problem understanding that standards organizations like the IETF 
> sometimes don't follow through on what they thought were good ideas 
> and sometimes don't document that. Your response is to generate many 
> useless efforts to clean up the IETF specs instead of just doing what 
> everyone else does, which is to ask a question, find the answer, and 
> move on. It feels like you are wasting lots of people's time for the 
> benefit of no one other than maybe yourself. (If there are others who 
> feel that Mykyta's efforts are worth our time, by all means speak up 
> and I'm happy to back down here.)
Paul, Roy, and all,

What RFC 4395 says is that all URI schemes ever registered fall into 
three categories: Permanent, Provisional and Historical.  There are no 
other cases the URI scheme may be classified as.

RFC 1738, in its Section 4 mentioned the 'afs' URI scheme as reserved 
for further specifying.  Following the creation of URI schemes registry 
the scheme was added to Provisional category, since it does not appear 
to appropriate for registration as Permanent or Historical.

RFC 4395 sets clear criteria for all the categories.  The 'afs' URI 
scheme may not be classified as Permanent, because of the lack of what 
mentioned in Section 2.1, 2.3, 2.4, 2.6 and 2.7 of RFC 4395.  This 
scheme is not appropriate for Provisional because of the points 
described in Section 3 of this document, especially the cited below:

>    o  If no permanent, citable specification for the URI scheme
>        definition is included, credible reasons for not providing it
>        should be given.
>     o  A valid Security Considerations section, as required by Section 6
>        of [3  <http://tools.ietf.org/html/rfc4395#ref-3>].
>     o  If the scheme definition does not meet the guidelines laid out in
>        Section 2  <http://tools.ietf.org/html/rfc4395#section-2>, the differences and reasons SHOULD be noted.
>
Therefore, there are no other possibility either to remain it as 
Provisional or re-register it as Permanent.  Moreover, Section 4 mentions:

> once in use or registered but for whatever reason is no longer in
>     common use
and the 'afs' scheme meets these criteria.  So the conclusion is obvious.

As for the proposal to de-assign the scheme registration, the procedures 
for such action are not defined anywhere.

All the best,
Mykyta Yevstifeyev
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 1 Feb 2011 11:23:49 +0000

Mykyta,

On 1 Feb 2011, at 10:15, Mykyta Yevstifeyev wrote:

>> Mykyta, you are approximately the only person who seems to have a problem understanding that standards organizations like the IETF sometimes don't follow through on what they thought were good ideas and sometimes don't document that. Your response is to generate many useless efforts to clean up the IETF specs instead of just doing what everyone else does, which is to ask a question, find the answer, and move on. It feels like you are wasting lots of people's time for the benefit of no one other than maybe yourself. (If there are others who feel that Mykyta's efforts are worth our time, by all means speak up and I'm happy to back down here.) 
> Paul, Roy, and all,
> 
> What RFC 4395 says is that all URI schemes ever registered fall into three categories: Permanent, Provisional and Historical.  There are no other cases the URI scheme may be classified as.
> 
> RFC 1738, in its Section 4 mentioned the 'afs' URI scheme as reserved for further specifying.  Following the creation of URI schemes registry the scheme was added to Provisional category, since it does not appear to appropriate for registration as Permanent or Historical.
> 
> RFC 4395 sets clear criteria for all the categories.  The 'afs' URI scheme may not be classified as Permanent, because of the lack of what mentioned in Section 2.1, 2.3, 2.4, 2.6 and 2.7 of RFC 4395.  This scheme is not appropriate for Provisional because of the points described in Section 3 of this document, especially the cited below:
> 

I think the exact category these schemes are recorded under is not the key issue here.

These schemes were registered because it was believed they would be used but no-one has actually used them.

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.

One could argue that it is good housekeeping etc. but given the effort to write a draft, have it reviewed and taken through the IESG to become an RFC that no-one will read (because no-one uses the scheme in the first place) just doesn't seem a good use of the community's time and resources IMO.

Ben

---

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Feb 2011 14:14:55 +0200

+1

Lars

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 01 Feb 2011 17:02:09 +0200

> One could argue that it is good housekeeping etc. but given the effort to write a draft, have it reviewed and taken through the IESG to become an RFC that no-one will read (because no-one uses the…
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.

All the best,
Mykyta Yevstifeyev

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 1 Feb 2011 15:23:19 +0000

Mykyta,

On 1 Feb 2011, at 15:02, Mykyta Yevstifeyev wrote:
> 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.
> 

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.

>> 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.

Ben

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 01 Feb 2011 17:27:54 +0200

> 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.
> 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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 1 Feb 2011 10:40:59 -0500

On Tue, Feb 1, 2011 at 10:27 AM, Mykyta Yevstifeyev <[email-masked]> wrote:
>> 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.

It could be done as an IESG management item.  So... An AD has to
request it by putting it on a telechat agenda.  The IESG secretary has
to track it.  The IESG has to discuss it on the telechat (and the
scribe has to transcribe the discussion).  The secretary has to put it
in the minutes, and the IESG has to review the minutes.  IANA has to
make the change, and ensure that they do it right, which probably
means double-checking with the AD, who will review the IANA action.  A
notice has to be sent out.

No, that's not a *huge* amount of work.  But it *is* work and time,
spent by volunteers who are already working nights and weekends to get
their volunteer jobs done in addition to what their employers are
paying them for.

I don't know how the government works in Ukraine, but here in the U.S.
our Congress often comes out with silly "resolutions".  A few years
ago, they voted on and passed a resolution stating that Christmas is
important, for example.  Someone has to draft the resolution, it has
to be read at the meeting, someone has to speak in support of it --
sometimes multiple someones -- and a vote has to be taken.  Of course,
it passes.  But it accomplishes nothing, and it's wasted everyone's
time.

This is like that.  Let's not waste everyone's time.
In fact, let's not waste any more time discussing it.
(I'll point out, Mykyta, that you do not appear to have rough
consensus to do this, and there seems to be strong consensus NOT to.
Please accept that; it's how the IETF works.)

Barry

---

From: "t.petch" <[email-masked]>
Date: Tue, 1 Feb 2011 15:37:12 +0100

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

 >> 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.
> > 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.

> 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

> >>> 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.

---

From: "t.petch" <[email-masked]>
Date: Tue, 1 Feb 2011 15:42:49 +0100

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 31, 2011 3:59 PM

> sometimes don't follow through on what they thought were good ideas and 
> sometimes don't document that. Your response is to generate many useless 
> efforts to clean up the IETF specs instead of just doing what everyone 
> else does, which is to ask a question, find the answer, and move on. It 
> feels like you are wasting lots of people's time for the benefit of no 
> one other than maybe yourself. (If there are others who feel that 
> Mykyta's efforts are worth our time, by all means speak up and I'm happy 
> to back down here.)

No, looks spot on to me, so keep on doing whatever the opposite of 
backing down is.

Tom Petch.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 1 Feb 2011 15:49:54 +0000

Mykyta,

This will be my last mail on this topic as I've spent too long on it already.

On 1 Feb 2011, at 15:27, Mykyta Yevstifeyev wrote:
> 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.

Let me be more explicit. IMO spending any amount of time >0 on this is pointless.
 
> You should better ask the authors of RFC 4395 this, but not me.  If this wasn't needed, it wouldn't appear here.

RFC4395 states "Any scheme that is no longer in common use MAY be designated as historical". You're the one pushing for that optional action to be taken, not the authors of RFC4395 so you're the one that should justify why it is worthwhile taking that action.

Ben

---

From: John Levine <[email-masked]>
Date: 1 Feb 2011 15:53:45 -0000

>In fact, let's not waste any more time discussing it.

I certainly see rough consensus (everyone except one) that there is
nothing to do here.  So I encourage people to resist the urge to
debate it further.

R's,
John

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 01 Feb 2011 18:06:29 +0200

> nothing to do here.  So I encourage people to resist the urge to
Dear all,

If there is a rough consensus to remain this scheme Provisional, this 
means that there should be proper specification.  Even RFC 1738 is not 
appropriate here, as it is obsoleted.  Does anyone one want to specify 
this?  The answer is obviously 'no'.  The same answer is to the question 
'Move to Historic?'.  And for 'Do anything else?'

This seems to be a deadlock.  Therefore for I'll contact apps Area 
directors for their final decision.

Mykyta Yevstifeyev

---

From: Larry Masinter <[email-masked]>
Date: Mon, 7 Feb 2011 20:46:10 -0800

I think in general the overhead in maintaining current information about old registered values is too high, and that it *is* worth time thinking about how we could lower the overhead for registry maintenance.

There are a number of related issues raised about various registered values, including MIME type, charset, and URI schemes. 

Ideally a registry is a place where a new implementor can go to discover both the theory and current practice for use of registered values on the internet. I think the current processes cope OK with theory (although the overhead of updating the registry when there is a new spec is high, it might be acceptable) but not with practice (where implementation and deployment sometimes is in advance of, or divergent from, the formal specs).

The situation is more acute in areas where protocols and formats are undergoing rapid development.

So I agree that writing a document marking 'afs' as 'obsolete' is make-work and not-worth anyone's time, but how could we make it easier (light-weight annotation) without subjecting ourselves to DOS of unreliable annotation?

Larry

---

From: "t.petch" <[email-masked]>
Date: Tue, 8 Feb 2011 12:16:20 +0100

----- Original Message -----
From: "Larry Masinter" <[email-masked]>
To: "Ben Niven-Jenkins" <[email-masked]>; "Mykyta Yevstifeyev"
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 08, 2011 5:46 AM

> I think in general the overhead in maintaining current information about old
registered values is too high, and that it *is* worth time thinking about how we
could lower the overhead for registry maintenance.
>
> There are a number of related issues raised about various registered values,
including MIME type, charset, and URI schemes.
>
> Ideally a registry is a place where a new implementor can go to discover both
the theory and current practice for use of registered values on the internet. I
think the current processes cope OK with theory (although the overhead of
updating the registry when there is a new spec is high, it might be acceptable)
but not with practice (where implementation and deployment sometimes is in
advance of, or divergent from, the formal specs).
> So I agree that writing a document marking 'afs' as 'obsolete' is make-work
and not-worth anyone's time, but how could we make it easier (light-weight
annotation) without subjecting ourselves to DOS of unreliable annotation?

The problem, at least for URI, is RFC4395, which gives the procedures for new
schemes
and failed to consider old schemes.  RFC1738 did not make afs: provisional or
historic,
it merely asked that the name be reserved.  IANA, arguably incorrectly, places
afs: under
Provisional citing RFC1738 as its source.  But RFC1738 does not tell them to do
that!

So, arguably, we could tell IANA to create a provisional registry as RFC1738
told them to
and make it light weight, no need for IETF/IESG involvement unless and until a
move
to Provisional or Permanent is envisaged, using Expert Review in other cases of
change.
(I know of no other way of changing things in the IETF, which is what I see as a
constraint
we have to accept).

Or we could write a just-once catch-all RFC that picks up all these old ones,
and defines
a procedure for them (ie not a registration, but a procedure for registration,
such as
reinforcing the need for a Reserved category and placing those in it that should
always have
been in it).

Tom Petch

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 08 Feb 2011 17:46:25 +0200

08.02.2011 13:16, t.petch пишет:
> From: "Larry Masinter"<[email-masked]>
> To: "Ben Niven-Jenkins"<[email-masked]>; "Mykyta Yevstifeyev"
> <[email-masked]>
> Cc:<[email-masked]>
Maybe IANA was guided by the following fact. While RFC 4395 mentions the 
Provisional category, it does not give full definition of its purpose. 
This might cause misunderstanding of community and other interesting 
parties. IANA, due to lack of precise definition decided that RFC 1738 
reserves these names via their provisional registration. Therefore they 
put it into corresponding category.

But we should note that RFC 4395 says:

>   To transition to the new registry, all URL name schemes in the
>     existing table should be entered as URI schemes, with 'permanent'
>     status.
and says nothing about filling the Provisional registry. This should 
have caused this problem.
> (I know of no other way of changing things in the IETF, which is what I see as a
Such proposal is not very clear. What do you mean while saying 'registry 
per RFC1738'. Such registry is now replaced by what created by RFC4395. 
Moreover, since you propose to make it almost not controlled, possibly 
with the 'First Come First Served' policies will create great confusion. 
I do not think such idea is good.
> reinforcing the need for a Reserved category and placing those in it that should
During the discussion of this topic in December there was such a 
proposal - to create the special Reserved category, but this did not 
gain the support. Such category's scope is very contiguous with that for 
Provisional one.

Mykyta Yevstifeyev

---

From: Tony Hansen <[email-masked]>
Date: Tue, 08 Feb 2011 16:29:31 -0500

On 2/8/2011 10:46 AM, Mykyta Yevstifeyev wrote:
> Maybe IANA was guided by the following fact. While RFC 4395 mentions 
> the Provisional category, it does not give full definition of its 
> purpose. This might cause misunderstanding of community and other 
> interesting parties. IANA, due to lack of precise definition decided 
> that RFC 1738 reserves these names via their provisional registration. 
> Therefore they put it into corresponding category.
>
> Such proposal is not very clear. What do you mean while saying 
> 'registry per RFC1738'. Such registry is now replaced by what created 
> by RFC4395. Moreover, since you propose to make it almost not 
> controlled, possibly with the 'First Come First Served' policies will 
> create great confusion. I do not think such idea is good.
> gain the support. Such category's scope is very contiguous with that 
> for Provisional one.

I'm wondering if the authors of RFC 4395 (of which I'm one) should send 
a note to IANA saying that "afs" and "tn3270" should have been entered 
into the "Permanent" portion of the URI registry instead of the 
"Provisional" portion. (And then be done with the topic.)

     Tony Hansen
     [email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 09 Feb 2011 12:32:54 +0900

I'm cc'ing the IRI WG list. One of the deliverables of the IRI WG is an 
update of RFC 4395. You can see the current version at 
http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-00.

Given that there is a WG chartered to work on these issues, I suggest to 
move the discussion there.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Feb 2011 09:01:55 +0000

Tony Hansen wrote:

>> that RFC 1738 reserves these names via their provisional 
>> registration. Therefore they put it into corresponding category.
>>
> I'm wondering if the authors of RFC 4395 (of which I'm one) should 
> send a note to IANA saying that "afs" and "tn3270" should have been 
> entered into the "Permanent" portion of the URI registry instead of 
> the "Provisional" portion. (And then be done with the topic.)

While I personally like to be done with this topic, I don't think just 
declaring "afs"/"tn3270" permanent is Ok without having proper syntax 
specificications.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 9 Feb 2011 12:03:27 +0200

Hello all,

Let me cite the URI schmes regsitry from 28 November 2005

--- Citations starts----

Uniform Resource Identifier (URI) SCHEMES

(last updated 28 November 2005)

This is the Official IANA Registry of URI Schemes

In the Uniform Resource Identifier (URI) definition [RFC3986,RFC1738]
there is a field, called "scheme", to identify the type of resource
and access method.

[....]

Reserved URI Scheme Names:

   afs              Andrew File System global file names
   tn3270           Interactive 3270 emulation sessions
   mailserver       Access to data available from mail servers

---Citations ends---

And then from February 2007, provisional category:

---Ctation starts---

Index of /assignments/uri-schemes/prov
 Name                    Last modified       Size  Description
--------------------------------------------------------------------------------
 Parent Directory        23-Feb-2007 11:55      -
 iax2                    23-Feb-2007 11:54     3k

--------------------------------------------------------------------------------

Apache/1.3.27 Server at www.iana.org Port 80

---Citation ends----

The same is for Sepember 2007 and the latest archival entry from 23
October 2007 here:
http://web.archive.org/web/*/http://iana.org/assignments/uri-schemes

The question is - who added the sheme to the regsitry?

Mykyta Yevstifeyev

---

From: "t.petch" <[email-masked]>
Date: Wed, 9 Feb 2011 15:31:50 +0100

----- Original Message ----- 
From: "Tony Hansen" <[email-masked]>
To: "Mykyta Yevstifeyev" <[email-masked]>
Cc: <[email-masked]>; "URI" <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 08, 2011 10:29 PM

<snip>

> "Provisional" portion. (And then be done with the topic.)

Tony

It would be a step forward, but it would still leave the problem that the IANA 
website refers enquirers to RFC1738 which patently does not meet the 
requirements of RFC4395, which is why I see the choice as 
- either having a new category which is best efforts and does not come
up to RFC4395
- or producing an RFC which takes the schemes in question to Historic
or Provisional.

For me, the latter seems wasted effort, the former is the only one worth 
spending time on but perhaps someone has a third (or fourth) option.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Wed, 9 Feb 2011 15:41:41 +0100

----- Original Message -----
From: "Martin J. Dürst" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Larry Masinter" <[email-masked]>; "Ben Niven-Jenkins"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, February 09, 2011 4:32 AM

> move the discussion there.

Martin

Well, the IRI charter says produce a new version of RFC4395, but looking
at the details in the charter, I see no reference to RFC4395.

Looking at rfc4395bis, the changes I see are 'URI includes IRI'
which is good to have, but not really on the same scale as "let's
change the IANA categories".  I would expect the WG chairs
and AD to declare such activity ultra vires (but I might get
a pleasant surprise:-).

Tom Petch

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 10 Feb 2011 14:57:28 +0900

[Responding one more time here because this is a metadiscussion; please 
move the discussion to [email-masked] (the mailing list of the IETF 
IRI WG). Please also see 
http://trac.tools.ietf.org/wg/iri/trac/ticket/54 and 
http://trac.tools.ietf.org/wg/iri/trac/ticket/55 for the two issues this 
has resulted in]

On 2011/02/10 6:38, t.petch wrote:
> From: "Martin J. Dürst"<[email-masked]>
> To: "t.petch"<[email-masked]>
> Cc: "Larry Masinter"<[email-masked]>; "Ben Niven-Jenkins"
> <[email-masked]>;<[email-masked]>;<[email-masked]>

Yes, the charter contains no details about RFC4395, just that the WG 
will produce an update.

> change the IANA categories".

I don't think anybody has proposed a change in the categories itself. 
Some people just seem to have different ideas about what exactly the 
categories mean, so it's probably a good idea to clarify that. 
Clarifications of current text is about the lowest level of actual 
change I can imagine, and so I don't think there should be any problem 
with that. But of course I'm just a participant in that WG (and one of 
the editors of the other document of the WG), so it's ultimately not for 
me to decide.

As for the move of specific 'orphaned' schemes from one category to the 
other, I also see that as a very small scale issue.

> I would expect the WG chairs

I'd definitely like to hear from the WG chairs or the AD(s), but maybe 
first we have to have some discussion in the WG to see where we are 
headed, and to what extent we might potentially jump out of our charter 
fence.

Regards,   Martin.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 Feb 2011 09:54:03 +0000

Martin J. Dürst wrote:

> [Responding one more time here because this is a metadiscussion; 
> please move the discussion to [email-masked] (the mailing list of 
> the IETF IRI WG). Please also see 
> http://trac.tools.ietf.org/wg/iri/trac/ticket/55 for the two issues 
> this has resulted in]
>
 [...]

> headed, and to what extent we might potentially jump out of our 
> charter fence.

I think this is sensible. And if the WG comes to rough consensus that 
some procedure changes are needed, I am sure that one of your friendly 
ADs will be willing to help you out with rechartering, etc.

And of course it is up to the IRI WG chairs to decide if this discussion 
is appropriate for the IRI WG mailing list.

---

From: Graham Klyne <[email-masked]>
Date: Thu, 10 Feb 2011 10:34:48 +0000

Martin J. Dürst wrote:
> [Responding one more time here because this is a metadiscussion]

[Ditto, and also maybe affects the header registry 
(http://tools.ietf.org/html/rfc3864)]

What happened to "rough consensus and running code"?

As a reviewer, I sometimes make a recommendation that is in the spirit of the 
proposal even if not explicitly covered by the letter, but also alerting the 
relevant IESG director if I do so.  I think this is very much in the IETF spirit 
of "do the right thing".

For the message header registry, there some "weasel words" to allow some 
flexibility in section 4.4 that were intended to help circumvent unnecessary 
process-wrangling, ending with "The IESG is the final arbiter of any objection."

It seems to me that if the IANA+reviewer make a visible disposition that nobody 
objects to, the easiest thing is to just do it.

I'm not sure if it's necessary, but one might consider a minor update up the 
registration RFC(s) to provide this lattitude more explicitly, with further 
effort to be expended only in the event of an objection.  At some point, we need 
to trust the process participants (reserving the option to verify), or we get 
nowhere.

#g
--

---

From: Tony Hansen <[email-masked]>
Date: Thu, 10 Feb 2011 11:17:07 -0500

On 2/10/2011 5:34 AM, Graham Klyne wrote:
> As a reviewer, I sometimes make a recommendation that is in the spirit 
> of the proposal even if not explicitly covered by the letter, but also 
> alerting the relevant IESG director if I do so.  I think this is very 
> much in the IETF spirit of "do the right thing".
>
> For the message header registry, there some "weasel words" to allow 
> some flexibility in section 4.4 that were intended to help circumvent 
> unnecessary process-wrangling, ending with "The IESG is the final 
> arbiter of any objection."
>
> It seems to me that if the IANA+reviewer make a visible disposition 
> that nobody objects to, the easiest thing is to just do it.
>
> I'm not sure if it's necessary, but one might consider a minor update 
> up the registration RFC(s) to provide this lattitude more explicitly, 
> with further effort to be expended only in the event of an objection.  
> At some point, we need to trust the process participants (reserving 
> the option to verify), or we get nowhere.

+1

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 14 Feb 2011 10:42:03 +0900

Hello Graham,

> (http://tools.ietf.org/html/rfc3864)]

Only to the apps-discuss list this time, because the IRI list already 
got it.

I have opened an issue for this, please see
http://trac.tools.ietf.org/wg/iri/trac/ticket/57.

Regards,   Martin.

> flexibility in section 4.4 that were intended to help circumvent
> It seems to me that if the IANA+reviewer make a visible disposition that
> nobody objects to, the easiest thing is to just do it.
>
> I'm not sure if it's necessary, but one might consider a minor update up
> the registration RFC(s) to provide this lattitude more explicitly, with
> further effort to be expended only in the event of an objection. At some
> point, we need to trust the process participants (reserving the option
> to verify), or we get nowhere.
>
> #g
> --