>>>>> "Dan" == Dan Harkins <[email protected]> writes:
Dan> Hi Sam,
Dan> I know you have expressed your desire to use an existing
Dan> registry to identify channel binding information, I just don't
Dan> recall hearing you say why it's a good idea. Could you explain
Dan> the benefits (once more) of using an existing registry versus
Dan> rolling our own?
Seems like it's less effort. When I look at the effort involved for the
two applications of CB that we've started to spec out in detail (abfab
and 802.11), many of the attributes we bind to are already in the RADIUS
namespace in the case of 802.11 or need to be there for other reasons in
the case of abfab. So, we have less registration work to do if we have
a registry that can import that namespace.
My assumption is that either we use diameter or that RADIUS solves their
attribute shortage problem and that if we need to register new things
that we are not going to run into problems doing that.
I think we should explicitly discuss this with radext/dime if we want to
reuse their registry.
Dan> If we use an existing registry I still think there are going
Dan> to be some link-level information that might not be in the
Dan> existing registry and we're going to have to roll our own
Dan> registry to some extent anyway.
I agree we'll have to register some things.
Dan> As a for instance (and this
Dan> example may be contrived), there might be some provider that
Dan> charges more for an 11n connection than an 11a/b/g
Dan> connection. It might be valuable to bind this information to
Dan> the channel to prevent billing issues later but I am not aware
Dan> of an attribute in an existing registry to support this.
Yep. It would take a lot for this particular example to be an
issue. You'd need to interoperably understand the charging model. It's
presumably possible that someone like 3GPP might want to do that.
If you aren't actually encoding the charging model over the wire, then
you're stuck understanding the charging model based on local
configuration and some identity of the network you're connecting to.
That's a problem that we have more ability to do with the existing
attributes.
So, I think we're better off with an existing registry provided that we
can get things we need registered in it. I think it's not a huge deal to
go do our own registry if we need to; doing so probably makes
implementation more messy on the AAA server especially, but is not
impossible.
I'd really like to know the answer soon though. Moonshot expects to be
funding development of CB for AAA servers during the first half of next
year. So let's see if we can come to consensus on this quickly.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
