Narrative Minutes

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Notes for the February 16, 2006 IESG Teleconference

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

1. Administrivia

1.1 Roll Call

ATTENDEES
---------------------------------
Brian Carpenter (IBM) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA liaison
Leslie Daigle (Cisco) / IAB Chair
Spencer Dawkins (Futurewei) / Scribe
Marshall Eubanks (Multicast Tech) / Scribe
Bill Fenner (AT&T) / Routing Area
Barbara Fuller (NSS) / IETF Secretariat
Ted Hardie (Qualcomm, Inc.)/ Applications Area
Sam Hartman (MIT) / Security Area
Russ Housley (Vigil Security, LLC) / Security Area
David Kessens (Nokia) / Operations and Management Area
Allison Mankin / Transport Area
Dave Meyer (Cisco/University of Oregon) / IAB Liaison
Jon Peterson (NeuStar, Inc.) / Transport Area
Joyce K. Reynolds (ISI) / RFC Editor liaison
Barbara Roseman (ICANN) / IANA liaison
Dinara Suleymanova (NSS) / IETF Secretariat
Mark Townsley (Cisco) / Internet Area
Amy Vezza (NSS) / IETF Secretariat
Margaret Wasserman / Internet Area
Bert Wijnen (Lucent) / Operations and Management Area
Alex Zinin (Alcatel) / Routing Area

REGRETS
---------------------------------
Scott Hollenbeck (VeriSign)/ Applications Area
Ray Pelletier (ISOC) / IAD

1.2 Bash the Agenda

draft-ietf-geopriv-dhcp-civil-09.txt and draft-ietf-grow-rfc1519bis-04.txt were moved forward on the agenda (but are reported in original agenda order in these minutes, just so they are easier to find).

1.3 Approval of the Minutes

Feb 2 minutes were accepted with no discussion.

1.4 Review of Action Items

Proposal to announce WG drafts when adopted? Brian has done this.

Example phone numbers? Bert needs to do this.

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

No updates this week, send updates if you have them.

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 Three-document ballot: - 1 of 13
- draft-ietf-rmonmib-raqmon-framework-15.txt
Real-time Application Quality of Service Monitoring (RAQMON) Framework
(Proposed Standard)
Note: IETF Last Call still in progress, ends Monday Feb 13.. One new rev
will come out Monday to address GenArt review comments.
- draft-ietf-rmonmib-raqmon-mib-12.txt
Real-time Application Quality of Service Monitoring (RAQMON) MIB
(Proposed Standard)
- draft-ietf-rmonmib-raqmon-pdu-12.txt
Transport Mappings for Real-time Application Quality of Service
Monitoring (RAQMON) Protocol Data Unit (PDU) (Proposed Standard)
Token: Bert Wijnen

We did not discuss on this call (authors are working on new text now, goes to AD followup)
.
o draft-ietf-ipcdn-pktc-mtamib-09.txt
Multimedia Terminal Adapter (MTA) Management Information Base for
PacketCable and IPCablecom compliant devices (Proposed Standard) - 2 of 13
Note: Still in IETF Last Call, which ends Feb 13 (Monday); So if serious
comments come up from that I may have to withdraw. it from Agenda.
Token: Bert Wijnen

Bert needs to follow up with Allison, just saw DISCUSS. Allison will add text by end of call, should be handled with RFC Editor note.

o draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt
Node ID based RSVP Hello: A Clarification Statement (BCP) - 3 of 13
Token: Alex Zinin

This is going back to Last Call? Yes, has already been sent back out for Last Call as Proposed Standard (change of target status, from BCP). Alex thought this document needed another last call, Brian thought it didn't, and Sam thought the procedure was unclear.

This document will appear on next telechat agenda.

o draft-ietf-msec-newtype-keyid-04.txt
The Key ID Information Type for the General Extension Payload in MIKEY
(Proposed Standard) - 4 of 13
Token: Russ Housley

Allison changed her ballot to NO-OBJ. Sam requested AD followup, and this specification probably does need a revised ID.

o draft-ietf-grow-rfc1519bis-04.txt
Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and
Aggregation Plan (Proposed Standard) - 5 of 13
Note: Geoff Huston is the proto shepherd
Token: David Kessens

Ted - my DISCUSS is simple ("Why is this a Proposed Standard?") - is there anything someone needs to point to in a normative spec, or are we using this spec to obsolete a standards-track spec? David believes that the document is borderline for a BCP. Ted, Margaret, and Russ would also be happy with BCP.

Brian believes IESG can make this call (removing Ted's DISCUSS).

David asked if a BCP can update a Proposed Standard. Sam pointed out that he has been having a related conversation with Brian, for a specification that was going the other way.

Ted will move to NO-OBJ and let David figure out whether a new last call is required.

Margaret said, "I actually have three parts to my DISCUSS. The second part is that IPv6 isn't mentioned (this seems strange). The third part is the DISCUSSy part of my concern. If we publish a standards-track document that says we need to do an IPv4 multihoming document, do we have consensus to do this document? We need to do this."

Brian's concern is that a new IPv4 multihoming document simply isn't going to happen, so asked for e-mail discussion (since this is a complex issue).

This document goes to AD Followup for David.

o draft-ietf-mip4-rfc3012bis-05.txt
Mobile IPv4 Challenge/Response Extensions (revised) (Proposed Standard) - 6
of 13
Token: Margaret Wasserman

Allison and Mark added NO-OBJ ballot positions. There were a couple of DISCUSS postions, with absent DISCUSSants.

Margaret said she can do AD Followup with other ADs. Brian asked her to send out a personal reminder as well.

o draft-ietf-dnsext-tsig-sha-06.txt
HMAC SHA TSIG Algorithm Identifiers (Proposed Standard) - 7 of 13
Note: The PROTO Shepherd for this document is Olafur Gudmundsson
<ogud@ogud.com>.
Token: Margaret Wasserman

There was some confusion about this ballot position (www and www1 URLs weren't consistent).

Mark and Bert stated NO-OBJ ballot positions, so the document was approved with no objections. There are still a couple of (non-show-stopping) IANA questions that need to involve the WG chairs as well as document authors, so the document will be reported as Point Raised/Write-up needed.

o draft-ietf-aaa-diameter-sip-app-11.txt
Diameter Session Initiation Protocol (SIP) Application (Proposed Standard)
- 8 of 13
Note: A new rev is expected Feb 9 or 10 to address some AD review comments
and a comment from Sam Hartman on MD5 usage.. PROTO SHEPHERD: John Loughney
<john.loughney@nokia.com>
Token: Bert Wijnen

Sam deferred this document before the telechat.

o Three-document ballot: - 9 of 13
- draft-ietf-mpls-rfc3036bis-03.txt
LDP Specification (Draft Standard)
- draft-ietf-mpls-ldp-experience-00.txt
Experience with the LDP protocol (Informational)
- draft-ietf-mpls-ldp-survey2002-00.txt
LDP Implementation Survey Results (Informational)
Token: Alex Zinin

Allison reported her ballot position as NO-OBJ. Alex hasn't gotten to see DISCUSSes yet.

Margaret thought the implementation report should show implementations that actually tested against each other - this is what we did with PPP. Sam thought this should be handled the way it was for BGP (BGP specification was not held to this standards).

Brian was somewhat concerned because the implementation report is dated 2002. Alex stated that the specifications have been changed based on implementation experience, what's in the implementation report actually matches what's in the specification, and said he will verify with WG chairs. Margaret was OK with "implementations tested against another implementation in this report".

Sam requested more text in Security Considerations section.

Alex asked about a normative references issue - similar to Sam's concerns on MPLS-PING. Sam will reply by Monday.

Bert asked if IESG has enough positions stated? Amy stated that the specification will go to AD Followup, but does have a couple of open positions still.

o draft-ietf-sieve-3431bis-04.txt
Sieve Extension: Relational Tests (Proposed Standard) - 10 of 13
Note: Document shepherd is Alexey Melnikov
<alexey.melnikov@isode.com>
Token: Scott Hollenbeck

Approved with no discussion.

Allison pointed out a friendly suggestion to change normative reference to a document that is far from approval (tracker status is ID-Exists), and asked that the shepherd should look at this suggestion.

o Two-document ballot: - 11 of 13
- draft-ietf-cat-kerberos-pk-init-34.txt
Public Key Cryptography for Initial Authentication in Kerberos (Proposed
Standard)
Note: proto shepherd: jhutz@cmu.edu
- draft-ietf-krb-wg-ocsp-for-pkinit-06.txt
OCSP Support for PKINIT (Proposed Standard)
Note: Minor comment about security considerations sent to WG. I'm
holding this draft until pkinit catches up.
Token: Sam Hartman

ADs with open positions are absent, Sam is only DISCUSS.

Sam said he is aware of comments from Ted and Brian, and will resolve in AD Followup.

o draft-ietf-pkix-gost-cppk-05.txt
Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 algorithms
with the Internet X.509 Public Key Infrastructure Certificate and CRL
Profile. (Proposed Standard) - 12 of 13
Note: Proto shepherd is Steve Kent <kent@bbn.com>
Token: Russ Housley

Approved with no discussion, since there weren't even any comments from other ADs.

o draft-ietf-sip-refer-with-norefersub-04.txt
Suppression of Session Initiation Protocol REFER Method Implicit
Subscription (Proposed Standard) - 13 of 13
Note: PROTO shepherd dean.willis@softarmor.com Last Call ends 2/17.Â
On IESG agenda 2/16. Comments encouraged to the end.
Token: Allison Mankin

This specification has the ballots to be approved, but Last Call had not ended as of the telechat date. We will wait until Last Call ends to mark as approved, then announce on Monday.

2.1.2 Returning Item
o draft-ietf-idr-cease-subcode-07.txt
Subcodes for BGP Cease Notification Message (Proposed Standard) - 1 of 4
Token: Bill Fenner

The document was removed from the agenda prior to the start of the teleconference.

o draft-ietf-geopriv-dhcp-civil-09.txt
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic
Addresses Configuration Information (Proposed Standard) - 2 of 4
Note: Over-ride vote requested; please review accordingly.
Token: Ted Hardie

As best anyone can remember, this is the first override vote for a protocol specification.

Scott stated that he hadn't had time to read the document. Brian asked if everyone else was ready to move ahead.

Bert pointed out that Margaret found new issues during a re-read, and Brian responded that we don't collect new issues during an override vote. There is no DISCUSS option for an override vote.

(Some discussion of exact mechanism for override balloting took place here. Discussion included Allison asking about DISCUSS criteria, and Sam concerned about voting "YES" since this is more of an endorsement while "NO-OBJ" on a normal ballot is not.)

Make said he has not read the draft recently enough with a proper understanding of what's being voted on. Based on a quick re-read, he can't vote "YES", and asked what he should vote on the override ballot if he has issues with the document that aren't the issues in David's DISCUSS.

Bert said that he needed RFC Editor notes, answer from DHC (due tomorrow) in order to vote.

Ted said he has fixed/added RFC Editor notes to the balloting, and that DHC has reviewed 07 and isn't likely to raise new DHCP issues with this revision.

Brian asked if three people haven't read the draft recently enough, should the IESG hold the override vote in a week?

Ted expressed polite frustration, and appreciation for people who took time to read this document. Ted noted that Bill's comments would not have been a DISCUSS under current review criteria, and asked "Are we holding this document up to an extraordinary bar?" Ted believes that a "YES" vote here shouldn't be the same as a "YES" vote in a normal ballot, and noted that David offered three times to do polling informally on whether David has support for his DISCUSS, so we know more about where we stand - other DISCUSS issues are workable.

Russ said that Sam's questions in Jabber are the right ones (the questions are: " 1) Does anyone on the call believe they would need more time for evaluating David's discuss?" and "2) Does anyone believe David's discuss should be blocking.")

Margaret said she would have the same DISCUSSes now.

Allison noted that the document has been looked at carefully by community experts.

Brian expressed confidence that these DISCUSSes can be worked, but Allison pointed out that people can come up with new DISCUSSes.

Brian asked if people need more time to look at David's DISCUSS? Mark does (a week would be ok).

Brian asked if anyone believed David's DISCUSS should be blocking the document? Bert expressed readiness for a vote, and Russ requested a straw poll, which David said would be sufficient for his purposes on evaluating his DISCUSS.

Brian asked who would block based on David's DISCUSS? Bert would, with a couple of abstains.

Based on this straw poll, David will move his ballot position to ABSTAIN.

Brian asked Ted to look at the new DISCUSSes, too, and wished they hadn't come up so late. Bill answered that this is expected when there's a re-review - things will come up when people look at the document again.

Allison pointed out that Bill's concern is about E911 dealing with information (not an easy fix, not like typos).

Margaret said she was moving her position to a comment, but she is still concerned about the ambiguity. Based on working with addresses that she is familiar with, she doesn't know what to put in A4.

Allison said she would ask Henning to focus on this.

David said that he hopes shepherding AD still takes David's comments seriously.

Ted said he will resolve problems with one respin that includes RFC Editor notes and DHC inputs.

o draft-ietf-l2vpn-vpls-bgp-06.txt
Virtual Private LAN Service (Proposed Standard) - 3 of 4
Note: This document and draft-ietf-l2vpn-vpls-ldp are different solutions
to similar problems. L2VPN agreed to advance both and essentially "let the
market decide."
Token: Mark Townsley

Allison and Alex stated NO-OBJ ballot positions.

There was some discussion about why this document was listed as "returning" - it's been deferred, but it's never been on an agenda. This seems to be a known bug/artifact of the process.

Alex said he doesn't want to hold a DISCUSS since he's leaving the IESG.

Mark pointed out that we need to work implementation report requirements out in general, and Alex agreed that working group chairs have been ignoring the need for implementation reports for years. Brian said that Alex/Bill need to do a new BCP to really make this stick.

Mark pointed out that the ADs need to check with Thomas to make sure what people have been told previously (no curve balls at last minute).

o draft-ietf-l2vpn-vpls-ldp-08.txt
Virtual Private LAN Services over MPLS (Proposed Standard) - 4 of 4
Note: This document and draft-ietf-l2vpn-vpls-bgp are different solutions
to similar problems. L2VPN agreed to advance both and essentially "let the
market decide."
Token: Mark Townsley

Allison stated a NO-OBJ ballot position. Since there are DISCUSSes, this draft will be in AD Followup.

2.2 Individual Submissions
2.2.1 New Item
NONE
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-mip6-firewalls-04.txt
Mobile IPv6 and Firewalls: Problem statement (Informational) - 1 of 5
Token: Margaret Wasserman

Document is approved with no discussion.

o draft-ietf-dhc-dual-stack-04.txt
DHCP: IPv4 and IPv6 Dual-Stack Issues (Informational) - 2 of 5
Token: Margaret Wasserman

Document is approved with no discussion.

o draft-ietf-sipping-trait-authz-02.txt
Trait-based Authorization Requirements for the Session Initiation Protocol
(SIP) (Informational) - 3 of 5
Note: PROTO shepherd gonzalo.camarillo@ericsson.com
Token: Allison Mankin

Russ has DISCUSS (and isn't here). Allison requests AD Followup and will add reference to technology with RFC Editor note - Jon agrees.

o draft-ietf-capwap-eval-00.txt
Evaluation of Candidate CAPWAP Protocols (Informational) - 4 of 5
Token: Bert Wijnen

Brian asked if Bert saw his comment - there's a serious reference error. Yes, Bert saw comment.

Approved, Point Raised, Write-up Needed.

o draft-ietf-capwap-objectives-04.txt
Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)
(Informational) - 5 of 5
Token: Bert Wijnen

Brian has comments, that Sam used as basis for DISCUSS, and the authors are already responding. Bert will follow up.

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-mehta-rmt-flute-sdp-05.txt
SDP Descriptors for FLUTE (Experimental) - 1 of 2
Token: Allison Mankin

Allison is holding DISCUSS for Michelle's review (has lots of IANA considerations).

Brian asked, "Allison and I aren't the only people who have read this, right?" Allison has lots of targetted reviews mentioned in the tracker.

o draft-nir-ikev2-auth-lt-05.txt
Repeated Authentication in IKEv2 (Informational) - 2 of 2
Token: Russ Housley

Brian has DISCUSS, and is wondering whether this should be Informational or Experimental. Author doesn't know, either.

Allison asked "why not Proposed Standard?" Sam said we don't have concensus for Proposed Standard, but the document could be advanced with experience.

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-white-pathconsiderations-05.txt
Considerations in Validating the Path in BGP (Informational) - 1 of 2
Note: Document has been referred to RPSEC. Tony says it is related to what
the WG. is doing, yet the WG would have no problem with the RFC Editor
publishing this.
Token: Alex Zinin

No DISCUSSes, but no YESes, either. But all we need to do is say NO-OBJ to RFC Editor.

No objections, so will send NO-PROBLEM.

Alex has proposed message in the tracker - please put this in the ballot writeup box.

o draft-stiemerling-midcom-simco-08.txt
Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 (Experimental)
- 2 of 2
Token: Jon Peterson

Is this specifically proprietary? We should flag that to RFC Editor if it is.

Sam asked what "proprietary" means in this case. Brian supplied the definition, "if you sell something and no one else does."

Michelle asked if this specification is just updating the port number in IANA. Jon confirmed this.

Bert cleared DISCUSS based on RFC Editor note.

3.3.2 Returning Item
NONE

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

Ted said he has one chair and is looking for another (e-mail-savvy and not roman script in native language).

Bill passed on a comment that Russ said he has concerns on EAI, but he didn't tell me what they were.

Alex asked, "what is IAB position on this whole thing?" Ted answered, "We're seeing closed e-mail communities now with no way of saying what script IS required. Communities will form around languages anyway, we're trying to avoid the script problem, too. Time is well past for us to do this work, or we'll have a more-fractured e-mail space and more trouble."

Alex asked, "so, the working group would pick one standard that is guaranteed to work anywhere internationally?" Ted answered, "This is an extension, so SMTP would work the way it does today. This is ESMTP saying 'I support more formats'. The downgrade specification would get you back to where we are today - an address that no one can read, but will still be routable. Russ probably is correct about 'working group chairs authorized to add documents', should be "adding documents will happen by working group charter updates'."

Brian said the issue is that a chartered document might split - that's actually allowable now, with a very minor recharter.

Brian asked if there was any IAB feedback during internal review? Nothing beyond BOF report. David and Leslie don't know of any IAB feedback.

Ted asked if the charter change was sufficient for external review?. Bill said he thought this would be OK for Russ's concerns.

Ted will send a note to IESG with a tomorrow-afternoon deadline asking if this is OK, will send ticket after timer expires.

4.1.2 Proposed for Approval
o Secure Inter-Domain Routing (sidr) - 1 of 1
Token: Alex Zinin

Alex said he had received comments from Russ in reply to Bill's e-mail.

Brian wanted to know chairs, along with a couple more things.

Ted asked, as an aside, "are we holding a March-16th telechat?" Brian answered, "Hope so - I have items for it."

Alex haven't decided on the second chair yet. Would rather have one proposed chair as a participant in the working group - use this person as technical advisor?

Amy will wait for instructions from Alex before proceeding.

4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o MIPv6 Signaling and Handoff Optimization (mipshop) - 1 of 3
Token: Margaret Wasserman

Margaret state the charter changes are that HMIPv6 and FMIPv6 were published as Experimental and we now want to republish as Proposed Standard with appropriate security, also want to publish optimization of return-routability with CGA, want to publish MIPv6 interactions with IEEE 802.21 work currently underway. Want these changes reviewed externally.

No objections - will send notification and add to next telechat agenda.

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

Brian said the IPR working group has completed deliverables and now has new work to do. Have an update from two hours ago on charter text.

Ted is happy with text and with external review. Sam said he hasn't reviewed this closely enough - could he have a couple of days before this goes for external review?

Brian would like to get this done before Dallas (next meeting). Sam will have comments by tomorrow, and will then go to external review on Monday.

Amy requested, "Please send as new ticket, not under previous ticket."

o TCP Maintenance and Minor Extensions (tcpm) - 3 of 3
Token: Jon Peterson

Jon said this is a milestone update (very few text changes), removing lots of old milestones that were achieved and adding realistic dates for new milestones.

We'll just update the charter and send a notification about the update.

4.2.2 Proposed for Approval
NONE

5. IAB News We can use

Dave Meyer said:

* IAB is working on Julian Mehnle appeal.
* IAB is looking at NOMCOM IESG slate and has asked for additional input (and received some).
* Also looking at ISOC BoT slate.
* Also working on Bad Traffic workshop and Apricot presentation.
* Also planning for Dallas.

Sam pointed out that the Bad Traffic discussion has been pretty quiet.

Dave agreed, and noted that Leslie recently sent draft agenda to the list.

6. Management Issue

6.1 Appointing IESG Vice-Chairs (Brian Carpenter)

These will actually be IESG Whips - Bill and Russ will serve, and they need to update their job descriptions.

Whips or Vice-Chairs? Sam has a preference but not an objection. Brian heard "Vice-Chair doesn't seem IETFish" as feedback. We'll need to explain "whip" for non-English-speaking participants.

6.2 Response to Morfin Appeal Against draft-ietf-ltru-registry (Sam Hartman)

Sam stated that he hadn't gotten any objections, after sending out proposal yesterday. Time for a vote. There were no objections to Sam's proposed text.

Who actually sends the text to the person who appealed? IESG Secretary, historically. Send "From the IESG"? Yes.

6.3 Appointment of interim reviewer for the URI registries created under RFC
4395. (Ted Hardie)

Ted is planning on Graham Klyne - any other suggestions? Nice words from several, but not proposed changes.

IESG approves this.

6.4 Appeal response to J-F. C. Morfin's appeal to his suspension from the
ietf-languages mailing list. (Ted Hardie)

Now have second version sent to IESG-only list (please consider the changed version).

Sam preferred the first version but could accept either version.

IESG approved the text, so the response will be sent.

6.5 IESG appointment to IAOC (Brian Carpenter)

Appointed and announced Kurtis Lindquist previously (just minuting this now).

6.6 Confirmation of NomCom nominee for IAOC (Brian Carpenter)

Has everyone seen the nomination? No one said, "no".

Any objections? We confirmed the nomination (but the nomination will be announced by NOMCOM).

6.7 For approval: IESG Statement on disruptive posting (Brian Carpenter)

Brian asked, "Do we announce this, or put it out as a proposal?" Sam suggested that we ask for comments in the postings.

IESG approved the posting, and it will be posted.

7. Agenda Working Group News

Brian - no.

Bill - no.

Ted - still haven't gotten anything back from Japanese on IRIS for Routing Registry - this may be a Bar BOF. OPES is spinning down after Dallas.

Sam - no.

Allison - no.

Jon - no.

Mark - no.

Margaret - no.

Bert - Bert brought up the issue of CAPWAP chairs having appointed EDITORS of the CAPWAP protocol document to be (replacing a set of AUTHORS of an earlier LWAPP input-document to the WG). Bert believed that the WG chairs are allowed/tasked to carefully select Editors for WG documents, even though he could not find explicit text in a BCP. Bert wanted to know if any IESG member though he was wrong (or right) The IESG did not see anything wrong with interpretation from Bert.

Alex - no.