Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-alto-unified-props-new-18

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hello Paul, 
Thanks a lot for your feedback. You will see the updates in version 19
Best regards,
Sabine

>-----Original Message-----
>From: Paul Wouters <[e-mail]>
>Sent: Tuesday, October 19, 2021 8:48 PM
>To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
><[e-mail]>
>Cc: [e-mail]; [e-mail];
>[e-mail]; [e-mail]
>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