IETF 97 MODERN 9:30-11:00 Studio 4, Conrad Seoul ----------------------------------------------------------------- 5m Administrative, e.g., scribe, etc. Presenters: Steve Donovan Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-modern-chair-slides-00.ppt Note taker: Jean Mahoney Jabber scribe: Jean Mahoney slide 1: Title slide 2: Note Well slide 3: Agenda No changes slide 4: Working group milestones ----------------------------------------------------------------- 10m draft-modern-problem-framework-01 Presenter: Steve Donovan Framework draft had no comments in WGLC call. STIR has taken all the oxygen out of the room.In order to advance the draft, need more review. Need to show interest and review effort. Adam, Henning, Mary volunteered to review the draft. ACTION: Adam Roach, Henning Schulzrinne, and Mary Barnes to review draft-ietf-modern-problem-framework by Dec 9th. ----------------------------------------------------------------- 30m draft-wendt-modern-identity-registry-00 Presenter: Chris Wendt Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-modern-draft-wendt-modern-identity-registry-00-00.pdf slide 1: Title Chris - This is a brain dump on something we've been working on internally. Compatible with modern and TeRI. Goal is to talk through commonality. slide 2: Overview We have an implementation that's worked with the DRiP stuff. We explicitly associate service and we have a model with multiple identity associations and and separate routing identifiers. slide 3: Actors in this model Main actor is the provider. A provider can offer multiple services. Public identity is a phone number, could be extended to email addresses. Routing identity would be a URI kind of thing, a globally routable identity. Henning - what's an example of service identity? Chris - VOIP as as service. Think of it as a application. Henning - it's not a user describing a service itself. Jon - you say it's globally unique. Chris - unique in the scope of the provider. Could be globally unique - like VOIP. We use a qualified domain convention, like Voip.comcast.com. Henning - SMS provider and a different voice provider. Have two records. I don't care who provides the voice, but care if I want to route to it. OTT apps with realtime text and then classical IMS, legacy voice, and would need to route separately, different providers. It makes a big difference if there's a hierarchy implied. Chris - the intent is that I know I want to contact Henning at 215.555.1212 for realtime text. I look in the registry. I do a query for realtime text for 215.555.1212, I get a globally unique id that goes to the provider. Henning - that's what I was hoping for. Jon - that's in keeping with modern framework and TeRI. slide 4: Relationship diagram Adam - that makes more sense than what's in the doc. I like arrows. Chris - I can try to incorporate arrows in the text thing. slide 5: Registry API functions Chris - Distributed registry - details of the user subscriber should be private to the provider. We expose a restful interface to the distributed registry in gets and puts. We would map those into the implementation of the registry in the case of DRiP. slide 6: Messaging and Control Flows Chris - Most queries would be for public id and service, would identify which routing id would used to route. Allocation must be unique. Need to assure no race conditions on allocating numbers. Covered in the DRiP draft. slide 7: Example Allocation/Assignment Chris - the domain in the routingID's domain would represent both the provider and the service. Jon - the degree to which the routingID should encode in the domain what the service is. Is SIP a service? What is the service does it provide? SIP is a rendezvous service that allows endpoints to negotiate capabilities. What goes into the routing infrastructure that lets you find the SIP endpoint vs what the 2 end points should negotiate. We need a service id. The routing id I'm looking for is the one for VOIP. Is it a problem if it also worked for video. Chris - No and it's the definition of what the service id represents. If something routes into my network, if it's VOIP I might want to send it here, if it's RTT send it there. SIP is a generic signaling protocol, you're qualifying what the id represents with what's being offered within SIP infrastructure. Jon - as we look at aligning this with TeRI, I'd argue that there will be other ways to show routing usage. Encoding in the domain is very specific, implementation specific. Chris - It's how we did this, but we welcome feedback. Jon - advantages to having separate ways to signaling this. Dave Crocker - this appears to be in the realm of source routing instead of moving routing to realtime query at execution. You take the target that you want and using it at execution time rather than embedding it in the request. Why are you taking the embedded approach, if IIUC. With email once upon a time you could embed a source route in an address. It doesn't scale well. Currently you say where you want to go, and the underlying infrastructure figures it out. This appears to be more like source routing. Chris - it could be flexible. The intent is to make it straight forward. Henning - here the problem is a single identifier (TN) and multiple services administered by district bodies. Could be overlap - service offers Messaging, Video and voice. And a service that only offers messaging, which could be proprietary. You could do late binding, and see if it supports anything that you care about, and you try until you find something. Or provide a hint about what services you want. As long as both models are supported, it's more service selection than source routing. The problem will be, for services, for routing ids for multiple services - voice and video - would there be two entries or a multi-value service id. That changes lookups, DB structure, how to ask for all at the same time. Chris - Have a use case of SIP volte and legacy entering the network at the same place and then have internal routing. Support both models and let the carriers can decide how to treat ids. We can do that explicitly or implicitly with internal routing logic. We have a use case where we offer voice and messaging, have an umbrella service used as id. Crocker - multiple service is what prompted going from MX to SRV records to register for different services. Jon - in the TeRI models we have explicit source routing. For this query tell me what the route should be if this is the source of the traffic. That's a meaningful for service provider in a single network, that the route source is inside it and have to exit at particular gateways, which is different than being out on the big Internet. That needs to be part of the model. slide 8: Update Entry/Port slide 9: Removal/de-allocation ----------------------------------------------------------------- 30m draft-peterson-modern-teri-json-00 Presenter: Jon Peterson Draft: https://datatracker.ietf.org/doc/draft-peterson-modern-teri/ Presentation: https://www.ietf.org/proceedings/97/slides/slides-97-modern-draft-peterson-modern-teri-json-00-00.pptx slide 1: Title Jon - This is really great. We have needed this in MODERN. We've been having an abstract discussion about the principles needed to address the enum problem in a more ... way. Try to figure out rich query semantics to express questions about numbering resources. Let you create records related to these numbering resources in a SCRUD ecosystem, you can update them, delete them, etc. slide 2: draft-peterson-modern-teri Jon - As we've looked to extend ENUM, haven't looked at the records moving atomically though the life cycle. You need concrete examples, data elements - Chris's presentation is a good example. TeRI model should be able to do this. This should be straightforward to extend to accommodate it. Based on Chris's draft, I can see ways of updating it. next step - what would it look like to take Chris's model and create a TeRI binding. I wanted to show a data format. Trying to put TeRI into JSON. slide 3: TeRI Operations Jon - Retrieval is the ENUM problem. slide 4: The TeRI interfaces Jon - This should look similar to Chris' picture. Service provider could fulfill any of these roles. These are logical roles based on a DNS-like model, there's registries and registrars. Distributed registration - would not be service provider in a DRiP like case. At layer of indirection. Chris - What's the difference between distributed and not distributed? Jon - move out the intelligence that people query into a DHT. You remain the authority. But what is queried may not be your service. It would live out in this cloud. You would generate the records and sign them, and then they would go out into this DRiP cloud. Chris - A federated service. Jon - or even more radically distributed than federated. You can take these DHT approaches to a logical extreme, very decoupled. Alissa - would the acquisition flow also go through this federated, distributed service? And how does that relate to the authority's authority over acquiring? Jon - Sure. DRIP is based on the notion. There's some number ranges ceded to this distributed system. If you are a member of the system, you can use the interface to delete resources and release them to this. The acquisition process in Teri gives you the authority to provision records. Alissa - is there not a model where that would look beneficial for retrieval but not for acquisition? Do they have to be coupled? Jon - agree there is. You want the acquisition to be distributed. You can do the retrieval in a distributed way and acquisition is central. Henning - Would be beneficial to distinguish two kinds of distribution: physical distribution - blockchain or DHT. A cloud of independently resourced entities, but they all provide the same info. The DHT identifiers are split ... DHT identifier ranges. there's not one server that holds AT&T's records. Another model that's federated - there's an admin division between logical entities that can be distributed. Logically I can go to any node and ask for that mapping. In one case, it does it all for you - blockchain or DHT. 2nd point - it would be helpful to think about who can associate data with a record other than the original provisioner, as subscriber would like to attach a Better Business Bureau certificate to something. Need to run a 2 layer database because we have a telecom SP and a relay SP. It works but complex, makes porting harder. If you can associate different ids that may be opaque to the entity, but someone can have parts of DB record that I can add info to that, that is irrelevant to the provider, it makes adding functionality to DBs simpler. Jon - TeRI does has the concept of multiple authority for same number. Chris - DRIP and distributed systems in general - you want as a consumer of data and the initiator of data going into the system, you want a complete view of the system. I want read access on the Canadian registry and an up to date copy. The idea of replication and distribution is a necessary condition when you are reading and writing data. slide 5: Operations and Records slide 6: Request example slide 7: TeRI response slide 8: TeRI records slide 9: TeRI Success Response slide 10: Records: Think SCRUD slide 11: The Acquisition Operation slide 12: The Management Operation slide 13: The Retrieval Operation slide 14: Chris's Model Jon - We don't have an allocation timestamp. That would be a useful feature. We don't have a direct mapping to service routing. I'm trying to tease out Chris's requirements. Chris - partially, just the peer routing itself. You're talking about service incorporated into the routing id. Jon - (go back to the success response slide) The URI would have attribute associated with it. The authority would be Comcast. Is there some need for UUID for the service beyond VOIP? Chris - no, you can use that directly. I wasn't advocating for a UUID. Jon - I thought I saw a globally id for the service. Chris - from a routing point of view, says more explicitly where you want to go. Can use for logging purposes. For our routing ids, we use UUID for the user part to avoid leaking PPI. For the domain part of routing id, nice to have explicit domain and service association so you know where it's going to. If I want to send a VOIP call to 215.555.1212 I need that info to get globally unique routing address or URI, just include it in the URI that will actually route it. [back to Chris slide] Jon - I think we can converge on this. It's ultimately the authority of the signer and whether you trust him. I want the allocation timestamp. The operations in TERI allows porting and other phone number operations. Chris - as long is there a way to route, it can be anything. If you just use the domain, it provides less info. Or you can incorporate in the user part. Jon - we're just talking syntax. You can have multiple attributes associated with it. This address supports voip/video/sms. If you encode it in the domain name, how do you include all of that? voip.sms.video.comcast.net? Chris - how do you show it? Jon - Go back to request example slide. Service are arrays, you can associate multiple services with the telephone number. If we encode services into domain names it gets gnarly. Chris - In our case it would be separate records. what does the mapping from sms to the record... Jon - It's a discriminator of records. I'm not interested in services that are not sms. Henning - What are the primary keys? What kind of queries do you support? Exact match? Boolean? Wildcard? We've had trouble with ENUM because it's kludgy and its query model is very limited. Difficult outside of a single domain. Think about this differently - the primary key is based on three things - global id, service id, and a 3rd randomly assigned thing that you normally don't query for but allows for multiple entities. Relay service example - the provider is a carrier, 2nd entry the video provider is such-and-such, not related to the carrier, can attach a business record for the same service. Not hard to do. What changes with federated model? How to do wildcarding or complex queries? DHT doesn't work well for SQL-like queries, but works fine for replication. Alex - I can share horror stories of DRINKS. struggles - querying for range, weird collections, number lengths. You need to decide whether it's exact number, or supporting several types of queries for several collections of public identities. Jon - I want a search function. It would be SQL like. It would perform some hamster wheel function in the back and provide a response. Different from queries for records. We're still sketching it. Search would be different from the record fetch. Alex - remember weird European way of routing numbers. Hop-by-hop routing. Service provider routes to block owner, who is obligated to forward it. Jon - what's the job of SIP versus this lookup function. I can imagine delegative approaches. You go to one source and are given a pointer to another, where you get the number. TeRI model is agnostic to those architectural questions. You can't do that with DNS model. Alex - the model would allow for "hamster wheeling" on both client and provider side. Adam - if they are provisioned in ranges, and the signature occurs at provisioning time. If I asked for ranges, I would get the range and other stuff, then as client I would have to winnow it down. Jon - yes. Henning - given the DNS experience, you get all the complexity but not the generality. I recognize that some implementations won't be able to do the queries you want, that's ok. We're building a noSQL or SQL DB, more likely a hybrid between the two. It can add attributes that, that doesn't require schema transformation or rebuilding. A question to answer is the permission structure. Write and read access. Want to charge for access, don't want people to copy my data. I can retrieve a record that's mine, but I as a consumer can't query for every 212 area code record. Can't rely on just encryption and keying materials. Jon - I think you're right. I've been handwaving that Services themselves would have some responsibility of that. IPPNI is a closed network. DRiP is open, anyone can query and get a route. The kinds of services that you expose can be either informative or opaque depending on prefs of record creator. The acquisition interface and managing interface needs a permissioning system. Chris - To address number block issues - the restful interface the nouns and verbs are specific in terms of functionality. We would need that. For henning's concern - the objects underneath can be extensible, with security associations. We shouldn't worry about adding new nouns and verbs for each function. Dave - I'm confused about a core point - there's this difference between query service under one admin control versus multiple. Is the target for a single admin of the query service? Jon - Authorities generate the records. The services are intermediary. dave - if you meant that there's a single admin entity. Jon - I don't. Dave - How many are admin the content. Jon - that's authorities. Dave - I meant running the query service itself? A single entity? Jon - it can be distributed, federated. Dave - and the operational examples? Jon - I can point you to examples. IPNI is federated. We want architectural commonality into a set of familiar services. Henning - It's useful between 2 kinds of operations models - untrusted model like federated x500. And the other tbwidespaces in the US, operate admin-independent, consistent databases, but they trust each other. In the TN space, we'll see a legal trust model, not a technical trust model - You get to be part of a club. Chris - on the ops side, in the cloud and container world - there's many services, you're managing 100k containers, going up and down, they have to communicate across the world, they have distributed registries, works very well. Go back to the record - I'm still reconciling the service thing. The big difference between our ideas - whether or not an ID like your example sip:alice@example.com, should that represent multiple services as an ID. In my model, that's the id owned by provider or user, and how I reference myself vs how I route the calls. Jon - We always come up against how much info do we want to give the registration services about the services. Think of it as a multi stage transaction system. You could do another TeRI query to go from example.com to VOIP.example.com. Chris - You might have local routing tables - we map things to SBC destinations and peering agreements. We don't do VOIP routing directly, doesn't mean we can't use it. Jon - this isn't what the service provider world looks like today. This is an exploratory effort. Chris - I want something can support both models. Jon - I think we can get that. I can encode URIs that you have in your examples. SIP is a rendezvous protocol that does capability negotiation. If you have a VOIP URI, are we not negotiating video? Is this the only thing that's negotiated? Chris - SPs can do their own internal mapping? Jon - Yes Chris - There's some flexibility, but the model has to allow that. slide 15: TeRI Next Steps Jon - we're close. We can talk about this and consolidate, flesh out the restful API. ----------------------------------------------------------------- 15m Discussion Alissa - Can we set a deadline for problem-framework feedback? Steve - 3 weeks - Dec 9th.