Re: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03

[Dean cheng <[e-mail]>]

Hello Alan,

Thanks for your comments, and we'll take care
of them in the next revision.

Regards
Dean

> -----Original Message-----
> From: radext [mailto:[e-mail]] On Behalf Of Alan DeKok
> Sent: Tuesday, March 31, 2015 10:32 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-
> 03
> 
>   I'm not sure what Section 3.1.1 is for.  It shouldn't be needed.  The
> document does NOT define a new extended type.  It defines a new RADIUS
> attribute.  That attribute is allocated from the extended type space.
> 
>   My $0.02 is to remove Section 3.1.1, and all references to it.  Instead,
> just say:
> 
> 3.1.2.  IP-Port-Limit Attribute
> 
>    This attribute is of Extended-Type, and contains a set of embedded TLVs  ...
> 
>  Also, IANA should assign values.  There's no need to call them out:
> 
>    Type:
> 
>       TBA1 - Extended-Type-1 (241), Extended-Type-2 (242), Extended-
>       Type-3 (243), or Extended-Type-4 (244) per [RFC6929].
> 
> 
>   Just replace that with:
> 
>    Type:
> 
>       TBA1
> 
> 
>   It could be clearer that the same set of TLVs can be contained within the
> encapsulating attribute.  This means (e.g.) that IANA must allocate *multiple*
> attributes, e.g.
> 
> 241.33.1		IP-Port-Type TLV inside of IP-Port-Limit
> 241.34.1		P-Port-Type TLV inside of IP-Port-Forwarding-Map Attribute
> 
>   etc.  The IANA section isn't clear to me, either.  e.g.
> 
>    o  TBA1 (refer to Section 3.1.1): This value is for the Radius Type
>       field and should be allocated from the number space of Extended-
>       Type-1 (241), Extended-Type-2 (242), Extended-Type-3 (243), or
>       Extended-Type-4 (244) per [RFC6929].
> 
>    o  TBA2 (refer to Section 3.1.1): This value is for the Extended-Type
>       field and should be allocated from the Short Extended Space per
>       [RFC6929].
> 
> 
>   That's unnecessary, and should be deleted.
> 
> o  TBA3 (refer to Section 3.2.1): This value is for the Type field of
>       IP-Port-Type TLV.  It should be allocated as TLV data type.  It is
>       within the TBA2 container and it extends the attribute tree as
>       TBA1.TBA2.TBA3.[...].  Also, this value uniquely refers to IPFIX
>       Element ID transportType (TBAx1).
> 
>   Just say something like "TBA3: IP-Port-Type allocated from within the short
> extended space".
> 
>   The reference to IPFix should specify an IANA action:
> 
> 	Add a note for that attribute, saying that this attribute contains data
> from IPFix Element ID transportType TBAx1"
> 
>   If all of the TLVs can be used in all of the attributes, then the allocation
> of the TLVs should be done for the *first* attribute.  i.e. IP-Port-Type  is a
> sub-TLV of IP-Port-Limit, and should be assigned the number "TBA3.1".  It's OK
> to manually allocate numbers where they're TLVs, and not been allocated before.
> 
>   The document should *also* tell IANA to prohibit allocation of TLVs under
> the  IP-Port-Forwarding-Map, etc. attributes.  And note that those attributes
> are all of type TLV, with TLVs defined by the IP-Port-Limit attribute.
> 
>   That's it for now...
> 
>   Also, the document contains many data types which are explicitly forbidden
> by RFC 6929.  8-bit, 16-bit, etc.  While I know that these are in IPFIX, I
> wouldn't recommend using them here.  They should all be moved to "integer"
> data types, with a note that the bits unused by IPFIX *must* be zero.
> 
> 
> On Mar 31, 2015, at 12:51 PM, <[e-mail]>
> <[e-mail]> wrote:
> 
> > During the RADEXT session at IETF92, the authors of draft-ietf-radext-ip-
> port-radius-ext-03 have asked for a Working Group Last Call.
> >
> > This email officially starts a Working Group Last Call for the
> > following document
> >
> > http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-03
> >
> > Please respond to this email to support the document and/or send comments by
> 2015-04-13.
> >
> > In addition, following the strategy for promoting compliance with the IPR
> disclosure rules (RFC6702), the chairs would like to check  whether there are
> claims of Intellectual Property Rights (IPR) on the document that need to be
> disclosed. Therefore, the following questions are addressed to the WG and
> Especially Authors and Contributors of the draft:
> >
> > Are you personally aware of any IPR that applies to
> > draft-ietf-radext-ip-port-radius-ext-03? If so, has this IPR been
> > disclosed in compliance with IETF IPR rules?  (See RFCs 3979, 4879,
> > 3669, and 5378  for more details.)
> >
> > If you are a document author or listed contributor on this document, please
> reply to this email message regardless of whether or not you are personally
> aware of any relevant IPR.  We might not be able to advance this document to
> the next stage until we have received a reply from each author and listed
> contributor.
> >
> > If you are on the RADEXT WG email list but are not an author or listed
> contributor for this document, you are reminded of your opportunity for a
> voluntary IPR disclosure under BCP 79.  Please do not reply  unless you want
> to make such a voluntary disclosure.
> >
> > Online tools for filing IPR disclosures can be found at
> <http://www.ietf.org/ipr/file-disclosure>.
> >
> > Regards,
> >
> > Lionel & Stefan
> >
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > 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.
> >
> > _______________________________________________
> > radext mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/radext
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext