Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-02

Thanks Paul for the detailed review, i will definitely bring up these topics in tomorrow’s STIR meeting.  Your latter points i think are a side effect of the progressive nature of how the document evolved through discussions, so will be sure to bring up these points and try to address and see if we can agree on a path forward.

> On Jul 23, 2022, at 2:47 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:
> 
> Here are thoughts I have after reviewing this document:
> 
> * Section 3:
> 
> This document is depending on draft-sparks-sipcore-multiple-reasons for an extension to the Reason header field permitting multiple reasons for the same protocol. That is an individual draft and is currently expired. IMO *this* draft should not complete WGLC until that draft is adopted and completes its own WGLC.
> 
> Also, I think this draft should be more explicit in stating that the new STIR protocol it defines permits multiple uses, and perhaps constraints on how. (E.g., in what ways the multiple uses must differ, or how to resolve ambiguities among them. I *think* the response codes defined in RFC 8224 are mutually exclusive for a single passport, so perhaps constrain to a single cause per ppi.)
> 
> I'm inclined to think that draft-sparks-sipcore-multiple-reasons ought to revise the IANA registry to include a new column that indicates single or multiple use. If so this document would need to include that field in its IANA registration.
> 
> * Section 7:
> 
> Requiring unconditional removal of the Reason header field seems an excessive remedy for the stated problem. It should be sufficient to remove the ppi parameter. And is even that needed if the ppi value is in compact form?
> 
> * Section 8:
> 
> The Protocol Cause for the STIR Protocol Value is specified as "Status code". This is the same as is defined for the SIP protocol. The values used for STIR as a subset of the SIP Protocol Causes. It isn't clear what values are valid for use here. I guess you intend the values specified in section 6.2.2 of RFC 8224. But defining that way isn't future proof. What if a subsequent extension/update to RFC 8224 defines some additional codes?
> 
> I'm not certain what the best answer is here. I think it is worth some discussion.
> 
> 	Thanks,
> 	Paul
> 
> On 7/12/22 9:34 AM, Russ Housley wrote:
>> At the STIR Working Group Virtual Interim on 22 April 2022, we agreed to start WG Last Call for this document once an updates was posted.  It has now been posted.
>> Please send reviews to the list by Noon Eastern time on  in 26 July 2022.  This is a few hours before the STIR session at IETF 114.
>> If you plan to provide a review but need more time, please let us know as soon as possible.
>> See <https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4916-update/>
>> For the STIR WG Chairs,
>>  Russ
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir