Re: [Gen-art] Gen-RTP LC review of draft-ietf-hip-rfc5205-bis-08

["Jouni.nosmap" <[e-mail]>]

Thanks. I am OK with the proposed texts/corrections. 

Jouni

Sent from a smart phone.. Mind the typos..

> Julien Laganier <[e-mail]> 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 <[e-mail]> 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