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

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

Hi Murray,

We are waiting on the chairs to initiate this procedure.
Jean, Gonzalo, is there anything else needed from our side to proceed on this one?

Regards
Sreekanth

From: Murray S. Kucherawy <[e-mail]>
Date: Thursday, 18 April 2024 at 11:13 PM
To: Sreekanth Narayanan (sreenara) <[e-mail]>
Cc: Nicola Serafini <[e-mail]>, Asap <[e-mail]>, Kaustubh Inamdar <[e-mail]>
Subject: 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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Kaustubh Inamdar
Sent: Friday, December 8, 2023 5:15 PM
To: Nicola Serafini <n.serafini=[e-mail]<mailto:[e-mail]>>
Cc: Asap <[e-mail]<mailto:[e-mail]>>
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=[e-mail]<mailto:n.serafini=[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/asap

--
Asap mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/asap