Hello Paul, Thanks a lot for your feedback. You will see the updates in version 19 Best regards, Sabine >-----Original Message----- >From: Paul Wouters <paul.wouters@xxxxxxxx> >Sent: Tuesday, October 19, 2021 8:48 PM >To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ><sabine.randriamasy@xxxxxxxxxxxxxxxxxxx> >Cc: secdir@xxxxxxxx; draft-ietf-alto-unified-props-new.all@xxxxxxxx; >alto@xxxxxxxx; last-call@xxxxxxxx >Subject: Re: [Last-Call] Secdir last call review of draft-ietf-alto-unified-props- >new-18 > >On Tue, 19 Oct 2021, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote: > >> Thanks a lot for your review. A new version is under edition to address your >comments. >> Please see inline how we plan to address them. Can you let us know >whether the proposed updates meet your expectations? > >That looks good, thanks! > >>> appropriate to refer to RFC 7285 for the Security Considerations, as >>> is done in this document. >> [ [SR] ] >> [ [SR] ] Do you mean we should keep the security section of this document >as it is or should we shorten it? > >I meant it is good as is. > >>> 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. > >>> The IANA considerations are quite verbose. Usually, this section only >>> contains > >> [ [SR] ] We have identified some paragraphs and text that are more >considerations than specifications: > >Thanks. I think it will look better. Generally, think of this Section as something >only the IANA operator will read to actually perform the registry updates and >that any other reader will skip the section entirely. > >Paul -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
