headers
Rainer Gerhards | 1 Sep 2003 13:54

TIMESTAMP-3339 (Correction)

WG,

I posted too quickly. Maybe Chris can hold the post. I once again
reviewed RFC 3339 and it says:

--------------

4.4. Unqualified Local Time

   A number of devices currently connected to the Internet run their
   internal clocks in local time and are unaware of UTC.  While the
   Internet does have a tradition of accepting reality when creating
   specifications, this should not be done at the expense of
   interoperability.  Since interpretation of an unqualified local time
   zone will fail in approximately 23/24 of the globe, the
   interoperability problems of unqualified local time are deemed
   unacceptable for the Internet.  Systems that are configured with a
   local time, are unaware of the corresponding UTC offset, and depend
   on time synchronization with other Internet systems, MUST use a
   mechanism that ensures correct synchronization with UTC.  Some
   suitable mechanisms are:

   o  Use Network Time Protocol [NTP] to obtain the time in UTC.

Klyne, et. al.              Standards Track                     [Page 5]

RFC 3339       Date and Time on the Internet: Timestamps       July 2002

   o  Use another host in the same local time zone as a gateway to the
      Internet.  This host MUST correct unqualified local times that are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Gerhards | 1 Sep 2003 15:04

RE: TAG in syslog-sign draft

> I think, we need to add "/" as valid char in the TAG.

Would it hurt if we just said:

----
   The TAG is a string of visible (printing) characters excluding SP,
   that MUST NOT exceed 32 characters in length.

   The first occurrence of a colon (":") or SP " " character terminates
the TAG
   field. Generally, the TAG contains the name of the process that
   generated the message. It may OPTIONALLY contain additional
   information such as the numerical process ID of that process bound
   within square brackets ("[" and "]"). A colon MUST be the last
   character in this field.

   To be consistent with the format described in RFC 3164, a space
   character need not follow the colon in normal syslog packets.
----

In essence, that would allow any character but SP and colon to be used.
IMHO, this would not break existing applications and provide more
flexibility in what coud be in the tag. Think of e.g.

    Myproc[PID,Threadid]:

>
> At least in the FreeBSD version of syslog (which I'm extending to use
> -sign), the TAG is frequently set to the progname, including its path.
> E.g. "/usr/sbin/cron".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Gerhards | 1 Sep 2003 13:29

TIMESTAMP-3339

WG,

I am, too, currently implementing an -sign message parser (but not yet
signing). I am parsing the timestamp.

In ABNF, we say:

      full-time       = partial-time time-offset

That means I must have a time-offset in any case. What should I do (when
generating messages) if I simply do not (reliably) know the TZ the
device is in? This could happen, e.g. if the device TZ is not
configured. Wouldn't it be better to NOT include any timestamp
information so that the receiver knows of the fact I do  not know the
TZ. This would change the above to

      full-time       = partial-time [time-offset]

I know this is not a very common case, but it may happen.

Any thoghts?
Rainer
Permalink | Reply | 0 comments |
headers
Chris Lonvick | 3 Sep 2003 19:52
Picon
Favicon

Issues

Hi Folks,

We've had some issues raised in the past few weeks about syslog-sign-12.
I believe that I've cataloged them here:
  http://www.employees.org/~lonvick/issues.txt
but please send a note to the mailing list if I've missed any, or if
there are any additional ones.  Let's get some consensus on these so
that John and Jon may update the ID and we can move it along.  :-)

I've moved the syslog-sign ID into html via the xml2rfc program.
  http://www.employees.org/~lonvick/draft-ietf-syslog-sign-12.html
and I'm going to put each of these issues into a separate email - with
appropriate Subject line.  Please respond to these emails with your
thoughts.

Thanks,
Chris
Permalink | Reply | 0 comments |
headers
Chris Lonvick | 3 Sep 2003 19:53
Picon
Favicon

Issue 1: Examples

Issue 1: Examples
http://www.employees.org/~lonvick/draft-ietf-syslog-sign-12.html#Examples

From Archive:
http://www.mail-archive.com/syslog-sec%40employees.org/msg01221.html

Albert has an example available.  I'll suggest that we resolve each
of the other issues and then make sure that the example given is
consistent with the consensus of the group at that time.
Permalink | Reply | 0 comments |
headers
Chris Lonvick | 3 Sep 2003 19:54
Picon
Favicon

Issue 2: TAG Field Definition

Issue 2: TAG Field Definition
http://www.employees.org/~lonvick/draft-ietf-syslog-sign-12.html#HEADER

From Archive:
http://www.mail-archive.com/syslog-sec%40employees.org/msg01224.html
http://www.mail-archive.com/syslog-sec%40employees.org/msg01234.html
http://www.mail-archive.com/syslog-sec%40employees.org/msg01222.html

Rainer has proposed the following text:
"""
   The TAG is a string of visible (printing) characters excluding SP,
   that MUST NOT exceed 32 characters in length.

   The first occurrence of a colon (":") or SP " " character terminates
   the TAG field. Generally, the TAG contains the name of the process
   that generated the message. It may OPTIONALLY contain additional
   information such as the numerical process ID of that process bound
   within square brackets ("[" and "]"). A colon MUST be the last
   character in this field.

   To be consistent with the format described in RFC 3164, a space
   character need not follow the colon in normal syslog packets.
"""

However, anyone trying to convey information of "Myproc[PID,Threadid]:"
may have a problem with something like

  syslog[12345,C:\usr\sbin\cron]:

Albert suggests just having "syslog" in the cert/sig-block messages
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Lonvick | 3 Sep 2003 19:55
Picon
Favicon

Issue 3: IANA Considerations for undefined PRI values

Issue 3:  IANA Considerations for undefined PRI values
http://www.employees.org/~lonvick/draft-ietf-syslog-sign-12.html#iana

From Archive:
http://www.mail-archive.com/syslog-sec%40employees.org/msg01213.html
http://www.mail-archive.com/syslog-sec%40employees.org/msg01218.html
http://www.mail-archive.com/syslog-sec%40employees.org/msg01220.html
http://www.mail-archive.com/syslog-sec%40employees.org/msg01226.html

The consensus appears to be to have a new part in the "IANA
Considerations"  of syslog-sign stating the Facilities not defined
are open to future use by the consensus process (RFC 2434 page 6).

The current set of Facilities and Severities are listed by IANA here:
  http://www.iana.org/assignments/syslog-parameters

Any disagreement to that?
Permalink | Reply | 0 comments |
headers
Chris Lonvick | 3 Sep 2003 19:55
Picon
Favicon

Issue 4: Index into Payload in Cert Block

Issue 4:  Index into Payload in Cert Block
http://www.employees.org/~lonvick/draft-ietf-syslog-sign-12.html#index

From Archive:
http://www.mail-archive.com/syslog-sec%40employees.org/msg01228.html

Should the value of "0" or "1" be used as the lowest available value?
Albert suggests "0".  Any disagreement to that?
Permalink | Reply | 0 comments |
headers
Chris Lonvick | 3 Sep 2003 19:56
Picon
Favicon

Issue 5: First Message Number

Issue 5:  First Message Number
http://www.employees.org/~lonvick/draft-ietf-syslog-sign-12.html#firstmsg

From Archive:
http://www.mail-archive.com/syslog-sec%40employees.org/msg01228.html

Similar to Issue 4, should the value of "0" or "1" be used as the
lowest available value?  Albert again suggests "0".  Any disagreement
to that?
Permalink | Reply | 0 comments |
headers
Chris Lonvick | 3 Sep 2003 19:56
Picon
Favicon

Issue 6: Fragment Length

Issue 6:  Fragment Length
http://www.employees.org/~lonvick/draft-ietf-syslog-sign-12.html#fraglen

From Archive:
http://www.mail-archive.com/syslog-sec%40employees.org/msg01229.html

Albert suggests changing the value from "1-4 characters" to "1-3"
since the payload of a syslog Certificate Block will be less than
999 characters -taking out the length of the PRI, TIMESTAMP and
HOSTNAME.  Anyone have any problems with this?
Permalink | Reply | 0 comments |

Gmane