IAB Chair | 29 Aug 00:27 2014

IETF blog post on OpenStand

I just want to make people aware of this recent blog post.  It has been two years since the OpenStand
principles were published, and I still think they are important.

The blog post is here:
http://www.ietf.org/blog/2014/08/celebrating-the-importance-of-openstand/

The OpenStand web sire is here:
http://open-stand.org/

Russ Housley
IAB Chair

IAB Chair | 27 Aug 20:18 2014

Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking"

This is a call for review of "Architectural Considerations in Smart Object Networking" prior to potential
approval as an IAB stream RFC.

The document is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/

The Call for Review will last until 24 September 2014.  Please send comments to iab <at> iab.org.

On behalf of the IAB,
   Russ Housley
   IAB Chair

Dave Crocker | 27 Aug 06:12 2014
Picon

draft-dukhovni-opportunistic-security-04

Folks,

A new version of the draft was issued today.

And the Sponsoring AD promptly decided that there is IETF consensus on
the draft, scheduling it for the next IESG telechat.  The Sponsoring AD
has deemed all changes since the -02 version is minor.

This is spite of the fact that /nearly every word/ of the newest draft
is new.

Yes, really:

https://www.ietf.org/rfcdiff?url1=draft-dukhovni-opportunistic-security-03&difftype=--hwdiff&submit=Go!&url2=draft-dukhovni-opportunistic-security-04

I did another detailed review of the draft:

     http://www.ietf.org/mail-archive/web/saag/current/msg05531.html

including:

> Summary:
> 
>    The paper defines and explains flexible approach to the use of
> encryption on the Internet.  It assigns the term 'opportunistic
> security' to this term.
> 
>    The latest draft has extensive changes from the previous version.
> 
>    Although many of the changes are quite helpful, the document still
(Continue reading)

Tim Chown | 27 Aug 00:12 2014
Picon

Re: Hawaii Block - going, going, gone for Saturday

On 26 Aug 2014, at 22:32, John Levine <johnl <at> taugh.com> wrote:

> I booked a few days ago, and it said they were sold out of IETF rooms
> on Saturday the 8th, but were OK for the rest of the week.
> 
> Are more people arriving early than used to be the case?

If I travel from Europe to North America, I always land on the Saturday before, and leave on the Friday
evening.  If you fly Sunday to Friday the hike in fare for not flying over one Saturday night is noticeable.
I’d imagine that’s not uncommon. 

Tim

Brian E Carpenter | 24 Aug 22:01 2014
Picon

Re: Is traffic analysis really a target (was Re: [saag] Is opportunistic unauthenticated encryption a waste of time?)

On 25/08/2014 07:06, Michael StJohns wrote:
> At 12:32 PM 8/24/2014, Eric Burger wrote:
>> I am concerned with the drive to make all traffic totally opaque. I’ll be brief: we have an existence
proof of the mess that happens when we make all traffic look benign. It is called “everything over port
80.” That ‘practical’ approach drove the development of deep packet inspection, because
everything running over port 80 was no longer HTTP traffic. It meant we could no longer prioritize traffic
(in a good sense - *I* want to make sure my VoIP gets ahead of my Web surfing ahead of my FTP). It meant we could
no longer apply enterprise policy on different applications. It drove ‘investment’ in the tools
that today dominate pervasive monitoring.
>>
>> Good job folks for unintended consequences.
> 
> 
> For a longer and more complete discussion on this, please see also RFC3639.  

RFC3205 (BCP56) said some of it a bit earlier, and was ignored. I'd say that
RFC3639 was ignored too. For a practical lesson on the same topic, I suggest
a critical study of all the RTCWEB drafts and of draft-ietf-dart-dscp-rtp.
I think they show the depth of the hole we are in.

   Brian

> It was drafted at a time a national actor was contemplating blocking VoIP traffic at the actor's borders so
it could tariff voice traffic by forcing it onto the PTT POTS system. 
> 
> There will be unintended consequences for whatever this OS thing ends up getting called.  It would be nice
if we could do enough design and analysis prior to deployment to turn them into "carefully considered,
more good for the user than harm to the network" consequences.
> 
> Later, Mike
(Continue reading)

Eric Burger | 24 Aug 18:32 2014

Re: Is traffic analysis really a target (was Re: [saag] Is opportunistic unauthenticated encryption a waste of time?)

I am concerned with the drive to make all traffic totally opaque. I’ll be brief: we have an existence proof
of the mess that happens when we make all traffic look benign. It is called “everything over port 80.”
That ‘practical’ approach drove the development of deep packet inspection, because everything
running over port 80 was no longer HTTP traffic. It meant we could no longer prioritize traffic (in a good
sense - *I* want to make sure my VoIP gets ahead of my Web surfing ahead of my FTP). It meant we could no longer
apply enterprise policy on different applications. It drove ‘investment’ in the tools that today
dominate pervasive monitoring.

Good job folks for unintended consequences.

On Aug 23, 2014, at 5:33 PM, Stephen Farrell <stephen.farrell <at> cs.tcd.ie> wrote:

> 
> Hiya,
> 
> On 23/08/14 22:05, Bernard Aboba wrote:
>> Stephen Farrell:
>>> However, say we're wrong and someone who thinks OS is a waste of
>>> time is actually correct, what would such a person recommend that
>>> we do as well as, or instead of, OS?
>> 
>> [BA] It depends on who we are trying to protect, and from what (or
>> whom). 
> 
> Sure.
> 
>> If the target is protection of dissidents from oppressive
>> regimes, then you need something much more comprehensive than
>> 'unauthenticated opportunistic encryption" (e.g. along the lines of
>> Tor). 
(Continue reading)

Dave Crocker | 23 Aug 19:25 2014
Picon

The challenges of survey research (was Re: vacation locations)

The IETF periodically conducts a poll, such as after every meeting.

An NPR article this week reminded me of the concerns we should have
about doing surveys:

     A Tale Of Two Polls

     http://www.npr.org/blogs/ed/2014/08/20/341668003/a-tale-of-two-polls

The URL includes the tape and a transcript.  Listen first, and then look
at the last line of the article.

Surveys are known to be quite sensitive to sampling, wording, and
organization.  Ask the same question in different ways and you are
likely to get different answers.  Ask the wrong people, and of course
you'll get wrong answers.

For example, our recent survey on meeting venue preferences queried the
entire community.  Most IETF meeting attendees are well-funded and have
plenty of travel time.  Not surprisingly, most pointed at popular
tourism sites, some of which are not all that convenient to very many
IETF participants.

If we want to improve IETF diversity at meetings, we need to hold the
meetings at places that are convenient, with good, inexpensive hotel and
food options near the main venue.

If we do a survey about venues, we need to talk to folk with limitations
in travel funds, travel time or constraints on food and possibly other
'resource' requirements.
(Continue reading)

Phillip Hallam-Baker | 22 Aug 22:23 2014

Re: There should be a design pattern, not patterns.

On Fri, Aug 22, 2014 at 7:36 AM, Tom Thorogood <me <at> tomthorogood.co.uk> wrote:
>
>
>> On 21 Aug 2014, at 1:28 am, Phillip Hallam-Baker <phill <at> hallambaker.com> wrote:
>>
>> It is now possible to make a complicated DNS discovery request for the
>> same latency cost as traditional A record look up:
>>
>> Traditional query:
>>   example.com ? A
>>
>> Complex discovery
>>   example.com ? A
>>   example.com ? AAAA
>>   _http._tcp.example.com ? SRV
>>   _http._tcp.example.com ? POLICY
>>   _80.example.com ? TLSA
>
> Just to weigh in solely on your example here. I don't believe it makes complete sense to query A/AAAA
records for example.com at that point. Until the SRV record has been queried you can't know what server the
http protocol is handled by. Or is this a form of collateral where that query takes place to quicken legacy
lookups? (Those lacking SRV records).
>
> Apologies if any of this is off track at all.

The reason that you would do that is that it allows an SRV record to
dominate the A/AAAA when it is present. So the algorithm for discovery
would be

* Was an SRV record returned? If so us it and expect that the A/AAAA
(Continue reading)

Melinda Shore | 22 Aug 20:55 2014
Picon

Re: Vacation locations

On 8/22/14 10:36 AM, Michael StJohns wrote:
> As for the cost of getting to/staying in Hawaii - if I averaged out
> the cost of my various IETF plane tickets over say the last 5 years,
> I would say that this is probably pretty close or below that average.
> I would also say that the hotel costs are comparable and that the
> travel times are within a sigma of my average over the last 5 years.

Because of my situation (living in interior Alaska), travel nearly
anywhere takes multiple flight segments and at least the better
part of a day.  And because of my personal proclivities, Hawaii
in November sounds like a slice of hell.  For me the clincher
is the likely unavailability of decent low-cost food (Orlando
was absolutely awful on that front), and if I go at all I'll only stay
a few days, strictly because of the venue.  But that's me.

Everybody's different, so reasonable compromises seem reasonable.
(Although I still don't understand why we're not returning to
Minneapolis).  The size of the meeting and the need for a large
number of sessions in parallel is likely to drive nearly all
other  considerations, I think.

Melinda

John C Klensin | 22 Aug 19:39 2014

Vacation locations (was: Re: [Recentattendees] Were You Planning a Vacation Around IETF91 Trip?)


--On Friday, August 22, 2014 11:47 -0400 Ray Pelletier
<rpelletier <at> isoc.org> wrote:

> All;
> 
> When we were first contracting with the Hilton for IETF 91 the
> Hilton was asked about the possibility  of offering some
> special deals at their other properties in Hawaii for IETFers
> before and after the  scheduled meeting.
>...

Ray, 

I'm confident that the meeting committee isn't choosing
locations based on where its members would like to vacation and
hope that confidence is justified.  As others have commented, a
Waikiki Beach location fairly screams "boggle" to corporate
travel departments who are sensitive to such things, that (by
reputations and in my experience from several years ago) it is
an expensive area to do much of anything, and that Honolulu is
an expensive place to get to for many of us who attend IETF
without institutional sponsorship.   Given that, I find the idea
that you and/or the IAOC would include a discussion of packaging
that IETF meeting with vacation packages insensitive and
troubling. 

Perhaps no one actually cares.  But, if any corporate or
organizational travel departments get access to your note and
respond, e.g., "we thought this was a boggle, you said it
(Continue reading)

Andrew Allen | 22 Aug 17:15 2014

RE: Hawaii Block - going, going....

I was just able to book king bed resort room - but only from Sunday through to Saturday. 

It would seem to be an issue if you want to come a day or two early though (not available Friday and Saturday
before IETF starts)

-----Original Message-----
From: ietf [mailto:ietf-bounces <at> ietf.org] On Behalf Of Michael StJohns
Sent: Friday, August 22, 2014 12:56 AM
To: ietf <at> ietf.org
Subject: Hawaii Block - going, going....

I saw the email for the Hawaii IETF registration when I got home about 30 minutes ago.  I immediately got
online to book the hotel, and as of 12:48 (exactly 3 hours after the announcement), all of the Ocean View
rooms are gone as well as the King bed resort view rooms, leaving only the 2 Double Bed  resort view rooms. 
Impressive take rate (assuming at least somewhat even distribution between King and DB rooms).

I wouldn't be surprised to find the block filled by sometime tomorrow.

Mike


Gmane