[drinks] Your COMMENTS on draft-ietf-drinks-framework (Pete Resnick)

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Mon, 18 May 2015 15:24 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 CC94E1A923B for <drinks@ietfa.amsl.com>; Mon, 18 May 2015 08:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.041
X-Spam-Status: No, score=-3.041 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 U_P0kkTQ7sTA for <drinks@ietfa.amsl.com>; Mon, 18 May 2015 08:24:38 -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 497851A92B3 for <drinks@ietf.org>; Mon, 18 May 2015 08:24:33 -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 ; Mon, 18 May 2015 17:24:26 +0200
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; Mon, 18 May 2015 17:24:21 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: "Pete Resnick (presnick@qti.qualcomm.com)" <presnick@qti.qualcomm.com>
Thread-Topic: Your COMMENTS on draft-ietf-drinks-framework (Pete Resnick)
Thread-Index: AdCRYlfHv21SU0a2R+KX26zjta7vnA==
Date: Mon, 18 May 2015 15:24:20 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE075467F650E@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/MHVwKjfYeRBYKR6J_qp0nQJInzY>
Cc: "drinks@ietf.org" <drinks@ietf.org>
Subject: [drinks] Your COMMENTS on draft-ietf-drinks-framework (Pete Resnick)
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: Mon, 18 May 2015 15:24:45 -0000

Hello Pete,

You submitted the following COMMENTs during the IESG evaluation of draft-ietf-drinks-framework - our responses inline marked with "->":

3.2: s/is not approved for use/MUST NOT be used

-> changed accordingly.

3.3: s/MUST/need to
     s/SHOULD/is expected to

-> changed accordingly, thanks.

4.1/4.2: s/MUST/will (These are both definitional, not requirements; how could
you possibly do otherwise?)

-> changed as well.


   Refer to the Security Considerations section for further guidance.

-> done.

Please use an xref in here in order to refer to the section number. There are
several of these named references throughout the document. Please fix also
5.2.2, 6.1 (two occurrences), 6.3 (two occurrences), 6.4, 6.5 (two
occurrences), 6.6 (two occurrences), 7.1, 7.2, 7.4 (two occurrences), 7.5 (two
occurrences), 7.6, 9.1 (two occurrences)

-> I just noted this while going through the document (again), and I have changed
The references accordingly.

4.11: As written, this needs a (normative) reference to
-spp-protocol-over-soap. You can't have a MUST requirement without a normative

-> Yep, you're right, thanks for spotting this. I've added the respective reference in section 4.

5.1: I think it's really awful practice to include protocol requirements and
syntax definitions inside IANA Considerations. IANA Considerations are for
*IANA*, not for the implementer and not for the folks entering items in the
registry. I strongly suggest moving the syntax requirements and the ABNF from
11.2 into 5.1 and simply reverse the pointer so that 11.2 points to 5.1.

-> I have changed the draft accordingly.

5.2: (I'm still trying to figure out how to non-normatively define something.
:-) ) Can name attributes really be non-ASCII? Aren't these all protocol
elements, not user-interface items? I am icked-out by having to use toCasefold,
and having to have a reference to specific Unicode version.

-> Well.. We had a discussion in the WG Design team long ago, and the gist was 
That those "name" elements are very likely also going to be used to label objects 
e.g. in user interfaces. We then had a hallway discussion in Taipei (yes!) with a guy called
Pete ;) , and he advised us that if those elements are really user-visible, then they should 
be internationalized, otherwise we'd get trouble during the IESG evaluation ;)
 - I agree that the reference to a specific Unicode version is ... icky,
But I would propose "Unicode 6.1 or a newer version of Unicode"?

5.2.1/5.2.2/5.3: I always find this construction bizzarre: "Any conforming
specification MUST define...". They're all MUSTs (save a few MAYs in 5.3), and
those MUSTs seem pretty unnecessary. For 5.3, you should simply make the
opening paragraph:

   The following table contains the list of response types that a
   transport protocol specification needs to provide. An SPPF server
   MUST implement all of the following at minimum.

And then strike "Any conforming specification MUST define a response to
indicate that" from all of the entries. Move the MAY bits out of the table, as
those aren't part of the description of each of those response types. It'll
shorten things up significantly.

-> I have restructured the table.


   o  The value for Attribute Value MUST be the value of the data
      element to which the preceding Attribute Name refers.

   o  Response type "Attribute value invalid" MUST be used whenever an
      element value does not adhere to data validation rules.

What other choice could an implementation make? In other words, if I were to
violate the first MUST, what do you think I'm going to put in to the attribute
value that I need to be instructed that I MUST NOT do?


   hostName: Root-relative host name of the name server.

The additional term "root-relative" confused me. Are you somehow trying to say
that these names MUST NOT have a terminating "." (i.e., they must be relative
domain names)? If that's the point, then you should probably say that.
Otherwise, I would strike "root-relative". An absolute name (with a terminating
".") should be OK in this context, yes?

-> I *think* that term was created by Ted Hardie because he didn't like that "fully qualified" does 
Usually not include the trailing dot. What we wanted to say is that "full hostnames" are required 
(not just labels relative to some zone cut), but we didn't want the terminating dot to be included. 
I'll research what RFCs are typically saying - EPP says "... contains the fully qualified name of the 
host object to be created...", I'll probably go for that.


   Where human-readable languages are used in the
   protocol, those messages SHOULD be tagged according to [RFC5646]...

I think you mean that human-readable *messages* that might be displayed to the
user are to get language tags, but I don't see anywhere in the spec where you
produce human-readable messages. Can you point me to an example. If so, you
should probably say:

   Where human-readable messages that are presented to an end user are
   used in the protocol, those messages SHOULD be tagged with their
   language according to [RFC5646]...

-> The actual "transport" protocol (draft-ietf-drinks-spp-protocol-over-soap) contains 
Messages which could be internationalized. The provisions in the framework document 
were intended for those messages. I will change the text according to your proposal

-> The original idea behind "human-readable languages" was that one wouldn't need to
Tag the languages of eg. the elements in the XML itself (even though they definitely are
In a human-readable language, so I guess that was a bad idea in the first place). 


   If tags are absent, the language of the message defaults to "en"

That seems like a bad plan. If all of the characters are out of the Arabic
script, I'm pretty darn sure that an implicit default language tag of "en" is
unlikely to be helpful to an implementation. I would strike that sentence.

-> it's gone.

11.2: See comment on section 5.1 above.

-> Moved the formal syntax to section 5.1, created a cross  reference.

Many thanks for the thorough review!