Keith Moore wrote:
If IESG people were to personally benefit from their exercise
of this privilege you'd have a valid gripe. But I don't
recall ever seeing this happen. If it does happen, I don't
think it happens very often.
Publishing mutually exclusive experimental RfCs simultaneously,
On Tue, 5 Jul 2005, Bruce Lilly wrote:
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
--On Tuesday, 05 July, 2005 08:47 -0700 Bill Manning
[EMAIL PROTECTED] wrote:
I don't believe that is true in this case, as long as RFC
2780 is in force.
Especially since there is a clear path for Larry Roberts to
ask for IETF consensus, which by definition would overrule
the IESG.
Hi Bruce,
Please consider what Stephan Casner says. I totally agree with his
response. I simply want to make a few comments.
I think you really should ask yourself how it comes that the current
process has been used in 6-7 years and for more than 70 registrations
without anyone raising any
Keith Moore wrote:
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
John C Klensin wrote:
--On Tuesday, 05 July, 2005 08:47 -0700 Bill Manning
[EMAIL PROTECTED] wrote:
I don't believe that is true in this case, as long as RFC
2780 is in force.
Especially since there is a clear path for Larry Roberts to
ask for IETF consensus, which by definition would
Ned Freed wrote:
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.
RFC 2434
Ned Freed wrote:
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.
Why
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
If IESG people were to personally benefit from their exercise of this
privilege you'd have a valid gripe.
Personal gain is not the only motive; power can be its own motive. The
gripes are validated by cases of abuse of privilege.
If there's no obvious personal interest, whether a particular
Brian E Carpenter wrote:
Ned Freed wrote:
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
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
In message [EMAIL PROTECTED], Joe Touch writes:
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
It seems like such considerations are, by definition, relevant only for
standards-track RFCs. It is not useful to require it for other documents.
Not at all -- code points can be assigned
Keith Moore wrote:
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
Keith Moore wrote:
If IESG people were to personally benefit from their exercise of this
privilege you'd have a valid gripe.
Personal gain is not the only motive; power can be its own motive. The
gripes are validated by cases of abuse of privilege.
If there's no obvious personal
Joe,
It seems like such [IANA] considerations are, by definition, relevant only for
standards-track RFCs. It is not useful to require it for other documents.
I think you're correct in general but this is not always the case.
Consider URI schemes. I think they're often informational, and in
On Jul 6, 2005, at 8:15 AM, Brian E Carpenter wrote:
RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does
discuss them, and we will need to form consensus about whether the RFC
Editor is required to retain them, as we discuss RFC2434bis. Which we
need to do fairly soon.
In my
2026 separates process management from _independent_ technical review,
IMO for good reason.
I think you're reading more emphasis on independence than was intended
in 2026. But this is also subjective.
History reminds us of the abuses of power that started with act first,
appeal later.
At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote:
RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss
them, and we will need to form consensus about whether the RFC Editor is
required to retain them, as we discuss RFC2434bis.
I don't see any discussion of the RFC Editor
Date: 2005-07-06 04:06
From: Stephen Casner [EMAIL PROTECTED]
Stephen, you wrote:
That's not it. Of course all the existing registrations would be
copied. However, all of the many RTP-related RFCs that refer to MIME
registrations would become obsolete and need to be revised. A fair
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Moore wrote:
2026 separates process management from _independent_ technical review,
IMO for good reason.
I think you're reading more emphasis on independence than was intended
in 2026. But this is also subjective.
History reminds us
--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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Moore wrote:
External reviews are what I'm favoring - external, independent reviews.
so when IESG provides the external review, that's bad, but when someone
else does external review, that's good?
Yup. When judges decide cases, that's
External reviews are what I'm favoring - external, independent reviews.
so when IESG provides the external review, that's bad, but when someone
else does external review, that's good? I disagree. part of IESG's purpose
is to do review from a broad perspective.
On Jul 6, 2005, at 11:20 AM, Ned Freed wrote:
This is exactly what I predicted would happen - the IANA
considerations section has now become part of the boilerplate in at
least one I-D template. (Actually make that two - I put in in my own
equivalent template some time back.)
This opens the
External reviews are what I'm favoring - external, independent reviews.
so when IESG provides the external review, that's bad, but when someone
else does external review, that's good?
Yup. When judges decide cases, that's bad. When juries do, that's good.
not necessarily. judges can
On Jul 6, 2005, at 8:15 AM, Brian E Carpenter wrote:
RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does
discuss them, and we will need to form consensus about whether the RFC
Editor is required to retain them, as we discuss RFC2434bis. Which we
need to do fairly soon.
In
On Jul 6, 2005, at 11:20 AM, Ned Freed wrote:
This is exactly what I predicted would happen - the IANA
considerations section has now become part of the boilerplate in at
least one I-D template. (Actually make that two - I put in in my own
equivalent template some time back.)
This opens
On Wed, Jul 06, 2005 at 05:24:40PM +0200, Brian E Carpenter wrote:
John C Klensin wrote:
--On Tuesday, 05 July, 2005 08:47 -0700 Bill Manning
[EMAIL PROTECTED] wrote:
I don't believe that is true in this case, as long as RFC
2780 is in force.
Especially since there is a clear path for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ned Freed wrote:
On Jul 6, 2005, at 8:15 AM, Brian E Carpenter wrote:
RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does
discuss them, and we will need to form consensus about whether the RFC
Editor is required to retain
This opens the door to the author forgetting to check and the various
reviewers assuming the prsence of the sections means a check was done.
The goal of putting it in the template is to encourage it be addressed,
rather than forgotten altogether.
I am well aware of what the goal is, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ned Freed wrote:
This opens the door to the author forgetting to check and the various
reviewers assuming the prsence of the sections means a check was done.
The goal of putting it in the template is to encourage it be addressed,
rather than
Date: 2005-07-06 16:16
From: Joe Touch [EMAIL PROTECTED]
Ned Freed wrote:
This is exactly what I predicted would happen - the IANA considerations
section
has now become part of the boilerplate in at least one I-D template.
(Actually
make that two - I put in in my own equivalent
* harmful, and that the best way to insure coverage of IANA issues is to
have an
* explicit check for such things as part of our review process.
*
Ned,
As I expect you know, the IANA checks all documents at Last Call time,
and the RFC Editor checks them before publication, for missing
On Jul 6, 2005, at 2:19 PM, Bruce Lilly wrote:
This memo adds no new IANA considerations. The presence of this
template text indicates that the author/editor has not actually
reviewed IANA considerations.
I like it. Consider my template to have changed.
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
* harmful, and that the best way to insure coverage of IANA issues is to
have an
* explicit check for such things as part of our review process.
*
As I expect you know, the IANA checks all documents at Last Call time,
and the RFC Editor checks them before publication, for missing
--On Wednesday, 06 July, 2005 15:23 -0700 Bob Braden
[EMAIL PROTECTED] wrote:
* harmful, and that the best way to insure coverage of IANA
issues is to have an * explicit check for such things as
part of our review process.
Ned,
As I expect you know, the IANA checks all documents at
Date: 2005-07-06 16:16
From: Joe Touch [EMAIL PROTECTED]
Ned Freed wrote:
This is exactly what I predicted would happen - the IANA considerations
section
has now become part of the boilerplate in at least one I-D template.
(Actually
make that two - I put in in my own
John C Klensin wrote:
--On Wednesday, 06 July, 2005 15:23 -0700 Bob Braden
[EMAIL PROTECTED] wrote:
* harmful, and that the best way to insure coverage of IANA
issues is to have an * explicit check for such things as
part of our review process.
Ned,
As I expect you know, the
--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
That said, I think we should be paying careful attention to
Bruce's implied suggestion about how template
boilerplate-generators should be constructed. In terms of the
checking process Ned asks for (and which I still believe is the
right solution) there is a world of difference between a
Bruce Lilly wrote:
Date: 2005-07-06 16:16
From: Joe Touch [EMAIL PROTECTED]
...
However, I'm not at all in favor of requirements to IDs that are added
ad-hoc; until this actually makes it into an RFC as a formal
requirement, it won't be in the word template I manage.
I wouldn't call it
The IESG has received a request from the Layer 3 Virtual Private Networks WG
to consider the following document:
- 'Constrained VPN Route Distribution '
draft-ietf-l3vpn-rt-constrain-02.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from the Pseudo Wire Emulation Edge to Edge WG
to consider the following document:
- 'Pseudowire Setup and Maintenance using the Label Distribution Protocol '
draft-ietf-pwe3-control-protocol-17.txt as a Proposed Standard
The IESG plans to make a decision in
The IESG has received a request from the Pseudo Wire Emulation Edge to Edge WG
to consider the following document:
- 'Encapsulation Methods for Transport of Ethernet Over MPLS Networks '
draft-ietf-pwe3-ethernet-encap-10.txt as a Proposed Standard
The IESG plans to make a decision in the
The IESG has approved the following document:
- 'IPv6 Host to Router Load Sharing '
draft-ietf-ipv6-host-load-sharing-04.txt as a Proposed Standard
This document is the product of the IP Version 6 Working Group Working Group.
The IESG contact persons are Margaret Wasserman and Mark
47 matches
Mail list logo
