Narrative Minutes
INTERNET ENGINEERING STEERING GROUP (IESG)
DRAFT <NARRATIVE> Narrative Minutes of the May 24, 2007 IESG Teleconference
Reported by Marc Blanchet from recording. Corrections provided by Mark Townsley and Russ Housley and Spencer Dawkins
Amy Vezza: let's start with roll-call
Amy Vezza: have received regrets from Marc Blanchet, Spencer, Dan and Marshall.
Amy Vezza: Loa: Y, Jari: Y, Ron: N, Ross: Y, Yoshiko: Y, Michelle: will join later, Lisa: Y, Lars: Y, Sandy:Y, Sam: Y, Russ H: Y, Cullen: Y, Olaf: Y, Chris: Y, Jon: Y, Tim: Y, Mark Townsley: Y, Dave Ward: N, Magnus: Y.
Amy Vezza: bash agenda. add new item?
Ross Callon: I'm on the call.
Ron Bonica: I'm in.
Russ Housley: no scribe on the call. Marc will review the recordings to make the minutes.
Amy Vezza: will make sure Marc has the recordings info.
Amy Vezza: nothing new today.
Amy Vezza: approval of the minutes of the May 10, 2007 Teleconference. any objection?
Amy Vezza: none heard. minutes approved.
Amy Vezza: narrative minutes for may 10th?
Russ Housley: not ready.
Amy Vezza: no narrative minutes for today.
Amy Vezza: outstanding tasks and review of action items.
Amy Vezza: Cullen to address the IANA open issue of well known protocol name.
Cullen Jennings: still in progress.
Amy Vezza: Mark to identify the appropriate expert for RFC 3292
Mark Townsley: I think I did that during the retreat. We talked about it. I think I can name it instead of replay the whole series of events. But I have to pull out of my email to get the right name. Check jabber window.
Amy Vezza: I will.
Amy Vezza: Sam to identify the appropriate IANA expert for RFC 4767
Sam Hartman: in progress.
Amy Vezza: takes care of our outstanding task list.
Amy Vezza: going on to documents for today. Moving on to Protocol Actions, WG Submissions
Amy Vezza: draft-ietf-tsvwg-2960bis-04.txt. Token: Lars. Currently two open positions here.
Amy Vezza: Mark Townsley, do you want to state your position for this document?
Mark Townsley: no. There are few SCTP documents that I need to read. So no position.
Amy Vezza: Dave Ward is not with us today, so no position there.
Amy Vezza: Lars, we do have a number of open discusses held on this document. do we need to discuss them today?
Lars Eggert: No. I think for all SCTP documents, maybe except the second, it is going to revised ID needed. There has been the very good review that came in. I think we need to have new drafts for all of them. Definitely a new one for this one.
Amy Vezza: this will be revised-ID needed.
Lars Eggert: yes.
Amy Vezza: next document. draft-ietf-tsvwg-addip-sctp-20.txt to Proposed Standard
Amy Vezza: number of discusses on this one. also couple of open positions.
Amy Vezza: Chris, would you like to state your position for this document?
Chris Newman: no.
Amy Vezza: and Jon?
Jon Peterson: no objection.
Amy Vezza: Lars, also revised-id needed?
Lars Eggert: yes, revised-id needed.
Amy Vezza: next document: draft-ietf-dnsext-trustupdate-timers-06.txt to Proposed Standard.
Amy Vezza: Token is Mark Townsley
Amy Vezza: have a couple of open positions.
Amy Vezza: Chris, would you like to state your position for this document?
Chris Newman: no.
Amy Vezza: Mark, one discuss held on this document. Do we need to discuss it today?
Mark Townsley: probably not because there is an on-going exchange with the authors. better let that play out. So I don't know if it will be revised-id or not.
Amy Vezza: ok. will put as AD- followup
Amy Vezza: new item: draft-ietf-enum-xmpp-02.txt to Proposed Standard.
Amy Vezza: Token: Jon Peterson
Amy Vezza: couple of open positions. Sam, would you like to state your position for this document?
Sam Hartman: no ob
Amy Vezza: Dave is not here with us today.
Amy Vezza: no discusses on this document. Unless objections, it is going to be approved.
Yoshiko Chong: IANA has put a note in the jabber window. We'd like to know the reference information.
Jon Peterson: I'm not sure that I know it from top of my head.
Yoshiko Chong: If you could put a note or something.
Russ Housley: will approve with note needed.
Jon Peterson: should be resolved by the end of the call. please put as approved.
Amy Vezza: will go approved for announcement. Jon will let us know when ready.
Amy Vezza: next item: draft-ietf-ltans-ers-13.txt to Proposed Standard.
Amy Vezza: Token: Tim Polk
Amy Vezza: couple of open positions
Amy Vezza: Sam, would you like to state your position for this document?
Sam Hartman: no objection. I think that I concluded that all of the things were discussed.
Amy Vezza: do we have a discuss on the tracker for this document. Tim, do we need to discuss today?
Tim Polk: this document should go to revised-id needed. We don't need to discuss it today. I understand the discuss and we need to make that change into the document.
Amy Vezza: revised-id needed.
Amy Vezza: next item: draft-ietf-tsvwg-cc-alt-02.txt to BCP
Amy Vezza: Token: Lars Eggert
Amy Vezza: Lars, there are couple of discuss in the tracker for this. is this also a revised-id needed like the other tsgwg documents?
Lars Eggert: right. this more than the sctp one. my involvement was editing it. Want the other authors to look at it for some implications. so going to revised-id needed.
Russ Housley: I've agreed on text with Mark. if you want to hold the discuss, I'll clear.
Lars Eggert: hold it.
Mark Townsley: I have a discuss discuss. I just put it in. I did not push the button to email to the list. sorry.
Mark Townsley: The first item that should not be a surprise, someone else mentionned it, is I have coded some text. Is this a BCP or informational? The document goes out of its way to say nothing binding here. The discuss discuss part of this is I think the IESG may need to or at least I would like to have a better understanding of what exactly BCP is, if this document says we know this is not a binding document we are not changing requirements, but simply a document targetted for approval as best current practice. emphasize on the "current". At the same time, other BCP are used as a sticks to hit people's head sometimes.
Mark Townsley: even when I read it, even when it tried to have some teeth, it fell short. It comes to my second point which if you read that paragraph I included in the discuss text, you look at it and think what guidances are provided here remains an open question.
Lars Eggert: the topic of the draft is related to the item of last week. The point is to try to layout a process for people to bring new congestion control to the IETF and say if you don't talk about these questions, then you work is stopped being considered by the IETF. The problem is that congestion control is very wide. you can have many different things. TCP extensions easily to do to completly new architectures for congestion control. So it is very hard to come up with any hard criteria about what the bar is. The document is vague because it tries to be applicable to many different type of proposals. Other people, such as researchers, that are making proposals will like to have the IETF to tell them, these are ten cases you need to run and then if you pass, you get a standard. That is simply not doable.
Lars Eggert: Your first point about whether or not it should be a BCP, I don't know. We did not discuss as much in the transport area, at all.
Magnus Westerlund: I'm quite strong it should be BCP, because you want to have that extra power in some places. I can agree it is not binding. maybe for specific process, for more general process still applies.
Mark Townsley: as the text stands now, I actually don't have any problem with the kind of things that you are trying to make binding, because basically there is so much text that says it is not binding. So I'm sort of like: great advice and I do think it is too weak here and there and happy to clear the discuss if we run off to make it as informational, but you are going to go back to Sally or whomever, and rerun this thing, then make it binding and it needs a completly new review. As it stands now, ok fine, good advice. If you tightened it up, then I think it needs to go back to IESG or it must stay on discuss until I see the new version.
Lars Eggert: I think it goes back to a new revision. You can look at it when it comes out. I don't think there is a way to get rid of the weak statements. There is no way we can get a clear bar.
Mark Townsley: that's fair. I'm not trying to push you into a bar. if you do put a bar, then I want to see what those bars are.
Sam Hartman: Lars, I don't understand why there is a need to have rules about you should do this review. There should be some rules what specific review is absolutely required for what mechanism. But I don't think there should be rules about you should do the review.
Lars Eggert: The point the draft is making is that there is a list of things that you, as a proposer of new schemes, should discuss, but discussion could be simply "does not apply" because ...
Magnus Westerlund: agree with Sam. Look at the more general statements about the overall process. leave room on how you do it.
Lars Eggert: ok. So Mark, please mail to Mark Hallman and Sally and maybe explain a little bit longer what you mean so they understand and they'll work with the discuss and see we can get out of it.
Mark Townsley: I think we should capture here Sam suggestion since everybody agrees it is a good suggestion.
Sam Hartman: already sent cross-lists. and already replied.
Lars Eggert: Mark, if you want to add it to your comment, fine.
Mark Townsley: ok.
Amy Vezza: still going to be revised-id needed.
Lars Eggert: yes.
Amy Vezza: next new item: draft-ietf-pwe3-vccv-13.txt to Proposed Standard
Amy Vezza: Token: Mark Townsley
Amy Vezza: number of open positions here.
Amy Vezza: Lars, would you like to state your position for this document?
Lars Eggert: I just started this morning and I couldn't review it to a level I'm confortable stating anything about this.
Amy Vezza: Cullen, would you like to state your position for this document?
Cullen Jennings: definitely not.
Amy Vezza: Chris, would you like to state your position for this document?
Chris Newman: no.
Amy Vezza: Jon, would you like to state your position for this document?
Jon Peterson: I'm going to go with the other lemons here and say no.
Amy Vezza: Mark, it looks like there are lot of discuss held here. do we need to discuss them today?
Mark Townsley: I'll like to give it a shot. I'll start at the top, Jari. I think that IPv6 was added here for completeness but others are doing a good job to make it complete and it wasn't well addressed. I think we can fix that. Ron, I'm happy that you agree with Sam's comments. Since you offered to help, one way is to go through Sam's comments and pull out the ones you are willing to help with and write up a constructive and actionable discuss.
Ron Bonica: I almost feel that we should start the document again and maybe organize it so that, first, review the architecture a little bit, then what kind of failure mode,
Mark Townsley: that is not a very good first shot as simply saying "start over" is not very constructive, it requires a lot more work than that. If you want to help, I would very happy but would require to go through and tell this I don't understand, etc... what Sam actually did, but he got frustrated and decided not to continue. Fine if you pick up that ball. But to ask to redo your architecture and start over, you can't go anywhere with that.
Sam Hartman: Mark, that is basically what I'm trying to convince people to what should happen here. I believe that is something that one person on the IESG can't say and that needs to be statement coming from the whole IESG. So I'm attempting to invoke a mechanism to state that.
Mark Townsley: you did. you were the one who attempted to the cliff and all the lemmings followed.
Magnus Westerlund: I got documents that were re-written for much less than this. and that is few years back even. This document is not in good shape. Ask the editor to rewrite it. Serious work on this.
Mark Townsley: I got the message here. let's move on.
Mark Townsley: Tim, you are also concerned about readability, that sounds like most of it.
Tim Polk: I went through the document as best as I could, but I found very hard. I found very encouraging that other people beyond me also found it difficult to read. I do not think that if I were to implement this document, that I would do the right thing. I'm very worried about that and as a consequence, since I was not quite sure what we were doing at which stages, I don't know I can detect any real flaws in it because it was just too hard for me to go through. Maybe people in the working group were happy, but as an outside reviewer, I struggled. I know it is not very actionable, but .
Mark Townsley: I need to go back and clear this up. The reason I'm pushing back a little bit here is that it has been implemented and being deployed. There is a basis of what is being done here in running code. I'm not saying that makes the document good or bad, but saying it means that we really need to go and fix this. to get the bottom of the problem.
Lisa Dusseault: what do you like to see happening?
Mark Townsley: I would like to see the authors go back and produce something that everybody thinks it is readable. In this particular case, there is going to be a lot of it. You are jumping on something which is really comprehensive with a lot of pwe terminology. You have to digest a lot before going into this, but in the end I would like to see it approved.
Lisa Dusseault: it is possible for them to do that with the help of somebody not on the IESG? Find some willing volunteer to help them improve the readability of the document, such as the description of the architecture.
Mark Townsley: yes. you are providing a very constructive comment here: find somebody here that does not have his head deep inside pwe3 and read this and provide the type of baseline necessary for IESG to be able to read it. That is a good idea. I will find the poor willing soul.
Ron Bonica: I'd be willing to volunteer.
Mark Townsley: fantastic. and you are also on the IESG. that would help a lot.
Lisa Dusseault: I tend to look at one of the reviewer lists. we already noticed that people are volunteers and have experienced to read some docs.
Russ Housley: the Gen-ART reviewer tried to get through this. eventually, threw his hands off. He blamed himself to not have enough background in this area.
Mark Townsley: and finally, Magnus, since you have a different kind of discuss here, I would like to talk about it real quick. You concerned that the O&M packets will congest the link. God, I hope not. if it is, somebody really misusing this.
Sam Hartman: I was curious about Magnus' discuss. Shouldn't congestion control be discussed in the underlying protocol? for example, doesn't BFD discuss congestion control and doesn't ping discuss congestion control?
Magnus Westerlund: we are getting into this. Pseudo-wire and congestion control is a mess.
Sam Hartman: I do understand the general issue that congestion control and pseudo-wire is a mess. I don't understand why running BFD or ping over pseudo-wires is a mess. I agree that for arbitrary new CB types, that might be an issue, and maybe what you want to say here, is that one of the things that a new CB needs to discuss is how it meets congestion control objectives, but for the types that are defined, it seems like we ought to be able to go back to the spec and these should talk about congestion control.
Magnus Westerlund: probably true. I haven't figured out what the ICMP echo spec says about congestion control.
Sam Hartman: that's the one I'm not sure.
Sam Hartman: BFD does not talk about congestion control and you hold a discuss when it goes to the IESG. I don't know if ICMP talks about congestion control.
Magnus Westerlund: two parts here: underspecified, it is not written well enough to put in some limits on something like that. need to consider how much traffic if you put congestion control. also existing traffic need to be considered. you could easily fill a link with pings, if you were stupid.
Mark Townsley: I like Sam's argument and I can see where you come from. In any case, it sounds like it is certainly not the intention of vccb to overrun the link with OAM, that would be very dumb. If BFD needs to talk about congestion when running over IP, which it does, then I imagine it would be as just as applicable here, it would inherit that. good or bad, it would inherit it. With respect to ping, we can put some words in there such as back off a few drop or something like that. At the end of the day, there is not anything that is a showstopping here and could probably be fixed with words and not major changes in the mission here.
Magnus Westerlund: tearing up a few things to make it clear.
Mark Townsley: that is part of the overall clarity thing. let's move on. definitely revised-id needed.
Amy Vezza: revised-id needed.
Amy Vezza: returning item: draft-ietf-ipv6-over-ppp-v2-03.txt as Draft Standard
Amy Vezza: Token: Jari Arkko
Amy Vezza: no discuss on this draft. only one open position. Unless objection, this one is approved.
Amy Vezza: checking with Jari that the note to the RFC editor is correct for this version?
Jari Arkko: yes. it is ready from my perspective.
Amy Vezza: go to RFC-editor on monday.
Amy Vezza: draft-ietf-lemonade-deployments-08.txt as BCP
Amy Vezza:Token: Chris Newman
Amy Vezza: couple of open position on this.
Amy Vezza: Lisa, would you like to state your position for this document?
Lisa Dusseault: was hoping to not get involved yet.
Amy Vezza: Sam, would you like to state your position for this document?
Sam Hartman: Chris wanted to have this approved, so the fastest thing to help this is to not state a position.
Amy Vezza: Chris, there is a discuss held. do we need to discuss it today?
Chris Newman: I would like to turn around and ask that question to Cullen, do you need it would be helpful to discuss it today?
Cullen Jennings: I actually think that we can get on the phone tomorrow and spend half an hour on this and would be much more productive. would be my preference. I do know it has been around for a long time and you want to move along.
Chris Newman: if we can have that discussion today, since I'm going on vacation tomorrow.
Cullen Jennings: ok. 5pm.
Chris Newman: good.
Chris Newman: leave it.
Amy Vezza: AD-follow up.
Amy Vezza: Document Actions, WG Submissions, New Item
Amy Vezza: draft-ietf-tsvwg-sctpthreat-03.txt as Informational
Amy Vezza: Token: Lars Eggert
Amy Vezza: Lars, is this similar to other tsv documents as revised-id needed or do we need to discuss the discusses?
Lars Eggert: there is revised-id needed. there were good comments that need to get incorporated. This will probably move before the other two, because it does not have implications with IANA action.
Amy Vezza: revised-id needed.
Amy Vezza: draft-ietf-tcpm-syn-flood-04.txt Informational
Amy Vezza: Token: Lars Eggert
Amy Vezza: one discuss. Lars, do we need to discuss it today?
Lisa Dusseault: did I forgot to send to the list?
Lars Eggert: might be during vacation and unread yet.
Lars Eggert: can you summarize your discuss? I think you are concerned with the use of the first person here.
Lisa Dusseault: the phrase "we discourage". sounds like a requirement.
WM: you got into an interesting debate about this document. Some individual in the wg definitely want to be a BCP but...
Lars Eggert: they would actually like to have as a proposed standard. This is describing what current stacks are implementing but none of these mechanisms have been proposed as standard track IETF.
Lisa Dusseault: what is your opinion on whether it should be standard-track BCP?
Lars Eggert: not this document, because it has mechanisms that are problematic. But one of them hopefully becomes standard.
SM: which one is that?
Lars Eggert: two widely used: cookies and cache. cookies have been reasonbly extended in BSD and work most frequently used options in tcp packets. that was always been the problem to encode the options in ??? (high noise on the line) . That might move forward. But the idea is to describe what is currently implemented.
Lisa Dusseault: then how do you propose to deal with this weird?
Lars Eggert: we as probably wg or standard practice.
Lisa Dusseault: and reference to the mailing list?
Lars Eggert: haven't looked at the reference.
Lisa Dusseault: I looked through the whole TCP impl mailing list. It does not support the statement that this is a practice we discourage.
Lars Eggert: could you check if you have sent it out, so the authors can reply. This should go to AD-followup. Maybe revised-id needed if some changes are needed.
Lisa Dusseault: ok. I don't have a problem saying the wg recommend something.
Lars Eggert: the alternative is to remove the reference and move the argument why it is discouraged, into the document.
Lisa Dusseault: that would be pretty good. discuss offline after sending the mail
Lars Eggert: AD-followup.
Amy Vezza: AD-followup
Amy Vezza: draft-ietf-dnsext-rollover-requirements-04.txt as (Informational)
Amy Vezza: Token: Mark Townsley
Amy Vezza: no discuss. Unless objection, it is approved.
Amy Vezza: hearing no objection. approved. no note in the tracker, right Mark?
Mark Townsley: yes. inverse of the previous document.
Lars Eggert: I had one comment that I did not put any discuss. but there is some text that said wg decided to do this and then to do that. We usually don't put this into RFC. if the authors felt to remove it, it will make me more happy, but not blocking.
Mark Townsley: there were many comments. I intended to show them to the authors. "remove text what dnsext did and did not do".
Olaf Kolkman: you have coincidently the document shepherd in the call. I have contacted the authors today with all the suggestions that were made in the comments. We will hear from them.
Mark Townsley: I did see that.
Sam Hartman: I would be concerned removing something substantial without going back to wg and IETF.
Mark Townsley: yes.
Olaf Kolkman: I double checked that. Two substantive comments I think. I considered that comment about dnsext wg being non-substantive.
Lars Eggert: that is correct. fine.
Amy Vezza: approved announcement to be sent.
Amy Vezza: draft-ietf-sipping-spam-04.txt (Informational)
Amy Vezza: Token: Jon Peterson
Amy Vezza: one discuss. do we need to discuss it today?
Jon Peterson: I haven't seen this one yet.
Chris Newman: my fault, I put it in too late. I apologize. Basically, fairly long, there are a lot of comments about email systems that are factually incorrect and this document is too good otherwise, I think it would really strength it if we took the time to do a round rev to fix those problems. But i'm ok if you feel we should push it as is.
Jon Peterson: I have no problem to send this back to the authors in this instance. probably, a lot of these they would be willing to do, others, some push back. Let's put this as AD-followup and I suspect there will be revised-id. Put it as AD-followup.
Cullen Jennings: no problem of revising it. embarrassing in my name being on this document for a few things.
Amy Vezza: draft-ietf-pwe3-ms-pw-requirements-05.txt (Informational)
Amy Vezza: Token: Mark Townsley
Amy Vezza: four discuss. do we need to discuss it today?
Mark Townsley: if we have time, would like to do. Lars, I totally agree that RFC3985 should be called out more and I think it would help out in more than one case. I will point out that there is text in the document that says that multi-segments pseudo-wires MUST be composed of single segment pseudo-wires and if you know all the jargon, that single segment pseudo-wires are RFC3985. It just need to be called out better.
Lars Eggert: maybe, the characteristics do not need to be the same. A concatenation of tcp connections, the thing is not a tcp connection.
Mark Townsley: individual things that are setup are tcp connections
Lars Eggert: the thing they are defining looks pseudo-wire at the end. I want to be sure that none of the criteria in the overall architecture are being invalidated.
Mark Townsley: I know by being involved, that is not the case. I went back and re-read it and in several cases in the document, it goes out of its way in pwe3 speak to say that we are not changing anything in the architecture in each of the individual segment.
Lars Eggert: some text goes a little bit into another direction. figure one and figure two. figure one says RFC3985 pseudo-wire view and this document extends to this. That may be worried.
Mark Townsley: probably intended to have the opposite effect to providing some background. second figure is two figures concatenated together.
Lars Eggert: one sentence thing would clarify it.
Mark Townsley: ok. with respect to pwe3 inside traffic engineering. text like: solutions must insure that an mspw would be setup with a path that is certified to be pwe bandwidth and another possible attribute is one of the possible cause for congestion. Might fit what you are looking for. That is an example. I don't think anybody was trying to avoid congestion, anymore than single segment pseudo-wire already can avoid congestion.
Lars Eggert: I agree. First part of my discuss is true meaning that all requirements of the architecture document are still in effect. that would be covered. Similar to Magnus, I was border-line into making this as comment or discuss. I called out because in the single segment pseudo-wire, this is one for one operator. if the operator goofed with the provisioning of the path, it is their traffic that hurts. if you do a cross-operator, then you could hurt somebody else.
Mark Townsley: I totally agree. It is near Sam's comment and goes into security. The multi-thing of a pseudo-wire within a single administrative domain for a variety of reasons. and they also work accross AS, into interdomain. I think it is there, but maybe text should go into greater length to be better. This is in a controlled situation. Be very careful kind of language.
SM: why should we create a signaling mechanism for congestion into the inter-domain case?
Magnus Westerlund: they need to have the requirement that resulted into this.
SM: me being grumpy about pwe3, be very careful about how they will interpret requirements. If you actually want a protocol mechanism as opposed to operational practices, make sure you can find text explicitly that state that somewhere. Make sure you have agreed, you and wg agreed on the text.
Lars Eggert: for congestion control, the wg has adopted a requirement document. this was a hole they had. 3985 says if you have a pseudo-wire, you have to have a mechanism to backoff under congestion. They did not have that. The way out for all encapsulation documents that we have approved so far, is that if you don't have a mechanism like that, then you need to only run in provisioned capacity. And this is the only they are allowed to be deployed right now. That is also the case for the multi-segment one. Only need to make sure that the whole path is provisionally provided and that makes it harder.
SM: holding a discuss that they should have a requirement for a signaling mechanism that does backoff as mandatory in the multisegment case.
Magnus Westerlund: they need to do that by provisioning. it won't work in the interdomain case.
Mark Townsley: the document outlines preconfigured static routes, predetermined routes, dynamically signaled routes and goes on to fancier stuff. Certainly, in the static route case, which is really what we are talking about today, you can provision your bandwidth and the operators will know what is going on. and that is what providers are doing, that is there money. The requirements says the solutions must insure that pwe will be setup when a path will be setup with the pwe bandwidth constraints are met for the class of service. There will be ways to the pseudo-wire to not come up when there is not bandwidth available.
Magnus Westerlund: you are coming to my comment. For static configuration, you will need a congestion control also. I may need to upgrade my comment to discuss.
SM: you should not expect such a mechanism to come up unless the document says there will be one.
Mark Townsley: I'm not sure you should expect one even if the document says there will be one, because what is going to be implemented is what is realistic. You can only push so far. Guys should remember the war around the signaling for a single segment.
Lars Eggert: if you recall, what we have adopted is not limited to single segment.
Mark Townsley: great. I think we should have all this upfront, but mandating it upfront is difficult. it does not matter if it is signaled or provisioned, the point is to avoid congestion.
Lars Eggert: two statements: ideal case, we will have a congestion control mechanism for all cases that would backoff under congestion and make it tcp friendly on a reasonable timescale. Big question Mark is how we do that. The deal that was cut was that we will publish these documents under the assumption that they will only run under provisioned capacity. That approach also applied to multi-segments. I don't know how this is going to be done. If operators do dynamically routed pseudo-wires, I have doubt they could manage the congestion. I would rather have a mechanism.
Mark Townsley: dynamic is hard.
Russ Housley: are we making progress?
Mark Townsley: I'm happy, I'm making progress.
Russ Housley: looking at the time going by, we are not making progress on other documents.
Mark Townsley: two or three people saying this is 3985. Lars, I don't think we are far off. Sam, I have one question from you. Given that we have a static case and dynamic case, I think you have more concerns about the dynamic case, about pki, ...
Sam Hartman: I never said pki.
Mark Townsley: sorry. you said key mechanism.
Sam Hartman: I'm not concerned about that in the static case..
Sam Hartman: even in the static case, the document says: minimizing the number of configuration steps is important.
Sam Hartman: if you are not running any signaling such as LDP, then do not need to secure LDP. I completly agree that you do not need to secure protocols that are not running.
Mark Townsley: right. In the case of the labels at the switch points, you are not saying we need to encrypt?
Sam Hartman: I'm saying that an analysis should be done for data plane security. I would be shocked if the answer of the data plane analysis would be to encrypt the data.
Mark Townsley: even if there is a fixed set of nodes for LDP shared and setup within an administrative domain that have shared secrets.
Sam Hartman: If you are running LDP, I think you need RFC4107 analysis. We can do that analysis and if you come back, you might not need key management. I would rather have the wg do the analysis and explain that to me instead of doing it right now.
Mark Townsley: ok, let's move on. Oh. Dan, there is the MIB architecture stuff. fine.
Russ Housley: revised-id?
Mark Townsley: yes.
Amy Vezza: revised-id needed.
Amy Vezza: Individual Submissions Via AD
Amy Vezza: draft-montemurro-gsma-imei-urn-01.txt (Experimental)
Amy Vezza: Token: Lisa Dusseault
Amy Vezza: Lisa, number of discuss, do we need to discuss it today?
Lisa Dusseault: would be helpful. Russ said it should be informational. I thought that it does not matter to me if informational is better for registering stuff in URN space, I would recommend that. I'm sure that is ok. Is that what you want to suggest.?
Russ Housley: I just don't understand what happens when the experiment ends.
Lisa Dusseault: I assume if we do experiment, that the registrations will be obsoleted. I agree that this is probably not an experiment.
Russ Housley: that is my point.
Lisa Dusseault: in general, do we allow IANA registration for experimental RFCs?
Russ Housley: yes, we allow registrations for experimental RFCs. If we were to do a port number for an experimental protocol. We usually set aside a chunk for experimentals.
Lisa Dusseault: whether or not it is experimental or informational is not relevant for IANA registration, I could deal with it.
Russ Housley: only if registry is proposed.
Lisa Dusseault: I thought Cullen said it should be standard track.
Magnus Westerlund: I agree. it shouldn't be experimental.
Cullen Jennings: I think we will have documents that will reference this. So it should be standard track.
Russ Housley: what is it really doing? we have other URN that are informational.
Magnus Westerlund: we need to think how we handle reference stuff. If we are going to do this, then the documents should be in the right category. It should be standard track.
Lisa Dusseault: I would prefer not be standard track, since they are many comments from Cullen that we would need to deal with if we were on standards track. I don't think this GSMA stuff is particularly one of our standard.
Cullen Jennings: it will go into a billion handset in the contact header of the SIP field.
Lisa Dusseault: contact header of the SIP field?
Cullen Jennings: the contact header of all the SIP messages coming from these mobile devices that would include a device identifier.
Sam Hartman: don't you want a resolvable url as contact?
Magnus Westerlund: the mobile log has their own resolve list
Sam Hartman: we believe in this global internet here.
Cullen Jennings: part of the contact that has an IP address. For most SIP UA, it is non resolvable because they are behind a NAT. That is what this whole outbound draft is to solve. There is also part that you need a unique identifier for the device. Currently, people using MAC address or UUID. This is why we would need to go standard track document.
Lars Eggert: we should separate the use and the registration. We agree on issues with the use of this. At the end of the day, we are supposed to register things like that. When time comes for dealing with the use of this, we deal that at that point.
Magnus Westerlund: I'm fine for informational, not experimental.
Cullen Jennings: me too.
Lisa Dusseault: if this register a URN namespace, would it need another document that describes how to use it in the contact header?
Cullen Jennings: we are hoping to have the document.
Lisa Dusseault: I'll work with Cullen first and see if the discusses clear up easily.
Lisa Dusseault: revised-id needed.
Amy Vezza: revised-id needed.
Lars Eggert: question: what is the procedure to talking to GSMA or to 3GPP about this? Are we taking the word of the authors for this?
Lisa Dusseault: Cullen or Jon, you know more about this than I do.
Cullen Jennings: a lightweight thing we can do is to notify the liaison that the document is under review and that the liaison of 3GPP will be aware.
Lars Eggert: one of the author is from the GSMA. would ask him about the process. then flag this to 3GPP liaison. Since we are changing the document anyway, we can do another LC with the new class of document. during the LC, the 3GPP or anyone can comment.
Cullen Jennings: one other thing: they want two URN. What the document is to carve off a namespace so that they could later use any URN later. I don't think they have a process to manage those subregistrations. Alan is just fine to move that document to register only the two URN they need. Any comment?
Lars Eggert: sounds sensible.
Jon Peterson: we will see a lot of these. I know for a fact that there are many ways to characterize a mobile device. There will be more like this.
Lisa Dusseault: revised-id needed.
Amy Vezza: Independent Submissions Via RFC Editor
Amy Vezza: draft-friend-oftp2-04.txt (Informational)
Amy Vezza: Token: Lisa Dusseault
Amy Vezza: no discuss. unless objections, then approved for no problem message.
Russ Housley: we need to pick one of the three IESG note to RFC editor.
Cullen Jennings: I'm confused about this process. Supposed Lisa says this submission is bad and I agree. Should I put "no objection" as my vote?
Cullen Jennings: not in the tracker on how to vote. no need to fix now.
Russ Housley: understood.
Magnus Westerlund: the shepherd should put the note in the RFC- editor note field. put discuss if you are not in agreement with the note to be sent to the RFC editor.
Lisa Dusseault: have a question on IANA actions for individual submissions to RFC editor?
Russ Housley: it is not our problem. Unless you think there is a problem, it is up to the RFC-editor and IANA to sort that out.
Lars Eggert: no, it is partially our problem. you have to check if the allocations are part of a space that have constraints for standard track.
Russ Housley: I agree: unless there is a problem, right. what you suggested would be a problem.
Lisa Dusseault: in a case, they might have a better scalability, extensability with a registry. But that is not our problem.
Russ Housley: right it is their protocol. If they choose to create a registry, fine. If they choose to update the document, then fine too. up to IANA and rfc-editor.
Russ Housley: now, in the tracker: IESG note and RFC-editor note.
Russ Housley: Amy done with this one.
Amy Vezza: will send the "no problem" with IESG/RFC-editor notes as in the tracker.
Amy Vezza: draft-carroll-dynmobileip-cdma-05.txt (Informational)
Amy Vezza: Token: Jari Arkko
Amy Vezza: no longer discuss. what is the next step?
Russ Housley: just tell the RFC-Editor the same thing as before: same "no problem", same note.
Amy Vezza: just resend the "no problem" with the same notes. answer the question the RFC-editor had?
Russ Housley: yes. Sandy?
Jari Arkko: that is the official thing. also another note that we did not see any significant change in the document that would change the notes.
Russ Housley: they already heard that.
Jari Arkko: I guess yes. We should not use this process again. confusing. easier with internet-drafts.
Russ Housley: Sandy ok?
Sandy Ginoza: if you guys send the message, we will be fine with it.
Russ Housley: you also understand Jari comment that you asked us to comment on this thing which is not a formal draft.
Sandy Ginoza: yes. document already in the 48 hours auth. rare case. not sure how to do. don't know to go back to the internet-draft
Russ Housley: i don't know either. just created a lot of confusion.
Sandy Ginoza: understand. we will try to figure out if comes again.
Amy Vezza: regular "no problem" message are usually sent cc: o the ietf-announce list. Since this document was never seen by IETF community, do you want to send it?
Russ Housley: not in this instance. no more comments. it started in 2004.
Amy Vezza: end of discussion on the documents. 5 minutes break.
Amy Vezza: back. roll call:
Amy Vezza: roll call: Loa: Y, Jari: Y, Ron: Y, Ross: Y, Yoshiko: N, Michelle: Y, Lisa: N, Lars: Y, Sandy: Y, Sam: Y, Russ H: Y, Cullen: Y, Olaf: Y, Chris: Y, Jon: Y, Tim: Y, Mark Townsley: Y, Magnus: Y.
Amy Vezza: Working Group Actions, WG Creation, Proposed for IETF Review
Amy Vezza: Operations and Management Area Working Group (opsawg)
Amy Vezza: Token: Dan Romascanu
Amy Vezza: any objection on the charter to be sent for external review.
Magnus Westerlund: had a comment but for minor language. might want to fix before sending it out.
Russ Housley: Ron, did you see those.
Ron Bonica: yes.
Russ Housley: send a ticket when ready
Russ Housley: Ron will provide updated text
Amy Vezza: no objection for external review. will wait Ron for edits.
Amy Vezza: Basic Level of Interoperability for SIP Services (bliss)
Amy Vezza: Token: Cullen Jennings
Amy Vezza: any objection for sending for external review?
Russ Housley: high level question: very long charter. do we really want to do that?
Cullen Jennings: this one add up, people very concerned about the scope what is there. I know why it is long. don't know how to make it shorter, without leaving issues. Uses a lot of PSTN terms that are expanded.
Russ Housley: just wanted to know. so it is based on discussions in the area that it is the right thing to do.
Cullen Jennings: number one thing that people want to resolve out of the bof is that.
Russ Housley: I'm right.
Magnus Westerlund: ensure that the text we sent is agreeable.
Cullen Jennings: yes.
Russ Housley: confused now.
Cullen Jennings: wanted to work on wrap thing.
Amy Vezza: just the word wrap issue?
Cullen Jennings: yes.
Amy Vezza: will take care of it.
Amy Vezza: external review is approved.
Amy Vezza: IAB News We Can Use
Olaf Kolkman: will do. Loa did not have the opportunity to be in the last meeting. We send out a reply on a questionnaire from the ITU consulting about Internet governance. ITU asks specific questions where they can help about IP addresses and DNS and things like that. We drafted the message and will be on the IAB web site shortly and basically say in polite words the protocol space is our reason, we set the standards for DNS, and this is our world, we work with ICANN on this, please work with us, if this is needed. We put the steak on the ground with this document.
Olaf Kolkman: Liaison with Cablelabs . Dave Oran is talking to a third candidate. We have not made the choice yet, hope to have. done by next business meeting or hopefully at the retreat.
Olaf Kolkman: Retreat in a week from now, 31stmay 1 june. One of the bigger topic is about the routing and addressing work. what we can do as IAB looking at the problem. If it is ready, we will be looking at problem statement from the routing and addressing directorate. and other things on the agenda as well, looking forward for the next year.
Amy Vezza: Management Issues
Amy Vezza: Removal of System port application form from the IANA website (Michelle Cotton)
Michelle Cotton: sent a message around. we are receiving applications for system ports that are completly bogus and they are for user ports. historically, we only assign system ports when they were documented in RFC. So we wanted to have some thoughts about removing the application from the web site. Most comments that I saw that it was reasonable. One comment asked about what if the IETF decided to standardize their protocol. This is the language in the application. They would send a generic form that way. But to my knowledge, none were received that way. Assignments were done when RFC publication. Any objection on removing the form from the web site, knowing that there is a generic form if needed.
Russ Housley: don't have an objection, but send a message to the IETF.
Michelle Cotton: to the announce list?
Russ Housley: yes. RH and then just say that the preferred way is to publish an RFC.
Amy Vezza: Expert for RFC4308 and RFC4869 (Michelle Cotton)
Michelle Cotton: solved on mine. Russ, this is Tero.
Russ Housley: we thought he was already on this.
Michelle Cotton: yes for some other RFC
Russ Housley: just extended his scope.
Amy Vezza: Selection of Volunteers for testing the Internet-Drafts Submission Tool for IETF 69 (Russ Housley)
Russ Housley: id submission tool: we want testers to use this prior to Chicago. Each area to name 10 authors to try the tool. Asking each AD to name 5 or each area to name 10. and pass it to the secretariat. This is a scalability test. Make sure the thing works and
Lars Eggert: authors with one document each, or many documents by authors.
Barbara Fuller: it does not matter.
Russ Housley: a mix will be best. different needs from the tool.
Sam Hartman: do we need to specify all authors or the just the submitter.
Russ Housley: just the submitter.
Mark Townsley: ok to just resubmit the same ID with a new number.
Barbara Fuller: this will be their mechanism to submit. real ID...
Mark Townsley: give the name to secretariat and the secretariat will contact them.
Russ Housley: when do you need the names.
Barbara Fuller: june 6th. first round, will be a account based. then when tool deploy, after chicago, then all every.
Sam Hartman: I assume that if it has issues, they can fall back to email
Russ Housley: correct to fall back to send email.
Amy Vezza: Response to RFC Editor regarding draft-saleem-msml (Cullen Jennings)
Cullen Jennings: I was unaware.
Jon Peterson: sorry.
Russ Housley: we will remove this agenda item. was not discussed.
Amy Vezza: Confirmation of replacement expert for PPP Numbers (Michelle Cotton)
Michelle Cotton: was put on hold until Jari and Mark were on call. Carl ?? has been the expert for years. He suggested Jim Carlson as replacement, since he is more involved than Carl is.
Jari Arkko: sounds great.
Russ Housley: IESG approved.
Amy Vezza: Question regarding a reallocation of system port numbers (Michelle Cotton)
Michelle Cotton: got a request from Jim Davies about reallocating system port numbers. Not being asked to do before. Feedback from IESG about what we can do, since it is not assigning new system ports. We can discuss it, tag an area director.
Russ Housley: anyone have info on these particular ports
Sam Hartman: if the facts claimed in the IANA claimed are true, this is a no brainer and we should say yes. and not spending a lot of time in process to say yes.
Cullen Jennings: it might be a technical issue here. assuming all the facts are right. I started being concerned about running two different protocols on the same number but udp and tcp. any concerns in DNS.
Sam Hartman: we need someone to volunteer to verify the facts.
Russ Housley: we can ask IANA to do that.
Michelle Cotton: yes.
Russ Housley: if facts are true, then we don't have any issue.
Russ Housley: Dan might know.
Michelle Cotton: will talk to Dan.
Amy Vezza: Working Group News We Can Use
Amy Vezza: Jari.
Jari Arkko: mip6-nemo merge is proceeding. currently issue is who the chair will be. expect merged charter in the next meetings.
Jari Arkko: 5 bof requests: interesting call next week.
Jari Arkko: IPR issues in mobike. not really my area anymore, but was chair. report from one of the implementor that they were approached by a small company requesting money for licensing. I should probably fill a third-party claim. Nokia also will fill a claim. The editor is also same company.
Russ Housley: you have a plan?
Jari Arkko: I have sent the announcement to the wg mailing list.
Sam Hartman: annoying about third party claim is that you need the patent number.
Jari Arkko: we have.
Sam Hartman: easy then, just fill a form on the web site. it asks you to assert that you believe the IPR applies.
Jari Arkko: really.
Sam Hartman: that is my recollection of the form.
Jari Arkko: not sure I want to make a statement.
Sam Hartman: when I was considering filling a third party statement, I was unconfortable filling the form. I was falling back to sending
mail. But Eric was.
Jari Arkko: you can still send email to.
Sam Hartman: you can. run the risk to have your disclosure marked as incomplete if you failed providing all the fields.
Jari Arkko: it is incomplete. this is the true state of the world.
Sam Hartman: you might not be considered.
Jari Arkko: what I care is the community knows it.
Russ Housley: the real goal is to have the holder to make a statement.
Jari Arkko: yes. I intend to contact the company, but there are out of business. probably why they are hunting for IPR. Will ask secretariat to do that.
Amy Vezza: if you know the name of the contact, that would help us a lot.
Jari Arkko: i know the ietf participant who use to work there.
Amy Vezza: Ron Bonica?
Ron Bonica: no
Amy Vezza: Ross Callon
Ross Callon: no
Amy Vezza: Lisa?
Lisa Dusseault: discussions on atompub and ietf general lists about use of specific versions of TLS. if the IESG is the one requiring the wg to specify mandatory to implement security reasonable authentication, we should be able to provide text and that text would be specific enough to define which version of TLS to be supported on both ends. I'm currently rejecting their call for IESG to provide text because we are not the ones with the knowledge about which version of TLS is available on those systems atompub people are using. And frankly, this is not a real problem. The interop event went fine.
Russ Housley: was text in EPP protocol about this.
Sam Hartman: maybe we should require TLS 2.0
RH laughing
Russ Housley: for people who did not get it, TLS 2.0 does not exist yet.
Cullen Jennings: I don't think it is our problem to solve.
Russ Housley: we point them to the words written before. Hope this is helpful.
Lisa Dusseault: I've been trying to tell wg that it is not IESG, IESG is enforcing a community requirement.
Russ Housley: exactly
Lisa Dusseault: that nuance statement gets lost.
Amy Vezza: Lars?
Lars Eggert: no
Amy Vezza: Sam?
Sam Hartman: bof received is ifare. not had a chance to review it. unfortunately, going on vacation tomorrow. may not be able to do the bof call.
Russ Housley: Tim, going to be on call.
Tim Polk: yes.
Tim Polk: we should discuss that before the bof call.
Amy Vezza: Russ?
Russ Housley: no
Amy Vezza: Cullen?
Cullen Jennings: no
Amy Vezza: Chris?
Chris Newman: lemonade wg had an interim meeting last week. attended remotely. very positive. lot of removal of complexity. one point: lemonade has a liaison with OMA such they want a lot of work done quickly and one person was discussing appealing IESG discuss vote on lemonade dcument. I was the only one saying you should not do that.
Sam Hartman: unlikely to speed up their document.
Sam Hartman: one constructive comment: if they see a discuss that does not fit into discuss requirements, then ask the person holding the discuss to consider looking at it.
Chris Newman: will do offline.
Chris Newman: bof request: I drove the bof request: write a draft charter. two document authors, two potential chairs. Vcard and carddev.
Amy Vezza: Jon?
Jon Peterson: Cullen and I are planning to send a statement to 3GPP on service identification. came out from concensus call in Sipping wg in Prague. Architectural trend that 3GPP is doing. Ignoring SDP and then use proprietary tags in the header.
Amy Vezza: TIm?
Tim Polk: bof on trust anchor management. looking for IAB and IESG bof telechat advice.
Amy Vezza: Mark?
Mark Townsley: no
Amy Vezza: Magnus?
Magnus Westerlund: no.
Amy Vezza: end of call