"Adult supervision"

[Bound, Jim]

As a note we just had a debate in IPv6 WG around SHOULD or MAY around
whether a BCP Nodes Requirement Document.  The issue was should the doc
state Nodes SHOULD or MAY have Stateful Implementation in addition to
Stateless (ergo DHCPv6).  A few participants noted that those wanting it
to be SHOULD quoting the SHOULD in 2119 that 2119 SHOULD statement needs
fixing.  The argument to use the SHOULD was not used but the confusing
on interpretation of the SHOULD was not good.  I think 2119 normally
works.  In this case those for stated that implied within what is call
Neighbor Discovery permitting a router to set the bit to do stateful (no
statement in that spec of should, may, or must) just an option as all
options, created a strong case for SHOULD.  But, then the same against
the SHOULD stated that SHOULD could apply for when Nodes want to get
non-address information.
But confusion does exist in 2119 as recent as San Franciso IETF.

Not sure if others are seeing this but having 2119 updated would be
important if needs fixing and causing a problem from multiple integrated
specifications depending on each other?

/jim

> -----Original Message-----
> From: Pete Resnick [mailto:presnick at qualcomm.com] 
> Sent: Wednesday, May 07, 2003 4:45 PM
> To: Keith Moore
> Cc: problem-statement at alvestrand.no
> Subject: Re: "Adult supervision"
> 
> 
> On 5/7/03 at 2:17 PM -0400, Keith Moore wrote:
> 
> >>>working groups choose to be derailed. a working group that refuses
> >>>to understand the constraints on its solution space before 
> >>>investing significant effort in a solution, has nobody to blame 
> >>>but itself.
> >>
> >>OK, so we are now talking about working groups that act out 
> of malice.
> >
> >I wouldn't call failure of a group to do the necessary background
> >work "malice"
> 
> The words used in the past few messages are not about "failure of a 
> group", they are about "choices" of a group and "refusals" of a 
> group. Would "willful negligence" be preferable to "malice"? It's 
> still about a *willful* decision on the part of these people to 
> disregard something important, or (as in the house-building metaphor) 
> an act of such huge and obvious stupidity and ignorance that people 
> involved should not be allowed near *any* project. I find all of this 
> hyperbolic, accusatory, and certainly not constructive. Again, when 
> viewed through the lens of "willful actions", some of the activity of 
> ADs seems equally horrific. (Or to put more of a point on it if we 
> allow ourselves to view all of this action as intentional, not only 
> would we be justified in saying that working groups choose to be 
> derailed and should be blamed, but we would be equally justified in 
> saying that certain ADs are/have been arbitrary, capricious, and 
> power happy.) Cutting back on this "intentional" language would go a 
> long way toward civilizing this debate, on both sides.
> 
> >I certainly agree that we need to find ways to better communicate
> >big picture needs, since what we have is clearly not working well. 
> >I suspect we'll have to get out of fire-fighting mode before we can 
> >find time to do that, though.
> 
> Quite true.
> 
> >>Can you (and the rest of us) make an attempt to assume that working
> >>groups do these things out of a lack of understanding and guidance, 
> >>and that ADs do these things out of frustration and overwork?
> >
> >This is very close to what I do assume, and I didn't indicate 
> >otherwise.
> 
> Whether or not you indicated this, if you *mean* this, your previous 
> language is not conveying it.
> 
> Again, dialing back the language would be helpful along these lines.
> 
> >>      A Proposed Standard should have no known technical 
> omissions with
> >>      respect to the requirements placed upon it.  However, 
> the IESG may
> >>      waive this requirement in order to allow a specification to
> >>      advance to the Proposed Standard state when it is 
> considered to be
> >>      useful and necessary (and timely) even with known technical
> >>      omissions.
> >>
> >>I have always taken this to mean that a Proposed Standard can't say
> >>something like, "This protocol requires some way for the client and 
> >>server to rendezvous. It is left for future development to figure 
> >>out how to do that."
> >
> >I have always taken this to mean that a document that fails to
> >address any important technical concern does not qualify for 
> >Proposed Standard.
> 
> If it meant that, then why bother with the whole paragraph? Why not 
> simply say (as you always seem to misquote it) "A Proposed Standard 
> should have no known technical omissions", full stop? Unless, as I 
> asked before, you think that things like providing authentication and 
> interoperating with the global Internet are universal and implicit 
> "requirements" in all Proposed Standards. I think there is sufficient 
> evidence to the contrary.
> 
> 2026 provides different places for input. Stating the requirements 
> comes at the beginning of the process, either through chartering or 
> through writing and approval of a requirements document. Deciding 
> whether a document has met those requirements is what comes at the 
> end of the process. The quoted paragraph above is about the latter. I 
> find your interpretation of the paragraph a reach at best, and 
> certainly inconsistent with the context of it.
> 
> pr
> -- 
> Pete Resnick <mailto:presnick at qualcomm.com>
> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: 
> (858)651-1102
>