Original Message -
From: Ben Niven-Jenkins b...@niven-jenkins.co.uk
To: Ole Jacobsen o...@cisco.com
Cc: ietf@ietf.org
Sent: Thursday, May 31, 2012 11:36 PM
On 31 May 2012, at 09:16, Ole Jacobsen wrote:
Sounds like a difficult thing to do with any kind of predictable or
measurable
if i have to delete through much more about this bikeshed, i will give
you some colloquial american to read.
randy
On Jun 1, 2012, at 11:13 AM, Randy Bush wrote:
if i have to delete through much more about this bikeshed, i will give
you some colloquial american to read.
bikeshed ?
:-)
Yoav
Peter Saint-Andre wrote:
So the way we introduce some people to the IETF is to expect that they
will look up fifty unfamiliar words and phrases? Having taught English
as a second language, I can attest that some of the idioms and
colloquialisms included in this document would have caused
On May 31, 2012:6:36 PM, at 6:36 PM, Ben Niven-Jenkins wrote:
On 31 May 2012, at 09:16, Ole Jacobsen wrote:
Sounds like a difficult thing to do with any kind of predictable or
measurable outcome, although it might be fun to ask the Brits if they
understand everything the Americans are
On 01/06/2012 00:50, Paul Hoffman wrote:
Thank you for that most colorful analogy. :-) What I proposed is exactly
what we are doing now, except that the changes would appear on the web
page instead of an Internet-Draft and, five years later, an RFC. Are you
saying that the current system
There are still a few problems with this draft. The first is that it uses a
nonstandard and somewhat odd encoding to deliver the URI and Lifetime values.
These should simply be delivered as separate options, leaving out the whole
Luritype complication.The argument might be raised that
On May 31, 2012, at 9:38 PM, Fred Baker wrote:
The IAB decides who acts as the IETF's IANA. RFC 2860 again.
http://ntia.doc.gov/page/iana-functions-purchase-order
You're correct that NTIA wants to pay someone to do the protocol parameter
job.
Err, pay isn't the right word here: it's a zero
Hi Ben,
Thanks for your review. See responses below.
On Thu, May 31, 2012 at 6:08 PM, Ben Campbell b...@nostrum.com wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please
Thanks for the quick response. Further comments inline. I deleted sections that
do not appear to need further discussion.
Thanks!
Ben.
On Jun 1, 2012, at 10:45 AM, Donald Eastlake wrote:
Hi Ben,
Thanks for your review. See responses below.
On Thu, May 31, 2012 at 6:08 PM, Ben Campbell
At 09:42 01-06-2012, IESG Secretary wrote:
The IESG has received a request from the TLS Working Group to
reclassify RFC 2818 (HTTP Over TLS) to Proposed Standard.
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send substantive
I have a concern here. When I did the AD review for this document, I was quite
surprised how stale it had become. For example, the document told people to
send I-Ds to the Secretariat for posting instead of pointing to the online I-D
submission tool. If we put it in a wiki, there will be
C. M. Heard wrote:
My one reservation is that I do not think it is strictly necessary
to ban re-use of the IPv4 ID value in retransmitted non-atomic IPv4
datagrams.
Do you mean
Sources of non-atomic IPv4 datagrams MUST rate-limit their output
to comply with the ID uniqueness
On 6/1/2012 5:03 PM, Masataka Ohta wrote:
C. M. Heard wrote:
My one reservation is that I do not think it is strictly necessary
to ban re-use of the IPv4 ID value in retransmitted non-atomic IPv4
datagrams.
Do you mean
Sources of non-atomic IPv4 datagrams MUST rate-limit their
Joe Touch wrote:
Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.
The recommendation in this doc - that such sources MUST rate-limit - is
to comply with the ID uniqueness requirements already in RFC791 that
this
The IESG has received a request from an individual submitter to consider
the following document:
- 'RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)'
draft-sandlund-rfc4996bis-02.txt as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has approved the following document:
- 'CoRE Link Format'
(draft-ietf-core-link-format-14.txt) as Proposed Standard
This document is the product of the Constrained RESTful Environments
Working Group.
The IESG contact persons are Barry Leiba and Pete Resnick.
A URL of this Internet
A new IETF non-working group email list has been created.
List address: d...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/dsii/
To subscribe: https://www.ietf.org/mailman/listinfo/dsii
Purpose: Purpose: This list will be focused on the persistent identification of
data sets that are
The IESG has received a request from the TLS Working Group to reclassify RFC
2818 (HTTP Over TLS) to Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the ietf at
ietf.org mailing lists by
The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'BGP Support for Four-octet AS Number Space'
draft-ietf-idr-rfc4893bis-06.txt as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments
The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Pseudowire Control Word Negotiation Mechanism Update'
draft-ietf-pwe3-cbit-negotiation-03.txt as Proposed Standard
The IESG plans to make a decision in the next few
BEHAVE will have a conference call interim meeting at 7am PDT on Thursday,
June 21. Details on the conference call will be posted at
http://trac.tools.ietf.org/wg/behave/trac/wiki. We expect the meeting to
last 1.5 - 2 hours. If you want to be on the agenda, please send email to
A new Request for Comments is now available in online RFC libraries.
RFC 6617
Title: Secure Pre-Shared Key (PSK) Authentication
for the Internet Key Exchange Protocol
(IKE)
Author: D. Harkins
Status:
A new Request for Comments is now available in online RFC libraries.
RFC 6628
Title: Efficient Augmented Password-Only Authentication and
Key Exchange for IKEv2
Author: S. Shin, K. Kobara
Status: Experimental
A new Request for Comments is now available in online RFC libraries.
RFC 6630
Title: EAP Re-authentication Protocol Extensions for
Authenticated Anticipatory Keying (ERP/AAK)
Author: Z. Cao, H. Deng,
Q. Wu, G.
A new Request for Comments is now available in online RFC libraries.
RFC 6632
Title: An Overview of the IETF
Network Management Standards
Author: M. Ersue, Ed.,
B. Claise
Status: Informational
26 matches
Mail list logo
