Folks,
One person has voiced concerns on my taking a strong public position
in the Should I* opinions be afforded a special status? thread while
serving as the chair of the 2007-8 nomcom. Perhaps there are others
with similar concerns.
The role of the nomcom chair is clearly described in
I realize we're well into meta-discussions here, but quite frankly I
find it refreshing that the NOMCOM chair is questioning the qualities
that an IESG should have. Not only do I think it appropriate, but I
hope that the selectees feel comfortable asking questions about these
sorts of things,
John C Klensin wrote:
To me, the fundamental question here is whether, in the last
analysis, we consider it more important to have
* the best and most extensive Internet interoperability
possible or
* a maximum of real or imagined IETF control over all
Lakshminath,
Just commenting from my own experience with views
about the BOF process...
I don't think the fact that someone is in the I* means
their opinions necessarily carries more weight than
other opinions.
This does not imply that all opinions carry the same
weight. Informed, well
Laksminath,
Let me stop being cynical and say that it would be worthwhile to iron
out the review criteria as clearly as possible.
I would support a document giving clearer guidelines
for this. Draft-narten-successful-bof already
outlines some of the things that a BOF proposal
should satisfy.
Dave and I appear to be in agreement here.
I have spent quite a bit of time thinking what the consequences of a default by
a registry of the IANA, ISBN, EUI (aka MAC address) type. My conclusion is:
virtually nil.
Let us imagine that the folk who assign EUI numbers decide that they are not
Fit might be the right criteria if the objective here is to have a nice jolly
time.
We have a rather serious responsibility here. Many of the best people in the
field are not exactly known for being easy to get along with.
-Original Message-
From: Ted Hardie [mailto:[EMAIL
I also have the experience that a too strict policy
can be harmful. I could cite numerous examples...
On the other hand, Thomas and Pasi are also right that
too loose policy can be harmful.
You have to remember that interoperability
can be hurt or improved in many ways. Secret
code allocations,
Phillip,
My personal view is that we should develop an Internet architecture that
allows an infinite number of new protocols to be deployed without consumption
of scarce resources, i.e. port numbers of DNS RRs.
...
So in summary, the IAB should be charged with identifying the set of finite
That is why I think this is an area that the IAB should look at.
I don't think we should be worried about running out of protocol numbers.
Deployment of IPv6 and multicast pretty much demonstrate that it is a non-issue.
At the application level we just need to persuade people that, no it is not
At 2:11 PM +0300 6/13/07, Jari Arkko wrote:
Yes -- but for clarification to others (I know you are aware of this), the
criteria are in active use by the IESG and often referred to when we
talk about some AD's discusses. The document was originally an
I-D (now expired), but is available from:
Can we please leave the specific opinions about DHCP out of this discussion?
The dhc WG has done its due diligence, with review and support from the IETF
and the IESG, to put into place processes to govern assignment of extensions
to DHCP and to accommodate future extensions to both DHCPv4 and
At 5:51 AM -0700 6/13/07, Hallam-Baker, Phillip wrote:
I have spent quite a bit of time thinking what the consequences of a
default by a registry of the IANA, ISBN, EUI (aka MAC address) type.
My conclusion is: virtually nil.
That kinda depends on what is part of that default. I would
At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote:
The hurdle of getting IETF consensus and publishing an RFC does
weed out many crazy proposals that, in all fairness, would not
have made the Internet work better, and would not have promoted
interoperability.
It does not need to promote
If the repository is active, rather than passive this is of course possible.
For example we might map out a DNS spec within the .arpa TLD and use it to
distribute machine readable descriptions of the code points. Something of the
sort could be done for EUI-48 and -64 space as well of course.
--On Wednesday, June 13, 2007 08:27 -0700 Paul Hoffman
[EMAIL PROTECTED] wrote:
At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote:
The hurdle of getting IETF consensus and publishing an RFC
does weed out many crazy proposals that, in all fairness,
would not have made the Internet work
Hi Vidya,
The following comment has been addressed already as part of Ted
Hardie's comments. A new API will be provided to select/bind the
preferred source address before connect().
Thanks,
-Samita
On 6/4/07, Narayanan, Vidya [EMAIL PROTECTED] wrote:
All,
I'm passing along a comment from one
Hi Jari,
Below are the additions in the OLD/New format.
-Rajeev
On 6/8/07 3:46 PM, Rajeev Koodli [EMAIL PROTECTED] wrote:
In Section 4.2 I believe you have to use RFC 2119 language for the
following text parts:
Home Address field must be the PCoA (which can be either the
Hi Hannes,
On 6/7/07 7:22 AM, ext Tschofenig, Hannes [EMAIL PROTECTED]
wrote:
A few minor comments:
In Section 4.2 I believe you have to use RFC 2119 language for the
following text parts:
Home Address field must be the PCoA (which can be either the
Home Address or the
On Mon, 11 Jun 2007, Barry Greene (bgreene) wrote:
I don't understand BCP. Information RFC yes. Something that can be use
for requirements yes. But Best Common Practice? How is an operator's I
wish my equipment can do this in my network become a BCP?
as an author I agree that BCP seems a
Sorry. Your message could not be delivered to:
Ralf Kreibig (Mailbox or Conference is full.)
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
I don't understand BCP. Information RFC yes. Something that can be use
for requirements yes. But Best Common Practice? How is an operator's I
wish my equipment can do this in my network become a BCP?
IESG - I think we are abusing the BCP system. It states:
A BCP document is subject to the
The recent discussion on the IFARE BOF has raised more fundamental issuesabout
the IETF BOF process. Rather than letting discussion continue on theSAAG list,
it would seem better for this discussion to occur on the IETF list. Speaking
as a former AD, it can be a very tough call to say yes/no
On 2007-06-13 17:18, Paul Hoffman wrote:
At 2:11 PM +0300 6/13/07, Jari Arkko wrote:
Yes -- but for clarification to others (I know you are aware of this),
the
criteria are in active use by the IESG and often referred to when we
talk about some AD's discusses. The document was originally an
[bcc'd someone from Verilan who can most likely comment on this :) ]
Jun-ichiro itojun Hagino wrote:
i'm wondering about IPv6 connectivity at chicago IETF69. if any
of you have hints about it, please drop me a note. if there's no
plan for IPv6, i'd be more than happy to
John Klensin,
You wrote:
*
* I think real specifications of what the requested parameter will
* mean and be used for are important. I think there is a
* difference between registering a parameter for a non-standard
* specification that is already deployed and in successful use
Bob Braden writes:
I would note that the purveyors of a non-standard specification that
is already deployed and in successful use must have somehow obtained
their own number assignment without the IANA's help, or this
situation could not arise. And before that specification was
successfully
I think that folk should decide where the scope of the IETF starts and ends.
The message I think that the IETF should be sending is 'we own layer 6 and
everything below'. I don't think that many people are really wanting to
perpetrate unauthorized innovations in those layers in any case.
In
One possibility, if one wants to get things through without modifying
current process, is to:
a) publish the specification as an independent submission
b) publish an one-line document, with IETF consensus, saying that the
codepoint x is for use with protocol Y, which is not an IETF protocol.
On Wed, 13 Jun 2007, Arnt Gulbrandsen wrote:
Cases like managesieve. Managesieve is almost a decade old and in real
use at many sites. Tens of thousands? Even more? No idea. The port it
uses was allocated to another purpose about four years after managesieve
was deployed.
The smtps port was
--On Wednesday, June 13, 2007 11:58 -0700 Bob Braden
[EMAIL PROTECTED] wrote:
John Klensin,
You wrote:
*
* I think real specifications of what the requested
parameter will* mean and be used for are important. I
think there is a* difference between registering a
parameter
Tony Finch wrote:
On Wed, 13 Jun 2007, Arnt Gulbrandsen wrote:
Cases like managesieve. Managesieve is almost a decade old and in real
use at many sites. Tens of thousands? Even more? No idea. The port it
uses was allocated to another purpose about four years after managesieve
was deployed.
--On Tuesday, June 12, 2007 14:22 -0700 Ted Hardie
[EMAIL PROTECTED] wrote:
...
That does not mean the IETF leadership is itself a
meritocracy; it's not. The IESG and IAB are picked by NomComs
for a variety of skills and fit is a critical one. Someone
who can fit into the team the NomCom
Paul Hoffman wrote:
At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote:
The hurdle of getting IETF consensus and publishing an RFC does
weed out many crazy proposals that, in all fairness, would not
have made the Internet work better, and would not have promoted
interoperability.
It does
A new IETF working group has been formed in the Operations and
Management Area. For additional information, please contact the Area
Directors or the WG Chairs.
+++
Operations and Management Area Working Group (opsawg)
==
Current Status: Active
The IESG has approved the following document:
- 'Mobile IPv4 Fast Handovers '
draft-ietf-mip4-fmipv4-07.txt as an Experimental RFC
This document is the product of the Mobility for IPv4 Working Group.
The IESG contact persons are Jari Arkko and Mark Townsley.
A URL of this Internet-Draft
A new Request for Comments is now available in online RFC libraries.
BCP 97
RFC 4897
Title: Handling Normative References to Standards-Track
Documents
Author: J. Klensin, S. Hartman
Status: Best Current Practice
The IESG has received a request from the Path Computation Element WG
(pce) to consider the following document:
- 'IS-IS protocol extensions for Path Computation Element (PCE)
Discovery'
draft-ietf-pce-disco-proto-isis-05.txt as a Proposed Standard
This last call is being repeated to clarify
38 matches
Mail list logo
