Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
draft-ietf-xmpp-dna-11
Yes
(Ben Campbell)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Kathleen Moriarty)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 10 and is now closed.
Ben Campbell Former IESG member
Yes
Yes
(for -10)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -10)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -10)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -10)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2015-07-29 for -10)
Unknown
Apart from the ".well-known" issue brought up in my comments to xmpp-posh, I have only one, tiny comment here: -- Section 1 -- If such delegation is not done in a secure manner, then the domain name association cannot be verified. Really small point: many people find these sorts of negative-negative constructions to be confusing, so I suggest this: NEW The domain name association can only be verified when the delegation is done in a secure manner. END
Benoît Claise Former IESG member
No Objection
No Objection
(2015-08-06 for -10)
Unknown
The conversation started between Mahesh (OPS-DIR reviewer) and the authors on the following points: Summary: This document defines new “prooftype” used to establish a strong association between a domain name and an XML stream. There are two companion documents draft-ietf-xmpp-posh-04 and draft-ietf-dane-srv-12 that should be viewed as part of reviewing this document. If there are any management requirements to configure the new “prooftype”, they have not been discussed as part of this document. I did not review the companion documents to see if management of the feature has been addressed in them. This document should talk about how the feature will be managed, even if it means referring to relevant sections of the other documents. If there is a need to define a YANG model to configure the feature, it should be identified, even if it is not defined in this document. From an operational perspective, it would be helpful to know how this would be deployed in the field. Are there any issues beyond certificate configuration that operators should be aware of? Some of the services are replacements for existing services, e.g. DNS with secure DNS. How would the operators role out the service in the field with existing service(s)? Section 3: The document talks about establishing a client to server Domain Name Association (DNA) in this section. This is a simpler case of the server to server DNA. However, it is not clear what happens if the certificate verification fails. Is the behavior the same as when a self-signed certificate is presented? Is there a fallback process or does the session just terminate? In addition, the following nits should be addressed in the document. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-12 ** Downref: Normative reference to an Informational RFC: RFC 4949 -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0220' == Outdated reference: draft-ietf-uta-xmpp has been published as RFC 7590 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (—). Thanks.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -10)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -10)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -10)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -10)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-08-05 for -10)
Unknown
- 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 "usertwo@a.example"? - 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.
Terry Manderson Former IESG member
No Objection
No Objection
(for -10)
Unknown