Re: [Iasa20] draft-ietf-iasa2-consolidated-upd-06

["Livingood, Jason" <[e-mail]>]

John - Thanks in advance for updating the doc. Hoping we can then keep moving in the processing of the doc after that.

JL

On 3/8/19, 12:18 PM, "iasa20 on behalf of John C Klensin" <[e-mail] on behalf of [e-mail]> wrote:

    Ted,
    
    (top post)
    
    Thanks.
    
    This seems entirely reasonable to me and, unless Jason or Jon
    direct otherwise, I will modify the document accordingly.  In
    the event that it was not clear, what I've been objecting to was
    a late command directive after the WG appeared to have made up
    its mind.
    
    It is a separate issue and clearly not within this WG's scope,
    but experiments that run for 18 years (and counting) are unusual
    in the IETF (and most other engineering work) and, IIR, the IESG
    has argued against them several times.  If you believe it is
    still live, I think it would be extremely desirable for you to
    generate an update that discusses what has helped and why (or
    if) the methods should be tested.  Ideally, such an update would
    also bring it into line with current norms about experiments
    that actually produce conclusions and end.
    
    best,
       john
    
    
    --On Friday, March 8, 2019 08:40 -0800 Ted Hardie
    <[e-mail]> wrote:
    
    > Comments in-line.
    > 
    > On Thu, Mar 7, 2019 at 4:56 PM John C Klensin
    > <[e-mail]> wrote:
    > 
    >> 
    >> 
    >> --On Thursday, March 7, 2019 16:52 -0500 Alissa Cooper
    >> <[e-mail]> wrote:
    >> 
    >> > Hi Brian,
    >> > 
    >> >> On Mar 7, 2019, at 2:46 PM, Brian E Carpenter
    >> >> <[e-mail]> wrote:
    >> >> 
    >> >> On 08-Mar-19 06:12, Alissa Cooper wrote:
    >> >>> Thanks. I still don't think this is quite right because
    >> >>> there is no basis for this working group to obsolete or
    >> >>> render historic RFC 3929 simply because it mentions the
    >> >>> IETF Executive Director. It seems that RFC 3929 should be
    >> >>> treated in Section 2 the same as the other documents in
    >> >>> that section.
    >> >> 
    >> >> There's a more general issue: tracking down all "open"
    >> >> Experimental RFCs and deciding which of them need to be
    >> >> closed off as Historic or Obsolete or both. <joke>No doubt
    >> >> the IESG will be doing this in its copious free
    >> >> time.</joke> But for the present, doesn't it make more
    >> >> sense to clear both 3929 and 4633 up right away? I agree
    >> >> that it's outside the WG's mandate, strictly interpreted,
    >> >> but if the IESG consents, is that really a problem?
    >> > 
    >> > Yes. The point of charters is to scope working groups' work.
    >> > This working group is chartered to to document the normative
    >> > changes to IETF administrative structures and processes
    >> > necessary to effectuate the change to IASA 2.0. Obsoleting
    >> > documents about other things because they are out of date is
    >> > not within the charter.
    >> 
    >> Alissa,
    >> 
    >> I was in the process of putting together a discussion of the
    >> IETF's history with making things Historic and then Brian's
    >> note arrived and I concluded that maybe I was missing your
    >> main point and I discarded that note.  We may have a small
    >> difference of opinion about what it means to "scope working
    >> groups' work", which I want to try to summarize below.
    >> 
    >> However, I, and I assume most WG participants, am much more
    >> interested in getting this work finished than in arguing so,
    >> if you are putting on your Responsible AD hat and telling me
    >> to change this, I will certainly do so.
    >> 
    >> To me, there are two closely-related principles for charters
    >> and limits on the scope of a WG's work:
    >> 
    >> (1) To be sure enough that the community is aware of what the
    >> WG is doing so that IETF participants who are skilled in the
    >> topic area(s) and materially concerned can either participate
    >> or otherwise follow the WG's efforts and, in particular, are
    >> not blindsided at IETF LC time or later.
    >> 
    >> (2) To lower the odds that the WG will go off in the weeds in
    >> a major way, in particular by exceeding its competence and/or
    >> taking up time that detracts from the overall planned schedule
    >> or other tasks, and giving people who believe it is doing
    >> that a basis for raising objections.
    >> 
    >> However, I think it is also important to keep some perspective
    >> and flexibility on charters and scope if those principles are
    >> not grossly violated.  One of the hallmarks of the IETF (and
    >> the network specification development mechanisms long before
    >> it) has been that it is far more important to get the right
    >> things to happen and get the right things done than to go
    >> looking for rules to interpret and enforce narrowly.  Some of
    >> us have even argued in other contexts that, in addition to
    >> technical advantages, much of the reason why the core
    >> technology for modern networking is TCP/IP and related
    >> protocols as specified by the IETF and its predecessor rather
    >> than, e.g., OSI, is precisely that focus on getting the right
    >> things done rather that spending disproportionate energy
    >> figuring out the letter of the are and enforcing them.
    >> 
    >> So, in this particular case, the WG, working well within its
    >> scope, discovered some now-problematic phrasing in 3929.   In
    >> the process of figuring out how to fix that, it was observed
    >> that the document was almost certainly no longer relevant.
    >> The conclusion, as I understood it, was that getting it off
    >> the list of things that people were expected to read and
    >> understand would be a more efficient fix than patching a
    >> phrase in a seriously old document and perhaps creating
    >> confusion about whether the specified experiment was still
    >> alive and relevant.  That is not exceeding the WG's task area
    >> or competence, because almost anyone could spot the relative
    >> obsolescence of the spec and the problem was discovered in
    >> the process of doing the WG's work. It didn't take extra time
    >> or effort.  Ted (the author), who appears to be following the
    >> WG's work, didn't stand up and say "no, no, that experiment
    >> is still active and the document is still alive" and neither
    >> did anyone else.  I assume any such substantive objection
    >> would have immediately killed the "make Historic" plan.
    >> 
    > 
    > Actually, the issue was raised by Robert, who was surprised at
    > the deprecation.  In my follow-up to Brian's message, I said
    > this:
    > 
    > I don't see how the lack of experimental deadline makes it
    > this WG's job to
    >>> decide--can you clarify your thinking?  In this document's
    >>> case, it is hard to call the experiment done when it has
    >>> never been exercised.  We can say that the threat of it has
    >>> been useful, but that the actual methods are "not proven"
    >>> (in the Scots legal sense).
    >>> 
    >>> My take on why they were included was more that they
    >>> included the phrase "IETF Executive Director"; the doc says
    >>> that specific methods require telling the IETF Executive
    >>> Director something (e.g. that you volunteer to serve).  The
    >>> working group concluded that this didn't mean the new
    >>> Executive Director, but meant the Secretariat role that used
    >>> that term before.  I personally would fix that with an
    >>> erratum, rather than deprecation or obsolescence.
    >>> 
    >>> I may, of course, have a slight bias here.
    >>> 
    >> 
    > If that was not clear that I thought that the document is
    > still live; I apologize.  As far as I can tell, the idea of
    > this has helped, but the methods have not been tested.  As a
    > result, I don't think the document is past its useful life.
    > Patching it seems sufficient.
    > 
    > Ted
    > 
    > 
    >> 
    >> So, yes, the decision could be to just patch the document
    >> because making it Historic is not strictly within the WG's
    >> scope but I don't see any possible harm that could result
    >> from just getting 3929 off everyone's radar and out of the
    >> way.   In addition, now that the problem has been identified
    >> and with a nod to Brian's joke, do you really want to either
    >> get a request for a WG or an individual submission to make
    >> 3929 Historic? While I certainly would not want to advocate a
    >> hunting expedition to identify and consider all of outstanding
    >> Experimental documents and figure out which ones should be
    >> Historic and/or Obsolete, in this case, the hard work of
    >> identifying a relevant document and even writing an
    >> appropriate sentence has been done already.
    >> 
    >> best,
    >>     john
    >> 
    >> _______________________________________________
    >> iasa20 mailing list
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/iasa20
    >> 
    
    
    
    
    _______________________________________________
    iasa20 mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/iasa20