AB,
You wrote:
but the authors are gaining so far.
That may be your opinion.
But it is absolutely not my opinion.
As the author of this draft I have worked four years to
address all the comments received, and improve the quality
of the document.
So you had four years to review and comment.
Hello Nabil,
Considering your response:
NB Please, see above. There are different contexts per above where the
expanded terminology is applied. Are you suggesting still using Reverse
Defect Indication per above where needed but not to abbreviate it? RDI as
Remote Defect Indication part of
Hello Nabil,
You replied:
I will folloup on the other emails. Just catching up in reverse order.
RDI (Reverse defect indication) is what is used in RFC 6310 to indicate
failure in the rverse direction from the failure, and this document is
aligned with that.
RDI is used to indicate that
that there's no need for re-mapping. I think that it is
easier to follow Y.1731.
I agree that this is the best.
These are the abbreviations used for MPLS-TP too.
Best regards, Huub.
On Fri, Jan 4, 2013 at 8:30 AM, Huub van Helvoort huubatw...@gmail.com
mailto:huubatw...@gmail.com wrote:
All
Hello Nabil,
Greg is almost right.
RDI == Remote Defect Indication
This is the abbreviation used in IEEE 802.1ag, Y.1731, G.707, G.8121
and rfc6428.
Regards, Huub.
can we avoid different interpretation of the same abbreviation (RDI):
RDI Remote Defect Indication for Continuity Check
All,
Some nits that need to be fixed:
ME Maintenance Entity
MEG Maintenance Entity Group
MEP Maintenance End Point
MEP ME End Point or Maintenance Entity End Point
MIP Maintenance End Point
MIP ME Intermediate Point or Maintenance Entity Intermediate Point
3.2.
On Thu, Oct 25, 2012 at 5:37 AM, David Sheets kosmo...@gmail.com wrote:
On Tue, Oct 23, 2012 at 10:05 PM, Ian Hickson i...@hixie.ch wrote:
No, Anne hasn't finished defining conformance yet. (He just started
today.)
This is a political dodge to delay the inevitable discussion of
address space
On Wed, Oct 24, 2012 at 8:41 AM, Manger, James H
james.h.man...@team.telstra.com wrote:
That is good to hear. There is no hint about this in the current
text/outline. There is an invalid flag in the current text -- but that is
for strings that are so broken no error handling can resurrect a
Hi Dale,
You wondered:
and btw my motto:
geek c ést chic!
What responses do you receive to your motto?
That it is spelled wrong...
BR, Huub.
[mailto:ietf-boun...@ietf.org] On Behalf Of
ext Huub van Helvoort
Sent: Friday, March 23, 2012 1:28 AM
To: ietf@ietf.org
Subject: Re: Last Call:draft-ietf-mpls-tp-oam-analysis-08.txt (An
Overviewofthe OAM Tool Set for MPLS based Transport Networks)
toInformational RFC
Hallo Nurit,
You replied
then, but it can easily be fixed!
Best regards,
Nurit
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
ext Huub van Helvoort
Sent: Thursday, March 22, 2012 12:49 AM
To: ietf@ietf.org
Subject: Re: Last Call: draft-ietf-mpls-tp-oam-analysis-08.txt
IESG,
I do *NOT* support this draft unless the following changes are made:
The first paragraph of section 8 Acknowledgements has to be removed:
It is an attempt to capture history, but lacks accuracy.
Removal does not impact the technical information in the draft;
the tools have evolved
Hello,
I continue my support for the codepoint allocation
I agree with Russ's statement in
https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=62185tid=1331648664
Some people are using the lack of a code point as the reason that
the cannot support the ITU-T document. My approach tells the
On 15 Mar 2012, at 11:47 , Shane Kerr wrote:
Yet we know based on country attendance statistics that people attend
meetings in their region much more than where they have to travel a
great distance. So even if cost is not a huge factor, SOMETHING is.
Not everyone goes to every meeting.
[cc to ietf@ietf]
On 14 Mar 2012, at 14:58 , Nathaniel Borenstein wrote:
One idea I've toyed with idly for years is halfway in between: keep the
physical meetings, but break them up into multiple locations. We could have
physical meetings in Europe, North America, and Asia, with strong
All,
I agree with the reply from Malcolm below and support his
suggested text insertion.
And repeat that slide 113 is a *summary*.
The *single* refers to the GAL - G-Ach discussion
with the *solution* on slides 19 and 20
and the observations in slides 21 and 22.
Regards, Huub.
===
Hello Adrian,
You typed:
Yuxia wrote:
I also agree with Huub.
As a consensus reached in Beijing meeting, mechanism using the tools defined
for MPLS is a default tool set and another using the tools defined in
G.8013/Y.1731
is an optional one.
That is a an interesting and helpful
Hello Russ,
You write:
RFC 5317 calls for one, and only one, protocol solution.
At least that is how I read JWT Agreement.
How the JWT report should be read is written on slide 9 in the PDF:
This presentation is a collection of *assumptions*, discussion points
and decisions that the
Hello Russ,
You wrote:
although the SONET discussion could be discarded.
It is not only the SDH/SONET discussion that should be removed.
I have very strong doubts about all the issues mentioned in
sections 4 and 5, none of them are factual.
Regards, Huub.
All,
I still do not support this draft.
Section 6 focusses on the interworking between two toolsets
In transport networks we *never* have peer-2-peer OAM interworking.
If it was required it would have explicitly been mentioned in
the MPLS-TP requirements RFC.
Why don't you simply read
All,
I do not support this draft.
As Brian pointed out there is already RFC1958 which addresses the
same issues. So any more time spent on this draft is wasted.
Brian quoted from RFC1958:
This isn't news. I quote from RFC 1958 (June 1996):
3.2 If there are several ways of doing the same
Hej Ole,
You wrote:
Maastricht Bans Cannabis Coffee-Shop Tourists
http://www.bbc.co.uk/news/world-europe-15134669
A ban on some foreign tourists has come into force in the
cannabis-selling coffee shops of the Dutch border city of Maastricht.
Do you mean that the majority of IETF is
All,
Section 1.1 contains the following text:
An analysis of the technical options for OAM solutions was carried
out by a design team (the MEAD team) consisting of experts from both
the ITU-T and the IETF. The team reached an agreement on the
principles of the design and the
All,
Section 1,1 also contains the text:
[RFC5317] includes the analysis that it is technically feasible that
the existing MPLS architecture can be extended to meet the
requirements of a Transport profile, and that the architecture allows
for a single OAM technology for LSPs, PWs,
All,
Why section 5.1 is an author's impression:
Statement:
SONET and SDH were defined as competing standards
Fact:
SONET was developed first by ANSI based on the 24 channel PDH hierarchy
existing in North America and Japan. The basic rate based on DS3.
Some time later ETSI developed SDH based
All,
I propose to completely remove section 5 of this draft.
The reason:
The IETF should *NOT* document any comment on any multiple standards
developed by other SDOs which are outside of the IETF's scope.
Especially standards like like SONET/SDH, CDMA/GSM.
The current text reflects the
On 27 Sep 2011, at 5:45 , Christian Huitema wrote:
if an address space is somehow set aside, we have no mechanism to enforce
that only ISP use it. So we have to assume it will be used by whoever feels
like it.
How is that different from the current situation? Is there a reason why
On 23 Sep 2011, at 7:21 , Benson Schliesser wrote:
The STS may have similar
semantics as RFC1918 space, in that it's non-routable on the Internet etc.
But it is not meant to be used in the same scope.
The draft isn't sufficiently clear on this to my liking.
I think it should be explicitly
On 26 Sep 2011, at 18:41 , Keith Moore wrote:
The problem isn't in the difficulty of finding these changes and fixing them,
for currently maintained code. The problem is in the zillions of systems in
the field that have assumptions about 240/4 wired into them, most of which
either have no
On 30 aug 2011, at 9:22, Henk Uijterwaal wrote:
That is a 4.5 year difference in when the exact date is announced. This
increase the risk that there is a clash with another meeting and people
cannot plan much in advance.
Come on, the idea that people need to know the date of a meeting more
On 27 Aug 2011, at 17:43 , Marshall Eubanks wrote:
I think that the meeting selection process is inherently iterative. Pseudo
code might be something like
- Find a list of all venues we can in the target area for the target week.
The number of these is rarely if ever more than 10.
So the
On 26 Aug 2011, at 16:24 , Tim Bray wrote:
I'm increasingly coming to think that *everything* should be done with
TLS unless you can prove it's harmful. Call me paranoid, but given
the general state of the world, secure-by-default seems like the way
to go. -Tim
That would be nice in a
On 27 Aug 2011, at 19:42 , Joel jaeggli wrote:
In the mean time, I would like TLS exterminated from the IETF website - any
reason will do - since the cost to me far outweighs the benefit. So who
decided to put it in, and on what grounds?
Good question. For me it also causes more trouble
On 29 Aug 2011, at 17:01 , Henk Uijterwaal wrote:
If we want more flexibility in order to find better hotel deals, then we have
to do something like: dates are fixed approximately 1.5 years out, and we do
not mind having meetings back-to-back with other organizations on the clash
list. That
On 29 Aug 2011, at 17:32 , Andrew Allen wrote:
There likely are no such dates as there are telecommunications standards
meetings of one kind or another virtually every week of the year (except
Christmas and (western) new year).
Then go from no clash to minimal clash. If it turns out that
Hello Barry,
You wrote:
Hi, Jorge.
You may want to refer to Section 5.2 of RFC 5378, which addresses this
issue:
Each Contributor agrees that any statement in a Contribution, whether
generated automatically or otherwise, that states or implies that the
Contribution is confidential or
to allow
users to set the MTU advertised in RAs to anything between 1280 and 1500
(inclusive, assuming ethernet), but this should not be done by default.
I still plan to get http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-03
published at some point and having widespread reduced MTUs advertising
On 10 jul 2011, at 17:20, Masataka Ohta wrote:
I was wondering what kind of unique perspective you would have here, and I
wasn't disappointed:
It means that rational operators MUST filter some ICMP
and, not surprisingly, some operators will block all
ICMP or all packet too big ICMPs
That is
-to-IPv4 translation
Author(s) : Iljitsch van Beijnum
Filename: draft-ietf-behave-ftp64-12.txt
Pages : 17
Date: 2011-07-08
I made a cosmetic change to the short title used in the page headers and, after
this week's discussion with Rockson
On 6 jul 2011, at 17:38, Cullen Jennings wrote:
Has anyone found a particularly good solution to reading drafts on an ipad?
I saw xml2rfc now has the option to convert to epub, which would make it easy
to read drafts on the iPad and other mobile devices, but unfortunately when I
tried to
[Please note that this message is going to many mailing lists, please trim as
appropriate when responding.]
I submitted a new version of the draft which addresses most, if not all
comments.
The most notable change, which I would like to ask previous reviewers to look
at again, is the handling
Its 'rough' consensus...
I don't wanna rat-hole here, but imho send the draft onwards for
publication asap please.
G/
-Original Message-
From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf
Of Keith Moore
Sent: 09 June 2011 16:38
To: james woodyatt
Cc: v6...@ietf.org
Thanks everyone for the comments. I'll look into the other technical comments
later this week, but there's one I can respond to right now:
On 4 jun 2011, at 0:16, Fernando Gont wrote:
* Section 1, page 3:
In 5 cases, issuing the EPSV
command to the server led to a significant delay, in
On 12 apr 2011, at 1:39, Doug Barton wrote:
http://bens.me.uk/2011/adventures-in-ipv6
What a bunch of whining.
When I first started doing IPv4 it was much harder than this.
Of course, I think the conclusion is basically wrong, *not* doing
IPv6 is much worse than breaking the finger-pointing
On 5 mrt 2011, at 5:06, Dean Willis wrote:
1) Privacy and Integrity: We believe that intermediaries should be neither
able to understand nor alter the transmitted material without the explicit
consent and awareness of the users.
2) Privacy and Obscurity: We believe that observation of a
Hello Brian,
You wrote:
Not to mention including the canard that the IETF unilaterally disbanded
its group assigned to work with ITU in 2009. Others with more detailed
knowledge can explain exactly why this is, er, a lie.
Here are some facts:
===
I was member of the MEAD
Hi,
In adition to the meter, also the platinum kilogram is in Paris.
Although recently it was found that it has lost some weight
(compared to its brothers and sisters in other locations)...
Wasn't the official definition of the meter also tied to Paris?
On 14 jan 2011, at 23:06, Martin Rex wrote:
Frankly, I'm actually more concerned about code assignments for
severely IPR-impaired algorithms (e.g. Elliptic Curve related)
than about GOST. (Admittedly, the GOST 34.10-2001 signature
algorithm appears to use Elliptic curve math, and it's
Hi Alex,
You wrote:
Thank you for guidance, I've put Shangri-La and Nikko on a google map:
http://ow.ly/2ZpEh
I hope they're correct.
They are correct if you pick the plan view the satelite view
has a horizontal offset of about 500 meters.
Regards, Huub.
--
Hello Ben,
You wrote:
One suggestion for Beijing where the level of English with bus/taxi
drivers etc will be low maybe to publish a page linked from the main
meeting page with something like Can you please take me to the
Shangri-La Hotel in Chinese so attendees can just print it out and
hand
On 8 sep 2010, at 3:13, Marshall Eubanks wrote:
or people who only attend meetings in their home region,
Am I imagining things or are more and more American attendees foregoing
meetings outside North America?
___
Ietf mailing list
Ietf@ietf.org
On 8 sep 2010, at 17:03, Eric Burger wrote:
in today's environment of thousands of Internet-connected publication venues,
why would we possibly ask ourselves to shoot ourselves in the foot by
continuing the practice of Informational RFC publication?
Link rot.
On Sep 3, 2010, at 7:48 PM,
On 2 sep 2010, at 10:04, t.petch wrote:
So it is legal to rewrite the DF bit from 1 to 0. I also know that this
happens in the wild because I used to do this at one time.
Curious; RFC2402 says
Flags -- This field is excluded since an intermediate router might
set the DF
On 2 sep 2010, at 7:40, Christer Holmberg wrote:
In my opinion, the discussion whether we should change the meeting calendar
(not having meetings during summer vacation months etc) was much more
interesting and useful.
To revisit that: if we move up all the meetings by one month, we gain a
On 31 aug 2010, at 22:04, John Kristoff wrote:
I'm trying to locate an RFC that spells out the behavioral
requirements, expectations or guidelines for NAT handling of the IP ID
field, particularly for UDP messages.
If this is not written down anywhere, do NATs generally rewrite the ID
field
On 31 aug 2010, at 1:13, Tobias Gondrom wrote:
My vote is strongly in favor of 1:1:1.
1. First, the location _is_ a significant barrier to entry for newcomers
and other contributors. Optimizing only for the current status quo does
create a strong perpetual cycle of self reinforcing structure
On 28 aug 2010, at 3:04, James M. Polk wrote:
I'm going to pile on what Michael and Mary have already said, by saying the
comparable list of cities (Minneapolis, Orlando, Vancouver, Barcelona,
Prague) isn't even remotely close to including Maastricht. Each of the above
cities are
On 30 aug 2010, at 19:57, Randall Gellens wrote:
8. Would you attend if we held the IETF in Africa?
9. Would you attend if we held the IETF in South or Central America?
Like the question on an earlier survey about Quebec City, I think it requires
more information and more individual
On 30 aug 2010, at 20:25, Randall Gellens wrote:
In both directions between BRU and Maastricht I had to change trains multiple
times, and several of the stations required me to carry my luggage up and
down non-trivial staircases. I wondered at the time how someone in a
wheelchair or who
On 30 aug 2010, at 21:57, Olaf Kolkman wrote:
If you want to be fair to the individual participants you have to optimize in
such a way that attending 6 meetings costs the same for every individual that
regularly attends the IETF. Obviously one can only approximate that by
putting fairly
On 30 aug 2010, at 23:47, Hadriel Kaplan wrote:
Therefore, I propose we meet in Hawaii (and Kauai in particular) from now on.
We can even rotate islands if people get bored.
No, we'd still have to rotate oceans. Iceland is nice and close to both NA and
EU (farther north generally helps),
Why?
inline: Screen shot 2010-07-25 at 14.14.45.png___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On 25 jul 2010, at 14:34, Thomson, Martin wrote:
This is the venue map page: http://tools.ietf.org/rooms ?
The reason is so that it can display where you are on the map.
Right. I had opened this page in a background tab so I didn't make the
connection.
Safari on the Mac doesn't seem to be
On 25 jul 2010, at 15:29, Scott Brim wrote:
Are we resurrecting that marvelous app that shows where you are based on wifi?
Yes. The Google streetview + wifi snooping truck should make its round through
the MECC shortly, please don't stand in its way.
On 21 jul 2010, at 5:27, Mark Andrews wrote:
The only keys that have to be widely distributed are those for the
root zone and that's a similar problem to distributing the list of
root nameservers and their addresses. Millions of recursives server
operators have managed that.
Would be great
FYI:
The police in Schiphol airport and Amsterdam also warns
for pickpockets and not to leave your luggage unattended.
(it is holiday season here, so full time employment for
these characters).
Regards, Huub.
--
Always remember
On 30 jun 2010, at 23:55, IETF Chair wrote:
To gain access to the IETF network, you will need to provide a
credential. Your primary credential will be your registration ID. You
can find your registration ID on the registration web page, in the
response email confirmation you received from
On 16 jul 2010, at 14:23, Russ Housley wrote:
I am passing on this announcement, and I want to add my thanks to
everyone in the Internet community that played a role in deploying DNSSEC.
Too bad it doesn't work for me.
Here IANA publishes info that needs conversion steps that I don't have
On 16 jul 2010, at 18:40, Andrew Sullivan wrote:
Define works?
Less of this:
validating @0x82e9000: . DNSKEY: please check the 'trusted-keys' for '.' in
named.conf.
If anyone can point me to a key I can paste in my BIND config that will allow
me to actually validate domains that would be
On Fri, Jul 16, 2010 at 18:01:20 +0100, Tony Finch wrote:
On Fri, 16 Jul 2010, Iljitsch van Beijnum wrote:
Too bad it doesn't work for me.
BIND's trust anchors are in DNSKEY format, but IANA publishes the root key
in DS format. You can fetch the root DNSKEY using dig, convert
On 16 jul 2010, at 19:56, Ronald van der Pol wrote:
http://fanf.livejournal.com/107310.html
Thanks! That was very useful. I finally got it working.
Yes, me too.
I would also like to check the output for a zone that is verifyable not
correct. Any examples of signed RRs with an incorrect
I should know better than dive back into this discussion...
On 13 jul 2010, at 18:05, Phillip Hallam-Baker wrote:
Con: There is no cost to generating the cert, the cert can be
generated after the device ships. Thus there is no degree of
accountability established in the presentation of a
On 13 jul 2010, at 7:19, Hasnaa Moustafa wrote:
I understood that the train runs daily from Brussels to Maastricht.
There are more than 10 connections daily. I can't seem to find the direct
Brussels - Maastricht train right now, though, the best options I see are with
two changes.
When in
On 13 jul 2010, at 9:22, Ole Jacobsen wrote:
Right, but Dutch trains are not nearly as nice as German
ICE trains.
There are many different kinds of trains in the Netherlands. Indeed only some
of them equal ICEs. However, by traveling through Eindhoven you're almost
certainly subjecting
On 13 jul 2010, at 11:38, Jaap Akkerhuis wrote:
That's the same software. If b-rail.be is competent about
updating its route database with other companies' trains, then
the results will be exactly as good as for bahn.de.
In that case, give ns.nl (dutch railways) a try. They seem to
On 13 jul 2010, at 18:49, Peter Saint-Andre wrote:
fun technologies like AJAX but also opens up the possibility for
new attacks (cross-site scripting, cross-site request forgery,
malvertising, clickjacking, and all the rest).
Isn't this W3C stuff?
On 12 jul 2010, at 17:47, Andrew G. Malis wrote:
Do you know if there is any sort of shuttle van service from Brussels
Airport to Maastricht? That could be an easier option, given the
luggage. As my company will be paying, I don't mind a higher cost as
long as it's not astronomical, as I
Sorry about my previous message, this was a private message that I accidentally
sent to the list. The one I really had in mind:
On 12 jul 2010, at 19:53, Chris Elliott wrote:
I thought we were talking about how to do this for the meeting in Maastricht
and then in Beijing. I agree that
On 6 jul 2010, at 23:45, joel jaeggli wrote:
What I'm missing is what happens with the information described under
Registering to attend a meeting or social event:, there are no
retention periods mentioned (that I noticed).
the trust's records retention policy already deals with
On 7 jul 2010, at 14:02, Alissa Cooper wrote:
Data retention is addressed explicitly in section 5:
What's missing?
What I said: the stuff that gets asked for during registration and payment.
Apparently I didn't notice the link to the IETF trust. However, I don't see the
point of having a
On 7 jul 2010, at 16:32, John Morris wrote:
And, if you indeed think that something is missing, perhaps you could suggest
some language to address your concern, rather than just dismiss the entire
effort.
I think it's completely legitimate to question whether efforts like this are
worth
On 7 jul 2010, at 17:23, John Morris wrote:
Well, as someone who believes that *all* websites and online-operating
organizations should have a clear and accessible privacy policy, I think it
is beyond embarrassing that the IETF does not have one.
The IETF got along without one for two
On 5 jul 2010, at 18:05, Alissa Cooper wrote:
1) Respond on this list if you support the idea of the IETF having a privacy
policy (a simple +1 will do).
I'm torn between good to have this written down and do we really need to go
out and look for more process work.
2) If you have comments
On 2 jul 2010, at 2:30, Phillip Hallam-Baker wrote:
It has taken ten years for WiFi to get to a state where an adequate
credential mechanism is supported, and it is still clunky.
What are you talking about?? Enterprise type WPA where you authenticate against
a back end server has been around
On 1 jul 2010, at 19:07, Andrew Sullivan wrote:
This is useful, but not quite what I was asking. Clearly, the above
means that the logs exist during the meeting, while we are at the host
venue. I think it is safe to say that under some legal regimes, a
government could require the delivery
Some more Amsterdam airport - Maastricht train info:
On 27 jun 2010, at 22:01, Iljitsch van Beijnum wrote:
From there, there's a train to the city of Utrecht every 30 minutes at x.29
and x.59. This is a 33 minute ride. When you arrive in Utrecht, change to the
train to Maastricht, which
This is some information about trains to and from Maastricht and the busses
within the city. Probably more than you ever wanted to know.
If you use an airport other than schiphol (Amsterdam), then see my earlier
message about advance travel info. Schiphol has a big train station right
A paper train ticket is 25 euros; if you want to go to Maastricht Randwyck is
the same but it needs to say Maastricht Randwyck on the ticket.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On 25 mei 2010, at 20:17, todd glassey wrote:
The IETF does NOT own the underlying license rights to TCP/IP in ANY WAY.
For the record TCP/IP actually probably still belongs to the US
Government as it was originally produced under a Department of Defense
contract with BBN about 40 years ago
If you go through all of the trouble to say all of this:
On 18 mei 2010, at 21:46, Ray Pelletier wrote:
The IAOC has adopted a Meeting Room Policy regarding the use
of available IETF meeting room space, the approval process, and charges for
the
rooms and services based upon the category
On 17 mei 2010, at 22:05, victor nunes wrote:
For example, if I wanted to write a book about an article or book on some
proprietary protocols, I'd have to ask permission for the patent holders of
their protocols?
You don't need to ask for permission to write a book if the country you're
On 10 mei 2010, at 5:01, ty...@mit.edu wrote:
I talked to a cab driver in Boston, and he's not very happy with
credit cards, because he was forced to use a new system for credit
cards, and it takes what he considered an unfairly large percentage
when customers pay by credit cards.
And that's
On 8 mei 2010, at 1:50, Glen Zorn wrote:
More than once, I _have_ asked the driver specifically if he accepts credit
cards (the advertised policy notwithstanding) only to have him refuse it
upon arrival...
Curious way to engage in commerce. Where was this?
BTW:
I'm typing this from Schiphol
On 6 apr 2010, at 18:16, Mark Atwood wrote:
Cisco, IBM, MCI, or Linden Lab are not a members of the IETF. No agency of
the US government, or of any other government, is a member of the IETF. No
university, non-profit, PIRG, PAC, or other concerned citizens group, is a
member of the IETF.
On 1 apr 2010, at 2:56, Phillip Hallam-Baker wrote:
In theory it is possible to use a US issued credit card in Europe.
In practice, forget it unless you are willing to face the
embarrassment of 50% of places declining your card.
:-)
What you have to remember is that in many European
On 1 apr 2010, at 01:12, Ole Jacobsen o...@cisco.com wrote:
On the other hand, generic discussions about meeting planning, travel
tips and Ole's Guide to Japanese Gadgets might be more appropriate on
a permanent list, right?
If only the IETF had a list for general discussions...
As for the
On 30 mrt 2010, at 10:15, Marco Davids (Prive) wrote:
http://www.ietf78.nl/.
Ok, one thing: I strongly recommend AGAINST purchasing any _Dutch_ train
tickets before you travel. (This does not apply to international train tickets!)
The Nethelands is currently making a transition from paper
On 30 mrt 2010, at 15:39, Basil Dolmatov wrote:
OV-chipkaart logo is already seen on some ticket machines, so I would be
glad to get an advice where and how these chipkaarts can be bought and
where it can be used except for train tickets purchase.
(Plural of chipkaart is chipkaarten, or use
Note: I unintentionally wrote off some German airports that _may_ be suitable
for travel to Maastricht, such as Cologne/Köln. But be careful with any of the
smaller airports in the region, check ground transportation before you book or
you may be in for nasty surprises.
On 29 mrt 2010, at
Even though many of you are still fighting jet lag, it's never too soon to
start thinking about the next IETF meeting! Below some musings on how to get to
Maastricht from various airports to aid those who want to book their plane and
possibly train tickets.
Lunch:
But before that: Maastricht
1 - 100 of 671 matches
Mail list logo
