Subject: ISSLOW drafts

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Mar 1998 21:57:12 +0100 (MET)

Dear I-D Editor,

as a product of the ISSLL WG, I'm now submitting the ISSLOW drafts.
I'm CCing the WG chairs and the mailing lists of both ISSLL and
PPPEXT, the two WGs involved.

The drafts are at:

	http://ftp.tzi.org/research/isslow.txt
	http://ftp.tzi.org/research/mcml.txt
	http://ftp.tzi.org/research/rtf.txt

(You have to type the http://, as browsers will default to ftp:// otherwise.)

(There also are HTML and PostScript versions at this place that you
probably don't need but may be useful for mailing list readers.)

Gruesse, Carsten
___________

PS.: Quick summary for mailing list readers:
These drafts contain final editorial changes only, except for:

1) As advised by Karl Fox, LCP option type number 18 gets used for
both the old PPP Multilink Short Sequence Number Header Format option
(type = 18, length = 2) and the new, more general Multilink Header
Format option (type = 18, length = 3).  If that makes you or your code
barf (or config-rej a length 3 type 18 although you could do a length
2 type 18), please speak up now.

2) Unlike advised by Karl Fox, the Prefix Elision LCP option still
goes from sender to receiver; it just does not make sense the other
way around (which would require the sender to always NAK for the
prefixes it wants to use).  I expect a lively debate on this in LA.
Again, if that makes you or your code barf, please speak up now.

I'm still waiting for the number assignment for the Prefix Elision
option.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: 16 Mar 1998 16:46:39 +0100

> 2 type 18), please speak up now.

Serious "bad idea" alert.  At this point in time (when US west coast
people are barely awake), I already got pointers to two widely
deployed products which would be thoroughly confused by using option
18 in this way.  In at least one case, a deployed peer and an ISSLOW
peer would think different things about what they apparently
successfully negotiated.

I'll ask for a second number for the generalized Multilink Header
Format option, as was proposed in my original draft.
In the meantime, please don't implement it with 18...

Gruesse, Carsten

---

From: Karl Fox <[email-masked]>
Date: Mon, 16 Mar 1998 09:23:57 -0800

Carsten, could you please publish the specifics of the problem you
mention?  There is no inherent problem with reusing the number; as has
been said before, the same thing was done with IPCP VJ compression,
and that transition worked quite well.

I agree that we shouldn't go out of our way to expose a bug in
someone's product, but we can't always avoid it, and it's
traditionally not been considered a valid reason to change what we're
doing.

What do the rest of you think?

-- 
Karl Fox, servant of God, employee of Ascend Communications
655 Metro Place South, Suite 370, Dublin, Ohio  43017   +1 614 760 4041

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Mar 1998 19:32:24 +0100 (MET)

> traditionally not been considered a valid reason to change what we're

Karl,

I don't think it would be appropriate for me to publish the private
E-mail.  Suffice it to say that there is one widely deployed product
that "ignores the length of the Multilink Short Sequence Number Header
Format options in LCP Configure-Requests.  It will Configure-Ack them
no matter how short or how long."  The other (equally well-known)
product "will, when receiving a 3-byte long LCP option type 18,
configure-ack the 3-byte option and then use Short Sequence Number
Headers (without classes) on the link.  This is true no matter what
the 3rd byte is, and is true for all versions of" the product
(including a soon-to-be-release one).

With two wide-spread implementations that act that way, no box
implementing ISSLOW would turn on ISSLOW negotiation by default --
this would be a disaster.  As it is easy to avoid (use another LCP
option type, of which only 10 % have been allocated so far, and
extending the space is cheap), I don't see a big issue.

Of course, in the future, we never should allocate simple boolean
options such as 18 when we already can see that there will be further
variants.  Too late for this one.

Gruesse, Carsten

PS.: I don't know enough about the (pre-RFC1172?) history of IPCP VJ
compression to comment on that.  Could you elucidate?

---

From: Karl Fox <[email-masked]>
Date: Tue, 17 Mar 1998 13:30:05 -0800

Carsten, your arguments (and those of others) are persuasive.  Go
ahead and get another number.