Re: [Asap] Comments on draft-engi-siptrunkingcapability-link-01

["Paul E. Jones" <[e-mail]>]

Just one follow-up on the last paragraph below.  The text in
draft-ietf-asap-sip-auto-peer says, "This request can be challenged by the
service provider to authenticate the enterprise", which would also
facilitate returning a tailored response given the authentication
credentials.  In that case (and perhaps even more preferred), the URI in the
WebFinger response should not include identifying information itself.  It
would be redundant.

 

Paul

 

 

From: Paul E. Jones <[e-mail]> 
Sent: Wednesday, September 7, 2022 5:03 PM
To: '[e-mail]' <[e-mail]>
Subject: Comments on draft-engi-siptrunkingcapability-link-01

 

ASAP WG,

 

In section 3, I see "comprised of".  That should be "composed of".

 

In section 4 regarding this sentence: "The need for an enterprise telephony
network to obtain a capability set document from an Internet Telephony
Service Provider (ITSP) is documented in Automatic Peering for SIP Trunks
[I-D.ietf-asap-sip-auto-peer]."  Since this is an example section, I would
suggest moving that to section 3.  Let section 4 be strictly example, not
justification.  The sentence immediately following this explains what the
link relation enables.  Again, I'd move that, but I think it's already
well-covered at this point. Maybe just remove it?

 

How would the enterprise know to query "http:// ssp1.example.com"?  Is that
preconfigured? Perhaps a word about that would be useful. What if the ITSP
has different customers with different capabilities offered? I would expect
that to be likely. An ITSP could configure different resource per customer
using "http" type resource identifiers, but I wonder if it might make more
sense to use urn:uuid, acct, or some other URI type? My preference would be
for using the "acct" URI like "acct:[e-mail]".  (I noted a
similar example in draft-ietf-asap-sip-auto-peer.)

 

Further, it might make sense for the WebFinger response to align with the
example in section 9.2 of draft-ietf-asap-sip-auto-peer.  Perhaps the URL
returned should point to
https://capserver.ssp1.com/capdoc?trunkid=trunkent1456.

 

Paul