Hi,
please note that the TSV and INT are sponsoring the following non-WG-
forming BOF in Montreal. We'd welcome any input you may have on the
scope or content of this BOF. This discussion should take place on
the BOF mailing list.
Thanks,
Lars
Dave Crocker wrote:
For #1, it removes the requirements for Last Call and
demonstration of community consensus that apply to BCPs.
In other words, these are IESG Operational Notes, not IETF Operational
Notes.
Not really; some of them would be issued not on IESG authority but
on
John,
John C Klensin wrote:
--On Thursday, 18 May, 2006 17:16 -0400 The IESG
[EMAIL PROTECTED] wrote:
The IESG has received a request from an individual submitter
to consider the following document:
- 'IETF Process and Operations Documentss '
draft-alvestrand-ipod-01.txt as an
C. M. Heard wrote:
On Thu, 1 Jun 2006, Eric Rosen wrote:
There are also other reasons why I find this proposed experiment
disheartening.
For one thing, it really misses the point. We need to simplify our
processes, not make them more complicated. Either we need the
... I believe the
RFC 3978 practice and the RFC 2026 variance process provides
adequate means publishing documents with such references.
Kurt, what's the relevance of RFC 3978? The current procedure
for downrefs is RFC 3967, as mentioned in the draft. The RFC 2026
variance process is
On 8-jun-2006, at 11:13, Iljitsch van Beijnum wrote:
But it's a clear trade-off between efficient representation and
complexity for the developer - we've had this debate once already
in this thread, I think. The more complex the representation, the
harder it is to code correctly and debug.
A little post script to this discussion: I wrote a few small test
programs in C to evaluate the performance of reading integers from
a text file using stdio.h versus doing the same with direct read()
s from a binary file. The difference is between two and three
orders of magnitude. See
--On Monday, 12 June, 2006 12:20 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
...
The real underlying problem of course is the the
multi-stage standards process is just a relic from another
time, and makes no sense at all in the current environment.
Experiments in fine tuning the
--On Monday, 12 June, 2006 12:02 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
John,
John C Klensin wrote:
--On Thursday, 18 May, 2006 17:16 -0400 The IESG
[EMAIL PROTECTED] wrote:
The IESG has received a request from an individual submitter
to consider the following document:
On 12-jun-2006, at 13:31, Carsten Bormann wrote:
in your original question to the list, you didn't quite make clear
that your question was with respect to BGP-style transfer of large-
scale routing information.
I didn't want to limit the scope of the discussion to one particular
type of
This isolation, however, comes at a cost, because the traditional
communication abstraction maintained by these new network-layer extensions
hides information that transport-layer protocols should act on.
The information is hidden only for the purposes of connection management,
not for
I think this experiment is a good idea.
While we have discussed throwing out the whole structure, we have not
agreed to do so. (I happen to not like the 1-step proposals, but
that is not the point.)
Whether we eventually throw out the whole thing or not, in teh mean
time this improves our
...
The IESG (shepherded by Bill Fenner, Routing AD) has agreed to proceed
with the experiment.
Bill may have agreed to shepherd it, but the IESG has not reviewed
this document yet, so has not agreed to anything.
Brian
___
Ietf mailing list
At 03:32 AM 6/12/2006, Brian E Carpenter wrote:
... I believe the
RFC 3978 practice and the RFC 2026 variance process provides
adequate means publishing documents with such references.
Kurt, what's the relevance of RFC 3978?
It's a typo. I mean 3967.
Brian,
I had responded to Eric Rosen's note earlier (see my mail
of Thu 6/1/2006 12:07 PM EDT) - in particular concluding:
I - for one - see nothing either false or misleading in the
proposed note. I also find that addition of such a note is
substantially less onerous than
--On Monday, 12 June, 2006 12:20 +0200 Brian E Carpenter
[EMAIL PROTECTED] wrote:
...
The real underlying problem of course is the the
multi-stage standards process is just a relic from another
time, and makes no sense at all in the current environment.
Experiments in fine
Michael StJohns wrote:
Brian -
In absolute seriousness, I could publish an ID/RFC or other document
that says that I'm the king of the Internet - doesn't make it so.
These are the facts as I understand them.
1) The RFC Series has always been at ISI, originally under Jon Postel
the
secIETF == IETF Secretariat [EMAIL PROTECTED] writes:
secIETF * Only HTTP, SMTP, FTP, and DNS traffic are permitted through an
IPv6
secIETF Native firewall (pings, traceroutes etc. are dropped)
Please make sure that ICMP messages needed for path MTU discovery are
not
Sam Hartman wrote:
secIETF == IETF Secretariat [EMAIL PROTECTED] writes:
secIETF * Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6
secIETF Native firewall (pings, traceroutes etc. are dropped)
Please make sure that ICMP messages needed for path MTU
On Mon, 12 Jun 2006, Kevin Loch wrote:
Sam Hartman wrote:
secIETF == IETF Secretariat [EMAIL PROTECTED] writes:
secIETF * Only HTTP, SMTP, FTP, and DNS traffic are permitted
through an IPv6 secIETF Native firewall (pings, traceroutes
etc. are dropped)
Please make sure that
On Mon, 12 Jun 2006, John C Klensin wrote:
FWIW, I still think the approach in the draft is a good idea
given that...
(1) We have not been able to get consensus eliminating a
multistep standard process. For reasons explained elsewhere, I
personally consider that eliminating that process would
Kevin Loch wrote:
Sam Hartman wrote:
secIETF == IETF Secretariat [EMAIL PROTECTED] writes:
secIETF *Only HTTP, SMTP, FTP, and DNS traffic are permitted
through an IPv6 secIETF Native firewall (pings,
traceroutes etc. are dropped)
Please make sure that ICMP messages
On Mon, Jun 12, 2006 at 02:11:19PM +0200, Iljitsch van Beijnum wrote:
The problem with text is that you have to walk through memory and
compare characters. A LOT.
That's not where your code spends its time.
Run gprof(1). The majority of time your code spends is spent doing the
2 integer
The notes from the recent IESG Retreat, held May 5/6, 2006, can be found at the
following URL:
http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt
Brian Carpenter
IESG Chair
___
IETF-Announce mailing list
IETF-Announce@ietf.org
The IESG has received a request from the Layer Two Tunneling Protocol
Extensions WG to consider the following document:
- 'Transport of Ethernet Frames over L2TPv3 '
draft-ietf-l2tpext-pwe3-ethernet-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
The IESG has approved the following document:
- 'The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force '
draft-hoffman-taobis-08.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact
The IESG has approved the following document:
- 'Problem Statement for bootstrapping Mobile IPv6 '
draft-ietf-mip6-bootstrap-ps-05.txt as an Informational RFC
This document is the product of the Mobility for IPv6 Working Group.
The IESG contact persons are Jari Arkko and Mark Townsley.
A
The IESG has approved the following document:
- 'Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG '
draft-harrington-8021-mib-transition-03.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact
The IESG has approved the following document:
- 'Multiprotocol Extensions for BGP-4 '
draft-ietf-idr-rfc2858bis-10.txt as a Draft Standard
This document is the product of the Inter-Domain Routing Working Group.
The IESG contact persons are Bill Fenner and Ross Callon.
A URL of this
The IESG has approved the following document:
- 'Generalized Multi-Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH)
Control '
draft-ietf-ccamp-rfc3946bis-01.txt as a Proposed Standard
This document is the
30 matches
Mail list logo
