Re: [Geopriv] Irregularity at the GEOPRIV Meeting at IETF 68

[Bernard Aboba]

In reading the messages posted to the list relating to the GEOPRIV WG 
meeting at IETF 68, it strikes me that we have a situation in which
a deadlock was allowed to persist for much too long. 

Whether "standard" or "alternative" mechanisms of consensus determination
can resolve this situation seems almost besides the point -- a huge amount
of energy and time has already been wasted. 

Looking backwards, many of the IETF's most heated battles did in fact
resolve themselves in clear outcomes, but only years afterwards once
it become clear that one or more of the proposed approaches had little
or no support in the marketplace.  For example, recall the 
LDP vs. RSVP-TE debate. 

Given this, I would suggest that debating whether the IESG did the
right or wrong thing at IETF 68 is somewhat besides the point. 

Instead, I would like to ask whether we are furthering
the interest of the Internet community by allowing deadlocks to
persist for long periods, rather than quickly recognizing them and
defusing the situation by publishing the competing
approaches, allowing the market to decide which one is "best".

Cullen Jennings said:

"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."

Ted Hardie said:

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.

John Schnizlein said:

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.

Martin Dawson said:

The conspiracy theory is quite simply wrong. 

James Polk said:

energy and misrepresentation doesn't make things right either

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

[Brian Rosen]

In the example you gave the Hilton is EXACTLY the network that MUST give you
your location, and Verisign, if they tried, would give a valid, but very
wrong location.

That is the point of using DHCP for location, you need the closest possible
server to get the right location.  You need a server that understands the L2
to which you are connected.  Anything L3 and farther has a big problem of
where, exactly, are you?  The proposals for L7 versions of location
configuration protocols suffer mightily from the problem of figuring out
where you are in the L2.  They have to go to great lengths to determine some
kind of identifier that they can unambiguously use to figure that out.  I
think we have (painfully) figured out a way though that morass that will
work in enough circumstances to be interesting, but it remains hard, very
hard, to identify the L2 when your server is sitting at L7.

So, make sure that when you go to the Hilton that you use it's location
server, or you may have a big problem if you have to make an emergency call
(or even order a pizza).

DHCP is an excellent choice for a location server for networks where the
DHCP infrastructure is present, and can reasonably be upgraded.  The L7 guys
point out, correctly, that that's a tall order in a lot of interesting
networks.  I think that is right.  I do think they believe L7 works on every
network.  I'm certain it doesn't.  

That's why the compromise of BOTH is probably required.  I know it's the
only way we are going to get anything done in the next year.

Brian

> -Original Message-
> From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 19, 2007 6:39 PM
> To: James M. Polk; Dawson, Martin; John Schnizlein; Andrew Newton
> Cc: GEOPRIV WG; ietf@ietf.org; Allison Mankin
> Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
> 
> DHCP is a layer 3 technology that talks directly to layer 2.
> 
> This is entirely acceptable, useful and right for NETWORK configuration.
> DHCP is an entirely sensible means of obtaining an IP address and
> _proposals_ for domain name prefixes and DNS servers.
> 
> DHCP should not be used for any other purpose. In particular to make use
> of DHCP for application configuration is a layer violation. Layer 7 should
> NEVER communicate with Layer 2 directly. When that happens we lose all the
> power and flexibility built into the IP stack.
> 
> 
> To give a concrete example of the problems caused. I am currently typing
> on a VeriSign machine in an office in VeriSign corporate HQ. In that
> environment the local DHCP server could provide me with useful and valid
> suggestions for all manner of services. But its still the wrong
> technology.
> 
> The problem is that when I take the machine to the Hilton Garden Inn down
> the road where I am staying I explicitly DO NOT want the hotel network to
> provide any more than an IP address. I am not going to use their DNS
> server and I certainly don't want to make use of any email server, DNS
> prefix, GEOPRV or any other application layer feature they might want to
> foist onto me.
> 
> I am using the Hilton Garden Inn LAN, I am not joining their network. The
> machine is remaining on the VeriSign network.
> 
> 
> DHCP is a fine technology for the task DHCP is designed to do. It is an
> inappropriate technology for application or service configuration. The
> proper infrastructure to support those needs is DNS, supplemented if
> necessary by HTTP or LDAP backing store (i.e. either discover the services
> via DNS directly or use DNS to discover where the directory service is to
> be found).
> 
> Looking at the history of UPnP and Zero Config it strikes me that
> attempting to manage networks through peer to peer broadcast or multicast
> have been a bust precisely because of this layer violation.
> 
> 
> > -Original Message-
> > From: James M. Polk [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, April 19, 2007 5:31 PM
> > To: Dawson, Martin; John Schnizlein; Andrew Newton
> > Cc: GEOPRIV WG; ietf@ietf.org; Allison Mankin
> > Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68
> > Working Group Hums
> >
> > At 04:20 PM 4/19/2007, Dawson, Martin wrote:
> > >"DHCP is not adequate because it doesn't meet multiple sets of
> > >requirements as documented multiple times ..."
> >
> > bologna
> >
> > "documented multiple times" means in individual submissions
> >
> > of which, zero facts were presented to substantiate
> >
> > If DHCP were so inadequate, why is the DSL forum now going to
> > specify it? Why does PacketCable define it?  These were
> > fairly recent moves...
> >
> > And, how many times has HELD been presented as if it were a
> > product of an IETF WG?
> >
> > James
> >
> >
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> >
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.or

Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

[David W. Hankins]

On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote:
> DHCP is a layer 3 technology that talks directly to layer 2.

DHCP is a technology that dynamically configures hosts.

If a host has a configuration knob that might reasonably and
properly be set by the systems administrator or the network you
are presently attached to, then it is reasonable and proper to
configure it via DHCP.

DHCP would be the wrong tool to configure how, in what frequency,
or in what manner an application would directly contact a specific
remotely administered service, such as a distant web server.  DNS
would be the correct tool for that sort of job, having as it does
a global reach, and fate sharing.


If GEOPRIV is truthfully a global service the client communicates
with directly without the local network operator's involvement,
then I think it should be configured by whatever global distribution
means is reasonable.

My impression is that GEOPRIV is a service that is provided by
the local network to which the client is attached, and as such
under the purview of that network's operator and DHCP, but I admit
to not following it very closely.

-- 
David W. Hankins"If you don't do it right the first time,
Software Engineer   you'll just have to do it again."
Internet Systems Consortium, Inc.   -- Jack T. Hankins


pgpUBecRJKYQm.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

[Hallam-Baker, Phillip]

DHCP is a layer 3 technology that talks directly to layer 2.

This is entirely acceptable, useful and right for NETWORK configuration. DHCP 
is an entirely sensible means of obtaining an IP address and _proposals_ for 
domain name prefixes and DNS servers.

DHCP should not be used for any other purpose. In particular to make use of 
DHCP for application configuration is a layer violation. Layer 7 should NEVER 
communicate with Layer 2 directly. When that happens we lose all the power and 
flexibility built into the IP stack. 


To give a concrete example of the problems caused. I am currently typing on a 
VeriSign machine in an office in VeriSign corporate HQ. In that environment the 
local DHCP server could provide me with useful and valid suggestions for all 
manner of services. But its still the wrong technology.

The problem is that when I take the machine to the Hilton Garden Inn down the 
road where I am staying I explicitly DO NOT want the hotel network to provide 
any more than an IP address. I am not going to use their DNS server and I 
certainly don't want to make use of any email server, DNS prefix, GEOPRV or any 
other application layer feature they might want to foist onto me. 

I am using the Hilton Garden Inn LAN, I am not joining their network. The 
machine is remaining on the VeriSign network.


DHCP is a fine technology for the task DHCP is designed to do. It is an 
inappropriate technology for application or service configuration. The proper 
infrastructure to support those needs is DNS, supplemented if necessary by HTTP 
or LDAP backing store (i.e. either discover the services via DNS directly or 
use DNS to discover where the directory service is to be found).

Looking at the history of UPnP and Zero Config it strikes me that attempting to 
manage networks through peer to peer broadcast or multicast have been a bust 
precisely because of this layer violation.


> -Original Message-
> From: James M. Polk [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 19, 2007 5:31 PM
> To: Dawson, Martin; John Schnizlein; Andrew Newton
> Cc: GEOPRIV WG; ietf@ietf.org; Allison Mankin
> Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 
> Working Group Hums
> 
> At 04:20 PM 4/19/2007, Dawson, Martin wrote:
> >"DHCP is not adequate because it doesn't meet multiple sets of 
> >requirements as documented multiple times ..."
> 
> bologna
> 
> "documented multiple times" means in individual submissions
> 
> of which, zero facts were presented to substantiate
> 
> If DHCP were so inadequate, why is the DSL forum now going to 
> specify it? Why does PacketCable define it?  These were 
> fairly recent moves...
> 
> And, how many times has HELD been presented as if it were a 
> product of an IETF WG?
> 
> James
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

[James M. Polk]

Martin

Exactly what products support HELD right now?

If you want location verification and location signing - are these 
deployed today?


Doesn't all these mean something has to be changed or upgraded?

Broadband providers in the US have given away FREE home routers to 
enable a service as recently as a year ago.  So, taking the stance 
that this won't happen is looking facts to the contrary in the eye 
and saying "that didn't happen" *or* "that's not going to happen"


At 04:34 PM 4/19/2007, Dawson, Martin wrote:

Does DHCP require a change to the residential CPE James? How long is it
going to take to change every residential router in the world? Do you
think it is an unreasonable requirement to not have to do this?

You can't just object to HELD on the basis that you think it's been
misrepresented. I don't accept that it has - but in any case, it's not a
technical rationale.

Cheers,
Martin



-Original Message-
From: James M. Polk [mailto:[EMAIL PROTECTED]
Sent: Friday, 20 April 2007 7:31 AM
To: Dawson, Martin; John Schnizlein; Andrew Newton
Cc: GEOPRIV WG; Allison Mankin; ietf@ietf.org
Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
Hums

At 04:20 PM 4/19/2007, Dawson, Martin wrote:
>"DHCP is not adequate because it doesn't meet multiple sets of
>requirements as documented multiple times ..."

bologna

"documented multiple times" means in individual submissions

of which, zero facts were presented to substantiate

If DHCP were so inadequate, why is the DSL forum now going to specify
it? Why does PacketCable define it?  These were fairly recent moves...

And, how many times has HELD been presented as if it were a product
of an IETF WG?

James



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]


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[James M. Polk]

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; ietf@ietf.org
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; 

RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

[James M. Polk]

At 04:20 PM 4/19/2007, Dawson, Martin wrote:
"DHCP is not adequate because it doesn't meet multiple sets of 
requirements as documented multiple times ..."


bologna

"documented multiple times" means in individual submissions

of which, zero facts were presented to substantiate

If DHCP were so inadequate, why is the DSL forum now going to specify 
it? Why does PacketCable define it?  These were fairly recent moves...


And, how many times has HELD been presented as if it were a product 
of an IETF WG?


James


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[John Schnizlein]

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 impr

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

[Otmar Lendl]

Some comments from me regarding this issue:

First of all, as Ted mentioned, we have to note whether the chairs
themselves complain about the Prague session or whether they 
are just responding to complaint voiced to them in private mails.

As I read the mails, it's the latter which begs the question
why the complains haven't simply been sent to the list in the
first place. 

Anyway,

On 2007/04/18 22:04, Cullen Jennings <[EMAIL PROTECTED]> wrote:
> 
> 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. 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.

Anybody reading the geopriv list already knew that a number of people
(me included) were pushing for a resolution of the HELD vs. RELO
question. So I'm a bit at loss how one can surprised that this
issue featured prominently during the meeting.

> <> Scheduling: 

I've no comment on the scheduling.

> <> 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?

Coming to Prague I was not optimistic that the WG can make progress
on the L7LCP issue. I was positively surprised by the steps the ADs took
in order to reach a decision.

>From my point of view, the ADs did exactly what they are supposed to
do: Listen to their constituency, learn about their needs and guide the
WGs towards progress. In this case the need was for a decision on the
single L7LCP standard.

As I remember the HUMs, this need was not at all in doubt. Everybody
agreed that we should resolve this question in this session.

I did not sense any preference from the ADs for one of the proposals,
only the clear desire to reach a resolution. The sequence of HUMs were
cleverly designed to lead the group towards *a* solution, whatever that
may be.

> >Cullen Jennings both called the consensus
> >and cast the last and tie-breaking vote in the room.

I can confirm Ted's account: Cullen just wanted to break the deadlock in
the room (what other options did he have at that point? Toss a coin?).
The Jabber count did swing the count in the other direction, so his vote
was irrelevant.

My summary is thus:

* I was positively impressed by the way the ADs handled a tricky situation.

* The WG got what it really needed and unanimously wanted: A resolution 
  of the L7LCP question.

  All those HUMs leading up to the final question were unopposed, I see
  thus no need to revisit them here on the mailinglist.

* The question the chairs should IMHO put to the list is simple:

  "Do we need to reopen the HELD vs. RELO decision?"

  If there are a number of clear statements that we need to, then we can
  go once again and try whatever RFC 3929 offers.

  Personally, I don't think the WG's aims are served by another 
  round of voting. This time and energy is better spent on
  reviews and updates to HELD. 

/ol
-- 
/ Otmar Lendl <[EMAIL PROTECTED]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Spencer Dawkins]

Hi, John,

Not-an-AD would be better than an-AD, but an-AD would be better than wasting 
the WG's time.


I agree with your point, I agree with not making a hard-and-fast rule, and I 
agree that the expectation is that an-AD chairing a WG meeting would recuse 
self from subsequent IESG discussions.


Thanks,

Spencer

From: "John C Klensin" <[EMAIL PROTECTED]>




Spencer,

I want to express slight disagreement on one of your points (the
others are clearly, at least to me, on-target)...

--On Thursday, 19 April, 2007 08:03 -0500 Spencer Dawkins
<[EMAIL PROTECTED]> wrote:


...
- We have been encouraging greater separation of roles (an
extreme case of non-separated roles is a document editor who
is also the working group chair, the document shepherd, and
the responsible AD for the working group). We've been saying
that having ADs chair WGs in their own area is not a good
thing. We've been saying that having WG chairs edit major
documents in their own area is not a good thing. We may want
to provide guidance that having ADs chair WG meetings in their
own area, especially where there is no other person acting as
chair, is not a good thing, and that the ADs really need to
find someone else who is willing to chair the meeting, and who
is not involved as the next step on the appeals ladder.


If a WG is in trouble -- not in terms of the peculiarities of a
particular meeting, but more generally -- and especially if it
is showing signs of long-term deadlock or paralysis about
particular issues, and the usual chair(s) are not available,
then my first preference would be to have someone in the chair
who has a good knowledge of the issues and a responsibility both
for balance about particular issues and, as you point out, for
balancing fairness and progress.  In many cases, that finger is
going to point to the relevant AD(s).  I'd hate to make a rule
that would prevent their sitting in the chair for a particular
meeting if, in their judgment, that was the best way to
facilitate both fairness and progress.If they had to recuse
themselves from later IESG decision-making discussions on the
subject, I think that is a reasonable price to pay: if the WG
doesn't manage to reach conclusions, the IESG won't have the
chance to examine the relevant documents.


...
In summary - not a good situation, but one that is being
handled correctly at this point. Let's let the WG chairs, and
the ADs, do their jobs and see where we end up.


   indeed.
john







___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Meeting Survey

[John C Klensin]

--On Thursday, 19 April, 2007 07:25 -0400 Dave Crocker
<[EMAIL PROTECTED]> wrote:

> Whether a break period should or should not include food might
> be a reasonable question, given the limited time to forage for
> food elsewhere.
> 
> But what is the reason for presuming that the IETF has an
> obligation to feed us meals?  Why breakfast, but no other
> meal?  Why any?

I have to agree with Dave.  Recognizing that the questions
weren't included in the survey,

(1) I think it is an open question as to whether the IETF should
be feeding us any meals, including breakfast, especially if
doing so increases either the hotel room costs or the
registration fees.  The observation that the combination of
other commitments and personal habits result in many of us
missing some or all of those "included" meals reinforces that
view.  Of course, if the negotiation with the hotel is such that
the IAD and secretariat have a choice between "supply at least
one meal each day" and "pay for the meeting rooms at
significantly higher net cost", that becomes a different
question... and I don't believe the community needs to get
involved in a discussion of how that particular sausage is made.

(2) In cities where hotels routinely offer "with breakfast" and
"without breakfast" rates, I would hope that the IAD and
Secretariat would negotiate for the lowest room rates possible,
without breakfast if that is less expensive than the "with
breakfast" rate.   In a perfect world, they could negotiate for
a "breakfast supplement" to the "no breakfast" rate, but the
goal should be lowest possible participant cost.

  john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[John C Klensin]

Spencer,

I want to express slight disagreement on one of your points (the
others are clearly, at least to me, on-target)...

--On Thursday, 19 April, 2007 08:03 -0500 Spencer Dawkins
<[EMAIL PROTECTED]> wrote:

>...
> - We have been encouraging greater separation of roles (an
> extreme case of non-separated roles is a document editor who
> is also the working group chair, the document shepherd, and
> the responsible AD for the working group). We've been saying
> that having ADs chair WGs in their own area is not a good
> thing. We've been saying that having WG chairs edit major
> documents in their own area is not a good thing. We may want
> to provide guidance that having ADs chair WG meetings in their
> own area, especially where there is no other person acting as
> chair, is not a good thing, and that the ADs really need to
> find someone else who is willing to chair the meeting, and who
> is not involved as the next step on the appeals ladder.

If a WG is in trouble -- not in terms of the peculiarities of a
particular meeting, but more generally -- and especially if it
is showing signs of long-term deadlock or paralysis about
particular issues, and the usual chair(s) are not available,
then my first preference would be to have someone in the chair
who has a good knowledge of the issues and a responsibility both
for balance about particular issues and, as you point out, for
balancing fairness and progress.  In many cases, that finger is
going to point to the relevant AD(s).  I'd hate to make a rule
that would prevent their sitting in the chair for a particular
meeting if, in their judgment, that was the best way to
facilitate both fairness and progress.If they had to recuse
themselves from later IESG decision-making discussions on the
subject, I think that is a reasonable price to pay: if the WG
doesn't manage to reach conclusions, the IESG won't have the
chance to examine the relevant documents.

>...
> In summary - not a good situation, but one that is being
> handled correctly at this point. Let's let the WG chairs, and
> the ADs, do their jobs and see where we end up.

indeed.
 john



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[John C Klensin]

--On Wednesday, 18 April, 2007 19:08 -0400 Sam Hartman
<[EMAIL PROTECTED]> wrote:

> 
> 
> Geopriv dropped because I'm asking a general question.
> 
> 
> >> AGENDA CHANGE
> >> 
> >> The IETF process allows for agenda changes during
> meetings.  At >> the outset of the meeting, the agenda was
>...
> I'm a bit concerned that I may regularly be doing something
> that the geopriv chairs feel is inappropriate.  I'd lik e to
> discuss with the wider community so I can change my practices
> if needed.
> 
> It's reasonably common that I will try to work with chairs and
> key participants in a working group to find ways to unstick a
> working group.  for example I may suggest to a chair that some
>...

Sam, 

It seems to me that the community has a choice between ADs who
set themselves up, or are set up by others, as all-knowing
authority figures and ADs who try to move WGs forward by talking
with people, mediating, negotiating, and generally exercising
leadership rather than authority.   I believe that the
community's preference for the latter is very clear, especially
from the number of criticisms that regularly crop up in response
to symptoms of the former.

>From the material that was posted, I have no way to deduce
whether this was handled optimally.  For example, under normal
circumstances, I would expect that at least some of the WG
Co-Chairs were aware that these other conversations were going
on, rather than being surprised by them.  But I can also see a
number of reasons why they would not be consulted, notably ones
in which the WG is seriously behind schedule and the ADs were
starting to wonder whether the existing WG leadership was being
effective.

As Cullen suggests, if there were clear indications that the ADs
were using their authority to force a particular outcome, that
should be dealt with by immediate recalls.   On the other hand,
if the one or more co-chairs and the ADs have lost confidence in
either other, or in the WG's ability to succeed, some
rearrangement of the WG --by termination, change of leadership
(whether by resignation or "firing"), or significant change of
charter-- would seem to be in order.  But that goes well beyond
the question I think you were asking.

john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Brian E Carpenter]

I want to make three peripheral comments.

1. I congratulate the ADs for bringing this to the general list.
If we habitually resolve such difficulties openly, we strengthen
the IETF going forward.

2. I think we have a general problem of assuming that issues
"decided" in the meeting room and "approved" on the mailing list
by lack of complaint at the draft minutes have in fact gained
rough consensus. I'm very glad that GEOPRIV isn't assuming
that, and IMHO all WGs should copy.

3. It's aggravating when meetings get rescheduled on site, but we've
been warning people for a couple of years that "IETF Meetings
start Monday morning and run through Friday lunchtime, with late
scheduling changes." Those last 4 words mean what they say, after all.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Spencer Dawkins]

I'm following up to Cullen's note, but I've read Sam's note, Joel's note, 
and Ted's note. I tried to keep my own note short, but really admire Joel's 
brevity...


(Disclaimer: I'm one of the EDU team members who worked on the WG Chairs/WG 
Leadership tutorial. If I'm seriously off-base in my note, it would be great 
if people told Russ Housley (General AD, responsible for EDU), and Margaret 
Wasserman/Avri Doria (EDU team co-leaders).


- most of the time, it's not like this.

- the WG chairs are correctly raising the concern, and are starting at the 
right place in the appeals ladder. If this turns into an appeal, the IESG 
asks that appeals be clearly identified as appeals, and that people who 
appeal decisions state clearly what the desired way forward is.


- the AD(s) are correctly bringing the concern to the broader community. I 
agree with Cullen that recall would be (a) correct response to consensus 
manipulation, and agree with Ted that recall should not be the first place 
we go. As Ted noted, we've never used the recall procedure. If we get all 
the way to considering recall, it really is OK to use the procedure - we're 
just not there.


- the WG chairs are taking the right actions to confirm (or deny) the 
sense-of-the-room calls made in Prague.


- what we tell the WG chairs, and WG draft editors, is that their job is 
balancing fairness and progress. If you aren't fair, you'll spend all your 
time in appeals, so you won't make any progress, and if you don't make 
progress, it doesn't matter how fairly you stall. This is not a new theory - 
it was in the WG chair training when Dave Crocker gave the training for the 
first time.


- It's probably not a stretch to expect the ADs to be working to achieve the 
same balance. I agree with Sam that AD intervention to try to "unstick" 
discussions is part of the job. I agree with the GeoPriv chairs that AD 
intervention to choose a "consensus" consensus is not.


- what we tell the WG chairs is that ADs have the power to make a decision 
for the working group, in order to break a deadlock. Jeff Schiller (one of 
the ADs who did the WG chair training for several years) was very clear that 
an AD can say, "if you guys don't make a decision by date X, I'll make a 
decision for you". If this is not part of the community understanding, 
someone should be telling the WG chairs and ADs what the community 
understanding is.


- our formal process is that WG meetings don't make decisions, WGs make 
decisions on mailing lists and try to make progress in face-to-face 
meetings. If the ADs said they were making consensus calls during the 
meeting, that would be bad. If the ADs said they were asking for the sense 
of the room in order to understand where a decent number of participants 
stand, and that "sense of the room" would be consensus-called on the mailing 
list, that would be OK, in our documented process. If we don't actually 
believe this, we need to change our formal process.


- For both GEOPRIV and SPEERMINT, the question is whether having no meeting 
in Prague would have been an improvement over having meetings that were 
re-scheduled/held with substitute chairs. My recent experience with 
substitute-chair meetings has not been positive. It would be good to 
understand the community consensus here ("how badly do you need to have a 
formal meeting slot, given that you're not making decisions anyway?").


- We have been encouraging greater separation of roles (an extreme case of 
non-separated roles is a document editor who is also the working group 
chair, the document shepherd, and the responsible AD for the working group). 
We've been saying that having ADs chair WGs in their own area is not a good 
thing. We've been saying that having WG chairs edit major documents in their 
own area is not a good thing. We may want to provide guidance that having 
ADs chair WG meetings in their own area, especially where there is no other 
person acting as chair, is not a good thing, and that the ADs really need to 
find someone else who is willing to chair the meeting, and who is not 
involved as the next step on the appeals ladder.


I note that Jon is (with Russ, according to 
http://www.ietf.org/iesg_mem.html) the most experienced AD serving on the 
IESG today. If he thought this was OK, and it's not, the community should 
let the IESG know. Clear feedback is good.


In summary - not a good situation, but one that is being handled correctly 
at this point. Let's let the WG chairs, and the ADs, do their jobs and see 
where we end up.


Thanks to everyone involved for working to resolve this.

Spencer 




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Meeting Survey

[Janet P Gunn]

Good question.
But that isn't how the survey question was phrased.

The question wasn't "should IETF provide breakfast (in general)?"

The question was "should IETF skip breakfast if the contract hotel 
provides it?", which seems to presume that IETF WILL continue to provide 
(continental) breakfast if it is not included in the room rate at the 
contract hotel.

Janet

Dave Crocker <[EMAIL PROTECTED]> wrote on 04/19/2007 07:25:33 AM:

> 
> 
> Janet P Gunn wrote:
> > But if it is ONLY the "contracted hotel" that provides breakfast,  and 

> > the other hotels do not, then I think that the meeting should provide 
at 
> > least SOME breakfast items.
> 
> Whether a break period should or should not include food might be a 
> reasonable question, given the limited time to forage for food 
elsewhere.
> 
> But what is the reason for presuming that the IETF has an obligation to 
> feed us meals?  Why breakfast, but no other meal?  Why any?
> 
> d/
> 
> -- 
> 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Meeting Survey

[Dave Crocker]

Janet P Gunn wrote:
But if it is ONLY the "contracted hotel" that provides breakfast,  and 
the other hotels do not, then I think that the meeting should provide at 
least SOME breakfast items.


Whether a break period should or should not include food might be a 
reasonable question, given the limited time to forage for food elsewhere.


But what is the reason for presuming that the IETF has an obligation to 
feed us meals?  Why breakfast, but no other meal?  Why any?


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Meeting Survey

[Janet P Gunn]

There was no place for comments on the "breakfast question".
I think an important criterion is not just whether the CONTRACTED HOTEL 
provides breakfast, but whether, in addition, the OTHER HOTELS IN THE AREA 
where IETF-ers are likely to stay, provide breakfast.

If we are in a city where MOST HOTELS include breakfast, then it is fine 
to not provide breakfast at the meeting.

But if it is ONLY the "contracted hotel" that provides breakfast,  and the 
other hotels do not, then I think that the meeting should provide at least 
SOME breakfast items.

Janet

Eric Rescorla <[EMAIL PROTECTED]> wrote on 04/18/2007 05:47:51 PM:

> 
> Ray,
> 
> Thanks for doing this survey.
> 
> Two of the questions (18 and 19) would be much easier to answer with a
> little extra information:
> 
> 18. When breakfast is included in the room rate for the contracted
> hotels breakfast is not provided at the meeting to be most cost
> effective. Do you agree with this practice?
> 
> 19. During the Monday and Tuesday afternoons there are two breaks. For
> budget reasons we provided only beverages and no snacks during the
> first break, approximately 2 hours after the lunch. Do you agree
> with this practice?
> 
> Could you maybe send out a mail with the rough approximate costs of
> these when we run the meetings in the US (as a baseline)?
> 
> Best,
> -Ekr
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns

[Simon Josefsson]

"Mark Brown" <[EMAIL PROTECTED]> writes:

>> However, if I understand the license correctly, it seems incompatible
>> with free software licenses.  The RedPhone license contains:
>> 
>>"1. General Use License"
>> 
>>"Upon request, RedPhone Security will provide a worldwide,
>>nonexclusive, fully-paid, perpetual, royalty-free patent license to
>>manufacturers who (a) implement the Protocol, (b) acknowledge this
>>general use license as described in Schedule B, and (c) refrain
>>from implementing any Protected Assurance System Functions defined
>>and listed below.  This general use license granted to
>>manufacturers also flows down to sublicensees and users, to permit
>>end users of these systems (including both client and server
>>components) to use the Protocol, provided those users do not use
>>the system as a Protected Assurance System (PAS) as defined in
>>Schedule A without obtaining an End User License."
>> 
>> There are two problems here:
>> 
>>  1) Requires that vendors 'request' the license.  It would be
>>  better if the license was given directly to third parties without
>>  any action required by the third parties.
>> 
>>  2) The restriction of field-of-use (i.e., cannot be used with
>>  PAS) is incompatible with free software norms: implementations
>>  must be usable for any purpose as long as the license is
>>  followed, and several free software licenses does not permit
>>  restrictions like this.
>
> Problem 1 seems solvable to me, but I'd like more input.  For 2, My goal is
> this exchange:
>
> Manufacturer: "We're requesting the General Use License from RedPhone
> Security.  In exchange, we promise not to implement (or on a per-release
> basis: we did not implement) the PAS Functions."  
>
> Each Manufacturer needs to take responsibility only for "his" own actions;
> any subsequent Manufacturer (alters the code in a way that may or may not be
> material to the PAS Functions) either voids the license or inherits it or
> requests their own license -- but that's not "your" problem.  
>
> A Manufacturer will develop code, test the functionality and release the
> software.  At each of these steps it should be pretty clear if the software
> being developed, tested and released violates the PAS Functions.  ..Doubly
> clear if the function of the software is to make use of X509 certificates
> which are marked with a "critical" policy that identifies RedPhone Security
> (a hard-coded OID ending in .23106 will likely show up in the software).
>
> I think a free software provider/clearinghouse could choose to not go beyond
> the RedPhone Security General Use License with no problem.  In the event
> that some third party contributor made a code contribution "back" to the
> provider that violated the PAS Functions, simply classify that
> code-contribution as "buggy" -- and choose to not roll that contribution up
> into any release.
>
> I can imagine a case where a user of free software chooses to start with
> free software and then obtain a PAS License from RPS and become
> Manufacturer2.  Then the score would be:  Manufacturer1: GUL, Manufacturer2:
> PASL, and both would remain true to their commitments -- no problems.  The
> only problem would be if Manufacturer2 contributed PAS Functions back to
> Manufacturer1 and then Manufacturer1 rolled those functions in (and tested
> and released them) under GUL.
>
> Back to question 1, I guess the question for me is, Who is making the
> promise to RedPhone Security?  How the promise is communicated is not the
> main issue.  If the preferred OpenSSL approach is to put a legal stuff into
> comments atop source files which are published for anyone to see, that may
> be more effective than sending one postcard.
>
> This may also help (somewhat) the "on installation" question.  If one
> Manufacturer only releases (presumably tested) source code, then "on
> installation" for source code could simply be comments atop the source code
> file.  What I want to accomplish is fair warning to downstream users /
> Manufacturers, so that we can help users steer clear of accidental GUL
> violations. 
>
> In summary, for (1) I'd like more input.  RPS "will provide" a GUL upon
> request, by snail mail or electronically.  The question I have is how an
> open source provider might prefer to make that request with its associated
> promise about PAS Functions -- once and for all, or from time to time, etc.
> This question could be sorted out on a per-license basis, but I think
> consistency would be preferable.
>
> For (2) I'd like each Manufacturer/User to stand on his or her own two feet.
> If "you" made or used the PAS Functions, "you" need a license.  Otherwise,
> say "you" didn't under the GUL.  No Manufacturer under the GUL should be
> responsible for implementations of PAS Functions that they did not develop,
> test and/or release.

Hi Mark!  I believe I understand what you are trying to achieve