IESG Telechat 2006-07-06 (Narrative Summary)

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the July 06 2006 IESG Teleconference

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

Thanks for corrections from Dan Romascanu, Lisa Dusseault, Ted Hardie,, David Kessens, and Brian Carpenter

1. Administrivia

1.1 Roll Call

1.2 Bash the Agenda

Mark has asked for his document to be moved to the head of the line (since he's only available early in the call). It will be reported in agenda order.

1.3 Approval of the Minutes

Official minutes approved with no discussion.

1.4 Review of Action Items

Jari's task is "in progress"

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

Once again there are no updates, but Jon threatened a whip round if there are no updates after Montreal.

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-ipfix-protocol-22.txt
    IPFIX Protocol Specification (Proposed Standard) - 1 of 5
    Token: Dan Romascanu

Ross stating a postion? NO-OBJ.

Dan says authors agree on a new revision responding to the DISCUSSes.

Sam - do WG have sufficient Security expertise to address my DISCUSS?

Dan - we can talk about this in Montreal, and if you can name a security expert, that would help.

o Two-document ballot: - 2 of 5
     - draft-ietf-radext-rfc2619bis-04.txt
       RADIUS Authentication Server MIB for IPv6 (Proposed Standard)
     - draft-ietf-radext-rfc2618bis-04.txt
       RADIUS Authentication Client MIB for IPV6 (Proposed Standard)
    Token: Dan Romascanu

Documents were approved with no discussion.

o draft-ietf-ltru-matching-15.txt
    Matching of Language Tags (BCP) - 3 of 5
    Token: Ted Hardie

Sam's position? ABSTAIN, really disagree with this being a BCP, understand argument and understand I'm in the minority.

Ted has an RFC Editor note to address the only DISCUSS (Brian's, who will move to NO-OBJ), so will be approved and announced Monday.

o draft-ietf-sieve-rfc3598bis-05.txt
    Sieve Email Filtering -- Subaddress Extension (Proposed Standard) - 4 of 5
    Token: Lisa Dusseault

Mark's position? NO-OBJ.

Did Cullen see the note that the draft doesn't define a separator? Yes, so how does this work (since it works today).

Ted - this is always for incoming, you never use this on a field someone else filled in - it's site policy.

Cullen - if my site was running this, how do I know how to configure my mailboxes?

Sam - site instruction would say plus or minus, just based on some website.

Cullen - I have to guess or ask someone, and this is all local configuration.

Sam - you just pick subaddresses based on site policy and people use that separator to send you e-mail.

Cullen - OK, I'll clear my DISCUSS.

Lisa considering adding an RFC Editor based on Brian's comments.

o draft-ietf-l2tpext-pwe3-ethernet-07.txt
    Transport of Ethernet Frames over L2TPv3 (Proposed Standard) - 5 of 5
    Token: Jari Arkko

Jari isn't on the call, but has sent a message - can Mark channel? Mark-as-Jari says "revised ID needed"

Ross's position? not yet.

Bill's position? NO-OBJ.

Ted's position - NO-OBJ.

2.1.2 Returning Item
o draft-ietf-simple-xcap-11.txt
    The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
    (Proposed Standard) - 1 of 1
    Note: Note that this document was pulled from the RFC Editor queue and is
    returning with some changes, which are recorded in the tracker.
    Token: Jon Peterson

Dan's DISCUSS - is providing proposed text for the document, based on NetConf experience/war stories. Jon thinks this is reasonable (may not be word-for-word).

Lisa's DISCUSS - need to talk with Jonathan next week, we can make progress.

Ted - please remember that this document was approved and in the RFC Editor queue when the need for these changes was discovered by implementation.
Going back to basic design decisions at this point would be a real problem. As Dan pointed out, this is a point solution, not the ultimate answer; it doesn't
even pretend to work if the problem doesn't look like this.

Lisa - authors can take an opportunity to fix something before pulling it again or issuing a revised RFC later.

Ted - can you rephrase your DISCUSS so that it looks like the working group has a choice?

Lisa - UID addition was late in the process, and mentioned in two other last call comments.

Brian - don't like to overrule working group consensus, especially when this document was approved once, a long time ago (including ballots from Thomas Narten and Harald). Would be good to sit with Jonathan and Lisa in Montreal.

2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
o draft-ietf-ipsec-ike-auth-ecdsa-05.txt
    IKE and IKEv2 Authentication Using ECDSA (Proposed Standard) - 1 of 1
    Token: Russ Housley

Russ has an open position, but there are no DISCUSSes - approved with no discussion on the call, subject to the end of
last call (for a downref) which expires 2006-07-20.

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-dnsext-mdns-46.txt
    Linklocal Multicast Name Resolution (LLMNR) (Informational) - 1 of 6
    Token: Mark Townsley

Was deferred this morning.

o draft-ietf-ipfix-architecture-11.txt
    Architecture for IP Flow Information Export (Informational) - 2 of 6
    Token: Dan Romascanu

Will be in AD Followup - DISCUSS is because this is closely tied to the protocol document.

o Two-document ballot: - 3 of 6
     - draft-ietf-radext-dynauth-client-mib-06.txt
       Dynamic Authorization Client MIB (Informational)
     - draft-ietf-radext-dynauth-server-mib-06.txt
       Dynamic Authorization Server MIB (Informational)
    Token: Dan Romascanu

Was approved with no discussion on the call.

Dan pointed out that he has corrected the IANA note - there was confusion between the two documents.

Sam pointed out that IANA notes are just to tell IANA they have no actions.

Dan - what do I do when IANA reviewed the document and didn't interpret the contents of the document correctly?

Brian - please make sure the documents are unambiguous, and then IANA note would make sense.

Barbara - Michelle has a way of doing this, and we don't know what that way is.

Bill - need to make sure IANA understands - can you talk via phone and make sure everyone has the same understanding? Don't just put in a note that might still be misunderstood.

Dan will coordinate with Yoshiko, IANA note will be removed from the announcement.

o Two-document ballot: - 4 of 6
     - draft-ietf-radext-rfc2621bis-04.txt
       RADIUS Accounting Server MIB for IPv6 (Informational)
     - draft-ietf-radext-rfc2620bis-04.txt
       RADIUS Accounting Client MIB for IPv6 (Informational)
    Token: Dan Romascanu

Approved with no discussion on the call.

o draft-ietf-avt-rfc2190-to-historic-06.txt
    RTP Payload Format for H.263 using RFC2190 to Historic status
    (Informational) - 5 of 6
    Note: PROTO shepherd: Colin Perkins csp@csperkins.org
    Token: Cullen Jennings

Approved with no discussion on the call.

Cullen has added Dan's comment to the RFC Editor note.

Brian - also need to instruct RFC Editor to label RFC 2190 as Historic in the RFC Index when this draft is published. as RFC

o draft-ietf-netlmm-nohost-ps-04.txt
    Problem Statement for Network-based Localized Mobility Management
    (Informational) - 6 of 6
    Token: Jari Arkko

Brian - expecting an update for my DISCUSS, revised ID needed? Dan has same expectation, Jari 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-mankin-pub-req-09.txt
    Requirements for IETF Technical Publication Service (Informational) - 1 of
    2
    Token: Brian Carpenter

Brian believes this is Revised ID Needed. Leslie would like to hear the expected changes, just to speed things up.

Brian hasn't looked at what's needed to address the existing DISCUSSes because he was heading off future DISCUSSes. Should ask Jon to state a position - stated NO-OBJ. Brian will put the plan together tomorrow.

o draft-alvestrand-ipod-02.txt
    IETF Operational Notes (Experimental) - 2 of 2
    Note: RFC 3933 process experiment
    Token: Brian Carpenter

Mark - there is no mention of the Wiki - is the Wiki encroaching what an ION is? Brian said the Wiki was newer than Harold, but IONs should be more structured than Wiki pages. Henrik will have a Subversion server running on the same server as the Wiki, so we might be close. But this is a work in progress, speaking practically.

Mark - would just like to nail down the description of an ION a bit. Is it a Wiki page with version control?

Sam - ION is a formal statement that has been approved, but Wiki pages aren't "approved" or "last called". Could implement on a Wiki, but don't think this is a good idea. Also want to let other people enter IONs.

Brian - the proposal is that this question would be answered in the first three IONs.

Cullen - if all three first-IONs were in the draft, would that help?

Sam - not comfortable with this,.

Brian - still an experiment in progress.

Sam - not comfortable. Don't think IESG should be able to override other people's IONs, but it's important to have a single manager for the series (like, "is this in the scope of the ION series") - this isn't clear now.

Brian - Jari objected to "supreme authority" phrase.

Sam - while IESG doesn't manage content, it does manage the mechanics of the series. - Brian can buy this.

Brian - won't approve this today until the DISCUSSes go away - is Mark convinced? Mark is happy with storage ION, would like a pointer that the Wiki exists, but this is a COMMENT, not a DISCUSS.

Ted is happy with Brian's proposed fix, but Brian needs to talk to Harald to close this off.

Ross - useful experiment, but don't know what the experiment will include. Really liked the first three proposed IONs.

Brian - please ask people to state a position (even though this is Experimental) - and Jon stated NO-OBJ.

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-vandyke-mscml-09.txt
    Media Server Control Markup Language (MSCML) and Protocol (Informational) -
    1 of 2
    Note: Proposing we use response #1 (the no conflict response) and note #2
    (the this protocol was not reviewed by IETF and YMMV note). More details in
    id tracker comments.
    Token: Cullen Jennings

NO-OBJ to RFC Editor publishing. Cullen has questions about where the IESG note actually goes in the document. Bill said just to include the boilerplate as an IESG Note. Needs to go into the announcement, somplace like protocol quality in the announcements (but Cullen will use his judgement about where).

o draft-vanderveen-eap-sake-02.txt
    Extensible Authentication Protocol Method for Shared-secret Authentication
    and Key Establishment (EAP-SAKE) (Informational) - 2 of 2
    Token: Jari Arkko

Bill - need same editing on the notes - since Jari isn't here, Bill will "just do it" and copy Jari.

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
    NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Robust Header Compression (rohc) - 1 of 1
    Token: Magnus Westerlund

Magnus not on the call - apparently the requested change is large, because we're starting on ROHC version 2.

Brian - would like to know to what extent this will be backwards-compatible. Cullen has discussed this with Magnus and has no idea what the answer was - no, Allison said there was a negotiation phase, so should be backwards-compatible. Brian would like this to be mentioned in the proposed charter, but that's nit-picking.

Brian - put this out for external review during IETF week? People are going to be busy - no one had an opinion about this. Bill - always hard to do something close to IETF weeks, people add weeks to last calls, etc.

Slide this to next telechat, same slot? Issue request for comments with 7/20 deadline? Would actually be 7/24 or 7/25, with two-week period.

4.2.2 Proposed for Approval
o Mobility for IPv4 (mip4) - 1 of 2
    Token: Jari Arkko

No objection to rechartering, so it's approved? No, Jari wanted to defer one telechat anyway (sent a page-and-a-half e-mail with rewording). Will slide to 7/20 telechat.

o Datagram Congestion Control Protocol (dccp) - 2 of 2
    Token: Lars Eggert

Approved pending confirmation from Lars that this is the right text for the charter.

5. IAB News We can use

IAB is focusing on IETF 66, with various liaison appointments (802.16, etc).

Whittling down list of routing and addressing workshop attendees.

Discussing Net Neutrality, but haven't converged.

Also working on appeals (to the point of writing text).

Do have text around Simon's document and will publish to IESG later today.

6. Management Issue

6.1 expert review for capwap (Dan Romascanu)

Several people on IESG are interested in providing feedback on questions, so Dan forwarded to IESG. Would like to have one or two experts (TSV and RTG) designated during Montreal week. Have heard that TSV ADs had the same problem in one of their working groups (or was this one of Mark's working groups?).

Brian - probably have to work on this in Montreal (actions for absent members not helpful in getting anything done).

Actions to Mark and RTG? Dan will send action item text to Amy, and will clue Bill and Ross in on what's needed. RTG Directorate is a good place to look for help, but remember that working group wants help with a specific problem, not a general review.

Cullen - why not IAB?

Brian - need to boil question down smaller than eight pages.

Cullen - issue is that question is eight pages, not that the answer is hard.

Dan - question is about multiplexing on a single port - disagreement about criteria for making this choice.

Brian - one-paragraph question is key to getting help on this.

6.2 NomCom Liaison (Brian Carpenter)

Cullen has volunteered to general relief from other ADs. No objections, so Cullen will serve, and Brian will inform NomCom chair (directly or indirectly).

6.3 Areas for Next Year (Brian Carpenter)

Proposal is for no change next year. Anyone want to discuss?

Ross - process and infrastructure issues in addition to technical issues, and expertise isn't in the same people.

Brian - don't want people in leadership who think they focus on process issues. Even second General Area director should be technical. Would not go to NomCom asking for someone who wants to work on process.

Lisa - no general area? Brian - another way to look at this.

Leslie - IPR and Newtrk are trying to get work done.

Brian - we don't have to ask NomCom about this, because there's little constitution about this.

David - the "IETF process & procedures" part of the general area might actually fit reasonably well with the Ops area.

Brian- we can talk about this next week.

Jon and Lars were appointed for one-year slots, so will be reviewed this year.

6.4 JFC Morfin Appeals (Brian Carpenter)

Discussion was not minuted. Liaisons were not present.

6.5 Dean Anderson Appeal (Brian Carpenter)

Discussion was not minuted. Liaisons were not present.

7. Agenda Working Group News

Jari Arkko - not present

Ross Callon - no

Brian Carpenter - no

Lisa Dusseault - lots of discussion about WAE BOF, will discuss with Russ/Leslie/Sam next week. Russ was probably concerned about overlapping BoFs, and Sam doesn't (now) think this is true.

Lars Eggert - not present

Bill Fenner - PDF RFC document last call is ending, not sure how to proceed. There's a lot more going on than people said during last call.

- Brian - need to demonstrate PDF variant that is suitable for long-term archiving.

- Bill - but some people think we need a different experiment. Feel like loudest arguments against were "trust me" or "you don't understand" - how to deal with these comments?

- Sam - IETF-wide consensus is hard to judge. Don't know how to move forward either.

- Brian - this is why we need a second general area director

- David - we keep skipping over whether we need pictures in RFCs. If we do, we have to choose (but we know we need to choose).

- Sam - all you can conclude is that this proposal didn't get consensus, can't generalize.

- David - may conclude we can't do anything in this area, even though we want to do it.

- Bill - "something must be done, and this is something" is stupid, I know that.

- Leslie - need to change the way we have discussions like this, especially as we change the way we deal with the RFC Editor in the next few months. Inputs more useful in three months.

- Brian - first challenge is writing a summary.

- Bill - should RFP say anything about different output formats?

- Leslie - possibly yes, but could be too late in the game with too little review to throw into the RFP at this point. A "maybe"? Can't say "this is likely"..

- Sam - we have RFCs in PDF with figures today - how does "normative pictures" change the RFP?

- Leslie - some people believe RFC series has editorial consistency, want more involvement from RFC Editor providing feedback. How do we handle splitting one RFC stream from the others? We don't know how to have the conversation now.

- Bill - we don't know how to consult the RFC Editor in a way that generates a response.

Ted Hardie - working on area-wide review (but could review cross-area as well).

Sam Hartman - no

Russ Housley - not present

Cullen Jennings - no

David Kessens - no

Jon Peterson - no

Dan Romascanu - DISMAN has published last RFC, planning to close (have sent one-week comment request).

Mark Townsley - not present

Magnus Westerlund - not present