Hi Russ,
On 1/26/19 7:27 AM, Russ Housley wrote:
> I have no problem with the protocol itself, but I do not understand how this
> specification can not have a reference to TLS.
It does have at least a couple of indirect references to TLS, through
STARTTLS (RFC 3207) and BCP 195. An informative
Thanks for the review, Stephan.
On 1/25/19 1:58 PM, Stephan Bosch wrote:
>
> I just quickly reviewed this document. I notice that this extension
> also applies to LMTP. Now, I wonder what should happen when Sieve [RFC
> 5228] is involved there, particularly when actions like "redirect",
>
After reading all the discussion I posted an -02 which takes out all
mention of ESNI. Here's why.
The most important issue is process. ESNI is currently described only in
an early I-D which will not turn into an RFC for a long time. If I
reference it, this draft will be stuck behind ESNI,
Hiya,
As is probably obvious I don't agree with this. But I can raise
it when the draft gets to IETF LC, so we don't need to bang on
about it.
On 26/01/2019 17:40, John R Levine wrote:
> After reading all the discussion I posted an -02 which takes out all
> mention of ESNI. Here's why.
>
>
> On Jan 26, 2019, at 12:40 PM, John R Levine wrote:
>
> After reading all the discussion I posted an -02 which takes out all mention
> of ESNI. Here's why.
>
> More substantively, I would be surprised if any MTA ever implements ESNI
> because it makes no sense for mail. On the web,
After reading all the discussion I posted an -02 which takes out all
mention of ESNI. Here's why.
The most important issue is process. ESNI is currently described only in
an early I-D which will not turn into an RFC for a long time. If I
reference it, this draft will be stuck behind ESNI,
I have no problem with the protocol itself, but I do not understand how this
specification can not have a reference to TLS.
Russ
> On Jan 25, 2019, at 10:00 AM, The IESG wrote:
>
>
> The IESG has received a request from the Using TLS in Applications WG (uta)
> to consider the following
