Re: [Asap] I-D Action: draft-ietf-asap-sip-auto-peer-09.txt

Hi all,

It looks like this document has been in WGLC since December.

Is it ready to go to Publication Requested?

-MSK

On Sat, Dec 16, 2023 at 8:44 AM Sreekanth Narayanan (sreenara) <sreenara=
40cisco.com@dmarc.ietf.org> wrote:

> Hi Nicola,
>
>
>
> Thank you for your feedback! We’ve incorporated your suggestions and
> published the latest version of the draft (draft-ietf-asap-sip-auto-peer-11)
>
>
>
> Regards
>
> Sreekanth
>
>
>
> *From:* Asap <asap-bounces@ietf.org> *On Behalf Of *Kaustubh Inamdar
> *Sent:* Friday, December 8, 2023 5:15 PM
> *To:* Nicola Serafini <n.serafini=40tutanota.com@dmarc.ietf.org>
> *Cc:* Asap <asap@ietf.org>
> *Subject:* Re: [Asap] I-D Action: draft-ietf-asap-sip-auto-peer-09.txt
>
>
>
> Hi Nicola,
>
> Thank you for your suggestions, I agree that references to RFC 7231 is
> incorrect. Our intention was to specify and enforce the usage of HTTPS or
> HTTP over TLS. We will make the required modifications in an upcoming
> version of the draft that will be published shortly.
>
>
>
> Thanks,
>
> Kaustubh
>
> On 27-Nov-2023, at 11:55 AM, Nicola Serafini <
> n.serafini=40tutanota.com@dmarc.ietf.org> wrote:
>
>
>
> Hi everybody, first of all,  many thanks for your work.
>
>
>
> While reading the draft, I may noticed some typos regarding the HTTP
> protocol, all of those typos I identified use HTTPS instead of HTTP; a week
> ago I emailed Authors and I have not received any response so far.
>
>
>
> An example of typo that I also referenced in my previous email is Section
> "2.1. Reference Architecture":
>
> 2.1.  Reference Architecture
>
>
>
>    Figure 1 illustrates a reference architecture that may be deployed to
>
>    support the mechanism described in this document.  The enterprise
>
>    network consists of a SIP-PBX, media endpoints (M.E.) and a Session
>
>    Border Controller [RFC7092].  It may also include additional
>
>    components such as application servers for voicemail, recording, fax
>
>    etc.  At a high level, the service provider consists of a SIP
>
>    signaling entity (SP-SSE), a media entity for handling media streams
>
>    of calls setup by the SP-SSE and a HTTPS [RFC7231] server.
>
>
>
> As you can see here, I think "HTTPS [RFC7231]" is typo for three main
> reasons:
>
>
>
>     1 - RFC7231 defines HTTP protocol.
>
>     2 - RFC7231 was obsoleted by RFC9110 (
> https://www.rfc-editor.org/rfc/rfc9110).
>
>     3 - RFC9110 also obsoletes RFC2818 (
> https://www.rfc-editor.org/rfc/rfc2818).
>
>
>
> Another example is:
>
>    Taking the above considerations into account, this document proposes
>
>    a Hypertext Transfer Protocol (HTTP)-based workflow using which the
>
>    enterprise network can solicit and ultimately obtain the service
>
>    provider capability set.  The enterprise network creates a well
>
>    formed HTTPS GET request to solicit the service provider capability
>
>    set.  Subsequently, the HTTPS response from the SIP service provider
>
>    includes the capability set.  The capability set is encoded in JSON,
>
>    thus ensuring that the response can be easily parsed by automation.
>
>
>
> Where I believe you mean: "[...] The enterprise network creates a well
> formed HTTP GET request [...]".
>
>
>
> Finally, I agree with you that you may want to suggest the use of HTTP
> over TLS for this architecture.
>
>
>
> Am I wrong with this concerns/suggestions?
>
>
>
>
>
> Regards,
>
>
>
> --
>
> Nicola
>
> --
> Asap mailing list
> Asap@ietf.org
> https://www.ietf.org/mailman/listinfo/asap
>
>
> --
> Asap mailing list
> Asap@ietf.org
> https://www.ietf.org/mailman/listinfo/asap
>