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
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
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.
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
Jari,
As I've told Larry, and as Margaret and you both say, there are two
ways forward:
1. The proponents submit an I-D and ask the IETF to review it.
The IETF's IPR rules would apply.
2. Another standards body sends a liaison to the IETF asking for
an assignment, backed up by a publicly
Hi Larry,
At 12:30 PM -0700 6/25/05, Dr. Lawrence G. Roberts wrote:
I need help as to any process that can mitigate this major conflict
with the TIA/ITU and the IETF and I need to act now. Please send
your thoughts,
I was looking back over this thread, and I just happened to notice
this
Hi Margaret,
And thanks for posting constructive suggestions for moving
forward on this issue!
What you say below makes sense. However, it occurs to me that
there's also another possibility which has perhaps more commonly
been used when IETF works together with other standards bodies,
and has
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
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, 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
--On Wednesday, 29 June, 2005 01:04 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
John, I'm probably replying out of sequence, and I'll say this
once
again only:
I don't believe that the IESG is entitled, under the BCP in
force,
to authorise the IANA to assign a hop by hop option
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
Larry,
One thing that may not be immediately obvious is that if the IETF
reviews a contribution (whether it's an Internet-Draft or an email),
it automatically falls under IETF IPR rules. Alternatively, if another
SDO sends a liaison requesting IETF review of their document, we
presume that the
Yakov asks:
What was the reason(s) the request was made for an assignment
that required IESG Approval, rather than either Specification
Required or First Come First Serve ?
it semed to be the right thing at the time
it seemed to be too lose to have the IETF out of the loop
when changing one
John, as I understand it, the IESG believed it was turning down this
specific request. The IESG believes this option will never be
assigned through the IESG review process. I don't think the IESG did
turn down the option of IETF consensus nor the option of standards
action. I do not believe the
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_
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
Yakov Rekhter wrote:
Ned,
To state that somewhat differently, since we cannot effectively
prohibit the deployment of an extension or option of which the
IETF disapproves, the best things we can do for the Internet are
make it as easy as possible to identify the use of the extension
so it can
Ned,
The document on my packet.cc web site is certenatly close enough to the
final ITU documents attached (which I sent to Brian) that there should be
no trouble reviewing it for the concepts. The attached documents are the
latest ITU documents and the TIA 1039 document is identical in content.
--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
Brian - I think part of my difficulty in understanding what has
transpired is that the process was truly invisible and what little
written record exists is misleading. I now infer that the initial entry
in the minutes of the IESG meeting of 2005-04-14 records that Allison
took responsibility for
--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
John - as a concrete example of the problem you describe, the dhc WG
perceived that there was a looming problem with exhaustion of the DHCP
option code space. So, we wrote up a procedure (RFC 2939) requiring
documentation of new options in an RFC, implying technical review by the
dhc WG. Now, we
Allison...
On Sun, 2005-06-26 at 10:22 -0700, Allison Mankin wrote:
Ralph,
Under RFC 2780, IPv6 hop-by-hop option numbers are granted
either with an approved IETF document, or an IESG review.
It seems that neither the reference to IESG review in RFC 2780, nor the
definition of IESG review
Scott,
The discussion in SG12 was where the work should be done. The concept was
accepted but, being a QoS group, the details were left for SG13. The
submission to SG 13 was slightly improved, but how much was from the
discussion I am not clear about. But thats the function of such
meetings.
I
Ralph,
Are you saying that the vendor community interprets registration delay
as damage, and routes around it?
Spencer
John - as a concrete example of the problem you describe, the dhc WG
perceived that there was a looming problem with exhaustion of the
DHCP
option code space. So, we
Ralph,
Are you saying that the vendor community interprets registration delay
as damage, and routes around it?
or maybe, the vendor community insists on inflicting damage?
Keith
___
Ietf mailing list
Ietf@ietf.org
On Tue, 2005-06-28 at 00:15, Scott W Brim wrote:
In SG13 there was considerable debate, and at the end the
group *allowed* exploration of the topic through development through a
new draft recommendation.
assuming, for sake of argument, that the general proposal makes
sense[1], it sounds like
Bill...
On Tue, 2005-06-28 at 10:23 -0400, Bill Sommerfeld wrote:
On Tue, 2005-06-28 at 00:15, Scott W Brim wrote:
In SG13 there was considerable debate, and at the end the
group *allowed* exploration of the topic through development through a
new draft recommendation.
assuming, for
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 --
Date:Tue, 28 Jun 2005 10:23:47 -0400
From:Bill Sommerfeld [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| assigning a final IPv6 option codepoint might actually be
| counterproductive (as early behavior might be cast in code, concrete, or
| silicon and forever
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-
Date:Tue, 28 Jun 2005 00:16:56 +0200
From:Brian E Carpenter [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| Yakov Rekhter wrote:
| What was the reason(s) the request was made for an assignment
| that required IESG Approval, rather than either Specification
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
Allison - in pervious e-mail to you, I made the statement blaming the
tools is a pretty lame excuse, which makes several unwarranted
assumptions about motivations and the constraints within which the IESG
works. I could have expressed my frustration with the lack of clarity
and detail in the
Rob,
| is whether the proposed mechanism will interfere
| with existing or other proposed mechanisms.
This is totally irrelevant. We're talking about an option. Options,
by their very nature are optional. If use of an option interferes
with some other processing that you require,
Eliot,
There are at least two things that are wrong with the model you
describe below,...
(1) The assignment of address space, and the whole
notion of private networks with specialized space, are
not just options to a protocol, regardless of whatever
else they
Date:Tue, 28 Jun 2005 20:13:20 +0200
From:Eliot Lear [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| Let's look at an analogy that worked just as you suggest: the assignment
| of 10/8 172.16/16 and 192.168/16 in RFC 1597.
They'e not options. There's no
--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
Please see below:
Whether that discussion amounted to consensus or not
I wouldn't like to say after all of this time, but it certainly occurred.
Not publicly. Certainly there was a problem. Indeed someone (I forget
who) had made a request for a /8, which forced the issue.
| What
_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
John, I'm probably replying out of sequence, and I'll say this once
again only:
I don't believe that the IESG is entitled, under the BCP in force,
to authorise the IANA to assign a hop by hop option number to
a usage that we believe clearly needs IETF technical review.
So we don't go to question
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
To whatever small degree it matters, I agree with Brian on this.
There have been many clear statements indicating that the writer believes
that the policy in force for the allocation of these code points is
wrong. The policy may be right, and it may be wrong. But that is not the
point.
But
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
Date:Tue, 28 Jun 2005 23:21:35 +0200
From:Eliot Lear [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| Not publicly. Certainly there was a problem. Indeed someone (I forget
| who) had made a request for a /8, which forced the issue.
At the time 1597 was being
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
procedures.
Steve Silverman
-Original Message-
From: [EMAIL PROTECTED]
[ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Behalf Of Ralph
Droms
Sent: Friday, June 24, 2005 6:42 PM
To: IESG
Cc: [EMAIL PROTECTED]; IETF Announcement list
Subject: Re: IANA Action: Assignment of an IPV6 Hop
Vinton G. Cerf wrote:
I want to clarify something here. IANA is not at fault. It submits
requests like this to IESG to assure that there is consistency in
standards work. In the past there have been attempts to circumvent
standards work that is under way by directly submitting requests to
Ralph,
I'm not sure I understand your question. This is the IETF so
we take decisions by on line deliberation inside the IESG
just as much as any WG does, and the minutes or IESG announcements
are the public record. And this decision, and the formulation
of the response to IANA and the
All,
To address some misunderstandings of IANA's role in this action, Dr.
Roberts requested a hop-by-hop option number from section 5b in the
following registry: http://www.iana.org/assignments/ipv6-parameters.
Currently, the registration rule for this particular registry is IESG
Approval,
On one point (since it was mentioned in other thread as well):
(ii) For the reasons above and in my earlier note, I think the
IESG, and the IETF more broadly, must exert great caution in
rejecting a registration request and must exert that caution in
public. For example, the language of
Ned,
To state that somewhat differently, since we cannot effectively
prohibit the deployment of an extension or option of which the
IETF disapproves, the best things we can do for the Internet are
make it as easy as possible to identify the use of the extension
so it can be effectively
Dave Crocker wrote:
Vinton G. Cerf wrote:
I want to clarify something here. IANA is not at fault. It submits
requests like this to IESG to assure that there is consistency in
standards work. In the past there have been attempts to circumvent
standards work that is under way by directly
--On Monday, 27 June, 2005 17:00 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
The debate (except that since the work hadn't been brought to
the IETF,
the debate hasn't happened) is whether the proposed mechanism
will interfere
with existing or other proposed mechanisms. It isn't about
Date:Mon, 27 Jun 2005 17:00:22 +0200
From:Brian E Carpenter [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| The debate (except that since the work hadn't been brought to the IETF,
| the debate hasn't happened)
Except that it has been reported that the work was
Date:Mon, 27 Jun 2005 09:26:46 -0700
From:Barbara Roseman [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| To address some misunderstandings of IANA's role in this action, [...]
I hadn't actually noted any. As best I can recall, there neither has
been, nor
On Sat, Jun 25, 2005 12:30:44PM -0700, Dr. Lawrence G. Roberts allegedly wrote:
Steve,
Thank you for your thoughts. I am not sure about the next step, but I can
clarify some of the points that were unclear.
British Telecom submitted it to the ITU SG12 in January and we had
unanimous
Date:Mon, 27 Jun 2005 13:28:24 -0400
From:Thomas Narten [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| What 2434 says about IESG approval is:
|
|IESG Approval - New assignments must be approved by the IESG, but
| there is no requirement
Vinton G. Cerf wrote:
I want to clarify something here. IANA is not at fault. It submits requests
like this to IESG to assure that there is consistency in
standards work. In the past there have been attempts to circumvent standards
work that is under way by directly submitting requests
to IANA
Ralph,
Ralph Droms wrote:
I'd like to understand the process through which Dr. Roberts' request
was reviewed. The first reference I can find to Dr. Roberts' request is
in the 2005-04-14 minutes of the IESG
(https://datatracker.ietf.org/public/view_telechat_minute.cgi?
command=view_minuteid=318
John Leslie wrote:
Thomas Narten [EMAIL PROTECTED] wrote:
...
The right thing to do is to have this document reviewed proper in the
IETF and then let the IETF decide what it wants to do with it.
Then why don't we do that?
There has never been an Internet-Draft or other form of IETF
1 - 100 of 111 matches
Mail list logo
