For clarification, which kinds of updates? Updating a document to reflect different organizational structure clearly is in scope. Whether replacing the document (rather than updating it with a new document) is in scope seems to me to be simply a different choice as long as the replacement document meets two conditions: (1) It does not leave a lot of loose ends in terms of references to the original document, existing updates to the original document, or other things that would create confusion and best and contradictory requirements at worst. (2) It does not make "any changes to anything related to the oversight or steering of the standards process as currently conducted by the IESG and IAB, the appeal chain, the confirming bodies for existing IETF and IAB appointments, the IRTF, or ISOC's memberships in other organizations." (quoting from the last paragraph of the charter at https://datatracker.ietf.org/doc/charter-ietf-iasa2/ ) My main difficulty with the 2814bis I-D is that it seems to create issues with both (1) and (2) above. My main difficulty with 5377bis is that it _may_ be a problem with (2). Both also contain a number of errors, some at the nit-picking level and others not, but those are not scope issues. Watch for draft-klensin-iasa2-2418upd-5377upd-00, which should provide a better idea of what I have in mind as a clearly-in-scope alternative than my ranting. best, john --On Monday, October 22, 2018 15:35 -0400 Joseph Lorenzo Hall <joe@xxxxxxx> wrote: > These kinds of updates are not in scope for this WG, it seems > to me. > > On Mon, Oct 22, 2018 at 2:01 PM John C Klensin > <john-ietf@xxxxxxx> wrote: > >> Jason, >> >> For perspective, I think there is a longstanding problem with >> IETF procedural work. I don't know how typical I am, but, in >> recent years, I've ended up with very little time to spend on >> IETF work. Both personal preferences and my perceptions of >> the best interests of the Internet lead me to try to spend as >> large a portion of that time as possible on substantive work >> rather than procedures. So, although I'm on the WG mailing >> list, I looked at the WG Charter and early discussions, >> accepted the explanation that this was about a largely >> technical change from the original "ISOC activity" model and >> corresponding IASA structure to a semi-separate LLC and the >> things that implies and the promise in the charter that the >> effort would have no effect one IETF procedures, and have not >> been paying in-depth attention. I'm still not convinced >> that the changes are worth the trouble but, if the IESG and >> those who are active in the WG are convinced --and convinced >> you can get it right-- my attitude has been "go for it and >> I'll go spend my time on substantive technical work". >> >> However, that approach is conditioned on the WG being able to >> get all of it right. Whether to adjust the terminology of >> 2418 by update or replacement is a matter of taste and I'm >> happy to defer to the WG's consensus taste... However, if the >> WG manages to demonstrate that it can't produce an update to >> 2418 without unintended side effects or pushing the >> boundaries of the contract with the community implied by the >> charter, at least without significantly more effort than has >> been invested so far, then, as I see it, the balance changes >> from "WG choice" to "better go the update" route. And, >> fwiw, while it is late in your process, you are, IMO at >> least, far better off finding that out now than getting the >> same feedback during IETF Last Call (potentially including >> appeals from the Last Call itself because the document fell >> outside the WG Charter into areas that would have drawn >> people who would have participated more actively in the WG >> effort had changes to IETF procedures been on the agenda). >> >> So, while I should have been doing other things, I've spent >> much of today looking at another document or two that might >> have been candidates for the "update" approach. For better >> or worse, I've found the same sort of issues that I found >> with 2418bis: changes that should have been made if the >> document was to be a replacement, a substantive error or two, >> q0uestions about whether IETF procedures for document >> approval were being changes, and difficulties with >> longstanding rules about replacement ("obsoleting") >> documents. In at least one case, the document has cleared >> WGLC but, given those issues, is clearly not ready for IETF >> LC. >> >> IMO, two documents with problems of this sort, including one >> that the WG was prepared to sign off on, takes the substantive >> part of the replace vs. update choice out of the realms of >> both "WG preference" and "isolated example". >> >> So, too bad this is late. And too bad it is going to require >> more work. However, it seems to me that we are better of >> catching these things now rather than later... and I hope that >> it does not suggest that we need to ask ourselves fundamental >> questions about the quality of the WG process in assembling >> and reviewing other documents. >> >> I sincerely hope you can avoid blaming the messengers. >> >> best, >> john >> >> >> >> >> --On Monday, October 22, 2018 14:23 +0000 "Livingood, Jason" >> <Jason_Livingood@xxxxxxxxxxx> wrote: >> >> > We debated the update tactic some months ago. It seemed >> > whatever path we took, we might be criticized but we had to >> > pick one. This is very nearly the final document in that >> > long list, so it is interesting that its really only one of >> > the last few to see this issue raised. Of course it seems >> > quite possible we'll now spend more time debating it on >> > email lists that it'd take to produce the document updates. >> > ;-) >> >> >> >>
