[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] I-D ACTION:draft-ietf-syslog-transport-udp-02.txt
Anton,
thanks for your great work.
Some points:
- you use "domain.com" in some examples. I recommend changing this to
"example.com", which has been reserved for this use.
- In 3.4, the draft says:
######
All implementations MUST support sending and receiving syslog
messages up to and including the size which does not require
fragmentation (507 bytes for IPv4 and 1191 bytes for IPv6). This
size excludes the overhead of the syslog transport and UDP/IP
headers. Support for larger messages is encouraged. Implementors
SHOULD clearly state the maximum supported message size in
documentation.
######
Actually, all implementations MUST support a message size of 65,000
bytes, because this is the required minimum in -protocol 4.1. We agreeed
on this minimum after long discussions on the message size. I'd actually
prefer not to re-iterate this. But if we must, let me say that a
guaranteed message size of 507 bytes looks far too low to me.
Please note that the -protcol requirement meant that all implementations
MUST support fragmentation.
Sorry I didn't spot this in the -01 version...
I've also noticed that in -protocol, I have limited that max message
size to 16,000,000 bytes in -protocol. It might make sense to sync this.
I can go up with my number.
I do not fully understand what you mean in 4.2 by:
#####
No concurrent port reuse on the same host is
allowed.
#####
It's probably just my English, but I do not get it. I'd appreciate if
you could elaborate a little.
Thanks for the great draft!
Rainer
> -----Original Message-----
> From: syslog-sec-bounces@www.employees.org
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> Anton Okmianski
> Sent: Thursday, September 02, 2004 4:20 PM
> To: syslog-sec@employees.org
> Subject: RE: [Syslog-sec] I-D
> ACTION:draft-ietf-syslog-transport-udp-02.txt
>
> Hi!
>
> Updates in this draft include:
>
> 1. UDP checksums are now a SHOULD instead of a MUST for IPv4.
> Checking checksums by receiver when available is still a MUST.
>
> 2. Requirement about using the same port for a given process was
> removed. This opens up the possibility for a given process to have
> multiple sockets sending syslog messages. The requirement about using
> the same MessageId and source port for fragments of a given message is
> still there, so we are covered for message reassembly.
>
> 3. The references were split into Normative and Informative.
>
> Based on limited feedback I got for previous version, I believe the
> draft is ready to be published. It has to be published together with
> syslog-protocol when both are ready.
>
> Thanks,
> Anton.
>
> > -----Original Message-----
> > From: syslog-sec-bounces@willers.employees.org
> > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf
> > Of Internet-Drafts@ietf.org
> > Sent: Wednesday, September 01, 2004 4:10 PM
> > To: i-d-announce@ietf.org
> > Cc: syslog-sec@employees.org
> > Subject: [Syslog-sec] I-D
> > ACTION:draft-ietf-syslog-transport-udp-02.txt
> >
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories. This draft is a work item of the
> > Security Issues in Network Event Logging Working Group of the IETF.
> >
> > Title : Transmission of syslog messages over UDP
> > Author(s) : A. Okmianski
> > Filename : draft-ietf-syslog-transport-udp-02.txt
> > Pages : 21
> > Date : 2004-9-1
> >
> > This document describes the transport for syslog messages over UDP/
> > IPv4 or UDP/IPv6. While several transport mappings are
> envisioned
> > for the syslog protocol, syslog protocol implementors are
> > required to
> > support the transport mapping described in this document. This
> > transport specification overcomes limitations of UDP/IP
> > datagram size
> > by introducing support for fragmentation of large messages.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpor
> > t-udp-02.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
>
> > i-d-announce-request@ietf.org with the word unsubscribe in
> > the body of the message.
> > You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> > with the username "anonymous" and a password of your e-mail
> > address. After logging in, type "cd internet-drafts" and then
> > "get draft-ietf-syslog-transport-udp-02.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE
> /internet-drafts/draft-ietf-syslog-transport-udp-02.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command. To decode the response(s), you will need "munpack"
> or
> > a MIME-compliant mail reader. Different MIME-compliant
> > mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been
> split
> > up into multiple messages), so check your local documentation
> on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail
> > reader implementation to automatically retrieve the ASCII
> > version of the Internet-Draft.
> >
> > --------------------------------------------------------------
> > -----------
> > In order to maintain computing infrastructure integrity,
> > Cisco Systems Enterprise Messaging Services and InfoSec teams
> > have set a mail policy disallowing executable attachments in email.
> >
> > This message contained an executable attachment type that is
> > prohibited
> > by this policy. The attachment has been removed from this message
> and
> > copied to quarantine by our systems. It will be held in
> > quarantine for seven days in the event that the content needs
> > to be retrieved.
> >
> >
> > --------------------------------------------------------------
> > -----------
> > For further reference information about viruses and email antivirus
> > efforts within Cisco, please visit:
> >
> http://wwwin.cisco.com/it/ems/services/antiviral
>
>
> If your concern isn't addressed by the information in this
> notification
> or the above web page, you may open a support request:
>
> http://wwwin.cisco.com/support/
>
> Select "Messaging", "Email-Related", "Mail Routing"
>
> Please include in the text of your case the following information:
>
> * Full headers of the message. Documentation on displaying the full
> headers is available at this URL:
>
> http://wwwin.cisco.com/support/library/faqs/solution002471.html
>
> * This unique quarantine identifier: i81M6jA3002394
>
> If the matter is urgent, you may follow up by calling one of the below
>
> referenced numbers. Please make every effort to provide the above
> requested information via the support web tool prior to calling as it
> will greatly aid the resolution of your issue.
>
> Americas:
> 1 408 526 8888
>
> Asiapac
> +61 2 8446 8888
>
> EMEA
> +31 20 485 4888
>
> Japan
> +81 3 5549 6888
>
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
>
> Thank you for your cooperation,
>
> Enterprise Messaging Services
> Cisco Systems, Inc
>
> _______________________________________________
> Syslog-sec mailing list
> Syslog-sec@www.employees.org
> http://www.employees.org/mailman/listinfo/syslog-sec
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec