Re: [AAA-DOCTORS] Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-ext-05: (with DISCUSS and COMMENT)

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi Roberta,

Thank you for your timely answer. 

I will address part of your answers, and I am waiting for the original AAA Doctors reviewers to jump in for the other. 

See in-line. I edited out the items that I will not discuss in this mail. 

Regards,

Dan




> -----Original Message-----
> From: Maglione Roberta [mailto:[e-mail]]
> Sent: Thursday, August 11, 2011 3:39 PM
> To: Romascanu, Dan (Dan); The IESG
> Cc: [e-mail]; [e-mail]; draft-ietf-
> [e-mail]; Ullio Mario
> Subject: RE: Dan Romascanu's Discuss on draft-ietf-softwire-dslite-
> radius-ext-05: (with DISCUSS and COMMENT)
> 
> Hello,
>    Please see answers inline [RM]
> Thanks,
> Regards,
> Roberta
> 
> -----Original Message-----
> From: Dan Romascanu [mailto:[e-mail]]
> Sent: giovedì 11 agosto 2011 11.16
> To: The IESG
> Cc: [e-mail]; [e-mail]; draft-ietf-
> [e-mail]
> Subject: Dan Romascanu's Discuss on draft-ietf-softwire-dslite-radius-
> ext-05: (with DISCUSS and COMMENT)
> 
> Dan Romascanu has entered the following ballot position for
> draft-ietf-softwire-dslite-radius-ext-05: 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 to http://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 

...

> 
> 3. Section 4.1 describes a NAS sending an Access-Accept to a RADIUS
> server.   Either this is a typo (e.g. it should say Access-Request) or
> the authors are making a major change to the RADIUS protocol:
>    This attribute MAY be used in Access-Accept packets as a hint to the
>    RADIUS server; for example if the NAS is pre-configured with a
>    default tunnel name, this name MAY be inserted in the attribute.
> The
>    RADIUS server MAY ignore the hint sent by the NAS and it MAY assign
> a
>    different AFTR tunnel name.
> 
> [RM] it's a typo, sorry I have fixed it in version -05
> 
> 


[[DR]] Fine. I am editing out this item. 

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 1. The use of kewords in section 3 seems inconsistent. Why are the
> 'may' and 'shall' in the second paragraph of the section non-
> capitalized, while in the rest of the section the keywords are
> capitalized.
> 
> [RM] I'm going to change them in this paragraph.
> 
> > This list may also contain the AFTR Tunnel Name.  When
>    the NAS receives a DHCPv6 client request containing the DS-Lite
>    tunnel Option, the NAS shall use the name returned in the RADIUS DS-
>    Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME
>    option in the DHCPv6 reply message.
> 
[[DR]] I believe that the 'shall' needs to be capitalized, so that the editing is consistent with the rest of the section. Is there a special reason not to use SHALL? 

> 2. I support item #2 in David's DISCUSS about the need to document the
> operational considerations of the NAS configuration and device
> configuration changes.
> 
> [RM] I tried to clarify this point in one of my previous emails, please
> let me know if the explanation addresses your comment.
> 
[[DR]]  Not completely. This is still a configuration change, even if this is related to per-session/ per-users configuration/behavior. It is not clear to me how operators would know that such change occurred on the NAS. I will let David (holder of the DISCUSS) on this issue decide. 


> 3. Two of the AAA-Doctors made in early reviews the comment that it was
> not clear why the authors needed a new AVP when the RADIUS tunnel
> attributes (RFC2868) could probably be reused here. One of them even
> proposed an alternative based on RFC2868 but authors argued that their
> approach was better. that may be true, but it would have been good to
> document the decision and explain why the alternative was rejected.
> 
> [RM] When we first presented this draft in the RADEXT WG last year, the
> document contained two different attributes one for the DS-Lite-Tunnel-
> Name and another for the DS-Lite-Tunnel-Address, in order to match
> exactly the two different DHCPv6 options proposed for the same purpose.
> The idea to have a new AVP instead of re-using the one from RFC2868
> came up in order to have a 1:1 mapping between RADIUS AVPs and DHCPv6
> options. The reason behind this choice was to avoid having an extra
> logic implemented on the NAS required to decide in which DHCPv6 option
> inserting the value received from RADIUS AVP.
> After a long discussion based on DHC WG feedback, the DHCPv6 option
> related to AFTR address was removed from that document and only the
> AFTR name DHCPv6 option was kept, thus we updated this draft according
> to that decision.
> 
[[DR]] Your explanation makes sense, but as I said in the comment the reasoning ...

> The idea to have a new AVP instead of re-using the one from RFC2868
> came up in order to have a 1:1 mapping between RADIUS AVPs and DHCPv6
> options. The reason behind this choice was to avoid having an extra
> logic implemented on the NAS required to decide in which DHCPv6 option
> inserting the value received from RADIUS AVP.

... would be useful to be included in the document. 

> Thanks,
> Regards,
> Roberta