Subject: Re: draft-ietf-pppext-aodi-02.txt

From: Archie Cobbs <[email-masked]>
Date: Wed, 8 Mar 2000 16:39:37 -0800 (PST)

Re: draft-ietf-pppext-aodi-02.txt

I have one comment about this draft..  please separate this draft
into two separate drafts, or at least, two completely separate sections:

  1. One describing how to setup and perform PPP over an ISDN D-channel
     using X.25

  2. Another describing how to use BACP in the above scenario to
     dynamically increase/decrease bandwidth using the 2 B channels.

This draft seems to assume everybody will use BACP, but that's
an unwarranted assumption.  Moreover, it's confusing that the
above two concepts are being glommed together.

#1 can be relatively short, and rely on RFC 1598 as appropriate.
It should include the discussion about X.25 paramters, Use of
Call User Data field, etc.

#2 can discuss the situtation where BACP is also being used,
e.g., the section on BACP phone deltas.

Thanks,
-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

---

From: James Carlson <[email-masked]>
Date: 09 Mar 2000 07:45:25 -0500

> into two separate drafts, or at least, two completely separate sections:

I've been conversing with Matt Holdrege privately about this draft,
and I've pointed out similar things.  There are deeper problems here.
The AO/DI use of X.25 is nonstandard and broken.  It's also deployed
in a lot of boxes and unlikely to change.

>      dynamically increase/decrease bandwidth using the 2 B channels.

Assuming you also want to hack MP's calculation of 'M' (as suggested
in this draft), that should be yet another completely separate section
or draft.  (I suggested to Mr. Holdrege that MP isn't at all what you
want here.  It doesn't make sense.  It makes a lot of sense to bring
up the X.25 link without MP, then, on demand, bring up a B channel and
quiesce the X.25 link.  No MP and no incompatible modification
required.)

Again, the problem is that AO/DI is really just documentation of what
was already shipped.  As that, I think it doesn't belong in standards
track.

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: "Karl Fox" <[email-masked]>
Date: Thu, 09 Mar 2000 08:10:08 -0500

What do others think?  Matt, what about you?

Is there any chance this spec could be "fixed"?  We've made 
non-backward-compatible changes to protocols before.

Karl

>in a lot of boxes and unlikely to change.
...
>was already shipped.  As that, I think it doesn't belong in standards

Karl Fox <[email-masked]>
Key fingerprint = 5B15 7260 D55E D680 0B93  4953 8A3B AB0E C05D 77A3

---

From: "Karl Fox" <[email-masked]>
Date: Thu, 09 Mar 2000 11:19:53 -0500

Hi Matt,

What I was asking about was the protocol itself, to make it compatible with 
other standards such as PPP over X.25.

Karl

At 08:11 AM 3/9/00 -0800, Matt Holdrege wrote:
>First of all, I've made several fixes in this draft thanks to comments from James and others. Secondly, there are a lot of choices in this draft and I need to fix the language to make that more clear. MP on the D channel is one such choice, BACP is another.
>
>There is nothing horribly wrong with using either BACP or MP and vice versa there is nothing wrong with choosing not to use them. As we all know, a PPP endpoint can make its own choices and it's peer can ack or nack. I'll take this input to make the draft more clear on this point. I know PPPEXT isn't meeting in Adelaide, but I'll be there if anyone wants to chat face-to-face.
>
>
>At 08:10 AM 3/9/00 -0500, Karl Fox wrote: