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

[Benoit Claise <[e-mail]>]

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