Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt

From: Timothy Kwok <[email-masked]>
Date: Thu, 18 Dec 1997 08:00:41 -0800

Good question, Joel.

The major motivation of driving this RFC is for ADSL environment from
vendors and carriers eager to deploy ADSL service ASAP and supporting Y in
such environments is not the focus at all. Forcing the ADSL environment to
use X is a burden to those environments. 

Hence, this RFC is really saying
1. X is recommended, but optional (so its not a burden to those who has no
intention of supporting Y)
2. AND, IF you are interested in interoperating with Y, you MUST X. Also, IF
you are interested interoperating with ALL scenarios, you MUST X.

Tim

> -----Original Message-----
> From:	Joel Halpern [SMTP:[email-masked]]
> Sent:	Thursday, December 18, 1997 7:36 AM
> To:	David Allan
> Cc:	[email-masked]'; 'James Watt';
> [email-masked]'; [email-masked]'; Timothy Kwok
> Subject:	RE: Last call on draft-ietf-pppext-aal5-03.txt
> 
> I must observe that writing into a proposed RFC text which reads:
>   Implementations Should X
>   Implementations which do not X will not interoperate with Y
> Is a clear invitation for someone to push harder on the question I am
> asking:
>     Why not MUST X?
> 
> Yours,
> Joel M. Halpern
> 
> On Wed, 17 Dec 1997, David Allan wrote:
> 
> > George:
> > 
> > Only suggestion for readability of the section would be to move the
> > third para out of the list. So you get:
> > 
> > "When transporting....
> > 
> > 1) MUST
> > 
> > 2) MAY
> > 
> > 3) Used to be para 4 --> For SVC set up, an implementation....
> > 
> > If an implementation ....."
> > 
> > No actual content change implied or otherwise.:-)
> > 
> > Regards
> > Dave
> > 
> > >----------
> > >From: 	[email-masked][SMTP:[email-masked]]
> > >Sent: 	Tuesday, December 16, 1997 10:38 AM
> > >To: 	[email-masked]; James Watt
> > >Cc: 	Allan, David (D.); [email-masked];
> [email-masked];
> > >[email-masked]
> > >Subject: 	RE: Last call on draft-ietf-pppext-aal5-03.txt
> > >
> > >Hi,
> > >	Here's what I would like to nominate as the final version of the
> > >text passage in question:
> > >
> > >3. If an implementation is connecting through a Frame Relay/ATM
> > >   FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point,
> > >   then it MUST use LLC encapsulated PPP payloads. Implementations
> > >   that want to inter-operate with all potential end points MUST
> > >   implement LLC encapsulated PPP payloads.
> > >
> > >The -03 version said "MUST support LLC encapsulated PPP..." instead of
> MUST
> > >use.  The last sentence in the above text reflects a discussion held
> last
> > >week at the IETF between Andy Malis, James Watt, David Allan, and
> myself.
> > >The intent is to highlight the consequences of implementing only
> > >VC-multiplexed PPP payloads.
> > >
> > >	George
> > >
> > >
> > 
> 
> Yours,
> Joel M. Halpern                         [email-masked]
> Newbridge Networks Inc.

---

From: Joel Halpern <[email-masked]>
Date: Thu, 18 Dec 1997 12:00:08 -0500 (EST)

> you are interested interoperating with ALL scenarios, you MUST X.

Time, I am very sympathetic to your view that there is a specific
envirmonemtn where Y does not apply, and that is the problem to be solved.
Two issues, from lessor to greater:
1) The Document title and Scope is not "ADSL support", but "PPP Over ATM".
If we only want to solve ADSL, we should say so.

2) More significantly, I think that FR interworking does apply to ADSL.
   For example, consider a work-at-home or remote office, using ADSL to
   access an ATM service, which is directly interworked with the FR
   service that the corporation uses.  Instead of using L2TP tunnels 
   (which are an option), the user simply establishes VCs directly to the
   corporate infrastructure and runs IP over them.
   If I can think of one case, I am sure that there are others.
   Suppose that the ISP is actually using FR rather than ATM, and is
   reached through an interworking function.

So, I tend to feel that the device can not "know" at manufacturing time
that it will never have to deal with FR interworking.

> >   ... Other content elided ...

Yours,