On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews ma...@isc.org wrote:
If you believe that I have a bridge to sell you.
Keep the bridge - it's all yours. Remember - in order to sell the bridge
you first have to own it. Your convenced you have something to sell. I am
not.
Totally
I am bringing this draft to its second last call. After the completion
of the headers and boilerplates document and extensive discussions
within the IESG, it has become clear that several ADs had an issue with
the 3932bis draft. I have asked Russ to post a new version which I
believe resolves
And to start off the comments, I wanted tell my personal opinion about this.
First, I have not been extremely happy with either the hb or the
3932bis document, as some people who have been reading the various lists
may gather. However, I think they were already good enough to be shipped
The changes described in your other note (copied after your text to
preserve context) are reasonable in the abstract. However, the devil is
in the details.
As I understand it, the reason for calling the extra note exceptional
is that the IESG has in the past sometimes used that note to place
In message 874c02a20906010608p3e7fbdd3wa31c9ea5452a7...@mail.gmail.com, Joe
Baptista writes:
On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews ma...@isc.org wrote:
If you believe that I have a bridge to sell you.
Keep the bridge - it's all yours. Remember - in order to sell the
Fernando,
I was modifying the document to update the last call comments and I
would want to make sure if we are on same page w.r.t to your comments.
Pl see inline.
-Original Message-
From: fernando.gont.netbook@gmail.com
[mailto:fernando.gont.netbook@gmail.com] On Behalf
As the liaison from IETF to the Unicode Consortium, I would like to
make the IETF community aware of the following opening for public
comments.
The character U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA BELOW that the
review is related to has today the derived property value PVALID in
the
As a disinterested third party...
On Mon Jun 1 16:09:39 2009, Mark Andrews wrote:
Totally different from DNSSEC which indeed uses chains of trust -
i.e. root
to tld to sld etc.etc.
And DNSCurve uses chains of trust from root servers to tld
servers to sld servers etc. etc.
To the IETF mailing list subscribers:
The US government involvement in DNSSEC operations is almost certainly
not in-scope for the ietf mailing list. Thus, it would be
counterproductive to start a discussion based on Mr. Baptista comments
on this topic (hence no in-line comments in the
Joel,
However, the devil is in the details.
As I understand it, the reason for calling the extra note
exceptional is that the IESG has in the past sometimes used that
note to place far more pejorative language than you suggest, in places
that it really does not belong. That can turn a
--On Monday, June 01, 2009 18:30 +0300 Jari Arkko
jari.ar...@piuha.net wrote:
Joel,
However, the devil is in the details.
As I understand it, the reason for calling the extra note
exceptional is that the IESG has in the past sometimes used
that note to place far more pejorative
--On Monday, June 01, 2009 17:47 +0300 Jari Arkko
jari.ar...@piuha.net wrote:
I am bringing this draft to its second last call. After the
completion of the headers and boilerplates document and
extensive discussions within the IESG, it has become clear
that several ADs had an issue with the
John,
The IAB and the RFC Editor have made updates to the formatting
of the title page for all RFCs [N3]. With these changes, the
upper left hand corner of the title page indicates the stream
that produced the RFC. This label replaces some of the
information that was previously provided in
The IAB and the RFC Editor have made updates to the formatting
of the title page for all RFCs [N3]. With these changes, the
upper left hand corner of the title page indicates the stream
that produced the RFC. This label replaces some of the
information that was previously provided in mandatory
--On Monday, June 01, 2009 21:47 +0300 Jari Arkko
jari.ar...@piuha.net wrote:
As written, this violates provisions of RFC 4846 as well as
some of the language in the current RFC Editor Model draft.
The IESG may _request_ that notes or other language be added.
Indeed -- thanks for catching
Hi IESG members, folks,
I'm one of the authors of the draft, so this is rather odd. But...
as per request, I'm pushing this issue as a comment into the IETF
LC/IESG review for draft rfc3761bis. This has an error that should be
fixed and has caused confusion.
draft rfc3761bis-04 inherits a lot
The RFC Editor Services Bidders Conference will be June 3, 2009 from
10:00 AM to 1:00 PM PT (UTC-7).
The conference will permit those considering the positions of RFC Series
Editor, Independent Submissions Editor, or bidding on the RFC Production
Center RFP to appear and ask questions of the
The IESG has received a request from an individual submitter to consider
the following document:
- 'IESG Procedures for Handling of Independent and IRTF Stream
Submissions '
draft-housley-iesg-rfc3932bis-07.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has approved the following document:
- 'DomainKeys Identified Mail (DKIM) Service Overview '
draft-ietf-dkim-overview-12.txt as an Informational RFC
This document is the product of the Domain Keys Identified Mail Working
Group.
The IESG contact persons are Pasi Eronen and Tim
The IESG has approved the following document:
- 'Report from the IETF workshop on P2P Infrastructure, May 28, 2008 '
draft-p2pi-cooper-workshop-report-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
The IESG has approved the following document:
- 'Quality of Service Parameters for Usage with Diameter '
draft-ietf-dime-qos-parameters-11.txt as a Proposed Standard
This document is the product of the Diameter Maintenance and Extensions
Working Group.
The IESG contact persons are Dan
21 matches
Mail list logo
