This was NOT intended for general distribution - my apologies...
Spencer
----- Original Message -----
From: "Spencer Dawkins" <spencer@xxxxxxxxxxxxx>
To: <ietf@xxxxxxxx>
Cc: "John C Klensin" <klensin@xxxxxxx>
Sent: Tuesday, July 11, 2006 8:43 AM
Subject: My notes from this morning at breakfast
Tuesday - Area Breakouts
John Klensin - downref document
Has been deferred to next telechat.
Some of Ted's concerns addressed in e-mail.
Bill has noticed that documents that are expedited aren't just numbered
early, they are published early - doesn't exactly match the document text.
Sam - how many documents are we talking about, that this would apply to?
Documents submitted to IESG with normative references to either documents
that are also in IESG queue, or have been approved at the same or lower
level, but not published yet.
Sam - just RFC Editor publication delays?
John - document prepared after discussions in the community about norm ref
rule holding things up. John doesn't think there are many documents
covered, just wrote proposal because of the noise. Have reviewed last call
comments, in interesting place. John doesn't care if proposal is approved
or not, or whether documents waiting to be published are included or not.
If IESG rejects document on grounds that were not raised during last call,
community can say IESG is doing what IAB was doing in 1972 (was this 1992?
but that's the quote).
Sam - want to make sure understanding is correct, what delays are
included.
Ross - two documents held up for more than a year for references that
shouldn't have held the documents up. BGP spec updated, but not the
protocol, shouldn't have held up the proposal, but it did, and held up
multiple proposals.
John - could have said "BGP spec is changing, but not in any meaningful
way, go publish".
Sam - would experiment have helped with this situation? not sure.
Ted - my confusion - reference to RFC Editor queue document whether or not
it had a reference hold? There are cases where documents that are done are
being held for references that are not done. Would have helped with
SDPnew, gotten more documents out more quickly.
John - meant to be able to do what you're asking about, but not required
to do so. 5-minute discussion on whether reference hold is appropriate.
Ted - we don't ask RFC Editor to remove reference holds today.
Sam - can't remove reference hold - that's on a document that wouldn't
qualify for this experiment.
John - this is a deliberately small change being proposed.
Ted - second issue is that experiment has wide latitude, so IESG needs to
actually run the experiment.
Brian - first experiemental text has to be carefully crafted -
cut-and-paste after that?
Ted - stable RFC numbers is no problem - run experiments in stages,
starting with stable RFC numbers?
Brian - no one challenged IESG discretion at last call time.
Sam - three stages - downref to RFCs, downref to approved transitive
closure, downref to transative non-closure. May want guidelines on
situations that might make us leery of applying guideline, John has
proposed examples where experiment would work.
Brian - are DISCUSSants NO-OBJ on next telechat? Do concerns prevent
running the experiment?
Ted - don't try to run all three parts of the experiment at once. Suggest
that we approve document and say clock starts ticking when we publish
something. Don't start experiment before we're finished baking it.
Sam - late last call comment from Kurt, believes this might not cover case
where you advance an RFC with no text changes, but with resulting
downrefs. Approval message, rather than text in the document?
Mark - sitting on a document with that issue now.
John - if I understand, a much more radical change - making a cautious
downref in the text, making a community decision that downref is OK, and a
third case where we shouldn't be making a downref at all - that was the
thinking.
Brian - some AD has to step up to the mark on writing up the experiment
Sam - no, someone has to step up, AD not required.
Brian - that's true. Clock starts when we have experiement written up.
Date for next retreat
(But not everyone is here)
Sam noticed that he can pay for one retreat, but he hasn't yet (since
previous one was in Boston).
Reasonable timescale for next retreat? Not six months later, puts us in
November.
Brian - last retreat was useful - need another one?
Jon - efficiency retreat experience, set around an agenda, said we would
cancel retreat if we didn't have an agenda ...
Sam - agenda content was pretty much nailed down OK, even though the final
agenda wasn't published until a couple of days before the retreat.
Lars - no more than three retreats per year.
Ross - would like to do more at retreats, and meet with community at
IETFs.
Dan - start with agenda? we are beyond team building.
Lisa - joint IAB/IESG retreats useful?
Sam - agenda during e-mail, availability needs face-to-face
Brian - need provisional date (months in advance).
(not recording minute-by-minute here)
Looking at Sept 25th and October 2nd weeks?
Looking at October 9th?
Brian will send proposal to the list.
Ted - need to plan for remote participation.
Lars is possible host, in Europe. Cullen can host in San Jose, Mark can
host in France ... Ted can do San Diego, but we go there soon anyway.
Will cancel Thursday breakfast and meet with community.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf