Date: Sun, 14 Dec 2025 17:14:34 +0000
To: Mike Bishop <mbishop@evequefou.be>
From: Sreekanth Narayanan <sknth.n@protonmail.com>
Message-ID: 
 <6LoWsvzufDA3UmsdO9ZJKF4hVKpuVKCX1AxNmWj5U_v6zHsCJ8HH7mH-4fi7pSsUQR2shLqbtDk0N-tkqFWhSWPg_8I95vG4p-FDvz9ltXA=@protonmail.com>
In-Reply-To: 
 <176116647330.109507.17623972407747289326@dt-datatracker-675c8fd764-bsflw>
References: 
 <176116647330.109507.17623972407747289326@dt-datatracker-675c8fd764-bsflw>
Feedback-ID: 5262089:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: ZVUISVLFUV5YNXT2VQAKA32PGR26MHBJ
CC: The IESG <iesg@ietf.org>, asap-chairs@ietf.org, asap@ietf.org,
 draft-ietf-asap-sip-auto-peer@ietf.org, marc@petit-huguenin.org,
 snandaku@cisco.com
Precedence: list
Subject: =?utf-8?q?=5BAsap=5D_Re=3A_Mike_Bishop=27s_Discuss_on_draft-ietf-asap-sip-au?=
	=?utf-8?q?to-peer-35=3A_=28with_DISCUSS_and_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/asap/FoU5qjbLVA_VDXbHu899NwVof70>

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=3Ddraft-ietf-asap-sip-auto-peer-35=
&doc_2=3Ddraft-ietf-asap-sip-auto-peer-36

Thanks
Sreekanth


On Thursday, October 23rd, 2025 at 2:24 AM, Mike Bishop via Datatracker <no=
reply@ietf.org> wrote:

> Mike Bishop has entered the following ballot position for
> draft-ietf-asap-sip-auto-peer-35: Discuss
>=20
> 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.)
>=20
>=20
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handlin=
g-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-asap-sip-auto-peer/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>=20
> Thank you for the work put into this document.
>=20
> 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.
>=20
> # Normative Language in Section 4.6
>=20
> Why is generation of errors using lower-case "must"? Is this not a requir=
ement?
> Being distinct from the "MUST" in the same section suggests it's not, but=
 it
> seems like it ought to be.
>=20
> # Discussion of HTTP Status Codes in Section 4.6
>=20
> It's true that HTTP servers can respond with redirect status codes, inclu=
ding
> 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 y=
ou
> don't discuss those. That includes other 3XX status codes besides the thr=
ee 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.
>=20
> I think what you're actually trying to say here is that servers SHOULD in=
clude
> 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.
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> "aren't required to enforce the guidelines" seems like too many layers of=
 vague
> indirection. Is this saying "because those guidelines aren't hard require=
ments
> that can be enforced by the peer"?
>=20
> Thanks for a thorough overview/terminology section. "SIP Auto Peer" is us=
ed
> 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.
>=20
> In Section 2.2, I'd drop the discussion of alternative approaches that th=
is
> draft doesn't take. Either move it to an appendix on alternatives the WG =
didn't
> adopt or leave it out entirely.
>=20
> Throughout, change most occurrences of "HTTPS" to "HTTP" except when talk=
ing
> specifically about the "https" URI scheme (which should be lower-cased).
> Compare to https://www.rfc-editor.org/rfc/rfc9110.html#https.uri for usag=
e.
>=20
> 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 o=
f HTTP
> (RFC9110), which all HTTP versions support.
>=20
> 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 particul=
ar
> protocol, I'd suggest dropping the over-specific example entirely and sim=
ply
> talking about SIP extensions in general.
>=20
> TLS is required, but no particular version? Why not 1.2 or later, or 1.3?
>=20
> Rather than saying "line wraps are for display purposes only", consider u=
sing
> the wrapping format described in RFC8792.
>=20
> 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 exampl=
es and
> a helpful reference.
>=20
> 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", a=
nd
> discuss caching and periodically re-verifying here. Also note that HTTP h=
as
> mechanisms for only fetching a document if it has changed; see
> https://www.rfc-editor.org/rfc/rfc9110.html#name-conditional-requests.
>=20
> I will defer to others whose YANG experience is much greater than mine, b=
ut
> 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 whi=
ch are
> not in this document's References. That's likely not correct.
>=20
> =3D=3D=3D NITS FOLLOW =3D=3D=3D
>=20
> - Section 1, "using which" =3D> "by which"
>=20
> - Section 2.2, "facilitates" =3D> "enables"
>=20
>=20
>=20
>=20
> --
> Asap mailing list -- asap@ietf.org
> To unsubscribe send an email to asap-leave@ietf.org