Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls

From: Chris Lonvick <[email-masked]>
Date: Mon, 3 May 2010 06:48:54 -0700 (PDT)

Hi,

I'm good with that as well.

Joe, can you edit and resubmit a new ID?

Sean, if this covers all of your edits, when can we expect to see it on 
the IESG agenda, and when can we see IETF LC?

Thanks,
Chris

On Tue, 27 Apr 2010, tom.petch wrote:

> ----- Original Message -----
> From: "Joseph Salowey (jsalowey)" <[email-masked]>
> To: "Sean Turner" <[email-masked]>; "Chris Lonvick (clonvick)"
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, April 23, 2010 5:02 PM
>
>
>> Anybody on the list have objection to adding the Chris' suggested text
>> and the DCCP service code SYLG?
>
> I see SYSL used as a four character code for syslog in other settings and would
> prefer that.  Else, following the principle of dropping vowels, SSLG, but I
> think that not as good.
>
> Tom Petch
>
>> Thanks,
>>
>> Joe
>>
>>> -----Original Message-----
>>> From: Sean Turner [mailto:[email-masked]]
>>> Sent: Thursday, April 22, 2010 3:55 PM
>>> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick)
>>> Cc: [email-masked]
>>> Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls
>>>
>>> I'm fine with either.  Regardless, the IANA considerations section
>> needs
>>> to be updated to register the service code - unless some other
>> document
>>> that I don't know about already did.  Notes for the registration can
>> be
>>> found here:
>>> http://www.iana.org/assignments/service-codes/service-codes.xhtml
>>>
>>> But, all that I think is needed is some text asking IANA to register
>> the
>>> following DCCP service code:
>>>
>>>    1398361159   SYLG   SYSLOG Protocol    [TBD]
>>>
>>> spt
>>>
>>> Joseph Salowey (jsalowey) wrote:
>>>> Hi Chris,
>>>>
>>>> CCID 3 looks good to me, I'm OK with the text.
>>>>
>>>> We could just use the port number, 6514, as the service code. Since
>> the
>>>> service identifier applies to more than DCCP, it probably makes more
>>>> sense the follow the scheme defined in RFC4340 where a 4 letter
>> string
>>>> is used as the service identifier, such as the following:
>>>>
>>>> SC:SYLG
>>>> SC=x53594C47
>>>> SC=1398361159
>>>>
>>>> Cheers,
>>>>
>>>> Joe
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf
>>>>> Of Chris Lonvick (clonvick)
>>>>> Sent: Monday, April 12, 2010 6:40 AM
>>>>> To: [email-masked]
>>>>> Subject: Re: [Syslog] AD review comments for draft-ietf-syslog-dtls
>>>>>
>>>>> Hi Folks,
>>>>>
>>>>> I'll suggest CCID 3 because that's my lucky number.  ;-)
>>>>>
>>>>> Seriously, here is a relevant point from RFC 5238:
>>>>> ===vvv===
>>>>>     In addition to the retransmission issues, if the throughput
>> needs
>>>> of
>>>>>     the actual application data differ from the needs of the DTLS
>>>>>     handshake, it is possible that the handshake transference could
>>>> leave
>>>>>     the DCCP congestion control in a state that is not immediately
>>>>>     suitable for the application data that will follow.  For
>> example,
>>>>>     DCCP Congestion Control Identifier (CCID) 2 ([RFC4341])
>> congestion
>>>>>     control uses an Additive Increase Multiplicative Decrease
>> (AIMD)
>>>>>     algorithm similar to TCP congestion control.  If it is used,
>> then
>>>> it
>>>>>     is possible that transference of a large handshake could cause
>> a
>>>>>     multiplicative decrease that would not have happened with the
>>>>>     application data.  The application might then be throttled
>> while
>>>>>     waiting for additive increase to return throughput to
>> acceptable
>>>>>     levels.
>>>>>
>>>>>     Applications where this might be a problem should consider
>> using
>>>> DCCP
>>>>>     CCID 3 ([RFC4342]).  CCID 3 implements TCP-Friendly Rate
>> Control
>>>>>     (TFRC, [RFC3448])).  TFRC varies the allowed throughput more
>>>> slowly
>>>>>     than AIMD and might avoid the discontinuities possible with
>> CCID
>>>> 2.
>>>>> ===^^^===
>>>>>
>>>>> My reasoning for choosing CCID 3 is that when some devices start up
>>>> they
>>>>> will queue up syslog messages until the network is up, and then
>> they
>>>> will
>>>>> start to deliver them.  I don't want a large handshake to throttle
>>>> that
>>>>> initial burst of messages.  (Please challenge this assumption if
>> you
>>>> have
>>>>> a better understanding of the process.)
>>>>>
>>>>> I'll suggest that the specific wording will need to be: "MUST
>>>> implement
>>>>> CCID 3 and SHOULD implement CCID 2 to ensure interoperability".
>> Does
>>>> that
>>>>> sound OK to everyone?
>>>>>
>>>>>
>>>>> Joe: can you look at Sean's second question and let us know about
>>>> that?
>>>>> Thanks,
>>>>> Chris
>>>>>
>>>>> On Thu, 8 Apr 2010, Sean Turner wrote:
>>>>>
>>>>>> I have one major comment and it relates to DCCP:
>>>>>>
>>>>>> The DCCP chairs tell me that to specify the use of DCCP the ID
>> needs
>>>> to
>>>>>> decide which CCID it will use (CCID 2 is AIMD and CCID 3 is TFRC).
>>>> I
>>>>> was
>>>>>> hoping that the DTLS over DCCP RFC addressed this, but that RFC
>>>> doesn't
>>>>> pick
>>>>>> one it leaves this choice to the "application".
>>>>>>
>>>>>> Can you also confirm that the Port # is used as the DCCP service
>>>> code?
>>>>>> spt
>>
>
>

---

From: Sean Turner <[email-masked]>
Date: Mon, 03 May 2010 09:57:12 -0400

> the IESG agenda, and when can we see IETF LC?

The day I see the publication note will be the day I issue the 
IETF LC.  I will also put it on the IESG telechat that comes 
immediately after the IETF LC ends.  I'd like to put it on the 
5/20 telechat, but that would probably mean the new version has 
to be published today or tomorrow.  At the latest, it will be on 
the 6/3 telechat.

Obviously, all of this depends on the number of comments we get.

spt