Skip to main content

Last Call Review of draft-ietf-xmpp-dna-10
review-ietf-xmpp-dna-10-opsdir-lc-jethanandani-2015-08-06-00

Request Review of draft-ietf-xmpp-dna
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-08-04
Requested 2015-06-30
Authors Peter Saint-Andre , Matthew A. Miller , Philipp Hancke
I-D last updated 2015-08-06
Completed reviews Genart Last Call review of -10 by Dan Romascanu (diff)
Secdir Last Call review of -10 by Derek Atkins (diff)
Opsdir Last Call review of -10 by Mahesh Jethanandani (diff)
Opsdir Last Call review of -10 by Fred Baker (diff)
Assignment Reviewer Mahesh Jethanandani
State Completed
Request Last Call review on draft-ietf-xmpp-dna by Ops Directorate Assigned
Reviewed revision 10 (document currently at 11)
Result Has issues
Completed 2015-08-06
review-ietf-xmpp-dna-10-opsdir-lc-jethanandani-2015-08-06-00
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Status:

Ready with issues.

Summary:

This document defines new “prototypes” 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 “prototypes”,
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.

Mahesh Jethanandani

mjethanandani at gmail.com