Barry Leiba has entered the following ballot position for
draft-ietf-uta-tls-attacks-04: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http
Barry Leiba has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http
15 at 5:12 PM, Peter Saint-Andre - &yet
wrote:
> Hi Barry, thanks for the feedback. My comments inline (not coordinated with
> my co-authors, who are in far-off timezones).
>
> On 2/18/15 5:16 PM, Barry Leiba wrote:
>>
>> Barry Leiba has entered the following ballot po
> Barry, following up, here is some proposed text (again, not yet coordinated
> with my co-authors).
Nice text all 'round; thanks.
One question on one of them:
> OLD
>Implementations and deployments SHOULD disable TLS-level compression
>([RFC5246], Section 6.2.2).
>
> NEW
>In order t
Looks nice. Thanks for working this out.
b
On Thursday, February 19, 2015, Peter Saint-Andre - &yet
wrote:
> On 2/19/15 10:03 AM, Peter Saint-Andre - &yet wrote:
>
>>
>> On 2/18/15 6:12 PM, Peter Saint-Andre - &yet wrote:
>>
>>&
Barry Leiba has entered the following ballot position for
draft-ietf-uta-tls-bcp-10: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http
Barry Leiba has entered the following ballot position for
draft-ietf-uta-xmpp-06: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http
Barry Leiba has entered the following ballot position for
draft-ietf-uta-xmpp-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http
>> It was pointed out to me that RFC4949 as a normative
>> reference here is a downref, and I didn't call that
>> out during the IETF LC for this document. (Sorry about
>> that.) Oddly, 4949 hasn't previously been added to the
>> downref registry. [1]
>
> That surprises me, given that RFC 4949 is a
> BTW, we based the user-oriented recommendation somewhat on current practices
> in web browsers. For instance, Firefox has an indicator showing whether a
> connection is encrypted, but also has an advanced option that enables a user
> to view the certificate and also see the TLS version and cipher
> To wit, I am not ignoring the process.
>
>Once a specific down reference to a particular document has been
>accepted by the community (e.g., has been mentioned in several Last
>Calls), an Area Director may waive subsequent notices in the Last
>Call of down references to it. This
>>>Once a specific down reference to a particular document has been
>>>accepted by the community (e.g., has been mentioned in several Last
>>>Calls), an Area Director may waive subsequent notices in the Last
>>>Call of down references to it. This should only occur when the same
>>>
ll wrote:
>>
>>>
>>> Top quoting: thanks all - let's do that. I'll add to the
>>> downref registry before the telechat unless someone else
>>> on the IESG yells.
>>>
>>> Cheers,
>>> S.
>>>
>&
This report strike me as what should have been feedback during the
development of the document, and not as a report of an error in the
publication of the document. Apart from that, it's basically a
different "spin" on the same point -- a different way of saying it,
with different emphasis, that ne
Leif appears to be in a time warp and is living in April 2016. His
point, though, remains
b
On Tue, Nov 3, 2015 at 2:03 AM, Leif Johansson wrote:
> On 2015-07-22 10:31, Leif Johansson wrote:
>> On 2015-07-22 10:28, Alexey Melnikov wrote:
>>> Hi,
>>> I've reviewed changes between -01 and -00
Barry Leiba has entered the following ballot position for
draft-ietf-uta-email-tls-certs-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
On Wed, Dec 16, 2015 at 7:33 AM, Alexey Melnikov
wrote:
> Hi Barry,
> I am going to quickly answer to your DISCUSS point and will reply to your
> comments separately:
>
> On 15/12/2015 21:20, Ba
(Sorry for the empty message I just sent...)
>> A small question before I go to "Yes":
>>
>> RFC 2595 Section 2.4 says:
>>
>> - Matching is case-insensitive.
>>
>> This document does not. Was that dropped intentionally?
>
> This was replaced by section 6.4 (Matching the DNS Domain Name Portio
Barry Leiba has entered the following ballot position for
draft-ietf-uta-email-tls-certs-07: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
> This seems to me to be clearly "updating" or "profiling" RFC6125 normative
> language, in the specific email use case.
Profiling it for email, yes. Why should that make it *update* the
document that specifies the general process? Profiles need to
normatively reference what they profile, but no
>> > To elaborate on one point a bit: it seems to me that it's harmful to
>> > security to allow the sender to unilaterally override the recipient's
>> > preferences that something be encrypted. To forestall one argument,
>> > yes, the sender knows the contents of the message, but the recipient
>>
> My idea of an ideal end-state for hop-by-hop security for e-mail is
> that:
>
> a) *senders* should be able to specify in the envelope that they want
>secure, encrypted, authenticated delivery of email at every hop,
>
> b) senders should get bounces when that cannot happen,
>
> c) *recipients
> > > My idea of an ideal end-state for hop-by-hop security for e-mail is
> > > that:
> >
> > See, this is why we often say that IETF folks should not generally try
> > to design UI things:
>
> What on Earth made you choose to be so condescending here? Do I not get
> to express my personal prefere
I think draft-tschofenig-uta-tls13-profile represents work that UTA
should take on, and that it is a good starting point for the working
group to use.
Review of version -01:
Section 2: Please change to the RFC 8174 boilerplate and add a
normative reference to RFC 8174.
Section 3, last paragraph:
Barry Leiba has entered the following ballot position for
draft-ietf-uta-tls-for-email-04: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Barry Leiba has entered the following ballot position for
draft-ietf-uta-tls-for-email-04: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https
Reviewer: Barry Leiba
Review result: Ready
Thanks for this: it’s well written, clear, and important. I have no further
comments and did not even find any typos to mention.
___
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le
27 matches
Mail list logo
