Re: concerning draft-josefsson-dns-url-08.txt
Paul Vixie <[EMAIL PROTECTED]> writes: >> This view limit the usefulness of the URI, as it cannot be used to >> refer to, e.g., not-yet delegated data. It can be useful to use DNS >> URIs to denote DNS data in a delegation request, to indicate where the >> new data will be placed, so it can be checked for conformance with >> various rules. > > i guess we're in different weeds now. because of the high abstractness > of your "hostport" definition, there's no guaranty that the dns protocol > will even be used by the uri-handler to resolve the pseudoquery. so, the > idea of "not-yet-delegated" has no foundation at all. > > here's the real issue: there are many companies and political movements who > think that iana's namespace is not the only namespace. new.net, for > example. iab takes a very strong "single unique namespace" view, and as > such, the i* organizations (iesg in this case) will probably (and ought to, > in my view) take a very dim view of any attempt to standardize a uri that > permits a "multiple namespace" fiction to be operable. I don't see how this relate to being able to specify the DNS server to query in a URI to denote DNS data. Can you describe how the DNS URI with a "hostport" make multiple namespaces operable? Having multiple namespaces is not [inter]operable by definition, IMHO. The DNS URI is not an attempt in this direction. > to me the layering violation of your "hostpart" suggestion is jarring, and > obvious, and is approximately equal to extending "hostpart" in normal http: > (and telnet: and mail: and so on) uri's to allow one to specify not only a > hostname, but also the address of the dns server which ought to be asked > to resolve the A or query. "http://new.net:foo.sex/bar/";, anyone? if > you answered "no" then you gotta ask yourself why allow a "hostport" in a > dns: uri if you dislike its tangible equivilent in other parts of the spec. I see no problem here. A HTTP URI should not contain the DNS server address to use, since the HTTP specification describe how the server is found. Same goes for mailto; RFC 821 and 2821 describe how the SMTP server for a mail address is found. Adding the DNS server to use would expose details that should be hidden in the application. The situation is different for a DNS URI, since RFC 1024/1025 describe how you query a specific DNS server (IP) via the DNS protocol. I claim it can be useful to specify this information, but acknowledge that removing the hostport would remove this potential confusion. >> > you can't have it both ways. either you're trying to represent dns data >> > using the tuple, or you're trying to represent >> > the query itself. >> >> I'm trying, like the document says, to represent dns data using the >> tuple together with the authority/server. The >> authority was added to be able to denote data that, for some reason, >> is not linked into the global DNS. The reason could be multiple >> roots, split-view DNS, disconnected operation, efficiency or whatnot. > > ah, meat. for multiple roots, the iab has (thankfully) recognized that > the dns just doesn't work that way. The global DNS namespace and the DNS protocol are not the same thing. I believe the IAB has only recognized that the former, the namespace, doesn't work with multiple roots, in RFC 2826. And like I say above, I don't see how the DNS URI further the multiple namespace root cause. That the DNS protocol can handle multiple roots is a technical property that can be used for good purposes, in which "hostport" can be useful. (Of course, it is not only useful for multiple roots.) Do you have a reference to where the IAB recognize that the DNS protocol technically doesn't work with multiple roots? > for split-dns and disconnected operation, the place to put that kind > of policy is in the resolver, not in every application who calls it. DNS URIs can be used to put this kind of policy in the resolver. Applications are not generally expected to support DNS URIs. > the tradeoff between efficiency and correctness weighs > VERY heavily on the side of correctness, such that the likelihood of > getting the wrong data or no data by using "hostport" for efficiency > is MUCH HIGHER than the likelihood of a performance problem from not > using it. (for user populations of a global size, as ours is.) Some people still do experiment to improve the efficiency in the DNS. The DNS URI is not intended to be used widely (see the specification, and "Intended Usage"), nor will the "hostport" field always be present; that's why it is optional. People would avoid using the "hostport" field if it decreased correctness for them. >> I could remove the hostport element if the consensus is that doing so >> would improve the usefulness of the URI. Anyone else with an opinion? >> Remove hostport or keep it? > > for my part, i'd like to hear the iab's input, since this goes to the > architecture of the overall internet system. There hasn't been much
Re: concerning draft-josefsson-dns-url-08.txt
sorry to lose momentum on this thread, i got busy with something else briefly: > > a dns resource lives where its parent NS RRs say it lives -- and not, as > > you also suggest... > > > >> The hostport describes the authority that know the intended DNS > >> resource. An authority is useful even for abstract, non-DNS-protocol, > >> DNS resources. DNS resources themselves are indexed by (NAME, CLASS, > >> TYPE), but to distinguish between the answer that entity A > >> knows/generate, and the answer that entity B knows/generate, an > >> authority scope like "hostport" is needed. > > > > ...in the answers that different entities can generate. > > This view limit the usefulness of the URI, as it cannot be used to > refer to, e.g., not-yet delegated data. It can be useful to use DNS > URIs to denote DNS data in a delegation request, to indicate where the > new data will be placed, so it can be checked for conformance with > various rules. i guess we're in different weeds now. because of the high abstractness of your "hostport" definition, there's no guaranty that the dns protocol will even be used by the uri-handler to resolve the pseudoquery. so, the idea of "not-yet-delegated" has no foundation at all. here's the real issue: there are many companies and political movements who think that iana's namespace is not the only namespace. new.net, for example. iab takes a very strong "single unique namespace" view, and as such, the i* organizations (iesg in this case) will probably (and ought to, in my view) take a very dim view of any attempt to standardize a uri that permits a "multiple namespace" fiction to be operable. to me the layering violation of your "hostpart" suggestion is jarring, and obvious, and is approximately equal to extending "hostpart" in normal http: (and telnet: and mail: and so on) uri's to allow one to specify not only a hostname, but also the address of the dns server which ought to be asked to resolve the A or query. "http://new.net:foo.sex/bar/";, anyone? if you answered "no" then you gotta ask yourself why allow a "hostport" in a dns: uri if you dislike its tangible equivilent in other parts of the spec. > > you can't have it both ways. either you're trying to represent dns data > > using the tuple, or you're trying to represent > > the query itself. > > I'm trying, like the document says, to represent dns data using the > tuple together with the authority/server. The > authority was added to be able to denote data that, for some reason, > is not linked into the global DNS. The reason could be multiple > roots, split-view DNS, disconnected operation, efficiency or whatnot. ah, meat. for multiple roots, the iab has (thankfully) recognized that the dns just doesn't work that way. for split-dns and disconnected operation, the place to put that kind of policy is in the resolver, not in every application who calls it. see http://sa.vix.com/~vixie/proxynet.pdf for an example of how to do this (it's from 1995 but the code still compiles if anybody still wants it.) the tradeoff between efficiency and correctness weighs VERY heavily on the side of correctness, such that the likelihood of getting the wrong data or no data by using "hostport" for efficiency is MUCH HIGHER than the likelihood of a performance problem from not using it. (for user populations of a global size, as ours is.) > I could remove the hostport element if the consensus is that doing so > would improve the usefulness of the URI. Anyone else with an opinion? > Remove hostport or keep it? for my part, i'd like to hear the iab's input, since this goes to the architecture of the overall internet system.
Re: Where can I find capwap BOF Agenda ?
At 05:44 PM 7/1/2003, Soohong Daniel Park wrote: >Hi all > >I am searching for capwap Agenda http://www.ietf.org/ietf/03jul/capwap.txt >Friday, July 18 >OPS capwap Control And Provisioning of Wirelsss Acc. Point BOF > > > >Daniel (Soohong Daniel Park) >Mobile Platform Lab,SAMSUNG Electronics Andy
Re: the end-to-end name problem
S Woodside wrote: [..] > That is, perhaps, a good thing, since I think that most naive people > will THINK that they intuitively grasp what end-to-end means, but they > are wrong. Most naive people are wrong about many things, but this is not an argument for making up new words to express broadly-similar-but-different-in-context concepts. It is an argument for naive people to recognize their lack of knowledge and go to the sources pertinent to the subject matter. Which, for the purposes of understanding packet networking and "the internet", is NOT your local dictionary. gja
Re: The requirements cycle (Re: WG review: Layer 2 Virtual....)
] > L2VPN is not progress. It's the opposite. ] ] users do want ways to bridge a layer two lan across the internet. yeah, I know. of course, there are some things users want to do that you simply cannot make work well. not that we've let that stop us before...
Re: The requirements cycle (Re: WG review: Layer 2 Virtual....)
> L2VPN is not progress. It's the opposite. users do want ways to bridge a layer two lan across the internet. and this seems a legitimate desire that should be doable without breaking anything. of course, this will drift into areas where we know large l2 networks have problems. but, if properly done, that should not affect the internet across which the lans are bridged. otoh, those kinds of l2 issues and others should make us very cautious when evaluating schemes to make the transforming the internet core into an l2 circuit network. randy
Re: the end-to-end name problem
> From: grenville armitage <[EMAIL PROTECTED]> > a dictionary is hardly a compelling substitute for going direct to the > paper(s) in which the end to end principle has been articulated. I couldn't agree with your suggestion more; were I Tsar of the Internet, I'd make it a rule to bind and gag anyone who utters the phrase "end-to-end principle" who hasn't read this excellent paper, easily available here: http://www.reed.com/Papers/EndtoEnd.html However, I will differ with you slightly, in that reading this paper will not necessarily produce 100% enlightenment. If you actually talk with the authors, you will discover that in the time since the paper was written, their understanding of what they were trying to get at has deepened (they now talk about a "network end-end principle", which has important differenced with an "application end-end principle"), and in addition two of them (Reed and Clark) have since gone in slightly different directions in their thinking! I was discussing this all with them at length, but alas I don't have access to all my notes at this instant; perhaps I can produce another page containing some additional commentary on the end-end principle, in addition to: http://users.exis.net/~jnc/tech/end_end.html which discusses one popular misconception about the end-end principle. Noel
Re: The requirements cycle (Re: WG review: Layer 2 Virtual....)
high level bit of this reply: from my perspective, the management of the PPVPN WG appears not to have been optimal, to say the least. But I'm not willing to blame *all* the delay and confusion on the IESG. even if a WG feels abused by the IESG, or its AD, that's no excuse for a WG not fighting back - in this case, by rapidly removing the IESG's apparent excuses for delay. Dejection is an explanation, not an excuse. Details: --On torsdag, juli 03, 2003 12:52:48 -0400 Eric Rosen <[EMAIL PROTECTED]> wrote: Harald> did any of the technologies change because of issues that were Harald> discovered in the discussions that were needed to clarify the Harald> requirements and framework? No. Harald> If no - why did it take any time at all to produce them? Not sure what you mean, it always takes time to produce a document, even if the document is just a "rock fetch". sorry; "rock fetch" is beyond my scope of American idiom. But version -01 of the framework document is dated July 19, 2001, and the first version submitted to the IESG is dated February 15, 2002. (I don't have a copy of -00). So the WG spent at least 7 months and 5 versions on it before submission. I took that as a hint that there might have been controversy in the working group about it. Harald> there is little that the IESG can do when the WG knows what the Harald> comments are and chooses not to act upon them for 2-5 months. This reminds me of Dilbert's pointy-haired boss, who says "your project is late, so I want you to give me hourly status reports." just as well that I did not suggest that the IESG could yell more at the WG to update the documents, then When we have documents which aren't really necessary in the first place, which ultimately will not have any impact on the technology, but which need to be massaged and remassaged so as to get them past the IESG, I think it's quite clear where the responsibility for the delay is coming from. If I accepted your evaluation as true, I'd agree with you. Harald> And I don't understand why WG updates to fix problems take 2-3 Harald> months per cycle when the WG thinks that it's important to be Harald> finished with the docs. Well, each objection from the IESG needs to be discussed and a response crafted. which should take approximately 3 days of work, IMHO. Comments that translate to "you are referencing an obsolete version of LDAP" should take approximately 2 minutes to fix. Harald> is the IESG supposed to care about inconsistencies between the Harald> requirements (which are what the *WG* thinks should be satisfied) Harald> and the technologies that will be proposed for standardization? Sure; but the reqs, framework, protocol specs, and applicability statements were all ready 18 months ago. They could have been submitted as a group. But we were told, "first you need to submit the first document, then a year or so later you can submit the second". This is a very peculiar way to encourage progress ;-) From the WG perspective, the specs have been ready for review forever, but the IESG has refused to look at them because of bogus process issues. And then they turn around and accuse the WG of making slow progress! I did not see that instruction. On the surface, your suggestion seems a sensible one; if the WG had officially declared consensus on all the documents at that time, I do not understand why you couldn't do it that way. Did the WG declare consensus on all those documents 18 months ago (January 2002)? (And in the interest of being specific, I'd like you to say which documents you think of when you say that..) Harald
Re: the end-to-end name problem
On Thursday, July 3, 2003, at 06:11 AM, Iljitsch van Beijnum wrote: On woensdag, jul 2, 2003, at 23:43 Europe/Amsterdam, S Woodside wrote: I think there's a problem with the name "end-to-end". End is a word with a lot of definitions: for example wordnet [1] lists 14 senses for the noun end and 4 more for the verb. Indeed, we must walk down to the 5th definition before we come to the one that is relevant. >> [2] [...] Semantics, at its worst, is something that can be argued about endlessly and pointlessly. But, I'm sure that many people in the IETF spend at least some time introducing the CONCEPT of end-to-end networking to novices. Novices, who know english but not the internet, may be confused. You're falling in your own trap here. The concept "end" is very fundamental and as such understood by everyone who can read and write. The dictionary just lists some ways in which the concept is applied. The fact that there are many applications shows the concept is fundamental, not that it is ambiguous, as you suggest. The fact that the word "end" has so many meanings does imply that it's a common word. But people are aware that the popular can have many different meanings. The problem is that the meaning intended by End-To-End is not among the naïve meanings. It is a typical trap in naming things to choose a word that is misleading. It is often much simpler to choose a word that is totally made up or has no significance, like an acronym, or a combination of letters and numbers. Like TCP/IP, which has no naive meaning at all, and requires the naive person to dive in to make any conclusion. One alternative, used is "edge networking" and edge has much fewer definitions (only 6 for the noun) and the very FIRST one is the relevant one. I don't know about you, but "end to end" sounds like something that I might grasp intuitively, but "edge to edge" not so much. That is, perhaps, a good thing, since I think that most naive people will THINK that they intuitively grasp what end-to-end means, but they are wrong. simon -- www.simonwoodside.com -- 99% Devil, 1% Angel
Re: the end-to-end name problem
On Thursday, July 3, 2003, at 01:54 AM, Einar Stefferud wrote: I expect we could safely say that TCP/IP is an End-to-End protocol pair, and though it is a critical part of the Internet, it is not "The Internet". It isn't? Then what is "the internet" ? There are at least two other network arguments that can be made to support the end-to-end principle (and potentially rename it) The network effect - whether it's Metcalfe's law, or Reed's law, or otherwise. The network effect, I think, is real. We can say that the network effect reinforces the upwards scaling of any network, by delivering much better than linear payback. Thus, it can be argued that the IDEAL network, is a network that scales upwards as quickly as possible, for as long as possible. Now, we can compose an argument that the most scalable network, is an end-to-end network, because it contains the simplest network core, and thus the most easy to scale network core. If that argument is valid, then we can say that the network effect supports the end-to-end principle. The neutral network argument - this is an argument that I have seen much more from the side of economics and law. I have seen the term used in relation to the internet by Lawrence Lessig [1]. Network neutrality argues that a network should be unbiased to any particular USER or USE. This would again lead to a principle network simplicity, since any kind of complexity would either (a) indicate an effort to control the network internals or (b) allow operators to impose greater control by taking advantage of the complexity. Fully describing the Internet requires much more sophisticated mathematical logic than simply declaring that it employs End-to-Endness, even though some of its parts do exhibit end-to-endness which is put to good use to make The Whole Internet work as it does. Perhaps the neutral network arguments in economics would help. simon So, we must not do away with End-to-Endness where it is used, or ignore all the rest of what makes the Internet what it is. Cheers...\Stef At 20:41 -0400 7/2/03, Keith Moore wrote: ] We all know what the end-to-end principle means. well, you'd think so - but these days I hear it used to justify all kinds of things that have nothing to do with its original meaning. I think it's becoming a religion - something that is accepted without question, and usually, without undertanding. [SNIP]... -- www.simonwoodside.com -- 99% Devil, 1% Angel
Re: The requirements cycle (Re: WG review: Layer 2 Virtual....)
> Sure; but the reqs, framework, protocol specs, and applicability > statements were all ready 18 months ago. They could have been > submitted as a group. But we were told, "first you need to submit > the first document, then a year or so later you can submit the > second". This is a very peculiar way to encourage progress ;-) L2VPN is not progress. It's the opposite.
Re: The requirements cycle (Re: WG review: Layer 2 Virtual....)
Harald> did any of the technologies change because of issues that were Harald> discovered in the discussions that were needed to clarify the Harald> requirements and framework? No. Harald> If no - why did it take any time at all to produce them? Not sure what you mean, it always takes time to produce a document, even if the document is just a "rock fetch". Harald> there is little that the IESG can do when the WG knows what the Harald> comments are and chooses not to act upon them for 2-5 months. This reminds me of Dilbert's pointy-haired boss, who says "your project is late, so I want you to give me hourly status reports." When we have documents which aren't really necessary in the first place, which ultimately will not have any impact on the technology, but which need to be massaged and remassaged so as to get them past the IESG, I think it's quite clear where the responsibility for the delay is coming from. Harald> And I don't understand why WG updates to fix problems take 2-3 Harald> months per cycle when the WG thinks that it's important to be Harald> finished with the docs. Well, each objection from the IESG needs to be discussed and a response crafted. Harald> is the IESG supposed to care about inconsistencies between the Harald> requirements (which are what the *WG* thinks should be satisfied) Harald> and the technologies that will be proposed for standardization? Sure; but the reqs, framework, protocol specs, and applicability statements were all ready 18 months ago. They could have been submitted as a group. But we were told, "first you need to submit the first document, then a year or so later you can submit the second". This is a very peculiar way to encourage progress ;-) From the WG perspective, the specs have been ready for review forever, but the IESG has refused to look at them because of bogus process issues. And then they turn around and accuse the WG of making slow progress!
Re: the end-to-end name problem
On Thursday, July 3, 2003, at 05:26 AM, Zefram wrote: S Woodside wrote: we must walk down to the 5th definition before we come to the one that is relevant. [2] 1. end -- (either extremity of something that has length; "the end of the pier"; "she knotted the end of the thread"; "they rode to the end of the line") This definition looks relevant. More relevant than the fifth. It's talking about something linear. simon
Re: the end-to-end name problem
S Woodside wrote: [..] > Novices, who know english but not the internet, > may be confused. Forgive me for not thinking it insightful to observe that technical terminologies are often confusing to novices. This insight is hardly a compelling argument for gratuitous word substitutions. Likewise a dictionary is hardly a compelling substitute for going direct to the paper(s) in which the end to end principle has been articulated. cheers, gja -- Grenville Armitage http://caia.swin.edu.au I come from a LAN downunder.
Re: the end-to-end name problem
Simon; > We all know what the end-to-end principle means. It's (reportedly) THE > guiding principle of the IETF, and THE guiding principle of IETF design > decisions. The problem I am trying to demonstrate with this dictionary > analysis, is that average non-indoctrinated person needs to travel a > long way from the simple word "end" in order to get to the definition > that the IETF actually means. Wrong. It is the principle of not the IETF but the Internet. As you should recognize, most, if not all, of recent activity of IETF is against the principle, against which, the Internet is operated. Well organized standardization body such as IETF is an intermediate intelligent entity between end users and the Internet. That is, according to the principle, an intermediate intelligent entity of IETF MUST be removed. Masataka Ohta
Re: the end-to-end name problem
On woensdag, jul 2, 2003, at 23:43 Europe/Amsterdam, S Woodside wrote: I think there's a problem with the name "end-to-end". End is a word with a lot of definitions: for example wordnet [1] lists 14 senses for the noun end and 4 more for the verb. Indeed, we must walk down to the 5th definition before we come to the one that is relevant. [2] [...] Semantics, at its worst, is something that can be argued about endlessly and pointlessly. But, I'm sure that many people in the IETF spend at least some time introducing the CONCEPT of end-to-end networking to novices. Novices, who know english but not the internet, may be confused. You're falling in your own trap here. The concept "end" is very fundamental and as such understood by everyone who can read and write. The dictionary just lists some ways in which the concept is applied. The fact that there are many applications shows the concept is fundamental, not that it is ambiguous, as you suggest. One alternative, used is "edge networking" and edge has much fewer definitions (only 6 for the noun) and the very FIRST one is the relevant one. I don't know about you, but "end to end" sounds like something that I might grasp intuitively, but "edge to edge" not so much. Also, "edge" is used for other stuff in the industry.
Re: the end-to-end name problem
S Woodside wrote: > we must walk down to the >5th definition before we come to the one that is relevant. [2] > >1. end -- (either extremity of something that has length; "the end of >the pier"; "she knotted the end of the thread"; "they rode to the end >of the line") This definition looks relevant. More relevant than the fifth. -zefram
