draft-ietf-modern-problem-framework Jon Peterson - New minor revision, reflecting NIT reviews - Author thinks ready for WGLC - Only feedback since adoption has been NITs - Comment from Pierce on-list indicating that "we still don't get it." Richard Shockey: You've heard my objections to the problem statement, and ÊÊ consistently ignored them. I'm going to try to keep my mouth closed as long ÊÊ as possible. Jon: I understand that anything meeting the charter will be found objectionable. ÊÊ We have not ignored you. Richard: I think you and the ADs have consistently ignored me. I think the ÊÊ charter and problem statement does not address a real problem. Jon: We can go back and plumb the history of the workshop; the goal was ÊÊ to examine tools for a post-IP-transition world experimentally. Richard: I have no objection to you all to continue to play in that sandbox, ÊÊ but the public record needs to reflect that several of us have serious ÊÊ objections. Jon: I think, with your help, we should be able to address the issues that you ÊÊ have with the design. Richard: A generic framework for dealing with generic telephone network ÊÊ metadata would be useful. This does not need to be a replacement for ENUM. ÊÊ A generalized protocol for dealing with telephone metadata would be useful, ÊÊ and that's what this working group should have been chartered to do. But ÊÊ my comments were ignored by the ADs. Alissa: Your comments were not ignored. We had an extended debate about ÊÊ the scope of the WG charter. The metric for chartering a WG is whether ÊÊ there is enough interest in doing work in the IETF, not in determining ÊÊ whether there is consensus. Within the bound of the existing MODERN charter, ÊÊ is there any document that you would not object to? Richard: I think the charter is too narrow, and I think my statements ÊÊ on the topic have been ignored. That degrades the ability of the WG ÊÊ to progress something useful. Alissa: So is that a no? Richard: If people want to do work, fine. If you want to play in your sandbox ÊÊ and not do anything useful... you want to deal with issuing phone numbers, ÊÊ fine. But I don't see national regulators in this room. So the way this has ÊÊ been scoped severely damages its applicability. Alissa: So, there's no work that can be done in this charter that you would ÊÊ find agreeable. Richard: I'm trying to be reasonable. I have no fundamental objection to the ÊÊ current charter work going forward as stated. But the usefulness of this work ÊÊ is damaged beyond repair because it addresses a very limited problem statement ÊÊ rather than dealing with phone number metadata. There is enough limited ÊÊ hope that a framework for this class of protocol can be useful in a broader ÊÊ context. But since the charter never addressed the true scope of what we're ÊÊ dealing with, the charter prevents us from doing something useful. I'm on ÊÊ the NANC, so while I'm not representing the FCC, I am part of the committee ÊÊ that recommends to the FCC how phone numbers are issued. How the phone number ÊÊ is issued is minor compared to metadata, distribution, circulation, and a ÊÊ host of other issues. Alissa: That was helpful. I got the information I needed. Jon: Let's move on to TeRI. --------------------------------------------------------------------------- draft-peterson-modern-teri - Introduction to purpose of TeRI [see slides, draft] - Added role of registrars to the document in this version, ÊÊ separable from CSP Jon: To be clear, the acquisition operation here includes ÊÊ practical operations that exist today, like getting numbers from ÊÊ your PBX, registering toll free numbers, and getting your Google ÊÊ voice number. These are things that fall outside the purview of ÊÊ national regulations regarding number assignment. Richard: You're delving into what I think is... you're wading into ÊÊ policy, which is determined by regulatory authorities. The actors ÊÊ here... you're postulating policies that impinge upon the ÊÊ authority that regulators ultimately have. I was hoping you ÊÊ would come up with a generic metadata approach that would finally ÊÊ kill the ENUM beast. I have no problem that a third-party service ÊÊ provider can use this under the broader permission of a regulator ÊÊ but the work is scoped too narrowly. Jon: Surely you agree that PBXes assigning numbers to phones is ÊÊ not of interest to regulators. Richard: That is a highly secondary use case. [Call for interested parties to assist in definition of the format, including a facetious offer to close the WG, and an enthusiastic response from Richard] Bobby Flaim: For civil & LE agencies, we already have a problem with process. ÊÊ With this system, who do we go to? Jon: The registrar. With traditional phone networks, this is the ÊÊ same entity as today. Bobby: Our worry is that, with this model, there's a lot of redirection, ÊÊ making a "chain of custody" difficult for phone numbers. Bobby: Who accredited the registrar? Jon: Typically, we accredit the registry, which is accredited by ÊÊ the national regulatory bodies. Richard: Typically, you need to find the carrier of record, and ÊÊ then contact them to find out who has a phone number. The problem ÊÊ in North America is that phone numbers have been delegated a lot, ÊÊ and have not had much policing. So the problem is that you may ÊÊ have gone through tertiary elements for assignment of numbers, ÊÊ which complicates things. So if we were discussing better metadata ÊÊ to assist LE in catching the bad guys, we would all be happy. ÊÊ If we were talking about that instead of other use cases, ÊÊ it would be much more helpful. Eric Burger [remote]: What is ensuring that the registrar knows the ÊÊ delegation? Jon: The framework distinguishes between assignee and delegate: the ÊÊ registrar is responsible for the assignee. The delegates are ÊÊ responsible to update the registrar. That's a policy, and we ÊÊ aren't defining policy; however, we accommodate a variety of ÊÊ policies with the technology. It's up to the regulators to define ÊÊ these policies. Brian Rosen: There's more than one step in a delegation chain. ÊÊ These chains are represent-able in the structures we define ÊÊ (e.g., numbering authority to a phone company to a reseller ÊÊ to an individual). I think we might need to spend some more ÊÊ work in TeRI to support this. Jon: Multiple authorities can publish records that overlap. ÊÊ That's how the model supports what you propose. Brian: An example would help. Jon: Sure, but we don't want to be prescriptive. Chairs: This sounds like an excellent discussion for the list. --------------------------------------------------------------------------- draft-wendt-modern-drip-01 Chris Wendt [see slides and draft for overview] Eric Burger: I just had a stupid, crazy idea. Would anyone be interested ÊÊ in a blockchain implementation of this? It get yous verifiablity, ÊÊ traceability, other stuff. Chris: Yes, we've thought about that. Is that complexity necessary? ÊÊ I'm not a blockchain expert, so I can't really comment, but it's ÊÊ probably worth evaluating. Eric: I'd be happy to work on it, but only if there's interest Cullen: I'm interested, in that I've thought about it. It's certainly ÊÊ more complicated, but I can't come up with something that makes it ÊÊ better than the existing approach. So we'd need to have a concrete ÊÊ benefit in mind before we did the work. Tom McGarry: We think of the registrar and registry as separate. In ÊÊ this model, can the be combined? Chris: In this model, the registry [missed the point, ultimate conclusion ÊÊ seemed to be that combination could be possible] Jon: I think of the registry function as managing the uniqueness of the ÊÊ namespace. So registries necessarily have a scope of authority. ÊÊ Registrars do not. So there are models where registries act as ÊÊ registrars, and I can imagine some PTTs where that's true. We don't ÊÊ rule that model out. I would love to do something in our next pass ÊÊ at this document additional text that covers drip server resource ÊÊ allocation issues. --------------------------------------------------------------------------- Open Mic Chairs: The list is a very lonely place. With TeRI, there's enough meat that ÊÊ we hopefully can get started. On problem statement, I agree that it's ÊÊ getting close to WGLC, but we need more expression of support on-list Area Director: It would be worthwhile to issue a WGLC at this time. Chairs: Any objections to WGLC? [none registered] Chairs: On TeRI, there's obvious additional work. Maybe we can take it on ÊÊ as a document in Seoul. Jon: I think I'd like to have something more concrete first. Chris: In terms of ownership versus routing, do we have anything about that? Jon: Boy do we ever. But we need to tread carefully so that we can ÊÊ accommodate areas that handle things differently. Can you be more ÊÊ specific in what you would like to see? Richard: Can you bury the name "ENUM" for the rest of time? Jon: Sure. [More discussion on working group charter.] Martin Dolly: We will need an authority to push the work before ÊÊ people understand what's going on. Chris: Should we wait for the chicken or the egg? The data model ÊÊ supports all kinds of use cases. Once the tools exist, the push ÊÊ may well follow. Jon [to Richard]: I have time to work together with you on this. If ÊÊ you have use cases that aren't supported here, let's sit down ÊÊ and figure it out. Richard: The problem I have is that the way the IETF is proceeding lacks ÊÊ specificity and a lack of use cases, which prevents people from getting ÊÊ involved, and prevents people from implementing. The NNI use cases are ÊÊ clear and demonstrable. Rather than a mailing list that no one uses, ÊÊ rather than a mailing list with carriers on it... AD: If people want to do work, write a draft. Jon: The aim is that we would need a new deliverable for the WG AD: No, just do an individual draft. Show some interest. Jon: If no one wants it, I'm not wasting time. I need to see some interest ÊÊ before I do this. Chairs: Take it to the list