Hi, Paul, Thanks for the followup! That works ...
Spencer On Fri, Sep 18, 2015 at 3:59 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > On 18 Sep 2015, at 13:41, Spencer Dawkins at IETF wrote: > > Hi, Paul, >> >> On Fri, Sep 18, 2015 at 2:08 PM, Paul Hoffman <paul.hoff...@vpnc.org> >> wrote: >> >> On 16 Sep 2015, at 9:52, Spencer Dawkins wrote: >>> >>> If this >>> >>>> >>>> For example, at the time this document is published, the "au" TLD >>>> is not considered a public suffix, but the "com.au" domain is. >>>> (Note that this example might change in the future.) >>>> >>>> is intended to say that a subdomain may be a public suffix when its >>>> domain is not, that could be stated more clearly. If it's intended to >>>> say >>>> something else, I don't know what that is (and "For example" didn't >>>> help!) >>>> >>>> >>> It is just an example of what we already said was an area of >>> disagreement. >>> >> >> >> Hmmm. I didn't get that from the text. I'm not understanding what the >> question is, that people disagree about the answer to. Could you help me >> understand that? >> > > I think I see the problem now. The text can simply be "For example, at the > time this document is published, the "com.au" domain is considered a public > suffix. (Note that this example might change in the future.)". > > I wonder if flipping the order would make your point more clearly. >> >> DNSSEC-aware and DNSSEC-unaware: these two terms are not >> defined in Section 2 of [RFC4033], but many >> types of resolvers and validators, including "non-validating >> security-aware stub resolver", "non-validating stub resolver", >> "security-aware name server", "security-aware recursive name >> server", "security-aware resolver", "security-aware stub >> resolver", and "security-oblivious 'anything'" are defined there. >> "DNSSEC-aware" and "DNSSEC-unaware" are used in later RFCs, >> but the terms that have been formally defined are likely better >> choices for new documents. (Note that the term "validating resolver", >> which is used in some places in those documents, is nevertheless >> not defined in that section.) >> >> >> >>> >>> I'm also slightly confused about why "validating resolver" is mentioned >>> >>>> in this list item, instead of appearing in a separate list item. Is the >>>> common element that it's not defined anywhere else, either? >>>> >>>> >>> More the fact that it is another DNSSEC-related term. >>> >>> >> That helps. Perhaps s/nevertheless/also/ would have made this point more >> clearly to me. >> > > These seem like reasonable changes. > > --Paul Hoffman >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
