Re: [auth48] AUTH48: RFC-to-be 9410 <draft-ietf-stir-identity-header-errors-handling-08> for your review

[Chris Wendt <[e-mail]>]

Responses inline.

> On Jul 10, 2023, at 11:51 PM, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) 
> the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] Note that the title of the document has been updated as
> follows. Please review and let us know if updates are required. 
> 
> Original:
> Identity Header Errors Handling for STIR
> 
> Current: 
> Handling of Identity Header Errors for Secure Telephone Identity
> Revisited (STIR) -->
> 

ok

> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on https://www.rfc-editor.org/search. -->  
> 

multiple errors, passport, reason header field

> 
> 3) <!-- [rfced] We suggest rephrasing the following text in the abstract 
> into two seperate sentences for better comprehension. Does the following
> suggestion retain your intended meaning?
> 
> Original: 
> This document extends STIR and the Authenticated Identity Management
> in the Session Initiation Protocol (SIP) error handling procedures to 
> include the mapping of verification failure reasons to STIR defined 4xx 
> codes so the failure reason of an Identity header field can be conveyed to 
> the upstream authentication service when local policy dictates that the 
> call should continue in the presence of a verification failure.
> 
> Perhaps: 
> This document extends Secure Telephone Identity Revisited (STIR) and
> the Authenticated Identity Management in the Session Initiation Protocol 
> (SIP) error-handling procedures to include the mapping of verification 
> failure reasons to STIR-defined 4xx codes. The failure reason of an 
> Identity header field can be conveyed to the upstream authentication 
> service when local policy dictates that the call should continue in the 
> presence of a verification failure.-->
> 

I would include this slight variation to clarify the meaning:

> This document extends the Secure Telephone Identity Revisited (STIR) and
> the Authenticated Identity Management in the Session Initiation Protocol 
> (SIP) current error-handling procedures for the mapping of verification 
> failure reasons to STIR-defined 4xx codes. It extends the ability to use the reason header field as an option of conveying an error associated with an 
> Identity header field to the upstream authentication 
> service when local policy dictates that the call should continue in the 
> presence of a verification failure.

> 
> 4) <!-- [rfced] We suggest rephrasing the following sentence for
> readability. Does the following suggestion retain your intended meaning?
> 
> Original: 
> [RFC8224] describes the use of the STIR framework in the SIP
> protocol [RFC3261] and defines both the authentication service that creates 
> a PASSporT, defined in [RFC8225], and delivers it in an Identity header 
> field and the verification service that correspondingly verifies the 
> PASSporT and embedded originating identity.
> 
> Perhaps: 
> [RFC8224] describes the use of the STIR framework in the SIP
> protocol [RFC3261].  It defines both a) the authentication service that 
> creates a PASSporT [RFC8225] and delivers it in an Identity header field, 
> and b) the verification service that correspondingly verifies the PASSporT 
> and embedded originating identity.-->
> 

ok

> 
> 5) <!-- [rfced] We suggest rephrasing the following sentence for clarity. Does the following suggestion retain your intended meaning?
> 
> Original: 
> Additionally, it addresses the issue of the current 4xx error
> response and that when there is a verification error, the call is terminated.
> 
> Perhaps: 
> Additionally, it addresses the issue of the current 4xx error
> response, i.e., the call is terminated when a verification error is
> present. -->

ok

> 
> 
> 6) <!-- [rfced] We have rephrased the following sentence for clarity. 
> Please let us know any objections.
> 
> Original: 
> In many cases of, for example, inadvertent or operational errors
> that do not represent any identity falsification type of attempt, the 
> policy of continuing the call even though the identity is not verified, may 
> be the preferred policy.
> 
> Current: 
> For example, in many cases of inadvertent or operational errors that
> do not represent any type of identity falsification attempt, the preferred
> policy may be to continue the call despite the unverified
> identity. -->

ok

> 
> 
> 7) <!-- [rfced] For readability, please consider whether the following correctly conveys the intended meaning. 
> 
> Original:
>   For the handling of multiple Identity header fields and the potential
>   situation that some of the Identity header fields in a call may pass
>   verification but others may have errors, this document defines the
>   method of adding an identifier so that the authentication service can
>   uniquely identify which Identity header field is being referred to in
>   the case of an error.
> 
> Perhaps:
>   To handle multiple Identity header fields where 
>   some in a call may be verified while others may not (i.e., they have 
>   errors), this document defines a method by which an identifier is added 
>   to the header so that the authentication service can uniquely identify 
>   which Identity header field is being referred to in
>   the case of an error.
> -->
> 

ok

> 
> 8) <!-- [rfced] We have updated artwork elements to sourcecode throughout 
> the document. Please review the "type" attribute of each sourcecode element
> in the XML file to ensure correctness. If the current list of preferred
> values for "type" 
> (https://www.rfc-editor.org/materials/sourcecode-types.txt) does not
> contain an applicable type, then feel free to let us know. Also, it is
> acceptable to leave the "type" attribute not set. -->
> 

I think that is ok to have the artwork as sourcecode. But i’ll also defer to editor or others cc’d if there is better feedback.

> 
> 9) <!-- [rfced] Please review the following text. Terms such as "cause code" and "call dialog" do not appear in RFC 8824.  Please let us know how/if we should update the text and/or citation.
> 
> Original: 
>   The
>   association of a "ppi" parameter with a Reason header field using
>   "STIR" protocol MUST only identify a single cause code in the context
>   of a call dialog defined in [RFC8224] or in future documents defining
>   STIR related errors.
> -->
> 

Good question, the cause codes (i.e. 4xx) are defined in 8224, but the Reason header and cause code are defined in 3326.  Call dialog as a term is defined in 3261.

So perhaps the following:

The association of a “ppi” parameter with a Reason header field [RFC3326] using the protocol value of “STIR” defined in this document MUST only identify a single cause code [RFC3326] in the context of a call dialog [RFC3261] corresponding to only the STIR related error codes defined in [RFC8224] or in future documents defining new STIR related error codes.

> 
> 10) <!-- [rfced] FYI - We have added expansions for the following 
> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please 
> review each expansion in the document carefully to ensure correctness.
> 
> Secure Telephone Identity Revisited (STIR)
> User Agent Client (UAC)
> User Agent Server (UAS) -->

Yes these are correct

> 
> 
> 11) <!-- [rfced] Please review the "Inclusive Language" portion of the 
> online Style Guide
> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
> us know if any changes are needed.  Note that our script did not flag any
> words in particular, but this should still be reviewed as a best
> practice. -->
> 

I did not find any opportunities to change anything.

> 
> Thank you.
> 
> RFC Editor
> 
> 
> On Jul 10, 2023, at 8:45 PM, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2023/07/10
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48
> 
> Your document has now entered AUTH48.  Once it has been reviewed and 
> approved by you and all coauthors, it will be published as an RFC.  
> If an author is no longer available, there are several remedies 
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> 
> You and you coauthors are responsible for engaging other parties 
> (e.g., Contributors or Working Group) as necessary before providing 
> your approval.
> 
> Planning your review 
> ---------------------
> 
> Please review the following aspects of your document:
> 
> *  RFC Editor questions
> 
>   Please review and resolve any questions raised by the RFC Editor 
>   that have been included in the XML file as comments marked as 
>   follows:
> 
>   <!-- [rfced] ... -->
> 
>   These questions will also be sent in a subsequent email.
> 
> *  Changes submitted by coauthors 
> 
>   Please ensure that you review any changes submitted by your 
>   coauthors.  We assume that if you do not speak up that you 
>   agree to changes submitted by your coauthors.
> 
> *  Content 
> 
>   Please review the full content of the document, as this cannot 
>   change once the RFC is published.  Please pay particular attention to:
>   - IANA considerations updates (if applicable)
>   - contact information
>   - references
> 
> *  Copyright notices and legends
> 
>   Please review the copyright notice and legends as defined in
>   RFC 5378 and the Trust Legal Provisions 
>   (TLP – https://trustee.ietf.org/license-info/).
> 
> *  Semantic markup
> 
>   Please review the markup in the XML file to ensure that elements of  
>   content are correctly tagged.  For example, ensure that <sourcecode> 
>   and <artwork> are set correctly.  See details at 
>   <https://authors.ietf.org/rfcxml-vocabulary>.
> 
> *  Formatted output
> 
>   Please review the PDF, HTML, and TXT files to ensure that the 
>   formatted output, as generated from the markup in the XML file, is 
>   reasonable.  Please note that the TXT will have formatting 
>   limitations compared to the PDF and HTML.
> 
> 
> Submitting changes
> ------------------
> 
> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
> the parties CCed on this message need to see your changes. The parties 
> include:
> 
>   *  your coauthors
> 
>   *  [e-mail] (the RPC team)
> 
>   *  other document participants, depending on the stream (e.g., 
>      IETF Stream participants are your working group chairs, the 
>      responsible ADs, and the document shepherd).
> 
>   *  [e-mail], which is a new archival mailing list 
>      to preserve AUTH48 conversations; it is not an active discussion 
>      list:
> 
>     *  More info:
>        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> 
>     *  The archive itself:
>        https://mailarchive.ietf.org/arch/browse/auth48archive/
> 
>     *  Note: If only absolutely necessary, you may temporarily opt out 
>        of the archiving of messages (e.g., to discuss a sensitive matter).
>        If needed, please add a note at the top of the message that you 
>        have dropped the address. When the discussion is concluded, 
>        [e-mail] will be re-added to the CC list and 
>        its addition will be noted at the top of the message. 
> 
> You may submit your changes in one of two ways:
> 
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
> 
> Section # (or indicate Global)
> 
> OLD:
> old text
> 
> NEW:
> new text
> 
> You do not need to reply with both an updated XML file and an explicit 
> list of changes, as either form is sufficient.
> 
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text, 
> and technical changes.  Information about stream managers can be found in 
> the FAQ.  Editorial changes do not require approval from a stream manager.
> 
> 
> Approving for publication
> --------------------------
> 
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
> 
> 
> Files 
> -----
> 
> The files are available here:
>   https://www.rfc-editor.org/authors/rfc9410.xml
>   https://www.rfc-editor.org/authors/rfc9410.html
>   https://www.rfc-editor.org/authors/rfc9410.pdf
>   https://www.rfc-editor.org/authors/rfc9410.txt
> 
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9410-diff.html
>   https://www.rfc-editor.org/authors/rfc9410-rfcdiff.html (side by side)
> 
> Diff of the XML: 
>   https://www.rfc-editor.org/authors/rfc9410-xmldiff1.html
> 
> The following files are provided to facilitate creation of your own 
> diff files of the XML.  
> 
> Initial XMLv3 created using XMLv2 as input:
>   https://www.rfc-editor.org/authors/rfc9410.original.v2v3.xml 
> 
> XMLv3 file that is a best effort to capture v3-related format updates 
> only: 
>   https://www.rfc-editor.org/authors/rfc9410.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9410
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9410 (draft-ietf-stir-identity-header-errors-handling-08)
> 
> Title            : Identity Header Errors Handling for STIR
> Author(s)        : C. Wendt
> WG Chair(s)      : Ben Campbell, Robert Sparks, Russ Housley
> Area Director(s) : Murray Kucherawy, Francesca Palombini
> 
>