Minutes IETF111: asap
minutes-111-asap-00

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.