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

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Sat, 9 Feb 2013 14:57:29 +0000

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 <[email-masked]> 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 <[email-masked]>
>> To: 	The IESG <[email-masked]>
>> CC: 	[email-masked],
>> [email-masked]
>> 
>> 
>> 
>> 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.
>> 
>> 
>> 
>> 
>> 
>>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 11 Feb 2013 18:14:13 +0100

Hi Bernard,

Please let us (Sean, Ralph, and I) is this version 11 is satisfactory 
wrt this DISCUSS: 
https://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot/#benoit-claise

Regards, Benoit