[Asap] Re: Mike Bishop's Discuss on draft-ietf-asap-sip-auto-peer-35: (with DISCUSS and COMMENT)

[Sreekanth Narayanan <[e-mail]>]

Hi Mike,

I've addressed all your comments below in draft-ietf-asap-sip-auto-peer-36.
https://author-tools.ietf.org/diff?doc_1=draft-ietf-asap-sip-auto-peer-35&doc_2=draft-ietf-asap-sip-auto-peer-36

Thanks
Sreekanth


On Thursday, October 23rd, 2025 at 2:24 AM, Mike Bishop via Datatracker <[e-mail]> wrote:

> Mike Bishop has entered the following ballot position for
> draft-ietf-asap-sip-auto-peer-35: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-asap-sip-auto-peer/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document.
> 
> As noted in
> https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
> a DISCUSS ballot is a request to have a discussion on the point below; I really
> think that the document would be improved with a change here, but can be
> convinced otherwise.
> 
> # Normative Language in Section 4.6
> 
> Why is generation of errors using lower-case "must"? Is this not a requirement?
> Being distinct from the "MUST" in the same section suggests it's not, but it
> seems like it ought to be.
> 
> # Discussion of HTTP Status Codes in Section 4.6
> 
> It's true that HTTP servers can respond with redirect status codes, including
> the three mentioned in this section, so I think the "may" doesn't need to be
> all-caps. Servers can also respond with any other HTTP status code, but you
> don't discuss those. That includes other 3XX status codes besides the three you
> list. They don't need permission from this document. Rather, servers need
> guidance about what information to include when they do and clients need
> guidance about how to handle those responses.
> 
> I think what you're actually trying to say here is that servers SHOULD include
> a Location header if they respond with a 3xx (Redirect) status code. A
> reference to https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx
> for client handling of redirects might be appropriate as well.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> "aren't required to enforce the guidelines" seems like too many layers of vague
> indirection. Is this saying "because those guidelines aren't hard requirements
> that can be enforced by the peer"?
> 
> Thanks for a thorough overview/terminology section. "SIP Auto Peer" is used
> here without definition. I assume, based on the document name, that it's
> intended to be the thing in this draft? Maybe introduce it by name in the
> introduction.
> 
> In Section 2.2, I'd drop the discussion of alternative approaches that this
> draft doesn't take. Either move it to an appendix on alternatives the WG didn't
> adopt or leave it out entirely.
> 
> Throughout, change most occurrences of "HTTPS" to "HTTP" except when talking
> specifically about the "https" URI scheme (which should be lower-cased).
> Compare to https://www.rfc-editor.org/rfc/rfc9110.html#https.uri for usage.
> 
> Similarly, I'd adjust the language around being "based on HTTP/1.1" and
> "backward compatible with HTTP/1.1." Rather, you're using the semantics of HTTP
> (RFC9110), which all HTTP versions support.
> 
> Why is RFC3262 mentioned in the prose but not as a reference? Given that the
> specific SIP extension isn't needed to understand/implement this particular
> protocol, I'd suggest dropping the over-specific example entirely and simply
> talking about SIP extensions in general.
> 
> TLS is required, but no particular version? Why not 1.2 or later, or 1.3?
> 
> Rather than saying "line wraps are for display purposes only", consider using
> the wrapping format described in RFC8792.
> 
> In Section 4.6, "response" should be "status code". The usual format for these
> would be "400 (Bad Request)"; see
> https://httpwg.org/admin/editors/style-guide#status-codes for more examples and
> a helpful reference.
> 
> Why is Section 5 entitled "State Deltas" when the point of the section is that
> this protocol doesn't define a way to communicate state deltas? I'd drop the
> discussion of what you're not doing, title it "Monitoring for updates", and
> discuss caching and periodically re-verifying here. Also note that HTTP has
> mechanisms for only fetching a document if it has changed; see
> https://www.rfc-editor.org/rfc/rfc9110.html#name-conditional-requests.
> 
> I will defer to others whose YANG experience is much greater than mine, but
> there appear to be many things present in the YANG module which are not
> described in the prose of this document, including references to RFCs which are
> not in this document's References. That's likely not correct.
> 
> === NITS FOLLOW ===
> 
> - Section 1, "using which" => "by which"
> 
> - Section 2.2, "facilitates" => "enables"
> 
> 
> 
> 
> --
> Asap mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]