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

Asap Status Pages

Automatic SIP trunking And Peering (Concluded WG)
Art Area: Francesca Palombini, Murray Kucherawy | 2020-Jul-24 —  
Chairs
 
 


IETF-111 asap minutes


Minutes

minutes-111-asap-00 minutes



          Automatic SIP trunking And Peering (ASAP) Working Group
          =======================================================
          
          CHAIRS:  Jean Mahoney
                   Gonzalo Salgueiro
          
          Automatic SIP trunking And Peering (ASAP) Working Group
          =======================================================
          
          CHAIRS:  Jean Mahoney
                   Gonzalo Salgueiro
          
          IETF 111 AGENDA
          
          Thursday, July 29, 2021
          13:30 - 14:30 US Pacific Time
          Session II, Room 1
          
          IETF 111 Info: https://www.ietf.org/how/meetings/111/
          Meeting URL: https://gce.conf.meetecho.com/conference/?group=asap
          Etherpad: https://codimd.ietf.org/notes-ietf-111-asap
          
          -------------------------------------------------
          
          1. Note Well, Note Takers, Agenda Bashing, Draft status - (Chairs, 10 min)
          
          2. Automatic Peering for SIP Trunks (Kaustubh Inamdar, Sreekanth
          Narayanan, 40 min)
          https://tools.ietf.org/html/draft-ietf-asap-sip-auto-peer
          
          3. Wrapup and Next Steps (Chairs, 10 min)
          -------------------------------------------------
          
          1. Chair Items
          
          ~ Note well
          
          ~ Agenda bash
          
          ~ Gonzalo Salgueiro to act as Jabber scribe
          
          ~ Thanks to Marc Petit-Huguenin and Kaustubh Inamdar for taking notes
          
          ~ Draft status
          
          
          2. Automatic Peering for SIP Trunks (draft-ietf-asap-sip-auto-peer)
          
          ~ Draft authors provided overview, status and version history of
          current draft
          
                  ⁃     Sreekanth Narayanan provided overview of the changes
                  made in the latest version of the draft and put forth open items
                  (https://datatracker.ietf.org/doc/draft-ietf-asap-sip-auto-peer/)
                  ⁃     Jon Peterson: Good to see the STIR stuff included in the
                  draft. Lot of discussion around provisioning systems that are
                  related to STIR. There is  interest in pre-provisioning systems
                  to sign and attest numbers in a certain way. There are a bunch
                  of things with regards to provisioning that can be discussed on
                  the list and added into the draft. Definitely interested to see
                  more standardization around pre-provisioning.
                  ⁃     Sreekanth Narayanan: we can surely have a discussion on
                  the list.
                  ⁃     Jonathan: Happy to see things added into the draft about
                  STIR. Comments on things that aren’t in the draft - firstly,
                  there is a flag called STIRCompliance which is a Boolean. This is
                  a tautology as the all service providers in the United States are
                  required to be STIR complaint as of June 30th 2021. To me the more
                  interesting thing is how PASSporTs are handled in and out. For
                  example, when calls are sent from contact centre providers to
                  carriers, will the carriers accept the PASSporT inserted by
                  the contact centre provider and pass them through. Also, would
                  they verify if the numbers are part of the range that has been
                  allocated. These are certain aspects that need to be manually
                  probed as of today. Would be nice to see some bits within the
                  draft that captures this information. I’m less optimistic about
                  getting certificates using the fields in the draft - therefore
                  the cert delegation fields within the draft are less useful to me.
                  ⁃     Jon Peterson: ACME for enterprises is still largely
                  aspirational. There is so much administrative stuff around
                  ordering a number range, if part of that could be added into
                  the draft, it perhaps could be useful. However parts of that
                  would still remain out of band. Having a way to track that
                  enterprise and service providers  have a mutual understanding
                  of what numbers have been allocated would be useful. I would
                  like to see a world where number allocation is dynamic, but I
                  don’t think we will get there in the foreseeable future.
                  ⁃     Jonathan Rosenberg: Law doesn’t mandate all
                  behaviors. It would be useful to encode the variabilities for
                  both ingress and egress STIR in the draft.
                  ⁃     Chris Wendt: Agree with what Jon Peterson said. Interested
                  in the certificate delegation piece of the draft. Question is
                  about trunking v/s peering v/s shaken as a service. See a lot of
                  variation between those things. Is this document focused on one
                  of those or more? Is the intent to cover all of those things,
                  or a small scope? There will be a need for a lot of those things
                  going forward.
                  ⁃     Cullen Jennings: Agree that this isn’t a great mechanism
                  to order numbers from service providers. There is value in the
                  service provider reporting back to the enterprise that this is
                  number range allocated.
                  ⁃     Kaustubh Inamdar: Two points - scope of work at
                  this time to get what the service provider likes/doesn’t
                  like, supports/doesn’t support and use that information to
                  bring up the SIP trunk. We can certainly discuss if some of
                  the as a service paradigms could be added into scope. Also,
                  there is a field within the capability set wherein the service
                  provider reports that exact number block/range allocated to the
                  enterprise. That would serve a viable mechanism for the enterprise
                  to use the appropriate identity when sending calls outbound.
                  ⁃     Chris Wendt: I guess my concern is that there isn’t a
                  ton of overlap. Probably could have different specs to address
                  those.
                  ⁃     Gonzalo Salgueiro: Wanted to follow up with Jonathan on
                  something that was discussed in the last meeting about conflicts
                  that needed to be resolved between this draft and his draft on
                  SIP High Availability.
                  ⁃     Jonathan Rosenberg: Have not looked at it yet, will do so.
                  ⁃     Kaustubh Inamdar: Ask the group their thoughts on open
                  items - Need to register a new link relation type and whether
                  the group favours XML over JSON or vice versa.
                  ⁃     Jean Mahoney: Some of the questions have been outstanding
                  for a while. XML v/s JSON.
                  ⁃     Jonathan Rosenberg: Flip a coin or support both. JSON! I
                  vote for JSON, can we close the open issue? Just pick something.
                  ⁃     Cullen Jennings: Please don’t pick two things, pick
                  one. I second Jonathan’s proposal of using JSON or any other
                  proposal - but just pick one format.
          
          ~ Show of hands for JSON as the encoding format. Group favors JSON.
          
                  ⁃     Gonzalo Salgueiro: Kaustubh & Sreekanth, what is it
                  exactly about WebFinger that you’ll want final decisions on?
                  ⁃     Kaustubh Inamdar: To make this as much of an automated
                  solution as possible, WebFinger is useful. In the context of ASAP,
                  for WebFinger to be truly effective, we cannot have a WebFinger
                  query that returns a ton of objects in the Links Array as most of
                  them aren’t relevant to ASAP. To make WebFinger more streamlined
                  for ASAP, it makes sense to define a new link relation type. It
                  could be called “capabilitySet” or anything else. The name
                  of the link relation isn’t important. Looking for decision
                  on whether is makes sense to register a new link relation type
                  in IANA.
                  ⁃     Gonzalo Salgueiro: We can do a show of hands for decision
                  on registering a new link relation type for WebFinger.
          
          ~ Show of hands for registering a new link relation type for ASAP. 5
          weighed in, all 5 are in favor.
          
                  ⁃     Jean Mahoney: Is there anything else that we should
                  throw to a show of hands?
                  ⁃     Jonathan Rosenberg: Not sure, whether this should be
                  thrown to a show of hands, but if this is the mechanism used
                  by service providers to report the number range allocated to
                  an enterprise, it dramatically changes the security properties
                  of the framework. Minus the number range, other fields, one
                  can argue, doesn’t require authentication. However, a number
                  range is sensitive information. The document waives its hand
                  on authentication. You probably should say more than “out
                  of scope” in the draft. My question is whether we need to
                  specify an authentication mechanism to get an interoperable
                  solution? Or leave it vague? Or remove anything from the draft
                  that is considered sensitive information?
                  ⁃     Cullen Jennings: I favor simplicity over anything
                  else. If adding an explicit authentication mechanism makes this
                  more complicated, I would favor simplicity. While I can easily
                  live with either, I favor simplicity.
                  ⁃     Kaustubh Inamdar: I agree with Cullen. The purpose of
                  this effort was to make SIP trunk configuration simple. However,
                  to ensure that this framework is relevant for some time to
                  come, it probably makes sense to add text around an explicit
                  authentication mechanism so that number ranges can be reported
                  by service providers.
                  ⁃     Jonathan Rosenberg: I would not leave it vague or suggest
                  that we use Digest. We can probably use OAuth, which shouldn’t
                  be difficult to specify, however, we don’t know if vendors
                  would be willing to implement. It could a barrier.
                  ⁃     Sreekanth Narayanan: We did have OAuth in an earlier
                  version of the draft. But was removed, because we thought it might
                  be complicated to implement. We need to make a decision on this
                  and weigh whether we need to specify an authentication mechanism
                  to be able to include sensitive data or favour implementation
                  simplicity.
                  ⁃     Jean Mahoney: The authentication decision perhaps needs
                  more discussion on the mailer as opposed to settling it now via
                  a show of hands.
          
          ~ Wrap-Up and Next Steps:
          
                  ⁃     Confirm on the list about the use of JSON and the need
                  to register a new WebFinger link relation type.
          
          



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