Jouni, Thank you for reviewing the document and apologies for the belated reply. Please find my answers to your comments inlined below:
On Mon, Dec 21, 2015 at 12:41 PM, Jouni Korhonen <[email protected]> wrote: [...] > Summary: This draft is ready for publication as a standard track RFC with > small nits to be corrected. > > Major issues: None. > > Minor issues: > > * The document seems to imply/assume that a DNS query has multiple question > sections with different QTYPEs. At least the exmaples in lines 226 and 278 > make me read so. I wonder whether this is actually the intention. If not, > reword/edit accordingly to avoid the confusion. This is to avoid known > issues when QDCOUNT>1 or have a justification to do so. That was a formatting issue that ended up putting two queries on the same line. I've fixed the formatting and clarified that these are different queries. E.g.: An Initiator willing to associate with a node would typically issue the following queries: o Query #1: QNAME=www.example.com, QTYPE=HIP (QCLASS=IN is assumed and omitted from the examples) Which returns a DNS packet with RCODE=0 and one or more HIP RRs with the HIT and HI (e.g., HIT-R and HI-R) of the Responder in the answer section, but no RVS. o Query #2: QNAME=www.example.com, QTYPE=A o Query #3: QNAME=www.example.com, QTYPE=AAAA Which would return DNS packets with RCODE=0 and respectively one or more A or AAAA RRs containing IP address(es) of the Responder (e.g., IP-R) in their answer sections. > * Section 5 and the assiciated HIP RR figure mostly mentions public key but > not HI anymore. For the clarity I would suggest adding text that the public > key is the HI as well. I've clarified in section 5 that the public key _is_ the HI: 5. HIP RR Storage Format The RDATA for a HIP RR consists of a public key algorithm type, the HIT length, a HIT, a public key (i.e., a HI), and optionally one or more rendezvous server(s). > Nits/editorial comments: > > * IDnits complains on outdated reference: draft-ietf-hip-rfc5204-bis-06 but > this can be corrected e.g., by the RFC Editor. This is automatically updated at draft generation by XML2RFC, and, as you note, at the time of publication by the RFC Editor. > * Line 97: s/address\(es\)/addresses done > * Line 162: s/obtain/obtains done > * Line 163: s/initiate/initiates done. > * The document sometime uses "initiator" instead of "Initiator" e.g., in > line 173. Suggest always using "Initiator" when meaning the HIP Initiator. done. > * API is never expanded. expanded at first use. > * Sentence between lines 204-206 is somewhat hard to parse. Suggest > rewording. reworded more simply: In addition to its IP address(es) (IP-R), a HIP node (R) with a single static network attachment that wishes to be reachable by reference to its FQDN (www.example.com) to act as a Responder would store in the DNS a HIP resource record containing its Host Identity (HI-R) and Host Identity Tag (HIT-R). > * Line 201: "HIP node (R)" probably means Responder. Suggest actually > stating that. done as part of the rewording above. Thanks again for the review. Best regards, --julien _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
