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

[Ted Lemon <[e-mail]>]

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