Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions
draft-mammoliti-l2tp-accessline-avp-06

[Ballot discuss]
This is a good document and was about to vote Yes. However, there were
a couple of minor unclear points which I believe should be corrected
before the document moves forward, so that the reader can unambiguously
understand what the spec means:

1) Please provide a definition of attainable and maximum (and how they
differ from each other). Presumably maximum refers to a configured
per-policy allowable value. Is attainable the value that the physical
media etc. allows the user to employ? Can attainable speed be higher
than maximum speed?

It is possible that these are already well defined in the DSLF documents
that I did not read. If so, please add an explicit reference from the
use of the term to its definition.

2) Its not clear to me what minimum speeds mean, please define them
better. Is a minimum configured speed a policy limit for how much at
least should be given to the user? What if the actual data rate is
lower?

3) Please define "interleaving delay".

4) IANA considerations section should state what the policy is for
allocating new enumerated values for AVPs defined in this document
(such as ANCP Access Line Type AVP). It is possible that the L2TP
documents already have a generic policy for this. If that is the
case, please refer to that policy from the IANA considerations
section.

[Ballot discuss]
This is a good document and was about to vote Yes. However, there were
a couple of minor unclear points which I believe should be corrected
before the document moves forward, so that the reader can unambiguously
understand what the spec means:

1) Please provide a definition of attainable and maximum (and how they
differ from each other).

2) Please define "interleaving delay".

3) IANA considerations section should state what the policy is for
allocating new enumerated values for AVPs defined in this document
(such as ANCP Access Line Type AVP). It is possible that the L2TP
documents already have a generic policy for this. If that is the
case, please refer to that policy from the IANA considerations
section.

IANA Last Call questions/comments:

In Sections 5.1-5.19 you define the Access Line Agent-Circuit-Id,
Agent-Remote-Id, Actual-Data-Rate-Upstream,
Actual-Data-Rate-Downstream, Minimum-Data-Rate-Upstream,
Minimum-Data-Rate-Downstream, Attainable-Data-Rate-Upstream,
Attainable-Data-Rate-Downstream, Maximum-Data-Rate-Upstream,
Maximum-Data-Rate-Downstream, Minimum-Data-Rate-Upstream-Low-Power,
Minimum-Data-Rate-Downstream-Low-Power,
Maximum-Interleaving-Delay-Upstream,
Actual-Interleaving-Delay-Upstream,
Maximum-Interleaving-Delay-Downstream,
Actual-Interleaving-Delay-Downstream, Access-Loop-Encapsulation,
ANCP, and IWF-Session AVPs but you never ask to register them.

- In Section 5.17 you define a bunch of data link sub-fields but
never register them anywhere. Do you want a registry for these
values?

- In Section 5.18 you define Transmission System types but never
create a registry. Do you want one?

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "Message Type AVP (Attribute Type 0) Values"
registry at
http://www.iana.org/assignments/l2tp-parameters

Access Line Information Attributes

MSG-TBD1 (CSUN) Connect-Speed-Update-Notification
[RFC-mammoliti-l2tp-accessline-avp-04]
MSG-TBD2 (CSURQ) Connect-Speed-Update-Request
[RFC-mammoliti-l2tp-accessline-avp-04]


Action 2:

Upon approval of this document, the IANA will make the following
assignments in the "Control Message Attribute Value Pairs"
registry at
http://www.iana.org/assignments/l2tp-parameters

Attribute
Type Description Reference
--------- ------------------ ---------
AVP-TBD1 Connect Speed Update AVP
[RFC-mammoliti-l2tp-accessline-avp-04]
AVP-TBD2 Connect Speed Update Enable AVP
[RFC-mammoliti-l2tp-accessline-avp-04]


We understand the above to be the only IANA Actions for this document.