Narrative Minutes

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the November 29, 2007 IESG Teleconference

Narrative Scribe: Spencer Dawkins <spencer@mcsr-labs.org>

With corrections from Jari Arkko, Alice Hagens, Sandy Ginoza

1. Administrivia

1.1 Roll Call

1.2 Bash the Agenda

Need to figure out if next telechat is on December 13 or December 20... Management item was added to this agenda.

1.3 Approval of the Minutes

2007 11 15 Minutes - approved with no discussion.

2007 11 15 Narrative Minutes - approved with no discussion, Spencer to submit.

1.4 Review of Action Items

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

Lisa - No update.

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

Jari - No progress, still on my to-do list..

IP 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 - done nothing since last meeting, still on my list.

IP o Chris Newman to draft an IESG recommendation regarding working group registration ownership.

Chris - ran out of time to work on that.

2. Protocol Actions

2.1 WG Submissions
2.1.1 New Item
o draft-ietf-behave-rfc3489bis-13.txt
Session Traversal Utilities for (NAT) (STUN) (Proposed Standard) - 1 of 9
Token: Magnus Westerlund

Magnus - don't fully understand issue for Chris' DISCUSS. Risk is that when someone tried to create name can end up with several different strings

Chris - problem is UNICODE variants (precomposed or decomposed) - want to do some sort of normalization. Still have problem with look-alikes, but that's a general problem. We've been asking for UTF-8 in user names, etc. I 'd go from UNKC, that's what stringprep uses.

Sam - really? I'm confused. KC does make more sense than KD.

Cullen - just for education - when you already have passwords/user names you want to reuse, are there other considerations?

Chris - KC is close enough to "normal" that things mostly work, but if you're encoded in non-normal form, that's a problem.

Sam - good text on this in SASL/Plain document, but if you're just reusing stuff with no thought, expect it's not going to work very well.

Cullen - OK, I'll go read all this stuff. Other than them not defining a STUN server, the document looked pretty good :-) I'll ping them.

Magnus - plus authentication ... revised ID needed.

o draft-ietf-geopriv-revised-civic-lo-06.txt
Revised Civic Location Format for PIDF-LO (Proposed Standard) - 2 of 9
Note: Robert is proto shepherd
Token: Cullen Jennings

Cullen - not sure what to do with Chris's DISCUSS. We have XML everywhere - is it all wrong?

Chris - pinged W3C policy for their opinion, don't want to provide my opinion before I check.

Cullen - this is basically an RFC 3066 issue?

Chris - doesn't have script tags - it's older, we've updated, but XML refers to the old version. Not sure if we're referencing an old element that doesn't allow us to use the new capability. We started using script tags in RFC 4646, that was the update to 3066. Want to check with W3C if not updating XML is an oversight or intentional. Keep nagging me to keep me honest. I think this will boil down to a one-sentence change.

Cullen - let's go AD Followup

o draft-ietf-rmt-bb-fec-ldpc-07.txt
Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes (Proposed Standard) - 3 of 9
Token: Magnus Westerlund

Magnus - trying to get head around IPR

Russ - tracking as best we can, but IPR document is still working on document. Disagreement because this is non-normative. Either add Robin Whittle to code fragment or replace code fragment with URL pointing to code fragment in public domain. IPR documents in WGLC right now.

Magnus - revised ID needed.

o draft-ietf-rmt-bb-fec-rs-05.txt
Reed-Solomon Forward Error Correction (FEC) Schemes (Proposed Standard) - 4 of 9
Token: Magnus Westerlund

No DISCUSSes and enough votes (Sam's NO-OBJ was not critical to pass). Approved with no discussion on this call.

o draft-ietf-smime-bfibecms-08.txt
Using the Boneh-Franklin and Boneh-Boyen identity-based encryption algorithms with the Cryptographic Message Syntax (CMS) (Proposed Standard) - 5 of 9
Token: Tim Polk

Tim - Sent Chris an e-mail (minutes ago) - right about 2821 for e-mail address reference. Underspecified in terms of internationalized domain names, have proposals that follow what we've done in PKIX. Worried about two things - IA5 and ASN.1. Have notes in RFC 3280 on ASN.1 in general, DISCUSS isn't specific to ASN.1. Also concerned about IA5 - we've used this lots of places, may stick with what we've been using rather than asking people to change the type.

Russ - stronger than that - it was UTF-8 and I asked for IA5.

Chris - Punycode is problem because we don't use it for left-hand side of e-mail addresses.

Russ - true for certificates too?

Chris - yes. Look at architecture draft. There isn't a requirement for EAI compatibility right now, if this is ASCII local-parts, that's fine. Need to look at this more closely.

Sam - IA5 is pretty limited, but please read up on it. Kerberos uses this limited to IA5 character sets to avoid lots of issues.

Chris - I may be wrong on this.

Sam - Punycode for left-hand side is way wrong, should not be used outside the DNS context, it does things you don't want it to do.

Russ - this takes the next step - want to support international, but EAI isn't done.

Chris - allow UTF-8 if you want to handle EAI.

Sam - probably needs to be re-last called because of downref to crypto specs.

Tim - HTML is also a downref to Informational - ID-Arch refers to RFC 3236, hadn't been downrefed before.

Sam - crypto is definitely not informational - it's specifying mandatory-to-implement. Believe these need to be last called again (also the wrong kind of reference).

Tim - have to re-last call both documents, we can move on. Revised ID and a lot of other things needed.

o draft-ietf-smime-ibearch-06.txt
Identity-based Encryption Architecture (Proposed Standard) - 6 of 9
Token: Tim Polk

Tim - lots of work left to do, but would like to talk about Russ's DISCUSS on title.

Russ - just disagree with the proposal.

Sam - this is using different authentication than E-mail - discuss with APP area? POP, SMTP, IMAP all use same auth infrastructure, this protocol uses a different one. Do we want to do that? Limited to set of security mechanisms between the two. S/MIME is a different case.

Chris - good discussion to have but wouldn't hold up a document for this. Two auth frameworks is just a fact these days. SASL suggestions haven't gotten community agreement here.

Sam - not sure I'll hold the spec unless there's consensus this is a problem with the spec.

Lisa - can bash APP-AREA agenda on Monday morning.

Chris - can take a shot at introducing this.

Cullen - a lot of documents would have problems if we ask another area if they see a problem.

Chris - think discussion will not block document but will motivate people to fix the situation.

Sam - need to authenticate all the time here in order to read my e-mail. Also not sure I understand the utility of this model at all, but not going there.

Tim - we've had that discussion in the working group, thank you for not going there.

o draft-ietf-avt-rfc3119bis-05.txt
A More Loss-Tolerant RTP Payload Format for MP3 Audio (Proposed Standard) - 7 of 9
Note: Colin Perkins is the document shepherd.
Token: Cullen Jennings

No DISCUSSes - approved?

Cullen - yes, but put in point raised so I can deal with Magnus comment.

o draft-ietf-avt-rfc2833biscas-05.txt
Definition of Events For Channel-Oriented Telephony Signalling (Proposed - Standard) - 8 of 9
Note: Proto shepherd is Roni Even
Token: Cullen Jennings

Cullen - Russ, need automated keying for SRTP, but we have a problem on saying which one.

Russ - don't have a problem if you say there's an open work item.

Sam - not sure you need automated keying at all. Why is this different from any other RTP media?

Cullen - don't think it is.

Sam - no one's going to deploy security just for this. Connection's not encrypted, people won't decide they need to start encrypting everything. Don't want security requirements no one's going to follow.

Russ - "if you need security, should use SRTP" - that's all we need to say.

Magnus - all payload formats have the same security requirements, covered by RTP.

Russ - would be happy with one sentence about automated keying in Security Considerations - " If confidentiality, authentication, or integrity protection are needed then SRTP [REF] SHOULD be used with automated key management." (pasted in Jabber)

Magnus - in most cases, you should just say X, unless you have other requirements.

Cullen - AD Followup.

o draft-ietf-mip4-vpn-problem-solution-03.txt
Mobile IPv4 Traversal Across IPsec-based VPN Gateways (BCP) - 9 of 9
Note: Document Shepherd is Henrik Levkowetz
Token: Jari Arkko

Jari - some DISCUSSes are straightforward - Sam, Russ. Bigger issue is network detection, inside/outside, automatic switching. Need IESG guidance here. My opinion is practical reality in VPNs is that this is done manually, don't want to block improvements to bad situations while we search for perfect solutions.

Sam - Some framing questions. 1. do we consider MIP4 auth strong enough that we can solve the problem about server being available in contexts when it shouldn't be? (No objections were stated in response) 2. Who is worried about possibility of sending a few packets before you realize you're not on the internal network - is this a big problem? If it is, that's probably fatal on this approach. (No objections were stated in response) But have seen some DISCUSSes - is this critical?

Jari - if you're not using VPN internally, it's likely this attack would succeed.

Sam - 3. then "the firewall is going to make it all better" - is that the problem?

Jari - in my interpretation, yes,

Sam - arguing that IHA is responsible for enforcing security problem - make it clear to mobile node that it's responsible and will not respond to registration from untrusted networks (so IHA has to know what's trusted). This violates "HA does not change" design constraint. If you don't get extension, you can't use this mode. If you do, IHA has to know what trusted networks are.

Jari - reasonable and small enough change to be practical. Some other proposals were a lot broader. Would probably remove some of the worries.

Sam - does it remove enough worries that we can publish the document?

Tim - would help, but still have concerns about complexity. If we can weaken some assumptions, that would help.

Sam - security considerations "not sure anyone can implement this" - that's not a good sign. Implementing on hosted OS will be tricky.

Tim - still worries me that it's a BCP and we're not sure multivendor interop will happen.

Sam - if we make HA changes, this should be a PS.

Tim - if that happened, I would clear.

Jari - status change and Sam's solution would solve your problem.

Sam - Lars is not here.

Lisa - my problem is serious. Author responded that we would need new protocol support for Home node AND Home Agent. Still two problems - home nodes may assume they must be inside the network if they are reachable (easy one) and how you make sure you're not vulnerable to MITM - if those problems are solved, I'm fine. Does this take us back to the drawing board?

Jari - No, that's doable. Need to go back to WG and talk to authors, but this would go a long way in solving concerns. Will tell you if they say this is impossible.

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 1
Note: Document Shepherd is <pete.mccann@motorola.com>
Token: Jari Arkko

Jari - don't need to DISCUSS, waiting resolution on another document. AD Followup.

2.2 Individual Submissions
2.2.1 New Item
o draft-klensin-unicode-escapes-07.txt
ASCII Escaping of Unicode Characters (BCP) - 1 of 1
Token: Chris Newman

Sam - position is YES.

No DISCUSSes, approved with no discussion on this call.

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions

3.1.1 New Item
o draft-ietf-manet-jitter-03.txt
Jitter considerations in Mobile Ad Hoc Networks (MANETs) Informational) - 1 of 1
Token: Ross Callon

Ross - couple of issues from Lars - Lars cleared, but issues are still open. One issue - this is Information with 2119, is that OK?

Russ - think it's fine.

Magnus - fine.

Sam - we keep coming to this conclusion.

Ross - this one is informational, but a couple of other documents (intended as PS) will likely refer normatively to this document ("intentional downref", not historical oddity). Is intending an intentional downref OK?

Russ - SEC does this all the time.

Sam - but for things like algorithms we don't control.

Ross - PS to BCP is a downref? Not. Is an intentional downref OK?

Sam - read RFC 3967, has good guidance, and ask MIDCOM people how they feel about this.

Ross - OK. Will take Dave Ward's DISCUSS offline. Will go Revised ID needed.

3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD

3.2.1 New Item
o draft-korhonen-mip6-service-05.txt
Service Selection for Mobile IPv6 (Informational) - 1 of 1
Note: No document shepherd
Token: Jari Arkko

Was DEFERred this morning.

3.2.2 Returning Item
NONE

3.3.1 New Item
o draft-jayasumana-reorder-density-08.txt
Reorder Density and Reorder Buffer-occupancy Density - Metrics for Packet Reordering Measurements (Informational) - 1 of 2
Token: Lars Eggert

No DISCUSSes, plenty of votes to pass.

Russ - looks that way to me.

"No problem" with no discussion.

o draft-irtf-mobopts-l2-abstractions-04.txt
Unified L2 Abstractions for L3-Driven Fast Handover (Experimental) - 2 of 2
Note: This is an IRTF submission
Token: Jari Arkko

No DISCUSSes.

Jari - kind of borderline here. See ongoing work in the IETF in various places, but no direct conflict, but this isn't high-quality document, has lots of problem. Trying to figure out if I'm supposed to fix them. Suggest that we let this go and Lars and I will send comments to the RG as interested parties.

Russ - send your comments to RFC Editor, IRSG actually approves this stream.

Dan - DISCUSS from Tim was cleared and isn't even a COMMENT - were Tim's concerns resolved?

Tim - cleared based because I wasn't following the proper process, concern wasn't addressed in any way. Don't quite believe statements they made based on documents they referred to, still trying to understand process.

Dan - had the same concerns, not sure what they mean about layer-two/layer-three interface. At least leave the COMMENTs so the RFC Editor is aware.

Jari - should I forward COMMENTs in my e-mail?

Tim - fine with me, will restore my DISCUSS text as a COMMENT.

Dan - can forward my COMMENTs, of course.

Jari - would, and in fact have, blocked documents with similar concerns from my WGs for years. Will let the RG know what we think.

"No Problem"

3.3.2 Returning Item
o draft-irtf-tmrg-metrics-11.txt
Metrics for the Evaluation of Congestion Control Mechanisms (Informational) - 1 of 1
Token: Lars Eggert

Any objections? None on the call, also "no problem" with no discussion on the call.

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
NONE
4.2.2 Proposed for Approval
NONE

5. IAB News We can use

No IAB members on the call - anything interesting?

Russ (ex officio) - statement about 60 days appeal timer, IAB said discussion should happen within entire community, started discussion on IETF list, thriving.

There are about 8 documents being held now.

MPLS design team - Loa will talk about that at face-to-face on Sunday.

6. Management Issue

6.1 RFC Editor Errata Reports (Russ Housley)

Russ - finally have functioning errata system (not sitting in queue forever), responsible party will get pinged, there are 297 coming to the IESG... what process do we use to handle them? Hoping for advice.

Jari - fraction that is actually helpful versus editorial?

Sandy - about 70 percent of the unverified errata were submitted by Alfred Hoenes. He often includes multiple corrections per errata, and many contain both technical and editorial corrections, so it's not easy to "focus on the technical corrections first".

Ross - no errata for documents that are older than some amount?

Russ - what if someone reports a bug in TCP?

Jari - Errata are useful, but there are two things. One, we need to have a policy about what is acceptable as an errata. Suspect many don't pass that bar. Two, can we delegate some of this to RFC Editor?

Cullen - policy on changes that cause no harm? and then delegate toward the authors? Don't encourage editors to do new documents, that's even more work. 297 isn't that bad, considering. If we can solve this over a one-year period and get author suggestions for 80 percent.

Ross - shouldn't fix spelling errors?

Cullen - need a policy, what causes implementations to be broken?

Russ - will discuss more, just giving a heads-up on the scope of the problem

6.2 xml submissions after draft approvals (Jari Arkko)

Fallout of RH deprecation, authors submitted wrong XML, just raising issue that authors should be careful. Fairly big on-list discussion with other issues, whether RFC Editor should be checking exact matches, tool checking, etc. We are doing this, system actually works, caught the problem. Suggestions?

Cullen - AD signoff on diffs?

Sam - oh, please no.

Jari - but you get to do that in AUTH48, all changes in one go. I prefer that

Sam - AD isn't blocking in this process.

Jari - unless RFC Editor thinks there's too big a change.

Sam - that's no problem whatsoever.

Jari - we already have instructions to them about this.

Alice - could be more explicit to authors about submitting exactly what matches approved ID, etc.

Jari - how should we be doing edits after approval - new document at AUTH48? unclear to me what we're talking about.

Cullen - letting authors submit XML that's not the TXT we approved is a non-starter. Submit revised ID and matching XML at AUTH48. This is the process I thought we had.

Russ - that's true before people submitted XML

Sandy - we also checked nroff. We compare the submitted files against the approved IDs and try to point out non-trivial changes to the Area Directors for review and approval. But, our question to you is, do you think it's necessary for us to require that a submitted source file produce the approved ID exactly? Some changes are useful (contact changes, etc).

Cullen - fine with that, but this assumes RFC Editor applies knowledge and seems to be working well - no change.

Sandy - in this case, changes we saw seemed strange (moved text, etc with no e-mail). Most of the text looked right.

Sam - If XML is in the repository, do you use it? That will help.

Sandy - We were unaware of this feature until recently. We are going to start checking for XML files in the repository.

Cullen - but people can submit any XML

Sam - but people won't try to game that.

Jari - will put guidance in Jabber.

6.3 RFC3588 vendor-specific command codes (Dan Romascanu)

Dan - don't have a good answer yet - process is quite heavy and requires IETF consensus, considered historical mistake, some people on IESG were concerned but maybe we don't care and OMA is asking for two common codes for reasonable reasons, with specifications, process is too heavy. There is 3688-bis allocating half the space as vendor-specific and FCFS, process would be much easier. Any way to meet OMA request more quickly?

Jari - entire IANA story on DIAMETER extensibility was flawed in my (outside) opinion, forced on WG by then-current IESG.

Dan - right now, rules are RFC 3588 and 3588-bis is a few months away - "IETF Consensus". Does this mean we can do Last Call on some text in a statement, or does it have to be an Internet Draft?

Jari - IETF Consensus isn't about a document, it's about consensus. Could do statement or write two-page document. Does OMA need them this week?

Dan - OMA would like them by second week of December. If IESG agrees, I can draft text for Last Call, like, two paragraphs.

Cullen - we're talking about the old definition here, right? Means an RFC.

Sam - yes. Informational is OK. So is Experimental.

Dan - no other way, need quick Internet Draft and run as AD-sponsored.

Russ - Individual would be four-week last call.

Magnus - does RFC contain specification or reference?

Sam - could contain reference, but people can say "needs specification".

Cullen - also doing this for OMA, don't see any other way. Did it by reference, there may be objections, but I doubt it. Don't remember if it's Informational or Standards-track, whatever the registry required.

Magnus - the one I'm doing is for 3GPP.

Cullen - mine was Informational (after checking).

Jari - what are they asking for?

Dan - spec asks for two common codes here.

Jari - biggest flaw is that considerations too strict - not easy to add new attributes on top of existing message structures. Need new command codes to add attributes, multiple ways of carrying EAP isn't helping interoperability.

Dan - workaround people take to short-cut policy, because it's absurd. Can define new application but not with common codes, so doing encapsulation.

Jari - some room for interpretation.

Dan - document is in last call now, not happy because they are jumping to the other end of the pool. FCFS for one million common codes.

Jari - danger is interoperability. I'll read this, it's on my list.

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

Chris - didn't get a chance to send revised text for review - on agenda for next telechat.

6.5 Last Telechat date of the year (Dan)

Dan suggesting swapping December 13 and 20th formal/informal, will avoid four-week gap between formal telechats.

Amy - week after 20th will be secretariat holiday, so decisions are announced in the new year - OK?

Ross - one advantage of swapping is that we will be busy and won't get a lot on the agenda for the 13th, haven't had informal telechat in a while (Thanksgiving, IETF). No one reads announcements over holidays.

Russ - what matters is when the appeal window starts...

Balloting for regular telechat - group consensus was formal telechat on the 20th, with informal/discuss-clearing will be on the 13th

7. Agenda Working Group News

- Ron Bonica

OPSDIR has been reorganized, Ted Seely will coordinate, will review like Gen-ART (all documents)

- Sam Hartman

BUTTONS will need review from APPS and INT areas after Vancouver, will need time in area meetings at IETF 71. Application interactions - Need consumers to tell us how off-base we are.

- Russ Housley

Todd Glassey appealing suspension from IPR mailing list.

- Jon Peterson

Thought I was closing SIGTRAN, but they have two more documents - hate that...

- Dan Romascanu

Security Directorate Advisor for NETCONF - need replacement