On Fri, 8 Jul 2005, Robert Elz wrote:
The relevant part is from section 2, basicly all of page 5 of the doc.
...
Everything between is about documentation requirements, just read
them ...
...
New assignments must be approved by the IESG, but
there is no requirement that the
Date:Thu, 7 Jul 2005 22:25:18 -0700 (PDT)
From:C. M. Heard [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| Would it be unreasonable to ask that you point to some text in the
| document to support your claim? Or lacking that, to point to some
| publically
Date:Wed, 06 Jul 2005 17:28:28 +0200
From:Brian E Carpenter [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| Well, that is not how I read the text in RFC 2460. It's pretty clear
| to me that there are only 32 option codes and that the other three bits
| don't
On Thu, 7 Jul 2005, Robert Elze wrote:
The question is what the words in 2434 (to which 2780 refers)
actually mean.
To me, and apparently to some others, it is clear that 2434 is
all about what amount of documentation is required to get IANA
to register an option, and who gets to judge that
grenville armitage wrote:
Brian E Carpenter wrote:
grenville armitage wrote:
...
My only concern is that we're using codepoint assignment denial as a
means
of protecting the Internet from poor, TCP-unfriendly end2end algorithms.
Who's we? The IESG said that the IESG wasn't going to
Robert Elz wrote:
Date:Tue, 5 Jul 2005 00:58:36 -0700
From:Christian Huitema [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| The problem is the really small size of the option type field in IPv6.
| There really only are 5 bits available for numbering both the
--On Wednesday, 06 July, 2005 17:28 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
It isn't really that bad, the option with 17 in the low 5
bits and 0 in the upper 3 is a different option than the one
with 17 in the low 5 bits and 7 in the upper 3.
So, really there are 8 distint groups
John C Klensin [EMAIL PROTECTED] wrote:
--On Wednesday, 06 July, 2005 17:28 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
[Robert Elz wrote:]
It isn't really that bad, the option with 17 in the low 5
bits and 0 in the upper 3 is a different option than the one
with 17 in the low 5 bits
--On Wednesday, 06 July, 2005 20:37 -0400 John Leslie
[EMAIL PROTECTED] wrote:
John C Klensin [EMAIL PROTECTED] wrote:
--On Wednesday, 06 July, 2005 17:28 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
[Robert Elz wrote:]
It isn't really that bad, the option with 17 in the low 5
bits
Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Keith Moore
Sent: Monday, July 04, 2005 3:50 AM
To: Robert Elz
Cc: Margaret Wasserman; ietf@ietf.org; grenville armitage
Subject: Re: RFC 2434 term IESG approval (Re: IANA Action: Assignment of
an IPV6 Hop-by-hop Option
I think as has already been suggested we are having two different
discussions masquerade as one. I obviously can't speak for Robert but
it
seems to me he is not saying the IESG ought to approve every (or any)
extension of IP, he is merely saying each should have an option number
assigned.
Oh, great...
As Harald noted, draft-klensin-iana-reg-policy is pretty prescriptive
about saying that if we're in conservation mode for a registry, we
also need to be in evasive-action mode (how do we get more room in
this registry?).
If we are already in conservation mode on IPv6 options,
Brian E Carpenter wrote:
grenville armitage wrote:
...
My only concern is that we're using codepoint assignment denial as a
means
of protecting the Internet from poor, TCP-unfriendly end2end algorithms.
Who's we? The IESG said that the IESG wasn't going to approve a
codepoint,
and that
Robert Elz wrote:
Date:Wed, 29 Jun 2005 17:39:37 -0400
From:Margaret Wasserman [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| The arguments against what the IESG has done seem,
| mostly, to be that we should have gotten IETF consensus before
| making a
grenville armitage wrote:
...
My only concern is that we're using codepoint assignment denial as a means
of protecting the Internet from poor, TCP-unfriendly end2end algorithms.
Who's we? The IESG said that the IESG wasn't going to approve a codepoint,
and that the only way to get it approved
Pete Resnick wrote:
...
Personally, I find nothing in 2026 which indicates in the best
interests of the IETF and the Internet as a criteria for the IESG to
evaluate much of anything. And I think that is part of the concern you
are hearing expressed in the objections to the decision process.
On Tue, Jul 05, 2005 at 07:02:11AM -0500, Spencer Dawkins wrote:
Oh, great...
As Harald noted, draft-klensin-iana-reg-policy is pretty prescriptive
about saying that if we're in conservation mode for a registry, we
also need to be in evasive-action mode (how do we get more room in
this
Date:Tue, 5 Jul 2005 00:58:36 -0700
From:Christian Huitema [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| The problem is the really small size of the option type field in IPv6.
| There really only are 5 bits available for numbering both the hop by hop
| and
--On Tuesday, 05 July, 2005 15:09 -0400 Theodore Ts'o
[EMAIL PROTECTED] wrote:
...
People seem to be forgetting that the 'E' in IETF standards
Engineering, and that infinitely expandable registries in
order to obviate the need for responsible registration of code
points may not necessarily
Date:Fri, 1 Jul 2005 15:16:09 -0400
From:Margaret Wasserman [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| In what way would that differ from Specification Required?
See below.
| No. That one (Specification Required) explicitly states that the
| document
The problem is that the IETF, and the IESG in particular, sees a protocol,
sees it is planned to be used with internet related protocols, and so
perhaps on some part of the internet, and decides that's ours, we must
be the ones to decide whether that is any good or not, now how do we force
that
Date:Wed, 29 Jun 2005 17:39:37 -0400
From:Margaret Wasserman [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| The arguments against what the IESG has done seem,
| mostly, to be that we should have gotten IETF consensus before
| making a decision.
That is
Date:Thu, 30 Jun 2005 18:50:01 -0400
From:Jeffrey Hutzelman [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| Have you read the spec in question?
I have not, and I expressly will not, because that cannot possibly be
relevant.
| The issue is not that the presence
Scott,
--On 29. juni 2005 19:22 -0400 Scott Bradner [EMAIL PROTECTED] wrote:
It's not a hard concept. It just isn't mentioned or implied in RFC 2780.
neither is not drinking gasoline but I trust that will not change
your desire to not do so
while Brian and the IESG have certainly chosen
--On fredag, juli 01, 2005 19:20:37 +0700 Robert Elz [EMAIL PROTECTED]
wrote:
Date:Fri, 01 Jul 2005 12:26:31 +0200
From:Harald Tveit Alvestrand [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| So we've got two possible interpretations:
|
| - The authors
On Fri, Jul 01, 2005 at 07:20:37PM +0700, Robert Elz wrote:
I do not agree. To me, everything in 2434 is talking about what level
of documentation should be required to register a parameter (code point,
whatever you want to call it) via the IANA. The IESG approval
section contains
Hi,
At 12:53 PM +0700 7/1/05, Robert Elz wrote:
Failing to register whatever parameter they need, because the protocol
proposed is disgusting, even if true, helps absolutely no-one. On
the other hand, if the documentation of what the parameter means, or
how to use it, is inadequate, then
Date:Fri, 01 Jul 2005 16:14:54 +0200
From:Harald Tveit Alvestrand [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| I don't agree, which is no surprise.
Not really!
| RFC 2434 also says (section 2):
|
|One way to insure community review of prospective
Date:Fri, 1 Jul 2005 11:24:42 -0400
From:Theodore Ts'o [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| So if someone documented a code point in a registry with a scares
| number of available code points which was actively harmful to the
| entire
Date:Fri, 1 Jul 2005 11:39:05 -0400
From:Margaret Wasserman [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| You seem to be arguing that the only thing that the IESG _should_
| have done regarding this allocation was to determine whether or not a
| document
Hi Robert,
At 1:18 AM +0700 7/2/05, Robert Elz wrote:
| You seem to be arguing that the only thing that the IESG _should_
| have done regarding this allocation was to determine whether or not a
| document exists.
No, I didn't say that at all, ever. What I said was that the IESG should
On Sat, Jul 02, 2005 at 01:18:31AM +0700, Robert Elz wrote:
Date:Fri, 1 Jul 2005 11:39:05 -0400
From:Margaret Wasserman [EMAIL PROTECTED]
No, I didn't say that at all, ever. What I said was that the IESG should
have determined whether there was adequate
On 7/1/05 at 3:16 PM -0400, Margaret Wasserman wrote:
At 1:18 AM +0700 7/2/05, Robert Elz wrote:
...the IESG should have determined whether there was adequate
documentation for the option. That is, whether the documentation
was clear, unambiguous, complete, and would allow an implementation
Jeffrey Hutzelman wrote:
On Friday, July 01, 2005 07:58:42 AM +1000 grenville armitage
[EMAIL PROTECTED] wrote:
[..]
Scenario (a) would seem to be solved by assigned a non-conflicting option
codepoint and then hoping the competing protocol dies of irrelevance.
Scenario (b) suggests we
Jefsey,
Many of us await, with great interest, the appearance of an
Internet Draft from you that explains how, with a field with a
finite (and fairly small) number of bits available, once can
carry out an arbitrary number of properly-identified
experiments. Even a discussion about how one might
Hans,
I think this formulation is consistent with what I, and others,
have been trying to say. I would, however, add one element.
The IESG was asked to approve a code point for work developed
elsewhere. There is no question that they could have approved
it and approved it on the basis of the
Dear John,
the subject is of importance and cannot be dealt with an individual's draft
in Franglish. Qui va piano va sano, doucment, doucement nous sommes
pressés (Talleyrand).
As a liaison to ICANN BoD you know that the criteria I quote are those
(reviewed by a two years experiment) of the
Hans Kruse wrote:
...
but otherwise I _cannot_ see how the _content_ of the option could harm a device that does not want to deal with it.
If it interferes with congestion management elsewhere along the path, it can
potentially damage
every other packet stream. This is a *very* complex
On Wednesday, June 29, 2005 04:18:18 PM -0400 Margaret Wasserman
[EMAIL PROTECTED] wrote:
I don't think the fact that the IESG did not choose to exercise its
authority to allocate this IP option number precludes the proponents of
this allocation from attempting to gain IETF consensus (for
Brian E Carpenter wrote:
Hans Kruse wrote:
...
but otherwise I _cannot_ see how the _content_ of the option could
harm a device that does not want to deal with it.
If it interferes with congestion management elsewhere along the path, it
can potentially damage
every other packet stream.
On Friday, July 01, 2005 07:58:42 AM +1000 grenville armitage
[EMAIL PROTECTED] wrote:
Brian E Carpenter wrote:
Hans Kruse wrote:
...
but otherwise I _cannot_ see how the _content_ of the option could
harm a device that does not want to deal with it.
If it interferes with congestion
--On Tuesday, 28 June, 2005 21:16 -0700 Randy Presuhn
[EMAIL PROTECTED] wrote:
...
More untruths. The working group's members include Harald
Alvestrand, and John Klensin, to name a few who know something
about the Internet standard process.
...
Randy,
Since you mentioned my name, to be
I am quite glad we cooperate to the outreach of the WG-ltru.
At 06:16 29/06/2005, Randy Presuhn wrote:
Yes. But we are missing experts in networking, Internet standard process,
multilingualism, national cultures, LDAP, standard document witing. This is
a actually complex issue (mix of
Sigh.
I, like John, have been following LTRU only with half an eye; it seemed to
be running fairly well, apart from the problems of dealing with Jefsey's
comments, but I haven't read the documents for quite some time.
But I'm confident enough about my reading of the mail in my mailbox to say
Just a quick (one-time I plan) note in support of John's position. I,
too, think it is counterproductive to avoid/deny registration in this
case. Maybe a slightly different way of saying it:
- A group of folks has designed an IP _option_ they intend to use
- They have documented the option
But the refusal of a code point is not effective, and in fact
counter-productive (since the option will indeed be deployed, you just
won't know what code point it self-assigned).
On Jun 28, 2005, at 23:10, Keith Moore wrote:
those are both valid concerns, but relatively minor concerns
Hans Kruse wrote:
But the refusal of a code point is not effective, and in fact
counter-productive (since the option will indeed be deployed, you just
won't know what code point it self-assigned).
that's not true in general. each situation is different.
the alternative - to blindly assign
we need to allow IESG to use some discretion here.
what *kind* of discretion?
should we allow the IESG the discretion to decide what they like or
don't like and then allow them the authority to make the decision based on that?
or, should we allow the IESG the discretion to note
As a matter of information, my habit is to ignore messages under a given
subject field that discuss something else, e.g. messages under a header
like 'RFC 2434 term IESG approval' that actually discuss language tags.
Brian
___
Ietf mailing list
we need to allow IESG to use some discretion here.
what *kind* of discretion?
should we allow the IESG the discretion to decide what they like or
don't like and then allow them the authority to make the decision based on
that?
IESG should have discretion to evaluate such
Margaret sed:
Personally, I think that if the IETF doesn't want to give the IESG
the right to approve (and refuse to approve) the allocation of IP
options, then the IETF should update RFC 2780.
for what it's worth (speaking as an IETFer, forment IESGer co-author of
RFC2780) - to me its
Hi Scott,
I agree that this would be a reasonable process, but wouldn't that be
IETF Consensus (an entirely separate choice in RFC 2434 from IESG
Approval)?
I said that I was confused... and this is the main point that is
confusing me. The arguments against what the IESG has done seem,
I agree that this would be a reasonable process, but wouldn't that be
IETF Consensus (an entirely separate choice in RFC 2434 from IESG
Approval)?
see RFC 2434
IETF Consensus - New values are assigned through the IETF
consensus process. Specifically, new assignments are
Dear Scott,
RFCs are made to be adapted to needs. The question should be what do we
want?. I think the response is to experiment. This means that every
registry should include an ad-experimendam area. If the experimentation is
OK it will permit to document the allocation of a code point
Values for the IPv6 Hop-by-Hop Options and Destination Options fields
are allocated using an IESG Approval, IETF Consensus or Standards
Action processes.
I read that as suggesting, in order, the groups who could _allocate_ a new
codepoint without requiring further review. But _not_
It's not a hard concept. It just isn't mentioned or implied in RFC 2780.
neither is not drinking gasoline but I trust that will not change
your desire to not do so
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Margaret,
my concerns (and those of others) are a bit different I think. Again,
I see what happened as:
1. A non-IETF standard is being developed.
2. The standard is being reviewed by another organization.
3. The group working on the standard requests a code point from IANA
The IESG review
(Changing the subject and flushing most of the CCs including the IESG. They
will probably read it anyway.)
As the other co-author of 2434, I want to point out that the term IESG
Approval was not invented by 2434.
In fact, a simple-minded grep for iesg approval shows that RFC 2048, the
first
--On Tuesday, 28 June, 2005 09:37 +0200 Harald Tveit Alvestrand
[EMAIL PROTECTED] wrote:
...
In fact, a simple-minded grep for iesg approval shows that
RFC 2048, the first MIME registration procedures, was the
first to use it, 2 years earlier; that only shows where I
cribbed the term from, I
--On tirsdag, juni 28, 2005 07:39:35 -0400 John C Klensin [EMAIL PROTECTED]
wrote:
To preview what would otherwise be a discussion on the new I-D,
here we disagree, for two reasons:
(i) For some registrations, especially those for which
there are no alternate registration
My personal opinion is that it's quite reasonable to require IESG
approval of an IP-level option. IMHO the IESG should solicit public
input before making such a decision, probably in the form of a Last
Call. But the potential for harm is such that somebody needs to have
the ability to say
Harald,
The presence of the X- option, and the fact that it can be
used among consenting parties without loss of function, puts
both of the cases you mention into the area of refusal means a
different choice of category not refusal encourages the
behavior to occur without proper identification.
Harald,
I have no strong opinion about the IPv6 hop-by-hop header in
question. But I don't want to (effectively) remove the ability
to refuse registration - I think we'll pay a high price for
that later.
I tend to agree. To me, IESG Approval in an IANA
considerations text means that we expect
We can reasonably delegate a determination of
definitional adequacy to an individual, but decisions
about good or bad, or recommendations to use or not
use something, require community consensus.
nice, simple language. seems to capture the distinction --
We can reasonably delegate a determination of
definitional adequacy to an individual, but decisions
about good or bad, or recommendations to use or not
use something, require community consensus.
nice, simple language. seems to capture the distinction -- and the
At 14:37 28/06/2005, Harald Tveit Alvestrand wrote:
1) The language tag reviewer (a designated expert) rejected the tag
es-americas after due debate on the ietf-languages mailing list.
(Debate led to the same functionality now being registered as es-419.
That namespace also allows for use of x-
Keith,
At 05:40 AM 06/28/2005, Keith Moore wrote:
My personal opinion is that it's quite reasonable to require IESG approval
of an IP-level option. IMHO the IESG should solicit public input before
making such a decision, probably in the form of a Last Call. But the
potential for harm is
--On Tuesday, June 28, 2005 09:48 -0700 Bob Hinden
[EMAIL PROTECTED] wrote:
Keith,
At 05:40 AM 06/28/2005, Keith Moore wrote:
My personal opinion is that it's quite reasonable to require
IESG approval of an IP-level option. IMHO the IESG should
solicit public input before making such a
Subject: Re: RFC 2434 term IESG approval (Re: IANA Action: Assignment of an
IPV6 Hop-by-hop Option)
...
2. this concerned list ([EMAIL PROTECTED]) is not an IETF list,
but an Harald Alvestrand's private mailing list. At least this what Harald
told me, to be able to ban me, without proper
_However_ if some rogue group comes along (and I hope that we
are a long distance from where Larry Roberts would be considered
a rogue group, even though I have disagreed about some things
he has advocated in the past and may do so in the future) and
has the resources and commitment to
Keith Moore wrote:
[..]
Basically I think we need to do whatever will be most effective at
discouraging the bad idea. If that means any of the following:
- not registering the idea, or
- registering the idea and clearly marking it as bad, or
- delaying registration of the idea until
This is a beautifull troll :-) However the good of the WG-ltru work calls
for short comments where we will probably partly agree.
At 22:23 28/06/2005, Randy Presuhn wrote:
The review of the management of the IANA langtag registry is subject to
the work of the WG-ltru.
In this case 'the idea' was we would like an option code point
assigned.
if that's all there is to the proposal, it should be rejected
out-of-hand without discussion.
I'd have thoughth the discussion should have been about whether there was an intention of deployment by the requestor (the
John C Klensin wrote:
[..]
snip
But the notion that the IETF can prevent something from happening or
being deployed by declining to register it, or by turning our
collective backs on it without any real explanation -- even at the
waist of the hourglass-- is, in this world, just
Keith Moore wrote:
In this case 'the idea' was we would like an option code point
assigned.
if that's all there is to the proposal, it should be rejected
out-of-hand without discussion.
who said that's all there was to the proposal? there was clearly a
proposed use. but the use factors
In this case 'the idea' was we would like an option code point
assigned.
if that's all there is to the proposal, it should be rejected
out-of-hand without discussion.
who said that's all there was to the proposal? there was clearly a
proposed use. but the use factors into the question only
Hi -
From: JFC (Jefsey) Morfin [EMAIL PROTECTED]
To: Randy Presuhn [EMAIL PROTECTED]; ietf@ietf.org
Sent: Tuesday, June 28, 2005 5:11 PM
Subject: Re: RFC 2434 term IESG approval (Re: IANA Action: Assignment of an
IPV6 Hop-by-hop Option)
...
Some members are linguists by training
77 matches
Mail list logo
