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
to all MIDCOM clients that have access to one of the
terminated rules.
As
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: MohsenSTRAW 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: 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: 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 from the outside to a particular IP/port on the inside unless an outbound packet has
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 = ___ 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
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
-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
... 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=ind0108L=ospf; T=0F=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: [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
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=ind0108L=ospfT=0F=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=ind0107L=OSPFD=0I=-3P =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=ind0212L=OSPFD=0I=-3P =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 draft-katz-yeung-ospf-traffic-09.txt 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 the SUB-IP (and/or other) directorates to ensure the continued coordination between the remaining WGs.
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: 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
--- 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: [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
--- 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: 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: ... 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: 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: 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: 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: 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
