Narrative Minutes
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the June 7, 2007 IESG Teleconference
Narrative Scribe: Spencer Dawkins <spencer@mcsr-labs.org>
With corrections by Lars Eggert
1. Administrivia
1.1 Roll Call
1.2 Bash the Agenda
Cullen asked for a discussion of NomCom liaison at the end of the management items, time permitting.
1.3 Approval of the Minutes
1.4 Review of Action Items
Cullen to address IANA open issue of well-known protocol names - no progress to report.
Sam's action item also - no progress to report.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-ips-iscsi-impl-guide-08.txt
iSCSI Corrections and Clarifications (Proposed Standard) - 1 of 6
Note: Document Shepherd: David Black
Token: Lars Eggert
David went "NO-OBJ" on this ballot. There are a couple of DISCUSSes.
There was an e-mail problem with the "IANA Expert" discussion. The Gen-ART review comments are accepted, and Chris's DISCUSS is clear.
o draft-ietf-atompub-protocol-15.txt
The Atom Publishing Protocol (Proposed Standard) - 2 of 6
Token: Lisa Dusseault
Ron went "NO-OBJ" on this ballot. A number of active DISCUSSes.
Russ has provided suggested wording but the working group was keen on keeping "must be capable of being configured" Russ was asking about versioning. Russ is OK if people wnat to point to TLS/1.1.
Sam - should respect WG position if it's strong.
Lisa - Paul has sent a couple of e-mails on this.
Sam - "are you appropriately using HTTP?" isn't about broken implementations. Don't think we need to say "sometimes signatures don't work". Need to explain what mitigations exist - they've done a good job of identifying threats, they just need to explain what to do about the threats. "Should client remove invalid signatures?" and similar questions - talk about not gratuitously breaking signatures ("only break them when it's the right thing to do").
Lisa - problem is that there's no way for a server to NOT break signatures.
Sam - that's fatal.
Lisa - I thought so, too.
Sam - if that turns out to be true, I can easily write something else.
Lisa - did anyone have a response to Chris's question about appropriate HTTP and my answer?
Cullen - need to consider whether running on the same port is a GOOD idea.
Sam - our entire way of looking at this is flawed. People can offer on a different port or on the same point, and we can't/won't stop them. Looking at this from server perspective makes no sense. Question is whether network administrators allow clients that can get to the web to also get to ATOMPUB.
Chris - and conversely, does it make sense to allow ATOMPUB and NOT HTTP?
Sam - exactly.
Lisa - no way to do ATOMPUB without doing HTTP - inseperable.
Chris - I'll keep raising this issue.
Sam - should change the guidance.
Lisa - if I had time, I would.
Chris - new HTTP working group could look at this if they can find a document editor (but APPS ADs are worried about this - look for document editor first!)
Cullen - Paul said the registration was W3C. It's just a process thing. We need to know where it's done.
Lisa - I think this is a misunderstanding.
Cullen - didn't think we were looking at purl.com as registratrar. We're set up to do registration into IANA, not other namespaces.
Sam - can Lisa just agree that we'll figure this out before the document moves forward?
Cullen - just need to do this before AUTH48, wish documents already had this type of detail when they get to IESG.
Lisa - choice of namespace for XML extensions has nothing to to do with non-standard extensions.
Cullen - let's just agree on where we do the namespace and move on. Perfectly fine if we make this consistent with other documents. Given that WG has punted to IESG, wondering if everyone using self-signed certificates just decays down to the equivalent of digest.
Sam - we suggested disgest and they rejected that. The entire web works this way. People just click to add certificates. We haven't figured out a way to check against previously-seen certificates yet, and this makes rekeying harder.
o draft-ietf-dhc-dhcpv6-leasequery-00.txt
DHCPv6 Leasequery (Proposed Standard) - 3 of 6
Note: Document Shepherd is Ralph Droms <rdroms@cisco.com>
Token: Jari Arkko
Jari - authors and I agree with Tim's comments.
Sam is going NO-OBJ, we're moving to Revised ID Needed. Tim thinks authors are on track and will clear when the new document is available.
o draft-ietf-dnsext-nsec3-10.txt
DNSSEC Hashed Authenticated Denial of Existence (Proposed Standard) - 4 of 6
Note: Exiting IETF LC 5/23
Token: Mark Townsley
Mark said the authors will respond.
o draft-ietf-dhc-dhcpv6-ero-01.txt
DHCPv6 Relay Agent Echo Request Option (Proposed Standard) - 5 of 6
Note: Document Shepherd is Stig Venaas <stig.venaas@uninett.no>
Token: Jari Arkko
Approved with no discussion
o draft-ietf-midcom-rfc3989-bis-00.txt
Middlebox Communications (MIDCOM) Protocol Semantics (Proposed Standard) - 6 of 6
Note: This document is an draft update of the process of taking RFC 3989 to
proposed standard. It inherits the state RFC3989 to proposed had. The ones
that has reviewed it before should just copy their ballot position to this new ballot.
Token: Magnus Westerlund
Russ - this will be AD followup, can do RFC Editor notes, Magnus will discuss with Russ.
2.1.2 Returning Item
o draft-ietf-dnsext-nsid-02.txt
DNS Name Server Identifier Option (NSID) (Proposed Standard) - 1 of 1
Token: Mark Townsley
This isn't actually a returning item...
Fingerprinting is way out of the bottle, you can fingerprint anything. This is the second part of Tim's DISCUSS. After discussing, Tim will go NO-OBJ.
Mark will handle recommendation notes - approved, point raised.
2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-hip-dns-09.txt
Host Identity Protocol (HIP) Domain Name System (DNS) Extensions (Experimental) - 1 of 6
Token: Mark Townsley
Chris - why is this OK on algorithm agility?
Mark - would like discussion to continue. AD followup, probably revised ID needed. Mark will send proposal to WG chairs, too.
o draft-ietf-sipping-dialogusage-06.txt
Multiple Dialog Usages in the Session Initiation Protocol (Informational) - 2 of 6
Token: Jon Peterson
Jon - Tim is right, reference is a typo. One of the SIP guys replied to Russ, but Russ didn't see the reply - it was only on SIP mailing list. People thought the specific concern was left-field.
Russ - wish this had happened on the IETF list where the concern was raised.
Tim - what about bugs?
Jon - SIP uses bugzilla, but this isn't IETF stuff.
Russ - why not use errata now that RFC Editor is responsive?
Jon - probably several hundred bugs reported, just inertia. We can look at this.
o draft-ietf-nemo-multihoming-issues-07.txt
Analysis of Multihoming in Network Mobility Support (Informational) - 3 of 6
Note: Proto shepherd is TJ Kniveton <tj@kniveton.com>
Token: Jari Arkko
No DISCUSSes, so document is approved.
Jari - will discuss one comment with Lars, so will probably be RFC Editor note addition - "point raised".
o draft-ietf-hip-applications-01.txt
Using the Host Identity Protocol with Legacy Applications (Experimental) - 4 of 6
Token: Mark Townsley
Mark is going "revised ID needed" and discussion on e-mail will continue.
o draft-ietf-ccamp-gmpls-addressing-07.txt
Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS)
Networks (Informational) - 5 of 6
Token: Ross Callon
Ross - we can handle DISCUSS offline. There are lots of COMMENTs - should we have a revised document?
Lisa - am asking where recommendations should go in my DISCUSS.
Ross - can have e-mail exchange that doesn't require change to document. Will either be reflected in standards or not, going forward.
Jari - should go Revised ID Needed. Comments aren't quite addressed yet.
Ross - could just be a better document. Authors are responsive, not worried about getting changes.
David - long introductory section isn't reasonable in this document - do others agree?
Lisa - would like to see more references.
ADs are making comments so they aren't blocking...
Document will go AD Followup.
o draft-ietf-mip4-fmipv4-07.txt
Mobile IPv4 Fast Handovers (Experimental) - 6 of 6
Note: Document Shepherd is Pete McCann
Token: Jari Arkko
No DISCUSSes on thsi document, but IANA has raised questions on this document. Jari thinks he has answered most questions but whether authors want new namespace isn't clear, authors need to respond. Can document be approved now?
Michelle - if Yoshiko still have questions, can you still hold the DISCUSS ?
Was extremely late TSV review posted a couple of hours ago on main IETF list. If you're going revised ID needed anyway, look at these comments (from Hannes).
3.1.2 Returning Item
o draft-ietf-mip6-dsmip-problem-03.txt
Problem Statement: Dual Stack Mobility (Informational) - 1 of 1
Note: PROTO shepherd is Basavaraj Patil <basavaraj.patil@nokia.com>.
NOTE 1: There are significant RFC Editor notes!.
NOTE 2: Bringing back to agenda to resolve discusses and get more votes
Token: Jari Arkko
Jari - was Revised ID Needed, but authors are OK with Brian Carpenter's explanation. Can be done with RFC Editor Notes. Don't like introducing complexity twice. Having second thoughts, but we've said we shouldn't complain about chartered work items. Not comfortable blocking this document.
Sam - I agree with you, this is a great document, if it came out before we chartered the work, we wouldn't have chartered the work! My biggest objection is to doing this in both directions.
(Unminuted discussion happened here)
This is approved, point raised (to add RFC Editor notes).
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
NONE
3.2.2 Returning Item
NONE
3.3 Independent Submissions Via RFC Editor
3.3.1 New Item
o draft-ooms-xcast-basic-spec-11.txt
Explicit Multicast (Xcast) Concepts and Options (Experimental) - 1 of 2
Token: Ross Callon
Three DISCUSSes here, but Ross thinks this is straightforward - refers to document that doesn't exist yet, there is no IANA section but there are IANA considerations...
Jari - Ross, you need to talk to the authors and figure out what they want. If they want to describe a concept, tweaking the text to say that no numbers exist helps. If they want a spec, they need to come through IETF and have more details. If they want to describe an experiment, they may be able to use experimental protocol numbers.
Sam - just slap an IESG Note that says "you can't implement this". Are these guys trying to document something without a Protocol Action?
Jari - if they want protocol numbers, this has to come to the IETF.
Russ - will have to come back to agenda anyway. This type of document has to come through IETF, not through RFC Editor.
Ross - would individual AD-sponsored document work? Yes.
Lars - not detailed enough to implement, don't give them numbers intil the spec is detailed enough.
Will go into AD followup.
o draft-jurski-pppext-iphc-02.txt
Limited IP Header Compression over PPP (Informational) - 2 of 2
Token: Jari Arkko
No DISCUSSes - approved?
"Yes, we want to send this IESG Note to the RFC Editor" - Do Not Publish because of IANA issues.
Chris - note should point to correct IANA registry in the IESG Note.
Chris is providing a new IESG Note.
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
o Operations and Management Area Working Group (opsawg) - 1 of 2
Token: Dan Romascanu
No objections, is approved.
o Basic Level of Interoperability for SIP Services (bliss) - 2 of 2
Token: Cullen Jennings
"Does anyone have objections to the creation of BLISS?" (smiles)
David - is a WG required to do BCPs?
Cullen - trying to get energy around this, protocol changes would go to SIP.
Approved pending wording change from Cullen.
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) - 1 of 1
Token: Jari Arkko
Very minor rechartering, removing some HMIPv6, no informational elements for 802.21, clarified discovery work, some rewording.
Sam - so, we're not doing HMIPv6?
Jari - not much market for this.
Lars - have transport people in this group, but they are mostly NSIS folk. Can we provide a TSV Advisor with broader transport knowledge?
Jari - that would be great. NSIS is on our radar screen, but we're not letting them do creative things. Will discuss with chairs offline.
David - is flood of documents really going to happen this summer/fall?
Jari - milestone date changes don't require recharter. Most of this is in good shape, but I'm concerned about 802.21 work - design team was supposed to do work before Prague, and they didn't. I'm aware of this issue.
Given that this is a minor update, is there any need for IETF review? We're removing stuff, not adding it.
Russ - would support not reviewing.
No one objected to this course of action.
Jari - can't find Russ's editorial change, but will send minor charter revision to secretariat before rechartering announcement is sent.
4.2.2 Proposed for Approval
NONE
5. IAB News We can use
IAB had retreat, working on improving the IRTF working groups.
Had a ROAP discussion, made progress, have more and more understanding, no big hangups here.
Had followup on unwanted traffic workshop, finally have a plan to do work in IRTF in this space. Will also work with ISOC to craft a message to community about unwanted traffic.
Discussed improving ISOC communications. They are hiring people to work on communications.
Discussed NomCom quite a bit at telechat earlier this week. We need to address in concerted manner that doesn't block NomCom work. Have a candidate for IAB liaison to NomCom.
Setting up Wiki page for Chicago BOFs, would be good to know how stable agenda is.
Have series of IAB documents coming through RFC Editor's queue.
No decisions to create output on ROAP. Probably something will come out.
6. Management Issue
6.1 IESG liaison to NomCom
Cullen - personally plan to respond to Lakshminath.letter, thinks IESG should respond about what liaisons are allowed to do. Would be less concerned if he hadn't already said he has an agenda.
Sam - We think experienced people should explain issues, not talking about specific people. No way to tell Lakshminath he is overstepping part of the process while doing part of what he says. But we can instruct OUR liaison not to provide specific people.
Russ - RFC 3777 wording is vague and contradictory. "participates in everything except voting", or not.
Sam - had never considered that liaisons might provide specific input - am horrified at the thought.
Cullen - what about facts about an incident?
Sam - answering questions about an incident is fine.
Cullen - what about facts that people don't know?
Sam - a grey area, but I'm not ruling this out.
Dan - is input from IESG, or from individual?
Cullen - individual, aware of what happened, nothing else.
Sam - much more appropriate to focward mail than express an opinion.
Lisa - "can't possibly replace personal judgement with process"
Sam - but ruling out individual input is something we should do.
Cullen - point to mail archives?
Sam - that's fine.
Ron - general instances of bad behavior that we shouldn't repeat -
(1) NomCom generally polls entire I-star, but one person gets to sit in on the calls as IESG member, shouldn't be giving personal opinions, maybe not even on qualities of candidates.
Cullen - what makes you think that in the current RFCs?
Sam - not relevant to this discussion.
Cullen - people should be writing drafts, I agree with the point but there's no doc that says that.
Lisa - can do this without making statements that will be used to shut up out liaison.
Russ - agree that liaison is on behalf of the entire group.
(2) when you're in a grey area, identify that you're speaking as an individual
Jon - have to be able to rely on people to use their judgement about this
Sam - some grey areas. Trust people to follow guidelines, but if guideline isn't there, may choose to do something different.
Cullen - saying something that might affect the selection of a candidate is the only reason liaisons are on the calls at all. Hard to draw a bright line.
Sam - specific candidate comments should be made as individuals. If IESG had executive session and agreed on feedback, that would be fine, but that's not what we're talking about. Can provide comments as an individial.
Cullen - can liaisons provide comments they wouldn't have made except for discussion on a call.
Lisa - Lakshminath made it clear that he will resist subjective inputs from liaisons.
Cullen - last year, questions and answers were in writing only - this is why I am prickly.
Russ - chairs make this decision every year. This is the first time Chair told us what the decision is. I applaud that.
Jari - Lakshminath's heart is in the right place, trying to do the right thing.
Cullen - Sam made an important separation - what instruction we give, and what we think the rules are.
Russ - don't have a volunteer for this liaison anyway? Actually, there are three who have volunteered. Anyone else planning to volunteer? Jon also willing. Can we decide this today?
(some toe-dragging in the sand happened here, but I didn't minute most of this)
Cullen - NomCom is looking to liaison for IESG experience, not NomCom experience.
Russ called names as part of the selection. Jon was selected. We have about a month to nail down instructions (don't need this until voting members are selected), but we can provide Jon's name now.
There was also discussion about concerns about people looking at NomCom inputs inappropriately.
We'll work on the text at the next informal telechats, unless we all agree by e-mail. Ron will write a first draft.
7. Agenda Working Group News
Jari Arkko - no
Ron Bonica - OPS area working group has Scott Bradner as chair, still selecting co-chair.
Ross Callon - no
Lisa Dusseault - no
- Cullen - haven't seen APPS BOF charters, etc. yet.
- planning to approve a couple of these, but need to talk to Chris before making this decision.
- Chris - have had good discussions on both BOFs
- Lisa - need to get people in a room to have a good charter, not just a strawman
Lars Eggert - (not minuted)
Sam Hartman - will decline IFARE, we should do something in this space but Chicago wouldn't be productive. I won't sponsor their docs as individuals.
- Punting several years of Kerberos work and taking a different direction, because no one will implement.the current direction (Tim is watching this decision, because Sam doesn't want to have conflict of interest here).
Russ Housley - no
Cullen Jennings - no
Chris Newman - watching EAI design team, had discussion about IESG note on design teams. Amusingly, EAI design team chair that didn't apply IESG note was actually the author of the note, so apparently having two repositories (for IESG Notes and for IONs) is really confusing.
- Sam - is that required for self-organizing design team?
- Chris - requirement is for design team disclosure based on lifetime of design team.
- Sam - will probably convert IESG Notes to IONs if the ION experiement succeeds.
Jon Peterson - no
Tim Polk - will hold trust anchor management BOF in Chicago, but not for working group formation (in Chicago).
Dan Romascanu - no
Mark Townsley - no
David Ward- no
Magnus Westerlund- not on call