Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

Hi Martin,

Sorry for the delayed revert…

The capability set ought to be populated by the carrier/ITSP that handles and terminates trunk REGISTRATION. If that that happens to be an intermediary carrier, values that are local to the intermediary carrier such as the transport, registrar, callControl, OutboundProxy etc. may be populated without any challenges. Values that are dynamic, such as the set of audio media formats, faxing method etc. may be populated conservatively or via prior inter-carrier agreement. Perhaps carriers too could use something similar to the construct outlined in this draft to discover peer capabilities? The SBCs in the intermediary perhaps already take care of any mismatches in the signalling and media planes between the intermediary and end provider.

Thanks,
Kaustubh

From: "DOLLY, MARTIN C" <md3135@att.com>
Date: Thursday, 19 September 2019 at 5:12 PM
To: Kaustubh Inamdar <kinamdar@cisco.com>, Richard Barnes <rlb@ipv.sx>
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: RE: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

And what if there is an intermediate (transit) carrier between them?

From: Kaustubh Inamdar (kinamdar) <kinamdar@cisco.com>
Sent: Wednesday, September 18, 2019 9:08 PM
To: DOLLY, MARTIN C <md3135@att.com>; Richard Barnes <rlb@ipv.sx>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

Hi Martin,

This draft aims to enable an enterprise to discover the SIP service provider capability set. Both of these efforts are geared towards making calls work between enterprise and service provider networks, and as such are complementary.

Thanks,

Kaustubh

From: "DOLLY, MARTIN C" <md3135@att.com<mailto:md3135@att.com>>
Date: Tuesday, 17 September 2019 at 10:05 PM
To: Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>>
Cc: Kaustubh Inamdar <kinamdar@cisco.com<mailto:kinamdar@cisco.com>>, "dispatch@ietf.org<mailto:dispatch@ietf.org>" <dispatch@ietf.org<mailto:dispatch@ietf.org>>
Subject: Re: [dispatch] FW: New Version Notification for draft-kinamdar-dispatch-sip-auto-peer-00.txt

How does this fit with SIP CONNECT?

Martin C. Dolly
Lead Member of Technical Staff
Government & Services Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: md3135@att.com<mailto:md3135@att.com>

On Sep 17, 2019, at 11:38 AM, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:
I gave this draft a quick skim, and it seems sensible..  I'm not an expert in the configuration / setup of SIP trunks, but I do love automating manual processes (cf. ACME), and this draft seems like a plausible approach to automating things about SIP trunk configuration that are currently manual.

Couple of things that jumped out to me on a quick skim, in no particular order:

1. It would be good to have a tighter requirement for HTTPS in here..  For example, on the one hand, you have "it is required to secure HTTP using Transport Layer Security", but on the other hand, "MUST support the use of the https uri scheme" (not MUST use).  There is no reason to support unencrypted HTTP.  You can probably borrow some language from RFC 8555 https://tools.ietf.org/html/rfc8555#section-6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8555-23section-2D6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=XpLJRHudftgf9TYF395MAR923aZyfVyPb3j2gK8qDZ4&e=>

2. "Capability set documents MUST be formatted in XML or JSON" -- Why do you need both?

3. OAuth2 seems like overkill for this application.  OAuth2 is designed for a 3-party flow where authorization is being delegated; there are only two entities here.  It would be much simpler to just use some point-to-point authentication technique, such as TLS client certificates or even HTTP/SIP Digest authentication.

4. The WebFinger utilization here also seems like overkill.  Once you take out the OAuth2, you're just discovering a single URL -- at which point you might as well configure that directly!  In general, this document needs to specify (1) what configuration the client is presumed to start out with, and (2) how that information is used to auto-configure the trunk.  Cf. in ACME, "Each function is listed in a directory along with its corresponding URL, so clients only need to be configured with the directory URL."  It seems like all you really need here is a capability server URL and a certificate / password.

5. The relation types defined using "https://sipserviceprovider/<https://urldefense.proofpoint.com/v2/url?u=https-3A__sipserviceprovider_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=Nh0orXmFGB5EP87BbYzaB8LyrcQTu6_dDxUhpmpjSPA&e=>" need to be changed to something else.  While that's syntactically a URL, it isn't actually.  If you need a URI that isn't dereferenceable, please provide some URNs here.

--RLB

On Mon, Sep 16, 2019 at 9:31 PM Kaustubh Inamdar (kinamdar) <kinamdar@cisco.com<mailto:kinamdar@cisco.com>> wrote:
Hi All,
The following draft has been posted to dispatch. The draft aims to simplify peering between enterprise and service provider SIP networks. Discussions/comments are welcome.

-Kaustubh

    A new version of I-D, draft-kinamdar-dispatch-sip-auto-peer-00.txt
    has been successfully submitted by Cullen Jennings and posted to the
    IETF repository.

    Name:               draft-kinamdar-dispatch-sip-auto-peer
    Revision:   00
    Title:              Automatic Peering for SIP Trunks
    Document date:      2019-09-10
    Group:              Individual Submission
    Pages:              35
    URL:            https://www.ietf.org/internet-drafts/draft-kinamdar-dispatch-sip-auto-peer-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer-2D00.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=Q2zoz-rVzYoAPa1kAMOGqftJUWccXmkX8DAjNHO9MJQ&e=>
    Status:         https://datatracker.ietf.org/doc/draft-kinamdar-dispatch-sip-auto-peer/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=fcIx3co5agjP22REJR49X4c1pZoZgJEkbg3jjwt8eL0&e=>
    Htmlized:       https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=Tuzvwn9LD2APXpkJVHbzlTI7iXO3efPuikuGMp7Zabg&e=>
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-kinamdar-dispatch-sip-auto-peer<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dkinamdar-2Ddispatch-2Dsip-2Dauto-2Dpeer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=JGyQBNt1jPbfCcoLY9whz90UF1FEstsr-O3Cre3qCBQ&e=>

    Abstract:
       This draft specifies a configuration workflow to enable enterprise
       Session Initiation Protocol (SIP) networks to solicit the capability
       set of a SIP service provider network.  The capability set can
       subsequently be used to configure features and services on the
       enterprise edge element, such as a Session Border Controller (SBC),
       to ensure smooth peering between enterprise and service provider
       networks.

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=hxxdnH1hOeFSij1s6a3ZjWpMO8A18PTrzUiyAbfVP0M&e=>.

    The IETF Secretariat

_______________________________________________
dispatch mailing list
dispatch@ietf.org<mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dispatch&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=zAFTXA1XJJYHFhi3WKkswkBsybSNo3bLJ3G0nP428FU&e=>
_______________________________________________
dispatch mailing list
dispatch@ietf.org<mailto:dispatch@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dispatch&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=xEMPhxwgqm2i5dqSPqRt62tbrLOuCz_d3xCwsgJwpdQ&s=zAFTXA1XJJYHFhi3WKkswkBsybSNo3bLJ3G0nP428FU&e=