Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02

From: Sean Turner <[email-masked]>
Date: Thu, 6 Aug 2020 01:37:31 -0400

Hi!

Support moving this one along, and I think these are all minor.

0) I thought the security considerations was missing something about compromise leading to misuse of network resources, but it’s the 2nd paragraph of s1. That shows you which section I read first ;) Might be worth repeating that s1 blurb in s8 or at least referring to it from s8? Maybe:

  The security consideration enumerated in
  Section 1 and the security considerations discussed
  in [RFC8224], Section 12, are applicable.

1) I hit the nits button (also out of habit) there are a lot unused references and they can be deleted:

== Unused Reference: 'RFC3261' is defined on line 275, but no explicit
   reference was found in the text

== Unused Reference: 'RFC8226' is defined on line 305, but no explicit
   reference was found in the text

== Unused Reference: 'RFC7340' is defined on line 322, but no explicit
   reference was found in the text

== Unused Reference: 'RFC7375' is defined on line 327, but no explicit
   reference was found in the text

== Unused Reference: 'RFC8126' is defined on line 331, but no explicit
   reference was found in the text

2) Do the examples in s3.1, 3.2, and s4 match the order required in s5? I.e., shouldn’t the examples be as follow to be in lexicographic order:

s3.1:
{
 "dest":{["uri":"urn:service:sos"]},
 "iat":1443208345,
 "orig":{"tn":"12155551212"},
 "rph":{"ESorig":["esnet,x"]}
}

s3.2:
{
 "dest":{["tn":"12155551212"]},
 "iat":1443208345,
 "orig":{"tn":"12155551213"},
 "rph":{"EScallback":["esnet,x"]}
}

s4:
{
 "dest":{["tn":"12155551212"]},
 "iat":1443208345,
 "orig":{"tn":"12155551213"},
 "rph":{"EScallback":["esnet,x"]},
 "sph":"psap-callback"
}

3) In s3.2, there’s a reference to "r-values”. What’s that?

4) Should this “should only” be a SHOULD:

 The value of the "sph" claim key SHOULD be "psap-callback”
 to match the SIP Priority header field value for authorized
 emergency services callbacks.

4) In s5, s/order,/order:

5) In s6, should the compact form for ‘rph’ PASSPORTS be NOT RECOMMENDED, i.e.,

OLD:

  The use of the compact form of PASSporT is not specified in this
  document or recommended for 'rph' PASSporTs.

NEW:

  The use of the compact form of PASSporT is not specified in this
  document and it is NOT RECOMMENDED for 'rph' PASSporTs.

6) 2119 and 8174 should be normative references.

Cheers,

spt

> On Jul 31, 2020, at 11:29, Russ Housley <[email-masked]> wrote:
> 
> 
> This is the STIR WG Last Call for "Assertion Values for a Resource Priority Header Claim and a SIP Priority Header Claim in Support of Emergency Services Networks” <draft-ietf-stir-rph-emergency-services-02>.  Please review the document and send your comments to the STIR WG mail list by 22 August 2020.
> 
> https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/
> 
> Thanks,
> Robert & Russ
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 6 Aug 2020 12:47:38 +0000

I support as well

-----Original Message-----
From: stir <[email-masked]> On Behalf Of Sean Turner
Sent: Thursday, August 6, 2020 1:38 AM
To: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02

Hi!

s3.1:
{

s3.2:
{

s4:
{

 The value of the "sph" claim key SHOULD be "psap-callback”
 to match the SIP Priority header field value for authorized  emergency services callbacks.

OLD:

NEW:

Cheers,

spt

> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> org_doc_draft-2Dietf-2Dstir-2Drph-2Demergency-2Dservices_&d=DwIGaQ&c=L
> FYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rc3BKD0F1A86-CRpYcNpr
> 3ms70HuQtKNY4CHDOwLFi4&s=wrhfFB0s-E4uOkriBv9h6dXa72267K1J1fyz_BiBkNQ&e
> =
> 
> Thanks,
> Robert & Russ
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7I
> tG0r2g&m=rc3BKD0F1A86-CRpYcNpr3ms70HuQtKNY4CHDOwLFi4&s=ZKKsr6tspW-kbfj
> ncoP6hDzO5sgTK73kzp7v8GrK9z0&e=

_______________________________________________
stir mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rc3BKD0F1A86-CRpYcNpr3ms70HuQtKNY4CHDOwLFi4&s=ZKKsr6tspW-kbfjncoP6hDzO5sgTK73kzp7v8GrK9z0&e=

---

From: Hala Mowafy <[email-masked]>
Date: Thu, 6 Aug 2020 14:12:24 +0000

Ericsson supports moving this along.
Hala

-----Original Message-----
From: stir <[email-masked]> On Behalf Of Russ Housley
Sent: Friday, July 31, 2020 11:30 AM
To: IETF STIR Mail List <[email-masked]>
Subject: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02

This is the STIR WG Last Call for "Assertion Values for a Resource Priority Header Claim and a SIP Priority Header Claim in Support of Emergency Services Networks" <draft-ietf-stir-rph-emergency-services-02>.  Please review the document and send your comments to the STIR WG mail list by 22 August 2020.

Thanks,
Robert & Russ

---

From: Richard Shockey <[email-masked]>
Date: Thu, 06 Aug 2020 10:18:30 -0400

+1  I support this as well. 

— 
Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

On 8/6/20, 8:47 AM, "stir on behalf of DOLLY, MARTIN C" <[email-masked] on behalf of [email-masked]> wrote:

    I support as well

    -----Original Message-----
    From: stir <[email-masked]> On Behalf Of Sean Turner
    Sent: Thursday, August 6, 2020 1:38 AM
    To: IETF STIR Mail List <[email-masked]>
    Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02

    Hi!

    s3.1:
    {

    s3.2:
    {

    s4:
    {

    OLD:

    NEW:

    Cheers,

    spt

---

From: Robert Sparks <[email-masked]>
Date: Thu, 6 Aug 2020 11:03:39 -0500

It would be far more useful for me to hear "I have read this draft and 
see nothing that I think needs to change before sending it to IETF LC" 
than to hear +1 for support.

Is that what the +1s so far mean?

RjS

---

From: Brian Rosen <[email-masked]>
Date: Thu, 6 Aug 2020 14:32:10 -0400

We need to make a decision on what to reference for the emergency stuff.  I currently references my explanatory draft.  We discussed in the meeting on the rcd topic the proper separation of the stir mechanism that defines the PASSporT and the SIP mechanism that shows how it’s used.  I will definitely create and push through a sip mechanism draft updating RFC6881 to cover how we use RPH and Priority.  But should I push the explanatory draft through to an RFC so we can reference it?  I’m thinking not.  If that’s what we decide, then the reference would be to the mechanism document.

The reference to urn:service:sos is RFC5031.

Section 3.2 “When using "EScallback" as the "rph" assertion value, the "orig" claim of the PASSporT MUST represent the emergency network telephone  number. “  No idea what “emergency network telephone number is”.  Maybe “the telephone number used by the emergency services for call back, or a country or region specific dial string”.  I believe that won’t conflict with any text on authority (i.e. who has authority for a dial string would be determined by the same authorities who handle telephone numbers in a country or region). 

Other than that, I’ve reviewed it and think it’s ready to go.

Brian

> On Jul 31, 2020, at 11:29 AM, Russ Housley <[email-masked]> wrote:
> 
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 Aug 2020 10:36:49 -0400

I am confused by the last sentence of the Introduction (Section 1).  It says:

   In addition, the PASSPorT claims and values defined in
   this document are intended for use in environments where there are
   means to verify that the signer of the SIP 'Resource-Priority' and
   'Priority' header fields is authoritative.

The signer signs the PASSPorT.  The PASSPorT includes claims, and each claim has a value.  By construction, the values are expected to match the SIP 'Resource-Priority' header field and the SIP 'Priority' header field.  Is this saying that the PASSPorT must be authoritative for these claims if they are present?

In Section 3.1, I expected a MUST statement that says what appears in the value of the "ESorig" value.  It says what MUST appear on other claims around the "rph" claim, but it only gives an example of a value that matches an SIP 'Resource-Priority' header field.

Likewise in Section 3.2, I expected a MUST statement that says what appears in the value of the "EScallback" value.  It says what MUST appear on other claims around the "rph" claim, but it only gives an example of a value that matches an SIP 'Resource-Priority' header field.

In Section 3.2, I believe that the last paragraph applies to both the "ESorig" value and the "EScallback" value, so it probably belongs in Section 3 or a separate subsection.

Section 4 says:

   Therefore, we define a new claim key as part of the "rph" PASSporT, ...

I think it would be more clear to say:

   Therefore, we define a new claim key to be used in a PASSporT that includes "rph" claim, ...

Section 6 should use RFC 2119 wording:

   The use of the compact form of PASSporT is not specified in this
   document.   Use of the compact form of PASSporT is NOT
   RECOMMENDED for a PASSporT that includes a "rph" claim.

I think that the Security Considerations (Section 8) should say someting about the consequences of a PASSPorT that includes the "rph" or "sph" claim that is signed by a party that is not authoritative for the SIP 'Resource-Priority' header field and the SIP 'Priority' header field.

Russ
(No Hats)

---

From: Brian Rosen <[email-masked]>
Date: Tue, 18 Aug 2020 17:45:57 -0400

See my reply to Jack for more info.

For an emergency call, we are protecting the use of rph with the esnet namespace to be limited to emergency calls.  So the signer checks From as usual, and checks Request URI to see that it is urn:service:sos, and if so, checks rph to see that it is esnet.1 SIP Priority is not used with emergency calls.  It could modify rph if it wanted to and then sign, or refuse to put in the claim.

For a call back, the signer has to know that the calling entity is an allowed authority (or it may be that the authority signs its own calls).  That permits SIP Priority to use the call back marking.  rph must be esnet.0 or get modified as above to get the claim.

> On Aug 17, 2020, at 10:36 AM, Russ Housley <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 22 Aug 2020 18:35:54 -0400

WG Last Call is over.  I saw many comments that need to responses.

Russ