At 12:19 AM 4/9/01 -0700, Russ Allbery wrote:
>Albert Mietus <[EMAIL PROTECTED]> writes:
>
>> I know, we are describing the current use. But we can easily extent it,
>> as long as we don't break anything.
>
>For what it's worth, my experience with IETF standards is that the above
>statement, however innocuous-sounding as it may appear at first, can turn
>into a gaping maw of energy-devouring blackness that can be very difficult
>to climb back out of again.
Fully agree.
>> To structer the new ones, I suggest to code the diggits, like e.g. the
>> errorcodes in several other protocols
>
>> So the list of facilities becomes:
>
>As a matter of administrative structure, the standardish IETF way to
>handle something like this is to ask IANA to set up a registry of protocol
>numbers. Hard-coding meanings into a protocol is okay iff the meanings
>are directly related to the protocol in some fashion (like error codes in
>e-mail), but when you get into separating the fields of human endeavor in
>software into separate numeric codes, I think you've really got an IANA
>registry wanting to happen.
>
>(It's unclear to me that it's worth solving this problem, for the record,
>but if you do, a table in an RFC probably isn't the right way to solve
>it.)
We did discuss this issue a while ago. I asked if anyone could point
to any other Facilities in use other than the ones I had listed. We
found that some OSs were using cron/at on different Facilities and
that several OSs were also using several different Facilities for
"auth/security" messages. Those are now shown in the Notes of Table 1.
No one came forward at that time with any Facilities above 23.
I think that that ID contains sufficient instructions to IANA about the
PRI value. Anyone can choose what they feel fits their need and IANA
will NOT police it. Personally, I do not want to try to arbitrate the
"right way" to select a Facility, nor do I want to try to give guidance
of when to use Severity 5 rather than 4 or 6. If these things are not
well known and very clear (and they are not) then there is little chance
that they can be described properly to IANA.
The discussion of the Charter of this WG has been fairly well documented
as well. We are going to document the existing protocol and NOT make
any changes or proposals for new features. I will say that there is
a high degree of interest from many of the participants in this WG to
produce some "standard" message format. I support that idea but it is
outside the scope of our Charter. I would recommend that the people
who would like to see this done get together and propose it in an ID, or
as a future working group.
Thanks,
Chris
