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

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 24 Oct 2016 21:58:42 +0800 (GMT+08:00)

Hello,

  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.

thanks a lot.

Jiankang Yao

-----原始邮件-----
发件人: [email-masked]
抄送: 
主题: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt

A new version of I-D, draft-yao-dnsop-accompanying-questions-01.txt
has been successfully submitted by Jiankang Yao and posted to the
IETF repository.

Name:		draft-yao-dnsop-accompanying-questions
Revision:	01
Title:		A DNS Query including A Main Question with Accompanying Questions
Document date:	2016-10-24
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-01.txt
Status:         https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/
Htmlized:       https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-yao-dnsop-accompanying-questions-01

Abstract:
   This document enables DNS initiators to send a main question
   accompanying with several related questions in a single DNS query,
   and enables DNS responders to put the answers into a single DNS
   response.  This mechanism can reduce the number of DNS round-trips
   per application work-unit.

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

---

From: Ozgur Karatas <[email-masked]>
Date: Mon, 24 Oct 2016 17:10:37 +0300

Dear Yao;

Hello, I will contribute to dnsop draft, I will share my thought on this doc.

Regards,

Ozgur Karatas

---

From: Bob Harold <[email-masked]>
Date: Mon, 24 Oct 2016 12:25:03 -0400

>    per application work-unit.
I like the concept.
Removing the UAQ bit was a good change.
The AQ bit and count are probably unnecessary, the option length will
determine the end of the options.

But I don't understand how the length of each prefix is determined.  Can
you explain?

Some minor spelling corrections:

section 4

‘make’ -> ‘makes’

section 5

‘accomanying’ -> ‘accompanying’

‘quesiton’-> ‘question’

-- 
Bob Harold

---

From: 神明達哉 <[email-masked]>
Date: Tue, 25 Oct 2016 03:47:48 +0900

At Mon, 24 Oct 2016 21:58:42 +0800 (GMT+08:00),

>   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

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 26 Oct 2016 09:58:18 +0800

From: Bob Harold
Date: 2016-10-25 00:25
To: Jiankang Yao; IETF DNSOP WG
Subject: Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt

> I like the concept.

thanks.

> The AQ bit and count are probably unnecessary, the option length will determine the end of the options.
> 

will consider to remove it in the next version.

> But I don't understand how the length of each prefix is determined.  Can you explain?
> 

 It is same to normal domain names. 

it is terminated by a label with zero length.We will clarify it in the next version.

> Some minor spelling corrections:

 thanks. 

 Jiankang Yao

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 26 Oct 2016 14:55:49 +0800

Dear JINMEI-san,

     Thanks a lot for your kind review. All your comments/questions are very helpful to improve the document.
More comments are followed below.

thanks a lot.

Jiankang Yao

From: 神明達哉
Date: 2016-10-25 02:47
To: Jiankang Yao
CC: dnsop; Paul Vixie

>   resolvers?  
yes.

Intended for Both  " between stub and recursive resolvers",  and  "between recursive and authoritative"

>If it's also intended to be used between recursive and

Most RRs needed to parallel query are normally located in the same zone.
In case of that some sub-domain names are delegated, the Delegation information will be returned to the recursive server.
the recursive server then check the sub-domain based on the Delegation information and get the answer.

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

yes.

>   the main question), it's ambiguous for which AQ the AAAA answer is.

For each accompanying question, I suggest to remove AQ and  Count/Seq  bits, and add AQ-ANCOUNT, AQ-NSCOUNT and AQ-ARCOUNT bits

AQ-ANCOUNT         an unsigned 16 bit integer specifying the number of
                resource records in the answer section.

AQ-NSCOUNT         an unsigned 16 bit integer specifying the number of name
                server resource records in the authority records
                section.

AQ-ARCOUNT         an unsigned 16 bit integer specifying the number of
                resource records in the additional records section.

>   answer (that follows the CNAME answer) is.

the proposed AQ-ANCOUNT, AQ-NSCOUNT and AQ-ARCOUNT bits can make it clear

>   ambiguous and whether some of them can be more troublesome than the

pls see above.

>   precise, eliminating any ambiguity depending on the interpretation.

If we describe the Prefix field as the domain name which uses the message compression specified in  section 4.1.4. of rfc1035, that may be easily understood.
We will update this part of text.

>    indicates that the responder is AQ unaware.

yes.

>   But, as far as I know actual implementations tend to NOT echo back

In this case, the Initiator receiving no AQ OPT will assume that the Responder  does not support AQ.

We will clarify it in the new vesion. Thanks for catching it.

 >    Answer     |        example.com  IN A 192.168.0.1              |

will update it.

thanks.

Jiankang Yao

---

From: 神明達哉 <[email-masked]>
Date: Thu, 27 Oct 2016 09:46:17 -0700

At Wed, 26 Oct 2016 14:55:49 +0800,

> Most RRs needed to parallel query are normally located in the same zone.

That's probably true, but since this proposal is quite generic we
can't simply assume that in the description of the protocol.

> the recursive server then check the sub-domain based on the Delegation information and get the answer.

I don't disagree with that as a high level observation.  But my point
in the question was that if it's supposed to work for delegation, it
should describe how it should work more clearly (specifically what
will be answered in the response from the authoritative server, and
specifically how the recursive server should react to it, etc).

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

IMO things like this should also be explicitly included in the doc.

--
JINMEI, Tatuya

---

From: "Jiankang Yao" <[email-masked]>
Date: Sun, 30 Oct 2016 21:49:00 +0800 (GMT+08:00)

Dear Jinmei-san,

   We have updated it to a new version.

  https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-02.txt

   We hope that the new version has addressed all your concerns.

   Thanks a lot for your kind comments to help to improve this document.

Best Regards,
Jiankang Yao

> -----原始邮件-----
> 发件人: "神明達哉" <[email-masked]>
> 发送时间: 2016-10-28 00:46:17 (星期五)
> 收件人: yaojk <[email-masked]>
> 抄送: dnsop <[email-masked]>, vixie <[email-masked]>
> 主题: Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-01.txt
>