Hi Vidya Comments inline as appropriate. Narayanan, Vidya wrote: >> Your email indicates that you would: >> >> a) somehow require that a visitor's laptop run an NEA client, >> b) expect the device to support PAs that the server requires to be >> checked, and c) trust data coming out of it, >> >> rather than treat that endpoint as an unknown endpoint and do >> IDS/IPS in the network. You are limiting my options to a small subset of what I would have available. I may sandbox systems that don't have an NEA client and are unwilling to install one, they would be treated as an unknown node and given very limited access, they wouldn't be allowed onto the trusted network for instance. I would expect some information to be available which I would then be able to check against my policy. I would assume a limited amount of trust but would continue to have other mechanisms in place to be informed where that limited trust has been abused. >> Other than finding this a rather bizzarre trust model, I >> have to say that there will be a very small set of such >> endpoints where the owner of that endpoint is going to be >> thrilled to allow you to place such clients on his/her >> device and perform updates on it. If they wish to join my network they have to abide by the policies I have in place, they don't like it, they don't get to play. >> In short, this is exactly the type of endpoint I wouldn't imagine >> NEA being useful for! NEA is a means to automate the information gathering about this endpoint, if they don't agree to the policies, they will have options to. If a person or device doesn't agree with the policies in place, it doesn't mean I should still provide full access for them. Risk management will dictate what will or will not be allowed. Darryl (Dassa) Lynch _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf