Re: AD review comments for draft-ietf-syslog-dtls

Sean Turner <[email protected]> Mon, 03 May 2010 09:57:12 -0400
Newsgroups gmane.ietf.syslog
Message-ID <[email protected]>
Chris Lonvick wrote:
> 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?

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

> Thanks,
> Chris
> 
> On Tue, 27 Apr 2010, tom.petch wrote:
> 
>> ----- Original Message -----
>> From: "Joseph Salowey (jsalowey)" <[email protected]>
>> To: "Sean Turner" <[email protected]>; "Chris Lonvick (clonvick)"
>> <[email protected]>
>> Cc: <[email protected]>
>> 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 protected]]
>>>> Sent: Thursday, April 22, 2010 3:55 PM
>>>> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick)
>>>> Cc: [email protected]
>>>> 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 protected] [mailto:[email protected]] On
>>>>> Behalf
>>>>>> Of Chris Lonvick (clonvick)
>>>>>> Sent: Monday, April 12, 2010 6:40 AM
>>>>>> To: [email protected]
>>>>>> 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
>>>
>>
>>
> 
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog