Re: 6tsch BoF

[joel jaeggli]

On 8/1/13 6:25 PM, Melinda Shore wrote:
> On 8/1/13 1:29 AM, joel jaeggli wrote:
>> Consensus for any particular outcome is in the end a judgment call.
> Well, yes and no, but this situation strikes me as odd, and probably
> a mistake on the part of the chairs.  If you can't tell whether or
> not you've got consensus, you don't have consensus.
Yes agree The distinction of none or any variant of something else is a
judgement call.
>   It sounds like
> they were treating the hum as a vote in the first place (which we
> do entirely too often).
I see nothing wrong with taking the temperature of the room.  further
exposition on the mailing list might be a discriminator that would be
easier to identify the positions and what action should therefore occur.
>
> Melinda
>

Re: Bringing back Internet transparency

[Marc Petit-Huguenin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/02/2013 08:28 AM, Keith Moore wrote:
> 
> On Aug 1, 2013, at 9:14 PM, Noel Chiappa wrote:
> 
>>> From: Phillip Hallam-Baker 
>> 
>>> The ISPs had a clear interest in killing of NAT which threatened the 
>>> ISP business model.
>> 
>> So this is rather amusing: you're trying to tell me that ISPs wanted to
>> kill NAT, and I have other people telling me NAT was an intergral part of
>> ISPs' master plan to take over the universe.
>> 
>> Clearly you all both can't be right.
> 
> ISPs were against NATs at first.   It was only later that they embraced
> them.
> 

This mess is still the ISP fault.  If they gave users what they wanted, which
is multiple IP addresses, then they wouldn't have to install NAT (I am still
paying $9.95 per month for the privilege of having 4 additional IPv4 addresses
on my Comcast connection).  And that would have accelerated IPv6 deployment.

The firewall issue is orthogonal (which I put the blame on Microsoft sloppy
coding practices).

- -- 
Marc Petit-Huguenin
Email: m...@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBCAAGBQJR+1a7AAoJECnERZXWan7EK7MQAOTwF/oZp5nPSbygmgivYCCD
W+TYtQhtikwMJHn1VriikxQlsKaDM/GtJuG9/Zwe7zj7rdu4Z7QkHQolD3CMhOPM
d74rRnqTrFOxedyLoknly/xCkb/4cpb0q7zX06nRsrm6ufy84i6UWVX+HONcEkh1
/9rF1/6gNWlKIiEHjT9fmiOrdVU0D4I/sQaeGHrI4wCdIdr8PXVADPQ1mAQJlxVT
FW4P5KfXRz7pBQ+vcmuHEn+3spf64ClP5fBD6DsEuujjU6P5mxaaTgKZqy9YXhHb
9buSk7xJINLN9oG2GAYKPw/WGLlVo/AzaOmQoRIP63+bFmFZ4JAIS/ikWvdWdI5A
NJuxGML0Pp4sNAwtAOY5kAQsBwEdrJMDtUHNtSHCOarog/IpbPP9BKjgzF1owA+N
AzEh08YqiE+f67hXE4cYrnXcF87BzcBeP3NXsuRF3jh2uAY4DGuTVLvLgG4Z1tfI
aKXBQVekn3gdEFN4sMEjfEMih0gpS1mDqPm3ccVBQvD6WcWyZcFNwIiJGJfysBV3
EmAQC8W4hpSKQ7uzVhbpBb7M+puFJg7iIt6BprX60KoLXGx7HklsecdQXk6gYQA5
Pdr42nNiLZPwd3ehI8PR+K2qirXJUkKKBIn78rVt7UeuxEj+oN+GOQQSst3h2j4e
qYDN6/Qx+xUcAy1Y7D8m
=s1v7
-END PGP SIGNATURE-

Re: Bringing back Internet transparency

[Keith Moore]

On Aug 1, 2013, at 9:14 PM, Noel Chiappa wrote:

>> From: Phillip Hallam-Baker 
> 
>> The ISPs had a clear interest in killing of NAT which threatened the
>> ISP business model.
> 
> So this is rather amusing: you're trying to tell me that ISPs wanted to kill
> NAT, and I have other people telling me NAT was an intergral part of ISPs'
> master plan to take over the universe.
> 
> Clearly you all both can't be right.

ISPs were against NATs at first.   It was only later that they embraced them.

Keith

Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 222 messages in the last 7 days.
 
script run at: Fri Aug  2 00:53:02 EDT 2013
 
Messages   |  Bytes| Who
+--++--+
  4.95% |   11 |  7.45% |   129461 | abdussalambar...@gmail.com
  5.41% |   12 |  6.26% |   108812 | mo...@network-heretics.com
  4.95% |   11 |  4.51% |78362 | s...@resistor.net
  4.50% |   10 |  4.72% |82029 | brian.e.carpen...@gmail.com
  3.60% |8 |  5.15% |89569 | hal...@gmail.com
  4.05% |9 |  3.58% |62145 | john-i...@jck.com
  4.05% |9 |  3.54% |61529 | arturo.ser...@gmail.com
  4.05% |9 |  3.39% |58959 | melinda.sh...@gmail.com
  3.60% |8 |  2.83% |49207 | jari.ar...@piuha.net
  1.80% |4 |  3.79% |65923 | leaf.yeh@gmail.com
  3.15% |7 |  2.10% |36449 | j...@mercury.lcs.mit.edu
  2.70% |6 |  2.50% |43444 | y...@checkpoint.com
  2.70% |6 |  2.05% |35661 | stpe...@stpeter.im
  2.25% |5 |  2.01% |34917 | d...@dcrocker.net
  2.25% |5 |  1.87% |32418 | barryle...@computer.org
  1.80% |4 |  2.25% |39049 | t...@ecs.soton.ac.uk
  1.35% |3 |  2.36% |41081 | sprom...@unina.it
  1.80% |4 |  1.87% |32564 | a...@yumaworks.com
  1.80% |4 |  1.65% |28732 | ted.le...@nominum.com
  1.80% |4 |  1.50% |26028 | mcr+i...@sandelman.ca
  1.80% |4 |  1.45% |25184 | aaron.d...@cl.cam.ac.uk
  1.35% |3 |  1.38% |24049 | ch...@ietf.org
  1.35% |3 |  1.34% |23348 | rdroms.i...@gmail.com
  1.35% |3 |  1.16% |20126 | roland.bl...@kit.edu
  1.35% |3 |  1.15% |19939 | kathleen.moria...@emc.com
  1.35% |3 |  1.12% |19406 | joe...@bogus.com
  1.35% |3 |  1.09% |19009 | hartmans-i...@mit.edu
  1.35% |3 |  0.96% |16709 | to...@isi.edu
  0.90% |2 |  0.99% |17194 | d3e...@gmail.com
  0.90% |2 |  0.93% |16233 | petit...@acm.org
  0.90% |2 |  0.85% |14812 | amor...@amsl.com
  0.90% |2 |  0.82% |14280 | jcur...@istaff.org
  0.90% |2 |  0.80% |13957 | yd...@cs.helsinki.fi
  0.90% |2 |  0.77% |13418 | da...@tcb.net
  0.90% |2 |  0.71% |12262 | josh.howl...@ja.net
  0.90% |2 |  0.66% |11396 | scott.b...@gmail.com
  0.90% |2 |  0.64% |11075 | ned+i...@mauve.mrochek.com
  0.90% |2 |  0.59% |10336 | ra...@psg.com
  0.90% |2 |  0.56% | 9647 | i...@meetecho.com
  0.45% |1 |  0.93% |16123 | nkuk...@verilan.com
  0.45% |1 |  0.85% |14714 | jsalo...@cisco.com
  0.45% |1 |  0.81% |14144 | andrewm...@google.com
  0.45% |1 |  0.66% |11498 | amanda.ba...@icann.org
  0.45% |1 |  0.62% |10744 | mary.h.bar...@gmail.com
  0.45% |1 |  0.59% |10318 | daedu...@btconnect.com
  0.45% |1 |  0.55% | 9616 | d...@cridland.net
  0.45% |1 |  0.54% | 9392 | david.bl...@emc.com
  0.45% |1 |  0.50% | 8729 | a...@anvilwalrusden.com
  0.45% |1 |  0.50% | 8686 | nar...@us.ibm.com
  0.45% |1 |  0.47% | 8238 | ted.i...@gmail.com
  0.45% |1 |  0.46% | 7965 | br...@innovationslab.net
  0.45% |1 |  0.46% | 7918 | kvi...@broadcom.com
  0.45% |1 |  0.45% | 7905 | simon.lei...@switch.ch
  0.45% |1 |  0.45% | 7825 | flu...@cisco.com
  0.45% |1 |  0.45% | 7808 | m...@ripe.net
  0.45% |1 |  0.43% | 7535 | bcla...@cisco.com
  0.45% |1 |  0.43% | 7507 | bmann...@isi.edu
  0.45% |1 |  0.43% | 7493 | hannes.tschofe...@gmx.net
  0.45% |1 |  0.42% | 7376 | alejandroacostaal...@gmail.com
  0.45% |1 |  0.42% | 7233 | doug.mtv...@gmail.com
  0.45% |1 |  0.40% | 7035 | gsalg...@cisco.com
  0.45% |1 |  0.40% | 7005 | z...@sensinode.com
  0.45% |1 |  0.39% | 6692 | jab...@hopcount.ca
  0.45% |1 |  0.37% | 6450 | ma...@isc.org
  0.45% |1 |  0.37% | 6370 | jo...@taugh.com
  0.45% |1 |  0.36% | 6308 | pe...@akayla.com
  0.45% |1 |  0.34% | 5940 | lore...@meetecho.com
  0.45% |1 |  0.34% | 5865 | ietf2d...@davearonson.com
  0.45% |1 |  0.34% | 5864 | l.w...@surrey.ac.uk
  0.45% |1 |  0.33% | 5797 | st...@shinkuro.com
  0.45% |1 |  0.33% | 5733 | tterr...@xiph.org
  0.45% |1 |  0.32% | 5593 | hous...@vigilsec.com
  0.45% |1 |  0.30% | 5262 | bra...@isi.edu
  0.45% |1 |  0.30% | 5180 | jh...@cmu.edu
  0.45% |1 |  0.29% | 5035 | adr...@olddog.co.uk
+--++--+
100.00% |  222 |100.00% |  1737615 | Total

Re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard

[Manger, James H]

draft-bormann-cbor-04 adds text about handling maps with multiple identical 
keys., but it is contradictory. Section 3.4. "Specifying Keys for Maps" says:

   A CBOR-based protocol should make an intentional decision about what
   to do when a receiving application sees multiple identical keys in a
   map.  A protocol might have a rule that it is not an error to have
   identical keys in a map, and that the receiving application will
   discard all but the last key/value pair for a given key in a map.

   ...

   The CBOR data model for maps does not allow ascribing semantics to
   the order of the key/value pairs in the map representation.  A CBOR-
   based protocol MUST NOT be defined in such a way that changing the
   key/value pair order in a map would change the semantics, apart from
   trivial aspects (cache usage etc.).


A protocol that says "discard all but the last key/value pair for a given key" 
does change semantics if the key/value pair order is changed so it violates the 
text saying this "MUST NOT" happen.

Given there is no legacy CBOR data to maintain backward compatibility with, the 
spec should be clearer that a map with multiple identical keys is always an 
error. Discarding all but the last pair for a given key is NOT acceptable 
behaviour for a parser. A note that a streaming parser might not be able to 
detect duplicates is ok, accompanied by a warning that an application using 
such a parser will need its own checks for multiple identical keys to avoid 
unambiguous messages.

Suggestion:

Delete the whole paragraph starting "A CBOR-based protocol should make an 
intentional decision".

After the sentence "The CBOR data model for maps allows zero or one entries in 
the map for each specific key", add the following sentences:

   Consequently, a map in which a specific key appears multiple times is not
   a valid CBOR value. A parser MUST NOT accept such a map by keeping just
   one entry for an offending key.


Typo: s/for each a specific key/for each specific key/

--
James Manger

Re: The Trust Agreement

[John C Klensin]

FWIW, I share Brian's concern and reasoning about these
questions (and his allergy).   I might have a lower threshold of
necessity as a requirement for changing the agreement, but I'm
not convinced -- from either the slide or what I could hear of
the audio-- that it is necessary.

   john


--On Friday, August 02, 2013 08:59 +1200 Brian E Carpenter
 wrote:

> Hi,
> 
> Re the Trust's plenary slides (I was not in Berlin):
> 
> I have an allergy to modifying the Trust Agreement unless
> there's an overwhelming reason to do so. It was a very
> hard-won piece of text.
>...

Re: Bringing back Internet transparency

[Phillip Hallam-Baker]

On Thu, Aug 1, 2013 at 3:14 PM, Noel Chiappa wrote:

> > From: Phillip Hallam-Baker 
>
> > The ISPs had a clear interest in killing of NAT which threatened the
> > ISP business model.
>
> So this is rather amusing: you're trying to tell me that ISPs wanted to
> kill
> NAT, and I have other people telling me NAT was an intergral part of ISPs'
> master plan to take over the universe.
>
> Clearly you all both can't be right.
>

Not at all. It is entirely possible for them to be telling everyone else
not to use NAT because it is 'evul' while planning to deploy and use it
themselves.

In practice the two positions were separated in time by many years as my
ISP allowed me to use NAT ten years back and my current ISP actually
requires me to use a NAT box as the NAT capability is built into my cable
modem.


On the network neutrality thing, I think the arguments on both sides as
specious. The fundamental issue is whether ISPs will be permitted to
leverage local monopolies on the provision of broadband services to
establish monopolies in network services that depend on those monopoly
services.

Some people have ideological blinkers that tell them that the free market
solves all problems and since the markets in the US are free (they must be
because it says so in the constitution) there can be no monopoly issue.
Markets are not perfect, people need to get over that.

It seems reasonable to me that any party that has a local monopoly in
providing broadband services has to be regulated up the pattottie and the
same is true if the number of providers is effectively constrained. Network
neutrality is just a fix for a market failure situation.

If an ISP wants to have a pricing model where I get my 1x Internet
connection for $X but Sony can stream an HD movie to me at 10x by paying to
temporarily up my connection, that seems perfectly fine to me. If on the
other hand I am paying $Y for that 10x connection then the ISP has no
business demanding a double dip from Sony or whoever.

-- 
Website: http://hallambaker.com/

Re: 6tsch BoF

[Melinda Shore]

On 8/1/13 12:54 PM, Brian E Carpenter wrote:
> In the case of a WG-forming BOF, it seems to me that a nucleus
> of people willing and competent to do the work, and a good set of
> arguments why the work needs to be done and how it will make the
> Internet better, are more important than any kind of numbers game.

Yes, and "Who here is planning on contributing to
this effort if we're chartered?" is an entirely different
question from "Who here thinks we should charter a
working group?"

Finding consensus is not simply a matter of asking
a particular question at a given point in time.  It's
a process.  I cannot recommend strongly enough that
people spend time with Pete's document:
http://datatracker.ietf.org/doc/draft-resnick-on-consensus/

Melinda

Re: Bringing back Internet transparency

[Mark Andrews]

In message <20130801191438.c027718c...@mercury.lcs.mit.edu>, Noel Chiappa write
s:
> > From: Phillip Hallam-Baker 
> 
> > The ISPs had a clear interest in killing of NAT which threatened the
> > ISP business model.
> 
> So this is rather amusing: you're trying to tell me that ISPs wanted to kill
> NAT, and I have other people telling me NAT was an intergral part of ISPs'
> master plan to take over the universe.
> 
> Clearly you all both can't be right.

They want the extra dollars for extra address but the don't want
the support costs that would bring.  They sit at different points
for different sets of customers.

>   Noel
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

The Trust Agreement

[Brian E Carpenter]

Hi,

Re the Trust's plenary slides (I was not in Berlin):

I have an allergy to modifying the Trust Agreement unless there's an
overwhelming reason to do so. It was a very hard-won piece of text.

> Issue #1
> We have recently been asked permission to
> republish the TAO with a creative commons
> license, but unfortunately the current trust
> agreement does not give the trustees the
> rights to do this

It doesn't? You have the right to license "existing and future
intellectual property" according to clause 2.1 of the Trust Agreement.
Is there some particular property of the CC license that causes a
problem?

> Issue #2
> We cannot currently accept physical assets
> like hardware donations into the trust
> Once accepted into the trust, we would be unable
> to dispose of these items in the future if they are
> identified as no longer being needed

It was definitely intended that the Trust would only handle
intellectual property, and that ISOC on behalf of IASA would handle
money and material property. Why change this?

(I'm not quite sure why the Trust Agreement included the words
"and other property" in the first place. It was there from a very
early draft and was never discussed, as far as I can tell from my
2005 email archive.)

> Issue #3
> Once a domain name or trademark is
> registered by the trust, it cannot be
> abandoned even if it is no longer needed
> We must maintain these in perpetuity

IANAL, but it isn't clear to me that clause 9.4 forces you to do this.
It requires you to "take reasonable steps" and to file applications "as
the Trustees deem necessary in order to maintain and protect the Trust
Assets." If you decide (and minute) that it isn't reasonable or necessary
to maintain veryolddomainname.org, where's the crime?

Brian

Re: 6tsch BoF

[Brian E Carpenter]

On 02/08/2013 01:30, Andy Bierman wrote:
> On Thu, Aug 1, 2013 at 4:24 AM, Yoav Nir  wrote:
>> On Aug 1, 2013, at 11:14 AM, Andy Bierman  wrote:
>>
>>> Hi,
>>>
>>> Isn't it obvious why humming is flawed and raising hands works?
>>> (Analog vs. digital).  A hand is either raised or it isn't.
>>> The sum of all hands raised is comparable across tests.
>>> The sum of the amplitude of all hums is not.
>> Hums are better as they give greater weight to people who are more vocally 
>> in support (or in opposition) to the assertion.
>>
> 
> Please provide some evidence that a loud hum means the person is more
> committed to work on an item.

I spotted a number of virtual :-)s in Yoav's message.

The fact is that both methods are broken. A loud hum may indeed
represent strength of feeling, which in judging consensus is
valuable input. Or it may represent chance (some people naturally
hum louder) or a cultural split in opinion. So it's fairly
meaningless. A lot of hands up may indicate that a couple of
employers have loaded the room.

One can make a case that we shouldn't use either method: just
go by the arguments made in the room and on the list.

In the case of a WG-forming BOF, it seems to me that a nucleus
of people willing and competent to do the work, and a good set of
arguments why the work needs to be done and how it will make the
Internet better, are more important than any kind of numbers game.

  Brian

Re: Bringing back Internet transparency

[Noel Chiappa]

> From: Phillip Hallam-Baker 

> The ISPs had a clear interest in killing of NAT which threatened the
> ISP business model.

So this is rather amusing: you're trying to tell me that ISPs wanted to kill
NAT, and I have other people telling me NAT was an intergral part of ISPs'
master plan to take over the universe.

Clearly you all both can't be right.

Noel

Re: stability of iana.org URLs

[Jeffrey Hutzelman]

On Thu, 2013-08-01 at 01:10 -0700, Amanda Baber wrote:
> Hi,
> 
> The link in RFC3315 is actually incorrect -- it should have been
> http://www.iana.org/assignments/enterprise-numbers, without the file
> extension, and there's an erratum about this. HTML was generally (if
> not exclusively) reserved for files that needed to include links to
> registration forms .

Nonetheless, it's an existing URL in an immutable published RFC.  Once
such a thing has been published, right or wrong, best practice is to
make sure it remains valid.

Protecting the disclosure of the identity (was: Loud humming is subject to cultural bias)

[SM]

Hi Andy,
At 09:26 01-08-2013, Andy Bierman wrote:

I meant that it is difficult to remain anonymous when the
email to the WG has your email address in it.


Agreed.


Perhaps you can point me to the RFC 2026 text (or other RFC)
that says something about protecting the disclosure of the identity
of the person expressing agreement or disagreement with
some question asked in a WG meeting.


I read RFC 2026 quickly.  I did not find any text about protecting 
the disclosure of the identity of a person.  I read another RFC which 
was about a WG meeting.  It states that there are requirements for 
disclosure of conflicts of interest.  I did not find any text about 
protecting the disclosure of the identity of the person.


Regards,
-sm 

Re: Bringing back Internet transparency

[Noel Chiappa]

> From: Simon Leinen 

> In the eyes of your ISP, you were misbehaving, because you were
> violating their assumption that you would use ONE (1) computer with that
> connection.  If you had been what they consider an honest citizen, you
> would have gotten a "commercial" connection to connect more than one.

I suspect it had a lot more to do with their customer service setup; they were
not, after all, hiring computer scientists. They worked off scripts, and the
script needed a known quantity connected to the port (I would guess the only
handled Windows boxes and Apple machines). With 7 different kinds of Brand-X
NAT boxes (some of which had limited maintainence capabilities), their scripts
would not have worked.

Besides, they had other ways to sort out the commercial from residential
customers; for one, they filtered out incoming SMTP connections (although this
might have been as much to prevent clueless home users from being spam vectors
by running open relays, etc as anything else). I would assume they filtered
out incoming HTTP connections too.

Don't forget, in some ways a NAT box probably works _against_ an ISP's
interests, because they'd probably _like_ to be able to charge for each
machine connected up. (Many cable TV suppliers try to charge for multiple TVs,
don't forget). But I suspect the difficulty of connecting multiple machines
_without_ a NAT box (you've got to have a real router, and configure it, etc),
and its attendant increase in customer service costs (not to mention the
increased demand for address space), led them to throw up their hands.

Anway, this is all just speculation on our part. IMO, further discussion
without some real data on how the ISPs saw this is just a waste of time.


>> I guess this is just a long-winded, engineering take on 'the customer
>> is always right'.

> were our (we being the IETF) customers the ISPs, the users .., the
> vendors of then-current equipment, the vendors of potential
> circumvention solutions (NATs)?
> These groups of customers probably didn't agree on what they wanted.
> Were all of them right?

Excellent point. Have to go away and ponder that one for a while.

  Noel

Re: stability of iana.org URLs

[ned+ietf]

> Hi,

> The link in RFC3315 is actually incorrect -- it should have been 
> http://www.iana.org/assignments/enterprise-numbers, without the file 
> extension, and there's an erratum about this. HTML was generally (if not 
> exclusively) reserved for files that needed to include links to registration 
> forms .

> As Barry said, we do intend to keep that same short 
> http://www.iana.org/assignments/example format working for every current 
> page, even the newly-created ones. We also prefer to see that format used in 
> documents, since we can't guarantee that the file extension used for the long 
> version won't change. (This information will be appearing on the website in 
> some form.)


> Also, if you find that a formerly-valid URL (like one that used to have an 
> .html exception) isn't redirecting to the current page, please report it to 
> i...@iana.org. A redirect should have been set up.

Excellent, thanks.

Ned

Re: Bringing back Internet transparency

[Joe Touch]

On 8/1/2013 2:16 AM, Simon Leinen wrote:

>For the first couple of years that I had an ISP connection (which soon
>had an early NAT box on it), whenever I called up the ISP (then, and
>still, one of the largest in the US) with a service call, the first
>thing I had to do was unplug the NAT box and plug in a host directly!

>

I don't think your anecdote contradicts Joe's claim.

In the eyes of your ISP, you were misbehaving, because you were
violating their assumption that you would use ONE (1) computer with that
connection.  If you had been what they consider an honest citizen, you
would have gotten a "commercial" connection to connect more than one.


Another data point is Google's recent reversal on network transparency 
focused on artificially differentiating between perceived "commercial" 
and "individual" customers:


http://www.listbox.com/member/archive/247/2013/07/sort/time_rev/page/1/entry/4:390/20130731102314:B16998B8-F9EC-11E2-AF78-DB9DE151F03B/

My experience has been that there are four ways ISPs try to break the 
Internet's assumption that "all nodes are equivalent" (any port, any 
time, any where, IMO), with:


1. asymmetric BW provisioning and throttling

2. NATs

3. short-lease DHCP (i.e., spinning IP addrs every day or
faster, to interfere with registering an assigned IP in the DNS)

4. legal means

ISPs use a combination of these, but the cheapest one is NATs.

Joe

Re: 6tsch BoF

[Melinda Shore]

On 8/1/13 1:29 AM, joel jaeggli wrote:
> Consensus for any particular outcome is in the end a judgment call.

Well, yes and no, but this situation strikes me as odd, and probably
a mistake on the part of the chairs.  If you can't tell whether or
not you've got consensus, you don't have consensus.  It sounds like
they were treating the hum as a vote in the first place (which we
do entirely too often).

Melinda

Re: 6tsch BoF

[Barry Leiba]

> We are not voting.
> We are expressing agreement with a specific assertion.
> That is true whether the agreement is expressed via vocalization
> or motion of limbs.

Absolutely so.

> The chairs can pick however they want to measure agreement.
> Many chairs ask for a show of hands.  I prefer that method.
> There is still a judgement call when the numbers for and against
> are not significantly different.

Just some somewhat arbitrary notes here:

There are times when I want to count hands, but it's not for a "vote".
 If I ask who will commit to working on something, I'm looking for a
critical mass that doesn't require counting... but I'm often *also*
looking for commitments, which requires both counting and
identification.

There are also times when I just want to see the relative balance.  As
Andy says, listening to hums can be dicey, even if we don't try to
second guess whether people who hum loudly have stronger opinions
and/or more enthusiasm, or are just demonstrating a cultural
difference.  But if I get a show of hands and do *not* count, I see
that relative balance better.

On the other hand, in perhaps the same situation, if it turns out that
I see only a few hands on one side of the question, I can see whom to
ask to stand up and tell us *why*, and that's often the real value of
the hums: we have a few people who object to X, and we need them to
tell us what their issues are so they can be discussed and addressed.

It drives me nuts [1] when chairs ask for a hum, hear a loud hum for A
and a weak hum for B, and then say, "OK, we have rough consensus,"
without pursuing the issue: What are the objections to A?  Do the B
people just *prefer* B, but they can live with A?  Or is A
fundamentally flawed, but only a few people understand that?

Barry

[1] Admittedly, a short drive.

Re: 6tsch BoF

[Dave Crocker]

Ralph, et al,

Perhaps I have missed relevant responses, but it appears that folk are 
missing what is significant here:



On 8/1/2013 10:50 AM, Ralph Droms wrote:

 In particular, the effect of humming versus
show of hands was pretty obvious.


The fact that the results were so profoundly different should get our 
attention, enough to get us to consider specifying how to measure 
consensus.  From the data you cited, it appears that raising hands 
carries some sort of social onus, at least for some people some times, 
that raising hands does not.


Perhaps that doesn't bother other folk very much but the differential 
result was so extreme -- as a single-event experiment -- it strongly 
suggests we should not call for hand-raising.  (The likely explanations 
for the difference are pretty straightforward.  Whether our community of 
engineers wants to believe the explanations or not doesn't matter  The 
data should be sufficiently compelling.)




The other question raised in my mind is why the initial result from
the hum, which did not have a consensus either way, was not
sufficient.


Exactly.  This is a point of working group management that should prompt 
some concern.


It's not appropriate to throw out results that were validly obtained but 
yield unpleasant results, and then repeat the same query.  (In fact a 
repetition of a survey on the same sample population is a rank violation 
of reasonable experimental methodology.)


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: Bringing back Internet transparency

[Phillip Hallam-Baker]

On Thu, Aug 1, 2013 at 5:16 AM, Simon Leinen  wrote:

> Noel Chiappa writes:
> > But in any event, it's doesn't void my point: if people want
> > something, we have two choices: i) blow people off, and they'll adopt
> > some point solution that interacts poorly with everything else, or ii)
> > give people the _capabilities_ they need/want (and thereby have some
> > chance at minimizing the brain damage - since generally people don't
> > care _how_ it works, as long as it _does_ what they want).
>
> > I guess this is just a long-winded, engineering take on 'the customer
> > is always right'.
>
> Yes, but it's harder than that.  In the NAT case, were our (we being the
> IETF) customers the ISPs, the users (in this case "end users" who
> insisted on connecting multiple devices without going incurring the
> costs of becoming "commercial" customers), the vendors of then-current
> equipment, the vendors of potential circumvention solutions (NATs)?
>
> These groups of customers probably didn't agree on what they wanted
>

I think it was a little uglier than that.

ISPs and backbone providers were well represented in the IETF, home users,
rather less so. The ISPs had a clear interest in killing of NAT which
threatened the ISP business model.

People internalize their employers interests very easily and without
knowing that they have done so. I have an acquaintance from Oxford who
spends his time 'researching' climate change for the Koch brothers. He has
no qualifications in the field. His 'research method' is essentially the
method of Winston Smith in 1984.  But he is completely convinced that he is
a legitimate researcher and that he is right and the nobel prize winners
whose work he is misrepresenting are engaged in an international conspiracy.

So when people were trying to mau-mau me into rejecting NAT as
ideologically unsound, I had a different perspective.

It is never going to be in the customers interest to let their internetwork
provider know what their internal network looks like. Never-ever-ever. I
don't want my ISP to know because then they might sell that information to
other people and I would be getting all sorts of demands for payment.

The business logic means that it will be NAT today, NAT tomorrow and NAT
forever. Whether I am a commercial or a residential user, I am going to use
that NAT box to protect my economic interests versus my supplier. And that
will be the case regardless of how many IP addresses are available.


The IETF was originally the product of a group of people who looked at the
telephone system and could see how to do the job differently. I don't see
many people who look at the Internet in that way. The IETF has become more
like what it has replaced.

The issue is not just welcoming newcomers, it is welcoming newcomers who
can look at problems with a fresh perspective and reject ideological
approaches. And that is why I am going to continue to point out the the
governance model of the IETF is expressly designed to exclude dissident
thinkers.


-- 
Website: http://hallambaker.com/

Re: 6tsch BoF

[Ted Lemon]

We actually had a talk about this amongst several IESG and former IESG members. 
  I am not going to report the results, because I might remember them wrong, 
but my thoughts on this are as follows:

- The hum is not a means of determining consensus; it is a means of determining 
the sense of the room.   If the hum is clearly many in favor, nobody 
against,then you have consensus, but that's unusual.   If the hum shows many in 
favor and some against, you need to go to the next step, because you do not yet 
know whether you have consensus.

- So since the hum was quite inconclusive, the next question is, "can somebody 
who objects please say why."   One way to approach that is to ask for a show of 
hands.   Here, the chairs could have asked for a show of hands against—the show 
of hands for was unnecessary.   But this is forgivable, I think, unless you 
think people were intimidated by the show of hands for.   I think that would be 
hard to argue, given that they had already heard the result of the hum.

- So the show of hands against elicited no hands.   I was there, that's what I 
remember seeing too.

So at this point, what do you do?   Nobody is willing to stand up and say "I 
think we shouldn't go forward with this because of X."   Many people have said 
"we think we should go forward with this, support doing this, and want to 
participate."

To me, that's consensus.

That wasn't the full outcome of the BoF; there was a lot of good feedback and 
the charter needs work.   But it's pretty clear to me that in principle at 
least, there was consensus to do this work.

If you disagree, now would be a fine time to say so, although if in fact we get 
a charter that the IESG decides is worth floating, you will get another chance 
during the last call on the charter.

Re: 6tsch BoF

[Ralph Droms]

On Aug 1, 2013, at 3:30 PM, Andy Bierman  wrote:

> On Thu, Aug 1, 2013 at 4:24 AM, Yoav Nir  wrote:
>> 
>> On Aug 1, 2013, at 11:14 AM, Andy Bierman  wrote:
>> 
>>> Hi,
>>> 
>>> Isn't it obvious why humming is flawed and raising hands works?
>>> (Analog vs. digital).  A hand is either raised or it isn't.
>>> The sum of all hands raised is comparable across tests.
>>> The sum of the amplitude of all hums is not.
>> 
>> Hums are better as they give greater weight to people who are more vocally 
>> in support (or in opposition) to the assertion.
> 
> Please provide some evidence that a loud hum means the person is more
> committed to work on an item.
> 
> Favoring loud humming is subject to cultural bias.

As is identifying oneself with a position by raising one's hand.  I can imagine 
as much - my uninformed opinion would be more - cultural bias effect on a show 
of hands as on a hum.

> Some cultures are more inclined to raise their voice than others.
> Some people have naturally louder voices than others.
> Measuring volume may introduce bias in favor of loud men and against
> soft-spoken women, for example.

And a show of hands may introduce bias against women preferring anonymity.

- Ralph

> 
> This cultural bias is not compatible with increased inclusiveness.
> 
> 
> Andy
> 
>> Research shows([1]), that the one humming loudly for acceptance, will also 
>> volunteer to review and contribute code. The one humming loudly against is 
>> going to jump up to the mike in all future meetings and tell the group that 
>> they're doing the wrong thing. Those who hum softly will go back to reading 
>> their email.
>> 
>> Yoav
>> 
>> [1] citation needed
>> 

Re: 6tsch BoF

[Andy Bierman]

On Thu, Aug 1, 2013 at 4:24 AM, Yoav Nir  wrote:
>
> On Aug 1, 2013, at 11:14 AM, Andy Bierman  wrote:
>
>> Hi,
>>
>> Isn't it obvious why humming is flawed and raising hands works?
>> (Analog vs. digital).  A hand is either raised or it isn't.
>> The sum of all hands raised is comparable across tests.
>> The sum of the amplitude of all hums is not.
>
> Hums are better as they give greater weight to people who are more vocally in 
> support (or in opposition) to the assertion.
>

Please provide some evidence that a loud hum means the person is more
committed to work on an item.

Favoring loud humming is subject to cultural bias.
Some cultures are more inclined to raise their voice than others.
Some people have naturally louder voices than others.
Measuring volume may introduce bias in favor of loud men and against
soft-spoken women, for example.

This cultural bias is not compatible with increased inclusiveness.


Andy

> Research shows([1]), that the one humming loudly for acceptance, will also 
> volunteer to review and contribute code. The one humming loudly against is 
> going to jump up to the mike in all future meetings and tell the group that 
> they're doing the wrong thing. Those who hum softly will go back to reading 
> their email.
>
> Yoav
>
> [1] citation needed
>

Re: stability of iana.org URLs

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/1/13 2:01 PM, John Curran wrote:
> On Jul 31, 2013, at 10:11 AM, Peter Saint-Andre
>  wrote:
>> 
>> That's true, but cool URIs don't change:
>> 
>> http://www.w3.org/Provider/Style/URI.html
> 
> Even cooler would have been URN's (e.g.
> urn:ietf:enterprise-numbers), which was designed specifically as a
> persistent handle to information (ref:
> http://en.wikipedia.org/wiki/Uniform_resource_name) but alas, it 
> was not to be.

You're preaching to the choir:

https://datatracker.ietf.org/doc/draft-saintandre-iana-urn/

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR+mKgAAoJEOoGpJErxa2pqxgP/3/G2YgYnSzblkgnxtx8zB8H
ff81vkCnhRF/HnfZ5AwSjoXNvoGLNo+5e86ma6RUf6cOmKid11CaLqx6fZuBIKIt
dDmeyPloU4cL90qr7DDa6+msecLUEJpywtc9rTqHCVreaxplVW01aAhIpHtx+ElH
azvvYkg+C2uA2AYi2d9UCXheBKVFWZ25GxUUoUKF8VIy6htwslAZ+kbbaAuiStdo
zc0+XKjnpTB2Ng2jrUfBScuguos8ISH4WbJ0bDMmcF0pl20tX7oiQ2OkdGkaNYuL
UQIAZKyL+GZfhvFid+OSVWzNPUTP+ai3PXE4CdU5r1FdhyfYacQFXSvAzK5uSB5T
Iuo7mBouv87MFYvRcAZOkRv1ALcYeut5ZrzB/1zCWDtTVo7dMuICLms7FdZ/IiMw
j2Zd4xp+ATcPDiLAxACBoDU8l8A6Sw2XDr99o/G7qGu6Ligu5+qqjO1mrmEhNt9o
ZcJKhdof8DLknMGUcOsU0vPyxNaJoutZbk2xMoiDCa8USlhCanwZO1Ok98tL6/dx
sDGe750VH18YCCLZ0mpPHImtQK4OZ6dZSXIbxBeGCMiCQxiaKGbrKDeQAjf7ITa3
e86A9RN3LoJFpzL/uV+cHQisilrZaTZM4td7DHvGphmVdJu9vx0LAwPQU8+nTdWT
iNF30/g+vGz1gHk0D6Ad
=UYu0
-END PGP SIGNATURE-

Re: stability of iana.org URLs

[John Curran]

On Jul 31, 2013, at 10:11 AM, Peter Saint-Andre  wrote:
> 
> That's true, but cool URIs don't change:
> 
> http://www.w3.org/Provider/Style/URI.html

Even cooler would have been URN's (e.g. urn:ietf:enterprise-numbers), 
which was designed specifically as a persistent handle to information
(ref: http://en.wikipedia.org/wiki/Uniform_resource_name) but alas, it 
was not to be.

/John

Re: 6tsch BoF

[Scott Brim]

See draft-resnick-on-consensus for the art of running a group using hums
and other tools.  With those nuances, I like hums.

Re: 6tsch BoF

[Yoav Nir]

On Aug 1, 2013, at 11:14 AM, Andy Bierman  wrote:

> Hi,
> 
> Isn't it obvious why humming is flawed and raising hands works?
> (Analog vs. digital).  A hand is either raised or it isn't.
> The sum of all hands raised is comparable across tests.
> The sum of the amplitude of all hums is not.

Hums are better as they give greater weight to people who are more vocally in 
support (or in opposition) to the assertion.

Research shows([1]), that the one humming loudly for acceptance, will also 
volunteer to review and contribute code. The one humming loudly against is 
going to jump up to the mike in all future meetings and tell the group that 
they're doing the wrong thing. Those who hum softly will go back to reading 
their email.

Yoav

[1] citation needed

Re: 6tsch BoF

[Andy Bierman]

On Thu, Aug 1, 2013 at 3:04 AM, manning bill  wrote:
> we have never voted at IETFs.
> "we believe in rough consensus and running code"
>

We are not voting.
We are expressing agreement with a specific assertion.
That is true whether the agreement is expressed via vocalization
or motion of limbs.

Humming allows the chairs to be totally biased and interpret the hum volume
in a way that aligns with their preference for the outcome.

However, I have seen many times where the chairs clearly miscounted
the number of raised hands in order to make the outcome align
with their preference.  However this is much harder to pull off than comparing
2 similar hum volumes.

The chairs can pick however they want to measure agreement.
Many chairs ask for a show of hands.  I prefer that method.
There is still a judgement call when the numbers for and against
are not significantly different.

> /bill

Andy

>
> On 1August2013Thursday, at 2:14, A ndy Bierman wrote:
>
>> Hi,
>>
>> Isn't it obvious why humming is flawed and raising hands works?
>> (Analog vs. digital).  A hand is either raised or it isn't.
>> The sum of all hands raised is comparable across tests.
>> The sum of the amplitude of all hums is not.
>>
>>
>> Andy
>>
>> On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms  wrote:
>>>
>>> I found the process in the 6tsch BoF (Tue 1520) for asking about taking on 
>>> the work discussed in the BoF to be thought-provoking.
>>>
>>> Toward the end of the BoF, the chairs asked the question "1. Is this a 
>>> topic that the IETF should address?"  First, the chairs asked for a hum.  
>>> From my vantage point (middle of the room), the hum was pretty close to 
>>> equal, for/against.  I reviewed the audio 
>>> (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
>>> starting about 1:22), and heard a slightly louder hum "for".  The BoF 
>>> chairs decided they needed more information than they could extract from 
>>> the hum, so they asked for a show of hands.  From the audio record, there 
>>> were "a lot" for (which matches my recollection) and "a handful" against 
>>> (my memory is that no hands showed against).  There was a request to ask 
>>> for a show of hands for "how many don't know".  The question was asked, and 
>>> the record shows "a dozen".
>>>
>>> So, there was apparently a complete change in the answer to the question 
>>> based on humming versus voting.  There may also have been some effect from 
>>> asking, after the fact, for a show of hands for "don't know".
>>>
>>> I'm really curious about the results, which indicate that, at least in this 
>>> case, the response to the question is heavily dependent on the on the mode 
>>> used to obtain the answers to the question (which we all know is possible). 
>>>  In particular, the effect of humming versus show of hands was pretty 
>>> obvious.  draft-resnick-on-consensus gives several reasons why humming is 
>>> preferred over a show of hands.  From this example, it seems to me to be 
>>> worth considering whether a more honest and accurate result is obtained 
>>> through humming rather than a show of hands.
>>>
>>> The other question raised in my mind is why the initial result from the 
>>> hum, which did not have a consensus either way, was not sufficient.  
>>> "Roughly the same response" for/against the question would seem to me to be 
>>> as valid a result as explicit consensus one way or the other, and the act 
>>> of taking a show of hands to survey the appeared to treat the hum as 
>>> irrelevant, rather than highly significant.
>>>
>>> - Ralph
>>>
>

Re: 6tsch BoF

[SM]

Hi Ralph,
At 01:50 01-08-2013, Ralph Droms wrote:
Toward the end of the BoF, the chairs asked the question "1. Is this 
a topic that the IETF should address?"  First, the chairs asked for 
a hum.  From my vantage point (middle of the room), the hum was 
pretty close to equal, for/against.  I reviewed the audio 
(http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
starting about 1:22), and heard a slightly louder hum "for".  The 
BoF chairs decided they needed more information than they could 
extract from the hum, so they asked for a show of hands.  From the 
audio record, there were "a lot" for (which matches my recollection) 
and "a handful" against (my memory is that no hands showed 
against).  There was a request to ask for a show of hands for "how 
many don't know".  The question was asked, and the record shows "a dozen".


Switching from hums to votes is not a good idea.  The above could be because:

  (a) The question asked was incorrect.

  (b) The choices provided were incorrect.

So, there was apparently a complete change in the answer to the 
question based on humming versus voting.  There may also have been 
some effect from asking, after the fact, for a show of hands for "don't know".


I'm really curious about the results, which indicate that, at least 
in this case, the response to the question is heavily dependent on 
the on the mode used to obtain the answers to the question (which we 
all know is possible).  In particular, the effect of humming versus 
show of hands was pretty obvious.  draft-resnick-on-consensus gives 
several reasons why humming is preferred over a show of hands.  From 
this example, it seems to me to be worth considering whether a more 
honest and accurate result is obtained through humming rather than a 
show of hands.


Your message does not provide enough context.  The simple explanation 
is that the vote was used to change the answer.  Consensus is a 
process, i.e. there are steps which are carefully followed until 
everyone is okay with the choices which they are provided with.  In 
case of doubt, hum.


The other question raised in my mind is why the initial result from 
the hum, which did not have a consensus either way, was not 
sufficient.  "Roughly the same response" for/against the question 
would seem to me to be as valid a result as explicit consensus one 
way or the other, and the act of taking a show of hands to survey 
the appeared to treat the hum as irrelevant, rather than highly significant.


The first result was sufficient.  A second try, whether it is a hum 
or a vote, creates an appearance that the decision-maker did not like 
the result and is trying to change it.  A decision can be undermined 
by people conforming to what other people in the group think.


Regards,
-sm 

Re: 6tsch BoF

[Joe Abley]

On 2013-08-01, at 12:04, manning bill  wrote:

> we have never voted at IETFs.
> "we believe in rough consensus and running code"

The enduring tautology in this is the use of the word "we".

"some of us believe in rough consensus and running code, probably enough that 
the mantra is worth repeating, although we have not measured support for this 
quantitatively, your mileage may vary"

:-)


Joe

Re: 6tsch BoF

[manning bill]

we have never voted at IETFs.
"we believe in rough consensus and running code"

/bill


On 1August2013Thursday, at 2:14, A ndy Bierman wrote:

> Hi,
> 
> Isn't it obvious why humming is flawed and raising hands works?
> (Analog vs. digital).  A hand is either raised or it isn't.
> The sum of all hands raised is comparable across tests.
> The sum of the amplitude of all hums is not.
> 
> 
> Andy
> 
> On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms  wrote:
>> 
>> I found the process in the 6tsch BoF (Tue 1520) for asking about taking on 
>> the work discussed in the BoF to be thought-provoking.
>> 
>> Toward the end of the BoF, the chairs asked the question "1. Is this a topic 
>> that the IETF should address?"  First, the chairs asked for a hum.  From my 
>> vantage point (middle of the room), the hum was pretty close to equal, 
>> for/against.  I reviewed the audio 
>> (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
>> starting about 1:22), and heard a slightly louder hum "for".  The BoF chairs 
>> decided they needed more information than they could extract from the hum, 
>> so they asked for a show of hands.  From the audio record, there were "a 
>> lot" for (which matches my recollection) and "a handful" against (my memory 
>> is that no hands showed against).  There was a request to ask for a show of 
>> hands for "how many don't know".  The question was asked, and the record 
>> shows "a dozen".
>> 
>> So, there was apparently a complete change in the answer to the question 
>> based on humming versus voting.  There may also have been some effect from 
>> asking, after the fact, for a show of hands for "don't know".
>> 
>> I'm really curious about the results, which indicate that, at least in this 
>> case, the response to the question is heavily dependent on the on the mode 
>> used to obtain the answers to the question (which we all know is possible).  
>> In particular, the effect of humming versus show of hands was pretty 
>> obvious.  draft-resnick-on-consensus gives several reasons why humming is 
>> preferred over a show of hands.  From this example, it seems to me to be 
>> worth considering whether a more honest and accurate result is obtained 
>> through humming rather than a show of hands.
>> 
>> The other question raised in my mind is why the initial result from the hum, 
>> which did not have a consensus either way, was not sufficient.  "Roughly the 
>> same response" for/against the question would seem to me to be as valid a 
>> result as explicit consensus one way or the other, and the act of taking a 
>> show of hands to survey the appeared to treat the hum as irrelevant, rather 
>> than highly significant.
>> 
>> - Ralph
>> 

Re: 6tsch BoF

[Andy Bierman]

On Thu, Aug 1, 2013 at 2:34 AM, Ralph Droms  wrote:
>
> On Aug 1, 2013, at 11:14 AM 8/1/13, Andy Bierman  wrote:
>
>> Hi,
>>
>> Isn't it obvious why humming is flawed and raising hands works?
>> (Analog vs. digital).  A hand is either raised or it isn't.
>> The sum of all hands raised is comparable across tests.
>
> The repeatable test gives *an* answer, but is not necessarily the answer that 
> best reflects the sentiment of those answering the question.
>
> A relatively imprecise thermometer that gives a reading close to the measured 
> temperature is more useful than a digital thermometer that gives a precise 
> but highly inaccurate reading.
>

I disagree.  Whether I raise my hand to ear level, 2 inches above my head,
or as high as I can reach, the chair will still count my raised hand as "1".
If I hum really load (and if everybody hums at a different volume) the
chair cannot possibly know how to quantify that result.

Quantifying the number of raised hands is not a judgement call,


> - Ralph

Andy


>
>> The sum of the amplitude of all hums is not.
>>
>>
>> Andy
>>
>> On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms  wrote:
>>>
>>> I found the process in the 6tsch BoF (Tue 1520) for asking about taking on 
>>> the work discussed in the BoF to be thought-provoking.
>>>
>>> Toward the end of the BoF, the chairs asked the question "1. Is this a 
>>> topic that the IETF should address?"  First, the chairs asked for a hum.  
>>> From my vantage point (middle of the room), the hum was pretty close to 
>>> equal, for/against.  I reviewed the audio 
>>> (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
>>> starting about 1:22), and heard a slightly louder hum "for".  The BoF 
>>> chairs decided they needed more information than they could extract from 
>>> the hum, so they asked for a show of hands.  From the audio record, there 
>>> were "a lot" for (which matches my recollection) and "a handful" against 
>>> (my memory is that no hands showed against).  There was a request to ask 
>>> for a show of hands for "how many don't know".  The question was asked, and 
>>> the record shows "a dozen".
>>>
>>> So, there was apparently a complete change in the answer to the question 
>>> based on humming versus voting.  There may also have been some effect from 
>>> asking, after the fact, for a show of hands for "don't know".
>>>
>>> I'm really curious about the results, which indicate that, at least in this 
>>> case, the response to the question is heavily dependent on the on the mode 
>>> used to obtain the answers to the question (which we all know is possible). 
>>>  In particular, the effect of humming versus show of hands was pretty 
>>> obvious.  draft-resnick-on-consensus gives several reasons why humming is 
>>> preferred over a show of hands.  From this example, it seems to me to be 
>>> worth considering whether a more honest and accurate result is obtained 
>>> through humming rather than a show of hands.
>>>
>>> The other question raised in my mind is why the initial result from the 
>>> hum, which did not have a consensus either way, was not sufficient.  
>>> "Roughly the same response" for/against the question would seem to me to be 
>>> as valid a result as explicit consensus one way or the other, and the act 
>>> of taking a show of hands to survey the appeared to treat the hum as 
>>> irrelevant, rather than highly significant.
>>>
>>> - Ralph
>>>
>

Re: 6tsch BoF

[Ralph Droms]

On Aug 1, 2013, at 11:14 AM 8/1/13, Andy Bierman  wrote:

> Hi,
> 
> Isn't it obvious why humming is flawed and raising hands works?
> (Analog vs. digital).  A hand is either raised or it isn't.
> The sum of all hands raised is comparable across tests.

The repeatable test gives *an* answer, but is not necessarily the answer that 
best reflects the sentiment of those answering the question.

A relatively imprecise thermometer that gives a reading close to the measured 
temperature is more useful than a digital thermometer that gives a precise but 
highly inaccurate reading.

- Ralph

> The sum of the amplitude of all hums is not.
> 
> 
> Andy
> 
> On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms  wrote:
>> 
>> I found the process in the 6tsch BoF (Tue 1520) for asking about taking on 
>> the work discussed in the BoF to be thought-provoking.
>> 
>> Toward the end of the BoF, the chairs asked the question "1. Is this a topic 
>> that the IETF should address?"  First, the chairs asked for a hum.  From my 
>> vantage point (middle of the room), the hum was pretty close to equal, 
>> for/against.  I reviewed the audio 
>> (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
>> starting about 1:22), and heard a slightly louder hum "for".  The BoF chairs 
>> decided they needed more information than they could extract from the hum, 
>> so they asked for a show of hands.  From the audio record, there were "a 
>> lot" for (which matches my recollection) and "a handful" against (my memory 
>> is that no hands showed against).  There was a request to ask for a show of 
>> hands for "how many don't know".  The question was asked, and the record 
>> shows "a dozen".
>> 
>> So, there was apparently a complete change in the answer to the question 
>> based on humming versus voting.  There may also have been some effect from 
>> asking, after the fact, for a show of hands for "don't know".
>> 
>> I'm really curious about the results, which indicate that, at least in this 
>> case, the response to the question is heavily dependent on the on the mode 
>> used to obtain the answers to the question (which we all know is possible).  
>> In particular, the effect of humming versus show of hands was pretty 
>> obvious.  draft-resnick-on-consensus gives several reasons why humming is 
>> preferred over a show of hands.  From this example, it seems to me to be 
>> worth considering whether a more honest and accurate result is obtained 
>> through humming rather than a show of hands.
>> 
>> The other question raised in my mind is why the initial result from the hum, 
>> which did not have a consensus either way, was not sufficient.  "Roughly the 
>> same response" for/against the question would seem to me to be as valid a 
>> result as explicit consensus one way or the other, and the act of taking a 
>> show of hands to survey the appeared to treat the hum as irrelevant, rather 
>> than highly significant.
>> 
>> - Ralph
>> 

Re: 6tsch BoF

[joel jaeggli]

On 8/1/13 11:14 AM, Andy Bierman wrote:
> Hi,
>
> Isn't it obvious why humming is flawed and raising hands works?
> (Analog vs. digital).  A hand is either raised or it isn't.
> The sum of all hands raised is comparable across tests.
> The sum of the amplitude of all hums is not.
Consensus for any particular outcome is in the end a judgment call.
> Andy
>
> On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms  wrote:
>> I found the process in the 6tsch BoF (Tue 1520) for asking about taking on 
>> the work discussed in the BoF to be thought-provoking.
>>
>> Toward the end of the BoF, the chairs asked the question "1. Is this a topic 
>> that the IETF should address?"  First, the chairs asked for a hum.  From my 
>> vantage point (middle of the room), the hum was pretty close to equal, 
>> for/against.  I reviewed the audio 
>> (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
>> starting about 1:22), and heard a slightly louder hum "for".  The BoF chairs 
>> decided they needed more information than they could extract from the hum, 
>> so they asked for a show of hands.  From the audio record, there were "a 
>> lot" for (which matches my recollection) and "a handful" against (my memory 
>> is that no hands showed against).  There was a request to ask for a show of 
>> hands for "how many don't know".  The question was asked, and the record 
>> shows "a dozen".
>>
>> So, there was apparently a complete change in the answer to the question 
>> based on humming versus voting.  There may also have been some effect from 
>> asking, after the fact, for a show of hands for "don't know".
>>
>> I'm really curious about the results, which indicate that, at least in this 
>> case, the response to the question is heavily dependent on the on the mode 
>> used to obtain the answers to the question (which we all know is possible).  
>> In particular, the effect of humming versus show of hands was pretty 
>> obvious.  draft-resnick-on-consensus gives several reasons why humming is 
>> preferred over a show of hands.  From this example, it seems to me to be 
>> worth considering whether a more honest and accurate result is obtained 
>> through humming rather than a show of hands.
>>
>> The other question raised in my mind is why the initial result from the hum, 
>> which did not have a consensus either way, was not sufficient.  "Roughly the 
>> same response" for/against the question would seem to me to be as valid a 
>> result as explicit consensus one way or the other, and the act of taking a 
>> show of hands to survey the appeared to treat the hum as irrelevant, rather 
>> than highly significant.
>>
>> - Ralph
>>

Re: Bringing back Internet transparency

[Simon Leinen]

Noel Chiappa writes:
>> From: Joe Touch 
>> "what people want" (ISP operators, or at least some of them), was an
>> artificial way to differentiate home customers from commercial
>> providers.
>> I.e., they wanted to create a differentiation that wasn't part of the
>> Internet architecture, so they put one in.
>> NATs did other things ... but IMO mostly as a by-product of this
>> primary motivation.

> I'm not so sure about that.

> For the first couple of years that I had an ISP connection (which soon
> had an early NAT box on it), whenever I called up the ISP (then, and
> still, one of the largest in the US) with a service call, the first
> thing I had to do was unplug the NAT box and plug in a host directly!

I don't think your anecdote contradicts Joe's claim.

In the eyes of your ISP, you were misbehaving, because you were
violating their assumption that you would use ONE (1) computer with that
connection.  If you had been what they consider an honest citizen, you
would have gotten a "commercial" connection to connect more than one.

(Your service calls were just an opportunity for them to remind you
about that. :-)

Another early assumption about the consumer Internet connection was that
you wouldn't use it all the time, but only when you needed it.  This
"session" concept was natural for modems or ISDN connections, but was,
somewhat artificially, included in xDSL, presumably to conserve the
valuable customer experience of "connecting" and "disconnecting".

> It was only after everyone's house had multiple PC's (which was really
> only after wireless became common - I don't think too many people were
> willing to wire their houses for Ethernet :-) that they kind of
> expected there to be a NAT box there.

Yes, eventually the ISPs had to adapt their assumptions.

> But in any event, it's doesn't void my point: if people want
> something, we have two choices: i) blow people off, and they'll adopt
> some point solution that interacts poorly with everything else, or ii)
> give people the _capabilities_ they need/want (and thereby have some
> chance at minimizing the brain damage - since generally people don't
> care _how_ it works, as long as it _does_ what they want).

> I guess this is just a long-winded, engineering take on 'the customer
> is always right'.

Yes, but it's harder than that.  In the NAT case, were our (we being the
IETF) customers the ISPs, the users (in this case "end users" who
insisted on connecting multiple devices without going incurring the
costs of becoming "commercial" customers), the vendors of then-current
equipment, the vendors of potential circumvention solutions (NATs)?

These groups of customers probably didn't agree on what they wanted.

Were all of them right?
-- 
Simon.

Re: 6tsch BoF

[Andy Bierman]

Hi,

Isn't it obvious why humming is flawed and raising hands works?
(Analog vs. digital).  A hand is either raised or it isn't.
The sum of all hands raised is comparable across tests.
The sum of the amplitude of all hums is not.


Andy

On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms  wrote:
>
> I found the process in the 6tsch BoF (Tue 1520) for asking about taking on 
> the work discussed in the BoF to be thought-provoking.
>
> Toward the end of the BoF, the chairs asked the question "1. Is this a topic 
> that the IETF should address?"  First, the chairs asked for a hum.  From my 
> vantage point (middle of the room), the hum was pretty close to equal, 
> for/against.  I reviewed the audio 
> (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
> starting about 1:22), and heard a slightly louder hum "for".  The BoF chairs 
> decided they needed more information than they could extract from the hum, so 
> they asked for a show of hands.  From the audio record, there were "a lot" 
> for (which matches my recollection) and "a handful" against (my memory is 
> that no hands showed against).  There was a request to ask for a show of 
> hands for "how many don't know".  The question was asked, and the record 
> shows "a dozen".
>
> So, there was apparently a complete change in the answer to the question 
> based on humming versus voting.  There may also have been some effect from 
> asking, after the fact, for a show of hands for "don't know".
>
> I'm really curious about the results, which indicate that, at least in this 
> case, the response to the question is heavily dependent on the on the mode 
> used to obtain the answers to the question (which we all know is possible).  
> In particular, the effect of humming versus show of hands was pretty obvious. 
>  draft-resnick-on-consensus gives several reasons why humming is preferred 
> over a show of hands.  From this example, it seems to me to be worth 
> considering whether a more honest and accurate result is obtained through 
> humming rather than a show of hands.
>
> The other question raised in my mind is why the initial result from the hum, 
> which did not have a consensus either way, was not sufficient.  "Roughly the 
> same response" for/against the question would seem to me to be as valid a 
> result as explicit consensus one way or the other, and the act of taking a 
> show of hands to survey the appeared to treat the hum as irrelevant, rather 
> than highly significant.
>
> - Ralph
>

ADMIN PLENARY session recording available

[Meetecho Team]

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the 
ADMIN PLENARY WG session at IETF 87 is available at the following URL:
http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#ADMIN_PLENARY

For the chair(s): please feel free to put the link to the recording in the 
minutes,
if you think this might be useful.

Cheers,
the Meetecho Team


This email has been automatically generated by The Meetecho Conferencing System

TECH PLENARY session recording available

[Meetecho Team]

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the 
TECH PLENARY WG session at IETF 87 is available at the following URL:
http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#TECH_PLENARY

For the chair(s): please feel free to put the link to the recording in the 
minutes,
if you think this might be useful.

Cheers,
the Meetecho Team


This email has been automatically generated by The Meetecho Conferencing System

6tsch BoF

[Ralph Droms]

I found the process in the 6tsch BoF (Tue 1520) for asking about taking on the 
work discussed in the BoF to be thought-provoking.

Toward the end of the BoF, the chairs asked the question "1. Is this a topic 
that the IETF should address?"  First, the chairs asked for a hum.  From my 
vantage point (middle of the room), the hum was pretty close to equal, 
for/against.  I reviewed the audio 
(http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
starting about 1:22), and heard a slightly louder hum "for".  The BoF chairs 
decided they needed more information than they could extract from the hum, so 
they asked for a show of hands.  From the audio record, there were "a lot" for 
(which matches my recollection) and "a handful" against (my memory is that no 
hands showed against).  There was a request to ask for a show of hands for "how 
many don't know".  The question was asked, and the record shows "a dozen".

So, there was apparently a complete change in the answer to the question based 
on humming versus voting.  There may also have been some effect from asking, 
after the fact, for a show of hands for "don't know".

I'm really curious about the results, which indicate that, at least in this 
case, the response to the question is heavily dependent on the on the mode used 
to obtain the answers to the question (which we all know is possible).  In 
particular, the effect of humming versus show of hands was pretty obvious.  
draft-resnick-on-consensus gives several reasons why humming is preferred over 
a show of hands.  From this example, it seems to me to be worth considering 
whether a more honest and accurate result is obtained through humming rather 
than a show of hands.

The other question raised in my mind is why the initial result from the hum, 
which did not have a consensus either way, was not sufficient.  "Roughly the 
same response" for/against the question would seem to me to be as valid a 
result as explicit consensus one way or the other, and the act of taking a show 
of hands to survey the appeared to treat the hum as irrelevant, rather than 
highly significant. 

- Ralph

Re: stability of iana.org URLs

[Amanda Baber]

Hi,

The link in RFC3315 is actually incorrect -- it should have been 
http://www.iana.org/assignments/enterprise-numbers, without the file extension, 
and there's an erratum about this. HTML was generally (if not exclusively) 
reserved for files that needed to include links to registration forms .

As Barry said, we do intend to keep that same short 
http://www.iana.org/assignments/example format working for every current page, 
even the newly-created ones. We also prefer to see that format used in 
documents, since we can't guarantee that the file extension used for the long 
version won't change. (This information will be appearing on the website in 
some form.)


Also, if you find that a formerly-valid URL (like one that used to have an 
.html exception) isn't redirecting to the current page, please report it to 
i...@iana.org. A redirect should have been set up.

thanks,

Amanda Baber
IANA Request Specialist
ICANN

On Wed Jul 31 14:06:28 2013, barryle...@computer.org wrote:
> > I just followed http://www.iana.org/assignments/enterprise-numbers.html
> > From RFC3315 (DHCPv6)'s reference section.  Ten years later, the URL
> > doesn't work.
> >
> > I know that things were reworked when we went to XML based storage, but
> > I thought that the old URLs would at least have a 301 error on them.
> >
> > I discovered that dropping the .html gets me the right data at:
> >   http://www.iana.org/assignments/enterprise-numbers
>
> Yes: that's the form that IANA would like you to use.  They changed
> their registries from HTML to XML, and the URLs changed.  Supposed
> they should decide to turn them all into JSON (aie!)... the
> URLs would change again.  But the suffix-less version will always
> work.
>
> When I've done AD reviews of documents that cite IANA URLs, I've given
> the authors that feedback, and suggested the change to the suffix-less
> URLs.  I also intend to suggest to IANA (thanks to a document author,
> and I've since forgotten who it was; sorry) that they post permalinks
> in all the registries, so people will know which URL they ought to
> use, and not have to guess.
>
> Barry, Applications AD
>