Narrative Minutes

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the January 25, 2007 IESG Teleconference

Scribe: Spencer Dawkins <spencer@mcsr-labs.org>, with corrections and clarifications from Cullen Jennings, Leslie Daigle, David Kessens, Lars Eggert, Jari Arkko,

1. Administrivia


 1.1 Roll Call
 1.2 Bash the Agenda

Sam asked that we move up section 6.2 from the management items earlier in the telechat.

 1.3 Approval of the Minutes

January 11 minutes were approved with no discussion.

 1.4 Review of Action Items

Bill Fenner to address the IANA open issue of address family numbers registration procedures.

Bill - IANA issue is still in progress.

Cullen Jennings to address the IANA open issue of well known protocol name.

Cullen - well known protocol names is still in progress.

Ted Hardie to address the IANA open issue of "reserved ports" LDAP similarity issue. 

Ted has sent a statement for IANA (late last night). Ted thinks there has been progress - any heartburn with the statement, please reply.

David Kessens to address the IANA open issue of needing multicast expert replacement.

David -  has prepared a 'Call for nominations'. He would like to receive comments on the text and possibly go ahead with the Call by next telechat.

Ted Hardie to address the IANA open issue of naming an expert for RFC 3864.

Ted - RFC 3864 expert has accepted (will be Graham Klyne)

Sam - dialog on IPR disclosure - has been slowed by illness, hope to do this soon

Ted Hardie to work with IANA to determine if there is, or needs to be, guidance on the acceptable characters for use in service strings registered with IANA.

Michelle - thinks IANA-registered service strings are ASCII while local service strings are UTF-8 - Ted thinks this is reasonable.

 1.5 Review of Projects
     http://www.unreason.com/jfp/iesg-projects

Jon - no project list update at this meeting.

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 Two-document ballot:  - 1 of 7
    - draft-ietf-ips-iwarp-da-05.txt
      Datamover Architecture for iSCSI (DA) (Informational)
      Note: PROTO Document Shepherd: David Black (black_david@emc.com)
    - draft-ietf-ips-iser-06.txt
      iSCSI Extensions for RDMA Specification (Proposed Standard)
      Note: Document Shepherd: David Black (black_david@emc.com)
   Token: Lars Eggert

Lisa and Mark declined to state positions, but there are still enough votes to approve.

 o draft-ietf-ccamp-rsvp-restart-ext-07.txt
   Extensions to GMPLS RSVP Graceful Restart (Proposed Standard) - 2 of 7
   Token: Ross Callon

DISCUSSes can be worked offline - no discussion here.

 o draft-ietf-pim-mib-v2-09.txt
   Protocol Independent Multicast MIB (Proposed Standard) - 3 of 7
   Note: IETF Last Call ends January 25.
   Token: Bill Fenner

Bill just sent e-mail (nanoseconds earlier) - Lars' issue is a downref for PIM Dense Mode (it's experimental), but decision was to keep the objects together (not worth the overhead to split them out). Now need to decide about the references

Brian - PIM-RM is optional, but we've treated option references as normative.

Bill - you don't need to know anything about PIM-DM to implement PIM.

Cullen - would I need to know IP to implement IP packet counts on Ethernet?

Sam - that's not a normal case, because we all know what an IP packet is. Think SIP - I'd argue that this would be normative. Need to find the most expeditious way to not care.

Bill - this isn't what the downref procedure was intended for. Don't want to split the document, but do want to figure out how to treat "conditionally normative" references involving options. Any objections to using the downref procedure for this?

<No one objected - we'll use the downref process>

Lars - Bill has a downref script, and Henrik is adding support for downrefs in id-nits..

 o draft-ietf-crisp-iris-common-transport-04.txt
   A Common Schema for Internet Registry Information Service Transfer
   Protocols (Proposed Standard) - 4 of 7
   Token: Ted Hardie

Cullen and Mark didn't state positions on the call.

Ted asked to chat about DISCUSSes. Thanks for everyone's reviews - I've been involved with these specs for so long as WG chair that missing context just flew by me. We really are missing critical contextualizing information. I'll be talking to DISCUSSants individually. CRISP has had a milestone for UDP transport, but we've assumed that most people will be able to move from UDP to TCP transport and keep a common view of the schema.

Lars - Application isn't well-suited for UDP with 4000-byte messages. We try to stay under minimum-MTU sizes.  There are other concerns Magnus has raised, and by the time you fix them, this isn't lightweight any more.

Brian - that's the problem you have building on UDP.

Ted - by the time the protocol acts like it's TCP, it's not worth doing.

Brian - we should be having this discussion with the working group.

Ted - squeezing into 512-byte packets isn't practical.

Lars - if you want to send larger packets, you have to do PMTU discovery, and then it's not lightweight.

Brian - the working group has to know this, and then figure out what to do.

Jari - what about DNS reflection attacks - isn't that a danger here?

Ted - we can make sure security considerations cover that

Jari - it's mentioned, but it doesn't say how good the tools are for dealing with these attacks.

This will go Revised ID Needed.

Sam - my DISCUSS is simple to deal with - if it's not, come back and let me know.

 o draft-ietf-crisp-iris-lwz-07.txt
   A Lightweight UDP Transfer Protocol for the the Internet Registry
   Information Service (Proposed Standard) - 5 of 7
   Token: Ted Hardie

Also in Revised ID Needed.

 o draft-ietf-crisp-iris-xpc-05.txt
   XML Pipelining with Chunks for the Information Registry Information Service
   (Proposed Standard) - 6 of 7
   Token: Ted Hardie

Also in Revised ID Needed.

 o draft-ietf-lemonade-compress-07.txt
   The IMAP COMPRESS Extension (Proposed Standard) - 7 of 7
   Note: Eric Burger is the Shepherd for this document.
   Token: Ted Hardie

One DISCUSS is a downref issue to DEFLATE, which we've done before. Ted needs to check for precedents.

Ted has sent Cullen mail about dealing with DEFLATE, and Cullen is reading the writeup. Cullen wants to know if we can already deprecate DEFLATE in favor of TLS - most phones Cullen knows about are using stacks that can support this as a compile time option.

Ted said the pushback was from Nokia, but Cullen said he's done some background investigation here - maybe we're making work, maybe adding into the stack is easier than adding to the application.

Sam - even if you're right, is your DISCUSS a DISCUSS?

Cullen - I think "fundamental premise is wrong" is a DISCUSS. If this caused no harm, I wouldn't care, but it's hard to argue that this won't cause confusion - two mechanisms to do the same thing at the same time. Double compressing is even worse. If this has been carefully considered, I can remove the DISCUSS.

Ted - WG has done the investigation, but maybe not with the same data and maybe with old data. We should ask the working group about this, and about a cornder case where you would use this without TLS.

Sam - if you're not using TLS for security, yes.

Ted - so the question is whether not using TLS in these targeted devices is ever reasonable.

Cullen - I can look at WG archive for previous discussion.

Brian - have to do downref last call again anyway, right?

Ted - need to check on how we've handled this in the past.

Russ - we don't usually move algorithms up the stack.

Ted - please put this in AD followup.

Bill - remember that hope is that downref Wiki is updated by ADs at Last Call time, right?

2.1.2 Returning Item
 o draft-ietf-tsvwg-tcp-mib-extension-14.txt
   TCP Extended Statistics MIB (Proposed Standard) - 1 of 2
   Note: PROTO Document Shepherd: James Polk. MIB Doctors: Dan Romascanu, Bert Wijnen
   Token: Lars Eggert

Document was approved with no discussion.

Lars - has Bill heard from authors on question you put in COMMENT?

Bill - have not heard.

Lars - Point Raised, please let me check with authors.

 o rfc3989.txt
   MIDCOM Protocol Semantics (BCP) - 2 of 2
   Token: Magnus Westerlund

Magnus will try to sort DISCUSSes out - AD Followup for now.

2.2 Individual Submissions
2.2.1 New Item
 o draft-bonica-internet-icmp-14.txt
   Modifying ICMP to Support Multi-part Messages (Proposed Standard) - 1 of 4
   Token: Jari Arkko

Sam - stated NO-OBJ, David did not state a position.

Jari - holding DISCUSS for IANA until they complete review. Downref doesn't have to be normative. More concerned about Cullen's DISCUSS - have you seen Ron's e-mail?

Cullen is still working through... preliminary impression is positive, though.

Revised ID needed.

 o draft-manral-ipsec-rfc4305-bis-errata-03.txt
   Cryptographic Algorithm Implementation Requirements for Encapsulating
   Security Payload (ESP) and Authentication Header (AH) (Proposed Standard) - 2 of 4
   Token: Russ Housley

Mark did not state a position on the call.

Document was approved with no discussion on the call.

 o draft-solinas-ui-suites-01.txt
   Suite B Cryptographic Suites for IPsec (Proposed Standard) - 3 of 4
   Token: Russ Housley

Mark did not state a position on the document.

Russ - two ways I can handle the DISCUSS - go Informational, or Last Call again - is there a third choice?

Brian - if reference is normative, there is no third solution, right? IANA only requires a document, not a standard? Several ADs think so. If the only thing that matters is getting the registration done, we'll go the quick was and go Informational.

Document is approved as Informational (when DISCUSS is cleared).

 o draft-daigle-unaptr-01.txt
   Domain-based Application Service Location Using URIs and the Dynamic
   Delegation Discovery Service (DDDS) (Proposed Standard) - 4 of 4
   Token: Ted Hardie

Ted can work DISCUSSes offline - Revised ID Needed, and thanks for actionable DISCUSSes.

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-widex-requirements-04.txt
   Widget Description Exchange Service (WIDEX) Requirements (Informational) - 1 of 1
   Token: Lisa Dusseault

Lisa - has Russ seen answers to security directorate review? Russ has not. Lisa would like to stop working on security considerations (Informational document, requirements, working group being shut down...)

Russ - can go ABSTAIN, or could have IESG Note that says issues aren't being addressed.

Brian - would need to have Lisa craft an IESG Note.

Lisa will do this via e-mail.

Will Dan do the same thing? Lisa will propose text, and then we'll ask Dan what he thinks, too.

Will be approved, AD Followup.

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-cam-winget-eap-fast-06.txt
   The Flexible Authentication via Secure Tunneling Extensible Authentication
   Protocol Method (EAP-FAST) (Informational) - 1 of 2
   Token: Russ Housley

Document was approved with no discussion on the call.

Brian - still an open discussion around Dan's comment...

Russ - we can handle anything there in AUTH48.

 o draft-conboy-mime-opf-00.txt
   Media Type Registrations for OEBPS Package File (OPF) (Informational) - 2 of 2
   Note: Sent to ietf-types in October of 2006
   Token: Ted Hardie

Document was approved with no discussion on the call. Gen-ART review didn't generate a DISCUSS, only COMMENTs.

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-zorn-radius-keywrap-12.txt
   RADIUS Attributes for the Delivery of Keying Material (Informational) - 1 of 3
   Token: Russ Housley

Russ - there is DNP text in the writeup now - just send this off to RFC Editor.

Brian - might consider Russ doing followup note to RFC Editor - clear from Tracker text, but may need special handling.

Any objections to "Please Do Not Publish" as an exceedingly strong polite request? None noted.

 o draft-burke-vxml-02.txt
   SIP Interface to VoiceXML Media Services (Informational) - 2 of 3
   Note: This is an individual submission to the RFC Editor being shepherded
   through the IESG review process by Cullen Jennings.
   Token: Cullen Jennings

Cullen - this is dead-on-center for not-yet-chartered Mediactrl WG - others suggested asking authors to pull their own document. Will defer this until next telechat while Cullen has conversations with authors. Cullen will move to DISCUSS to hold it for two weeks.

 o draft-irtf-dtnrg-arch-08.txt
   Delay-Tolerant Networking Architecture (Informational) - 3 of 3
   Note: Advancing according to: draft-irtf-rfcs-00.txt. Document Shepherd:
   Stephen Farrell (stephen.farrell@cs.tcd.ie)
   Token: Lars Eggert

There were no objections to RFC Editor publishing this document.

David - we should make sure we don't have the problem I mentioned in my DISCUSS again.

Brian - IRTF doesn't have an "Amy" to fix that problem...

3.3.2 Returning Item
 o draft-deoliveira-diff-te-preemption-06.txt
   LSP Preemption Policies for MPLS Traffic Engineering (Informational) - 1 of 1
   Token: Ross Callon

Document was approved with no discussion.

Brian - just change "I believe" to "We believe" in the approval text, since we now all agree...

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
   NONE
4.1.2 Proposed for Approval
 o Provisioning of Symmetric Keys (keyprov) - 1 of 1
   Token: Russ Housley

No discussion about technical part of the announcement. Discussion of proposed chairs was not minuted.

WG creation was approved.

4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
 o Network Mobility (nemo) - 1 of 1
   Token: Jari Arkko

Significant charter change - lots of proposed work, but hacked the list down to route optimizations for air industry/space industry. Jari is calling for detailed requirements for each application area. There is business riding on some of these problems, but the problems are really hard. Jari thinks we should let people try to solve them.

David - more ready for a BOF. WG completed, close it. This is new work, not an extension. I think this area is research and not engineering at this point, unless you're a lot more specific about the problem you're solving and how you're going to solve it within constraints.

Jari - there are ideas about how to solve the ideas.

David - not convinced that proposals for solutions are workable.

Jari - question of making tradeoffs. Boeing's design is completely based on routing protocol updates, other people are competely based on tunneling. If you could combine the proposals, the end result might be better.

David - need to be clear about direction in the charter, not general research. Should be a BOF.

Brian - either WG or BOF needs to be tightly chartered, is that what you're saying?

Jari - this is a continuation of route optimization work done previously, and we have safeguards in the charter - if people fail to deliver, the work disappears.

David - what do other ADs think?

Mark - didn't we decide NOT to hold a BOF on these items, at IESG/IAB level? Requested airplane mobility BOF at last IETF. People had problem statement, everything for a BOF, but we told organizers they could do work within working groups.

Jari - we sent them to Nemo for the specific issues, that's right.

David - the problem domains are pretty disjoint - space applications are the research end of the problem domain.

Brian - other opinions?

Cullen - general comment that semi-chartering ("if stuff doesn't happen on time we'll remove it") gives us enormous pain, every single time. If we don't know a solution, this is research, and we shouldn't charter it.

Jari - don't think this is research. There are research topics in the area, but this isn't about research.

Mark - we have one AD in entire IESG who is willing to voice this concern.

Mark - don't want to cycle on "oh, now we think we need to do a BOF" as a 180-degree turn. Either tweak it or kill it.

Russ - send this out for IETF review and see if community has similar concerns.

Brian - let Jari tighten up charter on what's in scope/out of scope before we send this out for review.

David - start with a charter that just defines requirements - we did this with Multi6/SHIM6.

Cullen - if the work is so questionable you have to do that, do it, but there will be pain.

Jari - problem domains have similar technology issues.

??? - believe difference is relative speeds, etc.

Jari - technology matters, too - you have problems with satellites no matter what you do.

Mark - this is all part of engineering the solution. The point was that people recognized commonalities and want to look for common mechanisms. If a specific application falls outside the boundary, that's fine.

Brian - Jari needs to tighten charter before review.

Jari - bring it back to the IESG?

Brian - need another look, maybe by e-mail after the propsoed charter is updated.

4.2.2 Proposed for Approval
   NONE

5. IAB News We can use - Leslie

IAB has completed IAOC selection.

Have made some changes to multiple-encapsuations draft (in RFC Editor queue), multilink document going for last call.

ISOC BoT position search is underway.

ECRIT - tech chat will be in late February (these are usually informal).

- Cullen - heard rumors - people bringing you architectures to approve, etc.

- Leslie - generally intended to make sure the IAB is clued in to what's going on in this space, in case liaison or other decisions are needed

- Ted - please have ECRIT put together a reading list for topics like PhoneBCP, expecially.

- David - Any idea for the timeframe when the IAB confirms or does not confirm the IESG slate?

- Leslie - best I know we don't have a slate under consideration, but I'm not involved in this for other reasons.

6. Management Issue

 6.1 Expert for draft-ietf-hubmib-rfc3636bis-05.txt [IANA #33594] (Michelle Cotton)

Michelle - we need an expert, who can get is one?

Brian - Bert suggested experts would be Dan and HUBMIB WG chair

No one objected to giving this job to Dan (who was not on the call) and the HUBMIB WG chair, currently Bert Wijnen.

 6.2 Wordsmithing of Approval (Ted Hardie)

Ted - wasn't able to reply to Sam's suggestion, but Sam's suggestion was to add to the writeup for draft-hollenbeck-epp-rfc3733bis, which Ted has done. Sam is fine with this (because the reason is given as modularity) and will remove his DISCUSS.

Addition was "The IESG believes that IANA may allocate an additional port in the 'user port' range to protocols whose current port allocation requires access to a privileged port.  This allocation should not be automatic, but may occur upon application by an interested party whose application would otherwise fit IANA's policies."

This addition seemed to make sense to everyone on the call...

 6.3 Confirmation of IAOC Candidate (Cullen Jennings)

Candidate was confirmed in executive session with no discussion, will be announced with the rest of NomCom's candidates.

 6.4 Ed Lewis as Designated Expert for RFC2929bis experiment (Mark Townsley)

No objections to this appointment on the call.

 6.5 New revision of the AD sponsoring guidelines (Jari Arkko)

People have had a chance to comment, and guidelines were revised based on comments.

Question - what to do about documents that have been through IETF process but didn't come to us in the normal way? WG rejected approach, etc. Klensin draft proposed that we are stuck with anything that has ever been in the IETF, Jari's proposal isn't quite so strong.

Brian - set a deadline for comments?

Jari - I did - it was today...

Cullen - only wanted to say "thank you" as my comment.

Jari - have also reviewed independent submission document, others should as well.

Brian - also need to decide whether this is an RFC or an ION.

Leslie - put forward pros and cons, worth having the discussion.

Brian - clearly can't do an ION that changes the rules.

Leslie - document does a good job of focusing on interpreting, not on making new rules.

Brian - we'll come back to this on the next formal chat.

Jari - don't care, either way, toss a coin.

Brian - if no reason this can't be an ION, make it an ION - easier to ION->RFC than to go the other way.

David - is there a reason not to publish an RFC? I didn't see one.

Brian - we can figure this out at Last Call time.

Leslie - would be more comfortable as RFC, we don't have air under our wings with IONs yet.

(There was general agreement to pursue this direction, at this point in the telechat)

7. Agenda Working Group News

Brian Carpenter - please pay attention to IPR issues about patent policy, from open source community
Lisa Dusseault - non-WG news - SMTP to draft standard? John Klensin volunteered to do a draft, but there's no WG group for SMTP. Hoping this can all happen as an open cabal with a mailing list. Any objections?

- Brian - no objections because the work is visible to the community. Two steps ahead of you, because SMTP is a full standard now.

- Cullen - if you meet, you might be able to get new people participating.

- Lisa - new e-mail people show up every two meetings....

Ted Hardie - John Klensin is working on a proposal to describe UNICODE in Internet Drafts, on apps mailing list. Will see a reasonable proposal in the near future. Webdav is the interesting one, with lots of feedback at IETF Last Call time. Draft will be revised, but we may get an appeal that we are publishing a document with known technical issues. This will be a tough one. WG has very low energy and IETF Last Call opened old disagreements. Lisa and Cullen are both recused, but incoming AD will have to deal with this.

Russ Housley - thank you for your efforts on the DKIM telecomm, but the document doesn't reflect all my recollections of the telecomm. May need another telecomm to get the "rest of the way" before Prague.

Cullen Jennings - proposal to merge DTLS and ZRTP proposals. Authors think this will go somewhere, I'm less convinced.

David Kessens - currently participating in CAPWAP interim, good progress.

Jon Peterson - IEPREP people are coming back with a BOF request. Have people seen it? Think that contentious parts are unchanged from WG charter proposal, so we're probably not through here.