Narrative Minutes

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the January 5, 2006 IESG Teleconference
Scribe: Spencer Dawkins <spencer@mcsr-labs.org>

1. Administrivia

1.1 Roll Call
1.2 Bash the Agenda

No bashing took place.

1.3 Approval of the Minutes

No discussion of 12-1-2005 minutes. Allison reported a narrative minutes glitch for the 12-1 meeting.

We will do narrative minutes approval electronically and use a last-call mechanism for approval.

1.4 Review of Action Items

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

No update to projects list over the holidays (website was down due to weather/power issues over the holidays). Jon will provide a prod soon.

2. Protocol Actions

2.1 WG Submissions
2.1.1 New Item
o draft-ietf-pkix-acpolicies-extn-07.txt
Attribute Certificate Policies extension (Proposed Standard) - 1 of 4
Token: Russ Housley

No discussion (revised ID needed)

o draft-ietf-mmusic-comedia-tls-05.txt
Connection-Oriented Media Transport over the Transport Layer Security (TLS)
Protocol in the Session Description Protocol (SDP) (Proposed Standard) - 2
of 4
Note: PROTO shepherd Colin Perkins csp@csperkins.org
Token: Allison Mankin

This document had three DISCUSSes (from Sam, Ted, and Russ). Sam and Ted's DISCUSSes need to be worked with author, but Allison thought they could be resolved quickly. Russ's DISCUSS could be fixed with an RFC-Editor Note.

Russ asked if IANA was OK with adding an update to RFC 3279 as part of the policy. Michelle answered, "yes".

o draft-ietf-imss-fc-nsm-mib-05.txt
Fibre-Channel Name Server MIB (Proposed Standard) - 3 of 4
Token: Bert Wijnen

Allison raised a question about the reviewer for this document being one of the document authors. Bert pointed out that the reviewer didn't do all the writing, and Allison suggested that "the protocol was reviewed by only one of a large group of authors" would sound better. Bert agreed.

o draft-ietf-imss-fc-fam-mib-03.txt
Fibre Channel Fabric Address Manager MIB (Proposed Standard) - 4 of 4
Token: Bert Wijnen

Approved without discussion.

2.1.2 Returning Item
o draft-ietf-mpls-lsp-ping-12.txt
Detecting MPLS Data Plane Failures (Proposed Standard) - 1 of 1
Note: ITU requires an RFC number by December 12th.
Token: Alex Zinin

Alex had added this document to the agenda to ask people with DISCUSSes for status. Margaret had updated her DISCUSS because one issue (of two) had been resolved. Alex and Margaret will locate George's proposal (amid the holiday break mail) and follow up.

Sam believes that this specification can now be implemented, and that the rest of the references are informative.

2.2 Individual Submissions
2.2.1 New Item

NONE

2.2.2 Returning Item

NONE

3. Document Actions

3.1 WG Submissions

3.1.1 New Item
o draft-ietf-tsvwg-mlpp-that-works-02.txt
Implementing an Emergency Telecommunications Service for Real Time Services
in the Internet Protocol Suite (Informational) - 1 of 2
Token: Allison Mankin

Allison reported that the working group was OK with removing the non-normative paragraph on QoS mentioned in David's DISCUSS.

Ted commented (but not as a DISCUSS) that these people have talked about how to do management without talking about placement for it to be effective. Shipboard example - management may be for an application with proxies at various places in the network, and proxy placement matters (if you've already traversed the choke-point link before you get to the proxy). Is there a reason why this isn't explained, or is it obvious?

Allison said that the WG thinks of this as obvious and assumes networks are tightly engineered - that's probably why it's not explained. IEPREP documents do talk about this (and one is in some distress because it didn't have enough detail).

Russ raised a concern about the reference to HAIPE (High Assurance Internet Protocol Encryptor), because there's no specification the document can use as a reference.

Alex raised a concern with the amount of NATO/USG/DOD discussion in the main body of the document = too much material to be "an example", and not appropriate as a general standard. Could this be reworded as technology-centric and move some material to appendix?

Allison said that MLPP is particularly for NATO and DOD (although perhaps changing the title would set expectations more appropriately), and Brian said that most of IEPREP is the same way

Alex - but that's not a good thing. If this was Informational, that would be fine, but we're talking about a general standard. Needs to be more government-agnostic.

Allison said that the WG is basing its work on standards from NATO/USG/DOD, and that the issue needed to be worked with the WG. Alex and Allison agreed that Allison would do the right thing...

o draft-ietf-sipping-consent-reqs-03.txt
Requirements for Consent-Based Communications in the Session Initiation
Protocol (SIP) (Informational) - 2 of 2
Note: PROTO shepherd Rohan Mahy rohan@ekabal.com
Token: Allison Mankin

Sam has problems with Section 2 and scope of requirements. Section 2 describes problems that could be resolved in UA, but this isn't explained. Sam will write up his DISCUSS promptly, to avoid a DEFER.

3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD

3.2.1 New Item
o draft-savola-mtufrag-network-tunneling-05.txt
MTU and Fragmentation Issues with In-the-Network Tunneling (Informational)
- 1 of 3
Token: Mark Townsley

Allison asked Mark to follow up with Pekka on her comment about PMTU-D applicability (or lack thereof)

o draft-songlee-aes-cmac-03.txt
The AES-CMAC Algorithm (Informational) - 2 of 3
Token: Russ Housley

Allison noted that this is an Informational publication of an algorithm, and Russ noted that it's already in use in IEEE 802.16, and was reviewed in IRTF CFRG (Crypto Forum Research Group).

Allison pointed out that the RFC-Editor Note needed to be explicit about what was being superceeded, and the note was added during the telechat.

RFC Editor note was added during telechat.

o draft-jennings-sip-voicemail-uri-05.txt
Session Initiation Protocol (SIP) URIs for Applications such as Voicemail
and Interactive Voice Response (IVR) (Informational) - 3 of 3
Token: Allison Mankin

Allison said that the authors will have a revised ID, and are not quite finished with comments yet.

3.2.2 Returning Item
o draft-jones-avt-audio-t38-05.txt
Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration
(Historic) - 1 of 1
Note: Last Called to Historic for the same reason audio/t140c was - allow
registration of a "legacy" because of the way SDP uses these
registrations,Ã, but make sure this is not a precedent in any way.
Token: Allison Mankin

Allison noted that she is holding DISCUSS for registration issue on this document.

3.3 Individual Submissions Via RFC Editor

3.3.1 New Item
o draft-bberry-pppoe-credit-04.txt
PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
(Informational) - 1 of 1
Note: Requested TSVWG review of flow-control procedures, will sync up with
draft-arberg-pppoe-iana-00.txt
Token: Mark Townsley

Brian said he was satisfied with flow control issue based on feedback from Sally Floyd and asked how to handle IANA issue.

Mark explained that the author was happy to include text on message types. This document defines registries for PPPoE, for the first time, and Mark is worried about everything cross-referencing everything else. His suggestion was to limit the IANA document references to policy and PPPoE, as a BCP.

Sam asked how the document could be a BCP when the base specification for PPPoE is Informational, and Mark explained that the "BCP" would cover only IANA practices. This could be handled with a downref.

Mark said there was a need for guidance on IANA documents in general - he has seen several different statuses used for different IANA documents.

Allison pointed out that in order for other standards-track documents to reference a specification, it's useful to have a BCP (and that we need a downref registry).

Sam pointed out that RFC 3932 doesn't give the IESG authority to do what we're talking about - "give one of a finite number of responses quickly". Can't say the document conflicts with IETF work because we're not working on PPPoE.

Brian suggested that IESG would respond that this specification is related to PPPEXT, but this does not prevent publishing, and then add text about IANA issue.

Mark said the tracker already contains warning text from the PPPEXT WG, and asked if the note should also reference draft-arberg-pppoe-iana-00.txt . Sam said, "not in the RFC Editor note, only in the IESG Note."

Mark also asked about the Gen-ART review which raised concerns. Brian pointed out that the Gen-ART reviewer can discuss this with RFC Editor directly, and Allison pointed out that these tags are allocated first-come, first served anyway.

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 Domain Keys Identified Mail (dkim) - 1 of 4
Token: Russ Housley

No discussion minuted.

o EAP Method Update (emu) - 2 of 4
Token: Sam Hartman

Sam reported that Pekka wishes the working group was doing more, but the charter can be approved as it stands.

Sam asked "is mailing list creation automatic?" It isn't, the WG chairs put in a request and the AD approves it. The announcement can't be sent until the mailing list has been created (since it points to the mailing list).

o Diameter Maintanence and Extentions (dime) - 3 of 4
Token: Bert Wijnen

Brian and Allison tagged a couple of spelling errors.

There was some discussion about whether chairs needed to be identified before IESG approved the creation, since chair selection is an AD matter. David said new ADs should be asking for advice, but ADs shouldn't have to clear chairs with the other ADs, in general.

o Network-based Localized Mobility Management (netlmm) - 4 of 4
Token: Margaret Wasserman

Approved with no discussion.

4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Transport Layer Security (tls) - 1 of 3
Token: Russ Housley

Russ asked if this recharter should go for external review - this is for TLS 1.2, moving away from SHA-1 and MD-5, and it's a major change. It was discussed in Vancouver, and no contentious objections have been raised.

Bert said the charter should go to the New-Work mailing list also (since we complain when other SDOs don't send information like this to New-Work)

o ADSL MIB (adslmib) - 2 of 3
Token: Bert Wijnen

Bert wants this charter to go for external review because this is management for protocols done in other organizations

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

Sam said that the proposed charter needs to be either turned down or sent for review. Syslog was chartered to do signing and reliability, but syslog is so poorly specified they couldn't do what they were charter to do, then developed a new protocol that no one implemented, and now they are trying to get the protocol into the charter as well as reliability and signing. There are real questions whether anyone will use this work - so we should either close the working group or send this for external review.

Brian said it is probably legal, but not right, to close the working group without discussing it with the IETF, and Bert suggested that Sam include his concerns in the request for feedback.

Allison asked how many people are active in syslog. Sam said it's hard to say - the meeting attendees aren't the mailing list participants. There were 30 people at the meeting but it's not clear who will stay involved on the mailing list.

Sam raised one other issue - Syslog isn't planning on having a mandatory-to-implement security requirement, and asked if Russ was OK with this.

Bert raised a concern about the signal this sends to other working groups. This is an atypical situation - syslog has been around for 30 years, so it's not like "other working groups"

Russ said that the security area needs to hold ourselves to the same standard as everyone else - Bert is right - and asked if the working group could agree on a mandatory-to-implement requirement?

Allison asked why Syslog is a working group in SEC, since they are doing protocols, they are doing transport mappings ... if they are talking about reliability, fragmentation ... this sounds like APPS.

Sam agreed that APPS would also be a reasonable choice, and said that he understands the applications issues well enough to manage the working group but would be willing to give it away. Russ pointed out that this might be a loadbalancing opportunity when we have new ADs and a new area.

Sam agreed to tell the working group that they need a mandatory-to-implement requirement, and that the IESG will see the revised charter.

4.2.2 Proposed for Approval
o Pseudo Wire Emulation Edge to Edge (pwe3) - 1 of 1
Token: Mark Townsley

Mark pointed out that the current version of the charter doesn't include MPLS PWs, which was the source of negative external comments. Allison asked about wildcard FEC, and Mark said this is part of signaling in L2VPN. Allison is concerned about Fiber Channel being a pseudowire, and Mark mentioned that David Black is following the work closely.

5. IAB News We can use - Dave Meyer

- IAB is moving to Round Two of multihoming at APRICOT. PC is somewhat disorganized, but it looks like the date is March 1. We are considering locations for a workshop on "unwanted traffic". Has this been socialized with IESG? <only a little> - there's a blurb on the IAB webpage, but timing information may not be correct (it's tough to schedule so close to NANOG and IETF). If you know key players who need to be involved, please IAB know.

- The Liaison document has been through a couple of revs.

- IAB Work on the Jefsey appeal is spinning up now (whether to uphold Harald's action).

David also asked how best to keep IESG in the loop on the "unwanted traffic" workshop, and Leslie pointed out that the invitee list would be open to IAB and IESG members who are interested. Brian requested a summary to the IESG.

6. Management Issue

6.1 Timeout on AUTH48 (Brian Carpenter)

Current wording is "The IESG has decided that as of now, any IESG-approved drafts that enter the AUTH48 state, where the RFC Editor waits for final text approval from all listed authors, may be released on the responsible AD's authority if any authors have not responded after a reasonable time, typically two weeks." Brian pointed out that this allows the RFC Editor to expand to four weeks, but doesn't require four weeks as the minimum period.

Brian said IESG can also ask Joyce to request that RFC Editor changes the state name to something more realistic ("AUTH-CHECK"), but this is separate.

Allison raised a concern that ADs should use this with discretion, since authors check things that ADs don't, and the IESG doesn't want to cut off someone who really needs to be checking.

6.2 IKEv1 is obsoleted by IKEv2 (Russ Housley)

Russ asked if anything needs to be done, since IKEv1 is obsoleted, but also PS-not Historic. Other work depends in IKEv1, and there's no security reason or other reason to force a change. We will probably talk more about this when someone who depends on IKEv1 and wants to go to DS.

Brian said there is still work to do on versioning in general, but ISDs would make this MORE confusing...

Allison - nobody said this is straightforward...

<Short discussion of the entertainment goals [or lack thereof] that narrative minutes should be striving for, followed here>

6.3 Approval of text for PR-Action decision (Brian Carpenter)

<discussion here was not minuted>

6.4 Changing document status from Proposed to Experimental (David Kessens)

David has revceived this recommendation on NAT-PT from v6ops, and it looks good, but approving it would also move NAT-PT from PS to Experimental. David thought this was fine, but 2026 doesn't seem to support this and we've never done it before, so wanted to ask.

Margaret said that if IESG does the normal thing and Last Call this action, that should be OK.

Brian asked why v6ops is choosing Experimental and not Historic? Sam - or Informational? Margraret explained that this decision happened a long time ago, and we've changed the meaning of Experimental, etc. since then.

Brian pointed out the actual RFC text says "this is a standards-track RFC" - it would be wrong to have this move to Experimental or Informational. Margaret noted that Historic is on the standards track.

Sam pointed out that we can have an applicability statement that says "limited use" in any of these cases. 2026 says you're supposed to move to Historic if you're writing a "limited use" applicability statement.

6.5 IESG to Say OK to 3 IAB Documents in RFC-Editor Queue (Bert Wijnen)

Leslie objected to this agenda item, and the result of a quick discussion is that IESG will let RFC Editor know that IAB documents don't wait for IESG feedback before publication - Brian will reply to mail on this.

January Retreat - Brian

Alex will provide logistics offers tomorrow - he has two or three offers. Will start at mid-day on January 30. The agenda will be discussed via e-mail (possibly on call next week as well). Allison will be the agenda mistress.

7. Agenda Working Group News

Sam is hosting an ISMS interim meeting at MIT, February 13-14th.

Mark will be the advisor for 6LOWPAN, DNA, and HIP. 6LOWPAN has scheduled their interim as well.

Jon - ECRIT will be meeting on Feburary 1-2 in DC.

Ted asked "how will we schedule the new RAI area at IETF 65? Will this be a separate track?" Jon pointed out that this work forms a single consolidated track, even in the past. Allison agreed with Ted, we should schedule RAI using the tools (but we don't know if the tools will support this, so we need to find out), as RAI, and asked that a message be sent to agenda@ietf.org saying that we want RAI to appear, and let them check out the tool support for this. Ted said there should also be an RAI Area meeting, and that he and Allison would take the action to draft the message text.