IESG Narrative Minutes

Narrative Minutes

INTERNET ENGINEERING STEERING GROUP (IESG)
<NARRATIVE> Minutes of the April 19, 2007 IESG Teleconference

Reported by: Marc Blanchet, with diffs from RH, LD, MW.

RH: Marc, the new scribe, are you on the call?

MB: Yes

RH: I think this is your first one you are the lead scribe on.

MB: Yes

RH: Thank you and congratulations and condoleances. Let us know if you run into trouble with voices. Everybody, let's help Marc out. Say who you are the first few times you speak.

MB: Thanks

AV: The conference call is recording. Let's find out who is here.

AV: roll call. I have received regrets from: Ron, Ross, Spencer and Barbara Fuller.

AV: Loa? Y Jari? Y, Marc? Y Yoshiko? Y, Michelle? Y, Lisa? Y, Lars? Y, Marshall? N, Sandy? Y, Sam? Y, Russ? Y, Cullen? Y,

AV: Olaf? Y, Chris? N, Jon? Y, Tim? Y, Dan? N, Mark? Y, Dave? N. Magnus? Y

AV: Dave not here. Hopefully people will join.

ME: Marshall here

CN: Chris here

RH: Dave says he is in jabber, but can't hear him.

AV: we don't hear Dave. hopefully will be worked out.

AV: Bashing agenda. Anything new?

RH: want to change order of something

AV: I know. I couldn't get the executive session at the end. Will skip it to the end. anything else?

RH: no.

JA: I want to add a management item: Proxy-MIPv4.

RH: Jari in the echo chamber

JA: yes, in the submarine.

AV: one new management issue. ok.

AV: any other changes?

AV: any objection on minutes of April 5th being approved?

AV: minutes approved

AV: are there any narrative minutes?

AV: take that as a note.

AV: review of action items:

AV: Cullen to address the IANA open issue of well known protocol name.

CJ: in progress not just in waiting.

AV: still in progress

AV: Mark to identify the appropriate expert for RFC 3292

MT: don't have it yet.

AV: next two for Ross. Ross is not today. tempted to mark as done, pending management issue.

RH: let's do that at the time we agree.

AV: yes

AV: Sam to identify the appropriate expert for RFC 4430

SH: I named two candidates on the last IESG call. They accepted. If no one does not remember, I can write the names in jabber. Mark as done.

AV: done.

AV: next one is with Ron and is not with us, so marking as in progress.

AV: next one is for Magnus: Magnus to identify the appropriate expert for RFC 3936. However , I do have that as management issue from Russ.

RH: yes. bit of confusion. will take that up during management issue discussion.

AV: Jari to identify person to resolve IANA ether-type question.

JA: Dan and Bernard Adoba and I already informed IANA. closed.

AV: will be marked as done.

AV: review of projects. Jon any?

JP: no.

AV: discussion on documents:

AV: WG Submissions New Item:

AV: draft-ietf-simple-presence-rules-09.txt to Proposed Standard.

Token: Jon. Have 2 open positions here.

AV: Chris?

CN: no

AV: Dave Ward, state your position?

DW: no.

AV: Jon, we have 2 discusses for today?

JP: I guess there is one that should be discussed today. The whole issue of if it is an appropriate downrefs. This is a tough one for me, since we have two of the authors of 3325 informational downref on this call. The degree of this being implemented by the community is so huge. At this point, I really don't think we can really hold out, considered that this document like this can simply be referenced.

SH: I completly understand that you need to specify a rule for how this mechanism interacts with 2325. I have no problem with that. I think it is a bad down reference. The reason is that there should be an abstraction there that is not invented yet. Basically, because it is not a standard track document, there is no reason to believe that this will be the only solution people will use. We can't say that we are endorsing that solution because it will be pushing something on the standard track. So you need to have a way, basically, that that could be one mechanism people use, rather than an explicit mechanism going to right normative rules like this.

JP: I think I understood your position and the abstraction you are looking for. Really having trouble to see how a downref puts it to standard track. High-level question, maybe not appropriate for this call. I don't have a good feel for the degree we are violating the downref rule

RH: I think there is an issue of a downref to an informational can be handled in two ways. For example, a downref to MD5, we really mean do exactly MD5, nothing else and we don't want to elevate this downref to standard track. Here, we mean something different and we don't have a mechanism to distinguising these kinds of downrefs. Do you agree Jon?

JP: I agree with you. We are expressing something which is already used in the wild. If we did not describe it in this document, we will be at risk that making the document useless for an actual implementation. There is a confusion about the issue on how to handle downrefs. I'm concerned of having a discuss on that aspect of it, makes it difficult to resolve. I can bring back the abstraction suggestion to the authors.

SH: Note that if there was no downref issue, I would effectively have the same discuss. We have at least three instances of authentication mechanisms for SIP. And frankly, not all were envisioned when 3261 happened. That says there might be more in the future, which means you need that abstraction anyway.

CJ: When this document was started, 3325 was the only practical solution available to implementors to solve this. Identity is the only other one that they can use very well in a lot of situations. That work recently got done.

SH: I will also argue that I might want to specify rules if I have a SMIME signed thing as well. You don't do that in this document, which is fine because you can argue there is no implementation so no need to spend the effort. But if you don't have the abstraction, I can't comment and do that later.

JP: that is fine. I'll bring to the author and I think we can solve this.

RH: Is this revised-id or AD followup

JP: revised-id. I'll bring it to the author.

AV: go to revised-id needed.

AV: next item: draft-ietf-ips-isns-mib-11.txt to Proposed Standard.

Token: Lars Eggert

AV: Lisa, do you want to state your position?

LD: No. If I have an open position, it can stay that way.

AV: Cullen, do you want to state your position?

CJ: No. same as Lisa.

AV: no discuss held. It is enough to pass for approval.

LE: Question for Tim, since he posted a security AD review. Do you think anything there requires an RFC-editor note?

TP: I didn't seen anything blocking. Worth passing by the authors to improve the document. Wasn't willing to block anything.

TP: Editors discretion.

SH: I would strongly recommend against making any changes you suggested to the security section.

TP: I will defer to Sam and go it as it is.

SH: We have a well understood template and we don't want to reopen that document.

LE: approved.

AV: approved and no notes. plain approved announcement.

AV: next new item: draft-ietf-rmt-fec-bb-revised-07.txt to Proposed

Standard. Token: Magnus Westerlund

AV: Only one discuss held. Magnus, do we want to discuss today?

MW: no. fine.

RH: I think we can fix it with a RFC-editor note by the end of the call.

MW: Yes.

RH: approved forward. I'll clear right now

??: other wording changes in my comment.

MW: there are in. there is a new -07, which addresses your comments.

RH: just cleared.

AV: Magnus, there is an RFC editor note in tracker. Is this for -06 or -07?

MW: It is for -07. referencing 2104 in references section, talking about strong hash, should I use another reference?

RH: I'll send it to you.

MW: approved. status

AV: we will look for confirmation by the end of this call or with a ticket from Magnus.

YC: IANA has a question. Action is ok. We are not sure what is the name of the registry

MW: Fixed in -07.

AV: next item: draft-ietf-16ng-ipv6-over-ipv6cs-09.txt to Proposed

Standard. Token: Jari Arkko

AV: four discuss held. Jari, one is yours. discuss today?

JA: yes. some of them we do. some will be part of a revision coming. author could not do that for today. pending an IEEE review comment. If we can handle Russ discuss by a new revision, likewise for Sam. Lars, we can handle the second part of your discuss with a revised document, but the first part needs some discuss here. the question is who changes the timers, the recommended values, the maximum values for particular neighbor discovery.

SH: informational question about neighbor discovery? my understanding is that this particular link-layer is allowed to override the timer values. right?

JA: that is my understanding, although I'm not sure I can actually point to some RFC that says that. It is a general point that Lars raised that if there is a MUST in neighbor discovery specification, we can not for a particular instance overwrite that MUST, without the initial document saying that other documents can change this.

LA: you can say that this new document is an update of that earlier document and put in the new document the piece of text that modifies it. I would not be the most obvious way but.

SH: Since that document has not been out yet, I would rather deal with in the neighbor discovery bis.

JA: different cases. we have a discussion in the ipv6 wg about this. The conclusion was that these changes would rather be done in the link-specific layer documents rather than changing the standard values.

SH: Lars and I are saying is that the neighbor discovery document should have said this could be overwritten.

JA: it could be useful but we already approved that document.

LA: the neighbor discovery at the time we approved it, I was not aware that the wg came into concensus that some of those values that were required to be within certain ranges that will be later overwritten. We don't have on the standards track a mechanism called override. We have only what we have. If the neighbor discovery document says this is the recommended range but if you have a link layer , you can pick other timer values. Maybe it is in the wg, but not in the document.

JA: let me point out that this is purely a process discussion. there is no technical impact. On a layer foo, you have to implement ipv6 over foo, and the document says these are the values, and there are no interoperability issue whatsoever. I'm not sure why you really need to worry about this.

SH: I would argue that it is critical for our standards to be self-consistent and that, it is a bug if two standards conflict and the later one does not update the other. We should not, knowing we approve a standard that meet that criteria.

JA: it is not clear that they are talking about the same thing. Obviously they are changing the same timer value, but one document is a generic document and the one we are talking about right now is one specifying the timer value for link-layer foo. It is not a generic change.

LA: The generic solution does not allow to override the values. The standards process does not allow either without having some text. I agree with you this is not a technical issue at all. It is purely . I don't want to have a new TCP next generation proposal that happen to override the red calculation in 793 and claim to be compliant with the TCP spec. Here, claim to be compliant with the neighbor discovery except that we change this specific timer. The neighbor discovery section not recommendation, but requirement. There is a loophole there.

JA: I understand what you both say, but I'm arguing if this is real-world issue. Let's find a constructive way forward. Would you be ok if we make a change that says in AUTH48 that you can override this in the foo documents and we ask the wg if they are ok. Would that work for you?

LA: that would work for me. That would be my preferred way forward. The other way forward is that this document update the neighbor discovery spec with a note saying this section overrides this piece of neighbor discovery specification and overrides later to happen.

RH: I greatly prefer either the AUTH48 approach or a separate document providing the update, instead of people finding which document does different on foo.

LA: if you can stick it in the AUTH48, that would be the best.

JA: if no one here has an objection on the AUTH48 change with the wg consent, then that is the way forward.

RH: I like Jari to provide word for the minutes. I think we need to document this since we are authorizing a change to an approved document.

JA: my jabber offline. will do.

RH: if jabber comes back, fine. if not, mail to Amy.

JA: yes. revised-id needed.

LA: there is a list of timer values in the neighbor discovery that the wg agreed that it could be overwritten. this has been discussed, yes?

JA: yes

LA: they should check that the list make sense. They should not open all the parameters.

JA: right.

AV: this document is going to revised-id needed as a sub-state and I also need an email or jabber note from Jari to document the discussion.

AV: next item: draft-ietf-behave-tcp-06.txt to BCP. Token: Magnus Westerlund

AV: no open position, 2 discuss. do we need to discuss today?

MW: yes.

CJ: Mine is very simple and will be cleared in two minutes one way or the other.

MW: will check.

CJ: the best way to resolve with everybody on the call. The threat does not explicitly with a normative language way would require this, that it would be a good idea to have NATs to do TCP keepalives by effectively NAT becomes a man in the middle and if the endpoint are not doing keepalive, then the NAT wants to detect is some place is alive, then NAT does keepalive to both ends. This would require to man in the middle the sequence numbers in the TCP stream. This will work with TCP with most hosts today. The question to security and transport AD or anyone is: are there things coming down into the pipeline that are going to break somebody in the middle man-in-the- middle the sequence numbers.

SH: yes. It would break TCP-MD5 today. wouldn't it?

CJ: I suspect it would.

SH: It would break any future TCP.

LE: yes I think so.

MW: you can't use TCP-MD5 with NATs on the path anyway.

SH: does it check on the ports? oh yes, it does. Ok, it does not clear to me that it would break anything that NAT does not break already.

MW: Lars, any input?

LE: I think we are safe on that one.

CJ: implement that any way.

MW: revised-id needed.

LE: quick question on Magnus comment, because it is based on what I thought was a discussion on UDP and ??? draft with a concensus. I might be wrong. Cullen was following that discussion as well, but Magnus was. Have you looked at what I put in the discuss? Do you think this would make sense.

CJ: yes. My recollection that past discovery should work for hosts inside the NAT.

MW: yes.

LE: requires that would send the ??

CJ: that was what the earlier versions of the draft said.

LE: leave it there and minutes for wg to discuss.

CJ: I support that discuss. I agree.

MW: revised-id needed.

AV: revised-id needed.

AV: returning item: draft-ietf-pkix-lightweight-ocsp-profile-09.txt, Proposed Standard, Token: Russ Housley

AV: one discuss remaining. Russ, do we discuss today?

RH: no. revised-id needed.

AV: revised-id needed.

AV: Individual Submissions, New Item, draft-siemborski-imap-sasl-initial-response-06.txt, Proposed Standard, Token: Chris Newman

AV: one discuss. Chris, do we discuss today?

CN: yes.

TP: the first half of my discuss is non-blocking and the editors have already said that they don't want to do the reformatting however, they would do that if asked earlier. I can buy that is not worth struggling. But, the second half, it is not entirely clear to me that clients are able to differentiate between all of the error conditions. There were some reference to the capability command that has been the reason they should never get a NO when the wrong mechanism was specified. this is out of the scope of the document we are reviewing and I'm not familiar with 3501. Is it your opinion that position simply not going to occur?

CN: it is my opinion that this document does not change the ability to distinguish errors response on authentication. I also happen to think that RFC 3501 is not good enough and it needs an extension like the POP extension 3206 to distinguish between authentication error type is and where you have different UI behavior you want in the client. That something that should be done. This document is so simple that it does not change the status quo as far as I'm concerned.

TP: to recap, you are saying that this does not create any new problems for clients and the solution to the problem needs to be not this command but for the work that would provide better feedback in general. Is that correct?

CN: yes. IMAP has acceptable error codes so it would be quite simple to do that but it is further work.

TP: I'm going to clear the discuss then.

CJ: what are the implications of not being able to differentiate by error codes? what happens?

CN: I point you to RFC3206, which is the issues for POP3. I would rather not go into a lot of details right now. If you have a bad password, you want to prompt the user with another password, but if you have some failure that is just a failure, then prompting the user for another password is not something that should do. I have key situations where prompted service calls by not distinguishing error codes sent to clients. It is a substantive issue but it is a problem with the base spec not with this extension.

TP: given that, I will clear, but I hate to see clients retrying when they don't know what is wrong.

AV: Chris, with Tim clear, I have now approved. Correct?

CN: Correct.

AV: notes there are correct for that version

CN: yes. correct.

AV: have RFC-editor note and IANA note, and those notes are good.

CN: yes.

AV: announce on monday.

AV: Document Actions, WG Submissions, New Item

AV: draft-ietf-16ng-ipv6-link-model-analysis-03.txt, Informational. Token: Jari Arkko

AV: Jari, 2 discuss. Discuss today?

JA: yes. one from Ross and suggested RFC-editor note with more or less his text edited. He is not here today and I expect he will clear when he is back.

JA: what we should discuss is David Ward's discuss. He mentioned sensor networks work or rsn bof. It is not clear to me how this is related to that. Maybe you can expand a little bit.

DW: the sensor network sutff is going to be looking at the same particular problem, at the routing impact over these types of networks. My point is if the routing stuff is going to be done in a new group, that is fine, maybe we can go with some very vague language that has been suggested by routing, or it is done here, I'm little bit worried about just ponting with extreme vague language that has been suggested.

JA: first of all, sensor networks and wireless aren't the same thing. This is very traditional wireless link type and what you will have in sensor networks is far more adhoc and far more demanding from a point of view of routing I think. It is clear me that this wg is not chartered for developing any routing work. So you can bring up the same issue with any link type if you have routing issues. Don't see the connection really.

DW: The point that Ross and I are trying to make is that in any kind of link model analysis, when you say, when there are text that there is a significant impact on routing and that is ponted, what the solution going to be or Where is this going to be discussed or how. Basically asking for the plan. If it is brought by such strong terms, then if it has an impact on internet routing, and in fact it could, if routing is done over these types of links, then where do we want to do it, how do we want to do it.

JA: I think it should happen outside the 16ng wg and probably in your area.

SH: what is it of concern here? What is special about this?

JA: dave?

DW: What is special of these types of links?

SH: I don't see the impact on internet routing. What is it?

DW: basically, the impact on internet routing over these types of wireless links is there are different types of links. They go up and down more rapidly, there are potentially dealing with mobility of these particular addressed endpoints. So given that these types of links have specific properties than other types of links right. If the authors are saying that there is a significant impact on Internet routing, and in fact due to the rapid changes of these different types, there could be impact, the document as it says punted outside the scope of this document. Then the question is where this work going to be done.

JA: David, this is not the first wireless link type that has surfaced in the world. Number 20.

DW: I agree. it is the generic language in the other document that says we are going to look at the impact on internet routing and punt.

JA: I think the significant impact depends on how you deploy this. If you deploy this as a DSL replacement kind of thing on the edges, it is really not a big deal. If you deploy this in a very dynamic environment where we do actually run routing, then when one moves in a sensor type situation, then that is why we are having this discussion at the bof at the next IETF. I think it is your problem solved.

DW: toward that end, trying to resolve this. the suggested text it basically try to allude to the DSl replacement and effectively trying to do. It is relatively straight forward as a DSL replacement as point to point links and that is ok.

JA: right.

DW: do you feel we should add a sentence that if the deployment is different and that routing protocols are running over these types of links, then other issues can be encountered and again they are outside the scope of this document and this will be taken elsewhere.

JA: I would happy to add a sentence like that. Please send by email or jabber.

DW: will do. rewording the paragraph.

JA: AD followup. RFC-editor note. David and Ross to provide text.

AV: AD followup.

AV: draft-ietf-trill-routing-reqs-02.txt, Informational. Token: Mark Townsley

AV: quite number of discuss. Mark, do we discuss today?

MT: I will go ahead and say that this is the first trill document come to the IESG and It was probably one of the reason why there are so many discuss on this document. Should be better judgement to bring it to IESG before say the trill architecture document. I apologize for that. I think I responded to most of the discusses. The one I did not see done is the shepherd for the document and wg chair. I did not see discuss on the thread coming to conclusion was Ron Bonica, but he is not on the call.

SH: you already have text in the RFC-editor note that says the one Jari proposed. It is not in yet?

MT: no, because this will go revised-id needed because embedded in these threads, there is a lot of compromises for texts and rather go ahead and get another doc out of it. I think there are 4-5 discuss, but except for Ron, there is agreed upon text or agreed upon direction to create text so I think we are ok, unless someone wants to discuss something in particular.

DR: Observation that might clear our interaction. Part of the confusion is that the scope of this document is more narrow than the title says and more narrow than the charter says. So there is a kind of point of order here: you have a different expectation when starting reading the charter than what you get when you go deep into the document.

MT: I and All of you paying the price of me bringing what is really a narrowly scoped document to the IESG before bringing the architecture document, which have come here first. And I apologize for that. You and I discussed it and we will get a better title and abstract.

DW: Also another meta comment is that section 3, which is link-state protocol requirements, those don't match with the functionality work on in the IS-IS working group and I have got a little bit of an issue and I'm asking Mark how are you going to resolve it if the requirements don't match the functionality being speced.

MT: Normally, I would say the requirements come before the functionality. But in this particular case, it is reversed. But if there is a disconnect, that certainly needs to be resolved. We need to find out if IS-IS did it wrong or the requirements are wrong, and fix the case.

DW: IS-IS clearly did not do it wrong.

MT: stop it.

DW: the folks at IS-IS are headed down the path, working with the trill folks, to make it right. So the right thing is happening with respect to protocol. But the functionality is not mapping into the requirements here, which makes this requirements document useless.

MT: this is one of the reason why I was ... that this document done early was that the real work, the protocol spec, was running ahead, faster. To be honest, the original reason for this document was a particular opinion that IS-IS should be the chosen protocol and it was mandated to create a requirements document. It seems that without that document, the community has chosen IS-IS. You are right that the original purpose is over taken by events. The options are to decide it is useless and modify the charter that it is not a deliverable from the trill working group or go ahead and get it right if we think there is anything useful here.

DW: to that end, I agree there is one section is key in this document and all the rest is moderately or out of target or not interesting. It is the first paragraph of section 3 which said IS-IS is more appropriate choice than OSPF and that was the choice of the working group. If that is the key thing they want to get accross, maybe they could take that out and put it in the architecture document with some context around it and be done with it. The requirements as stated, we could not do anything with it in IS-IS.

MT: That would be perfectly fine for me. What I really want is protocol specification and my personal views is that requirements document are tools to get there. Perfectly fine with me, but we need to cycle back to the wg, lot of work here, people's names on it, people spent time and effort to it. We might be at a point where each of these requirements need to be hashed out. I love to be able to say the wg has it perfectly correct with trill but I can't just say it is true without cycling back to the wg. The constructive way to end this is for you to add a 6th discuss that says please describe the mismatch and armed with that, we will either match it up or take a look at the 6th discuss and, go, why don't we pull out what we need. One or the other. At least we have something to run with.

RH: need to move on.

MT: can you do that Dave?

DW: sure.

AV: revised-id needed. Correct Mark?

MT: yes.

AV: Five-document ballot: draft-ietf-hip-base-* Experimental. Token: Mark Townsley.

AV: 1 discuss held. Mark, do we need to discuss today?

MT: don't think so. Sam, unless you want to. Will manage with HIP folks.

RH: I would like you to take a look at my comment.

MT: I did. trying to remember what it says.

RH: may be an issue with running native IPsec with this on the same host. going to Experimental, but need to answer that question for sure.

MT: my assumption was about it and copied to others.

RH: while resolving the discuss, take a look at it.

MT: sure.

SH: There is a section at the end of the document that answers that.

RH: the SecDir Reviewer was unable to determine whether the information in the appendix was sufficient.

SH: I agree with you completly.

AV: revised-id or AD-followup

MT: Sam, revised-id needed?

SH: yes.

MT: revised-id.

AV: Individual Submissions Via AD. New Item

AV: draft-allen-sipping-poc-p-answer-state-header-05.txt. Informational. Token: Jon Peterson

AV: a discuss held. Jon, discuss today?

JP: yes. I put in an RFC-editor note that should be ok.

RH: let me check real quick.

JP: can probably move on.

RH: I cleared.

AV: have Russ cleared his discuss. approved with note already included. approve announcement going on monday.

AV: Independent Submissions Via RFC Editor, New Item

AV: draft-iino-capwap-wicop-02.txt Informational. Token: Dan Romascanu

AV: number of discuss held on the document. Dan, do we need to discuss today?

DR: I believe so. I would like to discuss the 3 documents as a group, because this is not a new issue. When the first document was brought, Brian was looking for ownership. We discussed and I cannot understand what to do with these documents. Now after having looked carefully, some of us changed their mind. There are 3 solutions with this document. Three ways we can deal with them. One would be to grant RFC-editor independent submission. The intention was to honor an agreement with the author and agree to publish as informational RFC with IESG note similar to previous notes at least from ops, like the netflow welliness of IPv6, it is not yet publish as an RFC until today. Second group of discuss are saying better synchronize the publication of this document with the publication of the capwap protocol, so we do not create confusion about what is the IETF solution to this problem space, so publish them not earlier than capwap protocol specification, particularly put a stronger note giving the status of historic, rather than informational, so, from the start, it is clear that there is no intention about the technical value. Also it is superceded by the capwap publication. Third group of discuss belong to Mark and to some extent, to Magnus, that this document does not deserve to be published as an RFC at all. I would like to get some clarity about where we go with this.

RH: state my personal opinion, not as chair, but peer to other AD: I would most confortable with them being published as historic and the same time with an IESG note that points to the standards track IETF preferred solution.

DR: right, to some extent, what I circulated is not in the IESG note in the tracker today, but it is an IESG note that I distributed earlier today and there was an amendment that no IANA action should be taken to this document, because there is no intention to create any new registry. The question is whether that IESG note would satisfy the folks that believe this is the way to go.

MW: I think I'm fine as long as there is a note that is really really clear that these are purely documenting rough protocol at the time the working group selected his direction. If this is really really clear, I'm fine this to be published. Although we actually wait until the capwap protocol comes out.

RH: right. That has been used in other working groups. They go at the same time and get RFC numbers that are adjacent to each other.

DR: ok. I believe the only clear open position against is Mark's. right?

MT: From my perspective, the minimum I would be happy with is something along the lines of what you proposed and Russ Magnus seemed to agree to. I'm still a little bothered, it sounds like any internet draft until working group and will be eventually published even if it is half-baked, -00 that you have tossed out there, which is some of this stuff looks like.

SH: Mark, the RFC-editor ultimately decides if it publishes the internet draft. It is certainly true that any IETF draft and ask the RFC-editor to publish it. That is how the process is supposed to work. They are free to not decide to.

MT: it is uncombent upon us to say things like in Magnus's discuss: no congestion control, this is evil for the internet and could be bad for the internet.

SH: this is not an appropriate discuss for an RFC-editor submission.

RH: that is right.

MT: harmful to the internet is.

SH: no. it is not.

MT: wait a minute. I have to read 3932. I know you have it memorized.

SH: actually my memory has started failing lately. really disturbing.

RH: oh no!

SH: Unfortunately. under excessive work. my memory does not work as before.

MT: it says when the publication is harmful.

RH: does not say harmful to what.

SH: harmful to the process.

MT: understand that the publication is harmful to the IETF process and working group X. We are in agreement that

DR: ...

RH: the wg is telling us that they don't mind documenting the inputs to their process.

TP: I think it is clear that this document can not go forward before. The question is if the document go forward as historic, then at the same time, goes with an IESG strong note, is it harmful in that position. Sounds like there is an agreement that we should go with historic and to lay the publication with an IESG note will narrow it.

DR: clearly state that this document is only published as historic reference because the document did not go through any basic checking of security, congestion control, etc.

MT: what was in my mind was thinking about harmful to the internet, is statement 5 section 3 that states the IESG think that this document extends an IETF protocol, therefore it should not be published unless IESG approval. I supposed when you. It is interesting that the document says extends the IETF protocol requires an IETF review. Does that mean if you violate congestion control principles? that

RH: no.

MT: ok!

SH: If you go there, you will have an appeal from ??? if he notices.

RH: I don't think that this is what that is meant.

MT: ok. what does it mean?

RH: I think it means you take an extension of a protocol and abuse the crap.

SH: basically, for example, some protocol have a special. Let's say you extended an ASN sequence in an IETF protocol. You just add some crap at the end of it. That would be an example of one of those. Or you did something that it requires an IANA standards action.

RH: ok. Have we given Dan enough advice?

MT: given this, I'll back off to the point everyone share. I'll change my view on what we can and cannot do with 3932. I thought we were allowed to make the internet work better, but guess not.

<laugh>

RH: thanks for that spin Mark.

MT: don't put that in the notes. You can, actually forget it, I don't care.

DR: thanks Mark and others for inputs. I will try to make the note sharper and I will circulate it before we see if we can clear.

SH: I don't wish to block our actions. But I want to caution that we maybe overstepping what we are supposed to do here in the following way: it is very difficult to play. It seems odd to me that we can claim that some actions harms the work done in some working group if that wg believes that harm is not. So it is difficult for us to delay publication if the working group does not want to see that delay. However, I don't care about that issue as Mark.

MT: I think I saw Dan say in an earlier email that it is not the working group, it is ...

DR: the wg does not care one way or the other. I believe the majority of the wg would be very amazed to know that the IESG dedicated 15 minutes on a telechat to these documents. So I ask the question again, yesterday. And the only two answers received and the people agree to delay the publication to informational until the protocol specification is out there.

SH: then I strongly support what we are doing.

DR: the working group today are the people think the protocol succeed.

RH: Sandy, are you clear on what we want to happen here?

??: on jabber, lost the connection.

SH: looks like muting but disconnecting.

RH: mark these all AD followup until we agree on the note. If we can do that by email, fine, otherwise bring it back to the telechat.

SG: I'm back.

RH: do you understand what we are trying to do with these three documents.

SG: I think you want to publish these documents together as Historic.

RH: But we want to publish with a fourth document, which is on standards track.

SG: we will put those documents on hold until that spec comes in.

RH: excellent. We will work in the appropriate IESG note that will point to the standards track.

SG: sounds good.

RH: thank you.

AV: least 3 documents going to AD followup.

RH: yes.

AV: five minutes break.

AV: let's see who has come back from break.

AV: Loa? <silence> Jari? Y, Marc? Y Yoshiko? Y, Michelle? Y, Lisa? Y, Lars? Y, Marshall? <silence>, Sandy? Y, Sam? Y, Russ? Y, Cullen? Y,

AV: Olaf? Y, Chris? Y, Jon? Y, Tim? Y, Dan? Y, Mark? Y, David? Y. Magnus? Y.

AV: no working group creation.

AV: WG rechartering under evaluation for IETF Review

AV: Internet and Management Support for Storage (imss). Token: Dan Romascanu

AV: Dan, do you want to give us a rundown on what the changes are for the new charter.

DR: the changes are pretty simple. Adding one item in the charter which is a fiber-channel security mib module. There is no change in the work in the charter since the charter is ready to accomodate future work for additional mib modules. I just want to bring it in front of the IESG.

AV: anyone has an objection to making this change to the charter?

AV: I'm hearing no objection.

JA: There is a question from Mark on this IPv6 part and the ipv6 working group actually going away as soon as they finish the ross document. It is under revised-id for a while. I wonder if there should be a need to rework on part of the ipv6 wg. wg does not need to know the progress of the imss, but the review is needed.

MT: ipv6 mailing list continue to exist, so can be done on the mailing list, but not as the ipv6 wg kept informed, since it does not exist. Can be done in the internet area.

JA: the core of the text is that the two working groups should work together on this, but in reality, we need review and there are many ipv6 experts that we can give you of course, but it is a different situation than the text says.

MT: Dan, I'm sorry I'm off, but what are the changes here?

DR: adding the last item in the goals and milestones. new item related to fiber-channel security mib.

MT: there are no text changes above the goals and milestones.

DR: no.

MT: Am I wrong in process again? technically, that does not require IESG review to add or update goals and milestones.

DR: well, yes and no, because it is new work. I preferred to be a little more stricter and adding new work...

MT: I don't mind having review. I'm just pointing out technically that if it is new work, it would be new text above the goals and milestones saying this is ... then you add the goals and milestones.

DR: right, but like I said, wording of the charter could accomodate the goals and milestones without having to add words above goals and milestones.

JA: anyway if you did not change or add anything about Ipv6, then it does not make sense to argue. Just keep it.

RH: just back to the question: do any object to just approving it?

RH: ok. let's approve it.

AV: wg action recharter announce.

AV: next IAB News We Can Use. Loa?

OK: Loa was not at our meeting yesterday, so I'm doing this today.

OK: What we talked about today or what is important for feedback is Cablelabs liaison, document is approved at the IESG. we are still looking for candidates for that position. Mark Townsley and Dave Oran working together to screen two candidates. I'm not quite sure I'm supposed to mention them. The cablelabs person on the other side has suggested a third person. that is ongoing work. We have also selected a new executive director, it will be Joe Abbley. in the mean time, we are busy with the agenda of the retreat, which will happen 31st of may, 1st of june in harvard location where the IESG had his retreat too. That is all for things of value at this moment.

AV: Management Issues

AV: Executive session will be at the end of the call.

AV: IANA designated expert for RFC 4728 (Dave Ward for Ross Callon)

DW: please see jabber window. names of folks. they have accepted. Any discussion?

DW: sounds it is accepted.

RH: approved. management item is resolved. Amy to send a note to IANA.

AV: IANA designated expert for RFC 3936. Dave?

DV: Dave is updating the pointer to Magnus

MW: I posted the names to the list. Francois as primary and Dimitri as backup.

DV: routing area is fine.

AV: any objection?

AV: hear no objection. done.

AV: have a question to Magnus. When secretariat send a note to IANA with these experts, do you want me to put Allison or not?

MW: we can include Allison from the beginning.

AV: ok.

AV: IANA designated expert for RFC 4204 (Dave Ward for Ross Callon)

DW: check jabber window. Is there any objection?

AV: no objection. approved. The note to IANA will include this person.

AV: Request to IESG to approve media type registrations from 3GPP SA4 (Magnus Westerlund)

MW: I put it on the agenda. People are ok or not. Cullen had an issue.

CJ: sorry not to reply earlier. I'm fine with this. no problem.

MW: ok. then my question is: Does anybody have an objection for these media-types registrations?

AV: I'm not hearing an objection. it looks like IESG has approved the media-types registrations from 3GPP SA4. Is there something we need to do to finish the , Magnus?

MW: yes. send the message to the ones included in the note and to

IANA. If you want, I can append that to the note.

AV: If you can send me to encompass. I can then send this out. I can't remember Russ, do we send these to the announcement list or just to IANA?

RH: I don't remember

AV: I don't remember either.

SH: no. I have never seen these on the announcement list.

RH: My memory is failing.

<laugh>

RH: Sorry, I could not resist.

SH: fair.

CJ: If it gets worst, it will be like the rest of us.

RH: exactly.

??: Michelle, do you have any comment?

MC: I would just say: going only to IANA too.

AV: that would be my instinct as well, but I thought I checked.

AV: will sent the note to IANA when we get that ticket from you Magnus

MW: ok.

CN: just a minute ago, I was just looking at the media-types procedures on the IESG procedures wiki and it says that it recommends to notify IANA with cc: to IETF announce. There is actually a template on the IESG wiki.

RH: There you go

CJ: might never been used before.

RH: did you just edit it?

CN: no.

AV: I will be still looking for the ticket from you, Magnus. And it will be announce to the IETF announce list, as the wiki instructs.

AV: next issue: What to do about Proxy Mobile IPv4 (Jari Arkko)

JA: The authors of this particular document as well as few other folks from wimaxforum have approached me for this particular draft, which is defining proxy mode for MobileIPv4. The origin of this is from Cisco and is deployed at least in some extent and some interest in a couple of places. The question in front of us is: do we publish that specification in some form and if so, what is that form. Now, this is fairly vendor-specific and it is not clear that IETF has change control. So no one is asking to us to start the standardisation process and even if we did, the question: how does this relates to Netlmm which is standardizing solutions in that space. Do we make it an independent submission or an individual submission for informational. Ideally, in either case, would be to document existing, and also get some additional review from the IETF. We haven't discussed on the IESG list about this case. I'm kind of torn between the two alternatives. The good thing if AD-sponsored submission, we will have more control, probably more review. The bad thing is that, if there is a problem with the document, then we are faced with the question of can we let it go through because we can't really change the deployment anyway or change the document, where no one will be happy with. I was reading my own document about AD-sponsoring guidelines and that actually says that vendor-specific protocols are not candidates for AD sponsoring, although we can debate if this is vendor-specific because other companies are interested.

SH: Particularly if the security section is not really good, I would strongly recommend that we would not run it through our review cycle, because you can easily get legitimate discuss that you can't do anything about.

JA: that is what I'm worried about.

SH: and, unless the security story is pretty good, it would end up in discuss.

JA: right, the reason I'm asking the IESG about this, is that either way, we are going to have to make a decision how we should go forward. It would be very funny if I recommend approach X and by the time it goes to IESG, then X was a bad idea.

SH: does not conflict with netlmm because they are not chartered to work on IPv4 currently.

JA: they are not, but I should tell you that the wg want to work on IPv4 as well and I might in fact send you a recharter some time soon on that topic and even, the author of the proxy-mipv4 document is one of those persons in netlmm wg argueing that netlmm standard protocol must also do v4.

SH: I think that is a problem. We had this discussion during that chartering and there was a reason to put it out of scope. If they want to finish the work and recharter to add v4, that seems reasonable. If they want to add v4 before they are done, I have a kind of major problem with that. We can discuss that.

JA: that is a separate issue.

SH: yes, that is a separate issue. It is pretty clear to me that this should be published somewhere and it probably should not be AD- sponsored.

JA: I agree with that. Russ, you had a different opinion on that. Did you change your mind?

RH: I can live with what you guys are talking about and it is just a matter that has already been discussed. In that gray area.

JA: yes.

RH: If you are confortable, I would certainly not push one way or the other.

JA: ok. let's do that. I wonder if anything we should put in the minutes. Or only we discussed the potential submission of proxy-mipv4 in the IETF or RFC editor. I will communicate after this.

RH: that seems fine. you are ok with that Amy?

AV: certainly. I have it as a management issue that was discussed. Anything else?

JA: no

AV: will put it as management issue was discussed.

AV: Working Group News We Can Use

JA: netlmm one of the news I just told you and have a new chair Jonne Soininen. In dhcp, there have been a proposal to do additional work on authentication. It is a bit unclear if it is authentication in dhcp or in network access authentication functionality into dhcp. Discussion going on in the internet area mailing list about that, so I would expect few of you at least are interested in that topic, so please participate in that.

SH: One proposal I saw was about CHAP.

JA: yes

SH: that would be a non-starter.

JA: yes, but do you want to add EAP state machine to dhcp?

SH: yes absolutely, but I understand that other people disagree.

RH: This is going to open the same can of worms that AAA key management did.

SH: no. not if you don't key anything and not if there is any security.

RH: many authentication mechanisms ??? a key and then somebody figures out how to use it.

SH: oh god, you are right.

RH: thank you

JA: Sam and Russ I'll put your email on the list.

RH: Just what I wanted: more email.

JA: I'm done with my news.

AV: Lisa, any working group news we can use?

LD: Atompub had an interop event on monday and tuesday. That was lovely. A lot of reasonable people came together and making sure their software worked and generally did. One of the interesting thing of atompub is that it can be used as a framework, e.g. for content management and picture publishing. A client that was not contended for that particular purpose might not be automatically try to upload the right mime-type and I think generally users will be able to figure out that they are posting the right content to the right site, so I was quite encouraged by the interop event. the atompub wg have had their problems and they don't necessarily do everything in "the IETF way" but sometimes, that is a good thing. That's it for me.

AV: thank you Lisa. Lars, any working group news we can use?

LE: not at this time.

AV: Sam?

SH: pass

AV: Russ?

RH: pass

AV: Cullen?

CJ: I imagine people have seen emails about geopriv floating around, percolating along. Probably the biggest thing happening right now. This week, the SIP folks are running a big SIPit interop event. It is not going seamlessly as well, the network had problem, we have discovered several bugs in people's TCP stacks due to the high error rate. Other than that, was an interesting interop.

LE: really? impact?

CJ: people not handling timers very well, it has been a network where there has been huge delays, very poor configured network with huge packet loss with an high assymetry since they had an ADSL line.

LE: are they usual tcp issues or embedded stacks tcp issues?

CJ: yes. not bugs in tcp stacks you care about. And all bugs known as bad ideas for a long time. that's all for me.

AV: Chris?

CN: yes. the lemonade wg is going to have an interim in May. But I should just mention that they have had a positive interim in the past.

SH: Is it too late?

RH: I was concerned whether we had 30 days notice of this interim.

CN: oh. well I was told they were going to do an interim without giving specific dates several weeks ago.

RH: but they have to send an announcement 30 days before the interim, or they can't have it.

CN: let's see. when was the announcement.

RH: I don't know. I just saw it today.

CN: yes. the corrected announcement went out today. Let me see.

RH: yesterday

CN: the 16th. yes.

RH: I think they have a problem

CN: yes. that is a problem. They are right on the edge. I would be inclined to let it slide but I don't know what other people feel. They were off by one day.

RH: At a minimum, you need to say: Ooops we realized we post one day late. Anyone object.

CN: ok. I'll send that out right now.

AV: anything else Chris?

CN: no, that's it.

AV: Jon, any working group news we can use?

JP: real quick. last week, I think I mentioned there is going to be a meeting on Emergency services stuff that it was not going to be exactly an ecrit interim, but ecrit wg participants will be present, and things that we need to discuss, and this is all what we needed. there was a pretty good interim meeting representations from 3GPP, ???, ETSI, typical players interested in that and I think the only potential work for IETF out of this, is that there was a pretty strong concensus, or a lot of people were very vocal about a liaison IETF ecrit and a bunch of other standard bodies basically saying can we all get along with a slightly more specific backbone to it. That might be coming down the pipe.

AV: Tim?

TP: no.

AV: Dan?

DR: shortly. we had a milestone update in adsl mib wg. we are working on a rechartering proposal on grow, having stopped the process of shutting down the wg. we are discussing the followup from ops area meeting held in Prague so we are discussing a chartering of a future ops area wg that would be modelled around what others area do, like transport area wg. that's it.

AV: Mark?

MT: no

AV: David?

DW: no.

AV: Magnus?

MW: no.

AV: end of official agenda. I will ask so that the IESG to go through their executive session for today, that all of us will leave.

SH: Amy, can the minutes reflect that I recuse myself from the discussion and I will not be part of the executive session.

AV: certainly

SH: I will be dropping off the call with others.

AV: RFC-editor, IANA, IAB will drop off. stop recording of the call now. and mute and turn down the volume and let me know when you are done.

RH: jabber you?

AV: yes.