Hi, Neil,
Thanks for the quick response (so I can still remember writing the review
:-)...
Deleting stuff we agree on - I think my suggestion here
3.8. Media Server Use of IMAP Server
If the media server is configured as an authorized user of the IMAP
server, it SHOULD authenticate to
On Tue Mar 10 12:12:44 2009, Spencer Dawkins wrote:
My biggest concern was whether the media server might be configured
with MY IMAP credentials,
Ah, no, it's referring to the media server's credentials, not yours.
It (probably) doesn't know yours, or at least only knows them
sufficient
Hi, Dave,
Ah - then this really does reduce to a general IMAP-wide don't send
credentials over unencrypted channels warning, that more appropriately
belongs somewhere else.
Thanks!
Spencer
My biggest concern was whether the media server might be configured with
MY IMAP credentials,
Ah,
Please note that I didn¹t make a proposal. I can live quite well with a
misalignment of IETF terminology and reality as perceived outside the IETF.
So can the industry, I think. What I was commenting on is that it does not
make sense to me to re-iterate the mantra of ³Experimental RFCs not being
I am the last person to propose making changes to IETF procedures to suit RMS
better.
The reason to make changes is to increase influence.
Experimental evidence (take any recent election you choose) strongly suggests
that the human logical reasoning system has the Post hoc ergo propter hoc
Florian Weimer wrote:
* Paul Vixie:
some number of vendors have depended on revenue from selling this
feature but i'd say that only a small number of sites ever saw any
benefit from it.
pool.ntp.org, security.debian.org, rsync.gentoo.org,
[a-o].ns.spamhaus.org, [a-n].surbl.org. In general
Spencer,
thanks for these comments, I broadly agree with most of them. I've
replied specifically inline below, and if you agree will update the
draft accordingly.
Neil
On 6 Mar 2009, at 22:29, Spencer Dawkins wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer
As the draft was not approved by the IESG as a Proposed Standard,
the fact is that most people in the IETF community would not consider
it as a proposed standard.
It depends whether one interprets the term according to IETF procedures
or according to everyday understanding of
Spencer,
agreed.
I'll update the draft based on your comments, and update the repository,
thanks,
Neil
On 10 Mar 2009, at 12:12, Spencer Dawkins wrote:
Hi, Neil,
Thanks for the quick response (so I can still remember writing the
review :-)...
Deleting stuff we agree on - I think my
Stephan Wenger wrote:
Please note that I didn't make a proposal. I can live quite well with a
misalignment of IETF terminology and reality as perceived outside the IETF.
So can the industry, I think. What I was commenting on is that it does not
make sense to me to re-iterate the mantra of
At 10:22 AM -0700 3/10/09, Lawrence Rosen wrote:
If we use different terminology to identify this IETF RFC, how does that
change anything?
Because you earlier complained about IETF standards having known patent issues.
Now we are talking about experimental protocols that are not standards.
On Tue, 10 Mar 2009 14:21:00 -0400
Richard M Stallman r...@gnu.org wrote:
Steve Bellovin wrote:
Other than giving up the RFC label for Experimental documents,
it's hard to see what the IETF can do.
Another thing the IETF could do is stop publishing this sort of
document. Anyone that
At 02:11 10-03-2009, Richard M Stallman wrote:
It depends whether one interprets the term according to IETF procedures
or according to everyday understanding of English.
I agree. That is why I specified IETF community in my reply.
How high is the threshold, in practice, for getting
Lawrence Rosen wrote:
If we use different terminology to identify this IETF RFC, how does that
change anything?
Paul Hoffman replied:
Because you earlier complained about IETF standards having known patent
issues. Now we are talking about experimental protocols that are not
standards.
And
Institute the policy as you suggest and you have just given the patent
trolls the power to place an indefinite hold on any IETF proposal.
So instead of extorting payment for exercise of the claims they hold the
standard hostage.
-Original Message-
From: ietf-boun...@ietf.org
Larry,
On 2009-03-11 08:28, Lawrence Rosen wrote:
...
I don't think we should publish under the IETF imprimatur if there are
*unresolved* known patent issues about which ignorant and cautious people
continue to speculate blindly. Why should any of us waste time and money on
IETF and
At 12:28 PM -0700 3/10/09, Lawrence Rosen wrote:
Lawrence Rosen wrote:
If we use different terminology to identify this IETF RFC, how does that
change anything?
Paul Hoffman replied:
Because you earlier complained about IETF standards having known patent
issues. Now we are talking about
On Mar 4, 2009, at 3:43 AM, Dearlove, Christopher (UK) wrote:
Putting aside whether I could buy such a machine, and assuming
taking it out of the US would be OK policy-wise (that I'd have
to check, I suspect it's within the letter but not the spirit
of the policy) as soon as it's outside the
On Mar 10, 2009, at 2:32 PM, Dean Willis wrote:
Is this a big enough problem to justify setting up a Netbook Rental
Desk near IETF checkin?
Maybe the IETF should offer to lease to Netbook Rental firms the space
to operate such a desk. That way, the IETF'ers get a service... and
the
Phillip Hallam-Baker wrote:
Institute the policy as you suggest and you have just given the patent
trolls the power to place an indefinite hold on any IETF proposal.
I have never suggested placing any kind of hold on any IETF proposal.
Propose all you want. Publish the proposal. Try to convince
When you say IETF RFC, do you also include RFC-Editor track informational RFCs?
EHL
On 3/10/09 3:08 PM, Lawrence Rosen lro...@rosenlaw.com wrote:
Phillip Hallam-Baker wrote:
Institute the policy as you suggest and you have just given the patent
trolls the power to place an indefinite hold on
Eran Hammer-Lahav wrote:
When you say IETF RFC, do you also include RFC-Editor track
informational RFCs?
There's no consensus requirement for an informational document, In point
of fact even the coordination clause in 2026 4.2.3 is not an obstacle to
publication...
EHL
On 3/10/09 3:08
On 3/10/09 7:46 PM, Lawrence Rosen wrote:
Only occasionally does someone submit a disclosure as misleading and
confusing as the one relating to TLS.
TLS itself (RFCs 2246, 4346, 5246) is not affected by the disclosure at
hand. The impact is limited to a particular extension to TLS (and even
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Exporting Type Information for IPFIX Information Elements '
draft-ietf-ipfix-exporting-type-02.txt as a Proposed Standard
The IESG plans to make a decision in the next few
The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:
- 'NAT Behavior Discovery Using STUN '
draft-ietf-behave-nat-behavior-discovery-06.txt as an Experimental
RFC
The IESG plans to make a decision in the next
The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:
- 'NACK-Oriented Reliable Multicast Protocol '
draft-ietf-rmt-pi-norm-revised-09.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has approved the following document:
- 'Framework for Establishing an SRTP Security Context using DTLS '
draft-ietf-sip-dtls-srtp-framework-07.txt as a Proposed Standard
This document is the product of the Session Initiation Protocol Working
Group.
The IESG contact persons are
74th IETF Meeting
San Francisco, CA
March 22-27, 2009
Host: Juniper
Early-Bird registration cutoff is this Friday, March 13 at 17:00 PT
(24:00 UTC). After that time, the registration fee will increase by $150
USD to $785 USD.
Online registration for the IETF meeting is at:
The IESG has approved the following document:
- 'Datagram Transport Layer Security (DTLS) Extension to Establish Keys
for Secure Real-time Transport Protocol (SRTP) '
draft-ietf-avt-dtls-srtp-07.txt as a Proposed Standard
This document is the product of the Audio/Video Transport Working
A new Request for Comments is now available in online RFC libraries.
RFC 5424
Title: The Syslog Protocol
Author: R. Gerhards
Status: Standards Track
Date: March 2009
Mailbox:rgerha...@adiscon.com
Pages:
A new Request for Comments is now available in online RFC libraries.
RFC 5425
Title: Transport Layer Security (TLS) Transport
Mapping for Syslog
Author: F. Miao, Ed.,
Y. Ma, Ed.,
J. Salowey,
A new Request for Comments is now available in online RFC libraries.
RFC 5426
Title: Transmission of Syslog Messages over
UDP
Author: A. Okmianski
Status: Standards Track
Date: March 2009
Mailbox:
A new Request for Comments is now available in online RFC libraries.
RFC 5442
Title: LEMONADE Architecture - Supporting Open
Mobile Alliance (OMA) Mobile Email (MEM)
Using Internet Mail
Author: E. Burger, G.
A new Request for Comments is now available in online RFC libraries.
RFC 5463
Title: Sieve Email Filtering: Ihave Extension
Author: N. Freed
Status: Standards Track
Date: March 2009
Mailbox:ned.fr...@mrochek.com
A new Request for Comments is now available in online RFC libraries.
RFC 5480
Title: Elliptic Curve Cryptography Subject Public
Key Information
Author: S. Turner, D. Brown,
K. Yiu, R. Housley,
A new Request for Comments is now available in online RFC libraries.
RFC 5486
Title: Session Peering for Multimedia Interconnect
(SPEERMINT) Terminology
Author: D. Malas, Ed.,
D. Meyer, Ed.
Status:
A new Request for Comments is now available in online RFC libraries.
RFC 5487
Title: Pre-Shared Key Cipher Suites for
TLS with SHA-256/384 and AES Galois
Counter Mode
Author: M. Badra
Status:
The 16ng session scheduled for Friday, March 27 from 1300-1400 has been
canceled.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
39 matches
Mail list logo
