Narrative Minutes

Narrative Minutes for the January 10, 2008 IESG Teleconference

Narrative Scribe: Spencer Dawkins <>

With corrections from: Jari Arkko, Lars Eggert, Lisa Dusseault, Russ Housley

1. Administrivia

1.1 Roll Call
1.2 Bash the Agenda
1.3 Approval of the Minutes

2007 11 29 Narrative Minutes - approved with no discussion, Spencer will submit final copy

2007 12 20 Minutes - approved with no discussion

2007 12 20 Narrative Minutes - Spencer sent out corrected narrative minutes this morning, will approve on next telechat. Spencer also tugged at forelock for not getting approval copies sent out earlier.

1.4 Review of Action Items

o Lisa Dusseault to find an author to update RFC 3406.

Lisa - no action

o Jari Arkko to write an explaination of IESG policy of when ADs can request documents be considered by the IESG before the Last Call has

Jari - still no progress

o Cullen Jennings to get a response from the AVT WG to help solve an IANA Registration issue for wave-avi-codec-registry [IANA # 97962]

Cullen - final stages, will have this in a week

o Sam Hartman to write a draft explanation of informational balloting.

Sam - in progress, should be able to get this out soon

2. Protocol Actions

2.1 WG Submissions
2.1.1 New Item
o draft-ietf-psamp-sample-tech-10.txt
Sampling and Filtering Techniques for IP Packet Selection (Proposed Standard) - 1 of 9
Token: Dan Romascanu

Dan - let's discuss DISCUSSes - both Ross and Ron raise question of "why PS"? This is part of a set of four documents, with two more in the pipe, that use definitions and parameters defined in this document as normative references.

Ron - didn't we have same same issue in L3VPN?

Sam - but L3VPN framework wasn't normatively referenced, I would have objected if I'd noticed that.

Russ - as long as references aren't normative, informational works

Ross - if you look at sampling part you can figure out several ways to implement, generally lots of ways to implement. There really isn't an interop issue, different systems don't interoperate (except at protocol level). Almost inconceiveable that someone will implement everything.

Dan - don't think document claims or requires this will happen.

Ross - almost reads more like "here's all the various things you could do". Carriers will ask vendors to implement specific stuff, may require ASIC updates, ISPs will argue for small pieces to implement and various requested pieces will be different. This looks like a framework to me. But there is a normative reference from the protocol documents.

Dave - agree, but there are two pieces that define PSAMP (sampling and filtering) that show up in this document. Would have to remove these pieces to go informational.

Sam - importanf to define things consistently because you'll want to compare outputs - need same behavior. Needs to be normatively referenced somewhere.

Dan - why wouldn't we improve introduction section to explain reasoning for proposed standard and point out the sections we expect to be normatively referenced?

Ron - I think that would fly, not a great sin to make something a PS that didn't need to be. But I still have DISCUSS from Fred Baker.

Ross - any document has some part that's purely informational.

Dan - so we are lowering the concern about service providers? Will do more work, response to Cullen just arrived 15 minutes ago. Put this on AD followup anyway and Cullen can feedback to me.

o draft-ietf-enum-calendar-service-03.txt
A Telephone Number Mapping (ENUM) Service Registration for Internet
Calendaring Services (Proposed Standard) - 2 of 9
Token: Jon Peterson

Jon - Lisa, have you contacted Rohan independently?

Lisa - yeah, Rohan agreed with separating the two parts if I came up with names for them.

Jon - can you help if Rohan doesn't produce a revision in a reasonable timeframe?

Lisa - I can help.

Jon - Maybe use an RFC Editor note? Put this into AD followup.

o draft-ietf-shim6-proto-09.txt
Shim6: Level 3 Multihoming Shim Protocol for IPv6 (Proposed Standard) - 3 of 9
Note: Please also read draft-ietf-shim6-applicability. Document Shepherd is Geoff Huston <>
Token: Jari Arkko

Jari - thought I moved this to next agenda - bring back HBA in this slot? :-) Dan cleared his DISCUSS, Dave Ward has proposed text in RFC Editor note - is that good enough?

Dave - I'll check and give you feedback by e-mail.

Russ - minutes should say "moved to next agenda by Jari".

o draft-ietf-sieve-body-07.txt
Sieve Email Filtering: Body Extension (Proposed Standard) - 4 of 9
Token: Lisa Dusseault

Lisa - Tim's comments are reasonable, will figure out how to deal with them.

Tim - heard back from authors, I'm the slow one. Authors are assuming things from 3028bis and I didn't think these things were being inherited. Straightforward.

Lisa - AD Followup.

o draft-ietf-pkix-rfc3280bis-10.txt
Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile (Proposed Standard) - 5 of 9
Token: Sam Hartman

Sam - will ask authors to respond to Chris's COMMENTs - not blocking, but the issues Chris raised matter. Approved, point raised, write-up needed.

o draft-ietf-psamp-protocol-09.txt
Packet Sampling (PSAMP) Protocol Specifications (Proposed Standard) - 6 of 9
Token: Dan Romascanu

Dan - same answer to Cullen, do we have time to go through it?

Cullen - PSAMP is missing hash functions specification - can't find them in the MIB, don't see how you build a system. Should clear because it's not this document, but what document has the problem? (psamp-sample-tech)

Magnus - have you seen my comments?

Dan - think your concern is with high peaks and timestamps? don't have an answer from authors, but isn't this IPFIX and PSAMP issue using microseconds?

Magnus - would like to have answer, understand the purpose.

Dan - will get answer, but this is a general issue. Cullen, you said you're going to clear?

Cullen - preference is to wait, but can clear. But need hash functions defined somewhere.

o draft-simon-emu-rfc2716bis-13.txt
The EAP TLS Authentication Protocol (Proposed Standard) - 7 of 9
Note: Joe Salowey is the proto shepherd
Token: Sam Hartman

DEFERed this morning.

o draft-ietf-msec-ipsec-extensions-07.txt
Multicast Extensions to the Security Architecture for the Internet Protocol (Proposed Standard) - 8 of 9
Note: Lakshminath Dondeti is the proto shepherd.
Token: Tim Polk

Lots of open positions on this document, and no one stated one on the call...

Tim - clearly this is revised ID needed, a lot of work to get votes, even more to clear DISCUSSes. Does Russ's DISCUSS capture Sam's issues?

Sam - I think so, hoped that someone would capture my concerns and make them actionable so I don't need to fix this before leaving IESG. The document needs to be fixed, publishing it in this form is worse than saying nothing. Decide how long much time you're willing to spend on this draft.

Tim - can go revised ID needed, we'll see how long this takes.

o draft-ietf-sip-consent-framework-03.txt
A Framework for Consent-based Communications in the Session Initiation Protocol (SIP) (Proposed Standard) - 9 of 9
Note: Keith Drage is the document shepherd
Token: Cullen Jennings

Sam - going ABSTAIN, I have concerns but don't want to block it. Let me describe - mechanism seems useful but authors want it applied everywhere and think there's a problem if it's not - not realistic, maybe not even desirable. Remember document transferring calls between devices, etc. Not clear that in a trusted environment that all devices will even be able to respond to all this. Author's concerns are overwrought.

Cullen - authors thinking that they were talking about scenarios like one relay.

Sam - but that's not what the document says. If you want to fix that, involve me in the discussion, I just don't want to block this document.

Cullen - Lisa/Lars/Tim DISCUSSes - I understand and they're straightforward. Chris, suspect this is similiar. Sometimes the draft sounds like it solves problems that it doesn't solve, need to be clearer about this. Need to authorize who the original sender was - we have that, but idea of authorizing anyone who belongs to a certain list isn't part of the document today - we could look at that. What else?

Chris - rigidly specified attack surfaces for dynamic attacks, attackers will adapt. You're missing "only subscribers can post" mechanism from e-mail - seems glaring omission.

Cullen - but that's about who the relay can send to, not who can send to the relay. I do agree you can't figure that out from reading the document.

Chris - looks like accept from anywhere, autormatically forward to all previously approved recipients. Clearing that up will go a long way. Other thing was "MUST provide SIP URI as consent mechanism" - some people will have reasons to do something else (SHOULD).

Sam - agree with point about dynamic attack surfaces but disagree because web services have interfaces that are TOO dynamic (porn sites that collect CAPTCHAs). Could do better thinking about this in standard context.

Cullen - can't assume much in e-mail that anyone can do. This is different. I want to put something in place before everything is deployed.

Chris - MUST implement, but not MUST use.

Cullen - Oh, that's all the difference. Oh.

Chris - if far-end knows what makes sense, should be able to do what makes sense.

Cullen - black phones with no displays.... do what makes sense?

Chris - we need mandatory-to-implement, like we have for security authentication. That gives you what we want.

Sam - if you don't do that, people will do it anyway. Still have concerns but don't object.

Chris - will clarify so DISCUSS will be more actionable. If you go mandatory-to-implement, not mandatory-to-use, that will help a lot.

Cullen - will also mention accept-from problem.

Sam - but some devices will accep callst from anyone. My desk phone probably would accept a call from anyone.

Jon - but your phone isn't a relay

Sam - but it could be

Cullen - devices like that are is exactly where spam-porn-CAPTCHAs would be running... revised ID needed.

Sam - I'm a NO-OBJ on this document.

2.1.2 Returning Item

2.2 Individual Submissions
2.2.1 New Item
o draft-arkko-rfc2780-proto-update-02.txt
IANA Allocation Guidelines for the Protocol Field (BCP) - 1 of 1
Token: Russ Housley

Russ - don't understand Dan's "DISCUSS DISCUSS", asking Jari to help me understand it.

Dan - how does IESG consensus process work for requests coming from outside the IETF? We're supposed to prevent duplication, stable specification, etc.

Jari - IESG approval is fallback case, not normal case, we use our judgement in special cases, hard to provide hard guidelines.

Dan - but how does this work?

Sam - when this happened the last time, IANA brought us a management item, we said no, we got a lot of e-mails.

Dan - we have another document (ethernet IANA), same problem in a broader space. People arguing "need an RFC for any request", these are OUIs. Leaves the door open for process that involves entire IESG.

Jari - should this be clarified in this document, or in the IANA-bis draft?

Dan - just cleared, but this isn't clear to me.

Sam - saying "if you want IESG approval as an option, prepare specific guidelines for IESG to use in evaluating". Harm the internet? Pure stewardship? reasonable to ask document to provide guidelines, it already does. So we'd have a response that says yes or no based on guidelines. Not sure that we need IESG approval as an option.

Jari - it's in many protocols. Requiring standards-track has problems with IRTF Experimental protocols even when allocation makes sense - that's why the fallback is here.

Dan - I cleared.

Amy - This document is approved.

2.2.2 Returning Item

3. Document Actions

3.1 WG Submissions

3.1.1 New Item
o draft-ietf-btns-prob-and-applic-06.txt
Problem and Applicability Statement for Better Than Nothing Security (BTNS) (Informational) - 1 of 5
Token: Sam Hartman

Russ - My DISCUSS is the same as Sam's - I'll clear.

Sam - Tim's DISCUSS - strong consensus in BTNS BOF to tell community when they should use BTNS - this document does that. Let people know what the tradeoffs were. Two scenarios - no security anyway/security to passive attackers, or channel binding. Two very different environments with different properties. People who care about channel bindings have done the work. Would like to strongly disagree with DISCUSS that higher-level authentication is likely to be stronger than IPsec - if you deploy higher-level authentication, it's likely to be weaker and an afterthought. This is not the case where people have IPsec infrastructure they care about, it's where people care about application, and not IPsec.

Tim - agree that this is mostly what the document says, but one section seems to vary from this. Want to check consistency with other sections.

Sam - sure, channel binding is still valuable if you have good infrastructure, point is to make authentication at both levels succeed, not just one. Make sure that document provides guidance. Decide how much time you want to spend on this document. Authors take a little effort to work with.

Tim - document isn't harmful in its present condition, but doesn't communicate as effectively as it could. Worth spending some time on this. Not willing to put in DISCUSS on Steve's comments because wasn't sure they were actionable, but Steve identified areas that were also problematic for me. Will revise DISCUSS.

Sam - fine. If you do take on "describing solutions", that's particularly challenging (even if it's particularly useful). Steve also points out some examples have been overtaken by events - can't imply that BGP would use BTNS, this isn't going to happen.

Tim - reasonable change.

Sam - don't object to you saying that, too.

Tim - believe it's important that document is guiding other working groups, need to highlight this in an actionable DISCUSS. First DISCUSS went only to IESG. Revised DISCUSS will go to everyone, not just IESG.

Amy - Russ cleared his DISCUSS, Sam and Tim are keeping theirs.

o draft-ietf-v6ops-802-16-deployment-scenarios-06.txt
IPv6 Deployment Scenarios in 802.16 Networks (Informational) - 2 of 5
Token: Ron Bonica


o draft-ietf-bmwg-ipv6-meth-04.txt
IPv6 Benchmarking Methodology for Network Interconnect Devices (Informational) - 3 of 5
Token: Ron Bonica

Ron - this is revised ID needed, no discussion necessary.

o draft-ietf-v6ops-rfc3330-for-ipv6-03.txt
Special-Use IPv6 Addresses (Informational) - 4 of 5
Token: Ron Bonica

Ron - DISCUSS is pretty easily dealt with, revised ID needed.

Russ - Marc Blanchet pushed back on Mark's response.

Mark - what's odd here is that at the end of the day Teredo is in this RFC AND in the IANA IPv6 registry - it's the only one. There are even other concluded experiments in this document. Seems inconsistent. Could solve with RFC Editor note, but something needs to be done.

Ron - put revised ID needed, will work this out on the next call.

o draft-ietf-nea-requirements-05.txt
Network Endpoint Assessment (NEA): Overview and Requirements
(Informational) - 5 of 5
Token: Tim Polk

Tim - would like to DISCUSS one aspect - NEA is chartered to include generic requirements for posture transport protocol, but NEA shouldn't be specifying posture transport protocols themselves. Hadn't lost sleep over this aspect, looked at DISCUSSes and are concerned that generic requirements may not be practical - both Jari - and Lars were concerned about this. Where is the train wreck?

Lars - they state PR protocol should have multiple possibilities, but almost none of them will work without extension (EAP, IKE, 802.IX). TLS over TCP is the only thing they can actually use. Talking to lots of devices before you connect to the network is chicken-and-egg - doesn't work. Intersection of requirements is the empty set.

Sam - for EAP, EMU wants a tunnel method, as soon as they get a new charter to me, tunnel method would be flexible enough to carry NEA but that doesn't support "lots of data problem". Discussion will need to happen and will not be trivial.

Jari - train wreck is in the future. Problem is that when you fix the short-term problems with TCP/TLS and RADIUS, you reduce the applicability way below "generic" - hope people are ok with this.

Sam - if document doesn't say TCP/TLS for server-initiated, it needs to. Nothing else is going to work.

Tim - ask working group to review requirements and either say "can be satisfied" or redo the requirements?

Jari - three options: convince us this can actually be implemented, reduce requirements, or honestly declare requirements are hard and can only be met in limited conditions.

Lars - agree that the initial communication is the hard part. Need expressive description language, probably not even binary. Can't use any existing layer 4 transport protocols for reliability, etc. Have to add to EAP, etc. - that will be hard. Not clear what they need - not a byte stream, but a bunch of messages from upstream devices. Assume reliable transport or this won't work. If we were piggybacking a couple of messages, no problem, but the're sending significant amounts of data.

Jari - Issue is that EAP isn't efficient and is stop-and-wait across the internet.

Magnus - would like to DISCUSS my DISCUSS. When I read this document, got impression that we're always talking point-to-point. Don't get impression that this is realistic deployment mode. Whole description leaves out the procedures that would be used.

Tim - agree with your DISCUSS, it's out of scope for WG charter but required to discuss at requirement level (confidentiality, etc). Hopefully won't have to spend a lot of time on these two entities but needs to be clear this is part of a bigger system. Please leave your DISCUSS in place, will get 2119 language fixed, too. Other comments were straightforward, needs to be revised ID needed.

3.1.2 Returning Item

3.2 Individual Submissions Via AD

3.2.1 New Item
o draft-adolf-dvb-urn-03.txt
A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB) (Informational) - 1 of 1
Token: Lisa Dusseault

Lisa - Tim's "URLs are unique" was an English problem, I read right through this, wasn't as clear as it should be

Lisa - Lars has identified an issue with service names. Leaves Cullen's DISCUSS.

Cullen - this is a DISCUSS DISCUSS, couldn't understand the document and couldn't get the references.

Lisa - is this the way ETSI documents work?

Cullen - normally I can get them, but I couldn't find them, couldn't understand document without them. Don't understand what resolution stuff is, whether people are using these as URIs or URNs. Either could be reasonable, but I don't understand this from the document.

Lisa - will try to pull Leslie Daigle in to help with this.

Cullen - not even sure this qualifies as a DISCUSS

Lisa - definitely revised ID needed.

3.2.2 Returning Item
3.3 Independent Submissions Via RFC Editor

3.3.1 New Item
3.3.2 Returning Item

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o vCard and CardDAV (vcarddav) - 1 of 3
Token: Chris Newman

Sent for external review with no discussion on this call.

o Routing Over Low power and Lossy networks (roll) - 2 of 3
Token: David Ward

Magnus - would like to see Lar's text on this charter.

David - new text on website has Lars' text and additional sentence you asked about.

Magnus - no problem going forward for IETF review.

David - you wanted to explicitly say "routing protocols" instead of "applications", right?

Magnus - not sure where right place to talk about transport is.

David - sentence is to nudge TSV to set up a ROLL-TSV working group, right? Don't need to wordsmith this :-)

Magnus - need to think about transport for routing protocol itself, too.

Jari - sent mail with text suggestions as well. One was charter didn't say "framework only until you look at current work", one was broad mobility text.

David - we have recharter at the bottom, and framework is roadblock for additional work. Most of the drafts are underway, including analysis. In reality, everything will happen in parallel.

Jari - OK with that, will you still insert the better scoping text for mobility?

Dave - Yes, will do. Does Magnus want to flog me on the dates?

Magnus - April is very aggressive.

David - OK, we'll push this to Dublin (out one quarter).

Mark - 6LOWPAN chair, speaking as individual - dates, plus rationale for selection of four areas of interest. Not sure what you want to do there, but do you have some idea what WG will do to evaluate alternatives.

David - community chose those four alternatives by consensus. Justification was Chicago/Vancouver BOF focus. There's a document on each of the four areas, with justification and boundaries.

Mark - maybe these could be referred to explicitly... Routing metrics as Informational - how can you do this if they're used for routing?

David - this is more description about why new metrics are needed - explanation, terminology, etc. Not about calculating best paths, etc - that's in the protocol specifications themselves.

Mark - I see what you're getting at here, but can't turn around and reference from routing protocol without downref, you're setting yourself up for this. If it is just "these are the kinds of metrics that might exist", why not part of the routing requirements?

David - could have same duplication of text.

Sam - but this isn't normative?

David - how do we get around this problem?

Sam - either don't state a publication class, or PS could be OK. Let the working group figure this out. WG can always downgrade from PS - and so can the IESG.

David - I like that plan.

Mark - if you target proposed standards, might have different metrics, if you can tease out common metrics as proposed standard it's easier to actually use those metrics in protocol documents. Shoot high. If you can't get there, you can go informational. Also concerned about routing architecture.

David - no decision about completely distributed algorithm, centralized, etc. Need to identify the routing architecture in a framework to figure this out.

Mark - no objection to external review with these small changes.

David - Ross, Ron OK? OK.

o Cga & Send maIntenance (csi) - 3 of 3
Token: Jari Arkko

Jari - will take care of Russ's comment.

Russ - so we need to wait for text from Jari

Amy - approved, pending new text.

4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval

5. IAB News We can use (this was mostly cut-and-paste from Olaf's text in Jabber)

IAB NAT-PT; ongoing active work

OMA Liaison; not an AP; Dean still doing the job

Unwanted Traffic RG; AP change from draft a message to the reserach community to, actually find out who to send it to

Anycast; will go to a tech chat

Discussion on Infrastructure ENUM Doc; has began to move

Consider Policy on ICANN Nominations Committee; for discussion

Plenary Speaker for Philadelphia; outstanding

Number of documents we're working on.

Agreed to ISOC BoD appointment timeline.


- report; we did not succeded in coming up with solutions to the outstanding issues (the list is 60 issues long); the list as such will be liaised to the ITU-T from mpls and pwe3 wgs

- very unclear what the outcome of the Seoul meeting will be, we are pretty good staffed for that meeting

- support for our position is building up; hard thing is that normally the ITU-T folks vote en bloc trusting their rapporteurs which will make it very hard to put documents on hold if we request that they hold the documents so we can sort out the issues

if they do: we go ahead and kick start the cooperation
if they don't: we go back to plan B

- message from Russ and Olaf to Malcolm Johnsson asking him to step in and take action.

- We have work going on in ITU-T on MPLS with no problems. all the problems are on T-MPLS side (part of three questions)

Russ - sent message to Malcolm this morning.

6. Management Issue

6.1 Approval of the IESG Policy on Autoresponse Messages Sent to IETF Mailing Lists (Chris Newman)

Chris sent new text at beginning of meeting - approve or carry over one meeting? Not much changed.

Sam - read it, old and new versions were both fine.

Anyone object to this going forward? Approved.

6.2 IAOC Candidate Confirmation (Executive Session) (Russ Housley)

(Not minuted - scribe was not on call for this section)

6.3 RFC Errata (Russ Housley)

Deferred to next telechat due to time constraints

6.4 Appeals (Executive Session) (Russ Housley)

(Not minuted - scribe was not on call for this section)

6.5 Management Item: IESG Narrative Scribes

Russ - one community member complains that not all scribes are fullfilling their roles, I think we should take any help we can get and ignore that complaint. We also have two new volunteers - interview them?

Sam - if Spencer complains about inactive scribes, that probably matters.

Spencer - not complaining about inactive scribes, understand IESG priorities (thanks, Russ) and understand scribe priorities, we're getting new volunteers, OK with current situation.

(Not minuting management discussion of proposed scribes).

Plan is to invite scribes to an informal telechat so they can get some idea what they're in for.


(This draft was discussed in the slot reserved for draft-ietf-shim6-proto-09.txt above, after draft-ietf-shim6-proto-09.txt was deferred)

7. Agenda Working Group News

Sam Hartman - emu is expecting to recharter

Russ Housley - IPR WGLC on last two documents finishing, getting to IESG by month-end, will require IESG attention on management aspects

Cullen Jennings - discussing with 3GPP about how DTLS-SRTP works with SBCs - now have MMUSIC milestone for this.

- Jari - one solution is still sufficient for everyone?

- Cullen - 3GPP security group fairly confident for voice (not IP-TV), wanted to think a little more about legal intercept. Guessing "yes", but need to check with SBCs. Brian Stucker's draft is pretty much getting this.

Jon Peterson - have identified one possible replacement for Dave Meyers

Dan Romascanu - new co-chairs for netconf (Bert Wijnen and Mehmet Ersue). We hope Bert will continue to attend IETF and IEEE meetings.