From ken@funk.com Fri Jan 6 12:53:49 1995 Received: from funk.Funk.COM (funk.terranet.com [199.103.254.41]) by merit.edu (8.6.9/merit-2.0) with ESMTP id MAA22869 for ; Fri, 6 Jan 1995 12:53:47 -0500 Received: from ken.funk.com (machine-133.Funk.COM [198.186.160.133]) by funk.Funk.COM (8.6.5/FUNK-1.2) with SMTP id MAA07279 for ; Fri, 6 Jan 1995 12:56:12 -0500 Date: Fri, 6 Jan 1995 12:56:12 -0500 Message-Id: <199501061756.MAA07279@funk.Funk.COM> X-Sender: ken@funk.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@merit.edu From: ken@funk.com (Ken Culbert) Subject: termination reasons X-Mailer: Does anyone use the data field of Terminate-Request/Terminate-Response packets to indicate termination reasons? If so, is there any consensus on how this is done? Ken Culbert ken@funk.com Funk Software, Inc. voice: (617) 497-6339 222 Third Street fax: (617) 547-1031 Cambridge, MA 02142 From ken@funk.com Mon Jan 9 10:31:58 1995 Received: from funk.Funk.COM (funk.terranet.com [199.103.254.41]) by merit.edu (8.6.9/merit-2.0) with ESMTP id KAA13795 for ; Mon, 9 Jan 1995 10:31:56 -0500 Received: from ken.funk.com (machine-133.Funk.COM [198.186.160.133]) by funk.Funk.COM (8.6.5/FUNK-1.2) with SMTP id KAA02009; Mon, 9 Jan 1995 10:22:54 -0500 Date: Mon, 9 Jan 1995 10:22:54 -0500 Message-Id: <199501091522.KAA02009@funk.Funk.COM> X-Sender: ken@funk.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: klos@mv.mv.com, jgregg@Shiva.com, vjs@sgi.com From: ken@funk.com (Ken Culbert) Subject: Re: termination reasons Cc: ietf-ppp@merit.edu X-Mailer: Ken Culbert (ken@funk.com) writes: >>Does anyone use the data field of Terminate-Request/Terminate-Response >>packets to indicate termination reasons? If so, is there any consensus on >>how this is done? Patrick Klos (klos@mv.mv.com) writes: >I don't know of any implementation that uses the "uninterpreted" data field >of the Terminate-Request/Terminate-Response packets. What are you hoping to >do with this field? Maybe there's a cleaner way to accomplish it? John Gregg (jgregg@Shiva.com) writes: > We use a single byte error code; it is proprietary, agreed on >between our server and client. It is also CP-specific, i.e. 0x03 means >something different on an IPCP TR than it does on an IPXCP TR. Vernon Schryver (vjs@sgi.com) writes: >I've seen various ASCII strings in other vendors' Terminate-Request >packets. So far, they've only been useful for pointing the finger of >blame at the guys who put the text in the packet. I (and I believe others, such as Shiva) are trying to let the other end know why we're terminating the link. Some termination reasons can be determined by the ppp automaton, but it can be desirable to take a short cut and bring down the link immediatly rather than wait for link establishment to fail 'normally'. We and Shiva evidently use numbers for our reasons, while it appears from Vernon's comments that others use text. Perhaps it would be useful for the group to standardize the methodology. Comments? Ken Culbert ken@funk.com Funk Software, Inc. voice: (617) 497-6339 222 Third Street fax: (617) 547-1031 Cambridge, MA 02142 From bill.simpson@um.cc.umich.edu Mon Jan 9 11:48:39 1995 Received: from Bill.Simpson.DialUp.Mich.Net (pm012-12.dialip.mich.net [141.211.7.180]) by merit.edu (8.6.9/merit-2.0) with SMTP id LAA15051 for ; Mon, 9 Jan 1995 11:48:37 -0500 Date: Mon, 9 Jan 95 03:31:07 GMT From: "William Allen Simpson" Message-ID: <3639.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: termination reasons > Does anyone use the data field of Terminate-Request/Terminate-Response > packets to indicate termination reasons? If so, is there any consensus on > how this is done? > I don't. But it can be any binary value. Most likely for debugging, of course. Note that it is not even required to be the same in both directions, unlike Configure-Ack. Don't depend on it being ASCII! This completely implementation dependent. Bill.Simpson@um.cc.umich.edu From vjs@rhyolite.denver.sgi.com Mon Jan 9 14:41:05 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id OAA17926 for ; Mon, 9 Jan 1995 14:41:05 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@merit.edu> id LAA02250; Mon, 9 Jan 1995 11:40:59 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA19209; Mon, 9 Jan 95 11:03:57 -0700 Date: Mon, 9 Jan 95 11:03:57 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501091803.AA19209@rhyolite.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: termination reasons > From: ken@funk.com (Ken Culbert) > ... > I (and I believe others, such as Shiva) are trying to let the other end know > why we're terminating the link. Some termination reasons can be determined > by the ppp automaton, but it can be desirable to take a short cut and bring > down the link immediatly rather than wait for link establishment to fail > 'normally'. We and Shiva evidently use numbers for our reasons, while it > appears from Vernon's comments that others use text. Perhaps it would be > useful for the group to standardize the methodology. Comments? It seems to me there are only the following Terminate Requests: 1. normal, such at the end of a session 2. authentication problems 3. problems on the local machine, such as impossible state machine transitions or bad configurations. There is no reason to include text, a number, or anything else with (1) and (2). (Recall the CHAP and PAP Response and NAK packets have room for strings.) (3) are by definition undesirable, and so had better be infrequent. They are most likely to occur when soemthing is misconfigured. I've most often seen reports of strange text in terminate-requests from peers after installation of new firmware or configuration changes in router boxes. It is unlikely to be possible to make a useful standard for terminate request reasons codes. Anything that you might standardize should be prevented, making the standard irrelevant. Numbers are useless unless you have the magic decoder ring that translates them into something a human can understand or at least guess about. You are most likely care about an unusual terminate-request reason exactly when you do not have the magic decoder ring. For example, I have no decoder rings but my own, but I am more likely to see and care about some other vendor's mysterious text than my own. I've probably seen some binary numbers in other guy's terminate requests, and did not realize they were anything except garbage that should not have been transmitted.. In other words, the ancient IBM practice of using numbers for error messages was reasonable when even disk space was too valuable to spend on English messages, but it is at best counter productive in these days of Mbit EEPROMs. Vernon Schryver, vjs@sgi.com From gurdeep@microsoft.com Mon Jan 9 15:24:48 1995 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.9/merit-2.0) with SMTP id PAA18784; Mon, 9 Jan 1995 15:24:47 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA23762; Mon, 9 Jan 95 12:25:13 -0800 Message-Id: <9501092025.AA23762@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Mon, 09 Jan 95 12:25:12 PST X-Msmail-Message-Id: 58CF7085 X-Msmail-Conversation-Id: 58CF7085 From: Gurdeep Singh Pall To: ietf-ppp-request@MERIT.EDU, jgregg@Shiva.com, klos@mv.mv.com, vjs@sgi.com Date: Mon, 9 Jan 95 12:18:48 TZ Subject: Re: termination reasons Cc: ietf-ppp@MERIT.EDU I disagree that this field only has "debugging" value. Like Ken and others mention below there are some valid reasons that would be useful if communicated at time of termination - especially from a usability/feedback standpoint. IMHO, we should make disconnect reasons more concrete (at least the ones common to most implementations). How about changing the data field to be something like - 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | Data +-+-+-+-+-+-+-+-+-+-+-+ Reason 0 disconnection due to idle timeout 1 disconnection due to administrator request 2 disconnection due to user request 3 disconnection due to network condition (???) 4 <------ your favorite reason goes here etc. Data same as before. This allows for numbers for the standard reasons while allowing a free format non-standard data field for ASCII/EBCDIC/UNICODE/? strings. Comments? gurdeep@microsoft.com ---------- | From: Ken Culbert | To: ; ; | Cc: | Subject: Re: termination reasons | Date: Monday, January 09, 1995 10:22AM | | Received: from merit.edu by netmail.microsoft.com with SMTP (5.65/25-eef) | id AA01010; Mon, 9 Jan 95 07:35:16 -0800 | Received: (from slist@localhost) by merit.edu | (8.6.9/merit-2.0) id KAA13820; Mon, 9 Jan 1995 10:32:11 -0500 | Resent-Date: Mon, 9 Jan 1995 10:32:11 -0500 | Message-Id: <199501091522.KAA02009@funk.Funk.COM> | X-Sender: ken@funk.com | Mime-Version: 1.0 | Content-Type: text/plain; charset="us-ascii" | X-Mailer: | Resent-Message-Id: <"j30cW2.0.lN3.mRL4l"@merit.edu> | Resent-From: ietf-ppp@MERIT.EDU | X-Mailing-List: archive/latest/2 | X-Loop: ietf-ppp@MERIT.EDU | Precedence: list | Resent-Sender: ietf-ppp-request@MERIT.EDU | | Ken Culbert (ken@funk.com) writes: | >>Does anyone use the data field of Terminate-Request/Terminate-Response | >>packets to indicate termination reasons? If so, is there any consensus on | >>how this is done? | | Patrick Klos (klos@mv.mv.com) writes: | >I don't know of any implementation that uses the "uninterpreted" data field | >of the Terminate-Request/Terminate-Response packets. What are you hoping to | >do with this field? Maybe there's a cleaner way to accomplish it? | | | John Gregg (jgregg@Shiva.com) writes: | > We use a single byte error code; it is proprietary, agreed on | >between our server and client. It is also CP-specific, i.e. 0x03 means | >something different on an IPCP TR than it does on an IPXCP TR. | | | Vernon Schryver (vjs@sgi.com) writes: | >I've seen various ASCII strings in other vendors' Terminate-Request | >packets. So far, they've only been useful for pointing the finger of | >blame at the guys who put the text in the packet. | | | I (and I believe others, such as Shiva) are trying to let the other end know | why we're terminating the link. Some termination reasons can be determined | by the ppp automaton, but it can be desirable to take a short cut and bring | down the link immediatly rather than wait for link establishment to fail | 'normally'. We and Shiva evidently use numbers for our reasons, while it | appears from Vernon's comments that others use text. Perhaps it would be | useful for the group to standardize the methodology. Comments? | | Ken Culbert ken@funk.com | Funk Software, Inc. voice: (617) 497-6339 | 222 Third Street fax: (617) 547-1031 | Cambridge, MA 02142 | | From vjs@rhyolite.denver.sgi.com Mon Jan 9 15:52:53 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id PAA19304 for ; Mon, 9 Jan 1995 15:52:52 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@MERIT.EDU> id MAA29437; Mon, 9 Jan 1995 12:52:46 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@MERIT.EDU id AA20156; Mon, 9 Jan 95 13:52:10 -0700 Date: Mon, 9 Jan 95 13:52:10 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501092052.AA20156@rhyolite.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: termination reasons > From: Gurdeep Singh Pall > To: ietf-ppp-request@MERIT.EDU, jgregg@Shiva.com, klos@mv.mv.com, Why send to ietf-ppp-request@merit.edu? > vjs@sgi.sgi.com > Date: Mon, 9 Jan 95 12:18:48 TZ > Subject: Re: termination reasons > Cc: ietf-ppp@MERIT.EDU > > > I disagree that this field only has "debugging" value. Like Ken and > others mention below there are some valid reasons that would be useful > if communicated at time of termination - especially from a > usability/feedback standpoint. What kind of "usability" would it be for a PPP implementation to tell the user "disconnection due to idle timeout" on every such disconnection? Imagine having your WINSOCK PPP babble such stuff every few seconds as your ISDN link comes and goes. Except when debugging, such messages will <> be hidden, usually discarded, and at most recorded in a log with a short rotation time. There is absolutely no assurance that a Terminate-Request will reach the peer before the link goes down. No implementation can make any assumptions about the contents of a Terminate-Request, because the packets themselves are unreliable. > IMHO, we should make disconnect reasons more concrete (at least the > ones common to most implementations). > > How about changing the data field to be something like - > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code | Identifier | > Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reason | Data > +-+-+-+-+-+-+-+-+-+-+-+ > > Reason > 0 disconnection due to idle timeout > 1 disconnection due to administrator request > 2 disconnection due to user request > 3 disconnection due to network condition (???) > 4 <------ your favorite reason goes here > etc. > Data > same as before. > > This allows for numbers for the standard reasons while allowing a free > format non-standard data field for ASCII/EBCDIC/UNICODE/? strings. Now that you mention it, it might make good sense even in my code to stick in a message saying "idle timeout" or whatever. However, I strongly disagree with the other conclusions above. EBCDIC is a non-starter. PPP messages such as those for authentication are required to be in ASCII, so there is no profit in encouraging obsolete and obscure character sets. (I've probably written more ASCII-EBCDIC and more differing conversion tables than many people, and so I feel permitted to denigrate EBCIDIC.) If "disconnection due to idle timeout" were to be a standardized reason, then make the "reason" be that ASCII string. There is no profit in converting a perfectly readable ASCII string into 8 bits of mysterious, useless cybercrud. The only time anyone will ever care about these messages is when something goes wrong, when someone is staring at packet traces. That is exactly when you want self-describing packets. In any case, such messages must not be standardized. There are too many installation and implementation dependent variations. For example, (I think) MorningStar has 3 different idle timeout timers and so we would need at least 3 different "idle timeout" messages. I have 2 different timers; probably sufficiently different from MorningStar's to require 1 or 2 more messages. So we would need a message/reason registry! There is no profit writing an elaborate standard for these messages. Those of us who care will craft ASCII, UNICODE, or whatever messages that describe our situations. The rest will not. The market will decide. This is an old argument. Standards do not and must not attempt to define absolutely every detail. Standards can only try to control things that affect interoperability. There is no way in which a Terminate-Request reason might affect the interoperability of reasonable implementations. A networking standard is not and should not try to be a functional specification. It seems many in the PPP community with whom I've argued about compression, multi-linking, and so forth would like the PPP standards to be complete functional specifications. I think that is very wrong. Vernon Schryver, vjs@sgi.com From ken@funk.com Mon Jan 9 17:12:48 1995 Received: from funk.Funk.COM (funk.terranet.com [199.103.254.41]) by merit.edu (8.6.9/merit-2.0) with ESMTP id RAA20660 for ; Mon, 9 Jan 1995 17:12:44 -0500 Received: from ken.funk.com (machine-133.Funk.COM [198.186.160.133]) by funk.Funk.COM (8.6.5/FUNK-1.2) with SMTP id RAA03470; Mon, 9 Jan 1995 17:02:52 -0500 Date: Mon, 9 Jan 1995 17:02:52 -0500 Message-Id: <199501092202.RAA03470@funk.Funk.COM> X-Sender: ken@funk.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: vjs@rhyolite.denver.sgi.com, gurdeep@microsoft.com From: ken@funk.com (Ken Culbert) Subject: Re: termination reasons Cc: ietf-ppp@merit.edu X-Mailer: Gurdeep Singh Pall writes: >> I disagree that this field only has "debugging" value. Like Ken and >> others mention below there are some valid reasons that would be useful >> if communicated at time of termination - especially from a >> usability/feedback standpoint. Vernon Schryver (vjs@rhyolite.sgi.com) writes: >What kind of "usability" would it be for a PPP implementation to >tell the user "disconnection due to idle timeout" on every such >disconnection? Imagine having your WINSOCK PPP babble such stuff >every few seconds as your ISDN link comes and goes. Implementations are not compelled to babble. Presumably, an ISDN implementation would suppress such messages. >Except when debugging, such messages will <> be hidden, usually >discarded, and at most recorded in a log with a short rotation time. > >There is absolutely no assurance that a Terminate-Request will reach >the peer before the link goes down. No implementation can make any >assumptions about the contents of a Terminate-Request, because the >packets themselves are unreliable. A bad packet will be discarded. A lost termination message leaves us no worse off than none. >> IMHO, we should make disconnect reasons more concrete (at least the >> ones common to most implementations). >> >> How about changing the data field to be something like - >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Code | Identifier | >> Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reason | Data >> +-+-+-+-+-+-+-+-+-+-+-+ >> >> Reason >> 0 disconnection due to idle timeout >> 1 disconnection due to administrator request >> 2 disconnection due to user request >> 3 disconnection due to network condition (???) >> 4 <------ your favorite reason goes here >> etc. >> Data >> same as before. >> >> This allows for numbers for the standard reasons while allowing a free >> format non-standard data field for ASCII/EBCDIC/UNICODE/? strings. > >Now that you mention it, it might make good sense even in my code to >stick in a message saying "idle timeout" or whatever. > > >However, I strongly disagree with the other conclusions above. EBCDIC >is a non-starter. PPP messages such as those for authentication are >required to be in ASCII, so there is no profit in encouraging obsolete >and obscure character sets. (I've probably written more ASCII-EBCDIC >and more differing conversion tables than many people, and so I feel >permitted to denigrate EBCIDIC.) > >If "disconnection due to idle timeout" were to be a standardized >reason, then make the "reason" be that ASCII string. There is no >profit in converting a perfectly readable ASCII string into 8 bits of >mysterious, useless cybercrud. The only time anyone will ever care >about these messages is when something goes wrong, when someone is >staring at packet traces. That is exactly when you want >self-describing packets. I think users can find the information helpful. As for requiring ASCII (presumably English) strings, what about internationalization? >In any case, such messages must not be standardized. There are too >many installation and implementation dependent variations. For >example, (I think) MorningStar has 3 different idle timeout timers and >so we would need at least 3 different "idle timeout" messages. I have >2 different timers; probably sufficiently different from MorningStar's >to require 1 or 2 more messages. So we would need a message/reason >registry! >There is no profit writing an elaborate standard for these messages. >Those of us who care will craft ASCII, UNICODE, or whatever messages >that describe our situations. The rest will not. The market will >decide. > >This is an old argument. Standards do not and must not attempt to >define absolutely every detail. Standards can only try to control >things that affect interoperability. There is no way in which a >Terminate-Request reason might affect the interoperability of >reasonable implementations. A networking standard is not and should >not try to be a functional specification. It seems many in the PPP >community with whom I've argued about compression, multi-linking, and >so forth would like the PPP standards to be complete functional >specifications. I think that is very wrong. IMHO, kinder and gentler interoperability includes useful diagnostic capabilities. I don't think it's necessary to go to extremes with this, but it might be beneficial for implementors to agree on a few common termination reasons. For example, here are the ones we use: // terminate reasons #define UNDEFINED 0 #define BAD_NODE_ADDR 1 // invalid IPX address #define FAILED_AUTHEN 2 #define TERM_TIMEOUT 3 // no response from peer #define INVALID_CONFIG 4 #define LINK_STOPPED 5 // network layer negotiation failed #define USER_REQUEST 6 #define CALLINGBACK 7 #define NO_PORTS 8 // no ports available on server #define NOT_DIAL_IN 9 // not a valid dial-in port #define FORCED 10 // forced by administrator #define BAD_NETWORK_NO 11 // invalid IPX network number #define FAILED_NODEID 12 #define BAD_MAGIC 13 // bad magic # (crossed connection) #define NOT_PAID 14 // wrong type of client #define NO_LICENSE 15 #define DATABASE_ERROR 16 #define TIME_EXPIRED 17 Some of these don't apply to other implementations; some do. The point is that users find them useful when using our products, and some standardization would make their lives easier when using supposedly 'interoperable' products. So, as I see it, the choices are: 1) do nothing and live with a hodge-podge of incompatible messages/reasons 2) publish an informational/suggested list of numeric and/or text reasons 3) mandate the messages Personally, I prefer 2). Ken Culbert ken@funk.com Funk Software, Inc. voice: (617) 497-6339 222 Third Street fax: (617) 547-1031 Cambridge, MA 02142 From gurdeep@microsoft.com Mon Jan 9 17:24:17 1995 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.9/merit-2.0) with SMTP id RAA20940; Mon, 9 Jan 1995 17:24:16 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA03818; Mon, 9 Jan 95 14:24:41 -0800 Message-Id: <9501092224.AA03818@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Mon, 09 Jan 95 14:24:41 PST X-Msmail-Message-Id: C8AFF48A X-Msmail-Conversation-Id: C8AFF48A From: Gurdeep Singh Pall To: ietf-ppp@MERIT.EDU, ietf-ppp-request@MERIT.EDU Date: Mon, 9 Jan 95 14:17:06 TZ Subject: Re: termination reasons 1. IMHO it makes sense to inform the user that their link was blown away because of an idle timeout as opposed to a bug/crash on the server - some internet providers will appreciate not having to answer support calls from a irate (and novice) user. You can hide this in your implementation if you want - especially if your feedback appears as "babble .... every few seconds" to the user. Of course why you should re-negotiate lcp & ncps every few seconds over isdn - is another matter. 2. If the terminate packets provided "useful" information to indicate a reason for disconnection - implementations might even try harder to deliver/receive them. 3. The ASCII string idea is bad. In today's global community - the idea of picking up a string from the request and displaying it, doesnt work. IMHO reserved numbers with clear semantics works better than ASCII blurbs - since, in a global sense both are "bits of mysterious, useless cybercrud". 4. Please don't feel compelled to interoperate - the free format data field should remain for proprietary schemes. gurdeep@microsoft.com ---------- | From: Vernon Schryver | To: | Subject: Re: termination reasons | Date: Monday, January 09, 1995 1:52PM | | Received: from merit.edu by netmail.microsoft.com with SMTP (5.65/25-eef) | id AA26385; Mon, 9 Jan 95 12:57:24 -0800 | Received: (from slist@localhost) by merit.edu | (8.6.9/merit-2.0) id PAA19323; Mon, 9 Jan 1995 15:52:57 -0500 | Resent-Date: Mon, 9 Jan 1995 15:52:57 -0500 | Message-Id: <9501092052.AA20156@rhyolite.denver.sgi.com> | Resent-Message-Id: <"6uAxg1.0.lj4.d8Q4l"@merit.edu> | Resent-From: ietf-ppp@MERIT.EDU | X-Mailing-List: archive/latest/6 | X-Loop: ietf-ppp@MERIT.EDU | Precedence: list | Resent-Sender: ietf-ppp-request@MERIT.EDU | | > From: Gurdeep Singh Pall | > To: ietf-ppp-request@MERIT.EDU, jgregg@Shiva.com, klos@mv.mv.com, | | Why send to ietf-ppp-request@merit.edu? | | > vjs@sgi.sgi.com | > Date: Mon, 9 Jan 95 12:18:48 TZ | > Subject: Re: termination reasons | > Cc: ietf-ppp@MERIT.EDU | > | > | > I disagree that this field only has "debugging" value. Like Ken and | > others mention below there are some valid reasons that would be useful | > if communicated at time of termination - especially from a | > usability/feedback standpoint. | | What kind of "usability" would it be for a PPP implementation to | tell the user "disconnection due to idle timeout" on every such | disconnection? Imagine having your WINSOCK PPP babble such stuff | every few seconds as your ISDN link comes and goes. | | Except when debugging, such messages will <> be hidden, usually | discarded, and at most recorded in a log with a short rotation time. | | There is absolutely no assurance that a Terminate-Request will reach | the peer before the link goes down. No implementation can make any | assumptions about the contents of a Terminate-Request, because the | packets themselves are unreliable. | | | | > IMHO, we should make disconnect reasons more concrete (at least the | > ones common to most implementations). | > | > How about changing the data field to be something like - | > | > 0 1 2 3 | > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Code | Identifier | | > Length | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Reason | Data | > +-+-+-+-+-+-+-+-+-+-+-+ | > | > Reason | > 0 disconnection due to idle timeout | > 1 disconnection due to administrator request | > 2 disconnection due to user request | > 3 disconnection due to network condition (???) | > 4 <------ your favorite reason goes here | > etc. | > Data | > same as before. | > | > This allows for numbers for the standard reasons while allowing a free | > format non-standard data field for ASCII/EBCDIC/UNICODE/? strings. | | Now that you mention it, it might make good sense even in my code to | stick in a message saying "idle timeout" or whatever. | | | However, I strongly disagree with the other conclusions above. EBCDIC | is a non-starter. PPP messages such as those for authentication are | required to be in ASCII, so there is no profit in encouraging obsolete | and obscure character sets. (I've probably written more ASCII-EBCDIC | and more differing conversion tables than many people, and so I feel | permitted to denigrate EBCIDIC.) | | If "disconnection due to idle timeout" were to be a standardized | reason, then make the "reason" be that ASCII string. There is no | profit in converting a perfectly readable ASCII string into 8 bits of | mysterious, useless cybercrud. The only time anyone will ever care | about these messages is when something goes wrong, when someone is | staring at packet traces. That is exactly when you want | self-describing packets. | | In any case, such messages must not be standardized. There are too | many installation and implementation dependent variations. For | example, (I think) MorningStar has 3 different idle timeout timers and | so we would need at least 3 different "idle timeout" messages. I have | 2 different timers; probably sufficiently different from MorningStar's | to require 1 or 2 more messages. So we would need a message/reason | registry! | | | There is no profit writing an elaborate standard for these messages. | Those of us who care will craft ASCII, UNICODE, or whatever messages | that describe our situations. The rest will not. The market will | decide. | | This is an old argument. Standards do not and must not attempt to | define absolutely every detail. Standards can only try to control | things that affect interoperability. There is no way in which a | Terminate-Request reason might affect the interoperability of | reasonable implementations. A networking standard is not and should | not try to be a functional specification. It seems many in the PPP | community with whom I've argued about compression, multi-linking, and | so forth would like the PPP standards to be complete functional | specifications. I think that is very wrong. | | | Vernon Schryver, vjs@sgi.com | | From vjs@rhyolite.denver.sgi.com Mon Jan 9 18:41:33 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id SAA21810 for ; Mon, 9 Jan 1995 18:41:32 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@merit.edu> id PAA29655; Mon, 9 Jan 1995 15:41:26 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA21028; Mon, 9 Jan 95 16:40:48 -0700 Date: Mon, 9 Jan 95 16:40:48 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501092340.AA21028@rhyolite.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: termination reasons > From: ken@funk.com (Ken Culbert) > ... > >What kind of "usability" would it be for a PPP implementation to > >tell the user "disconnection due to idle timeout" on every such > >disconnection? Imagine having your WINSOCK PPP babble such stuff > >every few seconds as your ISDN link comes and goes. > > Implementations are not compelled to babble. Presumably, an ISDN > implementation would suppress such messages. If the messages are suppressed normally, then as I claim, they can only be used during debugging. Even a simple, v.32 modem interface would not want to bother users with "disconnection due to idle timeout" messages except when the link is being debugged. You soon turn off the modem squawks if you regularly use demand-dialed PPP. I suspect people are thinking of these messages only for a new PPP installation, instead of for an installation that has been running for months. Or perhaps PPP used by the infrequent user, in some kind of TIA mode. Then such messages are interesting, for debugging. > ... > I think users can find the information helpful. As for requiring ASCII > (presumably English) strings, what about internationalization? How is 0x1 more international than "Bad Node ADDR" in ASCII? That the first is an arbitrary 8-bit number while the second is an arbitrary 104-bit number is irrelevant. The 104-bit number has nmemonic significance for perhaps 1000 million people (assuming they guess what a "Node ADDR" is), while the 8-bit number has meaning for at most 100's of people. Don't you use things like 0xbadf00d for uninitialized pointers, despite their lack of "language independence"? It is not significantly more difficult to convert the string "BAD_NODE_ADDR" to a translation of "invalid IPX address" than the number 0x1, if such translating is worthwhile in either case. To be helpful to users, information must make sense to them when they see it, not just when they look up what they remember. "ABEND 1234" has been an infamous bad joke for 25 or 30 years for very good reasons. The first rule of debugging anything is that users do not perceive, not to mention remember, messages that they do not understand. "Failure 1234" is reported as "Failure," if it is reported at all. Incomprehensible messages are usually not even perceived. > ... > IMHO, kinder and gentler interoperability includes useful diagnostic > capabilities. I don't think it's necessary to go to extremes with this, but > it might be beneficial for implementors to agree on a few common termination > reasons. For example, here are the ones we use: > > // terminate reasons > #define UNDEFINED 0 > #define BAD_NODE_ADDR 1 // invalid IPX address > #define FAILED_AUTHEN 2 > ... > Some of these don't apply to other implementations; some do. The point is > that users find them useful when using our products, and some > standardization would make their lives easier when using supposedly > 'interoperable' products. Users would find them even more useful if you used "FAILED_AUTHEN" or even "Authentication Failure" instead of 0x02. In this context, the extra bits are free. > So, as I see it, the choices are: > 1) do nothing and live with a hodge-podge of incompatible messages/reasons > 2) publish an informational/suggested list of numeric and/or text reasons > 3) mandate the messages > > Personally, I prefer 2). To publish such a list, you'll need far more text. You'll need to define what kinds of ivalidity generates BAD_NODE_ADDR, and you'll need to define IPX addresses and "NODEID". If you only publish a list, unadorned with 100's words of explanation per message, then why not just "publish" the messages only in your code and your Terminate-Request packets? If the only information that exists about BAD_NODE_ADDR is "invalid IPX address" (written in non-international English ASCII in an RFC somewhere), there is no profit in compiling a list. Simply put the string "invalid IPX address" in your Terminate-Request. What if another vendor wants to distinguish different kinds of IPX address invalidity and inform users with a more varied choice of message? Would you like to have to change your code to support more varieties of that message? Or would you feel comfortable prohibiting the more precise information? I oppose (2) and (3) because I do not want to spend weeks now arguing about which messages belong in the list and what each should cover and whether any pair overlaps, or the rest of my career arguing with users whether BAD_NODE_ADDR should or should not apply to a failure to negotiate IP addresses, or whether or not including or not including 0x1 in a Termination-Request after 11 IPCP NAKs is a Failure To Comply with An Official Informational IETF RFC. Vernon Schryver, vjs@sgi.com From ken@funk.com Tue Jan 10 10:07:24 1995 Received: from funk.Funk.COM (funk.terranet.com [199.103.254.41]) by merit.edu (8.6.9/merit-2.0) with ESMTP id KAA28046 for ; Tue, 10 Jan 1995 10:07:22 -0500 Received: from ken.funk.com (machine-133.Funk.COM [198.186.160.133]) by funk.Funk.COM (8.6.5/FUNK-1.2) with SMTP id JAA05180 for ; Tue, 10 Jan 1995 09:59:20 -0500 Date: Tue, 10 Jan 1995 09:59:20 -0500 Message-Id: <199501101459.JAA05180@funk.Funk.COM> X-Sender: ken@funk.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@merit.edu From: ken@funk.com (Ken Culbert) Subject: Re: termination reasons X-Mailer: Let's back up a step or 2. My initial posting had 2 questions; the first was: 'Does anyone use the data field of Terminate-Request/Terminate-Response packets to indicate termination reasons?' The response was affirmative. The next question was: 'If so, is there any consensus on how this is done?' The response seems to be negative. Now, the next logical question (IMHO) is: 'Do we want to develop a consensus?' If the answer to this question is negative, ok, case closed. Otherwise, we should discuss the merits of interoperability, and THEN the methodology. If the list doesn't take up the issue (which I can entertain may be not be worthwhile), then it is possible that either a subset of the group will come up with a closed consensus or that an influential implementor will put a proprietary method in place, which will become a defacto standard. The problem with the first case is that it goes against the purpose of the list (as I understand it), the problem with the second is that extensions to the proprietary standard will crop up -- anyone familiar with 'Hayes-compatible modems' knows what I'm talking about ;) . So, let's continue, and consider if interoperability is desirable: .... >If the messages are suppressed normally, then as I claim, they >can only be used during debugging. >I suspect people are thinking of these messages only for a new PPP >installation, instead of for an installation that has been running for >months. Or perhaps PPP used by the infrequent user, in some kind of >TIA mode. Then such messages are interesting, for debugging. Specific, expected messages could be suppressed. You are correct in stating that the messages of most interest are those affecting initial connections, but I don't see that that argues against developing a consensus about the messages. >What if another vendor wants to distinguish different kinds of IPX >address invalidity and inform users with a more varied choice of >message? Would you like to have to change your code to support more >varieties of that message? Or would you feel comfortable prohibiting >the more precise information? There are several ways that the details of specifity vs. generality could be dealt with. Does the fact that such a difficulty exists preclude trying to develop a consensus? .... >I oppose (2) and (3) because I do not want to spend weeks now arguing >about which messages belong in the list and what each should cover and >whether any pair overlaps, or the rest of my career arguing with users >whether BAD_NODE_ADDR should or should not apply to a failure to >negotiate IP addresses, or whether or not including or not including >0x1 in a Termination-Request after 11 IPCP NAKs is a Failure To Comply >with An Official Informational IETF RFC. If we can't come up with a simple, extensible consensus, we should drop the issue. Ken Culbert ken@funk.com Funk Software, Inc. voice: (617) 497-6339 222 Third Street fax: (617) 547-1031 Cambridge, MA 02142 From gurdeep@microsoft.com Tue Jan 10 14:10:58 1995 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.9/merit-2.0) with SMTP id OAA01388; Tue, 10 Jan 1995 14:10:56 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA15767; Tue, 10 Jan 95 11:11:21 -0800 Message-Id: <9501101911.AA15767@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 10 Jan 95 11:11:20 PST X-Msmail-Message-Id: 96A177AA X-Msmail-Conversation-Id: 96A177AA From: Gurdeep Singh Pall To: ietf-ppp@MERIT.EDU, ietf-ppp-request@MERIT.EDU Date: Tue, 10 Jan 95 11:07:06 TZ Subject: Re: termination reasons 1. The complexity of this enhancement is being greatly exaggerated. If this forum can nail broader specs like LCP, why you think common termination reasons cannot be standardized? 2. Again, I think the ASCII string idea is BAD. If the string cannot be displayed directly to the user - as is the case for all globally selling implementations - then it is of NO use. It only takes longer to xmit, wastes memory, takes more cpu to compare, etc. You are missing the point here. If a number is sent as termination reason you dont have to display it to the user - just because you were displaying the reason string in your previous implementations. You might consider passing the number through the "decoder rings" in your implementation (mentioned in your earlier mail). 3. Also, I don't really care if you like the idea of displaying a "idle time disconnect" message or not. The question is - should this information be communicated between peers in a standard way? gurdeep@microsoft.com ---------- | From: Vernon Schryver | To: | Subject: Re: termination reasons | Date: Monday, January 09, 1995 4:40PM | || > From: ken@funk.com (Ken Culbert) | | > ... | > >What kind of "usability" would it be for a PPP implementation to | > >tell the user "disconnection due to idle timeout" on every such | > >disconnection? Imagine having your WINSOCK PPP babble such stuff | > >every few seconds as your ISDN link comes and goes. | > | > Implementations are not compelled to babble. Presumably, an ISDN | > implementation would suppress such messages. | | | If the messages are suppressed normally, then as I claim, they | can only be used during debugging. | | Even a simple, v.32 modem interface would not want to bother users | with "disconnection due to idle timeout" messages except when the link | is being debugged. You soon turn off the modem squawks if you regularly | use demand-dialed PPP. | | I suspect people are thinking of these messages only for a new PPP | installation, instead of for an installation that has been running for | months. Or perhaps PPP used by the infrequent user, in some kind of | TIA mode. Then such messages are interesting, for debugging. | | | > ... | > I think users can find the information helpful. As for requiring ASCII | > (presumably English) strings, what about internationalization? | | How is 0x1 more international than "Bad Node ADDR" in ASCII? That the | first is an arbitrary 8-bit number while the second is an arbitrary | 104-bit number is irrelevant. The 104-bit number has nmemonic | significance for perhaps 1000 million people (assuming they guess what | a "Node ADDR" is), while the 8-bit number has meaning for at most | 100's of people. Don't you use things like 0xbadf00d for uninitialized | pointers, despite their lack of "language independence"? | | It is not significantly more difficult to convert the string | "BAD_NODE_ADDR" to a translation of "invalid IPX address" than the | number 0x1, if such translating is worthwhile in either case. | | | To be helpful to users, information must make sense to them when they | see it, not just when they look up what they remember. "ABEND 1234" has | been an infamous bad joke for 25 or 30 years for very good reasons. | The first rule of debugging anything is that users do not perceive, not | to mention remember, messages that they do not understand. | "Failure 1234" is reported as "Failure," if it is reported at all. | Incomprehensible messages are usually not even perceived. | | | > ... | > IMHO, kinder and gentler interoperability includes useful diagnostic | > capabilities. I don't think it's necessary to go to extremes with this, but | > it might be beneficial for implementors to agree on a few common termination | > reasons. For example, here are the ones we use: | > | > // terminate reasons | > #define UNDEFINED 0 | > #define BAD_NODE_ADDR 1 // invalid IPX address | > #define FAILED_AUTHEN 2 | | > ... | > Some of these don't apply to other implementations; some do. The point is | > that users find them useful when using our products, and some | > standardization would make their lives easier when using supposedly | > 'interoperable' products. | | Users would find them even more useful if you used "FAILED_AUTHEN" | or even "Authentication Failure" instead of 0x02. In this context, | the extra bits are free. | | | > So, as I see it, the choices are: | > 1) do nothing and live with a hodge-podge of incompatible messages/reasons | > 2) publish an informational/suggested list of numeric and/or text reasons | > 3) mandate the messages | > | > Personally, I prefer 2). | | | To publish such a list, you'll need far more text. You'll need to | define what kinds of ivalidity generates BAD_NODE_ADDR, and you'll need | to define IPX addresses and "NODEID". | | If you only publish a list, unadorned with 100's words of explanation | per message, then why not just "publish" the messages only in your code | and your Terminate-Request packets? If the only information that | exists about BAD_NODE_ADDR is "invalid IPX address" (written in | non-international English ASCII in an RFC somewhere), there is no | profit in compiling a list. Simply put the string "invalid IPX | address" in your Terminate-Request. | | What if another vendor wants to distinguish different kinds of IPX | address invalidity and inform users with a more varied choice of | message? Would you like to have to change your code to support more | varieties of that message? Or would you feel comfortable prohibiting | the more precise information? | | I oppose (2) and (3) because I do not want to spend weeks now arguing | about which messages belong in the list and what each should cover and | whether any pair overlaps, or the rest of my career arguing with users | whether BAD_NODE_ADDR should or should not apply to a failure to | negotiate IP addresses, or whether or not including or not including | 0x1 in a Termination-Request after 11 IPCP NAKs is a Failure To Comply | with An Official Informational IETF RFC. | | | Vernon Schryver, vjs@sgi.com | | From bill.simpson@um.cc.umich.edu Tue Jan 10 15:31:17 1995 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-03.dialip.mich.net [141.211.7.139]) by merit.edu (8.6.9/merit-2.0) with SMTP id PAA02426 for ; Tue, 10 Jan 1995 15:31:14 -0500 Date: Tue, 10 Jan 95 19:40:42 GMT From: "William Allen Simpson" Message-ID: <3670.bill.simpson@um.cc.umich.edu> To: ietf-ppp@MERIT.EDU Reply-to: bsimpson@morningstar.com Subject: Re: termination reasons I hate to admit it, but I emphatically agree with Vernon on this one. Here we have one example of where the group wanted an incompletely specified field, so that various implementors could use it however they desired, and so that developers in other languages wouldn't be stuck with US ASCII. Now, some folks want to nail down even this detail, which is primarily for debugging (people running packet traces). > From: ken@funk.com (Ken Culbert) > Now, the next logical question (IMHO) is: 'Do we want to develop a consensus?' > > If the answer to this question is negative, ok, case closed. > Otherwise, we should discuss the merits of interoperability, and THEN the > methodology. > Three problems: 1) There are already 40 odd vendors who don't follow any particular scheme. It is very unlikely that anyone will bother to deploy a new version to be compatible with whatever someone asks for at this late date. 2) PPP is a peer to peer, not client server. Anything you define has to be useful for two routers, not just some client dialer. 3) Even in a client, you certainly don't want to stop and display some user visible message when the link terminates. I already hate it when MacPPP puts up that dialog box when it dials out. > So, let's continue, and consider if interoperability is desirable: > > Specific, expected messages could be suppressed. You are correct in stating > that the messages of most interest are those affecting initial connections, > but I don't see that that argues against developing a consensus about the > messages. > Such messages shouldn't _EVER_ be displayed unless the user is experiencing a problem! And at that time, the user hopefully has a hand-holder which is stepping through the problem. How do we know that it is an "initial" connection? Why would I want a user message at termination, when my machine auto-dials out for email in the middle of the night? > If we can't come up with a simple, extensible consensus, we should drop the > issue. > Worse, if we can't come up with a consensus which successfully interoperates with _every_ previously deployed version of PPP, we should drop the issue. Remember, your peer is _not_ likely to be the same code as your local implementation. Bill.Simpson@um.cc.umich.edu From karl@MorningStar.Com Tue Jan 10 15:31:26 1995 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.9/merit-2.0) with SMTP id PAA02448 for ; Tue, 10 Jan 1995 15:31:21 -0500 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA09864; Tue, 10 Jan 95 15:30:42 -0500 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA09120; Tue, 10 Jan 95 15:30:41 -0500 Date: Tue, 10 Jan 95 15:30:41 -0500 Message-Id: <9501102030.AA09120@gefilte.MorningStar.Com> To: Gurdeep Singh Pall Cc: ietf-ppp@MERIT.EDU Subject: Re: termination reasons In-Reply-To: <9501101911.AA15767@netmail2.microsoft.com> References: <9501101911.AA15767@netmail2.microsoft.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Gurdeep Singh Pall writes: > 2. Again, I think the ASCII string idea is BAD. I, and others, think it's not only not bad, but that it's the best possible choice. > If the string cannot be displayed directly to the user - as is the > case for all globally selling implementations - then it is of NO > use. I, and others, disagree. The most likely use of such data is while debugging a dial-up connection, when it is usually easy to see the contents of packets. I'm not likely to notice an extra 03 on a Terminate-Request packet, nor will I be able to figure out what it means if I do notice it. If I see the ASCII characters `Idle timeout' in the Terminate-Request data field, I immediately know what it means, and I am likely to notice it when examining the Terminate-Request. > It only takes longer to xmit, wastes memory, takes more cpu to > compare, etc. Insignificantly so. Remember, PPP sessions rarely contain many Terminate-Request packets. :-) Keep in mind, folks, that we will *never* be able to rely on the semantic contents of the Terminate-Request data field. There are too many implementations extant, even if we were all to reach perfect consensus today. It *is* possible, however, to notice whether the data field is a printable ASCII string. `Idle timeout' is printable and interpretable (at least by humans); `\003' is neither, nor can it ever be interpretable as anything other than `\003' or `^C' or `0x03', as long as there is the slightest possibility that two or more existing implementations generate `\003' but with different meanings. From vjs@rhyolite.denver.sgi.com Tue Jan 10 16:46:58 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id QAA03459 for ; Tue, 10 Jan 1995 16:46:58 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@merit.edu> id NAA06411; Tue, 10 Jan 1995 13:46:53 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA25304; Tue, 10 Jan 95 14:46:47 -0700 Date: Tue, 10 Jan 95 14:46:47 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501102146.AA25304@rhyolite.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: termination reasons > From ietf-ppp-request@MERIT.EDU Tue Jan 10 14:02:25 1995 > From: Gurdeep Singh Pall > To: ietf-ppp@MERIT.EDU, ietf-ppp-request@MERIT.EDU Again, I suspect sending discusssions to ietf-ppp-request@merit.edu is unpopular. > 1. The complexity of this enhancement is being greatly exaggerated. If > this forum can nail broader specs like LCP, why you think common > termination reasons cannot be standardized? Termination reasons by definition include implementation specific things while LCP is an interoperability issue. The proposed list of termination codes is a case study of why it is inconceivable that a usefully comprehensive set of codes could be agreed to. The reasons codes in that list were fine for that one implementation, but do not fit any other implementation. > 2. Again, I think the ASCII string idea is BAD. If the string cannot be > displayed directly to the user - as is the case for all globally > selling implementations - then it is of NO use. It only takes longer to > xmit, wastes memory, takes more cpu to compare, etc. > > You are missing the point here. If a number is sent as termination > reason you dont have to display it to the user - just because you were > displaying the reason string in your previous implementations. You > might consider passing the number through the "decoder rings" in your > implementation (mentioned in your earlier mail). > ... Speaking of complexity exaggerations, how complex is code to translate any of a few dozen short fixed strings to a local language? Among the possibilities that occur to me are: - naive, straight string compares. - minimal perfect hash, possibly augmented with a string compare. - binary probe into sorted list of strings. - insist the standardized ASCII string be prefixed with an 8-bit binary or 16-bit ASCII numeric code that can be used as an index into a table of natural language narratives. The ROM needed for the code and support data to do any of those is substantially less than the translated text in any one of the the local languages that any user-friendly implementation would contain. I haven't seen Microsoft's PPP implementation, but I have seen enough other Microsoft software products to be puzzled about any concerns from people with microsoft.com addresses about the little dab of code to translate from mnemonic termination reason codes (i.e. ASCII strings) to a natural language for a user interface. (I do not mean that as a snide comment about bloat. The Microsoft products I've purchased have an amazing amount of "help text" considering their target platforms.) Yes, there are two issues, 1. should the Terminate-Request reasons be standardized 2. if so, should they be 8-bit numbers or longer strings that include ASCII characters and I'm only talking about the second. However, once a reasonable position is chosen on the second question, then the first becomes less controversial. I bet that there would be no interest in the first question now if everyone had chosen to use ASCII strings instead of binary numbers that no one in the field remembers. Vernon Schryver, vjs@sgi.com From gurdeep@microsoft.com Tue Jan 10 16:58:12 1995 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.9/merit-2.0) with SMTP id QAA03656 for ; Tue, 10 Jan 1995 16:58:11 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA29554; Tue, 10 Jan 95 13:58:36 -0800 Message-Id: <9501102158.AA29554@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 10 Jan 95 13:58:36 PST X-Msmail-Message-Id: EABF6188 X-Msmail-Conversation-Id: EABF6188 From: Gurdeep Singh Pall To: karl@MorningStar.Com Date: Tue, 10 Jan 95 13:52:18 TZ Subject: Re: termination reasons Cc: ietf-ppp@MERIT.EDU ---------- | From: Karl Fox | | > If the string cannot be displayed directly to the user - as is the | > case for all globally selling implementations - then it is of NO | > use. | | I, and others, disagree. The most likely use of such data is while | debugging a dial-up connection, when it is usually easy to see the | contents of packets. I'm not likely to notice an extra 03 on a | Terminate-Request packet, nor will I be able to figure out what it | means if I do notice it. If I see the ASCII characters `Idle timeout' | in the Terminate-Request data field, I immediately know what it means, | and I am likely to notice it when examining the Terminate-Request. | Gurdeep> I'm pursuing this feature from a user's standpoint while you seem to pursuing this from a developer's standpoint (for debugging). You think that termination reasons are used for debugging only - I disagree and am not going to waste time changing your views. I believe that there is some termination information a user can benefit from that can be communicated in a interoperable way. If we do decide to pursue this spec. - I doubt ASCII will be used - pretty much for the same reason numbers were used to identify options codes and protocol ids - not ASCII strings. | | Keep in mind, folks, that we will *never* be able to rely on the | semantic contents of the Terminate-Request data field. There are too | many implementations extant, even if we were all to reach perfect | consensus today. It *is* possible, however, to notice whether the | data field is a printable ASCII string. `Idle timeout' is printable | and interpretable (at least by humans); `\003' is neither, nor can it | ever be interpretable as anything other than `\003' or `^C' or `0x03', | as long as there is the slightest possibility that two or more | existing implementations generate `\003' but with different meanings. | Gurdeep> Karl, here's a startling revelation - there are humans who don't understand printable ASCII strings. Bottom line, a string that comes in a packet cannot be displayed to the user (unless the sender is aware of locale etc.) in any s/w thats sells globally. From gurdeep@microsoft.com Tue Jan 10 17:57:24 1995 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.9/merit-2.0) with SMTP id RAA04378; Tue, 10 Jan 1995 17:57:23 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA03753; Tue, 10 Jan 95 14:57:45 -0800 Message-Id: <9501102257.AA03753@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 10 Jan 95 14:57:45 PST X-Msmail-Message-Id: 500FB13A X-Msmail-Conversation-Id: 500FB13A From: Gurdeep Singh Pall To: ietf-ppp@MERIT.EDU, ietf-ppp-request@MERIT.EDU Date: Tue, 10 Jan 95 14:49:22 TZ Subject: Re: termination reasons ---------- | From: Vernon Schryver | | Again, I suspect sending discusssions to ietf-ppp-request@merit.edu | is unpopular. | | > 1. The complexity of this enhancement is being greatly exaggerated. If | > this forum can nail broader specs like LCP, why you think common | > termination reasons cannot be standardized? | | Termination reasons by definition include implementation specific | things while LCP is an interoperability issue. The proposed list of | termination codes is a case study of why it is inconceivable that a | usefully comprehensive set of codes could be agreed to. The reasons codes | in that list were fine for that one implementation, but do not fit any | other implementation. | | | > 2. Again, I think the ASCII string idea is BAD. If the string cannot be | > displayed directly to the user - as is the case for all globally | > selling implementations - then it is of NO use. It only takes longer to | > xmit, wastes memory, takes more cpu to compare, etc. | > | > You are missing the point here. If a number is sent as termination | > reason you dont have to display it to the user - just because you were | > displaying the reason string in your previous implementations. You | > might consider passing the number through the "decoder rings" in your | > implementation (mentioned in your earlier mail). | > ... | | Speaking of complexity exaggerations, how complex is code to translate | any of a few dozen short fixed strings to a local language? Among the | possibilities that occur to me are: | - naive, straight string compares. | - minimal perfect hash, possibly augmented with a string compare. | - binary probe into sorted list of strings. | - insist the standardized ASCII string be prefixed with an 8-bit | binary or 16-bit ASCII numeric code that can be used as an | index into a table of natural language narratives. Gurdeep> Here is an excerpt from rfc1331 - PPP spec - by Mr. Simpson. " Protocol field values in the "0---" to "3---" range identify the network-layer protocol of specific datagrams, and values in the "8-- -" to "b---" range identify datagrams belonging to the associated Network Control Protocols (NCPs), if any. Protocol field values in the "4---" to "7---" range are used for protocols with low volume traffic which have no associated NCP. Protocol field values in the "c---" to "f---" range identify" Mr. Simpson and others chose a numeric scheme because in a compact form it meets the identification needs. Notice that the spec doesnt read "Protocol field values in the "Network layer protocol datagram 1" to :Network layer protocol datagram N" range...." In the least a precedence clause applies to the nomenclature of termination-reasons. Why would one use ASCII strings when a more compact, easier to handle, identifier called an "integer" exists - still remains a mystery to me. | | The ROM needed for the code and support data to do any of those is | substantially less than the translated text in any one of the the local | languages that any user-friendly implementation would contain. | | I haven't seen Microsoft's PPP implementation, but I have seen enough | other Microsoft software products to be puzzled about any concerns | from people with microsoft.com addresses about the little dab of code | to translate from mnemonic termination reason codes (i.e. ASCII | strings) to a natural language for a user interface. (I do not mean | that as a snide comment about bloat. The Microsoft products I've | purchased have an amazing amount of "help text" considering their | target platforms.) | Gurdeep> Let's keep this alias free of company bashing. | Yes, there are two issues, | 1. should the Terminate-Request reasons be standardized | 2. if so, should they be 8-bit numbers or longer strings that | include ASCII characters | and I'm only talking about the second. However, once a reasonable | position is chosen on the second question, then the first becomes less | controversial. I bet that there would be no interest in the first | question now if everyone had chosen to use ASCII strings instead of | binary numbers that no one in the field remembers. | I agree 1. is most important. 2. is a purist argument. | | Vernon Schryver, vjs@sgi.com | | From vjs@rhyolite.denver.sgi.com Tue Jan 10 18:48:13 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id SAA04833 for ; Tue, 10 Jan 1995 18:48:12 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@merit.edu> id PAA24395; Tue, 10 Jan 1995 15:48:07 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA00987; Tue, 10 Jan 95 16:47:26 -0700 Date: Tue, 10 Jan 95 16:47:26 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501102347.AA00987@rhyolite.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: termination reasons > From: gurdeep@microsoft.com (Gurdeep Singh Pall) > ... > Gurdeep> Karl, here's a startling revelation - there are humans who > don't understand printable ASCII strings. Bottom line, a string that > comes in a packet cannot be displayed to the user (unless the sender is > aware of locale etc.) in any s/w thats sells globally. That is irrelevant, given the trivial code to translate from an ASCII string to something localized. That is also baldly false. In the last 15 years I have been the author of much more than 100,000 lines of globally sold s/w. Between 30% and 40% of the 10,000's of its buyers have not had English as their native languages, and it has contained English messages that are presented unvarnished to users that ask for it, and for which there are no (as far as I know) translations. Text that is frequently displayed to unsophisticated users should be in the local natural language, as much as cybercrud can be. Localization is important, but I have also seen a lot of time, money, effort, projects, and even careers wasted on obsessive localization. Termination reasons will not be routinely presented to users, because users do not care why the link went down. They care only that (not why) it will come back up when needed next. It is extremely expensive and difficult to translate cybercrud. In fact, much of the non-native-English speaking audience for termination request reasons would rather have the original English than a fracture translation by someone who neither understands the original cybercrud nor is a fluent speaker of the local language. Imagine how "bad node ID" would probably be translated, given the English translations we have all seen of Oriental instructions for "insert tab A into slot B". PPP Termination codes are like the reasons a modern disk drive decides to relocate a sector. Sane people to not expect to be informed whenever their disk drive relocates a sector, not to mention absolutely positively every bit of the SCSI codes and conditions from the drive. To see where you are heading, read the ANSI SCSI standard and SCSI disk drive manuals from more than one vendor, and notice that most of the good information is in "vendor specific" fields, despite pages of standardized error codes. Consider the many versions of Hayes modem connection and failure messages. How many people have their modems deliver numeric codes? How standardized are those messages? The big difference is that PPP Termination messages cannot and so will not be parse by computers for the purpose of doing anything except logging or displaying a message. Vernon Schryver, vjs@sgi.com From fred@cisco.com Tue Jan 10 19:06:47 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.3.143]) by merit.edu (8.6.9/merit-2.0) with ESMTP id TAA05039 for ; Tue, 10 Jan 1995 19:06:46 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id QAA13951 for ; Tue, 10 Jan 1995 16:06:13 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Jan 1995 16:06:15 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Re: termination reasons At 5:52 AM 1/10/95, Gurdeep Singh Pall wrote: >I believe that there is some termination information a user can benefit >from that can be communicated in a interoperable way. If we do decide >to pursue this spec. - I doubt ASCII will be used - pretty much for the >same reason numbers were used to identify options codes and protocol >ids - not ASCII strings. I bit of implementation experience might help with this one. It comes from my recently-ex employer (I am the dearly departed :^) ACC has a pretty reasonable X.25 implementation, which is used by a lot of folks. X.25 has binary reason codes on Clear Requests, one of the X.25 equivalents to a Terminate. We found that in certain cases it was useful for the user to be able to dump a small circular "error code" log (which we never implemented, but felt would be a real great idea - the "circular log" we actually used was in a WAN Sniffer). For this reason, when the IETF was discussing the X.25 MIB, we pushed for a small circular buffer as a MIB table, which would contain recent clear reason codes (among other cruft). The biggest single reason we wanted this was because there was this other (nameless) DCE implementation. When you configure ACC's box to allow for N valid logical channels, it sets up tables for LCNs 1..N, since zero is an illegal LCN to use. Said other implementation would set up LCNs 0..N-1, and use 1..N-1. When a customer bought X.25 service from said (nameless) vendor, the vendor would tell the customer that there were N LCNs, and he would merry type N into the ACC configuration. And whenever we tried to negotiate the opening of LCN #N, we would get a CLEAR REASON of "INVALID LCN #". Gee whiz, being able to display that would have solved a number of customer support headaches. When we had a customer in that situation, we generally shipped them or convinced them to rent a WAN Sniffer or equivalent and capture the CLEARs. Seeing the scenario, we would say "are you doing business with vendor ? Did he tell you N, and you typed in N?" and that would be the end of it. I assert that if it's true for X.25, it's probably true for PPP. There is a set of reasons for termination that is interesting for a customer/user to know. The other end may be a router or a host, and this end may be either also. If you and I can't seem to communicate, it would be nice to be able to dump *something* that says "I gave up because he did, and he gave up because he thought I was not playing fair." OK, given that this is the class of problem that is most useful to know the particulars of, what is the PPP counterpart? I think - correct me if I'm wrong - that it's not a TERMINATE, if anything it's a CONFIGURE REJECT. As Vernon points out, once we have established an LCP or NCP, a terminate is given for basically four reasons: a ppp-initiated but otherwise normal shutdown, an LQM-initiated shutdown, an authentication failure (in LCP's case only), and a user-of-ppp initiated shutdown. It seems to me (and I claim no special gifts here) like the reason code corollary to the useful thing in an X.25 CLEAR REASON would indicate a parameter problem, and would therefore be related to a CONFIGURE NAK or CONFIGURE REJECT rather than a TERMINATE REQUEST. The most interesting TERMINATE reasons would be "authentication failure," "line's hosed," or a value supplied by the user application that requested the terminate. Non-LQM PPP-initiated shutdowns - The only reasons I can think of are "normal" ones, and I think that's all I'd be prone to say. I think if it were me doing it, I wouldn't bother with a TERMINATE reason, given all of this before. Rather, I would display the variables that the other end and I had not reached closure on, the value I was proposing and the value he was NAKing me to get, as my "presumed reason for shutdown" during LCP/NCP configuration. In any other case, I would print something on my own console or log, and presume that it were that important someone would go read my log. From vjs@rhyolite.denver.sgi.com Tue Jan 10 19:51:08 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id TAA05434 for ; Tue, 10 Jan 1995 19:51:07 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@merit.edu> id QAA07701; Tue, 10 Jan 1995 16:51:02 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA00784; Tue, 10 Jan 95 17:50:30 -0700 Date: Tue, 10 Jan 95 17:50:30 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501110050.AA00784@rhyolite.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: termination reasons >From: gurdeep@microsoft.com (Gurdeep Singh Pall) > ... >Mr. Simpson and others chose a numeric scheme because in a compact form >it meets the identification needs. Notice that the spec doesnt read >"Protocol field values in the "Network layer protocol datagram 1" to >:Network layer protocol datagram N" range...." > >In the least a precedence clause applies to the nomenclature of >termination-reasons. Why would one use ASCII strings when a more >compact, easier to handle, identifier called an "integer" exists - >still remains a mystery to me. There is an enormous difference between protocol numbers that are present in every PPP packet and must be parsed by computers to effect the PPP protocol, and very infrequent natural language messages (or their binary equivalent) that are at most displayed to people and never parsed by computers except to translate them into other messages. Protocol numbers demand as compact and efficient a representation as possible, while the messages should be optimized on additional grounds. What do you say to the people who read packet traces? Isn't it worth some inefficiency in very infrequent packets to make their job easier, particularly if it costs essentially zero CPU cycles and an insignificant increase in the bytes that are allocated to dealing with localizing the messages? >... >| The ROM needed for the code and support data to do any of those is >| substantially less than the translated text in any one of the the local >| languages that any user-friendly implementation would contain. >| >| I haven't seen Microsoft's PPP implementation, but I have seen enough >| other Microsoft software products to be puzzled about any concerns >| from people with microsoft.com addresses about the little dab of code >| to translate from mnemonic termination reason codes (i.e. ASCII >| strings) to a natural language for a user interface. (I do not mean >| that as a snide comment about bloat. The Microsoft products I've >| purchased have an amazing amount of "help text" considering their >| target platforms.) > >Gurdeep> Let's keep this alias free of company bashing. Please re-read my text. I tried to avoid company bashing, while trying to question what seems to me to be an inconsistency. If it is ok to include large amounts of help text in products that are intended for small, desktop machines, why do you object to a small amount of very infrequently executed code to convert a string of bytes instead of an 8-bit number to a localized message? >| Yes, there are two issues, >| 1. should the Terminate-Request reasons be standardized >| 2. if so, should they be 8-bit numbers or longer strings that >| include ASCII characters >| and I'm only talking about the second. However, once a reasonable >| position is chosen on the second question, then the first becomes less >| controversial. I bet that there would be no interest in the first >| question now if everyone had chosen to use ASCII strings instead of >| binary numbers that no one in the field remembers. >| > >I agree 1. is most important. 2. is a purist argument. That is not my point. My point is that a different choice than you and others would make for (2) would render (1) uninteresting to more people. Vernon Schryver, vjs@sgi.com From gurdeep@microsoft.com Tue Jan 10 20:48:14 1995 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.9/merit-2.0) with SMTP id UAA06074; Tue, 10 Jan 1995 20:48:14 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA16933; Tue, 10 Jan 95 17:48:38 -0800 Message-Id: <9501110148.AA16933@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 10 Jan 95 17:48:37 PST X-Msmail-Message-Id: 9571D6C7 X-Msmail-Conversation-Id: 9571D6C7 From: Gurdeep Singh Pall To: ietf-ppp@MERIT.EDU, ietf-ppp-request@MERIT.EDU Date: Tue, 10 Jan 95 17:46:04 TZ Subject: Re: termination reasons Vernon I'm not at *all* interested in your opinion on whether the ASCII string should or shouldnt be translated. Its great to know that your international customers tolerated ASCII messages, blah blah blah.... Lets forget about how a message is displayed etc, and talk about whether termination-codes should be formalized. Bill makes a good point about retaining compatibility with existing implementations - this will be tough given all the adhoc implementations. Any ideas here? gurdeep@microsoft.com ---------- | From: Vernon Schryver | To: | | > From: gurdeep@microsoft.com (Gurdeep Singh Pall) | | > ... | > Gurdeep> Karl, here's a startling revelation - there are humans who | > don't understand printable ASCII strings. Bottom line, a string that | > comes in a packet cannot be displayed to the user (unless the sender is | > aware of locale etc.) in any s/w thats sells globally. | | | That is irrelevant, given the trivial code to translate from an ASCII | string to something localized. That is also baldly false. In the last | 15 years I have been the author of much more than 100,000 lines of | globally sold s/w. Between 30% and 40% of the 10,000's of its buyers | have not had English as their native languages, and it has contained | English messages that are presented unvarnished to users that ask for | it, and for which there are no (as far as I know) translations. | | Text that is frequently displayed to unsophisticated users should be in | the local natural language, as much as cybercrud can be. Localization | is important, but I have also seen a lot of time, money, effort, projects, | and even careers wasted on obsessive localization. Termination reasons | will not be routinely presented to users, because users do not care why | the link went down. They care only that (not why) it will come back up | when needed next. | | It is extremely expensive and difficult to translate cybercrud. In | fact, much of the non-native-English speaking audience for termination | request reasons would rather have the original English than a fracture | translation by someone who neither understands the original cybercrud | nor is a fluent speaker of the local language. Imagine how "bad node | ID" would probably be translated, given the English translations we | have all seen of Oriental instructions for "insert tab A into slot B". | | | PPP Termination codes are like the reasons a modern disk drive decides | to relocate a sector. Sane people to not expect to be informed | whenever their disk drive relocates a sector, not to mention absolutely | positively every bit of the SCSI codes and conditions from the drive. | To see where you are heading, read the ANSI SCSI standard and SCSI disk | drive manuals from more than one vendor, and notice that most of the | good information is in "vendor specific" fields, despite pages of | standardized error codes. | | | Consider the many versions of Hayes modem connection and failure | messages. How many people have their modems deliver numeric codes? | How standardized are those messages? The big difference is that PPP | Termination messages cannot and so will not be parse by computers for | the purpose of doing anything except logging or displaying a message. | | | Vernon Schryver, vjs@sgi.com | | From karl@MorningStar.Com Tue Jan 10 22:38:24 1995 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.9/merit-2.0) with SMTP id WAA06906 for ; Tue, 10 Jan 1995 22:38:23 -0500 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA15975; Tue, 10 Jan 95 22:37:51 -0500 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA10349; Tue, 10 Jan 95 22:37:50 -0500 Date: Tue, 10 Jan 95 22:37:50 -0500 Message-Id: <9501110337.AA10349@gefilte.MorningStar.Com> To: Gurdeep Singh Pall Cc: ietf-ppp@MERIT.EDU Subject: Re: termination reasons In-Reply-To: <9501102158.AA29554@netmail2.microsoft.com> References: <9501102158.AA29554@netmail2.microsoft.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Gurdeep Singh Pall writes: > I'm pursuing this feature from a user's standpoint while you seem to > pursuing this from a developer's standpoint (for debugging). No, I'm looking at it from the point of view of 1) a customer, and 2) a customer support person. *They* are the ones who have to figure out why their connection doesn't work, or why it hangs up too soon, or why it won't hang up at all. The only value I could think of for the termination messages were so that it would be possible to figure out the disconnection reason from the side that *didn't* initiate the disconnection. > If we do decide to pursue this spec. - I doubt ASCII will be used - > pretty much for the same reason numbers were used to identify > options codes and protocol ids - not ASCII strings. That would make sense if the messages had to be interpreted by software. I haven't yet seen anyone propose such a thing. > Karl, here's a startling revelation - there are humans who > don't understand printable ASCII strings. Yes, but fortunately, they generally don't use computers. Every single computer I have ever seen uses printable ASCII strings for the bulk of the information displayed to the user. > Bottom line, a string that comes in a packet cannot be displayed to > the user (unless the sender is aware of locale etc.) in any s/w > thats sells globally. Why not? All other software does. Nobody said it had to be in English. So make versions of your products for other languages already. From karl@MorningStar.Com Tue Jan 10 23:02:23 1995 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.9/merit-2.0) with SMTP id XAA07124 for ; Tue, 10 Jan 1995 23:02:22 -0500 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA16184; Tue, 10 Jan 95 23:01:50 -0500 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA10357; Tue, 10 Jan 95 23:01:49 -0500 Date: Tue, 10 Jan 95 23:01:49 -0500 Message-Id: <9501110401.AA10357@gefilte.MorningStar.Com> To: Gurdeep Singh Pall Cc: ietf-ppp@MERIT.EDU Subject: Re: termination reasons In-Reply-To: <9501110148.AA16933@netmail2.microsoft.com> References: <9501110148.AA16933@netmail2.microsoft.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Gurdeep Singh Pall writes: > Lets forget about how a message is displayed etc, and talk about > whether termination-codes should be formalized. Bill makes a good point > about retaining compatibility with existing implementations - this will > be tough given all the adhoc implementations. Any ideas here? Before we can get very far we'll need some reasons why the messages need to be standardized. Any ideas? Can anybody think of any reason why they need to be machine interpretable? From bill.simpson@um.cc.umich.edu Wed Jan 11 08:29:18 1995 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-04.dialip.mich.net [141.211.7.140]) by merit.edu (8.6.9/merit-2.0) with SMTP id IAA11083 for ; Wed, 11 Jan 1995 08:29:15 -0500 Date: Wed, 11 Jan 95 11:21:26 GMT From: "William Allen Simpson" Message-ID: <3674.bill.simpson@um.cc.umich.edu> To: ietf-ppp@MERIT.EDU Reply-to: bsimpson@morningstar.com Subject: Re: termination reasons > From: Gurdeep Singh Pall > To: ietf-ppp@MERIT.EDU, ietf-ppp-request@MERIT.EDU There is something wrong with your alias. Please remove the second -request entry. Also, it would really help if your software would stop including the _entire_ original in every reply! We already read the original, and can always go back and look at it if we need it. > Gurdeep> Here is an excerpt from rfc1331 - PPP spec - by Mr. Simpson. > > " Protocol field values in the "0---" to "3---" range identify the > network-layer protocol of specific datagrams, and values in the "8-- > -" to "b---" range identify datagrams belonging to the associated > Network Control Protocols (NCPs), if any. > > Protocol field values in the "4---" to "7---" range are used for > protocols with low volume traffic which have no associated NCP. > Protocol field values in the "c---" to "f---" range identify" > > Mr. Simpson and others chose a numeric scheme because in a compact form > it meets the identification needs. Notice that the spec doesnt read > "Protocol field values in the "Network layer protocol datagram 1" to > :Network layer protocol datagram N" range...." > Excuse me? The PPP Protocol ranges have no computer meaning. There is no processing done on those number ranges, which the exception of compression of leading zeroes. The ranges are used to assist ASSIGNMENT (by humans), and DUMP READING (by humans). And you are using a very old copy of PPP! You might consider using a more recent version [RFC-1661]. > In the least a precedence clause applies to the nomenclature of > termination-reasons. Why would one use ASCII strings when a more > compact, easier to handle, identifier called an "integer" exists - > still remains a mystery to me. > Because, as several persons have now stated, these are infrequent messages that shouldn't be displayed to a user. Integers are notoriously difficult to quickly find in a packet trace or log. > | Yes, there are two issues, > | 1. should the Terminate-Request reasons be standardized > | 2. if so, should they be 8-bit numbers or longer strings that > | include ASCII characters > | and I'm only talking about the second. However, once a reasonable > | position is chosen on the second question, then the first becomes less > | controversial. I bet that there would be no interest in the first > | question now if everyone had chosen to use ASCII strings instead of > | binary numbers that no one in the field remembers. > | > > I agree 1. is most important. 2. is a purist argument. > It seems to be running about 3 to 1 against "standardizing". PPP is already a "Standard". The time to have raised this was at Proposed (where we stayed for 3 years). We already discussed the character set issues then, and decided on uninterpreted data. Bill.Simpson@um.cc.umich.edu From bill.simpson@um.cc.umich.edu Wed Jan 11 08:29:21 1995 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-04.dialip.mich.net [141.211.7.140]) by merit.edu (8.6.9/merit-2.0) with SMTP id IAA11086 for ; Wed, 11 Jan 1995 08:29:19 -0500 Date: Wed, 11 Jan 95 11:37:12 GMT From: "William Allen Simpson" Message-ID: <3675.bill.simpson@um.cc.umich.edu> To: ietf-ppp@MERIT.EDU Reply-to: bsimpson@morningstar.com Subject: Re: termination reasons > From: fred@cisco.com (Fred Baker) > OK, given that this is the class of problem that is most useful to know the > particulars of, what is the PPP counterpart? I think - correct me if I'm > wrong - that it's not a TERMINATE, if anything it's a CONFIGURE REJECT. As > Vernon points out, once we have established an LCP or NCP, a terminate is > given for basically four reasons: a ppp-initiated but otherwise normal > shutdown, an LQM-initiated shutdown, an authentication failure (in LCP's > case only), and a user-of-ppp initiated shutdown. > Good analysis. Neither the normal or user-initiated cases need a message displayed, since these are common and expected. For LQM, it might be usedful to tell the user that shutdown was due to quality, but the LQM messages are already passed, and so the user's software already knows the link quality is bad. For authentication, we already have a separate set of messages in the authentication Ack/Nak. (I both log those and display them.) > I think if it were me doing it, I wouldn't bother with a TERMINATE reason, > given all of this before. Rather, I would display the variables that the > other end and I had not reached closure on, the value I was proposing and > the value he was NAKing me to get, as my "presumed reason for shutdown" > during LCP/NCP configuration. In any other case, I would print something on > my own console or log, and presume that it were that important someone > would go read my log. > Yep, that's the right thing to do! Bill.Simpson@um.cc.umich.edu From sgw@sgw.xyplex.com Wed Jan 11 09:21:37 1995 Received: from sgw.xyplex.com (sgw.xyplex.com [140.179.224.7]) by merit.edu (8.6.9/merit-2.0) with SMTP id JAA11938 for ; Wed, 11 Jan 1995 09:21:34 -0500 Received: by sgw.xyplex.com (4.1/SMI-4.1) id AA02598; Wed, 11 Jan 95 09:19:24 EST From: sgw@sgw.xyplex.com (sgw) Message-Id: <9501111419.AA02598@sgw.xyplex.com> Subject: Re: termination reasons To: bsimpson@morningstar.com Date: Wed, 11 Jan 95 9:19:23 EST Cc: ietf-ppp@MERIT.EDU In-Reply-To: <3675.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Jan 11, 95 11:37 am X-Mailer: ELM [version 2.3 PL8] According to William Allen Simpson: > > For LQM, it might be usedful to tell the user that shutdown was due to > quality, but the LQM messages are already passed, and so the user's > software already knows the link quality is bad. > That's only half true. LQM only defines the machinery; it doesn't spec a "policy". The peer's policy may be configured to shut down the link if 23% of the packets are being lost. While my peer and I both computed the same "raw data", we may have different definitions of "bad", and different policies on what to do about it. I cast my vote for human-readable strings. I disagree with Vernon's point about conversion to foreign languages ('Put tab A in slot B'). Instead that's just putting off the problem to documentation. Great, the PPP packet has a '5' at the end. Now let me go find my handy-dandy User's Guide (which every good customer dutifully keeps at his bed-side for late-night reading material :-> ). Wrong. Nobody wants to be bothered to remove the shrink-wrap, keep it handy, or much less read the thing. Besides, documentation is just as likely to suffer the same translational difficulties. The burden placed on foreigners is not onerous. We're not expecting him to translate the text of "War and Peace" here. Just a several-word phrase. I would expect it to be rather easy to find at least one english-speaking individual within the confines of most overseas worksites. I think 1661 is fine as-is. At most we should say that Term-reqs "MAY" or "SHOULD" be appended with a human-readable string. But of course they may or may not be appended with anything at all. +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Scott G. Wasson sgwasson@eng.xyplex.com | | Xyplex, Internetworking & Media Voice: (508) 952-4746 | | 295 Foster St. Littleton, MA 01460 Fax: (508) 952-4887 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ From bill@tribe.tribe.com Wed Jan 11 13:07:47 1995 Received: from tribe.tribe.com (tribe.tribe.com [199.35.172.35]) by merit.edu (8.6.9/merit-2.0) with SMTP id NAA14565 for ; Wed, 11 Jan 1995 13:07:46 -0500 Received: from [199.35.172.106] by tribe.tribe.com (5.64/A/UX-3.00) id AA29283; Wed, 11 Jan 95 11:24:21 PST Message-Id: <9501111924.AA29283@tribe.tribe.com> Date: Wed, 11 Jan 1995 10:14:11 -0800 To: ietf-ppp@merit.edu From: bill@tribe.tribe.com (Bill Jackson) X-Sender: bill@tribe.tribe.com Subject: Changing passwords with PPP Does anyone know if there have been proposals or work done to allow users to change passwords remotely? Has anyone proposed extentions to CHAP or suggested a new protocol which could require/allow users to change passwords remotely? If not, is anyone interested in this problem? Thanks, Bill Jackson Tribe Computer Works From vjs@rhyolite.denver.sgi.com Wed Jan 11 13:44:40 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id NAA15022 for ; Wed, 11 Jan 1995 13:44:39 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@Merit.edu> id KAA01318; Wed, 11 Jan 1995 10:44:35 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@Merit.edu id AA10557; Wed, 11 Jan 95 11:44:02 -0700 Date: Wed, 11 Jan 95 11:44:02 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501111844.AA10557@rhyolite.denver.sgi.com> To: ietf-ppp@Merit.edu Subject: Changing passwords with PPP >From: bill@tribe.tribe.com (Bill Jackson) > >Does anyone know if there have been proposals or work done to allow users >to change passwords remotely? Has anyone proposed extentions to CHAP or >suggested a new protocol which could require/allow users to change >passwords remotely? If not, is anyone interested in this problem? There are a zillion protocols for changing passwords remotely. Most of them are wide open security holes. The problem is intrinsically very hard, since it is essentially the cryptographic key distribution problem. Support for changing passwords does not sound like something that should be attempted in the IETF PPP working group. If it is something that the IETF should touch at all, it sounds like something for the general security group, since a password is a password, regardless of whether it is used for PAP, CHAP, a remote shell, or to launch missles. I continue get beaten up about adding support to SLIP and PPP for those newfangled smart-cards. I think they could be supported by treating their magic strings as PAP or CHAP passwords, but maybe there is a better way, perhaps even a new PPP protocol. Vernon Schryver, vjs@sgi.com From vjs@rhyolite.denver.sgi.com Wed Jan 11 14:00:31 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id OAA15357 for ; Wed, 11 Jan 1995 14:00:30 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@merit.edu> id LAA04102; Wed, 11 Jan 1995 11:00:18 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA10673; Wed, 11 Jan 95 11:59:35 -0700 Date: Wed, 11 Jan 95 11:59:35 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501111859.AA10673@rhyolite.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: termination reasons What about the contents of Terminate-Acks? I think copying the Data from the Terminate-Request is useless (there is the Identifier), and so a waste of bandwidth, and so I'm changing my code to always use a length of 4. > From: karl@MorningStar.Com (Karl Fox) > ... > Before we can get very far we'll need some reasons why the messages > need to be standardized. Any ideas? Can anybody think of any reason > why they need to be machine interpretable? I think the reason is so that the local machine can translate the termination reasons of the remote machine into the local language so that they can be read by the user, not just during debugging but routinely. (I think I've accurately represented that unstated goal, although I do not support it.) One answer is in the following: ] From: karl@MorningStar.Com (Karl Fox) ]... ] Nobody said it had to be in English. So make versions of your ] products for other languages already. That elegantly solves most of the issue. If termination request messages use English ASCII, you can always include an appendix in your documentation of likely English phrases in termination requests and translations into the local language. Another answer is that every implementation is likely to have at least one off-the wall reason for terminating that will never be in the standard list of reasons and so cannot be translated by another vendor's implemenation to the local language, but that Murphy will ensure is what always happens between those two implemenations. That makes any mechanical translation of other vendor's termination request messages a waste much of the time. I've gone through my code since this discussion started, adding termination strings where they do not seem useless (e.g. restart expired). At least two useful strings are so certifiably off-the-wall for any other implementation that I would not bother submitting them to any Official ISEG PPP Registery of Termination Request Reasons Strings. Describing them to the Registery well enough for another vendor to produce a "localized" translation would be more work than I would want to attempt. Again, there is no conflict between machine readable and human readable. If you don't like your machine reading known English (or local language) ASCII strings, then prepend or append an ASCII or binary number to the English (or local language) string in the packet. Vernon Schryver, vjs@sgi.com From fred@cisco.com Wed Jan 11 15:06:07 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.3.143]) by merit.edu (8.6.9/merit-2.0) with ESMTP id PAA16453 for ; Wed, 11 Jan 1995 15:06:06 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id MAA29447; Wed, 11 Jan 1995 12:05:28 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jan 1995 12:05:31 -0800 To: bill@tribe.tribe.com (Bill Jackson), vjs@rhyolite.denver.sgi.com (Vernon Schryver) From: fred@cisco.com (Fred Baker) Subject: Re: Changing passwords with PPP Cc: brad@fcp.com, ietf-ppp@MERIT.EDU At 10:44 AM 1/11/95, Vernon Schryver wrote: >I continue get beaten up about adding support to SLIP and PPP for those >newfangled smart-cards. I think they could be supported by treating >their magic strings as PAP or CHAP passwords, but maybe there is a >better way, perhaps even a new PPP protocol. At the recent IETF meeting, we discussed the progress of a smallish group of people who are working on this class of problem. Brad Parker agreed to flesh out his "gap" proposal and move it along towards RFC-dom, as it is actually a deployed product. You might take a look at it and comment to him. I don't believe that it changes passwords remotely, it targets the one-time password cards. From fred@cisco.com Wed Jan 11 15:06:10 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.3.143]) by merit.edu (8.6.9/merit-2.0) with ESMTP id PAA16464 for ; Wed, 11 Jan 1995 15:06:09 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id MAA29455 for ; Wed, 11 Jan 1995 12:05:36 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jan 1995 12:05:38 -0800 To: ietf-ppp@merit.edu From: fred@cisco.com (Fred Baker) Subject: GIF licensing: the saga continues For those who thought the patent wars were over... ----begin forwarded text---- Here is the complete text of the News Flash currently posted on the Compuserve Graphic Support Forum: * * * * * January 6, 1995 Unisys Clarifies Policy Regarding Patent Use in On-Line Service Offerings The concerns, inquiries and some apparent confusion that have resulted from the December CompuServe advisory clearly indicate that we need to clarify our policy concerning the use of the Unisys Lev Zempel Welch (LZW) patent by software developers for the major on-line services. We want to reiterate earlier communications that the issue of patent licenses is not focused on the end users of on-line networks, including the Internet. We encourage end users to continue to take full advantage of the outstanding benefits of a rapidly growing on-line community. Unisys was awarded the patent in 1985. We became aware of the increasing interest in our LZW patent beginning in 1990 when many companies approached us to license the patent for their hardware and software products. The growth in the use of compression technology was mushrooming in order to meet the demands for transmitting increased amounts of data. To date, more than 100 companies, including hardware, software and on-line information services, have licensed the Unisys LZW technology. Two years ago, Unisys learned that the LZW method was incorporated in the GIF specification and immediately began negotiations with CompuServe in January of 1993. We reached agreement with CompuServe on licensing the technology in June 1994, which calls for CompuServe to pay Unisys a royalty of 1% of the average selling price it charges for its software. This represents approximately 11 cents for each copy sold and connected to its information service. Under the agreement, CompuServe, at its discretion, could relicense the LZW technology to commercial developers using the GIF specification in software that connected directly to the CompuServe information service. With the agreement completed on June 21, 1994, CompuServe was given six months to implement the terms of its license. CompuServe later asked for a one-month extension, which we granted. Unisys did not require CompuServe to pass on any fee to its sublicensees or end users. Such a decision, and the content and timing of CompuServe's advisory, was at their discretion. Consistent with the entire information industry+s desire to protect intellectual property, Unisys will expect all of the major commercial on-line information services companies employing the LZW patent to license the technology from Unisys at a reasonable rate. The on-line service companies are not required to sublicense the technology to developers producing software for the commercial on-line services. It will be, as it is today, at the on-line service's discretion as to whether it charges a license fee to developers or chooses an alternative method to account for its licensing fees payable to Unisys. We recognize and are concerned -- thanks in large part to the recent and very active use of the on-line network -- that developers did not understand that the patented technology was resident in GIF. Taking that into account, Unisys does not intend to pursue previous inadvertent infringement by versions of GIF-based software products marketed prior to 1995. Concerning all future software product development and enhancement of existing products for accessing on-line services, Unisys expects developers of commercial, for-profit software to secure a license from Unisys, or through the licensed on-line service, for the use of the patented technology. The very reasonable terms should prove no financial barrier to the introduction of product into the on-line network. Unisys does not require licensing, or fees to be paid, for non-commercial, non-profit GIF-based applications, including those for use on the on-line services. Concerning developers of software for the Internet network, the same principle applies. Unisys will not pursue previous inadvertent infringement by developers producing versions of software products for the Internet prior to 1995. The company does not require licensing, or fees to be paid for non-commercial, non-profit offerings on the Internet, including "Freeware". Commercial developers of GIF-based software for the Internet are expected to secure a licensing agreement with Unisys for software products introduced beginning in 1995, or enhancements of products that were introduced prior to 1995. Again, terms should not preclude the entry by these firms into the marketplace. For organizations introducing World Wide Web servers and "Home Page" offerings, most will not be required to secure a license from Unisys. Most organizations acquire software from other developers to create their offerings on their servers. Therefore, only the software firms who sell the enabling software for profit would be expected to secure a licensing agreement from Unisys. Unisys understands that this issue has caused concern. We want to reassure all users and developers that we are strong proponents of the on-line industry. We're proud that this important Unisys technology has played a role in the introduction of innovative products and services, many of which are fueling the explosive growth of the information superhighway. As members of the information community we want to strike the appropriate balance between information access and the rights of all information companies, including the developers of software, to protect their intellectual property rights. Patent information: Contact Welch Patent Licensing Department; Unisys; Mail Stop C1SW19; P.O. Box 500, Blue Bell, PA 19424. Or via Internet, send E-mail to LZW_INFOUNISYS.COM, or use a form available on the Home Page of the Unisys Web Server (http:\\www.unisys.com) to request follow-up information. Media contacts: Unisys Public Relations -- Bob O'Leary (215) 986-6413 or Oliver Picher (215) 986-5367 * * * * * source: David Vereschagin Art before life. quadrat@interlog.com 75645.1273@compuserve.com B2/3 t- c- k+ s+(+) m p ------------------------------------------------------------------------ The Arctos Group - Information Strategies for the Real Estate Industry 101 Federal Street - Suite 1900 - Boston, Massachusetts 02110 USA tel: 617.342.7411 - fax: 617.232.0025 - email: arctos@arctos.com visit our WWW site at URL: http://www.arctos.com/arctos ------------------------------------------------------------------------ From gurdeep@microsoft.com Wed Jan 11 15:25:13 1995 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.9/merit-2.0) with SMTP id PAA17029 for ; Wed, 11 Jan 1995 15:25:09 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA14240; Wed, 11 Jan 95 12:25:05 -0800 Message-Id: <9501112025.AA14240@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Wed, 11 Jan 95 12:25:04 PST X-Msmail-Message-Id: CA086444 X-Msmail-Conversation-Id: CA086444 From: Gurdeep Singh Pall To: bsimpson@morningstar.com, ietf-ppp@MERIT.EDU Date: Wed, 11 Jan 95 12:17:41 TZ Subject: Re: termination reasons | Bill.Simpson@um.cc.umich.edu writes: | Excuse me? The PPP Protocol ranges have no computer meaning. There is | no processing done on those number ranges, which the exception of | compression of leading zeroes. | The ranges are used to assist ASSIGNMENT (by humans), and DUMP READING | (by humans). | And you are using a very old copy of PPP! You might consider using a | more recent version [RFC-1661]. I think you missed the point. Identification of an entity (whether it be a protocol, an option, an error code, a termination reason) is best done with a number. This number then can be translated into an action (a code fork, a log, a dialog popped to the user) by the receiving s/w. btw, the same "range" text appears in rfc1661. | It seems to be running about 3 to 1 against "standardizing". | | PPP is already a "Standard". The time to have raised this was at | Proposed (where we stayed for 3 years). We already discussed the | character set issues then, and decided on uninterpreted data. Bill you and I and every one else has come across standards that slowly become out of date for many reasons. Maybe it is time to start thinking about PPPv2 huh? Else, lets keep the status-quo argument out and see if this problem should be addressed - we can talk about how later. On a more general note. It is being widely implied in the responses on this subject that the termination reason is displayed AS IS to the user!?!?! My position is: Why cannot a number be sent as a termination code and the receiving host s/w appropriately maps it to a locale specific string? Also, Fred pointed out that termination reasons can be put into the specific config rejects. Our implementation already does this - giving localized messages to the user about the problem, ways to fix it etc. I think that other termination reasons - that cannot be handled as such since there is no config request pending - are quite important as well. Bill's comment that you can expect a user to have hand-holding when experiencing problems - is not a design ideal for us. For these abnormal termination problems - we would like to give a clear and "in their own language" popup to the user - in addition have detailed online help describing the possible problem. We would like to have the same level of feedback when interoperating with other implementations as well. With rising support costs - we would ideally like a user NEVER to call for support - especially if it is because of her/his inexperience with the software. From vjs@rhyolite.denver.sgi.com Wed Jan 11 17:54:57 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id RAA19683 for ; Wed, 11 Jan 1995 17:54:56 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@merit.edu> id OAA13345; Wed, 11 Jan 1995 14:54:52 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA11704; Wed, 11 Jan 95 15:54:19 -0700 Date: Wed, 11 Jan 95 15:54:19 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501112254.AA11704@rhyolite.denver.sgi.com> To: ietf-ppp@merit.edu Subject: PPP compression (was GIF licensing: the saga continues) > From: fred@cisco.com (Fred Baker) > ... > For those who thought the patent wars were over... > ----begin forwarded text---- There is a lot more traffic in comp.compression, ranging from silly noise to interesting words from Victor Miller, one of the holders of the IBM LZW patent. I found Raymond Gardner's interesting as well. Consider this part of the note from Unisys: > ... > Concerning developers of software for the Internet network, the same > principle applies. Unisys will not pursue previous inadvertent > infringement by developers producing versions of software products for > the Internet prior to 1995. The company does not require licensing, or > fees to be paid for non-commercial, non-profit offerings on the Internet, > including "Freeware". > ... It seems (to me, not a lawyer) that "BSD Compress" is free for freeware, even if you do not have the `compress` command. Vernon Schryver, vjs@sgi.com From ken@funk.com Thu Jan 12 08:52:38 1995 Received: from funk.Funk.COM (funk.terranet.com [199.103.254.41]) by merit.edu (8.6.9/merit-2.0) with ESMTP id IAA26060 for ; Thu, 12 Jan 1995 08:52:36 -0500 Received: from ken.funk.com (machine-133.Funk.COM [198.186.160.133]) by funk.Funk.COM (8.6.5/FUNK-1.2) with SMTP id IAA12111 for ; Thu, 12 Jan 1995 08:45:11 -0500 Date: Thu, 12 Jan 1995 08:45:11 -0500 Message-Id: <199501121345.IAA12111@funk.Funk.COM> X-Sender: ken@funk.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@merit.edu From: ken@funk.com (Ken Culbert) Subject: Re: termination reasons X-Mailer: >It seems to me (and I claim no special gifts here) like the reason code >corollary to the useful thing in an X.25 CLEAR REASON would indicate a >parameter problem, and would therefore be related to a CONFIGURE NAK or >CONFIGURE REJECT rather than a TERMINATE REQUEST. The most interesting >TERMINATE reasons would be "authentication failure," "line's hosed," or a >value supplied by the user application that requested the terminate. >Non-LQM PPP-initiated shutdowns - The only reasons I can think of are >"normal" ones, and I think that's all I'd be prone to say. > >I think if it were me doing it, I wouldn't bother with a TERMINATE reason, >given all of this before. Rather, I would display the variables that the >other end and I had not reached closure on, the value I was proposing and >the value he was NAKing me to get, as my "presumed reason for shutdown" >during LCP/NCP configuration. In any other case, I would print something on >my own console or log, and presume that it were that important someone >would go read my log. Your point is well taken; but I still think there are reasons to use the terminate data field: 1) Rejection of an option does not necessarily (or usually, in my experience) cause link establishment to fail. Why require a user to wade through arcane specs to determine the actual reasons for the failure, when the terminating implementation can provide the information directly? Also, implementations may disagree on which is the offending option. 2) 'Normal' termination could occur in a variety of flavors -- callback, time expired, user-requested, administrator-request, etc. I think it's important for the user, and useful for the implementation, to be informed of the termination reason. Ken Culbert ken@funk.com Funk Software, Inc. voice: (617) 497-6339 222 Third Street fax: (617) 547-1031 Cambridge, MA 02142 From fred@cisco.com Thu Jan 12 12:53:57 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.3.143]) by merit.edu (8.6.9/merit-2.0) with ESMTP id MAA29350 for ; Thu, 12 Jan 1995 12:53:56 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id JAA16259; Thu, 12 Jan 1995 09:52:31 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jan 1995 09:52:37 -0800 To: ken@funk.com (Ken Culbert) From: fred@cisco.com (Fred Baker) Subject: Re: termination reasons Cc: ietf-ppp@MERIT.EDU At 5:43 AM 1/12/95, Ken Culbert wrote: >1) Rejection of an option does not necessarily (or usually, in my >experience) cause link establishment to fail. Why require a user to wade >through arcane specs to determine the actual reasons for the failure, when >the terminating implementation can provide the information directly? Also, >implementations may disagree on which is the offending option. I think we're talking about the same thing, believe it or not. If I am negotiating five different options and we deadlock on one (and what are we likely to deadlock on? Authentication procedure, perhaps) I didn't propose that we list five, but one. Say "we were negotiating and negotiating, he insists on authentication, I am not configured for authentication, and therefore we cannot open LCP." Or say "I was asking him for an IP address (offering IP address 0.0.0.0) and he was ACKing/REJECTing the option rather than NAKing back with an IP address, and we therefore cannot open IP CP". I'd like to believe that the cases can be described in a locally generated message in user-understandable terms, and not require wading through manuals. In both of these cases, the issue is incompatible configuration. One end is requiring a service that the other end cannot or is not configured to offer. >2) 'Normal' termination could occur in a variety of flavors -- callback, >time expired, user-requested, administrator-request, etc. I think it's >important for the user, and useful for the implementation, to be informed of >the termination reason. Maybe, but I observe that X.25, X.21, etc. don't do that. They have one "normal" termination and any number of error terminations. If a termination is normal, then the software should know what would constitute a normal termination in the case. If I have negotiated a callback and I get a TERMINATE with a "normal" reason code, that's the same as getting a terminate that says "I'll call you back." And in context - that would be right after getting the LCP configure ACK - what else would be a reason to send a TERMINATE? Why would I not infer the same from our current TERMINATE? Consider LAPB as a very related example. LAPB has a normal disconnect (DISC), and a message that says "you sent me a non-SABM and I am down" called DM (Disconnected Mode). DISC and DM are "normal" terminations. Error terminations are signalled by FRMR, which has a bunch of incomprehensible bits that are supposed to convey what happened. The thing I think is being missed here is that, with one exception (an LQM failure) a TERMINATE is *always* a normal termination. If I log into some application, and it sets a timer, and the timer expires triggering a call drop, isn't it that application's job to tell the caller "I am dropping you because you blab for too long" or "...because you took a coffee break"? - I know that's what ARA does. After doing that, the application closes the call, and PPP sends a PPP TERMINATE to clear the call. Seems to me that the driver should be able to work out what a normal termination is from the state of the connection. Making application-specific timers get reported by the application is an application of what Craig Partridge would call the "End to End Principle" - if there is a facility required at some higher point in the stack, doing the same thing at a lower level in the stack is redundant and a bad idea. The principle underlies the reason PPP has no retransmissions - the transport or application must do that anyway, doing it again in PPP is (generally) not a worthwhile optimization (specific cases, such as compression, are what justifies it at all). In context, I think it's an important principle. Handling an LQM drop shouldn't be a major exercise - both sides can see that there has been a major data loss. In such a case, maybe the PPP driver should say "the other end dropped the line and I had observed a major data loss. Please check your hardware." And by the way, gee whiz, suppose that we updated LQM with a message or flag value that indicates "I am about to send you an LCP TERMINATE, the reason I will send it is data loss." What might be helpful in this discussion would be some real world evidence (anecdotes, specific cases where the protocol has a normal termination can't be worked out, etc.). We're at a pretty high philosophical level here, and neither side of the debate seems to be able to convince the other. From vjs@rhyolite.denver.sgi.com Thu Jan 12 16:59:30 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id QAA02878 for ; Thu, 12 Jan 1995 16:59:29 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@merit.edu> id NAA29559; Thu, 12 Jan 1995 13:59:24 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA00636; Thu, 12 Jan 95 14:58:45 -0700 Date: Thu, 12 Jan 95 14:58:45 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501122158.AA00636@rhyolite.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: termination reasons > From: fred@cisco.com (Fred Baker) > ... > >2) 'Normal' termination could occur in a variety of flavors -- callback, > >time expired, user-requested, administrator-request, etc. I think it's > >important for the user, and useful for the implementation, to be informed of > >the termination reason. > > Maybe, but I observe that X.25, X.21, etc. don't do that. They have one > "normal" termination and any number of error terminations. If a termination > is normal, then the software should know what would constitute a normal > termination in the case. ... > ... > The thing I think is being missed here is that, with one exception (an LQM > failure) a TERMINATE is *always* a normal termination. ... > ... > Handling an LQM drop shouldn't be a major exercise - both sides can see > that there has been a major data loss. In such a case, maybe the PPP driver > should say "the other end dropped the line and I had observed a major data > loss. Please check your hardware." And by the way, gee whiz, suppose that > we updated LQM with a message or flag value that indicates "I am about to > send you an LCP TERMINATE, the reason I will send it is data loss." > > What might be helpful in this discussion would be some real world evidence > (anecdotes, specific cases where the protocol has a normal termination > can't be worked out, etc.). We're at a pretty high philosophical level > here, and neither side of the debate seems to be able to convince the other. There are not 2, but several positions, including at least: 1. it is good, when convenient, to stick some ASCII text into your Terminate-Requests to make debugging easier for (human) packet trace decoders. 2. Terminate-Requests "SHOULD" (or maybe even "MUST") use include one of several reason indications, chosing from a list to be published in an RFC. 3. same as (2), except that the reasons must be single octets instead of ASCII. 4. There is no reason to put anything into Terminate-Requests I favor (1). If all implementations were correct, and correctly installed and configured, and offered good packet and state traces, then no additional information would be necessary. In the real world, every clue you can get is important, and nothing, emphatically not the Standards bureaucracy machinery of registering reasons for (2) or (3), should get in the way. I've been receiving many packet traces in recent months, including - the ISDN router box that sometimes resonds to the first Configure-Request with Terminate-Requests. They contain a peculiar ASCII message that could not be standardized and means nothing to me, but it instantly tells other people that the box is mis-configured and/or has new firmware installed. - one yesterday from an "Internet Provider using PC's" in Europe. They reject the offer of magic numbers, and respond to subsequent Configure-Requests with Configure-NAKs of length 4. (Today it was pointed out that I have failed to implement the ESP option in RFC 9972.) - the "passive ISDN cards" for PC's popular in Europe that miss short, fast packets and so never get to Opened. - the box of the big ISDN router/bridge vendor that responds with a Configure-Reject when you would expect a Configure-Nak, and subsequently responds to everything with Terminate-Requests, including Terminate-Acks to their requests and your own Terminate-Requests. If they would put some text in those bogus Terminate-Requests, I might have a clue about what is going on. - the box of a big router vendor that does not understand the MTU option, and so does not work with the implementation of a nameless workstation vendor that insists on sending the MTU option even for 1500. vjs From fred@cisco.com Thu Jan 12 18:49:45 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.3.143]) by merit.edu (8.6.9/merit-2.0) with ESMTP id SAA04463 for ; Thu, 12 Jan 1995 18:49:44 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id PAA26255; Thu, 12 Jan 1995 15:49:00 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jan 1995 15:49:12 -0800 To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) From: fred@cisco.com (Fred Baker) Subject: Re: termination reasons Cc: ietf-ppp@MERIT.EDU At 1:58 PM 1/12/95, Vernon Schryver wrote: > 1. it is good, when convenient, to stick some ASCII text into your > Terminate-Requests to make debugging easier for (human) > packet trace decoders. > > 2. Terminate-Requests "SHOULD" (or maybe even "MUST") use include > one of several reason indications, choosing from a list to > be published in an RFC. > > 3. same as (2), except that the reasons must be single octets > instead of ASCII. > > 4. There is no reason to put anything into Terminate-Requests > >I favor (1). If all implementations were correct, and correctly >installed and configured, and offered good packet and state traces, >then no additional information would be necessary. In the real world, >every clue you can get is important, and nothing, emphatically not the >Standards bureaucracy machinery of registering reasons for (2) or (3), >should get in the way. Gurdeep and I have been having a private exchange, in which I have attempted to express my views about upper and lower layers, and he has attempted to disabuse me of any notions of the kind. :^) I guess my feeling is that it won't hurt anybody if there is ASCII text there that is universally ignored. I'm not sure how to reliably insert that in the standard without breaking a lot of things that shouldn't be broken. But I can see the point of folks documenting this as Good Programming Practice. One approach that we haven't explored: I am currently playing games with the RREQ draft; I could put a statement similar to #1 into that. Like Bill, I really can't see updating the LCP Specification at this point to add this text to it. Opinions? Does this adequately solve the problem without stabbing people in the back? From vjs@rhyolite.denver.sgi.com Thu Jan 12 20:45:19 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id UAA05358 for ; Thu, 12 Jan 1995 20:45:19 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@MERIT.EDU> id RAA09048; Thu, 12 Jan 1995 17:45:08 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@MERIT.EDU id AA01852; Thu, 12 Jan 95 18:44:31 -0700 Date: Thu, 12 Jan 95 18:44:31 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501130144.AA01852@rhyolite.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: termination reasons > From: fred@cisco.com (Fred Baker) > ... > I guess my feeling is that it won't hurt anybody if there is ASCII text > there that is universally ignored. I'm not sure how to reliably insert that > in the standard without breaking a lot of things that shouldn't be broken. > But I can see the point of folks documenting this as Good Programming > Practice. > > One approach that we haven't explored: I am currently playing games with > the RREQ draft; I could put a statement similar to #1 into that. > > Like Bill, I really can't see updating the LCP Specification at this point > to add this text to it. > > Opinions? Does this adequately solve the problem without stabbing people in > the back? > ... Router requirements would be an odd place to look for hints about how to build the familar Internet Super Info Highway On Ramp In A Box On A PC, or any workstation vendor's product. Besides, I have the impression from router guys that host guys like me would be getting above their station in life by reading a router standard. I favor words in some RFC somewhere like: It is really swell when sending PPP Terminate Requests to include informative ASCII text in the Data field. In some cases, such as Terminate Requests resulting from some PPP FSM transitions, no text is necessary. When swell text is included in a Terminate Request, it is even sweller when strings from the following list are used: 01-operator shutdown 02-inactivity timeout ... The ASCII digits at the start of the strings let other implementations simplistically and mechanically translate some messages. (I trust everyone who cares knows how to convert 2 ASCII digits to binary with about 3 8086 instructions.) The use of cliches and the ASCII digits help non-English speaking people manually translate the messages, sometimes by looking up the message, number, or cliches in a vendor's documentation. The weasel words do not constrain any implementation from more or (just as important) less ASCII text or from using binary codes. By the way, I don't know the IETF Standard words for "swell" and "really swell." Could they be "SWELL" and "FAAAANNTASTIC"? Vernon Schryver, vjs@sgi.com From fred@cisco.com Fri Jan 13 01:17:20 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.3.143]) by merit.edu (8.6.9/merit-2.0) with ESMTP id BAA07414 for ; Fri, 13 Jan 1995 01:17:19 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id WAA03096; Thu, 12 Jan 1995 22:16:45 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jan 1995 22:16:48 -0800 To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) From: fred@cisco.com (Fred Baker) Subject: Re: termination reasons Cc: ietf-ppp@MERIT.EDU At 5:44 PM 1/12/95, Vernon Schryver wrote: >Router requirements would be an odd place to look for hints about >how to build the familiar Internet Super Info Highway On Ramp In A Box >On A PC, or any workstation vendor's product. OK, I tried. What can I say? I don't see the point of opening up the Nth revision of an RFC, which has run the gauntlet and finally just very recently been bronzed for posterity to add listen guys, no-one has to do it, but we think it might be a really swell idea... Fact is, there are a number of hints and ideas of this type in the Host Requirements document (1122/1123) - that's its purpose - except that it got a number of points really wrong in some really bad ways. Router Requirements updated those, because the router guys were really worried about getting it right. (Not that the HR guys weren't, sheesh, how do you say that without offending somebody?). There's some talk about breaking the link layer parts out of both, and making a separate updated "link layer requirements document." I have no plan to do that, but the fact is that in both there is a fair amount of "we finalized the spec years ago and we're not going to open it up to add usage notes - but do this, just do it, please." >I have the >impression from router guys that host guys like me would be getting >above their station in life by reading a router standard. Those router guys, what will we ever do with them :^) :^) :^) >By the way, I don't know the IETF Standard words for "swell" and "really >swell." Could they be "SWELL" and "FAAAANNTASTIC"? I don't know. I like the capitals, that's probably one of the more important parts of such a specification. But I had a little difficulty finding "FAAAANNTASTIC" in my 1941 Oxford English Dictionary (urp, no, that's the OSI side of the house, sorry, looking...). I think more common IETF-ese would be MAY, SHOULD, MUST IMPLEMENT, or MUST. They mean, respectively, "we think it's OK if you do," "it will work correctly without this, but it probably won't work well," "listen up, you really need to implement this," and "it won't work correctly if you don't." Sounds like a SHOULD, based on the diagnostic improvement. From mo@wipinfo.soft.net Fri Jan 13 06:03:28 1995 Received: from s.wipinfo.soft.net (s.wipinfo.soft.net [164.164.6.6]) by merit.edu (8.6.9/merit-2.0) with SMTP id GAA09441 for ; Fri, 13 Jan 1995 06:03:22 -0500 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA15433; Fri, 13 Jan 95 11:08:17 GMT Received: by comm10. (4.1/SMI-4.0) id AA02097; Fri, 13 Jan 95 16:32:37 IST Date: Fri, 13 Jan 95 16:32:37 IST From: mo@wipinfo.soft.net (Monty S Gill) Message-Id: <9501131132.AA02097@comm10.> Apparently-To: ietf-ppp@merit.edu P3er's I am using the LZW data compression algorithm over serial links to enhance the performance of my router. I would like it to be a negotiable LCP or *CP parameter.Is there any such application which does this/ Is there a standard for negotiating data compression parameters? Thanx Bill, Vernon, Karl, Fred and the gang... Mo mo@wipinfo.soft.net From mo@wipinfo.soft.net Fri Jan 13 06:32:52 1995 Received: from s.wipinfo.soft.net (s.wipinfo.soft.net [164.164.6.6]) by merit.edu (8.6.9/merit-2.0) with SMTP id GAA09652 for ; Fri, 13 Jan 1995 06:32:48 -0500 Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA15500; Fri, 13 Jan 95 11:37:53 GMT Received: by comm10. (4.1/SMI-4.0) id AA02205; Fri, 13 Jan 95 17:02:12 IST From: mo@wipinfo.soft.net (Monty S Gill) Message-Id: <9501131202.AA02205@comm10.> Subject: Data Compression Negotiable options To: ietf-ppp@merit.edu Date: Fri, 13 Jan 1995 17:02:11 +0500 (IST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 358 P3er's I am using the LZW data compression algorithm over serial links to enhance the performance of my router. I would like it to be a negotiable LCP or *CP parameter.Is there any such application which does this/ Is there a standard for negotiating data compression parameters? Thanx Bill, Vernon, Karl, Fred and the gang... Mo mo@wipinfo.soft.net From bill.simpson@um.cc.umich.edu Fri Jan 13 07:32:47 1995 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-18.dialip.mich.net [141.211.7.154]) by merit.edu (8.6.9/merit-2.0) with SMTP id HAA10114 for ; Fri, 13 Jan 1995 07:32:44 -0500 Date: Fri, 13 Jan 95 10:21:32 GMT From: "William Allen Simpson" Message-ID: <3701.bill.simpson@um.cc.umich.edu> To: ietf-ppp@MERIT.EDU Reply-to: bsimpson@morningstar.com Subject: Re: termination reasons > > 1. it is good, when convenient, to stick some ASCII text into your > > Terminate-Requests to make debugging easier for (human) > > packet trace decoders. > > > I guess my feeling is that it won't hurt anybody if there is ASCII text > there that is universally ignored. I'm not sure how to reliably insert that > in the standard without breaking a lot of things that shouldn't be broken. > But I can see the point of folks documenting this as Good Programming > Practice. > > One approach that we haven't explored: I am currently playing games with > the RREQ draft; I could put a statement similar to #1 into that. > Seems an odd place to put it. Perhaps when Link-Layer Requirements is split out. > Like Bill, I really can't see updating the LCP Specification at this point > to add this text to it. > Hear, Hear. > Opinions? Does this adequately solve the problem without stabbing people in > the back? > Actually, last year I started a PPP implementors guide. I haven't finished it because, well, I've been working on 11 other drafts.... I'll add the sentiments of (1) into that draft. And I promise to have something for us to talk about in Danvers. Bill.Simpson@um.cc.umich.edu From vjs@rhyolite.denver.sgi.com Fri Jan 13 11:36:18 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id LAA13470 for ; Fri, 13 Jan 1995 11:36:16 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@Merit.edu> id IAA06283; Fri, 13 Jan 1995 08:36:03 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@Merit.edu id AA03979; Fri, 13 Jan 95 09:25:29 -0700 Date: Fri, 13 Jan 95 09:25:29 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501131625.AA03979@rhyolite.denver.sgi.com> To: ietf-ppp@Merit.edu Subject: default MTU changes Some people at Silicon Graphics have been asking me about the prospects of the default PPP MTU being changed to something small. It sounds as if someone is telling some kind of video standards committee for H.whatever some surprising things: ] We had been told that there was a strong leaning among the IETF PPP/ISDN ] crowd towards a much smaller number (less than 512 bytes) for the typical ] or default MTU for PPP/ISDN. I told the SGI people that RFC 1661 is extremely unlike to be changed in the next 12 months for any purpose, and that there are other reasons that make a change in the default MTU even less likely. Let me list some of my reasons here in case the source of those statements apparently given the video standards committee is listening here: - very small MTUs have bad effects on throughput, causing many more TCP headers on traffic originated at one of the ends of the PPP link. - very small MTUs have bad effects by increasing IP fragmentation. - as far as I can tell, the consensus among video over IP people is that 56Kbit/sec is minimumal, except that a lot seem to think 112 Kbps is the minimum (2 B channels). The common MTU for 56K and larger leased lines seems to be at least 1500, so it would make no sense to use a smaller MTU for PPP over ISDN. - smaller MTUs do not significantly help the latency of other traffic if the PPP implementation does some kind of TOS queuing, whether based on packet size, port numbers, or IP TOS bits. - some PPP implementations by major router vendors as well as some PC implementations support only 1500 now. Interoperability concerns mean that the default PPP MTU cannot be changed for the foreseeable future. Vernon Schryver, vjs@sgi.com From bill.simpson@um.cc.umich.edu Fri Jan 13 14:18:21 1995 Received: from Bill.Simpson.DialUp.Mich.Net (pm036-14.dialip.mich.net [141.211.7.56]) by merit.edu (8.6.9/merit-2.0) with SMTP id OAA15280 for ; Fri, 13 Jan 1995 14:18:20 -0500 Date: Fri, 13 Jan 95 18:57:27 GMT From: "William Allen Simpson" Message-ID: <3707.bill.simpson@um.cc.umich.edu> To: ietf-ppp@MERIT.EDU Reply-to: bsimpson@morningstar.com Subject: Re: default MTU changes > ] We had been told that there was a strong leaning among the IETF PPP/ISDN > ] crowd towards a much smaller number (less than 512 bytes) for the typical > ] or default MTU for PPP/ISDN. > Actually, the push is to _higher_ MTUs for ISDN. That's why RFC-1618 explicitly discusses when to switch to a greater than 1500 MTU. There is no movement towards a smaller MTU. In fact, the IPv6 folks recently decided that the minimal MTU for IPng will be 1500! Bill.Simpson@um.cc.umich.edu From bill.simpson@um.cc.umich.edu Fri Jan 13 14:18:23 1995 Received: from Bill.Simpson.DialUp.Mich.Net (pm036-14.dialip.mich.net [141.211.7.56]) by merit.edu (8.6.9/merit-2.0) with SMTP id OAA15283 for ; Fri, 13 Jan 1995 14:18:22 -0500 Date: Fri, 13 Jan 95 19:00:56 GMT From: "William Allen Simpson" Message-ID: <3708.bill.simpson@um.cc.umich.edu> To: ietf-ppp@MERIT.EDU Reply-to: bsimpson@morningstar.com Subject: Re: Data Compression Negotiable options > From: mo@wipinfo.soft.net (Monty S Gill) > I am using the LZW data compression algorithm over serial links to > enhance the performance of my router. I would like it to be a > negotiable LCP or *CP parameter.Is there any such application which > does this/ Is there a standard for negotiating data compression > parameters? > Vernon wrote one for Unix Compress. Or, you could use Stac, another LZ variant. Both are free. The PPP Compression CP is long overdue -- see the internet-draft. Bill.Simpson@um.cc.umich.edu From fred@cisco.com Fri Jan 13 14:47:52 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.3.143]) by merit.edu (8.6.9/merit-2.0) with ESMTP id OAA15645 for ; Fri, 13 Jan 1995 14:47:51 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA11258; Fri, 13 Jan 1995 11:47:17 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Jan 1995 11:47:18 -0800 To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) From: fred@cisco.com (Fred Baker) Subject: Re: default MTU changes Cc: ietf-ppp@MERIT.EDU At 8:25 AM 1/13/95, Vernon Schryver wrote: >Some people at Silicon Graphics have been asking me about the prospects >of the default PPP MTU being changed to something small. It sounds as >if someone is telling some kind of video standards committee for >H.whatever some surprising things: > >] We had been told that there was a strong leaning among the IETF PPP/ISDN >] crowd towards a much smaller number (less than 512 bytes) for the typical >] or default MTU for PPP/ISDN. At 10:57 AM 1/13/95, William Allen Simpson wrote: >There is no movement towards a smaller MTU. In fact, the IPv6 folks >recently decided that the minimal MTU for IPng will be 1500! Vernon: Please forward this mailgram to your favorite video folks. The PPP Working group has had no suggestion from any quarter that a default Maximum Receive Unit smaller than 1500 octets is advisable on ISDN or any other media. We are not contemplating reducing the MRU for ISDN. Fred Baker Chair, PPP Extensions Working Group From fred@cisco.com Fri Jan 13 14:48:00 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.3.143]) by merit.edu (8.6.9/merit-2.0) with ESMTP id OAA15669 for ; Fri, 13 Jan 1995 14:48:00 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id LAA11251; Fri, 13 Jan 1995 11:47:03 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Jan 1995 11:47:11 -0800 To: mo@wipinfo.soft.net (Monty S Gill) From: fred@cisco.com (Fred Baker) Subject: Re: Unidentified subject! Cc: ietf-ppp@MERIT.EDU At 8:32 AM 1/13/95, Monty S Gill wrote: >I am using the LZW data compression algorithm over serial links to >enhance the performance of my router. I would like it to be a >negotiable LCP or *CP parameter.Is there any such application which >does this/ Is there a standard for negotiating data compression >parameters? look at the compression draft and its associated FYIs. There are several folks using this, and someday it will actually get a number. From vjs@rhyolite.denver.sgi.com Fri Jan 13 15:11:32 1995 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.9/merit-2.0) with ESMTP id PAA15983 for ; Fri, 13 Jan 1995 15:11:31 -0500 Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI) id MAA19622; Fri, 13 Jan 1995 12:10:12 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:mo@wipinfo.soft.net id AA04840; Fri, 13 Jan 95 13:09:37 -0700 Date: Fri, 13 Jan 95 13:09:37 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501132009.AA04840@rhyolite.denver.sgi.com> To: mo@wipinfo.soft.net (Monty S Gill) Subject: Data Compression Negotiable options Cc: ietf-ppp@merit.edu >From: mo@wipinfo.soft.net (Monty S Gill) >I am using the LZW data compression algorithm over serial links to >enhance the performance of my router. I would like it to be a >negotiable LCP or *CP parameter.Is there any such application which >does this/ Is there a standard for negotiating data compression >parameters? Rumor has it that the (or just an?) Austrailian freeware PPP implementation has been seen in the U.S. running on MicroVax's, NetBSD 1.0 on PC's, and some other platform that slips my mind, and that it includes CCP and "BSD Compress". If your router is a PC, that code might be directly applicable. Vernon Schryver, vjs@sgi.com From gurdeep@microsoft.com Fri Jan 13 15:18:36 1995 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.9/merit-2.0) with SMTP id PAA16146; Fri, 13 Jan 1995 15:18:35 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA07125; Fri, 13 Jan 95 12:18:57 -0800 Message-Id: <9501132018.AA07125@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Fri, 13 Jan 95 12:18:57 PST X-Msmail-Message-Id: 6999DC4D X-Msmail-Conversation-Id: 6999DC4D From: Gurdeep Singh Pall To: ietf-ppp@MERIT.EDU, ietf-ppp-request@MERIT.EDU Date: Fri, 13 Jan 95 12:05:26 TZ Subject: Re: termination reasons Vernon writes: |I favor words in some RFC somewhere like: | | It is really swell when sending PPP Terminate Requests to include | informative ASCII text in the Data field. In some cases, such as | Terminate Requests resulting from some PPP FSM transitions, no text | is necessary. When swell text is included in a Terminate Request, | it is even sweller when strings from the following list are used: | | 01-operator shutdown | 02-inactivity timeout | ... | |The ASCII digits at the start of the strings let other implementations |simplistically and mechanically translate some messages. (I trust |everyone who cares knows how to convert 2 ASCII digits to binary |with about 3 8086 instructions.) Let me present my original proposal with ASCII string in the Data field, in what I think (like Fred says: I don't claim any special gifts in this area) is more in line with rfc format. It is swell when PPP Terminate Requests use the following format to indicate termination reason to the peer. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | Data +-+-+-+-+-+-+-+-+-+-+-+ Reason 0 disconnection due to idle timeout 1 disconnection due to administrator request 2 disconnection due to network condition (???) 3 <------ your favorite reason goes here etc. Data An ASCII string describing the problem. The following strings are recommended, For Reason 0 use "idle timeout" 1 use "operator timeout" 2 etc. IMHO this addresses our need of getting a "standard" code for a disconnection - and Vernon and others need for a easily readable ASCII string. (I'm assuming that Vernon will not have an objection to putting the preceding codes as numbers - since he will have an informative ASCII string anyway). From fred@cisco.com Fri Jan 13 19:59:28 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.3.143]) by merit.edu (8.6.9/merit-2.0) with ESMTP id TAA19834 for ; Fri, 13 Jan 1995 19:59:27 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id QAA20103; Fri, 13 Jan 1995 16:58:52 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Jan 1995 16:58:56 -0800 To: ietf-ppp@merit.edu From: fred@cisco.com (Fred Baker) Subject: Re: ppp things Cc: topolcic@bbn.com I have been trying to determine the current status of the various items in the pipeline, and Claudio tells me: > By the way, there was also a NBFCP in the queue that I had >sent back a bunch of comments (some substantally more than just >editoral) to Thomas Dimitri and I have also not received a reply. Do >you know differently? Thomas Dimitri no longer works for Microsoft, so tommyd@microsoft.com is not a working address. Who owns this now? Is it a dead draft? From fred@cisco.com Fri Jan 13 20:00:03 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.3.143]) by merit.edu (8.6.9/merit-2.0) with ESMTP id UAA19863 for ; Fri, 13 Jan 1995 20:00:03 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id QAA20106; Fri, 13 Jan 1995 16:58:58 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Jan 1995 16:59:01 -0800 To: Mark Lundquist From: fred@cisco.com (Fred Baker) Subject: Re: rfc-1661, async character map Cc: ietf-ppp@merit.edu Mark: I believe that you'll find what you're looking for in section 7.1 of RFC 1662. Fred At 4:24 PM 1/13/95, Mark Lundquist wrote: >Dear Mr. Baker: > >I'm working on a PPP implementation, and I have a question about >the Async Map. I'm posted it to comp.protocols.ppp, but there's no >telling when I might get an answer there...so I wanted to ask you as >well. I'm enclosing my posting. Any answer you can give would help >me out a lot... > >Newsgroups: comp.protocols.ppp >Subject: rfc-1661, async character map > >I have a question about negotiating the Async Control Character Map in >the Link Control Protocol per rfc-1661. > >In rfc-1661, the AACM Configuration Option that was present in the >earlier PPP rfcs (e.g. rfc-1331) as option code "2", is missing. > >Does that mean that the AACM is no longer configurable via LCP? > >In rfc-1662, "PPP in HDLC-like Framing", the description of the AACM >(in Section 7.1) makes it clear that this it should be negotiable. > >What gives? > >I'd appreciate any help... >Thanks, > >Mark Lundquist >Rational Software Corporation From blaine@sonicsys.com Sat Jan 14 13:47:58 1995 Received: from mail.sonicsys.com (mail.sonicsys.com [199.2.23.98]) by merit.edu (8.6.9/merit-2.0) with ESMTP id NAA24161 for ; Sat, 14 Jan 1995 13:47:56 -0500 Received: from [199.2.23.3] by mail.sonicsys.com with SMTP (MailShare 1.0b8); Sat, 14 Jan 1995 10:57:09 +0000 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 14 Jan 1995 10:47:40 -0800 To: ietf-ppp@MERIT.EDU From: blaine@sonicsys.com (Blaine Kubesh) Subject: AppleTalk Bridging vs. Routing over PPP Link Cc: bob Would anyone care to share any insight you might have regarding bridging vs. routing over a PPP link using a dynamic address protocol such as AppleTalk. With each side of the PPP link being a local area network. What are some ways to handle the duplicate addresses that may occur. One cannot assume that when the link is established, every node on the link will reboot to resolve any conflict. Routing would solve this problem by configuring unique AppleTalk network numbers on each side fo the link. One pain with routing, it is configurable only by a system administrator who knows the network setup of the LAN. You also need a half-router on each end of the link. Bridging has some merits in that it does not need to be configured by an administrator. Bridging does not handle the duplicate addressing without using some address tricks. One way might be to build an address proxy table and convert addresses on one side to addresses that you know are unique on the other. One major limitation to this is that you then have a finite number of addresses you can proxy on the link. Has anybody else thought about this? I would like to hear from you if you have any comment. Regards, -Blaine Kubesh From gurdeep@microsoft.com Sat Jan 14 19:59:40 1995 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.9/merit-2.0) with SMTP id TAA26479; Sat, 14 Jan 1995 19:59:40 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA22081; Sat, 14 Jan 95 17:00:07 -0800 Message-Id: <9501150100.AA22081@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sat, 14 Jan 95 17:00:07 PST X-Msmail-Message-Id: 03B2B442 X-Msmail-Conversation-Id: 03B2B442 From: Gurdeep Singh Pall To: ietf-ppp@MERIT.EDU, ietf-ppp-request@MERIT.EDU Date: Sat, 14 Jan 95 16:56:32 TZ Subject: Re: ppp things Cc: topolcic@bbn.com Please direct all NBFCP questions to me. (gurdeep@microsoft.com) ---------- | From: Fred Baker | To: | Cc: | Subject: Re: ppp things | Date: Friday, January 13, 1995 4:58PM | | Received: from merit.edu by netmail.microsoft.com with SMTP (5.65/25-eef) | id AA07732; Fri, 13 Jan 95 17:00:30 -0800 | Received: (from slist@localhost) by merit.edu | (8.6.9/merit-2.0) id TAA19850; Fri, 13 Jan 1995 19:59:31 -0500 | Resent-Date: Fri, 13 Jan 1995 19:59:31 -0500 | X-Sender: fred@stilton.cisco.com | Message-Id: | Mime-Version: 1.0 | Content-Type: text/plain; charset="us-ascii" | Resent-Message-Id: <"kVldM2.0.1s4.n7o5l"@merit.edu> | Resent-From: ietf-ppp@MERIT.EDU | X-Mailing-List: archive/latest/49 | X-Loop: ietf-ppp@MERIT.EDU | Precedence: list | Resent-Sender: ietf-ppp-request@MERIT.EDU | | I have been trying to determine the current status of the various items in | the pipeline, and Claudio tells me: | | > By the way, there was also a NBFCP in the queue that I had | >sent back a bunch of comments (some substantally more than just | >editoral) to Thomas Dimitri and I have also not received a reply. Do | >you know differently? | | Thomas Dimitri no longer works for Microsoft, so tommyd@microsoft.com is | not a working address. Who owns this now? Is it a dead draft? | | | From jay@gordian.com Sat Jan 14 20:14:31 1995 Received: from gordius.gordian.com (gordius.gordian.com [192.73.220.81]) by merit.edu (8.6.9/merit-2.0) with ESMTP id UAA26705 for ; Sat, 14 Jan 1995 20:14:19 -0500 Received: from chaos (chaos.gordian.com [192.73.220.110]) by gordius.gordian.com (8.6.9/8.6.5) with SMTP id RAA09383 for <@gordius.gordian.com:ietf-ppp@merit.edu>; Sat, 14 Jan 1995 17:13:40 -0800 Received: by chaos (920330.SGI/920502.SGI) for @gordius.gordian.com:ietf-ppp@merit.edu id AA29422; Sat, 14 Jan 95 17:13:39 -0800 Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.chaos.sgi.4d via MS.5.6.chaos.sgi_4d; Sat, 14 Jan 1995 17:13:39 -0800 (PST) Message-Id: <0j67P330GRli5mSVMe@chaos> Date: Sat, 14 Jan 1995 17:13:39 -0800 (PST) From: Jay Laefer To: ietf-ppp@merit.edu Subject: IPCP for IPng This may be jumping the gun, but has anyone given thought to revamping IPCP for IPv6? I just finished going through RFC 1752 (Recommendation for IPng), and when I got to section 18, Impact on Other IETF Standards, I noticed that PPP was totally ignored. At the very least, IPCP needs a new address option (this would be the third) that allows for 16 byte addresses. Use of this new option would, of course, preclude use of Van Jacobson TCP compression. Are there any new options that need to be added to deal with IPv6? And did I just volunteer to write the new draft? -Jay Laefer jay@gordian.com From bill.simpson@um.cc.umich.edu Sun Jan 15 06:48:05 1995 Received: from Bill.Simpson.DialUp.Mich.Net (pm002-01.dialip.mich.net [141.211.7.137]) by merit.edu (8.6.9/merit-2.0) with SMTP id GAA28967 for ; Sun, 15 Jan 1995 06:48:02 -0500 Date: Sun, 15 Jan 95 09:48:02 GMT From: "William Allen Simpson" Message-ID: <3734.bill.simpson@um.cc.umich.edu> To: ietf-ppp@MERIT.EDU Reply-to: bsimpson@morningstar.com Subject: Re: IPCP for IPng > From: Jay Laefer > At the very least, IPCP needs a new address option (this would be the > third) that allows for 16 byte addresses. Use of this new option would, > of course, preclude use of Van Jacobson TCP compression. > Yes. I've put some thought into it. The reason we needed IPCP to assign addresses was the lack of an IPv4 mechanism. OSINCP doesn't have an address assignment, because ES-IS has its own mechanism. Since IPv6 (supposedly) incorporates auto-configuration (we have a WG), IPCP won't need a new address assignment Option. Also, I've written a replacement header compression draft for IPv6. draft-simpson-ipv6-hc-00.txt > Are there any new options that need to be added to deal with IPv6? And > did I just volunteer to write the new draft? > Well, we've seen the need to update for over a year. The original author hasn't. Somebody else volunteered 8 months ago. Every so often, I bug Fred about the fact nothing has been written. If nobody else does, I'll post something next week. Bill.Simpson@um.cc.umich.edu From Robert_Jeckell@3mail.3Com.COM Sun Jan 15 22:36:43 1995 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.9/merit-2.0) with ESMTP id WAA02833 for ; Sun, 15 Jan 1995 22:36:42 -0500 Received: from cixgate by relay2.UU.NET with SMTP id QQxywk14335; Sun, 15 Jan 1995 22:36:39 -0500 Received: from gw.3Com.COM by cixgate (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA10736; Mon, 16 Jan 95 03:41:04 GMT Received: from hqsmtp.OPS.3Com.COM by gw.3Com.COM with SMTP id AA10558 (5.65c/IDA-1.4.4 for ); Sun, 15 Jan 1995 19:36:38 -0800 Received: by hqsmtp.ops.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA3027; Sun, 15 Jan 95 19:37:10 -0800 Message-Id: <9501160337.AA3027@hqsmtp.ops.3com.com> Received: from 3Com with "Lotus Notes Mail Gateway for SMTP" id 39D46D351BF394A188256146001257D2; Sun, 15 Jan 95 19:37:03 To: Blaine Kubesh Cc: ietf-ppp , bob , anf-disc From: Robert Jeckell/HQ/3Com Date: 15 Jan 95 19:35:16 EDT Subject: Re: AppleTalk Bridging vs. Routing over PPP Link Mime-Version: 1.0 Content-Type: Text/Plain Blaine, If I'm not mistaken, the default options for router to router PPP connections specified in the AppleTalk CP spec is for an unnumbered link. This means no network number, no end point addresses to configure or zone information to specify. If you can get two routers that can perform in the specified default settings, then you have little to configure other than enabling the two ports for routing in this mode. Routing, as currently specified in the ATCP spec is certainly the prefered interoperable solution for AppleTalk as your message clearly cries out. Are you assuming that the AppleTalk environments on each end are administered by the same folks? If not, then you may still have network number and zone name duplication that could represent a second level of problems. /bob ----- Previous Message ---------------------------------------------------- To: ietf-ppp @ MERIT.EDU @ UGATE cc: bob @ merit.edu @ UGATE From: blaine @ sonicsys.com (Blaine Kubesh) @ UGATE Date: Saturday January 14, 1995 10:47 AM Subject: AppleTalk Bridging vs. Routing over PPP Link ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Would anyone care to share any insight you might have regarding bridging vs. routing over a PPP link using a dynamic address protocol such as AppleTalk. With each side of the PPP link being a local area network. What are some ways to handle the duplicate addresses that may occur. One cannot assume that when the link is established, every node on the link will reboot to resolve any conflict. Routing would solve this problem by configuring unique AppleTalk network numbers on each side fo the link. One pain with routing, it is configurable only by a system administrator who knows the network setup of the LAN. You also need a half-router on each end of the link. Bridging has some merits in that it does not need to be configured by an administrator. Bridging does not handle the duplicate addressing without using some address tricks. One way might be to build an address proxy table and convert addresses on one side to addresses that you know are unique on the other. One major limitation to this is that you then have a finite number of addresses you can proxy on the link. Has anybody else thought about this? I would like to hear from you if you have any comment. Regards, -Blaine Kubesh From fred@cisco.com Mon Jan 16 00:00:42 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by merit.edu (8.6.9/merit-2.0) with ESMTP id AAA03263; Mon, 16 Jan 1995 00:00:41 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id VAA08638; Sun, 15 Jan 1995 21:00:07 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 Jan 1995 21:00:09 -0800 To: blaine@sonicsys.com (Blaine Kubesh) From: fred@cisco.com (Fred Baker) Subject: Re: AppleTalk Bridging vs. Routing over PPP Link Cc: ietf-ppp@MERIT.EDU, bob@MERIT.EDU At 10:47 AM 1/14/95, Blaine Kubesh wrote: >Would anyone care to share any insight you might have regarding bridging >vs. routing over a PPP link using a dynamic address protocol such as >AppleTalk. With each side of the PPP link being a local area network. What >are some ways to handle the duplicate addresses that may occur. One cannot >assume that when the link is established, every node on the link will >reboot to resolve any conflict. Reality is that both approaches work. Routing solves the problem you allude to and several that you don't, but if bridging is used, in time all of the duplicated nodes do in fact work it out and negotiate new addresses. I know of some fairly large networks that use bridged AppleTalk and whatever else might be said about them, they do in fact work. I would ask, though, why bother? If both solutions are available, and you know for a fact that one is a better solution, should getting the network administrator to do his job slow you down from getting a solid well-designed network? From fred@cisco.com Mon Jan 16 00:00:55 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by merit.edu (8.6.9/merit-2.0) with ESMTP id AAA03291 for ; Mon, 16 Jan 1995 00:00:55 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id VAA08644; Sun, 15 Jan 1995 21:00:14 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 Jan 1995 21:00:16 -0800 To: "William Allen Simpson" , Gurdeep Singh Pall From: fred@cisco.com (Fred Baker) Subject: Re: IPCP for IPng Cc: ietf-ppp@MERIT.EDU At 1:48 AM 1/15/95, William Allen Simpson wrote: >> Are there any new options that need to be added to deal with IPv6? And >> did I just volunteer to write the new draft? >> >Well, we've seen the need to update for over a year. The original >author hasn't. Somebody else volunteered 8 months ago. Every so often, >I bug Fred about the fact nothing has been written. Gurdeep: Would you please post your draft to internet-drafts@cnri.reston.va.us? Bill: I think you are a bit presumptuous. Fred From fred@cisco.com Mon Jan 16 09:00:42 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by merit.edu (8.6.9/merit-2.0) with ESMTP id JAA07016 for ; Mon, 16 Jan 1995 09:00:41 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id GAA08496; Mon, 16 Jan 1995 06:00:02 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Jan 1995 06:00:04 -0800 To: stev@ftp.com, topolcic@bbn.com From: fred@cisco.com (Fred Baker) Subject: documents to Proposed Standard Cc: ietf-ppp@merit.edu Please refer these documents to the IESG for advancement to Proposed Standard. draft-ietf-pppext-vines-02.txt draft-ietf-pppext-xnscp-00.txt draft-ietf-pppext-encryption-01.txt From ranch@montgomery.com Mon Jan 16 11:42:49 1995 Received: from montgomery.com (montgomery.com [199.182.140.3]) by merit.edu (8.6.9/merit-2.0) with SMTP id LAA08652; Mon, 16 Jan 1995 11:42:47 -0500 Message-ID: Date: 16 Jan 1995 08:25:50 -0800 From: "Chris Ranch" Subject: RE: AppleTalk Bridging vs. Routing over PPP Link To: "Blaine Kubesh" , "Robert Jeckell/HQ/3Com" Cc: "anf-disc" , "bob" , "ietf-ppp" X-Mailer: Mail*Link SMTP-MS 3.0.1 Bridging is evil for AppleTalk. Duplicate addresses occur, especially when you're bridging over a congested low speed link. IAT2 specified 10 AARP probes at 200 msec intervals. That means that a probe must be delivered to the node that already has the address, spit out a response, and deliver that response, all within 2 seconds. Everyone does it differently, including various versions of MacOS and AIR. Address proxies are hard to configure and manage. Especially when you're conveying address level information in the ddp payload, like snmp table walks. This is one of the uglinesses in AURP's network number mapping and clustering. Ease of configuration is a non-issue. I would think that inventing a workable address proxy would be a lot harder than writing a router... Chris _______________________________________________________________________________ From: Robert Jeckell/HQ/3Com on Sun, Jan 15, 1995 8:00 PM Subject: Re: AppleTalk Bridging vs. Routing over PPP Link To: Blaine Kubesh Cc: ietf-ppp; bob; anf-disc Blaine, If I'm not mistaken, the default options for router to router PPP connections specified in the AppleTalk CP spec is for an unnumbered link. This means no network number, no end point addresses to configure or zone information to specify. If you can get two routers that can perform in the specified default settings, then you have little to configure other than enabling the two ports for routing in this mode. Routing, as currently specified in the ATCP spec is certainly the prefered interoperable solution for AppleTalk as your message clearly cries out. Are you assuming that the AppleTalk environments on each end are administered by the same folks? If not, then you may still have network number and zone name duplication that could represent a second level of problems. /bob ----- Previous Message ---------------------------------------------------- To: ietf-ppp @ MERIT.EDU @ UGATE cc: bob @ merit.edu @ UGATE From: blaine @ sonicsys.com (Blaine Kubesh) @ UGATE Date: Saturday January 14, 1995 10:47 AM Subject: AppleTalk Bridging vs. Routing over PPP Link ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Would anyone care to share any insight you might have regarding bridging vs. routing over a PPP link using a dynamic address protocol such as AppleTalk. With each side of the PPP link being a local area network. What are some ways to handle the duplicate addresses that may occur. One cannot assume that when the link is established, every node on the link will reboot to resolve any conflict. Routing would solve this problem by configuring unique AppleTalk network numbers on each side fo the link. One pain with routing, it is configurable only by a system administrator who knows the network setup of the LAN. You also need a half-router on each end of the link. Bridging has some merits in that it does not need to be configured by an administrator. Bridging does not handle the duplicate addressing without using some address tricks. One way might be to build an address proxy table and convert addresses on one side to addresses that you know are unique on the other. One major limitation to this is that you then have a finite number of addresses you can proxy on the link. Has anybody else thought about this? I would like to hear from you if you have any comment. Regards, -Blaine Kubesh ------------------ RFC822 Header Follows ------------------ Received: by montgomery.com with SMTP;15 Jan 1995 20:00:34 -0800 Received: (daemon@localhost) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) id TAA01995 for outbound-anf-disc; Sun, 15 Jan 1995 19:37:04 -0800 Received: from netcom15.netcom.com (daemon@netcom15.netcom.com [192.100.81.128]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with ESMTP id TAA01977 for ; Sun, 15 Jan 1995 19:36:57 -0800 Received: by netcom15.netcom.com (8.6.9/Netcom) id TAA17833; Sun, 15 Jan 1995 19:36:08 -0800 Received: from relay2.UU.NET by netcom15.netcom.com (8.6.9/Netcom) id TAA17823; Sun, 15 Jan 1995 19:36:05 -0800 Received: from cixgate by relay2.UU.NET with SMTP id QQxywk14348; Sun, 15 Jan 1995 22:36:44 -0500 Received: from gw.3Com.COM by cixgate (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA10742; Mon, 16 Jan 95 03:41:08 GMT Received: from hqsmtp.OPS.3Com.COM by gw.3Com.COM with SMTP id AA10566 (5.65c/IDA-1.4.4 for ); Sun, 15 Jan 1995 19:36:42 -0800 Received: by hqsmtp.ops.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA3031; Sun, 15 Jan 95 19:37:14 -0800 Message-Id: <9501160337.AA3031@hqsmtp.ops.3com.com> Received: from 3Com with "Lotus Notes Mail Gateway for SMTP" id 39D46D351BF394A188256146001257D2; Sun, 15 Jan 95 19:37:03 To: Blaine Kubesh Cc: ietf-ppp , bob , anf-disc From: Robert Jeckell/HQ/3Com Date: 15 Jan 95 19:35:16 EDT Subject: Re: AppleTalk Bridging vs. Routing over PPP Link Mime-Version: 1.0 Content-Type: Text/Plain X-Deleted-Errors-To: anf-disc-request@cisco.com X-Comment: List additions/deletions to: anf-disc-request@cisco.com X-Disclaimer: The use of cisco machines does not mean that X-Disclaimer: postings made to this mailing list are the X-Disclaimer: official opinions of cisco Systems, Inc. Precedence: bulk From owner-ietf-ppp@franc.ucdavis.edu Mon Jan 16 11:48:32 1995 Received: from franc.ucdavis.edu (franc.ucdavis.edu [128.120.8.183]) by merit.edu (8.6.9/merit-2.0) with ESMTP id LAA08741 for ; Mon, 16 Jan 1995 11:48:31 -0500 Received: from matrox.Matrox.COM by franc.ucdavis.edu (8.6.9/UCD3.0) id IAA01229; Mon, 16 Jan 1995 08:47:33 -0800 Received: from focus.Matrox.COM by matrox.Matrox.COM with SMTP id AA26106 (5.65c8/IDA-1.4.4 for ); Mon, 16 Jan 1995 11:48:23 -0500 Received: by focus.matrox.com (4.1/SMI-4.1) id AA23104; Mon, 16 Jan 95 11:48:23 EST Date: Mon, 16 Jan 95 11:48:23 EST Message-Id: <9501161648.AA23104@focus.matrox.com> From: Ted.Sadi@Matrox.COM (Ted Sadi) To: ietf-ppp@ucdavis.edu Subject: PPP in Frame Relay In reference to the Internet Draft, October 1993, about PPP in Frame Relay, please inform me of any sites where I can find more information about Frame Relay. From owner-ietf-ppp@franc.ucdavis.edu Mon Jan 16 13:07:33 1995 Received: from franc.ucdavis.edu (franc.ucdavis.edu [128.120.8.183]) by merit.edu (8.6.9/merit-2.0) with ESMTP id NAA09827 for ; Mon, 16 Jan 1995 13:07:32 -0500 Received: from maelstrom.acton.timeplex.com by franc.ucdavis.edu (8.6.9/UCD3.0) id KAA04958; Mon, 16 Jan 1995 10:06:34 -0800 Received: from enigma.acton.timeplex.com (enigma.acton.timeplex.com [134.196.22.57]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id NAA08745; Mon, 16 Jan 1995 13:08:25 -0500 Received: from maelstrom.timeplex.com (malis@localhost) by enigma.acton.timeplex.com (8.6.9/ACTON-SUB-1.0) with ESMTP id NAA28794; Mon, 16 Jan 1995 13:08:23 -0500 Message-Id: <199501161808.NAA28794@enigma.acton.timeplex.com> To: Ted.Sadi@Matrox.COM (Ted Sadi) cc: ietf-ppp@ucdavis.edu, malis@maelstrom.Timeplex.COM Subject: Re: PPP in Frame Relay In-reply-to: Your message of "Mon, 16 Jan 1995 11:48:23 EST." <9501161648.AA23104@focus.matrox.com> Date: Mon, 16 Jan 1995 13:08:22 -0500 From: Andy Malis Ted, > Please inform me of any sites where I can find more information > about Frame Relay. A good place to start is http://frame-relay.indiana.edu/, which is the Frame Relay Forum Home Page. Click on "General Frame Relay Information" to find a tutorial. You can also read comp.dcom.frame-relay on Usenet, which is gatewayed to an Internet mailing list - send a subscription request to frame-relay-request@indiana.edu to join. [I thought of just making this a private reply, but figured it might help other PPPers out there. Let's move further general FR conversation to the newsgroup.] Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999 From timh@RNS.COM Tue Jan 17 19:20:13 1995 Received: from Spectrum.RNS.COM (SPECTRUM.RNS.COM [131.143.16.1]) by merit.edu (8.6.9/merit-2.0) with SMTP id TAA26374 for ; Tue, 17 Jan 1995 19:20:10 -0500 Received: by Spectrum.RNS.COM (4.1/SMI-4.1(Spectrum)) id AA09492; Tue, 17 Jan 95 16:14:58 PST Date: Tue, 17 Jan 95 16:14:58 PST From: timh@RNS.COM (Tim Hayes) Message-Id: <9501180014.AA09492@Spectrum.RNS.COM> To: ietf-ppp@merit.edu Subject: IPX compression RFCs Cc: ken@RNS.COM, price@RNS.COM, timh@RNS.COM I am interested in obtaining the most recent documents covering IPX compression over WAN media. Is RFC1553 the most recent ? Are there any other relevant documents ? Thanks Tim Hayes Rockwell Network Systems Santa Barbara CA timh@rns.com From scoya@CNRI.Reston.VA.US Wed Jan 18 10:09:35 1995 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.9/merit-2.0) with SMTP id KAA01072 for ; Wed, 18 Jan 1995 10:09:34 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02336; 18 Jan 95 9:54 EST To: IETF-Announce:; cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call: The PPP Banyan Vines Control Protocol (BVCP) to Proposed Standard Date: Wed, 18 Jan 95 09:54:33 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9501180954.aa02336@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "The PPP Banyan Vines Control Protocol (BVCP)" for the status of 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 iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by January 31, 1995. IESG Secretary From scoya@CNRI.Reston.VA.US Wed Jan 18 10:46:24 1995 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.9/merit-2.0) with SMTP id KAA01444 for ; Wed, 18 Jan 1995 10:46:23 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02469; 18 Jan 95 10:01 EST To: IETF-Announce:; cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call: The PPP XNS IDP Control Protocol (XNSCP) to Proposed Standard Date: Wed, 18 Jan 95 10:01:09 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9501181001.aa02469@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "The PPP XNS IDP Control Protocol (XNSCP)" for the status of 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 iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by January 31, 1995. From scoya@CNRI.Reston.VA.US Wed Jan 18 11:24:18 1995 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.9/merit-2.0) with SMTP id LAA01876 for ; Wed, 18 Jan 1995 11:24:18 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02786; 18 Jan 95 10:08 EST To: IETF-Announce:; cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call: The PPP Encryption Control Protocol (ECP) to Proposed Standard Date: Wed, 18 Jan 95 10:08:22 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9501181008.aa02786@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "The PPP Encryption Control Protocol (ECP)" for the status of 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 iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by January 31, 1995. IESG Secretary From ken@funk.com Wed Jan 18 14:48:49 1995 Received: from funk.Funk.COM (funk.terranet.com [199.103.254.41]) by merit.edu (8.6.9/merit-2.0) with ESMTP id OAA04243 for ; Wed, 18 Jan 1995 14:48:47 -0500 Received: from ken.funk.com (machine-151.Funk.COM [198.186.160.151]) by funk.Funk.COM (8.6.5/FUNK-1.2) with SMTP id OAA02626 for ; Wed, 18 Jan 1995 14:50:22 -0500 Date: Wed, 18 Jan 1995 14:50:22 -0500 Message-Id: <199501181950.OAA02626@funk.Funk.COM> X-Sender: ken@funk.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@merit.edu From: ken@funk.com (Ken Culbert) Subject: Re: termination reasons X-Mailer: Vernon writes: >I favor words in some RFC somewhere like: > > It is really swell when sending PPP Terminate Requests to include > informative ASCII text in the Data field. In some cases, such as > Terminate Requests resulting from some PPP FSM transitions, no text > is necessary. When swell text is included in a Terminate Request, > it is even sweller when strings from the following list are used: .... Gurdeep writes: >Let me present my original proposal with ASCII string in the Data >field, in what I think (like Fred says: I don't claim any special >gifts in this area) is more in line with rfc format. ... >(I'm assuming that Vernon will not have an objection to putting the >preceding codes as numbers - since he will have an informative ASCII >string anyway). We're approaching a consensus?! Should there be an indication that this is a 'standard' message, such as a prefix? Patrick Klos suggested a signature of some kind, followed by the Terminate Reason Code (to make the signature something unlikely to show up in jibberish, like 0x4b 0xb4). Where would this go -- in a new PPP RFC, a termination message RFC, or what? Ken Culbert ken@funk.com Funk Software, Inc. voice: (617) 497-6339 222 Third Street fax: (617) 547-1031 Cambridge, MA 02142 From fred@cisco.com Wed Jan 18 17:49:44 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by merit.edu (8.6.9/merit-2.0) with ESMTP id RAA06380 for ; Wed, 18 Jan 1995 17:49:44 -0500 Received: from [171.69.60.202] (fbaker-mac.cisco.com [171.69.60.202]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id OAA28981; Wed, 18 Jan 1995 14:48:34 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Jan 1995 14:48:36 -0800 To: ken@funk.com (Ken Culbert) From: fred@cisco.com (Fred Baker) Subject: Re: termination reasons Cc: ietf-ppp@MERIT.EDU At 11:50 AM 1/18/95, Ken Culbert wrote: >We're approaching a consensus?! I think we're approaching a consensus that IF we open an RFC to add these words, what the words might be. I think there remain two strongly opposed camps on whether we should open the RFC. The consensus would be strengthened, I think, if the change was substantive. The change is a usage note, nothing more and nothing less. Perhaps those that feel strongly on the matter should mail me (privately) a yea or a nay; if I get more than ten of such, I will summarize to the list. My feeling is that there is nothing now to preclude insertion of whatever you please in the terminate request, and many folks do, so there's no point in opening the RFC to adds the words "you don't have to do it, nobody's going to yell at you if you don't, but it makes things easier to debug if you put some ascii text in the terminate saying why you are teminating." Good grief, just put the text in for your own debugging, and don't take it out when you ship. Bill has suggested that he could include such a comment in a "general implementation and usage notes" draft he's writing. If he wants to do that, I have no objection. From ken@funk.com Thu Jan 19 09:23:04 1995 Received: from funk.Funk.COM (funk.terranet.com [199.103.254.41]) by merit.edu (8.6.9/merit-2.0) with ESMTP id JAA12965 for ; Thu, 19 Jan 1995 09:23:03 -0500 Received: from ken.funk.com (machine-133.Funk.COM [198.186.160.133]) by funk.Funk.COM (8.6.5/FUNK-1.2) with SMTP id JAA08302 for ; Thu, 19 Jan 1995 09:24:48 -0500 Date: Thu, 19 Jan 1995 09:24:48 -0500 Message-Id: <199501191424.JAA08302@funk.Funk.COM> X-Sender: ken@funk.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@merit.edu From: ken@funk.com (Ken Culbert) Subject: Re: termination reasons X-Mailer: >My feeling is that there is nothing now to preclude insertion of whatever >you please in the terminate request, and many folks do, so there's no point >in opening the RFC to adds the words > > "you don't have to do it, nobody's going to yell at you if you > don't, but it makes things easier to debug if you put some ascii > text in the terminate saying why you are teminating." > >Good grief, just put the text in for your own debugging, and don't take it >out when you ship. I have no problem debugging my own product. The point is that it would be very useful to implementors and users alike to have 'standard' termination messages to further the goal of interoperability. Ken Culbert ken@funk.com Funk Software, Inc. voice: (617) 497-6339 222 Third Street fax: (617) 547-1031 Cambridge, MA 02142 From jay@gordian.com Thu Jan 19 19:44:17 1995 Received: from gordius.gordian.com (gordius.gordian.com [192.73.220.81]) by merit.edu (8.6.9/merit-2.0) with ESMTP id TAA21159 for ; Thu, 19 Jan 1995 19:44:16 -0500 Received: from chaos (chaos.gordian.com [192.73.220.110]) by gordius.gordian.com (8.6.9/8.6.5) with SMTP id QAA01745 for <@gordius.gordian.com:ietf-ppp@merit.edu>; Thu, 19 Jan 1995 16:43:41 -0800 Received: by chaos (920330.SGI/920502.SGI) for @gordius.gordian.com:ietf-ppp@merit.edu id AA18788; Thu, 19 Jan 95 16:43:40 -0800 Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.chaos.sgi.4d via MS.5.6.chaos.sgi_4d; Thu, 19 Jan 1995 16:43:40 -0800 (PST) Message-Id: <0j7kQw30GRli8uXvQM@chaos> Date: Thu, 19 Jan 1995 16:43:40 -0800 (PST) From: Jay Laefer To: ietf-ppp@merit.edu Subject: Re: termination reasons > I have no problem debugging my own product. The point is that it would be > very useful to implementors and users alike to have 'standard' termination > messages to further the goal of interoperability. I respectfully disagree. The Terminate-Request message itself *is* the debugging message. If you want to know why it was sent, check the host who sent it for information. Or check your state table. Let's look at the real world situations. Are people really having problems with unexplained Terminate-Requests? Or are they having problems with Configure-Rejects and -Naks? Let's not solve a problem that doesn't exist. As an aside, and this is *not* my main point, I'd like to remind people that some implementors have very real concerns about the space it takes to implement a standard. I don't want to have to spend more and more valuable code space on a bunch of text strings of questionable value. I'd rather put it to use implementing new features and bullet-proofing older ones. (Yes, I know text can be stored compressed.) If you'd like *optional* *suggested* Termination-Request messages, that's fine. Please don't force me to use them. -Jay Laefer jay@gordian.com From roeck@saturn.conware.de Fri Jan 20 02:08:24 1995 Received: from relay.conware.de (relay.conware.de [153.92.1.3]) by merit.edu (8.6.9/merit-2.0) with SMTP id CAA23952 for ; Fri, 20 Jan 1995 02:08:21 -0500 Received: from saturn.conware.de by relay.conware.de with smtp (Smail3.1.28.1 #2) id m0rVDRr-000DzBC; Fri, 20 Jan 95 08:07 MET Received: by saturn.conware.de (/\==/\ Smail3.1.25.1 #25.8) id ; Fri, 20 Jan 95 08:07 MET Message-Id: From: roeck@conware.de (Guenter Roeck) Subject: Re: termination reasons To: ietf-ppp@merit.edu Date: Fri, 20 Jan 95 8:07:54 MET X-Mailer: ELM [version 2.3 PL11] I totally agree with this opinion. All of our problems related to configuring PPP, having PPP accept options it actually does not understand, state machine disbehavior and things like that. During our entire testing and debugging phase, those termination request reason messages would NOT have helped us at all - except to make testing more expensive. Thus, I also suggest to make such messages optional (thus, do not change anything) and keep on with real work. Gunter > > I respectfully disagree. The Terminate-Request message itself *is* the > debugging message. If you want to know why it was sent, check the host > who sent it for information. Or check your state table. > > Let's look at the real world situations. Are people really having > problems with unexplained Terminate-Requests? Or are they having > problems with Configure-Rejects and -Naks? > > Let's not solve a problem that doesn't exist. > > As an aside, and this is *not* my main point, I'd like to remind people > that some implementors have very real concerns about the space it takes > to implement a standard. > > I don't want to have to spend more and more valuable code space on a > bunch of text strings of questionable value. I'd rather put it to use > implementing new features and bullet-proofing older ones. (Yes, I know > text can be stored compressed.) > > If you'd like *optional* *suggested* Termination-Request messages, > that's fine. Please don't force me to use them. > > -Jay Laefer > jay@gordian.com > -------------------------------------------------------------------------- Gunter Rock - Conware GmbH Phone: (0049) 721-9495-0 Internet: roeck@conware.de Fax: (0049) 721-9495-146 -------------------------------------------------------------------------- From fred@cisco.com Fri Jan 20 03:46:16 1995 Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by merit.edu (8.6.9/merit-2.0) with ESMTP id DAA24576 for ; Fri, 20 Jan 1995 03:46:16 -0500 Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id AAA29148 for ; Fri, 20 Jan 1995 00:45:43 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Jan 1995 00:45:45 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Re: termination reasons At 11:07 PM 1/19/95, Guenter Roeck wrote: >Thus, I also suggest to make such messages optional (thus, do not >change anything) and keep on with real work. I have gotten, now, four private messages. The list has seen three more. One was a call for standardization, and the remainder convey Guenter's sense. Bill has offered to include a usage note in his draft indicating that some ASCII text would be nice in the termination message so that someone with a sniffer can figure out what's happening, and that implementations should neither require it to be there nor assume that it is ASCII; it could be binary codes as some implementations use, or it could be the famous non-meaningful pad that PPP permits any message to have. I think the sense of the group is that this is sufficient. From ietf-ppp-request@MERIT.EDU Sat Jan 21 05:20:34 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id FAA01143; Sat, 21 Jan 1995 05:20:34 -0500 Resent-Date: Sat, 21 Jan 1995 05:20:34 -0500 From: mo@wipinfo.soft.net (Monty S Gill) Message-Id: <9501211049.AA00559@comm10.> Subject: Compressed IPX Headers... To: ietf-ppp@MERIT.EDU Date: Sat, 21 Jan 1995 15:49:37 +0500 (IST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 606 Resent-Message-ID: <"_VMly3.0.dH.W_D8l"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/5 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi Gang! Well, my setup involves a remote PC dialing into our router and "attaching" to the Netware Server on the remote LAN. I am able to send Compressed IPX packets (ie. Compressed IPX/NCP Headers RFC 1553) from the client to the File Server via our router. In the Compression process, I am not able to understand the use of Unconfirmed Initials. I do send a Confirmed Initial packet and a Confirm Packet etc..(RFC 1553) but the use of Unconfirmed Initial packets appears to be a bit vague. Could anyone enlighten me please? BTW, is RFC 1553 the latest on CIPX Headers? Monty mo@wipinfo.soft.net - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Jan 22 12:32:24 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id MAA00874; Sun, 22 Jan 1995 12:32:24 -0500 Resent-Date: Sun, 22 Jan 1995 12:32:24 -0500 Date: Sun, 22 Jan 95 09:21:38 GMT From: "William Allen Simpson" Message-ID: <1250.bill.simpson@um.cc.umich.edu> To: ietf-ppp@MERIT.EDU Reply-to: bsimpson@morningstar.com Subject: Re: Compressed IPX Headers... Resent-Message-ID: <"2mZO-3.0.UD.HQf8l"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/6 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: mo@wipinfo.soft.net (Monty S Gill) > via our router. In the Compression process, I am not able to > understand the use of Unconfirmed Initials. I do send a Confirmed > Initial packet and a Confirm Packet etc..(RFC 1553) but the use > of Unconfirmed Initial packets appears to be a bit vague. Could > anyone enlighten me please? > Confirmed are for IPX-only, Unconfirmed are for NCP & IPX. It relies on the re-transmission of NCP, just like VJ relies on TCP re-transmission. > BTW, is RFC 1553 the latest on CIPX Headers? > Yes. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jan 24 12:09:31 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id MAA12851; Tue, 24 Jan 1995 12:09:31 -0500 Resent-Date: Tue, 24 Jan 1995 12:09:31 -0500 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 24 Jan 1995 10:06:53 -0700 From: Michael Allen To: ietf-ppp@MERIT.EDU, mo@wipinfo.soft.net Subject: Compressed IPX Headers... -Reply Resent-Message-ID: <"PMG3Q3.0.L83.ZFJ9l"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/7 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Unconfirmed Initial packets are used for NCP packets. You can get away with unconfirmed since you can tell when an NCP packet is being retransmitted as a duplicate request - the NCP sequence # does not increment as predicted. In this case, you can tell the packet may not have got to the other end and you should send another uncompressed rather than compressed frame. With normal IPX packets, you cannot tell when a retransmission is occurring, and as such, you need to be able to guarentee that the uncompressed header has got to the remote end. That is the reason for the confirmed initial packet. ------------------------------------------------------------------------- Michael Allen Work: (408) 577-8412 Novell Inc. Fax: (408) 577-5761 E-mail: Michael_Allen@novell.com >>> Monty S Gill 01/21/95 02:20am >>> Hi Gang! Well, my setup involves a remote PC dialing into our router and "attaching" to the Netware Server on the remote LAN. I am able to send Compressed IPX packets (ie. Compressed IPX/NCP Headers RFC 1553) from the client to the File Server via our router. In the Compression process, I am not able to understand the use of Unconfirmed Initials. I do send a Confirmed Initial packet and a Confirm Packet etc..(RFC 1553) but the use of Unconfirmed Initial packets appears to be a bit vague. Could anyone enlighten me please? BTW, is RFC 1553 the latest on CIPX Headers? Monty mo@wipinfo.soft.net - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Jan 25 13:10:14 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id NAA11063; Wed, 25 Jan 1995 13:10:14 -0500 Resent-Date: Wed, 25 Jan 1995 13:10:14 -0500 To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: IESG Secretary Subject: Last Call: The PPP DECnet Phase IV Control Protocol (DNCP) to Draft Standard Date: Wed, 25 Jan 95 13:08:59 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9501251309.aa05449@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"AvUFR.0.Ff2.aFf9l"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/8 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "The PPP DECnet Phase IV Control Protocol (DNCP)" for the status of Draft Standard. Note that this document is intended to update RFC 1376. There are a few minor editorial changes from the text in RFC 1376. 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 iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by February 8, 1995. IESG Secretary - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jan 30 20:16:01 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id UAA14753; Mon, 30 Jan 1995 20:16:01 -0500 Resent-Date: Mon, 30 Jan 1995 20:16:01 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 30 Jan 1995 17:12:34 -0800 To: "Jose I. Arevalo" From: fred@cisco.com (Fred Baker) Subject: Re: Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"3wtrr3.0.Ec3.tyOBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/9 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 3:16 PM 1/30/95, Jose I. Arevalo wrote: >I would like to know some details about ppp using ISDN I would suggest that you read RFC 1618 PS W. Simpson, "PPP over ISDN", 05/13/1994. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jan 30 22:03:23 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id WAA19176; Mon, 30 Jan 1995 22:03:23 -0500 Resent-Date: Mon, 30 Jan 1995 22:03:23 -0500 Date: Mon, 30 Jan 95 20:03:04 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501310303.AA09131@rhyolite.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: errors in RFC 1661 and 1717 Resent-Message-ID: <"8t6Hw2.0.Sh4.tXQBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/10 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The top of page 32 of RFC-1661, part of secion 5.4, contains a minor nit: ] be a proper subset of those in the last transmitted Configure- ] Request. Invalid packets are silently discarded. The word "proper" is wrong, since it is reasonable for a Configure- Reject to contain all of the options in the corresponding Configure- Request. In common mathematical usage "proper subset" is one that is strictly smaller, not a collection that is not a subset. The word "proper" is redundant in non-mathematical discussions. The bottom of page 13 of RFC 1717 says: ]5.1.2. Short Sequence Number Header Format Option ] ] Figure 5: Short Sequence Number Header Format Option ] ] 0 1 ] 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] | Type = 18 | Length = 2 | ] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ] ] This option advises the peer that the implementation wishes to ] receive fragments with short, 12 bit sequence numbers. By default ] sequence, numbers are 24 bits long. When this option is received, an ] implementation MUST either transmit all subsequent multilink packets ] on all links of the bundle with 12 bit sequence numbers or ] configure-NAK or configure-Reject the option. What does it mean for the boolean Short Sequence Number Header Format Option to appear in a Configure-NAK? According the main PPP RFC, the SSNHF option can never appear in an Configure-Nak. Page 30 of RFC 1661 says: ]5.3. Configure-Nak ] ] Description ] ] If every instance of the received Configuration Options is ] recognizable, but some values are not acceptable, then the ] implementation MUST transmit a Configure-Nak. The Options field ] is filled with only the unacceptable Configuration Options from ] the Configure-Request. All acceptable Configuration Options are ] filtered out of the Configure-Nak, but otherwise the Configuration ] Options from the Configure-Request MUST NOT be reordered. ] ] Options which have no value fields (boolean options) MUST use the ] Configure-Reject reply instead. I believe it is a significant error for the SSNHF option to request the use of the Multilink Protocol. What should a system that wants to use the Multilink Protocol without short sequence numbers do? If it Configure-Rejects the SSNHF option, the peer may decide the entire protocol is being rejected. On the other hand, since the discussion of the MRRU option does not require that all Multilink Protocol implementations support the MRRU option, a system that wants to use the Multilink protocol may not be able to communicate as much to its peer. In other words, I'm claiming conformant implementations can fail to interoperate. Consider one MP system that supports the MRRU option but does not like short sequence numbers, and another system that does not support the MRRU option. There is no way the two systems can agree to use the Multilink Protocol. I think the solution is to 1. remove the words "or configure-NAK" from the bottome of page 13. 2. replace the following text on page 13: ] A system MAY indicate the desire to conduct multilink operation ] solely by use of the Multilink Short Sequence Number Header Format ] LCP option (discussed next); the default value for MRRU option is ] 1600 bytes if not otherwise explicitly negotiated. with the following: ! A system MUST indicate the desire to conduct multilink operation ! by sending the MRRU LCP option. I was sensitive to this because I've discovered the hard way that PPP implementations from at least one major commercial router vendors do not support the basic (not MP) MRU option. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jan 30 22:34:31 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id WAA20651; Mon, 30 Jan 1995 22:34:31 -0500 Resent-Date: Mon, 30 Jan 1995 22:34:31 -0500 Date: Mon, 30 Jan 95 20:21:35 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501310321.AA09193@rhyolite.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: oops (somewhat) Resent-Message-ID: <"ktn931.0.V25.5_QBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/11 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Now I've read page 14 of RFC 1717, and see what a Configure-NAK of Short Sequence Numbers means, contrary to RFC 1661. However, I still think it is desirable that the MRRU option be the only way that a desire for multilink is signalled. I bet such a change would not affect any existing implementation. In addition, I cannot find any words that say whether it is legal for some members of a multilink bundle to use short sequence numbers and other members to use long sequence numbers. Such a chimera would work, but I think it is offensive enough to be explicitly outlawed in the name of implemenation simplicity. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jan 31 08:14:21 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id IAA10229; Tue, 31 Jan 1995 08:14:21 -0500 Resent-Date: Tue, 31 Jan 1995 08:14:21 -0500 Date: Tue, 31 Jan 95 08:17:28 EST From: ed_allen@wellfleet.com (Ed Allen) Message-Id: <9501311317.AA12087@wellfleet> To: vjs@rhyolite.denver.sgi.com Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9501310321.AA09193@rhyolite.denver.sgi.com> (vjs@rhyolite.denver.sgi.com) Subject: Re: oops (somewhat) Resent-Message-ID: <"qyaCP3.0.bV2.eUZBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/12 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>>>> Vernon Schryver writes: VS> In addition, I cannot find any words that say whether it is legal for VS> some members of a multilink bundle to use short sequence numbers and VS> other members to use long sequence numbers. Such a chimera would work, VS> but I think it is offensive enough to be explicitly outlawed in the VS> name of implemenation simplicity. Offensive it would be. Doesn't this next text from 1717, bottom of page 12 do the job? 5.1.2. Short Sequence Number Header Format Option Figure 5: Short Sequence Number Header Format Option 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 18 | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option advises the peer that the implementation wishes to receive fragments with short, 12 bit sequence numbers. By default sequence, numbers are 24 bits long. When this option is received, an implementation MUST either transmit all subsequent multilink packets on all links of the bundle with 12 bit sequence numbers or configure-NAK or configure-Reject the option. - Ed - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jan 31 09:32:44 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id JAA13601; Tue, 31 Jan 1995 09:32:44 -0500 Resent-Date: Tue, 31 Jan 1995 09:32:44 -0500 Date: Tue, 31 Jan 95 07:31:49 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501311431.AA10863@rhyolite.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: oops (somewhat) Resent-Message-ID: <"Rc5Jm2.0.IK3.4eaBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/13 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: ed_allen@wellfleet.com (Ed Allen) > ... > implementation MUST either transmit all subsequent multilink packets > on all links of the bundle ... Good point. Thanks. I wish it also said something about having to specify short sequence numbers from the first. It seems distasteful to have deal with the case of a peer that asks for short sequence numbers only on the 3rd link of a bundle. Even if all of your state machines are in close proximity (e.g. not separate UNIX processes), how do you handle the transition from long to short sequence numbers? What about a peer that decides to ask for a different MRRU on the second link of a bundle? My solution is the obvious one (punt), but I wish it were sanctified by the standard. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jan 31 14:58:58 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id OAA27599; Tue, 31 Jan 1995 14:58:58 -0500 Resent-Date: Tue, 31 Jan 1995 14:58:58 -0500 From: Karl Fox Date: Tue, 31 Jan 95 14:57:59 -0500 Message-Id: <9501311957.AA11046@gefilte.MorningStar.Com> To: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: Re: oops (somewhat) In-Reply-To: <9501311431.AA10863@rhyolite.denver.sgi.com> References: <9501311431.AA10863@rhyolite.denver.sgi.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"pIlA_2.0.tk6.iPfBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/14 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > I wish it also said something about having to specify short sequence > numbers from the first. It seems distasteful to have deal with the > case of a peer that asks for short sequence numbers only on the 3rd > link of a bundle. Even if all of your state machines are in close > proximity (e.g. not separate UNIX processes), how do you handle the > transition from long to short sequence numbers? No problem; you just Configure-Reject the short sequence number (SSNHF) option. The *real* problem is when you have two links up using short sequence numbers and then on the third connection the peer Configure-Rejects your SSNHF option! Ha! Make sure you can convert your links on the fly from short to long sequence numbers! Don't forget to keep in mind what your code then has to do when it receives packets with headers of the format you don't want! - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jan 31 15:18:54 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id PAA28548; Tue, 31 Jan 1995 15:18:54 -0500 Resent-Date: Tue, 31 Jan 1995 15:18:54 -0500 Date: Tue, 31 Jan 95 15:22:05 EST From: ed_allen@wellfleet.com (Ed Allen) Message-Id: <9501312022.AA24104@wellfleet> To: karl@MorningStar.Com Cc: vjs@rhyolite.denver.sgi.com, ietf-ppp@MERIT.EDU In-Reply-To: <9501311957.AA11046@gefilte.MorningStar.Com> (message from Karl Fox on Tue, 31 Jan 95 14:57:59 -0500) Subject: Re: oops (somewhat) Resent-Message-ID: <"6-5N33.0.uz6.iifBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/15 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>>>> Karl Fox writes: KF> No problem; you just Configure-Reject the short sequence number KF> (SSNHF) option. The *real* problem is when you have two links up KF> using short sequence numbers and then on the third connection the peer KF> Configure-Rejects your SSNHF option! Ha! Make sure you can convert KF> your links on the fly from short to long sequence numbers! Don't KF> forget to keep in mind what your code then has to do when it receives KF> packets with headers of the format you don't want! Yikes! I hope it is also "legit" to call it a configuration error, and prevent the third connection from joining the bundle, by whatever means. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jan 31 15:32:47 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id PAA29594; Tue, 31 Jan 1995 15:32:47 -0500 Resent-Date: Tue, 31 Jan 1995 15:32:47 -0500 From: Karl Fox Date: Tue, 31 Jan 95 15:31:56 -0500 Message-Id: <9501312031.AA11496@gefilte.MorningStar.Com> To: ed_allen@wellfleet.com (Ed Allen) Cc: vjs@rhyolite.denver.sgi.com, ietf-ppp@MERIT.EDU Subject: Re: oops (somewhat) In-Reply-To: <9501312022.AA24104@wellfleet> References: <9501311957.AA11046@gefilte.MorningStar.Com> <9501312022.AA24104@wellfleet> Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"w9tfa3.0.EE7.ivfBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/16 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ed Allen writes: > >>>>> Karl Fox writes: > > KF> No problem; you just Configure-Reject the short sequence number > KF> (SSNHF) option. The *real* problem is when you have two links up > KF> using short sequence numbers and then on the third connection the peer > KF> Configure-Rejects your SSNHF option! Ha! Make sure you can convert > KF> your links on the fly from short to long sequence numbers! Don't > KF> forget to keep in mind what your code then has to do when it receives > KF> packets with headers of the format you don't want! > > Yikes! > I hope it is also "legit" to call it a configuration error, and > prevent the third connection from joining the bundle, by whatever > means. Not as far as I can tell. I call it a `protocol design error.' - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jan 31 15:47:54 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id PAA00412; Tue, 31 Jan 1995 15:47:54 -0500 Resent-Date: Tue, 31 Jan 1995 15:47:54 -0500 Date: Tue, 31 Jan 95 13:47:06 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9501312047.AA12891@rhyolite.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: multilink Resent-Message-ID: <"cqOe3.0.F6.u7gBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/17 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Karl Fox > > Ed Allen writes: > > >>>>> Karl Fox writes: > > > > KF> No problem; you just Configure-Reject the short sequence number > > KF> (SSNHF) option. That does not work, since that must mean you are rejecting the link as part of the bundle. If Configure-Rejecing SSNHF does not mean "no I do not want to play MP", then how do you say that to a peer that wants to use an MRRU of 1600 and so does not send an MRRU option? A NAK of SSNHF cannot mean "no MP," since it means "please do SSNHF" according to page 14. > > KF> The *real* problem is when you have two links up > > KF> using short sequence numbers and then on the third connection the peer > > KF> Configure-Rejects your SSNHF option! Ha! Make sure you can convert > > KF> your links on the fly from short to long sequence numbers! Don't > > KF> forget to keep in mind what your code then has to do when it receives > > KF> packets with headers of the format you don't want! > > > > Yikes! > > I hope it is also "legit" to call it a configuration error, and > > prevent the third connection from joining the bundle, by whatever > > means. > > Not as far as I can tell. I call it a `protocol design error.' Anything done by a peer not clearly prohibited by the protocol specification cannot be a local configuration error. If you tell the operators of the other machine they've made a configuration error, you know they'll respond with "your system is broken." I think the solution is obvious and easy: 1. require the MRRU option to indicate whether MP is desired. The SSNHF option would be like the Endpoint Discriminator option in not implying anything about whether multilink will be used. 2. make the SSNHF option play completely by the RFC 1661 rules as far as NAK's and Rejects are concerned. 3. make the SSNHF option symmetric, so that you receive short sequence numbers if and only if you send them, either peer can Configure-Request them, and a Configure-ACK of the SSHNF option impies an agreement to both send and receive them. I think this change would cause no interoperation problems with existing implementations. It seems to me to meet the needs of those who want short sequence numbers. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jan 31 19:25:28 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id TAA09890; Tue, 31 Jan 1995 19:25:28 -0500 Resent-Date: Tue, 31 Jan 1995 19:25:28 -0500 Message-Id: <199502010026.AA07753@seegiri.NSD.3Com.COM> To: ietf-ppp@MERIT.EDU Subject: MLP SSNHF Organization: 3Com, 5400 Bayfront Plaza, P.O.Box 58145, Santa Clara, CA 95052 Phone.......: (408) 764-6333 (Office) (415) 969-4400 (General Office) Date: Tue, 31 Jan 1995 16:26:04 -0800 From: "Podi Kuruppu" Resent-Message-ID: <"bCXBx3.0.HQ2.SJjBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/18 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU If I read section 5.1.2 of RFC 1717 on SSNHF option correctly, this applies only to the receiver, does it not? The transmitter can still use the default 24-bit sequence numbers - unless, of course, the peer requests the SSNHF option. Is my interpretation correct here? Thanks, -Podibanda Kuruppu - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jan 31 21:07:32 1995 Received: (from slist@localhost) by merit.edu (8.6.9/merit-2.0) id VAA14379; Tue, 31 Jan 1995 21:07:32 -0500 Resent-Date: Tue, 31 Jan 1995 21:07:32 -0500 Date: Tue, 31 Jan 1995 18:06:59 -0800 (PST) From: Keith Sklower Message-Id: <199502010206.SAA18791@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: multilink sticky wicket? Resent-Message-ID: <"PU2dJ2.0.VW3.YpkBl"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/19 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I've been on jury duty for the past week and a half, and have (shortsidely) only been looking at mail specifically addressed to me, rather than to mailing lists. The subject came up about how you deal with a situation where you have at least one physical link up, and a second link gets started where the party attempts to negotiate Short sequence numbers. The guiding principle was that all members of a link where supposed to play by the same rules. So it seems to me that the most simple minded solution is that if you want short sequence numbers, you should negotiate that up front on the first link, and shouldn't change that for the life of the link. If you want to change it, you should close multilink and reopen it. I'm stuck at home on a glass tty which doesn't support vi very well, so I can't effectively cite chapter & verse. I agree that the the next rev of the RFC probably needs more explanatory text on this point. - - - - - - - - - - - - - - - - -