Subject: [Uri-review] syslog URI, anyone?

From: Eliot Lear <[email-masked]>
Date: Tue, 08 May 2007 14:16:56 +0200

Dear all,

I would like to draw your attention to draft-lear-ietf-syslog-uri-00 
<http://tools.ietf.org/html/draft-lear-ietf-syslog-uri-00> and request 
your comments.  This URI is meant to be passed via a configuration 
mechanism such as DHCP or a configuration file, to indicate a logging 
server.  I envision simple devices making use of it at first, possibly 
expanding upward.  There are three URIs defined because there are three 
transports for SYSLOG: UDP, BEEP, and soon TLS.  My questions for this 
esteemed body are these:

   1. Is the use of '.' within the scheme name still considered good
      form?  This use seems obvious to me, given what else is out there,
      but perhaps there's something I missed in RFC 4395?
   2. I would like to cede control of this to the IESG.  Does that
      itself require IESG approval?
   3. Are the URIs and templates in good form?  I am particularly
      concerned about Security Considerations because the URI itself has
      very limited scope.  There is only one operation associated with
      this URI (send syslog messages) and I'm not quite certain what
      else is needed.
   4. Should I be registering these as permanent or provisional?  They
      will each be based on IETF standards.

My intent is to follow this up with a DHCP option.  Yes, there is a 
"logging" option out there now, but shockingly it refers to something 
done at MIT many years ago for which there is no documentation 
available.  And so my thought was to pass a URI so devices know what 
transport to use (or not).

Comments?

Thanks for your help,

Eliot
_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: Ted Hardie <[email-masked]>
Date: Thu, 10 May 2007 11:25:46 -0700

At 2:16 PM +0200 5/8/07, Eliot Lear wrote:
>Dear all,
>
>I would like to draw your attention to <http://tools.ietf.org/html/draft-lear-ietf-syslog-uri-00>draft-lear-ietf-syslog-uri-00 and request your comments.  This URI is meant to be passed via a configuration mechanism such as DHCP or a configuration file, to indicate a logging server.  I envision simple devices making use of it at first, possibly expanding upward.  There are three URIs defined because there are three transports for SYSLOG: UDP, BEEP, and soon TLS.  My questions for this esteemed body are these:

First off, I have to say that this is an admirably short document, but I am somewhat
concerned that if the use of the scheme does increase that this "target-only"
style URI won't be enough. 

Would including an optional version field be useful?  draft-ietf-syslog-protocol-20
does seem to allow for syslog to be versioned (see section 6.2.2) and it might
be useful to include that.

Would including parameters to designate which Facilities and which Severity levels
are desired be useful? 

>1.	Is the use of '.' within the scheme name still considered good form?  This use seems obvious to me, given what else is out there, but perhaps there's something I missed in RFC 4395?

For cases like this, it does seem to work.  Given how simple this is, you could
also use a parameter pretty easily, e.g. syslog://host:port/;transport=beep .

>2.	I would like to cede control of this to the IESG.  Does that itself require IESG approval?

I think so.  I'm assuming that this has been/will be reviewed by the SYSLOG
working group.  It can be ceded to the IESG, which can re-delegate it to SYSLOG
for as long as the WG is around.

>3.	Are the URIs and templates in good form?  I am particularly concerned about Security Considerations because the URI itself has very limited scope.  There is only one operation associated with this URI (send syslog messages) and I'm not quite certain what else is needed.

The Security considerations does seem to mix the security of the data passed by
syslog with the URI itself.  The base URI security considerations in 3986 would apply
here, and they should be cited.

>4.	Should I be registering these as permanent or provisional?  They will each be based on IETF standards.

Permanent, probably.  Certainly if reviewed to and agreed by the SYSLOG WG,
they can go for permanent.
					Ted

>My intent is to follow this up with a DHCP option.  Yes, there is a "logging" option out there now, but shockingly it refers to something done at MIT many years ago for which there is no documentation available.  And so my thought was to pass a URI so devices know what transport to use (or not).
>
>Comments?
>
>Thanks for your help,
>
>Eliot
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 May 2007 20:47:07 +0200

Hi Ted,

Thanks for your review and your useful comments.  I should say that this 
has NOT been reviewed by the SYSLOG WG first.  They're on a relatively 
short timeline and are not looking for new items.  Obviously I would 
welcome reviews.

> be useful to include that.

I think this is a good question.  Perhaps.  I imagine I would want to 
encode an optional minimum and maximum version, sort of the way Calsify 
does it.  This might be a good question for the WG.

> also use a parameter pretty easily, e.g. syslog://host:port/;transport=beep .
If I do it the way you suggest, it also solves another problem.  I could 
say ...;transport=beep;transport=udp for an ordered list of methods to 
try, without having to have multiple copies of the option.   The DHCP WG 
might have something to say about this.
> for as long as the WG is around.

Ok see above.
> here, and they should be cited.

Ok, thanks.

> they can go for permanent.

Not sure the path this takes with regard to standardization but I was 
initially aiming for PS so that the DHCP option could make a normative 
reference to it.

Again, thanks for help,

Eliot