Dan,
Thank you for your detailed comments. Sorry for the delayed response. I was
away on vacation and just got back. Please see my responses below inline.
regards,
suresh
--- Romascanu, Dan (Dan) [EMAIL PROTECTED] wrote:
1. Is the 'strict' SNMP terminology intentionally avoided in Section 4.2
I too agree with Mohsen's comments, overall. What Mohsen points out as true
eight years ago continues to be true even now. Not a lot changed, IMHO. I
believe, it had gotten worse. IESG continues to wield enormous influence over
the independent submissions sent to the RFC editor. The RFC editor
Right, that is the foced outcome of the current practice. Without an
independent channel, people find other avenues outside the IETF to get their
work done.
regards,
suresh
--- Steven M. Bellovin [EMAIL PROTECTED] wrote:
On Sun, 19 Mar 2006 09:42:50 -0800 (PST), Pyda Srisuresh
[EMAIL
Hi Tony,
I have not been followign this thread at all. But, I did happen to look at this
e-mail and decided to respond. Please see my comments below. Thanks.
regards,
suresh
--- Tony Hain [EMAIL PROTECTED] wrote:
Jonathan Rosenberg wrote:
...
I agree that ALGs are not the answer, and I
Dont have a lot to add to the already nicely articulated comments below from
John. However, I would like to know why this IETF meeting in DC is scheduled so
soon after the last one - barely 3 months from the last one. Added to this, the
dead-lines for the drafts are more conservative, leaving
Yakov,
Are you saying inter-area OSPF TE is not required?
Without the inter-area OSPF TE, the non-backbone areas of an
OPPF AS boil down to being *stub areas* and the backbone area
becomes the only area. The round-robin ABR based trial-and-error
CSPF computations can take inordinate amounts of
... snip
My recommendation against using this draft as the basis for
building further TE-extensions to inter-area and mixed networks
was in the context of OSPF Autonomous System (AS). I also
mentioned the draft has scalability limitations in extending this
to inter-area and mixed
... snip
Please look at draft-kompella-mpls-multiarea-te-03.txt, as
at least some of the approaches described in that draft
do *not* assume additive properties of TE metrics (and do not
advertise summary info).
Yakov.
Yakov - You are right. The draft does talk about
I understand.
The flip side to this is that once a solution is
implemented and deployed, there is lethargy to look at
other solutions (or) to expand the problem space. Then,
there is the legacy of this implementation that
future solutions have to live with.
Anyways, this is all the more why I
-Original Message-
From: Kireeti Kompella [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 3:37 PM
To: Pyda Srisuresh
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2
to Proposed Standard
On Wed, 18
... snip
As for the comment from John Moy (circa July 2001) about the
availability of an inter-area OSPF draft, I do recall responding
that the inter-area draft was assuming additive properties to
TE metrics to advertise summary info. It is a mistake to assume
that all TE metrics can be
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Kireeti Kompella
Sent: Wednesday, December 18, 2002 5:16 PM
To: Pyda Srisuresh
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2
Rohit,
My comments were made solely in reference to the
draft-katz-yeung draft; not in comparison to any specific draft,
as you might believe.
As for the comment from John Moy (circa July 2001) about the
availability of an inter-area OSPF draft, I do recall responding
that the inter-area draft
resending... My apologies, if you receive two copies of this.
I believe, the orginal e-mail did reach the ietf list. Thanks.
regards,
suresh
-Original Message-
From: Pyda Srisuresh [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 13, 2002 11:13 AM
To: [EMAIL PROTECTED]
Cc: Pyda Srisuresh
I vote for DP1 - Moving the WGs back to one of the
existing permanent areas. Otherwise, the problem of
coordination with related permanent areas is likely
to get worse.
regards,
suresh
--- Alex Zinin [EMAIL PROTECTED] wrote:
FYI below. (Sorry for cross-posting.)
Please post follow-ups to
Here is a suggestion.
Require people to subscribe to a list to post to the list.
This is in addition to requiring subscription to receive posts
mailed to the list. Nanog adopts this approach and has been
fairly successful in avoiding spam, I believe.
Subscription to Post can be made
--- Keith Moore [EMAIL PROTECTED] wrote:
Here is a suggestion.
Require people to subscribe to a list to post to the list.
worked great for the NAT WG list, which successfully used this technique
to discourage input from people harmed by NAT.
NAT WG never had a separate
--- Keith Moore [EMAIL PROTECTED] wrote:
Suresh,
I don't mind having WG lists moderate contributions from non-subscribers,
provided the moderator can act in a timely fashion (say within a day or
so) and the moderator allows any post that is even arguably on-topic for
the list.
Having a
--- Keith Moore [EMAIL PROTECTED] wrote:
Keith, why don't you start an NAT-Haters mailing list, and take all this
disgust with NAT's there? (I'm quite serious about this.)
Noel,
I expressed an opinion that this group should confine itself to addressing
short-term goals rather than
--- Henning Schulzrinne [EMAIL PROTECTED] wrote:
It might be useful to point out more clearly the common characteristics
of protocols that are broken by NATs. These include, in particular,
protocols that use one connection to establish another data flow. Such
protocols include ftp, SIP and
--- Jeffrey Altman [EMAIL PROTECTED] wrote:
I have so many issues with this reply that I am only going to focus on
one.
Agreed. How do you expect the intruders will steal the tickets, without
being recipients of the ticket? Unless, you are assuming that the private
network is not
--- Keith Moore [EMAIL PROTECTED] wrote:
I'm being a bit extreme but the point is that just because something is
architecturally bad doesn't mean you shouldn't do it, since these days it
takes us years to make any architectural enhancements.
perhaps architectural impurity alone
--- Keith Moore [EMAIL PROTECTED] wrote:
... stuff deleted
As we have done with the NAT WG, it is
often useful to accurately document the drawbacks of a
common practice as well as to encourage exploration of
alternatives.
From my point of view there were significant forces within the
--- Keith Moore [EMAIL PROTECTED] wrote:
Keith - I argued to keep the term "transparent routing" in the
NAT terminology RFC (RFC 2663). The arguments I put forth were
solely mine and not influenced by my employer or anyone else.
didn't say that they were.
Clearly, your point of
--- Keith Moore [EMAIL PROTECTED] wrote:
Sorry.. Your conclusion is based on a wrong premise.
The NAT group's draft documents speak for themselves.
My point exactly.
regards,
suresh
__
Do You Yahoo!?
Talk to your friends online with
--- Brian E Carpenter [EMAIL PROTECTED] wrote:
"David R. Conrad" wrote:
Christian,
Increasing our reliance on the DNS is definitely not a good idea.
Hmmm. This would appear to be the exact opposite of what the IETF has done
with IPv6.
Rgds,
-drc
Well now. There is
--- Keith Moore [EMAIL PROTECTED] wrote:
And yes, additional IP addresses were going to cost dramatically more. NAT
was a simple case of economics... but on the other hand, I don't experience
any "lack" because of it. I don't play UDP-based games or employ any of
the
other relatively
27 matches
Mail list logo