Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-05.txt

2021-01-14 Thread tirumal reddy
Hi Joey,

Thanks for the interest in the draft. We published a revised draft
https://tools.ietf.org/html/draft-reddy-dnsop-error-page-06  to address the
comments from the WG during the presentation at IETF-109.

Further comments and suggestions are welcome.

Cheers,
-Tiru

On Sat, 19 Dec 2020 at 02:57, Joey S  wrote:

> Dear Tirumal, dnsop,
>
> Following up on the last IETF session and observations regarding the
> usability of this draft at the end of the meeting, this draft covers 2
> important areas from my perspective: DNS error information made available
> to the end-users as opposed to (mainly) administrators/operators from the
> extended-DNS-errors RFC (rfc8914); the promotion of increased DNS security
> as a means to achieve reliable information.
>
> For those two reasons I'd like to ask:
>
>- Are there specific sections of the I-D that require input?
>- Are there remaining questions from the 109 meeting?
>- What's currently needed for potentially moving forward with WG
>adoption?
>
> Thank you,
>
> --
> Joey Salazar
> Digital Sr. Programme Officer
> ARTICLE 19
> 6E9C 95E5 5BED 9413 5D08 55D5 0A40 4136 0DF0 1A91
>
> On 14-Oct-20 10:50 PM, tirumal reddy wrote:
>
> Hi all,
>
> This revision https://tools.ietf.org/html/draft-reddy-dnsop-error-page-05
> updates security considerations section to address comments from the WG
> during the presentation at IETF-108.
>
> As a reminder, it discusses a method to return an URL that explains the
> reason the DNS query was filtered. It defines an Error page URI EDNS0
> option to return an URI Template which when accessed provides the reason
> the DNS query was filtered. The Error Page URI Template is protected with a
> signature for data origin authentication. It discusses mandatory rules
> (e.g., DoH and strict privacy profile in DoT) to process the Error page URI
> EDNS0 option.
>
> Further comments and suggestions are welcome.
>
> Cheers,
> -Tiru
>
> -- Forwarded message -
> From: 
> Date: Wed, 14 Oct 2020 at 11:25
> Subject: New Version Notification for draft-reddy-dnsop-error-page-05.txt
> To: Tirumaleswar Reddy.K , Mohamed Boucadair <
> mohamed.boucad...@orange.com>, Neil Cook , Dan
> Wing 
>
>
>
> A new version of I-D, draft-reddy-dnsop-error-page-05.txt
> has been successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name:   draft-reddy-dnsop-error-page
> Revision:   05
> Title:  DNS Access Denied Error page
> Document date:  2020-10-13
> Group:  Individual Submission
> Pages:  16
> URL:
> https://www.ietf.org/archive/id/draft-reddy-dnsop-error-page-05.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reddy-dnsop-error-page
> Htmlized:
> https://tools.ietf.org/html/draft-reddy-dnsop-error-page-05
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-reddy-dnsop-error-page-05
>
> Abstract:
>When a DNS server filters a query, the response conveys no detailed
>explanation of why that query was blocked, leading thus to end-user
>confusion.  A solution is needed to enhance the user experience.
>
>This document defines a method to return an URI that explains the
>reason why a DNS query was filtered.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> ___
> DNSOP mailing listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] SVCB without A/AAAA records at the service name

2021-01-14 Thread Martin Thomson
As requested (I'm not engaged here enough to understand the terms of 
engagement, so my apologies for using an interaction form I'm accustomed to), 
moving discussion from https://github.com/MikeBishop/dns-alt-svc/issues/287 to 
here:

The SVCB draft basically mandates a fallback to A/.  I think that this is 
not universal and that this should instead be made an option.

For HTTP, the fallback is necessary.  For a new protocol, a fallback could be 
undesirable.  Especially if you want to deploy that protocol using a service 
name on which you have already deployed HTTP.  If you don't want your HTTP 
servers getting connection attempts for the new protocol, the fallback is more 
nuisance than useful.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop