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

From: Jouni Korhonen <[email-masked]>
Date: Thu, 09 Apr 2015 23:19:05 -0700

3/31/2015, 9:51 AM, [email-masked] kirjoitti:

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

Not aware of any IPR on this document.

- Jouni

---

From: Dean cheng <[email-masked]>
Date: Wed, 22 Apr 2015 10:21:02 +0000

Hello,

We've just posted the 04 text that addressed comments
posted by Alan. It is:

http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-04

Cheers
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.
> 
>   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:
> 
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/radext
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Wed, 22 Apr 2015 15:29:50 -0400

> http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-04

  On a quick scan, it looks good.  The only minor nit is the ASCII art.  You have a field ending at the end of a line, and then continuing on the next line:

	... | Field-Name |
      | Field-Name | ...

  It should just be:

	... | Field-Name 
       Field-Name | ...

  i.e. without the last | on the first line, and the first | on the next line.

---

From: Dean cheng <[email-masked]>
Date: Thu, 23 Apr 2015 08:17:20 +0000

Alan - thanks for the review and catch. It is now fixed
in the 05 text:

http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-05

Cheers
Dean

> Sent: Wednesday, April 22, 2015 12:30 PM
> To: Dean cheng
> Cc: [email-masked]; [email-masked]; [email-masked]
> > We've just posted the 04 text that addressed comments posted by Alan.
> > It is:
> >
>   On a quick scan, it looks good.  The only minor nit is the ASCII art.  You
> have a field ending at the end of a line, and then continuing on the next line:
> 
> 	... | Field-Name |
>       | Field-Name | ...
> 
>   It should just be:
> 
> 	... | Field-Name
>        Field-Name | ...
>