RE: [Syslog] MIB document decision

["Alexander Clemm (alex)" <alex@cisco.com>]

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

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