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

From: <[email-masked]>
Date: Tue, 31 Mar 2015 16:51:24 +0000

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.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 31 Mar 2015 12:58:33 -0400

>>>>>   <[email-masked]> writes:

    > 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.)

Any necessary IPR disclosures I'm required to file have been filed. I
have filed no disclosures.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 31 Mar 2015 13:32:09 -0400

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, <[email-masked]> <[email-masked]> wrote:

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Dean cheng <[email-masked]>
Date: Tue, 31 Mar 2015 18:46:13 +0000

I'm not aware of any IPR that applies to this draft.

Dean
> 
> 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.
>

---

From: Dean cheng <[email-masked]>
Date: Tue, 31 Mar 2015 18:49:50 +0000

Hello Alan,

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

Regards
Dean

> -----Original Message-----
> From: radext [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Tuesday, March 31, 2015 10:32 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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.
> 
>   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.
> 
> 	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.
> 
> 
> > 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.
> >
> > 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:
> >
> > disclosed in compliance with IETF IPR rules?  (See RFCs 3979, 4879,
> > 3669, and 5378  for more details.)
> >
> > 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,
> > 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.