Re: [stir] Draft minutes from the 2019-Sep-20 Stir Virtual Interim

[Ben Campbell <[e-mail]>]

I assume this is my typo:

s/ "Is third-party RCS evil” / "Is third-party RCD evil"

Ben.



> On Sep 24, 2019, at 9:06 AM, Robert Sparks <[e-mail]> wrote:
> 
> The draft minutes are available at <https://datatracker.ietf.org/meeting/interim-2019-stir-01/materials/minutes-interim-2019-stir-01-201909201000> <https://datatracker.ietf.org/meeting/interim-2019-stir-01/materials/minutes-interim-2019-stir-01-201909201000> (and copied below for your convenience).
> 
> Please send any necessary corrections to the list or the chairs.
> 
> The recording is at <https://ietf.webex.com/recordingservice/sites/ietf/recording/playback/9bfb52eeb4334ea2b5226811474ff8a4> <https://ietf.webex.com/recordingservice/sites/ietf/recording/playback/9bfb52eeb4334ea2b5226811474ff8a4>
> RjS
> 
> ----
> 
> Minutes: STIR Virtual Interim September 20, 2019
> 
> == Attendees ==
> 
> Adam Roach, Andrew Gallant, Arleen Elliot, Ben Campbell, Bopsi Chandramouli,
> Chris Wendt, Eric Burger, Hala Mowafy, Jon Peterson, Kevin Cassidy, Martin
> Dolly, Mary Barnes, Michael Richardson, Mike Hamilton, Rich Salz, Rifaat
> Shekh-Yusef, Robert Sparks, Russ Housley, Sathvik Prasad, Vijay Gurbani
> 
> == Agenda ==
> 
> Close open issues on:
> 
>     draft-ietf-stir-passport-rcd-04
>     draft-ietf-stir-cert-delegation-00
> 
> == draft-ietf-stir-passport-rcd-04 ==
> 
> Chris presented updates in version 04.
> 
> Question: Should call-info/RCD be used together for the two main cases?
> 
>   1: Post-validation: Extract out identity headers towards UE  (e.g. eCNAM)
>   2: compact-form (canonicalization from display-name and call-info) - needs
>      further definition
> 
> Conclusions:  Align the RCD with call-info. Use call-inf as a mechanism to
> define compact-form. Future extensions to call-info may need to align with RCD.
> Need to make sure this really works—may need a separate “stub” draft.
> 
> 
> Discussion: issues related to URL nesting in RCD. Issues include the
> possibility of intentional abuse, the need for any vetting authority to verify
> nested URIs, and the need to put reasonable limits on nesting.
> 
> Conclusions: The draft should guidance for the use of referenced content in
> RCD, including the use of nested references. There are a number of
> considerations here; the group needs some proposed text to discuss.
> 
> Discussion: Should the use of the “rcdi” mechanism should be normatively
> required?
> 
> Conclusions: “MUST” use rcdi if the RCD includes referenced content (i.e.
> Links). “MAY” use otherwise.
> 
> Discussion: Do we need 3 digest algorithms? Current algorithms align with existing passport signature algorithms.
> 
> Conclusions: Keep as is (i.e. keep the 3 algorithms)
> 
> Discussion: “icn” key vs using “logo” in a jcard.
> 
> Conclusions: Favor the jCard usage. jCard is more expressive  than the “icn”
> key about the originator’s intent. jCard gives a better chance of having both
> the sender and recipient interpret the content in the same context. We should
> align with jCard as main mechanism for both RCD and call-info, but need to have
> discussion in both areas to come to consensus.
> 
> Discussion: Is third-party RCS evil?
> 
> Conclusions: Not necessarily. There are reasonable use cases for third part
> RCD. These may provide migration paths since not all call originators will be
> able to sign their own RCD passports on day 1.
> 
> Discussion: Privacy Considerations.
> 
> Conclusions: The privacy considerations for RCD are mostly similar to those for
> SIP headers. The same privacy mechanism should apply to RCD as the rest of the
> SIP message. The main difference is the use of referenced content. The draft
> should include privacy considerations related to referenced content.
> 
> 
> == draft-ietf-stir-cert-delegation ==
> 
> Discussion: Should this work continue, given the controversy in other industry
> groups about the best way to handle enterprise caller use cases?
> 
> Conclusions: Continue to progress the work. Industry likely to use multiple
> solutions in parallel. Treat this as a tool in the toolbox that other groups
> can use (or not) as they wish.
> 
> 
> Discussion: How do OCN and tn blocks interact?
> 
> Conclusions: Typically parent cert contains the OCN and the child cert has TN
> blocks, in which case the parent OCN constrains the childTN blocks. If a single
> cert has both OCN and TN blocks, they are additive, that is, the OCN does not
> constrains the TNs. This may need further discussion/clarification, as people
> not involved in the discussion may have different interpretations.
> 
> 
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir