Oslo Minutes (11 July, 1999) ============================ Present: Juergen Schoenwalder (JS), University of Braunscheig Aiko Pras (AP), University of Twente Ron Sprenkel (RS) University of Twente Bert Wijnen (BW) IBM Bert-Jan van Beijnum (BJ) University of Twente Eric Schoenfelder(E) Dave Thaler (D) Microsoft Agenda: ======= 1. discuss any open issues w.r.t. the SNMP over TCP document 2. discuss and select an approach for SNMP payload compression 3. work out the details of the GetSubTree protocol operation 4. (if time is left) discuss the SMIng specification 5. discuss other topics such as meta-level discussions on NMRG. We started the meeting outside: the wether was nice and the door was closed so we couldn’t get in. 1 SNMP over TCP document ======================== *About closing TCP connection: what when connections gets lost/closes? option1: do not specify. motivation: it aligns with the UDP case option2:do specify. TCP i.e. a request is send and agent received it. motivtion: with UDP: you dont’n know of a request arrives, with tcp you do know. Discussion ---------- example: if you do a bulkset, you want to know wether it succeeded (arrival is nice, but you don’t know if it succeeded when the tcp connection is broken). observation: you could do either a confirmed or an unconfirmed set- opeeration. After we went in, Bert-Jan made some coffee, which we all appreciated! The fundamental issue is: what are the consequences for the application. traps & inform: transport gets confirmed. with sets: confirms tell you that they have been transported and processed. BW: not specify behavior when TCP closes/breaks JS: one way shut down should be specified as legal. EOF only when all packets have been processed. BW: make a note about closing connection in one direction in the document. AP: poors us a cup of coffee. Include notes about ‘half closing a connection’ (about what to assume and what not in this case); The manager should not assume anything except what can be based on responses. Include explanation about implementation choices whether or not to process arrived packets. Explain about the meaning of responses/replies/informs received (authentication and encryption has taken place). Harald’s email: the message was about how to explain things. Conclusion: There is (rough) consensus about not include such detialed levels of info in the document. The AD takes care of getting the next round of coffee. Conclusions: ------------ - put in text that processing outstanding packets after closing is up to the implementer. - the sending entity should not assume anything about processing or not, but rely on normal SNMP operation. - wording to include about half closed connections. 2. SNMP payload compression =========================== The options are: 1. another encryption algorithm 2. use msgFlag bits to signal compression 3. define a new PDUtype 4. (added) (Wes H.) introduce a new security model. 5. (added) (RS) overload the security name: whether compression is used or not. This has a simiilar disadvantage as in 1. and it is not an architectural clean thing to do (easy to implement though) Discussion: ----------- BW: the better it fits in v3 the better it is JS: the better is fits in v1 the better it is BW: the PDU solution might be a problem. JS: but if one has to be done (getSubTreePDU), two can be done as well!? BW: can live with a new PDU provided that a new PDU for get SubTree is needed. Some procedural proposal: - select a solution - propose a compression method - include option for other compression methods If you preconfigure compression, you don’t need a new PDU type. After discussion, the following came out - First choice: new PDU tpye, - Second choice msgFlag, - Third choice encryption or option 5 or option 4. First and second choice remain to be chosen from. All agree with one, under the following consideration: if a new PDU is being introduced, then introduce a new PDU type for compression! Implementation issues: - no prescription about how to do the compression from the PDU contructed or under construction, this is left to the implementation. 3.getSubTree SNMP operation =========================== BW: suggestion - give a consideration to trick the getBULK, to avoid new PDU type discussions. BW has to leave the meeting. Dave attends the meeting. Dave: Include in the document the option to use IPsec for compression. Question: what if there are multiple subtrees? AP: subtrees can be very large, that should be allowed. This calls for multiple replies (to limit buffer size). Observation: after a single reply the manager could be noted that there is more, it is the manager that asks for the next portion. This is another possible scenario. Advantage is that in case of single threaded agents, it won’t be blocked during the getSubTree operation. Disadvantage is relative large RTT’s. Everybody agrees that in getSubTree we assume that TCP is being used. It is not mandatory to return a consistent response to a getSubTree. Sending multiple responses: set timer for inter packet timeout, a flag for the last response. It should be possible to use getSubTree over UDP. Question: In case of request retransmission a new request ID should be used, or should the same be used? Solution: current specs recommend (should) to use a new ID for retransmissions. Options: specify MUST, because it’s a new PDU. Or SHOULD with an explanation why. Qs: send multiple responses: TCP is in sequence, UDP we don’t know. How to indentify the last response, what about error situations. Question - If an error occurs: should or must be the last response? Solution: MUST seem to be the appropriate solution. Quetion: Is it useful that the manager can stop a getSubTree? Solution: Using TCP you can simply close the connection. Dave: What about a set for row creation to specify the subtree and the agent responds with a bunch of traps contain the subtree? Conclusion: This is a very good suggestion, which will be studied further at a later stage. Qs: multiple responses over UDP, i.e. sequence numbers number be used, where to have them in the PDU? Possible solutions: - An option is to use the error-status (which is unused in this case). - Put a verbind in each PDU. - Build a special respond message. There is preference for the first option Question: how to code the last PDU? Possible solution: - use highest bit of the error status - .or introduce a new error code option 2 portentially influences documents such as 190X, Question: what’s going to happen when there are holes in a/the subtree? JS proposes an algorithm to solve this problem (which can be used also in the set/trap ‘solution’) and can be easily done by the agent: just return ‘noSuchInstance’ for te holes. Intermezzo: (I really had concentrationproblems here, so the minutes do not make sense to me ;-)))). Make an association between oid and ? this has many advantages and really adds something (it is really different from the getBULK). MIB Bowsing: getSubTree(1), you do not get tables as table. To get tables as table you need to get each column individually. There is preference for non-repeating repeater. JS: is it useful to have a timestamp on each ‘fragment’ (i.e. a side question made by BJ pops up again ;-)))). For some variables it could be useful. End of intermezzo (I think I’m back again). About sequence numbering: Use of row-numbers could be helpful for UDP, however we expect things to use TCP, therefore there is no need or it. Asymmetric Compession can be useful in getSubTree: an uncompressed get request and a compressed reply. How to continue: - implementing & writing an ID should go hand-in-hand. Next Meeting ============ - We arrange another meeting for later this week to discuss things further - next meeting is: Thursday July 15, 1999 13:00-15:00.