Additional Values for the NAS-Port-Type Attribute
RFC 4603

[Ballot comment]
Since I'm told this is not proprietary, the sentence
  The values given have already been implemented by Cisco Systems.
(end of section 3.1) is inappropriate and amounts to condoning the use
of unassigned values. I would suggest
  The values given have already been implemented by at least one vendor
  without assignment by IANA.

Also, the first two sentences in section 3 have no logical place
in this document.
  This section explains the criteria to be used by the IANA for
  assignment of numbers within namespaces defined within this document.
  The "Expert Review" policy is used here with the meaning defined in
  BCP 26 [RFC2434].
The document doesn't define a namespace and doesn't define a policy.
I would simply delete those sentences.

IANA Follow-up Comments:
Upon approval of this document the IANA will register the following values for RADIUS Attribute 61, NAS-Port-Type registry located at http://www.iana.org/assignments/radius-types

30 PPPoA (PPP over ATM [RFC3336])
31 PPPoEoA (PPP over Ethernet [RFC2516] over ATM)
32 PPPoEoE (PPP over Ethernet [RFC2516] over Ethernet
33 PPPoEoVLAN (PPP over Ethernet [RFC2516] over VLAN)
34 PPPoEoQinQ (PPP over Ethernet [RFC2516] over IEEE 802.1QinQ)

[Ballot comment]
Section 1 and 3.1 contain largely the same text. Are both copies really necessary? Consider removing 3.1 when addressing Brain's comment WRT vendor naming (including his suggested text change in section 1).

[Ballot discuss]
The reader may confuse Section 3 to be a new definition of
the RADIUS IANA rule when it says "This section explains the
criteria to be used by the IANA for assignment of numbers within
namespaces defined within this document." And the document does
not define any new namespaces, it allocates values within an
existing namespace.

I would suggest replacing Section 3 with the following text:

    3. IANA Considerations

    This document is intended to act as a request for allocation of
    the attribute values listed in Section 2 from the appropriate
    registry [RADTYP], based on IANA allocation rules specified in RFC
    3575. Suggested values are provided in Section 2.

Or something along those lines. Otherwise I think the document is
fine and should get a Yes from me if the IANA part is clarified.

IANA Comments:
Clarification is needed (similar to Brian's comments)
We can't find any registry to be created.  It appears this document is requesting a attributes value registry to be added to the following:
http://www.iana.org/assignments/radius-types, however we can't find any details other than it will be an expert review registry.

[Ballot discuss]
Is this proprietary? If yes, title should mention Cisco. If no, the sentence
  The values given have already been implemented by Cisco Systems.
(end of section 3.1) is inappropriate and amounts to condoning the use
of unassigned values. I would suggest
  The values given have already been implemented by at least one vendor
  without assignment by IANA.

Also, the first two sentences in section 3 have no logical place
in this document.
  This section explains the criteria to be used by the IANA for
  assignment of numbers within namespaces defined within this document.
  The "Expert Review" policy is used here with the meaning defined in
  BCP 26 [RFC2434].
The document doesn't define a namespace and doesn't define a policy.
I would simply delete those sentences.

[Ballot discuss]
Is this proprietary? If yes, title should mention Cisco. If no, the sentence
  The values given have already been implemented by Cisco Systems.
(end of section 3.1) is inappropriate and amounts to condoning the use
of unassigned values.

Also, the first two sentences in section 3 have no logical place
in this document.
  This section explains the criteria to be used by the IANA for
  assignment of numbers within namespaces defined within this document.
  The "Expert Review" policy is used here with the meaning defined in
  BCP 26 [RFC2434].
The document doesn't define a namespace and doesn't define a policy.