Re: [Asap] [Last-Call] Artart last call review of draft-ietf-asap-siptrunkingcapability-link-03

["Derek Engi (deengi)" <[e-mail]>]

Hi Tim, thanks for the review. Here are our comments:

>> RFC8288 is careful to decouple link types and media types, but the lack of a media type does feel like a gap.

The ASAP draft does define a new media type, but after a chat with the authors this media type will be changed to “application/json” to both keep things simple and avoid the need to register a new media type. This change will be added in a subsequent version of the implementation draft.

>> - In the GET example in section 3, maybe a note that the line-breaks & indentation are there for clarity?

Agreed, we can add a comment that the following example includes additional line-breaks and indentation for clarity.

>> - In the security considerations, perhaps a reference to draft-ietf-asap-sip-auto-peer#name-security-considerations would be helpful?

Sure, we can add some text along the lines of “Security considerations specific to the capability set document are documented here” and provide a link to the ASAP draft.

Thanks again for the support and the review.
Derek

--
Derek Engi
[e-mail]


From: Asap <[e-mail]> on behalf of Tim Bray <[e-mail]>
Date: Friday, March 10, 2023 at 12:44 PM
To: Tim Bray <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Asap] [Last-Call] Artart last call review of draft-ietf-asap-siptrunkingcapability-link-03
[Now with line breaks. Sorry.]

- Reading section 1, I wondered what dereferencing a URI with this link type would yield. Following the reference to draft-ietf-asap-sip-auto-peer-07, I eventually found the YANG definition, but I was a little surprised that it didn't seem to register a media type?  Now, RFC8288 is careful to decouple link types and media types, but the lack of a media type does feel like a gap.

- In the GET example in section 3, maybe a note that the line-breaks & indentation are there for clarity? As presented it's not a valid GET request.

- In the security considerations, perhaps a reference to draft-ietf-asap-sip-auto-peer#name-security-considerations would be helpful?

On Fri, Mar 10, 2023 at 9:43 AM Tim Bray via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Reviewer: Tim Bray
Review result: Ready with Nits

I am the designated Artart Last Call reviewer for
draft-ietf-asap-siptrunkingcapability-link-03.

This document is good; I remember almost nothing about SIP and it was still
easy to understand. Nits:

- Reading section 1, I wondered what dereferencing a URI with this link type
would yield. Following the reference to draft-ietf-asap-sip-auto-peer-07, I
eventually found the YANG definition, but I was a little surprised that it
didn't seem to register a media type?  Now, RFC8288 is careful to decouple link
types and media types, but the lack of a media type does feel like a gap. - In
the GET example in section 3, maybe a note that the line-breaks & indentation
are there for clarity? As presented it's not a valid GET request. - In the
security considerations, perhaps a reference to
draft-ietf-asap-sip-auto-peer#name-security-considerations would be helpful?


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