Telechat Review of draft-ietf-ecrit-lost-planned-changes-18
review-ietf-ecrit-lost-planned-changes-18-secdir-telechat-sparks-2026-09-21-00

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 authors, document editors, and WG chairs should treat
these comments just like any other IETF Last Call comments.

SUMMARY

This draft has issues to address before publication as a Proposed Standard RFC.

I apologize in advance for how high-level these comments are - I recieved this
review assignment fairly late in the review period.

ISSUES:

The document needs a more discussion around changeSetIds. It should be explicit
about sorting by intended date of application I think.

I'm still not certain that there's not an issue to consider with changeSetId
collision - is it the intent that this Id is scoped to a particular server? If
multiple servers are involved (such as might happen in the example given where
some area is changing administrative control and queries are not expected to be
recursive) is the client expected to keep a separate queue of upcoming changes
per server? Should there be further guidance on what to do if the authorities
don't agree on what the state will be on a given date?

The OpenAPI spec looks incomplete as written - a client is supposed to provide
a changesetID in polls past its first, but I don't think the interface provides
a way to do that. This document is the first ecrit document to use OpenAPI to
specify an interface I think - have any OpenAPI experts looked at it?

The document says it is defining an extension to LoST, but I think it is
defining an adjacent, separate protocol that defines an api to carry LoST-like
things. If I'm getting that right, the document should say so. Are there any
considerations about how this use of HTTP should authenticate compared to
normal use of LoST?

Getting XML Schema and RelaxNG to say exactly the same thing is very hard. The
document claims the XML schema can be used interchangeably with the RelaxNG
schema, but the RelaxNG schema remains authoritative. Has there been tooling
used that proves them equivalent? If they aren't at some unexpected edge, and a
message validates under one but not the other, what's the interoperability
consequence if a client and server are each validating with the different
definitions? Should the document talk about that?

If I read the document correctly, the benefit for implementing this extension
is to be able to detect _issues_ with making upcoming changes (the actual state
is verified at the server at the time of need - updating the local db in
advance is an optimization that is tested at time of use). Perhaps the document
should talk more about the benefits and limitations of using the extension?

I have a few nits that I'll send directly to Brian.