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

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

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/" 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> 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
>     Status:
> https://datatracker.ietf.org/doc/draft-kinamdar-dispatch-sip-auto-peer/
>     Htmlized:
> https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-00
>     Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kinamdar-dispatch-sip-auto-peer
>
>
>
>     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.
>
>     The IETF Secretariat
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>