Re: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT)

Bill Mills <wmills_92105@yahoo.com> Wed, 27 May 2015 22:52 UTC

Return-Path: <wmills_92105@yahoo.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308D51B2A91 for <kitten@ietfa.amsl.com>; Wed, 27 May 2015 15:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.175
X-Spam-Level:
X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5HSTRc1sBlmf for <kitten@ietfa.amsl.com>; Wed, 27 May 2015 15:52:07 -0700 (PDT)
Received: from nm44-vm2.bullet.mail.gq1.yahoo.com (nm44-vm2.bullet.mail.gq1.yahoo.com [67.195.87.25]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514411B2A97 for <kitten@ietf.org>; Wed, 27 May 2015 15:52:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1432767126; bh=U1NBrOapMk+3aA/E65oepdS5jz0QS0FVeYzb84Z/lfk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=cZDj3VSDRr03NtapmhemHXHyCFrCZLofki8lvGfCqTcvlitFhlwfXrclp4CWnZo73IiL/U36JzDlQV3Z3DR6CORH1fZz5B/BichcM7Dw0XhBWvLKee4HVFJBvjJaq4IAWDCYPDC7G42obz9z7R8NcRiSPuEhuCxyOIN9a4JJpqzlLEzgrW2ubxoHn12Ll9Wz2iMiD0YNre2NJOLRTnlKK1YvAbdXn0WDViAx1+b+G4wU3kvZEHpdWLR+GSILMqFU/QhrKO7t8ABKo4AqKcBsaH9RuHJRySxQfjLAcPT4MYqI6JzeKvUWHD2MjCD1AaByDuLythzGfTkvyeHIh50g6Q==
Received: from [127.0.0.1] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 27 May 2015 22:52:06 -0000
Received: from [98.137.12.62] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 27 May 2015 22:49:05 -0000
Received: from [98.139.170.179] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 27 May 2015 22:49:05 -0000
Received: from [98.139.212.219] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2015 22:49:05 -0000
Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 27 May 2015 22:49:05 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 67432.5896.bm@omp1028.mail.bf1.yahoo.com
X-YMail-OSG: nIQv4OkVRDuCKSnbc1dMqpCNA81yDMFbDujdvQ0rZRMCcEVqYA--
Received: by 66.196.81.105; Wed, 27 May 2015 22:49:04 +0000
Date: Wed, 27 May 2015 22:49:03 +0000
From: Bill Mills <wmills_92105@yahoo.com>
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
Message-ID: <1717038366.5795.1432766943755.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <20150527211918.9536.15611.idtracker@ietfa.amsl.com>
References: <20150527211918.9536.15611.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_5794_1598924530.1432766943740"
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/asCnIC_xDqq-3E3J8MHPudJ7544>
Cc: "kitten@ietf.org" <kitten@ietf.org>, "kitten-chairs@ietf.org" <kitten-chairs@ietf.org>, "draft-ietf-kitten-sasl-oauth.ad@ietf.org" <draft-ietf-kitten-sasl-oauth.ad@ietf.org>, "draft-ietf-kitten-sasl-oauth@ietf.org" <draft-ietf-kitten-sasl-oauth@ietf.org>, "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" <draft-ietf-kitten-sasl-oauth.shepherd@ietf.org>
Subject: Re: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <wmills_92105@yahoo.com>
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2015 22:52:09 -0000

Thanks for the good feedback.  My replies inline below, and this will be checked in to my working copy on GitHub at https://github.com/sweetums/idrafts
2+ possible follow-ons/questions.
Regards,
-bill
> ----------------------------------------------------------------------> COMMENT:> ----------------------------------------------------------------------> > -- section 1, description of step A:> > if the preferred way is different than the diagram, why not show it the preferred way in the diagram in the first place?> 
Struck "preferrably".  This was based in the desire to prefer web based flows over the password grant type, but in the end both are valid and we're putting no normative language around it.

> -- 1, 2nd to last paragraph> > The "SHOULD" means the reference to I-D.ietf-oauth-dyn-reg needs to be be normative.
done
> > -- 3: "Such a new SASL OAuth mechanism can be added by simply>    registering the new name(s)"> > Register them where?
s/by simply registering the new name(s)/by registering the new name(s) with IANA/
change made in my working copy.
> > -- 3.2, 2nd paragraph : "... known to the application."> > Known to the "resource server"?
this is server config and in protocol data that the app could have, so I'd rather leave this as "application" but if there's strong desire for "resource server" I'll make the change.
> > Editorial Stuff:> > -- 3.1, "Port":> > I assume that means the destination port to which the client connected?> (similar to Host?)> > -- 3.1.1 "Post": default value is "". > > Does "" represent an empty string?
Yes, does this need to be spelled out?
> > -- 3.2, first sentence"> > s/" ... according the specification..." / "... according to the specification..."
done
> > - 5: "Lifetime of the appliation sessions"> > s/appliation/application
done
> > "It is possible that SASL will be authenticating..."> > s/"... be authenticating..." / "... be used to authenticate..."> 
Done.
> >  



     On Wednesday, May 27, 2015 2:59 PM, Ben Campbell <ben@nostrum.com> wrote:
   

 Ben Campbell has entered the following ballot position for
draft-ietf-kitten-sasl-oauth-22: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- section 1, description of step A:

if the preferred way is different than the diagram, why not show it the
preferred way in the diagram in the first place?

-- 1, 2nd to last paragraph

The "SHOULD" means the reference to I-D.ietf-oauth-dyn-reg needs to be be
normative.

-- 3: "Such a new SASL OAuth mechanism can be added by simply
  registering the new name(s)"

Register them where?

-- 3.2, 2nd paragraph : "... known to the application."

Known to the "resource server"?

Editorial Stuff:

-- 3.1, "Port":

I assume that means the destination port to which the client connected?
(similar to Host?)

-- 3.1.1 "Post": default value is "". 

Does "" represent an empty string?

-- 3.2, first sentence"

s/" ... according the specification..." / "... according to the
specification..."

- 5: "Lifetime of the appliation sessions"

s/appliation/application

"It is possible that SASL will be authenticating..."

s/"... be authenticating..." / "... be used to authenticate..."


_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten