Re: [radext] [IANA #935820] Protocol Action: 'RADIUS Extensions for IP Port Configuration and Reporting' to Proposed Standard (draft-ietf-radext-ip-port-radius-ext-16.txt)

Hi Amanda,

Also, there are TBD1 etc. in the current draft
pending on value assigned by IANA. Should we
wait for the assignment and update the draft
accordingly too?

Thanks
Dean

> -----Original Message-----
> From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Dean cheng
> Sent: Monday, November 14, 2016 4:54 PM
> To: drafts-approval@iana.org
> Cc: draft-ietf-radext-ip-port-radius-ext.all@ietf.org
> Subject: Re: [radext] [IANA #935820] Protocol Action: 'RADIUS
> Extensions for IP Port Configuration and Reporting' to Proposed
> Standard (draft-ietf-radext-ip-port-radius-ext-16.txt)
> 
> Hi Amanda,
> 
> OK, I'll take a look of the new registries, and send you back the
> feedback.
> 
> Please send us once you are done (I'm in California time zone).
> 
> For the draft itself, do we need to make any more changes - e.g., in
> the two examples you sent to us below, the RFC7361 has text in Section
> 7.2 to reference RFC7361 itself (RFC7688 has similar reference), if we
> want to follow the same, we need to know the RFC number now??
> 
> Thanks
> Dean
> 
> > -----Original Message-----
> > From: Amanda Baber via RT [mailto:drafts-approval@iana.org]
> > Sent: Monday, November 14, 2016 4:25 PM
> > Cc: draft-ietf-radext-ip-port-radius-ext.all@ietf.org
> > Subject: [IANA #935820] Protocol Action: 'RADIUS Extensions for IP
> > Port Configuration and Reporting' to Proposed Standard
> > (draft-ietf-radext-
> > ip-port-radius-ext-16.txt)
> >
> > Hi Dean,
> >
> > I checked with the RFC Editor, and they said that this is a good time
> > for the authors to upload a new revision. We can complete these
> > actions before this has been uploaded, though. I'll contact you
> within
> > a few hours to ask you to review the registries and confirm that
> > everything was completed correctly.
> >
> > thanks,
> > Amanda
> >
> > On Mon Nov 14 18:20:41 2016, dean.cheng@huawei.com wrote:
> > > Hi Amanda,
> > >
> > > Thanks for the message. We've just made changes in Section 7.3
> > > according to the suggestion.
> > >
> > > If the updates OK, should we upload a new revision
> > > (17.txt) at this time?
> > >
> > > Regards
> > > Dean
> > >
> > > > -----Original Message-----
> > > > From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Amanda
> > > > Baber via RT
> > > > Sent: Saturday, November 12, 2016 6:49 AM
> > > > Cc: draft-ietf-radext-ip-port-radius-ext.all@ietf.org
> > > > Subject: [radext] [IANA #935820] Protocol Action: 'RADIUS
> > Extensions
> > > > for IP Port Configuration and Reporting' to Proposed Standard
> > > > (draft-
> > > > ietf-radext-ip-port-radius-ext-16.txt)
> > > >
> > > > Hi,
> > > >
> > > > On Fri Nov 11 15:08:15 2016, aland@deployingradius.com wrote:
> > > > > On Nov 10, 2016, at 10:04 PM, Dean cheng <dean.cheng@huawei.com>
> > > > > wrote:
> > > > > >
> > > > > > The "type" field is 8-bit long so there are possibly 256
> values.
> > > > > > RFC6929 does not say the value "0" is "Unassigned"
> > > > > > or "Reserved". In the Radius registry, the value "0" for
> > > > > > attribute
> > > > > > 241.1 is "Reserved". For consistency, I'd suggest  to follow
> > the
> > > > > > same. The maximum value is 256.
> > > > >
> > > > > https://tools.ietf.org/html/rfc6929#section-10
> > > > >
> > > > > Allocation of an Attribute Type value "TYPE" using the new
> > > > > "Extended Type" format results in allocation of 255 new
> > > > > Attribute Type values
> > > > of
> > > > > format "TYPE.1" through "TYPE.255".
> > > > >
> > > > > i.e. zero is not for allocation.
> > > > >
> > > > > > Note each TLV in Section 7.3 may have more than one parent
> > > > > > Radius attributes (e.g., 241.TBD1.1 and 241.TBD2.1).
> Therefore
> > > > > > I'm not
> > > > sure
> > > > > > if these TLVs should go to Radius registry (Section 7.3 only
> > > > > > requests for "allocation" for TLV types).
> > > > > >
> > > > > > If need to define these TLV types in the registry, it must
> say
> > > > > > that these TLVs are independent and may associate with more
> > than
> > > > > > one attributes; but I don’t see any example like
> > > > > >   this in current registry.
> > > > > >
> > > > > > Alan - what is your opinion?
> > > > >
> > > > > This is a new thing to RADIUS.
> > > > >
> > > > > I suggest creating a new RADIUS TLV registry:
> > > > >
> > > > > name: RADIUS IP Port Configuration and Reporting TLVs
> > > > >
> > > > > contents: all of the TLVs which have more than one parent.
> > > > >
> > > > > Then, each parent TLV can be marked as NOT having child
> > attributes.
> > > > > Instead, they should be marked as using the new registry for
> > their
> > > > > children.
> > > >
> > > > Is this in addition to the action in Section 7.3, or instead of
> > > > the action in Section 7.3?
> > > >
> > > > If the latter, please send us a new version of the section. It
> > > > should tell us to create a registry and provide the following:
> > > >
> > > > - the name of the registry
> > > > -  the registration procedure for the registry (see RFC 5226)
> > > > - the initial contents of the registry (including a definition
> for
> > > > value 0 and the maximum value)
> > > >
> > > > For a recent example of a document that creates a registry, see
> > > > https://tools.ietf.org/html/rfc7361#section-7.2 or
> > > > https://tools.ietf.org/html/rfc7688#section-6.2.1.
> > > >
> > > > thanks,
> > > > Amanda
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > radext mailing list
> > > > radext@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/radext
> >
> >
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext