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

[Peter Musgrave <[e-mail]>]

Hi, 

I am a fan of keeping separate things separate. So I agree transport and send/receive would benefit from being untangled (IIRC, I may be the one responsible for entangling them).

The transport field was intended to match the SIP transport protocol - so I think one byte for UDP, TCP, TLS, SCTP is ok. 

I don't see the need to have a separate security field (since we already have TCP/TLS sharing a byte) - so I would continue in the same vein. It's not a biggie for me - so if others want a secure/not secure byte that would be okay. 

Peter Musgrave
(as individual)

On 2011-03-15, at 3:58 PM, Gonzalo Salgueiro wrote:

> 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
>>> 
>>> 
> 
> _______________________________________________
> sip-clf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-clf