Re: [stir] WGLC: draft-ietf-stir-rfc4916-update-02

["Peterson, Jon" <[e-mail]>]

Thanks for the notes Russ. Responses below.


I do not think this document is ready for the IESG yet.


MAJOR:

General: In many places, the document uses: "rsp" PASSporT.  This is not really accurate.  It is an "rsp" claim in a PASSporT.

General: Likewise for "div" PASSporT.

These are not referring to the claim, but to the PASSporT type (ppt). I think we do generally say things like "a 'div' PASSporT" to refer to the type. E.g. RFC8946: "Throughout this document, PASSporTs that contain a "div" element will be referred to as "div" PASSporTs." Only div PASSporTs have div elements, like with rsp.


Section 4 says:

   [TBD - Identity in 3xx, 4xx, 6xx responses?]

This needs to be filled in or removed.

Filled in a bit there.

Section 11: This section needs to be completed.

Since this document has drifted a bit from being an update to RFC4916 into an alternative to it, I think having a "changelog" sort of section is no longer necessary.

This does of course beg the question of the status of the document (obsoletes RFC4916?) but we can discuss that…


Section 12: This section needs to be completed.

Done.


MINOR:

Section 1 says:

   The property of providing identity in the backwards direction of a
   call is here called "connected identity."

I think it would be more clear to avoid the direction, and say:

   The property of providing identity of the called party to the calling party
   is called "connected identity."

The next few sentences properly introduce direction, which is needed in the rest of the document.

OK, done.


Can Section 5 be structured to avoid having a single subsection?

Hmm... I made it the end of Section 6.


Section 7 says:

   Users will not always place
   calls where the connected identity is crucial, but when they do, they
   should have a way to tell their devices that the call should not be
   completed if it arrives at an unexpected or insecure party.

Can we replace "insecure" with "unidentified" or "unauthenticated"?

"Unauthenticated" works for me.


Can Section 8 be structured to avoid having a single subsection?

OK, I just folded 8.1 into 8.

Nits below are all fixed. Thanks again!

Jon Peterson
TransUnion, Inc.


NITS:

Section 1: s/initiated by a SIP/initiated by SIP/

Section 1: s/request, for various backwards-compatibility reasons/request/

Section 1: s/would not be signable/could not be properly signed/

Section 1: s/any work towards multiparty/multiparty/

Section 3: s/be unceremoniously dumped/be dumped/

Section 3: s/a local flat file/a local configuration file/

Section 4: s/In sunny-day uses cases/In straightforward call setup/

Section 5: s/Many of the use cases that motivate connected identity are not sunny-day cases, but instead involve retargeting/Use cases involve authorized retargeting motivate connected identity/


From: Ben Campbell <[e-mail]>
Subject: WGLC: draft-ietf-stir-rfc4916-update-02
Date: April 13, 2023 at 2:15:15 PM CDT
To: IETF STIR Mail List <[e-mail]>
Cc: STIR Chairs <[e-mail]>, [e-mail]

[Oops, I messed up the authors’ alias. Apologies for the repeat.]

Hi,

This is a Working Group Last Call for draft-ietf-stir-rfc4916-update-02 [1]. Please send feedback to the list and the authors by 28 April, 2023.

If you have read the document and think it is ready to go, please say so.

Thanks!

Ben.



[1] https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4916-update/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4916-update/__;!!N14HnBHF!_ZoIbOLPPkknnQHEsXkoMQCkyGdFVr_TbnsTIMoBepSfiJywl31Tyk-FXdve17Z2d4xVLD0Ef6pW7Kn6CXA7t7g$>


Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: stir <[e-mail]> on behalf of Russ Housley <[e-mail]>
Sent: Thursday, April 20, 2023 4:10:53 PM
To: IETF STIR Mail List <[e-mail]>
Subject: Re: [stir] WGLC: draft-ietf-stir-rfc4916-update-02

I do not think this document is ready for the IESG yet.


MAJOR:

General: In many places, the document uses: "rsp" PASSporT.  This is not really accurate.  It is an "rsp" claim in a PASSporT.

General: Likewise for "div" PASSporT.

Section 4 says:

   [TBD - Identity in 3xx, 4xx, 6xx responses?]

This needs to be filled in or removed.

Section 11: This section needs to be completed.

Section 12: This section needs to be completed.


MINOR:

Section 1 says:

   The property of providing identity in the backwards direction of a
   call is here called "connected identity."

I think it would be more clear to avoid the direction, and say:

   The property of providing identity of the called party to the calling party
   is called "connected identity."

The next few sentences properly introduce direction, which is needed in the rest of the document.

Can Section 5 be structured to avoid having a single subsection?

Section 7 says:

   Users will not always place
   calls where the connected identity is crucial, but when they do, they
   should have a way to tell their devices that the call should not be
   completed if it arrives at an unexpected or insecure party.

Can we replace "insecure" with "unidentified" or "unauthenticated"?

Can Section 8 be structured to avoid having a single subsection?


NITS:

Section 1: s/initiated by a SIP/initiated by SIP/

Section 1: s/request, for various backwards-compatibility reasons/request/

Section 1: s/would not be signable/could not be properly signed/

Section 1: s/any work towards multiparty/multiparty/

Section 3: s/be unceremoniously dumped/be dumped/

Section 3: s/a local flat file/a local configuration file/

Section 4: s/In sunny-day uses cases/In straightforward call setup/

Section 5: s/Many of the use cases that motivate connected identity are not sunny-day cases, but instead involve retargeting/Use cases involve authorized retargeting motivate connected identity/


From: Ben Campbell <[e-mail]<mailto:[e-mail]>>
Subject: WGLC: draft-ietf-stir-rfc4916-update-02
Date: April 13, 2023 at 2:15:15 PM CDT
To: IETF STIR Mail List <[e-mail]<mailto:[e-mail]>>
Cc: STIR Chairs <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>

[Oops, I messed up the authors’ alias. Apologies for the repeat.]

Hi,

This is a Working Group Last Call for draft-ietf-stir-rfc4916-update-02 [1]. Please send feedback to the list and the authors by 28 April, 2023.

If you have read the document and think it is ready to go, please say so.

Thanks!

Ben.



[1] https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4916-update/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4916-update/__;!!N14HnBHF!_ZoIbOLPPkknnQHEsXkoMQCkyGdFVr_TbnsTIMoBepSfiJywl31Tyk-FXdve17Z2d4xVLD0Ef6pW7Kn6CXA7t7g$>