summary ------- sessions / netbios / tcp / transport independence: 2, 2.1, 2.5, 2.5.1, 10, 11 authentication / security (negotiation / re-negotiation): 2.8, 4.1.1, 4.1.2.2, 4.1.4 dfs 2.9 notes ----- 1.1.7 you still have a single point of failure in the establishment of a session. no redundancy is possible due to the removal of the abstraction that the netbios layer gave. 1.1.8 last sentence: no they did not. 2 tearing down a connection. how will a verified, secure connection be re-established, transparently? 2.1 adding a SMB session request message which passes a URL in of the form "cifs://fs.megacorp.com:139" is suggested. see http://mailhost.cb1.com/~lkcl/cifs/cifs-ext.txt 2.2 end of last sentence, first para, doesn't make grammatical sense. para 2: the default can be any means accepted by the internet community. url to address resolution should be used by but (but not part of) cifs. 2.5 detection failure. how does the failure detection mechanism work? (read appendixes a/b later. read them: there isn't one). 2.5.1 transport establishment messages means transport dependence. put a SMB session request message in, and cifs is transport independent. bullet 4: ties in with 2) above. 2.8 which specification has auth. been moved to? please inform the cifs list of this at your earliest convenience. 2.9 what is the value of STATUS_DFS_PATH_NOT_COVERED? where is it documented? will "not specifying the topology of dfs" affect anyone wishing to interoperate with other dfs servers? when can we expect the release of a document outlining dfs topology? 3.2.3 paging io. interesting. 3.7 are you sure about access modes? 0,1,2,3 for r,w,rw,x? i have seen NetMonitor decode access mode as a bit field 1,2,4,8 for r,w,rw,x). SMBopenX, i think. 3.8 aces. interesting. 3.12 DELETE_ON_CLOSE: description is not a grammatically correct sentence. BACKUP_SEMANTICS: over-ride normal security checks??? you must be kidding! POSIX_SEMANTICS: interesting. and good. 3.14.2 3.13.2 (???) SMB_COM_NT_TRANSACTION. interesting. 4 good comment on "simpler" future servers. 4.1.1 NEGOTIATE_PROTOCOL. lm 0.12. negotiating protocol has nothing to do with negotiating security. separate SMB_NEG_SECURITY is needed. see cifs-ext.txt. if CAP_EXTENDED_SECURITY is negotiated in lm 0.12 then GUID, SecurityBlob/bloblen and domain should not be present in NEGPROT. last paragraph should document exactly which protocols are used, so that other clients/servers can interoperate. 4.1.2.2 need to split SESS_SETUP_X down or create a SECURITY_SETUP_X. the concept of SESS_SETUP_X is like letting someone into a vault because they know the combination, and then letting them ransack the place once they are in. this is an old fashioned approach to security. session setup should have nothing to do with security. or, if it does, it should be re-negotiable on demand by the server _without_ affecting the session in any way (except if the security re-negotiation fails). a mechanism similar to oplock breaking could be used by the server to indicate such a demand. or a SESS_RESETUP_X. 4.1.4 tconX. similar comments about tconX security as to sesssetup security. 4.1.6.5 device info type query. interesting. this i presume is for use by "explorer" to decide which icon to display? 4.1.7 oh, good! an "echo" command. can something similar be added for the server to test the client? it would be best to have it as a capability. model it on the oplock support negotiation. 4.2.12 copy? this is new? regardless: a good idea. 4.2.13.9 FILE_ALT_NAME_INFO - insufficient info on this one. what is it? 4.2.13.10 FILE_STREAM_INFO - interesting! how exactly is this used? there will be some very good uses this can be put to. e.g for dce/rpc. 4.2.13.11 FILE_COMPRESSION_INFO - interesting. 4.2.15 SET/GET FILE INFO - can it be ensured/verified that time/dates are correctly documented? 4.3.3 check directory. what's this about servers not having a concept of a current working directory for a client? how does this tie in with findfirst/next? 10.1 the calling name is highly significant in NetBIOS. 10.1.1 how does this section (allowing connection refusal) tie in with "must accept on *SMBSERVER"? 10.2 no, no, no, and no again. most definitely damn well not. a CIFS server should have the right to REFUSE a connection from a server if it connects with *SMBSERVER. not being allowed to do so will destroy the abstraction and transport independence attained by NetBIOS, and make it more than useless. this is fine if it is your intention (to destroy NetBIOS), but you MUST replace it with something else that serves the same purpose. if the server refuses a connection on *SMBSERVER, the client MUST resolve the real NetBIOS name of the server, and use that. 11 good. useful only in the context of having a "smb session request" which does the same as what NetBIOS session request does at the moment, only better. most definitely not good about the port number. sections 10 and 11, if implemented, will severely limit the capabilities and the usefulness of cifs.