[Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-01.txt

I have sent my rechartering questions around regarding these two 
documents. I took a brief look at them and I wonder what the 
relationship between the two documents is. Why are there 2 documents on 
almost the same subject?

When I browse through 
http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt 
then I sometimes get the impression that you would like to later 
standardize a Diameter application. I wasn't sure why additional AVPs 
aren't sufficient, in case existing AVPs cannot be re-used?

Let me also comment on a few selected items:

AAA-based prefix authorization (PA) application MUST run between a NAS, 
located on AR, LMA, MR, etc. and an AAA server.

[hannes] This requirement does not say a lot. The AAA protocol is always 
run between a client and a server.

AAA-based PA application MUST support the AAA client to request prefixes 
from an AAA server. AAA-based PA application MUST support the client to 
give back the prefixes to the AAA server.

[hannes] With the last sentence you mean that you need to have a way to 
indicate that the AAA session is terminated?

If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices on 
the network, the certificate or the information needed to obtain a 
certificate SHOULD also be sent by the AAA server to NAS.

[hannes] What information do you exactly want to carry towards the AAA 
client?

In point-to-point link operation, the NAS MUST identify the interface of 
MN in its request. The NAS MAY provide a prefix hint, e.g. of length /48 
to which the AAA server MUST reply with one or more prefixes, e.g. of 
length /64.

[hannes] how would such an interface identifier look like?

In point-to-point operation, the AAA server MAY assign the prefix(es) 
and related parameters such as the lifetime and the certificates to MN 
from MN's profile.

[hannes] I am not sure what this means. You mean that the AAA server 
should keep state to make sure that it does not forget what it has 
provided to the MN?
For some reason the problem is not well described. In Section 3 of 
draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC 4818 
but I do not quite understand what you would like to see happening instead.

AAA-based prefix authorization application SHOULD support prefix release 
procedures.

[hannes] isn't this the same as mentioned in the previous requirement 
"AAA-based PA application MUST support the client to give back the 
prefixes to the AAA server. "

The NAS is responsible for renewing the prefixes when the lifetime 
expires. The NAS SHOULD be able to extend the lifetime of the prefixes 
using messages designed for this purpose.

[hannes] Why wouldn't we tie the lifetime of the prefix to the lifetime 
of the AAA session itself? Makes things much easier. The same applies a 
bit to this requirement: "It SHOULD be possible to renumber the prefixes 
authorized by AAA server. The AAA server SHOULD initiate prefix 
renumbering process. "

RFC2119 seems to be a bit randomly used in the document.

Ciao
Hannes

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime