On 25 nov 2007, at 22:51, Jari Arkko wrote:
Eric is right that HBA does not appear to buy much additional value
over
CGAs. On the other hand, HBAs are very easy to support if you already
support CGAs; and some people seem to think shared-key only crypto is
helpful. You might disagree with
Paul Hoffman wrote:
At 11:58 PM +0200 11/25/07, Jari Arkko wrote:
Paul,
They still should (strongly) consider checking the validity of the XML
by comparing it to what the IESG approved.
Yes, and they do compare to what IESG approved. Substantial changes are
brought to the AD's approval.
There are two differences:
- both generating and checking public key signatures is more expensive
than just hashes
- for CGA, a host needs to store a private key somehwere, with HBA
there are no secrets
Yes, and in addition generating the key pair take some time. These are
not being
At Mon, 26 Nov 2007 11:18:42 +0100,
Iljitsch van Beijnum wrote:
On 25 nov 2007, at 22:51, Jari Arkko wrote:
Eric is right that HBA does not appear to buy much additional value
over
CGAs. On the other hand, HBAs are very easy to support if you already
support CGAs; and some people
--On Monday, 26 November, 2007 11:21 +0100 Eliot Lear
[EMAIL PROTECTED] wrote:
This argues that XML files be submitted as the authoritative
source at the time of WGLC, Paul, if they are going to be
submitted at all, and the I-D manager generates the text. I'm
fine with that, by the way.
At Mon, 26 Nov 2007 11:21:05 +0100,
Eliot Lear wrote:
At Mon, 26 Nov 2007 11:21:05 +0100,
Eliot Lear wrote:
Paul Hoffman wrote:
At 11:58 PM +0200 11/25/07, Jari Arkko wrote:
Paul,
They still should (strongly) consider checking the validity of the XML
by comparing it to what the
--On Monday, 26 November, 2007 11:21 +0100 Eliot Lear
[EMAIL PROTECTED] wrote:
This argues that XML files be submitted as the authoritative
source at the time of WGLC, Paul, if they are going to be
submitted at all, and the I-D manager generates the text. I'm
fine with that, by the
Spencer Dawkins wrote:
Laksminath's note is more detailed, but it's roughly what I was thinking
at about 2 PM EST today :-(
I'm sure there's an opportunity for us to pick a time zone for IETF 71
cutoffs!
you mean like UTC?
I'd note that all the reference times in this message were in the
One clarification,
A computer program should do this for the RFC Editor.
I don't want to see even more manual processing steps introduced into this
procedure.
It should be pretty easy to derive a diff from the canonical XML source minus
comments. I don't think that the RFC XML should
Spencer Dawkins wrote:
Laksminath's note is more detailed, but it's roughly what I was thinking
at about 2 PM EST today :-(
I'm sure there's an opportunity for us to pick a time zone for IETF 71
cutoffs!
you mean like UTC?
:-)
OK, guilty. My point was that the cutoff time seemed to be
From my point of view, it can be any timezone as long as the cutoff
time is the same in all cases. While we are on topic, I propose to use
AOE as defined by IEEE (I think 802.16).
regards,
Lakshminath
On 11/26/2007 10:33 AM, Spencer Dawkins wrote:
Spencer Dawkins wrote:
Laksminath's note
At Mon, 26 Nov 2007 10:39:03 -0800,
Lakshminath Dondeti wrote:
From my point of view, it can be any timezone as long as the cutoff
time is the same in all cases. While we are on topic, I propose to use
AOE as defined by IEEE (I think 802.16).
AOE == UTC-1200. UTC seems much more natural.
Just in case you are not familiar with AOE, it stands for Anywhere on
Earth (See http://www.ieee802.org/16/aoe.html)
regards,
Lakshminath
On 11/26/2007 10:39 AM, Lakshminath Dondeti wrote:
From my point of view, it can be any timezone as long as the cutoff
time is the same in all cases.
Greetings,
All 8 parallel tracks will be broadcast starting with the
commencement of working group sessions on Monday December 3rd at 0900
PST (UTC-8) and continue until Friday at 1130 PST. Additionally it is
our intention to broadcast the IEPG meeting occurring on Sunday the 2nd
starting at 1000
Yeah, I can deal with any TZ actually (AOE is one suggestion and I think
most intuitive, UTC is another), but can't handle the varying cutoff
times :).
On why AOE is intuitive, everyone gets to treat the deadline with their
own TZ substituted for AOE (the actual deadline for most people would
On 2007-11-26 19:55 Lakshminath Dondeti said the following:
Yeah, I can deal with any TZ actually (AOE is one suggestion and I think
most intuitive, UTC is another), but can't handle the varying cutoff
times :).
On why AOE is intuitive, everyone gets to treat the deadline with their
Looks to me as if the cut off is start of business for the RFC Editor. That
makes sense to me, no matter how much you try to change the cut off you can't
make it any later than the point where the editor needs to start work.
I would not mind seeing the -00 cutoff moving to the same as the
On 2007-11-27 00:33, Jari Arkko wrote:
There are two differences:
- both generating and checking public key signatures is more expensive
than just hashes
- for CGA, a host needs to store a private key somehwere, with HBA
there are no secrets
Yes, and in addition generating the key pair take
Cullen Jennings wrote:
On Nov 11, 2007, at 12:57 PM, Alexey Melnikov wrote:
I also don't see any particular reason for prohibiting direct use of
XMPP or SIP URIs here. There is no need in extra resolution step if an
email author only supports one type of IM application.
+1
(thought I
From: Lakshminath Dondeti [EMAIL PROTECTED]
Just in case you are not familiar with AOE, it stands for Anywhere on
Earth (See http://www.ieee802.org/16/aoe.html)
Cool concept: the deadline [time] has not passed if, anywhere on earth, the
deadline date has not yet passed. I like it.
At 6:26 PM -0800 11/26/07, Sandy Ginoza wrote:
Often times, authors send us the XML file, and let us know that they
have updated the file to reflect the requested RFC Editor notes,
that they have updated the authors addresses section, or that they
did a bit of editorial clean-up because of
And, just to keep Henrik sane, it looks like
http://en.wikipedia.org/wiki/List_of_time_zones#UTC.E2.88.9212.2C_Y should
be a real time zone that calendaring systems could understand (as opposed to
AOE) - did I get this right?
Spencer
From: Lakshminath Dondeti [EMAIL PROTECTED]
The IESG has approved the following document:
- 'Transmission of IPv6 via the IPv6 CS over IEEE 802.16 Networks '
draft-ietf-16ng-ipv6-over-ipv6cs-11.txt as a Proposed Standard
This document is the product of the IP over IEEE 802.16 Networks Working
Group.
The IESG contact persons are Jari
The IESG has approved the following document:
- 'Aggregation of DiffServ Service Classes '
draft-ietf-tsvwg-diffserv-class-aggr-07.txt as an Informational RFC
This document is the product of the Transport Area Working Group.
The IESG contact persons are Magnus Westerlund and Lars Eggert.
A
The IP Flow Information Export (ipfix) working group in the Operations
and Management Area of the IETF has been rechartered. For additional
information, please contact the Area Directors or the working group
Chairs.
+++
IP Flow Information Export (ipfix)
===
The Network Configuration (netconf) working group in the Operations and
Management Area of the IETF has been rechartered. For additional
information, please contact the Area Directors or the working group
Chairs.
+++
Network Configuration (netconf)
Current
The IESG has approved the following document:
- 'State of Peer-to-Peer(P2P) Communication Across Network Address
Translators(NATs) '
draft-ietf-behave-p2p-state-06.txt as an Informational RFC
This document is the product of the Behavior Engineering for Hindrance
Avoidance Working Group.
The IESG has approved the following document:
- 'Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) '
draft-ietf-avt-profile-savpf-12.txt as a Proposed Standard
This document is the product of the Audio/Video Transport Working Group.
The IESG contact persons is Cullen Jennings.
The IESG has approved the following document:
- 'A Telephony Gateway REgistration Protocol (TGREP) '
draft-ietf-iptel-tgrep-09.txt as a Proposed Standard
This document is the product of the IP Telephony Working Group.
The IESG contact persons are Cullen Jennings and Jon Peterson.
A URL of
The IESG has approved the following document:
- 'Reclassification of RFC 3525 to Historic '
draft-taylor-megaco-obsol3525-01.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 person is Cullen Jennings.
The IESG has approved the following document:
- 'URI Fragment Identifiers for the text/plain Media Type '
draft-wilde-text-fragment-09.txt as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Chris
A new IETF working group has been formed in the Internet Area.
For additional information, please contact the Area Directors
or the WG Chairs.
+++
Mobility EXTensions for IPv6 (mext)
Current Status: Active Working Group
Chair(s):
Julien Laganier [EMAIL
The Mobile Nodes and Multiple Interfaces in IPv6 WG (monami6)
in the Internet Area has concluded.
The IESG contact persons are Jari Arkko and Mark Townsley.
The mailing list will remain active.
The work continues in the new MEXT WG, combining the
Mobile IPv6 related efforts from the MIP6,
The Network Mobility WG (nemo)in the Internet Area has concluded.
The IESG contact persons are Jari Arkko and Mark Townsley.
The mailing list will remain active.
The work continues in the new MEXT WG, combining the
Mobile IPv6 related efforts from the MIP6, NEMO, and
MONAMI6 WGs.
The new WG
The IESG has received a request from an individual submitter to consider
the following document:
- 'Simple Mail Transfer Protocol '
draft-klensin-rfc2821bis-06.txt as a Draft Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please
35 matches
Mail list logo
