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

From: "Ben Campbell" <[email-masked]>
Date: Wed, 27 May 2015 14:19:18 -0700

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..."

---

From: Bill Mills <[email-masked]>
Date: Wed, 27 May 2015 22:49:03 +0000 (UTC)

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 <[email-masked]> wrote:

Register them where?

Editorial Stuff:

-- 3.1, "Port":

-- 3.2, first sentence"

s/appliation/application

_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 27 May 2015 22:20:28 -0500

Hi, thanks for the response. A few comments below. I removed sections 
that do not seem to need further discussion.

On 27 May 2015, at 17:49, Bill Mills wrote:

[...]

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

Sorry, I guess I was asking for which registry at IANA.

> 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.

Do I understand correctly that we are talking about matching things like 
host and port sent by the client to things the server "knows" through 
other channels?  It seems like "application" could mean application at 
the client as well as the server, or even the combination of both. Maybe 
"application server"? (Or maybe I've missed the intent?)

>>  > 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?

"Need" might be too strong a word, but I think a description like 
"empty" would be more clear than '""'.

>>  > -- 3.2, first sentence"> > s/" ... according the 
>> specification..." / "... according to the specification..."

[...]

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 May 2015 23:56:16 -0400 (EDT)

Hi Ben,

On Wed, 27 May 2015, Ben Campbell wrote:

> Hi, thanks for the response. A few comments below. I removed sections that do
> not seem to need further discussion.
>

The SASL Mechanisms registry; the only one affected by this document.

> > 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.
>
> Do I understand correctly that we are talking about matching things like host
> and port sent by the client to things the server "knows" through other
> channels?  It seems like "application" could mean application at the client as
> well as the server, or even the combination of both. Maybe "application
> server"? (Or maybe I've missed the intent?)

Things like host and port that could be extracted from the OS or http
stack or similar, yes.  I don't particularly care for "resource server"
here, but "application server" seems unobjectionable.

> > > destination port to which the client connected?> (similar to Host?)> > --
> > > 3.1.1 "Post": default value is "". > > Does "" represent an empty string?
> "Need" might be too strong a word, but I think a description like "empty"
> would be more clear than '""'.

I agree that it's probably worth doing "destination port to which the
client connected".  I have no strong feelings regarding the way in which
the empty string is described.

> > > "... according to the specification..."

Indeed.

-Ben

---

From: Bill Mills <[email-masked]>
Date: Thu, 28 May 2015 18:17:37 +0000 (UTC)

Responses inline below tagged with [[WMILLS]]

     On Wednesday, May 27, 2015 8:56 PM, Benjamin Kaduk <[email-masked]> wrote:

 Hi Ben,

The SASL Mechanisms registry; the only one affected by this document.
[[WMILLS]] changed wording to "registering the new name(s) with IANA in the SASL Mechanisms registry"

[[wmills]] WFM "application server" it is.

> would be more clear than '""'.

[[WMILLS]] changed those to "the default value is the empty string ("")."

I agree that it's probably worth doing "destination port to which the
client connected".  I have no strong feelings regarding the way in which
the empty string is described.
[[WMILLS]] WFM now "Contains the destination port that the client connected to, represented as a  decimal positive integer string without leading zeros."

Indeed.

-Ben