Keith (and anyone interested in this thread that doesn't have me on ignore),
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
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.
Hi,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
ext saravanan t s
Sent: 04 July, 2005 18:06
To: ietf@ietf.org; [EMAIL PROTECTED]
Subject: RE: Remote UI BoF at IETF63
Hi Vlad others
Just adding some opinions on this from my side, since I
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.
Robert Elz wrote:
...
Also remember that no consensus in an issue like this, really needs to
mean no authority - if you cannot get at least most of the community to
agree with the IESG position, then the IESG cannot just claim the
authority and say there is no consensus that we should not have
Thanks Ken (and those who have followed up). I don't think
there's any need to repeat the count - we can safely say
that opinions are divided.
Brian
Ken Carlberg wrote:
From: Brian E Carpenter
I'm supposed to be on vacation so this will be brief, but I don't
think that your assertion
John,
John C Klensin wrote:
...
However, consider instead the situation we find ourselves in. The IESG,
at least in the interpretation as given on this list by some of its
members, has said, essentially, We have concluded that this requires
technical review within the IETF before it is
Hi Vlad,
Thanks for the reply.
I will now go through the draft for a better understanding.
Regards,
Saravanan T S
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, July 05, 2005 1:31 PM
To: [EMAIL PROTECTED];
Further clarifications inline.
Robert Elz wrote:
Date:Fri, 01 Jul 2005 17:38:19 +0200
From:Magnus Westerlund [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
I understand everything you're saying, except this part...
| I do want to point out that how we RTP uses
Hi Bruce,
I will comment some of the arguments that you list. And if we where
having this discussion before any RTP payload name registry existed at
all I would definitely be tempted by separated registries. However the
fact that we have used an IETF established policy for more than 5 years
Talking about power saving, I think that the most important feature that we
have here is that the application logic is run entirely in the server side.
This thing will definitely save power and also will reduce the software
complexity of the client.
on the other hand, having all the
On Jul 5, 2005, at 2:32, Brian E Carpenter wrote:
Robert Elz wrote:
...
Also remember that no consensus in an issue like this, really needs
to
mean no authority - if you cannot get at least most of the
community to
agree with the IESG position, then the IESG cannot just claim the
authority
On Friday, July 01, 2005 11:32:41 AM +0200 Harald Tveit Alvestrand
[EMAIL PROTECTED] wrote:
But this too is a change; if the people writing the IANA considerations
section had desired public review of requests, they would presumably have
used IETF consensus as the registration criteria; to
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: 2005-07-05 11:18
From: Magnus Westerlund [EMAIL PROTECTED]
Magnus,
Comments in-line:
[...] registered a large amount of names (70) makes it very hard to see
that moving into separated registries will resolve any confusion. In
addition it will require a huge work effort to move to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Moore wrote:
Nothing like responsibility to look after the overall technical health of
the
Internet was assigned to the IESG.
You seem to be forgetting something, Dave.
Every IETF participant is supposed to use his best engineering
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Can anyone suggest where I could find the requirement for IANA
Considerations?
I found it on the website, but it's not listed in any RFC (just in an
expired ID, one that even mentions that empty IANA Considerations
sections may be dropped by the RFC
Can anyone suggest where I could find the requirement for IANA
Considerations?
There is no requirement that such sections appear in published RFCs. This
debate has never been about what's required in RFCs, but rather what's required
in drafts submitted to the IESG.
I found it on the website,
Keith,
The IESG can still exercise their best engineering judgment as
individuals, as the rest of us do.
The IESG role itself need not incorporate a privileged position from
which to wield that judgement. There's plenty left to do.
Joe,
The IESG has several duties that are defined in RFC
The IESG has received a request from an individual submitter to consider the
following document:
- 'MIME Type Registrations for 3GPP2 Multimedia files '
draft-garudadri-avt-3gpp2-mime-02.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
26 matches
Mail list logo
