Petr, 
sorry of my tardiness,
I’m fine with adding text along the lines you outlined, as long as there is
and IPR statement that is inline with the terms you referred. 

Wes, do you agree ? 

Olafur

> On Oct 23, 2015, at 5:38 AM, Petr Spacek <pspacek@redhat.com> wrote:
> 
> On 7.10.2015 17:47, Petr Spacek wrote:
>> On 25.8.2015 17:34, Petr Spacek wrote:
>>> On 26.6.2015 22:45, Olafur Gudmundsson wrote:
>>>>> On Feb 11, 2015, at 11:24 AM, Petr Spacek <pspacek@redhat.com> wrote:
>>> [...]
>>>>> Few guys in Red Hat proposed "hacky but almost-reliable automatic" way how to
>>>>> improve usability without sacrificing security.
>>>>> 
>>>>> 
>>>>> Disclaimer
>>>>> ==========
>>>>> Method described below is covered by US patent application named "USING DOMAIN
>>>>> NAME SYSTEM SECURITY EXTENSIONS IN A MIXED-MODE ENVIRONMENT".
>>>>> 
>>>>> See Red Hat, Inc. Statement of Position and Our Promise on Software Patents:
>>>>> http://www.redhat.com/legal/patent_policy.html
>>>>> 
>>>>> 
>>>> I reject the below text as I do not want any IPR on anything in this informational document. 
>>>> Olafur
>>> 
>>> Olafur and dnsop chairs,
>>> 
>>> would you be willing to accept the text below if Red Hat granted a license
>>> similar to https://datatracker.ietf.org/ipr/1430/ ?
>>> (I.e. the patent could be asserted only for defensive purposes.)
>>> 
>>> I'm asking because the text might be suitable for some other document
>>> describing split-dns, so this question is still valid even if the text might
>>> not be directly usable in draft-ietf-dnsop-dnssec-roadblock-avoidance.
>>> 
>>> Thank you for considering this as an option.
>> 
>> I'm sorry for nagging you again, but we are still interesting in knowing if
>> proposed approach how to deal with patent issue would be acceptable to dnsop.
>> 
>> Thank you very much,
>> Petr Spacek  @  Red Hat
> 
> Hello once again,
> 
> we as a company are really interested in contributing to IETF but we have to
> sort out situation about the patent first. Could chairs (or possibly draft
> authors) clarify dnsop (or author's?) position on this?
> 
> Thank you for your time,
> Petr Spacek @ Red Hat
> 
> 
>>> Petr Spacek @ Red Hat
>>> 
>>>>> The Hack
>>>>> ========
>>>>> Fundamental assumption:
>>>>> Internal & external DNS view are both signed with the same keys or both
>>>>> unsigned. This assumption allows the method to work without explicit
>>>>> configuration on every client and removes dependency on reliable/secure
>>>>> network-detection logic.
>>>>> 
>>>>> 
>>>>> The main idea can re-phrased as amendment to section 5 of the draft:
>>>>> 
>>>>>  The general fallback approach can be described by the following
>>>>>  sequence:
>>>>> 
>>>>>      If the resolver is labeled as "Validator" or "DNSSEC aware"
>>>>>          Send query through this resolver and perform local
>>>>>          validation on the results.
>>>>> 
>>>>>          If validation fails, try the next resolver
>>>>> 
>>>>>      Else if the resolver is labeled "Not a DNS Resolver" or
>>>>>         "Non-DNSSEC capable"
>>>>>          Mark it as unusable and try next resolver
>>>>> 
>>>>> --- amended text begins here ---
>>>>> 
>>>>>      Else if no more resolvers are configured and if direct queries
>>>>>      are supported
>>>>>         1. Try iterating from Root
>>>>> 
>>>>>         2. If the answer is SECURE/BOGUS
>>>>>           Return the result of iteration.
>>>>> 
>>>>>         3. If the answer is INSECURE
>>>>>           Re-query "Non-DNSSEC capable" servers and get answer
>>>>>           from "Non-DNSSEC capable" servers.
>>>>>           Set AD bit to 0 before returning the answer to client.
>>>>> 
>>>>>      Else return a useful error code
>>>>> 
>>>>> 
>>>>> This method covers DNS split-views with internal unsigned views pretty
>>>>> nicely as long as the fundamental assumption holds. (Naturally it works only
>>>>> for cases where fallback to iteration is possible.)
>>>>> 
>>>>> We wanted to write Unbound module for this but it is harder than it seems.
>>>>> (Proof-of-concept with stand-alone DNS proxy works fine, we have problem with
>>>>> Unbound module architecture - not with the described method.)
>>>>> 
>>>>> Feel free to incorporate the idea to the draft if you wish.
>>>>> 
>>>>> -- 
>>>>> Petr Spacek  @  Red Hat