james woodyatt writes:
If it could be published as standards-track, instead of informational,
*without* *any* *further* *delay*, that would be excellent. However,
I believe there is nothing to be gained for the Internet community by
any further delay in publishing this important document.
It
Brian E Carpenter brian.e.carpen...@gmail.com writes:
On 2009-11-24 06:44, Steven M. Bellovin wrote:
On Mon, 23 Nov 2009 08:16:49 -0500
Scott Brim scott.b...@gmail.com wrote:
Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM:
John-Luc said he is bound by confidentiality obligations
Folks,
At Tue, 24 Nov 2009 16:00:48 +0100, Julian Reschke wrote:
To illustrate the problem: for IETF Experimental, with Consensus
Call, we get:
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task
Can we please recommend *not* to put a file extension into the URL?
The text can be updated - there is no file extension. The URL is of
the form:
http://www.rfc-editor.org/static-path/rfcrfc-no
For example:
http://www.rfc-editor.org/info/rfc2026
RFC Editor/ah
On Nov 24, 2009, at 7:01
Let's just get this published and go with what we have even if it does not
necessarily read real pretty. The text of the strings can be updated at a
later point by a modification of the RFC Style Guide if there are enough
complaints about how the text looks. Given that it is boilerplate, I
Hi,
- 'ESMTP and LMTP Transmission Types Registration '
[...]
Implementation Report can be accessed at
http://www.ietf.org/iesg/implementation.html
Initial set of implementations is currently in the datatracker (see below).
I do not know to whom I should write that.
There is a trailing
Samuel Weiler writes:
Registration of an IMAP keyword intended for common use (whether or
not they use the $ prefix) requires Expert Review [RFC5226]. IESG
appoints one or more Expert Reviewer, one of which is designated as
the primary Expert Reviewer. IMAP keywords intended
On Wed, 18 Nov 2009, Alexey Melnikov wrote:
Further registrations will be done by the designated expert. I am
concerned that if I put all of them in the document, then the
document will never finish.
Sympathies.
And for the common-use:
Registration of an IMAP keyword intended for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have reviewed draft (-08) and support it, on the Informational track.
Review comments.
* The NSEC type is used for negative responses (from a discussion in
DNSEXT). However, the draft specifies that only the bitmap for types
0-255 is to be
Simon Josefsson wrote:
Brian E Carpenter brian.e.carpen...@gmail.com writes:
On 2009-11-24 06:44, Steven M. Bellovin wrote:
On Mon, 23 Nov 2009 08:16:49 -0500
Scott Brim scott.b...@gmail.com wrote:
Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM:
John-Luc said
I support draft-ietf-tls-renegotiation-01.txt.
--
Robert DugalSenior Software Developer
Certicom Corp. A Subsidiary of Research In Motion
rdu...@certicom.com
direct905.501.3848
fax 905.507.4230
www.certicom.com
-Original Message-
From:
Simon Josefsson writes:
There is no requirement in the IETF process for organizations to
disclose patents as far as I can see. The current approach of only
having people participate, and disclose patents, in the IETF is easy
to work around by having two persons in an organization doing
Samuel Weiler answers Alexey:
Isn't it enough to have them in a consensus doc?) And how do you
expect the expert to encourage/enforce the SHOULD, given the
favour registering it over requiring perfect documentation
guideline? Again, the current text isn't as clear as I'd like.
This is
Arnt Gulbrandsen a...@gulbrandsen.priv.no writes:
Simon Josefsson writes:
There is no requirement in the IETF process for organizations to
disclose patents as far as I can see. The current approach of only
having people participate, and disclose patents, in the IETF is easy
to work around by
Julien ÉLIE wrote:
Hi,
Hi Julien,
- 'ESMTP and LMTP Transmission Types Registration '
[...]
Implementation Report can be accessed at
http://www.ietf.org/iesg/implementation.html
Initial set of implementations is currently in the datatracker (see
below).
I do not know to whom I should
The biggest problem I have with this document is among those pointed out by
Wouter:
* The rule that .local names MUST be sent to mdns(port 5353). I feel
this is a little too strong, there are sites out there that have set ups
with .local in their unicast DNS. Propose: SHOULD.
As stated
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
On 2009-12-01 06:03, Thierry Moreau wrote:
Simon Josefsson wrote:
Brian E Carpenter brian.e.carpen...@gmail.com writes:
On 2009-11-24 06:44, Steven M. Bellovin wrote:
On Mon, 23 Nov 2009 08:16:49 -0500
Scott Brim scott.b...@gmail.com wrote:
Simon Josefsson allegedly wrote on
On Mon, 2009-11-30 at 18:50 +0100, Simon Josefsson wrote:
Arnt Gulbrandsen a...@gulbrandsen.priv.no writes:
Simon Josefsson writes:
There is no requirement in the IETF process for organizations to
disclose patents as far as I can see. The current approach of only
having people
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
On 25 Nov, 2009, at 01:52, W.C.A. Wijngaards wrote:
* The rule that .local names MUST be sent to mdns(port 5353). I feel
this is a little too strong, there are sites out there that have
set ups
with .local in their unicast DNS. Propose: SHOULD.
I think you may be misreading this.
A
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
On 30 Nov, 2009, at 15:23, Phillip Hallam-Baker wrote:
90% of this proposal is equally relevant to the enterprise case.
But the multicast part is not.
The document is called Multicast DNS. Which parts of the document
do you think do *not* relate to multicast?
Stuart Cheshire
Paragraph 3 of section 4 says:
Because this cipher suite is equivalent to an empty
renegotiation_info extension, only renegotiation_info may be used
rehandshakes.
Leaving aside the incorrect punctuation, this doesn't make any sense to me.
In section 5, suggest replacing all
Arnt Gulbrandsen [mailto://a...@gulbrandsen.priv.no] writes:
Simon Josefsson writes:
There is no requirement in the IETF process for organizations to
disclose patents as far as I can see. The current approach of only
having people participate, and disclose patents, in the IETF is easy
to
The IESG has received a request from the FEC Framework WG (fecframe) to
consider the following document:
- 'DVB-IPTV Application-Layer Hybrid FEC Protection '
draft-ietf-fecframe-dvb-al-fec-03.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has received a request from the FEC Framework WG (fecframe) to
consider the following document:
- 'RTP Payload Format for 1-D Interleaved Parity FEC '
draft-ietf-fecframe-interleaved-fec-scheme-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks,
The IESG has received a request from the Domain Keys Identified Mail WG
(dkim) to consider the following document:
- 'DomainKeys Identified Mail (DKIM) Development, Deployment and
Operations '
draft-ietf-dkim-deployment-09.txt as an Informational RFC
The IESG plans to make a decision in
The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Transport Layer Security (TLS) Renegotiation Indication Extension '
draft-ietf-tls-renegotiation-01.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:
- 'The 'mailto' URI Scheme '
draft-duerst-mailto-bis-07.txt as a Proposed Standard
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 an individual submitter to consider
the following document:
- 'The 'mailto' URI Scheme '
draft-duerst-mailto-bis-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please
The IESG has approved the following document:
- 'Handling of overlapping IPv6 fragments '
draft-ietf-6man-overlap-fragment-03.txt as a Proposed Standard
This document is the product of the IPv6 Maintenance Working Group.
The IESG contact persons are Jari Arkko and Ralph Droms.
A URL of
The Language Tag Registry Update (ltru) working group in the Applications
Area has concluded.
The IESG contact persons are Alexey Melnikov and Lisa Dusseault.
The LTRU working group has successfully completed its deliverables and
can now be closed. The ADs would like to thank everyone who
The IESG has approved the following document:
- 'IMAP Support for UTF-8 '
draft-ietf-eai-imap-utf8-09.txt as an Experimental RFC
This document is the product of the Email Address Internationalization Working
Group.
The IESG contact persons are Alexey Melnikov and Lisa Dusseault.
A URL of
The IESG has approved the following document:
- 'Post-Repair Loss RLE Report Block Type for RTCP XR '
draft-ietf-avt-post-repair-rtcp-xr-07.txt as a Proposed Standard
This document is the product of the Audio/Video Transport Working Group.
The IESG contact persons are Cullen Jennings and
35 matches
Mail list logo
