Hi SM,
the examples you give are /very/ significant, because of the miserable
state of affairs that currently characterizes email.
On 27/Jun/10 19:32, SM wrote:
If you then go to RFC 2821 and you will see that it is a Proposed
Standard which has been obsoleted by RFC 5321 (Draft Standard).
A lot of the application code I've seen could be described as
second-guess one or more TCP timers, add pepper and salt, serve as
desired. The second half of that is obviously not amenable to
standardisation. The TCP stack cannot take any action. But the first
part seems more... reasonable. I
Arnt Gulbrandsen wrote:
A lot of the application code I've seen could be described as
second-guess one or more TCP timers, add pepper and salt, serve as
desired. The second half of that is obviously not amenable to
standardisation. The TCP stack cannot take any action. But the first
part
Well lets unpack this.
If we care about 50ms response then we probably expect the operator of the
service to be interested in making sure that information that can assist is
delivered to the DNS resolver.
At the moment the DNS service does not provide hints like 'this host best if
calling from
Hi, thanks for the quick response.
Followup comments inline:
On Jun 24, 2010, at 6:13 PM, Jaehoon Paul Jeong wrote:
Hi Ben,
First of all, I sincerely appreciate your review work on our I-D.
I tried to address all of your comments with a revised version:
The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.
It seems pretty basic to me that when you declare a document Obsolete it
should lose its STANDARD status. But under the current system that does not
happen.
This
One approach that may help avoid that blockage is to use a Quaker poll.
[Yes, Yes, consensus, blah, blah]
At the moment the mode of discourse is that everyone proposes their
preferred solution. So the clear consensus that the three step process is
not being applied is lost because everyone is
Ben,
I revised the I-D according to your follow-up comments as below:
The revised I-D is located at the following link:
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-04.txt
The difference between 03-version and 04-version is located:
Thanks for the edits, I appreciate them. I've adjusted the text.
At 10:24 AM -0700 3/28/10, SM wrote:
At 16:44 23-03-10, The IESG wrote:
The IESG has received a request from the Email Address
Internationalization WG (eai) to consider the following document:
- 'Mailing Lists and
Somebody said the message sent was not delivered on the list,
therefore, I send it again.
sorry if this is a repeat.
jun
On Tue, Jun 22, 2010 at 6:17 PM, Jun Murai j...@wide.ad.jp wrote:
Dear IETFers,
Please note below regarding the Itojun Service Award.
Nomination deadline is 12 July 2010.
As far as I can tell, the WG says they wants to transfer some information to
achieve cross vendor interoperability. However, what I believe the charter is
actually going to do is exactly the opposite of that. When you get your head
around what this charter is proposing, it is going to form a
Phillip Hallam-Baker wrote:
The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.
It seems pretty basic to me that when you declare a document Obsolete it
should lose its STANDARD status. But under the current
Phillip Hallam-Baker wrote:
The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.
It seems pretty basic to me that when you declare a document Obsolete it
should lose its STANDARD status. But under the current
On 6/28/10 12:35 PM, Martin Rex wrote:
To me it looks like Obsolete: has been used with quite different
meanings across RFCs, and some current uses might be inappropriate.
Although it's been more than two decades that I read rfc821 (and
none of the successors), I assume that all those RFC
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 RA-Guard '
draft-ietf-v6ops-ra-guard-06.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please
The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Internet X.509 Public Key Infrastructure - Certificate Image '
draft-ietf-pkix-certimage-08.txt as a Proposed Standard
The IESG plans to make a decision in the next few
The IESG has received a request from an individual submitter to consider
the following document:
- 'MIKEY-IBAKE: Identity-Based Mode of Key Distribution in Multimedia
Internet KEYing (MIKEY) '
draft-cakulev-mikey-ibake-01.txt as an Informational RFC
The IESG plans to make a decision in
The IESG has received a request from the Forwarding and Control Element
Separation WG (forces) to consider the following document:
- 'ForCES Applicability Statement '
draft-ietf-forces-applicability-09.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the Forwarding and Control Element
Separation WG (forces) to consider the following document:
- 'Implementation Report for ForCES '
draft-ietf-forces-implementation-report-02.txt as an Informational RFC
The IESG plans to make a decision in the next few
The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap '
draft-ietf-ipsecme-roadmap-07.txt as an Informational RFC
The IESG plans to make a
The IESG has received a request from the IS-IS for IP Internets WG (isis)
to consider the following document:
- 'IPv6 Traffic Engineering in IS-IS '
draft-ietf-isis-ipv6-te-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG has approved the following document:
- 'A Dedicated Routing Policy Specification Language Interface Identifier
for Operational Testing '
draft-haberman-rpsl-reachable-test-04.txt as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF
The IESG has approved the following document:
- 'An Extension for EAP-Only Authentication in IKEv2 '
draft-ietf-ipsecme-eap-mutual-05.txt as a Proposed Standard
This document is the product of the IP Security Maintenance and Extensions
Working Group.
The IESG contact persons are Sean
A new Request for Comments is now available in online RFC libraries.
RFC 5896
Title: Generic Security Service Application Program
Interface (GSS-API): Delegate if Approved by
Policy
Author: L. Hornquist
A new Request for Comments is now available in online RFC libraries.
RFC 5932
Title: Camellia Cipher Suites for TLS
Author: A. Kato, M. Kanda,
S. Kanno
Status: Standards Track
Stream: IETF
Date:
A new Request for Comments is now available in online RFC libraries.
RFC 5936
Title: DNS Zone Transfer Protocol (AXFR)
Author: E. Lewis, A. Hoenes, Ed.
Status: Standards Track
Stream: IETF
Date: June 2010
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Rogue IPv6 Router Advertisement Problem Statement '
draft-ietf-v6ops-rogue-ra-01.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
The RADEXT WG will be holding a virtual interim meeting on Monday, July
12, 2010, from 11 AM - 1:30 PM Pacific Time.
A strawman agenda has been posted to the list:
http://ops.ietf.org/lists/radiusext/2010/msg00483.html
Conference call parameters will be posted to the mailing list once they
are
Hi all,
This is the Third call for Volunteers for the 2010-2011 Nomcom.
We are now 2/3 of the way through the volunteer period so if you are
considering volunteering please do so now as the time in which you may
volunteer is beginning to run short.
The call for volunteers remains open until
Nomcom Volunteers (2nd Listing)
List is current as of June 28, 2010 at 12:00 PDT (19:00 UTC)
If you sent an email to nomcom-ch...@ietf.org to volunteer before 12:00
PDT (19:00 UTC) on June 28, 2010 and your name does not appear on this
list, please re-submit and put the words
30 matches
Mail list logo
