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

[Ted Lemon <[e-mail]>]

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.]
>
>