Re: [Iasa20] draft-ietf-iasa2-rfc2418bis-01.txt

[John C Klensin <[e-mail]>]

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"
<[e-mail]> 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. ;-)