你好 Jorge,
You wrote:
And ASCII is more eco-friendly :-)
Simplified Chinese is even more eco-friendly ;-)
Cheers, Huub van Helvoort (AKA 海高明)
--
Always remember that you are unique...just like everyone else
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
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
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.
--
Hi Iljitsch,
You replied:
This is to inform you that, effective January 12, 2009, the
requirements to travel visa-free into the United States will be
changed. Nationals of Visa Waiver Program countries will still be
eligible to travel without a visa, but will have to obtain an approved
trave
Hello Yaacov,
You wrote:
I rescind my first comment,
but stand by my second one.
This was your second, with my comments [hvh] in-line:
> Second, "that the mechanisms in Y.1731 are sufficiently
> simple to allow some "hardwarization".
[hvh] this HW already exists, as was mentioned at the IET
eed be a nightmare.
Best regards, Huub.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub
van Helvoort
Sent: Saturday, October 10, 2009 23:15
To: ietf@ietf.org
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements,>
(R
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
802.1ag or Y.1731, terminology throughout the
> document so 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
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
Hello Nabil,
Considering your response:
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 Etherne
Hello,
I continue my support for the codepoint allocation
I agree with Russ's statement in
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=62185&tid=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
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 signific
not inform us that you changed your mind since
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: Las
[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: (An
Overviewofthe OAM Tool Set for MPLS based Transport Networks)
toInformational RFC
Hallo Nurit,
You replied:
Thanks for your comments to IESG
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.
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. Ter
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?
_
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 tea
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 subjec
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 auth
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,
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 directi
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, an
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,
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 sam
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 comb
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 draft-ts
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 statemen
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.
===
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.
32 matches
Mail list logo
