On Dec 2, 2009, at 9:04 AM, Chris Newman wrote:
This the most time-sensitive and security-critical IETF draft with respect
to impact on the Internet community that I have seen in 17 years of IETF
participation.
This is the part I disagree with.
New extensions to protocols will take
Brian E Carpenter brian.e.carpen...@gmail.com writes:
On 2009-12-01 23:57, Simon Josefsson wrote:
Scott Brim scott.b...@gmail.com writes:
Simon Josefsson allegedly wrote on 11/30/2009 10:11 AM:
There is no requirement in the IETF process for organizations to
disclose patents as far as I
On Tue, Dec 01, 2009 at 04:21:02PM -0800, SM wrote:
Note that this use of the .local. suffix falls under IETF/IANA
jurisdiction, not ICANN jurisdiction.
This draft mentions that the IETF has the authority to instruct IANA to
reserve pseudo-TLDs as required for protocol design purposes.
--On December 2, 2009 11:12:26 +0200 Yoav Nir y...@checkpoint.com wrote:
On Dec 2, 2009, at 9:04 AM, Chris Newman wrote:
This the most time-sensitive and security-critical IETF draft with
respect to impact on the Internet community that I have seen in 17
years of IETF participation.
This
Peter Saint-Andre wrote:
On 12/1/09 7:49 PM, Martin Rex wrote:
Stephen Farrell wrote:
7. 6.2 says: If servers wish to avoid attack they MUST
NOT do stuff Isn't that equivalent to servers SHOULD
NOT? I think a SHOULD NOT is better. (And that's the form
used in section 7.)
MUST
Normative language is not affected by case.
In the IETF normative terms are typically capitalized, but there is nothing in
their formal definition that requires this.
If a document has declared use of the standard normative terms, then it needs to
use them ONLY for normative purposes. If a
--On December 2, 2009 15:19:53 +0100 Martin Rex m...@sap.com wrote:
1. Running code: multiple implementations and interop testing was
performed on an earlier version of draft-ietf-tls-renegotiation.
Even EKR admitted that implementing the update is an insignificant
amount of work.
Pushing
I think that Stefan sums up the state of play well (after some 1,000 posts to
the TLS list with the number still rising steadily).
The IETF Last Call was premature, capricious even, given the ongoing debates on
the TLS list.
Technically, either draft will do but the mrex draft is superior in
On Wed, Dec 02, 2009 at 12:35:11PM -0500, Phillip Hallam-Baker wrote:
I want my personal machines to be part of the .hallambaker.com DNS
domain and look for configuration data there. I want my business
machines to be part of the .defaultdenysecurity.com domain and look
for configuration data
On Dec 1, 2009, at 4:36 AM, Stephen Farrell wrote:
On Nov 30, 2009, at 5:37 PM, The IESG wrote:
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 '
If multicast worked it would be the ideal protocol for NNTP. As far as
an NNTP client is concerned, the protocol could be functioning over
multicast.
In practice of course multicast would not be a useful protocol for
NNTP because you would at a minimum need a separate multicast channel
per
I don't think the IESG or ICANN should go there, or anywhere close.
There are three options:
1) Do not reserve .local. This would effectively mean throwing out the
draft as it depends on .local
2) Reserve .local for this particular protocol. This would be
inconsistent with current legacy use
The alternative would be to not use .local at all and insist on that
approach as a means of avoiding ICANNs perceived perogatives. I think
that would be a bad idea as the spec would not serve its intended
purpose.
On Wed, Dec 2, 2009 at 1:55 PM, Andrew Sullivan a...@shinkuro.com wrote:
On Wed,
Martin Rex wrote:
Chris Newman wrote:
Evaluation relative to draft-mrex-tls-secure-renegotiation-03:
Kudos to Martin Rex for producing such a good alternate proposal. The
introductory text up to and including section 4.1 is very good and would
improve draft-ietf-tls-renegotiation. While
Stephen Farrell wrote:
7. 6.2 says: If servers wish to avoid attack they MUST
NOT do stuff Isn't that equivalent to servers SHOULD
NOT? I think a SHOULD NOT is better. (And that's the form
used in section 7.)
This might be confusion with ISO terminology.
MUST == SHALL
MUST
Chris Newman wrote:
Evaluation relative to draft-mrex-tls-secure-renegotiation-03:
Kudos to Martin Rex for producing such a good alternate proposal. The
introductory text up to and including section 4.1 is very good and would
improve draft-ietf-tls-renegotiation. While I would support
Chris Newman wrote:
--On December 2, 2009 15:19:53 +0100 Martin Rex m...@sap.com wrote:
1. Running code: multiple implementations and interop testing was
performed on an earlier version of draft-ietf-tls-renegotiation.
Even EKR admitted that implementing the update is an
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
My colleagues and I support this draft. We would
In searching for the answer to a question I have regarding binary
encapsulation, I decided to join the IETF's listserv to see if anyone is
familiar with this.
In the context of packet headers (e.g. IP) and deep packet inspection, does
anyone know what binary encapsulation is, and if so, can
At 06:27 02-12-2009, Andrew Sullivan wrote:
There is in fact a request, it's just made indirectly. That was my
complaint.
I'll second your complaint. RFC 5226 provides guidelines to authors
on what sort of text should be added to their documents in order to
provide IANA clear guidelines.
20 matches
Mail list logo
