[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IESG review DISCUSS ondraft-ietf-radext-management-authorization-06.txt
> -----Original Message-----
> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On
> Behalf Of Pasi.Eronen@nokia.com
> Sent: Monday, April 20, 2009 1:32 PM
> To: d.b.nelson@comcast.net
> Cc: iesg@ietf.org; radiusext@ops.ietf.org
> Subject: RE: IESG review DISCUSS
> ondraft-ietf-radext-management-authorization-06.txt
>
> Dave Nelson wrote:
>
> > The attributes that have variability are the NAS-ID and
> NAS-Port-ID,
> > which are basically as you have indicated -- human readable strings
> > with no specific recommended format. I have to think that these
> > attributes were (a) intended for use in accounting, where they are
> > simply logged verbatim for humans to inspect later on or (b) were
> > intended for use in authentication and/or or authorization
> decisions,
> > in some vendor-specific fashion. The RFCs don't give us
> any guidance
> > here.
> >
> > If there are (b) usages, it might be nice to standardize
> them someday.
> > The point we were making was that it's not directly related
> to the NAS
> > Management Authorization work, and it's something that may be very
> > difficult to achieve consensus on, given the large diversity of
> > implementations over a large number of years. In sort, the authors
> > feel that it would be unreasonable to hold *this* draft accountable
> > for solving that problem.
>
> I was not asking this draft to fully solve the problems about
> NAS-Port-Id.
>
> I was asking a very specific suggestion: given that many
> NASes implementing this specification will probably send the
> IP address (and possibly port number) of the SSH/NETCONF/etc.
> client *somewhere* in the Access-Request packet, should the
> document give some guidance on what attribute/format could be used?
>
> Do I understand correctly that you think it's better to *not*
> give any guidance, leaving each vendor to do things differently?
> (remembering that we're talking about new NASes that
> implement the attributes from this draft, not old stuff)
>
> Best regards,
> Pasi
>
My opinion is that it is better to not give any guidance in this
document, for the reasons mentioned by David. A proper and complete
solution would require long discussions and I am not certain is within
the scope here, and in the absence of a complete solution I prefer to
leave this implementation dependent at this point in time.
Dan
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>