User:Hcberkowitz/Inactive-Routers

Router
I reverted your additions to router because you posted the information to the wrong article. There has been discussion on this. Router is about routers, routing is about routing and routing protocols covers the protocol topic. Your additions should have been split between the two other articles. There has discussion that these need to be split so that it does not overwhelm the average reader. Your additions were g ood one, just placed in the wrong places. --User: (talk • contribs • count) 02:51, 26 June 2007 (UTC)


 * I'm sorry, but some of the reverted changes are technically wrong. ICMP absolutely does not pass path information between routers, other than in the extremely limited sense of redirects and destination unreachables. Routing protocols pass this information. The routing protocols need not be listed, but that is what they do, as opposed to an exception reporting protocol such as ICMP. Were I to get too compulsive, I'd also introduce link-local router, not routing protocols, such as VRRP, HSRP, or GLBP.


 * "Switch" is really a marketing term, but a wide range of products from multiple vendors (Cisco, Nortel, Extreme and others) do not learn topology by frame discovery, but by exchanging routing protocol information. Some medium-level Cisco switches may have layer 2 only SMI software images rather than layer 3 (routing) EMI software images. A high-end Cisco switch like the 6500, however, is principally a layer 3 device. Again where marketing raises its head, the even higher-end 12000 series products are called Gigabit Switch Routers (GSR). Historically, this comes back to a Wellfleet/Bay marketing slogan of "switch when you can, route when you must."


 * Perpetuating the idea that "switch" is a technically meaningful term better than "bridge" or "router", constantly confuses beginners. I'm open to comments, but I really believe at least part of the reversion needs to be reverted. ICMP, for example, simply does not do what the earlier version describes. For the record, I have been a router developer and IETF Routing Area participant. See, for example, RFC 2072 and RFC 4098 as open-source IETF documents; it would seem inappropriate to cite my own books on routing.


 * I am sorry, you are correct. I did not completely finish working on the router artile page.  If you looked at it a week ago it was much worse.  Looking at the history, it seemed like a good idea to leave this split. There were many tags complaining that the material was too complex, not enough data, all types of issues.  It seemed like a good idea.  The next problem is that, remember anyone can edit an article, so mis-information winds up in an article and then other editors feed on it.  Some of the data in this article has been wrong for a long time.  Now regarding the issue you mention concerning a switch.  This is a vendor related issue issue, I have owned a switch that just watches the traffic, sees where it goes and learns what port it is going though.  This is why in the article I said it learns and I was not specific. I was not specific because different switches from diff. companies work differently.  ICMP should not be in this article, I missed it.  You can point your own book to me on my talk page and I can reference it.  As far as your expertise. GREAT! I hope you will work on the routing protocol article for sure.  I also used to do work in the IETF and co-aut an RFC which is now forgotten.  The problem is that we as authors need to form a consensus on where data goes and in what articles.  These articles were so messed up, you could not believe it.  I am glad you are willing to help.  I will partially revert. --User: (talk • contribs • count) 04:16, 26 June 2007 (UTC)

If you have time please have a look at the article Network switch I am going to tag the article with an expert tag becuase this article needs a great deal of help as well. There is so much mis-infomation here, I am glad you are here to help clean things up. --User: (talk • contribs • count) 04:42, 26 June 2007 (UTC)

Telecommunication
Hi,

Welcome to Wikipedia. Thanks for your changes to the telecommunication article. Unfortunately the article is presently trying to achieve featured status. One of the comments about the article in a previous nomination (see Zvika's comment here) was that it contained too many technical details. As a result, we are trying to keep technical details to a minimum, improve referencing and improve writing (for why we are doing the last two see here). This means your changes might be changed or removed after they are added. If you think you can improve the article further to address the previously linked comments, please don't hesitate to do so. Also consider contributing to the many sub-articles on telecommunication.

Cedars 00:09, 27 June 2007 (UTC)


 * I don't necessarily argue that the article has too much technical content. Certain technical content, however, is appropriate for a discussion that isn't limited purely to the social effects of telecommunications.


 * As an example of technical content that may be too deep, I can easily see moving anything, for example, on analog versus digital to an article on "telecommunications transmission", or a similar title. I can see cutting discussion of multiplexing, in this article, back to the level of "More than one user can use a physical telecommunications medium, using multiplexing techniques.


 * Where I did add technical content, I think the discussions of one-way, two-way alternating, and two-way simultaneous communication are significant with respect to the social and human interface aspects of telecommunications. These terms, I believe, are more intuitive than the various forms of duplex; I'd move duplex to the link to the article on telecommunications transmission.


 * The more I think about this, the more I think that a linked article on transmission technology would be the first place to move content. I am not sufficiently versed in Wiki editing and consensus building to know how to stimulate discussion on this point -- the discussion page on telecommunications seems to have grown to unwieldy size for commentary.


 * Please guide me in the appropriate direction to have this discussion.


 * Incidentally, how can I get my user signature to have Howard C. Berkowitz display--other than editing it manually each time? Howard C. Berkowitz 15:55, 27 June 2007 (UTC)


 * You can sign your posts by typing ~ . It will automatically be converted to your signature when you save. The article on transmission is available here. According to the tag, it is in need of some help. You may also like to edit your user page here to provide some information on yourself for other community members. In a topic as big as telecommunication it always difficult to tell what should be included and what should not. Cedars 01:17, 28 June 2007 (UTC)

More on Telecommunication
Relevant comments copied from other pages:

''As an example of technical content that may be too deep, I can easily see moving anything, for example, on analog versus digital to an article on "telecommunications transmission", or a similar title. I can see cutting discussion of multiplexing, in this article, back to the level of "More than one user can use a physical telecommunications medium, using multiplexing techniques.''

''Where I did add technical content, I think the discussions of one-way, two-way alternating, and two-way simultaneous communication are significant with respect to the social and human interface aspects of telecommunications. These terms, I believe, are more intuitive than the various forms of duplex; I'd move duplex to the link to the article on telecommunications transmission. Howard C. Berkowitz 15:55, 27 June 2007 (UTC)''

''At the least, I see creating a new article for "telecommunications transmission", and moving such things as analog versus digital, modulation, etc., there. I'd move the introductory discussion of duplex modes there (with links to more detailed articles), but keep one-way, two-way alternating, and two-way simultaneous in the main article, as terms that are less ambiguous, have definitions in standards, and, I believe, are more intuitive to people.''

''Another new subsection with appropriate links might be "user interaction with a telecommunications system". This would include the types of user information that could be carried (voice, data, images, etc.), perhaps the one-way versus two-way, and a brief discussion of efficiency of, and interference with, telecommunications, which links to such things as information theory. Howard C. Berkowitz 16:02, 27 June 2007 (UTC)''


 * One of the questions I tried to think about while editing telecommunication is what would someone who knows nothing about telecommunication want to know about? I think one of the things they would most want to know about is how the devices that they use in their everyday lives work. That's why the article tries to give some insight into how the Internet, telephone, radio and television work. It also tries not to make the explanations too simplistic, so that they also work for more advanced users. However, I worry discussing things like information theory will take the article too far away from answering that question. Cedars 01:48, 28 June 2007 (UTC)


 * With your experience I am sure there is a lot you can bring to the article. I would especially like someone to look over the Modern Operation section (which I think is where the article needs most improvement). The problem is the more I think about it, the less relevant I see describing one-way, two-way alternating and two-way simultaneous communication is to occasional visitors to the article. Describing modulation for example helps them to understand how their radio works. Describing channels (and briefly multiplexing) also helps them to understand how their radios work. But describing one-way, two-way alternating and two-way simultaneous doesn't seem to help in the same way. Cedars 01:55, 28 June 2007 (UTC)


 * By the way, the article reviewers are often very demanding about citations, so please cite as much as possible if you edit the article. Cedars 02:05, 28 June 2007 (UTC)

Excellent work on Router
Excellent work on router. I must point out however that you must decide if you want to create stub articles or add the content, you cannot re-write the section as a stub elsewhere. Also every article needs reference and cites place properly or a bot will come and flag them automatically for deletion.


 * I'm not sure what you mean by creating stub articles or rewriting elsewhere. What I was trying to do is to move certain more technical areas out of the main article where they have been criticized, and then add to them given the appropriate time.
 * Unfortunately, in routing, switching, etc., there's a huge amount of marketing, or at least vendor-specific terminology and even framework. Routing needed a near-total hacking to get that out, and "network switch" is worse. I'm sitting here with a hard copy of the latter, trying to get a sense of where to start given the technically erroneous idea that there is something architecturally unique called a "switch". Now, I can describe layer 2, 3, 4/5 and 7 switching as they are used in the marketplace, but, in many cases, I'd see the material in the general article being more of a framework. Layer 4 switching, for example, variously can mean quality of service enforcement, stateful network address translation for failover, load balancing of specific TCP exchanges, etc. It could be flow switching.

I fixed your article, Control Plane by making the cite in the references section. Also it needs to be listed as a stub because it is too short. Even the article I wrote on Server appliance is a stub.

I hope this information helps you. --User: (talk • contribs • count) 18:48, 28 June 2007 (UTC)


 * Thanks. I need to sit down and spend some time on how the reference citations work in Wiki formatting. It's not a problem to come up with a citation for much of this work; my challenge is understanding the bibliographic notation.


 * Did I misunderstand what you did, or did you remove the RFC citation in your edit? Does some of the material you put at the end cause the RFC reference to appear there?


 * I will try to explain. When you write an article here. They most be notable worthy of being listed. So for one thing you need a cite, and a references section. If you look at the article I fixed, you will see that the information is all still there, but it does not show up in the article, it shows up in the references area.  You do this with the tag.  In the references area, you will see that the there is a tag. This tag tells wiki where to build the list.   The next thing I would like you to know is that you cannot duplicate information as you did.  I actually like doing it the way you did it, but I have had articles ripped apart becuase of this. To explain. Your article Control Plane is a stub. Becuase it has useful infomation but it is to short. If it is too short, like a definition of a word, it will be delete, definitions don't belong here. Now saying this, if you write an article called control plane you cannot have a section in the router protocol article that explains the same thing. You just use the normal wiki link to point to it.  If and editor see this, they just trim it all away and your article that you worked so hard to do looks destroyed.  So please rememeber.  Everything you talk about needs a reference and you have to cite it in the references area. You don't say inline, Routes are defined in RFC 89xxx that use this method.  Instead you would say, Routes are defined using this method. and then you put in the cite that will build the reference information.  I hope this information helps you and feel free to ask me for any help or anything you want me to look at, I will gladly help you.  I would also like your help. There is alot of bad info in wiki and I am part of the cleanup project for networking.  When your done with routing are you interested in helping in other articles. ?  Best Regards, Al --User: (talk • contribs • count) 22:51, 28 June 2007 (UTC)


 * I see what you did with the initial paragraph, and appreciate it. Let me print that out and meditate on it in hard copy. Definitely interested in doing more, and I'm also trying to recruit some colleagues. Clearly, there is a specific style I need to grasp.


 * I built out "Forwarding Plane" in more detail. Part of the problem here is trying to get a good grasp on what is an awkward set of articles: awkward from an architectural standpoint. Separating "router" from "routing", for example, doesn't make a lot of sense to me. Separating routing protocols from routing/router does make sense, but I'd prefer to see routing protocols brought it through the indirection of a control plane. Not all information in the control plane comes from routing protocols. I plan to build that section out a bit, and that's where the status of local interfaces (hardware and software), as well as static routes, should go. I'm thinking of putting a section "Sources of Control Information" under the control plane, with subsections for local status, static routes, and then a placeholder that points to dynamic routing.


 * Is there a way to suggest a consensus on the set of articles on related subjects?


 * There are other parts of control information, such as filtering, reservation, etc., that would be at an equal level with "Sources". I haven't yet thought through where specialized routing, which builds on unicast dynamic routing, goes. These topics include multicast routing, MPLS path setup, and (if it's not a blind alley) QoS-based routing, which all build on unicast control information.


 * Again trying to avoid overload, I can't help but think of the constraint-based routing extensions used in optical path setup. I'm tempted to put a "trivia" section into "router", including the evolution of the saying that "routers need magic smoke to run. If you see the smoke leaking out, you know the router has failed." The evolutionary aspect comes from optical routing, in which you supplement the routing rules with something called preservation of the wavelength continuity property. In lay terms, wavelength continuity means that you don't have to refocus the mirrors in the optical elements if you keep a route all the same "color". So, we can now say that losing magic smoke, or breaking the magic mirror when present, causes a router failure.

PS Articles always have a default intro paragraph and then sections, so the intro you wrote for Router is great but to long for an intro, this is why there was a section called function. Also bear in mind that the into paragraph needs to be written for someone who does not know what a router is or a subnet or a network. Just really basic introduction. I will put the section back and you may want to ease in for a non computer user. Please rememeber anyone can edit your article and an admin can rip it apart, so I tell you this to preserve your good work and for you not to have to learn the hard way (the way I did).--User: (talk • contribs • count) 23:00, 28 June 2007 (UTC)

Merging Router with Routing
Yes I really app. all your help. The issue here is that wiki is a group effort and there are two other editors (not me) working on the Routing article now. If you want to update infomation there in that article feel free. But the merge idea was presented and by consensus was rejected. In my own mind... you need to remember that wiki is not a search engine. So if you get rid of the Routing article 1. you get no results, if you type in routing. 2. If you create a redirect to Router then the use is presented with data that may overwhelm them. Third choice is to create a redirect to the section of the article. Lastly, to leave it seperate. I suggested to leave it seperate, because there were people working on it whilst I was working on Router. The article was in very bad shape when I started and you helped it a great deal as well.

So do you really want nothing to show up when a person types Routing what are your thoughts. The current proposal was to re-write the routing article but to leave it as a stand alone article. Please let me know your thoughts. --User: (talk • contribs • count) 19:23, 29 June 2007 (UTC)

Merge Routing Table with Router
I see you were working on the article Routing table. What would you think about merging this entire article with Routing with a wiki link to the section? In other words the entire article would not be alone any more. The would save the trouble of creating an non-computerish beginning. Let me know your thoughts. Thanks! --User: (talk • contribs • count) 15:50, 2 July 2007 (UTC)


 * I'm afraid I disagree, and still don't like having "Routing" as much more than disambiguation, and, if there is a non-computerish beginning anywhere, it belongs there. "Router" has a reasonably non-computerish beginning. My preferred place for routing table would be under Control Plane, just as forwarding information base is logically under Forwarding Plane. Part of my reasoning here is that there are other, admittedly technical, topics that are logically subordinate to the various planes, such as the RFC2547 Virtual Routing & Forwarding Table (a little misnamed), multicast routing, certain MPLS functions and RSVP path tables under Control.  Forwarding has the FIB, but also adjacency tables, load-sharing, etc.


 * Incidentally, after I did the expansion of core router, I realized that I should probably do a router type list for non-BGP (or mostly non-BGP) environments, such as enterprise (where, in other than the very largest, BGP typically runs on a distribution tier border/edge router) and possibly broadband service provider.


 * Have routing table and forwarding plane earned their way out of stubness?


 * Your article Forwarding Plane is no longer a stub. I need to get the ok for the articles though. I do not want all you excellent work to possibly get deleted. This is why I flagged the Routing table article.  I want to make sure Admins will not have a problem with this. The issue is complex, but it could be argued that the information is more infomation that would be in a text book rather than an enyclopedia. I am looking for someone else to confirm it can be as it is.  If I get the ok.  I will post the answer on your talk page. I dont want you to write articles and then get them deleted, as was done to me.


 * I appreciate your efforts. While, thankfully, I'm no longer a road warrior teaching routing, I did so, on and off, for Cisco and partners for about 16 years (frightening) as well as developing some of the courses. Eventually, I found myself being typecast as a "trainer" rather than an engineer who can teach, but that's another issue.


 * The reason I try to insist on the control and forwarding plane distinction, with the multiple kinds of routing-related tables, is that I have known too many students to be given oversimplified models easy to teach (and easy to test, especially for certification), but very different from the real world. The greatest example of confusing education is the insistence of fitting every protocol in an even-obsolescent-for-OSI OSI reference model. When I've written my books on routing, I felt it my duty to clear up common misconceptions.


 * If it adds any cheer, I once caught myself writing "it will be obvious to the reader that..." When I realized what I had done, I promptly went to stand in front of a mirror and slap my face thoroughly. :-)  Howard C. Berkowitz 18:40, 3 July 2007 (UTC)

Your Invited to Join the Computer Networking Project
If you did not join already. I invite you to join the Networking Project that I am already a member of. WikiProject_Computer_networking just edit the page and add your user name to join. Once you are a member you can ask others to join and hopefully we can work as a team and clean up and expand the networking articles. --User: (talk • contribs • count) 16:29, 3 July 2007 (UTC)


 * Appreciate the invitation, and I'm going to do so now. I think I am under the telecommunication project, but that doesn't seem active. I am recruiting several more people who are both technical experts and excellent writers. Howard C. Berkowitz 18:41, 3 July 2007 (UTC)

Information that is placed in articles
Here is some information to help you with the articles you write. Please remember that Wiki is not the IETF or an rfc or a reference book. If you write an article like it is, it will be deleted and I will not be able to help save it. All I can do as a maintainer is try to help you write the article so it complies with how wiki wants them to be written. They absolutely cannot be written as you would a manual. They cannot have a how to section, or explain in detail how to do something. In other words, lets say you wrote the router article. In it you cannot explain how to set one up. You can only talk about it and how it works. If you want to write details about it, it belongs in, Wikibooks or another wiki for original works. So please be careful. As a maintainer I just cannot just say, its ok to do it, because then another editor will come and say akc9000 is not doing a good job. I have to point out problems. I hope you understand. So here is what an admins says about this...

From my converstation with an admin... Looking at your specific articles, I think they could be kept. Forwarding Plane does read like a manual in some parts. Phrases like "the next step" give it an almost how-to feel and should be rewritten or completely removed. The article is actually quite large for such a specific item, and tends to go off into the history of routers/processing. If you cut it down to just the specifics of the forwarding plane, it will probably have a more encyclopedic tone. If it's still not reading very well, maybe redirect it to Router (or whatever appropriate article) and include a section.


 * Control Plane seems to have the same problem; much of the article focuses on the use/installation/background noise, rather than the actual subject. It's also overly technical. I don't have a clue what "Routers, obviously, have local physical interfaces, and possibly logical subinterfaces, that have addresses in particular IP subnets." means...it's not so obvious. I think you're right that they aren't on a whole encyclopedic, and read like a text-book, but there might be enough information to make a proper article

So please remember that Wiki is not a manual or how to guide. It is not to go into great detail, that is what the cites do.

--User: (talk • contribs • count) 01:49, 4 July 2007 (UTC)

Usenet
Hey, I noticed your name when you commented on the Clonazepam article. Are you the same Howard Berkowitz who regularly posts to usenet? KonradG 20:46, 6 July 2007 (UTC)


 * Probably so, although I've had a lot of USENET connectivity problems and haven't posted in a year or so. — Preceding unsigned comment added by Hcberkowitz (talk • contribs)


 * I didn't participate myself, but I remember your name from some of the newsgroups I occasionally followed. Nice to see you here. KonradG 00:30, 8 July 2007 (UTC)

Virtual Private Network
Compliments for your work on VPN article. Very well written and structured, it was long due. Thank you. Alex Pankratov 06:43, 11 July 2007 (UTC)

Add the source for image
Hey there, could you go ahead and add your source for Image:AIS-USCG-Overview.jpg to the image's description page. It will prevent problems with the image being removed. Thanks. - Davandron | Talk 04:03, 20 July 2007 (UTC)

subnetworks
grateful for comments on Talk:Subnetwork Tjpayne 20:34, 24 July 2007 (UTC)

IPv6 NAT?
Hi. I saw your recent edit comment. Can you give an example of when NAT is needed with IPv6? -- RoySmith (talk) 19:40, 14 August 2007 (UTC)

Router article
If what you say is true, that's all the more reason to remove it&mdash;a lengthy and uncited direct quote would be plagiarism and a likely violation of copyright. It also uses second-person ("you") which our articles don't. If you were to properly attribute it and cite it as a direct quote, however, it certainly might be usable (and the second-person is no issue when we're using a direct quote, of course). Hope that clears things up! Seraphimblade Talk to me 03:03, 29 August 2007 (UTC)
 * Well sure, I'd be happy to! I don't see any issue if it's from your own work, I don't see any possibility of conflict of interest here, and peer-reviewed work is a reliable source even if it was your own. Let me see what I can do with the prose, and then if you can provide the cite that should work perfect. Seraphimblade Talk to me 03:49, 29 August 2007 (UTC)