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

With corrections from: Russ Housley, Lars Eggert, Jari Arkko
    
1. Administrivia
                                                                        
  1.1 Roll Call

  1.2 Bash the Agenda

No additions, no changes noted.

  1.3 Approval of the Minutes

2007 11 01 Minutes - approved with no discussion.

2007 11 01 Narrative Minutes - approved with no discussion, Spencer to submit.

  1.4 Review of Action Items

IP   o Lisa Dusseault to find an author to update RFC 3406.

Still in progress...

IP   o Jari Arkko to write an explanation of IESG policy of  when ADs can request documents be considered by the IESG before the Last Call has ended.

Still in Jari's queue...

IP   o Cullen Jennings to get a response from the AVT WG to help solve an IANA Registration issue for wave-avi-codec-registry [IANA #97962]

Cullen - everyone reasonable has either declined or said "I don't know" about old entries, gotten a bug report but can't find anyone to verify. Use bug reporter as expert?

Sam - send notification about this to wide list of people.

Cullen - already sent to AVT, will forward to wider list (IETF)

Still in progress...

IP   o Chris Newman to draft an IESG recommendation regarding working group registration ownership.

Seem to have lost Chris from the call...

2. Protocol Actions


2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-xcon-framework-10.txt
    A Framework for Centralized Conferencing (Proposed Standard) - 1 of 6
    Note: Adam Roach is proto shepherd
    Token: Cullen Jennings

Lisa - no objection but would like to hear discussion about Informational status.

"Number of DISCUSSes"

Cullen - went through all of them, understand all but Informational, need to fix/revised ID needed. Want to push back on Informational - framework but also how actual implementations actually fit together. Don't think you can implement without understanding this document. May have factored that wrong in the working group, but this was common working group document for common issues.

Sam - by the time you finish with my/Tim's DISCUSSes, that's going to be even more true.

Cullen - don't want to be like MIDCOM moving INFO to PS. Does anyone agree? Going to INFO explodes this work, going back to WG.

Magnus - agree we don't want to do MIDCOM again, fine.

Lars - fine.

Ron - I'll clear.

Cullen - if people can clear on PS, that would be great. Been discussed in WG already.

Revised ID needed.

  o draft-ietf-simple-prescaps-ext-08.txt
    Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) (Proposed Standard) - 2 of 6
    Token: Jon Peterson

Sam - NO-OBJ but concerned about Lisa's comments - would consider ABSTAIN if she's recruiting ABSTAINs.

Chris - just some attempt to fix things, not insisting everything gets fixed. Let authors work through Lisa's list, if author says "too much work to fix" I'm ok, but there's enough there that needs a pass. Language tag needs to be fixed.

Lisa - not ABSTAINing because I'm unwilling to work with authors, but think document will only be good if you chop out half the functionality.

Jon - Chocolate-and-peanut-butter draft, not a problem in WG view. Chris's concerns are actionable.

Revised ID needed.

  o draft-ietf-behave-nat-icmp-06.txt
    NAT Behavioral Requirements for ICMP protocol (BCP) - 3 of 6
    Token: Magnus Westerlund

Five DISCUSSes, let's chat.

Magnus - checksumming - don't see use of transport header checksum issue, either correct or fails on payload checksum. Going beyond that doesn't help.

Cullen- chair of WG thought this was bad idea, posted on mailing list, no one said it wasn't a bad idea, WG editor ignored all this.

Ross - if there's consensus it's a bad idea, editor can't block that.

Magnus - this made more sense in TCP with ICMP errors, having NATs do this for TCP seems wrong.

Lars - Tried to push this as standard in TCPM and failed, now trying to do the same thing here.

Sam - authors don't understand ICMP and I've given up talking to them.

Lars - if this doesn't open any attack vectors - and it doesn't...

Magnus - will have discussion with Suresh. Requirements for ICMP extensions from NAT would be good - anyone have issues?

Ron - agree with that.

Cullen - right path, WG will ask if ICMP extensions are used.

Ron - 4950 implemented by both Cisco and Juniper.

Sam - doesn't ICMP extensions go away if you punt the checksums?

Ron - nothing in extensions to translate yet, but there's a draft.

Sam - should leave text in about that ("no extensions today are translated")

Jari - requiring that NATs process extensions/parse through the list, then when extensions do appear it will be easier to deal with them.

Cullen - "mandating implementation of no-op" - weird...

Magnus - need to think. Revised ID needed.

Jari - change will be significant - bring back for full evaluation? Not full last call, but at least one directorate review. Don't assume everything is fine with revision.

Magnus - will send back for WGLC, will have people contact you for directorate review.

  o draft-ietf-tsvwg-ecn-mpls-02.txt
    Explicit Congestion Marking in MPLS (Proposed Standard) - 4 of 6
    Note: Lars Eggert (lars.eggert@nokia.com) is document shepherd.
    Token: Lars Eggert

David - no obj, but fast and furious discussions with authors about changes - how to handle these?

Lars - not copied on any of this.

David - author in family emergency, other authors waiting to meet in a week or two. Not the usual case.

Lars - can hold this.

Sam - approve writeup needed for changes of unknown scope?  Not comfortable.

Lars - will hold DISCUSS until I get all-clear from authors.

AD Followup...

Dward - please send e-mail to authors/Fred Baker alerting them (my mailbox is blown up)

  o draft-ietf-sigtran-rfc4233update-02.txt
    TEI Query Request Number Change (Proposed Standard) - 5 of 6
    Token: Jon Peterson

Jon - just put in RFC Editor Note

Chris clearing his DISCUSS to NO-OBJ.

Document is approved on this call.

  o draft-ietf-mipshop-handover-key-03.txt
    Distributing a Symmetric FMIPv6 Handover Key using SEND (Proposed Standard) - 6 of 6
    Note: Document Shepherd is Vijay Devarapalli
    Token: Jari Arkko

Approved with no discussion.

2.1.2 Returning Item
  o draft-ietf-isis-wg-multi-topology-12.txt
    M-ISIS: Multi Topology (MT) Routing in IS-IS (Proposed Standard) - 1 of 2
    Token: Russ Housley

Approved with no discussion. There is an update - Russ confirmed that the note to the RFC Editor was correct (in jabber).

  o draft-ietf-16ng-ipv6-over-ipv6cs-11.txt
    Transmission of IPv6 via the IPv6 CS over IEEE 802.16 Networks (Proposed Standard) - 2 of 2
    Note: Bringing back to the agenda now that a new version exists.
    Token: Jari Arkko

Sam - didn't realize this was on agenda, will work with Jari, AD followup but expect to clear on this call.

Jari - I still have some checking to do, too.

 (Sam did clear later in the call - the document is approved).

 Point Raised, Writeup Needed.

2.2 Individual Submissions
2.2.1 New Item
  o draft-garcia-simple-presence-dictionary-06.txt
    The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) (Proposed Standard) - 1 of 1
    Token: Jon Peterson

Jon - "why this is a standard" - previous work was PS. People want to interop with dictionaries, pretty natural case for me.

Lisa - don't disagree, but this doesn't affect ability to interop, right?

Jon - (breaking up)

Cullen - downloading a program that SIGCOMP executes

Chris - will interop (by not using this) if somebody doesn't implement, but if you DO want to use this, needs to be standard.

Lisa - already better informed than five minutes ago, can clear on this call with it as standard. Wasn't sure that negotiation is solid, but you now know that issue - clearing DISCUSS.

Approved with no further discussion.

Jon - will make sure authors see your comments.

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions

3.1.1 New Item
  o draft-ietf-nfsv4-nfs-rdma-problem-statement-07.txt
    NFS RDMA Problem Statement (Informational) - 1 of 5
    Note: Document Shepherd: Spencer Shepler (spencer.shepler@sun.com)
    Token: Lars Eggert

Lars - authors need to respond to comments they've gotten from SECDIR, other DISCUSS that just came in. AD Followup for now.

  o draft-ietf-sipping-ipv6-torture-tests-04.txt
    Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) (Informational) - 2 of 5
    Token: Jon Peterson

Approved with no discussion on the call.

  o draft-ietf-eap-netsel-problem-08.txt
    Network Discovery and Selection Problem (Informational) - 3 of 5
    Token: Mark Townsley

Mark - have you guys seen e-mail from Jari on IESG list? Could add as RFC Editor note and approve now if people agree.

Will be AD Followup so Tim can look at this and respond.

  o draft-ietf-behave-p2p-state-05.txt
    State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) (Informational) - 4 of 5
    Token: Magnus Westerlund

Magnus - revised ID needed, don't need to discuss today.

  o draft-ietf-smime-cades-07.txt
    CMS Advanced Electronic Signatures (CAdES) (Informational) - 5 of 5
    Token: Tim Polk

Approved with no discussion on this call.

3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD

3.2.1 New Item
  o draft-lepinski-dh-groups-03.txt
    Additional Diffie-Hellman Groups for use with IETF Standards (Informational) - 1 of 1
    Token: Tim Polk

Michelle - have registrations been reviewed by designated experts?

Sam - can't answer that in real time.

Russ - expert provided comments.

Sam - if these are IKE registry, expert has reviewed.

No other registries involved, so no reason to hold document back.

Approved with no further discussion.

3.2.2 Returning Item
  o draft-mealling-epc-urn-02.txt
    A Uniform Resource Name Namespace For The EPCglobal Electronic Product Code (EPC) and Related Standards (Informational) - 1 of 1
    Token: Lisa Dusseault

Approved with no discussion on this call.

3.3 Independent Submissions Via RFC Editor

3.3.1 New Item
  o draft-irtf-tmrg-metrics-11.txt
    Metrics for the Evaluation of Congestion Control Mechanisms (Informational)     - 1 of 1
    Note: To be published according to draft-irtf-rfcs-01.txt

    Based on the Working Group Summary, I believe that the. second variant suggested in Appendix A of draft-irtf-rfcs-0. is appropriate for this document:

"This document in not an IETF Internet Standard. It represents. the individual opinion(s) of one or more members of the TMRG. Research Group of the Internet Research Task Force. It may be. considered for standardization by the IETF or adoption as a. IRTF Research Group consensus document
in the future."
  
 Token: Lars Eggert

Lars - Waiting for Aaron to get back to us. Don't think we can alter the statements we can select from.

Russ - We've published IRTF documents with RFC 3932 statements before. IRTF wants different statement, but they have not requested publication of a BCP to get their statements approved by the community. Also, Aaron hasn't moved this document in several months.

Sam - we've used non-standard notes, but always added text, never changed the base text. Don't want to hold up document for this.

Russ - fastest way is to publish with a standard note.

Sam - can respect wanting to wait and publish with accurate note, have been a process stickler before.

Lars - should wait for Aaron.

Russ - I'm willing to sponsor the IRTF document that defines new notes.

Ross - can we change notes?

Sam - does RFC 3932 allow that? we can only add to the base text.

AD Follow-up...

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
    NONE
4.2.2 Proposed for Approval
  o IP Flow Information Export (ipfix) - 1 of 2
    Token: Dan Romascanu

Went for external review last time.

Russ - was text fixed?

Dan - if this is approved will send version to Amy that includes correction.

Approved with no further discussion.

  o Network Configuration (netconf) - 2 of 2
    Token: Dan Romascanu

Went for external review last time.

Lisa - this is an enormous amount of work (locking, etc). Sharon's suggestion to use SOAP is counter to standard. Maybe you can do that, but it's counter to standards.

Sam - why are they doing SOAP in the middle of XML?

Dan - notification was in previous charter, just completed WGLC.

Sam - may be getting pushback from me and Lisa.

Dan - will ask for a new chair.

Sam - layering RPC mechanisms without a good reason is not good.

Rechartering was approved on this call.

Russ - sent comments, don't see them. Will paste into jabber (just in case). Version on agenda right now does not have these corrections.

Dan - will send clean version.

5. IAB News We can use

Loa - T-MPLS design team has started to work, getting organized. Most issues under control, open issue is where SG13 is going, want to know they are going to follow the agreement with SG15. Also need to know what attendees we'll need for SG13 and SG15 meetings early next year.

Ross - trying to figure out actual dates (Dave and I are both reluctant to attend for two full weeks).

Loa - topics are spread out over entire meeting, trying to work with SG chairs to narrow this.

OMA liaison - still looking at how to continue relationship, Barry has token and is talking to ADs, will grab a few of you in Vancouver.

Decided topics for technical plenary ("protocol success" Thaler draft overview, IRTF invited speaker on energy with Elwyn presentation to summarize and tie to work in the IETF. Dward has been talking to Elwyn. If you have in-depth knowledge, please contact speaker in advance.

Cullen - can we see slides for those presentations? Have done that in previous IETFs.

Loa - not specifically planned, need to ask authors before I forward.

6. Management Issue

 6.1 Expert for RFC 3340 APEX Parameters [IANA #121073] (Michelle Cotton)

Not urgent, no current requests, moving documents to historic so registries will be going away. No expert needed.

 6.2 New IANA expert for AVP Codes (RFC 3588) (Dan Romascanu)

This leftover we forgot to make change during editor changes. Bert is still listed. Proposal is to change to Hannes.

Lars - Hannes is on TSV directorate and showing signs of overload.

Dan - probably one request a year. Can put my name in but would turn to DIME chairs anyway. Can put myself as primary and work with DIME working group, know other folks to work with.

Jari - shouldn't you be looking for somebody new as opposed to overloading YOURself?

Dan - could consider this, there are some people I could ask. But Bert is definitely not the right person to hold this any longer. Will list me for now.

 6.3 CARP protocol number allocation situation (Jari Arkko)

Jari - asking for advice. Came out of proto-update draft which changed the rules for protocol allocation. CARP and PFSYNC protocols running on 112 (same as VRRP) and 240 (currently unallocated). Two stories about what happened (which differ significantly) between BSD and IETF. Don't know what actually happened, but end result is protocols colliding and protocol squatting on unallocated port number. Talked to Bill Fenner, he said might be possible to allocate PFSYNC (with a document), but not sure anything could be done for CARP.

Cullen - why don't you send a request to IANA for both protocols?

Jari - can do that, but question is whether BSD people will use them.

Mark - can VRRP and CARP detect a collision?

Jari - expect you use one or the other.

Mark - but how bad is the collision?

Jari - I do not know.

Sam - CARP has no spec but the source code.

Cullen - goal was to beak VRRP, would be astonished if this didn't happen.

Sam - so this is about license whining?

Cullen - this is the one patent BSD hates.

Sam - but it's a non-assert license!

Jari - this is part of software patent argument. Not here to deal with political aspects, what works for the good of the Internet? Can contact and ask if they would use for CARP, if goal was to break VRRP that's counter to their goal.

Mark - offer to make protocols work together?

Russ - thought that Bill tried to do this and got nowhere.

Jari - concerned that I'll end up as part of propaganda. Do PFSYNC and then do CARP some months later.

Mark - protocol ID without a specification (except for source code).

Jari - allocate protocol number and document protocol (I would shepherd their document). Not sure I'm willing to allocate without documentation - what if they aren't willing to spend cycles on documentation? What is IESG advice?

No one opposed to giving code point, but no one confident it will be used.

Mark - hesitant, but you have specification in source code.

Cullen - why would we treat BSD differently than Microsoft?

Sam - we should give them the codepoint, too!

Russ - would be great to break collision, but don't think people who caused the collision are interested in fixing it.

Jari - could also be about finding the right person to make the document.

Sam - there's not one BSD community - wide range of participants.

Cullen - Try to find someone who can write this up - then you'd be done. Randy, Bill, someone who can help you find someone who will do the work.

Lars - should send note about why we are allocating without a specification (protecting implementations that followed the rules).

Jari - part of cleanup that's already in progress, won't do this again.

Lars - can we prove there was no request?

Michelle - haven't been able to find anything, but will keep looking, will ask Barton if he saw anything during his tenure.

Jari - hard to prove there was no request at this point.

Sam - why do we care? We'll work with them on interoperability regardless of what they've done, and if they don't care about interoperability, we can't work with them anyway.

Cullen will help Jari find suitable person...

 6.4 Review of Atom Link Relation request [IANA #123284] (Michelle Cotton)

Michelle - sent request to IESG, then Sam had additional question, requester has responded.  Need IESG approval.

Sam - strong preference - register only for Atom service documents.

<Sam audio breaking up here>

Sam - original request proposed use for any type of service document without saying what a service document was, they said they would register only for Atom service document, that's my preference.

Lisa - also followed up with Mark Nottingham

Russ - text in the agenda does not not limit it to Atom

No one objected to revised text...

Michelle - will forward final registration before we update the registry. Can Sam sign off?

Russ - sounds good.

Lisa will send ticket with text saying IESG has approved.

 6.5 Approval of IESG Policy on Autoresponse Messages Sent to IETF Mailing Lists (Chris Newman)

Chris sent text two weeks ago - no comments on text?

Sam - asked that you remove specific reference to PR Actions, not the hammer you would use, would just moderate good contributers with bad autoresponders.

Cullen - read this and can't figure out if my autoresponder is compliant or not...

Chris - can describe most common broken behaviors are, but that's a big rewrite.

Cullen - should be actionable. WG chairs don't know what's compliant and partcipants don't know what to change.

Chris - will be page-and-a-half if I do technical details. Refer to BCP/standards-track documents? but can take another pass.

Sam - thought your summary was actually pretty good.

Chris - take another cut and bring back on next telechat? will be a little longer but relatively clean. Two specific things in standards-track document that are most problematic, would be more concrete if I pointed them out.

On agenda for next telechat.

7. Agenda Working Group News

Jari Arkko

- two issues - SAVI BOF, Danny McPherson will chair but looking for another, Fred Baker has produced a few documents but we need more details.

- other BOF going well.

- big issues queued up, new co-chairs, v6ops/NAT-PT

Ron Bonica

- also hunting for OPSEC and NETCONF co-chairs.

Lisa Dusseault

- HTTPbis is working, will meet in Vancouver

Sam Hartman

- behind on AD reviews

- SAAG will have pre-BOF for key management. Will have people/presentations lined up, will know what our gaps are. Just making sure we have people in place to get a BOF, plan for successful BOF. Sandy is presenting on design team output, want others to briefly describe their solutions, need to see what requirements are actually written down, need to recruit BOF chairs.

Russ Housley

- Todd Glassey posting rights suspended in IPR for two weeks.

Chris Newman

- Lisa and Dan discussing YANG Netconf proposal, really interesting issue for APPS - what circumstances to make sense for narrowly-focused data modeling language. Expect detailed discussion of this in Vancouver.

- Dan - preparation call on Monday about this - Chris will do his best to participate.

- Chris - this is feasible - it's in a product we shipped. Need community consensus on when it's appropriate. Can you automatically convert modeling language to XSD or Relax-NG to use tools? What are benefits where existing languages have gaps.

- Lisa - need to discuss on APPS-AREA mailing list before the meeting

- Ron - we can make that happen.

Mark Townsley

- may see appeal in DNSEXT, hope chair and appellants can work this out but the timer is about to pop. Will take this offline.

OTHER DISCUSSION

Russ - RFC Editor doing things faster, now might be consistently below two months, have 2026 that says IESG decisions can be appealed for two months, so RFC can appear before a correct appeal arrives.

Sam - involve IAB in this, Leslie and Eric have had strong opinions in the past. Should decide as community whether we move to historic or rescend an RFC, but we'd have to do that for copyright infringement anyway.

Jari - problem is that we give something status no matter what happens after we publish something. Involve community, but we shouldn't hold everything up because appeals are rare.

Chris - pre-appeal from someone?

Cullen - we can do that.

Ron - problem is when someone is silent for 59 days out of 60 and then pops up...

Russ - problem is when document has been published.

Ron - either wait two months or figure out how to pull back/say "whoops".

Chris - if you can't put an appeal together faster than the RFC Editor can publish, we shouldn't take that as seriously.

Sam - discussion about Historic doesn't make sense for us to have.

Ross - say "you have one month to tell us you're appealing?"

Chris - requires change to 2026

Russ - have asked RFC Editor not to publish IESG-approved for 60 days, until we figure this out.

Cullen - don't delay all our documents two months, figure out how to recall a document, because our current position is actually a joke.

Jari - don't need to give RFC Editor any instructions now, initiate discussion with IAB. Uncomfortable about delaying all documents for rare cases.

Cullen - OK with waiting while we figure stuff out.

Chris - OK with that if we remove state if things start piling up.

Russ - when we've expedited, we just published.

Sam - have had heated discussion with IAB on ULTRA document

Russ - don't remember this. Our contract challenges RFC Editor to get down to 30 days processing.

Dan - can we ask for appeals in 30 days? after announcement? announce intention to appeal?

Russ - don't want to say "please appeal me" in announcement

Magnus - this isn't helping solve the real problem, need to have long run solution about how to "pull back".

Olaf - didn't think this is contentious but now think should discuss within IAB.

Russ - raised on internal list to see if there's an issue - there is!

Olaf - not a problem now, if RFC Editor gets below 60 days, we'll need to have a solution.

Jari - can RFC Editor tell us when this happens?

Russ - IAB gets that report now, by state.

Olaf - RFC Editor doesn't want to be measured including this state, because they don't control it at all.

Russ- need IAB/IESG discussion, will post to IAB and IESG lists.

Sam - this will need to go to the community at some point.

Russ - especially if it requires 2026 changes...