Re: [AAA-DOCTORS] Fwd: Benoit Claise's Discuss on draft-ietf-softwire-6rd-radius-attrib-10: (with DISCUSS and COMMENT)

[Sean Turner <[e-mail]>]

Any feedback folks?  I'm sitting on a discuss related to this.

spt

On 1/17/13 4:20 AM, Benoit Claise wrote:
> Dear AAA doctors,
>
> I updated my DISCUSS with the latest information. See below
> Regarding this COMMENT
>
>     Also, it would be helpful to be explicit about the value of the
>     Service-Type attribute in Access-Requests (I am assuming that this
>     is no longer "Call-Check", since the User-Password attribute is
>     included in the Access-Request).
>
> I believe that the AAA doctors should give clear guidelines to the
> draft-ietf-softwire-6rd-radius-attrib authors regarding the content of
> the Service-Type.
> If we can't, I propose not to insist on this issue.
> This is the reason why this is a COMMENT and not a DISCUSS.
>
> Feedback?
>
> Regards, Benoit
>
>
> -------- Original Message --------
> Subject: 	Benoit Claise's Discuss on
> draft-ietf-softwire-6rd-radius-attrib-10: (with DISCUSS and COMMENT)
> Date: 	Thu, 17 Jan 2013 01:13:06 -0800
> From: 	Benoit Claise <[e-mail]>
> To: 	The IESG <[e-mail]>
> CC: 	[e-mail],
> [e-mail]
>
>
>
> Benoit Claise has entered the following ballot position for
> draft-ietf-softwire-6rd-radius-attrib-10: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttp://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> The AAA doctors reviewed version 10
>
> 1. While Section 3 now does describe how authentication/authorization
> functions in a way that is compliant with RFC 2865 and 5080, there is no
> normative language and the requirements (e.g. for User-Name and
> User-Password attributes, Message-Authenticator attribute) are not
> included in Section 4.2.
>
> 2. Section 6 (Security Considerations) has a dangling sentence:
>
> ...
>
>     The MAC address spoofing is possible
>
> ...
>
>    OK... then what?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - Also, it would be helpful to be explicit about the value of the
> Service-Type attribute in Access-Requests (I am assuming that this is no
> longer "Call-Check", since the User-Password attribute is included in the
> Access-Request).
>
> - You started to use the terminology from RFC 5969, but for two terms
> only.
> It's a pity that you didn't reuse so other.
> 4.1. IPv6-6rd-Configuration Attribute
>
>         6rdPrefix
>
>           The Service Provider's 6rd IPv6 prefix represented as a 16
>           octet IPv6 address. The bits after the 6rdPrefixlen number of
>           bits in the prefix SHOULD be set to zero.
>
>         ...
>
>         6rdBRIPv4Address
>
>           One or more IPv4 addresses of the 6rd Border Relay(s) for a
>           given 6rd domain. The maximum RADIUS Attribute length of 255
>           octets results in a limit of 58 IPv4 addresses.
>
>>From RFC 5969:
>     6rd prefix            An IPv6 prefix selected by the service provider
>                           for use by a 6rd domain.  There is exactly one
>                           6rd prefix for a given 6rd domain.  An SP may
>                           deploy 6rd with a single 6rd domain or multiple
>                           6rd domains.
>
>     ...
>
>     BR IPv4 address       The IPv4 address of the 6rd Border Relay for a
>                           given 6rd domain.  This IPv4 address is used by
>                           the CE to send packets to a BR in order to
>                           reach IPv6 destinations outside of the 6rd
>                           domain.
>
>
>
>
>
>