On Sep 26, 2012, at 4:27 AM, <pierrick.se...@orange.com> wrote: > We also need for reactive notifications Interface_down (the interface went > down suddenly, e.g loss of wi-fi coverage, user switched off the interface) > and Interface_up. Here, I guess it can be done with "Interface announcement" > and "no Interface announcement", right?
Yes. Of course, the fact that you are asking these questions means that the document needs work! > I'm thinking about the case where the application is a connection manager. > After making a decision, e.g. regarding the mapping of a flow to a given > interface, the connection manager needs to associate a routing table to the > flow, configure NAT, modify firewall rules and policy table for source > address selection,... Yes, if you want to implement a connection manager, you will need additional API functionality. When we originally scoped the document, we assumed that the connection manager was implicitly *part* of the MIF API, rather than a customer of it. Of course the expectation is that some parts of the MIF API would be usable by the connection manager, but that the connection manager would require an extensively richer API. I think in this discussion that it's important to think about who could benefit from the document. It sounds like you have a wish to have a document that would allow you to implement a connection manager, perhaps one that could show the same behavior across different handsets produced by different manufacturers. If that's your motivation, it's certainly a valid use case for a MIF API. However, when we originally scoped this, we were not including that as part of the intended set of users for the documents—we were specifically targeting applications. Part of the reason for this was the understanding that most existing devices that we had in mind (e.g., iOS devices and Android devices) already had a pretty complete connection manager function, and that we didn't have the expertise to tell Apple or Google how to do a connection manager—that was expertise that they had already developed in-house, and we would expect substantial resistance to us trying to get them to actually do an API like that. That's not to say that such an API is a bad idea, but it's definitely scope creep for the work we are doing now. If you are interested in having an API with this functionality, I would argue that it ought to be presented as a supplementary API to the current document, rather than being added on to the current document. Otherwise, I don't think we have any hope of completing the current document in a timely manner (it could be argued that we have already failed to do so). What I would encourage you to do if you want to go down this path is think about the current document in terms of what it might _prevent_ you from doing in the supplementary document, and ask us to fix those bits. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
