Re: [drinks] Your DISCUSS on draft-ietf-drinks-spp-framework

Barry Leiba <barryleiba@computer.org> Tue, 24 March 2015 18:27 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: drinks@ietfa.amsl.com
Delivered-To: drinks@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4299D1A89A3 for <drinks@ietfa.amsl.com>; Tue, 24 Mar 2015 11:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 6a2vjD9c1aIl for <drinks@ietfa.amsl.com>; Tue, 24 Mar 2015 11:27:23 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 B55B81A1B71 for <drinks@ietf.org>; Tue, 24 Mar 2015 11:27:23 -0700 (PDT)
Received: by igcau2 with SMTP id au2so56903822igc.1 for <drinks@ietf.org>; Tue, 24 Mar 2015 11:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eIkOiItnjr4eY0Awu9LHH2NNMMLg8Mn1DPdkCIUK4Xs=; b=Gp12zMtKEYkteu0PAS/3fZ8BE9/w4Ku5d11QZDBARzxw2SnUkeTxQ3uKeBSjpRH60O KLw+IUgwERO7yGmeChMIFp73Kf/OqRX++6D9rIrq/3oSi+EZzbIGi0rGidt6lJVOmM3C uMuQLtHRSpKmtdD410ZAvukwn55mJOY2yu47yjcQi5gZ+I5dflIePejCabdGyfLmKnbr WsZamP8X8BfVLGYlBAwLxHui8zwh3k0DRRDNfwJKF7EpBpYuebhexplNHVq8mLlyB/jQ Fo2Kd0tPR/i+rxJFuqKay6FwWnRxtMFx0FiUJ+DGIFrHwa2yUKTZayc5Nvs3bMAQ6R2z zDVg==
MIME-Version: 1.0
X-Received: by 10.50.66.235 with SMTP id i11mr24483826igt.40.1427221643187; Tue, 24 Mar 2015 11:27:23 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.17.26 with HTTP; Tue, 24 Mar 2015 11:27:22 -0700 (PDT)
In-Reply-To: <19F54F2956911544A32543B8A9BDE07546785F7F@NICS-EXCH2.sbg.nic.at>
References: <19F54F2956911544A32543B8A9BDE07546785F7F@NICS-EXCH2.sbg.nic.at>
Date: Tue, 24 Mar 2015 13:27:22 -0500
X-Google-Sender-Auth: qKZXkfdSpEBqhZ6f3A3ctiY2_h0
Message-ID: <CALaySJJaGjkCgA_qh6zxZgCGCgVUuPpgOeT5d=J25Dv-Gj74OA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/drinks/hm6VB9rJa9BK9ZlUw1LRA1qCv5M>
Cc: "drinks@ietf.org" <drinks@ietf.org>
Subject: Re: [drinks] Your DISCUSS on draft-ietf-drinks-spp-framework
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks/>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2015 18:27:25 -0000

Hi, Alex.  Thanks for the response.

>    This document reuses terms from [RFC3261], [RFC5486], use cases and
>    requirements documented in [RFC6461] and the ENUM Validation
>    Architecture [RFC4725].
>
> These are all listed as informative references.  If you use terminology defined
> elsewhere, those references (3261 and 5486) need to be normative (they're
> required in order to understand the terms used in this doument).
>
> -> RFC 5486 is an Informative document, adding it as normative
> reference would create a downref, so i think we can't change that to
> normative.. I find this a general problem with documents that specify
> Terminology, since these are typically Informational.  Also, since
> SPPP itself is a provisioning protocol, i think that the Terminology
> of the underlying protocol for which information is provisioned is not
> necessarily normative, as long as the definitions of the provisioning
> protocol itself are fine.

Downrefs are allowed these days, and are no longer a big problem.  The
only requirement is that they be identified in the last call message
so that the community is made aware of them.  Of course, that wasn't
done in this case, so if we were to change the reference to 5486 to
normative, we'd have to have a two-week last call on that change.

As to whether it *should* be normative, I understand your response,
and at this point I'm happy to leave this to the judgment of the
working group and your AD.  Thanks for discussing this with me, and I
see no reason that I need to be in the loop now.

>    At the time of this writing, a choice of transport protocol has been
>    provided in SPP Protocol over SOAP document.
>
> This would be a good place for a reference to that draft.  I think the
> reference is important, as you've made it MTI; I think it's a normative one.  I
> don't think "At the time of this writing" is necessary, though if you really
> like it I don't object.  It's also missing a "the" and some quotes, as thus:
>
> NEW
>    One choice of transport protocol has been provided in the document
>    "SPP Protocol over SOAP" [reference].
> END
>
> -> Will change accordingly in the text, thanks for spotting that.

Thanks.  Again, I trust you folks to handle this appropriately.

> Why does the policy need to be RFC Required?  Why not Expert Review?  For that
> matter, why not FCFS?  You can either point me at mailing list archives where
> this was discussed, or explain the necessity in response to this comment.
>
> -> https://www.ietf.org/mail-archive/web/drinks/current/msg01232.html was my
> original message on the IANA registration policy. There was consensus in a
> design team call that this was the right policy.

Thank you; that's enough for me.  I wanted to make sure you folks made
an informed decision, and it's clear that you did.

> -> However, *if* the industry ever agreed on using another form of identifier for
> service providers, we still wanted to leave the option available. I can add
> respective text, such adding
>
> NEW
> Such assignments will typically be requested when a new namespace for
> identification of service providers is defined.
> END

Again, thanks for the explanation, which makes sense.  And again, I'll
leave it to you to add a little explanation, and our discussion is
done.

So I think we've covered all the discussion I wanted, and it's all
left to "I trust the authors and the AD to do the right thing."  I'll
go update my ballot after I send this.  And thanks, also, for
addressing my non-blocking comments.

Barry