On Mar 2, 2009, at 1:52 PM, Joel Jaeggli wrote:
Dearlove, Christopher (UK) wrote:
But now, if I come to IETF74, I won't have a laptop with me.
Corporate policy, based on recent US legal decisions, is that
I may not take a laptop (or PDA etc.) into the USA. This is
not subject to modification.
Alexa Morris
Actually, the Terminal Room will have two laptops set up for attendee
use; these are traditionally used primarily for printing (boarding
passes, etc) but are available for other uses as well.
That's useful to know. I did enquire of the Secretariat
(reference rt.amsl.com
Hi guys,
I sent the message to this list (as well as LTRU) in the belief I was
following the instructions given to me...
(My mail actually preceded Martin's request to the AD.)
I admit to confusion about the suggestion I can register the change after
4645bis is accepted.
4645bis changes a code
I think that a rather more fundamental problem is the fact that the IETF
constitution prevents any organization or party speaking on behalf of the IETF
as a whole.
I agree that it would be rather better if the IAB could take on this particular
role than ISOC. But even the IAB can only
s...@resistor.net writes:
If there isn't an authoritative reference and there are differences in
semantics or syntax between the draft and RFC5321/5322 or future
revisions of these documents, it can lead to serious issues.
Standards Track documents are around years. The documents may be
The IESG has received a request from the Audio/Video Transport WG (avt)
to consider the following document:
- 'The SEED Cipher Algorithm and Its Use with the Secure Real-time
Transport Protocol (SRTP) '
draft-ietf-avt-seed-srtp-09.txt as a Proposed Standard
The IESG plans to make a
On Mon, 2 Mar 2009, John C Klensin wrote:
* Machines in the netbook category have gotten very cheap (cheaper
than IETF registration fees, for example). While I would not expect
your company to change policy, obtaining a few of those machines and
imaging them to contain nothing in local
s...@resistor.net writes:
If there isn't an authoritative reference and there are differences in
semantics or syntax between the draft and RFC5321/5322 or future
revisions of these documents, it can lead to serious issues.
Standards Track documents are around years. The documents may be
So at this point the rule in the identity space is safety in numbers. The
major waring factions are now spending considerable
time and effort to show that the war is over and there is going to be a
concerted joint effort. Thus ISOC joining liberty does not represent the
IETF taking sides in a
All;
Several tools to publish Internet Drafts have implemented the IETF
Trust's recent policy changes that provide a work-around to the issues
raised by the inclusion of material from contributions published
before 10 November 2008. You may have already been aware of one or
more of the
In message alpine.bsf.2.00.0903021337550.15...@fledge.watson.org, Samuel Weil
er writes:
On Mon, 2 Mar 2009, John C Klensin wrote:
* Machines in the netbook category have gotten very cheap (cheaper
than IETF registration fees, for example). While I would not expect
your company to
I would like to bring to your attention this proposal to put back
running code at the center of Internet protocol design by adding a
new Considerations Section in future Internet-Drafts and RFCs:
http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt
Thanks.
As I mentioned late last week, as a side effect of a recent Mailman
upgrade some mail lists with previously public archives had their list
configuration reset to private archiving, resulting in inaccessible
archives. This archiving issue has now been repaired and the missing
archives have
Marc, and Henry,
I think adding any new mandatory section to all I-Ds is a bad idea.
It will quickly become bureaucratic. We've had proposals for mandatory
Management Considerations, IPv6 Considerations, and no doubt others
that I've forgotten, and they all have the same problem.
However, I
This is very sad news. Jim was a very strong supporter of the IETF and IPv6.
Jim served the community as:
- IPv6 Forum Chief Technology Officer
- Chair of the North American IPv6 Task Force
- Active IETF contributor, including member of the IPng Directorate
We will miss him.
Russ
Brian E Carpenter wrote:
Marc, and Henry,
I think adding any new mandatory section to all I-Ds is a bad idea.
It will quickly become bureaucratic. We've had proposals for mandatory
Management Considerations, IPv6 Considerations, and no doubt others
that I've forgotten, and they all have the
--On Wednesday, March 04, 2009 07:51 +1100 Mark Andrews
mark_andr...@isc.org wrote:
...
There is no interesting direction. I'm pretty sure customs
gets the same sort of search and ceasure rights on exit and
it does on arrival. They do here in Australia.
In principle,
In message ee08613c757444318d788...@pst.jck.com, John C Klensin writes:
--On Wednesday, March 04, 2009 07:51 +1100 Mark Andrews
mark_andr...@isc.org wrote:
...
There is no interesting direction. I'm pretty sure customs
gets the same sort of search and ceasure rights on exit
Harald Alvestrand wrote:
Marc Petit-Huguenin wrote:
I would like to bring to your attention this proposal to put back
running code at the center of Internet protocol design by adding a
new Considerations Section in future Internet-Drafts and RFCs:
I admit that I'm no friend of additional I-D sections, as they easily
generate into boilerplate and make work projects. If the goal, which
does not seem stated, is to acknowledge the contributions of
implementations in improving a standards document, we already have a
mechanism for
I don't see the value of running code quite as others do.
For me the value of running code is that the requirement to actually implement
stuff does tend to reduce the scope for complexity, you have someone in the
room pushing against something that will make work for them. And the other
Hallam-Baker, Phillip wrote:
I don't see the value of running code quite as others do.
I agree. It was valuable in good old days, when implmenting a protocol
was purely voluntary with no budget.
Existence of multiple independent implementations, then, meant the
protocol was widely accepted by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yo Masataka!
On Wed, 4 Mar 2009, Masataka Ohta wrote:
So, existence of required running code does not mean much.
Except a basic proof of real functionality and that is valuable.
RGDS
GARY
-
Masataka Ohta wrote:
Hallam-Baker, Phillip wrote:
I don't see the value of running code quite as others do.
I agree. It was valuable in good old days, when implmenting a protocol
was purely voluntary with no budget.
Existence of multiple independent implementations, then, meant the
protocol
Harald Alvestrand wrote:
Marc Petit-Huguenin wrote:
I would like to bring to your attention this proposal to put back
running code at the center of Internet protocol design by adding a
new Considerations Section in future Internet-Drafts and RFCs:
Andy Bierman wrote:
So, existence of required running code does not mean much.
I disagree.
It means the specification is implementable.
If a protocol is so complex that its implementability is not
obvious, you have lost from the beginning.
Since the goal of our work is to produce
On Mar 1, 2009, at 9:04 PM, Eric Rescorla wrote:
At Sun, 1 Mar 2009 19:59:00 +0200,
Hannes Tschofenig wrote:
As you might have noticed, the WebSSO Identity Management space is
not
running out of organizations and groups. Someone could, for
example, come up
with the question why ISOC did
We also certainly don't want to put yet more hurdles into the
path of getting drafts published. Does the RFC editor have to
verify the URLs and that they still exist? Do we worry about
advertising pages and implementations that turn out to be
malicious? I'd really rather not have to deal with
The IESG has approved the following document:
- 'ForCES Protocol Specification '
draft-ietf-forces-protocol-22.txt as a Proposed Standard
This document is the product of the Forwarding and Control Element
Separation Working Group.
The IESG contact persons are Ross Callon and David Ward.
A
The charter of the IP Performance Metrics (ippm) working group in the
Transport Area of the IETF has been updated. For additional information,
please contact the Area Directors or the working group Chairs.
IP Performance Metrics (ippm)
Last
A new Request for Comments is now available in online RFC libraries.
RFC 5432
Title: Quality of Service (QoS) Mechanism
Selection in the Session Description Protocol
(SDP)
Author: J. Polk, S. Dhesikan, G.
A new Request for Comments is now available in online RFC libraries.
RFC 5443
Title: LDP IGP Synchronization
Author: M. Jork, A. Atlas, L. Fang
Status: Informational
Date: March 2009
Mailbox:
A new Request for Comments is now available in online RFC libraries.
RFC 5484
Title: Associating Time-Codes with RTP Streams
Author: D. Singer
Status: Standards Track
Date: March 2009
Mailbox:sin...@apple.com
A new Request for Comments is now available in online RFC libraries.
RFC 5485
Title: Digital Signatures on Internet-Draft Documents
Author: R. Housley
Status: Informational
Date: March 2009
Mailbox:
34 matches
Mail list logo
