John Leslie wrote:
> Tony Hain <alh-ietf@xxxxxxxx> wrote:
> >
> > Lars,
> >
> > As I understand it, the characterization was correct.
>
> Try though I may, I can't stretch it to "correct".
>
> In fairness to James, though, it was _not_ false, just misleading.
> (After all, it led me to a thoroughly inaccurate assumption: that the
> ruling and the suggestion were about the same issue.)
>
> Assuming the minutes are correct (by definition, an appropriate
> assumption), the _ruling_ was that the I-D _could_not_ be adopted
> because it was out of scope in the Charter.
>
> The suggestion had to do with what would make Lars comfortable in
> proposing a change in the Charter (which could not be accomplished that
> day in any case). _One_thing_ he suggested was documenting multiple
> implementation if they existed.
>
> James, of course, is perfectly entitled to raise the question of
> whether an AD should even _consider_ whether a spec is sufficiently
> detailed to enable two interoperable implementations without being
> supplemented by out-of-band communications with the author(s).
Interoperable implementations have absolutely nothing to do with charter
scope.
>
> > The level of the bar you appear to be setting is appropriate for
> > progressing an ID out of the WG,
>
> Actually, I don't agree the "multiple implementations" bar for
> Proposed Standard is _ever_ appropriate...
I was reacting to the excerpted minutes in the response Lars sent to James.
Right now, it is hard for
me to judge if an RSVP implementer can interoperate using this
specification. If there were two independent implementations,
this would clearly demonstrate the implementability of a Spec.
If the AD questions the clarity of WG output, multiple interoperable
implementations from the spec would be a reasonable measure of clarity. I
don't want multiple implementations to become a bar for every PS to
overcome, but the bigger point is that it can't even be a hint at a bar for
getting INTO a WG. If the doc is so complete that multiple interoperable
implementations are done, what work is there for the WG to do? Given that an
array of products will have shipped and been end-of-life'd before a WG & the
IESG could even think about allowing a PS to be published, what relevance
does the IETF have if the implementations are done before allowing a WG to
start?
>
> > but completely insane for evaluating a personal submission for
> > becoming a WG item.
>
> (Thus, I'd consider it also inappropriate for that evaluation.)
>
> But recall, the _ruling_ was that it was out of scope -- not whether
> the I-D was adequate for adoption by _a_ Transport WG as a WG draft.
I was not in the room, but this is inconsistent with the minutes excerpt
that is focused on document clarity.
>
> (I find it a bit distressing that some WGs don't think their Charter
> places any limits on what they may adopt as a work item. I'm pretty
> sure this is explained in WGC training sessions. Does it need to be
> repeated at a WGC meeting every IETF?)
In vs. out of charter is something the Chair should be able to resolve, and
-might- call for AD consultation if there is ambiguity. In any case,
implementation clarity of the document is not grounds for consideration, yet
the minutes show clearly that was the discussion at hand.
>
> > In the abstract, requiring multiple interoperable implementations
> > of personal drafts essentially codifies that the IETF process is
> > irrelevant...
>
> It would be _entirely_ appropriate if the Individual Submission
> was seeking Draft Standard status.
At that point one presumes it would be a PS RFC, not an individual I-D, or
did I miss a process step that allows skipping PS?
>
> May I suggest that our problem may be the RFC2026 "time-in-grade"
> requirements? Perhaps the IESG should be trusted to publish an RFC
> as Draft Standard _without_ going through the whole process twice?
Again, I have no problem dropping DS from the sequence. Time-in-grade has a
grand intent, but is totally OBE given the length of time it takes for the
IESG to get PS out the door. The products are on their deathbed by the time
documents are blessed, so we might as well move straight from personal I-D
to Historic.
Tony
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf