Narrative Minutes

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the March 2, 2006 IESG Teleconference

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

1. Administrivia

1.1 Roll Call

Many new participants (new IESG, plus Eric Rescorla channeling Leslie and Dave Meyer for IAB)

1.2 Bash the Agenda

Brian added one management issue (late).

Ted asked that the eai charter discussion move forward, and we moved the URN document forward as well (these are described in original agenda order).

1.3 Approval of the Minutes

We discussed changing "Vice-chair" to "Whip" in the minutes (to match the new terminology). This needs to be changed in the narrative minutes, as well.

1.4 Review of Action Items

Bert's action item is still in progress.

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

Jon has updates to several projects (which is good), but these updates were not discussed because the responsible parties were not on the call.

Ted asked if Jon is missing stuckees for the post-IETF 65 work. Jon thinks most of the projects that will lack stuckees after retiring ADs retire are mostly finished.

Brian suggested that we add the WIKI to the project list. Russ smiled at using a WIKI to manage the WIKI project.

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 draft-ietf-ips-auth-mib-08.txt
Definitions of Managed Objects for IP Storage User Identity Authorization
(Proposed Standard) - 1 of 16
Note: PROTO Shepherd black_david@emc.com. Title Change: Definitions
of Managed Objects for IP Storage User Identity Authorization [add "IP
Storage"]
Token: Allison Mankin

No open positions and no active DISCUSSes - this document is approved.

Allison confirmed that the RFC Editor notes are true and correct.

o draft-ietf-ips-iscsi-mib-11.txt
Definitions of Managed Objects for iSCSI (Proposed Standard) - 2 of 16
Note: PROTO Shepherd black_david@emc.com
Token: Allison Mankin

No open positions and no active DISCUSSes - this document is approved, with no RFC Editor Notes.

o draft-ietf-ipcdn-docs-rfmibv2-14.txt
Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0
compliant RF interfaces (Proposed Standard) - 3 of 16
Token: Bert Wijnen

Ted stated a NO-OBJ position. There are no active DISCUSSes - this document is approved. Bert confirmed that the RFC Editor note is correct.

o draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt
Node ID based RSVP Hello: A Clarification Statement (Proposed Standard) - 4
of 16
Token: Alex Zinin

This goes to AD Followup - Brian believes that the fix for his DISCUSS is trivial (RFC Editor note), and authors agree.

o draft-ietf-l2tpext-l2vpn-06.txt
L2VPN Extensions for L2TP (Proposed Standard) - 5 of 16
Token: Mark Townsley

Document has three DISCUSSes. Mark says there's an ongoing thread on e-mail. Can do a pointer for Russ's DISCUSS, Brian's DISCUSS is addressed in the 07 version. Sam's DISCUSS is related to the requirements document - you need additional requirements compatible with, but stronger than, RFC 3193 in this document.

Mark said this document is only about autodiscovery, and Sam said this is why the additional requirements are required. Mark said that this mechanism is used between BGP peers, so BGP security should be running. Sam said that public key certificates are required for autodiscovery - in the case of manual configuration, Sam assumes that security is also manually configured, but doesn't believe that automated discovery is appropriate with manual security. Brian asked what RFC explains this, and Sam said "the ICARD RFC".

Mark is concerned about ramifications here - can set up L2VPN today with L2TP, and this document is an improvement (over autodiscovery by other means) - why do we need certificates for the improved mechanism, if the unimproved mechanism doesn't have it?

Sam would be willing to block another document on this point (if another document was available), but Mark believes the time to block was March 2005, and that blocking this document would open the door to overturning L3VPN as well.

This issue needs to be worked face to face, in Dallas, and there's background work that needs to be done, to make sure the discussion is constructive. The zero step is a conference call between Sam and Mark, and the first step will be a meeting in Dallas.

Ross Callon volunteered to sit in on the discussion.

This document will stay in AD Followup.

o draft-ietf-netconf-beep-08.txt
Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)
(Proposed Standard) - 6 of 16
Token: Bert Wijnen

This document has two DISCUSSes, and Bert would like to put this document in AD Followup.

o Two-document ballot: - 7 of 16
- draft-ietf-netconf-ssh-05.txt
Using the NETCONF Configuration Protocol over Secure Shell (SSH)
(Proposed Standard)
- draft-ietf-netconf-prot-11.txt
NETCONF Configuration Protocol (Proposed Standard)
Token: Bert Wijnen

This ballot was DEFERRED last night, and Bert would like to clear these documents before he steps down from IESG. Can we get the DISCUSS work done with a revision by ID cutoff on Monday? Ted will not be available before Monday.

o draft-ietf-netconf-soap-07.txt
Using the Network Configuration Protocol (NETCONF) Over the Simple Object
Access Protocol (SOAP) (Proposed Standard) - 8 of 16
Token: Bert Wijnen

Document has no open positions with one DISCUSS.

Ted believes that the base locking mechanism has problems, and needs to see analysis to make sure it's workable. Ted may still need to ABSTAIN, because this is just too big a change to existing mechanisms - can NETCONF take a charter item to develop a standards-track mechanism for locking? If they will, Ted will ABSTAIN. Ted is concerned that the filter mechanism has the same issues, so we know there's a problem.

Ted will work with Lisa and Dan to resolve the issue.

o draft-ietf-sip-target-dialog-03.txt
Request Authorization through Dialog Identification in the Session
Initiation Protocol (SIP) (Proposed Standard) - 9 of 16
Token: Allison Mankin

Document has no open positions, with one DISCUSS - a one-word clarification from Brian, who will go NO-OBJ and trust that "sufficiently" is removed as DISCUSSed.

This document is approved, with point raised.

o draft-ietf-aaa-diameter-sip-app-11.txt
Diameter Session Initiation Protocol (SIP) Application (Proposed Standard)
- 10 of 16
Note: PROTO SHEPHERD: John Loughney <john.loughney@nokia.com>
Token: Bert Wijnen

Document has no open positions and two DISCUSSes.

Is Sam's DISCUSS related to the MD5 discussion? Not really - this is Bernard's issue where a SIP proxy can fake billing information (Sam doesn't recall all details) - would like for documents to be consistent with each other.

Allison asked that Bernard's note be forwarded to IESG (so far, it's gone to Security Directorate and RADEXT). Don't want to block this document, want to get other document (draft-ietf-radext-digest-auth-06.txt) to emulate this document.

o draft-ietf-dhc-server-override-03.txt
DHCP Server Identifier Override Suboption (Proposed Standard) - 11 of 16
Token: Margaret Wasserman

Ted said he had an ABSTAIN and encouraged others to consider this.

Allison said the working group understands the issues that have been raised. With four ABSTAINs, this document goes back to the working group.

Margaret will take this back to the working group, with a careful message explaining this (and she'll be talking to Ralph very soon). Margaret points out that the number of ADs will change in a few weeks anyway, so this is confusing. Two issues - does working group have consensus, and does IESG believe that the protocol is too complicated.

Allison would like INT to consider changing the way DHC works, because they adopt their own items and this results in big extensions with no vetting, unlike other working groups.

Margaret said that old working group charters often carved out territory (IPv6 was the same way) - Jari may wish to change the way that DHC works, but there are advantages to vendors that actually describe what they are doing with no IPR so others can also implement. DHC was rechartered more tightly a couple of years ago, may need to revisit this.

David spoke backing up Allison on this issue.

Amy will move to IESG evaluation/AD followup.

o draft-ietf-pwe3-fragmentation-10.txt
PWE3 Fragmentation and Reassembly (Proposed Standard) - 12 of 16
Token: Margaret Wasserman

Document has two DISCUSSes. Margaret has talked with Sam offline, and Mark has talked with Bert offline. Bert's concerns are about 2119 language. Margaret finds Bert's DISCUSS clear and actionable, but doesn't know how to resolve Sam's DISCUSS - we don't know whether the PE is a router or a switch, and this matters. Sam will provide possible text.

o draft-ietf-ipoib-connected-mode-02.txt
IP over InfiniBand: Connected Mode (Proposed Standard) - 13 of 16
Token: Margaret Wasserman

This document has three DISCUSSes, but Margaret understands them and can take them back to the relevant people. Allison said she can work with Bill Strahm on this. Margaret didn't think this document should have been done at all (but it was chartered when she became an AD).

o draft-ietf-geopriv-location-types-registry-04.txt
Location Types Registry (Proposed Standard) - 14 of 16
Token: Ted Hardie

Mark stated a NO-OBJ position for this document. Will these DISCUSSes require a revised ID? Russ and Brian said, "AD Followup", because some of the DISCUSSes require some DISCUSSion.

Allison asked for clarification on what's required ("sometimes it's a person, sometimes it's a device ..."?). Can David send text, to avoid interations? David asked Allison to use "entity" throughout. Allison is concerned at how much text there is in the DISCUSS. David was very close to a COMMENT, but wants to make sure that someone takes a second look - that's all that's required.

David believes that "location" is more useful than anything else. This is also John Loughney's point on mailing lists - types are not algorithmic, and Allison doesn't think they need to be. Is Brian's amphibious plane an aircraft or a watercraft? Brian can only pick one.

Allison asked David to put non-blocking text in COMMENTs, and David responded that he had done this.

o draft-ietf-dnsext-ds-sha256-05.txt
Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
(Proposed Standard) - 15 of 16
Note: The PROTO Shepherd for this document is Olafur Gudmundsson
<ogud@ogud.com>.
Token: Margaret Wasserman

Bert stated a NO-OBJ position. There are no DISCUSS positions and no notes in the tracker, so this document is approved.

o draft-ietf-sip-refer-feature-param-01.txt
Conveying Feature Tags with Session Initiation Protocol REFER Method
(Proposed Standard) - 16 of 16
Note: PROTO shepherd: dean.willis@softarmor.com
Token: Allison Mankin

Brian and Sam stated NO-OBJ positions. There are no DISCUSSes, all RFC Editor notes are correct, so this document is approved.

2.1.2 Returning Item
o draft-ietf-imapext-condstore-09.txt
IMAP Extension for Conditional STORE operation (Proposed Standard) - 1 of 1
Note: Document shepherd is Lisa Dusseault
<lisa@osafoundation.org>. This document is coming back because
the working group revised the document after IESG approval. Version 5
was approved; see Appendix A for a change log.
Token: Scott Hollenbeck

There are no DISCUSS positions on this document, so this document is approved. Scott will provide text for the announcement that says this is a reapproval of a document that was revised after previous approval.

2.2 Individual Submissions
2.2.1 New Item
o draft-salowey-tls-ticket-07.txt
Transport Layer Security Session Resumption without Server-Side State
(Proposed Standard) - 1 of 1
Token: Russ Housley

Brian and Allison stated NO-OBJ. Allison asked why this wasn't a working group document. Russ said working group discussed the draft and decided not to take it on as a chartered item, but EAP needs the capability. Eric said this was mostly the working group trying to focus on what was already chartered. The working group looked at seven revisions, so the working group is OK with what's being done here.

Document is approved, and RFC Editor notes are correct (there is one note, but it goes on for a while).

Is IANA information correct? Russ hasn't heard back from Jill yet.

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-ipngwg-icmp-name-lookups-15.txt
IPv6 Node Information Queries (Experimental) - 1 of 6
Note: The PROTO Shepherd is Bob Hinden <hinden@nokia.com>.
Token: Margaret Wasserman

Margaret agrees with David on feedback, but text says shouldn't be blocking - is David's feedback really a DISCUSS or a COMMENT? David simply wants to know that authors have looked at his feedback.

Brian said we usually set the bar lower for Experimental - don't want to hold up this document for a while to resolve this feedback.

David will hold DISCUSS for IANA considerations as well.

This document goes to AD followup.

o draft-ietf-idwg-idmef-xml-15.txt
The Intrusion Detection Message Exchange Format (Experimental) - 2 of 6
Note: Returning for publication as an experimental RFC rather than a.
proposed standard. When I talked to the IESG about this the plan was.
to completely remove the schema. The authors really want appendix c.
to stay as non-normative; if the IESG cannot accept this then we can. use
an rfc editor note.
Token: Sam Hartman

There is one DISCUSS on this document.

Sam says authors have agreed to provide a proposed editor's note, and spoke to Brian's comment - people are using this facility now, want to publish something now and get experience, to discover whether there's really interest. Should Sam change the note? Brian says this isn't necessary.

Brian thought Bert's issue had been fixed (with SNMPv3), but apparently the fix wasn't really a fix.

o draft-ietf-tsvwg-diffserv-service-classes-02.txt
Configuration Guidelines for DiffServ Service Classes (Informational) - 3
of 6
Note: PROTO shepherd: James Polk <jmpolk@cisco.com>
Token: Allison Mankin

There are three DISCUSSes for this document. Ted's and Bert's DISCUSSes can be easily fixed with AD followup (these are small points). For David/Pekka's question, the working group considered carefully whether to use RFC 2119 language in an Informational RFC, and Allison doesn't believe this is an appropriate reason to DISCUSS the document - the document carefully positions itself in the Introduction, so is just saying what MUST happen in order to accept the advice in the document.

Brian believes that the document is consistent with the DIFFSERV architecture.

Allison doesn't believe that BCP would be the correct track, because the intention is not to tell operators to do something, it's to tell them how to do something if they want to do it.

David will clear his DISCUSS, but wishes the document had used lower case. Please make sure the working group notices the comments.

Bert also wonders if all the MAYs and SHOULDs should be RFC 2119 as well.

o draft-ietf-dnsop-dnssec-operational-practices-07.txt
DNSSEC Operational Practices (Informational) - 4 of 6
Note: Peter Koch <pk@DENIC.DE> will act as the proto shepherd
Token: David Kessens

There is one DISCUSS for this document. It will go into Revised ID Needed.

o draft-ietf-mip6-bootstrap-ps-04.txt
Problem Statement for bootstrapping Mobile IPv6 (Informational) - 5 of 6
Token: Margaret Wasserman

There is one DISCUSS for this document. Margaret will follow up with the working group, but this will probably result in a revised ID.

o draft-ietf-ediint-as3-04.txt
FTP Transport for Secure Peer-to-Peer Business Data Interchange over the
Internet (Informational) - 6 of 6
Note: There has been almost no public discussion of this document within
whatever remains of the EDIINT working group. However, there do appear to
be implementations and there thus appears to be value in publishing the
document as an Informational RFC. Significant comments that can not be
addressed with an RFC Editor note might not be resolvable.
Token: Scott Hollenbeck

There are no DISCUSSes for this document - the document is approved, and the RFC Editor note is correct. Now Scott can close the working group.

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-edwards-mime-mxf-02.txt
Media Type Registration for SMPTE Material Exchange Format (MXF)
(Informational) - 1 of 1
Token: Scott Hollenbeck

There is one DISCUSS for this document. Scott has talked with Ted, and a revised ID will be needed.

3.2.2 Returning Item
NONE
3.2.3 For Action
o draft-hoschka-smil-media-type-13.txt
The application/smil and application/smil+xml Media Types (Informational) -
1 of 1
Note: Back on ballot to confirm the IESG is okay with a late change related
to SMIL versions. The substantive change is that SMIL is now being
registered as OBSOLETE
Token: Ted Hardie

This document was cleared during the backlog-clearing calls, using RFC Editor notes.It turns out, though, that the authors had been waiting to respond until SMIL 2.0 was stable. This will require a change to the registration, moving one of the two MIME types from "common" to "obsolete". This is reflected in version 13. The IESG was asked to approve this change; no objections, so it goes back to the RFC Editor queue for processing.

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
NONE
3.3.2 Returning Item
NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
o Email Address Internationalization (eai) - 1 of 1
Token: Ted Hardie

The IESG got significant comments from Keith Moore, plus a long set of comments from Dave Crocker and John Klensin on who to handle Experimental-first work. Ted has confirmed with Aaron Falk that he's OK with an IETF working group chartered to develop Experimentals and does not believe this work has to start in in the IRTF.

The base concern is that this work could create islands of email connectivity. Without this, though, that can happen in any case, and there would be no way to tell what island someone belongs to. It's also possible that we'll get part-way through the work and have to kill it, but we need to take the risk that this working group will produce a consensus.

Ted is still looking for a co-chair (besides Harald Alvestrand), but is OK with announcing with one chair and then choosing a second chair at/after IETF 65. Russ made a suggestion, and this was discussed (but not minuted).

Allison asked about the plan to get a non-Latin charset co-chair, and Ted said this would be good, but may not have candidates with this background and chair experience.

David said he would abstain on this decision (if he could abstain).

Ted will review the charter with Amy before it is announced, to make sure everything is right.

4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 3
Token: Jon Peterson

Jon said proposed change is inclusion of TURN draft in the charter (it has been circulating as an individual draft for a while).

No objections to the charter update.

o Internet Emergency Preparedness (ieprep) - 2 of 3
Token: Jon Peterson

There's still a lot of discussion about the right of this work to exist at all.

Sam believes that this discussion should happen in the community, and not just within the IESG. Sam believes that the discussion should be part of the rechartering discussion, in public, and would like to see a more tightly scoped proposed charter that can go out for review in the community. Jon will produce a revised charter with more limited milestones, plus a rechartering milestone.

Some discussion of possible co-chairs took place, but was not minuted. It would be lovely to find a co-chair from outside North America, because so much of the input is coming from North America thus far.

David pointed out that IM and e-mail are also relevant to emergency communication.

o Security Issues in Network Event Logging (syslog) - 3 of 3
Token: Sam Hartman

Sam says this is similar to the previous charter brought to IESG, when we decided to require a mandatory-to-implement security mechanism, and believes that the charter announcement should ask specifically for evidence of support from implementers (without this support, should probably close down the working group).

Bert - what about generic underlying security for management? Netconf needs this, too.

Sam - if people come to an agreement, we can add the milestones for it then.

Bert - but won't we be defending this action in six months, when other people discover the same needs?

Sam will provide text for the announcement, and the charter will go for external review.

4.2.2 Proposed for Approval
o MIPv6 Signaling and Handoff Optimization (mipshop) - 1 of 2
Token: Margaret Wasserman

No objections, so charter is approved.

Margaret asked about a change to the working group name, proposed by the chairs (same acronym, different name). Margaret remembers that changing acronyms was problematic - is changing the name OK? Handoff optimization isn't limited to IPv6, so chairs want a name that reflects this.

Bill says that five-year-old experience is that it's easier to shut down the working group... this may have been tongue-in-cheek.

Barbara is concerned about the archives under the old names - how does that work? Brian asked that this be handled offline due to time pressure.

o Intellectual Property Rights (ipr) - 2 of 2
Token: Brian Carpenter

Recharter is approved and announcement will be sent.

5. IAB News We can use

Eric Rescorla:

* Pekka has resigned from IAB, effective immediately, and will be replaced after TSV slot filled.
* Lots of new IAB people, already on the mailing list and coming up to speed, with mentors available.
* IAB multihoming/shim6 BOF in Perth (will have update later).
* February 9/10th - Bad Traffic workshop will be held in LA. Is Cullen the only IESG person who will be attending?

6. Management Issue

Jefsey 3066bis appeal - final text has been discussed on ADs-only list, and will be issued after the meeting.

6.1 License Text in draft-eastlake-sha2 (Russ Housley)

Russ asked whether we let this go or do something in response to the comments received.

Brian is concerned about a related topic under discussion in the IPR working group - if we make a change without a Last Call, will this be appealable?

Sam pointed out that authors can make the licensing change whether we want them to or not, and there's no reason to prevent authors from describing their actual license.

Brian's suggestion is to send the note with a heads-up for RFC Editor and IETF list.

Allison - is this specific to software code in the document? Yes - need to make sure this is very clear in the announcement, so people won't think they can have strange licensing on a document.

6.2 Reclassification/withdrawal of draft-ietf-idwg-beep-idxp (Sam Hartman)

Sam said that we were down to one DISCUSS on the last idwg document, and there's a document that normatively refers to this document, approved in 2001 or 2002 as a proposed standard. Can IESG agree that this document can be published as experimental?

This is the oldest document in the queue.

If Sam withdraws, he would need permission to withdraw the requirements document, too? Yes, the requirements document is still in the RFC Editor queue (sigh).

Russ encourages authorization for reclassification, but come back and ask before you withdraw.

The IESG approves the reclassification to Experimental.

7. Agenda Working Group News

Brian - No.

Bill - working on SIDR chairs, but was letting Alex handle this. Still have a little time before IETF 65.

Sam - Last KINK document is in AUTH48, IDWG can also be closed.

Scott - Can also close a group.

Russ - nothing.

David - No.

Allison - talking with Cullen and Magnus on their new working groups.

Jon - No.

Margaret - No.

Bert - heads-up about CAPWAP author question, may come up at plenaries.