[xmpp] Stephen Farrell's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-xmpp-dna-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- section 3: does nobody ever use mutually authenticated
TLS for this with XMPP? (Just wondering.)

- 3.2: I didn't know that XMPP clients send a user ID in
cleartext before turning on TLS. Pity that.  Is it ok
for a client to fake that and then later authenticate as
a different entity such as "[e-mail]"?

- 3.2, step 5: "proving" isn't quite right but is good
enough here.

- 4.1: Please separate the seperable pictures by at
least some whitespace but ideally with captions.  Right
now it looks initially as if it's just one big figure.
At present, I find that figure makes things less clear
rather than more.

- 4.2, bullets: the 2nd last one here is really similar
to the 1st two (as I read 'em). Maybe consider merging.
And the use of "is trusted by" in the 1st two is a bit
inaccurate, but could be lived with;-)

- 4.4.1: should the refs for dialback (and the "first
specified..." comment) be earlier?

- 5.1: Is there going to be another "XMPP with DANE
prooftype" document? I'm not sure that 5.1 alone is
enough, and there is one for POSH, so I wondered.

- 5.2: does this repeat text from the POSH I-D?  If so,
is that a good idea?

- 8.1: Huh? Why aren't these in the POSH I-d?

- 8.1/8.2: Is it a good/bad idea to have structure in
the .well-known URIs and where that structure is not a
pathname? Personally, I think it's not a great idea but
that's just a personal preference. I also don't think
"_tcp.json" is good to include in the URI.