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

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Tue, 24 March 2015 16:37 UTC

Return-Path: <alexander.mayrhofer@nic.at>
X-Original-To: drinks@ietfa.amsl.com
Delivered-To: drinks@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 45B9A1A8A0E for <drinks@ietfa.amsl.com>; Tue, 24 Mar 2015 09:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.741
X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HTODzpU6H6PX for <drinks@ietfa.amsl.com>; Tue, 24 Mar 2015 09:37:35 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C3A1A914B for <drinks@ietf.org>; Tue, 24 Mar 2015 09:36:54 -0700 (PDT)
Received: from nics-exch2.sbg.nic.at ([]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Tue, 24 Mar 2015 17:36:53 +0100
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Tue, 24 Mar 2015 17:36:51 +0100
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: "barryleiba@computer.org" <barryleiba@computer.org>
Thread-Topic: Your DISCUSS on draft-ietf-drinks-spp-framework
Thread-Index: AdBmSxoMKabb2hlvReK7JRvOurLuUg==
Date: Tue, 24 Mar 2015 16:36:51 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE07546785F7F@NICS-EXCH2.sbg.nic.at>
Accept-Language: en-US, de-DE
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/drinks/KLtx1hE-i_T054NwOSr_6e7gDm0>
Cc: "drinks@ietf.org" <drinks@ietf.org>
Subject: [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 16:37:39 -0000

Hello Barry,

you raised a DISCUSS on draft-ietf-drinks-spp-framework (https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ballot/#barry-leiba). Please find our response below (I've quoted your DISCUSS text below, my comments are prefixed with "->"

-- Section 2 --

   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.

-> How shall we proceed with that one? I'm here until Friday noon, if you happen to have time to discuss this in person? We would appreciate advice on this..

-- Section 4.11 --

   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:

   One choice of transport protocol has been provided in the document
   "SPP Protocol over SOAP" [reference].

-> Will change accordingly in the text, thanks for spotting that.

-- Section 11.2 --

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. 

While we're talking about OrgIdType, I don't think the document makes it clear
what this is, and why new ones would be registered in the first place.  Why
would we ever need an OrgIdType Namespace other than "iana-en"?  Shouldn't the
document say something about that?

-> There was a long-standing discussion about something called "SPID" ("Service Provider ID"), even to the point where a draft was dedicated to this, and heavily discussed: https://tools.ietf.org/html/draft-pfautz-service-provider-identifier-urn-01
-> However, because of various problems (mostly du to issues on layer 8 and beyond - eg. local  regulator competences on assigning these Identifiers), this work was not completed. Also, it was unclear what a "service provider" would be - even individuals could operator a "service" on someone's behalf - would they be entitled such an identifier?
-> Subsequently, we came to the conclusion that re-using Enterprise numbers was the best was to go, and also that the addition of another type of identifer to the SPPP protocol shouldn't be too lightweight.
-> 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 

Such assignments will typically be requested when a new namespace for identification of service providers is defined.

-> We will roll and updated revision of the document before it goes to the RFC editor. Does our response above clarify the issues enough so that you can clear the DISCUSS? 

I've also copied your "comments" into this message, and - again - our response inline:

-- Section 1 --

   1.  A resolution system returns a Look-Up Function (LUF) that
       comprises the target domain to assist in call routing (as
       described in [RFC5486]).

I don't know that it means for a LUF to "comprise the target domain"; perhaps
its a meaning of "comprise" with which I'm unfamiliar.  (Similarly for bullet

Also, where in 5486 is this described?  Is it Section 4.3.3?  It'd be helpful
to include that.

-> Yes, correct, Section 4.3.3 is the correct definition. We will change the reference accordingly.
-> We will also change "comprises" to "identifies".

-- Section 2 --

   In addition, this document specifies the following additional terms:

You can get rid of "In addition," (my preference) or "additional"; you don't
need both.  (I would also use "defines" rather than "specifies".)

-> Right, thanks for spotting that. Will change text accordingly.

   Server:   In the context of SPPF, this is an application that
      receives a provisioning request and responds accordingly.  It is
      sometimes referred to as a Registry.

   Registry:   The Registry operates a master database of Session
      Establishment Data for one or more Registrants.

The latter sentence in the first definition seems to say that "Server" and
"Registry" are synonymous.  How does it, then, make sense to have separate
definitions that are different?  And if they're not synonymous, perhaps it's
unwise to sometimes refer to a Server as a Registry.

-> Thanks for spotting that. A server is typically a component of a Registry, so, i will simply remove the second sentence of "Server"

In the definition of Registrant:

      Within the confines of a Registry, a Registrant is uniquely
      identified by a well-known ID.

What is a "well-known ID"?  What is well known about it?  I ask because the
term isn't otherwise used in this document.

-> We will change that to "is uniquely identified by the 'rant' element".

-- Section 4 subsections --
These subsections are inconsistent in how they refer to the transport protocol
(and see Martin's comments about that).  Some of those differences don't
matter, but I think some do, and I think we'd be better off making the
terminology consistent. 4.1, 4.2, 4.10: "a transport protocol for SPPF" 4.3: "a
protocol suitable for SPPF" [is the word "suitable" significant here?] 4.4:
"the SPPF transport protocol" 4.6: "the transport protocol" [doesn't mention
SPPF] 4.7: "a DRINKS transport protocol" [DRINKS, as opposed to SPPF?] 4.8: "a
suitable transport protocol for SPPF" 4.9: "a transport protocol suitable for

You're in a maze of little twisting passages, all different.
I suggest picking one phrasing and using it in all nine subsections.

-> We will unify that to "a SPPF transport protocol", which is the most sensible term, and change text accordingly. Thanks for spotting, this draft has quite a long history...

-- Section 5.2 --

   "Name" attributes that are used as components of object key types
   MUST be treated case insensitive, more specifically, comparison
   operations MUST use the toCasefold() function, as specified in
   Section 3.13 of [Unicode6.1].

It's a small point, but I think it would be better to lead with the more
specific requirement, which makes the other unnecessary except by way of

   "Name" attributes that are used as components of object key types
   MUST be compared using the toCasefold() function, as specified in
   Section 3.13 of [Unicode6.1].  That function performs case-insensitive

-> Thanks, will change text accordingly.

-- Section 11.2 --
The ABNF allows an OrgIdType Namespace identifier to end with "-"; is that

-> The only intention was that the string should not start with a dash. Since the policy of the Registry is pretty heavyweight, i think we can leave it that way, as any request that contains a string ending with a "-" would be reviewed extensively. If you're concerned about that, we can change the ABNF to disallow the "-" in the end.

Again, it would be great if we could get the DISCUSS cleared today or tomorrow, since we'd rather shut the WG down sooner than later.. I'm happy to discuss all of that in person here, too..

Alex Mayrhofer