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

Peter Saint-Andre - &yet <peter@andyet.net> Thu, 06 August 2015 01:59 UTC

Return-Path: <peter@andyet.net>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C99E1B2A7D for <xmpp@ietfa.amsl.com>; Wed, 5 Aug 2015 18:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8priNGyWJPYF for <xmpp@ietfa.amsl.com>; Wed, 5 Aug 2015 18:59:28 -0700 (PDT)
Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DEE1B2A72 for <xmpp@ietf.org>; Wed, 5 Aug 2015 18:59:28 -0700 (PDT)
Received: by igbpg9 with SMTP id pg9so2432949igb.0 for <xmpp@ietf.org>; Wed, 05 Aug 2015 18:59:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=u4Tg6iEFv+8LiO5RCCzO51fo5YvZEIA8QXqT7t3MKII=; b=Z3x6V4p4R05iuFkxXT0a9jlpZJcLk3Bh8xd9Uc0sW0DaA6+RjOVJ0X2b3ljU+TIYkM VGvMDqeQ1qrKUTPeUPyA6OMkbBGqnB8P5dUJxius8fzF1wZT5yfLmAZ99AIAu2jlYLit h0ZM9a72fo2iGeLKHYL1qTsOXaQlgiME0hbozJLVdCnbkH9lOFavdosMPOdMzDJ6Zn2h 93wBikfW08QHOBe1GpcHKjmH+gQueczvO6nHEu19LYecpAkmzqS+Z0fxdapTaJhYF5DN IKEb3FOUaB1V78nNkHBFT9NkwocI5qPp+iNjfhFIoUgRb5zF/zCIsXnvDCAne8DcpfZj wKUg==
X-Gm-Message-State: ALoCoQmH6C/FIP4tfYh49TU8dQwqxiTpz75ZcMSMlljumEhg6BoMBGdCbG9UMVqjxexouhBkAOr0
X-Received: by 10.50.138.76 with SMTP id qo12mr829727igb.38.1438826367522; Wed, 05 Aug 2015 18:59:27 -0700 (PDT)
Received: from aither.local ([2601:282:4201:ef5b:fd55:db01:48f0:2211]) by smtp.googlemail.com with ESMTPSA id r4sm345309igh.9.2015.08.05.18.59.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 18:59:26 -0700 (PDT)
To: Mahesh Jethanandani <mjethanandani@gmail.com>
References: <65CE3787-11DC-4216-B6F0-93B2EA411195@gmail.com> <53444484-149D-4B4D-B1FE-0F71AABF0E72@gmail.com> <F294573B-FF22-4692-8BE8-BB6AA684085A@andyet.net>
From: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <55C2BF7B.1030809@andyet.net>
Date: Wed, 5 Aug 2015 19:59:23 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <F294573B-FF22-4692-8BE8-BB6AA684085A@andyet.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/VymvhuVNfSFaNv8YEjpslzR_tw4>
Cc: "draft-ietf-xmpp-dna.all@tools.ietf.org" <draft-ietf-xmpp-dna.all@tools.ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>, XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] OPS-DIR review of draft-ietf-xmpp-dna-10
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2015 01:59:30 -0000

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 <mjethanandani@gmail.com
> <mailto:mjethanandani@gmail.com>> 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
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>>
>>
>>
>>
>>