Narrative Minutes
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the February 21, 2008 IESG Teleconference
Narrative scribe: Spencer Dawkins <spencer@wonderhamster.org>
With corrections by: Lisa Dusseault, Russ Housley, Magnus Westerlund, Jari Arkko, Dan Romascanu
1. Administrivia
1.1 Roll Call
Pasi Eronen (new SEC AD, replacing Sam Hartman after IETF 71) joined his first telechat
1.2 Bash the Agenda
Cullen - haven't done anything anything management item about RFC Errata on agenda - remove it?
Russ - wanted to hear what Tim learned.
Jari - want to ask about whether it's OK to publish statistics, and want to put the ERX discussion as the last document (still working on it :-)
1.3 Approval of the Minutes
2007 01 24 - Narrative Minutes (revised) went out this morning - but there are still two "what was this really?" questions. Spencer pinged for corrections on the call. Magnus sent e-mail on one correction.
2007 02 07 - Minutes approved with no discussion
2007 02 07 - Narrative Minutes approved with no discussion - Spencer will send clean copy
1.4 Review of Action Items
IP o Lisa Dusseault to develop statement about IESG Policy with respect to RFC 3406 registrations.
Lisa - Completed, on agenda today
IP o Sam Hartman to write a draft explanation of informational balloting.
Sam - Really will do this before next telechat
Russ - Sam is on agenda for Sunday at IETF 71 to discuss this
IP o Lars Eggert to find primary and secondary experts for Port Numbers.
Lars - primary will be Allison, need more than one secondary. There is a new document describing procedures that needs to be discussed.
IP o Cullen Jennings to develop a policy statement on how to handle errata.
Cullen - in progress
IP o Cullen Jennings to develop suggestions for tool changes for errata processing.
Cullen - in progress
IP o Tim Polk to process at least two errata for Security Area specs. DEADLINE: February 21, 2008.
Tim - looked at 4909 (Mikey extension) and 4956 (DNS security) - from Alfred, 6 items, 2 were important enough that (if verified) should be associated prominently with document (interop issue). One item needed to go to working group chairs. Will need to make sure that people see errata that really affect interop - and there are some of these.
IP o Dan Romascanu to send mail to nmrg/irtf proposing two options to move forward:
1. Last Call their document for the specific question according to the current RFC 3688 text, or
2. Defining a urn:irtf... space for the IRTF to manage.
Dan not here today ... in progress :-)
IP o Lisa Dusseault to resolve the ambiguity in registration requirements in RFC 3866.
Lisa - also on agenda for today - done.
IP o Mark Townsley to decide and report whether RFC 2784 is an update to 1701 or not.
Mark - done.
Cullen - would like that mentioned in minutes.
Jari - More complicated than "yes"/"no".
Mark - I was asked to answer the question, that's all.
Russ - just need to send RFC Editor with official answer - which is "no"
Jari - no, there are some updates
Russ - either does update or doesn't
Jari - need to get linkage correctly.
Mark - we do have some issues to resolve, but not on this call.
Russ - answer should say what is, is not updated.
Mark will send a note to the RFC Editor that indicates:
1) RFC 2890 updates RFC 2784. Neither are an update of RFC 1701 or 1702.
2) RFC 1702 is not supposed to be an update of 1701, it's supposed to
be an orthogonal and complementary document.
IP o Cullen Jennings to draft a response for the chair to reply to the ITU-T on the subject of ITU-T/IANA coordination.
Cullen - think it's done. Right, Russ?
Russ - it's done.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-ecrit-dhc-lost-discovery-02.txt
A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure (Proposed Standard) - 1 of 3
Token: Jon Peterson
Jon - don't need to discuss today. DISCUSSes are actionable, will make the change. Revised ID needed.
o draft-ietf-ecrit-lost-07.txt
LoST: A Location-to-Service Translation Protocol (Proposed Standard) - 2 of 3
Token: Jon Peterson
Was DEFERRED to next telechat.
o draft-ietf-hokey-erx-11.txt
EAP Extensions for EAP Re-authentication Protocol (ERP) (Proposed Standard) - 3 of 3
Token: Tim Polk
Jari - just sent out e-mail on this.
Tim - start with Sam - haven't followed up on either DISCUSS, but you're right about domain authorization is being handled correctly. Does that discussion need to happen in this document?
Sam - if you have two domains with same identifier, or have home domain/visited domain communication in authorization, there are two problems - peer can't authenticate authenticator because channel isn't trusted, and if you have two people claiming to be the same domain, you may distribute key material to both of them - that case is critical. If you care about channel, you have to bind name to identity - needs to be discussed.
Tim - understand and agree.
Tim - Jari, wording can be improved but not sure if other solutions were discussed in working group - need to talk to authors/chairs. Think interop for legacy clients is assumed to be handled correctly, may be statement about what's expected isn't in document. Fourth point is a real concern - Bernard thinks implementations will/might fail if you have an unrecognized code. Standard requires that you handle these, but not everyone implements correctly.
Jari - not extremely concerned, just checking to see what information we have about this.
Tim - didn't identify a specific implementation would fail. We can check with him again on this.
Jari - as I started reading, I got a bad feeling. Cleared up a lot, it's not as bad as I thought when you lose first packet. Think the legacy handling is MUST, not MAY. Look at timing and legacy implementation issues.
Tim - they've looked at all Bernard's issues. Not sure Bernard agrees completely.
Jari - should let Bernard have chance to respond before we approve.
Tim - revised ID needed anyway, we have what we need to work with this.
2.1.2 Returning Item
o draft-ietf-mip4-mobike-connectivity-03.txt
Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE (BCP) - 1 of 2
Note: Document Shepherd is <pete.mccann@motorola.com>
Token: Jari Arkko
Jari - this is old document, put on hold for solution document. Still has IPv6 details to work out. Anyone objecting to approving now?
Sam - had a bunch of duplicated text from other document, IIRC. Would approve if text is up to date. You worked with Tim on my DISCUSS, right? don't want to second-guess Tim.
Tim - I think Sam's DISCUSS is satisfied.
Approved on this call.
o draft-ietf-mip4-vpn-problem-solution-04.txt
Mobile IPv4 Traversal Across IPsec-based VPN Gateways (BCP) - 2 of 2
Note: Document Shepherd is Henrik Levkowetz
Token: Jari Arkko
Jari - don't need to DISCUSS today, waiting for author to respond to Tim.
Tim - only remaining questions are from use-ipsec.
Sam - reasonable to publish without that?
Tim - reasonable to publish after that. Should I take on your DISCUSS? that's probably the right strategy - will update my DISCUSS.
Jari - will remind authors we need additional text. Revised ID needed.
Russ - Sam, can you update your DISCUSS to focus on Section 4/use-ipsec?
Sam - that's what Tim and I are going to do. Having some access issues.
Amy - will clear for Sam, and Tim will hold the use-ipsec DISCUSS.
2.2 Individual Submissions
2.2.1 New Item
o draft-klensin-net-utf8-09.txt
Unicode Format for Network Interchange (Proposed Standard) - 1 of 3
Note: AD is shepherding
Token: Chris Newman
Chris - can just ask authors to make any changes in AUTH-48?
Lisa - that's fine.
Jari - yes, that's fine.
Document was approved on this call.
o draft-harrington-text-mib-doc-template-04.txt
A Template for Documents Containing a MIB Module (BCP) - 2 of 3
Token: Dan Romascanu
Dan isn't here, can't DISCUSS
Cullen - DEFER to next agenda - should have already done this.
o draft-melnikov-imap-search-res-07.txt
IMAP extension for referencing the last SEARCH result (Proposed Standard) - 3 of 3
Note: AD is shepherding.
Token: Chris Newman
Document was approved on the call with no discussion.
2.2.2 Returning Item
o draft-cheshire-ipv4-acd-06.txt
IPv4 Address Conflict Detection (Proposed Standard) - 1 of 1
Note: Back on the agenda so I can be sure there are no more discusses, and if enough positions have been recorded. The text ballot is broken.. This is for version -06 which should arrive in the repository soon. Otherwise, you may find it here:
http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-06.txt
Token: Mark Townsley
Mark approved this morning, no reason to mention on this call.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-speermint-consolidated-presence-im-usecases-04.txt
Presence & Instant Messaging Peering Use Cases (Informational) - 1 of 4
Token: Jon Peterson
Russ - concerned about number of ABSTAINs.
Jon - understand where people are coming from, tricky space. This is what large IM carriers are doing. There are privacy concerns. Interop won't be possible without scaling, and speermint is going to have this problem again.
Sam - are we committing to publish solutions that solve this problem? I wouldn't approve them. Should let people know they will hit a significant IESG hurdle.
Jon - this is people documenting practices in existing networks, and speermint isn't a protocol working group anyway. want to think about underlying protocol requirements for these use cases. speermint can't do more than that.
Lisa - as use cases, these are terrible because they lay out a scenario that's assumed rather than explaining user need.
Jon - not happy with this either, didn't think it was going to get better. Also suffers because IM presence isn't popular service (like voice). But not in love with this.
Tim - is value in calling attention to privacy concerns - just satisfying one of these use cases won't be enough. Sam suggested note on document.
Jon - wouldn't object. Not dire enough for IESG statement, but wouldn't object. Focus on requirements document instead - that determines what's in scope. Encouraged people who don't have Internet PoV to submit use cases. Don't want to end up with documents that have been sanitized from the way operators really operate.
Chris - wasn't clear to me what use cases were about. Uncomfortable publishing without some statement - doesn't have to be IESG Note, just a statement would be fine. But this isn't no-obj if it has use cases that reflect a bad design.
Jon - would prefer that, actually. That's reasonable.
Russ - RFC Editor note?
Jon - that would be fine.
Russ - document status is approved - point raised.
o draft-ietf-hokey-reauth-ps-08.txt
Handover Key Management and Re-authentication Problem Statement (Informational) - 2 of 4
Token: Tim Polk
Tim - Jari's DISCUSS is clear, and I think Russ's is also fixed if we fix Jari's. Lots of open positions. Should be revised ID available soon.
Russ - INFORMATIONAL, don't need the votes, just clear the DISCUSSes.
o draft-ietf-ecrit-mapping-arch-03.txt
Location-to-URL Mapping Architecture and Framework (Informational) - 3 of 4
Token: Jon Peterson
Jon - DISCUSSes are OK. Will take Cullen's point back.
Russ - mine was a DISCUSS DISCUSS. Wasn't this PS originally?
Jon - no, this is ARCH. Don't think this one was PS. Charter says INFO.
Russ - confused by Gen-ART review - reviewer thought it was PS. Clearing now.
Cullen - will be DISCUSS on LOST about this.
o draft-ietf-mipshop-fh80216e-06.txt
Mobile IPv6 Fast Handovers over IEEE 802.16e Networks (Informational) - 4 of 4
Note: Document Shepherd is Vijay Devarapalli
Token: Jari Arkko
Jari - Tim has valid questions, expect we have answers but may require text tweaking. Is INFORMATIONAL, document is clear on using 802.21 as example. Would that work for Tm?
Tim - text is tied closely to 802.21. Want to understand what happens when 802.21 changes - it's not stable today. Felt more normative than informative.
Jari - I'm sure your security comments are correct and will address them. Revised ID needed.
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-brenner-dime-peem-01.txt
Diameter Policy Processing Application (Informational) - 1 of 1
Token: Dan Romascanu
Cullen - cleared my DISCUSS, but document extends DIAMETER way outside what the applicability statement of DIAMETER specifies. Does anyone care?
No one cared, so this document was approved on the call with no discussion.
3.2.2 Returning Item
NONE
3.3 Independent Submissions Via RFC Editor
3.3.1 New Item
NONE
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Timing over IP Connection and Transfer of Clock (tictoc) - 1 of 2
Token: Mark Townsley
No discussion of charter being sent for external review on this call.
o Internationalized Domain Name (idn) - 2 of 2
Token: Lisa Dusseault
Sam - did Lisa get a chance to update milestones?
Lisa - didn't do it.
Sam - doesn't need to happen before external review, but March 08 is unrealistic.
Lisa - being a little unreasonable does help chairs manage to a schedule...
External review was approved on this call.
4.1.2 Proposed for Approval
NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
NONE
5. IAB News We can use - Olaf
Meeting yesterday. Request from Jon on infrastructure ENUM for IAB input, invited Jon and ENUM co-chairs to Sunday afternoon agenda to discuss issues.
ICANN asking for feedback on new top-level TLDs - request is about creating a bunch of these. Will poke DNS directorate.
We have IESG/IAB lunch topic on APPS workshop report. For technical plenary, two presentations, one on IPTV (Marshall) and P2P Internet Video (Keith Ross) (on transport, with P2P focus).
Had executive session on RFC Editor RFP, ensuring community can provide feedback at appropriate times.
Cullen - will you send plenary presentations to IESG at some point? Would I be providing comments at mike for the first time?
Olaf - we don't see them much in advance of the meeting, either.
6. Management Issue
6.1 Enforcement of IDnits for document submission (Chris Newman)
Chris - complaints from active participants about IDnits enforcement, at least one was a bug about 15 pages. Can we make sure only audits we do are the critical ones (boilerplate, etc).
Russ - brief period when secretariat didn't understand there are two sets of critera (accepting drafts and forwarding them for publication).
Magnus - impression is that tools team hacked so they don't enforce everything on individual submissions.
Russ - Chris, are you still hearing about problems in the last ten days?
Russ - The file program on the variant of UNIX being used by AMS was treating files that include "(if approved)" as Lisp programs.
Magnus - think boilerplate indication is now fixed, too. Any issues remaining that you know of?
Russ - know there was a problem, AMS addressed it aggressively, so if there are still problems, please send tickets to ietf-action@ietf.org.
Chris - good enough for me.
Cullen - what changed?
Russ - training issue with new secretariat plus infrastructure transition - some stuff broke. Did not change policy.
6.2 IESG Statement on RFC3406 and URN Namespaces Registry Review (Lisa Dusseault)
Lisa - is everyone happy? ("Ship it!", "Beautiful!")
Amy - does this go on website, ANNOUNCE, DISCUSSION?
Russ - goes to all three places. Last time we did this, subject line didn't say "IESG statement on" - please prefix subject so we don't have confusion/three rounds of discussion on those lists.
6.3 IESG Statement on Registration Requests for URIs Containing Telephone Numbers (Lisa Dusseault)
Lisa - Cullen convinced me.
Cullen - statement is carefully phrased, won't prevent us from doing another one.
Statement will also be announced (same places as previous statement).
6.4 IESG Statement on RFC3688 XML Registry Process (Lisa Dusseault)
Magnus - Jari sent an e-mail. Are the proposed statement still doing a change of rules for the registry? I have trouble understanding the full intent.
Lisa - may not have to issue a full statement, but there was disagreement about what the statement meant (first come/first served + IETF consensus).
Jari - if IANA registration is unclear, can we clarify that? does the IESG have a power to clarify what the rule really is?
Cullen - nothing unclear, IANA registration is wrong. Good thing to discuss.
Lisa - we mostly agree this is IETF consensus - at least convinced Dan on this.
Jari - if we all agree, should send mail, tell IANA to fix it. If it's wrong, should find author and fix document. Has even the IESG given up on idea that RFCs can be published in timely manner?
Lisa - only one registration since I've been approving these, probably not worth an RFC.
Jari - but RFC is our process to know what IANA rules are.
Lisa - understand. Errata? but that's a huge change for errata.
Magnus - agree.
Lisa - stronger than a statement - it's a policy. Not important either way. Just e-mail IANA and ask them to change registration process?
Michelle - still not 100 percent clear. Two different registries in RFC, appeared to have two different requirements. Just trying to get clear on both registries. Whatever decision is, is totally fine. Just want to make sure we're all talking about the same thing.
Lisa - can bring this back to next telechat, or handle via e-mail. Won't be IESG statements.
Magnus - agree that RFC 3688 is unclear in its IANA section.
Michelle - just need to be clear, and move on.
Lisa - will follow up on two different registries.
6.5 - RFC Errata (Russ Housley)
Tim has provided last inputs, Cullen will provide text for this and we'll discuss.
Tim - if we're going to have errata, need to think about how we make errata obvious. Some errata were really important. If we're going to identify important errata, need to make sure that you can find them.
Cullen - "may have errata at following location", show errata in tools. Not sure what else we can do that we're not already doing.
Tim - older links point to non-tool files (plain-text repositories)
Cullen -need to explain to community that we're producing them - telling community errata aren't useless is the best we can do.
Will come back to agenda on March 6.
6.6 draft-ietf-smime-symkeydist-10.txt (Russ Housley)
Russ - sent mail with diff. This document has been in RFC Editor queue for five years, in ref-wait. Reference is finally in queue, author looked at other references and submitted new draft. Don't want to put this on agenda but want ADs to have a chance to comment on document (because it's been sitting waiting in the queue with the IESG for a long time. Please speak now, or forever hold your peace...
Amy - alert RFC Editor that there's a new version of the document? It's been posted (on January 28th)
Russ - will draft a ticket to notify RFC Editor
6.7 IESG Statistics (Jari Arkko)
Talked about this last September - Jari collects statistics, OK for them to be public? Had concerns then about reliability (number of documents per AD). Document updated now, disclaimers at beginning about who owns time intervals, etc. Any objection?
Cullen - worried early on, meant to review carefully. Thought disclaimers were good. Purpose isn't to compare ADs or areas, but that's what these statistics would reasonably be used for. You can publish these without IESG permission, don't want to block this.
Jari - could have pages by AD, not comparisons.
Cullen - make a pass to ensure stats are useful. What should you go do?
Jari - I would like Cullen's help to go over these statistics and make them more useful.
Jari: in any case, I came here to ask whether there's an objection is to removing the authorization?
(No objection)
7. Agenda Working Group News
Jari Arkko
- SAVI - required threats document. Danny has been working on it, didn't make the deadline, can't approve it any more even if I had the document today. What should I do - proponents want a meeting, I'm talking with Danny about waiting one IETF cycle because we don't have the document, don't have solutions, don't want to repeat the BOF experience. Meeting slot exists - I reserved it, but it's not a WG, and they aren't ready for a BOF. Seems silly.
- Lars - enough people to justify a slot?
- Jari - would be, if you scheduled a meeting.
- Russ - IESG breakout room plus announcement of meeting?
- Jari - if they do not get an official slot the added benefit is that we do not have people from IAB etc asking nasty questions about what problem they are solving, why they have been granted a slot, etc -- all questions they are unable to answer at this time. Better to give them a shielded place to prepare their work until they are ready.
Lars Eggert
- Draft-cotton on IANA registration for UDP/TCP ports
- two liaison statements from ITU-T to me personally
- Russ - did you send to statements@ietf.org? doesn't get posted on website as liaison statements
- Flowreq - can't do this in ITU-T, have to do this in IETF, but no deadline.
- PCN - struggling with basic architecture, not doing well, lots of discussion, leaning toward letting them publish architecture and close working group - ITU-T interest won't help, but Huawei chairs in ITU-T want to use PCN as component in ITU-T architecture proposal and develop protocols around it. Scheduled breakout session during IETF week but telling ITU-T that it's too early to do this, and telling them working group may not survive anyway.
- Mark - what SG?
- Loa - liaisons came from SG11.
Russ Housley
- IPR finished last two documents, expect last call soon and please comment early (as opposed to late)
Chris Newman
- one chair in LEMONADE posted little-bit-ill-considered message, doesn't look like appeal, looks like will be worked out, but wanted to give heads-up. Think it will be worked out with no involvement from me.
Tim Polk
- need a new co-chair for TLS (replacing Pasi)
Magnus Westerlund
- Not sure how we're going to get TURN published in a reasonable timeframe.
- Cullen - strong opinions about what's appropriate to deploy - ADs don't agree with authors. Need to meet in Philly.
- Magnus - when you're building a router at a higher level, these issues happen.