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