Re: [midcom] RE: Last Call: 'Definitions of Managed Objects for Middlebox Communication' to Proposed Standard (draft-ietf-midcom-mib)
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
> and associated diagrams, and why? Meaning why do we say 'SNMP get
> message' instead of 'SNMP GetRequest PDU', etc. ?
[suresh] The objective of section 4.2 was essentially to indicate how the
MIDCOM transactions can be mapped to SNMP. I.e., make the description of
MIDCOM transactions to SNMP mapping easy to underdtand. Terms like "SNMP get
message" and "SNMP put message" are simply easier for the reader to relate
while talking about transactions.
> 2. Section 5.3.1
> > The MIDCOM MIB module does not require a middlebox to implement
>further specific MIB modules for supported middlebox functions, such
>as, for example, the NAT MIB module [RFC4008].
>
> This should probably be 'further specific middlebox (NAT devices,
> firewall) MIB modules'
>as, for example, the NAT MIB module [RFC4008].
>
[suresh] OK; with a minor tweak to your suggested text as follows.
s/"(NAT devices, firewall)"/"(NAT, Firewll)/
> 3. Object midcomRuleAdminStatus
>
> > midcomRuleAdminStatus OBJECT-TYPE
>SYNTAX INTEGER {
>reserve(1),
>enable(2),
>notSet(3)
>}
> ...
> When retrieved, the object returns the last set value. If
> no value has been set, it returns one of the two possible
> values."
>DEFVAL { notSet }
>
> I do not understand what are the 'two possible values'. What happens of
> a retrieval happens before the object is set for the first time?
>
[suresh] Oops... Will change the text to read as follows.
When retrieved, the object returns the last set value. If
no value has been set, it returns the default value of notset(3).
> 4. Several DESCRIPTION clauses (e.g. midcomRuleAdminStatus,
> midcomRuleStorageType) include SNMP-specific error messages when
> describing the behavior of the object. This is OK, as the MIDCOM-MIB is
> designed to be used with SNMP as MIDCOM protocol, yet I would include a
> note on this subject because this is not customary within other MIB
> documents which are written with a protocol-independent orientation.
>
[suresh] I will leave to Juergen or Martin to comment on this.
> 5. What happens with the object midcomRuleObjectTime when
> midcomRuleObjectType is permanent(4)? The DESCRIPTION clause of the type
> object suggests that time is read-only. With DEFVAL 0 this means
> automatic destruction of the row at the end of the transaction. Is this
> the desired behavior, or did I mis-understand something?
[suresh] Yes, I believe, that is the desired behaviour.
Note, however, the DESCRIPTION for midcomRuleStorageType says that attempts to
set this object to permanent will always fail with an inconsistentValue error.
And, the default value for this object is volatile(2).
>
> 6. I do not feel comfortable with the DESCRIPTION clause of
> midcomRuleError RECOMMENDing values for this object without defining
> what behavior each message is supposed to cover. This type of object is
> not interoperable, and this would be made clear if it was said that
> these are examples rather than RECOMMENDations.
>
[suresh] I am OK with listing the error strings as examples, rather than as
recommendations. I will leave to Juergen or Martin to further comment on this.
> 7. Another side-effect of the midcomRuleObjectType being permanent(4) is
> that the permanent rules cannot be applied to interfaces, so they can be
> only global. Same about transport protocol and other read-write objects.
>
[suresh] As I said earlier, attempts to set midcomRuleStorageType to permanent
will always fail with an inconsistentValue error.
> 8 . There is no DEFVAL for midcomRuleFlowDirection
>
[suresh] Right, that was intentional.
> 9.
> > Valid values for midcomRuleTransportProtocol
> other than zero are defined at:
> http://www.iana.org/assignments/protocol-numbers
>
> Does this need a new type of registry from IANA? There is nothing in the
> IANA considerations about this.
[suresh] Well, nothing specific to MIDCOM MIB per se. IANA assigns IP protocol
numbers independently, right.
>
> 10. What notification needs to be sent when midcomConfigIfEnabled is set
> to false? Neither the DESCRIPTION of the object nor the one of the
> notifications do provide any clue.
>
[suresh] The DESCRIPTION for midcomConfigIfEnabled does say the following.
Setting
this object to false(2) immediately stops middlebox
support at the indexed IP interface. This implies that
all policy rules that use NAT or firewall resources at
the indexed IP interface are terminated immediately.
In this case, The MIDCOM agent MUST send notifications
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
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 PROTECTED]> wrote: > > > 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 needs to > be > > independent. > > Why? There are plenty of other publication venues. > > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
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 needs to be independent. regards, suresh --- Mohsen BANAN <[EMAIL PROTECTED]> wrote: > > > On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand > <[EMAIL PROTECTED]> said: > > On Sat, 18 Mar 2006 21:10:10 -0800, Dave Crocker <[EMAIL PROTECTED]> > said: > > Harald> What's the point of reposting this message now? > > Dave> Seems like there ought to be a statute of limitations. > > In response to both of you: the point of referring > to eight-year old history is not to disinter the > corpse of the past. > > The point is that this history is directly > relevent to a current discussion thread. > > I believe I made the point of reposting clear in > the following header: > > Mohsen> [ This is a repost from 6 Nov 1998. > Mohsen> In particular the section on: > Mohsen> o Separate The RFC Publication Service from the IETF/IESG/IAB. > Mohsen> is relevant to the current: > Mohsen>STRAW PROPOSAL RFC Editor charter > Mohsen> thread. ] > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: FW: Why?
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 believe the reasons for that > > are treated in: > > > > http://www.ietf.org/internet-drafts/draft-iab-nat-traversal- > > considerations-00.txt > > I have a fundamental problem with an IAB document that implies NAT provides > a firewall. The artifact of lack of state is exploited to prevent inbound [suresh] Why is it a problem with what Jonathan said in the IAB document? It is true that traditinal NATs do inherently provide a limited firewall functionality. Jonathan did not say that NAT function implies full Firewall functionality. Also, what exactly do you mean by the comment about "lack of state" being exploited to prevent inbound connections? Many firewalls are stateful and so are NATs. Who is exploiting "lack of state" in what? > connections, but that has nothing to do with a policy rich firewall, and > even less to do with anything resembling 'security'. > [suresh] Agree with your comment about firewalls being policy rich. The comment about security in the draft relates just to the filtering of inbound connections. Given that, why is it OK to say that a firewall secures an organization by not permitting inbound connections, but not OK to draw the same conclusion about a NAT? > As I said in an earlier post, the entire focus of this document is the wrong > direction for the IAB. It should be focused on simplifying application > operation, so there should be no NAT in the title. The IAB should be looking > at how applications can avoid worrying about the convolution in the network, > not focusing on how to navigate it. > [suresh] This sounds like some kind of an unwritten rule, or something. Why is it wrong for the IAB to address real-life problems involving NATs? A tremendous amount of work has been ongoing in the IETF lately concerning how applications should traverse NATs. A new IPsec standard has emerged to deal with NAT traversal. I think, it makes sense that the IAB recognizes that and makes a statement about NAT traversal for the apps. That is not to say that application designers should not design for the V6 networks. > It is also broken in that it focuses on Client/Server application models, > which are generally less of an issue for applications in a NAT environment. > Peer-to-peer applications have more trouble with mangled headers so the > second thing to do (after changing the title & focus) is to rework this so > that P2P issues are up front. > [suresh] The focus is principaly on the P2P applications in the draft, from what I can tell. > > > > As I mentioned during the plenary, the document above makes a case that > > the right answer in many situations are vpn-ish technologies that > > include v6 tunnels. However, different applications have different > > needs, and there are real differences between the various vpn-ish > > solutions (TURN, STUN, teredo, etc.) that are driving their development > > and adoption. For VoIP, where the nat traversal issue has been > > especially painful, the increase in voice latency, packet loss, and > > substantial cost increase of relaying traffic through the tunnel > > servers, has driven people to solutions like STUN. Thus, I cannot agree > > that there only needs to be a single solution here. > > You appear to be too focused on the weeds to notice the path forward. Yes > many of the IPv6 transition technologies have the same issues as the NAT > traversal technologies in IPv4 (in many cases they do exactly the same thing > but with different encapsulated packets). That said if the applications > community doesn't get the point that they can leave all that crap behind > when native IPv6 is available to them then they will never move. If the > applications community doesn't do their part we will always be stuck with > the garbage in the network. > [suresh] It sounds like you are suggesting that the IAB should advocate the mantra that application desginers shoudl jettison the issue of NAT traversal and simply write apps that work with v6 only. Why do you believe the application designers will heed that? Application desginers cannot afford to ignore the current deployment. After all, they want their apps to be deployed. > > > > That said, I agree that the IAB nat traversal consideration document > > lacks adequate consideration of how evolution plays into this, and I'll > > endeavor to improve the document on that front. > > I will try to send text, but I am buried for the next couple of months. > [suresh] That sounds good. > > > > Another concern I have is that, in an IPv6-only world, even if you > > eliminate NAT, there will still be firewalls, and those firewalls will > > frequently have the property that they block traffic coming f
Re: Internet-Draft cutoffs and getting work done
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 very little time for the draft authors. Thanks. regards, suresh --- John C Klensin <[EMAIL PROTECTED]> wrote: > Hi. > > Summary: Four weeks? When we sometimes run only three months > between meetings? > > Some years ago, the secretariat and IESG agreed on an I-D > posting deadline about a week before IETF began, in the hope of > getting all submitted drafts posted before WGs needed them for > review and discussion. Prior to that rule, the last drafts to > arrive either slipped through the cracks or were posted after we > had started meeting, which did no one any good. > > As the load of incoming drafts increased, still with a > completely manual process, the posting deadline was shifted back > another week, to be two weeks before meetings began, and then a > rule was imposed (for which I fear I'm at least partially > responsible) requiring that initial-version drafts be posted yet > a week earlier -- three weeks out. The theory behind the latter > was the load continued to rise and that initial versions often > took longer to process and confirm than second and subsequent > versions, so it made sense to let the additional time burden > fall on them. > > Such deadlines, considerably in advance of IETF meetings, are an > impediment to objectives we claim for the standards process -- > opportunities for people to get as much work as possible done > outside the face to face meetings, and documents in hand that > are timely enough that people who do not attend meetings in > person can effectively express their comments. > > Over the last few IETF meetings, processing has become more > automated, or the Secretariat has become more efficient in other > ways. The typical time to get an I-D posted other than in the > pre- and post-meeting rush has dropped to one working day and > has sometimes even been less. And, during the rush, the queue > has often cleared early enough that consideration of shortening > the deadlines/ lead time would be in order. > > Instead, a new rule has apparently crept into the posting > deadlines, with no community discussion or announcement other > than in those deadline announcements. The rule, in this > meeting's form, is that > > "As always, all initial submissions (-00) with a > filename beginning with "draft-ietf" must be approved by > the appropriate WG Chair before they can be processed or > announced. WG Chair approval must be received by > Monday, October 11 at 9:00 AM ET." > > First of all, this isn't "as always". The rule requiring > explicit WG Chair approval is fairly recent. But, more > important, we now have a situation in which WG drafts -- > presumably the most important documents for the face to face > meetings-- now require formal naming, authorization, and > approval a full four weeks before the first IETF meeting > sessions. Remembering that we have sometimes had meetings as > close as three months apart, but even with four months being the > nominal separation, this is a _big_ chunk of time. On the three > month schedule, and allowing a couple of weeks post-meetings for > things to stabilize, people to get caught up, and new > discussions to start, it could give a WG only six weeks to have > a discussion that could generate a new document for discussion > and agree on that document before cutoffs impose, at least, > names that make those documents harder to find and track. > > As we continue to discuss problems and issues that get in the > way of our getting effective work done, it seems to me that this > is a new one that should be added to the list. > > Also, in the context of administrative reorganization, I would > find it helpful, and others might too, to understand where this > new requirement came from: > > (1) If from the Secretariat by unilateral action, it is > perhaps a symptom of difficulties with the Secretariat > that require some change in models. > > (2) If from the IESG, it perhaps should be examined as a > procedural change made without an announcement to the > community and opportunity for comment -- precisely the > type of change that the "July14" draft was intended to > prevent in the future by providing a more efficient way > to get such changes made _with_ community involvement > and (at least default) authorization. > > Finally, if four weeks is really necessary, I suggest that we > are in need of firm rules about minimum meeting spacing. > > john > > > ___ > Ietf mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ietf > = __
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
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 time for LSP convergence. As LSPs are setup, TE network reachability changes. Without the inter-area OSPF TE, nodes are blind to TE reachability outside the area. Not offering inter-area OSPF TE, I believe, is a disservice to customers who need predictability. Same goes with the flooding and other limitations imposed on mixed networks. Lack of a requirements document for OSPF TE is clearly the cause of this debate. It may not be too late to work on one. Borrowing Keith's words, it sounds like we have a group of people insisting on adopting the "one solution" without significant change - treating it as inviolate rather than as a proof of concept. regards, suresh > -Original Message- > From: Yakov Rekhter [mailto:[EMAIL PROTECTED]] > Sent: Sunday, December 22, 2002 6:29 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 > to Proposed Standard > > > Suresh, > > > > > 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 networks - also in the context of OSPF AS. > > > > > > > > Without going into the details of the "Multi-area MPLS Traffic > > > > Enginering" draft - The work cited in this draft as going on to > > > > address multi-area TE is in the MPLS signalling context, not in > > > > the OSPF. > > > > > > As I said in my previous e-mail quite a few scenarios described in > > > draft-kompella-mpls-multiarea-te-03.txt are supported with the TE > > > extensions that are subject to this Last Call. That is precisely > > > while quite a few scenarios in the "Multi-area MPLS Traffic > Engineering" > > > draft do not require any additions to what is already defined > > > in the katz-yeung draft. > > > > > > Yakov. > > > > Yakov, > > > > Yes, quite a few scenarios described in > kompella-mpls-multiarea-te draft > > are supported with single-area TE extensions and do not require any > > additions. And, katz-yeung draft proposal will suffice for single-area > > TE extensions. > > Good. So we are in agreement that the katz-yeung draft can support > both single area and multi-area TE. > > > katz-yeung draft does not cover dissemination of inter-area TE info > > (which I was refering to as *inter-area OSPF-TE*). Neither does the > > draft claim to do so. > > That is correct too. > > > Inter-area OSPF-TE is a scenario described in > > kompella-mpls-multiarea-te for faster convergence in LSP computation. > > I am not sure which scenario you are referring to. But anyway, this > is outside the scope of the present discussion... > > > In this context - my recommendation to not use katz-yeung draft as the > > basis to extend to inter-area OSPF-TE was because of its scaling > > limitation. > > And my recommendation is exactly the opposite - start multi-area TE > with what is already in the katz-yeung draft, gain some operational > experience with it, and then improve this, *if necessary*, based on > the experience. But anyway, this is outside the scope of the present > discussion... > > > Neither katz-yeung nor kompella-mpls-multiarea-te drafts address mixed > > networks. katz-yeung draft has limitations with flooding disruption > > and topology isolation in a mixed network - both intra-area and > > inter-area. This was another reason why I recommended to not use > > katz-yeung draft as the basis to extend to inter-area OSPF-TE. > > To avoid any confusion I would suggest to add the following to > the katz-yeung draft: > > It is an explicit non-goal of the solution described in this > document to address all possible (as well as impossible) > requirements. Therefore, the solution described in this document > is clearly not a perfect solution, and as such doesn't quality > for being a LTSFGTC (Long Term Solution For Generations To Come). > Work on the perfect solution (aka LTSFGTC) is in progress, and is > expected to be published in RFC10. > > Yakov.
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
<... 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 networks - also in the context of OSPF AS. > > > > Without going into the details of the "Multi-area MPLS Traffic > > Enginering" draft - The work cited in this draft as going on to > > address multi-area TE is in the MPLS signalling context, not in > > the OSPF. > > As I said in my previous e-mail quite a few scenarios described in > draft-kompella-mpls-multiarea-te-03.txt are supported with the TE > extensions that are subject to this Last Call. That is precisely > while quite a few scenarios in the "Multi-area MPLS Traffic Engineering" > draft do not require any additions to what is already defined > in the katz-yeung draft. > > Yakov. Yakov, Yes, quite a few scenarios described in kompella-mpls-multiarea-te draft are supported with single-area TE extensions and do not require any additions. And, katz-yeung draft proposal will suffice for single-area TE extensions. katz-yeung draft does not cover dissemination of inter-area TE info (which I was refering to as *inter-area OSPF-TE*). Neither does the draft claim to do so. Inter-area OSPF-TE is a scenario described in kompella-mpls-multiarea-te for faster convergence in LSP computation. In this context - my recommendation to not use katz-yeung draft as the basis to extend to inter-area OSPF-TE was because of its scaling limitation. Neither katz-yeung nor kompella-mpls-multiarea-te drafts address mixed networks. katz-yeung draft has limitations with flooding disruption and topology isolation in a mixed network - both intra-area and inter-area. This was another reason why I recommended to not use katz-yeung draft as the basis to extend to inter-area OSPF-TE. regards, suresh
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
<... 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 different > > mechanisms the MPLS signaling protocols could use to setup > > LSPs in an AS spanning multiple areas. However, the draft is > > not about inter-area OSPF TE. > > The draft is about multi-area TE, as it describes how to solve > the problem of supporting TE in a multi-area environment. > OK. > > Clearly, there is interplay between signalling protocols and > > the extent of TE link state data base (TE-LSDB) a node has. > > I believe, scenario-3 is where the inter-area OSPF-TE is in > > place and all nodes in an area have the same information as > > their ABRs do. This scenario presents the signalling protocols > > with fast convergence in settign up an LSP, right. > > Just to point out that quite a few scenarios described in > draft-kompella-mpls-multiarea-te-03.txt are supported with the TE > extensions that are subject to this Last Call. To repeat what > Kireeti said already "There is work going on to address multi-area > TE *that builds on this draft*." > Yakov - My comment on the katz-yeung draft concerning multi-area is that it supports TE in a single OSPF area; and hence to rename the draft as "TE extensions to an OSPFv2 area". 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 networks - also in the context of OSPF AS. Without going into the details of the "Multi-area MPLS Traffic Enginering" draft - The work cited in this draft as going on to address multi-area TE is in the MPLS signalling context, not in the OSPF. > Yakov. regards, suresh
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
> -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 > to Proposed Standard > > > On Wed, 18 Dec 2002, Pyda Srisuresh wrote: > > > > Let me be more precise: draft-katz-yeung says how TE in a single OSPF > > > area can be accomplished. It doesn't aim to address the multi-area > > > case; *nor does it say that it cannot do so*; *nor should it do so*. > > > There is work going on to address multi-area TE *that builds on this > > > draft*. In spite of your "recommendations", this multi-area work > > > building on draft-katz-yeung has a lot of traction. I therefore have > > > no intentions of putting in incorrect or incomplete limitations. > > > > > > ... > > > > Kireeti - You apparantly have an attitude and it shows. Outside > > of your attitude, you have not said anything in your defence. > > You clearly have an agenda. Those who have a background in this > matter know this. Those who don't don't know how lucky they are. > There is no secret or hidden agenda here. Stop making insinuations. It is no secret that I have a competing draft, titled, "OSPF-TE: An experimental extension to OSPF for Traffic Engineering" (filed as draft-srisuesh-ospf-te-04.txt). I sent messages in the past to the OSPF WG, comparing my draft to the katz-yeung draft. This is what Rohit Dube was alluding to in his last e-mail. Make no mistake. The comments I sent to the IETF were solely in response to the IETF last call on the katz-yeung draft; not in comparison with any specific draft. I mentioned this to Rohit in my last e-mail to him. It is part of the IETF process to let the wider community know of the concerns with the draft. I am doing my share. I backed all my comments with explanations. > Let me repeat, using short words with few syllables: > > 1) draft-katz-yeung says how to do TE in a single OSPF area. > 2) draft-katz-yeung does not address the multi-area case. > 3) Given (2), it does not make sense to put in lim it ations that >say it won't work in the multi-area case when at worst we don't >know, and at best it may in fact work like a charm. > No dispute here. My comment in this context was to fix the title. My remaining comments are to do with fixing confusing terminology and adding limitations of the model vis-a-vis mixed networks. > > All my comments including those on limitations remain unanswered. > > You confuse "answered, but not to your satisfaction" with "unanswered". > > ... > Your answers were either incomplete or riddled with attitude so as to sidestep the original comment. <... snip> regards, suresh
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
<... 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 additive. Below is a pointer to > > the response I sent. > > > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=ospf&; > T=0&F=&S=& > > P=5937 > > 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 different mechanisms the MPLS signaling protocols could use to setup LSPs in an AS spanning multiple areas. However, the draft is not about inter-area OSPF TE. Clearly, there is interplay between signalling protocols and the extent of TE link state data base (TE-LSDB) a node has. I believe, scenario-3 is where the inter-area OSPF-TE is in place and all nodes in an area have the same information as their ABRs do. This scenario presents the signalling protocols with fast convergence in settign up an LSP, right. regards, suresh
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
> -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 Dec 2002, Pyda Srisuresh wrote: > > ... > > > Hence, a statement of applicability and limitations is > > warranted in the draft. > > Let me be more precise: draft-katz-yeung says how TE in a single OSPF > area can be accomplished. It doesn't aim to address the multi-area > case; *nor does it say that it cannot do so*; *nor should it do so*. > There is work going on to address multi-area TE *that builds on this > draft*. In spite of your "recommendations", this multi-area work > building on draft-katz-yeung has a lot of traction. I therefore have > no intentions of putting in incorrect or incomplete limitations. > > ... Kireeti - You apparantly have an attitude and it shows. Outside of your attitude, you have not said anything in your defence. All my comments including those on limitations remain unanswered. > > > Kireeti - I am aware of RFC 2702 and have reviewed it. > > The RFC is about requirements and applications of TE over MPLS. > > The RFC is *not* about requirements for the IGP collecting > > TE metrics within an Autonomous System(AS). I was refering > > to the latter. > > draft-katz-yeung is *not* about collecting TE metrics. It's about > providing a topological database that can be used for routing traffic > trunks; the parameters that are carried in this database are those > whose semantics and applicability are described in RFC 2702. > > ... > > > The whole crux of my comments has been on scaling and applicability > > limitations. > > > > > >Large OSPF networks with multiple areas will not > > > >run this protocol. > > > > > > Crystal ball? I suggest you get a new one. > > > > > > > READ - This protocol is restricted in scope to a single area. > > I beg to differ -- see above. > > In response to your comments, I will add the following statement > at the end of the second para in the Introduction: > > "This document purposely does not say how the mechanisms described > here can be used for traffic engineering across multiple OSPF areas; > that task is left to future documents." > This is *not* what I stated in my comments and is *not* a characterization of my commnents. I gave backing for all the comments I made. I am sorry to say you did little on your part, other than come back with an attitude. > Kireeti. regards, suresh
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
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 believe, the protocol document should at a minimum cover the boundaries of its applicability. regards, suresh > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike > O'Dell > Sent: Wednesday, December 18, 2002 1:47 PM > To: [EMAIL PROTECTED] > Cc: Mike O'Dell; [EMAIL PROTECTED] > Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 > to Proposed Standard > > > actually, in the IETF, having running code for *one* solution is a good > way > to demonstrate how much of the problem is understood, and if some of > us had our way, it would be impossible to charter a Working Group > *without* the understanding of the problem space being *at least* that > good. > > cheers, > -mo > > "Always do right. It will gratify some people and astonish the rest." > -Mark Twain >
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
<... snip> >> Hi, > > On Mon, 16 Dec 2002, Pyda Srisuresh wrote: > > > The draft is a solution to providing TE within an OSPF area. > > Yes. > > > The draft has serious scalability limitations in > > extending this to inter-area and mixed networks (with TE and > > non-TE nodes). Please see my comments below. > > Actually, inter-area TE is a hard problem -- however, the issue is not > how you format the bits or what type of LSA you use, but what > information should be carried, how it should be summarized (if at all > that is a feasible approach), minimizing crankback, etc. > You forgot to mention flooding. > > I would not > > recommend using this draft as the basis for building further > > TE-extensions to inter-area and mixed networks. > > Your recommendation is noted. Of course, that is not the issue at > hand -- the issue at hand is a proposal for *intra-area* TE. > You are right. The draft at hand is about intra-area TE. There are many reasons why I recommend the draft be not extended to inter-area and mixed networks. There is often a tendency to assume extensibility or using the existing draft/RFC as the basis for inter-area and mixed networks unless stated otherwise. It is also concerning because the OSPF WG currently has no drafts in its charter to cover inter-area and mixed networks. Lastly, this intra-area draft is bound to impose backward compatibility requirements on any follow-on drafts covering inter-area and mixed networks. Hence, a statement of applicability and limitations is warranted in the draft. > > The draft apparently evolved over time with no requirements > > document to guide it. > > Perhaps you should read RFC 2702 before making comments. > Kireeti - I am aware of RFC 2702 and have reviewed it. The RFC is about requirements and applications of TE over MPLS. The RFC is *not* about requirements for the IGP collecting TE metrics within an Autonomous System(AS). I was refering to the latter. > > The vendors and implementors behind the > > draft may have been guided by different set of requirements > > and motivations, such as having some working code. > > Your point being that working code is a Bad Thing? > I am saying that the problem should be well defined, before you decide on a solution. Having "some" working code that solves a problem is not the same as having working code that implements a solution to a well-defined problem. > > Below are my specific comments on the draft. > > > > 1. The draft basically describes link TLVs for area-wide > >flooding. OSPF is an AS-wide IGP, not just area-wide. > > > >So, I would suggest renaming the draft as "TE extensions > >to an OSPFv2 area", instead of the current title, > >"TE extensions to OSPFV2". > > If you're going to comment on the title, please at least get it right: > it's "Traffic Engineering Extensions to OSPF Version 2". > > Your suggested title would be unnecessarily long; anyone who can read > the very short (20 word) abstract will learn that this is for intra-area > TE post haste. > Truth in labeling is important; And, I suggested a label that is truthful and will fit in a line. The whole crux of my comments has been on scaling and applicability limitations. > >Large OSPF networks with multiple areas will not > >run this protocol. > > Crystal ball? I suggest you get a new one. > READ - This protocol is restricted in scope to a single area. I will leave the crystal ball business to the market. > > 2. It is confusing to refer an opaque LSA with with a > >specific sub-type as "TE LSA". It makes it sound like a > >stand-alone OSPF LSA with a distinct LSA type - which > >is is not. OSPF LSAs define the flooding scope. TE LSA > >does not. > > > >One suggestion would be to refer Opaque LSAs with specific > >sub-type 1 as "TE-type Opaque LSA". > > This is beyond nitpicking. Note that the Opaque LSA for Graceful > Restart is called the Grace LSA; also that many many other documents > besides this one call the "TE-type Opaque LSA" simply a TE LSA. > What is the RFC that uses the term "Grace LSA" ? This is not nitpicking. It is just a matter of using the terminology right, so it doesnot cause semantics confusion. I pointed out what the confusion is. Hope you understand. > > 3. The limitations section (section 1.2) should mention the > >following limiations with a mixed network containing TE > >and non-TE nodes. > > 1. When a network area is constituted of TE and > > native-nodes (supporting IP-only
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
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 was assuming additive properties to TE metrics to advertise summary info. It is a mistake to assume that all TE metrics can be additive. Below is a pointer to the response I sent. http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=ospf&T=0&F=&S=&; P=5937 This goes right back to the comment I made below about using the draft-katz-yeung draft as the basis for inter-area TE. regards, suresh -Original Message- From: Rohit Dube [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 11:46 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard Suresh, You have brought up this issue on the ospf mailing list a couple of times and as such the topic has been addressed on the list. Here is pointer to an email from John Moy (circa July 2001) http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0107&L=OSPF&D=0&I=-3&P =15162 and another more recent one from me in response to your email on your alternate-te proposal http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0212&L=OSPF&D=0&I=-3&P =6031 Best, --rohit. (OSPF WG co-chair) ::The draft is a solution to providing TE within an OSPF area. ::The draft has serious scalability limitations in ::extending this to inter-area and mixed networks (with TE and ::non-TE nodes). Please see my comments below. I would not ::recommend using this draft as the basis for building further ::TE-extensions to inter-area and mixed networks. :: ::The draft apparently evolved over time with no requirements ::document to guide it. The vendors and implementors behind the ::draft may have been guided by different set of requirements ::and motivations, such as having some working code. Unfortunately, ::this ad-hoc approach has a cost. Any new requirements are having ::to be met in a reactive mode and having to be provided as fixes ::on top of this "working" code. This is not right and doesnt bode ::well for the future of the protocol. [snip]
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
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; [EMAIL PROTECTED] Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard The draft is a solution to providing TE within an OSPF area. The draft has serious scalability limitations in extending this to inter-area and mixed networks (with TE and non-TE nodes). Please see my comments below. I would not recommend using this draft as the basis for building further TE-extensions to inter-area and mixed networks. The draft apparently evolved over time with no requirements document to guide it. The vendors and implementors behind the draft may have been guided by different set of requirements and motivations, such as having some working code. Unfortunately, this ad-hoc approach has a cost. Any new requirements are having to be met in a reactive mode and having to be provided as fixes on top of this "working" code. This is not right and doesnt bode well for the future of the protocol. Below are my specific comments on the draft. 1. The draft basically describes link TLVs for area-wide flooding. OSPF is an AS-wide IGP, not just area-wide. So, I would suggest renaming the draft as "TE extensions to an OSPFv2 area", instead of the current title, "TE extensions to OSPFV2". Large OSPF networks with multiple areas will not run this protocol. 2. It is confusing to refer an opaque LSA with with a specific sub-type as "TE LSA". It makes it sound like a stand-alone OSPF LSA with a distinct LSA type - which is is not. OSPF LSAs define the flooding scope. TE LSA does not. One suggestion would be to refer Opaque LSAs with specific sub-type 1 as "TE-type Opaque LSA". 3. The limitations section (section 1.2) should mention the following limiations with a mixed network containing TE and non-TE nodes. 1. When a network area is constituted of TE and native-nodes (supporting IP-only links), the opaque LSAs will flood all nodes in the area, thereby disrupting native OSPF nodes. As As a general rule, a TE network is likely to generate significantly more control traffic than a native OSPF network. The excess traffic is almost directly proportional to the rate at which TE circuits are set up and torn down within the TE network. The more frequent and wider the flooding frequency, the larger the number of retransmissions and Acks. It is undesirable to flood non-TE nodes with TE TLVs. 2. A link cannot be reserved for TE-only use. All links must be subjectable to best-effort IP traffic first, before any of the links are permitted to carry TE traffic. In a mixed network, an OSPF router supporting TE-links and native IP-links could potentially select a TE link to be its least cost link and inundate the link with best-effort IP traffic, thereby rendering the link unusable for TE purposes. regards, suresh -Original Message- From: Mailing List [mailto:[EMAIL PROTECTED]]On Behalf Of The IESG Sent: Monday, November 25, 2002 3:47 PM To: [EMAIL PROTECTED] Subject: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard The IESG has received a request from the Open Shortest Path First IGP Working Group to consider Traffic Engineering Extensions to OSPF Version 2 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by December 26, 2002 Files can be obtained via http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt
Re: IETF Sub-IP area: request for input
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 [EMAIL PROTECTED] > -- > Alex > > This is a forwarded message > From: The IESG <[EMAIL PROTECTED]> > To: > Cc: > Date: Wednesday, December 04, 2002, 8:08:49 AM > Subject: IETF Sub-IP area: request for input > > ===8<==Original message text=== > > > IETF SUB-IP area > > The IESG announced in November of 2000 that a new SUB-IP temporary > pseudo-area would be formed as a part of an effort to develop a > "systematic approach to dealing with what we used to describe as > "sub-IP" technologies." At the time the IESG said: > > "Over the years the boundary between 'wires' and IP protocols has > become harder to define and the interaction has become more intertwined. > For example, what appear as 'wires' or 'circuits' in a virtual network > may in fact be routed datagrams in an underlying IP network. The > topology of dynamic underlying networks such as ATM and soon switched > optical networks can interact with IP-level traffic engineering and > routing. Additionally, with IETF technologies such as MPLS we are > defining a whole new class of 'wires'." > (http://www.ietf.org/IESG/STATEMENTS/new-area.txt) > > After the December 2000 IETF meeting and taking into account the > discussion at that meeting the IESG formed a "temporary" SUB-IP Area. > IN the announcement of this action the IESG said: > > "It is temporary because the IESG believes that this concentrated > sub-IP effort will likely be of short duration, on the order of a year > or two. We feel that much of the work will be done by then, and the > working groups closed. Any working groups that have not finished when > the IESG determines that the area should be closed will be moved into > existing the IETF areas where they seem to have the best fit." and "The > IESG expects to review the development process and charters, however; > if we conclude that this expectation is incorrect, we will need to make > this area more formal. At that point, the nominating committee will be > asked to supply dedicated area directors." > (http://www.ietf.org/IESG/STATEMENTS/sub_area.txt) > > Although the SUB-IP working groups have made considerable progress > (with 7 RFCs published, another 12 IDs approved for publication, 9 IDs > under IESG consideration and an additional 11 IDs having been passed to > the ADs for their evaluation) their work is not yet done (with 53 > working group IDs currently in progress). It does appear that some of > the working groups could finish the work in their charters over the next > 6 months but it could be a lot longer for others. > > Because the end is in sight for some of the working groups and since the > IESG had generally assumed that the area would be a temporary one and > the second anniversary of the creation of the SUB-IP area is next spring, > analysis was started in the IESG to figure out which areas would be the > best ones for the SUB-IP working groups to move to so that they could > continue their work. > > As part of that analysis a SUB-IP area session was held during the IETF > meeting in Atlanta where this topic was discussed. > > There was a spirited discussion during the session on the best path > forward. The opinions ranged from following the distribution of > working groups, to doing so with some specific changes to keeping the > working groups in a separate SUB-IP area. A sense of the room was > taken at the end of the discussion and that sense was very strongly > that the SUB-IP Area should become a "long-term" (the description that > was used during the consensus call) one and that the nomcom be asked > to nominate a person (or persons) to become director(s) of the SUB-IP > area. > > To help provide more information as input for the IESG discussion we > would like to continue the discussion started in Atlanta on the mailing > list. It is our intention to keep the discussion on the future of the > SUB-IP area open, but short-lived, because it would be a very good idea > to let the nomcom know ASAP what the future holds as they need to know > what expertise is needed in the ADs for the existing areas and if they > need to search for additional people. > > The IESG aim is to be able to let the nomcom know what the future of > the SUB-IP work is by the end of the day of Thursday Dec 12th. That > date was chosen because it is the date of the next IESG teleconference > yet it provides some time for a public discussion. > > The options seem to be: > 1/ move WGs (back) to permanent areas: migrate the SUB-IP > working groups to other IETF areas sometime soon, likely before next > summer and close the SUB-IP area. Also, reconstitute
Re: filtering of mailing lists
--- 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 separate subscribe-to-post requirement alleviates the burden on the list administartor, at the cost of minor one-time additional inconvenience to the poster. This, in no way, violates the principle of open participation and being open to good ideas from all sources. If a responsible poster still chooses to send a message without subscribing-to-post, then it is not unreasonable if the message posting is delayed by more than a day or is dropped at the discrition of the list moderator(s). On the other hand, if spam is sent automagically to a bunch of lists, the spam will automagically get dropped, unless the spam sender subscribes to each of the lists and violates the posting law. > for reasons already stated, I doubt that a single moderator could be > found for the main ietf list. but I would like to see an experiment > with the 'multiple per-message moderators chosen at random from the > subcriber list' proposals. I am OK with the idea of multiple moderators. Many lists already have multiple moderators. The IESG members, for example, could be the moderators for the IETF list. Unless the moderators group is pre-selected, attempting to select a moderator at random from the subscriber list for each new mailing thread can be at best difficult and at worst a box of pandora. The random selection process in itself can become very hard to manage and will become a giant meta problem in itself. <.. stuff deleted> Thanks. Have a nie day. cheers, suresh __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: filtering of mailing lists
--- 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 subscribe-to-post requirement, FYI. The previous list as well as the current list (hosted by the IETF) required a single subscription to receive as well as to post. With the current list, messages sent by folks not subscribed to the list would be directed to list administrator to permit posting to the list. List administrator would have to manually approve the posting. Now, do you object to a separate subscribe-to-post requirement? Would this discourage or inconvenience you (the occassional non-spam contributor to a non-subscribed-to-receive-list) or the spammer more? If the answer is debatable (or) the frequent spammer is likely to be discouraged at least 50% of the time, the approach is worth a try. > > Keith cheers, suresh = __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: filtering of mailing lists and NATs
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 contingent on the subscriber not agreeing to post material that is out of scope for the list and willing to abide by the list administrator's decision to moderate inappropriate postings. Free-for-all type of lists are inherently prone to spam. Thanks. cheers, suresh --- Keith Moore <[EMAIL PROTECTED]> wrote: > > > however, I have seen a couple of occasions where I believe that > > > a 'moderator' acted inappropriately in filtering messages that > > > came from non-subscribers but were arguably on-topic for the lists. > > > > So the non-subscriber subscribed, and their posts went through okay, > > right? > > no. the WG was badly in need of a clue from folks outside of the WG - > because the WG was failing to understand how its work would interact > with and/or affect other applications or protocols outside of its purview. > > the would-be contributor did not want to subscribe to the list because > he/she had no desire to participate in the day-to-day conversations of > the working group. after all, the contributor normally worked at > layer X while the WG was working at layer Y. > > still, the WG needed the contribution. it would have benefited from > knowing that what it was doing was inherently flawed, and that its > poorly-informed design decisions would do harm and/or cause its work > to be less useful than anticipated. > > but the capriciousness of the mailing list maintainer prevented this > from happening, and many months of hard work were wasted. > > > (If not, and the moderator was in fact filtering all posts > > to the mailing list in question, then this example is a red-herring.) > > seems like you've left a big hole in your case analysis. > > > > Gas tanks explode - we ban cars? > > if the gas tanks explode under normal or even occasional use, we do in > fact recall the car. > > you seem to believe that non-subscribers are inherently illegimiate, > and that any barriers we erect to make it more difficult for them to > post are therefore justified. looks like circular reasoning to me. > > Keith > = __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: [midcom] WG scope/deliverables
--- 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 trying to make NATs a part of the Internet > architecture. > With all due respect, Keith, you are saying that addressing NAT concerns should not be a short-term goal. You are OK with the WG addressing firewall concerns however. But, insisting on this and repeating the mantra many times over, even after the WG is formed with a specific mission and chater, is really disruptive to the work being done in the WG. The charter requires the work group to address both NAT and firewall concerns. It is very confusing and intimidating to the folks who are genuinely trying to contribute. You jump on the bandwagon the moment someone says anything about NAT. Soon it turns into a flaming fest. > I said this because I've looked at the problem quite extensively. > The more I have done so, the more have concluded that there's no way > to restore the valuable functionality that NATs have removed from the > Internet without providing another global address space, and that it's > much more efficient and less painful to embellish the NATs to become > IPv6 routers than it is to embellish both the NATs and applications to > support a segmented address space. Well, I (and perhaps many others) respectfully disagree. This is not a short-term solution yet, not until folks have V6 networks deployed. > > Thus, while I accept that the market needs a short-term solution to deal > with NATs, I also am firmly of the opinion that it's a short-term solution. So, if you do agree working that dealing with NATs is a short term solution, why are you so repeatedly trying to torpedo the effort going in to solve the short term problems ? > IPv6 will be attractive for the same reasons that NAT was attractive - > it will be the path of least pain to solving a pressing set of problems. > Agreed, perhaps with the exception of address renumbering. > Being over-ambitious about goals has prevented more than one working > group from accomplishing anything useful, and exhausted lots of > talented people in the process. I hardly think that advocating a little > restraint in this group's ambition is sufficient justification for > personal attacks. > This has been more than just a little advocation of restraint, I might add. > Keith > > ___ > midcom mailing list > [EMAIL PROTECTED] > http://www.ietf.org/mailman/listinfo/midcom Thanks. regards, suresh __ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
Re: draft-ietf-nat-protocol-complications-02.txt
--- 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 RTSP (the latter is not mentioned yet in > the draft, but NATs also interfere with its operation). Note that unless > we forego such control protocol designs altogether, NATs in principle > break these unless every host has an external DNS mapping. We had originally considered having a section in the draft listing common characteristics of all the applications that fail. Then we decided against it, as such a section already exists in RFC 2663 and "Traditional-NAT" draft. Instead, we chose to focus on gathering the various protocols/applications that fail, why they fail and if there are any work-arounds. Input on the IETF list, past few days, has been great. The draft should look much better when the input is all folded in. For example, the problem you point out with applications with inter-dependent control and data sessions can be found listed as NAT limitation in section 8.2 of RFC 2663. >(Thus, in > reference to a recent message to just design NAT-friendly protocols, > this means in practice that such "out-of-band" designs could not be > supported by this NATy version of the Internet. In effect, this leads to > the abomination of carrying real-time data in HTTP connections.) > Agreed. The intent of NAT-friendly guidelines was merely to point the gotchas that can be fixed - not to dissuade development of protocols that cannot be NAT-friendly. > Other protocol designs are those that are symmetric rather than > client-server based. This affects all Internet telephony or event-based > protocols (IM and generalizations) unless they maintain an outbound > connection with a server acting as their representative to the globally > routed Internet. The latter obviously does not address the media stream > addressing problems. > I assume, you mean Peer-to-peer protocols/applications require bi-directional flows at a minimum. Clearly, it is a problem doing this across traditional NAT (i.e., Basic-NAT or NAPT) because Traditional-NAT fundamentally is unidirectional and supports out-bound flows only. Bidirectional-NAT might work with these apps (with all the caveats that go with address translation). > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > regards, suresh __ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com
Re: draft-ietf-nat-protocol-complications-02.txt
--- "J. Noel Chiappa" <[EMAIL PROTECTED]> wrote: > > From: Keith Moore <[EMAIL PROTECTED]> > > > there are far too many problems to NAT, affecting far too many > > applications ... and the list is constantly growing larger. > > Perhaps if there was a document that explained how to design an application > so that it worked through a NAT box, the list might not be growing so > quickly? > There actually is a draft titled "NAT Friendly Application Design Guidelines" < draft-ietf-nat-app-guide-02.txt> attempting to do just that. I do believe, this can be very valuable to future application developers that need to deploy their apps in networks with NAT devices. Thanks for bringing this up. If someone has valuable input on this, please send the same to the draft author. Thanks. <... Text deleted> regards, suresh __ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com
Re: draft-ietf-nat-protocol-complications-02.txt
--- 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 trusted and that there are intruders within the private > > network. > > There is no such thing as a trusted network. One of the first things > you learn about security (having nothing to do with computer security) > is that most attacks occur from inside the organization. There is no > such thing as a trusted network. > I hear what you say. Thanks. > I have pointed you in directions you need to follow. Stating that the > a problem in one context is described in the described in another > context is not useful in this document. It is exactly because of this > approach that the document comes across sounding as if the problems > described are trivial and inconsequential. > > Dont get me wrong. I was not suggesting that it suffices to point out one end of the problem (ex: X-Windows Server redirection). I was merely stating that the document covered one end, but failed to cover the other end of the problem (i.e., Setting the DISPLAY variable from a Telnet session, using an IP address). > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 > The Kermit Project * Columbia University > 612 West 115th St #716 * New York, NY * 10025 > http://www.kermit-project.org/k95.html * [EMAIL PROTECTED] > > cheers, suresh = __ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com
Re: draft-ietf-nat-protocol-complications-02.txt
--- Jeffrey Altman <[EMAIL PROTECTED]> wrote: > This draft is very incomplete and in my opinion not ready for prime > time. The working group has in the past requested lists of protocols > and applications which do not work with NATs. I have replied > discussing those items for which I am most familiar: Hmm.. I do not recall seeing your e-mail on this matter before. I dont know how we could have lost it. Anyways, sorry about that. <... stuff deleted> > > > Telnet: > > Transmits IP addresses from the client to the server for the purposes > of setting the DISPLAY variable. When set the DISPLAY variable is > used for subsequent connections from X clients on the host to an > X server on the workstation. > Agreed, if you use IP address of the X-server, instead of DNS name (in the case of Basic-NAT en-route). In the case of NAPT enroute, it is a non-issue, as you would have used just the IP address of the NAPT device, right? We covered this in section 3.1, but not in the context of telnet (X-Windows client). Good point. > When AUTH is used with Kerberos 4 and Kerberos 5 there are issues > related to the IP addresses which are embedded into the Kerberos > tickets which specify the valid machines from which the tickets are > valid. > Are you saying that IP address of the senders is always embedded in the kerberos-4 tickets? Section 6 attempts to state that any application that has private IP address in the payload and its payload secured (and NAT is not party to the security key) cannot traverse NAT device. We can certainly include this application there. Section 8.1 of RFC 2663 also talks about NAT limitations with regards to applications with IP address content(especially, encrypted/authenticated) > When START_TLS is used there may be client certificate verification > problems caused by the NAT depending on the information provided in > the certificate. > Agreed. Same comment as before. > FTP: > > As stated FTP, uses multiple sessions. But what it fails to state > is that if any form of PROT is used to secure the command channel > then it is impossible to implement an ALG to perform IP Address swaps. > Agreed. Will add text to clarify this. > When AUTH is used with Kerberos 4, Kerberos 5, and TLS the same > problems that occur with Telnet occur with FTP. > I guess, you are talking about sending IP address data encrypted from a telnet station. Please elaborate, if I am missing something. > RSH/RLOGIN: > > RSH uses multiple sessions to support separate streams for stdout and > stderr. The stderr socket is a connection from the server to the > client. And unlike FTP, there is no equivalent to PASV mode. > Are you saying that there is a problem when a private host does rsh into an external server? If so, can stderr be directed to the client-host by name, as opposed to IP-address? I donot know much about the inner-working of "rsh" to state whether it can work with a NAPT device between client and server. > RLOGIN does not use multiple sessions. What is the problem here? > > But the Kerberos protoected versions of RSH and RLOGIN will not work > in a NAT environment due to the ticket problems and the use of > multiple sessions. > What is the issue with multiple sessions? Are you refering to one of the sessions being redirected to the originator by address? > Kerberos 4: > > Kerberos 4 tickets are encrypted. Therefore, an ALG cannot be > written. The K4 ticket contains a single IP address describing the > interface used by the client to retrieve the ticket from the TGT from > the perspective of the KDC. If the KDC and all services are on the > far side of the NAT, the end user will not notice any problems. But > the ticket will be valid from any IP address inside the NAT (on the > private network.) How so? Are you assuming that AUTH is not used? > Without a NAT, an attacker needs to be able to > spoof the source IP addresses of a connection that is being made in > order to use a stolen ticket on a different host.With a NAT, all > the attacker needs to do from the near side of the NAT is to simply > gain possession of a ticket. > An attacker can be resourceful in many ways. An attacker does not need a NAT to spoof an IP address. Private users of a NAT domain are assumed to be within a trusting domain. > Kerberos 5: > > Kerberos 5 tickets are encrypted. Therefore, an ALG cannot be > written. The K5 ticket contains a list of IP addresses from which > the ticket is to be considered valid. The list is generated by the > client machine, not the KDC. If the services being accessed with > Kerberos authentication are on the public side of the NAT, then > the Kerberos authentication will fail because the IP address used > by the NAT is not in the list of acceptable addresses. > OK. > There are two workarounds in Kerberos 5 both of which reduce the > security of the tickets. The first is to have the clients specify > the
Re: draft-ietf-nat-protocol-complications-02.txt
--- Vernon Schryver <[EMAIL PROTECTED]> wrote: > > From: Matt Holdrege <[EMAIL PROTECTED]> > > > ... > > Just so there is no more confusion, in no way is the IETF endorsing the use > > > or development of NAT. You've completely missed the point of the draft. > > It's purpose is to clearly point out the problems that NAT causes to a > > given set of protocols. > > > > Also please do not steer this thread towards a NAT bashing-fest. We need to > > > complete this document and we need constructive input to this draft. Thanks > > > again for your original input. > > > If the document is not intended to be read as advocating NAT, it also > needs substantial non-technical changes. It currently comes across as > a list of fairly minor, generally easily fixed problems or problems that > don't matter. I don't mean to say that is the intended point of the > document, but is how I read it. Since I'm among those who feel that the > situation with NAT is not quite as bad things would have been if we had > waited for IPv6, you might expect my prejudices to make me read it the > other way. > If you an issue with specific portions of the draft, please let us know. Minor edits could be sent to the authors privately. Thanks. > Instead of appearing to be a complete list of problem and their complete > and easy solutions, the document needs to have more words in each section > saying that the sublist of problems is probably incomplete. The > shortcomings of solutions to the problems should be belabored instead of > glossed over. Seeing that the problems are significant must not require > any technical sophistication in the reader. Agreed. The document was not intended to be an exhaustive list of protocols/applications that fail with NAT. The abstract actually captures that sentiment. Anyways, if you have specific input on things being glossed over without sufficient coverage, do let us know, with any proposed textual editions. We will certainly follow through on that. > For example, most people who > should read this document will see nothing but some opaque acronyms > whose problems surely don't matter in Section 5. Why should anyone care > that IPCEC doesn't work with NAT? > Well, readers should know that IPsec that protects the addresses in IP header cannot work with NAT enroute. Dont you think? > > Vernon Schryver[EMAIL PROTECTED] > cheers, suresh = __ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com
Re: draft-ietf-nat-protocol-complications-02.txt
--- Keith Moore <[EMAIL PROTECTED]> wrote: > > Also please do not steer this thread towards a NAT bashing-fest. We need to > > > complete this document and we need constructive input to this draft. > > unfortunately, the major premise of the draft is flawed. there > are far too many problems to NAT, affecting far too many applications, > to make a usefully complete list of the applications that are affected. > and the list is constantly growing larger. > > finally, the notion that one can fix NAT's problems with ALGs is > not only incorrect, it's impractical for NATs to support even > the applications for which ALGs are feasible. > > Keith > > Keith - If you have issues with the premise of the draft or the NAT WG - you should take this up with the ADs. This is not the forum to do that. Our mailboxes are just getting cluttered with way too much of the crusade stuff. That is not what the draft or the WG is about. You are welcome to send in input that can be valuable to the draft. Thanks. regards, suresh = __ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com
Re: breaking the IP model (or 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 shouldn't keep you from doing > something, but the fact that something violates fundamental design > assumptions should cause you to do some analysis and hard thinking > about the likely consequences of using them. and if you are in the > business of selling boxes that violate the design assumptions you > shouldn't misrepresent these to your customers. > > most of these hacks can be employed in ways that are mostly harmless, > but knowing when they are harmless and when they will cause harm > can be quite difficult. NATs seemed mostly harmless when they were > first deployed; now they're a huge problem. Hmm... Depends on one's perspective. Do not underestimate the timeliness of a solution. Timeliness is operational reality. It could have been catastrphic had we not had a timely solution with no addresses to issue. NAT is the reason we have had this much time to work on IPng. > > Keith > > regards, suresh = __ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com
Re: recommendation against publication of draft-cerpa-necp-02.txt
--- 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 Yahoo! Messenger. http://im.yahoo.com
Re: recommendation against publication of draft-cerpa-necp-02.txt
--- 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 view is skewed against NATs. It is rather > > hypocritical and unfair to say that those opposed to your view > > point are misleading the readers, while you apparently do not > > purport to mislead. > > I've tried to get an accurate assessment of the harm done by NATs. > Not surprisingly, NAT developers have tried to downplay these problems. > > the problem with a "NAT working group" is that it attracts NAT > developers far more than it does the people whose interests > are harmed by NATs - which is to say, Internet users in general. That is just not true. NAT WG attracts NAT users just as much and often more than NAT developers. It is perhaps your opinion that NAT harms more people than it benefits that is tainted. > so by its very nature a "focused" NAT working group will produce > misleading results. > Sorry.. Your conclusion is based on a wrong premise. > Keith > regards, suresh = __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: recommendation against publication of draft-cerpa-necp-02.txt
--- 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 > NAT group attempting to keep the extent of these drawbacks from > being accurately documented and to mislead the readers of those > documents into thinking that NATs worked better than they do - > for instance, the repeated assertions that NATs are "transparent". 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. I donot know who else you are refering to as the "significant forces in NAT group attempting to mislead readers into thinkining NATs are transparent". Clearly, your point of view is skewed against NATs. It is rather hypocritical and unfair to say that those opposed to your view point are misleading the readers, while you apparently do not purport to mislead. > So I'm not sure that this is a good model on which to base future work. > NAT WG has made substantial progress in the form of demystifying the FUD surrounding NATs. We still have work to do and intend to stay focussed to continue presening a balanced view point. regards, suresh __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: IP network address assignments/allocations information?
Folks, Hammers are inteded to solve a certain problem space. So, we should not use hammer to solve every problem we encounter, (or) ban hammers altogeher because they do not solve all problems. Now, the reality check. NATs donot respect end node ownership of IP entities (IP-Addr, port # etc). Thats how they accomplish address conservation and obviate address renumbering. This lack of IP address sactity clearly violates the assmptions made by a large number of problems. So, NAT is not the hammer to use. Make the problems go away (or) show clearly superior solutions to solve the problems. Then, may be, we wont need the NAT hammer. I dont have a problem with that. There are efforts going on in the IETF to precisely do the above. That is great and I am all for it. Soon, the market place will tell us when it is time to retire or replace the NAT hammers. Until then, let us not engage in NAT flaming (or) overtly push NATs to be a save-all solution. To that end, I encourage you to participate in in the NAT working group, addressing precisely these issues. There is a draft to desctibe NAT complications (i.e., limitations of NAT problem space) and your input to draft authors/editors is most welcome. The NAT WG also has a draft to define NAT friendly criteria that new applications need to adhere to for acceptability into NAT problem space. If you have some input you could provide, Please do. Lastly, there is an IAB draft describing architectural issues with NAT. Once again, do send in your comments to the draft authors. Thanks. regards, suresh = __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: To address or NAT to address?
--- 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 some truth in that (A6 records are quite complex...) > but NAT has generated some serious and complex dependencies on DNS too, > not to mention various load sharing techniques. > > Brian Brian, I am aware of the problems DNS-ALG has w.r.t. DNSSEC. But, what are the DNS Load-sharing problems you are refering to here? regards, suresh __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: To address or NAT to address?
--- Matt Crawford <[EMAIL PROTECTED]> wrote: > > It seems to me that we may be able to recapture some aspects of end-to-end > > transparency at the application level if addressing issues are focused on > > host FQDNs, rather than IP addresses. > > Forget about it. Many of the same folks doing NAT also do a > two-faced DNS which hides most of their names from the outside. So a > host inside such a site has no more idea of its global name than of > its global address. > > Its a different problem if you want to hide from outside access. That is independent of whether you use IP address or FQDN to label the host. regards, suresh __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: IP network address assignments/allocations information?
--- Henning Schulzrinne <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > > > In any event, I've always personally been of the opinion that > > > if applications don't work in the face of NAT, then the > > > applications themselves are functionally deficient and should be > > > fixed. :-) > > > > I'm certainly not going to disagree with you about that, > > but H.323 does not work through NAT without extremely > > sophisticated stateful inspection/rewrite capabilities > > in the NAT, and it will not work, period, if the signaling > > streams are encrypted. For better or worse (and let's > > not get into that), there's a lot of H.323 out there > > and there's going to be much, much more over the > > coming years. RSIP isn't going to work cleanly with > > H.323, either (although there are some rather disgusting > > things you can do in the application about that). > > Agreed. > > Any protocol that wants to have out-of-band control will have > difficulties with existing NATs (without ALGs). Good point. Out-of-band control will require an ALG. No argument there. But, that is not to say you shouldnt think about ALGs. > Thus, by saying "let's > design NAT-friendly protocols", we are effectively ruling out a whole > class of designs and only allow protocols with outgoing TCP connections > (and possibly UDP request-response protocols). I dont think, that is what is being said at all. If you could design applications that can work with NAT enroute, without needing an ALG; that would be great. But, if the applications do require an ALG enroute (as in the case of voice-over-IP which uses out-of-band call-control segnalling), then the application designers should also consider what it takes to build an ALG enroute. This is an issue not just with NATs, but also with firewalls and perhaps security gateways. >In the case of telephony, > it would mean keeping a TCP connection open continuously to some outside > server that would then use that TCP connection to send incoming calls > behind the NAT. > Are you refering to the TCP connection so you can retain the name-to-address mapping? I suspect, you need to do more than just that to permite RTP streams across NAT boundaries. In which case, you are better off monitoring the name-to-address mapping as part of the ALG, instead of relying on a TCP call-control session. > Thus, this is not just a matter of existing software, but fundamentally > restricting protocol design to a very narrow class of design choices, > choices which are basically inappropriate for anything related to > efficient multimedia carriage (real-time multimedia over TCP isn't > exactly a great option). > Please see my comments above. Protocol design will be deemed successful only as they are deployed. It does not harm to think of their impact on NATs, firewalls and security gateways - all of which are already deployed in a large number of locations. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > regards, suresh __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: IP network address assignments/allocations information?
--- Keith Moore <[EMAIL PROTECTED]> wrote: > > Keith - There is no denying that NAT devices break a bunch of applications > > and protocols. But, they did get us through the rough times when IP > > addresses are scarce and many people wanted to hop on the Internet. In a > > way, NATs helped people keep their trust in IP and in the engineering > > community as a whole to come up with solutions that meet the need of the > > time. > > the latter statement seems a bit extreme. one could as easily make the > statement that NATs are giving the engineering community a bad reputation > in the eyes of the public, given that so many problems are now being caused > by them. (also an extreme statement, but no less so than the first one) > I wasnt meaning to make an extreme statement. You are right; Neither of the statements by itself is complete. Fair is somewhere in the middle. > I'd rather just say that (a) NATs are a short-term fix with limited > applicability, (b) for the long term general solution we will need > longer addresses - as in IPv6, and (c) with careful definition of > adaptation mechanisms such as NAT-PT and 6to4, devices with NAT > and ALG functionality can be part of a transition path to IPv6. > That sounds good. Thanks. > > There are some folks who believe NATs are behind the creation of private > > addresses. The fact of the matter of the matter is the other way around. > > People have been using private addresses to build their networks; People > > change their providers, but do not want to renumber their networks each > > time they change their providers. NATs were able to provide connetivity > > to external world without requiring them to renumber their addresses in > > the private network. > > absolutely true. > > > If nothing else, I would say that NATs were able to bring to bear an > > awareness in the minds of protocol/application designers a need to > > seperate names and addresses. > > though folks are indeed looking into the implications of such a separation, > it's far from clear that this is a 'need'. every additional layer > of indirection imposes a cost in terms of money, performance, reliability, > and flexibility - all of which need to be weighted against whatever > advantages might be obtained from such a separation. > Address-renumbering and host-mobility come to mind as areas that can benefit from seperation of name and address semantics. Surely, this should be weighed against other metrics, as you say. No one solution fits all. > Keith regards, suresh __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: IP network address assignments/allocations information?
--- 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 new protocols that are so sensitive to end-to-end-ness > > (should they be? was that a valid assumption?), so a NAT is a great > solution > > for me. > > understood. and you may never miss any of those distributed applications > or applications that want your end to be the "server" for the very reason > that NAT prevents them from having enough market share to be successful. > > i.e. just because you don't know what you're missing doesn't mean that NAT > hasn't done you harm. > Keith - There is no denying that NAT devices break a bunch of applications and protocols. But, they did get us through the rough times when IP addresses are scarce and many people wanted to hop on the Internet. In a way, NATs helped people keep their trust in IP and in the engineering community as a whole to come up with solutions that meet the need of the time. Having said this, I do believe, people who market NAT devices should warn customers of the limitations and not pretend like there arent any. There are some folks who believe NATs are behind the creation of private addresses. The fact of the matter of the matter is the other way around. People have been using private addresses to build their networks; People change their providers, but do not want to renumber their networks each time they change their providers. NATs were able to provide connetivity to external world without requiring them to renumber their addresses in the private network. If nothing else, I would say that NATs were able to bring to bear an awareness in the minds of protocol/application designers a need to seperate names and addresses. That in itself seems like an accomplishment. > > NAT would be bad if an ISP were using it to artificially expand its address > > space; the use of NAT at the "small-time" end user's site seems quite > > practical and beneficial, especially in a world where ISPs are going to > hold > > up non-naive users for ransom. Cheers -- Ian > > if you think of NAT as a short-term strategy and are fully aware of its > limitations, it probably won't cause you much harm as an individual. > > then again, there are dozens of products out there claiming to offer > something like "internet connection sharing" without bothering to mention > the limitations of that approach...which seems like misleading advertising > at best. > I agree. > Keith > > regards, suresh __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
