Minutes IETF111: asap
minutes-111-asap-00
| Meeting Minutes | Automatic SIP trunking And Peering (asap) WG | |
|---|---|---|
| Title | Minutes IETF111: asap | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2021-08-04 |
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.