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