Narrative Minutes
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the November 16, 2006 IESG Teleconference
Narrative Scribe: Spencer Dawkins <spencer@mcsr-labs.org>
With corrections from Lisa Dusseault, Ted Hardie, Dan Romascanu, David Kessens, Magnus Westerlund, Jari Arkko, Brian Carpenter, Leslie Daigle.
1. Administrivia
1.1 Roll Call
1.2 Bash the Agenda
Couple of bashes to the agenda sent in early.
Will talk about Dan's documents after administrivia, will address the late management item.
Brian would also like to talk about IESG meeting on Sunday morning in Prague.
1.3 Approval of the Minutes
October 26 minutes were approved with no discussion. Narrative minutes were approved and will be submitted by Spencer.
1.4 Review of Action Items
David/Bill/Dave IANA multicast address assignment expert job description - David has some progress, but is also waiting on comments from IANA.
1.5 Review of Projects
http://www.unreason.com/jfp/iesg-projects
No Jon, so no review.
2. Protocol Actions
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-ipfix-info-14.txt
Information Model for IP Flow Information Export (Proposed Standard) - 1 of 6
Token: Dan Romascanu
Two open positions - Bill stated No-Obj, Sam remained open. There are five DISCUSSes, with enough detail for the authors to work on them.
Will go AD follow-up, for the time being.
Cullen - do we want to have URLs pointing to IANA registries in documents?
Dan - also a comment from Ted on another document. My answer is "yes", we want the registry to be updated, so URL pointing to IANA registry seems flexible.
Cullen - I've been telling RAI to put the name of the registry in, not the URL - don't care, just want to be consistent.
Sam - concern with stable identifiers, providing the locator is fine as long as you provide stable identifier.
Bill - IANA has pushed back pretty hard on this in the past, because IANA worries about being unable to rearrange their website (several years ago) - worth clarifying now.
Ted - IANA would consider URLs for realtime access, but this isn't the case here.
Brian - weasel-word as "currently located at", but no more.
Cullen - I can now give good advice to RAI.
o draft-ietf-ipv6-over-ppp-v2-02.txt
IP Version 6 over PPP (Draft Standard) - 2 of 6
Note: This was in IESG in 2005, though never on the agenda. Got to
wait
state because of lack of implementation reports from both sides of a
test.
This is now brought back to the IESG to either approve it as-is, or
formally force the WG to downgrade this to PS.
Token: Jari Arkko
Lisa and Sam did not state positions on the call.
Jari - need to discuss Brian's and Cullen's DISCUSSes. First issue (stopped this draft in 2005) is that two implementations had to be on both ends, we don't seem to be requiring this now based on the e-mail discussion ... compression selection algorithm. We can wait for more tests, or drop this from the spec (leave as PS-only).
Sam - uncomfortable having part of the protocol stay at proposed standard - either get the interop reports or decide this is a minor feature. Prefer "minor feature".
Brian - where does it talk about "minor features" in 2026?
Sam - there is no clear specification of what needs to go into the reports.
Cullen - no problem with "interop reports didn't come from vendors", no problem with two implementations, one at each end. Don't really care about whether this spec is DS or not, but if this is the new bar for DS, we'll get a request to advance SIP from the SIP community, based on 150 companies testing at SIPits, along with a request to advance the closure set of all SIP-dependent documents. If the specification we're discussing was approved as DS, based on this implementation report, I would appeal.
??? - but this is case-by-case.
Mark - just a word about setting precedent - recently RTG required interop for PS. Each area sets its own bar.
Cullen - this bar is too low. I'm only enforcing my bar on what I'm approving.
Brian- trying to do this after Newtrk, but haven't gotten traction.
Lisa - APPS thinks we need documentation on every MUST. Would be OK if section 4.2 was removed.
Magnus - have heard of people implementing section 4.2, but we don't have any implementation reports about this part of the spec.
Brian - I'm sitting on a DISCUSS for this, I'm going to sit on this until I hear back from the authors.
Jari - we heard back from the authors, it hasn't been tested.
Sam - agree with Brian that guidance would be great, but absent guidance, we must make our own individual determination on what's appropriate. What Cullen is asking for will prevent documents advancing.
Mark - there isn't any consensus on what an interop report looks like, and this document won't change this.
Sam - do you have concerns about interop?
Cullen - think that the common case was tested, not error cases, at a showcase event to prove that everything worked.
Brian - two issues, this document and telling the community what we really think an interop report is.
Jari - document authors have waited a year, this is it. I don't care if this is recycled at PS or if we take away parts, it makes no sense to keep the draft waiting.
Bill - could go to PS with a different document containing only 4.2?
Brian - or non-normative appendix. Let's not rerun the Newtrk discussion - the document isn't going to be approved today.
Jari - will go back to PS on this document.
Sam - what does it mean for error cases to be tested?
Cullen - "if this happens, you MUST send this error" - needed for interop, recovery, etc.
Mark - maybe this is needed in SIP, but this is a tiny feature for a full standard.
Jari - remember that SIP will need a 1000-page report to advance if we use the same bar.
Cullen - if you think an interop report is "two vendors think this work", that's what we've got here.
Jari - but there aren't many things in the spec.
Cullen - we had WG chairs training about interop reports, sense of room is that you don't need to write code to test error conditions.
Brian - issue is that we have two DISCUSSes on interop reports with no written feedback.
Lisa - Cullen's DISCUSS is broader than my DISCUSS. My DISCUSS is entirely about section 4.2.
Cullen - maybe we could figure out a plan for this.
Brian - depends on what the proposal is - saying "we didn't test that" doesn't cut that.
Magnus - ask the header compression people if they use this
Jari - if they don't, we can pull it out of the document.
Jari - if there isn't going to be any more information, we can either let it die, do PS, or DS.
Brian - I didn't make these rules. If we advance without the rules ...
Magnus - header compression people haven't been asked, PPPEXT was asked a couple of days ago.
Brian - go AD followup and check this stuff out.
Jari - yes, if we don't have new information in a week, we'll go PS.
Mark - have a feeling 4.2 isn't even implemented.
Magnus - our guys did implement.
Brian - can't make progress on speculation. Jari needs to report back.
Jari - will give header compression a week and then go PS.
Magnus - I have other documents depending on section 4.2, if it gets dropped to go to DS.
* Fast discussion happening here, about not being able to reference the obsoleted PS in new documents, etc., the possibility of copying the section into other documents, and the need to avoid dangling normative references to obsolete specifications in our standards.*
Jari - What about not moving 4.2 to DS?
Sam - Not good to leave dangling references. You are essentially obsoleting the option then.
??? - You could also split the document into two, one DS and one PS.
Brian - need to move on.
Cullen - I'll remove my DISCUSS if the feedback justifies it.
Lisa went NO-OBJ based on discussion.
o draft-ietf-iporpr-basic-03.txt
Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) Networks (Proposed Standard) - 3 of 6
Token: Mark Townsley
Have converged on several DISCUSS issues, can work the rest offline. Revised ID needed.
o draft-ietf-pwe3-cell-transport-06.txt
PWE3 ATM Transparent Cell Transport Service (Proposed Standard) - 4 of 6
Token: Mark Townsley
No DISCUSSes on this document. Document is approved with no discussion.
o draft-ietf-hubmib-rfc3636bis-05.txt
Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) (Proposed Standard) - 5 of 6
Note: Bert Wijnen is the PROTO shepherd
Token: Dan Romascanu
Sam declined to state a position. No DISCUSSes, so approved with no discussion on this call.
Brian - is IANA happy about their question?
Dan - experts will be the WG Chair and the AD which are Bert and myself, to start with. IANA is OK with this.
o draft-ietf-rohc-rtp-impl-guide-22.txt
RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 (Proposed Standard) - 6 of 6
Token: Magnus Westerlund
No active DISCUSSes, so approved with no discussion on this call.
2.1.2 Returning Item
NONE
2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
3.1.1 New Item
o draft-ietf-imapext-annotate-16.txt
IMAP ANNOTATE Extension (Experimental) - 1 of 5
Token: Lisa Dusseault
One DISCUSS - document didn't ask for creation of a registry, just added values.
Lisa - IANA didn't think they needed further instructions.
Brian - if IANA is happy, I'm happy. Clearing DISCUSS.
Lisa - will go Point Raised anyway, can now do this faster.
o draft-ietf-ipdvb-ar-05.txt
Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks (Informational) - 2 of 5
Token: Mark Townsley
One DISCUSS - Mark thinks DISCUSS is actionable and authors can work with it - revised ID needed.
o draft-ietf-netlmm-threats-04.txt
Security Threats to Network-Based Localized Mobility Management (Informational) - 3 of 5
Token: Jari Arkko
No DISCUSSes on this document.
Jari - Russ asked about updates after SECDIR review - revisions are in RFC Editor notes.
Sam - another document coming back delayed until this document?
Jari - had multiple netLMM documents with DISCUSSes, each AD should review the documents, the WG says they have addressed the issues.
Document was approved for publication.
o draft-ietf-mip6-location-privacy-ps-04.txt
IP Address Location Privacy and Mobile IPv6: Problem Statement (Informational) - 4 of 5
Note: PROTO Shepherd is Gopal Dommety <gdommety@cisco>.. NOTE:
There
are RFC Editor notes!
Token: Jari Arkko
Jari - One DISCUSS - WG should address this, plus COMMENTs about clarity of document.
Sam - if you need help making my DISCUSS actionable, let me know.
Ted - ABSTAIN issue is on clarity - concern is that location and location/privacy are being discussed differently that in other documents. Not worth blocking, but worth talking to other WGs for other documents.
Jari - have been concerned with this document, went through multiple rounds, trying to justify work that might not be needed. Will look at Lisa/Ted issues.
Revised ID needed.
o Two-document ballot: - 5 of 5
- draft-ietf-nemo-ro-problem-statement-03.txt
Network Mobility Route Optimization Problem Statement (Informational)
Note: Proto shepherd is TJ Kniveton <tj@kniveton.com>
- draft-ietf-nemo-ro-space-analysis-03.txt
Network Mobility Route Optimization Solution Space Analysis (Informational)
Note: Proto shepherd is TJ Kniveton <tj@kniveton.com>
Token: Jari Arkko
No DISCUSSes on this ballot set -
Jari - agree with Sam's comment that they've been boiling the ocean, but new work will be more tightly controlled - look for revised charter.
Sam - just publish, don't worry about addressing my comments.
Jari - CGA is just removing two words - we can do that one, for instance.
Point raised, write-up needed.
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
3.2.1 New Item
o draft-ietf-proto-wgchair-doc-shepherding-08.txt
Document Shepherding from Working Group Last Call to Publication
(Informational) - 1 of 2
Token: Brian Carpenter
Two DISCUSSes - Russ's comments are good, will go revised ID needed. Sam's DISCUSS is that if we approve this document it implies changed in the ID Tracker. If Brian sends appropriate tickets, will Sam change?
Sam - will change to "YES" - are authors encouraging MORE appeals? Talk to responsible AD - it's their job to solve the problem.
Cullen - what names are we using for shepherding roles?
Brian - "responsible AD", not "shepherding AD" - anyone object to being called "responsible"?
Magnus - like that better.
Bill - we changed from "responsible" to "shepherding" a long time ago, we've gone full circle.
David - should this be an ION? Russ's DISCUSS encourages this, have heard other people ask question, too.
Brian - if ION is up and running, can consider this when document comes back. May peeve the authors, of course.
Lisa - not comfortable with questions in RFC if we update it as an ION - confusing.
Magnus - move entire document to ION.
Brian - only a synchronization issue - if ION is available, I'll talk to the authors. I'll revisit the ION question one more time - revised ID needed, in any case.
o draft-bellovin-keyroll2385-03.txt
Key Change Strategies for TCP-MD5 (Informational) - 2 of 2
Token: Russ Housley
Jari has a DISCUSS, with no Russ.
Jari - getting e-mail, making progress, may be confused about about my initial DISCUSS, but I still feel that there is a change that we need to do.
Ross - late COMMENTs, not DISCUSS, please look at them if you revise the document.
AD followup.
Magnus - Jari, is the issue that you will expire keys if the host is silent and can't perform the roll over?
Jari - the issue is that key roll over in one direction has implications on the other direction as well.
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
The IESG will use RFC 3932 responses: 1) The IESG has not
found any conflict between this document and IETF work; 2) The
IESG thinks that this work is related to IETF work done in WG
<X>, but this does not prevent publishing; 3) The IESG thinks
that publication is harmful to work in WG <X> and recommends
not publishing at this time; 4) The IESG thinks that this
document violates the IETF procedures for <X> and should
therefore not be published without IETF review and IESG
approval; 5) The IESG thinks that this document extends an
IETF protocol in a way that requires IETF review and should
therefore not be published without IETF review and IESG approval.
Other matters may be recorded in comments to be passed on
to the RFC Editor as community review of the document.
3.3.1 New Item
o draft-irtf-mobopts-ro-enhancements-08.txt
A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization (Informational) - 1 of 1
Note: Advancing according to draft-irtf-rfcs-00.txt. The IESG should
review
only for "end-run" conflicts according to RFC 3932.
Token: Mark Townsley
No DISCUSSes and no objections to being published as an Informational RFC.
Brian - do Sec ADs need to talk to IRTF chair about SECDIR review?
Sam - we can talk, but authors have been very responsive. Can work on this, but will be challenging - reviewers jump down the throat of early-stage work too much, sometimes. Will talk to Russ about this.
Leslie - intention is that IRTF publication is supposed to be less heavy-weight than Independent Submissions - probably need to discuss if this becomes more complex.
Brian - would be nice to say "we reviewed this early" in these cases.
Mark - at a minimum, we're doing an RFC 3932 end-run check for IRTF documents - what else can we do? Can we "Do Not Publish"?
Sam - isn't there an IRTF draft on this?
Brian - should look at that one - these documents are test cases for whether the procedure actually works.
Jari - ETA for getting this procedure in place?
Leslie - IRTF thinks procedure is in place. Where does this get published? Informational document shepherded by IAB?
Mark - have generated some feedback for the next procedure revision.
Approved for publication.
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Kitten (GSS-API Next Generation) (kitten) - 1 of 1
Token: Sam Hartman
Sam - WG realized that they weren't chartered to work on internationalization issues, some of their stuff would be IESG-rejected without fixing these issues, so doing internationalized versions of APIs. Also chartered for TLS and IPsec, so removed this item which shouldn't have been there in the first place.
Brian - any intention to change milestones?
Sam - was doing this under rechartering, can add milestones, but hope doesn't need to go for IETF review.
Brian - anyone think IETF review is needed? (No one did)
??? - one editorial nit.
Sam - I can deal with that, too. Will look at the editorial nit and see whether to send detailed message or new draft charter.
4.2.2 Proposed for Approval
o Internet Emergency Preparedness (ieprep) - 1 of 1
Token: Jon Peterson
Brian - Lots of people have objections, all different.
Sam - three problems, not clear on proposed work, question whether WG has subject matter expertise (need to know what WG is doing to know this for sure), and very little support for the work from people outside the WG - concerned that this is an isolated enclave. Dropping concern that this work belongs in another SDO based on what Fred thinks they will be doing - but the charter doesn't say what Fred thinks.
Brian - we're closer than I thought on this. Looks like they updated their old charter, need to rewrite.
Cullen - concern that they will charter for anything and do what they want.
Sam - willing to work with them until I get a consistent story.
Brian - Jon thought "re-BOF".
Sam - Re-BOF may be best way to figure out points two and three, but need clarification of charter proposal first.
Cullen - let's wait until Jon is here, don't want to derail discussion.
Sam - don't talk next week, it's American Thanksgiving.
Brian - back as WG charter item, or management item?
Sam - let's see where I go with the WG.
Brian - better to keep ourselves moving, put on the agenda in two weeks, someplace.
Ross - haven't looked at this lately, but Sam's concerns sound like my concerns two years ago.
Sam - have TSV issues under control, any area Fred knows about is fine, but they're moving into new areas.
Brian - there may be a gap in the working group.
Lisa - like "new BOF" - trying to look up how long WG has existed.
Cullen - existed in a state of pain for a long time.
Lisa - really like "new BOF"
Brian - can Cullen make sure Jon gets this on the agenda next time?
5. IAB News We can use - Leslie Daigle
Not much to report since last week, raging discussion of RAWS.
Looking at successful protocols - currently DNSSEC. No matter what protocol you look at, there's a divergence between architecture and deployment.
Mark - what are you looking at, for your metric?
Leslie - exactly. Dave Thaler and Bernard Aboba are preparing case studies and we're reviewing them. This could be an interesting discussion for joint IAB+IESG. Can provide slides (if Dave agrees), but probably better to report discussion.
6. Management Issue
6.1 Status update on 4676 replacement.
Cullen - don't know what status is - IANA codepoint was wrong, some other SDOs were asking for status (and expedited handling).
Sandy - can do this today.
Cullen - a week would be fine.
Brian - shouldn't we say what actually happened here?
Ted - late codepoint change, document went out with a different codepoint and this conflicted. We approved the document with <TBD> here, and errata has been approved. Would be good to do this while attention is on it - please do this quickly.
6.2 Prague Sunday Morning IESG Meeting
Anyone disagree? None noted.
Leslie - only discussion is what we do long-term - bouncing between morning and afternoon is probably the worst suggestion.
Cullen - I can make this work as long as I have any regular plan, even alternating - just need to know what the plan is.
7. Agenda Working Group News
Jari Arkko - WiMAX Forum asking Jari and IAB people about official liaison with IETF. Really worried about not being official liaison and not being heard.
- Leslie - there was no answer to the question of "how will this help IETF work?" the last time we discussed this. If there is an answer now, we can move forward.
- Jari - have gotten suggestions from Bernard for next steps. Those steps are useful even if there is no liaison.
Ross Callon -
Brian Carpenter -
Lisa Dusseault -
Lars Eggert -
Bill Fenner -
Ted Hardie - Sent out EPP documents related to the work of the *closed* PROVREG working group; they take its documents to draft standard. - is there any way to advance TLS to DS?
- Sam - no way any time soon. Respinning to deal with hash agility and combined modes, TLS doesn't have much interest in this. Russ and Sam explained "we don't ever want to go to draft" isn't the right answer. Could move current spec to draft, but they have no interest in doing so. They depend on RFC 3280, getting THAT to DS is really hard.
- Ted - Bill raised this issue - X.509 not standards-track, so TLS isn't DS, so nothing that depends on TLS can go to draft.
- Sam - can do this, but not for three years. Was Bill unhappy, or is this just a normative downref issue?
- Ted - will probably say "IESG thought about this and think the normative downref is OK".
- Sam - I'm happy if this isn't a special case.
- Ted - two classes of spiraling dependency - if you have clear layering and if you don't. Will forward e-mail chain to Sam for background.
Sam Hartman -
Russ Housley -
Cullen Jennings - Need WG ADVICE from IESG. P2PSIP question is "everyone pretty much wants to go with DHT, can spend infinite time choosing between DHTs". What does IESG think of proposing one in the charter (with IAB input), and saying DHTs will be pluggable?
- Sam - get consensus from them that this is reasonable. This is more radical than Ted's alternative decision making process, but have been in two WGs that made decision based on coin flips. Get them to agree that IESG/IAB is a reasonable forum for this call. Not convinced that IESG/IAB have cycles to understand the issue.
- Lisa - get WG to agree that Cullen will make the decision?
- Cullen - don't want to be hated that much...
- Ross - we're not all experts on everything, hopefully ADs are.
- Lisa - if WG agrees, that's fine.
- Cullen - no one is pointing to arbitrary charter constraints?
- Sam - no, we've absolutely done that before - NEA, but not negative. If they agree we can be arbitrary, that's fine. It would be easier if you get WG to agree to an evaluation of the alternatives. If we have to do analysis ourselves, that's a huge amount of work.
- Cullen - think we can do that in an e-mail.
- Sam - that would be fine.
- Cullen - no idea what I'm going to do moving forward, but I'm moving forward. May drive consensus on this, on the list.
- Mark - "reason for choosing is WG makes progress faster" - may not be sure, IETF resources aren't like company resources. If people disappear, what we care about doesn't get worked on, either.
- Ross - sometimes progressing multiple approaches is the right thing to do.
- Cullen - need at least one mandatory-to-implement.
David Kessens -
Jon Peterson -
Dan Romascanu -
Mark Townsley -
Magnus Westerlund - In ROHC WG the 3GPP2 is pushing for having a lightly modified version of the RFC 3095 profiles intended to handle reordering better to be published now instead of waiting for the ongoing work on version 2 profiles. There are currently four options; WG adaptation, AD sponsored, Independent submission to RFC-editor, or publication in a 3GPP2 document. These are being discussed in the WG with quite diverse views.