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 <noreply@ietf.org>
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
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>