Jim: Thanks for the review. Please see my comments below.
On 9/30/12 2:01 PM, "Jim Schaad" <[email protected]> wrote: >1. Should the Message Length field be present if the TLS Data field is >absent? [HZ] According to the text in the draft, the message length field should only be present if the L bit is set, usually for fragmented packets. In those cases, the TLS data field will be present, not absent. The only case TLS data will be absent is when empty TEAP packet it is used to indicate TEAP acknowledgement for either a fragmented message, a TLS Alert message or a TLS Finished message. So the message length field is not needed. We can clarify that in the draft. > >2. There is nothing to say which TLVs can and cannot occur in the Outer >TLVs in any easily findable method. Either a table or the string outer in >descriptions would be helpful. As an example, does the Authority-ID TLV >in >the outer TLV make sense? [HZ] We will add that table. > >3. I have gone through the fragmentation and did an implementation rather >than just reading it. The questions that I have on it now are slightly >different. Do TLVs need to be on a fragment boundary? Or do we just build >the entire message, fragment it into convenient sizes regardless of the >actual content of the message contents and sent the pieces across? If so >then the text should probably be re-written to be clearer. Specifically, >the message length is not useful for allocating the buffer on the first >round trip of messages where one can have a TLV added in to the content. >[HZ] Message length covers the whole TEAP packet even if fragmented. TLVs >do not need to be on a fragment boundary. Just build the whole message >contents and send the pieces across. We will provide some text to clarify >this. > > >_______________________________________________ >Emu mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
