> PM: It seems like james morris is not a big fan of > overloading secmark,
We are NOT overloading the security identifier (secmark) on the skb since there's no such thing as an internal Vs. external label in the secpoint design. There's only a "default" label that very intuitively gets overridden by a "real" label that comes with the data. There can be NOTHING sacrosanct about not replacing a default label with the correct one. As I see Joe Nall has rightly pointed out later, there's only one label on an skb. > but > seems that venkat believes in that. if we need to get > that in the > future, we need to get away from overloading the secmark field Status on the secid patch: 1. I am currently looking at the igmp issue and the general issue of how to handle packets that aren't associated with a socket. I am close to a resolution on this. 2. Responded to Joshua's concerns yesterday. If he still has any concerns I am hoping he will get back with a specific counter proposal that will make sense for the entire flow control problem we are trying to solve. 3. Working with Chris PeBenito on the ipsec controls (already past the secid discussions). 4. James DID have concerns over the "perceived" overloading of the secmark field, but it's really a mute issue considering the fact that in the secmark case it's a "default" vs. "real" label as explained above, and hence no overloading to begin with. Ultimately, he would like to see policy upstreamed before he will consider upstreaming the secid patchset. 5. Suggested naming changes, but not sure they will be done. 6. Also just now looking at the xfrm problems Joy encountered. All in all, I believe we are progressing... -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
