[ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt

[Tim Chown]

Hi,

In the dnssd WG, we are developing methods to enable scalable DNS-based service 
discovery, which in practice means enabling mDNS/DNS-SD to work over multiple 
links within a site. As defined, mDNS/DNS-SD are link-local protocols, not 
forwarded by routers. If successful, one ‘win’ is that users with devices can 
discover services that may be physically near them, but that lie in a different 
subnet.

At a high level, the proposed solution works by clients/resolvers sending 
queries to hybrid proxies running on specific subnets (which may be manually 
configured in an enterprise scenario, or auto-discovered in an unmanaged home 
network scenario), which then issue local service discovery messages, the 
answers to which are relayed back to the originating querier.

We’re encouraging discussion of privacy considerations in the WG. As a result, 
we now have a draft (see below), including an initial proposal for a solution, 
for which we’d welcome wider review. The draft also addresses mDNS/DNS-SD 
privacy within single subnet scenarios.

Feel free to comment here, or join the dnssd WG list and contribute there.

Many thanks,
Tim & Ralph, dnssd WG co-chairs

Begin forwarded message:

From: Christian Huitema >
Subject: [dnssd] FW: New Version Notification for 
draft-huitema-dnssd-privacy-01.txt
Date: 10 June 2016 at 21:02:50 BST
To: "dn...@ietf.org" 
>
Cc: Daniel Kaiser 
>

Here is a new version of the "DNS-SD Privacy" draft. I co-authored it with 
Daniel Kaiser. Daniel is completing his PhD at the University of Konstanz, in 
Germany, studying issues related to privacy and discovery. This new draft is in 
my opinion much improved from the version 00 that I presented in Buenos Aires. 
You can read the abstract below for the broad lines of the proposed solution. 
Or, better yet, read the draft and comment!

-- Christian Huitema



-Original Message-
From: internet-dra...@ietf.org 
[mailto:internet-dra...@ietf.org]
Sent: Friday, June 10, 2016 12:35 PM
To: Christian Huitema >; 
Daniel Kaiser 
>
Subject: New Version Notification for draft-huitema-dnssd-privacy-01.txt


A new version of I-D, draft-huitema-dnssd-privacy-01.txt
has been successfully submitted by Christian Huitema and posted to the IETF 
repository.

Name: draft-huitema-dnssd-privacy
Revision: 01
Title: Privacy Extensions for DNS-SD
Document date: 2016-06-10
Group: Individual Submission
Pages: 26
URL:
https://www.ietf.org/internet-drafts/draft-huitema-dnssd-privacy-01.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/
Htmlized:   https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01
Diff:   https://www.ietf.org/rfcdiff?url2=draft-huitema-dnssd-privacy-01

Abstract:
  DNS-SD allows discovery of services published in DNS or MDNS.  The
  publication normally discloses information about the device
  publishing the services.  There are use cases where devices want to
  communicate without disclosing their identity, for example two mobile
  devices visiting the same hotspot.

  We propose to solve this problem by a two-stage approach.  In the
  first stage, hosts discover Private Discovery Service Instances via
  DNS-SD using special formats to protect their privacy.  These service
  instances correspond to Private Discovery Servers running on peers.
  In the second stage, hosts directly query these Private Discovery
  Servers via DNS-SD over TLS.  A pairwise shared secret necessary to
  establish these connections is only known to hosts authorized by a
  pairing system.




Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat

___
dnssd mailing list
dn...@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


___
ietf-privacy mailing list
ietf-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy

Re: NOMCOM - Time-Critical - Final Call for Nominations

[Tim Chown]

Hi,

On 17 Oct 2013, at 15:09, NomCom Chair 2013 nomcom-chair-2...@ietf.org wrote:

 A critically low number of people have accepted nominations for some of the 
 IESG open positions.  There is only one nominee per slot in APP, OPS and TSV, 
 only two in INT and RAI.  Many folks have declined nominations.  
 
 While the Nomcom appreciates that support for two years of intense service 
 is hard to assure, and while we are aware that there is much support for the 
 incumbents who are standing, the IETF should continually be considering
 which new talent is available for our leadership, and the Nomcom process 
 needs for there to be some review and deliberation. 

I believe the intense service you mention is a significant deterrent for many.

I'm sure it's been suggested before, but is there mileage in rethinking the 
AD roles, and either the number of ADs per area, or whether introducing 
Assistant ADs or similar might allow people who can contribute less time to 
do so, while easing the burden on the main ADs?

Just a thought anyway. Personally, I'd assume that some people would be 
more willing to help if deemed to have the skills required, but the time 
constraints are, as many ADs will confirm if you chat with them, the blocking
factor.

Tim

Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

[Tim Chown]

On 3 Oct 2013, at 18:07, manning bill bmann...@isi.edu wrote:

  - The following addresses had permanent fatal errors -
 dnssdext-requ...@ietf.org
   (reason: 550 5.1.1 dnssdext-requ...@ietf.org: Recipient address rejected: 
 User unknown in virtual alias table)

I think the active list is still mdns...@ietf.org?
See: http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html

And the 'header' information below should now probably read something like this:

--- snip ---

Scalable DNS Service Discovery  (dnssd)

Current Status: Proposed WG

Chairs:
 Ralph Droms rdroms.i...@gmail.com
 Tim Chown t...@ecs.soton.ac.uk

Assigned Area Director:
 Ted Lemon ted.le...@nominum.com

Mailing list
 Address: dn...@ietf.org
 To Subscribe: dnssd-requ...@ietf.org
 Archive: http://www.ietf.org/mail-archive/web/dnssd
 Pre-WG BoF Archive: http://www.ietf.org/mail-archive/web/mdnsext 


--- snip ---

Tim

 
 
 
 On 3October2013Thursday, at 8:42, The IESG wrote:
 
 A new IETF working group has been proposed in the Internet Area. The IESG
 has not made any determination yet. The following draft charter was
 submitted, and is provided for informational purposes only. Please send
 your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-10.
 
 Extensions for Scalable DNS Service Discovery  (dnssd)
 
 Current Status: Proposed WG
 
 Chairs:
 Ralph Droms rdroms.i...@gmail.com
 Tim Chown t...@ecs.soton.ac.uk
 
 Assigned Area Director:
 Ted Lemon ted.le...@nominum.com
 
 Mailing list
 Address: dnssd...@ietf.org
 To Subscribe: dnssdext-requ...@ietf.org
 Archive: http://www.ietf.org/mail-archive/web/dnssdext
 
 Charter:
 
 Background
 --
 
 Zero configuration networking protocols are currently well suited to
 discover services within the scope of a single link.  In particular,
 the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
 referred to using Apple Computer Inc.'s trademark, Bonjour) are
 widely used for DNS-based service discovery and host name resolution
 on a single link.
 
 The DNS-SD/mDNS protocol suite is used in many scenarios including
 home, campus, and enterprise networks.  However, the zero configuration
 mDNS protocol is constrained to link-local multicast scope by design,
 and therefore cannot be used to discover services on remote links.
 
 In a home network that consists of a single (possibly bridged) link,
 users experience the expected discovery behavior; available services
 appear because all devices share a common link.  However, in multi-link
 home networks (as envisaged by the homenet WG) or in routed campus or
 enterprise networks, devices and users can only discover services on
 the same link, which is a significant limitation.  This has led to
 calls, such as the Educause petition, to develop an appropriate service
 discovery solution to span multiple links or to perform discovery across
 a wide area, not necessarily on directly connected links.
 
 In addition, the Smart Energy Profile 2 Application Protocol Standard,
 published by ZigBee Alliance and HomePlug Powerline Alliance specifies
 the DNS-SD/mDNS protocol suite as the basis for its method of zero
 configuration service discovery.  However, its use of wireless mesh
 multi-link subnets in conjunction with traditional routed networks will
 require extensions to the DNS-SD/mDNS protocols to allow operation
 across multiple links.
 
 The scenarios in which multi-link service discovery is required may
 be zero configuration environments, environments where administrative
 configuration is supported, or a mixture of the two.
 
 As demand for service discovery across wider area routed networks
 grows, some vendors are beginning to ship proprietary solutions.  It
 is thus both timely and important that efforts to develop improved, 
 scalable, autonomous service discovery solutions for routed networks 
 are coordinated towards producing a single, standards-based solution.
 
 The WG will consider the tradeoffs between reusing/extending existing
 protocols and developing entirely new ones.  It is highly desirable
 that any new solution is backwardly compatible with existing DNS-SD/mDNS
 deployments.  Any solution developed by the dnssd WG must not conflict
 or interfere with the operation of other zero-configuration service and
 naming protocols such as uPnP or LLMNR.  Integration with such protocols
 is out of scope for this WG.
 
 The focus of the WG is to develop a solution for extended, scalable 
 DNS-SD.  This work is likely to highlight problems and challenges with 
 naming protocols, as some level of coexistence will be required between 
 local zero configuration name services and those forming part of the 
 global DNS.  It is important that these issues are captured and 
 documented for further analysis; solving those problems is however not 
 within the scope of this WG.
 
 Working Group Description

Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

[Tim Chown]

On 7 Sep 2013, at 04:05, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:

 From: Scott Brim scott.b...@gmail.com
 
 The encapsulation is not much of an obstacle to packet examination.
 
 There was actually a proposal a couple of weeks back in the WG to encrypt all
 traffic on the inter-xTR stage.
 
 The win in doing it in the xTRs, of course, is that you don't have to go
 change all the hosts, application by application: _all_ traffic, of any kind,
 from that site to any/all other sites which are encryption-enabled, will get
 a certain degree of confidentiality.
 
 Does this count as something the IETF can do reasonably quickly that will
 help somewhat? :-)

It certainly wouldn't hurt :)

Tim

Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

[Tim Chown]

On 6 Sep 2013, at 21:32, Roger Jørgensen rog...@gmail.com wrote:

 On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak interf...@gmail.com wrote:


 The IETF focused on developing protocols (and reserving the necessary
 network numbers) to facilitate direct network peering between private
 individuals, it could make it much more expensive to mount large-scale
 traffic interception attacks.
 
 Think there are work being done on the topic? However, how are you
 going to interconnect all of this private peerings? It sort of imply
 that everyone need to have their own netblock they can exchange with
 others.

Mobile IPv6 gives one way to run multiple devices in one subnet. Someone needs 
to be the HA though. And/or if future homes have multiple /64's, it's not 
infeasible to dedicate one or more to virtual/overlay LANs.

Tim

Re: Rude responses (sergeant-at-arms?)

[Tim Chown]

Isn't there supposed to be a sergeant-at-arms to handle inappropriate behaviour 
on this list?

Though the last I recall that was Jordi, and that was probably ten years ago...

Though it would be preferable if everyone were a bit more respectful of other 
posters, whether new or veteran.

Tim

Re: IETF 88 - Registration Now Open!

[Tim Chown]

On 23 Aug 2013, at 18:49, manning bill bmann...@isi.edu wrote:

 and the hotel is fully booked….

I guess it got fixed Bill, though I only booked for the meeting week itself.

tim

 
 /bill
 
 
 On 23August2013Friday, at 6:36, IETF Secretariat wrote:
 
 88th IETF Meeting
 Vancouver, BC, Canada
 November 3-8, 2013
 Host: Huawei
 
 Meeting venue:  Hyatt Regency Vancouver: 
 http://vancouver.hyatt.com/en/hotel/home.html
 
 Register online at: http://www.ietf.org/meetings/88/
 
 1.  Registration
 2.  Visas  Letters of Invitation
 3.  Accommodations
 4.  Companion Program
 
 
 1. Registration
 A. Early-Bird Registration - USD 650.00 Pay by Friday, 25 October 2013 UTC 
 24:00
 B. After Early-Bird cutoff - USD 800.00
 C. Full-time Student Registrations - USD 150.00 (with proper ID)
 D. One Day Pass Registration - USD 350.00
 E. Registration Cancellation   
 Cut-off for registration cancellation is Monday,
 28 October 2013 at UTC 24:00.
 Cancellations are subject to a 10% (ten percent)
 cancellation fee if requested by that date and time.
 F. Online Registration and Payment ends Friday, 1 November 2013, 1700 local 
 Vancouver time.
 G. On-site Registration starting Sunday, 3 November 2013 at 1100 local 
 Vancouver time.
 
 2. Visas  Letters of Invitation:
 Information on Visiting Canada, please visit:
 http://www.cic.gc.ca/english/visit/index.asp
 
 After you complete the registration process, you can request an electronic 
 IETF letter of invitation as well. The registration system also allows for 
 you to request a hard copy IETF letter of invitation. You may also request 
 one at a later time by following the link provided in the confirmation email.
 
 Please note that the IETF Letter of Invitation may not be sufficient for 
 obtaining a visa to enter Canada.
 
 3.  Accommodations
 The IETF is holding a block of guest rooms at the Hyatt Regency Vancouver, 
 the meeting venue, as well as at the overflow hotel Fairmont Hotel 
 Vancouver, which is located across the street from the Hyatt.
 Room Rates include in room high-speed Internet access. Taxes of 16.5% (hotel 
 room tax, GST and Destination Management Fee) are excluded from the 
 guestroom rate and are subject to change. Room rates DO NOT include daily 
 breakfast.
 
 Reservations Cut off Date: 
  Hyatt Regency Vancouver - 20 October 2013
  Fairmont Hotel Vancouver - 11 October 2013
 
 For additional information on rates and policies, please visit: 
 http://www.ietf.org/meetin/88/hotel.html
 
 4.  Companion Program
 If you are traveling with a friend or family member over 18 years of age you 
 can register them for the IETF Companion Program for only USD 25.00
 
 Benefits include:
 - A special welcome reception for companions from 1630-1730 on Sunday, 3 
 November
 - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 
 3 November
 - A distinctive meeting badge that grants access to the venue (not to be 
 used to attend working sessions)
 - Participation in a separate companion email list if you choose to help 
 communicate and make plans with other IETF Companions.
 
 You can register your companion at any time via the IETF website or onsite 
 at the meeting.
 
 To join the 88 companions mailing list only see:
 https://www.ietf.org/mailman/listinfo/88companions
 
 Only 71 days until the Vancouver IETF!
 

Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)

[Tim Chown]

On 4 Aug 2013, at 20:53, John Levine jo...@taugh.com wrote:

 If there is a serious drive to discontinue the weekly posting
 summary - I strongly object.
 
 As far as I can tell, one person objects, everyone else thinks it's fine.
 
 Seems like rough consensus to me.

And the code is running…

Tim

Re: dnssdext BOF (was: Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info))

[Tim Chown]

On 27 Jul 2013, at 02:20, Phillip Hallam-Baker hal...@gmail.com wrote:

 If I had known this was taking place I might have made the trip to Berlin.
 
 I am very interested in the problem this tries to solve. I think it is the 
 wrong way to go about it but I am interested in the problem.
 
 The case for having some sort of local name discovery mechanism is clear in 
 both the enterprise and the home network. The case for that discovery 
 mechanism responding to DNS queries in the local namespace is equally clear.
 
 Thinking of this problem as how to clients configure their DNS entries is 
 completely the wrong way to go about it. Setting up a new network service 
 requires more than poking the DNS with a stick.

Phil, comments on draft-lynn-mdnsext-requirements are very welcome.

There should be a jabber realy who can forward remote comments to the mic.

Tim

Re: BOF posters in the welcome reception

[Tim Chown]

On 26 Jul 2013, at 07:36, Abdussalam Baryun abdussalambar...@gmail.com wrote:

 On 7/24/13, John C Klensin john-i...@jck.com wrote:
 
 --On Wednesday, July 24, 2013 09:22 +0300 IETF Chair
 ch...@ietf.org wrote:
 
 I wanted to let you know about an experiment we are trying out
 in Berlin.
 ...
 But we want as many people as possible to become involved in
 these efforts, or at least provide their feedback during the
 week. So we have given an opportunity for the BOFs to display
 a poster in the Welcome Reception (Sunday 5pm to 7pm). If you
 are attending the reception, take a look at the posters and
 look for topics that interest you.
 
 What about each poster state which WG/RFCs it is mostly
 depending-on/related (if applicable), this can make an easier way to
 know if I am interested or should be interested.

The poster deadline passed some time ago. The easiest way to decide if you're 
interested though is to read the poster, assuming it is well-written :)

The conference-style poster idea came up quite late this year. It's a good 
idea, and is hopefully something that can be improved for IETF88 and beyond.  I 
suspect the idea arose from IETF87 having an unusually high number of BOFs.

Tim

Re: dnssdext BOF (was: Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info))

[Tim Chown]

On 26 Jul 2013, at 21:48, John C Klensin john-i...@jck.com wrote:

 
 
 --On Friday, July 26, 2013 11:29 -0700 SM s...@resistor.net
 wrote:
 
 POSH has not published a session agenda.  However, the BoF is
 listed on the meeting agenda.  Is the BoF cancelled or will
 this be one of those willful violations of IETF Best Current
 Practices?
 
 On a similar note, according to its agenda, the core of the 
 DNS-SD Extensions BOF (dnssdext) is apparently
 draft-lynn-sadnssd-requirements-01.  The link from the agenda
 page [1] yields a 404 error and attempts to look up either
 draft-lynn-sadnssd-requirements or the author name lynn in
 the I-D search engine yield nothing.

Hi John,

Apologies for this. The correct draft name, and the BoF chair contacts, are now 
in the agenda file at: https://datatracker.ietf.org/meeting/87/agenda/dnssdext/

 FWIW, I also note that the posted agenda is heavily dependent on
 the Chairs and mentions an agreed charter.   

That means the charter agreed from the bashing of the draft charter in the 
previous 40 minutes, not that a charter is already agreed.

 I am mentioning this on the IETF list only because it is another
 example of the point that I (and probably SM and others) are
 trying to make:  If we are interested in newcomers, remote
 participants without years of IETF experience, and/or increased
 diversity, we should not allow these kinds of issues to become
 requirements for treasure hunts or other sorts of obstacles in
 people's paths.

True. Though the chair names are on the posters linked in the materials page, 
which I assume is well-advertised to newcomers as access to slides is rather 
important.  And also on the BoF wiki, which you should know about.  The names 
were just missing from the agenda file itself.

Tim

Re: dnssdext BOF (was: Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info))

[Tim Chown]

On 26 Jul 2013, at 23:31, John C Klensin john-i...@jck.com wrote:

 --On Friday, July 26, 2013 22:48 +0100 Tim Chown
 t...@ecs.soton.ac.uk wrote:
 
 That means the charter agreed from the bashing of the draft
 charter in the previous 40 minutes, not that a charter is
 already agreed.
 
 If there is something to be bashed for those 40 minutes, I'd
 expect a link to at least a skeleton first draft. I note that
 draft charter does have a link from the meeting materials page,
 just not from the agenda.   But, modulo the comment below, that
 is a matter of taste to be working out between you, Ralph, and
 the IESG.

The draft charter was placed where they usually are, on the BoF wiki.  But I 
added a link to a specific draft charter file when I updated the agenda, see 
https://datatracker.ietf.org/meeting/87/agenda/dnssdext/.

The other problem for mdnsext is that the second BoF has been given a 
different name, for various reasons, but that does make it a bit harder to 
locate the mail list and draft. 

 True. Though the chair names are on the posters linked in the
 materials page, which I assume is well-advertised to newcomers
 as access to slides is rather important.
 
 As far as I know, the only advertisement is the link from the
 Agendas and Meeting Materials section of the main meeting page
 and the similar links from the Meetings entry on the IETF home
 page.  Now I'd personally like to see the New Attendees
 category on the main meeting page changed to New Attendees and
 Participantes and then including a link to a page that would
 give hints about where these things are and how to navigate
 around them.  But that fairly clearly won't happen before Sunday
 and YMMD. 

Well, I would certainly agree that the meeting materials page/area needs to be 
well advertised, if it isn't already, but I don't know what additional 
information newcomers are pointed at, not being one.

 And also on the BoF wiki, which you should know about.  
 
 Yep.  I know about it and where to find it.  But, as I explained
 in my note to Brian, I'm a lot more concerned about newcomers
 and remote participants without years or experience than I am
 about what I can find if I remember all of the reasonable places
 where I might look.


While we/you can try to guess what the problems are, it may be better to 
surveymonkey those who registered as newcomers in a couple of weeks and ask 
them about their experience, whether they were aware of certain things, and 
what could be done better.

Tim

Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception

[Tim Chown]

On 24 Jul 2013, at 16:18, Jari Arkko jari.ar...@piuha.net wrote:

 Janet,
 
 I am another remote participant who would like to be able to subscribe to 
 the meeting-specific mailing list. 
 
 I can skip (myself)  the ones about coffee and cookies, but definitely want 
 to read the ones about schedule changes, etc. 
 
 And even the other messages give me a taste of what it would be like to be 
 there. 
 
 Understood. I'm wondering if this points to a need to get on the meeting list 
 easily. Either without registering, or having a registration flag of being 
 interested in the meeting while not intending to be there.
 
 We could create another mailing list too, but I'm a little sensitive for 
 creating many slightly different mailing lists (duplicate messages, posting 
 accidentally on the wrong one, etc)

I see no reason why the 87attend...@ietf.org list shouldn't be open to remote 
participants. Is that not the case already? We should be doing all we can to 
encourage participation.

I would share the concerns of duplication if an 87rem...@ietf.org list were set 
up, but it might be useful for those who aren't there to be able to discuss 
issues, tips, etc with remote participation.

A lot of meeting topics do come up on the main ietf list too, of course.

Tim

Re: IETF 87 Registration Suspended

[Tim Chown]

On 5 Jul 2013, at 15:30, John C Klensin j...@jck.com wrote:

 --On Friday, July 05, 2013 07:40 +0100 l.w...@surrey.ac.uk wrote:
 
 It strikes me that 'membership fees' as opposed to 'entrance
 fees' could work around this payment issue. Or incur a
 different tax...
 
 But the use of a term like membership fee has profound
 implications for what the IETF claims is our way of doing
 business.

I would add also that many organisations (and funding bodies) would not support 
claims for membership fees where conference meeting registration fees are 
perfectly accepted.

Tim

Berlin BoFzilla

[Tim Chown]

So I was looking at http://trac.tools.ietf.org/bof/trac/wiki/WikiStart to check 
the sdnssd BoF text, and was surprised to see a total of 15 proposed BoFs. That 
seems to be something of a record?

That people are coming to the IETF with proposals to do work is probably a 
healthy thing; it would be more worrying if there were no BoFs proposed. But if 
all the proposals are accepted, and they all lead to WGs being formed, that's a 
lot of new groups to be created, scheduled and supported.

In contrast, how many WGs have been closed in the past few months? I see 
there's http://trac.tools.ietf.org/wg/concluded from which I can see there are 
10 WGs listed there which seem to have closed this year:
iri 2013-01-19
imapmove 2013-01-31
csi 2013-02-12
sipclf 2013-02-20
bliss 2013-02-27
simple 2013-02-27
fecframe 2013-03-06
krb-wg 2013-03-19
eai 2013-03-19
6tch 2013-04-19

I wonder how the volume and lifetimes of WGs has changed over the years, e.g. 
the number we have, how quickly they complete their work, etc. Has anyone been 
looking at this?

Tim

Re: Weekly posting summary for ietf@ietf.org

[Tim Chown]

On 7 Jun 2013, at 16:52, Ted Lemon ted.le...@nominum.com wrote:

 On Jun 7, 2013, at 11:48 AM, Andy Bierman a...@yumaworks.com wrote:
 So why not move the signal?
 Put IETF Last Call mail on last-c...@ietf.org and leave this list for 
 everything else.
 
 The discussion still has to happen somewhere.   I certainly am not 
 restricting my meaningful participation in last calls, but even in that case 
 it is important to be restrained and not get into long fruitless discussions, 
 which, I am afraid, I am wont to do.

It's a significant problem for those who *have* to read the threads, in 
particular document authors, WG chairs, and ADs. Hats off to them for keeping 
up with it where they need to.

As another example, the v6ops list has recently also had four threads run well 
over the 100 message count, specifically end to end response time, ULA usage, 
being careful about ULAs and the semantic prefix thread. 

Of course, a healthy debate is a good thing, as is having an open process for 
discussion. If we had very few comments that would certainly not be good 
either. But I fear that some valuable contributions are either being drowned 
out, or that some people with valuable input are being put off contributing.

Tim

Re: Weekly posting summary for ietf@ietf.org

[Tim Chown]

On 7 Jun 2013, at 17:12, joel jaeggli joe...@bogus.com wrote:

 On 6/7/13 6:03 PM, Tim Chown wrote:
 
 As another example, the v6ops list has recently also had four threads run 
 well over the 100 message count, specifically end to end response time, ULA 
 usage, being careful about ULAs and the semantic prefix thread.
 v6ops had a single draft which attracted ~1100 messages over the course of a 
 year so this isn't new or unusual over there. A small number of posters tend 
 to be the majority of the volume on several topics, so if you're reading to 
 understand the positions of the working group or to measure consensus on the 
 list some judicious sorting is required.

Indeed.  Sorting and sifting through 500+ emails about one homenet topic over 
on 6man was similarly challenging (for the homenet arch text).  And many of 
those long v6ops threads were/are relevant to that.

It would be nice to determine some way to keep discussions open, without 
creating unnecessary volume, and repeating already raised arguments. 

Maybe the answer isn't email for judging consensus. As an outsider, I've seen 
the IESG/AD system, which seems to essentially allow positions on drafts to be 
expressed, and easily viewed at a glance. Maybe that's part of the answer, 
somehow. Some position view on a draft, that people can update/edit as the 
list discussion goes on, that becomes more useful at a glance for WG chairs 
and document editors?

We could continue as is with emails, but I've heard of a number of (very wise 
and valued) past contributors who no longer express their views, because of the 
problem of volume.

Or maybe it's not a valid concern.

Tim

Re: financial fun with an IETF Meeting in South America

[Tim Chown]

On 27 May 2013, at 05:15, John Levine jo...@taugh.com wrote:

 The move appears to be related to new, restrictive 
 regulations the Argentine government has imposed on currency exchanges.' 
 According to the Telegraph, 'The new regulations required anyone wanting 
 to change Argentine pesos into another currency to submit an online 
 request for permission to AFIP, the Argentine equivalent of HM Revenue  
 Customs. ...
 
 This isn't likely to change soon.

Going into the country isn't the problem, more importantly it seems that if you 
don't spend all your pesos in Argentina, you can't change them back to your own 
currency:

http://www.tripadvisor.co.uk/Travel-g294266-s601/Argentina:Banks.And.Money.html
(see last paragraph)

I just keep a pool of Euros and dollars (US and Canadian) which I never change 
back to my own currency, as I visit these countries a fair bit, but it is a 
concern to pick a venue where any cash I get in advance is lost if unspent.

Is this above advice from Tripadvisor correct?

Tim

Re: financial fun with an IETF Meeting in South America

[Tim Chown]

On 27 May 2013, at 16:37, John R Levine jo...@taugh.com wrote:

 Is this above advice from Tripadvisor correct?
 
 I believe so, but when I was there a few years ago for the ICANN meeting, 
 excess cash was not a problem.  It wasn't hard to estimate how much cash I'd 
 need, and whatever was left I spent at the airport.  The wine they drink in 
 Argentina is often better than the stuff they send to the UK (which isn't 
 bad) and much cheaper.  Take some home in your suitcase, even if you have to 
 pay duty it's a bargain.

It's not necessarily so easy over the course of seven days. But I guess we 
could also just give all our leftover cash to a deserving Argentinian IETF 
attendee.  Fernando may like that approach :)

 This still doesn't mean I think a meeting in South America is a good idea, 
 though.  See other messages.

I think Jari's views are spot on. There's a bigger picture question to address, 
regardless of the meeting venues, and not just for that region. 

Tim

Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)

[Tim Chown]

Yes, thanks all - I think we're nearly there…

Tim

On 13 May 2013, at 02:58, Liubing (Leo) leo.liub...@huawei.com wrote:

 Hi, Robert
 
 Your careful review and comments really helped improving the document a lot.
 Many thanks to you.
 
 All the best,
 Bing
 
 -Original Message-
 From: Robert Sparks [mailto:rjspa...@nostrum.com]
 Sent: Friday, May 10, 2013 11:13 PM
 To: Liubing (Leo)
 Cc: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org;
 gen-...@ietf.org; ietf@ietf.org
 Subject: Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
 (updated for -07)
 
 Thanks Bing -
 
 The updates make the document better, and I appreciate the resolution of
 referencing Tim's expired draft.
 I think you've addressed all my comments except for the one on section
 5.1, but that's ok.
 
 For completeness and ease on the ADs, here's an updated summary:
 
 Document: draft-ietf-6renum-gap-analysis-05.txt
 Reviewer: Robert Sparks
 Review Date: May 10, 2013
 IETF LC End Date: April 10, 2013
 IESG Telechat date: May 16, 2013
 
 Summary: Ready
 
 
 
 On 5/2/13 6:02 AM, Liubing (Leo) wrote:
 Hi, Robert
 
 Thanks a lot for your continuous careful review.
 Please see replies inline.
 
 -Original Message-
 From: Robert Sparks [mailto:rjspa...@nostrum.com]
 Sent: Wednesday, May 01, 2013 12:33 AM
 To: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org
 Cc: gen-...@ietf.org; ietf@ietf.org
 Subject: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
 
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please wait for direction from your document shepherd
 or AD before posting a new version of the draft.
 
 Document: draft-ietf-6renum-gap-analysis-05.txt
 Reviewer: Robert Sparks
 Review Date: April 1, 2013
 IETF LC End Date: April 10, 2013
 IESG Telechat date: May 16, 2013
 
 Summary: Ready with nits (that border on minor issues)
 
 This update improved the readability significantly, and addressed my
 major concern about being able to build a list of the gaps. Thank you.
 
 There are a few issues from my last call review that are still not
 addressed.
 I have left the classification of minor issue vs nits the same as the
 original review to make referring to the earlier review easier,
 but please consider all of these Nits. The IESG will need to decide
 whether to escalate them.
 
 I've trimmed away the points that were addressed.
 
 On 4/1/13 3:46 PM, Robert Sparks wrote:
 --
 Minor issues:
 
 The document currently references
 draft-chown-v6ops-renumber-thinkabout several times.
 That document is long expired (2006). It would be better to simply
 restate what is
 important from that document here and reference it only once in the
 acknowlegements
 rather than send the reader off to read it.
 This version still references that long expired draft. There was also
 conversation on apps-discuss
 about making that reference normative. IMHO, this is not the right way
 to treat the RFC series, and
 strongly encourage moving the text that you want to reference into
 something that will
 become an RFC.
 [Bing] Maybe Brian's suggestion of putting some texts into an appendix is a
 good way. We'll discuss this problem when make the next time update.
 
 Should section 8 belong to some other document? It looks like
 operational renumbering
 advice/considerations, but doesn't seem to be exploring renumbering
 gaps, except for
 the very short section 8.2 which says we need a better mechanism
 without much explanation.
 Afaict, this wasn't addressed at all. In particular, we need a better
 mechanism is still all that
 section 8.2 says.
 [Bing] Sorry for leaving it out. Will do in next update.
 
 Section 5.1, first bullet. The list below the impact of ambiguous M/O
 flags says things like
 there is no standard and it is unspecified. I think you are trying
 to say that there is
 ambiguity in what's written, not that nothing's written. This entire
 list would benefit from
 being recast in terms of what needs to be done (what are the gaps?).
 This text remains unmodified.
 [Bing] We made revision focusing on explaining what are the gaps, but
 the texts change was omitted, will do in next update.
 
 --
 Nits/editorial comments:
 
 There are a few sentences ending with etc. in the document. Please
 consider deleting the
 word from the list - it doesn't help each sentence make its point.
 There were some changes, but mostly these still exist. I'll leave
 pressing this point further to the RFC Editor.
 [Bing] A professional language/editorial check would be helpful.
 
 Seciton 7.1: The first bullet does not parse. If I guess its meaning
 correctly
 (that it would be benificial to tell hosts that local DNS has been
 updated and
 they may want to make fresh queries), please be careful with the
 wording. The
 hosts don't know which names are likely 

Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[Tim Chown]

On 30 Apr 2013, at 16:43, joel jaeggli joe...@bogus.com wrote:

 On 4/30/13 8:33 AM, Robert Sparks wrote:
 On 4/2/13 4:58 AM, Brian E Carpenter wrote:
 Just picking a couple of points for further comment:
 
 On 02/04/2013 08:46, Liubing (Leo) wrote:
 
 [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the 
 gap analysis. Although the draft is expired, most of the content are still 
 valid.
 draft-chown is a more comprehensive analysis, while the gap draft is 
 focusing on gaps in enterprise renumbering. So it might not easy to 
 abstract several points as important from draft-chown to this draft. We 
 actually encourage people to read it.
 Robert is right, though, sending people to a long-expired draft is a bad 
 idea.
 I'm not sure I see that as worse than referring to Wikipedia, an expired 
 draft has the property that it's not going to change. I have no problem with 
 the idea that it would be an informative reference.   but yes it's a bit much 
 to say go read this.
 Of course we have to acknowledge it, but maybe we should pull some of its 
 text
 into an Appendix.
 
 Tim Chown, any opinion?
 The most recent version (and the one slated for the next telechat) still has 
 this long-expired draft referenced.


Hi,

The old renumbering thinkabout draft came out of experiments on IPv6 
renumbering we did in 6NET some 10 (yikes!) years ago, for both enterprise and 
ISP networks. I think most of what was written is still applicable.  Brian 
borrowed a fair deal of it for RFC 5887.  I stopped work on it as there was 
little/no interest in the problem in v6ops at the time (or whatever v6ops was 
called back then). We produced technical 6NET reports separately, and did some 
follow-up work with Cisco separately.

Personally I don't mind if the principles are mentioned without the explicit 
reference - an ack in the Acknowledgements is adequate. 

It would be interesting to review the thinkabout draft to see how much still 
holds true.  Glancing at it, sections like Application and Service-Oriented 
Issues are still very much relevant. I guess Stig and I could consider 
advancing it along the Independent Submission path, or look for publication to 
an appropriate journal.  Life is short :)

Tim

Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first

[Tim Chown]

On 6 Apr 2013, at 16:39, Stewart Bryant (stbryant) stbry...@cisco.com wrote:
 
 On 6 Apr 2013, at 14:04, Abdussalam Baryun abdussalambar...@gmail.com 
 wrote:
 
 
 If the date is
 special then thoes RFCs SHOULD be *historical*.
 
 
 Surely the correct requirement is :
 
 If the date is special then those RFCs MUST be *hysterical*.

'Like' :)

Tim

Re: Time zones in IETF agenda

[Tim Chown]

On 6 Mar 2013, at 22:09, Henrik Levkowetz hen...@levkowetz.com wrote:

 
 On 2013-02-27 10:20 Tim Chown said the following:
 On 26 Feb 2013, at 20:28, Martin Rex m...@sap.com wrote:
 
 I have a recurring remote participation problem with the
 IETF Meeting Agendas, because it specifies the time of WG meeting slots
 in local time (local to the IETF Meeting), but does not give the
 local time zone *anywhere*.
 
 I would appreciate if the local time zone indication would be added
 like somewhere at the top of the page, to each IETF meeting agenda.
 
 So in this interesting discussion of UTC, Martin has actually made an
 excellent point.  Having UTC listings for the agenda would be very
 helpful, or an alternative agenda showing UTC.
 
 Now available:
 
  http://datatracker.ietf.org/meeting/agenda-utc

Many thanks, as always, Henrik.

Tim

Time zones in IETF agenda

[Tim Chown]

On 26 Feb 2013, at 20:28, Martin Rex m...@sap.com wrote:

 I have a recurring remote participation problem with the
 IETF Meeting Agendas, because it specifies the time of WG meeting slots
 in local time (local to the IETF Meeting), but does not give the
 local time zone *anywhere*.
 
 I would appreciate if the local time zone indication would be added
 like somewhere at the top of the page, to each IETF meeting agenda.

So in this interesting discussion of UTC, Martin has actually made an excellent 
point.  Having UTC listings for the agenda would be very helpful, or an 
alternative agenda showing UTC.

Tim

Re: Useful slide tex (was - Re: English spoken here)

[Tim Chown]

On 3 Dec 2012, at 18:11, Fred Baker (fred) f...@cisco.com wrote:

 I agree with the notion that the primary purpose of the meeting is 
 discussion. What you and I tell those who present in v6ops is that we want 
 the presentation to guide and support a discussion, and anything that is pure 
 presentation should take no more than half of the time allotted to them. I 
 don't see that the tool is the problem, it's the user of the tool, and we all 
 vary in our presentation/discussion skills.

Exactly. If the presentation is one slide listing the key changes in the 
document since the last revision/meeting, and one slide per key question/issue 
being asked of the room, then that should help facilitate good discussion, not 
hinder it.

What doesn't work is a 15 minute presentation of the current contents of a 
draft that leaves a couple of minutes for questions.

It's not the tool, it's how it's used.

And fwiw I think Fred and Joel have done a decent job of this in v6ops, and one 
of the things that's helped there is trimming out drafts that don't have 
evidence of a decent level of mail list discussion.

Tim

Re: IETF work is done on the mailing lists

[Tim Chown]

On 29 Nov 2012, at 18:51, SM s...@resistor.net wrote:

 Hi Ed,
 At 06:54 29-11-2012, Edward Lewis wrote:
 Earlier in the thread I saw that someone expressed dismay that BOFs seem to 
 be WG's that have already been meeting in secret.  I agree with that.  At 
 the last meeting in Atlanta, I filled in sessions with BOFs and found that 
 the ones I chose seemed as if they were already on the way to a 
 predetermined solution.  Only one had a presentation trying to set up the 
 problem to be solved, others just had detailed talks on draft solutions.  In 
 one there was a complaint that the mail list wasn't very active - not a WG, 
 a BOF!  Not very engaging.

The complaint about a quiet mail list may have been a comment I made at the 
mdnsext BoF.  The reason for that is that the guidance we have for holding a 
BoF (RFC 5434) recommends forming a public mail list a couple of months before 
the IETF meeting where the BoF is planned and to have substantive list 
discussion in advance of the BoF, which should help form a solid problem 
statement and draft charter.

  Extensions of the Bonjour Protocol Suite (mdnsext) BoF
 
 The agenda [5] mentions Goals of the BoF with a link.  I don't recall 
 whether any proposed solution was discussed.

Some views on potential solutions were made at the mic in the BoF.  But the 
draft that was presented was a requirements draft, not a solutions one. I'll 
speak to Ralph soon about moving this forward. 

 Bringing in baked work because there are multiple independent and 
 non-interoperable solutions is what the IETF is all about.  Bringing in a 
 baked specification just to get a stamp on it is not.

The former is a driver for mdnsext, i.e. a number of vendors producing 
potentially non-interoperable mDNS proxying solutions. I don't see a problem 
with the latter, especially if it documents something useful that is otherwise 
opaque.

Certainly some WG lists have a lot of traffic, and on lists it's easy for a 
small number of vocal people to dominate the discussion, which is less likely 
to happen face to face (where people have to queue and take turns).

Tim

Re: Newcomers [Was: Evolutionizing the IETF]

[Tim Chown]

On 16 Nov 2012, at 13:25, Carlos M. Martinez carlosm3...@gmail.com wrote:

 Moving the IETF forward will involve reaching out to other peoples,
 other regions, and yes, travel farther away once in a while. I also
 understand that we need to do our part in terms of fostering and
 increasing the contribution of our region. I said this in an earlier
 email and I stand by it.


A strength of the IETF is that to participate you can simply join discussions 
on mailing lists and participate remotely when physical meetings are held. This 
may mean that for the majority of IETF contributors, the location of the 
meetings isn't critical, because attendance at every physical meeting isn't 
required.

However, when planning where meetings are held I hope organisers take into 
account the chairs of the 100+ working groups in the IETF, for whom attendance 
may not be compulsory but it's certainly highly desirable. If the cost of 
attending meetings and the complexity of travel goes up, it may become harder 
to find volunteers willing to take on WG chair and other similar 
responsibilities for the benefit of the IETF community as a whole.

Tim 

Re: So, where to repeat? (was: Re: management granularity)

[Tim Chown]

Hi,

My top three repeat venues would be Prague, Minneapolis and Vancouver.  Great 
meeting venues, with everything you need nearby.

My least favoured venues have been Dublin, Vienna and Maastricht.

Of course, you have to experiment to find good repeat venues...

Tim

Re: So, where to repeat? (was: Re: management granularity)

[Tim Chown]

On 7 Aug 2012, at 23:01, Steve Crocker st...@shinkuro.com wrote:

 I'll bet Dublin would be rated higher if the meetings had been downtown.  
 Same for Vienna.

Quite possibly, but a rating is based on a venue, not a city.  Dublin is a 
great city.  An out of town golf resort is not a great venue.

Tim

 On Aug 7, 2012, at 5:55 PM, Tim Chown wrote:
 
 Hi,
 
 My top three repeat venues would be Prague, Minneapolis and Vancouver.  
 Great meeting venues, with everything you need nearby.
 
 My least favoured venues have been Dublin, Vienna and Maastricht.
 
 Of course, you have to experiment to find good repeat venues...
 
 Tim
 

Re: Meeting lounges at IETF meetings

[Tim Chown]

On 3 Aug 2012, at 22:56, Mary Barnes mary.ietf.bar...@gmail.com wrote:

 The issue that I experienced (and why I'm fussing)  is that if you were 
 attending many sessions in the Regency rooms (and moving rooms between 
 sessions), it was extremely difficult to weave your way through the corridor 
 as many people were having their discussion directly in the middle of the 
 corridor.  There just was not room in that corridor for side conversations.  
 The situation was made worse as that corridor was where they served the 
 refreshments.   And trying to ask people politely to move generally had no 
 impact in my experience as people were too engaged in their conversations.  

The corridor congestion when food was served was the only minor nit in an 
otherwise excellent meeting.  The wireless, the facilities etc were all top 
notch.

Tim

Re: Meeting lounges at IETF meetings

[Tim Chown]

On 3 Aug 2012, at 23:38, James Polk jmp...@cisco.com wrote:
 
 To me the exceptional aspects far outweighed the bad things - so I'm chalking 
 this venue up as one of the best in 13 years of attending IETFs, and a 
 *serious* contrast to the Paris venue (which I believe was one of the worst - 
 each time we were there, though the city was nice).

+1

Would be fun to get access to an API for the lifts for next time ;)

Tim

Re: Future Handling of Blue Sheets

[Tim Chown]

The registration number links to a registration that includes an email address, 
should that need to be looked up for some reason later.

Holding minimal information for the purpose, and keeping that information as 
non-identifiable to the holder as possible, would be nice properties?

Tim

On 17 Jun 2012, at 08:36, Yoav Nir wrote:

 This creates a distinguished identity, so if two Fei Zhangs attended in 
 Paris (only case I found in the attendee list), this would distinguish which 
 of them attended a particular meeting. It would not, however, tie them to an 
 identity on the mailing list, or to the Fei Zhang who attends the Vancouver 
 meeting, so I'm not sure what purpose it serves.
 
 Yoav
 
 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Tim 
 Chown
 Sent: 16 June 2012 13:54
 To: Joel jaeggli
 Cc: IETF Chair; IETF; ietf-boun...@ietf.org
 Subject: Re: Future Handling of Blue Sheets
 
 If the purpose is simply differentiation of people with the same names, could 
 we not ask people to enter the last four digits of their IETF registration 
 number, which would presumably be unique, while being easy to remember?  The 
 number could even be on your badge to always be easy to look up.
 
 Unless there's some reason to keep registration numbers private?
 
 That would also allow poorly handwritten names to more readily be 
 checked/corrected by OCR when the sheets are scanned.
 
 Tim
 
 On 16 Jun 2012, at 04:50, Joel jaeggli wrote:
 
 On 6/15/12 14:42 , edj@gmail.com wrote:
 I presume it is the same data that people input into the Organization 
 field when they register for the meeting.
 
 I do change mine based on what capacity I'm attending a particular 
 meeting in. That goes for email address on existing blue sheets as well...
 
 The nice people who send me a check every two weeks don't generally 
 fund my attendance.
 
 Regards,
 
 Ed  J.
 
 -Original Message-
 From: Eric Burger eburge...@standardstrack.com
 Sender: ietf-boun...@ietf.org
 Date: Fri, 15 Jun 2012 17:37:50
 To: IETF Chairch...@ietf.org
 Cc: IETFietf@ietf.org
 Subject: Re: Future Handling of Blue Sheets
 
 Do we have guidelines as to what is an organization affiliation?
 
 On Jun 14, 2012, at 5:26 PM, IETF Chair wrote:
 
 Two things have occurred since the message below as sent to the IETF mail 
 list.  First, we got a lawyer in Europe to do some investigation, and the 
 inclusion of the email address on the blue sheet will lead to trouble with 
 the European privacy laws.  Second, Ted Hardie suggested that we could 
 require a password to access the scanned blue sheet.
 
 Based on the European privacy law information, the use of email will 
 result in a major burden.  If the email address is used, then we must 
 provide a way for people to ask for their email address to be remove at 
 any time in the future, even if we got prior approval to include it.  
 Therefore, I suggest that we collect organization affiliation to 
 discriminate between multiple people with the same name instead of email 
 address.
 
 Based on Ted's suggestion, I checked with the Secretariat about using a 
 datatracker login to download the scanned blue sheet.  This is fairly easy 
 to do, once the community tracking tools are deployed.  However, with the 
 removal of the email addresses from the blue sheets, it is unclear that 
 there is any further need for password protection of these images.  
 Therefore, I suggest that we proceed without password protection for the 
 blue sheet images.
 
 Here is a summary of the suggested way forward:
 
 - Stop collecting email addresses on blue sheets;
 
 - Collect organization affiliation to discriminate between multiple 
 people with the same name;
 
 - Scan the blue sheets and include the images in the proceedings for 
 the WG session;
 
 - Add indication to top of the blue sheet so people know it will be 
 part of the proceedings; and
 
 - Discard paper blue sheets after scanning.
 
 Russ
 
 
 On May 6, 2012, at 12:46 PM, IETF Chair wrote:
 
 We have heard from many community participants, and consensus is quite 
 rough on this topic.  The IESG discussed this thread and reached two 
 conclusions:
 
 (1) Rough consensus: an open and transparent standards process is more 
 important to the IETF than privacy of blue sheet information.
 
 (2) Rough consensus: inclusion of email addresses is a good way to 
 distinguish participants with the same or similar names.
 
 
 Based on these conclusions, the plan is to handle blue sheets as follows:
 
 - Continue to collect email addresses on blue sheets;
 
 - Scan the blue sheet and include the image in the proceedings for 
 the WG session;
 
 - Add indication to top of the blue sheet so people know it will be 
 part of the proceedings; and
 
 - Discard paper blue sheets after scanning.
 
 
 On behalf of the IESG,
 Russ
 
 
 
 
 
 
 
 
 Scanned by Check Point Total Security Gateway.

Re: Future Handling of Blue Sheets

[Tim Chown]

If the purpose is simply differentiation of people with the same names, could 
we not ask people to enter the last four digits of their IETF registration 
number, which would presumably be unique, while being easy to remember?  The 
number could even be on your badge to always be easy to look up.

Unless there's some reason to keep registration numbers private?

That would also allow poorly handwritten names to more readily be 
checked/corrected by OCR when the sheets are scanned.

Tim

On 16 Jun 2012, at 04:50, Joel jaeggli wrote:

 On 6/15/12 14:42 , edj@gmail.com wrote:
 I presume it is the same data that people input into the Organization 
 field when they register for the meeting.
 
 I do change mine based on what capacity I'm attending a particular
 meeting in. That goes for email address on existing blue sheets as well...
 
 The nice people who send me a check every two weeks don't generally fund
 my attendance.
 
 Regards,
 
 Ed  J.
 
 -Original Message-
 From: Eric Burger eburge...@standardstrack.com
 Sender: ietf-boun...@ietf.org
 Date: Fri, 15 Jun 2012 17:37:50 
 To: IETF Chairch...@ietf.org
 Cc: IETFietf@ietf.org
 Subject: Re: Future Handling of Blue Sheets
 
 Do we have guidelines as to what is an organization affiliation?
 
 On Jun 14, 2012, at 5:26 PM, IETF Chair wrote:
 
 Two things have occurred since the message below as sent to the IETF mail 
 list.  First, we got a lawyer in Europe to do some investigation, and the 
 inclusion of the email address on the blue sheet will lead to trouble with 
 the European privacy laws.  Second, Ted Hardie suggested that we could 
 require a password to access the scanned blue sheet.
 
 Based on the European privacy law information, the use of email will result 
 in a major burden.  If the email address is used, then we must provide a 
 way for people to ask for their email address to be remove at any time in 
 the future, even if we got prior approval to include it.  Therefore, I 
 suggest that we collect organization affiliation to discriminate between 
 multiple people with the same name instead of email address.
 
 Based on Ted's suggestion, I checked with the Secretariat about using a 
 datatracker login to download the scanned blue sheet.  This is fairly easy 
 to do, once the community tracking tools are deployed.  However, with the 
 removal of the email addresses from the blue sheets, it is unclear that 
 there is any further need for password protection of these images.  
 Therefore, I suggest that we proceed without password protection for the 
 blue sheet images.
 
 Here is a summary of the suggested way forward:
 
 - Stop collecting email addresses on blue sheets;
 
 - Collect organization affiliation to discriminate between multiple people 
 with the same name;
 
 - Scan the blue sheets and include the images in the proceedings for the WG 
 session;
 
 - Add indication to top of the blue sheet so people know it will be part of 
 the proceedings; and
 
 - Discard paper blue sheets after scanning.
 
 Russ
 
 
 On May 6, 2012, at 12:46 PM, IETF Chair wrote:
 
 We have heard from many community participants, and consensus is quite 
 rough on this topic.  The IESG discussed this thread and reached two 
 conclusions:
 
 (1) Rough consensus: an open and transparent standards process is more 
 important to the IETF than privacy of blue sheet information.
 
 (2) Rough consensus: inclusion of email addresses is a good way to 
 distinguish participants with the same or similar names.
 
 
 Based on these conclusions, the plan is to handle blue sheets as follows:
 
 - Continue to collect email addresses on blue sheets;
 
 - Scan the blue sheet and include the image in the proceedings for the WG 
 session;
 
 - Add indication to top of the blue sheet so people know it will be part 
 of the proceedings; and
 
 - Discard paper blue sheets after scanning.
 
 
 On behalf of the IESG,
 Russ
 
 
 
 
 
 

Re: primary Paris hotel booking

[Tim Chown]

On 20 Jan 2012, at 00:37, Stuart Cheshire wrote:
 
 Good suggestion Brian.
 
 I just called our corporate travel department and got the same rate as IETF, 
 including free Internet and breakfast, and cancel by 6 PM on check-in day.

Nice if you have such a department :)

I booked a room by fax and the email confirmation took 11 days to arrive, so 
don't expect a quick turnaround.

Tim___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Requirement to go to meetings

[Tim Chown]

On 23 Oct 2011, at 18:28, Loa Andersson wrote:

 Nurit,
 
 I'm in the same situation, but part of the argument is right.
 
 If we do one North America, one Europe and one Asian meeting
 per year; places like Minneapolis and Phoenix is cheaper regardless
 where you come from. That is if you compare with high end cities
 like SF, NY AND DC. ALso places where you need an extra hop to get
 there.

+1 for Minneapolis and Prague.  Relatively large travel hubs, good venues and 
cheap hotels. But I understand the need to spread the venues. I recall reading 
thelatest attempt to secure an Asian venue led to Vancouver?

Perhaps WG chairs may consider more seriously not holding WG sessions if the 
agendas are very light?  At the very least that might solve the Friday problem.

But a lot is always done out of WG sessions too, which is hard to put a value 
on.

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

Re: voting system for future venues?

[Tim Chown]

On 25 Aug 2011, at 14:58, Nathaniel Borenstein wrote:
 
 I'm not saying this is the whole problem -- and it would be interesting to 
 graph US meetings separately -- but the weakness of the dollar has to be a 
 factor. -- Nathaniel

The graphs are really interesting, but the fact remains you can book a room for 
a week at Minneapolis or Prague in IETF82 week for nearly $100 a day less than 
the cost of the Hyatt in Taipei, and that's just the public hotel rate, nothing 
negotiated.

Tim

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

Re: Hyatt Taipei cancellation policy?

[Tim Chown]

On 24 Aug 2011, at 21:58, Donald Eastlake wrote:

 On Wed, Aug 24, 2011 at 4:28 PM, Geoff Mulligan geoff.i...@mulligan.com 
 wrote:
 
 ...
 
 You could pick Rosemont, IL (next to O'hare) for every meeting (oops,
 sorry - misses on decent food).
 
 Minneapolis or Chicago, one place doesn't make it. The policy of the
 IETF has been to meet where the attendees come from, although with
 some projection into the future. So I thought we were currently trying
 to equalize meetings in North America, Europe, and Asia. So it is an
 absolute minimum of three places.

That's a fair point, and the three region split is in principle the right thing 
to do.  But I think Taipei's prices are the highest I've seen for the venue 
hotel, and the organising committee should take note of the comments about 
that, and the cancellation policy, for future venue selections.

I am also a fan of Minneapolis.  I just looked at Hilton IETF venue prices 
there for the IETF82 week.  There are king rooms under $200 a night direct from 
the hotel with a good cancellation policy, and that's without any negotiated 
price.  That's a $500-$600 difference in cost over the 5-6 nights people would 
typically stay.

I'm interested in how much sponsors contribute, and how that compares to $500 
less in hotel fees over a week times 1,200 attendees.

The Hilton Prague also has rooms at $200 the same week.

The idea of exploring a university campus is an interesting one.

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

Re: Hyatt Taipei cancellation policy?

[Tim Chown]

The room rate I see is 8500 TWD, which is $293 a night.   That is a Grand King 
room, for 2 people.

If you don't put G-23ET in the corporate/group box, it gets much worse!  I'm 
guessing the web link on the IETF site should read 
http://taipei.grand.hyatt.com/hyatt/hotels/index.jsp?extCorporateId=G-23ET to 
simplify that? 

On the plus side, flying out from Europe the time zones mean I don't need to 
stay Saturday night, so that actually puts the total hotel cost down, since the 
stay is 5 nights not the usual 6 (remembering that you need to fly in/out 
including a Saturday night for the cheaper flight).

Tim

On 23 Aug 2011, at 12:57, Thomas Nadeau wrote:

 
 
 
 
 On Aug 23, 2011, at 1:34 AM, John C Klensin john-i...@jck.com wrote:
 
 
 
 --On Monday, August 22, 2011 20:16 -0400 Ray Pelletier
 rpellet...@isoc.org wrote:
 
 ...
 As for the rates, they are high.  Taiwan is expensive,
 particularly given that the hotels know what our options are
 when we book the TICC.  The Hyatt knew that foreign visitors
 needed to use the Hyatt as headquarters and charged
 accordingly.  Since the time of our site visit, 2 new hotels
 have been constructed in the vicinity of the TICC (Le Meridien
 and W), which may provide more competition for Hyatt in these
 circumstances.  At the time we were working on this event,
 there were no acceptable options.
 
 Ray,
 
 I know you want to find sponsors and go where the sponsors want
 to go.  I accept the explanation that you negotiated as hard as
 you could for both room rates and cancellation policies.  But I
 have to wonder, especially in the light of Lixia's observation
 about the US Govt rate (which, internationally, is often a
 pretty good measure for the higher end of a reasonable rate in a
 given city), whether there is a stopping rule.  We were told in
 Quebec that you had given up on one Southeast Asian city because
 rooms would have cost over USD 300 a night. I don't remember
 hearing about a sponsor there.  What looks like USD 275 net is
 not all that much less than USD 300, especially if the dollar
 continues to sink.
 
 So, if you had a sponsor for a future meeting at that other
 location, would an estimated USD 300 be acceptable?  USD 350?
 
 I obviously don't have all of the information available to me
 that you and the IAOC do, but it seems to be there is always
 another alternative.   If there are no local ones, that
 alternative is usually described as just say no and go
 elsewhere.  What I'm trying to understand, mostly for the
 future and with the understanding that it is presumably much too
 late for Taipei and the several following meetings, is whether
 you would ever consider that an option for a meeting for which
 you have a sponsor if you hold it in a particular place or if
 you and the IAOC really believe there is no alternative under
 those circumstances.
 
 I think we need to adopt a simple rule of thumb whereby we do not book venues 
 where room rates of less than $200 USD are unavailable - sponsor or otherwise.
 
 Tom
 
 
 
  john
 
 
  john
 
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

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

Re: Hyatt Taipei cancellation policy?

[Tim Chown]

Oh, and *after* you book, it says

Additional Charges  
10.000 Percent service charge

So the charge is 10% higher than what's displayed. It would be nice if the full 
charge was more up front.  People checking for budget in advance may be unaware 
of this.

Tim

On 23 Aug 2011, at 13:22, Tim Chown wrote:

 The room rate I see is 8500 TWD, which is $293 a night.   That is a Grand 
 King room, for 2 people.
 
 If you don't put G-23ET in the corporate/group box, it gets much worse!  I'm 
 guessing the web link on the IETF site should read 
 http://taipei.grand.hyatt.com/hyatt/hotels/index.jsp?extCorporateId=G-23ET to 
 simplify that? 
 
 On the plus side, flying out from Europe the time zones mean I don't need to 
 stay Saturday night, so that actually puts the total hotel cost down, since 
 the stay is 5 nights not the usual 6 (remembering that you need to fly in/out 
 including a Saturday night for the cheaper flight).
 
 Tim
 
 On 23 Aug 2011, at 12:57, Thomas Nadeau wrote:
 
 
 
 
 
 On Aug 23, 2011, at 1:34 AM, John C Klensin john-i...@jck.com wrote:
 
 
 
 --On Monday, August 22, 2011 20:16 -0400 Ray Pelletier
 rpellet...@isoc.org wrote:
 
 ...
 As for the rates, they are high.  Taiwan is expensive,
 particularly given that the hotels know what our options are
 when we book the TICC.  The Hyatt knew that foreign visitors
 needed to use the Hyatt as headquarters and charged
 accordingly.  Since the time of our site visit, 2 new hotels
 have been constructed in the vicinity of the TICC (Le Meridien
 and W), which may provide more competition for Hyatt in these
 circumstances.  At the time we were working on this event,
 there were no acceptable options.
 
 Ray,
 
 I know you want to find sponsors and go where the sponsors want
 to go.  I accept the explanation that you negotiated as hard as
 you could for both room rates and cancellation policies.  But I
 have to wonder, especially in the light of Lixia's observation
 about the US Govt rate (which, internationally, is often a
 pretty good measure for the higher end of a reasonable rate in a
 given city), whether there is a stopping rule.  We were told in
 Quebec that you had given up on one Southeast Asian city because
 rooms would have cost over USD 300 a night. I don't remember
 hearing about a sponsor there.  What looks like USD 275 net is
 not all that much less than USD 300, especially if the dollar
 continues to sink.
 
 So, if you had a sponsor for a future meeting at that other
 location, would an estimated USD 300 be acceptable?  USD 350?
 
 I obviously don't have all of the information available to me
 that you and the IAOC do, but it seems to be there is always
 another alternative.   If there are no local ones, that
 alternative is usually described as just say no and go
 elsewhere.  What I'm trying to understand, mostly for the
 future and with the understanding that it is presumably much too
 late for Taipei and the several following meetings, is whether
 you would ever consider that an option for a meeting for which
 you have a sponsor if you hold it in a particular place or if
 you and the IAOC really believe there is no alternative under
 those circumstances.
 
 I think we need to adopt a simple rule of thumb whereby we do not book 
 venues where room rates of less than $200 USD are unavailable - sponsor or 
 otherwise.
 
 Tom
 
 
 
 john
 
 
 john
 
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

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

Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6Support Required for all IP-capable nodes) to Proposed Standard

[Tim Chown]

On 22 Aug 2011, at 23:53, Brian E Carpenter wrote:

 +1 to Ned. I can't see why this draft seems to make some people
 go defensive - it isn't saying IPv4 is evil or anything silly
 like that, it's just saying IPv6 is the future.
 
 RFC1122v6 is another matter entirely. We clearly aren't ready
 for it yet, but draft-ietf-6man-node-req-bis is a step on the way.

I agree with Ned and Brian.

Tim

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

Re: IPv6 traffic distribution

[Tim Chown]

On 28 Jul 2011, at 21:51, Michel Py wrote:

 Lorenzo,
 
 Lorenzo Colitti wrote:
 http://www.google.com/intl/en/ipv6/statistics/
 
 Thanks for the update.
 Clarification: in your stats, is AS12322's traffic classified as native
 or as 6to4/teredo?


Hi,

I just ran a search through our Netflow logs of the most recent flows 
attempting to traverse our enterprise border and this showed:

2002::/16 (6to4):
Summary: total flows: 562468, total bytes: 6.2 G, total packets: 11.0 M 

2001::/32 (Teredo):
Summary: total flows: 1363887, total bytes: 4.9 G, total packets: 10.1 M

Other:
Summary: total flows: 23681562, total bytes: 483.1 G, total packets: 546.9 M

Teredo appears skewed by one host's behaviour which I'll be looking into, 
otherwise it's about what I'd expect with around 1% by volume being 6to4.

Tim___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] 6to4v2 (as in ripv2)?

[Tim Chown]

On 27 Jul 2011, at 16:15, Mark Andrews wrote:
 
 Because it will come down to run 6to4 and be exposed to some bug
 or not run 6to4 but be safe from the bug.  We already have vendors
 saying they are thinking about pulling 6to4 from their code bases
 if it becomes historic.

I would note that RIPE-501 does not mention 6to4:
http://www.ripe.net/ripe/docs/ripe-501
As far as I can see, it only mentions RFC4213.

I would ask what is the alternative if as Mark suggests the vendors begin 
removing 6to4 support?
a) use 6to4 anyway on an open platform like OpenWRT
b) use a tunnel broker - this works much better through NATs and with dynamic 
IPv4 addresses
c) use your $work VPN if it supports IPv6, which it could/should if your 
company values IPv6
d) get IPv6 from your ISP, or move to one that has it if yours does not

I suspect, but have no proof, that the huge majority of 6to4 users don't use it 
intentionally, and the content they are trying to reach is also available over 
IPv4. But for people who want to develop and use new IPv6-specific apps, then 
either a broker or something like OpenWRT ought to meet their needs?

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

Re: [v6ops] 6to4v2 (as in ripv2)?

[Tim Chown]

On 27 Jul 2011, at 17:03, Mark Andrews wrote:

 0d20eb6-78c9-415d-9493-3aa08faac...@ecs.soton.ac.uk, Tim Chown writes:
 
 a) use 6to4 anyway on an open platform like OpenWRT
 
 Which may or may not still have the code.  OpenWRT could remove
 support just the same as another source could.  OpenWRT is also not
 widely supported by CPE vendors.  i.e. you are own your own if
 something goes wrong in most (not all) cases.

In the event OpenWRT should remove 6to4 support, just get like-minded people 
together (if there are lots of people that consciously want to use 6to4 for 
application development and testing) and roll your own.

 b) use a tunnel broker - this works much better through NATs and with dynamic
 IPv4 addresses
 
 For which there is only experimental / ad-hoc code.  Please name
 CPE vendors that support tsp?  Please name CPE vendors that support
 tunnel re-configuration on re-number.

Jeroen has answered this, but I would point out, as an example of what can be 
done in short time, that I had a student last year who developed a mini-ITX 
Linux build with tunnel broker support, and IPv6 firewall and QoS support, 
using a web interface driving existing tools like iptables and tc.  He chose to 
use the HE broker, and it's a one-time registration after which it just works 
without further user intervention with HE.

It would be very interesting to see brokenness figures for well-known broker 
prefixes as against 6to4, if anyone is gathering such data.

 c) use your $work VPN if it supports IPv6, which it could/should if your comp
 any values IPv6
 d) get IPv6 from your ISP, or move to one that has it if yours does not
 
 Which is not always a viable option.

It is in the UK, at least.

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

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Tim Chown]

On 25 Jul 2011, at 15:30, Ronald Bonica wrote:
 
 Please post your views on this course of action by August 8, 2011.

Some observations.

Our own users made use of 6to4 maybe 8+ years ago, and at the time it was handy 
to have.  Today though we're not aware of any of our users running 6to4 
intentionally. We have IPv6 native on site, and anyone who wants home IPv6 
connectivity either goes to an ISP that provides it, e.g. AA in the UK, or 
they use a tunnel broker.  Brokers have the additional benefit of working 
through NATs and with dynamic IPv4 endpoints.

Our site sees about 1-2% of all inbound traffic being IPv6, and of that less 
than 1% is 6to4, and this is only likely to fall further with rfc3484-bis. What 
6to4 we do see is probably reasonably robust in that our return path uses the 
JANET-provided 6to4 relay.  

Most operating systems either already, or before long will, support 
rfc3484-bis, which means hosts should use IPv4 in preference to 6to4 where both 
are available.  To choose to use 6to4, the user would need to consciously 
change their 3484 policy table, assuming their OS supports that (Linux and 
Windows do, MacOS X Lion appears not to).

Geoff Huston has presented data at IETF80 showing 6to4 brokenness and 
performance. We now have 'Happy Eyeballs Lite' implemented in Chrome and (I 
believe, not tested it yet) Firefox, which means the browser can adapt to 
broken IPv6, whether caused by 6to4 or other factors.

The 6to4-advisory draft suggests off-by-default, which I agree with, and use of 
relays to improve user experience. The problem is we can't expect every 
site/ISP to run a relay (or multi-address with 6to4) so there will inevitably 
always be problems with the 3068 mode of 6to4.

We measured rogue RAs over a two year period on our wireless network.  About 
60% of the time at least one host was emitting a rogue 6to4-based RA. While 
these were mitigated by ramond, it would be good to see vendors fix this; it's 
not just MS ICS.  Happy Eyeballs is a mitigation for such rogue RAs also.

So in summary, in practice 3484-bis and the 6to4-advisory off-by-default will 
further reduce what little use there is of 6to4 now, and happy eyeballs will 
mitigate any remaining instances of its use that are bad. So whether 6to4 is 
tagged Historic or not, it should be causing significantly less harm.  

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

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Tim Chown]

On 26 Jul 2011, at 15:14, Tim Chown wrote:
 
 So in summary, in practice 3484-bis and the 6to4-advisory off-by-default will 
 further reduce what little use there is of 6to4 now, and happy eyeballs will 
 mitigate any remaining instances of its use that are bad. So whether 6to4 is 
 tagged Historic or not, it should be causing significantly less harm.  

To clarify, I am in favour.

Tim

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

Re: reading drafts on an ipad

[Tim Chown]

On 7 Jul 2011, at 03:36, Glen Zorn g...@net-zen.net wrote:

 On 7/6/2011 10:38 PM, Cullen Jennings wrote:
 
 Has anyone found a particularly good solution to reading drafts on an ipad? 
 What about markup and notes on drafts?
 
 The iPad is a porn toy; get a real computer.

You could save drafts as PDF and use GoodReader, which is a very nice app, to 
annotate comments, etc.  You can also fit a lot of drafts on a free DropBox 
account, which GoodReader works fine with.

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

Re: Last Call: draft-ietf-mboned-ssmping-08.txt (Multicast Ping Protocol) to Proposed Standard

[Tim Chown]

I think this draft specifies a very useful protocol, which we have used at our 
site and which has been a valuable multicast debugging tool.

The specification and implementations have evolved over maybe 5-6 years or so.  
The implementations we've used have been of various stages of the protocol's 
development.  A student at our site implemented an earlier version of the 
protocol successfully.  I don't believe we've used a version at our site based 
on the spec in the final version of the text, so I can't comment on that 
specifically.

There are some parts of the text that I think indicate the protocol has evolved 
over a length of time; if it were rewritten from scratch it would probably be 
somewhat more compact, due to some level of repetition of aspects of the 
protocol.  However, I think it's more important to get the protocol published 
now, so I would support publishing it as is.  

The protocol is defined in a fairly loose way, but the core elements are tight 
enough for implementation.  This is reflected in the text at the start of 
Section 6.

I noticed one nit in terms of the client ID. In Section 2 the text says:
At runtime, a client generates a client ID that is unique for the ping test.  
This ID is included in all messages sent by the client.
Then later in the more detailed spec, the text says:
A client SHOULD always include this option in all messages (both Init and Echo 
Request).
I would have expected the inclusion of the Client ID to be a MUST, based on the 
earlier explanation.  If it is a SHOULD, the introduction text should say this 
ID is usually included in all messages sent by the client.

It would be nice to consider mechanisms to discover 'public' ssmping test 
servers, but that's a separate text :)

Tim

On 20 Jun 2011, at 18:51, The IESG wrote:

 
 The IESG has received a request from the MBONE Deployment WG (mboned) to
 consider the following document:
 - 'Multicast Ping Protocol'
  draft-ietf-mboned-ssmping-08.txt as a Proposed Standard
 
 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2011-07-04. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.
 
 Abstract
 
 
 The Multicast Ping Protocol specified in this document allows for
 checking whether an endpoint can receive multicast, both Source-
 Specific Multicast (SSM) and Any-Source Multicast (ASM).  It can also
 be used to obtain additional multicast-related information such as
 multicast tree setup time.  This protocol is based on an
 implementation of tools called ssmping and asmping.
 
 
 
 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/
 
 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/
 
 
 No IPR declarations have been submitted directly on this I-D.
 
 
 ___
 IETF-Announce mailing list
 ietf-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

[Tim Chown]

On 3 Jul 2011, at 12:10, Gert Doering wrote:

 On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote:
 There's clearly a lack of consensus to support it.
 
 There's two very vocal persons opposing it and a much larger number of
 people that support it, but have not the time to write a similarily
 large amount of e-mails.  For me, this is enough for rough consensus.
 
 (And I second everything Lorenzo, Randy and Cameron said - there's 
 theoretical possibilities, and real world.  6to4 fails the real-world
 test.  Get over it, instead of attacking people that run real-world
 networks for the decisions they need to do to keep the networks running
 in a world without enough IPv4 addresses).

I'm with Gert, Lorenzo, Randy and others here. 

It seemed that both the -advisory and -historic drafts had strong support in 
v6ops, which isn't just any WG, it's the WG that anyone with a vested interest 
in IPv6 deployment takes part.  Thus its view on IPv6 deployment practices 
should be given due regard.  The opposition on the IETF list seemed to be a 
vocal minority, and of course one person seemed to post a disproportionate 
number of replies.

The problems with 6to4 (20% minimum failure rate, and poor performance when it 
does connect) are well documented and have led to various 'counter measures' 
from the IETF, including:
a) 6to4 off by default, as per 6to4-advisory
b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely implemented 
already)
c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs (a 
simplistic version is already in Chrome)

Those measures indicate how bad a problem 6to4 creates.  If we're going to the 
trouble of coming up with all these measures, there seems to be a good case for 
6to4 to Historic, which would be a steer to implementors to no longer include 
6to4 support at all.  I do agree however that the most important point is 
publishing the -advisory text.

As a provider of a (not large) enterprise, I know that a fraction of 1% of 
connections to our site suffer a 10 second+ delay to a dual-stack web site 
where they suffer no delay to an IPv4-only one.  There's no way to know for 
sure how much of that 'IPv6 brokenness' is 6to4, but measures (a), (b), and (c) 
should minimise that figure.  Having said that, less than 1% of users who 
connect to our site over IPv6 use 6to4, so we wouldn't be aggrieved to see it 
disappear in terms of loss of users, as those users could almost certainly 
still reach us over IPv4.  Our own users who want IPv6 connectivity when 
offsite use tunnel brokers, which provide a much better (and more predictable) 
service, one that also works from behind a NAT, which in the reality of home, 
hotel, and other hotspot networks is quite important.
 
As for operators 'fixing' 6to4, well, I'd rather see operators invest that 
effort in deploying IPv6, rather than making 6to4 work better, for some value 
of 'better'.

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

Re: whine, whine, whine

[Tim Chown]

On 21 Jun 2011, at 14:28, Ray Bellis wrote:

 
 On 21 Jun 2011, at 14:02, Simon Perreault wrote:
 
 Not going to argue about San Diego vs Québec, but just going to point
 out that multiple carriers do serve Québec. Among them are Air Canada,
 United, Continental, Delta, and US Airways.
 
 The only European operator into YBQ appears to be Air Transat (whoever the 
 heck they are) and they only fly from Marseille and Paris.
 
 I'm flying BA to Montreal and taking the short city hopper flight to YBQ from 
 there.

For a single operator trip from the UK to Quebec City, there's Air Canada out 
of Heathrow.   You can go via Montreal or other cities.

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

Re: Getting to Quebec City

[Tim Chown]

On 18 Jun 2011, at 17:08, John R. Levine wrote:

 As far as renting a car, it is likely a very good choice for anyone that is
 arriving in Montreal later in the day.  I have a choice of one direct flight
 to Montreal that puts me arriving in Montreal  7pm.
 
 FYI, there is a direct bus from YUL to Quebec that leaves at 20:30.  With 
 Wifi, even.  It's a reasonable choice, and about $100 less than a one way car 
 rental.  The Quebec bus station is adjacent to the train station and a quick 
 taxi to hotels.

I'm flying internationally to Montreal and have a connecting flight from there 
to Quebec City with Air Canada (if they're not on strike, though the planes 
still to be flying despite that).  The connect is listed at 50 mins so is 
probably about 30-40 in the air.

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

Re: one data point regarding native IPv6 support

[Tim Chown]

On 13 Jun 2011, at 16:28, Noel Chiappa wrote:
 
 If 6to4 has problems, fine, write a document that says something like '6to4
 won't work for a host behind a NAT box because the host won't know it's true
 IPv4 global-scope address - so you should also not turn 6to4 on by default'
 and fix/publicize the issues.

There has been a good deal of work making tunnel brokers work through IPv4 NATs 
and with changing IPv4 endpoints.  Both SiXXS and HE brokers handle such 
issues, e.g. using a heartbeat method. So these ought to be (relatively) 
attractive to end users who want IPv6?

Presumably the prefixes used by such providers, and others like gogo6, are 
known so brokenness stats for such services could be deduced?

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

Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

[Tim Chown]

I agree the draft should be progressed, so add another +1 to the 'just ship it' 
people.

On 9 Jun 2011, at 18:39, Keith Moore wrote:
  If pain associated with 6to4 provides an additional incentive for ISPs to 
 deploy native v6, and for users to use native v6 when it becomes available, 
 that's a Good Thing. 

The pain though is felt by the content providers, who still see too much 
brokenness.  

On 9 Jun 2011, at 19:01, james woodyatt wrote:
 I confidently predict the reclassification to Historic will be roundly 
 ignored not just by Apple product engineering but by the entire industry.  
 We're smart enough to recognize that we're not the target audience for the 
 RFC.  The draft that matters is the companion advisory draft.  It would be 
 nice if the 6to4-to-historic draft could be spiked so as not to distract from 
 its companion, but I don't see that as a likely outcome.  Alas and alack.

Well, the most important point in this is that 6to4 is disabled by default in 
every device.  Apple did that already, which is good. What is unclear to me 
though is whether deprecating 2002::/16 means that prefix would no longer be 
routed, as per 3ffe::/16, or just 'reserved' so it's not reallocated later.

On 9 Jun 2011, at 19:53, Keith Moore wrote:
 On Jun 9, 2011, at 2:45 PM, Lorenzo Colitti wrote:
 Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot 
 less time than you have spent writing email on this thread. :-)
 
 That's who I was using before.

Our staff and students find the HE broker easy to use, though I believe some 
also use other brokers.  One student did a final year project this year 
developing a Linux home router which included HE broker support.  It was simple 
to use/integrate.

On 9 Jun 2011, at 19:56, james woodyatt wrote:
 I need *native* IPv6 into my home in San Francisco for my day job

Have you considered deploying/adding IPv6 VPN support at your day job?  So your 
VPN from home to work gives you IPv4 and IPv6?  This is quite a nice model, and 
is starting to appear in UK universities, and I use it myself for IPv6 
training. At least one big vendor offers this today. Users are familiar with 
VPN use, so adding IPv6 with that comes naturally, and $dayjob provides the 
support, so you're in control.

 Meanwhile, 6to4 works fine on their network so long as remote IPv6 
 destinations have a working return path route to 2002::/16, i.e. they are 
 complying with I-D.ietf-v6ops-6to4-advisory now.

That 'so long as' is the crux though.

Tim___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

[Tim Chown]

On 8 Jun 2011, at 21:19, Keith Moore wrote:
 
 Nor, bluntly, is it about a few big content providers or whomever else you 
 want to label as important.  The internet is a hugely diverse place, and you 
 don't get to dismiss the concerns of people whom you want to label as red 
 herrings.   Again, 40-something percent of the IPv6 traffic that is observed 
 on the net today uses 6to4.  That's about as much as Teredo, it's a hell of a 
 lot more than native v6.  As long as 6to4 is one of the major ways that 
 people get IPv6 connectivity (and it clearly is), it's premature to declare 
 6to4 historic.

You see 40% of your IPv6 traffic as 6to4, we see rather less than 1%.  Our 
observation point is as a university on an academic/research network that is 
native dual-stack.  We probably have most of our IPv6 traffic come from other 
universities around the world, who are also most likely natively connected.  
Hence little if any need for transition methods.  This may be different to your 
scenario, of course, but it is hopefully a future that will be more widespread 
in time.

We did use 6to4 in its router-to-router, site-to-site flavour many years ago 
while a project called 6NET ran, but have had no use case for it since.  
Perhaps it would be useful to see your use cases more clearly documented with 
examples.

 Almost all usage of IPv6 today is in spite of ISPs.   For that matter, a 
 great many successful IPv4 applications today are deployed in spite of ISPs.  
 Again, ISPs in general have let us down, and 6to4 and Teredo are carrying 
 ~90% of IPv6 traffic.   ISPs are not in a good position to demand that 6to4 
 be deprecated.  

We see even less Teredo, i.e. the sum of the 6to4 and Teredo we see is under 1% 
of our total IPv6 traffic.  I don't know where you see 90%; I assume it's an 
environment with home-to-home networks, with no broker or IPv6 VPN use?

 That's excellent news.  But the current proposal on the table to deprecate 
 6to4 is premature, confusing, and harmful to real users.

The problem is that 6to4 is unfortunately also harmful to real users, at least 
the ones that don't want to know about IPv6. It will continue to be until we 
can be confident no vendor anywhere has 6to4 on by default, won't it?

The question is whether Historic stops knowledgeable people like you using 6to4 
safely in your own context/community, without affecting 'normal' users.  Does 
it mean 6to4 off be default, or 6to4 removed from product?

 It's not one versus the other.   6to4 is helping to promote ubiquitous IPv6.

The other view is that 6to4 is delaying ubiquitous IPv6 deployment, by adding 
brokenness. Geoff's stats illustrate that very well, though those are not based 
on vanilla 6to4.

Tim


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

Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

[Tim Chown]

On 7 Jun 2011, at 07:33, Gert Doering wrote:

 
 Do we really need to go through all this again?
 
 As long as there is no Internet Overlord that can command people to 
 a) put up relays everywhere and b) ensure that these relays are working,
 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL.
 
 If someone wants to use 6to4 to interconnect his machines over an IPv4
 infrastructure (=6to4 on both ends), nobody is taking this away.
 
 Gert Doering
-- NetMaster

Exactly.

Less than 1% of the IPv6 traffic reaching us is 6to4. And 6to4 in its 
6to4-to-native mode is proven to be highly unreliable. It seems highly 
preferable to have that 1% wait for native IPv6 to be available to them, rather 
than being used as a reason by the bigger content providers for holding back 
production deployment, which is what we all want to see.

It's time to remove the stabilisers on the IPv6 bicycle.

Tim

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

IETF web site down for IPv6?

[Tim Chown]

Not having any luck connecting - seems to be an issue near the server:

$ traceroute6 www.ietf.org
traceroute6 to www.ietf.org (2001:1890:1112:1::20) from 
2001:630:d0:f103:216:cbff:fe8b:752e, 64 hops max, 12 byte packets
 1  2001:630:d0:f103::2  0.529 ms  0.299 ms  0.321 ms
 2  zaphod.6core.ecs.soton.ac.uk  0.283 ms  0.514 ms  0.177 ms
 3  ford.6core.ecs.soton.ac.uk  0.564 ms  0.452 ms  0.491 ms
 4  2001:630:c1:100::1  0.912 ms  0.970 ms  0.755 ms
 5  2001:630:c1:18::a  0.758 ms  0.645 ms  1.550 ms
 6  so2-1-0.lond-sbr1.ja.net  3.664 ms  3.601 ms  3.594 ms
 7  as0.lond-sbr4.ja.net  3.878 ms  3.995 ms  3.894 ms
 8  ix-5-0-0.core4.ldn-london.ipv6.as6453.net  4.093 ms  4.256 ms  4.308 ms
 9  if-14-0-0.1874.mcore3.l78-london.ipv6.as6453.net  5.056 ms  5.872 ms  
12.121 ms
10  pos7-0.mcore4.njy-newark.ipv6.as6453.net  76.873 ms  77.426 ms  76.838 ms
11  if-12-0.mcore3.njy-newark.ipv6.as6453.net  93.370 ms  104.308 ms  115.081 ms
12  if-9-0-0.906.core3.nto-newyork.ipv6.as6453.net  77.124 ms  77.282 ms  
77.030 ms
13  2001:1890:1fff:10a:192:205:35:13  78.233 ms  77.740 ms  77.825 ms
14  * * *
15  * * *

Same for others?

Hopefully this mail will fall back to IPv4 transport if required.

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

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Tim Chown]

On Mon, Sep 21, 2009 at 07:01:22AM -0700, Ole Jacobsen wrote:
 
 My personal belief, and the belief of many of have attended meetings
 in China is that the fear is unfounded.

When I attended APAN24 in China, I felt the discussions in each session
were very open.  

As with the IETF, there was also plenty of good discussions around tables
outside the meeting rooms (smoke-free, for the person who asked) and
network access seemed open.   The meeting agenda contained some of the 
topics that some posters to this thread seem to have concerns with
(see http://www.apan.net/meetings/xian2007/schedule.html).  And a lot
of very interesting and innovative new application areas.

I think the IETF should explore every possibility to host a meeting in
China.

-- 
Tim


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

Re: Request for community guidance on issue concerning afuture mee ting of the IETF

[Tim Chown]

On Sun, Sep 20, 2009 at 04:19:31PM +0300, Soininen, Jonne (NSN - FI/Espoo) 
wrote:
 Hi,
 
 I think Steve has captured the core of the issue in this mail. I think his 
 reasoning is the exact reason why we should go to Beijing with a positive 
 attitude and have a great meetin in Beijing!
 
 Cheers,
 Jonne.

Exactly.

I have been to an APAN meeting in Xian.   It was superbly organised, the
hosts and everyone we met were very friendly.   The discussions were very
good, some of which were about differences in technology adoption and
development between Europe and China, for example.  I'd have no hesitation
to return for another event any time.

Over the years I have personally found that every country I visit expands
my understanding and knowledge.   People who don't travel perhaps tend
to remain more insular.   Taking the IETF to China has to be a good thing.

BTW getting a visa for China as a UK citizen was very easy, just a simple
visit to the London embassy and a 2-hour turnaround on the paperwork.
Entering China, at Beijing, was also very painless, perhaps in part due
to the investments for the Olympics.

Tim

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

Re: IETF74 T-Shirt Art Donated to IETF Trust

[Tim Chown]

On Mon, Aug 03, 2009 at 10:09:56AM +0100, Dave Cridland wrote:

 Hmmm... That depends on what you think the shirt means. You imply it  
 means participation - and I'll vocally resist any definition of  
 participation which mandates attendance as a part of participation,  
 since you're implicitly devaluing my participation to somewhere close  
 to zero - I'll admit I'm no Crocker, Klensin, or Postel, but I  
 believe my participation is somewhat higher than might be implied by  
 only having two shirts. (Paris and Prague, if anyone's counting).

I have another scenario for draft-ietf-more-t-shirts-please, which is the 
much loved but heavily faded or worn t-shirt.   I really liked my IETF55 
sports-style Nokia IPv6 shirt, but it's now relegated to gardening duty.   
A chance to get a new version would be awesome, and while I doubt we'll 
do backdated t-shirts, I can imagine the IETF74 shirt we have 'source' 
for being similarly desirable in five years time.   

I agree the income to the IETF will not exactly be huge, but more people
being seen in IETF shirts is no bad thing for awareness.   Often seeing
someone else in a past IETF shirt invites a conversation that would never
happen otherwise.

I also think there's room for non-event shirts, like the i...@20 one.

And these t-shirts don't have to be fascimiles - I would be quite happy to 
order t-shirts in different colours, or even as a polo shirt or in 'female 
tee' form for a partner.   If the IETF chooses to use an appropriate 
t-shirt company, that sort of bespoke ordering should be possible.

Of course I realise this is all work for someone, and there are bigger fish 
to fry.   I would be happy to spend some cycles helping out if volunteers
are needed.

-- 
Tim
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 75th IETF - Hotels

[Tim Chown]

On Wed, Apr 15, 2009 at 08:49:55PM +0200, Michael Tüxen wrote:
 Does others also have a problem in reserving a room
 at the Clarion Sign? I get only a generic error message
 the the system can not process the reservation and
 I should check my data...

You have to enter Stockholm as the location, but even then I was only
offered what seemed to be a single room despite requesting a double
room (2 guests).   I phoned up and booked that way, which was a little
complex (they have a special booking desk for block bookings) and I've
yet to receive the email confirmation 24 hours later.   But I'm
sure it will be OK.   Just seems calling is the way to go right now.

Tim

 On Apr 15, 2009, at 11:49 AM, Iljitsch van Beijnum wrote:
 
 On 14 apr 2009, at 16:37, IETF Secretariat wrote:
 
 Be sure to make your reservation at one of the Stockholm hotels the  
 IETF
 has a block of rooms held.  Cutoff dates for the blocks are  
 relatively
 early.
 
 No kidding: some are next week.
 
 Hotel information can be found at:
 http://www.ietf.org/meetings/75/hotels.html
 
 Some of the phone numbers have a (0) in there. Is this the European  
 (0) which means if you don't know that you sometimes have to remove  
 that 0 you will get some unlucky soul on the line who doesn't know  
 why he gets so many crank calls or the North American (xyz) which  
 means it's a normal part of the number?
 
 (My phone number in Holland used to be 31073... and it took me years  
 to figure out why people would keep calling me over and over again  
 when they clearly needed someone else. But this person apparently  
 decided that +31(0)73... was a good way to write down their number  
 +3173... / 073...)
 
 Do we have an RFC for how to format phone numbers?
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

-- 
Tim


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

Re: Welcome to the Dnsop-honest mailing list

[Tim Chown]

And now it's happening for the dnsop list...

On Wed, Mar 25, 2009 at 12:43:27PM -0400, dnsop-honest-requ...@lists.iadl.org 
wrote:
 Welcome to the dnsop-hon...@lists.iadl.org mailing list!
 
 This mailing list is for IETF DNSOP WG members to discuss IETF
 business without improper censorship.  It does not represent the IETF
 but does represent some IETF members.
 
 This list was created by IADL.ORG (www.iadl.org) because of dishonest
 filtering by the IESG.  See http://www.av8.net/IETF-watch for more
 information on the corrupt activities of officials of the Internet
 Society, Inc (ISOC) IETF Activity, and their connection to other
 corrupt activities.
 
 You were probably added to this list because you participated in
 dn...@ietf.org discussion, and that list is used to determine
 consensus for ISOC IETF Activity actions. Consensus is a democratic
 activity of the ISOC, which is a U.S. non-profit, tax exempt
 membership corporation. ALL members of the ISOC IETF have a property
 right to participate in its democratic decision processes.   [see U.S.
 v. Local 560, extortion (Hobbs Act) and racketeering by mafia that
 took over a Union and tried to prevent participation by those opposing
 the mafia]
 
 Email sent to this list will be forwarded to dn...@ietf.org.  Ordinary
 IETF members should feel free to unsubscribe from this list if they
 choose. IETF representatives (e.g. Working Group Chairs) have a duty
 to the  corporation to read email sent to them on IETF business, and
 should not try to unsubscribe.
 
 
 To post to this list, send your email to:
 
   dnsop-hon...@lists.iadl.org
 
 General information about the mailing list is at:
 
   http://lists.iadl.org/mailman/listinfo/dnsop-honest
 
 If you ever want to unsubscribe or change your options (eg, switch to
 or from digest mode, change your password, etc.), visit your
 subscription page at:
 
   http://lists.iadl.org/mailman/options/dnsop-honest/tjc%40ecs.soton.ac.uk
 
 
 You can also make such adjustments via email by sending a message to:
 
   dnsop-honest-requ...@lists.iadl.org
 
 with the word `help' in the subject or body (don't include the
 quotes), and you will get back a message with instructions.
 
 You must know your password to change your options (including changing
 the password, itself) or to unsubscribe.  It is:
 
   
 
 Normally, Mailman will remind you of your lists.iadl.org mailing list
 passwords once every month, although you can disable this if you
 prefer.  This reminder will also include instructions on how to
 unsubscribe or change your account options.  There is also a button on
 your options page that will email your current password to you.

-- 
Tim


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

Re: RFC 3484 section 6 rule 9 causing more operational problems

[Tim Chown]

On Wed, Mar 04, 2009 at 02:09:22PM +, Tony Finch wrote:
 It seems that Vista implements RFC 3484 address selection, including the
 requirement to sort IP addresses. This breaks a great deal of operational
 dependence on DNS-based load balancing, as well as being based on an
 incorrect understanding of how IP addresses are allocated.
 
 RFC 3484 needs to be updated to delete this rule, so that the order
 returned from the DNS is honoured when the client has no better knowledge
 about which address is appropriate.
 
 See
 http://drplokta.livejournal.com/109267.html
 http://www.ietf.org/mail-archive/web/ietf/current/msg51874.html
 http://www.ietf.org/mail-archive/web/discuss/current/msg01035.html
 http://www.ietf.org/mail-archive/web/dnsop/current/msg05847.html
 http://lists.debian.org/debian-ctte/2007/11/msg00029.html

The issue is mentioned in:

http://www.watersprings.org/pub/id/draft-arifumi-6man-rfc3484-revise-00.txt

2.5.  To disable or restrict RFC 3484 Section 6 Rule 9

   There was a discussion at v6ops and ietf@ietf.org mailing lists that
   the rule 9 of the destination address selection has a serious adverse
   effect on the round robin DNS technique

However the above has expired.  Perhaps Arifumi will issue a new version
before the upcoming cutoff.

-- 
Tim


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

Re: Announcement: New Boilerplate Text Required for all new Submissions to IETF

[Tim Chown]

Hi,

It would be great if the ietf list could be reminded when the new version
of the rather excellent xml2rfc tool is issued, so we don't need to keep
checking back for it.

Thanks,
Tim

On Tue, Nov 11, 2008 at 06:03:36PM -0500, Ed Juskevicius wrote:
 Greetings.  This message is to draw your attention to the significance
 of the publication of RFC5377 and RFC5378 earlier today.  
  
 * RFC5377 is Advice to the Trustees of the IETF Trust on Rights to Be
 Granted in IETF Documents
 * RFC5378 is Rights Contributors Provide to the IETF Trust
  
 Note that RFC5378 is also BCP0078.  RFC5378 is an update to RFC2026, and
 RFC5378 obsoletes both RFC3978 and RFC4748. 
  
 Coincident with the above, the IETF Trustees have posted a new policy
 document with guidance to the community on:
 * Legal Provisions Relating to IETF Documents at
 http://trustee.ietf.org/license-info/
  
 Taken as a set, the documents listed above specify changes that are now
 required in all new submissions into the IETF.
 
 Henrik Levkowetz has updated the idnit tool and AMS have updated the
 Internet-Draft submission tool to reflect the new requirements.  An
 update to the xml2rfc has been requested. 
  
 Please review the Legal Provisions Relating to IETF Documents and
 RFC5378 to discover the new boilerplate text that is now required.
 Please also take action to update the tools you use for creating your
 documents.
 
 New submissions using either the old or the new boilerplate text will be
 accepted starting today, until 01h00 UTC on December 16th, 2008.  After
 this cutoff date, all new submissions will be required to use ONLY the
 new boilerplate text.  All submissions using old boilerplate text after
 the cutoff date will be rejected.
 
 Regards and FYI.
 
  
 Ed Juskevicius
 IETF Trust Chair
 [EMAIL PROTECTED]
 
 
 p.s. - Don't be surprised if you see periodic reminders about this as we
 approach December 16th. 
 ___
 IETF-Announce mailing list
 [EMAIL PROTECTED]
 https://www.ietf.org/mailman/listinfo/ietf-announce

-- 
Tim


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

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Tim Chown]

On Mon, Nov 10, 2008 at 07:04:27PM +, Tony Finch wrote:
 On Mon, 10 Nov 2008, Keith Moore wrote:
 
  okay.  I found myself wondering if the change in address space size, and
  in granularity of assignment, might make DNSBLs less reliable.  Which is
  a different kind of scalability.
 
 IPv6's bigger address space affects more security mechanisms than just
 DNSBLs, such as defensive port scanning, traffic auditing, etc.
 
 http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-implications-02.txt

Thanks Tony - that draft has now emerged as RFC5157:

http://www.ietf.org/rfc/rfc5157.txt

The granularity of the address space that might appear in a blacklist is
an interesting question.   I would guess that where today a single IPv4
address appears, a whole IPv6 /64 would be required, at least, since a
client on a IPv6 link could in principle use any of the 2^64 available
host addresses.But it may be worse, if whole /48's are assigned to 
DSL users for example (although there seems to be pushback to /56 for SOHO
type networks).The question then is whether the single IPv6 address
or link it is on is blacklisted, or whether the blacklist includes the
'default' site prefix size.

On a related tack, I've been gathering stats on our recorded IPv6 transport 
mail volumes and identified spam since Dublin, and will analyse these soon 
and pop out a draft with appropriate observations.We've seen a fairly
consistent figure of 50% of our IPv6 transport connections being classified
as spam by our MailScanner system since Dublin.

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

Re: IESG Statement on Spam Control on IETF Mailing Lists

[Tim Chown]

Having a single system for all WG lists has the appeal that whatever
process(es) handle the lists, it will be the same for all lists, so
you don't have to figure out how N different lists are run.

As a shameless plug, we have a free open source solution developed here
which is widely used against spam/viruses and that could do the job, see 
http://www.mailscanner.info/

-- 
Tim


___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

New web-based submission tool

[Tim Chown]

Hi,

I'd just like to compliment whoever implemented the new web based
IETF draft submission tool.   Very simple to use and rather slick :)

I'd noticed drafts appearing over the weekend rather than in a batch 
batch as usual this evening.   Must be welcomed by the RFC editors
too!

Cheers,
-- 
Tim



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

Re: New web-based submission tool

[Tim Chown]

On Mon, Nov 12, 2007 at 08:53:37AM -0800, Dave Crocker wrote:
 
 Tim Chown wrote:
 I'd just like to compliment whoever implemented the new web based
 IETF draft submission tool.   Very simple to use and rather slick :)
 
 +10
 
 Easy to use, and astonishingly quick release for public access to each new 
 document.
 
 Definite home run.

I am noticing drafts being published 3 hours after the deadline.  I assume
that's because the draft is announced when the email ack is done for the
submission?   I recall having about 3 days to ack before the submitted
draft was dropped, which would suggest that we may see drafts appearing 
until Thursday.

But yes, it's very nice.

-- 
Tim



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

Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP

[Tim Chown]

On Fri, Sep 28, 2007 at 05:29:43PM -0400, Paul Wouters wrote:
 On Fri, 28 Sep 2007, Dean Anderson wrote:
 
  Maybe its not mentioned because its not a practical solution. But
  whatever the reason it isn't mentioned, a 25 million user VPN is not
  going to happen with 10/8. A comcast person recently complained on PPML
  that there wasn't enough RFC1918 space for their internal network.
 
 Time for them to migrate to IPv6? :)

http://www.6journal.org/archive/0265/

-- 
Tim



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

Re: IPv4 to IPv6 transition

[Tim Chown]

On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote:
 Ray Plzak wrote:
  The shortage of IPv4 addresses in developing countries in a red herring.
 that has to rank as one of the most bizarre statements that's ever been
 made on the ietf list.

More of an ostrich than a herring?


   .==._
 /  .,   .`. 
/__(,_.-' ||
   `/||| 
   / ||| 
\|||
 ~ ~ |\ ~~!)~~~


Tim

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

Re: IPv6 will never fly: ARIN continues to kill it

[Tim Chown]

On Thu, Sep 13, 2007 at 04:05:09PM +0900, Jun-ichiro itojun Hagino wrote:
  
   Let me see if I understand this. Without PI, the enterprises say  
   no, and with
   PI, the ISP's say no. Got it.
  
  I believe that a more constructive assessment is that enterprises are  
  unwilling to pay non-trivial costs to renumber, and ISPs are  
  unwilling to pay non-trivial costs to support a non-scalable routing  
  subsystem.
 
   my persistent question to the enterprise operator is this:
   how frequently do you plan to switch your isp, or how many times
   did you do that in the past?
 
   i have never got any reasonable answer from anyone.

OK, I'll bite.   Never, and never (in nearly 20 years).   Although we
in effect have IPv4 PI as being an older university we came online when 
getting an old Class B was easy, before IP allocations were made from
the NREN space.

We have renumbered our IPv6 networking as part of experimental/research
work (and would from that experience certainly say fully automated
renumbering is not possible today), but that was just an academic (and
very interesting) exercise.

If IPv6 PI were available to us we'd use it because it costs us no extra
to do so.  

-- 
Tim

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

Re: Charging I-Ds

[Tim Chown]

On Tue, Jul 31, 2007 at 04:51:56PM +0200, Stephane Bortzmeyer wrote:
 
 To summary: what problem do we try to solve?

either reducing ietf costs, or increasing ietf income

do we know the 'cost per i-d'?   or is that meaningless anyway while
the i-d live in the automated part of the process?

tim


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

Re: Charging I-Ds

[Tim Chown]

On Tue, Jul 31, 2007 at 12:29:51PM -0400, Keith Moore wrote:

 also, publishing an I-D might be useful for other reasons - e.g. to
 establish prior art in case an idea or invention in the draft is ever
 patented by someone else.

I have written or co-written a few drafts in the past purely as problem
statements or to raise issues.   Rather than repeat text in list 
discussions, it's 'nice' to have a plain text format statement of an
#issue or problem to focus discussion.   While the draft may become
an RFC, it also quite commonly may not if the solution draft briefly
cpatures the issue at hand.

Sure, the statement could be a web page, but the IETF 'version control'
on texts is also quite handy to see how a text evolved over time.

tim

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

Re: take the train in Chicago

[Tim Chown]

On Sun, Jul 15, 2007 at 03:55:39PM -, John Levine wrote:

 ... walk from the Palmer House unless it's raining really hard.
 
 ... If it's raining, 

So there's me thinking Chicago in July will be mid 80's sunshine, and
you mention rain twice in one email :)

-- 
Tim



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

Problems with xml.resource.org

[Tim Chown]

Hi,

[non xml2rfc users look away]

I'm seeing xml.resource.org timing out today, and it seems consistent
on one of the two returned IPv4 addresses I see for it (192.20.225.40).

$ telnet xml.resource.org 80
Trying 168.143.123.173...
Connected to xml.resource.org.
Escape character is '^]'.

Connection closed by foreign host.

But then

$ telnet xml.resource.org 80
Trying 192.20.225.40...


This seems enough to hamper my attempts to update a draft with xml2rfc.

I don't see a contact address for this resource on the web site apart 
from a mail list.

Anyone able to check it? :)

-- 
Tim

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

Re: Game theory and IPv4 to IPv6

[Tim Chown]

On Thu, Mar 15, 2007 at 07:37:26AM -0700, Hallam-Baker, Phillip wrote:
 The problem is that until IPv6 has critical mass it is much better to be on 
 IPv4 than IPv6. 
 
 If there are any grad students reading the list take a look at the game 
 theory literature and apply it to the transition. Assume that it's a 
 rat-choice world and that each actor follows their best interest.
 
 An actor can be in one of several states:
 
 Unconnected
 IPv4 connected with own address
 IPv4-NAT connected with NAT address
 IPv4/IPv6 connected Dual stack
 IPv4-NAT/IPv6 connected Dual stack
 IPv6 connected

Unfortunately most of the rats cannot choose certain states, so the game
is fundamentally flawed.   The ISPs are keeping the cheese to themselves.

Squeak.

-- 
Tim

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

Re: Scary technology

[Tim Chown]

On Wed, Nov 01, 2006 at 12:10:16AM -0800, Fred Baker wrote:
 if routing protocols aren't scary enough for you...
 
   http://money.cnn.com/popups/2006/fortune/scary_tech/index.html

Unexpected failure modes led to the early withdrawal of IPv5

-- 
Tim



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

Re: Fw: Why cant the IETF embrace an open Election Process rather than some

[Tim Chown]

Isn't he barred from posting here?

On Wed, Sep 13, 2006 at 07:51:27PM -0700, todd glassey wrote:
 I am forwarding this on behalf of Dean Anderson.
 
 
  Thanks
 
  --Dean
 
 
  On Mon, 11 Sep 2006, Noel Chiappa wrote:
 
From: todd glassey [EMAIL PROTECTED]
  
Why cant the IETF and IESG Embrace open elections
  
   Because the members are generally happy with the system we have now.
 It's
   called democracy - and you're outvoted.
 
  I think that in fact, members aren't very happy with the system that we
  have now. If they were happy, they wouldn't be changing it.
 
  I think that the system has created a very closed, and very unfair
  management selection process that is not benefiting the members are
  large, but benefiting a few private interests.
 
   Remember, we had this system for quite a while before the last major
 rework
   of the process (i.e. we'd all seen it in action for some years, and were
 able
   to judge how well was working), and the outcome of that rework was a
   standards document - i.e. something suject to community approval, i.e.
   democracy - which made adjustments, but retained the basic framework. If
   people weren't generally happy with that basic framework, it would have
 been
   obvious at the Last Call of the document.
  
   IMO, the IETF has some significant problems, but the process for
 selecting
   people for leadership positions isn't one of them.
 
  I think the IETF and ISOC do have some very significant problems, and
  that those problems are primarilly mismanagement, disloyalty, and
  improper use of the ISOC/IETF/IESG/IAB to benefit the personal and
  adverse interests of the management. The ISOC/IETF employees have
  accrued some torts against the organization for defamation and
  defamatory false reports of member misconduct.
 
  There is plenty of documentation now of disloyalty, fraudulent
  misrepresentation, collusion, and bad faith.  To see a little bit, look
  at the Appeal submitted recently to the IAB:
 
 
 http://www.av8.net/IETF-watch/Appeal_of_IESG_decision_of_July_10_2006-v4.pdf
  or
 
 http://www.av8.net/IETF-watch/Appeal_of_IESG_decision_of_July_10_2006-v4.html
 
 
 
  -- 
  Av8 Internet   Prepared to pay a premium for better service?
  www.av8.net faster, more reliable, better service
  617 344 9000
 
 
 
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www1.ietf.org/mailman/listinfo/ietf

-- 
Tim/::1



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

www.ietf.org unresponsive over IPv6?

[Tim Chown]

Hi,

While I can establish a fast telnet session to port 80:

$ telnet www.ietf.org 80
Trying 2001:503:c779:b::d1ad:35b4...
Connected to www.ietf.org.
Escape character is '^]'.

Attempting to browse via MSIE leads to timeouts.

Connecting explictly to http://209.173.53.180 to assure IPv4 works fine.

Perhaps some Apache issue or PMTU issue?

Anyone else experiencing this?

We're not seeing issues with any other IPv6 sites/services.

Tim

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

Re: www.ietf.org unresponsive over IPv6?

[Tim Chown]

On Fri, Sep 01, 2006 at 01:25:19PM +0200, Jeroen Massar wrote:
 Tim Chown wrote:
 Hi,
 
 While I can establish a fast telnet session to port 80:
 
 $ telnet www.ietf.org 80
 Trying 2001:503:c779:b::d1ad:35b4...
 Connected to www.ietf.org.
 Escape character is '^]'.
 
 Attempting to browse via MSIE leads to timeouts.
 
 Connecting explictly to http://209.173.53.180 to assure IPv4 works fine.
 
 telnet -4 www.ietf.org should do that trick too, but notez bien:
 
 www.ietf.orgA   209.173.53.180
 www.ietf.orgA   209.173.57.180
 www.ietf.org2001:503:C779:B:0:0:D1AD:35B4
 
 We don't know if those are 3 different boxes, or simply 1 box with 
 multiple links/addresses. As IPv4 traceroutes die off one can't tell 
 what really is happening behind ATT (at least from my perspective).
 Looking at routeviews it seems that both IPv4 /24's have somewhat 
 different ASPaths, going over different upstreams.
 
 Perhaps some Apache issue or PMTU issue?
 
 Most likely PMTU.
 
 Anyone else experiencing this?
 
 Works from boxes behind my home DSL line (purgatory.unfix.org) and from 
 my work box, which is behind SWITCH (2001:620::/32). Tested with telnet, 
  MSIE and firefox. See below for traces from the DSL.
 
 Can you try tracepath6, which is available afaik only on Linux boxes 
 though, to show the MTU path? (iputils-tracepath is the deb package)
 
 --
 [EMAIL PROTECTED]:~$ tracepath6 www.ietf.org
  1?: [LOCALHOST]  pmtu 1480
  1:  2001:7b8:5:10:74::1   32.572ms
  2:  i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl asymm  3  33.623ms
  3:  jun1.telecity.ipv6.network.bit.nlasymm  4  34.609ms
  4:  zpr2.amt.cw.net  asymm  5  35.522ms
  5:  so-5-2-0-dcr1.amd.cw.net asymm  6  34.597ms
  6:  as0-dcr2.amd.cw.net  asymm  7  35.611ms
  7:  so-4-0-0-dcr1.tsd.cw.net asymm  8  41.612ms
  8:  so-1-0-0-zcr1.lnt.cw.net asymm  9  41.507ms
  9:  2001:7f8:4::31f9:1   asymm  8 137.537ms
 10:  v3323-mpd.cr1.ewr1.us.occaid.net asymm  7 141.670ms
 11:  ge-0-1-0.cr1.iad1.us.occaid.net  asymm  7 146.538ms
 12:  unknown.occaid.net   asymm  8 152.466ms
 
 And then no responses, thus most likely filtered for this kind of trace.

So I'm on RedHat, have tracepath6 installed (not used before, thanks for
the pointer :) and I see in comparison:

$ /usr/sbin/tracepath6 www.ietf.org
 1?: [LOCALHOST]  pmtu 1500
 1:  2001:630:d0:f102::21.191ms 
 2:  zaphod.6core.ecs.soton.ac.uk   1. 93ms 
 3:  ford.6core.ecs.soton.ac.uk 1.915ms 
 4:  2001:630:c1:100::1 2. 66ms 
 5:  2001:630:c1:10::1  2.353ms 
 6:  no reply
 7:  no reply
 8:  no reply
 9:  po9-0.cosh-scr.ja.net  8.440ms 
10:  po2-0.lond-scr.ja.net  5.273ms 
11:  po0-0.lond-scr4.ja.net 6.319ms 
12:  gi0-1.lond-isr4.ja.net 6.238ms 
13:  2001:630:0:10::52  8.138ms 
14:  ge-2-24.r01.londen03.uk.bb.gin.ntt.net11.163ms 
15:  xe-0-1-0.r23.londen03.uk.bb.gin.ntt.net  asymm 16  11.525ms 
16:  xe-0-2-0.r22.londen03.uk.bb.gin.ntt.net  asymm 17  15.225ms 
17:  1d-uk6x.ipv6.btexact.com  11.292ms 
18:  52.ge0-0.cr2.lhr1.uk.occaid.net   13.643ms 
19:  52.ge0-0.cr2.lhr1.uk.occaid.net  asymm 18  16. 63ms pmtu 1480
19:  v3323-mpd.cr1.ewr1.us.occaid.net  88.237ms 
20:  ge-0-1-0.cr1.iad1.us.occaid.net   92.623ms 
21:  unknown.occaid.net   101.267ms 
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
31:  no reply
 Too many hops: pmtu 1480
 Resume: pmtu 1480 

Hmm, 1500 vs 1480.

 But traceroute6 works fully:
 
 traceroute to www.ietf.org (2001:503:c779:b::d1ad:35b4) from 
 2001:7b8:20d:0:290:27ff:fe24:c19f, 30 hops max, 24 byte packets
  1  2001:7b8:5:10:74::1 (2001:7b8:5:10:74::1)  13.874 ms  9.645 ms 
 10.963 ms
  2  i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl 
 (2001:7b8:3:31:290:6900:31c6:d81f)  9.943 ms  15.581 ms  14.958 ms
  3  jun1.telecity.ipv6.network.bit.nl (2001:7b8::290:6900:1c6:7c1f) 
 16.953 ms *  10.6 ms
  4  zpr2.amt.cw.net (2001:7f8:1::a500:1273:1)  10.972 ms  11.501 ms 
 10.99 ms
  5  so-5-2-0-dcr1.amd.cw.net (2001:5000:0:12::1)  11.987 ms  11.614 ms 
  11.986 ms
  6  as0-dcr2.amd.cw.net (2001:5000:0:11::2)  11.989 ms  11.569 ms 
 10.989 ms
  7  so-4-0-0-dcr1.tsd.cw.net (2001:5000:0:20::2)  17.988 ms  17.589 ms 
  17.989 ms
  8  so-1-0-0-zcr1.lnt.cw.net (2001:5000:0:61::2)  21.988 ms  17.505 ms 
  17.988 ms
  9  2001:7f8:4::31f9:1 (2001:7f8:4::31f9:1)  112.99 ms  112.727 ms 
 113.984 ms
 10  v3323-mpd.cr1.ewr1.us.occaid.net (2001:4830:fe:1010::2)  111.988 ms 
  112.501 ms  112.991 ms
 11  ge-0-1

Re: www.ietf.org unresponsive over IPv6?

[Tim Chown]

On Fri, Sep 01, 2006 at 02:48:10PM +0200, Jeroen Massar wrote:
 
 How sure are you these have a MTU of 1500? Best way to test is to do 
 ping6's in the form of ping6 -M do -s 1500 target and decrementing 
 per 10 or 20 till it doesn't respond anymore and then increasing again.
 
 19:  52.ge0-0.cr2.lhr1.uk.occaid.net  asymm 18  16. 63ms pmtu 1480

These seem to be OK.

 Maybe a traceroute6 interface on http://noc.ietf.org/ could help debug 
 these issues easier? I'll send the secretariat a separate message about 
 that, also that they might want to ask Neustar join up with GRH 
 (http://www.sixxs.net/tools/grh/) to make debugging easier as then we at 
 least have ASpaths also which might help here.

I think that would be helpful.   I think IETF could support nice diagnostics
if showcasing v6 connectivity.
 
 Check your neighbor cache after the traceroute/path or even a full TCP 
 connect has completed, you should have an entry similar to:
 
 [EMAIL PROTECTED]:~$ ip -6 ro sho cache
 2001:503:c779:b::d1ad:35b4 via 2001:7b8:5:10:74::1 dev eth1  metric 0
 cache  expires 429sec mtu 1480 advmss 1440 hoplimit 4294967295
 
 The 1480 is noted here, check that that is the case.

Well, I can see www.ipv6tf.org fine, but www.ietf.org hangs in the
browser, but both seem to negotiate 1480 MTU:

For www.ipv6tf.org

$ /usr/sbin/tracepath6 www.ipv6tf.org
 1?: [LOCALHOST]  pmtu 1500
 1:  2001:630:d0:f102::21.231ms 
 2:  zaphod.6core.ecs.soton.ac.uk   4.443ms 
 3:  ford.6core.ecs.soton.ac.uk 1.849ms 
 4:  2001:630:c1:100::1 1.982ms 
 5:  2001:630:c1:10::1  2.681ms 
 6:  no reply
 7:  no reply
 8:  no reply
 9:  po9-0.cosh-scr.ja.net  7.729ms 
10:  po2-0.lond-scr.ja.net  9.693ms 
11:  po0-0.lond-scr4.ja.net10.444ms 
12:  gi0-1.lond-isr4.ja.net 5.880ms 
13:  2001:630:0:10::52  6.636ms 
14:  uk6x.ipv6.btexact.com  8.269ms 
15:  uk6x.ipv6.btexact.comasymm 14  11.370ms pmtu 1480
15:  v6-tunnel-consulintel.ipv6.btexact.com   asymm 16  68.662ms 
16:  no reply
17:  no reply
snip

Indicates 1480, and I get the 1480 MTU in my cache:

[EMAIL PROTECTED] ~]$ /sbin/ip -6 ro sho cache
2001:630:d0:f102:20e:cff:fe09:e058 via 2001:630:d0:f102:20e:cff:fe09:e058 dev 
eth0  metric 0 
cache  mtu 1500 rtt 27ms rttvar 20ms cwnd 3 advmss 1440
2001:7f9:1000:1::103 via fe80::214:1bff:fe3d:2c00 dev eth0  metric 0 
cache  expires 557sec mtu 1480 advmss 1440

Then doing the same to www.ietf.org 

$ /usr/sbin/tracepath6 www.ietf.org
 1?: [LOCALHOST]  pmtu 1500
 1:  2001:630:d0:f102::21.297ms 
 2:  zaphod.6core.ecs.soton.ac.uk   1. 94ms 
 3:  ford.6core.ecs.soton.ac.uk 1.984ms 
 4:  2001:630:c1:100::1 2. 35ms 
 5:  2001:630:c1:10::1  2.746ms 
 6:  no reply
 7:  no reply
 8:  no reply
 9:  po9-0.cosh-scr.ja.net  3. 16ms 
10:  po2-0.lond-scr.ja.net  6. 13ms 
11:  po0-0.lond-scr4.ja.net 5.876ms 
12:  gi0-1.lond-isr4.ja.net 8.529ms 
13:  2001:630:0:10::52  8.918ms 
14:  ge-2-24.r01.londen03.uk.bb.gin.ntt.net 8.277ms 
15:  xe-0-1-0.r23.londen03.uk.bb.gin.ntt.net  asymm 16   8.742ms 
16:  xe-0-2-0.r22.londen03.uk.bb.gin.ntt.net  asymm 17   8.823ms 
17:  1d-uk6x.ipv6.btexact.com  12. 38ms 
18:  52.ge0-0.cr2.lhr1.uk.occaid.net   16.152ms 
19:  52.ge0-0.cr2.lhr1.uk.occaid.net  asymm 18  12.347ms pmtu 1480
19:  v3323-mpd.cr1.ewr1.us.occaid.net  88.965ms 
20:  ge-0-1-0.cr1.iad1.us.occaid.net   93.819ms 
21:  unknown.occaid.net   100.504ms 
22:  no reply
23:  no reply
snip

Suggests 1480, and that's in the cache:

[EMAIL PROTECTED] ~]$ /sbin/ip -6 ro sho cache
2001:503:c779:b::d1ad:35b4 via fe80::214:1bff:fe3d:2c00 dev eth0  metric 0 
cache  expires 591sec mtu 1480 advmss 1440
2001:630:d0:f102:20e:cff:fe09:e058 via 2001:630:d0:f102:20e:cff:fe09:e058 dev 
eth0  metric 0 
cache  mtu 1500 rtt 27ms rttvar 20ms cwnd 3 advmss 1440
2001:7f9:1000:1::103 via fe80::214:1bff:fe3d:2c00 dev eth0  metric 0 
cache  expires 329sec mtu 1480 advmss 1440

So both behave the same apparently in terms of PMTU discovery.

I just wondered if it might be an Apache thing because have run into
things like SENDFILE optimisation issues before.   But you've ruled
that out I think.

 $ /usr/sbin/traceroute6 www.ietf.org
 traceroute to www.ietf.org (2001:503:c779:b::d1ad:35b4) from 
 2001:630:d0:f102:230:48ff:fe23:58df, 30 hops max, 16 byte packets
  1  2001:630:d0:f102::2 (2001:630:d0:f102::2)  1.883 ms  2.719 ms  4.513 ms
  2  zaphod.6core.ecs.soton.ac.uk (2001:630:d0:f001::1)  4.462 ms  2.485 ms 
  2.886 ms
  3  

Re: An Absolutely Fantastic IETF Meeting Network - Redux

[Tim Chown]

On Wed, Jul 12, 2006 at 06:36:45PM -0400, Ed Juskevicius wrote:
 
To echo Harald's words from Dallas:
 
  - Just wanted to state what's obvious to all of us by now:
 
 - This time the wireless WORKED, and Just Went On Working.
 
 - THANK YOU!
 
In  addition,  I  want  to  extend  my  personal  compliments  to  our
Ericsson, Combat Networks and the entire NOC team for a very good job.

Yes, it's been very good this time.   Of course, sod's law kicked in 
last night as soon as the wireless was mentioned in the plenary, it seemed
to disappear, as if to make us all aware how much we appreciate it :)

Also the presence of tables again in the front rows, along with ample power
sockets, was very welcome.

Tim

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

Re: Pre-IPV6 maintenance of one of the www.ietf.org servers - 2006/06/03 - 12:00am EST

[Tim Chown]

On Fri, Jun 02, 2006 at 09:29:21PM -0400, [EMAIL PROTECTED] wrote:
 
 Hi All,
 
 Tomorrow Saturday June 3 at 12:00am EST, we will be taking down one of
 the round robin www servers for the IETF (209.173.53.180) for
 maintenance in preparation for supporting IPV6.  The outage should be
 less than 1 hour.  This system also serves as the primary site for...
 
  noc.ietf.org
  www.iab.org
  www.iesg.org
 
 so those sites will also be down.

Congratulations!

$ telnet www.ietf.org 80
Trying 2001:503:c779:b::d1ad:35b4...
Connected to www.ietf.org.

-- 
Tim/::1

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

Re: Wasting address space (was: Re: Last Call: 'Considerations on the IPv6 Host density Metric' to Informational RFC (draft-huston-hd-metric))

[Tim Chown]

On Mon, Jun 05, 2006 at 08:12:28PM +0200, Iljitsch van Beijnum wrote:
 
 Having to choose between /60 and /48 would be much better than having  
 to choose between /64 and bigger in general, as it removes the will  
 I ever need a second subnet consideration, the average allocation  
 size goes down and moving to a /48 after having grown out of a /60  
 isn't too painful.

There's a certain appeal to this, to have to renumber before your
network grows too big.  Interesting suggestion.
 
 It's also really helpful if all ISPs use the same subnet sizes. For  
 instance, I can set up my routes as DHCPv6 prefix delegation clients,  
 so they can be reconfigured with new address prefixes automatically  
 when changing ISPs, but I still need to put the subnet bits (and  
 therefore the subnet size) in the configuration by hand, so having to  
 change that defeats the purpose of the exercise.

Which was the point of /48 pervasively?

-- 
Tim/::1



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

Re: 66th IETF - Registration and Hotel Accommodations

[Tim Chown]

On Wed, Apr 19, 2006 at 06:07:50PM -0500, Spencer Dawkins wrote:
 
 Thanks to IAD for opening registration (helps with visa requests, although 
 this is less of a problem in Canada than elsewhere in North America).

Yes, very nice to have the hotel and registration open 3 month in advance
this time, well done!

I called direct, got a booking and a confirmation PDF by email, very easy.

But note the hotel is not the meeting venue as far as I can tell.  Some 
info on distances involved (or even a map showing locations) would be 
helpful.  Using zip codes on www.multimap.com (H3C 3Z7 for the hotel and
H2Z 1H2 for the Palais) suggests it's a couple of blocks along a fairly
major road, which should be easy walking distance...

-- 
Tim/::1

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

Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)

[Tim Chown]

On Thu, Mar 30, 2006 at 01:36:18PM +0200, Iljitsch van Beijnum wrote:
 
 The thing that is good about IPv6 is that once you get yourself a / 
 64, you can subdivide it yourself and still have four billion times  
 the IPv4 address space. (But you'd be giving up the autoconfiguration  
 advantages.)

I noticed that by deafult MS Vista doesn't use autoconf as per 2462, 
rather it uses a 3041-like random address.  See:
http://www.microsoft.com/technet/itsolutions/network/evaluate/new_network.mspx

Random Interface IDs for IPv6 Addresses

 To prevent address scans of IPv6 addresses based on the known company IDs of 
network adapter manufacturers, Windows Server Longhorn and Windows Vista by 
default generate random interface IDs for non-temporary autoconfigured IPv6 
addresses, including public and link-local addresses.

That reads to me like no 2462 by default.  Maybe I'm misinterpreting.

One could envisage an option where that randomness is applied to 48 host
bits not 64.  If you really really wanted to do that.

-- 
Tim/::1



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

Re: Stupid NAT tricks and how to stop them.

[Tim Chown]

Interesting discussion.

Keith is hitting all the nails on the head.   Phillip seems to suggest
that consumers buy NATs out of choice.  They don't have any choice.

I surveyed my final years students last month.  Just four have a static
IPv4 allocation for their home network, and only one has more than a /32
for use internally.  ISPs just don't give you a choice (unless you are
prepared to pay a non-negligible fee).

If you deply IPv6 NAT, you may as well stay with IPv4.  The first ISPs
offering IPv6 are offering /48's here.   The allocations to FT etc (they
have a /19) are clearly made on the basis of end site /48's.

See also http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt

We have deployed IPv6 in our enterprise (throughout).  We're seeing some
early benefits from (student) driven new services.  Students are also using
transition mechanisms to enable simpler use of applications between homes 
(rather than battling a NAT out and a NAT in on communication paths).

No regrets from deploying, no significant issues either for the existing
IPv4 service.  And there's more than just address space to take advantage
of, like embedded RP for multicast applications.

Tim

On Tue, Mar 28, 2006 at 12:48:13AM -0500, Keith Moore wrote:
 In this case the benefit to running NAT on my home network is that it saves
 me $50 per month in ISP fees, means I have wireless service to the whole
 house and means that guests can easily connect.
 
 one immediate benefit to my running IPv6 on my home network is that I 
 can access any of my machines from anywhere else on the network (via 
 6to4), as long as I'm not behind a NAT.  my home network also has a v4 
 NAT, so it's not as if they're mutually exclusive.
 
 I have never seen a coherent, rational argument as to why the network
 numbering on my internal network should be the same as the network 
 numbering
 on the Internet. 
 
 obviously you've never tried to write a distributed application in a 
 NATted network.  and presumably you never tried to do anything with UUCP 
 mail (which had naming conflicts) or a large DECnet (which had address 
 conflicts).  the problems are immediately obvious to those of us who 
 have had to deal with those disasters.
 
 in brief: one reason is so that apps can have the same view of the 
 network regardless of whether they're hosted on your internal network, 
 or on an external network, or on a combination of the two.  it's MUCH 
 simpler if apps don't have to worry about the fact that host A has 
 address A1 from network X and address A2 from network Y.  particularly 
 since in a network with scoped addresses, hosts don't really have any 
 way of knowing which network they're on.
 
 there are other reasons also: routing, coherent network management, DNS 
 consistency.  a network with scoped addressing is like a city where all 
 of the streets have the same name.  it becomes pretty difficult to navigate.
 
 People will still want to do NAT on IPv6.
 
 true.  people do all kinds of evil things that break the net. our 
 protocols will only work to the extent that people follow the 
 specifications.  when people start breaking things, the protocols and 
 applications start failing.  NAT is a good example.
 
 in ipv6, we can provide better ways of solving the problems that people 
 think they're solving with NATs.  if we fail to do that, or if people 
 insist on using NATs anyway, we're screwed.  but that's not a reason to 
 give up without trying.
 
 either do something to help or get out of the way.
 
 Keith
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www1.ietf.org/mailman/listinfo/ietf

-- 
Tim/::1



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

Re: Stupid NAT tricks and how to stop them.

[Tim Chown]

On Tue, Mar 28, 2006 at 01:54:52AM -0800, Michel Py wrote:
  Tim Chown wrote:
  If you deploy IPv6 NAT, you may as well stay with IPv4.
 
 You're the one who convinced me some three years ago that there will be
 IPv6 NAT no matter what, what's the message here?

I think there will be IPv6 NAT, because some people will want it.  That
doesn't mean it's rational to deploy it :)
  
  See also
 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt
 
 Remember: Users don't read drafts/RFCs.

And users don't walk into PC World and say 'I'd like a NAT router for my
home network please'.   They probably ask for a broadband modem, or 
something that doesn't specify NAT.
 
  We have deployed IPv6 in our enterprise (throughout).
 
 Could you have done it if you did not have the
 research dollars^H^H^H^H pounds?

While we ironed out many issues with research funding assistance in 6NET,
I would say the deployment we have now could be done as part of a natural
evolutionary procurement process.   The 'cost' is real terms is not that
high.  We have had to invest time in updating OSS-type elements, but much
of the rest comes 'out of the box'.   I guess we would have had some
training costs as a 'normal' enterprise, but we've helped address that in
the academic community by running hands-on IPv6 workshops (just as the
Internet2 people do for their community).
 
 Phillip, there a few (such as: NAT typically requires hard state, which
 is a pain to replicate if there is more than one edge router). NAT is
 not completely evil, but it's far from being clean. Pretending that
 there are no good reasons against NAT is going to achieve the same as
 trying to eliminate it: nothing.

I note Phillip's extremes of view on IPv6 and DNSSEC.  It's interesting
to compare how critical these two elements are, and his views on them.
 
 Yes, and since site-locals have been deprecated they will also hijack an
 unallocated block of addresses to use as private, same what happened
 prior to RFC 1597 for the very same reasons (difficult/pricey to get
 PI).

There are now ULAs, http://www.ietf.org/rfc/rfc4193.txt.
 
 When people will begin to scream bloody murder to use the extended bits
 (because v4 is getting near exhaustion) the infrastructure could be
 already in place, and then the pressure will be on software developers
 to recode their stuff with 128-bit addresses. When that has happened,
 then we can make use of all these reserved fields for better purposes,
 and possibly allocate PI to everybody which is another pre-requisite to
 get rid of NAT.

And there's always IPv8 ;)


-- 
Tim/::1



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

Re: Proposed 2008 - 2010 IETF Meeting dates

[Tim Chown]

On Mon, Mar 27, 2006 at 10:38:03AM +0200, Brian E Carpenter wrote:
 
 I don't think the analogy holds, for a number of reasons. (As a matter
 of interest, there were about 6 participants out of 350 with addresses
 in Europe at the March 1991 IETF meeting, and about 19 out of 530
 in March 1993. At that point, scheduling against RIPE would certainly
 have become a practical problem.)

You have to consider the most important clashes;  IETF66 clashes with 
the World Cup Final on July 9th.   I hope Canada has good coverage,
if not a good football team :)

Tim

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

Re: Moving from hosts to sponsors

[Tim Chown]

On Sat, Mar 25, 2006 at 12:43:57PM -0500, Henning Schulzrinne wrote:
 Indeed. Not only is it small, it isn't where corporate bean counters
 put their attention, which is air fare, hotel, and per diem.
 
 Brian,
 
 this is not universally true. With cheaper air fares and not staying  
 in the overpriced Hilton hotel rooms, my IETF65 meeting fee was  
 almost exactly the same as my combined hotel and air fare costs. For  
 those of us not on corporate expense accounts, it's the total amount  
 that matters.

Being trapped away from the IETF hotel for one night by the flood, the
quality of a nearish (5-10 min drive, probably 1h walk) motel was a
little of an eye opener, very similar quality for $69+taxes, and a
bigger bathroom.   Why the Hilton creates such enormous rooms with such
small en-suites is a mystery to me :)

-- 
Tim/::1



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

Re: An absolutely fantastic wireless IETF

[Tim Chown]

On Thu, Mar 23, 2006 at 11:35:13PM -0600, Ken Raeburn wrote:
 On Mar 23, 2006, at 21:58, Harald Alvestrand wrote:
 Just wanted to state what's obvious to all of us by now:
 
 This time the wireless WORKED, and Just Went On Working.
 
 That hasn't happened for a while. THANK YOU!
 
 Mmm... well, my laptop (Mac Powerbook) fell off the b/g network  
 several times, mostly during plenary sessions, but the problems were  
 brief, and I usually had no trouble getting back on.  It wasn't  
 perfect, but very much improved over previous meetings.

Same symptoms here, in the 'distant' rooms (Cortez et al) when the
rooms were full my Powerbook would lose association frequently, but
always rejoin when I forced it manually.
 
I'd love to know what was causing that; I've never seen similar
symptoms before.  My ssh sessions would survive the drops though :)
I don't know whether I was using b or g.

Maybe a Mac thing?

-- 
Tim/::1

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

Re: Making IETF happening in different regions

[Tim Chown]

On Thu, Mar 23, 2006 at 11:48:19PM -0600, JORDI PALET MARTINEZ wrote:
 
 The results is also better for all (even participants), because the
 logistics and local-planning is done more coherently.

I think there's some unfair handwaving in this thread.

One option however would be to seek 'partnerships' between vendors and
the IETF that span more than one meeting.  Unless that impacted the
perceived 'neutrality' of the IETF and its standardisation processes.

Tim

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

Re: Jabber chats (was: 2 hour meetings)

[Tim Chown]

On Fri, Mar 24, 2006 at 07:49:46AM -0800, Michael Thomas wrote:
 
 Maybe there's an intermediate between email and full f2f time?
 Something like having well known jabber chats to simulate the
 quickness of f2f conversation without having to be there? There
 is some amount of precedence for this with the IESG's telechats.
 They could be structured like regular wg meetings with moderation,
 etc for well known ones, and the same room could be reused for
 ad hoc/sidebar discussions when not in use.

Well, if we make remote participation too good, we may end up with
rather empty meeting rooms and a bankrupt IETF ;)
 
What we should do, given the rush of work that happens pre-ID cutoff,
is maybe look at such technology for interim meetings, and have the
IETF support some infrastructure to help interim meetings run more
effectively, maybe even without a physical meeting venue.   Some WGs
might then run more interim virtual meetings and help distribute the
workload over the year more smoothly.

-- 
Tim/::1



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

Re: Jabber chats (was: 2 hour meetings)

[Tim Chown]

On Fri, Mar 24, 2006 at 08:49:28AM -0800, Hallam-Baker, Phillip wrote:
 
 You mean like holding a bi-weekly teleconference?
 
 VOIP is getting to the point where this is practical. 

Well yes, telecons are fine for design team work, but for an open interim
meeting you need to determine which systems will work for maybe 50 virtual
attendees and not devolve to chaos :)

-- 
Tim/::1



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

Nokia 770?

[Tim Chown]

Hi,

Is there any way a non-US citizen can buy one of the promotional 770's
available at the event and walk out with a receipt in their name?

-- 
Tim/::1

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

Venue requirements - canoe?

[Tim Chown]

Hi,

I guess some people not in Dallas may have missed the news of the freak
local flooding here.

I was downtown with three colleagues and tried to come back to the hotel
around 5.30pm Sunday and hit the huge traffic jam.  Our taxi couldn't cross
the freeway to the hotel side because the police had blocked the flooded 
turnoffs, and we had no intention of running across the freeway (never 
was good at Frogger) so we ended up staying overnight at a motel 5 miles 
up the freeway.

The freeway was largely clear, but was underwater in places, but looking
to the side roads we could see cars almost completely submerged (and
probably couldn't see some that were).   

When we'd left the hotel at 1pm or so the heavy rain was very heavy, 
and we got pretty wet just running 10 yards from the cab to the restaurant,
but never had any idea of what was to follow.

Some pictures from www.dallasnews.com:
http://www.dallasnews.com/sharedcontent/dws/pt/slideshows/2006/03/0319weather/

The forecast is better for the rest of the week, thankfully.

-- 
Tim/::1



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

Re: v6 on the net in Dallas

[Tim Chown]

On Mon, Mar 20, 2006 at 02:43:11PM -0600, Jim Martin wrote:
 Gentlepeople,
   Yesterday and this morning, we had an issue for the wired and  
 wireless networks in the Terminal Room area that prevented IPv4 RAs  
 from reaching the user devices. This has been resolved and we believe  
 we have v6 working now everywhere in the network. If anyone is using  
 the IETF network and not getting v6 addressing (receiving RAs),  
 please open a ticket with the NOC at:
 http://noc.ietf65.org/trac/

Thanks Jim.

Also nice to see a commercial carrier (verio.net) providing transit all the
way from the event to a UK exchange (where my traffic home to the UK JANET
network is peered).   I recall in the past Abilene has been used (and 
performed very well).  

$ traceroute6 www.ecs.soton.ac.uk
traceroute6 to augur.ecs.soton.ac.uk (2001:630:d0:f102:204:23ff:feb9:897f) from 
2001:df8::128:20a:95ff:fef4:c482, 30 hops max, 12 byte packets
 1  2001:df8::128:290:6902:748c:7c1f  3.321 ms  1.855 ms  1.852 ms
 2  2001:df8::9:290:69ff:fe8b:a800  2.571 ms  2.346 ms  2.132 ms
 3  fa-3-37.r02.dllstx09.us.bb.verio.net  1.921 ms  2.223 ms  4.23 ms
 4  xe-0-3-0.r20.dllstx09.us.bb.verio.net  3.986 ms  4.467 ms  2.253 ms
 5  xe-0-0-0.r21.dllstx09.us.bb.verio.net  2.6 ms  2.706 ms  2.15 ms
 6  p16-0-3-1.r20.asbnva01.us.bb.verio.net  34.564 ms  34.528 ms  34.285 ms
 7  xe-1-3-0.r21.asbnva01.us.bb.verio.net  34.999 ms  35.145 ms  34.313 ms
 8  p64-0-0-0.r20.nycmny01.us.bb.verio.net  40.69 ms  40.146 ms 
p64-2-0-0.r23.amstnl02.nl.bb.verio.net  126.415 ms
 9  p16-0-0-1.r23.londen03.uk.bb.verio.net  132.811 ms  132.861 ms  132.924 ms
10  xe-3-1.r01.londen03.uk.bb.verio.net  131.015 ms  131.24 ms  133.182 ms
11  ge-0.ukerna.londen03.uk.bb.verio.net  133.816 ms  124.149 ms  124.397 ms
12  2001:630:0:10::51  124.988 ms  124.766 ms  135.02 ms
13  gi5-0-1.lond-scr4.ja.net  135.016 ms  135.649 ms  134.725 ms
14  ...

Interesting Dutch (.nl.?) traceroute 'blip'.

-- 
Tim/::1



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

Re: Meeting Survey Results

[Tim Chown]

On Tue, Jan 24, 2006 at 08:45:51AM -0800, Ned Freed wrote:
 Are there cards with Mac OS X drivers nowadays?
 
 Yes there are. Here's the one I use:
 
   http://www.orangeware.com/endusers/wirelessformac.html
 
 There's a fairly long list of supported cards, some of which support 
 802.11a.
 I'm currently using a 3COM 3CRWE154A72 card, FWIW.

Away from the technobabble...

A key finding is that only 7% have to pay their own way to the IETF,
some of whom may have their own companies.

And only 7% say that the $50US fee hike might stop them attending again.

With so many people unhappy with wireless, these stats add up to charging
more for better wireless

The weird stat was 7% for whom $50US extra means they have to file
paperwork to get the money (just eat less? :)

-- 
Tim/::1



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

IETFs... the final Friday?

[Tim Chown]

Hi,

Has there been any discussion in the upper echelons of the IETF about the
issue of Friday sessions?

If you look back over past agendas, it's typically a day with around 3-5
meetings in one session to 11.30am, of which half or more are BoFs.

Is this likely to continue, such that if you're from a different
continent to the host, and you choose to travel home on Friday to get
home a day earlier and save a little hotel money, you stand a (slim) 
chance of missing a WG session you'd like to attend?

Personally I would be happy to travel back Saturday if I knew Friday
was a fullish day, but as it is it's neither here nor there really...
thoughts?

-- 
Tim/::1

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

Re: hotels for Dallas?

[Tim Chown]

On Fri, Jan 20, 2006 at 12:27:59PM +0100, Brian E Carpenter wrote:
 
 Registration for Dallas is in the final test stage, with a new system for
 credit card processing, and we want it to be rock solid.
 Should be open *really* soon now.

And the hotel info?

(And is the meeting ending 11.30am on the Friday?)

Tim

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

Re: Last Call: 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan' to Proposed Standard

[Tim Chown]

On Tue, Nov 22, 2005 at 10:52:23AM -0500, The IESG wrote:
 The IESG has received a request from the Global Routing Operations WG to 
 consider the following document:
 
 - 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and 
Aggregation Plan '
draft-ietf-grow-rfc1519bis-03.txt as a Proposed Standard
 
 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action.  Please send any comments to the
 iesg@ietf.org or ietf@ietf.org mailing lists by 2005-12-06.

Hi,

I think this is an interesting update.  

Some minor points that may wish to be considered but feel free to
pass over.

One is on section 2 - I think the issue is perhaps more the efficiency
of usage of IPv4 address space.   I know that is tied to rate of
consumption, but for many end site admins the impact of CIDR is a lot
of paperwork to demonstrate efficient use of allocated (or requested)
address space.

The rate of growth of the routing tables is perhaps also about the PI vs PA
issue.   Perhaps these terms could be explained in the text.

Another point is the use of private address space in the documentation for 
example purposes.  I know this is hard to avoid, but a statement like

 For example, the legacy class B network 172.16.0.0, with an implied
  network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16

seems odd when I normally see 172.16.0.0 and think of it as a /12.

A third point is on the negative impacts of CIDR.  

For example, in squeezing out every bit of the prefix address space, 
administrators often spend extra time resizing internal (globally addressed) 
subnets because their provider insists on them maximising the efficiency 
of their address plans (understandably).Or when a site grows, its
ISP offers it a different larger block (requiring renumebring) or 
non-contiguous ones, adding some internal complexity.

I would also suggest that this pressure has led to increased adoption of
NAT.   I don't see NAT mentioned anywhere in the text - perhaps it is
avoided for 'religious' reasons :)

I think in contrast to IPv6 address space allocation, in IPv6 we have 
aggregation from the outset, with a /48 per site (or maybe a /56 for some 
sites :) and in effect 'infinitely' sized subnets, so the above concerns 
are not really present for a typical IPv6 deployment.   Perhaps again 
though an aside into IPv6 comparisons with aggregation would be a 
distraction :)

-- 
Tim/::1

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

Re: IETF Meeting Venue Selection Criteria

[Tim Chown]

On Fri, Oct 14, 2005 at 04:39:18PM +0200, Brian E Carpenter wrote:
 Excuse me Stéphane, but I do not find these comments constructive.
 Anyone planning an international meeting for 1000+ people has
 to take a great many things seriously that you seem to think
 are amusing. We had some serious security problems in Paris,
 for example.

I agree.  The thing is, my personal view is that one of the best places to
get work done is Minneapolis, but if you suggested that as a venue out of 
the blue, most people would think you were a few cans short of a six pack.

We should be very open minded in venues to consider, and try to capture
what it is about those venues that seem to work in the requirements doc.

The fact that Minneapolis was 4 degrees F last time I was there didn't
really matter.  In fact coming from a country that now rarely sees snow
it was actually very enjoyable :)

Tim

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