Hi Eric, all,
Thank your very much for handling this review and for your
comments !
We'd also like to apologize for the long delay. After some
internal discussions, we reach a consensus.
Basically, this document aims to provide guidance to solution documents
for the Mobile IPv6 bootstrapping problem. It is thus
a companion document to the following document:
For RADIUS based solution:
draft-ietf-mip6-radius
For Diameter based solution:
draft-ietf-dime-mip6-split
draft-ietf-dime-mip6-integrated
Hence, the goal was to catch what were the needed features that people
wanted to see in AAA applications.
Having said that, I agree that it would have been better to say: "A solution
MUST define how an NAS will' instead of "NAS MUST" but as you said the
document would be really more difficult to read.
Concerning the "SHOULD", we agree with you that we need to revisit our
requirement to clarify what we mean by this "SHOULD" in a requirement
documents. As a requirement document, we can not say if a feature as to be
a MUST or a SHOULD. We just require (or not) some features.
Based on this remark, we propose the following modifications:
1/
CHANGE:
G4.4 The HA SHOULD be able to request the AAAH server to
authenticate the MN with the value in the MN-AAA Mobility Message
Authentication Option.
TO:
G4.4 The HA supporting the Authentication Protocol MUST be able
to request the AAAH server to authenticate the MN with the value
in the MN-AAA Mobility Message Authentication Option.
2/
CHANGE:
G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can
allocate a Home Agent to the MN. Therefore the NAS SHOULD be able
to include suggested HA address in the ASP in the NAS - AAA
interaction.
TO:
G6.3 The ASP/MSP supporting the allocation of a Home Agent MUST be
able to indicate to the MSA if it can
allocate a Home Agent to the MN. Therefore the NAS MUST be able
to include suggested HA address in the ASP in the NAS - AAA
interaction.
3/ We do not want to change the following requirement (in section 5.5):
The HA SHOULD be able to communicate to the AAAH server the Home
Address allocated to the MN and the FQDN of the MN (e.g., for
allowing the AAAH server to perform a DNS update on behalf of the
MN).
Because it is not clear if it would be a problem if a solution document
does not support it. Thus a SHOULD seems ok.
4/ Concerning the second requirement in section 5.5:
The AAAH SHOULD be able to indicate to the HA if the MN is
authorized to autoconfigure its Home Address.
We think it is ok to let it but we want to add the following sentence:
If the AAAH does not indicate to the HA if a MN is authorized to autoconfigure
its address, the MN is not authorized.
If you agree with these modifications and if they address your comments,
we will produce a -02 version.
Thanks again,
Best regards,
Julien Bournelle
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
