[Asap] ASAP new version (04)

["Sreekanth Narayanan (sreenara)" <[e-mail]>]

Hi All,

A new version of the draft has been published. (https://datatracker.ietf.org/doc/draft-ietf-asap-sip-auto-peer/) Major edits include:


  1.  Expansion of Section 4.3 (Authenticated Client Identity) to cover client authentication by the service provider.  The ASAP configuration workflow will use the Resource Owner Password Credentials grant type from the Oauth2.0 framework. The section also details the steps involved in client authentication mechanism. This change came as a result of our discussion from the last review as well as an action item from the meeting @ IETF 111. (Minutes are available here: https://datatracker.ietf.org/doc/minutes-111-asap/) . This change also takes care of the comment below on the previous version.



>   B.7. Section 6.3 should probably add some text about verifying the TLS hostname.
>
> I see some new text in section 4.3, but that text is AFAICT incorrect. Verifying the TLS hostname is not an alternate way of authenticating the client, but a way of validating the server. If you are looking for alternate ways of authenticating the client, client certificates or OAUTH can be added to the list.





  1.  Adding the “revision” container to the YANG model after discussion during the last review. Comment below for reference.
>        A.2. There may be a need to provide a new capability set ahead of time, to ensure a smooth transition when properties change.  That can be done by permitting multiple capability sets in a document, and adding a "not-before" date.



  1.  Adding the “callerId” container to the YANG model to allow the service provider to be more specific regarding the way calling numbers are formatted by the enterprise. This container has two leaf nodes, ‘e164Format’ and ‘preferredMethod’. This has been done to address a comment from the last review as well. Comment pasted below for reference.



Marc: A.1. The document refers to the SIP Connect profile. and my understanding of SIP Connect is that it is US centric -- e.g., UK's NICC certainly has a different understanding on how Private-Asserted-Identity is used.  So I think that the capability set should be based first on a choice of profiles, not just implicitly on one (and BTW, which SIP Connect profile? there is 3 of them).  After a profile is selected, there seems to be two different set of properties that can be attached to it:
>        1) Choices that are part of the profile (e.g. DNS servers, Registration Mode vs Static Mode, any choice related to MAY keyword, etc..)
>        2) Properties that override the profile MUST/MUST NOT and SHOULD/SHOULD NOT.  E.g., if the provider does not support TCP (which is a MUST) there should be a property that overrides that implicit value.  It could also be used to add stuff that is not existing in the profile, like the SCTP transport for SIP.
>        To complement that, I would permit profile-less capabilities, where all the properties have to be explicit.
> KI:The SIP Connect technical recommendations isn’t US centric, it is applicable globally. There is a possibility of course of certain countries and geographies deferring to other, more localised, technical recommendations. The capability set document has been designed to include elements, which when populated correctly by the ITSPs, convey enough information to provide successful peering. The capability set isn’t using SIP Connect as a template, rather, it was designed looking at common ITSP peering issues across the globe. Having said that, there should ideally be a section added about caller identity (which currently isn’t there) - specifically around how caller ID is formatted (E.164 v/s non E.164 formatting) and which header field values must be included to convey called ID. For example, whether it is required to include the PAID along with the From header field value. We will add a section on Caller ID in an upcoming version of the draft.



  1.  Fixed the URL references for citations as well as the 72 column limit not being adhered to in certain lines.

> Thanks for doing that, it is better now. That said I think that putting the URL together with the citation label is a bit distracting when reading the text version of the draft.



  1.  Representation of the capability set document has been changed from XML to JSON. The group decided JSON by a show of hands at our IETF 111 meeting. Changed all references of XML to JSON.

Regards
Sreekanth