Thanks. I am OK with the proposed texts/corrections. Jouni
Sent from a smart phone.. Mind the typos.. > Julien Laganier <[email protected]> kirjoitti 31.1.2016 kello 15.55: > > 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
