Hi,

Let's coordinate our discussions on these issues.  We can keep Sam out of
these discussions until we get our responses together.  I'll put out notes
to the list on each issue and we can see how we want to address each.

Thanks,
Chris

On Thu, 22 Sep 2005, Rainer Gerhards wrote:

> Dear Sam & WG,
>
> many thanks for your review of syslog-protocol and the questions raised.
>
> Below, I have given answers to many of the questions. Some of them
> include suggestions of how we could change the ID. I would appreciate if
> WG members could read through this mail, even though it is quite large.
> I intend to make some changes as outlined in my answers and feedback is
> vitally important to get this going.
>
> I have also provided some answers not leading to changes. I hope I have
> summed up everything correctly. If somebody thinks differently, please
> let us know.
>
> There are some questions where I need to do further research. I have
> preferred to just flag them and leave them unanswered, so that the rest
> of the process can continue.
>
> Sam: I would appreciate if you could comment on the answers to 3 and 7
> and tell me if you can agree with this point of view.
>
> Best regards,
> Rainer Gerhards
>
>> -----Original Message-----
>> From: syslog-sec-bounces@www....
>> [mailto:syslog-sec-bounces@www....] On Behalf Of Sam Hartman
>> Sent: Monday, September 19, 2005 3:59 AM
>> To: syslog-sec@empl...
>> Cc: hartmans-ietf@mit....
>> Subject: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14
>>
>>
>>
>> Hi.  A few weeks ago you submitted draft-ietf-syslog-protocol-14 for
>> publication as a proposed standard.  The first step in that process is
>> review by the responsible AD, me.
>>
>>
>> here are my comments.  The working group needs to respond to these
>> comments; responses can come in the form of answers to questions,
>> disagreement, proposed changes, etc.
>>
>> 1) Has the ABNF been validated?  Which parser was used?  I'm
>>    particularly concerned about the handling of escaping in sd-values.
>>    If the ABNF is used directly to generate a parser, will it
>>    correctly handle the escaped text?  Is the handling of the escaping
>>    issue in this spec consistent with handling in other specs?
>
> The IETF-recommended ABNF validator at
> http://www.apps.ietf.org/abnf.html was used. Also used was APG
> (http://www.coasttocoastresearch.com/), both returning no diagnostics.
> However, I have not tried to generate a parser implementation and check
> its handling of the escaped text. I will do further checks in this
> regards and post an update when I am through with that.
>
>>
>> 2) You do not discuss Unicode security at all.  I suggest that people
>>     in the working group read Unicode TR 36 and also consider the
>>     implications of the Unicode security presentation given at the
>>     last SAAG presentation.  particularly consider comments from
>>     operators concerned about Unicode characters interacting with
>>     existing scripts.  Then write up a security considerations
>>     section.  You need to at least explain the security risks
>>     associated with your choice to support all Unicode characters.  It
>>     would be a good idea to discuss other alternatives that were
>>     considered and to explain why this choice was made.
>
> I will follow your advise and post comments/updates once I have them.
>
>>
>>
>> 3) Backward compatibility and versioning are not really discussed.
>>    You define semantics of the version field but these semantics
>>    require the sender to be configured with the version that the
>>    receiver will support.  Is this extensibility model acceptable to
>>    people who will deploy this protocol?  Also, it seems that this
>>    extensibility model means that making a change that requires a
>>    version number bump is very costly.  Structured data seems like the
>>    major extensibility mechanism that does not require a version
>>    number bump.  Is this mechanism sufficient to make sure version
>>    bumps will be infrequent?
>
> The core problem with version number coexistence is that syslog traffic
> is simplex. So it is not possible to have the sender and receiver
> negotiate on a specific version (which would obviously relieve many of
> the costs associated with it).
>
> We are still using a header that is depending on the field positions and
> avoids multi-line entities. The reasons are:
>
> - keep as consistent with traditional syslog as possible
> - allow coexistence with existing syslog implementations
>  (as outlined in section A.1)
> - keep the header as small as possible - we have severe size
>  restrictions in syslog based on the need to fit a message into
>  a single IPv4 UDP packet without fragmentation (message are allowed
>  to be longer, but this probably reduces reliability in a
> troubleshooting
>  case in a broken network)
>
> Given the simplex nature and the header structure, it has been WG
> concensus that the currently specified versioning is acceptable and not
> a major drawback.
>
> I also think that a version number bump - by its nature - is not
> costlier than in other protocols. That it actually is costlier stems
> back to the fact that the sender must be correctly (and manually)
> configured, something that other protocols handle during initial
> connection negotiation. Extending syslog to include a negotiation phase
> and thus becoming a (half)duplex protocol would solve the issue;
> however, it would bear a much higher cost in terms of acceptence of the
> new protocol. Many implementors and users I have talked to  inisit on
> the simple "send it and forget it" nature of the syslog protocol. If we
> would change that considerably, I would strongly expect to loose a lot
> of acceptance. As a side-note, the added complexity is also the major
> thing hindering real-world acceptance of RFC 3195. We tried to avoid
> this problem in syslog-protocol, obviously at some cost. Here it is the
> need to manually configure the sender.
>
> On the frequency of version number bumps, we assume that the current
> header provides every information needed in the forseeable future (of
> course, "forseeable future" is a weak term...). We expect that most
> needs can be addressed by structured data entries. For example,
> syslog-sign is expected to use structured data and so is RFC 3195bis, if
> there is need for extensions.
>
>> 4) The working group has adopted the very restrictive standards action
>>    IANA policy for  structured data.  Why is such a restrictive policy
>>    chosen?
>
> The "Standards Action" requirement was introduced as a late change
> without much discussion. We primarily did this to keep it consistent
> with the requirement for VERSION
> (http://www.mail-archive.com/syslog-sec%40www.employees.org/msg00269.htm
> l). I admit this should have received more thourough thinking.
>
> Most probably it is better to keep with the original "Specification
> Required" requirement.
>
>>
>>
>> 5) I don't think x- as a prefix is such a good idea for vendor use SD.
>>    It seems like that some way of identifying the vendor would be
>>    better; possibly something based on OIDs, enterprise numbers, or
>>    domain names.  The problem with a flat namespace for vendors is
>>    what do you do about collisions.
>
> We have seen the problem with collisions, but accepted it. Again, the
> prime reasoning is the worst-case-size limitation. The longer the
> prefix, the less space is left for actual message content. It obviously
> is good to have a discussion on what is more desirable: short overhead
> size or low avoidance of name space problems.
>
> After re-reading and re-thinking based on your comment, a compromise
> would probably be to use the vendor's enterprise numbers (same as in
> section 7.2.2, preferably without sub-identifiers) as the prefix for
> vendor extensions. So a vendor extension would not be "x-extension" but
> "19406-extension" (19406 is the enterprise id of the company I work for,
> I use it as a sample to avoid hitting someone else's id). The extra
> overhead in size should be acceptable if we look at what we gain on
> safety in namespace collisions. Optionally (if the vendor sees need),
> sub-identifiers could be used, leading to things like
> "19406.1.32.4.7.89-extension" - obviously this needs more space and thus
> should be avoided if it does not create any issues for the vendor (but I
> guess we would see such things quite often).
>
>> 6) I'm concerned about the use of x- param names in sd-ids that are
>>     not experimental.  As I read the spec, any x- param name can be
>>     used in any sd-id regardless of whether the specification for that
>>     sd-id permits the param-name.  However the specification of an
>>     sd-id must define the non-x-param names valid with that sd-id.  It
>>     seems like this will be used as a way to extend sd-ids after the
>>     fact rather than defining a new sd-id as required elsewhere in the
>>     text.  Is this really desirable?
>
> This is a very good question. The consensus ([too?] quickly reached) was
> that vendor-extension (and experimental ones) to standard SD-IDs are
> useful. The reasoning behind this is that if a vendor intends to provide
> information that is logically closely related to a standard SD-ID, it
> would be useful to include it with that SD-ID. This would keep the
> message both shorter and better readble than when a completely new
> (vendor-specific) SD-ID is used for that purpose. So this mechanism
> should be used to include not-yet-supported, closely related information
> into a standard SD-ID. Of course, what is "closely related" depends. So
> this mechanism could easily be abused.
>
> If I look at your comment 5) above, I also begin to have some other
> concern. For the same reasoning, we would have to replace the "x-" with
> something vendor specific down here, too. Even if we go for the compact
> enterprise-id, adding it to potentially multiple SD-PARAMs causes a lot
> of overhead.
>
> Given this whole picture, it probably makes sense to disallow x- params.
> An alternative might be that the vendor uses a SD-ID with the same name
> as the standard one but with its prefix (e.g. "19406-origin"), then add
> the new SD-PARAMs without any further prefix.
>
>> 7) What sort of review has this spec received from the vendor
>>    community that generates syslog messages and the operator community
>>    that consumes them?  Will this specification actually be useful to
>>    the Internet community?  Has the review been wide enough that we
>>    believe we are headed in the right direction?
>
> There are many syslog vendors on this list as well as some (but few
> given the total base) from the operator community. Review outside of the
> WG has been sparse. I tried to receive comments from several Internet
> discussion lists on syslog and/or closely related topics. However, the
> result was very weak. There were some reponses that people are not
> interested in any IETF work at all, not interested in protocol details
> and/or not willing to look at an ID.
>
>> From other discussions in the operator community, the following needs
> are often voiced. They are not targeted towards a specific standards but
> toward desired improvements in syslog in general. They are (order is NOT
> relevant):
>
> 1. more security for the syslog protocol
> 2. a simple, reliable transmission protocol
> 3. a better timestamp including year and higher precision time
> 4. a better hostname, FQDN strongly desired
> 5. standardization of the message content
>
> Syslog-protocol directly addresses 3 and 4. While 5 is not directly
> adressed, it is believed that structured data can be used to address
> this problem in the long term (please note that message content itself
> is beyond the current charter of the WG). By providing a better message
> id in syslog-protocol, we also hope to address some of 5. Issues 1 and 2
> are also not directly adressed. However, we think that removing many
> ambiguities and subtle differences in current RFCs (and
> industry-standard implementations) will definitley help with 1. For the
> same reason, the new layered architecture is designed to aid adding new
> transports with minimal impact on existing applications and standards.
> For this reason, I think 2 is also addressed, even if very indirectly.
>
> Looking at the implementor community, the new layered architecture and
> strict header specification greatly eases the task of developing syslog
> solutions.
>
> With currently-existing RFCs, there is a lot guesswork of what is
> contained in which header field. This is well-known throughout the
> communities, many applications provide different settings to select
> different header and message interpretation. Also, RFC3195 did specify a
> subtly different header than RFC 3164 did and syslog-sign was scheduled
> to use even another slightly different header. As an implementor, you
> had to support at least three different parsers/generators for mostly
> the same thing. The lack of a common format also made it impossible to
> transfer syslog-sign message via RFC 3195 because they required
> different header formats. This discussion lead to the initial idea of
> the layered architecture which then lead to syslog-protocol. With
> syslog-protocol, there now  is a single format specification (though
> with the versioning issue you pointed out) that  provides the base
> format for all other standards to come (RFC 3195bis, syslog-sign,
> whatever...). This consistency greatly enhances the ability to reuse
> code in implementations.
>
> Given these arguments, I belive that syslog-protocol will be useful to
> the Internet community in general and of benefit to the implementor and
> operator community.
>
> Regarding the review, participation on the WG mailing list is
> unfortunately lower than we would like to have it. However,
> syslog-protocol has seen dramatically increasing discussion and review
> in the months before WG last call. You might want to quickly browse the
> mail archive at:
>
> http://www.mail-archive.com/syslog-sec%40www.employees.org/
>
> Even with the limited direct end user comments on the draft, I consider
> the review to have been sufficiently enough. Maybe Chris can further
> comment on that.
>
>>
>>
>> thanks for your responses,
>>
>> --Sam
>>
>> _______________________________________________
>> Syslog-sec mailing list
>> Syslog-sec@www....
>> http://www.employees.org/mailman/listinfo/syslog-sec
>>
> _______________________________________________
> Syslog-sec mailing list
> Syslog-sec@www....
> http://www.employees.org/mailman/listinfo/syslog-sec
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www....
http://www.employees.org/mailman/listinfo/syslog-sec