>> While extensions to a protocol don't necessitate an Updates: clause, >> in this case I think it should because the document addresses >> shortcomings in the original protocol. That is, new implementations >> are expected to really require implementing this new document as part >> of the "core specification". Thus implementers reading 7285 should >> really be warned to also read (and >> implement) this document. > > [ [SR] ] we do not oppose entities against endpoints therefore this > extension does not intend to replace endpoints by entities. Both are > useful, as some use cases can live with the base protocol. A > discussion thread has just started on this point and we will like to > have your conclusions on the exposed points of view An RFC update does not mean "do not implement what was in the older one". Update really means that one should read (and ideally implement) both documents to get the updated picture of what the IETF believes should be implemented. If this is just an optional extension, then Update: is not needed. But if it modifies the previous document to clarify or extend in a way that is core to the protocol, it should probably Update: the previous RFC so implementers know there is more to take into account than just that core older document. [Qin Wu] Thank Paul for comment on this issue, ALTO WG has revisited issues again and the conclusion we made is this draft just focuses on an optional extension, a few explanation text will be added into abstract to clarify why update tag is not needed and confusion words will be cleaned up. https://mailarchive.ietf.org/arch/msg/alto/ykK66Uv_ypbsh9mn9SPu0QL01-k/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
