Meeting Minutes, NSIS, 29th July 2008 ===================================== Jukka is still on his agenda slide Discusses the status of the WG documents Magnus says that the extensibility document needs a new editor. He believes it is important He says that it is not useful to have both WG chairs as the draft authors Elwyn says that he once volunteered for the document editing . We was, however, unsure what exactly has to contain Jukka will solicit feedback on the extensibility doc from the list RAO document: Jukka says it is useless Henning argues it is still useful but we need to re-word it a bit Mobility Applicability He talks about the content of the most recent version More reviews are needed Henning: Is there is enough energy to finish? Jukka mentions that Martin has a webpage about implementations: http://ietf.stiemerling.org Hannes suggests to use the next IETF meeting (on Saturday when the codesprint takes place). Roland says that he would like to have an interop, next ietf as said Henning starts his presentation on GIST He starts with the biggest issue on RAO The authors & chairs came up with an idea on how to offer a solution IESG does not want to have NSIS using RAO (makes the Internet to fall apart) Henning says that all query mode packets need to be intercepted and then intercepted. no problem... If a handler for the packet exists then it will be pushed to the specific function If no handler exists then it needs to be forwarded. Henning says that this is more complex (and more costly) Henning would be interested to hear information about the performance impact. Maybe someone with an implementation has some data Henning mentions last minute changes Henning finished his presentation Magnus: Question about Q & D mode separation The issue is: in some cases it is difficult or impossible to figure out whether a message is Q or D mode Magnus: Cannot you use a different port? Henning + Magnus: Sounds like a good idea. Reasonable Jukka: Are there NAT/FW implementation issues? Henning: Hmmm. Henning: We need to think about it Henning starts his next presentation on "Permission-based Sending NSLP" based on a research project Idea: You have to have a permission before you are allowed to send Deny by defaul t Not very clear to me why you cant use NATFW NSLP for this purpose... Henning: We haven't decided on that issue. What we couldn't quite use was "volume" restrictions. The NATFW NSLP does not have this feature Additionally, Henning specifies a couple of actions (such as changing the data path) Data traffic is also assumed to be cryptographically protected. Meeting is done.