[stir] IETF#101: STIR minutes (Christer)

[Christer Holmberg <[e-mail]>]

Hi,

Below are my minutes from the IETF#101 STIR session.

Note that there is one OUTCOME with “????”, regarding whether we should allow Identity in 3xx responses, because I missed what was decided. Please fill in :)

Regards,

Christer

--------


Topic: PASSporT Extension for Resource-Priority Authorization
Presenter: Martin Dolly
Draft: draft-ietf-stir-rph-03

Status update.

An issue whether ppt values should be quoted or not. Both ways are used, and we should agree on a common way. See 'PASSporT Extension for Divert' minutes.

NEXT STEP: Submit new version of draft.

---

Topic: PASSporT Extension for SHAKEN
Presenter: Chris Wendt
Draft: draft-ietf-stir-passport-shaken-01

Status update.

Indicated that some minor changes are still to be done, but otherwise the draft is ready to be moved forwarded. Nobody objected to moving the draft forward.

NEXT STEP: Submit new version of draft.

---

Topic: PASSporT Extension for Divert
Presenter: Jon Peterson
Draft: draft-ietf-stir-passport-divert-02

ISSUE: It was suggested to allow Identity in 3xx responses.
OUTCOME: ????

ISSUE: It was discussed on whether we should deprecate the usage of nested claims for the in-band solution.
It was indicated that the total size of an INVITE request is not a problem (the size will be large even without Identity header fields), but a large size of a single header field can cause problems.
It was indicated that we should use the same mechanism for in-band and out-of-band (nesting is needed for out-of-band).
It was indicated that, if nesting is used, it needs to be clarified how nesting is done when there are multiple incoming Identity header fields, if e.g., all of them are to be nested.
OUTCOME: Nesting will stay.

ISSUE: It was discussed whether we should define the order of Identity header fields in a SIP message, when multiple header fields are included.
OUTCOME: No need to define order of Identity header fields.

ISSUE: It was discussed whether we should define the order of claims within a PASSporT, as required by RFC 8225.
OUTCOME: No need to define anything additional, as RFC 8225 already defines how to order the claims as part of the serialisation.

ISSUE: Should we make 'opt' independent of 'div', so nesting can be used with other PASSporT extensions?
OUTCOME: Will allow 'opt' with other extensions, if needed in future.

ISSUE: Should ppt= values be quoted or not?
OUTCOME: Keep quoting mandatory.

It was indicated that more reviewers of the draft are needed.

NEXT STEP: Submit new version of the draft. WGLC once the next version of the draft has been submitted.

---

Topic: Out-Of-Band (OOB)
Presenter: Jon P
Draft: draft-ietf-stir-oob-02

Presentation of changes:

- More generic guidance for validating PASSportTS against calls without SIP.

- Mocked up a REST interface for a CPS. Initial work, more work is needed.

It was indicated that there a need to specify at least one CPS discovery mechanism (while realising that service discovery in general is a complex and much-studied topic).

NEXT STEP: Work will continue.

---

Topic: Registry for Country-Specific STIR Root Certificates
Presenter: Eric B (remote)
Draft: draft-burger-stir-iana-cert-00

There was much concern about the suggestion. It would come with a big liability and huge responsibility on IANA. It was also unclear what the Expert Reviewer is expected to do.

It was indicated that, if such registry is to be created, it should be done e.g., by ITU-T. While to problem might be clear, it is not the within the expertise of IETF or IANA.

It was indicated that, even if a registry exist, people will not rely on the information and will anyway do vetting.

NEXT STEP: No decision.

---

Topic: Connected Identity for STIR
Presenter: Jon P
Draft: draft-peterson-stir-rfc4916-update-00

"STIR backwards". Send an UPDATE request in the backwards direction while the call is being established.

NEXT STEP: No decision (discussions will continue).

---

Topic: Callback
Presenter: Jonathan R
Draft: draft-rosenberg-stir-callback-00

It was indicated that the mechanism should be seen as a complement to RFC 8226.

It was indicated that the callback INVITE will often reach a PSTN gateway that do not support the Require header field value, which would trigger a call establishment in the PSTN network.

It was indicated that perhaps OOB could be used for this.

NEXT STEP: No decision.

---

Topic: SIPcoin
Presenter: Jonathan R
Draft: draft-rosenberg-stir-sipcoin-00

Short presentation of the mechanism.

It was clarified the a blockchain is not needed: an entity will only do work before the call, and then show proof of the work when establishing a call.

Interested parties were invited to a lunch meeting, where further discussions could take place.

NEXT STEP: No decision.