The attitude you're expressing does not seem to be in the spirit of collaborative discussion, which I find somewhat unusual and disappointing coming from you. But, if that is your position you are certainly entitled to it and I have no problem with it.
Thanks - Fred [EMAIL PROTECTED]
Pekka Savola wrote:
>Hi, > >I just about used up all my aspirin and tranquilizers trying to read >this message constructively and trying to write a constructive reply >to this message but failed. > >I don't think this document is constructive as a requirements >document, and I'll strongly oppose it being adopted as WG document >at any point of time. > >On Mon, 17 Nov 2003, Fred Templin wrote: > > >>>well, the document seems like to completely concentrate on an >>>addressing-based solution model.. which it probably should not. Anyone >>>even glancing at the document can be 100% sure of this. >>> >>>Or was it only supposed to be agnostic of whether local-use addressing was >>>needed? There's a difference there.. >>> >>>So, I agree 100% with Erik's earlier comments on the "coloring" and the >>>"background" of the document.. >>> >>> >>> >>I'm still waiting to see the specific comments that will correct this >>often-expressed wrong impression. Maybe they will appear below; >>I'll respond as I go and see where we end up. >> >> >> >>>(I only read the beginning of the draft, got too big a headache..) >>> >>> >>> >>Take some aspirin, then. >> >> >> >>>substantial >>>----------- >>> >>>1) the whole section 3.2 Maintaining Confidentiality of the Address Space is >>>pretty much bogus. Remember, we're talking about using local communications >>>with *IPv6*. With IPv4, you would be required to record the address >>>prefixes in the RIR registries etc. -- but these are no longer relevant. >>>You get one /48, put it in the registry, that's it. No exposing needed. >>> >>>Beyond that, all the exposing you'd do is what you choose to do yourself. >>>If you don't want to give e.g. people the ability to traceroute through the >>>network to learn the network properties, you can prevent that. >>> >>>In summary, this whole section should be removed or seriously reworded. >>> >>> >>> >>I disagree. Network managers should be empowered to self-select >>addresses to be used for internal-only communications and with >>no pre-arrangement with a RIR. For example, in IPv4 I know that >>network 15/8 is owned by HP, network 16/8 is (was?) owned by >>Digital Equipment Corporation, etc. But, general knowledge of >>this is nothing more than a burden on the party holding the >>registration, since they now need to concern themselves with >>liabilities for misuse of the RIR prefixes. >> >>In IPv6, there should be no reason for even this level of >>exposure if the addresses are indeed to be used only for local >>communications. Thus, the ability for network managers to >>self-select addresses would be an improvement over the existing >>condition for IPv4. >> >> >> >>>2) I don't see the point of section 3.3 myself: >>> >>> Test networks are frequently large, elaborate networks with a mix of >>> public and private address space. Use of random unallocated space >>> runs the risk of collision with legitimate addresses on remote >>> networks if the test network is ever connected to the Internet. >>> >>>==> what kind of test network are you talking about? >>>why would you ever connect a test to the Internet, except through some DMZ >>>hosts/routers etc? >>> >>>With IPv6, you have enough addresses to play around if you want to connect >>>something to the net. If you don't, you can just invent something (most TAC >>>etc. labs probably certaintly do). No magic there... >>> >>>Needs rewording to bring up the point better or remove.. >>> >>> >>> >>OK, how about this: >> >> "Test networks often provide a vehicle for limited experimentation >> with new Internetworking technologies prior to widescale deployment, >> but they may need to connect to the Internet to facilitate the >>experiment. >> Such experiments may entail large, elaborate networks with a mix of >> public and private address space, but the use of random unallocated >> space runs the risk of collision with legitimate addresses on remote >> networks." >> >>But, is this enough to warrant a new document revision? I >>don't think so. >> >> >> >>>3) there is solutionism/assuming the addressing is the answer in many of the >>>goal sections, like 3.4, 3.6, 3.6.2, 3.6.3, 3.7, 3.8. Intentional? >>> >>> >>> >>Please provide specific examples of text that you believe assumes >>a particular solution alternative, since there was no intention to >>dictate a particular alternative. >> >>If certain solution alternatives seem to suggest themselves based on >>the scenarios, then the document is doing its work - but this is NOT >>due to the intentional manipulation of the authors (see changelogs >>and acknolwedgements for the substantial community input already >>taken). >> >> >> >>>4) section 3.6.2 is just section 3.5 again (note it says Section 3.2 in the >>>text), could be removed ? >>> >>> >>> >>This is a valid point, but I prefer to say that sections 3.6.2 and 3.5 >>could be consolidated rather than removing one or the other. Does >>this warrant another revision, though? My take is no. >> >> >> >>>5) section 3.7 is a bit incomprehensible: >>> >>>3.7 Asset Protection in Enterprise Networks >>> >>> Enterprise networks that protect private corporate assets (e.g., >>> printers, faxes, robotics, sensors, etc.) require an addressing >>> scheme that remains stable even when VPN connections from outside >>> sites occur. >>> >>>==> how on earth would VPN connections from outside disturb a stable >>>addressing scheme?!? >>> >>> >>> >>We are talking here about site mergers, which becomes apparent >>in the subsequent sentences of that paragraph. When two sites >>merge, ongoing local communications which were in-progress >>within the two seperate sites should continue without breaking >>when the two sites become one. >> >>The sentences you cite above are taken out of context, and the >>meaning seems clear enough when they are considered within >>the context of the entire section. >> >> >> >>>6) it's no surprise that section 4 on goals presupposes an addressing-based >>>solution. Is this intentional? In any case, the titles are: >>> >>>4.1 Easy to Acquire >>>4.2 Stable >>>4.3 Multiple Link Support >>>4.4 Prefix Filtering and Hints to Applications >>>4.5 Globally Unique >>>4.6 Usable in the Absence of a Provider >>>4.7 Applicable in Managed/Unmanaged Environments >>>4.8 Compatible with Site Naming System >>>4.9 Compatible with VPN >>>4.10 Multiple Addressing >>> >>>one could generalize and reword these to: >>> >>>4.1 Easy to Take to Use >>>4.2 Session Stability >>>4.3 Multiple Link Support >>>4.4 Application Awareness of Policy >>>4.5 Locality Between Multiple Sites >>>4.6 Usable in the Absence of a Provider >>>4.7 Applicable in Managed/Unmanaged Environments >>>4.8 Compatible with Site Naming System >>>4.9 Compatible with VPN (XXX: ?) >>>4.10 Provision for Both Local and Global Communications >>> >>> >>> >>One could always re-word, yes, but re-wording can always >>be done ad-inifinitum. I don't see anything in any of these >>suggestions that provides any beneficial clarification. >> >> >> >>>semi-editorial >>>-------------- >>> >>>Abstract >>> >>> The IPv6 addressing architecture specifies global and local-use >>> unicast addressing schemes, but provides no operational guidelines >>> for their use. >>> >>>and: >>> >>>1. Introduction >>> >>> The IPv6 addressing architecture [RFC3513] specifies global and >>> local-use unicast addresses. Global addresses are understood to have >>> unlimited range and may be used as the source and destination >>> addresses in packets that originate from any point on the connected >>> global IPv6 Internet. Local-use addresses are intended for use only >>> within the range of a single link/site, but their specification does >>> not address operational considerations for real-world deployment >>> scenarios. >>> >>>==> the critical local-use addressing part is to be removed before this >>>becomes relevant, so I don't think it's appropriate to refer to these >>>documents here. Suggest removing or serious rewording. >>> >>> >>> >>Update from [RFC3513] to [RFC3513(bis)] you mean? >>I don't see this in and of itself necessitating a document >>update; in fact, the role of the hain-templin document is >>to set the target in motion - not to track the target as it >>moves. >> >> >> >>>.... >>> >>>. As such, >>> the address prefixes used in each PAN should be globally unique to >>> avoid collisions and provide a means for verifying ownership to >>> resolve conflicts. >>> >>>==> this (in 3.5) doesn't seem to be relevant to the local communications, >>>remove? >>> >>> >>> >>This goes with the above comment on consolidating sections 3.5 >>and 3.6.2, but do these alone warrant a new document revision? >>My take is that they don't. >> >> >> >> >>>editorial >>>--------- >>> >>>. Of >>> utmost importance is that the systems on board the ship all function, >>> >>>==> s/Of utmost importance is/It's of utmost importance/ >>> >>> >>> >>Noted. >> >>Fred >>[EMAIL PROTECTED] >> >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>[EMAIL PROTECTED] >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> >> >> > > >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
