Skip to main content

Telechat Review of draft-ietf-asap-sip-auto-peer-16
review-ietf-asap-sip-auto-peer-16-secdir-telechat-harkins-2025-02-24-00

Request Review of draft-ietf-asap-sip-auto-peer
Requested revision No specific revision (document currently at 41)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2025-03-04
Requested 2025-01-31
Authors Kaustubh Inamdar , Sreekanth Narayanan , Cullen Fluffy Jennings
I-D last updated 2026-08-11 (Latest revision 2026-01-20)
Completed reviews Tsvart Telechat review of -20 by Joerg Ott (diff)
Secdir Telechat review of -16 by Dan Harkins (diff)
Artart Telechat review of -21 by Harald T. Alvestrand (diff)
Genart IETF Last Call review of -18 by Joel M. Halpern (diff)
Yangdoctors Telechat review of -23 by Ebben Aries (diff)
Artart Telechat review of -23 by Harald T. Alvestrand (diff)
Yangdoctors IETF Last Call review of -30 by Ebben Aries (diff)
Opsdir IETF Last Call review of -32 by Jen Linkova (diff)
Assignment Reviewer Dan Harkins
State Completed
Request Telechat review on draft-ietf-asap-sip-auto-peer by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/Icp2qY9KIqsCsI7UrcYYNbr4g_g
Reviewed revision 16 (document currently at 41)
Result Ready
Completed 2025-02-24
review-ietf-asap-sip-auto-peer-16-secdir-telechat-harkins-2025-02-24-00
   Howdy,

   I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

   The summary of the review is Ready.

   This document defines a way for an enterprise network to obtain
a set of characteristics in a service provider network that will
allow the enterprise network to generate configuration blocks on
devices in the enterprise network in order to ensure a successful
service provider peering. The document specifies an HTTPS-protected
request-response. One thing I found missing (and I think it might
even arise to the level of "nit" but I'm not sure) was a reference
to RFC 8446. Also there was no mention of a required TLS version to
protect the exchange. Might want to consider adding that.

   The document is mature and well-written. The Security Considerations
look thorough, modulo the lack of mention of TLS 1.3 which seems to
be de rigueur these days.

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius