+1 > On Oct 21, 2018, at 12:11 PM, John C Klensin <john-ietf@xxxxxxx> wrote: > > Bob, > > I don't think Scott suggested a consolidated update to all of > these documents. Having started this thread, I certainly > didn't. If there is a substantive reason to rework a document, > by all means do that... especially if the scope of the original > document is very narrow. However, if the only change that is > required to a given document simple substitution, especially in > one place and especially if the document has very broad scope, > let's try to find a way to do a narrow update rather than > replacing/obsoleting the document. > > Like Scott, I hope that could be done by a single document that > draws all of the trivial updates together. But, if it cannot, I > believe we would be far better off with, using 2418 as an > example, with a one (substantive)-paragraph RFC changing the job > title rather than issuing a new, supposedly-complete, document > and obsoleting the original one. That also minimizes the risk > of unintended consequences. Or, while I had forgotten until > Rich's note caused me to review the history of 2418, for these > trivial cases, we could simply follow the POISSON/RFC Editor > precedent, treat the change of title as a simple editorial > matter, record it in an erratum identified as "save for > revision", and move on. > > If one wants to minimize the amount of community effort spent > per unit improvement, the latter is almost certainly the right > option for those simple cases. > > best, > john > > --On Sunday, October 21, 2018 08:39 -0700 Bob Hinden > <bob.hinden@xxxxxxxxx> wrote: > >> Scott, >> >>> On Oct 20, 2018, at 3:45 PM, Scott O. Bradner <sob@xxxxxxxxx> >>> wrote: >>> >>> sure seems a lot more efficient to just have one short RFC >>> instead of a bunch of RFCs that wind up changing well known >>> RFC #s for almost no meaningful changes - i >> >> I think it depends on the document. While there are some >> that could be handled this way, others are more complicated. >> For example, Jason and I are working on RFC7437bis " IAB,IESG, >> and IETF LLC Selection, Confirmation, and Recall Process: >> Operation of the IETF Nominating and Recall Committees". >> That's gotten more complicated because the IETF Trust >> Trustees and LLC Directors are being (partially) selected by >> the NomCom under the IASA2.0 work. The changes are not, for >> example, s/IAOC/LLC/. There are other changes that make sense >> like having the chairs communicate direclty with the NomCom >> instead it going through the IETF Executive Director (now >> called Managing Director, IETF Secretariat). Now starting to >> look at bringing in the Ombudsman changes from RFC7776. >> >> I suspect we are going to have the new ISAS 2 model for a >> while, good to get this right where it matters. >> >> Bob >> >>> >>> (never mind having to change training documents to point to >>> the changed RFC numbers) >>> >>> Scott >>> >>>> On Oct 20, 2018, at 5:27 PM, John C Klensin >>>> <john-ietf@xxxxxxx> wrote: >>>> >>>> >>>> >>>> --On Sunday, October 21, 2018 10:07 +1300 Brian E Carpenter >>>> <brian.e.carpenter@xxxxxxxxx> wrote: >>>> >>>>> fwiw I agree. There is no reference to IASA in 2418, for >>>>> obvious reasons. >>>>> >>>>> From a practical point of view, any terminology issue could >>>>> be handled >>>>> as an erratum with disposition "wait for update". >>>> >>>> That, IMO, would be an even better solution than creating an >>>> updating document that says "any time earlier documents say >>>> 'IETF Executive Director' replace it with..." and similar >>>> things and then hunting down the relevant documents and >>>> marking them as updated. >>>> >>>> Depending on how compulsive the WG and relevant AD are >>>> feeling, I think either would work. But we really have >>>> better ways to spend our time than replacing a process >>>> document to change a title... or at least I hope we do. >>>> >>>> Frankly, the only good reason I can see for generating all of >>>> these IASA2 documents just to change terminology is to create >>>> enough noise that the community doesn't notice and pay >>>> attention to changes that actually might be controversial. >>>> I trust and assume that is not the intent of anyone involved. >>>> >>>> john >>>> >>>> >>>> >>> >>> _______________________________________________ >>> iasa20 mailing list >>> iasa20@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/iasa20 >> > > > >
