headers
Eliot Lear | 8 May 14:16
Favicon

syslog URI, anyone?

Dear all,

I would like to draw your attention to 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
Uri-review <at> ietf.org
https://www1.ietf.org/mailman/listinfo/uri-review
Permalink | Reply |
headers
Ted Hardie | 10 May 20:25

Re: syslog URI, anyone?

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
>
>_______________________________________________
>Uri-review mailing list
>Uri-review <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/uri-review
Permalink | Reply |
headers
Eliot Lear | 10 May 20:47
Favicon

Re: syslog URI, anyone?

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.

>
> 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.
>   

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.

> 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 .
>
>   
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.
>   
>> 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.
>   

Ok see above.
>
>
>   
>> 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.
>   

Ok, thanks.

>
>   
>> 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.
>   

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
Permalink | Reply |

Gmane