IETF
stir
stir@jabber.ietf.org
Monday, September 13, 2021< ^ >
meetecho-alexamirante has set the subject to: STIR at IETF 111
Room Configuration
Room Occupants

GMT+0
[18:50:08] Ben Campbell_web_746 joins the room
[18:50:52] Robert Sparks_web_286 joins the room
[18:53:45] Jack Rickard_web_309 joins the room
[18:54:22] Paolo Saviano_web_544 joins the room
[18:54:49] Mary Barnes_web_308 joins the room
[18:55:04] Ken Carlberg_web_724 joins the room
[18:55:49] Paolo Saviano_web_544 leaves the room
[18:58:11] Norbert Angell_web_185 joins the room
[18:58:54] Sean Turner_web_470 joins the room
[18:59:03] Mayumi Ohsugi_web_339 joins the room
[18:59:06] Subir Das_web_230 joins the room
[18:59:24] Jon Peterson_web_428 joins the room
[18:59:41] <Sean Turner_web_470> /topic STIR Interim
[18:59:47] Chris Wendt_web_632 joins the room
[19:00:04] Jon Peterson_web_428 leaves the room
[19:00:13] Jon Peterson_web_830 joins the room
[19:00:22] Paolo Saviano_web_191 joins the room
[19:00:43] <Jon Peterson_web_830> not lettting me set audio/video permissions, grr, brb
[19:00:45] <Jack Rickard_web_309> https://notes.ietf.org/notes-ietf-interim-2021-stir-02-stir
[19:00:47] Jon Peterson_web_830 leaves the room
[19:01:19] Michael Fain_web_172 joins the room
[19:01:29] Arleen Elliott_web_118 joins the room
[19:01:45] Ben Campbell_web_746 leaves the room
[19:01:50] Jon Peterson_web_438 joins the room
[19:01:50] Anders Kristensen_web_592 joins the room
[19:02:41] Ben Campbell_web_353 joins the room
[19:03:13] hala.mowafy@ericsson.com_web_122 joins the room
[19:03:32] Paolo Saviano_web_191 leaves the room
[19:03:57] Russ Housley_web_440 joins the room
[19:04:13] Mayumi Ohsugi_web_339 leaves the room
[19:04:19] Mayumi Ohsugi_web_298 joins the room
[19:06:13] Roman Shpount_web_111 joins the room
[19:07:59] Alec Fenichel_web_755 joins the room
[19:12:06] <Sean Turner_web_470> Nope
[19:15:36] Paolo Saviano_web_471 joins the room
[19:16:00] Paolo Saviano_web_471 leaves the room
[19:24:53] <Robert Sparks_web_286> OLD:
   A SIP message MAY contain more than one Reason value (i.e., multiple
   Reason lines), but all of them MUST have different protocol values
   (e.g., one SIP and another Q.850).  An implementation is free to
   ignore Reason values that it does not understand.
NEW:
   A SIP message MAY contain more than one Reason value (i.e., multiple
   Reason lines). If the registered protocol for the Reason value specifies
   what it means for multiple values to occur in one message, more than one
   value for that protocol MAY be present. Otherwise, the MUST only one be
   one value per protocol provided (e.g., one SIP and another Q.850).  An
   implementation is free to ignore Reason values that it does not understand.
[19:25:03] <Robert Sparks_web_286> bah - reformatting
[19:25:14] <Robert Sparks_web_286> OLD:
[19:25:15] <Robert Sparks_web_286> A SIP message MAY contain more than one Reason value (i.e., multiple
   Reason lines), but all of them MUST have different protocol values
   (e.g., one SIP and another Q.850).  An implementation is free to
   ignore Reason values that it does not understand.
[19:25:18] <Robert Sparks_web_286> New:
[19:25:24] <Robert Sparks_web_286> A SIP message MAY contain more than one Reason value (i.e., multiple
   Reason lines). If the registered protocol for the Reason value specifies
   what it means for multiple values to occur in one message, more than one
   value for that protocol MAY be present. Otherwise, the MUST only one be
   one value per protocol provided (e.g., one SIP and another Q.850).  An
   implementation is free to ignore Reason values that it does not understand.
[19:25:30] <Ben Campbell_web_353> Ship it
[19:26:32] <Robert Sparks_web_286> Roman - could you put together a separate draft showing what's happening in the wild with multiple values for SIP?
[19:27:48] <Ben Campbell_web_353> @Russ: I think the doctor case is actually mentioned
[19:28:59] Roman Shpount_web_111 leaves the room
[19:29:16] Roman Shpount_web_792 joins the room
[19:29:34] Mayumi Ohsugi_web_298 leaves the room
[19:30:03] <Robert Sparks_web_286> @Russ/@Ben : Before the meeting is over, lets please record whether the people here are ready to adopt the error hadnling draft
[19:30:40] <Ben Campbell_web_353> @RjS: ack
[19:31:01] <Ben Campbell_web_353> ... Russ had suggested one more rev, then adopt. Do you disagree?
[19:31:48] Mayumi Ohsugi_web_134 joins the room
[19:34:58] Mayumi Ohsugi_web_134 leaves the room
[19:35:03] Mayumi Ohsugi_web_240 joins the room
[19:38:28] <Jon Peterson_web_438> i'm sold on that jack
[19:40:57] <Roman Shpount_web_792> @Robert please contact me via email (roman@telurix.com) regarding what kind of draft should it be and what you want to see there. All I am seeing are multiple SIP protocol disconnect reasons in SIP error messages. Considering that such messages are generated by proxies, people often have a haphazard code in proxy configuration.
[19:41:24] <Robert Sparks_web_286> @Hala - I took a stab at summarizing your question in the notes - please review and correct it if I was way off base
[19:43:12] <Ben Campbell_web_353> @Hala - do you mean to still have your hand up?
[19:43:15] <Robert Sparks_web_286> (wish meetecho/jabber supported thread: I'm ok with waiting for another rev of the error doc before making an adoption call (but it seems to me that we're already working on it).
[19:50:53] <Jon Peterson_web_438> if you want to not have validation of the base SHAKEN PASSporT share fate with the validation of the rcd, but them in different PASSporTs :P
[19:53:15] <Jon Peterson_web_438> i guess the subtlety that you only validate the PASSporT itself, and ignore the rcdi etc, makes sense to me from a security perspective - I just don't want the base PASSporT to not fail if you do NOT ignore rcdi and validate it and it fails - you shouldn't still trust orig/dest if that stuff fails, should you?
[19:55:07] Pierce Gorman_web_671 joins the room
[19:57:51] Subir Das_web_230 leaves the room
[20:10:22] <Alec Fenichel_web_755> I completely agree!!
[20:10:25] <Jon Peterson_web_438> the OSP wants to know the logo links are allowed in case they contain forbidden content (that doesn't validate)
[20:11:15] <Jon Peterson_web_438> like, if the link got jacked and is now showing gun propaganda - if the hash link was for kittens but the actually link is a bushmaster ad
[20:14:36] <Alec Fenichel_web_755> I don't think we should not allow the OSP to verify, they just shouldn't be required to if they are passing the integrity downstream
[20:19:32] <Ben Campbell_web_353> We have to say "Relying party for <what>"
[20:19:38] <Ben Campbell_web_353> ... what
[20:20:17] <Ben Campbell_web_353> That is"relying party for RCDi"
[20:20:23] <Ben Campbell_web_353> vs "relying party for the signature"
[20:21:00] <Ben Campbell_web_353> (sorry, MeetEcho ate the angle brackets around "what")
[20:21:57] <Jon Peterson_web_438> agreed alec it's inert from a security perspective if the OSP validates the integrity - just not inert from a policy and liability perspective
[20:22:37] <Ben Campbell_web_353> Lawyers find value in places that technologists do not :-)
[20:22:49] <Jon Peterson_web_438> ideally, if the terminating handset is the actual relying party for the PASSporT, any prior checks are inret
[20:23:03] <Jon Peterson_web_438> only liable if they transpose into their PASporT :)
[20:23:39] <Jon Peterson_web_438> if it changes, they can still prove what it was when they checked it
[20:27:17] <Alec Fenichel_web_755> I agree with Jack. rcdi checks should be outside of the scope of the verification service. rcdi check should be part of the entity that is consuming the rcd
[20:27:45] <Alec Fenichel_web_755> rcdi failure should be treated the same as a 404 or sever timeout
[20:28:08] <Jon Peterson_web_438> i know we're ending the queue here, but we need to talk about this more :)
[20:28:26] <Jon Peterson_web_438> let's just keep talking about this and skip my preso?
[20:32:45] <Ben Campbell_web_353> What Alec is saying needs to go in the security considerations
[20:33:41] <Robert Sparks_web_286> those participating in the back-and-forth now - please consider sharing video
[20:37:45] <Alec Fenichel_web_755> Sorry, I can't share my video without leaving and rejoining, Mac permissions...
[20:38:30] Roman Shpount_web_792 leaves the room
[20:45:27] Subir Das_web_335 joins the room
[20:46:01] <Alec Fenichel_web_755> Yes!!
[20:48:13] <Sean Turner_web_470> a wee bit
[20:52:27] <Robert Sparks_web_286> I'm in the queue with chair hat on
[20:52:52] <Jon Peterson_web_438> will shut up then :)
[20:52:54] <Robert Sparks_web_286> no need to skip the queue, but might jump in if I don't get to the front of the queue quickly
[20:53:21] <Jon Peterson_web_438> i think whether we call step 1 "validation"; or not is a specmanship point, not a design point
[20:53:35] <Jon Peterson_web_438> we can call validation step 1 "foo" and step 2 "bar"
[20:54:01] <Jon Peterson_web_438> long day
[20:55:07] Sean Turner_web_470 leaves the room
[20:57:40] Michael Fain_web_172 leaves the room
[20:59:30] Arleen Elliott_web_118 leaves the room
[20:59:31] hala.mowafy@ericsson.com_web_122 leaves the room
[20:59:32] Norbert Angell_web_185 leaves the room
[20:59:33] <Jon Peterson_web_438> good luck!
[20:59:33] Anders Kristensen_web_592 leaves the room
[20:59:35] Robert Sparks_web_286 leaves the room
[20:59:36] Chris Wendt_web_632 leaves the room
[20:59:36] Pierce Gorman_web_671 leaves the room
[20:59:37] Ben Campbell_web_353 leaves the room
[20:59:39] Russ Housley_web_440 leaves the room
[20:59:41] Jack Rickard_web_309 leaves the room
[20:59:42] Jon Peterson_web_438 leaves the room
[20:59:45] Alec Fenichel_web_755 leaves the room
[21:00:07] Mayumi Ohsugi_web_240 leaves the room
[21:03:00] Subir Das_web_335 leaves the room
[21:03:02] Mary Barnes_web_308 leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!