Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt
Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 30 December 2014 22:09 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDF01A8777; Tue, 30 Dec 2014 14:09:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 VL4lPbW4ZFRA; Tue, 30 Dec 2014 14:09:06 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB051A8776; Tue, 30 Dec 2014 14:09:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 02F09BEC4; Tue, 30 Dec 2014 22:09:04 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCd-9Okupa7i; Tue, 30 Dec 2014 22:09:02 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.41.60.190]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 89E5ABEC3; Tue, 30 Dec 2014 22:09:02 +0000 (GMT)
Message-ID: <54A3227E.7000209@cs.tcd.ie>
Date: Tue, 30 Dec 2014 22:09:02 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <CAF4+nEH3qmXQRg1B2F+uD4iwO8KQijzUTsJKb=u9TR5tEaAjSQ@mail.gmail.com> <54A2E649.9060705@cs.tcd.ie> <CALaySJ+3z=XBpt3-axtphqoeqRhLTe+9bY01KiEUA0+yVepR7g@mail.gmail.com>
In-Reply-To: <CALaySJ+3z=XBpt3-axtphqoeqRhLTe+9bY01KiEUA0+yVepR7g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Ws4DSFixpYOSN9Ou6W-oB1EyTio
Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 22:09:09 -0000
Hiya, On 30/12/14 19:48, Barry Leiba wrote: > On just a couple of points... > >>> Page 6/7/13, Figure 1/2/3: I'm not sure that something that is >>> entirely textural is best called a "Figure". But in any case, since >>> the text is, or at least has, lines that are flush left, it looks like >>> part of the preceding text and there isn't a clear demarcation of the >>> start. I recommend that the body of the Figures be indented 3 or 4 >>> spaces. >> >> I'd prefer let the RFC editor fix those if needed. > > I think that if we think a change in the formatting would make things > clearer, we should do that ourselves, and not defer it to the RFC > Editor. *We* should be happy with the document before we send it > over. I figure this is such a minor change that we are actually happy, even if we might also like to nitpick ourselves unhappy from time to time;-) > >>> Page 19, IANA Considerations: It seems from >>> draft-leiba-coton-iana-5226bis that IANA would prefer IANA >>> Considerations to be written in the past tense as if the actions had >>> already been accomplished, presumably to minimize IANA re-writing >>> effort. Thus, I suggest that consideration be given to changing the >>> initial part, between the Section 9 heading and the Section 9.1 >>> heading, to the following and making similar changes in the remainder >>> of the IANA Considerations Section: > > I'm with Stephen here: please leave this alone. At this point, the > document is making a request, and that's a fine way to put it. > >>> Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted >>> UTF8 string". There should probably be a Reference column. "a small >>> positive integer" is undefined. >> >> Oh come on. Small positive integer utterly clear as is unformatted >> string in this context. UTF8 isn't needed here as this is not meant >> to be seen by a user. > > With this and all other strings, the question isn't whether users are > going to see it or not, but how implementors are supposed to know what > a "string" is and how to create it. In these cases coders look @ the IANA registry to find the string in question. If IANA, and some expert, manage to muck up that badly then I suspect we have worse problems. I only agreed with the UTF8 addition in the did case as I could see that being presented to a user as a "you last logged in from a &^%SS device on Tuesday" so there's a chance that a non ASCII string might be worthwhile there. For a kid type (not kid, but a kid type) that's just not worth even these electrons, even if it appears to bear all the markings of a good i18n bunfight:-) Neither string is ever sent in the HOBA protocol itself. S. > If it's an arbitrary sequence of > bytes, then it should say that, rather than "string". If it's really > a string and is meant to represent characters in some encoding system, > then it needs to say either what encoding system that is (UTF-8, > US-ASCII, or whatever) or that it doesn't matter and that any encoding > can be used. The latter only works if the string is never consumed by > an entity other than the one that created it. > > Barry >
- [secdir] SECDIR review of draft-ietf-httpauth-hob… Donald Eastlake
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Stephen Farrell
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Kathleen Moriarty
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Barry Leiba
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Kathleen Moriarty
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Stephen Farrell
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Stephen Farrell
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Stephen Farrell
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Kathleen Moriarty