Narrative Minutes

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the October 4, 2007 IESG Teleconference

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

With corrections from Jari Arkko, Russ Housley. Magnus Westerlund

1. Administrivia

1.1 Roll Call
1.2 Bash the Agenda

Nothing bashed..

Ross - CCAMP charter revision submitted too late? Amy will check.

Sam - approved or external review? IAB gets a week to look at charter revisions, so submitted late doesn't give them the week. This is automatic, there's just a review period involved.

Ross - less than a week ago, hopefully we're in the middle of the week.

Sam - not a problem if we're sending to entire IETF for review, of course.

Loa - haven't seen this coming to IAB yet

Amy will check status on this

Ross - I sent in request on Monday, do I need to do anything else?

Amy - no

1.3 Approval of the Minutes

Minutes from September 20 telechat approved with no discussion.

Narrative minutes from September 6 telechat are approved with no discussion..

Narrative minutes from September 20 telechat approved with no discussion.

1.4 Review of Action Items

Cullen drafting statement on 00 versions of WG documents - Cullen has received comments and reflected them - management item on this agenda, so DONE.

2. Protocol Actions

2.1 WG Submissions
2.1.1 New Item
o draft-ietf-behave-multicast-10.txt
IP Multicast Requirements for a Network Address (and port) Translator (NAT) (BCP) - 1 of 5
Note: Magnus Westerlund is Proto Shepherd
Token: Magnus Westerlund

Couple of DISCUSSes.

Magnus - there is a requirment inconsistency with summary requirements, should be aligned.

Jari - fine.

Magnus - Mark, not sure about your first point

Mark - "way to handle multihoming into NAT can be by network design or by protocol design" - what happen if two boxes don't agree on the way they expect to do this? What's the default? Other magic stuff is fine, but what's interoperable? "MUST implement".

Magnus - understand, will check for response.

Mark - don't care which, just need one. Did you understand other comment? Link level multicast should never be forwarded, admin-scoped should be described, too. Bonjour through NATs could be nasty (this is an example) - going offlink in discovery protocols is a different mode. What you set the TTL to - huge reeling debates about setting TTLs high or low if you know routers don't forward link-local anyway.

Magnus - need to think about scope boundary anyway. No reason to mention, not passed through NATs

Mark - not obvious, need to describe this. Other than that, great document!

Revised ID needed.

o draft-ietf-mboned-routingarch-10.txt
Overview of the Internet Multicast Routing Architecture (BCP) - 2 of 5
Token: Ron Bonica

Lots of DISCUSSes (and more this morning than yesterday). Most can be dealt with quickly, will have revised ID. Will let RFC 1585 remain at Informational, this is appropriate for analysis and experience, not reasonable to obsolete/make HISTORIC.

Revised ID needed.

o draft-ietf-pce-disco-proto-isis-08.txt
IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery (Proposed Standard) - 3 of 5
Token: Ross Callon

No need to DISCUSS here, working on wording in e-mail. Dward thinks he'll be able to clear by Friday.

AD Followup.

o draft-ietf-dnsop-reflectors-are-evil-04.txt
Preventing Use of Recursive Nameservers in Reflector Attacks (BCP) - 4 of 5
Token: Ron Bonica

DISCUSSes are profound, need to go to WG mailing list

o draft-ietf-ipv6-deprecate-rh0-01.txt
Deprecation of Type 0 Routing Headers in IPv6 (Proposed Standard) - 5 of 5
Note: Document Shepherd is Bob Hinden <bob.hinden@nokia.com>
Token: Jari Arkko

Approved with no discussion.

2.1.2 Returning Item
o draft-ietf-ipfix-protocol-26.txt
Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information (Proposed Standard) - 1 of 1
Note: A previous version draft-ietf-ipfix-protocol-24.txt of this draft was. already approved by the IESG. The IPFIX WG decided to make
changes to that. version of the document with the principal goal of removing the SCTP. stream 0 restriction. Reviews should focus on the changes since draft-ietf-ipfix-protocol-24.txt which are mentioned in an editorial note. currently placed after the Table of Contents..
Token: Dan Romascanu

One DISCUSS, no Dan.

Russ - I feel a bit guilty about adding a DISCUSS position to a returning document, but I missed the telechat that addressed this document. Hopefully it can be addressed with a sentence or two.

AD Follow-up.

2.2 Individual Submissions
2.2.1 New Item
o draft-wilde-text-fragment-08.txt
URI Fragment Identifiers for the text/plain Media Type (Proposed Standard) - 1 of 1
Token: Chris Newman

Sam - would like to talk to Chris...

Chris - would like to DISCUSS - Tim's, the author agrees. Lisa, I'm agreeing with Tim, don't see how you could use fragment to do something nefarious.

Sam - issue is that this fragment is different from HTTP fragment - how to implement both? don't see how.

Chris - totally in agreement with that.

Lisa - ask if fragment identifier is intended for highlight/focus

Tim - not sure how serious a problem this could be, but seems to have different concerns than other fragment types. Just don't know enough about uses.

Chris - DATA URL with content, fragment to omit part of the data, but URL has so many covert channels now that I'm not worried about this now.

Sam - not sure how nit-picky I should be. Adding hashes? makes it harder to deploy new hashes if clients pop up dialogs whenever they see new hashes.

Chris - revised ID anyway, could you write this up as a COMMENT? I'll go NO-OBJ.

Cullen - didn't DISCUSS, but I'm not sure everyone understands how this works. HTML or text/plain - how do FTP clients know?

Chris - as far as I know, FTP clients look at extensions.

Cullen - no other RFC that mentions something like that. Another issue - community defining URIs don't understand that our document overrides all URIs - hash is legal fragment in TEL URI with no encoding. Misunderstanding is that 3666 applies at all. Unclear that this updates all schemes.

Chris - problem is URI is full standard, people reference but don't follow.

Cullen - don't reference whole document at all.

Sam - how are these things getting approved for registration?

Chris - URI list plus regular process

Sam - should both catch failure to conform

Cullen - thought I understood this but I was wrong.

Sam - surprised, too

Cullen - RAI people defining URIs got this wrong - didn't understand

Chris - should be more diligent in future.

Cullen - should probably fix at least a couple of these.

Magnus - interesting cases

Chris - rendering engine determines meaning of fragment

Magnus - think I understand but ...

Chris - will keep our eyes on this in the future - getting more eyes on this. Please enter as COMMENTs and I'll send to author.

Revised ID needed.

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions

3.1.1 New Item
NONE
3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD

3.2.1 New Item
o draft-edwards-urn-smpte-02.txt
A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE) (Informational) - 1 of 3
Token: Chris Newman

Chris - missed DISCUSS on this one.

Cullen - can explain and probably clear right now. 3406 says for formal URNs we review them - we have a process. We have upcoming URN requests that aren't even as good as this one - "please delegate to us and we'll go from there" - doesn't meet requirements but we've done this in the past. What's the IESG position? Not talking about MAC addresses, talking about URNs that can get subdelegated, etc.

Sam - make sure they have typing information, and basic stuff like that, then it's fine. If we expect subtypes, what are the tags to distinguish between subtypes?

Cullen - FCFS - would we approve that?

Sam - if I ask for string A, do I get A:? do I get AB? sure you didn't intend that, what's the intention here.

Cullen - we've done things like this in the past, but doesn't meet 3406 requirements

Sam - had some discussions like this with Leslie, as URN reviewer, she thought it was consistent

Lisa - also pinged Ted, thought we should approve subdelegation requests because we need an authoritative registry.

Sam - would be nice if document reflected that

Lisa - "only use for identifiers", but then usage changed - is that OK? people could change mind about namespace structure

Sam - need to either update or obsoliete IETF documents

Cullen - if plan is to approve anything, we are putting people through torturous process, that's why people ask for one URN and then go crazy. Not good or bad, it's just what we're doing.

Lisa - Michael spearheaded URNs, thought they would have meaning. MAC addresses, cell phone identifiers, etc. assigned under purpose. Thinks delegation by purpose is a losing battle.

Chris - insist that organizations make statements about stability of identifiers. They have own registry, with sufficient infrastructure. Discussed this during review, held this up until organization made commentment. We're following enough of 3406, not big on powerplay, big on benefits to community. That's value of review process - getting commitments about stability. Should update 3406 to reflect what we do, but we do need to be delegating to organizations that have made this commitment.

Cullen - will ABSTAIN and move forward

Chris - understand what you're saying

Cullen - clear we should update 3406, if it's what last couple of ADs have done

Russ - who has action for this?

Chris will take action to idenify someone to do update to 3406.

Document is approved.

o draft-tschofenig-eap-ikev2-15.txt
EAP-IKEv2 Method (Experimental) - 2 of 3
Note: There is no Document Shepherd..
Note: LC expires Oct 9, I will take this to the IESG 5 days before that
Token: Jari Arkko

Jari - need to DISCUSS - technical think no one has DISCUSS about how IANA registry is solved (in RFC Editor note right now) - separate registry, numbers end up being different.

Sam - separate registries is by far right solution

Tim - works for me, too.

Jari - on afenda before last call ended? Will look at comments if they happen, but being optimistic, don't expect comments. Does IESG think I shouldn't be doing this? Part of delay in the process.

Sam - discussed with very different IESG (Harald or Brian) - people thought this was OK at that time, newer people have been less comfortable. Not harmful as long as document shepherd thinks document comes back on substantial comments

Cullen - but we get no comments on 90 percent of the documents, shouldn't be the norm. We NEED comments.

Magnus - fine, just call this out clearly if you're shaving a couple of days, don't want people to miss that we're doing this when we hallot.

Jari - don't expect to do this often - Independent submissions with one-month last calls, fair amount of discussion already happened. But I did guess wrong on other document. Focused too much on getting stuff out?

Michelle - could you hold IANA DISCUSS so we have more time to look at this? Need to re-review IANA concerns in RFC Editor note.

Jari - now holding DISCUSS - any other thoughts about this process?

Russ - don't see a problem, why did you ask?

Jari - people raised concerns

Russ - previous IESG said this is OK, but people can DEFER if they need to

Sam - very different than what I thought. We agreed to write down a policy about this, but I never did.

Ross - awkward, approving without finishing process

Russ - shepherd holds DISCUSS, just in case

Magnus - prefer that last call has concluded

Mark - every time this happens someone complains. Why don't we agree not to do this (except in exceptional cases) until we write a policy down. I know IAB is working on a response, so will hold DISCUSS until that happens.

Jari - what's the plan here?

Sam - hearing this IESG is less comfortable than previous IESG.

Mark - one document I see specific problem with, but that's because I have background information. Not saying this is always bad, either ban this or write down exceptions.

Sam - agree with "extenuating circumstances unless we write something down", but I won't write it.

Jari has the action to write up instructions on when an AD can bring documents early to the telechat, and what the process is under those circumstances.

IESG review with AD followup? Last call until it ends, plus IANA comments.

o draft-aboba-sg-experiment-02.txt
Experiment in Study Group Formation within the Internet Engineering Task Force (IETF) (Experimental) - 3 of 3
Note: No document shepherd.. Note: LC Expires Oct 8, will take this to IESG four days before that
Token: Jari Arkko

Lots of DISCUSSes - similar to previous document?

Sam - allow me to review and move to a YES?

Jari - can DISCUSS until secretariat comments

Barbara - meeting tomorrow to go through WG steps to see how SG maps. "Exactly the same" - charter for the study group? Internal and external review? On telechat at each point?

Jari - yes. Bernard wrote additional text that makes this clear (in RFC Editor note)

Sam - don't need a separate agenda section.

Barbara - hoping you would say that, don't want to make lots of tool changes to accommodate an experiment. Will look for any differences (may be category in a database, may have SG in name... but no hyphens)

Jari - DWard DISCUSS - could you review Bernard's text in RFC Editor notes?

DWard - why extra overhead? Why is this necessary? Haven't needed them for a very long time.

Jari - lots of work happens before you have a working group (convincing IESG, etc) - hard to manage, unclear to outsiders. Sometimes we know we want to work on something but aren't ready to charter yet (still looking for collisions, etc). Would be temporary (12 months - now 18)

DWard - non-WG-forming BOFs, solving with too much overhead

Jari - also about ability to show people outside IESG that we are going ahead, but some work remains before a WG is approved. Keep people involved interested.

DWard - but SG group isn't a guarantee that we'll do this work at all.

Jari - no guarantee, document says we need clear indication from community that we want to do this. Unclear period doesn't work well with 1-2 BOF limit.

Sam - SG is post-first BOF?

Jari - yes, but not explicitly required.

Sam - against: strongly suspect that if you ask proponents, they would say examples that you might not agree with. for: asked DWard to look at 3933, has criteria from the community that isn't as strict as we're applying in this case.

Chris - might want to run DIX through this. Have BOF, have interest, don't have enough clarity to nail down a charter.

Mark - possible side effects? Concerned that people will camp out in SG and delay move to WG until they are even more disappointed when community decides not to do this work. Don't want idea that all WGs are SGs first. Look at BOFs - no BOFs, then one BOF, then two BOFs ...

Jari - hear you, but document is explicit about what we work on - preparing for WG.

Mark - but we tell people "work on your requirements", even proposed solutions, when we charter a WG.

Lisa - agree, expect people are invested and entitled if they put a year into a SG.

Jari - lots of examples of IETF losing opportunties, and usually because of problems in early phases.

Cullen - why did Russ ABSTAIN?

Russ - same reasons Mark listed. IFARE wouldn't have worked any better as a SG.

Ross - agree with Mark, but is experiment, ADs still control.

Jon - concern about this as an experiment is that we may not test the cases we're worried about. Concerned that RAI waiting list for WGs will camp out as SGs.

Ron - haven't entered a position, because agree with Lisa but when people bring a new idea to IETF, that's when the idea is in most flux. Would like SGs to make decisions early in the process.

DWard - make SG for BGP improvements? This isn't what SGs are for, but trying to do something official. Would RRG/Routing-Addressing split be an SG? Would SAVA?

Jari - does not remove need to push back on bad ideas. Not meant for everyone, for special cases.

DWard - why can't I form a SG in my case?

Jari - nothing prevents you from doing this. If community's opinion has been taken into consideration, that's what matters.

Russ - DWard, why not a directorate?

DWard - could be subdirectorate.

Sam - Why is DWard's comment blocking? Why not just Last Call comment?

DWard - maybe I could move to COMMENT

Ross - point of experiment is to answer questions?

DWard - how do you know experiment is over?

Ross - or succeeded or failed

DWard - allowing people to put SGs on IETF agendas, etc. ?

Cullen - not looking forward to this, because every BOF I turn down will request a SG. Limit number of SGs during experiment?

Jari - could be done

Ross - wildly popular with IETF, but wildly unpopular with IESG?

Russ - SAVA

Jari - trust me to keep them under control. They are under the current line for SG.

Sam - if there's not interest in doing the work, they don't meet SG critieria

Russ - During this discussion, SAVA keeps rattling around in the back of my mind. That is why I answered Ross' question that way.

Jari - are people changing positions? DWard, can you check whether we are overstepping what RFC 3393 requires for experiments?

Mark - experiments controlled so they don't cause harrm? Constant education process unless there's a limit on the number of SGs.

Cullen - 3-5 SGs across all areas.

Ron - could go NO-OBJ if there's a number

DWard - experiment in Int-Area frst?

Sam - would object.

Chris - 3 is reasonable, lower isn't

Sam - limiting to one area is a bad idea.

DWard - can live with three, will clear DISCUSS

Jari - will return to next telechat to check on IAB statement

Mark - they are coming up a statement, don't know what it will say

Will remain in Last Call until Monday, AD followup after that. On agenda next time? Will wait until we hear from IAB.

3.2.2 Returning Item
NONE
3.3 Independent Submissions Via RFC Editor

3.3.1 New Item
NONE
3.3.2 Returning Item
NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o HyperText Transport Protocol Bis (httpbis) - 1 of 1
Token: Lisa Dusseault

Cullen - think this reads like you're writing HTTP compliance documents, but you're not - don't change this

Sam - don't send this out unless you want to do the work, or you'll just get more mail

Lisa - separate security document because we're concerned about IESG approving any HTTP document - considerations is 30 pages to document all strange corner cases

Sam - why do we care about one document or two

Lisa - Mark wrote charter that way to involve more authors. Not sure a person who can write security document exists... Plan to do a call for chairs to get other names, too.

Sam - thought BOF conclusion was that security is important

Lisa - yes, just not sure we can do this. Community has looked at objections.

Sam - EKR concerned that APPs area isn't right place to do authentication

Magnus - my concern?

Lisa - would require rechartering. Possible change to say we're not talking about compliance, not adding new features without rechartering - but that's a fine line. Small features may be necessary.

Magnus - need to be able to say "you've gone beyond your charter" - hard to do that with current text.

Lisa - risk for this group of people is not to go crazy, it's that they will be extraordinarily tentative - can't make any change because it would make 10-year-old servers non-compliant

Sam - as long as we want to go in that direction, we can make today's servers non-comliant...

Lisa - do I need to revise charter and come back to IESG, or go to IETF review with revised charter?

Russ - any objections?

Cullen - not sure if you're making proposed changes or discussing them with people.

Lisa - can say "we're not going to work on compliance"

Cullen - or delete two sentences - I don't know, send it out. "Group will review tests for compliance" - would like to see this come back to IESG.

Will be on next telechat agenda? No, approve pending edits and send it out - will be on next agenda for approval?

Magnus - sure we have time for this?

Russ - depends on how fast they move

Lisa - will approve as BOF, can switch if they are approved before Vancouver

Sam - need to make sure IETF has time to review before telechat where we approve revised charter.

Edits will come from Lisa (needed by Tuesday - then there's no problem, per Amy)

4.1.2 Proposed for Approval
NONE

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review
o Dynamic Host Configuration (dhc) - 1 of 2
Token: Jari Arkko

Changes - DHC given space to own and do anything they want to do, this charter is narrowing that (allowing recharters, of course). Also removing completed items and lost-interest items. Have been chartered to work on security for years, no work done, has been dropped. Authentication for DSL Forum, etc would be a recharter.

DWard - some working group items aren't part of this charter (Authentication, etc). DSL Forum is looking at DHC for failure detection. Is this allowed?

Sam - charter says "charter items added with AD approval" - consequence is that DHC options done in other working groups and reviewed in DHC.

Jari - that's current practice. Also allowing addition of milestones for items that are listed in the charter without rechartering.

DWard - DSL Forum items aren't part of the current charter - why do it this way?

Jari - want to send this out now, DSL Forum discussion may be lengthy, don't want to hold up other parts of the charter. Has been discussed wiithn Internet Area. Don't want to bundle everything.

Mark - hope that we don't have 120 WGs rechartering every three months. Think of charters as something we touch every couple of years, otherwise it's unscalable.

Jari - lots of flexibility between "you own this space" and tight control.

Mark - just a little worried. Know work is coming up in a few months, agree with DWard.

Jari - but we don't know for sure we can do this work in DHC at all. What I'm doing makes more sense.

DWard - Jari is reasonable, this is a special case, not going to block work DSL Forum needs to do.

Mark - as long as this is Modus Operation for all working groups.

o Network File System Version 4 (nfsv4) - 2 of 2
Token: Lars Eggert

Magnus - charter hasn't been touched in five years, this is what working group is doing today.

Lars isn't here, Magnus isn't sure what details are.

Sam - uncomforable approving this without DIFFs today

Magnus - this is going for IETF review, not for approval today.

Sam - won't block going for approval.

Chris - "Maintenance of XDR", but isn't this a full standard?

Russ - any reason to block community comments here? No.

Will go to external review with no edits next week.

4.2.2 Proposed for Approval
NONE

5. IAB News We can use

IAB meeting yesterday - thining about ICAN candidate. Would be good to have timelines and procedures on this.

Also discussed agreement with ITU-T, sitll in liaison relationship. Forming a design team to figure out what needs to happen?

Other liaison discussions - need guidelines when managers talk to the press, need to look at procedures for terminating liaison.

IAB IP Confid/Host configuration document has been around for a while, ready to become an IAB document.

6. Management Issue

6.1 IESG Statement about Appeals (Russ Housley)

Some concern about recent appeal text raised by Ted Hardie. "Every action IS open for appeal".

- Sam - no problem, but don't think this needs to be posted on statements page.

- Ross - not sure what's happening here.

- Sam - we're talking about "wrongful termination" - reasonable to raise issues "done for political advantages" Mail to IETF/IETF announce?

- Cullen - don't care

Chair will send message about this.

6.2 Expert for RFC-to-be: draft-ietf-ipfix-info-15.txt [IANA #106002] (Michelle Cotton)

Michelle - approved to publish as RFC, hasn't happened yet, need expert for.

Action to find someone? Ron will do this.

6.3 ion-2026-practice.html (Russ Housley)

Russ - some discussion of this, Brian has responsed. Ready to approve?

Sam - Brian said he would fix this, one sentence, can approve and trust Brian.

Jari - I also had some suggested edits, not just one sentence. Would like to see document come back for approval.

Will come back in two weeks.

6.4 Autoresponse Policy (Russ Housley)

Russ - who had the pen on dealing with vacation messages, etc? Had discussions. Volunteer? Chris was dragooned. Discussion is on IESG list, about messages on IETF list.

6.5 Early IANA allocation issue (Mark Townsley)

Early allocation - IETF consensus doesn't fit this document,. Need to approve so people can do IETF consensus, too.

Tell IANA we are cool with propopsal? Yes.

7. Agenda Working Group News

Cullen Jennings - Geopriv underway revising milestones

David Ward IS-IS making progress on revising as standards-track - prepare yourself

Magnus Westerlund - ROHC WG has a new chair that will take care of the last items on their charter before the WG is closed."