Narrative Minutes

Narrative Minutes for the September 28, 2006 IESG Teleconference

Scribe: Spencer Dawkins <>

With corrections from Leslie Daigle, Russ Houseley, Lars Eggert, David Kessens, Jari Arkko.

1. Administrivia

1.1 Roll Call
1.2 Bash the Agenda

No changes noted.

1.3 Approval of the Minutes

Minutes of 9-14 approved with no discussion.

Narrative minutes of 8-31 approved with no discussion.

1.4 Review of Action Items

IANA multicast expert assignment job description is still in progress.

1.5 Review of Projects

Jon hasn't received any updates, but has managed to whip suspects into providing updates for next time.

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-nsis-ntlp-11.txt
GIST: General Internet Signaling Transport (Proposed Standard) - 1 of 4
Note: WG Shepherd: John Loughney (
Token: Magnus Westerlund

Magnus says we're making progress on discussions, revised ID needed.

Lisa - does every node talk only to its neighbor nodes, or to the originating node? This is unclear - needs help.

Cullen - will move to ABSTAIN - needs to go back to working group and decide if WG should be open or not. Issues are fundamental, not small things to fix. More serious than usual "revised ID needed".

Lars - Should talk about this on the informal call.

o draft-ietf-grow-anycast-04.txt
Operation of Anycast Services (BCP) - 2 of 4
Note: PROTO Shepherd: Geoff Huston
Token: David Kessens

Russ DEFERed this about an hour before the call - will be on the agenda next time.

o draft-ietf-avt-rtp-amr-bis-06.txt
RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs (Proposed Standard) - 3 of 4
Note: Colin Perkins is PROTO Shepherd
Token: Cullen Jennings

Several open positions from absent ADs, but has just enough support to approve on this call. Approved with no discussion.

o draft-ietf-secsh-publickey-subsystem-07.txt
Secure Shell Public-Key Subsystem (Proposed Standard) - 4 of 4
Token: Sam Hartman

Sam is holding own DISCUSS on this draft. Moving to approved, point raised, revised ID needed.

Russ - you sent e-mail about a revised paragraph, but didn't add this to the tracker.

Sam - will move to YES, but there are IESG comments that needed to be address (plus IANA), but the comments are all very small.

2.1.2 Returning Item

2.2 Individual Submissions
2.2.1 New Item
o draft-myers-ikev2-ocsp-04.txt
OCSP Extensions to IKEv2 (Proposed Standard) - 1 of 2
Token: Russ Housley

One DISCUSS, revised ID needed?

Jari - Certificate request payload for the client - a bug in the draft, or not useful in the OCSP case? Not sure it's useful in any other case either!

o draft-schoenw-snmp-ether-02.txt
Simple Network Management Protocol (SNMP) over IEEE 802 Networks (Proposed Standard) - 2 of 2
Note: version 02 was submitted by the document editor on 9/21 and should be used in the IESG discussion
Token: Dan Romascanu

Sam declined to state a position on the call.

Mark's DISCUSS - Dan asked if comments have been e-mailed to the list or not - apparently they have not been. Mark is asking what situations require this - it's in 802.1 with SNMP directly over Ethernet, unclear how to resolve the circular reference.

Mark - Informational reference? It's work in progress, but you can point to that informationally. I guess you CAN run SNMP over Ethernet, but can you provide an example of motivation?

Jari - is Proposed Standard correct? It's interesting and mostly harmless, but why does it need to be PS?

Dan - obsoleting previous PS from beginning of IETF. IEEE 802 is writing a MIB and they'd like to have a PS reference instead of a downref.

Jari - do they have a rule that you can't refer to IETF work in progress?

Dan - apparently so.

Mark - does anyone else think we should have a motivation?

Jari - it's a good idea.

Sam - not sure how DISCUSS criteria applies to non-WG items, but "asking for motivation" is explicitly DISCUSS non-criteria for WG items.

Mark - will move to COMMENT with NO-OBJ.

Dan - will ask for example text from authors - AD Followup.

2.2.2 Returning Item

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-l1vpn-framework-04.txt
Framework and Requirements for Layer 1 Virtual Private Networks (Informational) - 1 of 4
Token: Ross Callon

Three DISCUSSes and no Ross - will existing DISCUSSes require new ID? We think so.

Mark - got response from one of the authors this morning but haven't parsed it yet.

o draft-ietf-tsvwg-vpn-signaled-preemption-01.txt
QoS Signaling in a Nested Virtual Private Network (Informational) - 2 of 4
Token: Magnus Westerlund

One DISCUSS - Jari says part of the document should be simply removed, that would allow Jari to remove DISCUSS. Magnus will follow up on this document - but it's DEFERed, anyway, by Mark.

Sam - even though DEFERed, I have a question - makes strong assertion that you're required to carry single-presedence traffic, so this exposes what percentage of your traffic is in each preemption. This provides traffic analysis information - is this new, or has it always been this way? Sam will seek security community review before next telechat.

o draft-ietf-opsec-current-practices-07.txt
Operational Security Current Practices (Informational) - 3 of 4
Note: Ross Callon is the proto shepherd
Token: David Kessens

Do not need to DISCUSS this today, also have new review that asks for a few clarifications. Can probably be RFC Editor note, but list as "revised ID needed" for now.

o draft-ietf-softwire-problem-statement-02.txt
Softwire Problem Statement (Informational) - 4 of 4
Note: Exiting Last Call on 9/28
Token: Mark Townsley

Two DISCUSSes, Mark has sent responses out today. If people haven't seen responses, Mark will work offline.

Revised ID needed.

3.1.2 Returning Item

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-huston-ipv6-iana-specials-01.txt
Administration of the IANA Special Purpose Address Block (Informational) - 1 of 2
Token: Dan Romascanu

One DISCUSS - was an exchange of e-mail, does Lars think we're clear now?

Lars - haven't gotten response on what IANA policy the authors want. Authors thinks the text excludes direct submissions to RFC Editor, but the IESG gives these some level of review.

Sam - can we use standard 2434 term?

Bill - specifically, "IETF Concensus".

Russ - RFC Editor note :-)

Bill - name changed in 2434bis, now "IETF Review".

Dan - would prefer to use stable reference, clearer and easier.

Lars - IANA put same question in their comments - they don't know what policy is. Will be on vacation next week, and may thus be slow to clear the DISCUSS if a resolution is reached earlier, but this isn't more than a one-line RFC Editor note.

o draft-dondeti-msec-mikey-genext-oma-02.txt
OMA BCAST MIKEY General Extension Payload Specification (Informational) - 2 of 2
Token: Russ Housley

Don't need to DISCUSS, revised ID needed.

3.2.2 Returning Item

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-shirey-secgloss-v2-07.txt
Internet Security Glossary, Version 2 (Informational) - 1 of 1
Token: Russ Housley

Russ - Dan, I'm not sure you can make these a DISCUSS. I think they are just comments since this is a document that comes to us via the RFC Editor.

Dan - possibly, if documents are taking another path. Information I'm looking at is so wrong, but it's not an end run - will change to ABSTAIN and move text to COMMENT.

Russ - and send to the RFC Editor. Are Jari's comments the same thing?

Jari - references that go to the wrong place.

Cullen - this is a document defining terms that we use everywhere

Russ - but it's not our document.

Sam - send note to RFC Editor saying don't obsolete 2828.

Bill - this is defining standards-track terminology. Should not be processed this way.

Russ - changing one paragraph up front.

Joyce - but this implies that it's OK with IETF.

Sam - 3932 requires "no problem", but we should also send message as IESG saying "very bad if this document viewed as normative, or gives the impression these are preferred terms for standards-track documents".

Russ - would take a long time to get consensus.

Bill - "IESG disclaims fitness of this document for any purpose", but maybe we can do wordsmithing to look less prescriptive? Uses "ISDs" to describe standards-track documents.

Russ - document author now has agreed to use a different term.

Russ - will put together response - approved, point raised, writeup needed? Jari has already cleared DISCUSS, Dan will do the same in the next few minutes.

Russ posted the following into Jabber a few minutes later:

[11:41 AM]<Russ> For draft-shirey-secgloss-v2-07 I propose:

This RFC is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this RFC for
any purpose and notes that the decision to publish is not based on
IETF review apart from IESG review for conflict with IETF work.
The RFC Editor has chosen to publish this document at its
discretion. See RFC 3932 for more information.

Note to the RFC Editor

The Abstract and the Introduction of this document include
prescriptive language that is more appropriate in a BCP. The
IESG strongly encourages the RFC Editor to work with the author
to come up with wording that does not imply an IETF concensus
on the definitions in this document.

3.3.2 Returning Item
3.3.3 For Action
o draft-kunze-rfc2413bis-04.txt
The Dublin Core Metadata Element Set (Informational) - 1 of 1
Token: Brian Carpenter

Brian isn't on the call - does any AD claim this draft? Lisa sent e-mail about this, it's clearly APPS-related for WEBDAV, IMAP, etc. Same authors that did original version, not widely deployed, comes inline with what Dublin group is doing.

Russ and Bill - are you gonna shepherd it? We still need to have a shepherd.

Lisa - exactly what I'm suggesting.

Lisa can put this on telechat agenda "soon"

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Network Endpoint Assessment (nea) - 1 of 2
Token: Russ Housley

Objections to sending this forward for external review?

Cullen - framework or security threat - say this now?

Russ - I can raise this during external review, or you can - either way would work.

Sam - think requirements document includes security analysis.

Mark - "NEA will not standardize protocols except..." implies you work on PT as mandatory-to-implement - this is picking something that exists, but that's still work. Is this semantics?

Sam - PWE3 doesn't specify MPLS, but you have to use MPLS for it to work...

Mark - but PWE3 didn't compare MPLS and IPSEC and pick one. They're "working on" both RSVP and LDP.

Sam - but not "specifying" LDP.

Mark - but they specify extensions to LDP. Didn't want this to look like PT is out of scope.

Russ - concern is that they don't go off and specify something new.

Mark - "specify" wordsmithing helps and maybe that's enough.

Russ - does Amy need an updated charter?

Amy - please send us an updated charter (since I don't know where the words are).

Mark - third-to-last paragraph...

Cullen - chances of us getting this right are zero, please send an updated charter

Mark will talk to Russ and Sam offline, this won't take long.

Approved for external review pending edits to the charter.

o Handover Keying (hokey) - 2 of 2
Token: Russ Housley

Objections to sending for external review?

Russ - we're including things in the charter to please all three camps. There's a lot of energy in each camp.

Jari - need to mention key framework requirement. Low-latency reauthentication - is this getting close to L2 SDOs?

Russ - point is to not be media-specific - if we go there, it should be done in L2 SDOs. Deliverable #4 - add media-independent before "low-latency".

Jari - have concerns about boiling the ocean, and discussion at last BOF. Just for the record, I thought this was much-needed work, but have changed mind after many rounds of discussion. Not harmful, just not as useful.

Russ - ability to establish a single key hierarchy with a branch for each media to allow movement between the various media without another round trip to the AAA server is most important to me. The SDO responsible for each media can specify the depth, breadth, and other details for their branch.

Jari - maybe that's the value of this working group.

Russ - we agree on the crown jewel here.

Russ - any other changes? None noted, will send Amy an update in a few minutes.

4.1.2 Proposed for Approval

4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o ADSL MIB (adslmib) - 1 of 1
Token: Dan Romascanu

Objections to charter update, replacing current charter?

Dan - no discussions that require changes to proposed text.

Sam - what's different from old charter?

Dan - new set of MIB models to be developed. Old charter had one MIB model now in IETF last call. New charter covers new MIB models.

Jari - when people implement new versions, how much work will this be to add?

Dan - usually new DSL technology is most of the work.

Secretariat will send WG Action recharter note.

4.2.2 Proposed for Approval
o Mobility for IPv6 (mip6) - 1 of 1
Token: Jari Arkko

Jari has two minor edits before announcement is sent.

5. IAB News We can use

Dave Meyer -

- Got IDN-nextsteps to Auth48, authors have approved. This was a long process, at least two years.

- Leslie - IAB is sending liaison to ITU-T to make sure they know what we think the next steps are (and please make changes to IETF protocols in the IETF), as we know they are considering some questions about IDNs..

- RAW workshop - have all participants and are working on agenda/assignments.

- Had Anderson, JFC, Glassey appeals.

- trying to provide good feedback on the BOFs.

- Dan - mention discussion in tech chat yesterday?

- Dave Meyer - will ask about making this available.

- Leslie - tech chat was on survey of tools for network address translation (beyond NATs). Only issue is that IAB didn't reach a conclusion here.

- Dan - lots of references to IETF work during discussions.

- Leslie - asking first is good, don't see an issue as long as we are clear on what is being forwarded.

- Cullen - we declined MIG BOF, but these guys aren't going away. Can somebody help these guys?

- Leslie - I also note the message Lars sent with the TCP issue. Watching to see what kind of concerted effort would be appropriate. Sometimes it's more successful for IAB folks to get interested and go work with people as individuals, rather than trying to make the IAB do something officially.

- Lars - Bernard said Vista will ship with Compound-TCP, but disabled by default.

- Lars - thinking about hosting researchers together with PFLDNet 2007 and the ICCRG meeting hosted by Aaron at ISI.

- Leslie - Lixia has responded with interest in Lars' TCP message, there may be others.

- Lars - workshop is in February, can discuss this in San Diego.

6. Management Issue

6.1 Management Issue for IESG call 28th of Sep: Selection of IANA expert for GIST (Magnus Westerlund)

Have done open call for IANA expert. If anyone has objections for current candidate, please say so. (silence followed)

Russ - send text for announcement. "In anticipation of registry creation".

6.2 Allocation of transmission numbers (Dan Romascanu)

Dan - issued raised a few months ago, 802.16 had allocated their own value, needed to fix this by defining current reality. Can relax a rule here to point to MIB documents from another SDO. Does IESG think we need a broader issue?

Jari - Changing policy forever, or just for this allocation?

Dan - believe we can make this descision in broader context.

Michelle - don't know where this policy is written down - requirement for RFC was simply matching what appeared to be previous practice. More of these issues will come up as we go through the matrix - lots of registries don't have policies written down, they're just too old.

Dan - will change IANA web page to say this.

Leslie - given this is a change (even from an unknown state), this needs broader review. Other people may have pointers to original documents, may have new perspectives. Some of the unknown policies are actually written down, but no one has told IANA. Don't publish RFC per registry, but do announce 2-week IETF last call for changes.

Dan - what's the practical course of action?

Leslie - just asking for objections solves the issues

Dan - probably 50 to 500 question marks on the pages we're talking about. One document is enough - not 50-500 RFCs!

Michelle - on some old registries, there really isn't anything written down. Will combine by topics to the extent possible.

Leslie - as Jari has been suggesting, this could be an exception and the general case could be discussed in more detail. If you want to pursue a lighter-weight version by asking for attention, this would put conversations on mailing list archives and on IANA registries.

Michelle - just make this IEEE assignment?

Dan - trying to find a more general approach, but making one exception is OK.

Leslie - need to make sure that we don't just expedite process, but that everything gets properly considered.

Dan - will send text to the list for decision, and will work with Michelle.

6.3 Response to ITU-T SG-13 Liaison Statement (Lars Eggert)

Lars sent out draft liaison statement yesterday, deadline is Oct 16. Different options to send these, such as from the TSV area after broader consensus or from the IESG. Liaison statement would be stronger with Brian's protocol extensions draft approved. All DISCUSSes have now cleared - Ross should sent a note out on this,but he's not on the call. We need to come to agreement next week to get text approved.

Sam - there's an issue because there were significant differences between IETF last call text for this draft and what's in the repository now.

Lars - Ross can make decision on whether another IETF Last Call is required or not, but this takes time, and we don't have a lot. If Last Call is required, IESG can approve the text in this case. Can we tell ITU-T that we'll respond in two-four weeks? Probably not (dates are probably based on ITU-T meeting dates). Will discuss this with Scott Brim.

Magnus - we need to have something for ITU-T to reflect on in their meeting.

Lars - could rephrase "IESG has recently approved" as "IESG is currently considering".

Lars - we can discuss this on informal call next week (since Ross is in China this week).

Russ - at least one AD said they hadn't read the statement yet.

Cullen - that was me - and I read it during this discussion. I have no problem with it.

Russ - then we can record consensus on the response.

7. Agenda Working Group News

Jari Arkko - Had three BOFs, all three denied. Trying to figure out how to move work forward in the future (NETLMM, aviation).

Ross Callon - not present

Brian Carpenter - not present

Lisa Dusseault - USEFOR is finishing, documents in AD review, noticed normative reference to errata page, not stable and not reviewed (enough) - is this a problem?

- Russ - agree not stable and hard to get updated.

- Sam - RFC Editor errata page? Yes. Errata already approved? Yes.

- Lisa - authors said they could drop the reference.

- two charset reviewers, both excellent

- still uncomfortable about how to involve working group in appeal - don't know what to do about this.

- Michelle - are charset reviewers already on-stream? Yes.

Lars Eggert - all remaining RDDP drafts will hit the IESG next time, closing RDDP WG after finishing their work.

- IPPM third-party IPR disclosure was extremely vague, WG not sure what to do.

- PMTUD also being LCed with INT-AREA

- approved pre-congestion notification BOF, but not flowreq.

Bill Fenner - none

Ted Hardie - not present

Sam Hartman - none

Russ Housley - none

Cullen Jennings - approved P2PSIP and Media Control BOFs and declined MIG BOF

David Kessens - none

Jon Peterson - not present

Dan Romascanu - none

Mark Townsley - none

Magnus Westerlund - additional WG chairs in RMT and NSIS.