IETF 99 MODERN 11:50-13:20 Friday Afternoon session II Athens/Barcelona 5m Administrative, e.g., scribe, etc. - Chairs Note taker: Jean Mahoney Jabber scribe: Paul Hoffman Steve Donovan: Agenda change - Chris' presentation will be presented at the end. --------------------------------------------------------- 20m draft-ietf-modern-problem-framework-02 - Jon Peterson slide 1: Title slide 2: draft-ietf-modern-problem-framework slide 3: Next steps Jon Peterson: The draft has not had adequate review, but we can send it on. I don't see a lot of appetite for this. Steve: Adam asked if we take to RFC or not, IESG has been thinking about whether it should go through. Adam Roach, as AD: does this have archival value? Jon: Terminology. Paul Hoffman: Yes. Steve: Should we do another WGLC? Jon: Changes were minor. Steve: I'll suggest to list that we bypass WGLC. If no push back, send it on. ------------------------------------------------- 15m draft-peterson-modern-teri-03 - Jon Peterson slide 1: Title slide 2: draft-peterson-modern-teri slide 3: TeRI Operations slide 4: The TeRI Interfaces slide 5: Operations and Records Chris Wendt: Are restrictions any different than just narrowing - you have a data record and I only want one object within it - or are there policy implications? Jon: Not policy implications. The records that you return or the records that this request applies to are limited to those that contain this element that I'm restricting the request to. I wouldn't say that it's a policy restriction message. Chris: Programmatically limited - a query with parameters that give me only this. Jon: Yes, only things that match this. Chris: I keep bringing things back to SCRUD and keeping things simple. Jon: I have a scrud slide. I have a scrud. There are sets of records that will apply to most of the requests. Restrictions allow the client a way to reduce the set they're likely to receive, or to receive nothing if there's nothing applicable. What response codes are for when you send a request for something and there are no suitable records - you get back a response code saying I got nothing. there are similar things about unauthorized access to records. There is a success response. The idea is for ENUMish case when a successful response will contain one or more useful records. slide 6: Request example slide 7: TeRI response slide 8: TeRI records slide 9: TeRI Success Response Jon: Does it seem clear? Should we do something different? Chris: A point on admin data - need a security association with who can modify the data. slide 10: Records: Think SCRUD Paul: How do I know where to search? Tree discovery or linkage - I didn't see anything. Jon: ECRIT did this with LOST protocol - lets you find trees. If you only have a TN, how to find? Paul: We need this. This is for search. No I don't - if I have a TN, I don't know who to ask. Jon: there are assumptions about government entities. Paul: No one has heard of NANP. Jon: If you know enough to use the interface, you know enough. Paul: fair enough. Chris: I don't think it will be a tree, it will be relational model. Jon: Not every teri record is propagated to every service. That's an implementation decision. Chris: We can make that explicit. Needs to be extensible. Jon: ADDIs will say that, not IETF. Chris: There are logical roles that have been identified. Jon: Make sure it's extensible. We've identified a core model. I think we're close. Tom McGarry: we cover this in the framework doc with central vs distributed registries. Some may want one another way. Chris: Central vs distributed is independent from data model. The data should be the same and the query should be same. Jon: Yes. slide 11: The Acquisition Operation slide 12: The Management Operation slide 13: The Retrieval Operation slide 14: TeRI for Number Validity slide 15: How requests work slide 16: A response record for a valid block Jon: Should you have a blacklist or list of number aren't allocated? Bernie Hoeneisen: How about saying, I don't know but this guy does? Jon: I don't think we'll make a record that says I don't know. Bernie: It's doing here, but he can say this guy knows. Jon: This is unknown and is unknowable, don't have permission to share the info. (?) Paul: How do you do ranges in request. Not clear. Jon: the R - means range, can use it in the query. slide 17: Open Issue Chris: A number block is allocated or not, and a TN can be allocated or assigned or both. Unknown means you query for it and you get a 400 response. Jon: Unknown means allocated but I can't provide info on assignment. We can redefine that. Chris: Why do we want to separate that? Jon: We can separate it. Unknown is fine for determining DNO, do not originate it. Chis: If it's DNO, and I query for that number, and it doesn't exist in the registry, and I get an error back saying, no nothing, okay, that's if it's assigned or allocated exists. if it's not, then it doesn't exist. Jon: That's about right. Chris: We should define allocated and assigned and those things. If there's a need for unknown we can discuss, but keep the model. Jon: you can keep allocated aside if that's more intuitive. people have no problem with that. This was Tom's suggestion. Paul at mic for Eric Burger: Is there any practical difference between valid but not allocated versus invalid? I'm blocking on numbers not assigned to people. Do I care if a carrier is holding it? Paul: Multiple people are having this question. Jon: I've been assuming realtime assignment info is unavailable. It's unavailable in North America. It's a no-op to do this. If you could give me realtime assignment data, I'd be happy to use it. Chris: We should agree on that. Realtime is fuzzy. Adam: Upleveling - How does this make the problem better? This gets deployed. People move to using allocated numbers. There's blowback. Put analysis in doc. Jon: If we drive people from invalid numbers, they will spoof allocated numbers and it will get worse. But with STIR you can't spoof allocated numbers. Adam: Don't deploy this /until/ stir is deployed. Jim beats?: Back to the days of ENUM - voice operators would do an ENUM lookup - and you need to tell them - there's nothing here, Don't attempt to dump this call to the PSTN. Stop now. Need that a signal like that. Jon: I remember that, and problems with that like ENUM. That's like a blacklist. >>> Jon: I do remember that. Problems with that are very similar to the problems of the rest of - I think that was the blacklist approach - this is something you shouldn't go back to the PSTN list, don't do it if this record is present. I don't want this to work like that. I have to think of every record that needs to be put in means don't do this. Jim: The specific scenario is to avoid provide this had configured the set gate used to do things like, if there's nothing that you can find in the enum or in some other set repository, don't dump it to the PSTN. Chris: From the service provider perspective, in STIR we started with SP certs first. That's more practical to deploy. Then go to the relative realtime thing - not millisecond - what the status of the numbers are. That's a strategic goal. This is a practical use case to get it out there. There will be issues with pushing spam providers into the allocated number space but we already have those problems. This is the first step to control all the numbers and push toward real-time registry where we can be all-knowing. Jon: there's regulatory activity in NA going on right now - people asking how to get these lists of invalid, allocated and unallocated numbers. Tom: This is a great opportunity for Teri use case draft. The allocated vs assigned goes back to the 1990s in NorthAm, and the numbering plan was nearly blown up. The industry wanted to know what were actually assigned. We take inventory 1-2 year. About 50% assigned out of allocated. The robocalling problem - companies would look for recently unassigned numbers for robocalling. Thats where these concepts came up. Allocated vs assigned are diff concepts. Chris: At the end of the day, should be both and realtime. Jon: yes, both allocated and assigned. slide 18: Open Issue (2) Jon: talk about allocation for ranges and assigned applies only to individual numbers. But what the authority is for a record. A carrier has a block of numbers. Chris: It's a child parent relationship. If in the future we have individual numbers. Jon: For a freephone problem you don't have a parent. Chris: It can be a inheritance thing. A number block can have the authority for now. TNs inherit that. If a TN is a singleton it has all the properties. Jon: there can be multiple authorities that are signing records that match the same search. A record for the block, a record for the TN. One from carrier one from enterprise. They can both live in the service. If you only trust the carrier, you get the carrier. That's fundamental. RjS at Mic for Eric Burger: except in a number portability regime, you do not have nice allocations of solid blocks I.e., you don't have a nice hierarchy of 1000-blocks all sitting with a single carrier Jon: that's why I want this separate. Because of number porting. Chris: need well defined object relationship model. start with core concepts. Jon: Because the records have subjects, they are always indexible. You need the search in scrud to have the flexibility. I don't know what we get from it being hierarchical. Chris: The number has a relationship to a block, has a relationship to an authority, has a relationship to a carrier, multiple carriers. We define those 1 to N, 1 to 0 relationships Tom: You would want to know information about a prefix - is it allocated, unallocated. not necessarily allocated to carriers. Jon: I agree that we need an indexing property in the db to know how the records are correlated. The allocated - we'll treat as block level. Assigned is an individual TN. A block is never assigned. Chris: Yes, but we'll have allocated+assigned for individual TNs as well. It's assigned you assuming it's allocated. slide 19: Open Issue (3) slide 20: TeRI Next Steps Jon: Lots of work in other WGs now. We use this to flesh out teri as we go. Do people think this is a good idea. Adam: Would this be merged into teri doc? Jon: I'd keep it separate. I would merge encoding into the teri doc. Steve: Do we turn these into WG drafts? Jon: Think we should adopt it. Eric: given that TERI is still looking for a solid use case and from today's discussion we are still looking for a direction, would it not make more sense to keep it individual until something solid emerges? Jon: Is this not solid? Adam: I heard a solid use case. Chris: This use case from a DNO, the best the industry has is an excel spread sheet. We can do better. Eric: I guess we have use cases, but not at all clear how TERI solve it Jon: This draft is not great, but it shows it. Adam: this shows a useful use case, meets requirements from carriers to fill it. Steve: I'll take it to the list. Jon: Start with getting teri adopted. ------------------------------------------------------- 15m draft-wendt-modern-drip-02 - Chris slide 1: Title slide 2: Overview slide : Where do we go from here? Jon: I think we should do something like this. This goes back to the FCC workshop, alternative approaches to numbering. One experiment used a distributed registry system like this to allow real-time allocations from a mixed number block from carrier. It's been my plan to get us here, which was - what order we should do things in? or what is most used to do first. Need to figure out what how drip and teri relate. When we have some idea of that, we're in good shape to adopt this. Steve: Thoughts concerns? (silence) Who has read? A few. I'll take adoption question to the ML. Bernie: Why are you proposing something besides DNS? Chris: We need something that can adapt teri like objects. Good point something to consider. Bernie: Don't know if it's a good solution, something to consider. Eric: At least the proposal is *not* blockchain. Otherwise, OK Steve: I'll take it to the list. That's it for talks - slot for discussion. ------------------------------------------------------- 15m Discussion [Group felt that everything had been discussed]