Re: [midcom] RE: Last Call: 'Definitions of Managed Objects for Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib)

2006-08-28 Thread Pyda Srisuresh
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

Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)

2006-03-19 Thread Pyda Srisuresh
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

Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)

2006-03-19 Thread Pyda Srisuresh
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

RE: FW: Why?

2005-03-14 Thread Pyda Srisuresh
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

Re: Internet-Draft cutoffs and getting work done

2004-10-18 Thread Pyda Srisuresh
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

RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard

2002-12-22 Thread Pyda Srisuresh
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

RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard

2002-12-21 Thread Pyda Srisuresh
... 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

RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard

2002-12-19 Thread Pyda Srisuresh
... 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

RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard

2002-12-18 Thread Pyda Srisuresh
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

RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard

2002-12-18 Thread Pyda Srisuresh
-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

RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard

2002-12-18 Thread Pyda Srisuresh
... 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

RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard

2002-12-18 Thread Pyda Srisuresh
-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

RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard

2002-12-17 Thread Pyda Srisuresh
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

RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard

2002-12-16 Thread Pyda Srisuresh
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

Re: IETF Sub-IP area: request for input

2002-12-09 Thread 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

Re: filtering of mailing lists and NATs

2001-05-22 Thread Pyda Srisuresh
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

Re: filtering of mailing lists

2001-05-22 Thread Pyda Srisuresh
--- 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

Re: filtering of mailing lists

2001-05-22 Thread Pyda Srisuresh
--- 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

Re: [midcom] WG scope/deliverables

2001-01-31 Thread Pyda Srisuresh
--- 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

Re: draft-ietf-nat-protocol-complications-02.txt

2000-04-24 Thread Pyda Srisuresh
--- 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

Re: draft-ietf-nat-protocol-complications-02.txt

2000-04-22 Thread Pyda Srisuresh
--- 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

Re: breaking the IP model (or not)

2000-04-12 Thread Pyda Srisuresh
--- 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

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Pyda Srisuresh
--- 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

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Pyda Srisuresh
--- 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

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Pyda Srisuresh
--- 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

Re: To address or NAT to address?

1999-12-02 Thread Pyda Srisuresh
--- 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

Re: IP network address assignments/allocations information?

1999-11-30 Thread Pyda Srisuresh
--- 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