Re: [dnssd] Review of draft-ietf-dnssd-pairing-02 (Ted Lemon)

[Ted Lemon <[e-mail]>]

Oh, and the only issue I noticed in sections 2 and 3 is that there's at
least one use of the word "relation" where the word "relationship" is
what's meant.

On Tue, Jul 18, 2017 at 6:55 PM, Ted Lemon <[e-mail]> wrote:

> Okay, having now read sections 2 and 3, I still believe they should be in
> a separate document.   This isn't just because of what I said in the
> previous message, which I still think is true.   It's also that this
> document actually will serve as a useful jumping-off point for further work
> on authentication in homenet.   So separating out the informational portion
> of the document from the technical specification makes both documents more
> useful (at least, selfishly, to me).
>
> On Tue, Jul 18, 2017 at 4:18 PM, Ted Lemon <[e-mail]> wrote:
>
>> I agreed to review this document before the next meeting, and it is still
>> (barely) before the next meeting, so here's my review:
>>
>> In the abstract, paragraph 2, s/relation/relationship/ unless we are
>> talking about an rdbms. :)
>>
>> In the introduction, point 1, "disclose its presence" seems like the
>> wrong thing to say, since merely sending a packet on the network discloses
>> the device's presence.   I think, possibly incorrectly, that what you mean
>> here is "reveal information that could be used to identify it."
>>
>> Skipping to section 4, because I want to see if the document works
>> without sections 2 and 3:
>>
>> In the first paragraph of section 4, you don't say which device serves as
>> a server and which as a client.   Presumably the client is the one where
>> the user initiates the pairing, which is arbitrary and doesn't really
>> matter?   Might be worth saying so explicitly.
>>
>> In 4.1, the QR code scanning seems like it's a separate protocol.   Might
>> be less confusing to leave it out of this doc and do a follow-on doc that
>> describes how to do it in more detail.   It feels like a distraction.
>> This is true as QR codes come up later in the discussion.
>>
>> Also in 4.1, it might be good to go into a bit more detail about the
>> service records that should be published.   I think that this may be
>> incomplete.   If you want, I can look into this in more detail and propose
>> text if I still think it's a problem.   E.g., I assume class and weight in
>> the SRV record are 0 and are ignored by the client.   I assume that the
>> text record is empty.   It would be good to say this, and to say that the
>> client ignores these fields.   This observation may also apply to the
>> private service discovery document--I didn't think of this when I was
>> reviewing it.
>>
>> p. 18, first full paragraph, SHOULD .. MAY doesn't make sense.   Either
>> this is important, or it's not.   If it's important, then you need to give
>> the implementer clear guidance on what to do if the API doesn't let them
>> figure out which hash algorithm was used.   The MAY seems content-free.   I
>> would think you would want "SHOULD/MUST use the strongest mutually
>> available hash algorithm."   Personally, I'd just say MUST, and if the API
>> doesn't support this, they need to use a different API.  That way you are
>> trusting that the infrastructure is going to make the best decision
>> possible based on the situation at the time that software was released,
>> rather than hard-coding a suggestion for a hash that we think is strong now
>> but may not think is strong later.
>>
>> In the second paragraph of section 5, time frames are discussed in very
>> vague terms.   It might be a good idea to be less vague.   If we don't know
>> how to be less vague, I don't really know how to implement this.
>>
>> I haven't tried to implement this, so I don't know for sure if this is
>> true, but based on reading the document I believe I could implement it, and
>> it's not hard to implement.   I think the additional clarity I asked for
>> above in section 4.1 would make interop more likely, but as a potential
>> implementer I would make the assumptions I suggested requiring, and I think
>> that would work.
>>
>> Going back:
>>
>> I now definitely agree with the suggestion to separate this into two
>> drafts.   The document without sections 2&3 gives enough information to
>> implement, and there is enough motivational information in the introduction
>> (I haven't read sections 2&3 yet).   Having just scrolled back over
>> sections 2&3, I think leaving these in the document will discourage
>> potential implementers.
>>
>> [actually, I'm just going to send this in two parts--I might not get to
>> the rest of the review for a while, and hopefully this part is useful.]
>>
>>
>