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

[Russ Housley <[e-mail]>]

Paul:

The shepherd writeup points out this situation:

  When this update was started, the number of updates was expected to
  be smaller.  It is recognized that complex update documents place a
  burden on implementers.  So, when LAMPS WG tries to progress CMP to
  Internet Standard, a bis document will be produced to combine the
  base specification and the updates.

Will simply deleting the first paragraph in the IANA Considerations resolve your concern about that update?

Russ


> On May 31, 2022, at 5:57 PM, Paul Wouters via Datatracker <[e-mail]> wrote:
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-lamps-cmp-updates-20: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-updates/
> 
> 
> 
> ----------------------------------------------------------------------
> 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.
> 
> 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.
> 
> 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 ?
> 
> This deliverable might have been good for the WG for tracking purposes but I
> don’t think it works as an RFC for the intended target audience.
> 
> 
> 
> 
>