[10:10:15] --- renee has joined
[10:12:39] --- scribe has joined
[10:12:42] --- hardie@jabber.qualcomm.com has joined
[10:12:56] <scribe> NEW SPEAKER: Okay. Let's start. Everybody in the back
[10:12:56] <scribe> take a seat.
[10:13:10] --- anewton has joined
[10:13:10] --- menno pieters has joined
[10:13:13] --- Barbara Stark has joined
[10:13:16] <scribe> eeecrit
[10:13:20] <scribe> Ecrit
[10:13:36] <scribe> NEW SPEAKER: Okay. Folks, welcome to IETF
[10:13:38] <scribe> 68ecrit Meeting. We're going to try and get through this
[10:13:44] <scribe> very fast. Everybody knows hawz. And Mark Lynn
[10:13:45] <scribe> ser.
[10:13:51] <scribe> The note well, if you haven't memorized this, you might know
[10:13:54] <scribe> it from your sleep, it might be worthy of doing in your spare
[10:13:55] <scribe> time.
[10:14:00] <scribe> Andy is not here, he would lead us in a chorus of this.
[10:14:05] <scribe> Here's the agenda, the first thing we're going to do is bash
[10:14:09] <scribe> it. So we're going to take ten minutes talking about
[10:14:10] --- isudo has joined
[10:14:11] <scribe> document status and milestones. We're going to talk about
[10:14:15] <scribe> the future of the working group. Related emergency services
[10:14:20] <scribe> activities, then we have four presentations, two present
[10:14:24] <scribe> ters with four presentations. So this all adds up to
[10:14:26] <scribe> 60 minutes, is what our allotted time is today.
[10:14:31] <scribe> If we do not get done in 60 minutes, there is another hour
[10:14:32] <scribe> scheduled for tomorrow in the second half of the
[10:14:36] <scribe> SIPPING meeting. So, SIPPING has agreed to lend us an hour
[10:14:38] <scribe> of their time, if we need it.
[10:14:46] <scribe> So, just keep that in mind. So is the agenda okay as it
[10:14:49] <scribe> appears on the screen? Okay.
[10:14:55] <scribe> So document status, we've had three documents we've thrown
[10:14:58] <scribe> over the wall to the IESG. Two of those are, have come
[10:15:01] <scribe> back to us, with comments. All of them have
[10:15:05] <scribe> come back with comments. Two of the three that have
[10:15:07] <scribe> come back with comments, we've actually spun
[10:15:11] <scribe> another one and submitted it back. All this information was
[10:15:15] <scribe> unknown to the chairs, wasn't necessarily shared toss list
[10:15:18] <scribe> when it came back. We're presenting it out to
[10:15:22] <scribe> the list right now. So you will get to see all of that exchange.
[10:15:26] <scribe> We thought stuff was publicly available and not required to send
[10:15:29] <scribe> it to the list, but we found out yesterday that something
[10:15:33] <scribe> happened in there and it wasn't available on the list, and, on on
[10:15:36] <scribe> the I D tracker, so we're going to go ahead and put that out to
[10:15:40] <scribe> the list. I believe we did that, right. Everybody
[10:15:40] <scribe> everything
[10:15:44] <scribe> NEW SPEAKER: Yes. NEW SPEAKER: So the first three
[10:15:48] <scribe> documents are in I E S G review, working their way merly
[10:15:51] <scribe> along. I don't expect any problem with any of those.
[10:15:55] <scribe> The next document, we finished working group last call on March
[10:16:01] <scribe> 2nd, and I think post working group last call on the lost
[10:16:06] <scribe> document, has actually the O 5 version, I think there's
[10:16:08] <scribe> some late comments or comments that
[10:16:13] <scribe> didn't get boot ted in O 5, so they'll get in 06. So it
[10:16:18] <scribe> appears that 06 may be the one that we throw over the wall to
[10:16:21] <scribe> the IESG at this point in time. So stay in tune on the
[10:16:23] <scribe> list, all the comments are on the mail list for
[10:16:24] <scribe> that.
[10:16:29] <scribe> D H C lost discovery dock, we finished last call working group on that.
[10:16:34] <scribe> A draft update based on the working group last call.
[10:16:37] <scribe> Comments has been spun and submitted already.
[10:16:43] <scribe> The IETF mapping architecture 01 text, we finished working group last
[10:16:47] <scribe> call on March 16. The chairs have looked at the
[10:16:51] <scribe> comments we got, which are basically little to none. Okay.
[10:16:56] <scribe> So, we really need somebody to review this document. It
[10:17:01] <scribe> really unsees easy to throw it over to the wall to
[10:17:04] <scribe> the IESG without some expert review. Mr. Rosenburg. NEW SPEAKER:
[10:17:09] <scribe> Which one? Yes, I'll review it. I just don't know
[10:17:10] <scribe> exactly.
[10:17:16] <scribe> NEW SPEAKER: You have have a long airplane ride home in the
[10:17:17] <scribe> near future.
[10:17:23] <scribe> So, please anybody with a spare few minutes on their
[10:17:25] <scribe> hands, to read that document and give us some
[10:17:29] <scribe> comments on it. Mr. Rosenburg. NEW SPEAKER: Mr. Rosen.
[10:17:35] <scribe> I'm guilt tea as most. The thing I would ask everybody,
[10:17:39] <scribe> people are saying, why do I care? We're about to kick out
[10:17:43] <scribe> the mechanism, lost. But lost itself doesn't talk about
[10:17:47] <scribe> how you find lost servers, that's force guides and all that
[10:17:53] <scribe> stuff. That's a mapping ar sh. Mapping ar sh is
[10:17:56] <scribe> arch is not crystal clear xakly how the whole thing goes
[10:17:59] <scribe> together, how you build systems that allow us
[10:18:02] <scribe> to find, no matter where you are, no matter where you're
[10:18:05] <scribe> coming from, whether you're using a carrier or not, any of
[10:18:09] <scribe> those things, find the mapping. Then either mapping arch
[10:18:13] <scribe> or lost is not good enough to get through. So it's not just a
[10:18:16] <scribe> big picture documentation. Make sure we've got all the
[10:18:18] <scribe> pieces to run the whole system.
[10:18:24] <scribe> NEW SPEAKER: So basically, to try and shorten what Brian
[10:18:27] <scribe> said, if mapping doesn't work, we've got something wrong in
[10:18:30] <scribe> that document and lost ain't going to happen.
[10:18:36] <scribe> So we really need to make sure that document is in good shape.
[10:18:42] <scribe> And Mr. Henning. NEW SPEAKER: I will point out that there
[10:18:46] <scribe> is mapping out document does not quite define everything that's
[10:18:51] <scribe> needed because potentially we left synchronization stuff out,
[10:18:53] <scribe> which fim permitting, I will talk about as well. NEW SPEAKER:
[10:18:58] <scribe> So, we've got two more documents that are working group documents
[10:19:01] <scribe> that have not been through working group last call, and
[10:19:04] <scribe> that's the phone P C P and framework dock. So both of those
[10:19:06] <scribe> need more work by the authors.
[10:19:11] <scribe> So take, let's take a look at our milestones. These are
[10:19:13] --- mlepinski has joined
[10:19:16] <scribe> based on the January '07 proposal by the chairs, to update our
[10:19:20] <scribe> milestones. I don't believe that has had A D approval, in
[10:19:24] <scribe> fact, I know it's not. We're going to consider these
[10:19:26] <scribe> milestones as good, because when we ask for
[10:19:30] <scribe> comments on them, we got zero. So I guess we can call that
[10:19:35] <scribe> consensus for. Since we got nothing against. So these are our
[10:19:38] <scribe> milestones as they stand now. We're in pretty good shape,
[10:19:42] <scribe> all the way down, the first three are done, the standard track
[10:19:47] <scribe> RFC, describing how to lost, that's lost, March 2007 is a
[10:19:51] <scribe> good one on that. The mapping arch, March 2007, probably
[10:19:54] <scribe> prelt tea good on that. Hopefully we can get some review and
[10:19:56] <scribe> feel comfortable with that and send it over the wall.
[10:20:01] <scribe> The last two on our milestones, those are pretty impressive
[10:20:07] <scribe> gates, but Mr. Rosen has agreed to get in gear on some of
[10:20:09] <scribe> those documents and try and move those forward as
[10:20:14] <scribe> fast as we can. Is that right, Brian Rosen? NEW SPEAKER:
[10:20:17] <scribe> I was asking a question. NEW SPEAKER: Just say yes. NEW SPEAKER:
[10:20:23] <scribe> Did you realize you just committed to these milestones. There
[10:20:26] <scribe> and the dates on them? NEW SPEAKER: March
[10:20:27] <scribe> 2007?
[10:20:28] <scribe> ( Laughter.)
[10:20:38] <scribe> NEW SPEAKER: As well, I'll discuss, and when we're
[10:20:43] <scribe> going to bring these, the framework and B C P is in a state where I
[10:20:47] <scribe> could say, let's working group last call it, but there's
[10:20:49] <scribe> been tollly insufficient review on it. I don't think
[10:20:54] <scribe> really think we should, until we're really sure the
[10:20:57] <scribe> mechanisms are in place. The mechanisms are evolving a
[10:21:01] <scribe> little bit. But generally speaking, if it doesn't get any
[10:21:03] <scribe> review, I'm going to say let's go. NEW SPEAKER: So
[10:21:06] <scribe> it's similar to mapping architecture, we need more
[10:21:10] <scribe> comments. NEW SPEAKER: Actually, we got reasonable
[10:21:14] <scribe> review from I E E E on this document. And we asked a few
[10:21:19] <scribe> people at the last IETF to do a review. We need to thank those
[10:21:24] <scribe> folks again. I will take a look at the weekly of who those
[10:21:24] <scribe> persons are.
[10:21:28] <scribe> NEW SPEAKER: Go ahead. NEW SPEAKER: Jonathan
[10:21:32] <scribe> Rosenburg, the March '07 one, is that based on, that's
[10:21:39] <scribe> like, you know, days right? So, for the mapping arch, is that
[10:21:42] <scribe> based on a belief that you can't, this is the debate Brian
[10:21:46] <scribe> and I br were having. Can you deploy lost without mapping arch or not?
[10:21:51] <scribe> Is that why we're trying to tie that March document and we
[10:21:54] <scribe> believe it is eed ee and needs to go? NEW SPEAKER: So, when
[10:21:57] <scribe> do the authors believe that the document should be finished?
[10:22:00] <scribe> Because we need to put some milestones there. We can't just leave
[10:22:02] <scribe> everything open. NEW SPEAKER: I agree, but that is, you
[10:22:07] <scribe> know, that's like this month? I mean, you know, that's
[10:22:09] <scribe> very aggressive. So, NEW SPEAKER: This was two
[10:22:11] <scribe> months ago, remember. NEW SPEAKER: Of course,
[10:22:14] <scribe> right. I see. Okay. NEW SPEAKER: That was our
[10:22:16] <scribe> agreed to date. NEW SPEAKER: The main point that I'm here
[10:22:20] <scribe> to make, is that it seems to me that lost will likely be deployed
[10:22:25] <scribe> without mapping arc and you get a lot of gas out of it and
[10:22:28] <scribe> Brian was disagreeing with me on that. I
[10:22:33] <scribe> viewed the mapping arc as a much more complicated longer term
[10:22:35] <scribe> proposition that didn't seem to be on the same
[10:22:38] <scribe> timetables, but that's my personal opinion. NEW SPEAKER: I
[10:22:43] <scribe> have a feeling it might get held up in the IESG without the
[10:22:45] <scribe> mapping arch, so we'll see.
[10:22:48] <scribe> So future ofecrit
[10:22:52] <scribe> , Our milestones are well underway. Right. We've had nothing new
[10:22:57] <scribe> proposed that has work group support for new charter items. Not for a
[10:23:02] <scribe> while. Okay. We haven't seen anything necessarily come
[10:23:06] <scribe> up that we've taken a hum on and agreed to work on. NEW SPEAKER:
[10:23:09] <scribe> Again, lost zinc is a possible exception to that. NEW SPEAKER:
[10:23:13] <scribe> Okay. NEW SPEAKER: I'm not proposing it because we
[10:23:16] <scribe> haven't had time in the other, we have the higher urgency
[10:23:20] <scribe> items that discusses this. If we get to this either today or
[10:23:22] <scribe> tomorrow, that's the first time I believe it has seen working
[10:23:23] <scribe> group discussion. NEW SPEAKER: Okay chltd NEW SPEAKER:
[10:23:26] <scribe> That would be one possible item. NEW SPEAKER: So this is
[10:23:31] <scribe> goods feedback for us in the front, because we're gauging on
[10:23:34] <scribe> contributions and individual submissions
[10:23:38] <scribe> as to what we're going to do going forward. So, you know, kind
[10:23:41] <scribe> of, if you look down at the bottom line on this slide, it's
[10:23:45] <scribe> like if we don't have anything come up, this working group
[10:23:48] <scribe> could shut down soon. So we want to make everybody aware of
[10:23:50] <scribe> that and start thinking along those lines.
[10:23:54] <scribe> There's, anybody that's worked in the emergency services space
[10:23:57] <scribe> knows that we're not done. But we think from a citizen to
[10:24:02] <scribe> authority, the IETF is starting to get a grip on on what that is
[10:24:06] <scribe> about, and our work is starting to solve some of those
[10:24:08] <scribe> problems.Ecrit
[10:24:13] <scribe> Was never charted to work on authority to authority or authority
[10:24:17] <scribe> do sit sin. At this point in time, so it's going to take a gross
[10:24:21] <scribe> charter change to get into that. NEW SPEAKER: So,
[10:24:24] <scribe> again, with that, we decided we're going to go forward on
[10:24:28] <scribe> that, are we going to say what we need to do is actually get
[10:24:31] <scribe> a few people together, work on the BOF and maybe bring it to the next
[10:24:35] <scribe> meeting to the authority to authority and broadcast system?
[10:24:39] <scribe> Or are we saying, all the other option is the re charge the
[10:24:44] <scribe> cit. There are two the options we have at this moment. Is
[10:24:45] <scribe> that a correct understanding?
[10:24:51] <scribe> NEW SPEAKER: That's correct.
[10:24:54] <scribe> NEW SPEAKER: I think we have discussion on that,
[10:25:01] <scribe> obviously, is to, I believe for timing reasons, it seems
[10:25:08] <scribe> and to gather, kind -- since this is really, it's a fairly
[10:25:12] <scribe> E part, the rest of the word doesn't sort of apply. The E
[10:25:16] <scribe> part one could argue could not. It's not an emergency in many
[10:25:18] <scribe> cases, as defined.
[10:25:23] <scribe> I would, and we can overlap in the creation and planning for a
[10:25:28] <scribe> new group, in that particular space, we're winding down
[10:25:28] <scribe> theecrit
[10:25:31] <scribe> Working group, it would be ar to do otherwise. NEW SPEAKER:
[10:25:34] <scribe> I agree with that actually. NEW SPEAKER: Reflecting
[10:25:38] <scribe> from the jabber room, are there other S D Os working on
[10:25:39] <scribe> authority to authority? NEW SPEAKER: Yes. NEW SPEAKER:
[10:25:44] <scribe> Steve somebody says yes. NEW SPEAKER: Yes. There
[10:25:47] <scribe> are several and coordination will be
[10:25:51] <scribe> involved and I can articulate some reasons why I think the IETF
[10:25:51] <scribe> could help.
[10:25:56] <scribe> NEW SPEAKER: Okay. Moving on. This is some, just to
[10:25:59] <scribe> let you know, some work that's been going on external to the
[10:26:03] <scribe> IETF, or kind of in liaison to the IETF. Last November
[10:26:10] <scribe> fifteen, Mr. braij put up a conference call between 3-D tie
[10:26:13] <scribe> span and eeecrit Information available there, you actually
[10:26:15] <scribe> have the URL and you can see that document.
[10:26:20] <scribe> Whether was this, February, I thought we had the date in
[10:26:28] <scribe> here. In February, hanz and I participated in an I E D tech
[10:26:30] <scribe> chat in one of their regularly scheduled
[10:26:36] <scribe> calls in updating the I A B where we were at with eeecrit
[10:26:40] <scribe> And where we were at with the emergency services and trying to
[10:26:43] <scribe> train the I A B if that's possible.
[10:26:49] <scribe> This week, we had the IETF eeecrit
[10:26:54] <scribe> I E E E meeting on Monday, over the lunch time break, for an
[10:26:57] <scribe> hour and a half. Those slides are there, on those
[10:27:00] <scribe> pointers. The meeting minutes will be distributed this week.
[10:27:05] <scribe> The follow up will be review of the eeecrit Framework and
[10:27:08] <scribe> they've agreed to take a look at that dock. NEW SPEAKER:
[10:27:10] <scribe> Send it to the list. They've done that. NEW SPEAKER:
[10:27:15] <scribe> eeecrit Should review the I E E E docks as well. And
[10:27:20] <scribe> internal interaction within the I E E E is needed so some of
[10:27:23] <scribe> their working groups can talk amongst themselves and try and
[10:27:26] <scribe> get some stuff solved. Brian is standing up. NEW SPEAKER:
[10:27:30] <scribe> I will resolve the comments and I will
[10:27:32] <scribe> generate apply that we can send through back. NEW SPEAKER: All
[10:27:37] <scribe> right. To let you know something coming up, you heard a
[10:27:42] <scribe> report on this, a like meeting of this, or last November
[10:27:45] <scribe> meeting. We had an emergency services coordination workshop
[10:27:50] <scribe> post hosted by Columbia University last October. We're
[10:27:54] <scribe> having a second one of those and it's coming up April ten, 11,
[10:27:57] <scribe> and dwevl and the host is the U.S. Department of
[10:28:00] <scribe> Transportation. It's in Washington G C. The pointer at the
[10:28:03] <scribe> bottom of that slide will tell you everything you wanted to
[10:28:07] <scribe> know about dla and give you pointers on how to register. I think the
[10:28:07] --- hbaosiy has joined
[10:28:09] --- hardie@jabber.qualcomm.com has left: Replaced by new connection.
[10:28:11] <scribe> fee is a hundred bucks. What this is, we've invited
[10:28:14] <scribe> 20 standards development organizations, and it's going to be a
[10:28:17] <scribe> three day event. We expect that about the first day, time
[10:28:21] <scribe> frame, we're going to get catch up on what ever standards
[10:28:23] <scribe> development organization is doing with regards to emergency
[10:28:31] <scribe> services work. We're again targeting it as citizen to
[10:28:33] <scribe> authority communication. We're not looking at authority to
[10:28:34] <scribe> authority or authority to citizen.
[10:28:39] <scribe> So citizen to authority communication and what the standards
[10:28:42] <scribe> body is doing. And then day two and three, we'll get in
[10:28:45] <scribe> and start doing some technical feed on the differences, the
[10:28:49] <scribe> gaps, and trying to do some analysis, and divide and
[10:28:53] <scribe> conquer of the work needed to be done and pass it off to the
[10:28:56] <scribe> different S D Os. It's a good place for collaboration and I
[10:28:59] <scribe> wanted to give you heads up on that coming up.
[10:29:07] <scribe> There was A T I S liaison, the slides are on that URL there.
[10:29:10] <scribe> Scroll down and look for it. Review errs are
[10:29:17] <scribe> needed, coordinate this with geo priv. At tis has some work and
[10:29:24] <scribe> also did a comparison of location discovery mechanisms. And in
[10:29:27] <scribe> a document and gave an opinion, and actually compared those
[10:29:33] <scribe> against the Nina requirements and gave the opinion of how they
[10:29:35] <scribe> match up with the requirements. Provide
[10:29:38] <scribe> comments back on the list and we'll try and ago gra gate those. NEW SPEAKER:
[10:29:43] <scribe> Aggregate those. NEW SPEAKER: From a
[10:29:47] <scribe> point of view, it's we have to do something, but
[10:29:49] <scribe> it's just a question of exactly what. NEW SPEAKER:
[10:29:54] <scribe> So, we're through the first ten minutes and we did that in 20.
[10:29:59] <scribe> So, NEW SPEAKER: I'll make up for it. NEW SPEAKER:
[10:30:21] <scribe> Framework. So I'm gring to, there's a newer revision of
[10:30:26] <scribe> framework out. I resolved all the comments
[10:30:32] <scribe> that I had received. We update Ed it to reflect the changes that
[10:30:35] <scribe> were in lost and conveyance and we moved some more text a
[10:30:40] <scribe> roubd round to better and reword the text to align it
[10:30:44] <scribe> between phone B C P and aligns better. Next.
[10:30:50] <scribe> There are no open issues in this document that I am aware of.
[10:30:53] <scribe> There's, it still could use a little bit more alignment, a little
[10:30:57] <scribe> normative, non normative text movements, but most of it is done.
[10:31:00] <scribe> I will go through one whole pass again. I have
[10:31:03] <scribe> comments from other people. I'm looking for comments
[10:31:07] <scribe> from other people. I will do a critical pass through, but
[10:31:15] <scribe> unless mechanisms change in any way that we know, and pending
[10:31:20] <scribe> resolution of the, we'll have a normative reference to the L
[10:31:24] <scribe> 7 L C P, I guess that will be phone B C P. Probably won't
[10:31:28] <scribe> be here. Won't be a normative reference. This one doesn't
[10:31:29] <scribe> have normative references at all.
[10:31:32] <scribe> NEW SPEAKER: It woonltd be good to have normative reference because
[10:31:35] <scribe> then the document keeps hanging around until the other one is
[10:31:38] <scribe> finished. NEW SPEAKER: Well, this will -- hold onto
[10:31:40] <scribe> that thought. I don't think we'll have a proob lem with this
[10:31:41] <scribe> one.
[10:31:47] <scribe> But I don't intend to kick this out until we're happy with both phone
[10:31:50] <scribe> B C P and framework. I think they're put together and we have to have
[10:31:53] <scribe> both of them show up at the same time. I plead for review.
[10:31:56] <scribe> Please please please review it. Give it to anybody else that might
[10:32:00] <scribe> be interested in this thing. This is the big picture of how emergency
[10:32:04] <scribe> calls work. If we don't have the big picture right, no one
[10:32:06] <scribe> will ever have implementation. NEW SPEAKER: Okay.
[10:32:11] <scribe> Looking at the page, and the persons who volunteered to be expert
[10:32:17] <scribe> reviewer, last time it's Johnson and it's stiv Steve. And I
[10:32:20] <scribe> guess we need to have some more. So coy I have some more
[10:32:23] <scribe> hands on dash NEW SPEAKER: We need reviewers, not
[10:32:26] <scribe> names. NEW SPEAKER: Yes, right. So, who would
[10:32:32] <scribe> volunteer to review the document, the framework document?
[10:32:36] <scribe> Sheen na, Tom.
[10:32:41] <scribe> NEW SPEAKER: So, let's see, that's Steve, myself and who? NEW SPEAKER:
[10:32:48] <scribe> Sheen na.
[10:32:53] <scribe> NEW SPEAKER: I saw your hand as well.
[10:32:57] <scribe> NEW SPEAKER: We can volunteer you. NEW SPEAKER:
[10:33:00] <scribe> Okay. NEW SPEAKER: That's good. NEW SPEAKER:
[10:33:03] <scribe> So, that's what I just said. Continue to follow change.
[10:33:06] <scribe> Go, next is phone B C P.
[10:33:13] <scribe> Next. Resolved all the comments, better
[10:33:17] <scribe> aligned with lost, better aligned with framework, and the work
[10:33:19] <scribe> coming out of geo priv, next.
[10:33:24] <scribe> The one thing I know I have to do is to make sections that
[10:33:28] <scribe> clearly delineate what phones have to do versus wa proxy
[10:33:32] <scribe> servers, i.E. Carriers have to do. I know that's a big
[10:33:35] <scribe> fault with the current document. The next version I will make that much much
[10:33:41] <scribe> much more clear. I haven't figured out exactly how to do it.
[10:33:44] <scribe> But I will do it. People have argued the name is
[10:33:46] <scribe> wrong. The abbreviation for the name is wrong. I just
[10:33:49] <scribe> remind you that we're heading towards an RFC. The RFC has a
[10:33:54] <scribe> number. Phone B C P will not appear anywhere in the RFC. So
[10:33:55] <scribe> don't worry about the name.
[10:33:59] <scribe> NEW SPEAKER: When are we going to see the next version? You just
[10:34:03] <scribe> mentioned the next version will -- NEW SPEAKER: I,
[10:34:07] <scribe> well, I, I hope to have it, depending, -- that depends on
[10:34:10] <scribe> reviews. Right? If I get a set of reviews, I'll put out
[10:34:11] <scribe> a revision. (Several people talking.)
[10:34:19] <scribe> NEW SPEAKER: Let's take, let's put a goal in the stand. NEW SPEAKER:
[10:34:22] <scribe> We have a Milestone. NEW SPEAKER: Right. Well, I would like to have
[10:34:25] <scribe> it down, I'd like to have the revision out midway through the
[10:34:28] <scribe> cycle so I can do a whole other revision before the next
[10:34:31] <scribe> meeting. How's that? NEW SPEAKER: Mid April. NEW SPEAKER:
[10:34:34] <scribe> Yes. NEW SPEAKER: So, we have actually no reviewers
[10:34:38] <scribe> being listed. Actual reviewers for this the document.
[10:34:45] <scribe> So, I need a few persons to do a review of this document.
[10:34:46] <scribe> NEW SPEAKER: By when?
[10:34:59] <scribe> NEW SPEAKER: Two weeks from now. Scott bren ner. Who else?
[10:35:03] <scribe> Sheen na again. NEW SPEAKER: You already have mine. NEW SPEAKER:
[10:35:07] <scribe> Peter has already done it. He said he'd make sure that I
[10:35:11] <scribe> incorporated the changes he wanted. So he's been my stal
[10:35:13] <scribe> wart on this. NEW SPEAKER:
[10:35:13] <scribe> (Several people talking.)
[10:35:17] <scribe> NEW SPEAKER: That's true. NEW SPEAKER: James, you? NEW SPEAKER:
[10:35:21] <scribe> I'm co-author. NEW SPEAKER: Oh, you can't. NEW SPEAKER:
[10:35:27] <scribe> (Several people talking.) NEW SPEAKER: Yes, he has,
[10:35:30] <scribe> because I've gotten comments from him. NEW SPEAKER:
[10:35:33] <scribe> So, please, two more persons. NEW SPEAKER: What I
[10:35:38] <scribe> was going to to say, this is not really encouraging, but we just
[10:35:42] <scribe> added several or Brian, yes, Brian and I just added several
[10:35:47] <scribe> pieces of the new text from the conveyance into the phone B C
[10:35:51] <scribe> P. And that has not gotten a review comment yet. So we
[10:35:53] <scribe> really need that. NEW SPEAKER: Yes. NEW SPEAKER:
[10:35:57] <scribe> I don't mind reviewing it but I can't do it until 8 April. So
[10:36:00] <scribe> if you can wait until then, then you can have my
[10:36:01] <scribe> comments. NEW SPEAKER: I'll take
[10:36:06] <scribe> them whenever I can get them. NEW SPEAKER: Is that a time problem
[10:36:08] <scribe> James. NEW SPEAKER: It's called a leave with the
[10:36:10] <scribe> family problem.
[10:36:14] <scribe> NEW SPEAKER: Next slide? Or is that it?
[10:36:19] <scribe> All right. So, same basic things following changes, et cetera.
[10:36:22] <scribe> Now, here, I'll come back to the point, remember that
[10:36:27] <scribe> point, there are normative references to L 7 L C P here,
[10:36:30] <scribe> and I think we can get rid of them. NEW SPEAKER: Okay. NEW SPEAKER:
[10:36:33] <scribe> That's the end of the story. We're not going to get rid of
[10:36:35] <scribe> that normative reference. NEW SPEAKER: Forever
[10:36:37] <scribe> NEW SPEAKER: That's right. That's the way it is. NEW SPEAKER: All
[10:36:39] <scribe> right. NEW SPEAKER: (Several people talking.)
[10:36:43] <scribe> NEW SPEAKER: There's no way, there is simply no way
[10:36:48] <scribe> to write this document without a normative reference to L 7 L C
[10:36:51] <scribe> P. NEW SPEAKER: Okay. NEW SPEAKER: That's it.
[10:36:55] <scribe> Questions? Comments?
[10:36:59] <scribe> NEW SPEAKER: Good. NEW SPEAKER: That's easy. NEW SPEAKER:
[10:37:15] <scribe> Slow down. We have 30 minutes. NEW SPEAKER: Don't
[10:37:16] <scribe> say that. Okay. Please, next.
[10:37:21] <scribe> I won't bore you for that, this is more for the record than
[10:37:24] <scribe> anything else. We made lots of changes, which are
[10:37:28] <scribe> basically in the clean up phase of the document. So you can
[10:37:33] <scribe> read through those faster than even EKR can probably speak
[10:37:38] <scribe> them. NEW SPEAKER: Never. NEW SPEAKER: And so,
[10:37:42] <scribe> we, but there's no, in O 5, there have been no major changes.
[10:37:42] <scribe> Next.
[10:37:44] <scribe> More, next.
[10:37:53] <scribe> Next. There's really no dash in O four, there was the only one
[10:37:57] <scribe> major change, we generated a fair amount of discussion. I
[10:38:04] <scribe> remind people we had discussion as to whether we need U I R I
[10:38:07] <scribe> for this discussion. The discussion was inconclusive because
[10:38:11] <scribe> we couldn't agree as to whether we need none, a minimal one
[10:38:15] <scribe> which had no parameters or a full dmrejd one which did, essentially
[10:38:20] <scribe> allowed you to to invoke a protocol in various
[10:38:24] <scribe> option operations, as opposed to simply define a server for that
[10:38:25] <scribe> protocol.
[10:38:27] <scribe> ( Full-fledged. ) NEW SPEAKER: If you still
[10:38:32] <scribe> remember, in January, we p three one, which had previous
[10:38:37] <scribe> IETF changes, primarily involving the mapping element as a kind
[10:38:41] <scribe> of central element that was called out more explicitly as a
[10:38:46] <scribe> single X M L element. And the path mechanism was also called
[10:38:48] <scribe> out explicitly.
[10:38:55] <scribe> Next, as far as we know, we are no substantial issues left, except
[10:39:01] <scribe> for some oops issues, where we rushed to meet the I D
[10:39:05] <scribe> deadline, we just didn't clean it up, aligning examples
[10:39:10] <scribe> with text, getting X M L cleaned up, et cetera. One
[10:39:14] <scribe> error which was recommended as part of an implementation experience was
[10:39:21] <scribe> the issue of S R S may or may not be recognized and that sthub
[10:39:23] <scribe> called explicitly an error.
[10:39:28] <scribe> When I reviewed this, I found we need a discussion as to the
[10:39:31] <scribe> expiration mechanisms for list service by location and list
[10:39:35] <scribe> services as to whether those need an explicit expiration
[10:39:38] <scribe> parameter. We've had not just reading, and I appreciate
[10:39:42] <scribe> everybody who has provided comments on behalf of
[10:39:45] <scribe> did authors. But we've also had some
[10:39:50] <scribe> implementations already. There's at least two in progress.
[10:39:57] <scribe> Two of my students, somebody Kim. Have been doing
[10:40:00] <scribe> full-fledged implementation, so not just a client or single
[10:40:08] <scribe> server, but a mock architecture, so it includes a server,
[10:40:12] <scribe> forest guide for like two mock countries, or fake data.
[10:40:17] <scribe> And we used just the County data in the U.S. And there has
[10:40:20] <scribe> been some limited inter operability test, I don't think
[10:40:25] <scribe> through the full hierarchy yet, just kind of client server
[10:40:28] <scribe> inter operability testing.
[10:40:33] <scribe> There are some names I won't dare to proceed nuns, but these
[10:40:36] <scribe> guys have been working on it. And as far as I can tell,
[10:40:43] <scribe> after some usual kind of oops clean up, we have bigger inter
[10:40:45] <scribe> operability out the door. Off the gate.
[10:40:48] <scribe> So, we believe that unless somebody raises some
[10:40:53] <scribe> really crucial last minute issues, we are done in capital
[10:40:58] <scribe> letters, until the IESG gets their hands on it.
[10:41:03] <scribe> So this is my working group last call, obviously. Has
[10:41:07] <scribe> expired. But if you found some niche while you're reading
[10:41:09] <scribe> it, something, as usual, there's something that gets
[10:41:14] <scribe> slipped, it has a lot, the document has lots of examples
[10:41:17] <scribe> and synchronizing is not always
[10:41:17] <scribe> trivial.
[10:41:21] <scribe> I think that's it. Any additional comments on lost?
[10:41:24] <scribe> At this point? If not, I'll move right along.
[10:41:35] <scribe> Okay. So this is the document which we're pleading for,
[10:41:38] <scribe> which I'm pleading for additional review. Just a reminder,
[10:41:43] <scribe> this has this notion that there is, it talks about two items,
[10:41:47] <scribe> namely how do multiple servers interact with each other. It
[10:41:50] <scribe> doesn't specify any additional protocol mechanisms, just
[10:41:55] <scribe> description. How hierarchy of search referrals kind of works and
[10:42:00] <scribe> next slide, and the notion of forest can guides, how they kind
[10:42:03] <scribe> of exchange top level information with each other in a
[10:42:08] <scribe> gossiping style where data gets more or less replicated, as it more or
[10:42:12] <scribe> less doesn't have to be perfectly replicated, due to political
[10:42:15] <scribe> reasons. And then they refer to trees for
[10:42:17] <scribe> countries, or subdivisions in them.
[10:42:20] <scribe> So it defines terminology as well as interactions between those.
[10:42:23] <scribe> Does not define any el mingts. Next, please.
[10:42:25] <scribe> Paragraph
[10:42:26] <scribe> ( Elements.)
[10:42:30] <scribe> We had a few comments that were received so
[10:42:35] <scribe> far, and I appreciate those. The reviewers listed asked to
[10:42:40] <scribe> make sure that I didn't misunderstand or otherwise man gel
[10:42:43] <scribe> their comments. So if you could take a quick
[10:42:48] <scribe> look and make sure, as I said, I tried to respond but maybe I
[10:42:51] <scribe> missed one or something. Please take a quick look. The
[10:42:55] <scribe> document is not that long. NEW SPEAKER: I think somebody reviewed
[10:42:57] <scribe> the document. He might also want to double check.
[10:43:00] <scribe> NEW SPEAKER: I'm sorry for omitting the name. Sorry about
[10:43:01] <scribe> that.
[10:43:06] <scribe> The text and content I would consider them generally stable.
[10:43:09] <scribe> There's some tweaking of wording that needs to be
[10:43:12] <scribe> done. One of the things that came up while I thought about
[10:43:15] <scribe> this little more and reread it a while ago, is that I would like
[10:43:22] <scribe> to say a few more words about, is the role of resolve err,
[10:43:24] <scribe> namely whether we recommend or whether the idea is that all
[10:43:27] <scribe> requests get routed through resolve err by default or whether for
[10:43:32] <scribe> example, service boundary would go direct. That came up in
[10:43:33] <scribe> the service boundary discussion.
[10:43:38] <scribe> My students have an implementing caching, and be in
[10:43:41] <scribe> one of the discussions we had is where and when should cashing
[10:43:44] <scribe> happen. That's probably not called out as well as it
[10:43:48] <scribe> probably could be. Namely for example, should we resolve
[10:43:52] <scribe> caching or is forest guide allowed to do caching.
[10:43:57] <scribe> My inclination is to, this is not meant to contain normative
[10:44:00] <scribe> text, simply to indicate that caching can occur
[10:44:04] <scribe> in multiple places in the hierarchy, including tore service
[10:44:06] <scribe> boundary list, and other issues. Okay.
[10:44:11] <scribe> Left to do, I have a set of comments from Matt
[10:44:16] <scribe> that I need to incorporate and then I think we already have
[10:44:19] <scribe> working group last call. And we may need to extend that a
[10:44:21] <scribe> little bit. NEW SPEAKER: Okay. NEW SPEAKER: That's
[10:44:21] --- hbaosiy has left
[10:44:27] <scribe> it, any comments on the, that? Right now?
[10:44:39] <scribe> If you can get out of there. NEW SPEAKER: Hello.
[10:44:43] <scribe> I'm not sure if this has come up. In my review, which I
[10:44:49] <scribe> just sent to you, and this wasn't on the list, we came up
[10:44:49] <scribe> with --
[10:44:51] <scribe> NEW SPEAKER: Send it to the list as well. NEW SPEAKER:
[10:44:58] <scribe> Okay. There is the something attack, and the lost call which
[10:45:03] <scribe> tells that, whenever if response to the tree to the top, so
[10:45:08] <scribe> that the user information can, where the information came
[10:45:09] <scribe> from, which part.
[10:45:15] <scribe> We came up with the idea of doing the same thing, that whether
[10:45:21] <scribe> lost gets a request, it finds out why did I get
[10:45:24] <scribe> that request, and which path was it, who referred that
[10:45:25] <scribe> question to me?
[10:45:32] <scribe> Is this not m wherein the lost or not? NEW SPEAKER: No.
[10:45:36] <scribe> I remember having some discussion on na. My recollection
[10:45:42] <scribe> was that, was that we already have, in the mapping
[10:45:45] <scribe> element, an indication of the original source. But since the
[10:45:49] <scribe> other elements are not supposed to munge with mapping
[10:45:53] <scribe> elements, be cash and released, when they are requested, not
[10:45:59] <scribe> modified. It seemed unclear to me that relatively arbitrary
[10:46:03] <scribe> path of hosts that they would traverse didn't seem to
[10:46:07] <scribe> add a lot of value, because it's, it's not like it tells
[10:46:12] <scribe> you anything as to what would happen if I do it now, because the change is
[10:46:16] <scribe> based on who knows what, particularly if the
[10:46:17] <scribe> element is relatively old.
[10:46:24] <scribe> So unless there's a clear reason beyond just it could be nice, I'm
[10:46:27] <scribe> loathe to add complexity to that. NEW SPEAKER: It's similar to a refer
[10:46:32] <scribe> header in H T P. When somebody is linking to your page, to an
[10:46:36] <scribe> existing page, you can at least know who is making the
[10:46:38] <scribe> information. NEW SPEAKER: No. You wouldn't necessarily,
[10:46:43] <scribe> because the source of it wouldn't know where data gets
[10:46:48] <scribe> distributed to. Which is the refer. There is no way which
[10:46:51] <scribe> an authority tiff server, if that's what you would want.
[10:46:55] <scribe> The refer page is, if you can, if for example, you want to
[10:46:56] --- hardie@jabber.qualcomm.com has joined
[10:46:59] <scribe> tell everything that refers to your page that you updated the
[10:47:02] <scribe> page or it's no longer there. That wouldn't accomplish that.
[10:47:06] <scribe> For that, you would have to track, for every mapping
[10:47:10] <scribe> elements that gets passed down, we're all revolved when it
[10:47:13] <scribe> happens to reside. And we certainly can't do that. The
[10:47:18] <scribe> number could be thousands. So I don't see stha. Unless
[10:47:20] <scribe> I'm probably misunderstanding you. NEW SPEAKER: You
[10:47:24] <scribe> are. NEW SPEAKER: So I just don't see what tracking,
[10:47:27] <scribe> at the resolve level, as to where it originally came dpr,
[10:47:32] <scribe> came from, helps me with dealing with stale
[10:47:34] <scribe> data, if that's what you're trying to do. NEW SPEAKER:
[10:47:41] <scribe> We're trying to make it possible that lost service know which forest
[10:47:44] <scribe> guide refer the request to him. NEW SPEAKER: All
[10:47:49] <scribe> right. You already know that just by simply where the request
[10:47:52] <scribe> came from. So I don't see that as -- NEW SPEAKER: As
[10:47:55] <scribe> far as I remember, forest guides can either pass through the
[10:48:00] <scribe> requests or return back the lost something of the real server.
[10:48:03] <scribe> In that case, the request doesn't come from the dpor rest guide. NEW SPEAKER:
[10:48:06] <scribe> Right the it comes from the original. Who sends
[10:48:12] <scribe> you the requests basically on that? So, I mean, that can
[10:48:17] <scribe> come from any number of places. Again, I'm just, not
[10:48:21] <scribe> that I'm -- I'm trying to avoid adding mechanisms if we can
[10:48:25] <scribe> help it.
[10:48:33] <scribe> NEW SPEAKER: Maybe we need to work out, work on a use
[10:48:36] <scribe> case, the specifically, particularly. NEW SPEAKER:
[10:48:39] <scribe> Yes. There has been a
[10:48:43] <scribe> proposal, which might be related to that, which is that,
[10:48:47] <scribe> which would actually I thought is in there right now.
[10:48:51] <scribe> Namely, that if you have been redirected, that you actually
[10:48:54] <scribe> capture that, which will tell you that. So that, that's
[10:48:59] <scribe> why I'm confused. NEW SPEAKER: That's why I asked if
[10:49:00] <scribe> that's in the thing already. (Several people talking.)
[10:49:03] <scribe> NEW SPEAKER: Yes. NEW SPEAKER: In December, also in
[10:49:06] <scribe> there. NEW SPEAKER: In the March version it is. NEW SPEAKER:
[10:49:07] <scribe> (Several people talking.) NEW SPEAKER: We're talking
[10:49:10] <scribe> about maybe NEW SPEAKER: Maybe we -- NEW SPEAKER: Take
[10:49:15] <scribe> a look at the current version. Take a look at 06 in particular, if
[10:49:17] <scribe> that's all you're talking about, we got that already. Refer
[10:49:21] <scribe> 01 is already there. That was for loop detection, mainly,
[10:49:26] <scribe> actually but it does the same thing. So that when you're,
[10:49:29] <scribe> redirected, that you're not, when you're now going off
[10:49:32] <scribe> on, that they don't send you right back to where you've already
[10:49:37] <scribe> gotten to. Even though it's referral as opposed to a proxy.
[10:49:40] <scribe> So that's already in. Okay.
[10:49:45] <scribe> If it's not clear enough, any other comments?
[10:49:49] <scribe> NEW SPEAKER: Okay. So, that's it. NEW SPEAKER: NEW SPEAKER:
[10:49:54] <scribe> No. We do synchronization. NEW SPEAKER: How much
[10:50:13] <scribe> time do we have? NEW SPEAKER: Okay. So this is a
[10:50:16] <scribe> draft which is currently individual draft. It's not working
[10:50:21] <scribe> group item at this point. This is motivated by the need to
[10:50:26] <scribe> communicate between servers, primarily before dash next slide.
[10:50:30] <scribe> Oh, this one. Forest guides resolve ers clusters, you saw
[10:50:34] <scribe> the previous picture, you can also have multiple instances of
[10:50:37] <scribe> the same server for reliability. And authority tiff
[10:50:38] <scribe> servers themselves.
[10:50:44] <scribe> So, the idea is that in many cases, configuration of a data
[10:50:48] <scribe> and synchronization of data will be done through proprietary
[10:50:52] <scribe> vendor specific mechanisms. Database synchronization of some
[10:50:56] <scribe> sort. But that in some cases it is quite useful to be able to
[10:51:01] <scribe> have a non proprietary protocol to do that. Simply because for
[10:51:05] <scribe> example, forest guides need that, since we are unlikely to be
[10:51:11] <scribe> operated by the same vendor for political reasons, and even within
[10:51:15] <scribe> authoritative servers, they may well, software written by different
[10:51:19] <scribe> vendors, if only to prevent total collapse, if one of these
[10:51:25] <scribe> software vendors has a zero day explode in it. You don't
[10:51:30] <scribe> want to run your whole emergency mapping structure on one
[10:51:32] <scribe> server platform, for those reasons.
[10:51:37] <scribe> Okay. So the idea is that you have a notion of
[10:51:40] <scribe> peering. We have forest guide peers, with other forest
[10:51:45] <scribe> guides, authoritative server, with forest guides, et
[10:51:50] <scribe> cetera. And the idea in general, is that each of these
[10:51:53] <scribe> peres, peering is probably not the best choice as it is.
[10:51:59] <scribe> It is sometimes symmetric and sometimes a symmetric. But in
[10:52:04] <scribe> general, the authoritative server pushes up data to the
[10:52:07] <scribe> forest guide, and saying, this is the coverage region and
[10:52:11] <scribe> the URL you should send this to. So it pushes up the tree.
[10:52:14] <scribe> Forest guide themselves can push things around at the same
[10:52:18] <scribe> level, since it's flat. We don't, peering
[10:52:22] <scribe> relationships are meant to be static and secure. You can't
[10:52:26] <scribe> just randomly show up, and say, hi, I'm peering
[10:52:30] <scribe> with you. That would not be a good idea. And we assume
[10:52:34] <scribe> these are static long term, so that it's not like we need to redo
[10:52:35] <scribe> those every other day.
[10:52:40] <scribe> This is a new provider comes on line, for a particular
[10:52:44] <scribe> country, or a new country comes on line, which, it happens in
[10:52:50] <scribe> places we're in right now, but hoyp fully it doesn't happen
[10:52:51] <scribe> all that often.
[10:52:58] <scribe> Next, the draft defines two mechanisms which are meant to be
[10:53:01] <scribe> generic sink conk saition mechanisms.
[10:53:05] <scribe> One is push and one is pull. So the push mechanisms is that
[10:53:08] <scribe> a simple peer which has a particular mapping that it
[10:53:12] <scribe> wants to add, say a forest guide talking to
[10:53:15] <scribe> another forest guide, simply sends a mapping with some
[10:53:20] <scribe> additional meta information to its peer, and it if that one is
[10:53:25] <scribe> newer, using the existing mapping mechanism it replaces one
[10:53:28] <scribe> and there's a mechanism for deleting one as well.
[10:53:36] <scribe> Next. The poll mechanism is, if I I'm joining as a new
[10:53:43] <scribe> node, new forest guide, knew authoritative service replica.
[10:53:46] <scribe> I will send a mapping request to the other side and say,
[10:53:50] <scribe> hi, what do you got? And the other side then, this is what
[10:53:54] <scribe> I have, so I send a request of what I have, with an
[10:53:58] <scribe> abbreviated version that is not in line with the current lost
[10:54:02] <scribe> draft. We changed that a little bit. But the basic idea
[10:54:06] <scribe> is you have a source, and the version, and an expiration date, which
[10:54:10] <scribe> is, and the source I D, is in there, we dropped the
[10:54:11] <scribe> version stuff.
[10:54:15] <scribe> And that will simply get pushed which tells me, these are the
[10:54:18] <scribe> objects I already have, and it simply does a
[10:54:22] <scribe> diff to its own list of mappings and pushes across those which
[10:54:25] <scribe> are newer or non existent. One of the two.
[10:54:30] <scribe> Next. NEW SPEAKER: So, Henning, is the usage model
[10:54:34] <scribe> here, that whatever I get a new list of map tion, I'll get all of
[10:54:37] <scribe> the mappings, not a Delta of what I already
[10:54:40] <scribe> have. NEW SPEAKER: Flip back for a second. In the poll
[10:54:46] <scribe> case, I would send you, if I'm, if I want, dash let's
[10:54:48] <scribe> say. There are two cases. If we are already
[10:54:52] <scribe> peering for a while, I would assume that whenever you have something new
[10:54:55] <scribe> to tell me or vice versa, you would push it to me. And you
[10:54:59] <scribe> would keep track of what you've already sent me. So you keep
[10:55:02] <scribe> state for the small number of peers that you have in
[10:55:05] <scribe> there. And you only push to me things that I have if it's something
[10:55:10] <scribe> extra, who cares. NEW SPEAKER: Okay. So the poll
[10:55:12] <scribe> mechanism is initial start up condition and then after that it's
[10:55:15] <scribe> expected to be push. NEW SPEAKER: Exactly. That's, and
[10:55:19] <scribe> whenever you feel like it, obviously, for liability reasons, you
[10:55:23] <scribe> may on occasion just do a safety, one, to make sure that
[10:55:27] <scribe> you're still in sink. Next. NEW SPEAKER:
[10:55:33] <scribe> Okay. So, the open issues that I know about, are, it
[10:55:37] <scribe> lacks current error conditions which can occur with that. It
[10:55:39] <scribe> just has three dots there. And it needs to update the
[10:55:43] <scribe> mapping according to lost so that that works also. NEW SPEAKER:
[10:55:48] <scribe> I suspect that you want some kind of a throttle mechanisms,
[10:55:51] <scribe> especially on the initial poll, because you can over well the
[10:55:54] <scribe> other guy. Probably wants to do something about that. NEW SPEAKER:
[10:55:57] <scribe> We can talk about that. NEW SPEAKER: Zero start up of
[10:56:00] <scribe> a huge database will -- NEW SPEAKER: No. But it's just (Several people talking.) NEW SPEAKER:
[10:56:04] <scribe> It's a huge file transfer, so you can paste that. It's
[10:56:07] <scribe> all TCP. It's a huge file transfer. NEW SPEAKER:
[10:56:09] <scribe> Okay. NEW SPEAKER: We're talking about, in most of
[10:56:12] <scribe> these cases, I'm actually not sure of the data volume is
[10:56:17] <scribe> gigabytes. We're probably talking a few megabytes at this
[10:56:20] <scribe> point. Because we have a whole county database and it
[10:56:22] <scribe> doesn't take gigabytes. NEW SPEAKER: Okay. We'll
[10:56:24] <scribe> see. NEW SPEAKER: Okay. NEW SPEAKER: It mate
[10:56:26] <scribe> be, you might be right.
[10:56:31] <scribe> I feel this work is very good. I can give you six or 7
[10:56:34] <scribe> examples of where we want to use it. So I really would like to see
[10:56:36] <scribe> this happen.
[10:56:41] <scribe> Another area you might want to consider is the split update
[10:56:45] <scribe> regionally problem, you know, where you got things get
[10:56:49] <scribe> disconnected, both sides update, you know, for whatever reason and
[10:56:51] <scribe> then you want to re sink. That's
[10:56:55] <scribe> probably not as common a use case as we actually have. Most of the use
[10:56:57] <scribe> cases follow this model exactly. NEW SPEAKER: Yes. NEW SPEAKER:
[10:57:01] <scribe> But there are other use cases that have a disconnect, re
[10:57:05] <scribe> connect issue. NEW SPEAKER: Yes. I have considered, because I've
[10:57:11] <scribe> actually worked in S R P, in this area fairly extensively.
[10:57:14] <scribe> Is I have not assumed a clocks are
[10:57:17] <scribe> synchronized here. One of the problems, you can make life
[10:57:22] <scribe> much easier if you can basically send me all the updates that
[10:57:27] <scribe> occurred since non X. That's non trivial once you have non
[10:57:31] <scribe> synchronized clocks. If you can send updates which are
[10:57:34] <scribe> timed, I tried not to do this optimization simply because it is
[10:57:38] <scribe> harder to get it right. So, yes, that's, yes, you
[10:57:39] <scribe> could argue you'd want that.
[10:57:45] <scribe> It seems to me, I was in an earlier discussion told to keep it simple,
[10:57:48] <scribe> because update synchronization can be tricky and I wanted to
[10:57:53] <scribe> make this efficiency wasn't my prime concern. Since my data
[10:58:00] <scribe> volume is, we're not talking here U tube. Type of volumes.
[10:58:06] <scribe> So I'd rather dup indicate the data in a reliable. Rather
[10:58:11] <scribe> than risking laugh of data. That was my notion.
[10:58:16] <scribe> Even if a SIM mre implementation would not lose data. NEW SPEAKER:
[10:58:21] <scribe> Henning, I assume that you've got time stamps or
[10:58:23] <scribe> expiring times against mapping. NEW SPEAKER:
[10:58:26] <scribe> Yes. NEW SPEAKER: So there's still the potential that
[10:58:29] <scribe> you'll need to do specific poll requests in the case that you end
[10:58:32] <scribe> up with an expired mapping inside your database, right? NEW SPEAKER:
[10:58:36] <scribe> Yes, I'm not quite sure I follow, can you try dash NEW SPEAKER:
[10:58:42] <scribe> So, if a mapping expires in my database prior to like P
[10:58:46] <scribe> adding push, to me. Which it will do before it expires,
[10:58:49] <scribe> right. NEW SPEAKER: Right. NEW SPEAKER: Is there
[10:58:52] <scribe> facility for me to go and do an individual identity poll for a
[10:58:56] <scribe> mapping from IP F, just as I wake up, grab it. NEW SPEAKER:
[10:59:00] <scribe> Yes. NEW SPEAKER: Versus having to essentially mock it as stale
[10:59:04] <scribe> and not being able to support it. NEW SPEAKER: Yes. NEW SPEAKER: Because I
[10:59:07] <scribe> have to pull everything again which I might not want to do. NEW SPEAKER:
[10:59:11] <scribe> Normally, what should happen, before an object, if a peer
[10:59:15] <scribe> has a new object, it should push it around because it knows when it
[10:59:19] <scribe> appears. If I see a stale object in my cache, I should
[10:59:23] <scribe> certainly be able to, basically, pink ping the other guy
[10:59:26] <scribe> and say why didn't you ship it to me type of deal.
[10:59:30] <scribe> One thing I need to do a better job and I forgot to add to open
[10:59:34] <scribe> issues. What do we want to do with items that genuinely
[10:59:37] <scribe> disappear. We don't want ghosts floating around
[10:59:40] <scribe> forever. That gets replicated. But before they expire.
[10:59:44] <scribe> If they expire, they expire.
[10:59:48] <scribe> Okay. I'm otherwise done. This draft has kurntdly
[10:59:53] <scribe> received, justifiably so, no feedback so far. But one
[10:59:58] <scribe> question, that I presumably have to ask charter wise,
[11:00:02] <scribe> whether we want to take that on as late charter or do people want to
[11:00:05] <scribe> have a chance to look at it first and then decide to do that?
[11:00:10] <scribe> NEW SPEAKER: Questions to Henning?
[11:00:15] <scribe> NEW SPEAKER: In terms of the A S to A synchronization,
[11:00:18] <scribe> that's fine, well, in that case, we want the same information to
[11:00:22] <scribe> be in all authoritative servers. If you're talking about forest
[11:00:25] <scribe> guides to forest guide sink Ron
[11:00:30] <scribe> saition, I have a bit of a problem here, because because if
[11:00:34] <scribe> we pull the poll which is synchronize dz service, in terms of
[11:00:36] <scribe> synchronizing something so everybody has the
[11:00:40] <scribe> same data, and if we go to that model, the forest
[11:00:45] <scribe> guides, then the only thing the forest guides, and new rule
[11:00:48] <scribe> tree. NEW SPEAKER: Right. So, what I imagine, this
[11:00:52] <scribe> is the forest guide thing, the forest guide politics which I
[11:00:56] <scribe> mentioned. So you have two cases. Namely, one is where
[11:01:01] <scribe> a forest guide is, for political reasons, s or whatever,
[11:01:06] <scribe> politics as economics, or whatever. Is unwilling to tiz a certain
[11:01:11] <scribe> one. Advertise, take the classic, Kline na,
[11:01:16] <scribe> mainland China is not willing to advertise Taiwan. And Saudi
[11:01:21] <scribe> Arabia isn't willing to advertise Israel or something of that
[11:01:24] <scribe> nature. In that case, the synchronization is not the
[11:01:28] <scribe> problem. It's simply that it receives the object, and it will
[11:01:29] <scribe> simply drop it.
[11:01:34] <scribe> All right. That seems logically easy. It seems much easier
[11:01:38] <scribe> that the number of these are modest. The receiver can decide
[11:01:41] <scribe> not to enter it on the database or market or whatever.
[11:01:49] <scribe> The second case is, that if we rely on chain rep indication,
[11:01:53] <scribe> let's replication. Let's say a new country
[11:01:58] <scribe> emerges and is forest guides and pushes its data around and
[11:02:01] <scribe> forever whatever reason, there is a broken chain so this new
[11:02:05] <scribe> country is unfriendly with some other country which doesn't
[11:02:09] <scribe> propagate this information. That I can't deal with, in the
[11:02:12] <scribe> current one. Except manually, in the sense that you have
[11:02:16] <scribe> to make sure that if you know that your data is not going to be
[11:02:22] <scribe> just propagated indirectly as it will in this mechanism, this
[11:02:26] <scribe> will make sure that all the forest guides are roughly in
[11:02:30] <scribe> sink, that you have another path to everybody else. That
[11:02:33] <scribe> will work fine, but that's not totally efficient. Again,
[11:02:37] <scribe> I tried not to make it -- I tried to make it simple rather than
[11:02:41] <scribe> efficient, since forest guides are hopefully not changing that
[11:02:45] <scribe> much. Or information in forest guides are not changes that
[11:02:45] <scribe> much.
[11:02:50] <scribe> My notion, my general notion is that forest guides with the
[11:02:55] <scribe> exception of political hot spots, which hopefully are a
[11:03:00] <scribe> handful, not hundreds. Are generally containing the same
[11:03:03] <scribe> information. But political hot spots are dealt with on an individual
[11:03:07] <scribe> basis. NEW SPEAKER: There's another issue. One
[11:03:11] <scribe> issue is like before, China and Taiwan are using, I don't
[11:03:16] <scribe> know. One other thing is that, trust relationships. Maybe
[11:03:23] <scribe> yes, user A will want to know the policies for Canada. But
[11:03:29] <scribe> are they willing to concede the option to authorize the mapping
[11:03:34] <scribe> which overrides their own mapping. So they want to
[11:03:37] <scribe> exchange, but trust in terms of who is going to use what
[11:03:43] <scribe> information, so that global, that forest guides, I'm not sure
[11:03:48] <scribe> if your approach isn't way too simple for that. NEW SPEAKER:
[11:03:53] <scribe> Well, we won't know until we see deployments, in a sense. NEW SPEAKER:
[11:04:00] <scribe> You won't. I can't imagine that American Nina will allow the
[11:04:09] <scribe> Austrian guide somehow to influence their routing. My mistake, they just
[11:04:12] <scribe> won't. NEW SPEAKER: In any replication, you will have
[11:04:17] <scribe> to check, it's like P GP routing. You have to check who is
[11:04:21] <scribe> authorized and who you believe to be authorized for a certain
[11:04:24] <scribe> geographic area. And that's, to some extent, you will have
[11:04:29] <scribe> to have a an external database which is your version of the
[11:04:31] <scribe> atlas, political atlas of the world.
[11:04:39] <scribe> Which basically says, policy, if whatever Iran claims some piece
[11:04:43] <scribe> of Iraq, that you don't agree with that. NEW SPEAKER:
[11:04:46] <scribe> Yes. NEW SPEAKER: Precisely. Yes. That's real
[11:04:49] <scribe> important. That the forest guides will need policy, and
[11:04:53] <scribe> they will have to resolve conflicts because the data will have
[11:04:56] <scribe> conflicts. NEW SPEAKER: And in many of these cases
[11:04:59] <scribe> there will be have to some human intervention happening.
[11:05:03] <scribe> Because in some cases overlap is find, because you have joint
[11:05:08] <scribe> border region that is done by mutual entities. In other
[11:05:12] <scribe> cases, this is, namely, this is reason for lining up
[11:05:17] <scribe> tanks, and I don't think that we can specify policy on that, and I don't
[11:05:22] <scribe> think we need to. This is simply an I am mre ment ter of
[11:05:26] <scribe> forest guide will have a separate static database which simply
[11:05:31] <scribe> has poly gons in it that says, if somebody claims my polygon
[11:05:34] --- ysuzuki has joined
[11:05:36] <scribe> or any part of it, bells start ringing and you need to
[11:05:39] <scribe> resolve that, whether that's an accident or somebody just
[11:05:41] <scribe> declared war on you. NEW SPEAKER: I'd just like to
[11:05:45] <scribe> say, I think it is really important that we have m mechanism
[11:05:50] <scribe> for being able to do the synchronization, and the file format
[11:05:53] <scribe> mechanism is definitely required. And I think this working group
[11:05:57] <scribe> needs to have that as a charterd item. And I
[11:06:01] <scribe> do think too, that he has some good points about
[11:06:04] <scribe> how we're going to ensue the with the trust relationships and we
[11:06:06] <scribe> really need to sit back and think about it. NEW SPEAKER:
[11:06:10] <scribe> Certainly, those have not received my attention nor the working group
[11:06:12] <scribe> attention to the level they deserve. NEW SPEAKER:
[11:06:17] <scribe> Steve somebody. Did I hear hear you refer in positive
[11:06:22] <scribe> fashion to the nice way three GP P refers to this. NEW SPEAKER:
[11:06:27] <scribe> Yes. It's the same problem. The solution in terms of
[11:06:30] <scribe> signing and other things, certainly they have no current
[11:06:33] <scribe> solution to that particular problem. But it's the ownership
[11:06:36] <scribe> problem, where you have a static database, like the R L for
[11:06:40] <scribe> example, which is subility to much more human intervention as
[11:06:46] <scribe> opposed to automatic and you compare who can advertise things
[11:06:48] <scribe> against a certain database. NEW SPEAKER: Okay. Just
[11:06:50] <scribe> checking. NEW SPEAKER: Okay, we have three or four
[11:06:53] <scribe> minutes left. So we're going to cut the line. NEW SPEAKER: Can
[11:06:55] <scribe> we do a hum on that? NEW SPEAKER: Well, reflecting
[11:06:59] <scribe> from the jabber room, I've reviewed the draft and provided
[11:07:03] <scribe> comments to the list. As long as this does not include other
[11:07:06] <scribe> synchronization methods the, I believe this should be
[11:07:09] <scribe> accepted as a working group item. NEW SPEAKER: My
[11:07:13] <scribe> intent is not to preclude that, as I mentioned in the
[11:07:16] <scribe> introduction. NEW SPEAKER: Look into Brian Rosen, if
[11:07:23] <scribe> you have a database, somehow contains shades of something,
[11:07:27] <scribe> with information on who is allowed to publish
[11:07:34] <scribe> mappings on, who can change the lost parameters for that
[11:07:39] <scribe> region, and it basically can store in there a route of the
[11:07:45] <scribe> lost tree for that country, you're done.
[11:07:48] <scribe> NEW SPEAKER: Okay. NEW SPEAKER: Okay. So, in our
[11:07:51] <scribe> couple minutes we have left here, I think hanz and I just
[11:07:57] <scribe> want to know and verify via a hum, and it appear it appears
[11:08:00] <scribe> Andy has already hummed before we asked the question, is this
[11:08:05] <scribe> group interested in picking this up as work to be done in
[11:08:08] <scribe> here, but knowing that hanz and I have to defer just a little
[11:08:12] <scribe> bit and talk to the A Ds about that? So if you think this
[11:08:16] <scribe> is worthy of eeecrit Picking it up, adding it to a
[11:08:18] <scribe> charter, put a Milestone on it, hum now.
[11:08:19] <scribe> ( Humming.)
[11:08:25] <scribe> NEW SPEAKER: Those who think it's just not this place to do
[11:08:27] <scribe> it, hum now.
[11:08:30] <scribe> ( Silence. ) NEW SPEAKER: Okay. Do you want to call
[11:08:34] <scribe> what you heard? NEW SPEAKER: I believe it's worthy of doing and
[11:08:38] <scribe> again, I just want to talk to the A Ds on it. NEW SPEAKER: Thank you. NEW SPEAKER:
[11:08:42] <scribe> We do have one minute left, if anybody has open
[11:08:50] <scribe> issues they want to talk about. NEW SPEAKER: We're
[11:08:52] <scribe> done. NEW SPEAKER: We're done. NEW SPEAKER: We
[11:08:55] <scribe> have an early start on the cookies. NEW SPEAKER: Don't
[11:08:58] <scribe> want to make you late for cookies. We're done, folks.
[11:09:00] <scribe> Thanks. NEW SPEAKER: Has everybody signed the blue sheets?
[11:09:10] <scribe> NEW SPEAKER: No. Into no.
[11:09:10] --- scribe has left
[11:09:22] --- anewton has left
[11:09:31] --- menno pieters has left
[11:09:32] --- isudo has left
[11:09:54] --- ysuzuki has left
[11:10:09] --- Barbara Stark has left
[11:10:48] --- hardie@jabber.qualcomm.com has left: Disconnected.
[11:10:56] --- renee has left
[11:19:29] --- kafka-j31415927 has joined
[11:19:35] --- kafka-j31415927 has left: Logged out
[11:20:28] --- kafka-j31415927 has joined
[11:43:28] --- mlepinski has left: Computer went to sleep
[13:55:07] --- kafka-j31415927 has left