* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Modern Status Pages

Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2015-Jul-02 —  

IETF-99 modern minutes

Session 2017-07-21 1150-1320: Athens/Barcelona - Audio stream - modern chatroom


minutes-99-modern-00 minute

          IETF 99 MODERN
          11:50-13:20     Friday Afternoon session II
          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
          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
          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
          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
          15m Discussion
          [Group felt that everything had been discussed]

Generated from PyHt script /wg/modern/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -