Hi, Rob The first question whenever someone proposes a bis document is, of course, “are you volunteering to edit?”
Jokes aside, it’s always a question of whether or not it is worth the effort. Not just for whoever is editing, but the usual effort associated with any document, such as WG participants, shepherd, AD, IESG, various directorates, RFC editor. So before embarking on something like this, it’s not enough to just count the number of errata. You need to put yourself in the shoes of a naive implementer who doesn’t know about errata. Are the errors big enough that they might lead them to make a mistake in the implementation? Text that uses “example.com <http://example.com/>” instead of “example.org <http://example.org/>” probably isn’t. Text that says that a challenge object with an error cannot have the “processing” status when it can likely is. As for adding other RFCs, that’s again a judgement call. We did merge some add-ons to IKEv2 in one of its revisions. It make sense to merge them if the add-on is so obvious and so necessary, that pretty much every implementation of 8555 would also implement the other document. Is RFC8738 like that? Or are IP identifiers so rare and curious that many implementations exclude them? As always, it’s up to the group whether making a significantly bigger document with some of the add-ons makes sense. In general, groups and ADs tend to prefer smaller documents, but that is decided on a case-by-case basis. Yoav > On 11 Mar 2024, at 23:08, Rob Stradling <rob=40sectigo....@dmarc.ietf.org> > wrote: > > RFC8555 was published [1] 5 years ago today! > > Just thinking aloud, 'cos I'm curious what folks here think... > At what point might it make sense to start work on an 8555-bis? > > There's a fairly long list of Errata [2]: 10 Verified, 5 Reported, and 4 Held > for Document Update. > > Would it make sense for an 8555-bis document to incorporate and obsolete any > of the "add-on" RFCs / I-Ds, such as RFC8738, that have been published since > RFC8555? Or, conversely, would it be preferable to not do that? > > With 5 years of deployment experience behind us, have any "missing" features > in RFC8555 been identified that would be best addressed by updating the core > specification (i.e., in an 8555-bis document) rather than by writing new > "add-on" I-Ds? Or, conversely, are "add-on" I-Ds always the preferred > approach? (The "missing" feature that immediately springs to my mind is > "profiles" [3]). > > > [1] > https://mailarchive.ietf.org/arch/msg/rfc-dist/25pD6Za_dVkXMbJwyPhBJR6nIlo/ > [2] https://www.rfc-editor.org/errata_search.php?rfc=8555 > [3] https://mailarchive.ietf.org/arch/msg/acme/BLVAayrTrUCegT4s2twci3Q2BY8/ > > -- > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited > > _______________________________________________ > Acme mailing list > Acme@ietf.org <mailto:Acme@ietf.org> > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
