In general I support this document, with some minor comments below:
Abstract:
s/approache/approach
Section 1.1
2nd paragraph:
s/recomendations/recommendations
"it" is repeated twice in the sentence starting: "While these recomendations
are mainly aimed at Host Validators it it..."
s/Validatating/Validating
Last paragraph:
s/directy/directly
"...can not talk directy to a Resolver
the tests below do not address how to overcome that."
missing a semicolon? Or "...Resolver. The tests below..." Don't know for sure
but sounds strange the way it is currently.
Also, the paragraph talks about users, but maybe applications may be more
appropriate since the end user may not be aware of or care about proxies. The
meaning is clear though so I can live with the current wording.
Section 1.2.
2nd paragraph:
s/digiest/digest
Section 3
Title:
s/Compilance/Compliance
2nd paragraph
s/assumtption/assumption
3rd paragraph:
not a huge fan of the salty language since the goal should be to fix
broken middleboxes and not just call them crap and move on. Also, might want
to mention that middleboxes can also cause strange behavior with some
authoritative servers but that this should not necessary change the rank/use of
a recursive resolver. In other words, just because some queries start
returning bad or strange results, that should not be used to change the
rank/preference of the recursive resolver unless it happens with multiple
queries.
Section 3.1.5
While the test for the AD bit gives the host information about the validating
status of the upstream resolver, it really doesn't give full information about
what trust anchors are in use. This might become an issue with split DNS,
which isn't mentioned. I know the authors don't want to get stuck in that
quagmire, but it exists and will need to be acknowledged (since it can't be
solved).
Scott
On Jul 1, 2015, at 10:12 AM, Olafur Gudmundsson <[email protected]> wrote:
>>
>> On Jul 1, 2015, at 9:31 AM, Tim Wicinski <[email protected]> wrote:
>>
>>
>> Thanks Olafur. The Workign Group should discuss this as it was originally
>> planned to go into a Working Group Last Call. It can still be taken in this
>> direction.
>>
>> tim
>>
>>
> Tim
> We request a WGLC on the document
>
> Olafur
>
>> On 7/1/15 8:52 AM, Olafur Gudmundsson wrote:
>>> This version is a final version from the editors.
>>> We explicitly punt on explaining how to overcome the situation when a
>>> ´proxy/forwarder’ “randomly” sends queries to
>>> Resolvers with different capabilities.
>>>
>>> Olafur
>>>
>>>> On Jul 1, 2015, at 8:49 AM, [email protected] wrote:
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the Domain Name System Operations Working
>>>> Group of the IETF.
>>>>
>>>> Title : DNSSEC Roadblock Avoidance
>>>> Authors : Wes Hardaker
>>>> Olafur Gudmundsson
>>>> Suresh Krishnaswamy
>>>> Filename : draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt
>>>> Pages : 16
>>>> Date : 2015-07-01
>>>>
>>>> Abstract:
>>>> This document describes problems that a DNSSEC aware resolver/
>>>> application might run into within a non-compliant infrastructure. It
>>>> outline potential detection and mitigation techniques. The scope of
>>>> the document is to create a shared approache to detect and overcome
>>>> network issues that a DNSSEC software/system may face.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/
>>>>
>>>> There's also a htmlized version available at:
>>>> https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-02
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-02
>>>>
>>>>
>>>> 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.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> DNSOP mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
===================================
Scott Rose
NIST
[email protected]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
