Re: [radext] [IANA #920427] Last Call: <draft-ietf-radext-ip-port-radius-ext-10.txt> (RADIUS Extensions for IP Port Configuration and Reporting) to Proposed Standard

[Kathleen Moriarty <[e-mail]>]

Hello Dean,

Could you please assist with the response?

IANA - Could you please send the IE doctors review so we have the full
text?  A question was raised by one of the ADs who spoke with one of
the iE doctors and I'd like to make sure the WG addresses the full set
of concerns.

Thank you,
Kathleen

On Thu, Aug 11, 2016 at 10:21 AM, Dean cheng <[e-mail]> wrote:
> Hi Lionel,
>
>
>
> Sorry but I wasn't aware of that.
>
>
>
> Regards
>
> Dean
>
>
>
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, August 11, 2016 1:32 AM
> To: Dean cheng; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE : RE: [IANA #920427] Last Call:
> <draft-ietf-radext-ip-port-radius-ext-10.txt> (RADIUS Extensions for IP Port
> Configuration and Reporting) to Proposed Standard
>
>
>
> Hi Dean,
>
> Thank you for the update. However, it is recommended to answer first to the
> questions (form IANA or others) before updating the draft. It would avoid
> too many iterations. And it will allow to check if the proposed answers are
> correct/acceptable.
>
> Regards,
>
> Lionel
>
> Le 11 août 2016 03:43, Dean cheng <[e-mail]> a écrit :
>
> Hi Sabrina,
>
> Thank you for the review and comments.
> We've just uploaded a new revision (11.txt)
> that intends to resolve IANA questions as
> follows:
>
>> IANA Question --> for each of these three registrations, could the
>> authors please supply the data type semantics and the units to be
>> registered with these values?
>
> Regards
> Dean
>
>> -----Original Message-----
>> From: Sabrina Tanamal via RT [mailto:[e-mail]]
>> Sent: Wednesday, August 10, 2016 3:01 PM
>> Cc: [e-mail]; [e-mail]
>> Subject: [IANA #920427] Last Call: <draft-ietf-radext-ip-port-radius-
>> ext-10.txt> (RADIUS Extensions for IP Port Configuration and Reporting)
>> to Proposed Standard
>>
>> (BEGIN IANA COMMENTS)
>>
>> IESG/Authors/WG Chairs:
>>
>> IANA has completed its review of draft-ietf-radext-ip-port-radius-ext-
>> 10.txt. If any part of this review is inaccurate, please let us know.
>>
>> IANA has a question about one of the actions requested in the IANA
>> Considerations section of this document.
>>
>> IANA understands that, upon approval of this document, there are three
>> actions which IANA must complete.
>>
>> First, in the IPFIX Information Elements subregistry of the IP Flow
>> Information Export (IPFIX) Entities registry located at:
>>
>> https://www.iana.org/assignments/ipfix/
>>
>> three new information elements are to be registered as follows:
>>
>> ElementID: [ TBD-at-registration ]
>> Name: transportType
>> Data Type: unsigned8
>> Data Type Semantics:
>> Status: current
>> Description: The value indicates TCP/UDP ports and ICMP Identifiers (1),
>> TCP/UDP ports (2), TCP ports (3), UDP ports (4) or ICMP identifiers (5).
>> Units:
>> Range:
>> References: [ RFC-to-be ]
>>
>> ElementID: [ TBD-at-registration ]
>> Name: natTransportLimit
>> Data Type: unsigned16
>> Data Type Semantics:
>> Status: current
>> Description: The value is the max number of IP transport ports to be
>> assigned to an end user associated with one or more IPv4 addresses.
>> Units:
>> Range:
>> References: [ RFC-to-be ]
>>
>> ElementID: [ TBD-at-registration ]
>> Name: localID
>> Data Type: string
>> Data Type Semantics:
>> Status: current
>> Description: The value is an IPv4 or IPv6 address, a MAC address, a
>> VLAN ID, etc.
>> Units:
>> Range:
>> References: [ RFC-to-be ]
>>
>> IANA Question --> for each of these three registrations, could the
>> authors please supply the data type semantics and the units to be
>> registered with these values?
>>
>> As this document requests registrations in an Expert Review or
>> Specification Required (see RFC 5226) registry, we will initiate the
>> required Expert Review via a separate request. Expert review will need
>> to be completed before your document can be approved for publication as
>> an RFC.
>>
>> Second, in the Radius Attribute Types subregistry of the Radius Types
>> registry located at:
>>
>> http://www.iana.org/assignments/
>>
>> three new Radius attribute types are to be registered under the 241
>> Extended-Attribute-1 type as follows:
>>
>> Value: 241.[ TBD-at-registration ]
>> Description: IP-Port-Limit-Info
>> Reference: [ RFC-to-be ]
>>
>> Value: 241.[ TBD-at-registration ]
>> Description: IP-Port-Range
>> Reference: [ RFC-to-be ]
>>
>> Value: 241.[ TBD-at-registration ]
>> Description: IP-Port-Forwarding-Map
>> Reference: [ RFC-to-be ]
>>
>> Third, IANA notes that the authors request:
>>
>> This specification requests allocation of the following TLVs:
>> Name Value Meaning
>> ---- ----- -------
>> IP-Port-Type 1 see Section 3.2.1
>> IP-Port-Limit 2 see Section 3.2.2
>> IP-Port-Ext-IPv4-Addr 3 see Section 3.2.3 IP-Port-Int-IPv4-Addr 4 see
>> Section 3.2.4 IP-Port-Int-IPv6-Addr 5 see Section 3.2.5 IP-Port-Int-
>> Port 6 see Section 3.2.6 IP-Port-Ext-Port 7 see Section 3.2.7 IP-Port-
>> Alloc 8 see Section 3.2.8 IP-Port-Range-Start 9 see Section 3.2.9 IP-
>> Port-Range-End 10 see Section 3.2.10 IP-Port-Local-Id 11 see Section
>> 3.2.11
>>
>> IANA Question --> Specifically, in what registry are these new TLVs to
>> be registered?
>>
>> IANA understands that the three actions above are the only ones
>> required to be completed upon approval of this document.
>>
>> Note:  The actions requested in this document will not be completed
>> until the document has been approved for publication as an RFC. This
>> message is only to confirm what actions will be performed.
>>
>>
>> Thank you,
>>
>> Sabrina Tanamal
>> IANA Specialist
>> ICANN
>>
>> (END IANA COMMENTS)
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
>
> Thank you.



-- 

Best regards,
Kathleen