Subject: [sipcore] Publication has been requested for draft-ietf-sipcore-sip-token-authnz-12

From: Jean Mahoney via Datatracker <[email-masked]>
Date: Sat, 28 Mar 2020 14:19:23 -0700

Jean Mahoney has requested publication of draft-ietf-sipcore-sip-token-authnz-12 as Proposed Standard on behalf of the SIPCORE working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 28 Mar 2020 17:55:34 -0700

On Sat, Mar 28, 2020 at 2:19 PM Jean Mahoney via Datatracker <
[email-masked]> wrote:

> Jean Mahoney has requested publication of
> draft-ietf-sipcore-sip-token-authnz-12 as Proposed Standard on behalf of
> the SIPCORE working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/
>

First round of AD Evaluation comments.  I'm learning SIP as I go here, so
please be gentle in your responses to what might be neophyte questions.  :-)

Section 1.3:
Nits:
* s/usualy/usually/
* "... consumed only the AS ..." -- s/only/only by/

Section 2.1.1:
Nits:
* "In which case, ..." -- s/which/that/
* "... authorize UAC's access ..." -- insert "the" before "UAC's"

Section 2.2:
* The SHOULD in the first paragraph is curious.  Under what circumstances
might you do anything other than what it says there?

Section 3:
Nit:
* "The methods used and the access provided by the token is based on..." --
s/is/are/
* Why is "REGISTRAR" in all-caps?

Section 4:
* In the ABNF I believe it's more conventional to say in the prose that
this, that, or the-other tokens are imported from [RFCxxxx], without also
saying so in the ABNF itself.  This isn't a blocker, but an ABNF parser
might whine about what's present in this version of the document, and some
reviewer downstream of me might then squawk about it.

-MSK

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 29 Mar 2020 08:43:37 +0000

Hi Murray,

Thank You for the comments! Please see inline.

---

>* s/usualy/usually/

Will fix.

>* "... consumed only the AS ..." -- s/only/only by/ 

Will fix.

---

>* "In which case, ..." -- s/which/that/

Will fix.

>* "... authorize UAC's access ..." -- insert "the" before "UAC's"

Will fix.

---

Section 2.2:

>* The SHOULD in the first paragraph is curious.  Under what circumstances might you do anything other than what it says there?

The SHOULD is based on the generic procedure in RFC 3261, which says that a registrar SHOULD authenticate a user.

---

Section 3:
>
>Nit:
>* "The methods used and the access provided by the token is based on..." -- s/is/are/

Will fix.

>* Why is "REGISTRAR" in all-caps?

That is a mistake. Will fix.

---

Section 4:

> * In the ABNF I believe it's more conventional to say in the prose that this, that, or the-other tokens are imported from [RFCxxxx],
> without also saying so in the ABNF itself.  This isn't a blocker, but an ABNF parser might whine about what's present in this version
> of the document, and some reviewer downstream of me might then squawk about it.

This is the way we did e.g., in RFC 8599 (which is the latest SIPCORE RFC I was co-authoring). I personally don't have a strong opinion, but in general I think it is good to be consistent.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Mar 2020 14:32:49 -0400

Murray,

On 3/28/20 8:55 PM, Murray S. Kucherawy wrote:

> this, that, or the-other tokens are imported from [RFCxxxx], without 
> also saying so in the ABNF itself.  This isn't a blocker, but an ABNF 
> parser might whine about what's present in this version of the document, 
> and some reviewer downstream of me might then squawk about it.

It was changed to the current form from the "conventional" way at my 
request. The reason is to assist in mechanical verification of the ABNF. 
With the "conventional" way, if you run the ABNF through an ABNF 
verifier you get a bunch of errors due to undefined rules. Using this 
form the verifier has definitions of the rules and is happy.

Of course, if you are trying to generate a *parser* then you need to 
supply the *actual* rules, from their respective documents. That will 
take hands-on no matter what.

(I've tried, off and on, to get people interested in ABNF enhancements 
that permit actually parsing the cross document references and 
assembling a complete set of all the needed ABNF rules so that complete 
verification (and potentially parser generation) can be done. But there 
hasn't been much interest in that.)

	Thanks,
	Paul