[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Syslog] MIB document decision

Hi,
Alexander Clemm (alex) wrote:

As another question, should anything on syslog-sign be added?  Or do we
treat it as out-of-scope



Does the WG have an opinion on this ? Please note that "out of scope"
will not mean that we have decided to ignore syslog-sign altogether,
it will mean will that we will take it up probably in another document
after we (I) have understood the syslog-sign document and mechanisms
well.

Glenn


If included, this would probably require its own compliance group.
Here is what would need to be included:

Configuration Parameters for Certificate Blocks

   certInitialRepeat = number of times each Certificate Block should be
   sent before the first message is sent.

   certResendDelay = maximum time delay in seconds to delay before next
   redundant sending.

   certResendCount = maximum number of sent messages to delay before
   next redundant sending.

Configuration Parameters for Signature Blocks

   sigNumberResends = number of times a Signature Block is resent.

   sigResendDelay = maximum time delay in seconds from original sending
   to next redundant sending.

   sigResendCount = maximum number of sent messages to delay before next
   redundant sending.
In addition: currentRebootSessionId = the Reboot Session ID that is currently in 
effect.
   keyBlob, keyBlobType, as indicated by the name, for the public keys
used to validate the signatures. 
Possibly (although not absolutely required)
   sigSendDelay = maximum time delay until a Signature Block is sent, in
case it does not fill up with enough hashes. 
Regards
--- Alex


-----Original Message-----
From: Miao Fuyou [mailto:miaofy@huawei.com] Sent: Wednesday, August 23, 2006 3:05 AM 
To: 'Glenn M. Keeni'; syslog@ietf.org
Subject: RE: [Syslog] MIB document decision
Hi, 
Should we add something about TLS transport?

1, Page 9, trasport, should add TLS, may add DTLS and BEEP

2, Page 10, syslogDefaultTransport's defaul value is UDP, TLS? But I
think it's UDP 
My 0.01$

Thanks!
Miao


-----Original Message-----
From: Glenn M. Keeni [mailto:glenn@cysols.com]
Sent: Saturday, August 19, 2006 2:03 PM
To: syslog@ietf.org
Subject: Re: [Syslog] MIB document decision

Dave,
Thanks for the review. I am in full agreement with the observations. 
This
present document belongs to the 3164 era. Now that the protocol, udp documents are stable, it is time for an update. 
The following are TBDs
1. Update terminology to bring it incline with the protocol document. 
    2. Shift the base reference to the protocol document from RFC3164
    3. Make the defaults specified in the DEFVALs consistent with the
        protocol, udp, tls documents
    4. Make the document RFC4181-compliant, idnits-compliant
       [ref. draft-harrington-text-mib-doc-template-00.txt]
       a. Add references for IMPORTS
       b. Add a paragraph on relationship to other MIBs section
    5. Review
       a. Is syslDevCCtlConfFileName implementation-neutral?
b. Could syslDevOpsLastError contain sensitive information, such 
           as passwords or user names? What will be the impact ?
       c. Is the management functionality adequate?
    6. Editorial nits.
        MO=> managed objects
    7. Make the changes and submit the revised I-D

1-4, 6-7 is doable. I will do it.  I will look for WG input on item 5.
Particularly on 5c.

Cheers

Glenn
David Harrington wrote:

Hi,

I agree the terminology in the MIB document differs from that in
-protocol- and should be updated to match the WG consensus on terminology. 

Here are a few things I spotted that should be fixed or checked:

The references in the MIB are to RFC3164, not the current

-protocol-

document produced by the WG. Since -protocol- will be a

standard while

RFC3164 is informational, we should reference the standard

documents.

(If it is useful to compare the RFC3164 attributes to the

-protocol-

attributes, I recommend a section that shows how they map/compare.
There are DEFVAL default values; are these connsistent with the new document? 
Use existing textual-conventions (such as transportDomain)

rather than

SyslogTransport ?
Is syslDevCCtlConfFileName implementation-neutral?
MOs should be spelled out as managed objects.
syslDevOpsLastError - could this contain sen sitive

information, such

as passwords or user names?
Has the MIB been checked against RFC4181? MIB Doctors will expect a section entitled "Relationship to 
other MIB

Modules".
See


ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-harrington-tex

t-mib-doc-template-00.txt for further advice about what

should be in

the document.
The documents that contain the IMPORTS must be cited in

text outside

the MIB module.
The document does not pass the id-nits check by http://tools.ietf.org/tools/idnits/idnits.pyht 

It would be good to make this RFC4181-compliant and

idnits-compliant

before we start the WGLC.

The document should also be compared to the functionality

described in

-protocol-, -udp-, and -tls- documents to make sure the

defaults are

consistent, and the management functionality adequate.

David Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog



_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog





_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog





_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog