On Sat, Feb 10, 2018 at 7:53 PM, John C Klensin <john-ietf@xxxxxxx> wrote:
--On Saturday, February 10, 2018 05:44 -0500 Keith Moore
<moore@xxxxxxxxxxxxxxxxxxxx> wrote:
>> I agree that editors need to listen and reply, but also the
>> WG chair MUST follow up with editor to make sure they are
>> replying to feedback. Also the ADs MUST follow up with IETF
>> LC comments and they should be involved. I think we should
>> look at Acee as a great WG chair, and there are many other,
>> we may need to reward great WG chair to encourage guidance
>> and discussions.
>
> You are talking about something different here than what I was
> talking about. But I emphatically disagree with your MUST
> assertion. I do not believe that chairs and ADs have a duty
> to follow up individually on every LC comment. LC comments
> that are relevant should be carefully considered, of course.
> But just because a comment is made in response to LC does not
> mean it has sufficient merit to warrant a reply. There is a
> reason IETF requires rough consensus rather than complete
> consensus.
AB> IMHO, the IESG not-replying/not-ack to community's reply-to-iesg-request means not considering, and replying means considering. I think the ietf procedure says that iesg should consider community reviews.
Keith,
Speaking generally (with no information about this particular
case at all), there is at least one more reason, one that I
consider very important. In general there are two ways to get
to a consensus technical standard (rough or otherwise). One is
to try to incorporate every idea, or even most ideas, and
reflect every comment. The other is to try to end up with a
single, coherent, specification with a minimum of options.
AB> I don't think there is only two approaches or ways, I prefer the WG way that follows IETF procedures and Chairs do their job to help making productive discussions per WG.
The
first approach tends to create complex standards, sometimes with
internal inconsistencies, and often a need for profiling, but
often results in everyone who contributed to its development
feeling as if they got something.
AB> I say sometimes complex-standards and not often, it depends on our chair's experience or AD's experience per WG (experience in terms of guidance of engineers and ideas and discussions). I recommend IETF does often training to our WG chairs. We need in all ietf complex and simple and mix specifications, it depend on the technical requirements not WG consensus requirement.
Of the two, the second is
more likely to produce something that can actually be
implemented and deployed even if the approach runs the risk of
failing entirely.
IMHO, Not often/more-likely implemented, but usually depends on the authors experience or companies experience that are proposing such standard.
The IETF, as you know and I hope Abdussalam understands by now,
has historically favored the second approach and, IMO at least,
has often come to regret it when we slip over into the first.
I think IETF has not favoured any of the two, where was that announced/written, I think IETF left that to the WG experiences, discussions and consensus.
IETF is all about experiences and practices, we need to guide to that but not let our authors or editors or companies guide to other favors.
To paraphrase a now-ancient rant, the sides of the information
superhighway are littered with the corpses of specifications
developed using the first approach, largely because technical
reality tends to get lose in the process of compromise to get a
semblance of consensus.
We need guidance in our information superhighways by WG chairs, with guidance to get a semblance of consensus without losing technical discussions/messages, the complete technical and integration concerns. Some authors or editors need reminder from the WG chair to reply to reviews/messages or participants per adopted-ietf-wg-draft per ietf-wg-discussion-list.
Taking that second approach of trying to produce a focused
standard with few options and no features added just to get
agreement requires that WGs, and WG Chairs in particular, be
given considerable discretion to evaluate, not just rough
consensus, but which way the wind is blowing. That discretion
and authority can be abused, but the IETF's main protection
mechanism is appeals, not specific rules about procedures to be
followed.
IMHO, it will look as rules to who does not know the procedure, but who gets use to it, it looks like guidance or IETF participation.
IMHO, we need both procedures and appeals approach at events of abuse, or actually our IETF procedures includes the appeals process, so we only need to follow procedures then. Often participants don't appeal, it does not look good to appeal, so our WG chair should guide for no abuses. Furthermore, IMHO, we don't specify procedures to be followed, we follow procedures, or we get guided in a nice and expert way so we feel that there is a friendly environment of production.
And it is important the people remember that the main
purpose of IETF's appeals mechanism is not finding of fault but
being sure adequate consideration occurs when someone says "wait
a minute, that may need rethinking or more evaluation".
I agree all need to remember that.. However, I may remember better when my WG chair reminds the WG when some forget or when needed. Furthermore, our IESG should remember to consider comments when ietf community-review occurs, it will when the ietf chair reminds it.
best regards
AB
