Re: [sip-clf] draft-ietf-sipclf-format-01, Flag field

[Gonzalo Salgueiro <[e-mail]>]

Anders - 

The notion of adding both SCTP and TLS the flag was brought up on the list back in October and it went unreplied to (far as I can tell). Here is the snippet:

Although, given that TLS can ride on top of UDP or TCP, we may want to think of a second letter added to "L" to
denote TLS-over-TCP and TLS-over-UDP (I doubt any implementations are using TLS-over-UDP for signaling only, but given that SCTP is starting
to appear in kernels, maybe our flags ought to be "u, t, s, lu, lt, ls, U, T, S, LU, LT, LS").

The fact that this is the second time this has been raised leads me to believe there is a need. I will raise this as a discussion topic in the upcoming meeting Prague.

Regards,

Gonzalo


On Mar 15, 2011, at 3:13 PM, Anders Nygren wrote:

> On Tue, Mar 15, 2011 at 12:38 PM, Gonzalo Salgueiro <[e-mail]> wrote:
>> 
>> On Mar 15, 2011, at 1:49 PM, Anders Nygren wrote:
>> 
>> Hi
>> I will start writing one email for each issue in order to make it
>> easier to track the different discussions.
>> 
>> Thanks. That should help.
>> 
>> I would like to propose that the Flag Field is moved from the
>> <IndexPointers> to <MandatoryFields>. That way the <IndexPointers>
>> will be pure metadata that can be ignored if wanted and all interesting
>> data about the message is in the second line of the record.
>> 
>> I have no real preference on this one. I'll let others weigh in with their
>> thoughts.
>> 
>> Also I think it would be good to change the Sent/Received flag from
>> 
>> Sent/Received flag
>> 
>>         u = received UDP mesage
>>         t = received TCP mesage
>>         l = received TLS mesage
>>         U = sent UDP mesage
>>         T = sent TCP mesage
>>         L = sent TLS mesage
>> 
>> To
>> Sent/Received flag [1 byte]
>>         r = received message
>>         s = sent message
>> 
>> And add
>> Protocol [1 byte]
>>         u = UDP
>>         t = TCP
>>         l = TLS
>> 
>> Since the proposed CLF already requires quite a lot of space there is
>> little reason to
>> try to pack different parameters into the same byte.
>> 
>> This is what was proposed early on, but the group decided on consolidating
>> the two. I'm not violently opposed or in favor of either, but I don't see
>> any real benefit to separating the two out since all permutations are
>> covered in a single easy byte.
> 
> It is not a big deal but for instance if You want to find all sent messages it
> is 3 tests instead of one for each record, (and if we add SCTP, see below),
> then it would be 4. And when searching for all messages on a specific protocol
> it is 2 tests instead of one.
> 
> A quick check found RFC 4168, "The Stream Control Transmission
> Protocol (SCTP) as a Transport for the Session Initiation Protocol
> (SIP)"
> 
> So maybe SCTP should be added as a protocol. I do not know if there is something
> similar to TLS over SCTP, but I suspect things may get messy with a lot of
> permutations in the future.
> 
> So maybe we should consider 3 parameters
> send/receive    sent, received
> protocol           tcp, udp, sctp
> secure             encrypted, plain text
> 
> /Anders
> 
>> Regards,
>> Gonzalo
>> 
>> /Anders
>> _______________________________________________
>> sip-clf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sip-clf
>> 
>>