Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-rfc2845bis-07: No Objection
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
> On 11 Mar 2020, at 00:54, Warren Kumari wrote:
>
> On Thu, Dec 19, 2019 at 8:28 PM Warren Kumari wrote:
>>
>> [ Note: CC list edited ]
>>
>> Hi there authors,
>>
>> During the IETF LC Stephane supported the document (an important
>> document, worthy of publication), but noted that:
>> 1:
On Mar 10, 2020, at 18:10, Paul Hoffman wrote:
> If we can determine when something in the realm of "almost all" DNSEC signing
> with algorithms that use SHA-1 is done, then it is reasonable for the WG to
> propose that software that validates DNSSEC can stop doing so.
Which is quite
On Mar 9, 2020, at 7:40 PM, Tony Finch wrote:
>
> Paul Hoffman wrote:
>
>> This confuses a harm purposely caused by authorities (in this case, the
>> IETF), with self-harm (in this case, a zone owner who didn't hear about
>> the importance of doing an algorithm rollover, or did hear but didn't
Hiya,
On 10/03/2020 19:11, Paul Vixie wrote:
> On Tuesday, 10 March 2020 19:05:39 UTC Stephen Farrell wrote:
>> Paul,
>>
>> ...
>>
>> What's the difference between having a port number
>> as part of HTTPSSVC (or whatever we call it;-) in
>> the DNS and having a web page on 443 that includes
>>
On Tue, Mar 10, 2020 at 2:54 PM Paul Vixie wrote:
> httpssvc is not
> an alternate service description permitting fallback to the
> non-alternative;
> httpssvc is the service description itself.
>
7.2. Relationship to Alt-Svc
Publishing a ServiceForm HTTPSSVC record in DNS is intended to
On Tuesday, 10 March 2020 19:05:39 UTC Stephen Farrell wrote:
> Paul,
>
> ...
>
> What's the difference between having a port number
> as part of HTTPSSVC (or whatever we call it;-) in
> the DNS and having a web page on 443 that includes
> hrefs with https:// schemed URLs that are not using
>
Paul,
On 10/03/2020 18:54, Paul Vixie wrote:
> the httpssvc "port" parameter leading
> a service operator to put something on an "alternative origin" whose port
> number will be broadly unrecognized by far end managed private networks,
> which
> would prevent flow-state creation, thus
On Tuesday, 10 March 2020 18:25:57 UTC Patrick McManus wrote:
> alt-svc is quite robust to reachability failures of the alternative origins
> should some client find itself on a network that filters full transit.
>
> This process is already existing technology (rfc 7838). From that
> perspective
We should also look at how and where we want to separate operational
guidance from what mechanisms are available. Ideally we'd minimize
foot-guns
(hence the inclusion of a default transport, at least for the HTTPS
use-cases)
and we should have safe defaults, but I'm not sure to what degree
we
alt-svc is quite robust to reachability failures of the alternative origins
should some client find itself on a network that filters full transit.
This process is already existing technology (rfc 7838). From that
perspective the DNS record is just a way to bootstrap it over DNS rather
than the
On Tuesday, 10 March 2020 13:30:53 UTC Patrick McManus wrote:
> another positive feature of ports in this record is that it provides some
> address space independent of the origin security model of the URI. By this
> I mean that https://www.foo.com(implicit :443) and https://www.foo.com:555
> are
On Thu, Dec 19, 2019 at 8:28 PM Warren Kumari wrote:
>
> [ Note: CC list edited ]
>
> Hi there authors,
>
> During the IETF LC Stephane supported the document (an important
> document, worthy of publication), but noted that:
> 1: the document only deals with auth servers and that it should be
>
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Multi Signer DNSSEC models'
as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send
another positive feature of ports in this record is that it provides some
address space independent of the origin security model of the URI. By this
I mean that https://www.foo.com(implicit :443) and https://www.foo.com:555
are different origins with different web security boundaries. While two
Mirja Kühlewind has entered the following ballot position for
draft-ietf-dnsop-7706bis-10: No Objection
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
Thank you - IETF LC has been started.
W
On Mon, Mar 9, 2020 at 10:48 PM Shumon Huque wrote:
>
> On Mon, Jan 20, 2020 at 3:21 PM Shumon Huque wrote:
>>
>>
>> On Sun, Jan 12, 2020 at 9:24 PM Warren Kumari wrote:
>>>
>>> Hi there,
>>>
>>> Firstly, thank you for a well written and easy to
17 matches
Mail list logo
