Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.txt

From: [email-masked]
Date: Tue, 10 Feb 2009 06:00:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF.

	Title           : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications
	Author(s)       : J. Schoenwaelder, et al.
	Filename        : draft-ietf-opsawg-syslog-msg-mib-00.txt
	Pages           : 21
	Date            : 2009-02-10

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines a mapping of SYSLOG messages to Simple
Network Management Protocol (SNMP) notifications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 10 Feb 2009 15:50:54 +0100

I guess that the reason for using so many DisplayStrings is the fact that the unerlying syslog
messages are ASCII (probably even just the subset allowed in DisplayString) based ??

One could still represent them in UTF-8 based objects... and be prepared for future
international language support?

In any event, if you want to stick to DsiplayString, it would probably be good to explain
why this is justified, given the fact that we DISCOURAGE use of DisplayString these days,

Bert
  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Tuesday, February 10, 2009 3:00 PM
  Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.txt

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

  _______________________________________________
  OPSAWG mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/opsawg

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Feb 2009 16:48:56 +0100

On Tue, Feb 10, 2009 at 03:50:54PM +0100, Bert Wijnen (IETF) wrote:

> I guess that the reason for using so many DisplayStrings is the fact
> that the unerlying syslog messages are ASCII (probably even just the
> subset allowed in DisplayString) based ??

Yes.
 
> One could still represent them in UTF-8 based objects... and be
> prepared for future international language support?

The IETF version of SYSLOG is relatively new; since it passed IESG
review relatively recently, should I really bother that fields might
not be internationalization ready?

> In any event, if you want to stick to DsiplayString, it would
> probably be good to explain why this is justified, given the fact
> that we DISCOURAGE use of DisplayString these days,

Where is this policy stated? I tried to match the protocol - do I have
to state explicitely somewhere (for each object?) that the definitions
tries to match the protocol?

At the end, I do not care since these are not writable objects. But if
we make them UTF8, we should probably add an explanation that they
won't really carry non ASCII characters with today's version of SYSLOG
and that the UTF8 type is only there to future proof the definitions
in case there could ever be UTF8 encoded characters. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 10 Feb 2009 16:55:58 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder

....

> 
> > In any event, if you want to stick to DsiplayString, it 
> would probably 
> > be good to explain why this is justified, given the fact that we 
> > DISCOURAGE use of DisplayString these days,
> 
> Where is this policy stated? I tried to match the protocol - 
> do I have to state explicitely somewhere (for each object?) 
> that the definitions tries to match the protocol?

Appendix B, Note 2 in RFC4181 says:

            DisplayString does not support internationalized text.  It
            MUST NOT be used for objects that are required to hold
            internationalized text (which is always the case if the
            object is intended for use by humans [RFC2277]).  Designers
            SHOULD consider using SnmpAdminString, Utf8String, or
            LongUtf8String for such objects.
> 
> At the end, I do not care since these are not writable 
> objects. But if we make them UTF8, we should probably add an 
> explanation that they won't really carry non ASCII characters 
> with today's version of SYSLOG and that the UTF8 type is only 
> there to future proof the definitions in case there could 
> ever be UTF8 encoded characters. ;-)
> 
> /js
> 
>

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Feb 2009 17:15:09 +0100

> > ever be UTF8 encoded characters. ;-)

All fine, but in this case, the protocol elements modeled do not
support non ASCII characters and so is there a policy that even in
cases where the protocol is ASCII, DisplayString is DISCOURAGED in
favour of some other string format?

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 10 Feb 2009 17:20:35 +0100

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, February 10, 2009 6:15 PM
> To: Romascanu, Dan (Dan)
> Cc: Bert Wijnen (IETF); [email-masked]
> Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString
> 
> > > Where is this policy stated? I tried to match the protocol - do I 
> > > have to state explicitely somewhere (for each object?) that the 
> > > definitions tries to match the protocol?
> > 
> objects. But 
> > > if we make them UTF8, we should probably add an explanation that 
> > > they won't really carry non ASCII characters with today's 
> version of 
> > > SYSLOG and that the UTF8 type is only there to future proof the 
> > > definitions in case there could ever be UTF8 encoded 
> characters. ;-)
> 
> All fine, but in this case, the protocol elements modeled do 
> not support non ASCII characters and so is there a policy 
> that even in cases where the protocol is ASCII, DisplayString 
> is DISCOURAGED in favour of some other string format?
> 

Not that I am aware, and I am ready to stand corrected if I miss
something. Using DisplayString in this case seems OK to me, however, a
sentence to explain this in the DESCRIPTION cause cannot harm, for folks
who may come across the issue later. 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Feb 2009 19:49:42 +0100

> that we DISCOURAGE use of DisplayString these days,

I have double checked all uses of DisplayString and now each
DESCRIPTION clause has the following notice:

  The SYSLOG protocol specification constraints this string               
  to printable US-ASCII code points.

For most of the protocol fields, I assume the US-ASCII assumption is
quite safe. The exceptions are perhaps APP-NAME and perhaps HOSTNAME
but this seems to have passed IESG so I should probably not bother.

Since the above explanation is not in place, I can also do

  s/DisplayString/SnmpAdminString/g

and perhaps this is actually not such a bad idea for future proofing
the MIB module. But then the sentence should probably read "The SYSLOG
protocol version 1 specification constraints this string to printable
US-ASCII code points").

/js

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 10 Feb 2009 13:57:53 -0500

Hi Juergen,

I cannot see any downside to the use of SnmpAdminString vs DispalyString and would recommend that change.

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, February 10, 2009 1:50 PM
To: Bert Wijnen (IETF)
Cc: [email-masked]
Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-syslog-msg-mib-00.txt

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Feb 2009 20:42:23 +0100

On Tue, Feb 10, 2009 at 01:57:53PM -0500, Natale, Bob wrote:
 
> I cannot see any downside to the use of SnmpAdminString vs
> DispalyString and would recommend that change.

Yes, but then there are many other constraints coming from the SYSLOG
version 1 protocol, like most of the size constraints.  Shall I now go
ahead and remove them as well since they might change in the future
and instead write the size constraints down in the DESCRIPTION
clauses? Arguably, for international character sets, some of the sizes
are way too short. See, this is a slippery slope...

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 10 Feb 2009 15:01:32 -0500

I think this would be a good idea.
dbh 

> Subject: Re: [OPSAWG] I-D 
> Action:draft-ietf-opsawg-syslog-msg-mib-00.txt
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 Feb 2009 12:12:35 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, February 10, 2009 8:15 AM
...
> favour of some other string format?

To me it seems like a logical consequence of BCP 18 section 3.1,
second paragraph:

   Protocols MUST be able to use the UTF-8 charset, which consists of
   the ISO 10646 coded character set combined with the UTF-8 character
   encoding scheme, as defined in [10646] Annex R (published in
   Amendment 2), for all text.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Feb 2009 21:28:44 +0100

>    Amendment 2), for all text.

Here is another quote from BP 18 section 2:

   Internationalization is for humans. This means that protocols are not
   subject to internationalization; text strings are. Where protocol
   elements look like text tokens, such as in many IETF application
   layer protocols, protocols MUST specify which parts are protocol and
   which are text. [WR 2.2.1.1]

So the question boils down to whether things are protocol elements or
text for humans. Since SYSLOG passed all IETF reviews, I as a MIB
module author assume things that are not UTF8 must be protocol
elements. If this leads to wrong results, I believe someone has to fix
the problem SYSLOG has with BCP 18.

My point is that blindly discouraging DisplayString in favour of
SnmpAdminString or Utf8String without taking the context into account
(whether something is a protocol element or text) is not mandated by
BCP 18 section 2.

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 10 Feb 2009 15:37:00 -0500

Hi Juergen,

If I understand correctly, ASCII is a subset of UTF-8.
So I see no problem bringing the USASCII elements of the syslog
message into a UTF-8 object.

Do you intend to take the UTF-8 MIB objects and convert them into
syslog messages? 

dbh 

> Sent: Tuesday, February 10, 2009 2:42 PM
> To: Natale, Bob
> Cc: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Feb 2009 22:08:21 +0100

> Do you intend to take the UTF-8 MIB objects and convert them into

Here is the story again (exclusing meta discussion of DisplayString
policies and BCP 18):

- The current SYSLOG protocol says its US-ASCII.

- I thought DisplayString would be an appropriate type.

- It was suggested to not use DisplayString because DisplayString
  isn't a great idea anymore.

- I said there is no difference since the protocol says it is US-ASCII
  and the only imaginable benefit to move to SnmpAdminString is an
  attempt to future proof the MIB module in case a future SYSLOG
  version allows UTF8.

- I noted that in case SYSLOG version N with N > 1 makes some of the
  US-ASCII protocol elements UTF8, then likely some of the size
  restrictions need to change as well and I asked whether I should
  drop size the restrictions from the MIB as well in order to future
  proof the MIB even more. While this may sound polemic (and to some
  extend it is), there is some truth here since the number of bytes
  needed in UTF8 to encoded characters is not "fairly" distributed
  over the scripts out there. For example, the Euro symbol costs three
  bytes while the US dollar is comparably cheap with just one byte.

I guess for moving forward, I should simply change all DisplayStrings
to SnmpAdminStrings and then the DESCRIPTION clause says for SYSLOG
version 1, this is US-ASCII - this way I hope no policy questions will
be asked anymore.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Feb 2009 22:23:41 +0100

> version 1, this is US-ASCII - this way I hope no policy questions will

Let me add that the SYSLOG extensibility mechanism are structured data
elements. So if APP-NAME or HOSTNAME is broken, the likely way to fix
this is to introduce and SD-ELEM that carries values in a more
suitable representation. Note that this works because PARAM-VALUE is a
UTF-8-STRING in the protocol and syslogMsgSDParamValue is an
SnmpAdminString in the MIB module.

So my conclusion for today before I catch some sleep is that the
DisplayStrings are fine and since I added an explanation that they are
consistent with the protocol, I think we are done.

/js

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 10 Feb 2009 22:14:15 +0100

As I said in my original comment. It is quite possiblke that we "justify" using DisplayStrings
ebcause the underlying data is just that subset of ASCII. That I can live with. I would like to see
some text somehwere that describes that justification. So that if/wehen we review
other MIB modules where we challenge the use of DisplayString that we can expalibn
why it was/is ok in the Syslog-MIB.

Bert

  ----- Original Message ----- 
  From: Juergen Schoenwaelder 
  To: Randy Presuhn 
  Cc: [email-masked] 
  Sent: Tuesday, February 10, 2009 9:28 PM
  Subject: Re: [OPSAWG] SYSLOG-MSG-MIB: DisplayString vs SnmpAdminString

  /js