RE: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68

At 04:31 PM 4/19/2007, Dawson, Martin wrote:
>And there it is.
>
>You're going to have to justify the accusation, John. Barbara S has
>already said she thinks she'll be constrained to deploying a system such
>as this - so it's certainly not a hidden agenda on her behalf. Other
>than that, it constitutes about 1% of the reasons for needing a location
>protocol that works above IP.
>
>The conspiracy theory is quite simply wrong.

energy and misrepresentation doesn't make things right either....


>Cheers,
>Martin
>
>-----Original Message-----
>From: John Schnizlein [mailto:[email protected]]
>Sent: Friday, 20 April 2007 7:13 AM
>To: GEOPRIV WG; [email protected]
>Subject: Re: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF
>68
>
>It is worth recalling that a subset of the AD's and GeoPriv Chairs
>have pursued surprise changes to the advertised agenda before.
>
>The agenda of the GeoPriv WG meeting at IETF 57 was distinctly
>different from the one advertised, with the inclusion of a
>presentation by Jon Peterson on draft-ietf-geopriv-dhcp-lci-option at
>the beginning.  During Agenda Bash, I objected to the insertion of
>this presentation without the knowledge of the authors, and was told
>that the author not present had been told.  Jon's presentation was a
>well-organized ambush with slides in which he raised a wide variety
>of "concerns" about the draft that he had not (for that matter never
>did) post to the WG mailing list.  On the day after the draft minutes
>of the meeting were posted on September 23, 2003, I posted
>clarification on the mailing list of the whitewash of the objection
>to the inclusion of that ambush presentation.
>
>With modifications, that draft became RFC 3825, and represents the
>then-consensus position that hosts should obtain and control
>information about their geographic locations.  The alternative that
>may have been the hidden agenda at IETF 68 instead advocates that
>control of a host's geographic location reside with the network
>operator, and delivered through location servers.  The only
>"requirement" for these location servers appears to be the business
>interests of their operators, following the model of existing
>cellular telephone networks.  Advocates for this server-centric model
>have pushed a protocol called HELD, which may have been represented
>as an IETF product (based on individual-submission drafts) to
>operator groups.  Some of the same advocates have also undertaken
>attacks on RFC 3825 with arcane arguments about claimed differences
>between "uncertainty" and the resolution of a (latitude, longitude)
>location.  After one of the chairs requested a draft to clarify the
>meaning of resolution in RFC 3825, and the comments from IETF 67 were
>incorporated into a WG-approved draft, the chairs have arbitrarily
>labeled this draft: draft-ietf-geopriv-binary-lci-00 as "Awaiting
>revision by author team".
>
>There is reason to suspect that the maneuvers in Prague are part of
>an agenda to move control over a host's location from the host to the
>network operator in order to create a business of providing it.
>There is a pattern with implications on the outcome of the WG, not
>just procedural lapse.
>
>John
>
>On Apr 18, 2007, at 8:59 PM, Ted Hardie wrote:
>
> > Howdy,
> >       I'd like to make some comments on the issues discussed below.
>Before
> > diving into the details, I'd like to make two meta-comments.  First,
> > I believe that the chairs' messages noted that they had received
> > private messages
> > of concern, and that their e-mail was expressed as a response to
> > those messages.
> > As chairs, it is their responsibility to take the community's
> > concerns seriously
> > and to respond to them.  My reading of their response is that they
> > believe
> > that the IETF 68 meeting of GEOPRIV was sufficiently unusual that
> > it requires us
> > to be very careful to follow our standard procedures in following
> > up the meeting,
> > so that the overall process is obviously fair and is as transparent
> > as possible.
> >       This serves the interests of those who were at the GEOPRIV
>meeting at
> > IETF 68, as well as those who participate but could not physically
> > attend
> > the meeting.  Reading Cullen's response, it looks like he saw this
> > as the
> > chairs' impression and reaction as individuals; maybe that is part
> > of it,
> > but I believe is important to see this in terms of the view of the
> > participant
> > community (of which the Chairs certainly form part).  I also
> > believe that their
> > suggested response is basically "do business as usual, and make
> > sure that's obvious",
> > which I believe is non-controversial as a way forward.
> >       Secondly, I believe that this response has picked up some style
> > elements of the original chairs' message and exaggerated them,
> > falling into quasi-legal language that hurts us as a group of folks
> > trying to
> > get this done.  As I read the original message, the core is that
> > there were three
> > unusual aspects of the GEOPRIV meeting at IETF 68:  the schedule
> > changed, which
> > had some unfortunate consequences; the meeting agenda changed more
> > than usual;
> > and the way the group made progress was at the far end of our
> > process.  Any
> > one of those, alone, might be enough to cause us to want to be
> > careful of the
> > follow-up.  All of them together are definitely enough.  Rather
> > than push against
> > how any one of these points got to be, let's see if we can agree on
> > the way
> > forward.  I think, honestly, we already do, and bogging down in how we
> > got here is not that useful.  As you'll see below I see some
> > mistakes I made
> > here, and I suspect others do as well.  Let's learn from them and
> > move on.
> >
> > At 1:23 PM -0700 4/18/07, Cullen Jennings wrote:
> >> In the email below, the GEOPRIV chairs express serious concerns
> >> about the process surrounding the GEOPRIV meeting at IETF 68 in
> >> Prague. In particular, they allege:
> >>
> >> - That improper meetings occurred between the ADs and the working
> >> group participants and that this "potentially harmed the integrity
> >> and transparency of GEOPRIV and the IETF"
> >>
> >> - That there was "the appearance that there may have been an
> >> attempt to manipulate IETF process to hold and predetermine the
> >> outcome of consensus calls" on the part of the Area Directors.
> >>
> >> In the first place, the Area Directors take these concerns, and
> >> grave allegations, very seriously. Area Directors who manipulate
> >> schedules and agendas in order to predetermine the outcome of
> >> consensus calls should, in our opinion, be summarily recalled, and
> >> if the GEOPRIV working group chairs believe this transpired in
> >> IETF 68, we urge them to pursue such a recourse.
> >
> > I urge them not to.  Let's try to work this out without creaking
> > into effect a never-used
> > aspect of our process.  Pushing it to that extreme looks contrary
> > to our usual effort
> > to achieve consensus; let's continue talking to each other
> > instead.  If either the
> > Area Directors or chairs is no longer willing to talk about the
> > problems and resolve
> > them, I think we're in a sorry state.  If we've gotten there, let's
> > try and back away.
> >
> >
> >> While we speak to the particulars in detail below, in short we
> >> believe that our efforts before, during and after the GEOPRIV
> >> meeting at IETF 68 were limited to encouraging a set of
> >> participants to arrive at a consensus which was long overdue, and
> >> did not extend to steering said consensus in any particular
> >> direction. In this regard we do not believe we overstepped our
> >> bounds, either in the letter or the spirit of the process.
> >>
> >> As indicated in my message of March 25, we agree with the GEOPRIV
> >> chairs that the hums taken in prague need to be confirmed on the
> >> mailing list. As we all know, the contents of a room in Prague are
> >> not equivalent to an IETF working group; only formal decisions of
> >> this mailing list are definitive for the working group. Too often
> >> working group minutes are published and completely ignored, which
> >> only leads to further discord down the road when participants
> >> resist that to which they are presumed to have assented. This is
> >> particularly important in this case because opinion in the room
> >> was so closely divided. So in the interests of making progress,
> >> please do review the results of Prague carefully!
> >>
> >> To the particular concerns of the GEOPRIV chairs:
> >>
> >> <> Agenda: The Area Directors did meet privately with members of
> >> the GEOPRIV working group prior to the meeting at IETF 68. Indeed,
> >> we met with as many stakeholders as possible, specifically to
> >> ascertain how the group could move forward on a set of contentious
> >> issues which had been unresolved for some time.
> >
> > As a participant, I volunteered to meet with James Winterbottom to
> > discuss some
> > of his concerns and to understand better how some aspects of his
> > proposal helped
> > advance the work of the group.  Looking back over the email
> > exchange leading
> > up to that, I realize now that it would have better for me to add my
> > willingness to talk to other folks with other points of view, as
> > some other
> > folks might have misconstrued my message as singling James out.
> > Because I was serving on the IESG at the time, some folks might
> > have misunderstood which hat I was wearing when I made that offer.
> > I apologize for that, especially if
> > that contributed to  any of the feeling that one position was being
> > favored.
> >
> > I think the same could be said for Jon and Cullen.  Once they
> > started meeting
> > privately with folks from GEOPRIV to discuss how to move forward, a
> > note
> > to the group that they were looking for input on that would have been
> > useful.  In particular, it might have identified folks that Jon and
> > Cullen
> > didn't immediately recognize as "stakeholders", and it would have
> > given
> > those not at the physical meeting time to send email or otherwise
> > contact
> > them as ADs.  I don't think that would have had a huge impact on the
> > outcome, honestly, but it would have increased the transparency of
> > what
> > was going on.  That goes to the point the chairs have made.  In the
> > middle
> > of an IETF, jet-lagged and hyper-busy, I think we have to agree
> > that this is an easy
> > mistake to make.  But I hope we can agree that an open call for
> > input would
> > be a good thing to be sure of in the future.
> >
> >> In the course of these meetings we solicited input on how progress
> >> could be made at the meeting, and strongly encouraged working
> >> group members to find a path to consensus. We came to believe that
> >> focusing on core issues that were impeding progress, such as the
> >> longstanding disagreement on an HTTP-based Layer 7 Location
> >> Configuration Protocol (henceforth L7LCP) rather than ancillary
> >> issues like location signing, would be the best use of working
> >> group facetime.
> >
> > I'm not sure everyone sees location signing as ancillary; it's just
> > momentarily
> > less contentious.
> >
> > The reality is that the group was deadlocked on whether to do an L7LCP
> > and remained so for a long time after the idea was first
> > introduced.  This
> > was later exacerbated by a choice in which document to use as a
> > baseline if
> > the working group did take it up.  This latter choice was bitterly
> > contentious
> > and had been so for some time.  I agree with the choice to make
> > resolving
> > it a priority, but I also see the problem raised by the chairs:  it
> > was not the
> > focus of the original agenda and some, but not all, of the folks
> > going into the
> > meeting knew that there would be a proposal to change the focus of
> > the meeting.
> > Since that level of agenda bash is unusual, you can see that as
> > adding to a
> > concern about transparency.
> >
> > There is always concern that decisions made in situations like that
> > may be
> > influenced by partisans packing the room with folks who are not
> > typical
> > participants.  Whether that happened in this case or not, or on
> > which side,
> > is not really that important.  The reality is that our processes
> > have a way of
> > handling that, by making sure that the mailing list is always used
> > as the final
> > decision-making venue for the working group.  For less contentious
> > issues, that can
> > be a simple "Anyone disagree with the consensus of the room?".  I
> > believe
> > that for contentious issues, more care may be required to state
> > carefully
> > what the proposal is and how consensus will be determined.
> >
> > I don't think the chairs' proposal for how to move forward requires
> > more than
> > that, and I don't see any issues inside the WG with that as part of
> > the plan
> > on how to move forward.
> >
> >
> >> While it is certainly true that the Area Directors knew they
> >> wanted to use the agenda time in GEOPRIV to make progress on core
> >> issues, if necessary at the expense of existing agenda items,
> >> there was no concrete agenda to that effect privately circulated
> >> prior to the meeting, verbally or in writing, to our knowledge. In
> >> fact, the agenda was bashed at the start of the GEOPRIV meeting by
> >> a participant, albeit one whose counsel on making progress the
> >> Area Directors had sought prior to the meeting. Critically, that
> >> agenda bash was vetted by the room, as any other agenda bash would
> >> be - this was not a change made by fiat of the Area Directors. We
> >> strongly believe that there was a will in the room to prioritize
> >> and resolve the issues which were bashed onto the agenda. We
> >> furthermore took specific hums about the preparedness of the group
> >> to make decisions about these issues, which under the
> >> circumstances were required to proceed.
> >>
> >> <> Scheduling: There certainly were irregularities with the
> >> scheduling of the GEOPRIV meeting at IETF 68. That much said,
> >> scheduling the meeting track for the RAI Area is infamous, and
> >> last minute changes in timeslot are hardly unheard of (we had a
> >> similar one at the previous IETF). In this instance, the
> >> scheduling problem was ultimately caused by the unavailability of
> >> working group chairs. Two of the three GEOPRIV chairs, and one of
> >> the two SPEERMINT chairs, were unable to attend IETF 68 at all. It
> >> transpired that the SPEERMINT chair who could attend was unable to
> >> make the SPEERMINT timeslot due to a family obligation elsewhere
> >> in the world. As the GEOPRIV chairs note below, Henning
> >> Schulzrinne had previously been identified as a stand-in co-chair
> >> for GEOPRIV. We were thus left with the prospect of seeing
> >> SPEERMINT go forward with no available chairs, versus GEOPRIV
> >> going forward with at least one previously identified stand-in
> >> chair. We thus made a last minute decision to!
> >   find the lesser of two evils by swapping the timeslots of the
> > groups. This was a decision made at the last minute to find the
> > lesser of two evils. We certainly didn't anticipate all of the
> > ramifications this change would have in terms of attendance, and in
> > retrospect, we may not have made the most best choice. The choice
> > was not, however, motivated by a desire to prevent participants
> > from attending either meeting.
> >
> > Thanks for your clear description.  I'm sure that Andy didn't
> > anticipate his arm getting
> > broken prior to IETF 68, and we all recognize that these things
> > happen.  The concern
> > that might be raised would be that Henning is strongly identified
> > with one of the
> > proposals that was being considered in the revised agenda, and he
> > had never before
> > been part of calling consensus in a GEOPRIV meeting.  As has
> > already been noted,
> > Henning stepped away from that duty when his own topic was under
> > discussion.
> > Having been in the room, I can say that I did not see it as a
> > problem at the time.
> > I believe, though, that the chairs are telling us, at least in
> > part, how it appeared
> > to those who were not in the room.  I think the right thing to do
> > is acknowledge
> > that is a potential perception, and let it guide us in how we
> > implement the
> > consensus call on the mailing list.
> >
> >
> >> <> Consensus calls: There were indeed quite a few hums taken in
> >> the GEOPRIV room in Prague. In fact, the manner in which the
> >> meeting was run with regard to hums was not typical for this group
> >> - hums were used liberally to hone in on areas where there was,
> >> and was not, consensus. That much said, not all of the hums were
> >> consensus calls on working group issues; quite a few hums were
> >> also taken on how we should proceed, for example (taken from the
> >> minutes):
> >> - HUM : Are you informed enough to make this choice
> >> - HUM: Is it important to solve that today
> >> - HUM: Will the group accept a plurality for the decision?
> >>
> >> This last hum in particular represented an unusual step, as the
> >> GEOPRIV chairs note. It was a step recommended by the author of
> >> RFC3929 (a document on "alternative decision making processes for
> >> consensus-blocked decisions") when we asked him how we might
> >> proceed. We resorted to this step because the room felt (based on
> >> a previous hum) that it was important to walk away from the
> >> meeting with a resolution.
> >
> > I am the author of RFC 3929, and I did say that this was one way
> > forward.  This
> > is not, however, exactly what RFC 3929 says.  That sets out
> > preconditions
> > before alternative methods can be used:
> >
> > 3.1.  There is a clear decision to be reached
> >
> > 3.2.  Proposals are available in Draft form
> >
> > 3.3.  The working group has discussed the issue without reaching
> >       resolution
> >
> > 3.4.  There is an explicit working group last call to use an alternate
> >       method
> >
> > The hums in the room were not after an explicit working group last
> > call to use
> > an alternate method; they were after a hum in the room to use
> > plurality
> > rather consensus in order to make forward progress.  I believe that
> > the
> > method used is within the spirit of 3929; more importantly, though,
> > I think
> > they are well within what a working group can use to drive consensus.
> > All consensus requires compromise.  The call in the room could be
> > rephrased
> > as:  "Are you willing to compromise by adopting the other solution if
> > it is the majority preference?"  I think that was the spirit in
> > which it
> > was being asked, and I hope we can retain that spirit of compromise as
> > we ask for confirmation on the list.
> >
> >> To one particular point:
> >>> Cullen Jennings both called the consensus
> >>> and cast the last and tie-breaking vote in the room.
> >>>
> >>
> >> We feel it is important to clarify that Cullen Jennings did not
> >> call the consensus in the room. Rather, both Cullen and Ted Hardie
> >> were independently counting the tallies for the plurality in the
> >> room (two counters were used for redundancy, with the side effect
> >> that presumably we eliminated any chance of partiality); it was in
> >> fact Jon Peterson as chair who called the consensus, on the basis
> >> of those reported tallies. Furthermore, although Cullen Jennings
> >> did cast a vote when the count in the room was completed and
> >> discovered to result in a tie, this was not the tie-breaking vote
> >> for the purposes of determining consensus.
> >
> > I note that I did not vote in any of the questions where I was
> > tallying the answers.  In
> > the case where a tie was produced in the room I did say "Oh sh*t"
> > loudly enough
> > to elicit some nearby laughter, and it was after that that Cullen
> > raised his hand.
> > Having seen his face, I can thoroughly believe that it was
> > frustration at the level
> > of deadlock, and I was happy that counting the jabber room
> > participants' positions
> > resolved the question such that we could remove his vote from the
> > tally.
> >
> >> In fact, votes from the Jabber room determined the plurality, and
> >> the resulting tally did not favor the option for which Cullen had
> >> voted. To the charge that
> >>
> >>> one of the hums was called on a question not described
> >>> in an existing Internet-Draft.
> >>>
> >>
> >> That can be said of all of the process listed hums above. We
> >> aren't aware that process constrains us to make hums solely
> >> related to questions within existing Internet-Drafts.
> >
> > I personally, don't think they do.  But the number of hums, the
> > fact that we were
> > working from audible (rather than written) questions, and the pace
> > of the meeting
> > all contribute to the issue of whether everyone understood the full
> > impact
> > of all the questions being asked (especially those folks
> > contributing remotely,
> > since this is always a difficult task).  This doesn't mean anything
> > was done with
> > ill-intent; it just highlights the need to follow up with well-
> > worded consensus calls
> > on the mailing list.
> >
> > As I said before, I am personally happy with the outcome of the
> > calls, as they
> > move us forward; I would have been equally happy, in many cases,
> > with the
> > other choices, as they would do the same.  But I was at the meeting
> > and could
> > get a sense of the room.  If the combination of unusual features
> > related to
> > the meeting has raised questions in the community, then I believe
> > the chairs
> > are right to respond to them and to ensure that we all recognize to be
> > careful in our followup.  That's not about blame, or an
> > allegation.  I's a
> > practical statement of what it will take to keep all of the
> > participants
> > committed to finishing the work.
> >
> > I hope the chairs and ADs can come to a rapid and amicable
> > agreement on
> > that, and that we can all move forward quickly.
> >                       regards,
> >                               Ted
> >
> >
> >
> >
> >> Cullen Jennings
> >> Jon Peterson
> >> RAI Area Directors
> >>
> >>
> >>
> >> On Apr 17, 2007, at 8:06 PM, Randall Gellens wrote:
> >>
> >>> All,
> >>>
> >>> We, the co-chairs of the GEOPRIV working group, have received
> >>> private
> >>> messages of concern regarding the GEOPRIV meeting held at IETF 68
> >>> and
> >>> the outcome of that meeting.  Upon initial investigation, we believe
> >>> there were irregularities with the scheduling and agenda of the
> >>> meeting that rise above the normal course of business within the
> >>> IETF.  It is our opinion that at this time, it is best to bring
> >>> notice of these irregularities to the working group in the interest
> >>> of transparency and for the integrity of the IETF.
> >>>
> >>>
> >>> AGENDA CHANGE
> >>>
> >>> The IETF process allows for agenda changes during meetings.  At the
> >>> outset of the meeting, the agenda was changed substantially from the
> >>> published agenda.  This change included removing the discussion of
> >>> location signing and integrity and replacing it with an L7-LCP
> >>> protocol consensus call.  However, evidence has arisen that the
> >>> the Area Directors, Cullen Jennings and Jon Peterson, met
> >>> privately with
> >>> some participants of the GEOPRIV working group to inform them
> >>> of this agenda change.  Cullen Jennings is the Area Advisor to
> >>> GEOPRIV.
> >>>
> >>> If such meetings did occur, we believe them to be improper and to
> >>> have potentially harmed the integrity and transparency of GEOPRIV
> >>> and
> >>> the IETF.  It is not proper for officiates of a working group to
> >>> plan
> >>> working group agenda changes and privately inform only select group
> >>> participants.  Doing so disadvantages participants of the working
> >>> group who have not been advised of this change.  This is especially
> >>> true for this particular meeting as the agenda change
> >>> precipitated 15
> >>> hums during the meeting.
> >>>
> >>>
> >>> SCHEDULE CHANGE
> >>>
> >>> As noted ahead of time, two of the three co-chairs, Andy and
> >>> Allison,
> >>> were unable to attend IETF 68.  The working group co-chairs planned
> >>> for this in advance by finding a substitute acting chair, Henning
> >>> Schulzrinne, to aid the one co-chair, Randy, who was able to
> >>> attend.  This change was publicly announced on the mailing list
> >>> before IETF 68.  However, the RAI Area Directors announced a last
> >>> minute (Sunday) schedule change which created an unresolvable
> >>> conflict
> >>> for Randy.  The Area Directors executed this schedule change over
> >>> the
> >>> objections of the GEOPRIV co-chairs and in full knowledge of the
> >>> conflict it created.  Additionally, the reason given was so that a
> >>> working group co-chair for another working group could attend his
> >>> meeting.
> >>>
> >>> As a result of the schedule change, the meeting was co-chaired by
> >>> Jon
> >>> Peterson, the other RAI Area Director.  Consequent to the agenda
> >>> change regarding L7-LCP, Henning recused himself during the latter
> >>> half the meeting, leaving Jon Peterson to solely run the meeting.
> >>> During the meeting, a few participants expressed concerns regarding
> >>> the agenda and schedule changes.  These concerns were dismissed
> >>> by Jon.
> >>>
> >>>
> >>> CONSENSUS CALLS
> >>>
> >>> As noted above, the meeting resulted in an unusually high (15)
> >>> number
> >>> of consensus calls for GEOPRIV.  This includes the unusual
> >>> decision to
> >>> use an alternate consensus method of a plurality vote to choose
> >>> between
> >>> two protocol proposals.  As noted in the raw minutes and the
> >>> audio recording of the meeting, for the call that used the
> >>> plurality voting method, Cullen Jennings both called the consensus
> >>> and cast the last and tie-breaking vote in the room.  It should also
> >>> be noted that one of the hums was called on a question not described
> >>> in an existing Internet-Draft.
> >>>
> >>> The schedule change, the agenda change made known to a few select
> >>> participants in advance, and the unusual sense-of-the-room hums,
> >>> together
> >>> create at least the appearance that there may have been an
> >>> attempt to
> >>> manipulate the IETF process to hold and predetermine the outcome of
> >>> consensus calls.  Even the appearance of such manipulation,
> >>> regardless of
> >>> how well-intentioned the actions may have been, threatens the
> >>> integrity
> >>> and openness of the IETF.
> >>>
> >>> The IETF relies on not just open, fare processes, but also
> >>> transparency that good procedures are followed.  The irregularities
> >>> are now on the record of the group, hopefully never to be repeated.
> >>>
> >>> In order to follow IETF process, all resolutions put forward during
> >>> a working group meeting must be ratified on the working group's
> >>> mailing list.  The chairs will shortly be sending messages to
> >>> formally
> >>> initiate consensus calls on the sense-of-the-room hums that were
> >>> taken
> >>> in Prague.  Since so many hums were put forth during the IETF 68
> >>> meeting, we plan to send multiple messages to the working group
> >>> mailing list seeking ratification of the proposals.
> >>>
> >>> Because of what happened in Prague, the chairs want to make very
> >>> sure that the subsequent consensus calls are very open and
> >>> non-coercive. We ask all working group participants to please pay
> >>> close attention to these calls and respond appropriately.
> >>>
> >>> The first of these messages will be sent shortly.
> >>>
> >>> Sincerely,
> >>>
> >>> The geopriv co-chairs:
> >>>     - Andy
> >>>     - Allison
> >>>     - Randy
> >>>
> >>>
> >>> _______________________________________________
> >>> Geopriv mailing list
> >>> [email protected]
> >>> https://www1.ietf.org/mailman/listinfo/geopriv
> >>
> >> _______________________________________________
> >> Ietf mailing list
> >> [email protected]
> >> https://www1.ietf.org/mailman/listinfo/ietf
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/geopriv
>
>_______________________________________________
>Geopriv mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/geopriv
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]
>
>
>_______________________________________________
>Geopriv mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Ietf mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf