Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-sip-token-authnz-08

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 1 Mar 2020 10:02:47 -0500

Hi Jean,

Thanks for the detailed review, comments, and suggestions.
Please, see my replies inline below.

Regards,
 Rifaat

On Sun, Feb 23, 2020 at 4:29 PM A. Jean Mahoney <[email-masked]> wrote:

> Hi all,
>
> Below is my review of -08.
>
> Thanks!
>
> Jean
>
>
> Abstract -  To better define what the document covers, perhaps:
>
>     This document defines the "Bearer" authentication scheme for
>     the Session Initiation Protocol (SIP), and a mechanism by
>     which user authentication and SIP registration authorization
>     is delegated to a third party, using the OAuth 2.0 framework
>     and OpenID Connect Core 1.0.  This document updates RFC 3261
>     to provide guidance on how a SIP User Agent Client (UAC)
>     responds to a SIP 401/407 response that contains multiple
>     WWW-Authenticate/Proxy-Authenticate header fields.
>
> Ok

>
> Copyright - Does the document need a disclaimer for pre-RFC5378 work?
>
> Is there a specific text that I need to include that is missing from the
current draft?

>
> Section 1. Introduction
>
> The introduction should provide some text about the single-signon use
> case.
>
> Agree

> I would pull the Example Flows section forward to be part of the
> Introduction.
>
> Agree

>
> Section 1.2  SIP User Agent Types
>
> I think that this section should include a brief, non-normative
> discussion of how a UAC can act on an HTTPS URL - RFC8252 for Native
> Apps (user interacts with the authorization server with a browser),
> RFC8628 for browserless devices, and that there may be other ways in the
> future.
>
> I am not sure this is needed her, as this is described in later sections

>
> Section 2.1  UAC Behavior
>
> Should provide more guidance on token expiration.

Agree

> Section 2.1.1  Obtaining Tokens
>
> Add references for the token types.
>
> Ok

>
> Section 2.2. UAS and Registrar Behavior
>
> Should provide more guidance on token expiration.
>
> Ok

>
>
> Section 3. Access Token Claims
>
> Add info about reference token (or maybe that should go in the Intro)
>
> Ok

>
>
> Section 8.  Acknowledgments
>
> Yehoshua Gev should also get a nod in this section.
>
> Agree.

>
>
> Nits:
>
> See the pull request for specifics.
>
> https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/5/commits/a653c1a5f1184f3eeb5ccabd101f0d6a0053a6b1
>
> Thanks for these.

 Regards,
 Rifaat

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Fri, 6 Mar 2020 15:04:51 -0600

Hi Rifaat,

Thanks for the reply. An answer to your question below:

On 3/1/20 9:02 AM, Rifaat Shekh-Yusef wrote:
> On Sun, Feb 23, 2020 at 4:29 PM A. Jean Mahoney <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 

It's not necessary to include the pre-RFC5378 text in the copyright 
unless you are incorporating text from work that was created before RFC 
5378. You can change the following in the <rfc> element in the XML to 
remove it:

ipr="pre5378Trust200902"/ipr="trust200902"

Jean