Re: [Fwd: More information requested on publication status of draft-crocker-email-arch]

[Dave CROCKER]

Alexey Melnikov wrote:
   'Internet Mail Architecture'  as a Proposed 
Standard


The IESG has received a concern about the intended publication status of 
this document and wishes to confirm the community's preferences.




Folks,

As the document's author, my preference for its status is obvious.  But I 
thought it worth commenting on the reason I believe a document of this type -- 
and this particular document -- warrants standardization.


Any protocol specification that we do standardize is a component of an 
integrated service.  Standardizing a component, without standardizing the 
context into which is it being used, is a bit like writing a precise contract 
for a supply of screws or a heating element or bits of sheet metal, but not 
specifying their integration into a toaster, or some other particular 
(integrated) product.


The screws or heating elements might be used for a variety of other products. 
There's nothing wrong with that.  Those other uses do not constitute a 
"violation" of the toaster specification.  They're just different.


So it should be for an integrated service like Internet Mail.  We did not feel 
compelled to do the specification long ago because back then the service began 
in a kind of cottage industry within a small community. The systems 
specification was informally shared.  The community, now, is much larger and 
shares none of that original history.  This constantly causes confusion in 
discussions about the integrated service.  So, that community needs to see a 
specification for this particular service we call Internet Mail.


They need to see it as a standard for the same reason they need to see the 
components as standards.



d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-housley-aes-key-wrap-with-pad (Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm) to Informational RFC

[Sean Turner]

Can we add two ASN.1 modules.  They should include the OIDs and one 
should define the algs the old way (e.g., RFC 3370) and the other should 
define the algs the new way (draft-ietf-smime-new-asn1-05.txt)?  I would 
really like the OIDs in a module, as not having OIDs in a module has 
caused problems (there's no place to import the OIDs from).I'd be 
willing to whip them up if you want to include them.


spt

The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:

- 'Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm '
as an Informational RFC

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 2009-06-08. 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.


The file can be obtained via
http://www.ietf.org/internet-drafts/draft-housley-aes-key-wrap-with-pad-02.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18156&rfc_flag=0

___
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: Last Call: draft-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP

[Sean Turner]

The IESG wrote:



>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Guidance on Interoperation and Implementation Reports '
>as a BCP
>
>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 2009-06-18. 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.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-dusseault-impl-reports-02.txt
>
>
This is a fine document and I support its publication.


+1



I used an earlier version during the writing of the CMS [RFC3852] 
Interoperability I submitted in March.  I too found this a fine document 
and support its publication.


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

Re: Last Call: draft-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP

[Lisa Dusseault]

Will do, assuming my co-author agrees.

On Tue, May 26, 2009 at 3:58 PM, Paul Hoffman  wrote:
> At 2:45 PM -0700 5/26/09, Lisa Dusseault wrote:
>>Good suggestions.  I do agree with explaining why a subset was tested
>>and how that subset was chosen.  In some cases, however, listing all
>>known implementations would be onerous, ambiguous (an implementation
>>that shipped (or went beta) with partial (or untested) possibly
>>unannounced standards support) or even contrary to privacy agreements.
>
> Fully agree. That's why I listed them as suggestions, and I hope that this 
> document does so as well.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF 78 Announcement

[Ole Jacobsen]

I've been told there are NINE decent pipe organs in Maastricht.

(No, honest that was NOT why it was chosen, I would have gone
for Haarlem or Groningen but)

Check organdemo.info in about a years time, I'll see what can
be done, already have my Dutch friends working on it...

;-)

Ole


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



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

Re: IETF 78 Announcement

[Janet P Gunn]

So would it make sense to rent a CAR at BRU or AMS and DRIVE to 
Maastricht?

I am actually quite pleased with the choice, as Maastricht is quite close 
to Aachen, which is somewhere I have  long intended to visit.

Janet

ietf-boun...@ietf.org wrote on 05/24/2009 10:31:55 PM:

> Ole Jacobsen wrote:
> 
> > Like any engineering product, we can all argue about how well the 
> > compromise worked at the end of the day. Knowing this crowd, I am
> > sure we'll get all kinds of useful feedback from Stockholm, Hiroshima 
> > and even Maastricht.
> 
> Not to put to fine a point on it or anything but the distance between
> brussels (which has quite a large airport) or dusseldorf (which is a
> biggish secondary) and maastricht  is less than the distance between
> Narita and Yokohama.
> 
> You can almost but not quite fit greater los angeles between brussels
> and maastricht.
> 
> > Ole
> > ___
> > 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-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP

[Paul Hoffman]

At 2:45 PM -0700 5/26/09, Lisa Dusseault wrote:
>Good suggestions.  I do agree with explaining why a subset was tested
>and how that subset was chosen.  In some cases, however, listing all
>known implementations would be onerous, ambiguous (an implementation
>that shipped (or went beta) with partial (or untested) possibly
>unannounced standards support) or even contrary to privacy agreements.

Fully agree. That's why I listed them as suggestions, and I hope that this 
document does so as well.

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF 78 Annoucement

[David Kessens]

Antoin,

On Tue, May 26, 2009 at 03:45:20PM +0200, Antoin Verschuren wrote:
> 
> Paris Charles de Gaulle airport
> Is a reasonable alternative if your airline doesn't do Amsterdam or Brussels.
> The train journey to Maastricht will take you approx 3,5 hours, and includes 
> 2 stopovers.
> First from Paris CDG to Paris Nord by RER, then take the TGV to Brussels, and 
> then to Maastricht:
> 
> Aeroport Charles de Gaulle 1--Paris Nord
>   Paris Nord-- Bruxelles-Sud/Midi
>Bruxelles-Sud/Midi--Maastricht

There are many TGVs that go directly from CDG to brussels which cuts
out one connection and if your plane arrives at the right time, cuts
down the trip to 3 hours and 10 minutes which puts it in the same
order of magnitude as traveling from Amsterdam and has the advantage
of not having to travel at all on the congested dutch railway system
(and in fact one could argue whether you ever set foot on dutch soil ;-))

Iljitsch van Beijnum wrote:
> 
> So suppose you're flying from SFO with Northwest, leaving on friday.
> Land at 10:30 on saturday. (Results based on doing all of this the
> same week this year.) I don't think you'll make the 11:00 train, so it
> would have to be the 11:30 or 12:00 one, which gets you to the
> Maastricht train station at 14:04 or 14:34 with 6 minutes to change
> trains in Utrecht. So far so good.

Having flown this route many times, it is entirely possible to catch
the 11:00am train if you didn't check in, and even if you checked in,
more often than not this flight and other transatlantic flights arrive
early and you can also make it.

Also, if the meeting was held in Amsterdam, you would have still
needed to catch a train to Amsterdam. Catching the train to Maastricht
from Schiphol airport would not have caused an increase in difficulty
level compared to a train to Amsterdam. The only difference would have
been the longer travel time.

I agree that Maastricht is not an ideal location from a travel time
perspective and that locations like Paris are a better choice if
venues and sponsors happened to be available. On the other hand it is
really not that hard to get to Maastricht and certainly worth the few
extra travel hours compared to some of the cold and icy locations that
the IETF has visited in the recent past.

And when comparing it to Dublin, getting from the airport to the
meeting venue might actually not be much of a difference time wise
thanks to the horrible traffic situation around Dublin (unless you
were one of the lucky few who managed to into one of the black
helicopters).

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

IETF 81: Vancouver or Quebec?

[Ray Pelletier]

All;

The survey closes 1 June.

There have been nearly 400 votes cast.

Please let us know your preference.

https://www.surveymonkey.com/s.aspx?sm=0t2hfr934_2bEfmiPDNyEdlA_3d_3d

Thanks

Ray

The IAOC has qualified two venues in Canada for IETF 81 (July 2011) -  
the Vancouver Westin Bayshore and the Quebec City Convention Centre -  
and would like input from the community from this survey as to its  
preference before a final decision is taken.  The survey closes 1 June  
2009.


Vancouver advantages include:

*  Rooms and meeting space under one roof
*  Many direct North American and International flights
*  Well known location for an IETF meeting (IETF64 and IETF74 were  
held here)


Quebec City advantages include:

*  Broader range of hotel guest room rates and less expensive
*  A new location, adjacent to a European-like historic district with  
numerous restaurants
*  Convention center a short walk from main hotels (several within a 5  
minute walk)


The survey is 8 questions long and should take less than 3 minutes.

https://www.surveymonkey.com/s.aspx?sm=0t2hfr934_2bEfmiPDNyEdlA_3d_3d

Thank you for participating.

Ray Pelletier
IETF Administrative Director


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

Re: [Fwd: More information requested on publication status of draft-crocker-email-arch]

[Pete Resnick]

On 5/26/09 at 10:42 PM +0100, Alexey Melnikov wrote:

   'Internet Mail Architecture'  as a 
Proposed Standard


Please indicate your preference for publishing the document as:

   1. Proposed Standard, as queried in the two Last Call notices


I believe it should be Proposed Standard.


Also please indicate your reason(s) for this choice.


Restating something I sent to the IESG separately earlier:

This is an architecture document. We don't do these much anymore in 
the IETF, and this one is particularly strange because it is 
describing an architecture for a deployed service. However, I don't 
think that means we should shy away from it. We in the email 
community have needed this document for a *very* long time. We end up 
re-discussing architectural issues in each new WG just to get our 
terms straight and constrain solution spaces (cf. LEMONADE, MARID, 
DKIM). And we need to have a document to point to so that newcomers 
can couch their proposals in terms we understand without having to 
re-argue the model every time. But in order for it to work in these 
roles, and for it to have the ability to evolve over time, it really 
needs to be a standards track document.


Yes, there will inevitably be differences between the overall 
architecture of the system and the protocols that instantiate it. 
There are simply pragmatics which make such compromise required, and 
it is in fact a healthy tension. And yes, that fact means that some 
people will do stupid things, like claiming that where the 
architecture and protocols diverge, the architecture must win. There 
will always be such folks who don't understand that sometimes 
pragmatics prevail over architectural purity. But I think to not call 
this document what it is (i.e., an evolving community consensus on 
the email architecture) in fear of how it might be used is frankly a 
bit nuts. Let's address the problems as they arise rather than 
further diminishing the meaning of our document series.


pr
--
Pete Resnick 
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP

[Lisa Dusseault]

Good suggestions.  I do agree with explaining why a subset was tested
and how that subset was chosen.  In some cases, however, listing all
known implementations would be onerous, ambiguous (an implementation
that shipped (or went beta) with partial (or untested) possibly
unannounced standards support) or even contrary to privacy agreements.

Lisa

On Tue, May 26, 2009 at 12:38 PM, Stephane Bortzmeyer  wrote:
> On Tue, May 26, 2009 at 09:50:52AM -0700,
>  Lisa Dusseault  wrote
>  a message of 43 lines which said:
>
>> Do you have any suggestions for criteria that could be broadly
>> applicable and useful?
>
> Following Paul Hoffman, you could put in the I-D something like:
>
> All known (by the author of the report) implementations SHOULD be
> listed in the report and, if only a subset is tested, the reasons for
> selecting this subset SHOULD be written down. For instance, "We tested
> Foobar and Example because they are widely regarded as the two most
> common implementations." or "We tested Foobar and Example because they
> are the only ones available under a free software licence."
>
> (Paul's message contains other good examples.)
>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

[Fwd: More information requested on publication status of draft-crocker-email-arch]

[Alexey Melnikov]

[I am trying to avoid crossposting to 5 different mailing lists.]



--- Begin Message ---

There have been two Last Call notices sent to the IETF for:

   'Internet Mail Architecture'  as a 
Proposed Standard


The IESG has received a concern about the intended publication status of 
this document and wishes to confirm the community's preferences.
As the shepherding AD I would like to request more feedback on this 
topic. Please send your answers by the end of June 3rd.
You can either reply to this message, send your response directly to 
i...@ietf.org, or send it directly to me and Tony Hansen .


Please indicate your preference for publishing the document as:

   1. Proposed Standard, as queried in the two Last Call notices

   2. Informational

   3. Some other label

   4. I have another opinion (please describe)

Also please indicate your reason(s) for this choice.

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

Re: IETF 78 Annoucement

[Mans Nilsson]

Subject: Re: IETF 78 Annoucement Date: Tue, May 26, 2009 at 03:04:13PM +0200 
Quoting Tom.Petch (sisyp...@dial.pipex.com):
> 
> So May, delightful, June, pleasant, July, nightmare.  I wonder if that is why
> RIPE meet in May.

RIPE meets in May to get to sample Koninginnedag -- indeed an experience. 

Now, Maastricht, to get things back on topic, isn't that bad. From
home, it is 5 swaps and 21h on the European rail system. 

Narrator: You will now listen to my voice. My voice will help you and
guide you still deeper into Europa. Every time you hear my voice, with
every word and every number, you will enter into a still deeper layer,
open, relaxed and receptive. I shall now count from one to ten. On the
count of ten, you will be in Europa. 

(From the movie Europa, by Lars Von Trier, about an American
native trying to work in the post-war European railway system. Kind of
appropriate.)
-- 
Måns Nilsson


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

Re: Last Call: draft-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP

[Stephane Bortzmeyer]

On Tue, May 26, 2009 at 09:50:52AM -0700,
 Lisa Dusseault  wrote 
 a message of 43 lines which said:

> Do you have any suggestions for criteria that could be broadly
> applicable and useful?

Following Paul Hoffman, you could put in the I-D something like: 

All known (by the author of the report) implementations SHOULD be
listed in the report and, if only a subset is tested, the reasons for
selecting this subset SHOULD be written down. For instance, "We tested
Foobar and Example because they are widely regarded as the two most
common implementations." or "We tested Foobar and Example because they
are the only ones available under a free software licence."

(Paul's message contains other good examples.)

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

Re: Last Call: draft-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP

[Paul Hoffman]

At 9:50 AM -0700 5/26/09, Lisa Dusseault wrote:
>That's an excellent question, but I think like so many others it has
>to fall under the judgement of the person writing the implementation
>report.  Is it OK to just test 2 implementations or is it important to
>test 2 servers and 2 clients?  It might be possible to go to an
>interoperability forum and test 15 different implementations, yet if
>that's a protocol for which there's a sizable *other* community that
>doesn't implement a required feature, that ought to be noted in the
>implementation report.
>
>I'm hoping that by putting the onus on the writer of the report to
>carefully characterize interoperability, that we can encompass many
>such judgement questions.  On the flip side, if we tried to address
>every such judgement question, we couldn't possibly foresee every
>corner case.
>
>Do you have any suggestions for criteria that could be broadly
>applicable and useful?

One possible criterion would be "if you considered multiple implementations but 
focused on a subset for the report, at least discuss the wider set somewhere in 
the report". That could include a simple list of all the implementations 
considered, but also might include reasons for subsetting (some of the ones 
left out had difficult admin UIs, had licensing issues, and so on).

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IETF 78 Annoucement

[Antoin Verschuren]

Ah, yes Ole, you're right.
I missed that one because it involves traveling in 3 countries and it didn't 
show up in the regular travel planner from the Dutch railways because my 
subscribtion ticket isn't valid for the 3th country.
I never take the Maastricht-Liege route to Frankfurt from Eindhoven where I 
board the train, since that is longer for me, and I have to buy a surplus 
ticket.

As said, we will make a detailed trip advisor, and perhaps I'll even make 
pictures of the train stations, platforms, vending machines, scedules, signs 
and the one and only train conductor in the Netherlands that doesn't speak 
english just in case  he has duty on the train you'll be in (or perhaps he is 
retired by 2010) just to make it even more comfortable for non-train travelers.

You did a great job on Hiroshima, thank you for that.

Antoin Verschuren

Technical Advisor
Policy & Business Development
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525510
F +31 26 3525505
M +31 6 23368970
E antoin.verschu...@sidn.nl
W http://www.sidn.nl/




-Oorspronkelijk bericht-
Van: Ole Jacobsen [mailto:o...@cisco.com]
Verzonden: di 2009-05-26 17:33
Aan: Antoin Verschuren
CC: IETF Discussion
Onderwerp: RE: IETF 78 Annoucement
 

"Frankfurt airport Is probably your worst choice. Although there are 
lots of international flights, the train connection to Maastricht is 
poor. There is a 1 stopover train via Utrecht which takes 5:21 and a 3 
stopover journey that takes 4:25"

According the DB, the 3-connection ride is actually 3:35, but yeah, 
the scenic route via Utrecht is 5:21.

But you can also go via:

Frankfurt(M)
Flughafen Fernbf Su, 26.07.09 dep 13:43Fern 7   
Liege-Guillemins Su, 26.07.09 arr 15:42  
Liege-Guillemins Su, 26.07.09 dep 16:21 
Maastricht   Su, 26.07.09 arr 16:50 4b

That's ONE change and 3:07 from Frankfurt. And the departure is late 
enough in the day that you could do it the same day after flying in
to FRA. I am not pushing for FRA as the arrival point, just pointing
out that it's no worse than Amsterdam and there are of course lots of
flights to FRA from all over the world as you say.

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj




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

Re: Last Call: draft-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP

[Lisa Dusseault]

That's an excellent question, but I think like so many others it has
to fall under the judgement of the person writing the implementation
report.  Is it OK to just test 2 implementations or is it important to
test 2 servers and 2 clients?  It might be possible to go to an
interoperability forum and test 15 different implementations, yet if
that's a protocol for which there's a sizable *other* community that
doesn't implement a required feature, that ought to be noted in the
implementation report.

I'm hoping that by putting the onus on the writer of the report to
carefully characterize interoperability, that we can encompass many
such judgement questions.  On the flip side, if we tried to address
every such judgement question, we couldn't possibly foresee every
corner case.

Do you have any suggestions for criteria that could be broadly
applicable and useful?

Thanks,
Lisa

On Tue, May 26, 2009 at 1:35 AM, Stephane Bortzmeyer  wrote:
> On Thu, May 21, 2009 at 11:09:01AM -0700,
>  The IESG  wrote
>  a message of 23 lines which said:
>
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>>
>> - 'Guidance on Interoperation and Implementation Reports '
>>     as a BCP
>
> It's a fine and useful document. But something is missing: how to
> select the implementations tested when there are "many". For RFC 4234
> (mentioned in the I-D), some implementations were tested
>  and some
> were not. On what criteria?
>
> ___
> 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: IETF 78 Annoucement

[Samuel Weiler]

On Sun, 24 May 2009, Iljitsch van Beijnum wrote:

Not sure if making attending IETF meetings as difficult as possible 
is a winning strategy.


But at least this venue is not "as difficult as possible".

For comparison, consider Mar del Plata, Argentina, the venue for the 
April 2005 ICANN meeting[2].  It's 400km from Buenos Aires[1].


There is a train from Buenos Aires.  It takes 5.5 hours[1].

Aerolineas runs one or two flights a day (in the off season) from 
Buenos Aires' Arpt. Jorge Newbery (AEP).  But international flights 
arrive at EZE, which means there's a long surface transfer involved in 
you want to fly.


Or you can drive.  Or take the bus.

Besides, July is a lovely time to visit the Netherlands.  :-)

-- Sam


[1] http://wikitravel.org/en/Mar_del_Plata
[2] http://www.icann.org/en/meetings/mardelplata/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Security of BGP Re: Status of the 16-bit AS Number space

[Phillip Hallam-Baker]

On Sat, May 23, 2009 at 5:52 AM, Iljitsch van Beijnum
 wrote:
> [belatedly]
>
> On 12 mei 2009, at 21:42, Phillip Hallam-Baker wrote:
>
>> As for adding IPSEC to BGP, I would not want to comment on the
>> competence of the person involved.
>
> We need to replace the MD5 hack with IPsec, because MD5 doesn't have any DoS
> potection, crypto algorithm agility or key rollover mechanisms. But of
> course that only protects your BGP sessions, not the content of the
> information in those sessions.

We should replace the MD5 hack with something that makes for easier
management. It is somewhat disturbing to be reading specs that only
support one algorithm with a reference to a paper describing how that
algorithm was broken.

>> In particular I find it utterly unbelievable that large backbone
>> corporation A is going to configure its border routers to simply
>> accept routing information from large backboe corporation B. If I was
>> responsible for large corporation A then every piece of external
>> routing data would be funnelled into a control center and the edge
>> routers would only respond to control instructions from the control
>> center. No matter what specifications and standards might opine, that
>> is how I would run my network.
>
> Sounds like a plan. Now explain to us how your control center knows which
> routing information is valid and which isn't? You have in the order of 30
> seconds to decide for every update before your customers start to complain
> that "the internet" is broken.

30 seconds sounds a reasonable response time to aim for. Central
control need not be a single centralized control room. In fact much
better it is not. Rather what you want is to have centralized policy
development and localized enforcement.

But I think we need to restate the problem. We don't need to prove
that the information is valid so much as determine whether it is
likely to break things or not.

This looks much more like a spam filtering type problem to me than
pure access control.

So a first cut we might make on the data is to identify route
advertisements that are within previously established 'normal' bounds.
We do not need to vet every route advertisement, we only need to look
at those that are 'surprising'. Something of this sort must be taking
place already since each network has to decide whether to (1) use the
new route itself and (2) send out updated advertisements itself.

Having reduced the volume of routes to those that represent
'surprises' we have a problem that cannot be solved for the individual
route announcement in isolation. Like the spam problem we can only
evaluate routes by bringing in additional information to bear. In
particular we need to know if the routes that we are attempting to use
are connecting to the valid endpoints or not. We do not need to do
that for every route advertisement, just as we do not need to content
analyze every potential spam. We can also use reputation. But we do
need a source of grounding data if we are going to use reputation.


Traditional route analysis has to work with the IP level data that is
exposed in the current day Internet. That is fine provided that you
are not under attack from an intelligent adversary. Simply sending out
a bogus BGP announcement is not going to allow you to perform a long
term DDoS attack. The route is going to be quickly discarded if there
is nothing there to connect to.

So in summary, I think that to solve the BGP issue we need to look up
the stack as well and work out methods that allow for reliable
reporting of attack conditions.

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF 78 Annoucement

[David A. Bryan]

On Sun, May 24, 2009 at 3:54 PM, Ole Jacobsen  wrote:

> Coming from Tokyo to Minneapolis isn't exactly a single hop either if
> you want to consider another case.

Actually, it is a single hop. There is daily non-stop service from Tokyo to MSP:

http://www.orbitz.com/flight-info/NW/NW-MSP-NRT.html

And there are quite a few non-stop flights to MSP from Europe as well,
including Paris, Amsterdam, and Heathrow, plus Mumbai and
Singaporeand this is just the Northwest (Delta) non-stops. So
while personally I love visiting the Netherlands and think Maastricht
will be a very fun trip indeed, it will be quite difficult to get to,
and arguing this is somehow even remotely similar to Minneapolis in
terms of air service is pretty far off the mark. Minneapolis is not
Chicago or London, and lack of competition might make it a bit pricier
than some other airports, but it has a very well served international
airport.

David


>
> Plug: See hiroshima-info.info for general travel information for IETF
> 76.
>
>>
>> I also assume that you have attempted to launch a "sponsor IETF meetings"
>> program on a "contribute to a fund" basis, as distinct from "host this
>> particular meeting", and either gotten no useful response or discovered that
>> host in-kind contributions in specific locations dominate possible cash
>> contributions.  Can you confirm that as well?
>
> I think Ray and Drew can answer this better, but let's just say that
> the "money pool" idea is very difficult to sell to most sponsors.
>
>>
>> Finally, I assume that the IAOC has done an analysis, not only of what it
>> would cost us to abandon hosted meetings entirely, but of what it would cost
>> --both in absolute and meeting-fee terms-- to say "no" to hosts who insisted
>> on out of the way locations.  May we see that analysis not later than the
>> plenary in Stockholm?
>
> I don't think we've ever had hosts who have "insisted on out of the
> way locations," but I agree that such an analysis would be good to
> present.
>
> Ole
>
>>
>> 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

Security Review of draft-ietf-behave-nat-behavior-discovery-06

[Dave Cridland]

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG.  These comments were written primarily for the benefit of the  
security area directors.  Document editors and WG chairs should treat  
these comments just like any other last call comments.


(I note there is expected to be a new version coming for this draft).

Security Issues:

The Security Considerations section is reasonably complete, as far as  
I can tell, however it is not terribly clear that it suggests  
authentication of the clients (it says "preexisting credentials") - I  
think this could be clearer. The description of XOR-RESPONSE-TARGET  
also doesn't include this, it's mentioned most clearly in Section 6.1.


General comments:

I have a strong suspicion that this document is Experimental purely  
because it failed to gain sufficient consensus to be Standards-Track.  
It's not clear to me why this is not Informational, or why all the  
extensions described in the document are within the same document.  
I'm dubious that they're all of similar quality.


If there is an experiment here, then it's in the usage of these  
extensions to determine whether, at least in some cases, NAT  
behaviour is sufficiently stable as to be useful, and moreover,  
whether taking advantage of this is practical. The extensions  
themselves clearly seem suitable for discovering whether this is so.


As such, section 2.3 seems somewhat contrived and grasping. This  
isn't to say that the hypothesis being tested is not valid, but the  
experiment, as defined, seems like a matter of form rather than a  
useful test of the hypothesis as outlined.


Editorial Issues:

The use of the term "aprocyphal" is interesting, but conjures up  
connotations that seem to be somewhat self-defeating. Perhaps  
"anecdotal" would be more fitting, or "controversial". (It is this  
evidence, after all, that forms the hypothesis mentioned above, and  
the hypothesis itself is surely not aprocypha).


IANA section requests registration of CHANGE-REQUEST, but this is  
already registered - the registration needs changing, as per section  
6.1, where the situation is detailed more clearly.


Typographical Errors:

Extraneous "}" in section 9.4.

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

Re: Stockholm IETF Code Sprint

[IETF Chair]

Please excuse the typo.  The code sprint will take place on July 25th
(not July 15th).

Russ

IETF Chair wrote:
> Stockholm IETF Code Sprint
> 
> When:  July 15, 2009, begining at 9:30 AM
> 
> Where: IETF Hotel in Stockholm 
> 
> What:  A bunch of hackers get together to work on code for the IETF web
>site.  Some people may be porting of existing functionality to
>the new framework; some people may be adding exciting new
>functionality.  All code will become part of the open source
>IETF tools.
> 
> 
> Who:   Hopefully you can help
> 
> 
> Chris Newman will be helping with advance planning.  Henrik Levkowetz
> will be coordinating the event in Stockholm.  You will hear more from
> them shortly.  Many of the results of the last code sprint are being
> used every day.
> 
> 
> Please support the tools development effort,
>Russ

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

Re: IETF 78 Annoucement

[Spencer Dawkins]

Hi, Antoin,

This was quite tranquilizing. Thank you for posting.

I haven't been an adventurous traveler in Europe, but did have a nice 
day-long train trip from Amsterdam (SHIM6 interim) to Paris (Softwires 
interim) a couple of years ago, and that was OK. So I think there's hope.


On the other hand, my most adventurous IETF was the Dallas IETF And 
Watersports Event, and that was about 40 miles from my house, so I bet the 
biggest issue for IETF 78 turns out to be a surprise, too!


Spencer


However, the Netherlands only has a single airport with decent
connections and ground transportation. For those of us traveling to
IETF-78 from within Europe it's still doable (probably have to
sacrifice the friday afternoon sessions, though) but I'm glad I don't
have to fly in from the US west coast or Asia.


First to respond to Iljitsch comments of more plausible venues.
The major issue here in NL are Hotels, not conference centers.
That's because conference attendees usually don't stay over in NL, but go 
home to wife and kids in this densely populated country. The trip home is 
on average about an hour from any congress location.
The largest hotel in NL is yet to be build, and has a capacity of 500 
rooms. All other hotels are (much) smaller, and they usually are for 
tourists.
There are cities that have a joint hotel capacity for an IETF, but if you 
don't want to end up in Youth hostels, Budget Hotels or sloppy Airport 
hotels with no facilities at all in the hotel or neighborhood, there are 3 
places left. So Utrecht and Rotterdam are not viable options due to 
spreading out over too many and too uncomfortable hotels.
Some of us don't mind about hotel quality, but other frequent travelers 
do. An IETF should provide capacity for both.
Maastricht wouldn't have been my first choice due to the absence of an 
International airport, but I'm sure the location was chosen because of 
other logistics that could not be met in Amsterdam or The Hague.


You might also have noticed that there are multiple sponsors for this 
meeting, none of them being major international corporations.
None of these sponsors could carry the sponsoring budget all by 
themselves, but they all wanted to contribute to make your cost less.
That might also explain the choice of the venue, as there are sponsors 
from NL, BE and DE.
If you don't want sponsors like that anymore, and only choose large 
multinationals that don't care about location of the meeting, fine. You'll 
have less sponsors to choose from, and end up in the same places like 
Minneapolis every time.


And perhaps it's time to tranquilize some people.
I live in the south of the Netherlands, and I have to make the journey 
to/from Amsterdam/Brussels/Paris/Frankfurt airport on EVERY IETF or other 
trip that involves flying.
And I travel 100 km to work every day, which takes me less time than to 
get from an Amsterdam outskirt to Amsterdam center, so reach ability is 
something else than proximity.
There used to be scheduled domestic flights between Amsterdam Schiphol 
Airport and other Dutch airports like Maastricht-Aachen Airport, but they 
abolished them a number of years ago because the train between those 
airports was faster, cheaper, more frequent, more economical and more 
efficient than a flight.


I'll make sure there will be a good guide in due time.
But to give you some of my experiences in advance:

Train travel is the most used and comfortable way to reach an airport in 
Western Europe.
I find a taxi ride from any airport anywhere in the world more adventurous 
and risky than a train from Schiphol in the Netherlands.

Trains are clean, comfortable and run on schedule here.
You'll also find that this is more true on the Amsterdam-Maastricht 
intercity line than on local trains near Amsterdam/The Hague/Rotterdam.
Your figure of 80% trains that run on time is only because we consider a 
train late when it's 1 minute overdue, even when the next train is 
scheduled 15 minutes later.
By that definition, a taxi ride during rush hour is less predictable, and 
will never run on time.


The 4 major International airports for Maastricht are Amsterdam, Brussels, 
Paris and Frankfurt.


Amsterdam Schiphol airport.
This is probably your best choice.
The train journey to Maastricht will take you 2:34 on weekdays, 2:50 in 
the weekends and runs every half hour between 5:02 and 22:14.
It involves 1 stopover in either Utrecht, 's-Hertogenbosch or Eindhoven, 
so there is enough choice and no reason for panic:


Schiphol--Utrecht--'s-Hertogenbosch--Eindhoven
 Utrecht--'s-Hertogenbosch--Eindhoven--Maastricht

Maastricht is an end station, so no reason to panic getting off. Everybody 
leaves the train in Maastricht, you will not miss your stop.


Brussels airport
Also a good choice, but with less international flights. If your airline 
does do Brussels, it's an excellent choice.
The train journey to Maastricht will take you 1:46 or 1:58 and runs every 
hour between 5:50 and 21:5

Re: IETF 78 Annoucement

[Douglas Otis]

On May 25, 2009, at 4:56 PM, John C Klensin wrote:

With a train, you have to pick the correct train, and then leave  
the train at the correct stop. A bit more complicated to be honest.  
By interacting with people, you often can handle the most  
complicated train ride, but yes, it might be more complicated with  
train.


Complication that, in many cases, is severely complicated by being  
tired, exhausted, and out of focus from a long flight.


It could be there are only two more generations be able to travel  
extensively by jet airplanes.  Perhaps zeppelin travel will return.   
Trains are about 5 times more energy efficient that planes, and about  
3 times that of autos. While there is little safety difference between  
planes and trains, there is a significant difference between that of  
autos.  Dealing with trains is also much less common for those in  
North America than from other locales.  While I agree making sense of  
train schedules, and at times even knowing which direction the train  
should be heading to find the correct tracks, can be challenging.   
Patrik is right.  Sometimes you need to ask. :^)


-Doug

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

Re: IETF 78 Annoucement

[Tom.Petch]

- Original Message -
From: "Ole Jacobsen" 
To: "Iljitsch van Beijnum" 
Cc: "Harald Tveit Alvestrand" ; "IETF Discussion"

Sent: Monday, May 25, 2009 6:09 PM
Subject: Re: IETF 78 Annoucement

> I don't know why you think moving the meeting to June will make more
> facilities available in Europe. July-August is the traditional
> vacation season and hence "off season" for conferences.

Precisely, and if facilities include travel, which for me as a potential
participant they do, then yes, more is available.

When last I used Schipol, it was for a July meeting and, for a one hop
flight to another European country, I was told to check in three hours
beforehand.  This was before the security scares, when a one hour check-in would
be lengthy.  When I asked why so long, I was told never to use Schipol at a
weekend in July; holiday season, always a nightmare.  And it was; the check-in
queue is etched in my brain still.

So May, delightful, June, pleasant, July, nightmare.  I wonder if that is why
RIPE meet in May.

Tom Petch

>
The extreme
> example might be IETF in Paris which one could argue suffered slightly
> from the fact that Paris was basically "closed for vacation" at that
> time, but I am sure it made it easier to get the convention center
> and hotel and probably cheaper too. And the "closed" condition didn't
> seem to cause anyone to starve etc.
>
> Ole
>
> Ole J. Jacobsen
> Editor and Publisher,  The Internet Protocol Journal
> Cisco Systems
> Tel: +1 408-527-8972   Mobile: +1 415-370-4628
> E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
>

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

RE: IETF 78 Annoucement

[Ole Jacobsen]

"Frankfurt airport Is probably your worst choice. Although there are 
lots of international flights, the train connection to Maastricht is 
poor. There is a 1 stopover train via Utrecht which takes 5:21 and a 3 
stopover journey that takes 4:25"

According the DB, the 3-connection ride is actually 3:35, but yeah, 
the scenic route via Utrecht is 5:21.

But you can also go via:

Frankfurt(M)
Flughafen Fernbf Su, 26.07.09 dep 13:43Fern 7   
Liege-Guillemins Su, 26.07.09 arr 15:42  
Liege-Guillemins Su, 26.07.09 dep 16:21 
Maastricht   Su, 26.07.09 arr 16:50 4b

That's ONE change and 3:07 from Frankfurt. And the departure is late 
enough in the day that you could do it the same day after flying in
to FRA. I am not pushing for FRA as the arrival point, just pointing
out that it's no worse than Amsterdam and there are of course lots of
flights to FRA from all over the world as you say.

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



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

RE: IETF 78 Annoucement

[Antoin Verschuren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 26 mei 2009, at 23:33, Iljitsch van Beijnum wrote:

> However, the Netherlands only has a single airport with decent
> connections and ground transportation. For those of us traveling to
> IETF-78 from within Europe it's still doable (probably have to
> sacrifice the friday afternoon sessions, though) but I'm glad I don't
> have to fly in from the US west coast or Asia.

First to respond to Iljitsch comments of more plausible venues.
The major issue here in NL are Hotels, not conference centers.
That's because conference attendees usually don't stay over in NL, but go home 
to wife and kids in this densely populated country. The trip home is on average 
about an hour from any congress location.
The largest hotel in NL is yet to be build, and has a capacity of 500 rooms. 
All other hotels are (much) smaller, and they usually are for tourists.
There are cities that have a joint hotel capacity for an IETF, but if you don't 
want to end up in Youth hostels, Budget Hotels or sloppy Airport hotels with no 
facilities at all in the hotel or neighborhood, there are 3 places left. So 
Utrecht and Rotterdam are not viable options due to spreading out over too many 
and too uncomfortable hotels.
Some of us don't mind about hotel quality, but other frequent travelers do. An 
IETF should provide capacity for both.
Maastricht wouldn't have been my first choice due to the absence of an 
International airport, but I'm sure the location was chosen because of other 
logistics that could not be met in Amsterdam or The Hague.

You might also have noticed that there are multiple sponsors for this meeting, 
none of them being major international corporations.
None of these sponsors could carry the sponsoring budget all by themselves, but 
they all wanted to contribute to make your cost less.
That might also explain the choice of the venue, as there are sponsors from NL, 
BE and DE.
If you don't want sponsors like that anymore, and only choose large 
multinationals that don't care about location of the meeting, fine. You'll have 
less sponsors to choose from, and end up in the same places like Minneapolis 
every time.

And perhaps it's time to tranquilize some people.
I live in the south of the Netherlands, and I have to make the journey to/from 
Amsterdam/Brussels/Paris/Frankfurt airport on EVERY IETF or other trip that 
involves flying.
And I travel 100 km to work every day, which takes me less time than to get 
from an Amsterdam outskirt to Amsterdam center, so reach ability is something 
else than proximity.
There used to be scheduled domestic flights between Amsterdam Schiphol Airport 
and other Dutch airports like Maastricht-Aachen Airport, but they abolished 
them a number of years ago because the train between those airports was faster, 
cheaper, more frequent, more economical and more efficient than a flight.

I'll make sure there will be a good guide in due time.
But to give you some of my experiences in advance:

Train travel is the most used and comfortable way to reach an airport in 
Western Europe.
I find a taxi ride from any airport anywhere in the world more adventurous and 
risky than a train from Schiphol in the Netherlands.
Trains are clean, comfortable and run on schedule here.
You'll also find that this is more true on the Amsterdam-Maastricht intercity 
line than on local trains near Amsterdam/The Hague/Rotterdam.
Your figure of 80% trains that run on time is only because we consider a train 
late when it's 1 minute overdue, even when the next train is scheduled 15 
minutes later.
By that definition, a taxi ride during rush hour is less predictable, and will 
never run on time.

The 4 major International airports for Maastricht are Amsterdam, Brussels, 
Paris and Frankfurt.

Amsterdam Schiphol airport.
This is probably your best choice.
The train journey to Maastricht will take you 2:34 on weekdays, 2:50 in the 
weekends and runs every half hour between 5:02 and 22:14.
It involves 1 stopover in either Utrecht, 's-Hertogenbosch or Eindhoven, so 
there is enough choice and no reason for panic:

Schiphol--Utrecht--'s-Hertogenbosch--Eindhoven
  Utrecht--'s-Hertogenbosch--Eindhoven--Maastricht

Maastricht is an end station, so no reason to panic getting off. Everybody 
leaves the train in Maastricht, you will not miss your stop.

Brussels airport
Also a good choice, but with less international flights. If your airline does 
do Brussels, it's an excellent choice.
The train journey to Maastricht will take you 1:46 or 1:58 and runs every hour 
between 5:50 and 21:50.
It involves 1 stopover in Brussels:

Bruxelles-Nat.-Aéroport-- Brussel Noord/Bruxelles Nord
  Brussel Noord/Bruxelles Nord--Maastricht


Paris Charles de Gaulle airport
Is a reasonable alternative if your airline doesn't do Amsterdam or Brussels.
The train journey to Maastricht will take you approx 3,5 hours, and includes 2 
stopovers.
First from Paris CDG to Paris Nord

Re: Security of BGP Re: Status of the 16-bit AS Number space

[Iljitsch van Beijnum]

On 25 mei 2009, at 19:34, Phillip Hallam-Baker wrote:


But I think we need to restate the problem. We don't need to prove
that the information is valid so much as determine whether it is
likely to break things or not.


Not simple. One approach that seems attractive is to still allow  
routes that don't pass the authentication steps, but prefer ones that  
do by giving them a higher local preference. Ideally, we would reject  
routes that don't authenticate, but the problem with that is that  
today, none do, so at the very least there needs to be a transition  
period. But we all know what happens to transition periods... If we  
can get around that there's the issue of different kinds of failures  
in the authentication chain. People forgetting to install new  
certificates before the old ones expire is rather common. If that  
breaks your network, good luck getting that new certificate. But the  
"prefer authentic over unprovable" mechanism still has the issue that  
an attacker can inject false information and then do a DoS against the  
authentic information so eventually, the false information is used.



This looks much more like a spam filtering type problem to me than
pure access control.


I really don't want false positives in my route filtering...


So a first cut we might make on the data is to identify route
advertisements that are within previously established 'normal' bounds.


But how do you accommodate for normal failure conditions that routing  
should solve in that case?



Having reduced the volume of routes to those that represent
'surprises' we have a problem that cannot be solved for the individual
route announcement in isolation. Like the spam problem we can only
evaluate routes by bringing in additional information to bear.


Today, RFC 4271 tells us:

   The function that calculates the degree of preference for a given
   route SHALL NOT use any of the following as its inputs: the  
existence

   of other routes, the non-existence of other routes, or the path
   attributes of other routes


So in summary, I think that to solve the BGP issue we need to look up
the stack as well and work out methods that allow for reliable
reporting of attack conditions.


I don't have all the answers, but it seems to me like the model that  
would be most appropriate for BGP would be more like SSH (everyone  
manages their own trust) and a PGP web of trust than a root-anchored  
PKI.

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

Re: IETF 78 Annoucement

[Joel M. Halpern]

Please, let us keep a couple of things in mind here.

Firstly, I am quite sure that a large number of factors, both formal and 
informal, are evaluated by the IAOC in selecting a venue.  While we may 
or may not want more information, asking them to give us "all" the 
information they consider is, in my opinion, a request that can not and 
should not be fulfilled.


Let us also remember that we are actually getting better visibility to 
the selection process, and a better ability to provide input.


Most importantly, given the real world constraints, venue selection is 
hard.  As a community, we tend to articulate sets of mutually 
incompatible requirements.  (usually, it is different people with 
different requirements, but sometimes)


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

Re: IETF 78 Annoucement

[Ole Jacobsen]

On Tue, 26 May 2009, Iljitsch van Beijnum wrote:

> 
> It just doesn't make sense to me to meet in places that are that hard to
> reach. I've skipped San Diego for exactly this reason in the past and I'm not
> sure I'll be going to Hiroshima.

Neither are hard to reach, that's just your own definition.

> 
> The fact that there is very little information coming out about how this
> decision was reached and some of it has been of questionable quality ("MAYBE 3
> venues big enough", I listed 4 so with Maastricht that's 5; "reason for
> meeting during European holiday season lost in the mists of time") doesn't
> help.

You are either deliberately distorting what was said or you didn't 
understand it. Whether there are 3, 4 or 5 event venues that YOU think 
might be suitable isn't relevant. The availability of said venues, 
nearby hotels, cost, network-ability and so are the factors that have 
to be considered. I hope you understand that selecting a venue takes
more than 5 minutes with Google.

As for "lost in the mist of time", I think Fred explained the sequence 
of events that led to the current schedule, and let's not forgot the 
STRONG desire from the IETF community to have events that don't clash
with other meetings and that can be planned for more than 6 months 
out. Besides, you haven't offered a single reason why moving the 
meeting back to say June would be benefitial. You have theories about
availability, that's all.

Ole


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

Re: IETF 78 Annoucement

[Donald Eastlake]

On Tue, May 26, 2009 at 5:10 AM, Iljitsch van Beijnum
 wrote:
> On 25 mei 2009, at 23:33, Ole Jacobsen wrote:
>
>> Of all the people who have to travel to this meeting, I would not have
>> imagined that you would be the one to complain.
>
> It just doesn't make sense to me to meet in places that are that hard to
> reach. I've skipped San Diego for exactly this reason in the past and I'm
> not sure I'll be going to Hiroshima.

San Diego is, perhaps, the only IETF meeting where it is practical to
walk from the airport to the usual hotel.

Donald
=
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e...@gmail.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IETF 78 Annoucement

[BRUNGARD, DEBORAH A, ATTLABS]

While Netherlands is one of my favorite countries, over the last couple of 
years, the train service has become much less dependable. Maintenance 
activities are common, especially on weekends, where a bus is available between 
the two points, but the timing is unpredictable. And only if you have looked 
on-line and can read Dutch, will you be aware of it. And sometimes there are 
strikes - sometimes while you are on the train - it happened to me on the train 
between the airport and Amsterdam - and again the announcements were only in 
Dutch. Most Dutch can speak English, and someone will translate for you.
 
Suggest if you need to make a morning flight, stay the night before at an 
airport hotel or in Amsterdam where you can also take a taxi/airport bus. And 
this gives you the opportunity to also see Amsterdam:-)



From: ietf-boun...@ietf.org on behalf of Iljitsch van Beijnum
Sent: Tue 5/26/2009 4:10 AM
To: Ole Jacobsen
Cc: IETF Discussion
Subject: Re: IETF 78 Annoucement



On 25 mei 2009, at 23:33, Ole Jacobsen wrote:

> Of all the people who have to travel to this meeting, I would not have
> imagined that you would be the one to complain.

It just doesn't make sense to me to meet in places that are that hard 
to reach. I've skipped San Diego for exactly this reason in the past 
and I'm not sure I'll be going to Hiroshima.

The fact that there is very little information coming out about how 
this decision was reached and some of it has been of questionable 
quality ("MAYBE 3 venues big enough", I listed 4 so with Maastricht 
that's 5; "reason for meeting during European holiday season lost in 
the mists of time") doesn't help.

> The Netherlands is not
> a large country and it's not far from a lot of places in continental
> Europe.


However, the Netherlands only has a single airport with decent 
connections and ground transportation. For those of us traveling to 
IETF-78 from within Europe it's still doable (probably have to 
sacrifice the friday afternoon sessions, though) but I'm glad I don't 
have to fly in from the US west coast or Asia.
___
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: IETF 78 Annoucement

[Iljitsch van Beijnum]

On 25 mei 2009, at 23:33, Ole Jacobsen wrote:


Of all the people who have to travel to this meeting, I would not have
imagined that you would be the one to complain.


It just doesn't make sense to me to meet in places that are that hard  
to reach. I've skipped San Diego for exactly this reason in the past  
and I'm not sure I'll be going to Hiroshima.


The fact that there is very little information coming out about how  
this decision was reached and some of it has been of questionable  
quality ("MAYBE 3 venues big enough", I listed 4 so with Maastricht  
that's 5; "reason for meeting during European holiday season lost in  
the mists of time") doesn't help.



The Netherlands is not
a large country and it's not far from a lot of places in continental
Europe.



However, the Netherlands only has a single airport with decent  
connections and ground transportation. For those of us traveling to  
IETF-78 from within Europe it's still doable (probably have to  
sacrifice the friday afternoon sessions, though) but I'm glad I don't  
have to fly in from the US west coast or Asia.

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

Re: Last Call: draft-dusseault-impl-reports (Guidance on Interoperation and Implementation Reports) to BCP

[Stephane Bortzmeyer]

On Thu, May 21, 2009 at 11:09:01AM -0700,
 The IESG  wrote 
 a message of 23 lines which said:

> The IESG has received a request from an individual submitter to consider
> the following document:
> 
> - 'Guidance on Interoperation and Implementation Reports '
> as a BCP

It's a fine and useful document. But something is missing: how to
select the implementations tested when there are "many". For RFC 4234
(mentioned in the I-D), some implementations were tested
 and some
were not. On what criteria?

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