Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt

[神明達哉 <[e-mail]>]

At Mon, 24 Oct 2016 21:58:42 +0800 (GMT+08:00),
"Jiankang Yao" <[e-mail]> wrote:

>   We have updated it to the new version, simplying the mechanism.
>   pls kindly help to review it. any comments are welcome.
>   If Seoul DNSOP meeting has some time slot for it, I will appreciate it.

A few comments on a quick read:

- Does it assume to be used for exchanges between stub and recursive
  resolvers?  If it's also intended to be used between recursive and
  authoritative, how does it handle a delegation answer?

- Should we assume SOA('s) in the authority section for negative
  answers?

- What if AQ-TYPE is ANY?  I suspect the answer can be ambiguous in
  that case (even though it may not be a big issue in practice).  For
  example, if the first AQ-TYPE is ANY and the second is AAAA, and the
  answer section only contains one AAAA (in addition to the answer to
  the main question), it's ambiguous for which AQ the AAAA answer is.

- Likewise, what if the result is a CNAME chain?  For example, if the
  answer to the first AQ is a CNAME and the name for the second AQ is
  the CNAME's target, it can be ambiguous for which AQ the subsequent
  answer (that follows the CNAME answer) is.

- I wonder whether there are other cases where the results can be
  ambiguous and whether some of them can be more troublesome than the
  above examples.

- Maybe I missed something obvious, but the purpose of the AQ bit, and
  Count and Seq fields is not clear to me.  Some more explanations
  might help.

- Regarding the definition of "Prefix" in Section 3:

   o  Prefix field is a substring between the main domain name of the
      main quesiton and the accompanying domain name of the accompanying
      question.

  what "substring" means is vague to me.  It's not even clear whether
  this is an ascii string or it's a complete wire-format domain name.
  Likewise, the notation of "S-S1" is quite informal.  Since this is
  part of a formal definition, I'd suggest making it more formal and
  precise, eliminating any ambiguity depending on the interpretation.

- This part of Section 4 seems to assume a responder implementation
  generally echos back unrecognized EDNS options:

   [...] An AQ
   unaware responder is expected to ignore the AQ OPT of the query, and
   may echo the received OPT back into additional section of the
   response message.

  and the following part of Section 5 seems to rely on that
  assumption:

   If the initial value of the AQ-RCODE is unchanged in the response, it
   indicates that the responder is AQ unaware.

  But, as far as I know actual implementations tend to NOT echo back
  unrecognized options.

- Section 6: there's a missing period after 'example.com':

    Answer     |        example.com  IN A 192.168.0.1              |

--
JINMEI, Tatuya