Re: [stir] [E] RCD vs "div"

["Dwight, Timothy M (Tim)" <[e-mail]>]

Yeah I get it.  Tools not services... IETF philosophy...

My question was motivated by the statement below in this thread, "what we
want to remove is the act of using an identity you haven’t proven you have
the right-to-use".  I wanted to understand if that's even possible.  I
think you have confirmed my understanding, that it is not.  At least, not
in the context of public telephone networks.

I also offered my understanding of what I believe we are trying to
achieve.  Namely, to hold your service provider accountable if it
indicates, on your behalf, an identity you are not authorized to use.

I suppose in another context we might let you assert your identity, sign it
yourself, and carry that end to end.  In that case we could hold YOU
responsible for the asserted identity.  There are some logistical
challenges with that but I think it could be made to work.  Maybe people
are working on that too, but I'm not.

I suppose I'm guilty of making this all about me (or at least, about the
context in which I am implementing S/S) :-)

tim

On Thu, Mar 10, 2022 at 3:48 PM Chris Wendt <[e-mail]>
wrote:

> I do recognize i am speaking a bit abstractly, but that is how we built
> the specs and how they relate.  STIR is the core protocols and PKI
> definition, SHAKEN is the set of specifications based on STIR, but with
> North American or maybe more generally telephone service provider
> deployment model in mind, where the SP represents the user with a telephone
> number vs. a private SIP deployment that might use STIR that may have a
> different deployment model.  So, we very intentionally do not want to build
> the base specs to address any telephone number usage policies or anything
> specific to a deployment.  Hopefully that explains things a bit better.
>
> So for a consumer to “prove” they have right to use a number, in North
> America and probably most place, you and I know that can’t happen in order
> to general STIR certificate base credentials to prove that.  The service
> provider can perhaps do that on a users behalf based on having the proper
> customer relationship, etc.  vetting/KYC whatever you want.  But in STIR
> specs, we don’t address any of this, very much intentionally.
>
> -Chris
>
> On Mar 10, 2022, at 4:37 PM, Chris Wendt <[e-mail]>
> wrote:
>
> STIR doesn’t address that, SHAKEN doesn’t even specifically address that
> quite yet, but we are talking about vetting/TN validation/KYC concepts that
> allow those types of use cases to be addressed in a way that is compatible
> with policies.
>
> -Chris
>
> On Mar 10, 2022, at 4:22 PM, Dwight, Timothy M (Tim) <
> [e-mail]> wrote:
>
> Can't say as I understand that response.
>
> Would you answer my 2 questions differently than I did?
>
> tim
>
> On Thu, Mar 10, 2022 at 3:00 PM Chris Wendt <[e-mail]>
> wrote:
>
>> Hi Tim,
>>
>> I think you need to sort of separate the STIR concept of identity and the
>> SHAKEN concept of a specific implementation of STIR that is in the context
>> of policies and other things.  In SHAKEN, we assume a model that yes
>> consumers directly can’t assert their identity.  I think that is common
>> model, but i think STIR doesn’t assume any policy rather focuses on
>> protocol and PKI model.
>>
>> -Chris
>>
>> On Mar 10, 2022, at 2:04 PM, Dwight, Timothy M (Tim) <
>> [e-mail]> wrote:
>>
>> OK, so then 2 questions.
>>
>>    1. How does a consumer (or their device) "prove" they have the right
>>    to use a number?  What "evidence" do they present, and to whom?
>>
>>    2. Who grants the consumer this "right"?  What form does the grant
>>    take?
>>
>>
>> I think they're silly questions because the answers are (1) they
>> can't, and (2) nobody.
>>
>> As I understand it, there is nothing "on the wire" that would prove such
>> a right-to-use was valid.  Instead we "implicitly trust" the identity in
>> the P-Asserted-Identity header.  If it's not a number the originating
>> device is authorized to use, the originating carrier made a mistake.  STIR
>> / SHAKEN provides a means to hold carriers responsible if they make such
>> mistakes.
>>
>> STIR / SHAKEN will not AFAIK stop a call from the furnace repairman
>> presenting as its CPN the toll free number of Home Depot's service center.
>> For that to happen, Home Depot had to have worked with their carrier to
>> provide the numbers of their technicians, and authorized their carrier to
>> modify the PAID header in this way.  The carrier should have "signed its
>> work" so if there's any question whether it was appropriate, we have an
>> audit trail.
>>
>> The interesting follow-on question is what RCD gets presented in such a
>> case.  ISTM it might combine information about Home Depot (e.g., address,
>> logo, hours) and information about the repairman (e.g., his name, what he
>> looks like, what kind of car he drives).  If that's a desired end result,
>> are there standards needed to make it possible?
>>
>> tim
>>
>>
>> On Thu, Mar 10, 2022 at 11:23 AM Chris Wendt <[e-mail]>
>> wrote:
>>
>>> Sorry, clarification “spoofing” and what we want to remove is the act of
>>> using an identity you haven’t proven you have the right-to-use.
>>>
>>> On Mar 10, 2022, at 12:21 PM, Chris Wendt <[e-mail]>
>>> wrote:
>>>
>>> This is an important concept we need to agree, “spoofing” is the act of
>>> saying who you are not.  STIR should eliminate that concept, you can only
>>> assert your own identity, not an identity you do not have the
>>> right-to-use.  So i would disagree with you.
>>>
>>> On Mar 10, 2022, at 11:33 AM, Mary Barnes <[e-mail]>
>>> wrote:
>>>
>>> We are trying to eliminate "illegal" spoofing. There is also legal
>>> spoofing that we shouldn't be eliminating.
>>>
>>> On Thu, Mar 10, 2022 at 10:10 AM Chris Wendt <[e-mail]>
>>> wrote:
>>>
>>>> Wouldn’t you essentially treat that as a new call with new caller-id
>>>> and start from scratch anyway?  I’m a bit afraid of any of this scenario
>>>> because it implies some sort of spoofing of the caller that we are trying
>>>> to eliminate with STIR in the first place.
>>>>
>>>> On Mar 9, 2022, at 5:58 PM, David Hancock <[e-mail]>
>>>> wrote:
>>>>
>>>> Hi Mary -- comment on your following comment...
>>>>
>>>> "For example, there may be call forwarding scenarios where you want to
>>>> display the number for the first retargeting as the calling party and not
>>>> the original calling party."
>>>>
>>>> I vaguely remember hearing about call scenarios where the retargeting
>>>> identity is displayed to the called user, instead of or in addition to the
>>>> original calling identity. Are these cases documented anywhere?
>>>>
>>>> If the TSP is displaying the number for the first retargeting entity to
>>>> the called user instead of the original calling identity, then would there
>>>> be value in also being able to display rich call data associated with the
>>>> first retargeting entity? This gets back to my suggestion that an "rcd"
>>>> claim in a div PASSporT describes the rich call data of the "div" claim
>>>> identity. If there are legitimate scenarios where the "div" claim identity
>>>> becomes the calling identity, then maybe my suggestion has merit? Just want
>>>> to understand what we're leaving on/off the table with what we decide here.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On Wed, Mar 9, 2022 at 3:14 PM Mary Barnes <[e-mail]>
>>>> wrote:
>>>>
>>>>> Both Diversion Header and History-Info header have information as to
>>>>> why the call was diverted.  And, History-Info includes the type of retarget
>>>>> that is useful for some services.  There are services that can involve
>>>>> retargeting where the calling party number matters.  For example, there may
>>>>> be call forwarding scenarios where you want to display the number for the
>>>>> first retargeting as the calling party and not the original calling party.
>>>>> The whole purpose for Diversion and History-Info header fields is to
>>>>> provide information to services and there is not a single way they are
>>>>> handled by the called party.
>>>>>
>>>>> On Wed, Mar 9, 2022 at 2:14 PM Chris Wendt <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> No, the identity header is all about the calling party, should not
>>>>>> represent anything else. I think we even say that explicitly many times,
>>>>>> hopefully “div” specs donot imply that it represents anything besides the
>>>>>> fact that the call has been redirected from the original destination party.
>>>>>>
>>>>>> On Mar 9, 2022, at 2:44 PM, David Hancock <
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>> Adding rich call data to a div PASSporT does seem to me to go above
>>>>>> and beyond the original intent of the div PASSporT RFC. However, if we
>>>>>> think someone might want to do this, then would it make sense to have a
>>>>>> rule that the rich call data in the "rcd" claim of a div PASSporT must be
>>>>>> associated with the "div" claim identity, not the "orig" claim identity.
>>>>>> The logic being – the div authentication service is authoritative for the
>>>>>> identity in the "div" claim, but has no relationship with the identity in
>>>>>> the "orig" claim. I’m not sure if this would be a useful capability; e.g.,
>>>>>> might there be a case where the diverting entity wants to provide its rich
>>>>>> call data to the diverted-to user? But in any case this would avoid
>>>>>> creating the situation where there is conflicting rcd info between an inner
>>>>>> PASSporT and the div PASSporT(s).
>>>>>>
>>>>>> On Tue, Mar 8, 2022 at 1:00 PM Holmes, David <
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> The bottom line is going to be which passport comes from the most
>>>>>>> trusted entity (from the perspective of the terminating carrier
>>>>>>> and/recipient) and/or which allows a better assessment of the caller’s
>>>>>>> reputation to be made (if needed).  Obviously issues way beyond scope of
>>>>>>> any SDO, but ripe for someone to create a relevant “Code of practice”.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> BR/David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* stir <[e-mail]> *On Behalf Of * Ben Campbell
>>>>>>> *Sent:* Tuesday, March 8, 2022 9:29 AM
>>>>>>> *To:* Chris Wendt <[e-mail]>
>>>>>>> *Cc:* Peterson, Jon <[e-mail]>; Mary Barnes <
>>>>>>> [e-mail]>; Jack Rickard <
>>>>>>> [e-mail]>; IETF STIR Mail List <[e-mail]>
>>>>>>> *Subject:* Re: [stir] RCD vs "div"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *[External]*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mar 8, 2022, at 11:24 AM, Chris Wendt <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think putting “rcd” on a “div” identity header would be simply a
>>>>>>> fundamental misunderstanding of what “div” represents regarding the calling
>>>>>>> party identity.  I would hope we don’t need to spell that out.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I guess the real question is interoperability. If people think this
>>>>>>> is obvious enough that people won’t screw it up, I’m okay with it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I’m not sure if this was your intention but i wouldn’t say there is
>>>>>>> an “explicit association with a chain of earlier PASSporTs”  I think
>>>>>>> the opposite is true, there is a relationship with orig and dest of
>>>>>>> PASSporT(s) and new destination of “div” PASSporTs.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I didn’t mean to imply any semantics to the association other than
>>>>>>> that the linkage exists. I guess two RCD passports with the same orig and
>>>>>>> dest would have the same association—which I guess supports Jack’s argument
>>>>>>> that there is nothing special about RCD in “div” passports.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ben.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mar 8, 2022, at 12:11 PM, Ben Campbell <[e-mail]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Jack,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I understand you could get multiple passports with RCD in them even
>>>>>>> without div, and have to figure out what to use. But since a “div” passport
>>>>>>> has an explicit association with a chain of earlier passports, I wonder
>>>>>>> what it would mean to put RCD claims in a “div” passport if an innermost
>>>>>>> passport already had RCD. That seems semantically different from getting
>>>>>>> two passports with RCD that are only related by the fact they are in the
>>>>>>> same INVITE request.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> A simple answer could be “don’t do that.”
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ben.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mar 8, 2022, at 11:03 AM, Jack Rickard <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think you may be overcomplicating it: there’s nothing preventing
>>>>>>> you from putting 2 different valid RCD passports on the same call, so
>>>>>>> you’re going to have to be able to deal with conflicting RCD information no
>>>>>>> matter what. I believe the idea is that you just gather all of the RCD
>>>>>>> information you consider valid (which may have come from SHAKEN, RCD, or
>>>>>>> even DIV passports) and deal with it however you want to.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Given that I think the answers are:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Would a retargeted call inherit any RCD claims in the innermost
>>>>>>> passport?
>>>>>>>
>>>>>>> Yes, but the RCD claims would remain only in the innermost passport,
>>>>>>> the div passport won’t need them because the original passport is still
>>>>>>> valid.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> What happens if someone adds RCD claims to a “div” passport,
>>>>>>> especially if they conflict with any claims from earlier in the chain?
>>>>>>>
>>>>>>> You deal with however you see fit. I’d guess most people will have
>>>>>>> them take lower priority than the original ones but I’m not sure.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Is the answer the same for RCD passports vs other passport types
>>>>>>> with RCD claims?
>>>>>>>
>>>>>>> I don’t think there’s any real distinction between RCD information
>>>>>>> in RCD passports vs in any other type of passport.
>>>>>>>
>>>>>>>
>>>>>>> Jack
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* stir <[e-mail]> *On Behalf Of *Ben Campbell
>>>>>>> *Sent:* 08 March 2022 15:40
>>>>>>> *To:* Mary Barnes <[e-mail]>; Chris Wendt <
>>>>>>> [e-mail]>
>>>>>>> *Cc:* Peterson, Jon <[e-mail]>; IETF STIR Mail
>>>>>>> List <[e-mail]>
>>>>>>> *Subject:* [EXTERNAL] Re: [stir] RCD vs "div"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I’m willing to believe that the RCD draft doesn’t need to talk about
>>>>>>> “div” passports. But just to check my understanding:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - A “div” passport would not copy forward RCD claims from an inner
>>>>>>> passport. This is covered in RFC 8946, where it says no other claims are
>>>>>>> copied forward.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - A single “div” passport can chain back to multiple inner passports
>>>>>>> with matching orig/dest, e.g. if you have a separate SHAKEN and RCD
>>>>>>> passport in the original INVITE request. Also covered in 8946.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - Can we also assume that no one would ever add _new_ RCD claims to
>>>>>>> a “div” passport? That seems to make sense, but is it documented somewhere?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ben.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mar 7, 2022, at 2:48 PM, Mary Barnes <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I would agree with that in general.  IMHO, we really need a call
>>>>>>> flow document to show examples of all of this.  I worked on one a long
>>>>>>> while back  (no RCD - it was focused on DIV) and no one was interested in
>>>>>>> progressing.
>>>>>>>
>>>>>>>
>>>>>>> https://www.ietf.org/archive/id/draft-barnes-stir-passport-div-hi-callflows-02.txt
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Farchive-252Fid-252Fdraft-2Dbarnes-2Dstir-2Dpassport-2Ddiv-2Dhi-2Dcallflows-2D02.txt-26data-3D04-257C01-257Cdavid.holmes-2540t-2Dmobile.com-257C11d4aa0d70ec4a7cfb7408da01292bef-257Cbe0f980bdd994b19bd7bbc71a09b026c-257C0-257C0-257C637823573598265762-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-26sdata-3Dwp86b64trt9hVVKjAoA6MlBkeFZu8gpOshEWty7kjis-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=zhMTOg29rgCq8KsjWnXyZ_582kT7zpmyLEmycFMOWtQ&e=>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It's way too much work to do on my own.  But, if anyone is
>>>>>>> interested, let me know.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Mary.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 7, 2022 at 2:32 PM Chris Wendt <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>> Hi Ben,
>>>>>>>
>>>>>>> I think the way i'd like to think about it is that “div” rules apply
>>>>>>> to all PASSporTs and you don’t need multiple “div”s if you have multiple
>>>>>>> PASSporT types.  So, to the extent possible i’d like to keep that line of
>>>>>>> distinction.  In other words, i’d prefer to not have to discuss all of the
>>>>>>> other PASSporT types in subsequent PASSporT type specifications to the
>>>>>>> extent possible.
>>>>>>>
>>>>>>> A simpler answer would be that i don’t believe “rcd” has any
>>>>>>> implications specific to “div” other than someone adding new “div”s and
>>>>>>> following the general rules.
>>>>>>>
>>>>>>> -Chris
>>>>>>>
>>>>>>> > On Mar 7, 2022, at 3:25 PM, Ben Campbell <[e-mail]> wrote:
>>>>>>> >
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > (Apologies for bringing this up late in the process for RCD, but I
>>>>>>> just thought about it over the weekend.)
>>>>>>> >
>>>>>>> > Does the RCD passport draft need to talk about interactions with
>>>>>>> “div” passports?
>>>>>>> >
>>>>>>> > For example, would a retargeted call inherit any RCD claims in the
>>>>>>> innermost passport? What happens if someone adds RCD claims to a “div”
>>>>>>> passport, especially if they conflict with any claims from earlier in the
>>>>>>> chain? Is the answer the same for RCD passports vs other passport types
>>>>>>> with RCD claims?
>>>>>>> >
>>>>>>> > Thanks!
>>>>>>> >
>>>>>>> > Ben.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> stir mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fstir-26data-3D04-257C01-257Cdavid.holmes-2540t-2Dmobile.com-257C11d4aa0d70ec4a7cfb7408da01292bef-257Cbe0f980bdd994b19bd7bbc71a09b026c-257C0-257C0-257C637823573598265762-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-26sdata-3DQx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=Ny0S_IVz5OJQ3WTT8hBPOhB33PeNbOhnPye9sPWGB1g&e=>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> stir mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fstir-26data-3D04-257C01-257Cdavid.holmes-2540t-2Dmobile.com-257C11d4aa0d70ec4a7cfb7408da01292bef-257Cbe0f980bdd994b19bd7bbc71a09b026c-257C0-257C0-257C637823573598265762-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-26sdata-3DQx7nrpVtUpR52LwSr5fJ0HyD7RpUNOyFiXnzJwJlSqM-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=Ny0S_IVz5OJQ3WTT8hBPOhB33PeNbOhnPye9sPWGB1g&e=>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> stir mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=cGHwLGDrBZcVLymefoh2JE2UZ5Fv7EbQBMA1OXIhMhg&e=>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> stir mailing list
>>> [e-mail]
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=c_Kmr0d7wYbLjRgLlHhXDviBK0s0URNX8Rv57YMgUiA&m=GvnHPrfC3PsLJXplKXyXqK6mGtduWtTybUpETLN0oqjjin1oz9J9GUSgUqxIa1W5&s=cGHwLGDrBZcVLymefoh2JE2UZ5Fv7EbQBMA1OXIhMhg&e=
>>>
>>
>>
>
>