Re: [lamps] Paul Wouters' Discuss on draft-ietf-lamps-cmp-updates-20: (with DISCUSS)

["Brockhaus, Hendrik" <[e-mail]>]

Paul

Thank you for your review and the comments.

> Von: Spasm <[e-mail]> Im Auftrag von Paul Wouters via
> Datatracker
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> As a reviewer, and therefor I suspect also implementors, needing to read
> current + old and then compare it to new is very confusing. If this is for a
> few paragraphs I can see the point but throughout the entire long document? It
> prevented me from doing a full review.

I see your point.
This was discussed during IETF113 LAMPS meeting, see the snippet from the meeting minutes.

-------------------snip-------------------
CMP update vs. RFC4210bis: Roman Danyliw says that it does not need a bis document; however, the
reason for an update (as opposed to a bis document) needs to be explained. Russ explained that the
update was originally expected to be more modest. Tero Kivinen says that it is easier for a developer when
the specification is all in one document, and Tero asked that a single specification be produced before
advancing CMP to Internet Standard. Michael Richardson (MCR) said it would be nice to have a more
concise document by removing anything that is not used, but of course, that would be a bis document;
however, it is not worth delaying this work for years. Tero points out that that a bis document can advance
to Internet Standard without further changes, but the update document would need to be merged to
advance the CMP specification. Conclusion was to continue with the update document, and if the WG
wants to make it an Internet Standards in the future, then a bis will be written.
-------------------snip-------------------

I offered submitting an RFC4210bis document only performing the changes described in this draft. The WG decided that there would be some more work needed to update the complete document. There was support to spend this effort when progressing CMP to Internet Standard.
This would most likely mean to submit an RFC6712bis document, as CMP Updates also contains changes to RFC6712.

> 
> The document also "updates" the IANA Considerations which is not a real
> process
> we have. We only have new IANA Considerations and I don't think we should tell
> IANA to decode their instructions based on a diff with another rfc.

Finally, I followed the example in CMC Updates [RFC6402], see https://datatracker.ietf.org/doc/html/rfc6402#section-3.2 and  https://datatracker.ietf.org/doc/html/rfc6402#section-5
If this not OK for today, I will change it. Please let me know what the proposed way forward is.

> 
> Please tell me how this document would not be simply better if the diffing and
> replacing is done for the reader by obsoleting the old documents and creating
> one new clear readable document? If the WG could not do this, how can we
> expect
> an implementer to do this ?

It would be highly appreciated approving the CMP Updates draft soon to be able to continue the work on the Lightweight CMP Profile draft and to have a solid bases for ongoing implementation, e.g., in OpenSSL and Bouncy Castle.

Hendrik