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

["Ralph Droms (rdroms)" <[e-mail]>]

I'd like to get this document cleared up before I step down as Int AD.  Rev -11 has been published.  Does it address the remaining Discuss points?

- Ralph

On Jan 22, 2013, at 3:18 PM 1/22/13, Sean Turner <[e-mail]> wrote:

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