headers
W. Mark Townsley | 1 Oct 2002 16:00
Picon
Favicon

Last call for draft-dasilva-l2tp-relaysvc-04.txt


draft-dasilva-l2tp-relaysvc-04.txt incorporates items discussed during the last 
call for draft-dasilva-l2tp-relaysvc-03.txt

I will advise the Area Directors on October 15, 2002, to take 
draft-dasilva-l2tp-relaysvc-04.txt to Proposed Standard unless there is 
substantive comment raised on this list.

Thanks,

- Mark
Permalink | Reply | 0 comments |
headers
Vipin Jain | 1 Oct 2002 19:16
Picon
Favicon

Re: Comments on draft-ietf-l2tpext-tunnel-switching-03.txt

Thanks for the comments Mark. My response inline..
I snipped out plenty of text that you didn't comment on.

>
>      The figure above presents a typical tunnel switching scenario for
>      incoming calls. The user opens a layer2 (for example PPP) session
>
> WMT Are we going to mayke this RFC2661-specific or not? If so, I think we can
> go
> ahead and call this a "PPP" session vs. a "layer2" session. If we are going
> to
> make it L2TPv3 based, we probably need more nomenclature changes than just
> this.
> What we have here seems sort of in-between.
Yes, we'd like it to be generic because we think there is applicability
beyond PPP; Agree that it needs more nomenclature change (borrow most
of them from L2TPv3). It would allow tunnel switching to work with
L2TPv2 as well.

>      Tunnel switching enables higher administrative control on how layer2
>      sessions are engineered in L2TP deployments.
>
> WMT "higher administrative control," "layer2 sessions are engineered" - this
> is
> a little broad and encompassing. I think we should come down to earth a bit
> here.
sure, how about:
"Tunnel switching enables redirection of layer2 sessions based on
administrative policies as described below". 'below' would cover
the same text.
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 3 Oct 2002 17:17
Picon
Favicon

Protocol Action: L2TP IANA Considerations Update to BCP


The IESG has approved the Internet-Draft 'L2TP IANA Considerations 
Update' <draft-ietf-l2tpext-rfc2661-iana-01.txt> as a BCP.
This document is the product of the Layer Two Tunneling Protocol 
Extensions Working Group. The IESG contact persons are Erik Nordmark 
and Thomas Narten.

   
Technical Summary

This document provides guidelines to IANA on the assignment of
L2TP-related numbers.

Working Group Summary

There was support for this document in the WG and no issues were
raised during IETF Last Call.

Protocol Quality

This document has been reviewed for the IESG by Thomas Narten.
Permalink | Reply | 0 comments |
headers
W. Mark Townsley | 15 Oct 2002 03:54
Picon
Favicon

Call for L2TPEXT Agenda Items for the 55th IETF - Atlanta, GA


Please send me requests to make presentations at L2TPEXT.  Be sure to
include all of the information below. Even if you have already made a
request off line, please do me the favor of responding (privately, no
need to copy the list) to this email with the following items filled in.
I will provide a digest after receiving time slot requests.

Thanks!

- Mark

1) Name of presenter, including e-mail address
2) Title of presentation
3) Internet draft name, if applicable
4) Amount of time requested
Permalink | Reply | 0 comments |
headers
Thomas Narten | 22 Oct 2002 17:07
Picon
Favicon

AD review of draft-ietf-l2tpext-v92-moh-01.txt

Here are my review comments, based on the WG request to advance the
document as a PS. 

The IANA considerations really needs to be redone before last call,
since IANA will review the document during the LC to determine what
actions it has.

Once we have a new ID in place, I'll start the LC.

Thomas

title has acronyms  (rfc editor won't like this)

>                 V.92 Modem-On-Hold signalling on L2TP

Would a better title be:

      Signalling of Modem-On-Hold status in Layer Two Tunnelling
      Protocol (L2TP).

abstract not conformant with RFC editor guidelines.

see http://www.rfc-editor.org/policy.html

>    L2TP defines a general purpose mechanism for tunneling PPP over
>    various media.  By design, the operation of L2TP is insulated from
>    the details of the media from which the PPP session originated,
>    including when a V.92 client modem requests to go on-hold.  It may be
>    desirable for this information to be provided to the LNS.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane