Hi, Linda.
Thank you for your reply and explannation!
As for the question 6, the last paragraph in section 3 seems to describe
the communication when T1 expires. Does it mean that when the mB4 is responded
in T1 there is no communication between NAS and AAA server?
Best regards,
Linhui Sun
[email protected]
发件人： wang.cui1
发送时间： 2014-10-09 15:42
收件人： [email protected]
抄送： meng.wei2; mohamed.boucadair; wang.cui1; wangqian; softwires
主题： RE:Comments on draft-hu-softwire-multicast-radius-ext
Hi, Linhui,
Thanks for your comments. Please see inline.
And all your comments we will update them in the next version.
Many thanks.
BRs
Linda Wang
"[email protected]" <[email protected]> 写于 2014-10-06 11:38:50:
> "[email protected]" <[email protected]>
> 2014-10-06 11:38
>
> 收件人
>
> [email protected], [email protected],
> [email protected], [email protected],
>
> 抄送
>
> softwires <[email protected]>
>
> 主题
>
> Comments on draft-hu-softwire-multicast-radius-ext
>
> Dear authors,
>
> I have read this document and think it is meaningful to propose a
> new RADIUS attribute to carry the IPv6 prefixes together with the
> DHCPv6 option defined in draft-ietf-softwire-multicast-prefix-option-07.
>
> Here are some comments about this document.
>
> 1. The following paragraph repeats twice (section 3 and section 4)
> in this document.
> 'If the NAS does not receive the Multicast-Prefixes-64 attribute in
> the Access-Accept message, it MAY fall back to a pre-configured
> default Multicast-Prefixes-64, if any. If the NAS does not have any
> pre-configured, the delivery of multicast traffic is not supported.'
> Do you think it is more suitable to remove the repeated one in section 3?
//Linda: I do agree with you. Thanks.
>
> 2. The architecture of this document seems not very reasonable. Do
> you think it could be of a better structure? Here are my suggestions.
> a) The section 4 is intended to specify the new RADIUS attribute, it
> seems that the most content of the section 4.1 is describing the
> RADIUS client behavior. Do you think it is appropriate to treat this
> part as a separate section called the Client Behavior.
> b) And I think the sequence of the sections could be modified to
> become better organized. The section RADIUS Attribute could be
> introduced first, then the section Client Behavior would be
> discussed later. While the Multicast-Prefixes-64 Configuration with
> RADIUS and DHCPv6 section is more appropriate to locate in the rear
> of those two sections.
//Linda: Originally, we considered it would be clearer to present the
the whole message exchange flow first, then follow this flow, readers
can catch a better understanding of where this attribute would be brought
with and how this attribute would be used. After that, we illustrated the
format of this attribute naturally. Do you think this can explain
why we presented this draft in this structure?
As for your proposal about section 4.1, in fact, in this section we wanted
to emphasize the changed details which were caused by this new attribute,
not emphasize the separated client behavior or server behavior. So we
integrated them together.
But, we still will carefully consider your proposal structure later. Thanks.
>
> 3. The ‘DHCPv6 Advertisement’ in Figure 1,2 could be modified as
> ‘DHCPv6 Advertise’ in a more standardized way according to the RFC 3315.
//Linda: I do agree with you. Thanks.
>
> 4. There seems to be a conflict between the figure 1 and its
> corresponding description.
> From the Figure 1, we can conclude that the DHCPv6 Advertise message
> carries the DHCPv6 OPTION_PREFIX64 option.
> However, if we refer to the content, it states that ‘the NAS SHALL
> use the prefixes returned in the RADIUS Multicast-Prefixes-64
> attribute to populate the DHCPv6 OPTION_PREFIX64 option in the
> DHCPv6 reply message’ in section 3.
> Do you think it could be better to keep the consistence between the
> figure and its description.
//Linda: I do agree with you. Thanks.
>
> 5. Could you please explain why the DHCPv6 Request message in the
> Figure 2 does not carry a DHCPv6 OPTION_PREFIX64?
//Linda: Yes, you are right. The DHCPv6 Request message should carry this
option.
>
> 6. Do you think it is necessary to add a separate paragraph that
> defines how the NAS will communicate with the AAA server when the
> mB4 is at its DHCP renew stage to make the document more comprehensive?
//Linda: In the last paragraph in section 3, we explain the DHCP RENEW stage,
do
you think it is enough for your question?
>
> Best regards,
> Linhui Sun
>
> [email protected]
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
