I strongly support publishing this draft either in its present form or with
any modification that does not impact the protocol's security analysis.
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
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
> Behalf Of Peter Saint-Andre
> Sent: Tuesday, December 01, 2009 7:06 PM
> To: m...@sap.com
> Cc: ietf@ietf.org
> Subject: NOT RECOMMENDED (was: Re: [TLS] Last
> Call:draft-ietf-tls-renegotiation)
>
>
On 12/1/09 7:49 PM, Martin Rex wrote:
> Stephen Farrell wrote:
>> 7. 6.2 says: "If servers wish to <> they MUST
>> NOT <>" 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
At 14:29 01-12-2009, Andrew Sullivan wrote:
The IANA Considerations section is a little coy in the way it notes
that the document reserves .local. Moreover, the action is not merely
to IANA, but strictly to ICANN, and I worry about the procedural rules
for such an action. If there is a strong r
Dear colleagues,
I have read draft-cheshire-dnsext-multicastdns-08. I have some
comments. This is not an exhaustive or complete review, although I
have shared some previous observations with the authors of the
document.
First, I must emphasise that, while I currently serve as one of the
chairs
On 2009-12-01 23:57, Simon Josefsson wrote:
> Scott Brim 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 can see. The current approach of only
>>> having people participate,
Hi,
I find only the draft version of draft-jeong-nsis-3gpp-qosm-02.txt .
What is the latest development w.r.t '3GPP QoS Model for Networks Using 3GPP
QoS Classes'.
Any other related/alternative RFC available for this ?
Thx in advans,
Karthik Balaguru
___
On 09-12-01 12:19 AM, "David-Sarah Hopwood"
wrote:
> 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 '
>> as a Proposed Standard
>>
I disagree that the last call is premature. I realize that not everyone
is happy with all aspects of the current document but a clear majority
of people on the TLS list have voiced their support for it. I do not
see any consensus that the existing approach is flawed, nor do I see
evidence of an e
I support this draft.
-Original Message-
From: tls-boun...@ietf.org [mailto:tls-boun...@ietf.org] On Behalf Of
The IESG
Sent: Monday, November 30, 2009 10:38 AM
To: IETF-Announce
Cc: t...@ietf.org
Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport
LayerSecurity (TLS) Renegot
Bodo Moeller wrote:
>On Nov 30, 2009, at 4: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 '
>>as a Proposed Standard
>>
>> Th
Bodo Moeller wrote:
>
> There is no good reason for this asymmetry of having just the client's
> verify_data in the client's message, but both the client's and the
> server's verify_data in the server's message -- the latter is pure
> overhead, both in the specification and in the on-the-wire prot
I am not so sure that immediately going to PS is the best approach
considering the overall objective. My goal here would be to encourage
the widest possible adoption of the spec by equipment manufacturers.
The weakness I see in both the Microsoft and the Apple attempts to
simplify ease of net devi
All,
Al Morton has recently raised concerns RE taking the Maximum Packet Size
parameter out of the QSPEC document. Based on his comments (given below, along
with other background), it appears that the parameter should be put back
into the QSPEC.
Please comment on whether the parameter s
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 '
> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks,
On Nov 30, 2009, at 4: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 '
as a Proposed Standard
The IESG plans to make a decision in the
Yoav Nir 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 '
>>as a Proposed Standard
>>
>> Th
Scott Brim 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 can see. The current approach of only
>> having people participate, and disclose patents, in the IETF is easy to
>> wor
Arnt Gulbrandsen wrote:
> Simon Josefsson writes:
>> Arnt Gulbrandsen 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 p
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 '
>as a Proposed Standard
>
> The IESG plans to make a de
Simon Josefsson writes:
Arnt Gulbrandsen 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 aroun
21 matches
Mail list logo