Re: [Syslog] Status of syslog/dtls ISSUES

["David Harrington" <[e-mail]>]

Hi,

Tim, your orignal concern was that the section 5 advice and the
section 6 advice didn't align: a RECOMMENDED to use should be
accompanied by a mandatory-to-implement.
I agree there should be mandatory support for syslog/dtls to provide
an interace to DCCP, so that when DCCP is available it can be used.
But apparently the WG doesn't agree.
Good luck getting operators to use it, even when DCCP is available, if
implementers don't implement the necessary interface to call DCCP from
syslog/DTLS. I have not seen any technical arguments as to why this
cannot be done. 

But I recused, since I am chair of syslog, so this is not my DISCUSS.
I recommend the following as a compromise position:
 
Leave section 5 as is:
CURRENT:
    DTLS can run over multiple transports.  Implementations of this
    specification MUST support DTLS over UDP and SHOULD support DTLS
over
    DCCP [RFC5238].  Transports, such as UDP or DCCP do not provide
    session multiplexing and session-demultiplexing.  In such cases,
the
    application implementer provides this functionality by mapping a
    unique combination of the remote address, remote port number,
local
    address and local port number to a session.

section 6:
CURRENT:
    DCCP has congestion control.  For this reason the syslog over DTLS
    over DCCP option is recommended in preference to the syslog over
the
    DTLS over UDP option.  Implementations of syslog over DTLS over
DCCP
    MUST support CCID 3 and SHOULD support CCID 2 to ensure
    interoperability.
NEW:
    DCCP has congestion control.  If DCCP is available, syslog over
DTLS
    over DCCP is RECOMMENDED in preference to syslog over 
    DTLS over UDP.  Implementations of syslog over DTLS over DCCP
    MUST support CCID 3 and SHOULD support CCID 2 to ensure
    interoperability.

This provides clear guidance to implementers that they SHOULD
implement, and to users that they SHOULD use it if available. 

(I find this much better than "MUST implement if DCCP is available at
runtime", since an implementer would not necessarily know if DCCP
would be available at runtime.)

dbh
 

> -----Original Message-----
> From: Chris Lonvick [mailto:[e-mail]] 
> Sent: Tuesday, June 22, 2010 8:11 PM
> To: [e-mail]; Joseph Salowey (jsalowey)
> Cc: David Harrington
> Subject: RE: [Syslog] Status of syslog/dtls ISSUES
> 
> Hi Folks,
> 
> How about this:
> 
> - We leave Section 5 just as it is:
> CURRENT:
>     DTLS can run over multiple transports.  Implementations of this
>     specification MUST support DTLS over UDP and SHOULD 
> support DTLS over
>     DCCP [RFC5238].  Transports, such as UDP or DCCP do not provide
>     session multiplexing and session-demultiplexing.  In such 
> cases, the
>     application implementer provides this functionality by mapping a
>     unique combination of the remote address, remote port 
> number, local
>     address and local port number to a session.
> 
> - We modify Section 6 as follows:
> CURRENT:
>     DCCP has congestion control.  For this reason the syslog over
DTLS
>     over DCCP option is recommended in preference to the 
> syslog over the
>     DTLS over UDP option.  Implementations of syslog over 
> DTLS over DCCP
>     MUST support CCID 3 and SHOULD support CCID 2 to ensure
>     interoperability.
> PROPOSED:
>     DCCP has congestion control but is not widely deployed at 
> the time of
>     this writing.  Since it does have congestion control, 
> whereas UDP does
>     not, syslog over DTLS over DCCP is recommended in 
> preference to the
>     syslog over DTLS over UDP.  Implementations of syslog 
> over DTLS over
>     DCCP MUST support CCID 3 and SHOULD support CCID 2 to ensure
>     interoperability.
> 
> Please get your comments in quickly as we'd like to close this out.
> 
> Thanks,
> Chris
> 
> 
> On Mon, 21 Jun 2010, Joseph Salowey (jsalowey) wrote:
> 
> > I think DCCP features isn't really much clearer.  Perhaps the 
> > following would be better,
> >
> > "Implementations of this specification MUST support DTLS 
> over UDP and 
> > MUST support the DTLS over DCCP [RFC5238] CCIDs and service name 
> > specified in this document."
> >
> > This still seems to mandate a DCCP implementation to be 
> compliant with 
> > the spec.
> >
> >
> >
> >> -----Original Message-----
> >> From: David Harrington [mailto:[e-mail]]
> >> Sent: Monday, June 21, 2010 2:22 PM
> >> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick);
> > [e-mail]
> >> Subject: RE: [Syslog] Status of syslog/dtls ISSUES
> >>
> >> How about
> >>
> >>  "Implementations of this
> >>     specification MUST support DTLS over UDP and MUST support the

> >> DTLS over
> >>     DCCP [RFC5238] features of this specification."
> >>
> >> I'm not sure what else is necessary, but there are only two DCCP 
> >> things mentioned in this spec - the CCIDs and SYSL service 
> name. The 
> >> CCID text is already written using RFC2119 language.
> >>
> >> dbh
> >>
> >>> -----Original Message-----
> >>> From: Joseph Salowey (jsalowey) [mailto:[e-mail]]
> >>> Sent: Monday, June 21, 2010 12:39 PM
> >>> To: David Harrington; Chris Lonvick (clonvick); [e-mail]
> >>> Subject: RE: [Syslog] Status of syslog/dtls ISSUES
> >>>
> >>> What text would you suggest?
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: David Harrington [mailto:[e-mail]]
> >>>> Sent: Monday, June 21, 2010 8:46 AM
> >>>> To: Joseph Salowey (jsalowey); Chris Lonvick (clonvick);
> >>> [e-mail]
> >>>> Subject: RE: [Syslog] Status of syslog/dtls ISSUES
> >>>>
> >>>> Hi,
> >>>>
> >>>> The proposed text is:
> >>>> "Implementations of this
> >>>>    specification MUST support DTLS over UDP and MUST
> >>> support DTLS over
> >>>>    DCCP [RFC5238] if the DCCP transport is available at 
> run-time."
> >>>>
> >>>> So if I am an implementer, and I have no idea whether my 
> customers
> >>
> >>>> will have DCCP available at runtime, MUST I implement those 
> >>>> DCCP-related things that are specified in this document?
> >>>>
> >>>> Even if I see no customer demand for DCCP, and assume it
> >>> will NOT be
> >>>> available at runtime, MUST my implementation support the
> >>> service code
> >>>> SYLG?
> >>>>
> >>>> If I don't implement support for this, and the customer
> >>> DOES NOT have
> >>>> DCCP at runtime, is my implementation compliant to this spec?
> >>>>
> >>>> If I don't implement support for this, and the customer
> >>> DOES have DCCP
> >>>> at runtime, is my implementation still compliant to this spec?
> >>>>
> >>>> dbh
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: [e-mail]
> >>>>> [mailto:[e-mail]] On Behalf Of Joseph Salowey
> >>>>> (jsalowey)
> >>>>> Sent: Monday, June 21, 2010 1:09 AM
> >>>>> To: Chris Lonvick (clonvick); [e-mail]
> >>>>> Subject: Re: [Syslog] Status of syslog/dtls ISSUES
> >>>>>
> >>>>> Most of this looks pretty straight forward:
> >>>>>> Issue 8 - Tim Polk DISCUSS
> >>>>>> STATUS: Discussed by Tom and David.  Joe to incorporate
> >> changes.
> >>>>>>
> >>>>> [Joe] For this one I have Section 5 as:
> >>>>>
> >>>>> "Implementations of this
> >>>>>    specification MUST support DTLS over UDP and MUST support
> >> DTLS
> >>>> over
> >>>>>    DCCP [RFC5238] if the DCCP transport is available at
> >> run-time."
> >>>>>
> >>>>> And section 6 as:
> >>>>>
> >>>>> " DCCP has congestion control.  For this reason, when DCCP is
> >>>>>    available, the syslog over DTLS over DCCP option is
> >> RECOMMENDED
> >>>> in
> >>>>>    preference to the syslog over the DTLS over UDP option."
> >>>>>
> >>>>> I'm think the RECOMMENDED in the section 6 needs to be
> >>> replaced with
> >>>>> something else, I'm not quite sure what.
> >>>>>
> >>>>>> Issue 9, 9a, and 9b - from a Tim Polk COMMENT
> >>>>>> STATUS:  It looks like 9 and 9a have been discussed and Tom
> >> has
> >>>>> proposed
> >>>>>> text to resolve them.  Sean proposed text on 9b.  I'd like
> >> some
> >>>>> discussion
> >>>>>> on that.
> >>>>>>
> >>>>> [Joe] I'm not sure 9b is necessary, but I don't think it
causes
> >>>> harm.
> >>>>> I'd modify the text to say " implementations often generate
> >> their
> >>>>> own key pairs" since its possible for the generation to be
done 
> >>>>> outside the implementation.
> >>>>>
> >>>>>> Issue 10 - Jari Arrko DISCUSS
> >>>>>> STATUS: Same as Issue 1.  Is the text proposed by Sean good
to
> >>>> cover
> >>>>> all
> >>>>>> of this Issue, Issue 1 and Issue 2?
> >>>>>>
> >>>>> [Joe] I incorporated the text, I'm not sure it covers all the 
> >>>>> issues, I think Tom initiated some discussion on the TLS
> >>> list, but
> >>>>> I don't think it changes the result.
> >>>>>
> >>>>> _______________________________________________
> >>>>> Syslog mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/syslog
> >>>>>
> >>>
> >
> >