Re: My notes from this morning at breakfast

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]