22:54:24 RRSAgent has joined #did 22:54:24 logging to https://www.w3.org/2021/11/30-did-irc 22:54:30 zakim, this is did 22:54:31 got it, brent 22:56:05 zakim, start the meeting 22:56:05 RRSAgent, make logs Public 22:56:06 please title this meeting ("meeting: ..."), brent 22:56:21 meeting: Decentralized Identifier Working Group 22:56:28 chair: Brent Zundel 22:56:45 agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Nov/0015.html 22:56:45 brent, sorry, I did not recognize any agenda in https://lists.w3.org/Archives/Public/public-did-wg/2021Nov/0015.html 23:00:58 present+ 23:01:13 present+ 23:01:20 Logan_Porter has joined #did 23:02:16 present+ TallTed 23:02:29 present+ Logan_Porter 23:03:39 scribe+ 23:04:12 present+ cel 23:04:26 present+ agropper 23:05:15 brent: Let's go ahead and get started, fairly straightforward agenda, bulk of our meeting will be on DID Method registration limitations... what are existing limitations, what should those limitations be moving forward, as time permits after that, we'll look at did-spec-registries issues. 23:05:24 brent: Any questions about the agenda? Anything else we want to talk about today 23:05:25 q+ 23:05:33 ack manu 23:06:01 manu: Can we talk about DID Core objections for a bit? 23:06:07 brent: Yes, we can -- let's do that now. 23:06:17 sure 23:06:26 scribe+ cel 23:06:41 Topic: DID Core Spec update 23:06:54 manu: Just an update: we specifically requested a timeline before Thanksgiving, two weeks ago, to the Advisory Board. 23:07:05 ... They were talking about timeline and things of that nature. We haven't gotten a response yet. 23:07:14 ... It's been 80+ days. Really long time for a FO. 23:07:22 drummond has joined #did 23:07:27 present+ 23:07:34 ... Haven't published minutes - meeting every other week. Expecting minutes this Thursday and then to find if there is a timeline or not. 23:07:38 rgrant has joined #did 23:07:59 ... We're being guinea-pigged... don't know what to expect... don't know what to do about that, other than multiple of us asking for a timeline. 23:08:31 markus_sabadello has joined #did 23:08:42 ... Two things we can do... We've talked with Google, wrote it up. Also talked with Mozilla... they are writing it up for distributing to the AC. 23:08:45 present+ 23:09:02 ... We have a pretty good idea of their concerns at a high level. Probably need to write that up and circulate it among the AC. 23:09:08 ... I've taken a shot at that, here: 23:09:10 Letter to the AC on DID Core FO Status: https://docs.google.com/document/d/1hx8IxRHHE2ex5mzJ_4e_9qxZYeH9ZEcsdzJiVIdSor4/edit 23:09:11 present+ drummond 23:09:16 present+ dmitriz 23:09:23 Orie_ has joined #did 23:09:29 ... That's a link that has comment rights. I'd like this group to maybe review that, modify language, see if anything was missed. 23:09:35 present+ Orie_ 23:09:43 burn has joined #did 23:09:49 agropper has joined #did 23:09:51 present+ burn 23:10:00 present+ rgrant 23:10:00 present+ 23:10:03 ... The purpose of the letter is to try to summarize where we are, not to say what is right or wrong, just to say what seem to be the points of contention, and where the WG is right now. 23:10:15 ... We know what is request, and that is problematic... 23:10:24 kdenhartog has joined #did 23:10:24 present+ jandrieu 23:10:28 present+ 23:10:30 present+ kdenhartog 23:10:33 ... We are trying to say we understand the concerns at a high level and ask what you suggest we do about it concretely 23:10:54 Write up of status of formal objections: https://msporny.github.io/did-core-formal-objections/ 23:10:59 ... Second item: a request to the group - I think I've circulated this to the group before ^ 23:11:28 ... I'd like to propose the WG adopt the write-up I did - specifically to fix it up and make it a position, so that we can go into the FO council with a writeup and all the QA that's happened over the past few months. 23:11:35 ... Suggestion is to transfer it to the WG 23:12:13 ... To summarize, two requests to the group: 1. review that letter; if objections, I'll send it as a personal letter. 2. review transferring that repo to WG 23:12:18 q? 23:12:23 q+ 23:12:26 ... Goal is to make it easy to summarize the WG's position on all points 23:12:30 brent: Thanks, we'll take questions now. 23:12:38 ack drummond 23:13:09 drummond: First of all, thanks Manu for all the work to help us through this process. We're being guinea pigged, we don't even know what this process looks like, helpful. Question around AC letter -- is that letter you like to send from the WG? What's our process for approving it? 23:13:10 q+ 23:13:15 ack manu 23:13:17 q+ to wish to rewrite the sustainability section 23:13:22 manu: It's a good question... 23:13:55 ... I don't think we need to get it approved by the WG, I'm just going to send it out there, to say here's where we are - just don't want anyone to say "no, that's not all right" 23:14:07 ... Letter doesn't need to be formal - just a once-over by the WG for any objections 23:14:26 ... The repo, it would probably be better to have it in the WG, and be reviewed for any errors 23:14:46 ... Both are important for the Formal Objection council to take a look at and know that the WG has reviewed it and there are no objections, etc. 23:14:51 brent: Any other questions from folks? 23:15:01 ack rgrant 23:15:01 rgrant, you wanted to wish to rewrite the sustainability section 23:15:31 rgrant: I would like to rewrite the sustainability section to reference the conflict with human rights and inability to rank one above the other given the current ethical web principles. 23:15:32 q+ 23:15:37 ack manu 23:16:06 manu: My hope is to not get in an argument about that with anybody, and just say, sustainability is important to everyone, let's make another group. 23:16:19 ... The W3C cares about sustainability - there needs to be a sustainability group. 23:16:48 ... My concern about what you would do is that there would be an argument - It's totally valid, but if we get into that argument in this group with the FO council, it could slow the process down. 23:17:09 q+ 23:17:28 rgrant: ... I can't accept it as is 23:17:30 manu: Please suggest concrete changes 23:17:30 ack drummond 23:17:32 rgrant: Will do 23:17:33 manu: ok, please suggest changes and we'll go from there. 23:17:45 drummond: Were you commenting on the last section of letter or the FAQ? 23:17:51 rgrant: On the letter? 23:18:02 rgrant: I don't want to allow the current framing to persist. 23:18:52 drummond: Having looked at the letter, it would be helpful to send to the AC list this letter. We don't have to approve as WG -- would favor doing that, modulo changes/objections such as the one ryan just raised, it does help make a strong case for moving forward... put ball in FO Councils court. 23:18:56 q? 23:19:16 brent: We're going to mvoe forward with Agenda, thanks for bringing those things to groups attention. Going to talk about DID Method registration limitations. 23:19:24 Topic: DID Method Registration Limitations 23:19:35 https://github.com/w3c/did-spec-registries/pull/369 23:19:36 brent: Let's start by looking at PR 23:19:49 JoeAndrieu has joined #did 23:19:55 q+ 23:20:05 brent: markus, can you walk us through this PR? 23:20:14 markus_sabadello: yes, I can 23:20:16 ack markus_sabadello 23:20:56 markus_sabadello: a new requirement added to registration process -- DID Method names must be indicative of their function or underlying nature of Verifaible Data Registry, motivation, other PR -- addition of did:id method. 23:21:31 can someone drop the PR link? Is this in did-core? 23:21:39 markus_sabadello: Could be a useful role, names should indicate what they do -- 'myProperty', 'foo', 'abc', or 'firstName', but it has nothing to do with first name... registry, method -- do we have any rules around that/ 23:22:01 found it. https://github.com/w3c/did-spec-registries/pull/369 23:22:21 markus_sabadello: Feedback in PR so far, sounds like that could be useful, might be difficult to make judgement in some cases, one proposal was to change MUST to SHOULD ... after reflecting, I would be fine w/ that change. Would be fine with that change, to remove burden for Editors and additional value judgements. 23:22:24 +1 to making it a "SHOULD" 23:22:28 markus_sabadello: That's current status of PR. 23:22:38 q+ 23:23:04 ack JoeAndrieu 23:23:07 brent says some amazing things on mute. 23:23:24 JoeAndrieu: What's the definition of extension? property names or method names? 23:23:27 markus_sabadello: All of it 23:23:38 JoeAndrieu: It seems inappropriate that a method name has to be indicative. 23:23:39 q+ 23:23:45 ack manu 23:24:02 q+ 23:24:23 +1 to it being a "MUST" if the PR is limited to properties 23:24:27 q- 23:24:37 manu: If this is about properties, I don't have a problem with that, even with a MUST. Applying this to DID Methods is more difficult 23:24:42 scribe+ 23:24:47 +1 to property only and it seems much easier to scope the subjectiveness 23:24:51 q+ 23:25:06 q+ 23:25:10 ack kdenhartog 23:25:45 kdenhartog: I agree with manu about property aspects, but also recognize that this was raised because of method names -- in that regard, do we not apply this to method names? Or just split it out wrt. procedure, deal w/ method names later. 23:25:46 ack markus_sabadello 23:26:06 q+ to talk about the limitations of the directory 23:26:19 markus_sabadello: Kyle is right, original motivation had to do with method name -- felt that particular method was misnamed -- with regard to this PR, lets make it MUST for property names and parameter names, SHOULD for method names. 23:26:20 q+ 23:26:26 ack JoeAndrieu 23:26:26 JoeAndrieu, you wanted to talk about the limitations of the directory 23:27:06 JoeAndrieu: I think we're doing too much for methods, long term, we should not have a registry for DID Methods here -- we took what we needed to have an interoperable properties registry, and started listed DID Methods... feature creep, started an avalanche, not right place to do it, DID Methods don't have to be registered to be conformant. 23:27:30 JoeAndrieu: I'd like to plan that seed... don't have a solution that's better right now, whole world of conversations because we bit off what we can chew. 23:27:34 ack manu 23:27:45 q+ 23:27:48 +1 to less registry and more directory 23:27:53 q+ 23:27:55 There was a lot of pressure to establish unique DID method names, at least in one context (the W3C context) 23:28:09 +1 ... I think folks should not think of the registry as useful for discovery or directory.... 23:28:27 kristina_ has joined #did 23:28:31 manu: +1 to that. That solves a bunch of problems we're having now. And it incentivizes Method implementers to pass the test suite or go through the rubric. I'd like to split this in two. 23:28:39 q+ to talk about the unique namespace driver 23:28:47 q+ 23:28:56 ... property names should mean what they indicate, DID Method names should be kicked down the road. 23:29:13 ... then we can talk about DID Method names 23:29:19 ack agropper 23:29:32 agropper: +1 to Joe's point, curious -- why wouldn't we focus entirely on Rubrics? 23:29:39 ack kdenhartog 23:29:53 kdenhartog: Is it ok if we continue down path of responding or do this later? 23:31:04 q+ 23:31:17 kdenhartog: +1 to that, Joe's advocated that point... W3C from a founding, doesn't have things in place to deal w/ trademarks other difficult aspects, we're likely to run into that, only concern I have... what do we do about interop case where resolvers treat methods in different ways? BBS+ keys inside Sovrin DID method, but wasn't compliant w/ sovrin did method... breaking change, should've been renaming method, didn't do that -- implication on interop 23:31:17 by allowing people to resuse same namespace in different ways for different methods. 23:31:21 ack drummond 23:31:21 drummond, you wanted to talk about the unique namespace driver 23:31:23 q+ to say the spec does not require unique did method names. 23:31:28 present+ kristina_ 23:32:41 drummond: The very first versiono f DID spec, we said: there shall not be a registry of DID Methods... but here we are with a registry -- reason we have registry was because of unique namespace consideration, he was one of the strong proponents on "how do I know if I'm using authoritative method", that's why we're doing it. If we're doing it, that's why we need baseline requirements so we don't get it filled with junk... in terms of not real/legitimate 23:32:41 methods... way to get around it, ignore it? Namespace uniqueness was the reason we did it. 23:32:47 ack TallTed 23:33:19 TallTed: A few things -- the registry, as I recall it, one of the first thing that went into registry was DID Methods, namespaces wasn't solved in another way, if we undo it here, needs to be addressed. 23:33:28 Maybe we can move the did method registry to IANA? 23:33:41 q+ 23:33:59 TallTed: Not everyone in the world speaks english, if we have to name things to what they're doing, we need to declare a language... english would suit people on this call, but perhaps it should be cantonese or something w/ a larger population? 23:34:36 TallTed: In a lot of ways, what we were should've thought about two years ago we're thinking about now... unfortunate due to current FOs... but perhaps we do this again w/ some of these considerations higher in mind. 23:34:45 ack kristina_ 23:35:09 kristina_: A big -1 to killing DID Method registry entirely. Did I understand that correctly? 23:35:25 brent: My understanding is properties and parameters would stay, but DID Methods would be removed. 23:35:33 brent: This is about removal for DID Methods 23:36:34 kristina_: A big -1 to that, even though it's been criticized, it helps interop. We need to understand which client supports which DID Method, here's a registry, this is a common way on what to include in metadata without any judgement. This is why we're separating Rubric from DID Method registry, we need that. 23:36:45 kristina_: I'd like Mike Jones to be on this call if that decision were to be made. 23:36:46 ack JoeAndrieu 23:36:46 JoeAndrieu, you wanted to say the spec does not require unique did method names. 23:37:26 q+ 23:37:46 JoeAndrieu: There is a misconception about what's currently functionally specified. There is no requirement that property names be unique, DID Methods names are unique, this is exactly parallel to the question: Which blockchain deserves the BTC ticker symbol... a centralized registry to deliniate that space is not the right wayt to solve a decentralized identity problem. We need a healthy mechanism where people can discover DID Methods. 23:38:20 JoeAndrieu: Centralizing a control system is exactly what W3C does not have the institutional processes to handle... who owns any of these entries? Who gets to choose entries? 23:38:56 q+ 23:38:59 JoeAndrieu: For IANA, there is process and case law... we should take some time over holidays wrt. how we do this better. Main reason we had registry is interop for JSON / JSON-LD... then we added Methods. 23:39:06 ack markus_sabadello 23:40:00 markus_sabadello: Don't have a strong opinion either way, there is a trade-off -- on one hand it's useful to have registry of method names, on the other hand it introduces a central authority which controls a namespace... middle ground we ended up with was method registry is informal guidance, a way of discovering. 23:40:17 +1 method registration was always considered informal and optional 23:40:23 +1 to the method registry being to provide informal guidance 23:40:40 markus_sabadello: informal, non-normative listing, not a requirement for anything to work... they should still work for OpenID connect and other things, difficult topic -- maybe we shoul dhave method numbers instead of method names.... did:46 23:40:52 markus_sabadello: Removing it at this point would go too far. 23:40:56 q? 23:41:00 q+ 23:41:00 ack kristina_ 23:41:44 +1 to say anyone should be able to create a method, without censorship 23:42:02 kristina_: A couple of points -- first introducting centralization into decentralizing space... we're decentralizing identifiers, we're decentralizing keys... let's decentralize that first. decentralized PKI identifier problem first... then let's solve discovery next... simplest way is to have a registry right now. 23:42:25 +1 to Kristina's point that our first goal is solving decentralized identifiers and PKI first 23:42:52 kristina_: There are legal issues related to registries... there is a misconception there, doesn't mean system doesn't work... IANA has a registry, W3C is undergoing some transformation, but introducing a good mechanism... worth the effort to try and install it. 23:43:24 ack Orie_ 23:43:29 kristina_: You need to discover each DID Method... inside DID Documents, you can use another mechanism. 23:44:37 Orie_: There was a CCG work item that managed a registry of DID Methods and eventually we imported that work item into DID Spe cregistries as a section, and I kinda agree w/ everything everyone's been saying -- need a way to say "here's the namespace registry", then you need other places to pass judgement on those registrations. It's basically first come first serve unless you violate a legal/security issue that would put things at risk... we approve by 23:44:37 default if you follow the rules. 23:45:06 +1 to say we don't need discovery. it's a nice to have. 23:45:42 q+ to ask when we are going to discuss the "DID spec compliance value judgement" question 23:45:54 q+ 23:46:06 Orie_: I don't know how IANA handles this -- DID Method registry may belong at IANA, not at W3C -- not a place to put all these value judgements, customization, just a place to solve for global interop, that's it's purpose, based on centralized tech-- first version is going to be... IANA is totally centralized, it's what works -- centralized registries, you can't there is not way to solve that problem better than how IANA has solved it... DID Method 23:46:06 registries is how it's supposed to be, not filled w/ value judgements, you discover that information in other places. 23:46:10 ack manu 23:46:26 q- 23:46:31 +1 to returning to PR 23:46:46 and W3C != IANA 23:46:53 manu: I feel like we are spiraling away from the PR we were discussing. I want to remind folks that IANA is still people and they still have these discussions. 23:46:59 clearly... IANA has registries that work. 23:47:07 -10000000000 to returning to PR 23:47:43 "PR" pull request 369 - not proposed rec 23:48:06 ... we should keep what we have now. The value of IANA is that they don't make value judgements. I think we may have people in the WG who want to make value judgements. I'd like to go back to the PR itself. How can we pull it in. If we can make it aboutproperties and not methods. 23:48:14 q+ 23:48:23 Are we declaring English to be the lingua registrata? 23:49:09 ack drummond 23:49:09 drummond, you wanted to ask when we are going to discuss the "DID spec compliance value judgement" question 23:49:19 brent: Let's talk about the PR -- quickly, drummond. 23:49:59 not making a value judgement does not mean not making any judgement at all 23:50:00 drummond: If we're keeping method registry, we need baesline compliance value judgement/decision -- at one end, it's no judgement at all -- even IANA, baseline IANA -- do you have a spec, baseline judgement about compliance so we don't get complete junk. 23:50:09 Gotsta make English requirement explicit in the docs, if that's consensus. Or make something explicit about handling Unicode values, non-EN langs, etc. 23:50:16 ack markus_sabadello 23:50:18 q+ 23:50:46 Regarding the "DID spec compliance value judgement" we should take a look at [RFC6838], [RFC4289], and [RFC6657] which is how mime-types handle registration 23:50:49 present+ pam_dingle 23:51:00 presnt+ takeuchi 23:51:02 markus_sabadello: regarding the PR, I'll split it up into two PRs... one about property names, I don't think language concern is an issue... don't have to have things be in english, that's what I will do -- split it up into method names with SHOULD -- thngs can be said separately. 23:51:04 +1 to splitting the PR 23:51:04 ack kristina_ 23:51:27 kristina_: Not making value judgement doesn't mean not making any judgement at all. 23:51:33 manu: +1 to kristina. 23:51:53 q? 23:51:53 drummond: I would agree, value judgement or legitimacy discussion, not trying to say it's more than a baseline... 23:52:06 Kristina: Checking that method name exists, method name is harmful, etc. 23:52:23 q+ 23:52:31 drummond: Specific proposal, is the method spec compliant at a base level, we have a set of requirements that would prevent rogue registrations that wouldnt' have legitimate spec. 23:53:01 q+ 23:53:05 q+ 23:53:05 brent: First, thanks, this is a good conversation, agree, glad we were able to come to agreement on PR -- continue this conversation, going to ask question, purpose of question is to stir things up a bit? Why do we care if people register junk? 23:53:06 q+ 23:53:09 q+ 23:53:11 q+ 23:53:21 ack brent 23:53:26 ack Orie_ 23:53:31 pam has joined #did 23:53:36 q+ 23:53:42 Orie: The only reason we would care, is that they're taking valuable words and destroying their value so they're not useful. 23:53:44 q- 23:53:53 q+ 23:53:59 DDoS attack on a DID method registry by registering a lot of junk method names? 23:54:06 Exactly 23:54:37 ^^^^^^^ yup 23:54:39 7 days??? I thought we had 30? 23:54:48 Orie: if I name squat, namespace is shrinking, value in strings people have affinity for. So, we need registries that have Editors that are capable of handling those sorts of scenarios, whole bunch of people that are spinning up GPT3 crafted DID Specifications... according to rules, I have to approve them... not that great to do that sort of thing, squatting on whole namespace, assgn them, handle mapping, 23:54:54 q? 23:55:03 zakim, freeze the queue 23:55:03 I don't understand 'freeze the queue', brent 23:55:13 zakim, close the queue 23:55:13 ok, brent, the speaker queue is closed 23:55:14 zakim, close the queue 23:55:14 Orie: managing a registry is an annoying process and it's even more annoying when registry does more than checking a few minimum criteria. 23:55:15 ok, burn, the speaker queue is closed 23:55:34 Orie: Obsolete, probably going to happen. 23:55:48 I'm hoping that DID method names have minimal value because 99.99999% of humanity will never see one. But they still have some value to the developers, which is why we still need to avoid garbage DID methods. 23:56:15 +100, drummond. Devs are our main audience 23:56:21 ack kdenhartog 23:56:25 Orie: We care deeply if name squatting / damaging registrations happens, harm existing DID Methods, make registration process really frustrating, 23:57:13 kdenhartog: Primary reason we care, spam attack on maintainers of registry. Takes me 40 minutes to do an evaluation of method, I'm looking for "can I implement this myself?" -- maintainers have to spent time on this. 23:57:38 ack drummond 23:57:40 almost like IANA already knows how to solve this.... 23:57:43 kdenhartog: DID Methods are TLDs, some sold for $150K, we need to recognize cash value here. 23:58:06 ok, but they ARE TLDs for developers 23:58:15 We've already seen it in indy space 23:58:29 people are using the indy did method and renaming to fit their network 23:58:37 q+ to (probably too late for call) suggest that many (certainly some) DID method registrants may be thinking they're registering as implementations, not spec'ing a method that others can implement. I think DID methods should be considered as more akin to URI schemes, than the discussion of did:id suggests 23:58:57 is a DID method equivalent to a tld? an http URL? an IP address? 23:59:16 q? 23:59:20 q- I think the point is already well made 23:59:25 drummond: Allergic reaction of DID Method name to TLD, just got done entering a comment about vast majority of humanity will never see DID and Method name... could be completely wrong about that... they are TLDs for a developer, write code... still some value ... that's why we have 114 registrations, in my view, it's the quality of the registry, even if it's informal, being able to discover information, find spec associated w/ method. What we end up, 23:59:25 method name in spec, rubric, test reports, implementations, useful tool... quality of that tool -- that's what we should care about. 23:59:33 q? 23:59:33 ack JoeAndrieu 00:00:03 +100000 stop trying to use the registry to discover "value"... 00:00:27 JoeAndrieu: I don't think the registry is the sort of place to do that additional discovery... hoping to propose something next quarter on that... explciit question-- junk methods will make DIDs look like junk. People will pick one, and if it looks bad, they think it's malarkey/scam... 00:00:29 ack Logan_Porter 00:00:29 +1 to Orie 00:00:32 brent: maybe some folk shave already done that. 00:00:35 "a bunch of junk DID methods" will make DID look like junk <== totally agree with Joe on that 00:00:35 I tend to think the web is bad, because many web sites are bad. 00:00:57 orie: lol 00:01:03 q- pam 00:01:11 +1 to encouraging re-use of DID methods 00:01:13 Logan_Porter: A DID Method should be a means to access data rather than a brand, we want to encourage people to reuse methods and interop better... I hope it'll push implementers to use existing method rather than fulfill requirements to make high quality method. 00:01:33 cheers! 00:01:35 brent: Thanks all for being here, your passion, the discussion, thanks many and charles for scribing, see you next week! 00:01:48 s/many/Manu 00:01:49 rgrant: k thx :) 00:02:04 zakim, who is here? 00:02:04 Present: brent, shigeya, TallTed, Logan_Porter, cel, agropper, drummond, markus_sabadello, dmitriz, Orie_, burn, rgrant, jandrieu, kdenhartog, kristina_, pam_dingle 00:02:07 On IRC I see pam, kristina_, JoeAndrieu, kdenhartog, agropper, burn, Orie_, markus_sabadello, rgrant, drummond, Logan_Porter, RRSAgent, Zakim, brent, dmitriz, tzviya, TallTed, 00:02:07 ... dlehn, Travis, hadleybeeman, bigbluehat, jyasskin, agendabot, shigeya, dlongley, manu, juancaballero, damian77, asocrt, msim, cel, cypherhippie, wayne, dietrich, etropea73101, 00:02:07 ... cel[m], rhiaro 00:02:19 present- pam_dingle 00:02:26 present+ pam 00:03:03 zakim, end the meeting 00:03:03 As of this point the attendees have been brent, shigeya, TallTed, Logan_Porter, cel, agropper, drummond, markus_sabadello, dmitriz, Orie_, burn, rgrant, jandrieu, kdenhartog, 00:03:06 ... kristina_, pam_dingle 00:03:06 RRSAgent, please draft minutes 00:03:06 I have made the request to generate https://www.w3.org/2021/11/30-did-minutes.html Zakim 00:03:08 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 00:03:12 Zakim has left #did 00:03:23 rrsagent, please excuse us 00:03:23 I see no action items