Re: Last Call: IETF and ITU-T Collaboration Guidelines to Informational
However, what's the point of tying someone to the rails after the train wreck? As a deterrent, I think. Don't misrepresent the ITU position, because they know whom they sent, and you'll blow your credibility in the ITU. /=\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=| |If jumping off a bridge was the industry standard, would you do| |it? | \=/
Re: MPLS issues spam
At 05:58 PM 3/8/02 -0500, Andrew G. Malis wrote: I also completely agree with Randy's point. Posting to IETF lists should be restricted to list participants. The midcom mailing list started out that way but there were some very, very loud complaints from several quarters. Because the whole midcom thing was so contentious to start with I decided to err on the side of openness. Also, one thing that's happening with increasing frequency is that spammers are subscribing bogus addresses to the mailing list, which ups the ante on two fronts: 1) the spam gets through, and 2) I'm getting bounce messages against those addresses. So far the 21st century is not going as well as I'd hoped. Melinda
Re: Last Call: IETF and ITU-T Collaboration Guidelines to Informational
From: John Stracke [EMAIL PROTECTED] However, what's the point of tying someone to the rails after the train wreck? As a deterrent, I think. Don't misrepresent the ITU position, because they know whom they sent, and you'll blow your credibility in the ITU. Those who care enough about their credibility to not misrepresent the ITU position won't misrepresent it whether they are official representatives or not. Those who are swayed by other considerations will, as in that infamous IEEE 802.3 case, be swayed even if they are official representatives. Some people are incapable of foreseeing the possibility that they might be held accountable for what they see as minor fibs or saying what they think they will be able to convince the ITU to do expecially if the IETF has gone that way--again, apparently as in that IEEE 802.3 example. Vernon Schryver[EMAIL PROTECTED]
Re: PPP
That top-layer-calls-next-layer etc ad-nauseam model seems to have been one of the original ideas for how to implement a stack. Actual current implementations do all kinds of wierd stuff, but mostly pass around accumulating collections of buffers; so the payload buffer doesn't get copied to accomodate each new header, instead the kernel has a second buffer to contain the header (and later layers can add more). What gets passed around (by way of various queues and internal plumbing schemes) is a structure of pointers to pieces of packet, which gets put together on transmission, often by the DMA engine in the device or by the device driver. The layering is just a conceptual model for the logic of what is going on, and has no resemblance to the flow of control in a typical actual implementation. There are simple educational implementations that follow the layering fairly closely, and they are interesting to read but tend not to be practical for high performance applications. --On Tuesday, 5 March 2002 11:02 p.m. -0800 Christopher Evans [EMAIL PROTECTED] wrote: Here is a question that will tax your synapes to bursting point! How is PPP and TCP/IP libs wired together? Like, DO I (OSI 8) call TCP and it calls IP and down the chain till it spills over and gets real physical (OSI 1)? I am confused. At 10:02 AM 3/5/02 -0500, you wrote: whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore faster than TCP. They are encapsulated in IP, which is put into the data bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL. - Original Message -
