FW: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis

["David B. Nelson" <d.b.nelson@comcast.net>]

IESG DISCUSS and GenArt COMMENT.

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Wednesday, October 17, 2007 1:41 PM
> To: iesg@ietf.org
> Cc: ben@estacado.net; radext-chairs@tools.ietf.org
> Subject: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis
> 
> Discuss:
> 
>   Includes comments from the Gen-ART Review by Ben Campbell.
> 
>   Section 3, first paragraph, says:
>   >
>   > All NAS and session identification attributes included in a
>   > CoA-Request or Disconnect-Request packet MUST match at least one
>   > session in order for a Request to be successful; otherwise a
>   > Disconnect-NAK or CoA-NAK MUST be sent.
>   >
>   What does it mean for a NAS identification attribute to match a
>   session? I assume we are using the NAS identifiers as a scope in
>   which the session identifiers have meaning, so that all sessions
>   could be considered of having an implied NAS property?  This is
>   ambiguous.  Please clarify.
> 
>   Section 3.1, last paragraph, says:
>   >
>   > Since Disconnect and CoA responses are authenticated on the
>   > entire packet contents, the stripping of the Proxy-State
>   > Attribute invalidates the integrity check - so the proxy needs
>   > to recompute it.
>   >
>   Please say the proxy MUST recompute...
> 
>   Section 3.5, 5th paragraph, says:
>   >
>   > When the HMAC-MD5 message integrity check is calculated the
>   > Request Authenticator field and Message-Authenticator Attribute
>   > should be considered to be sixteen octets of zero.
>   >
>   Both of these are set to 16 zero octets.  That is not clear.
>   Also, please reword to use MUST.
> 
> Comment:
> 
>   From Gen-ART Review by Ben Campbell.
> 
>   In Section 3.2, It would be helpful to mention how Authorize Only
>   is used to ease mapping to Diameter, and reference the Diameter
>   Considerations section.  As it is, the reader wonders what the
>   semantic effect of the resulting Access-Request message is
>   supposed to be.
> 
>   Section 6.2, 4th paragraph, raises a question.  Can a proxy be
>   expected to easily know if it is one-hop away from the NAS?  Is the
>   mechanism for determining this well-known or documented somewhere
>   that could be referenced here?




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