Re: [xmpp] OPS-DIR review of draft-ietf-xmpp-dna-10

[Peter Saint-Andre - &yet <[e-mail]>]

Looping in the XMPP WG for completeness...

On 8/5/15 7:40 PM, Peter Saint-Andre wrote:
> Hi Mahesh, thanks for the review. Brief comments inline.
>
> On Aug 5, 2015, at 6:45 PM, Mahesh Jethanandani <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>> [Resending with the correct email address]
>>
>> 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
>> <https://tools.ietf.org/html/draft-ietf-xmpp-posh-04> and
>> draft-ietf-dane-srv-12
>> <https://tools.ietf.org/html/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.
>
> We introduced the concept of a prooftype (not prototype) in order to
> explain the security approach here. No operator will directly deploy
> prooftypes in the abstract.
>
>> 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.
>
> That is a good point. We will need to think about this a bit more from
> the ops and management perspective, and formulate some text. But I think
> most or all of the text belongs in the dane-srv and POSH specs.
>
>> 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.
>
> I have not seen YANG deployed with XMPP systems.
>
>> 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)?
>
> Some of these issues are addressed by the relevant specifications (e.g.,
> about DNSSEC). In general for DNA these are matters for the specific
> prooftypes.
>
>> 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?
>
> That is covered by RFC 6120. We might to point to the relevant sections
> of that spec.
>
> Peter
>
>> In addition, the following nits should be addressed in the document.
>>
>>    Checking nits according tohttp://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
>> [e-mail] <mailto:[e-mail]>
>>
>>
>>
>>
>>