+1 On 10/21/18 10:39 AM, Scott Bradner wrote: > +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 >>> >> >> >> >> > > _______________________________________________ > iasa20 mailing list > iasa20@xxxxxxxx > https://www.ietf.org/mailman/listinfo/iasa20 >
