From syslog-bounces@lists.ietf.org Fri Sep 01 08:09:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ7pT-00057L-U7; Fri, 01 Sep 2006 08:08:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ01r-0007cV-NU for syslog@ietf.org; Thu, 31 Aug 2006 23:49:15 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ01l-0000hU-Mh for syslog@ietf.org; Thu, 31 Aug 2006 23:49:15 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 31 Aug 2006 23:49:09 -0400 X-IronPort-AV: i="4.08,196,1154923200"; d="xml'217?txt'217?scan'217,208,217"; a="100139474:sNHT86540432" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k813n9Jk018101; Thu, 31 Aug 2006 23:49:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k813n7uI002112; Thu, 31 Aug 2006 23:49:09 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 23:49:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6CD79.92D1103D" Subject: RE: [Syslog] WGLC: udp-07 Date: Thu, 31 Aug 2006 23:45:34 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B7312201DF4E03@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Syslog] WGLC: udp-07 Thread-Index: AcbK0K9M+tcoQBzESHWT+Vw2/Sk/LwCmdZkg From: "Anton Okmianski \(aokmians\)" To: "David Harrington" , X-OriginalArrivalTime: 01 Sep 2006 03:49:07.0087 (UTC) FILETIME=[933181F0:01C6CD79] DKIM-Signature: a=rsa-sha1; q=dns; l=81122; t=1157082549; x=1157946549; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20WGLC=3A=20udp-07 |To:=22David=20Harrington=22=20,=20; X=v=3Dcisco.com=3B=20h=3DcRHJ5hVB3JXmLWlvBI8ya9cVE+A=3D; b=UyxoYdY/2Pwl2HVAA63vmnv5TVf+C98wuwIoMiZAW4H+LAxKgbsmjgvkc0d9SUKS/7dJjmQF U/b9NInJleALA8TqxKnNVQQ9+nCAdZ9OeBiNCdCP3aEHNC1ioMmWp1PH; Authentication-Results: rtp-dkim-2.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ba11eb5e600a059070a14bd841d36d X-Mailman-Approved-At: Fri, 01 Sep 2006 08:08:58 -0400 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CD79.92D1103D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David and all: Thanks for a thorough review. I updated the draft according to your comments. Generated text version from XML using tool at http://xml.resource.org/. Please see below for a couple of items for clarifications. Please let me know if I addressed this sufficiently to post the attached draft. I will be traveling starting September 8th for 3 weeks and will only have sporadic access to email. So, I'd prefer to finalize whatever we can before than. =20 Thanks, Anton. =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Monday, August 28, 2006 2:40 PM > To: syslog@ietf.org > Subject: [Syslog] WGLC: udp-07 >=20 > Hi, >=20 > I have reviewed > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 > .txt for WGLC. >=20 > The xml2rfc will be submitted with the final draft, so this=20 > should be a "clean" xml2rfc source file. > The xml2rfc-validator tools at > http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/valid.cgi=20 > shows the following warnings or errors, which should be fixed=20 > in the source file. Note that my copy of the XML source=20 > apparently does not match that used to generate the official draft. >=20 > ---- start validation output --- > Validation results for D:\My > Documents\IETF\syslog\draft-ietf-syslog-transport-udp-07.xml > Processing... >=20 > Validating document... > 280: element front: validity error : Element front content=20 > does not follow the DTD, expecting (title , author+ , date ,=20 > area* , workgroup* , keyword* , abstract? , note*), got=20 > (title author ) > 279: > 280: > 281: The syslog Protocol ...validation failed=20 > Performing additional checks... > 50: fyi: anchor intro not referenced > 49: > 50:
> 51: > 68: fyi: anchor terms not referenced > 67:=20 > 68:
Document"> > 69:=20 > 76: fyi: anchor Transport not referenced > 75:=20 > 76:
> 77:=20 > 78: fyi: anchor Datagram not referenced > 77:=20 > 78:
> 79: > 84: fyi: anchor MessageSize not referenced > 83:=20 > 84:
> 85:=20 > 104: fyi: anchor TargetPort not referenced > 103:=20 > 104:
> 105: > 110: fyi: anchor SourceIPAddress not referenced > 109:=20 > 110:
> 111: > 116: fyi: anchor UDPIPStructure not referenced > 115:=20 > 116:
> 117: > 122: fyi: anchor UDPChecksums not referenced > 121:=20 > 122:
> 123: > 137: fyi: anchor reliability not referenced > 136:=20 > 137:
Considerations"> > 138:=20 > 143: fyi: anchor loss not referenced > 142:=20 > 143:
> 144: > 152: fyi: anchor corruption not referenced > 151:=20 > 152:
> 153: > 162: fyi: anchor overload not referenced > 161:=20 > 162:
> 163: > 168: fyi: anchor sequence not referenced > 167:=20 > 168:
> 169: > 177: fyi: anchor security not referenced > 176:=20 > 177:
> 178: > 182: fyi: anchor SenderAuthentication not referenced > 181:=20 > 182:
Authentication"> > 183: > 188: fyi: anchor SecForg not referenced > 187:=20 > 188:
> 189: > 200: fyi: anchor SecObs not referenced > 199:=20 > 200:
> 201: > 206: fyi: anchor SecReplay not referenced > 205:=20 > 206:
> 207: > 212: fyi: anchor SecRelDel not referenced > 211:=20 > 212:
> 213: > 218: fyi: anchor SecPri not referenced > 217:=20 > 218:
and Differentiation"> > 219: > 224: fyi: anchor SecDen not referenced > 223:=20 > 224:
> 225: > 231: fyi: anchor iana not referenced > 230:=20 > 231:
> 232: > 237: fyi: anchor rfc-editor not referenced > 236:=20 > 237:
> 238: > 244: fyi: anchor acks not referenced > 243:=20 > 244:
> 245: > 310: warning: anchor RFC1122 not referenced > 309:=20 > 310: > 311: > ...done > ---- end xml2rfc validation output --- All of these are un-used anchors. I don't see a problem. =20 > Idnits (using http://tools.ietf.org/tools/idnits/idnits.pyht) > Boilerplates and formatting checks look good. >=20 > ---- spelling ---- > (using MS-Word on the xml2rfc-generated html file) >=20 > The implementer/implementor debate rages on.=20 > Usage is inconsistenct within this document. > It would be nice if we were consistent across our documents.=20 > My research shows implementer as the preferred spelling. Done. > The term "misconfigured" is used. This is apparently not a=20 > real English word, and that means that implementers and=20 > readers who rely on translation tools will probably have=20 > problems with this term. Can we use "inappropriately=20 > configured" instead? Done. > The draft acknowledges Mickael Graham; is this the correct spelling? Yes, it is correct. > --- grammar --- >=20 > "The informational RFC 3164 [7] originally described the=20 > syslog" - eliminate "originally" Done.=20 > The documentt talks about "RFC3164 described" - doesn't it=20 > still describe? Shouldn't this be "describes"? Done. > "The RFC-protocol specifies a layered architecture that provided for" > - /provided/provides/ Done. > "This standards track RFC describes" should be "This document=20 > describes"; the IESG could always decide to publish this as a=20 > non-standards-track RFC, and it could be moved to "Historic"=20 > at a later date, so we should not specify standards-track in=20 > the body of the document; that status is external to the document. Done. > I don't feel very comfortable with use of the word protocol=20 > in "Network administrators and architects should be aware of=20 > the significant reliability and security issues of this=20 > protocol, which stem from the use of UDP." I think this=20 > document describes a transport mapping - how syslog should=20 > "interface to" the UDP protocol. > We are not defining a syslog-udp message format. Part of the=20 > problem is that when the text says "this protocol", I need to=20 > think about whether "this protocol" means syslog (which is=20 > definitely a protocol), or the syslog-udp transport mapping.=20 > So "This protocol supports transmission of syslog messages up=20 > to 65535 octets in size" is ambiguous as to wehere the limit=20 > is defined, but "This transport mapping supports transmission=20 > of syslog messages up to 65535 octets in size" is not. In=20 > sexction 5.3, "This transport protocol" apparently refers to=20 > UDP. It woul dbe less ambiguous if each usage of "this ... > Protocol" was replaced by "the UDP protocol" or "the=20 > syslog/udp transport mapping". Done.=20 > "a well-known port 514" s/b "the well-known port 514" Done. > --- RFC2119 terminology --- >=20 > Some of the keywrods are used in both lowercase and=20 > uppercase; I believe the preferred approach is to use=20 > uppercase consistently. Some authors use lowercase when th=20 > eterm is not used as an rfc2119 keyword, but uppercase when=20 > referring to an rfc2119 keyword. I recommend always using=20 > uppercase and avoiding the keywords when they are not meant=20 > to be used as an rfc2119 keyword to avoid ambiguity. Replaced "may" with can/could. It is a bit akward English in places, but meaning is clear I think.=20 > The word "can" is used where MAY might be more appropriate. I found one place. Replaced can with MAY here: "Each syslog UDP datagram MUST contain only one syslog message, which MAY be complete or truncated." Any other placed you had in mind? > The document says that "this transport protocol" is required=20 > for interoperability. However, two transport protocols are=20 > referred to, and they are not necessarily interoperable. For=20 > a system that only supports IPv4, then the UDP/IPv4 protocol=20 > should be required for interoperability. For a system that=20 > only supports IPv6, then UDP/IPv6 should be supported for=20 > interoperability in an IPv6 environment. For a system that=20 > supports both IPv4 and IPv6, what is required - UDP/IPv4,=20 > UDP/IPv6, or both, for interoperability?=20 I don't know what a "system" is. I can have different interfaces on a single system. Regardless of what's available, I may want to use IPv4 on one interface and IPv6 on another. I can run completely different syslog stacks on different applications. Is not it obvious that if syslog client is configured with IPv6, it need to send UDP packets using IPv6 and can only send those to server that supports IPv6? And if I am configured with IPv4 source IP, I need ot send IPv4 packets? =20 > If both, then by=20 > default, should operators have syslog messages sent over both=20 > (i.e. duplicate the messages) so they can be transmitted over=20 > IPv4 and IPv6 networks? > In SNMPv3, we chose UDP/IPv4 as the required even if both IPv4 and > IPv6 are available, and for IPv6-only devices, we require UDP/IPv6. Is this over-specifying? Why are we talking about "devices"?=20 I drafted the following text as best as I understood your suggestion for people to comment, but I am not very comfortable that this is helpful: "The IPv4 version of this transport mapping is REQUIRED for all syslog protocol implementations on devices supporting IPv4. The IPv6 version of this transport mapping is REQUIRED for all syslog protocol implementations on IPv6-only devices. These requirements are mandated for interoperability purposes." > --- general review --- >=20 > "This limit stems from the maximum supported UDP payload of=20 > 65535 octets specified in the RFC 768 [1]." - I couldn't find=20 > such a limit specified in rfc768.=20 > In fact, rfc768 **assumes**=20 > this will run over the IP protocol.=20 > IP might define some=20 > limits that would lead to this syslog limit.=20 It specifies 2 bytes for length of UDP datagram payload. =20 We specified earlier in the text that "Each syslog UDP datagram MUST contain only one syslog message..." Hence, it apears correct to say that "This transport mapping supports transmission of syslog messages up to 65535 octets in size." What am I missing? > If UDP had a=20 > limit, then saying UDP supported "payloads" > of 65535 would probably be incorrect, since part of the 65535=20 > limit would be used up by header fields, thus lessening the=20 > "payload" limit. I believe it is 65535 octets in addition to UDP header fields. =20 Or are you referriung to syslog protocol headers? Those, at the transport layer I consider part of syslog message payload. Just like IP counts payload with whatever internal headers the payload may have.=20 I did not make any changes here. Need to understand the issue.=20 > "It is RECOMMENDED that application developers restrict message sizes" > - shouldn't this be "It is RECOMMENDED that syslog senders=20 > restrict message sizes"? The receivers are also applications=20 > and we don't really want the receivers to restrict message sizes. Done. > I am a bit concerned that we are violating layer separation=20 > when we get too specific about the structure and checksums of=20 > the transport protocol; lower-layer details like checksums=20 > should not necessarily be made accessible to the syslog=20 > protocol, which operates at a higher > layer. We should trust the underlying > transport to do its job correctly, and operators to configure=20 > their devices correctly, so requiring syslog receivers to=20 > examine the UDP checksums seems wrong. In section 4.1, we go=20 > even further - "This > protocol specifies use of UDP checksums to enable corruption > detection in addition to checksums used in IP and Layer 2 protocols." > We have no business looking at layer 3 and layer 2 checksums.=20 > If a checksum is neede to validate the syslog mesdsage, then=20 > we should have a syslog checksum. I changed this to RECOMMENDED for both sender and receiver instead of MUST/SHOULD. I think recommending how you should use a lower layer is fine. This is often done. A MUST and SHOULD may be too much. =20 > Doesn't the last sentence of 5.1 mean basically the same=20 > thing as what is discussed in 5.2? Pretty much - just different examples (copied from syslog RFC 3164). Maybe worthwhile to keep the different examples. I combined the text into a section with heading "Sender Authentication and Message Forgery". I am happy to get rid of content of 5.2 if peopl ethink it does not add value.=20 =20 > Section 5.6 says "they will not get a higher priority". The=20 > standard will not mandate prioritization because that is an=20 > implementation decision and would not affect interoperability=20 > on-the-wire, but a sending implementation might provide such=20 > prioritization, so the document should not say they will not=20 > get a higher priority. It might even be a good idea to=20 > suggest that implementers of sending applications and relays=20 > consider support for prioritization based on the label. Changed to: "Unless some prioritization is implemented by the syslog sender, receiver and/or the network devices, the security implication of such behavior is that the syslog receiver or network devices could get overwhelmed with low-severity messages and be forced to discard potentially high-severity messages." > Section 5.7 discusses DoS attacks. Should the MIB include the=20 > ability to restrict the nuber of messages sent per minute? I am fine with that - probably a MIB document issue. But restricting compliant implementions of senders will not eliminate the DoS thread from a real attacker. So, this text likely needs to stay. =20 Thanks, Anton.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 ------_=_NextPart_001_01C6CD79.92D1103D Content-Type: text/plain; name="draft-ietf-syslog-transport-udp-08.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-syslog-transport-udp-08.txt Content-Disposition: attachment; filename="draft-ietf-syslog-transport-udp-08.txt" CgoKc3lzbG9nIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQS4gT2ttaWFuc2tpCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcywgSW5jLgpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKRXhwaXJl czogTWFyY2ggNSwgMjAwNwoKCiAgICAgICAgICAgICAgICBUcmFuc21pc3Npb24gb2Ygc3lzbG9n IG1lc3NhZ2VzIG92ZXIgVURQCiAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXN5c2xvZy10 cmFuc3BvcnQtdWRwLTA3CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRo aXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBw bGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMg YXdhcmUKICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNo IGhlIG9yIHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRh bmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2Ug KElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQKICAg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50 ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQs IHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1l LiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5j ZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNj ZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoK ICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBh Y2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJ bnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXJjaCA1LCAyMDA3LgoKQ29weXJpZ2h0IE5v dGljZQoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuCgpBYnN0 cmFjdAoKICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHRyYW5zcG9ydCBmb3Igc3lzbG9n IG1lc3NhZ2VzIG92ZXIgVURQLwogICBJUHY0IG9yIFVEUC9JUHY2LiAgVGhlIHN5c2xvZyBwcm90 b2NvbCBsYXllcmVkIGFyY2hpdGVjdHVyZSBwcm92aWRlcwogICBmb3Igc3VwcG9ydCBvZiBhbnkg bnVtYmVyIG9mIHRyYW5zcG9ydCBtYXBwaW5ncy4gIEhvd2V2ZXIsIGZvcgogICBpbnRlcm9wZXJh YmlsaXR5IHB1cnBvc2VzLCBzeXNsb2cgcHJvdG9jb2wgaW1wbGVtZW50ZXJzIGFyZSByZXF1aXJl ZAogICB0byBzdXBwb3J0IHRoaXMgdHJhbnNwb3J0IG1hcHBpbmcuCgoKCgoKCk9rbWlhbnNraSAg ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCA1LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFn ZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgc3lzbG9nIHVkcCB0cmFuc3BvcnQgICAg ICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9k dWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDMKICAgMi4gIENvbnZlbnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudCAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAzCiAgIDMuICBUcmFuc3BvcnQgUHJvdG9jb2wgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAgIDMuMS4gIE9uZSBNZXNzYWdl IFBlciBEYXRhZ3JhbSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgICAz LjIuICBNZXNzYWdlIFNpemUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAzCiAgICAgMy4zLiAgU291cmNlIGFuZCBUYXJnZXQgUG9ydHMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAgIDMuNC4gIFNvdXJjZSBJUCBBZGRyZXNzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAzLjUuICBVRFAv SVAgU3RydWN0dXJlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0 CiAgICAgMy42LiAgVURQIENoZWNrc3VtcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNQogICA0LiAgUmVsaWFiaWxpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgICA0LjEuICBMb3N0IERhdGFncmFt cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgNC4y LiAgTWVzc2FnZSBDb3JydXB0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgNQogICAgIDQuMy4gIENvbmdlc3Rpb24gQ29udHJvbCAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgICA0LjQuICBTZXF1ZW5jZWQgRGVsaXZlcnkgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2CiAgIDUuICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgog ICAgIDUuMS4gIFNlbmRlciBBdXRoZW50aWNhdGlvbiBhbmQgTWVzc2FnZSBGb3JnZXJ5ICAuIC4g LiAuIC4gLiAuIC4gIDYKICAgICA1LjIuICBNZXNzYWdlIE9ic2VydmF0aW9uICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgNS4zLiAgUmVwbGF5aW5nICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgIDUuNC4g IFVucmVsaWFibGUgRGVsaXZlcnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDcKICAgICA1LjUuICBNZXNzYWdlIFByaW9yaXRpemF0aW9uIGFuZCBEaWZmZXJlbnRpYXRp b24gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAgNS42LiAgRGVuaWFsIG9mIFNlcnZpY2UgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICA2LiAgSUFOQSBDb25zaWRl cmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAg Ny4gIE5vdGljZSB0byBSRkMgRWRpdG9yIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA4CiAgIDguICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICA5LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICA5LjEuICBO b3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA5CiAgICAgOS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgOQogICBBdXRob3IncyBBZGRyZXNzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgSW50ZWxsZWN0dWFsIFByb3Bl cnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCgoKCgoK CgoKCgoKCgoKCgoKCgoKT2ttaWFuc2tpICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDUs IDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICBzeXNsb2cgdWRwIHRyYW5zcG9ydCAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKMS4gIElu dHJvZHVjdGlvbgoKICAgVGhlIGluZm9ybWF0aW9uYWwgUkZDIDMxNjQgWzZdIGRlc2NyaWJlcyB0 aGUgc3lzbG9nIHByb3RvY29sIGFzIGl0CiAgIHdhcyBvYnNlcnZlZCBpbiBleGlzdGluZyBpbXBs ZW1lbnRhdGlvbnMuICBJdCBkZXNjcmliZXMgYm90aCB0aGUKICAgZm9ybWF0IG9mIHN5c2xvZyBt ZXNzYWdlcyBhbmQgYSBVRFAgWzFdIHRyYW5zcG9ydC4gIFN1YnNlcXVlbnRseSwgdGhlCiAgIHN5 c2xvZyBwcm90b2NvbCBoYXMgYmVlbiBmb3JtYWxseSBkZWZpbmVkIGluIHRoZSBSRkMtcHJvdG9j b2wgWzJdLgoKICAgVGhlIFJGQy1wcm90b2NvbCBzcGVjaWZpZXMgYSBsYXllcmVkIGFyY2hpdGVj dHVyZSB0aGF0IHByb3ZpZGVzIGZvcgogICBzdXBwb3J0IG9mIGFueSBudW1iZXIgb2YgdHJhbnNw b3J0IGxheWVyIG1hcHBpbmdzIGZvciB0cmFuc21pdHRpbmcKICAgc3lzbG9nIG1lc3NhZ2VzLiAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIFVEUCB0cmFuc3BvcnQgbWFwcGluZwogICBmb3Ig dGhlIHN5c2xvZyBwcm90b2NvbC4KCiAgIFRoZSB0cmFuc3BvcnQgZGVzY3JpYmVkIGluIHRoaXMg ZG9jdW1lbnQgY2FuIGJlIHVzZWQgZm9yIHRyYW5zbWl0dGluZwogICBzeXNsb2cgbWVzc2FnZXMg b3ZlciBib3RoIElQdjQgWzNdIGFuZCBJUHY2IFs0XS4gIFRoZSBJUHY0IHZlcnNpb24gb2YKICAg dGhpcyB0cmFuc3BvcnQgbWFwcGluZyBpcyBSRVFVSVJFRCBmb3IgYWxsIHN5c2xvZyBwcm90b2Nv bAogICBpbXBsZW1lbnRhdGlvbnMgb24gZGV2aWNlcyBzdXBwb3J0aW5nIElQdjQuICBUaGUgSVB2 NiB2ZXJzaW9uIG9mIHRoaXMKICAgdHJhbnNwb3J0IG1hcHBpbmcgaXMgUkVRVUlSRUQgZm9yIGFs bCBzeXNsb2cgcHJvdG9jb2wgaW1wbGVtZW50YXRpb25zCiAgIG9uIElQdjYtb25seSBkZXZpY2Vz LiAgVGhlc2UgcmVxdWlyZW1lbnRzIGFyZSBtYW5kYXRlZCBmb3IKICAgaW50ZXJvcGVyYWJpbGl0 eSBwdXJwb3Nlcy4KCiAgIE5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgYW5kIGFyY2hpdGVjdHMgc2hv dWxkIGJlIGF3YXJlIG9mIHRoZQogICBzaWduaWZpY2FudCByZWxpYWJpbGl0eSBhbmQgc2VjdXJp dHkgaXNzdWVzIG9mIHRoaXMgdHJhbnNwb3J0LCB3aGljaAogICBzdGVtIGZyb20gdGhlIHVzZSBv ZiBVRFAuICBUaGV5IGFyZSBkb2N1bWVudGVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4KICAgSG93 ZXZlciwgdGhpcyB0cmFuc3BvcnQgaXMgbGlnaHR3ZWlnaHQgYW5kIGlzIGJ1aWx0IHVwb24gdGhl IGV4aXN0aW5nCiAgIHBvcHVsYXIgdXNlIG9mIFVEUCBmb3Igc3lzbG9nLgoKCjIuICBDb252ZW50 aW9ucyBVc2VkIGluIFRoaXMgRG9jdW1lbnQKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVT VCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJT SE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMK ICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjEx OSBbNV0uCgoKMy4gIFRyYW5zcG9ydCBQcm90b2NvbAoKMy4xLiAgT25lIE1lc3NhZ2UgUGVyIERh dGFncmFtCgogICBFYWNoIHN5c2xvZyBVRFAgZGF0YWdyYW0gTVVTVCBjb250YWluIG9ubHkgb25l IHN5c2xvZyBtZXNzYWdlLCB3aGljaAogICBNQVkgYmUgY29tcGxldGUgb3IgdHJ1bmNhdGVkLiAg VGhlIG1lc3NhZ2UgTVVTVCBiZSBmb3JtYXR0ZWQgYW5kCiAgIHRydW5jYXRlZCBhY2NvcmRpbmcg dG8gdGhlIFJGQy1wcm90b2NvbCBbMl0uICBBZGRpdGlvbmFsIGRhdGEgTVVTVAogICBOT1QgYmUg cHJlc2VudCBpbiB0aGUgZGF0YWdyYW0gcGF5bG9hZC4KCjMuMi4gIE1lc3NhZ2UgU2l6ZQoKICAg VGhpcyB0cmFuc3BvcnQgbWFwcGluZyBzdXBwb3J0cyB0cmFuc21pc3Npb24gb2Ygc3lzbG9nIG1l c3NhZ2VzIHVwIHRvCiAgIDY1NTM1IG9jdGV0cyBpbiBzaXplLiAgVGhpcyBsaW1pdCBzdGVtcyBm cm9tIHRoZSBtYXhpbXVtIHN1cHBvcnRlZAogICBVRFAgcGF5bG9hZCBvZiA2NTUzNSBvY3RldHMg c3BlY2lmaWVkIGluIHRoZSBSRkMgNzY4IFsxXS4KCgoKT2ttaWFuc2tpICAgICAgICAgICAgICAg ICBFeHBpcmVzIE1hcmNoIDUsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICBzeXNsb2cgdWRwIHRyYW5zcG9ydCAgICAgICAgICAgIFNlcHRl bWJlciAyMDA2CgoKICAgSVB2NCBzeXNsb2cgcmVjZWl2ZXJzIE1VU1QgYmUgYWJsZSB0byByZWNl aXZlIGRhdGFncmFtcyB3aXRoIG1lc3NhZ2UKICAgc2l6ZSB1cCB0byBhbmQgaW5jbHVkaW5nIDQ4 MCBvY3RldHMuICBJUHY2IHN5c2xvZyByZWNlaXZlcnMgTVVTVCBiZQogICBhYmxlIHRvIHJlY2Vp dmUgZGF0YWdyYW1zIHdpdGggbWVzc2FnZSBzaXplIHVwIHRvIGFuZCBpbmNsdWRpbmcgMTE4MAog ICBvY3RldHMuICBBbGwgc3lzbG9nIHJlY2VpdmVycyBTSE9VTEQgYmUgYWJsZSB0byByZWNlaXZl IGRhdGFncmFtcwogICB3aXRoIG1lc3NhZ2VzIHNpemUgb2YgYXQgbGVhc3QgMjA0OCBvY3RldHMu CgogICBUaGUgYWJvdmUgcmVzdHJpY3Rpb25zIGFuZCByZWNvbW1lbmRhdGlvbnMgZXN0YWJsaXNo IGEgYmFzZWxpbmUgZm9yCiAgIGludGVyb3BlcmFiaWxpdHkuICBUaGUgbWluaW11bSByZXF1aXJl ZCBtZXNzYWdlIHNpemUgc3VwcG9ydCB3YXMKICAgZGV0ZXJtaW5lZCBiYXNlZCBvbiB0aGUgbWlu aW11bSBNVFUgc2l6ZSB0aGF0IGludGVybmV0IGhvc3RzIGFyZQogICByZXF1aXJlZCB0byBzdXBw b3J0OiA1NzYgb2N0ZXRzIGZvciBJUHY0IFszXSBhbmQgMTI4MCBvY3RldHMgZm9yIElQdjYKICAg WzRdLiAgRGF0YWdyYW1zIHRoYXQgZmFsbCB3aXRoaW4gdGhlc2UgbGltaXRzIGhhdmUgdGhlIGdy ZWF0ZXN0CiAgIGNoYW5jZSBvZiBiZWluZyBkZWxpdmVyZWQgYmVjYXVzZSB0aGV5IGRvIG5vdCBy ZXF1aXJlIGZyYWdtZW50YXRpb24uCgogICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHN5c2xvZyBz ZW5kZXJzIHJlc3RyaWN0IG1lc3NhZ2Ugc2l6ZXMgc3VjaAogICB0aGF0IElQIGRhdGFncmFtcyBk byBub3QgZXhjZWVkIHRoZSBzbWFsbGVzdCBNVFUgb2YgdGhlIG5ldHdvcmsgaW4KICAgdXNlLiAg VGhpcyBhdm9pZHMgZGF0YWdyYW0gZnJhZ21lbnRhdGlvbiBhbmQgcG9zc2libGUgaXNzdWVzCiAg IHN1cnJvdW5kaW5nIGZyYWdtZW50YXRpb24gc3VjaCBhcyBpbmNvcnJlY3QgTVRVIGRpc2NvdmVy eS4KICAgRnJhZ21lbnRhdGlvbiBjYW4gYmUgdW5kZXNpcmFibGUgYmVjYXVzZSBpdCBpbmNyZWFz ZXMgdGhlIHJpc2sgb2YgdGhlCiAgIG1lc3NhZ2UgYmVpbmcgbG9zdCBkdWUgdG8gbG9zcyBvZiBq dXN0IG9uZSBkYXRhZ3JhbSBmcmFnbWVudC4gIFdoZW4KICAgbmV0d29yayBNVFUgaXMgbm90IGtu b3duIGluIGFkdmFuY2UgYW5kIGNhbm5vdCBiZSByZWxpYWJseSBkZXRlcm1pbmVkCiAgIHVzaW5n IHBhdGggTVRVIGRpc2NvdmVyeSBbN10sIHRoZSBzYWZlc3QgYXNzdW1wdGlvbiBpcyB0byByZXN0 cmljdAogICBtZXNzYWdlcyB0byA0ODAgb2N0ZXRzIGZvciBJUHY0IGFuZCAxMTgwIG9jdGV0cyBm b3IgSVB2Ni4KCjMuMy4gIFNvdXJjZSBhbmQgVGFyZ2V0IFBvcnRzCgogICBTeXNsb2cgcmVjZWl2 ZXJzIE1VU1Qgc3VwcG9ydCBhY2NlcHRpbmcgc3lzbG9nIGRhdGFncmFtcyBvbiB0aGUgd2VsbC0K ICAga25vd24gVURQIHBvcnQgNTE0LCBidXQgTUFZIGJlIGNvbmZpZ3VyYWJsZSB0byBsaXN0ZW4g b24gYSBkaWZmZXJlbnQKICAgcG9ydC4gIFN5c2xvZyBzZW5kZXJzIE1VU1Qgc3VwcG9ydCBzZW5k aW5nIHN5c2xvZyBtZXNzYWdlIGRhdGFncmFtcwogICB0byB0aGUgVURQIHBvcnQgNTE0LCBidXQg TUFZIGJlIGNvbmZpZ3VyYWJsZSB0byBzZW5kIG1lc3NhZ2VzIHRvIGEKICAgZGlmZmVyZW50IHBv cnQuICBTeXNsb2cgc2VuZGVycyBNQVkgdXNlIGFueSBzb3VyY2UgVURQIHBvcnQgZm9yCiAgIHRy YW5zbWl0dGluZyBtZXNzYWdlcy4KCjMuNC4gIFNvdXJjZSBJUCBBZGRyZXNzCgogICBUaGUgc291 cmNlIElQIGFkZHJlc3Mgb2YgdGhlIFVEUCBkYXRhZ3JhbXMgU0hPVUxEIE5PVCBiZSBpbnRlcnBy ZXRlZAogICBhcyB0aGUgaWRlbnRpZmllciBmb3IgdGhlIGhvc3QgdGhhdCBvcmlnaW5hdGVkIHRo ZSBzeXNsb2cgbWVzc2FnZS4KICAgVGhlIGVudGl0eSBzZW5kaW5nIHRoZSBzeXNsb2cgbWVzc2Fn ZSBjb3VsZCBiZSBtZXJlbHkgYSByZWxheS4gIFRoZQogICBzeXNsb2cgbWVzc2FnZSBpdHNlbGYg Y29udGFpbnMgdGhlIGlkZW50aWZpZXIgb2YgdGhlIG9yaWdpbmF0b3Igb2YKICAgdGhlIG1lc3Nh Z2UuCgozLjUuICBVRFAvSVAgU3RydWN0dXJlCgogICBFYWNoIFVEUC9JUCBkYXRhZ3JhbSBzZW50 IGJ5IHRoZSB0cmFuc3BvcnQgbGF5ZXIgTVVTVCBjb21wbGV0ZWx5CiAgIGFkaGVyZSB0byB0aGUg c3RydWN0dXJlIHNwZWNpZmllZCBpbiB0aGUgVURQIFJGQyA3NjggWzFdIGFuZCBlaXRoZXIKICAg SVB2NCBSRkMgNzkxIFszXSBvciBJUHY2IFJGQyAyNDYwIFs0XSBkZXBlbmRpbmcgb24gd2hpY2gg cHJvdG9jb2wgaXMKICAgdXNlZC4KCgoKCgpPa21pYW5za2kgICAgICAgICAgICAgICAgIEV4cGly ZXMgTWFyY2ggNSwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgIHN5c2xvZyB1ZHAgdHJhbnNwb3J0ICAgICAgICAgICAgU2VwdGVtYmVyIDIw MDYKCgozLjYuICBVRFAgQ2hlY2tzdW1zCgogICBVc2Ugb2YgVURQIGNoZWNrc3VtcyB3YXMgZGVm aW5lZCBhcyBPUFRJT05BTCBpbiBSRkMgNzY4IFsxXS4gIElQdjYKICAgaGFzIHN1YnNlcXVlbnRs eSBtYWRlIFVEUCBjaGVja3N1bXMgUkVRVUlSRUQgaW4gUkZDIDI0NjAgWzRdLgoKICAgSXQgaXMg UkVDT01NRU5ERUQgdGhhdCBzeXNsb2cgc2VuZGVycyB1c2UgdmFsaWQgVURQIGNoZWNrc3VtcyB3 aGVuCiAgIHNlbmRpbmcgbWVzc2FnZXMgb3ZlciBJUHY0IGFuZCBJUHY2LgoKICAgSXQgaXMgUkVD T01NRU5ERUQgdGhhdCBzeXNsb2cgcmVjZWl2ZXJzIGNoZWNrIHRoZSBjaGVja3N1bXMgd2hlbmV2 ZXIKICAgdGhleSBhcmUgcHJlc2VudCAoaS5lLiB0aGUgVURQIGhlYWRlciBjaGVja3N1bSBmaWVs ZCB2YWx1ZSBpcyBub3QgMCkKICAgYW5kIGRpc2NhcmQgbWVzc2FnZXMgd2l0aCBpbmNvcnJlY3Qg Y2hlY2tzdW1zLiAgTm90ZSB0aGF0IHRoaXMgaXMKICAgdHlwaWNhbGx5IGFjY29tcGxpc2hlZCBi eSB0aGUgVURQIGxheWVyIGltcGxlbWVudGF0aW9uLCBhbmQgc29tZSBVRFAKICAgaW1wbGVtZW50 YXRpb25zIGFsbG93IGZvciBjaGVja3N1bSB2YWxpZGF0aW9uIHRvIGJlIGVuYWJsZWQgb3IKICAg ZGlzYWJsZWQuCgoKNC4gIFJlbGlhYmlsaXR5IENvbnNpZGVyYXRpb25zCgogICBUaGUgVURQIGlz IGFuIHVucmVsaWFibGUgbG93LW92ZXJoZWFkIHByb3RvY29sLiAgVGhpcyBzZWN0aW9uCiAgIGRp c2N1c3NlcyByZWxpYWJpbGl0eSBpc3N1ZXMgaW5oZXJlbnQgaW4gVURQIHRoYXQgaW1wbGVtZW50 ZXJzIGFuZAogICB1c2VycyBNVVNUIGJlIGF3YXJlIG9mLgoKNC4xLiAgTG9zdCBEYXRhZ3JhbXMK CiAgIFRoaXMgdHJhbnNwb3J0IG1hcHBpbmcgZG9lcyBub3QgcHJvdmlkZSBhbnkgbWVjaGFuaXNt IHRvIGRldGVjdCBhbmQKICAgY29ycmVjdCBsb3NzIG9mIGRhdGFncmFtcy4gIERhdGFncmFtcyBj YW4gYmUgbG9zdCBpbiB0cmFuc2l0IGR1ZSB0bwogICBjb25nZXN0aW9uLCBjb3JydXB0aW9uLCBv ciBhbnkgb3RoZXIgaW50ZXJtaXR0ZW50IG5ldHdvcmsgcHJvYmxlbS4KICAgSVAgZnJhZ21lbnRh dGlvbiBleGFjZXJiYXRlcyB0aGlzIHByb2JsZW0gYmVjYXVzZSBsb3NzIG9mIGEgc2luZ2xlCiAg IGZyYWdtZW50IHdpbGwgcmVzdWx0IGluIHRoZSBlbnRpcmUgbWVzc2FnZSBiZWluZyBkaXNjYXJk ZWQuCgogICBJbiBzb21lIGNpcmN1bXN0YW5jZXMgdGhlIHNlbmRlciBjYW4gcmVjZWl2ZSBhbiBJ Q01QIGVycm9yIG1lc3NhZ2Ugb3IKICAgb3RoZXIgaW5kaWNhdGlvbiBvZiBhIHRyYW5zbWlzc2lv biBwcm9ibGVtLiAgSWYgdGhlIHNlbmRlciByZWNlaXZlcyBhCiAgIHJlYXNvbmFibGUgaW5kaWNh dGlvbiB0aGF0IGEgZGF0YWdyYW0gaGFzIGJlZW4gbG9zdCwgaXQgTUFZCiAgIHJldHJhbnNtaXQg dGhlIGRhdGFncmFtLgoKNC4yLiAgTWVzc2FnZSBDb3JydXB0aW9uCgogICBUaGUgVURQL0lQIGRh dGFncmFtcyBjYW4gZ2V0IGNvcnJ1cHRlZCBpbiB0cmFuc2l0IGR1ZSB0byBzb2Z0d2FyZSwKICAg aGFyZHdhcmUsIG9yIG5ldHdvcmsgZXJyb3JzLiAgVGhpcyB0cmFuc3BvcnQgbWFwcGluZyBzcGVj aWZpZXMgdXNlIG9mCiAgIFVEUCBjaGVja3N1bXMgdG8gZW5hYmxlIGNvcnJ1cHRpb24gZGV0ZWN0 aW9uIGluIGFkZGl0aW9uIHRvIGNoZWNrc3VtcwogICB1c2VkIGluIElQIGFuZCBMYXllciAyIHBy b3RvY29scy4gIEhvd2V2ZXIsIGNoZWNrc3VtcyBkbyBub3QKICAgZ3VhcmFudGVlIGNvcnJ1cHRp b24gZGV0ZWN0aW9uLCBhbmQgdGhpcyB0cmFuc3BvcnQgbWFwcGluZyBkb2VzIG5vdAogICBwcm92 aWRlIGZvciBtZXNzYWdlIHJldHJhbnNtaXNzaW9uIHdoZW4gYSBjb3JydXB0IG1lc3NhZ2UgaXMK ICAgZGV0ZWN0ZWQuCgogICBBIHNwZWNpYWwgY2FzZSBvZiBjb3JydXB0aW9uIGlzIGNvcnJ1cHRp b24gaW50cm9kdWNlZCBieSB0aGUgVURQCiAgIGltcGxlbWVudGF0aW9uIGl0c2VsZi4gIEZvciBl eGFtcGxlLCBzZXZlcmFsIGVhcmxpZXIgVURQCiAgIGltcGxlbWVudGF0aW9ucyBkZWZhdWx0ZWQg dG8gYSBidWZmZXIgc2l6ZSBvZiBsZXNzIHRoYW4gNjU1MzUgb2N0ZXRzCgoKCk9rbWlhbnNraSAg ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCA1LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFn ZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgc3lzbG9nIHVkcCB0cmFuc3BvcnQgICAg ICAgICAgICBTZXB0ZW1iZXIgMjAwNgoKCiAgIGFuZCB0cnVuY2F0ZWQgbGFyZ2VyIHBheWxvYWRz IHVwb24gcmVjZWlwdCBbOF0uICBCeSBmb2xsb3dpbmcgdGhlCiAgIG1lc3NhZ2Ugc2l6ZSByZWNv bW1lbmRhdGlvbnMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQsIGFwcGxpY2F0aW9uCiAgIGRl dmVsb3BlcnMgY2FuIHNpZ25pZmljYW50bHkgcmVkdWNlIHRoZSByaXNrIG9mIHRoaXMgdHlwZSBv ZiBlcnJvci4KCjQuMy4gIENvbmdlc3Rpb24gQ29udHJvbAoKICAgVGhlIFVEUCBkb2VzIG5vdCBw cm92aWRlIGZvciBjb25nZXN0aW9uIGNvbnRyb2wuICBBbnkgbmV0d29yayBob3N0IG9yCiAgIHJv dXRlciBjYW4gZGlzY2FyZCBVRFAgcGFja2V0cyB3aGVuIGl0IGlzIG92ZXJsb2FkZWQsIGFuZCBj YW4KICAgb3B0aW9uYWxseSBwcm92aWRlIGFuIElDTVAgZXJyb3IgdG8gaW5kaWNhdGUgdGhpcy4g IE9uZSBvciBtdWx0aXBsZQogICBzeXNsb2cgc2VuZGVycyBjYW4gbWFsaWNpb3VzbHkgb3IgaW5h ZHZlcnRlbnRseSBvdmVybG9hZCB0aGUgcmVjZWl2ZXIKICAgb3IgdGhlIG5ldHdvcmsgaW5mcmFz dHJ1Y3R1cmUgYW5kIGNhdXNlIGxvc3Mgb2Ygc3lzbG9nIG1lc3NhZ2VzLgoKNC40LiAgU2VxdWVu Y2VkIERlbGl2ZXJ5CgogICBUaGUgSVAgdHJhbnNwb3J0IHVzZWQgYnkgdGhlIFVEUCBkb2VzIG5v dCBndWFyYW50ZWUgdGhhdCB0aGUgc2VxdWVuY2UKICAgb2YgZGF0YWdyYW0gZGVsaXZlcnkgd2ls bCBtYXRjaCB0aGUgb3JkZXIgaW4gd2hpY2ggdGhlIGRhdGFncmFtcyB3ZXJlCiAgIHNlbnQuICBU aGUgdGltZSBzdGFtcCBjb250YWluZWQgd2l0aGluIGVhY2ggc3lzbG9nIG1lc3NhZ2UgY2FuIHNl cnZlCiAgIGFzIGEgcm91Z2ggZ3VpZGUgaW4gZXN0YWJsaXNoaW5nIHNlcXVlbmNlIG9yZGVyLCBi dXQgaXQgd2lsbCBub3QgaGVscAogICBpbiBjYXNlcyB3aGVuIG11bHRpcGxlIG1lc3NhZ2VzIHdl cmUgZ2VuZXJhdGVkIGR1cmluZyB0aGUgc2FtZSB0aW1lCiAgIHNsb3QsIHRoZSBzZW5kZXIgY2Fu bm90IGdlbmVyYXRlIGEgdGltZSBzdGFtcCwgb3IgbWVzc2FnZXMgb3JpZ2luYXRlZAogICBmcm9t IGRpZmZlcmVudCBob3N0cyB3aG9zZSBjbG9ja3MgYXJlIG5vdCBzeW5jaHJvbml6ZWQuICBUaGUg b3JkZXIgb2YKICAgc3lzbG9nIG1lc3NhZ2UgYXJyaXZhbCB2aWEgdGhpcyB0cmFuc3BvcnQgU0hP VUxEIE5PVCBiZSB1c2VkIGFzIGFuCiAgIGF1dGhvcml0YXRpdmUgZ3VpZGUgaW4gZXN0YWJsaXNo aW5nIGFuIGFic29sdXRlIG9yIHJlbGF0aXZlIHNlcXVlbmNlCiAgIG9mIGV2ZW50cyBvbiB0aGUg c3lzbG9nIHNlbmRlciBob3N0cy4KCgo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFNl dmVyYWwgc3lzbG9nIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFyZSBkaXNjdXNzZWQgaW4gUkZD LXByb3RvY29sCiAgIFsyXS4gIFRoaXMgc2VjdGlvbiBmb2N1c2VzIG9uIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHNwZWNpZmljIHRvIHRoZQogICBzeXNsb2cgdHJhbnNwb3J0IG92ZXIgVURQLiAg U29tZSBvZiB0aGUgc2VjdXJpdHkgaXNzdWVzIHJhaXNlZCBpbgogICB0aGlzIHNlY3Rpb24gY2Fu IGJlIG1pdGlnYXRlZCB0aHJvdWdoIHRoZSB1c2Ugb2YgSVBTZWMgYXMgZGVmaW5lZCBpbgogICBS RkMgNDMwMSBbOV0uCgo1LjEuICBTZW5kZXIgQXV0aGVudGljYXRpb24gYW5kIE1lc3NhZ2UgRm9y Z2VyeQoKICAgVGhpcyB0cmFuc3BvcnQgbWFwcGluZyBkb2VzIG5vdCBwcm92aWRlIGZvciBzdHJv bmcgc2VuZGVyCiAgIGF1dGhlbnRpY2F0aW9uLiAgVGhlIHJlY2VpdmVyIG9mIHRoZSBzeXNsb2cg bWVzc2FnZSB3aWxsIG5vdCBiZSBhYmxlCiAgIHRvIGFzY2VydGFpbiB0aGF0IHRoZSBtZXNzYWdl IHdhcyBpbmRlZWQgc2VudCBmcm9tIHRoZSByZXBvcnRlZAogICBzZW5kZXIsIG9yIHdoZXRoZXIg dGhlIHBhY2tldCB3YXMgc2VudCBmcm9tIGFub3RoZXIgZGV2aWNlLiAgVGhpcyBjYW4KICAgYWxz byBsZWFkIHRvIGEgY2FzZSBvZiBtaXN0YWtlbiBpZGVudGl0eSBpZiBhbiBpbmFwcHJvcHJpYXRl bHkKICAgY29uZmlndXJlZCBtYWNoaW5lIHNlbmRzIHN5c2xvZyBtZXNzYWdlcyB0byBhIHJlY2Vp dmVyIHJlcHJlc2VudGluZwogICBpdHNlbGYgYXMgYW5vdGhlciBtYWNoaW5lLgoKICAgVGhpcyB0 cmFuc3BvcnQgbWFwcGluZyBkb2VzIG5vdCBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCBzeXNs b2cKICAgbWVzc2FnZSBmb3JnZXJ5LiAgQW4gYXR0YWNrZXIgY2FuIHRyYW5zbWl0IHN5c2xvZyBt ZXNzYWdlcyAoZWl0aGVyCiAgIGZyb20gdGhlIG1hY2hpbmUgZnJvbSB3aGljaCB0aGUgbWVzc2Fn ZXMgYXJlIHB1cnBvcnRlZGx5IHNlbnQgb3IgZnJvbQogICBhbnkgb3RoZXIgbWFjaGluZSkgdG8g YSByZWNlaXZlci4KCgoKT2ttaWFuc2tpICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDUs IDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICBzeXNsb2cgdWRwIHRyYW5zcG9ydCAgICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKICAgSW4g b25lIGNhc2UsIGFuIGF0dGFja2VyIGNhbiBoaWRlIHRoZSB0cnVlIG5hdHVyZSBvZiBhbiBhdHRh Y2sgYW1pZHN0CiAgIG1hbnkgb3RoZXIgbWVzc2FnZXMuICBBcyBhbiBleGFtcGxlLCBhbiBhdHRh Y2tlciBjYW4gc3RhcnQgZ2VuZXJhdGluZwogICBmb3JnZWQgbWVzc2FnZXMgaW5kaWNhdGluZyBh IHByb2JsZW0gb24gc29tZSBtYWNoaW5lLiAgVGhpcyBjYW4gZ2V0CiAgIHRoZSBhdHRlbnRpb24g b2YgdGhlIHN5c3RlbSBhZG1pbmlzdHJhdG9ycywgd2hvIHdpbGwgc3BlbmQgdGhlaXIgdGltZQog ICBpbnZlc3RpZ2F0aW5nIHRoZSBhbGxlZ2VkIHByb2JsZW0uICBEdXJpbmcgdGhpcyB0aW1lLCB0 aGUgYXR0YWNrZXIKICAgY291bGQgYmUgYWJsZSB0byBjb21wcm9taXNlIGEgZGlmZmVyZW50IG1h Y2hpbmUgb3IgYSBkaWZmZXJlbnQKICAgcHJvY2VzcyBvbiB0aGUgc2FtZSBtYWNoaW5lLgoKICAg QWRkaXRpb25hbGx5LCBhbiBhdHRhY2tlciBjYW4gZ2VuZXJhdGUgZmFsc2Ugc3lzbG9nIG1lc3Nh Z2VzIHRvIGdpdmUKICAgdW50cnVlIGluZGljYXRpb25zIG9mIHRoZSBzdGF0dXMgb2Ygc3lzdGVt cy4gIEFzIGFuIGV4YW1wbGUsIGFuCiAgIGF0dGFja2VyIGNhbiBzdG9wIGEgY3JpdGljYWwgcHJv Y2VzcyBvbiBhIG1hY2hpbmUsIHdoaWNoIGNvdWxkCiAgIGdlbmVyYXRlIGEgbm90aWZpY2F0aW9u IG9mIGV4aXQuICBUaGUgYXR0YWNrZXIgY2FuIHN1YnNlcXVlbnRseQogICBnZW5lcmF0ZSBhIGZv cmdlZCBub3RpZmljYXRpb24gdGhhdCB0aGUgcHJvY2VzcyBoYWQgYmVlbiByZXN0YXJ0ZWQuCiAg IFRoZSBzeXN0ZW0gYWRtaW5pc3RyYXRvcnMgY291bGQgYWNjZXB0IHRoYXQgbWlzaW5mb3JtYXRp b24gYW5kIG5vdAogICB2ZXJpZnkgdGhhdCB0aGUgcHJvY2VzcyBoYWQgaW5kZWVkIG5vdCBiZWVu IHJlc3RhcnRlZC4KCjUuMi4gIE1lc3NhZ2UgT2JzZXJ2YXRpb24KCiAgIFRoaXMgdHJhbnNwb3J0 IG1hcHBpbmcgZG9lcyBub3QgcHJvdmlkZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlCiAgIG1lc3Nh Z2VzIGluIHRyYW5zaXQuICBJZiBzeXNsb2cgbWVzc2FnZXMgYXJlIGluIGNsZWFyIHRleHQsIHRo aXMgaXMKICAgaG93IHRoZXkgd2lsbCBiZSB0cmFuc2ZlcnJlZC4gIEluIG1vc3QgY2FzZXMgcGFz c2luZyBjbGVhci10ZXh0CiAgIGh1bWFuLXJlYWRhYmxlIG1lc3NhZ2VzIGlzIGEgYmVuZWZpdCB0 byB0aGUgYWRtaW5pc3RyYXRvcnMuCiAgIFVuZm9ydHVuYXRlbHksIGFuIGF0dGFja2VyIGNvdWxk IGFsc28gYmUgYWJsZSB0byBvYnNlcnZlIHRoZSBodW1hbi0KICAgcmVhZGFibGUgY29udGVudHMg b2Ygc3lzbG9nIG1lc3NhZ2VzLiAgVGhlIGF0dGFja2VyIGNvdWxkIHRoZW4gdXNlCiAgIHRoZSBr bm93bGVkZ2UgZ2FpbmVkIGZyb20gdGhlc2UgbWVzc2FnZXMgdG8gY29tcHJvbWlzZSBhIG1hY2hp bmUuICBJdAogICBpcyBSRUNPTU1FTkRFRCB0aGF0IG5vIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBi ZSB0cmFuc21pdHRlZCB2aWEgdGhpcwogICB0cmFuc3BvcnQgbWFwcGluZyBvciB0aGF0IHRyYW5z bWlzc2lvbiBvZiBzdWNoIGluZm9ybWF0aW9uIGJlCiAgIHJlc3RyaWN0ZWQgdG8gcHJvcGVybHkg c2VjdXJlZCBuZXR3b3Jrcy4KCjUuMy4gIFJlcGxheWluZwoKICAgTWVzc2FnZSBmb3JnZXJ5IGFu ZCBvYnNlcnZhdGlvbiBjYW4gYmUgY29tYmluZWQgaW50byBhIHJlcGxheSBhdHRhY2suCiAgIEFu IGF0dGFja2VyIGNvdWxkIHJlY29yZCBhIHNldCBvZiBtZXNzYWdlcyB0aGF0IGluZGljYXRlIG5v cm1hbAogICBhY3Rpdml0eSBvZiBhIG1hY2hpbmUuICBBdCBhIGxhdGVyIHRpbWUsIGFuIGF0dGFj a2VyIGNvdWxkIHJlbW92ZQogICB0aGF0IG1hY2hpbmUgZnJvbSB0aGUgbmV0d29yayBhbmQgcmVw bGF5IHRoZSBzeXNsb2cgbWVzc2FnZXMgd2l0aCBuZXcKICAgdGltZSBzdGFtcHMuICBUaGUgYWRt aW5pc3RyYXRvcnMgY291bGQgZmluZCBub3RoaW5nIHVudXN1YWwgaW4gdGhlCiAgIHJlY2VpdmVk IG1lc3NhZ2VzLCBhbmQgdGhlaXIgcmVjZWlwdCB3b3VsZCBmYWxzZWx5IGluZGljYXRlIG5vcm1h bAogICBhY3Rpdml0eSBvZiB0aGUgbWFjaGluZS4KCjUuNC4gIFVucmVsaWFibGUgRGVsaXZlcnkK CiAgIEFzIHdhcyBwcmV2aW91c2x5IGRpc2N1c3NlZCBpbiB0aGUgUmVsaWFiaWxpdHkgQ29uc2lk ZXJhdGlvbnMKICAgc2VjdGlvbiwgdGhlIFVEUCB0cmFuc3BvcnQgaXMgbm90IHJlbGlhYmxlLCBh bmQgcGFja2V0cyBjb250YWluaW5nCiAgIHN5c2xvZyBtZXNzYWdlIGRhdGFncmFtcyBjYW4gYmUg bG9zdCBpbiB0cmFuc2l0IHdpdGhvdXQgYW55IG5vdGljZS4KICAgVGhlcmUgY2FuIGJlIHNlY3Vy aXR5IGNvbnNlcXVlbmNlcyB0byB0aGUgbG9zcyBvZiBvbmUgb3IgbW9yZSBzeXNsb2cKICAgbWVz c2FnZXMuICBBZG1pbmlzdHJhdG9ycyBjb3VsZCBiZSB1bmF3YXJlIG9mIGEgZGV2ZWxvcGluZyBh bmQKICAgcG90ZW50aWFsbHkgc2VyaW91cyBwcm9ibGVtLiAgTWVzc2FnZXMgY291bGQgYWxzbyBi ZSBpbnRlcmNlcHRlZCBhbmQKICAgZGlzY2FyZGVkIGJ5IGFuIGF0dGFja2VyIGFzIGEgd2F5IHRv IGhpZGUgdW5hdXRob3JpemVkIGFjdGl2aXRpZXMuCgoKCk9rbWlhbnNraSAgICAgICAgICAgICAg ICAgRXhwaXJlcyBNYXJjaCA1LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgc3lzbG9nIHVkcCB0cmFuc3BvcnQgICAgICAgICAgICBTZXB0 ZW1iZXIgMjAwNgoKCjUuNS4gIE1lc3NhZ2UgUHJpb3JpdGl6YXRpb24gYW5kIERpZmZlcmVudGlh dGlvbgoKICAgVGhpcyB0cmFuc3BvcnQgbWFwcGluZyBkb2VzIG5vdCBtYW5kYXRlIHByaW9yaXRp emF0aW9uIG9mIHN5c2xvZwogICBtZXNzYWdlcyBvbiB0aGUgd2lyZSBvciB3aGVuIHByb2Nlc3Nl ZCBvbiB0aGUgcmVjZWl2aW5nIGhvc3QgYmFzZWQgb24KICAgdGhlaXIgc2V2ZXJpdHkuICBVbmxl c3Mgc29tZSBwcmlvcml0aXphdGlvbiBpcyBpbXBsZW1lbnRlZCBieSBzZW5kZXIsCiAgIHJlY2Vp dmVyIGFuZC9vciBuZXR3b3JrLCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb24gb2Ygc3VjaCBiZWhh dmlvciBpcwogICB0aGF0IHRoZSBzeXNsb2cgcmVjZWl2ZXIgb3IgbmV0d29yayBkZXZpY2VzIGNv dWxkIGdldCBvdmVyd2hlbG1lZAogICB3aXRoIGxvdy1zZXZlcml0eSBtZXNzYWdlcyBhbmQgYmUg Zm9yY2VkIHRvIGRpc2NhcmQgcG90ZW50aWFsbHkgaGlnaC0KICAgc2V2ZXJpdHkgbWVzc2FnZXMu Cgo1LjYuICBEZW5pYWwgb2YgU2VydmljZQoKICAgQW4gYXR0YWNrZXIgY291bGQgb3ZlcndoZWxt IGEgcmVjZWl2ZXIgYnkgc2VuZGluZyBtb3JlIG1lc3NhZ2VzIHRvIGl0CiAgIHRoYW4gY291bGQg YmUgaGFuZGxlZCBieSB0aGUgaW5mcmFzdHJ1Y3R1cmUgb3IgdGhlIGRldmljZSBpdHNlbGYuCiAg IEltcGxlbWVudGVycyBTSE9VTEQgYXR0ZW1wdCB0byBwcm92aWRlIGZlYXR1cmVzIHRoYXQgbWlu aW1pemUgdGhpcwogICB0aHJlYXQgc3VjaCBhcyBvcHRpb25hbGx5IHJlc3RyaWN0aW5nIHJlY2Vw dGlvbiBvZiBtZXNzYWdlcyB0byBhIHNldAogICBvZiBrbm93IHNvdXJjZSBJUCBhZGRyZXNzZXMu CgoKNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIElBTkEgTVVTVCByZXNlcnZlIFVEUCBwb3J0 IDUxNCBmb3IgdGhpcyB0cmFuc3BvcnQuCgoKNy4gIE5vdGljZSB0byBSRkMgRWRpdG9yCgogICBU aGlzIGlzIGEgbm90aWNlIHRvIHRoZSBSRkMgZWRpdG9yLiAgVGhpcyBJRCBpcyBzdWJtaXR0ZWQg YWxvbmcgd2l0aAogICBJRCBkcmFmdC1pZXRmLXN5c2xvZy1wcm90b2NvbCBhbmQgdGhleSBjcm9z cy1yZWZlcmVuY2UgZWFjaCBvdGhlci4KICAgV2hlbiBSRkMgbnVtYmVycyBhcmUgZGV0ZXJtaW5l ZCBmb3IgZWFjaCBvZiB0aGVzZSBJRHMsIHBsZWFzZSByZXBsYWNlCiAgIGFsbCByZWZlcmVuY2Vz IHRvICJSRkMtcHJvdG9jb2wiIHdpdGggdGhlIFJGQyBudW1iZXIgb2YKICAgZHJhZnQtaWV0Zi1z eXNsb2ctcHJvdG9jb2wgSUQuICBBbHNvLCBwbGVhc2UgdXBkYXRlIHRoZSBkYXRlIGluIHRoZQog ICBzZWN0aW9uIHJlZmVyZW5jaW5nIHRoZSBuZXcgUkZDLiAgUGxlYXNlIHJlbW92ZSB0aGlzIHNl Y3Rpb24gYWZ0ZXIKICAgZWRpdGluZy4KCgo4LiAgQWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIGF1 dGhvciBncmF0ZWZ1bGx5IGFja25vd2xlZGdlcyB0aGUgY29udHJpYnV0aW9ucyBvZjogQ2hyaXMK ICAgTG9udmljaywgUmFpbmVyIEdlcmhhcmRzLCBEYXZpZCBIYXJyaW5ndG9uLCBBbmRyZXcgUm9z cywgQWxiZXJ0CiAgIE1pZXR1cywgQmVybmllIFZvbHosIE1pY2thZWwgR3JhaGFtLCBHcmVnIE1v cnJpcywgQWxleGFuZHJhIEZlZG9yb3ZhLAogICBEZXZpbiBLb3dhdGNoLCBSaWNoYXJkIEdyYXZl bWFuLCBhbmQgYWxsIG90aGVycyB3aG8gaGF2ZSBjb21tZW50ZWQgb24KICAgdGhlIHZhcmlvdXMg dmVyc2lvbnMgb2YgdGhpcyBwcm9wb3NhbC4KCgo5LiAgUmVmZXJlbmNlcwoKCgoKCgpPa21pYW5z a2kgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggNSwgMjAwNyAgICAgICAgICAgICAgICAg W1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIHN5c2xvZyB1ZHAgdHJhbnNwb3J0 ICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDYKCgo5LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoK ICAgWzFdICBQb3N0ZWwsIEouLCAiVXNlciBEYXRhZ3JhbSBQcm90b2NvbCIsIFNURCA2LCBSRkMg NzY4LAogICAgICAgIEF1Z3VzdCAxOTgwLgoKICAgWzJdICBHZXJoYXJkcywgUi4sICJUaGUgc3lz bG9nIFByb3RvY29sIiwgUkZDIFJGQy1wcm90b2NvbCwKICAgICAgICBKYW51YXJ5IDIwMDcuCgog ICBbM10gIFBvc3RlbCwgSi4sICJJbnRlcm5ldCBQcm90b2NvbCIsIFNURCA1LCBSRkMgNzkxLCBT ZXB0ZW1iZXIgMTk4MS4KCiAgIFs0XSAgRGVlcmluZywgUy4gYW5kIFIuIEhpbmRlbiwgIkludGVy bmV0IFByb3RvY29sLCBWZXJzaW9uIDYgKElQdjYpCiAgICAgICAgU3BlY2lmaWNhdGlvbiIsIFJG QyAyNDYwLCBEZWNlbWJlciAxOTk4LgoKICAgWzVdICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBm b3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQKICAgICAgICBMZXZlbHMiLCBC Q1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoKOS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNl cwoKICAgWzZdICBMb252aWNrLCBDLiwgIlRoZSBCU0QgU3lzbG9nIFByb3RvY29sIiwgUkZDIDMx NjQsIEF1Z3VzdCAyMDAxLgoKICAgWzddICBNb2d1bCwgSi4gYW5kIFMuIERlZXJpbmcsICJQYXRo IE1UVSBkaXNjb3ZlcnkiLCBSRkMgMTE5MSwKICAgICAgICBOb3ZlbWJlciAxOTkwLgoKICAgWzhd ICBTdGV2ZW5zLCBXLiwgIlRDUC9JUCBJbGx1c3RyYXRlZCBWb2x1bWUgMS4gVGhlIFByb3RvY29s cy4iLAogICAgICAgIEphbnVhcnkgMTk5NC4KCiAgIFs5XSAgS2VudCwgUy4gYW5kIEsuIFNlbywg IlNlY3VyaXR5IEFyY2hpdGVjdHVyZSBmb3IgdGhlIEludGVybmV0CiAgICAgICAgUHJvdG9jb2wi LCBSRkMgNDMwMSwgRGVjZW1iZXIgMjAwNS4KCgpBdXRob3IncyBBZGRyZXNzCgogICBBbnRvbiBP a21pYW5za2kKICAgQ2lzY28gU3lzdGVtcywgSW5jLgogICAxNDE0IE1hc3NhY2h1c2V0dHMgQXZl CiAgIEJveGJvcm91Z2gsIE1BICAwMTcxOS0yMjA1CiAgIFVTQQoKICAgUGhvbmU6ICsxLTk3OC05 MzYtMTYxMgogICBFbWFpbDogYW9rbWlhbnNAY2lzY28uY29tCgoKCgoKCgoKCgoKT2ttaWFuc2tp ICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDUsIDIwMDcgICAgICAgICAgICAgICAgIFtQ YWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBzeXNsb2cgdWRwIHRyYW5zcG9ydCAg ICAgICAgICAgIFNlcHRlbWJlciAyMDA2CgoKRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50CgogICBD b3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2KS4KCiAgIFRoaXMgZG9jdW1l bnQgaXMgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zCiAg IGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRo ZSBhdXRob3JzCiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLgoKICAgVGhpcyBkb2N1bWVudCBh bmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuCiAg ICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9T SEUgUkVQUkVTRU5UUwogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5F VCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQKICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVND TEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELAogICBJTkNMVURJTkcgQlVU IE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFCiAgIElORk9S TUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVE CiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElD VUxBUiBQVVJQT1NFLgoKCkludGVsbGVjdHVhbCBQcm9wZXJ0eQoKICAgVGhlIElFVEYgdGFrZXMg bm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkKICAgSW50 ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBj bGFpbWVkIHRvCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUg dGVjaG5vbG9neSBkZXNjcmliZWQgaW4KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRv IHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzCiAgIG1pZ2h0IG9yIG1pZ2h0IG5v dCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcwogICBtYWRl IGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5m b3JtYXRpb24KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBS RkMgZG9jdW1lbnRzIGNhbiBiZQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIENv cGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQg YW55CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRo ZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5z ZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRz IGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24gY2FuIGJl IG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdAogICBodHRw Oi8vd3d3LmlldGYub3JnL2lwci4KCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQg cGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkKICAgY29weXJpZ2h0cywgcGF0ZW50 cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQogICByaWdodHMg dGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1l bnQKICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0 aGUgSUVURiBhdAogICBpZXRmLWlwckBpZXRmLm9yZy4KCgpBY2tub3dsZWRnbWVudAoKICAgRnVu ZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYK ICAgQWRtaW5pc3RyYXRpdmUgU3VwcG9ydCBBY3Rpdml0eSAoSUFTQSkuCgoKCgoKT2ttaWFuc2tp ICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDUsIDIwMDcgICAgICAgICAgICAgICAgW1Bh Z2UgMTBdCgwKCg== ------_=_NextPart_001_01C6CD79.92D1103D Content-Type: text/xml; name="draft-ietf-syslog-transport-udp-08.xml" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-syslog-transport-udp-08.xml Content-Disposition: attachment; filename="draft-ietf-syslog-transport-udp-08.xml" PD94bWwgdmVyc2lvbj0iMS4wIj8+DQoNCjwhRE9DVFlQRSByZmMgU1lTVEVNICJyZmMyNjI5LmR0 ZCI+DQoNCjw/cmZjIHRvYz0ieWVzIiA/Pg0KPD9yZmMgc29ydHJlZnM9InllcyI/Pg0KPD9yZmMg aXBybm90aWZpZWQ9Im5vIiA/Pg0KPD9yZmMgY29tcGFjdD0ieWVzIiA/Pg0KDQo8cmZjIGlwcj0i ZnVsbDM5NzgiIGRvY05hbWU9ImRyYWZ0LWlldGYtc3lzbG9nLXRyYW5zcG9ydC11ZHAtMDciPg0K CQ0KCTxmcm9udD4NCgkJPHRpdGxlIGFiYnJldj0ic3lzbG9nIHVkcCB0cmFuc3BvcnQiPlRyYW5z bWlzc2lvbiBvZiBzeXNsb2cgbWVzc2FnZXMgb3Zlcg0KCQkJVURQPC90aXRsZT4NCgkJDQoJCTxh dXRob3IgaW5pdGlhbHM9IkEuIiBzdXJuYW1lPSJPa21pYW5za2kiIGZ1bGxuYW1lPSJBbnRvbiBP a21pYW5za2kiPg0KCQkJPG9yZ2FuaXphdGlvbj5DaXNjbyBTeXN0ZW1zLCBJbmMuPC9vcmdhbml6 YXRpb24+DQoJCQk8YWRkcmVzcz4NCgkJCQk8cG9zdGFsPg0KCQkJCQk8c3RyZWV0PjE0MTQgTWFz c2FjaHVzZXR0cyBBdmU8L3N0cmVldD4NCgkJCQkJPGNpdHk+Qm94Ym9yb3VnaDwvY2l0eT4NCgkJ CQkJPHJlZ2lvbj5NQTwvcmVnaW9uPg0KCQkJCQk8Y29kZT4wMTcxOS0yMjA1PC9jb2RlPg0KCQkJ CQk8Y291bnRyeT5VU0E8L2NvdW50cnk+DQoJCQkJPC9wb3N0YWw+DQoJCQkJPHBob25lPisxLTk3 OC05MzYtMTYxMjwvcGhvbmU+DQoJCQkJPGVtYWlsPmFva21pYW5zQGNpc2NvLmNvbTwvZW1haWw+ DQoJCQk8L2FkZHJlc3M+DQoJCTwvYXV0aG9yPg0KCQkNCgkJPGRhdGUgbW9udGg9IlNlcHRlbWJl ciIgeWVhcj0iMjAwNiIvPg0KCQkNCgkJPGFyZWE+U2VjdXJpdHk8L2FyZWE+DQoJCTx3b3JrZ3Jv dXA+c3lzbG9nIFdvcmtpbmcgR3JvdXA8L3dvcmtncm91cD4NCgkJPGtleXdvcmQ+c3lzbG9nPC9r ZXl3b3JkPg0KCQk8a2V5d29yZD5VRFA8L2tleXdvcmQ+DQoJCTxrZXl3b3JkPlVzZXIgRGF0YWdy YW0gUHJvdG9jb2w8L2tleXdvcmQ+DQoJCTxrZXl3b3JkPnRyYW5zcG9ydDwva2V5d29yZD4NCgkJ PGtleXdvcmQ+dHJhbnNtaXNzaW9uPC9rZXl3b3JkPg0KCQk8a2V5d29yZD5zeXNsb2cgVURQIHRy YW5zcG9ydDwva2V5d29yZD4NCgkJDQoJCTxhYnN0cmFjdD4NCgkJCTx0PiBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyB0aGUgdHJhbnNwb3J0IGZvciBzeXNsb2cgbWVzc2FnZXMgb3ZlciBVRFAvSVB2 NCBvcg0KCQkJCVVEUC9JUHY2LiBUaGUgc3lzbG9nIHByb3RvY29sIGxheWVyZWQgYXJjaGl0ZWN0 dXJlIHByb3ZpZGVzIGZvciBzdXBwb3J0DQoJCQkJb2YgYW55IG51bWJlciBvZiB0cmFuc3BvcnQg bWFwcGluZ3MuIEhvd2V2ZXIsIGZvciBpbnRlcm9wZXJhYmlsaXR5DQoJCQkJcHVycG9zZXMsIHN5 c2xvZyBwcm90b2NvbCBpbXBsZW1lbnRlcnMgYXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhpcw0K CQkJCXRyYW5zcG9ydCBtYXBwaW5nLiA8L3Q+DQoJCTwvYWJzdHJhY3Q+DQoJPC9mcm9udD4NCgkN Cgk8bWlkZGxlPg0KCQk8c2VjdGlvbiBhbmNob3I9ImludHJvIiB0aXRsZT0iSW50cm9kdWN0aW9u Ij4NCgkJCTx0PiBUaGUgaW5mb3JtYXRpb25hbCBSRkMgMzE2NA0KCQkJCTx4cmVmIHRhcmdldD0i UkZDMzE2NCIvPiBkZXNjcmliZXMgdGhlIHN5c2xvZyBwcm90b2NvbCBhcyBpdA0KCQkJCXdhcyBv YnNlcnZlZCBpbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuIEl0IGRlc2NyaWJlcyBib3RoIHRo ZSBmb3JtYXQgb2YNCgkJCQlzeXNsb2cgbWVzc2FnZXMgYW5kIGEgVURQDQoJCQkJPHhyZWYgdGFy Z2V0PSJSRkMwNzY4Ii8+IHRyYW5zcG9ydC4gU3Vic2VxdWVudGx5LCB0aGUgc3lzbG9nIHByb3Rv Y29sDQoJCQkJaGFzIGJlZW4gZm9ybWFsbHkgZGVmaW5lZCBpbiB0aGUgUkZDLXByb3RvY29sDQoJ CQkJPHhyZWYgdGFyZ2V0PSJSRkMtcHJvdG9jb2wiLz4uIDwvdD4NCgkJCQ0KCQkJPHQ+IFRoZSBS RkMtcHJvdG9jb2wgc3BlY2lmaWVzIGEgbGF5ZXJlZCBhcmNoaXRlY3R1cmUgdGhhdCBwcm92aWRl cyBmb3INCgkJCQlzdXBwb3J0IG9mIGFueSBudW1iZXIgb2YgdHJhbnNwb3J0IGxheWVyIG1hcHBp bmdzIGZvciB0cmFuc21pdHRpbmcgc3lzbG9nDQoJCQkJbWVzc2FnZXMuIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSBVRFAgdHJhbnNwb3J0IG1hcHBpbmcgZm9yIHRoZQ0KCQkJCXN5c2xvZyBw cm90b2NvbC4gPC90Pg0KCQkJDQoJCQk8dD4gVGhlIHRyYW5zcG9ydCBkZXNjcmliZWQgaW4gdGhp cyBkb2N1bWVudCBjYW4gYmUgdXNlZCBmb3IgdHJhbnNtaXR0aW5nIHN5c2xvZyBtZXNzYWdlcyBv dmVyIGJvdGggSVB2NA0KCQkJCTx4cmVmIHRhcmdldD0iUkZDMDc5MSIvPiBhbmQgSVB2Ng0KCQkJ CTx4cmVmIHRhcmdldD0iUkZDMjQ2MCIvPi4gVGhlIElQdjQgdmVyc2lvbiBvZiB0aGlzIHRyYW5z cG9ydCBtYXBwaW5nIGlzIFJFUVVJUkVEIGZvciBhbGwgc3lzbG9nIHByb3RvY29sIGltcGxlbWVu dGF0aW9ucyBvbiBkZXZpY2VzIHN1cHBvcnRpbmcgSVB2NC4gIFRoZSBJUHY2CQkJCXZlcnNpb24g b2YgdGhpcyB0cmFuc3BvcnQgbWFwcGluZyBpcyBSRVFVSVJFRCBmb3IgYWxsIHN5c2xvZyBwcm90 b2NvbCBpbXBsZW1lbnRhdGlvbnMgb24gSVB2Ni1vbmx5IGRldmljZXMuIFRoZXNlIHJlcXVpcmVt ZW50cyBhcmUgbWFuZGF0ZWQgZm9yIGludGVyb3BlcmFiaWxpdHkgcHVycG9zZXMuIDwvdD4NCgkJ CQ0KCQkJPHQ+IE5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgYW5kIGFyY2hpdGVjdHMgc2hvdWxkIGJl IGF3YXJlIG9mIHRoZSBzaWduaWZpY2FudA0KCQkJCXJlbGlhYmlsaXR5IGFuZCBzZWN1cml0eSBp c3N1ZXMgb2YgdGhpcyB0cmFuc3BvcnQsIHdoaWNoIHN0ZW0gZnJvbSB0aGUgdXNlIG9mDQoJCQkJ VURQLiBUaGV5IGFyZSBkb2N1bWVudGVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gSG93ZXZlciwg dGhpcyB0cmFuc3BvcnQgaXMNCgkJCQlsaWdodHdlaWdodCBhbmQgaXMgYnVpbHQgdXBvbiB0aGUg ZXhpc3RpbmcgcG9wdWxhciB1c2Ugb2YgVURQIGZvciBzeXNsb2cuDQoJCQkJPC90Pg0KCQk8L3Nl Y3Rpb24+DQoJCQ0KCQk8c2VjdGlvbiBhbmNob3I9InRlcm1zIiB0aXRsZT0iQ29udmVudGlvbnMg VXNlZCBpbiBUaGlzIERvY3VtZW50Ij4NCgkJCQ0KCQkJPHQ+VGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KCQkJCSJTSE9V TEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBp biB0aGlzDQoJCQkJZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBp biBSRkMgMjExOQ0KCQkJCTx4cmVmIHRhcmdldD0iUkZDMjExOSIvPi4gPC90Pg0KCQk8L3NlY3Rp b24+DQoJCQ0KCQk8c2VjdGlvbiBhbmNob3I9IlRyYW5zcG9ydCIgdGl0bGU9IlRyYW5zcG9ydCBQ cm90b2NvbCI+DQoJCQkNCgkJCTxzZWN0aW9uIGFuY2hvcj0iRGF0YWdyYW0iIHRpdGxlPSJPbmUg TWVzc2FnZSBQZXIgRGF0YWdyYW0iPg0KCQkJCTx0PiBFYWNoIHN5c2xvZyBVRFAgZGF0YWdyYW0g TVVTVCBjb250YWluIG9ubHkgb25lIHN5c2xvZyBtZXNzYWdlLCB3aGljaCBNQVkNCgkJCQkJYmUg Y29tcGxldGUgb3IgdHJ1bmNhdGVkLiBUaGUgbWVzc2FnZSBNVVNUIGJlIGZvcm1hdHRlZCBhbmQg dHJ1bmNhdGVkDQoJCQkJCWFjY29yZGluZyB0byB0aGUgUkZDLXByb3RvY29sDQoJCQkJCTx4cmVm IHRhcmdldD0iUkZDLXByb3RvY29sIi8+LiBBZGRpdGlvbmFsIGRhdGEgTVVTVCBOT1QgYmUgcHJl c2VudA0KCQkJCQlpbiB0aGUgZGF0YWdyYW0gcGF5bG9hZC4gPC90Pg0KCQkJPC9zZWN0aW9uPg0K CQkJDQoJCQk8c2VjdGlvbiBhbmNob3I9Ik1lc3NhZ2VTaXplIiB0aXRsZT0iTWVzc2FnZSBTaXpl Ij4NCgkJCQkNCgkJCQk8dD4gVGhpcyB0cmFuc3BvcnQgbWFwcGluZyBzdXBwb3J0cyB0cmFuc21p c3Npb24gb2Ygc3lzbG9nIG1lc3NhZ2VzIHVwIHRvIDY1NTM1DQoJCQkJCW9jdGV0cyBpbiBzaXpl LiBUaGlzIGxpbWl0IHN0ZW1zIGZyb20gdGhlIG1heGltdW0gc3VwcG9ydGVkIFVEUCBwYXlsb2Fk DQoJCQkJCW9mIDY1NTM1IG9jdGV0cyBzcGVjaWZpZWQgaW4gdGhlIFJGQyA3NjgNCgkJCQkJPHhy ZWYgdGFyZ2V0PSJSRkMwNzY4Ii8+LiA8L3Q+DQoJCQkJDQoJCQkJPHQ+IElQdjQgc3lzbG9nIHJl Y2VpdmVycyBNVVNUIGJlIGFibGUgdG8gcmVjZWl2ZSBkYXRhZ3JhbXMgd2l0aCBtZXNzYWdlDQoJ CQkJCXNpemUgdXAgdG8gYW5kIGluY2x1ZGluZyA0ODAgb2N0ZXRzLiBJUHY2IHN5c2xvZyByZWNl aXZlcnMgTVVTVCBiZSBhYmxlDQoJCQkJCXRvIHJlY2VpdmUgZGF0YWdyYW1zIHdpdGggbWVzc2Fn ZSBzaXplIHVwIHRvIGFuZCBpbmNsdWRpbmcgMTE4MCBvY3RldHMuDQoJCQkJCUFsbCBzeXNsb2cg cmVjZWl2ZXJzIFNIT1VMRCBiZSBhYmxlIHRvIHJlY2VpdmUgZGF0YWdyYW1zIHdpdGggbWVzc2Fn ZXMNCgkJCQkJc2l6ZSBvZiBhdCBsZWFzdCAyMDQ4IG9jdGV0cy4gPC90Pg0KCQkJCQ0KCQkJCTx0 PiBUaGUgYWJvdmUgcmVzdHJpY3Rpb25zIGFuZCByZWNvbW1lbmRhdGlvbnMgZXN0YWJsaXNoIGEg YmFzZWxpbmUgZm9yDQoJCQkJCWludGVyb3BlcmFiaWxpdHkuIFRoZSBtaW5pbXVtIHJlcXVpcmVk IG1lc3NhZ2Ugc2l6ZSBzdXBwb3J0IHdhcw0KCQkJCQlkZXRlcm1pbmVkIGJhc2VkIG9uIHRoZSBt aW5pbXVtIE1UVSBzaXplIHRoYXQgaW50ZXJuZXQgaG9zdHMgYXJlDQoJCQkJCXJlcXVpcmVkIHRv IHN1cHBvcnQ6IDU3NiBvY3RldHMgZm9yIElQdjQNCgkJCQkJPHhyZWYgdGFyZ2V0PSJSRkMwNzkx Ii8+IGFuZCAxMjgwIG9jdGV0cyBmb3IgSVB2Ng0KCQkJCQk8eHJlZiB0YXJnZXQ9IlJGQzI0NjAi Lz4uIERhdGFncmFtcyB0aGF0IGZhbGwgd2l0aGluIHRoZXNlIGxpbWl0cw0KCQkJCQloYXZlIHRo ZSBncmVhdGVzdCBjaGFuY2Ugb2YgYmVpbmcgZGVsaXZlcmVkIGJlY2F1c2UgdGhleSBkbyBub3Qg cmVxdWlyZQ0KCQkJCQlmcmFnbWVudGF0aW9uLiA8L3Q+DQoJCQkJDQoJCQkJPHQ+IEl0IGlzIFJF Q09NTUVOREVEIHRoYXQgc3lzbG9nIHNlbmRlcnMgcmVzdHJpY3QgbWVzc2FnZSBzaXplcyBzdWNo IHRoYXQgSVAgZGF0YWdyYW1zIGRvIG5vdCBleGNlZWQgdGhlIHNtYWxsZXN0IE1UVSBvZiB0aGUg bmV0d29yayBpbg0KCQkJCQl1c2UuIFRoaXMgYXZvaWRzIGRhdGFncmFtIGZyYWdtZW50YXRpb24g YW5kIHBvc3NpYmxlIGlzc3Vlcw0KCQkJCQlzdXJyb3VuZGluZyBmcmFnbWVudGF0aW9uIHN1Y2gg YXMgaW5jb3JyZWN0IE1UVSBkaXNjb3ZlcnkuDQoJCQkJCUZyYWdtZW50YXRpb24gY2FuIGJlIHVu ZGVzaXJhYmxlIGJlY2F1c2UgaXQgaW5jcmVhc2VzIHRoZSByaXNrIG9mIHRoZQ0KCQkJCQltZXNz YWdlIGJlaW5nIGxvc3QgZHVlIHRvIGxvc3Mgb2YganVzdCBvbmUgZGF0YWdyYW0gZnJhZ21lbnQu IFdoZW4NCgkJCQkJbmV0d29yayBNVFUgaXMgbm90IGtub3duIGluIGFkdmFuY2UgYW5kIGNhbm5v dCBiZSByZWxpYWJseSBkZXRlcm1pbmVkDQoJCQkJCXVzaW5nIHBhdGggTVRVIGRpc2NvdmVyeQ0K CQkJCQk8eHJlZiB0YXJnZXQ9IlJGQzExOTEiLz4sIHRoZSBzYWZlc3QgYXNzdW1wdGlvbiBpcyB0 byByZXN0cmljdA0KCQkJCQltZXNzYWdlcyB0byA0ODAgb2N0ZXRzIGZvciBJUHY0IGFuZCAxMTgw IG9jdGV0cyBmb3IgSVB2Ni4gPC90Pg0KCQkJCQ0KCQkJPC9zZWN0aW9uPg0KCQkJDQoJCQk8c2Vj dGlvbiBhbmNob3I9IlRhcmdldFBvcnQiIHRpdGxlPSJTb3VyY2UgYW5kIFRhcmdldCBQb3J0cyI+ DQoJCQkJPHQ+IFN5c2xvZyByZWNlaXZlcnMgTVVTVCBzdXBwb3J0IGFjY2VwdGluZyBzeXNsb2cg ZGF0YWdyYW1zIG9uIHRoZQ0KCQkJCQl3ZWxsLWtub3duIFVEUCBwb3J0IDUxNCwgYnV0IE1BWSBi ZSBjb25maWd1cmFibGUgdG8gbGlzdGVuIG9uIGENCgkJCQkJZGlmZmVyZW50IHBvcnQuIFN5c2xv ZyBzZW5kZXJzIE1VU1Qgc3VwcG9ydCBzZW5kaW5nIHN5c2xvZyBtZXNzYWdlDQoJCQkJCWRhdGFn cmFtcyB0byB0aGUgVURQIHBvcnQgNTE0LCBidXQgTUFZIGJlIGNvbmZpZ3VyYWJsZSB0byBzZW5k IG1lc3NhZ2VzDQoJCQkJCXRvIGEgZGlmZmVyZW50IHBvcnQuIFN5c2xvZyBzZW5kZXJzIE1BWSB1 c2UgYW55IHNvdXJjZSBVRFAgcG9ydCBmb3INCgkJCQkJdHJhbnNtaXR0aW5nIG1lc3NhZ2VzLiA8 L3Q+DQoJCQk8L3NlY3Rpb24+DQoJCQkNCgkJCTxzZWN0aW9uIGFuY2hvcj0iU291cmNlSVBBZGRy ZXNzIiB0aXRsZT0iU291cmNlIElQIEFkZHJlc3MiPg0KCQkJCTx0PiBUaGUgc291cmNlIElQIGFk ZHJlc3Mgb2YgdGhlIFVEUCBkYXRhZ3JhbXMgU0hPVUxEIE5PVCBiZSBpbnRlcnByZXRlZCBhcw0K CQkJCQl0aGUgaWRlbnRpZmllciBmb3IgdGhlIGhvc3QgdGhhdCBvcmlnaW5hdGVkIHRoZSBzeXNs b2cgbWVzc2FnZS4gVGhlDQoJCQkJCWVudGl0eSBzZW5kaW5nIHRoZSBzeXNsb2cgbWVzc2FnZSBj b3VsZCBiZSBtZXJlbHkgYSByZWxheS4gVGhlIHN5c2xvZw0KCQkJCQltZXNzYWdlIGl0c2VsZiBj b250YWlucyB0aGUgaWRlbnRpZmllciBvZiB0aGUgb3JpZ2luYXRvciBvZiB0aGUNCgkJCQkJbWVz c2FnZS4gPC90Pg0KCQkJPC9zZWN0aW9uPg0KCQkJDQoJCQk8c2VjdGlvbiBhbmNob3I9IlVEUElQ U3RydWN0dXJlIiB0aXRsZT0iVURQL0lQIFN0cnVjdHVyZSI+DQoJCQkJPHQ+IEVhY2ggVURQL0lQ IGRhdGFncmFtIHNlbnQgYnkgdGhlIHRyYW5zcG9ydCBsYXllciBNVVNUIGNvbXBsZXRlbHkgYWRo ZXJlDQoJCQkJCXRvIHRoZSBzdHJ1Y3R1cmUgc3BlY2lmaWVkIGluIHRoZSBVRFAgUkZDIDc2OA0K CQkJCQk8eHJlZiB0YXJnZXQ9IlJGQzA3NjgiLz4gYW5kIGVpdGhlciBJUHY0IFJGQyA3OTENCgkJ CQkJPHhyZWYgdGFyZ2V0PSJSRkMwNzkxIi8+IG9yIElQdjYgUkZDIDI0NjANCgkJCQkJPHhyZWYg dGFyZ2V0PSJSRkMyNDYwIi8+IGRlcGVuZGluZyBvbiB3aGljaCBwcm90b2NvbCBpcyB1c2VkLiA8 L3Q+DQoJCQk8L3NlY3Rpb24+DQoJCQkNCgkJCTxzZWN0aW9uIGFuY2hvcj0iVURQQ2hlY2tzdW1z IiB0aXRsZT0iVURQIENoZWNrc3VtcyI+DQoJCQkJPHQ+IFVzZSBvZiBVRFAgY2hlY2tzdW1zIHdh cyBkZWZpbmVkIGFzIE9QVElPTkFMIGluIFJGQyA3NjgNCgkJCQkJPHhyZWYgdGFyZ2V0PSJSRkMw NzY4Ii8+LiBJUHY2IGhhcyBzdWJzZXF1ZW50bHkgbWFkZSBVRFAgY2hlY2tzdW1zDQoJCQkJCVJF UVVJUkVEIGluIFJGQyAyNDYwDQoJCQkJCTx4cmVmIHRhcmdldD0iUkZDMjQ2MCIvPi4gPC90Pg0K CQkJCQ0KCQkJCTx0PiBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHN5c2xvZyBzZW5kZXJzIHVzZSB2 YWxpZCBVRFAgY2hlY2tzdW1zIHdoZW4gc2VuZGluZyBtZXNzYWdlcyBvdmVyIElQdjQgYW5kIElQ djYuIDwvdD4NCgkJCQk8dD4gSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBzeXNsb2cgcmVjZWl2ZXJz IGNoZWNrIHRoZSBjaGVja3N1bXMgd2hlbmV2ZXIgdGhleSBhcmUgcHJlc2VudA0KCQkJCQkoaS5l LiB0aGUgVURQIGhlYWRlciBjaGVja3N1bSBmaWVsZCB2YWx1ZSBpcyBub3QgMCkgYW5kIGRpc2Nh cmQgbWVzc2FnZXMNCgkJCQkJd2l0aCBpbmNvcnJlY3QgY2hlY2tzdW1zLiBOb3RlIHRoYXQgdGhp cyBpcyB0eXBpY2FsbHkgYWNjb21wbGlzaGVkIGJ5DQoJCQkJCXRoZSBVRFAgbGF5ZXIgaW1wbGVt ZW50YXRpb24sIGFuZCBzb21lIFVEUCBpbXBsZW1lbnRhdGlvbnMgYWxsb3cgZm9yDQoJCQkJCWNo ZWNrc3VtIHZhbGlkYXRpb24gdG8gYmUgZW5hYmxlZCBvciBkaXNhYmxlZC4gPC90Pg0KCQkJPC9z ZWN0aW9uPg0KCQkJDQoJCTwvc2VjdGlvbj4NCgkJDQoJCTxzZWN0aW9uIGFuY2hvcj0icmVsaWFi aWxpdHkiIHRpdGxlPSJSZWxpYWJpbGl0eSBDb25zaWRlcmF0aW9ucyI+DQoJCQkNCgkJCTx0PiBU aGUgVURQIGlzIGFuIHVucmVsaWFibGUgbG93LW92ZXJoZWFkIHByb3RvY29sLiBUaGlzIHNlY3Rp b24gZGlzY3Vzc2VzDQoJCQkJcmVsaWFiaWxpdHkgaXNzdWVzIGluaGVyZW50IGluIFVEUCB0aGF0 IGltcGxlbWVudGVycyBhbmQgdXNlcnMgTVVTVCBiZQ0KCQkJCWF3YXJlIG9mLiA8L3Q+DQoJCQkN CgkJCTxzZWN0aW9uIGFuY2hvcj0ibG9zcyIgdGl0bGU9Ikxvc3QgRGF0YWdyYW1zIj4NCgkJCQk8 dD4gVGhpcyB0cmFuc3BvcnQgbWFwcGluZyBkb2VzIG5vdCBwcm92aWRlIGFueSBtZWNoYW5pc20g dG8gZGV0ZWN0IGFuZA0KCQkJCQljb3JyZWN0IGxvc3Mgb2YgZGF0YWdyYW1zLiBEYXRhZ3JhbXMg Y2FuIGJlIGxvc3QgaW4gdHJhbnNpdCBkdWUgdG8NCgkJCQkJY29uZ2VzdGlvbiwgY29ycnVwdGlv biwgb3IgYW55IG90aGVyIGludGVybWl0dGVudCBuZXR3b3JrIHByb2JsZW0uDQoJCQkJCUlQIGZy YWdtZW50YXRpb24gZXhhY2VyYmF0ZXMgdGhpcyBwcm9ibGVtIGJlY2F1c2UgbG9zcyBvZiBhIHNp bmdsZQ0KCQkJCQlmcmFnbWVudCB3aWxsIHJlc3VsdCBpbiB0aGUgZW50aXJlIG1lc3NhZ2UgYmVp bmcgZGlzY2FyZGVkLiA8L3Q+DQoJCQkJPHQ+IEluIHNvbWUgY2lyY3Vtc3RhbmNlcyB0aGUgc2Vu ZGVyIGNhbiByZWNlaXZlIGFuIElDTVAgZXJyb3IgbWVzc2FnZSBvcg0KCQkJCQlvdGhlciBpbmRp Y2F0aW9uIG9mIGEgdHJhbnNtaXNzaW9uIHByb2JsZW0uIElmIHRoZSBzZW5kZXIgcmVjZWl2ZXMg YQ0KCQkJCQlyZWFzb25hYmxlIGluZGljYXRpb24gdGhhdCBhIGRhdGFncmFtIGhhcyBiZWVuIGxv c3QsIGl0IE1BWQ0KCQkJCQlyZXRyYW5zbWl0IHRoZSBkYXRhZ3JhbS4gPC90Pg0KCQkJPC9zZWN0 aW9uPg0KCQkJDQoJCQk8c2VjdGlvbiBhbmNob3I9ImNvcnJ1cHRpb24iIHRpdGxlPSJNZXNzYWdl IENvcnJ1cHRpb24iPg0KCQkJCTx0PiBUaGUgVURQL0lQIGRhdGFncmFtcyBjYW4gZ2V0IGNvcnJ1 cHRlZCBpbiB0cmFuc2l0IGR1ZSB0byBzb2Z0d2FyZSwNCgkJCQkJaGFyZHdhcmUsIG9yIG5ldHdv cmsgZXJyb3JzLiBUaGlzIHRyYW5zcG9ydCBtYXBwaW5nIHNwZWNpZmllcyB1c2Ugb2YgVURQDQoJ CQkJCWNoZWNrc3VtcyB0byBlbmFibGUgY29ycnVwdGlvbiBkZXRlY3Rpb24gaW4gYWRkaXRpb24g dG8gY2hlY2tzdW1zDQoJCQkJCXVzZWQgaW4gSVAgYW5kIExheWVyIDIgcHJvdG9jb2xzLiBIb3dl dmVyLCBjaGVja3N1bXMgZG8gbm90IGd1YXJhbnRlZQ0KCQkJCQljb3JydXB0aW9uIGRldGVjdGlv biwgYW5kIHRoaXMgdHJhbnNwb3J0IG1hcHBpbmcgZG9lcyBub3QgcHJvdmlkZSBmb3IgbWVzc2Fn ZQ0KCQkJCQlyZXRyYW5zbWlzc2lvbiB3aGVuIGEgY29ycnVwdCBtZXNzYWdlIGlzIGRldGVjdGVk LiA8L3Q+DQoJCQkJPHQ+IEEgc3BlY2lhbCBjYXNlIG9mIGNvcnJ1cHRpb24gaXMgY29ycnVwdGlv biBpbnRyb2R1Y2VkIGJ5IHRoZSBVRFANCgkJCQkJaW1wbGVtZW50YXRpb24gaXRzZWxmLiBGb3Ig ZXhhbXBsZSwgc2V2ZXJhbCBlYXJsaWVyIFVEUA0KCQkJCQlpbXBsZW1lbnRhdGlvbnMgZGVmYXVs dGVkIHRvIGEgYnVmZmVyIHNpemUgb2YgbGVzcyB0aGFuIDY1NTM1IG9jdGV0cw0KCQkJCQlhbmQg dHJ1bmNhdGVkIGxhcmdlciBwYXlsb2FkcyB1cG9uIHJlY2VpcHQNCgkJCQkJPHhyZWYgdGFyZ2V0 PSJTdGV2ZW5zIi8+LiBCeSBmb2xsb3dpbmcgdGhlIG1lc3NhZ2Ugc2l6ZQ0KCQkJCQlyZWNvbW1l bmRhdGlvbnMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQsIGFwcGxpY2F0aW9uIGRldmVsb3Bl cnMgY2FuDQoJCQkJCXNpZ25pZmljYW50bHkgcmVkdWNlIHRoZSByaXNrIG9mIHRoaXMgdHlwZSBv ZiBlcnJvci4gPC90Pg0KCQkJPC9zZWN0aW9uPg0KCQkJDQoJCQk8c2VjdGlvbiBhbmNob3I9Im92 ZXJsb2FkIiB0aXRsZT0iQ29uZ2VzdGlvbiBDb250cm9sIj4NCgkJCQk8dD4gVGhlIFVEUCBkb2Vz IG5vdCBwcm92aWRlIGZvciBjb25nZXN0aW9uIGNvbnRyb2wuIEFueSBuZXR3b3JrIGhvc3Qgb3IN CgkJCQkJcm91dGVyIGNhbiBkaXNjYXJkIFVEUCBwYWNrZXRzIHdoZW4gaXQgaXMgb3ZlcmxvYWRl ZCwgYW5kIGNhbiBvcHRpb25hbGx5IA0KCQkJCQlwcm92aWRlIGFuIElDTVAgZXJyb3IgdG8gaW5k aWNhdGUgdGhpcy4gT25lIG9yIG11bHRpcGxlIHN5c2xvZw0KCQkJCQlzZW5kZXJzIGNhbiBtYWxp Y2lvdXNseSBvciBpbmFkdmVydGVudGx5IG92ZXJsb2FkIHRoZSByZWNlaXZlciBvciB0aGUNCgkJ CQkJbmV0d29yayBpbmZyYXN0cnVjdHVyZSBhbmQgY2F1c2UgbG9zcyBvZiBzeXNsb2cgbWVzc2Fn ZXMuIDwvdD4NCgkJCTwvc2VjdGlvbj4NCgkJCQ0KCQkJPHNlY3Rpb24gYW5jaG9yPSJzZXF1ZW5j ZSIgdGl0bGU9IlNlcXVlbmNlZCBEZWxpdmVyeSI+DQoJCQkJPHQ+IFRoZSBJUCB0cmFuc3BvcnQg dXNlZCBieSB0aGUgVURQIGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IHRoZSBzZXF1ZW5jZSBvZg0K CQkJCQlkYXRhZ3JhbSBkZWxpdmVyeSB3aWxsIG1hdGNoIHRoZSBvcmRlciBpbiB3aGljaCB0aGUg ZGF0YWdyYW1zIHdlcmUNCgkJCQkJc2VudC4gVGhlIHRpbWUgc3RhbXAgY29udGFpbmVkIHdpdGhp biBlYWNoIHN5c2xvZyBtZXNzYWdlIGNhbiBzZXJ2ZSBhcyBhDQoJCQkJCXJvdWdoIGd1aWRlIGlu IGVzdGFibGlzaGluZyBzZXF1ZW5jZSBvcmRlciwgYnV0IGl0IHdpbGwgbm90IGhlbHAgaW4NCgkJ CQkJY2FzZXMgd2hlbiBtdWx0aXBsZSBtZXNzYWdlcyB3ZXJlIGdlbmVyYXRlZCBkdXJpbmcgdGhl IHNhbWUgdGltZSBzbG90LA0KCQkJCQl0aGUgc2VuZGVyIGNhbm5vdCBnZW5lcmF0ZSBhIHRpbWUg c3RhbXAsIG9yIG1lc3NhZ2VzIG9yaWdpbmF0ZWQgZnJvbQ0KCQkJCQlkaWZmZXJlbnQgaG9zdHMg d2hvc2UgY2xvY2tzIGFyZSBub3Qgc3luY2hyb25pemVkLiBUaGUgb3JkZXIgb2Ygc3lzbG9nDQoJ CQkJCW1lc3NhZ2UgYXJyaXZhbCB2aWEgdGhpcyB0cmFuc3BvcnQgU0hPVUxEIE5PVCBiZSB1c2Vk IGFzIGFuDQoJCQkJCWF1dGhvcml0YXRpdmUgZ3VpZGUgaW4gZXN0YWJsaXNoaW5nIGFuIGFic29s dXRlIG9yIHJlbGF0aXZlIHNlcXVlbmNlDQoJCQkJCW9mIGV2ZW50cyBvbiB0aGUgc3lzbG9nIHNl bmRlciBob3N0cy4gPC90Pg0KCQkJPC9zZWN0aW9uPg0KCQkJDQoJCTwvc2VjdGlvbj4NCgkJDQoJ CTxzZWN0aW9uIGFuY2hvcj0ic2VjdXJpdHkiIHRpdGxlPSJTZWN1cml0eSBDb25zaWRlcmF0aW9u cyI+DQoJCQk8dD4gU2V2ZXJhbCBzeXNsb2cgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXJlIGRp c2N1c3NlZCBpbiBSRkMtcHJvdG9jb2wNCgkJCQk8eHJlZiB0YXJnZXQ9IlJGQy1wcm90b2NvbCIv Pi4gVGhpcyBzZWN0aW9uIGZvY3VzZXMgb24gc2VjdXJpdHkNCgkJCQljb25zaWRlcmF0aW9ucyBz cGVjaWZpYyB0byB0aGUgc3lzbG9nIHRyYW5zcG9ydCBvdmVyIFVEUC4gU29tZSBvZiB0aGUgc2Vj dXJpdHkNCgkJCQlpc3N1ZXMgcmFpc2VkIGluIHRoaXMgc2VjdGlvbiBjYW4gYmUgbWl0aWdhdGVk IHRocm91Z2ggdGhlIHVzZSBvZiBJUFNlYyBhcyBkZWZpbmVkIGluIFJGQw0KCQkJCTQzMDENCgkJ CQk8eHJlZiB0YXJnZXQ9IlJGQzQzMDEiLz4uPC90Pg0KCQkJDQoJCQk8c2VjdGlvbiBhbmNob3I9 IlNlbmRlckF1dGhlbnRpY2F0aW9uIiB0aXRsZT0iU2VuZGVyIEF1dGhlbnRpY2F0aW9uIGFuZCBN ZXNzYWdlIEZvcmdlcnkiPg0KCQkJCTx0PiBUaGlzIHRyYW5zcG9ydCBtYXBwaW5nIGRvZXMgbm90 IHByb3ZpZGUgZm9yIHN0cm9uZyBzZW5kZXINCgkJCQkJYXV0aGVudGljYXRpb24uIFRoZSByZWNl aXZlciBvZiB0aGUgc3lzbG9nIG1lc3NhZ2Ugd2lsbCBub3QgYmUgYWJsZSB0bw0KCQkJCQlhc2Nl cnRhaW4gdGhhdCB0aGUgbWVzc2FnZSB3YXMgaW5kZWVkIHNlbnQgZnJvbSB0aGUgcmVwb3J0ZWQg c2VuZGVyLCBvcg0KCQkJCQl3aGV0aGVyIHRoZSBwYWNrZXQgd2FzIHNlbnQgZnJvbSBhbm90aGVy IGRldmljZS4gVGhpcyBjYW4gYWxzbyBsZWFkIHRvIGENCgkJCQkJY2FzZSBvZiBtaXN0YWtlbiBp ZGVudGl0eSBpZiBhbiBpbmFwcHJvcHJpYXRlbHkgY29uZmlndXJlZCBtYWNoaW5lIHNlbmRzIHN5 c2xvZw0KCQkJCQltZXNzYWdlcyB0byBhIHJlY2VpdmVyIHJlcHJlc2VudGluZyBpdHNlbGYgYXMg YW5vdGhlciBtYWNoaW5lLiA8L3Q+DQoNCgkJCQk8dD4gVGhpcyB0cmFuc3BvcnQgbWFwcGluZyBk b2VzIG5vdCBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCBzeXNsb2cNCgkJCQkJbWVzc2FnZSBm b3JnZXJ5LiBBbiBhdHRhY2tlciBjYW4gdHJhbnNtaXQgc3lzbG9nIG1lc3NhZ2VzIChlaXRoZXIN CgkJCQkJZnJvbSB0aGUgbWFjaGluZSBmcm9tIHdoaWNoIHRoZSBtZXNzYWdlcyBhcmUgcHVycG9y dGVkbHkgc2VudCBvciBmcm9tDQoJCQkJCWFueSBvdGhlciBtYWNoaW5lKSB0byBhIHJlY2VpdmVy LiA8L3Q+DQoJCQkJPHQ+IEluIG9uZSBjYXNlLCBhbiBhdHRhY2tlciBjYW4gaGlkZSB0aGUgdHJ1 ZSBuYXR1cmUgb2YgYW4gYXR0YWNrIGFtaWRzdCBtYW55DQoJCQkJCW90aGVyIG1lc3NhZ2VzLiBB cyBhbiBleGFtcGxlLCBhbiBhdHRhY2tlciBjYW4gc3RhcnQgZ2VuZXJhdGluZyBmb3JnZWQNCgkJ CQkJbWVzc2FnZXMgaW5kaWNhdGluZyBhIHByb2JsZW0gb24gc29tZSBtYWNoaW5lLiBUaGlzIGNh biBnZXQgdGhlDQoJCQkJCWF0dGVudGlvbiBvZiB0aGUgc3lzdGVtIGFkbWluaXN0cmF0b3JzLCB3 aG8gd2lsbCBzcGVuZCB0aGVpciB0aW1lDQoJCQkJCWludmVzdGlnYXRpbmcgdGhlIGFsbGVnZWQg cHJvYmxlbS4gRHVyaW5nIHRoaXMgdGltZSwgdGhlIGF0dGFja2VyIGNvdWxkDQoJCQkJCWJlIGFi bGUgdG8gY29tcHJvbWlzZSBhIGRpZmZlcmVudCBtYWNoaW5lIG9yIGEgZGlmZmVyZW50IHByb2Nl c3Mgb24gdGhlDQoJCQkJCXNhbWUgbWFjaGluZS4gPC90Pg0KCQkJCTx0PiBBZGRpdGlvbmFsbHks IGFuIGF0dGFja2VyIGNhbiBnZW5lcmF0ZSBmYWxzZSBzeXNsb2cgbWVzc2FnZXMgdG8gZ2l2ZQ0K CQkJCQl1bnRydWUgaW5kaWNhdGlvbnMgb2YgdGhlIHN0YXR1cyBvZiBzeXN0ZW1zLiBBcyBhbiBl eGFtcGxlLCBhbiBhdHRhY2tlcg0KCQkJCQljYW4gc3RvcCBhIGNyaXRpY2FsIHByb2Nlc3Mgb24g YSBtYWNoaW5lLCB3aGljaCBjb3VsZCBnZW5lcmF0ZSBhDQoJCQkJCW5vdGlmaWNhdGlvbiBvZiBl eGl0LiBUaGUgYXR0YWNrZXIgY2FuIHN1YnNlcXVlbnRseSBnZW5lcmF0ZSBhIGZvcmdlZA0KCQkJ CQlub3RpZmljYXRpb24gdGhhdCB0aGUgcHJvY2VzcyBoYWQgYmVlbiByZXN0YXJ0ZWQuIFRoZSBz eXN0ZW0NCgkJCQkJYWRtaW5pc3RyYXRvcnMgY291bGQgYWNjZXB0IHRoYXQgbWlzaW5mb3JtYXRp b24gYW5kIG5vdCB2ZXJpZnkgdGhhdCB0aGUNCgkJCQkJcHJvY2VzcyBoYWQgaW5kZWVkIG5vdCBi ZWVuIHJlc3RhcnRlZC4gPC90Pg0KCQkJPC9zZWN0aW9uPg0KCQkJDQoJCQk8c2VjdGlvbiBhbmNo b3I9IlNlY09icyIgdGl0bGU9Ik1lc3NhZ2UgT2JzZXJ2YXRpb24iPg0KCQkJCTx0PiBUaGlzIHRy YW5zcG9ydCBtYXBwaW5nIGRvZXMgbm90IHByb3ZpZGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZQ0K CQkJCQltZXNzYWdlcyBpbiB0cmFuc2l0LiBJZiBzeXNsb2cgbWVzc2FnZXMgYXJlIGluIGNsZWFy IHRleHQsIHRoaXMgaXMgaG93DQoJCQkJCXRoZXkgd2lsbCBiZSB0cmFuc2ZlcnJlZC4gSW4gbW9z dCBjYXNlcyBwYXNzaW5nIGNsZWFyLXRleHQNCgkJCQkJaHVtYW4tcmVhZGFibGUgbWVzc2FnZXMg aXMgYSBiZW5lZml0IHRvIHRoZSBhZG1pbmlzdHJhdG9ycy4NCgkJCQkJVW5mb3J0dW5hdGVseSwg YW4gYXR0YWNrZXIgY291bGQgYWxzbyBiZSBhYmxlIHRvIG9ic2VydmUgdGhlDQoJCQkJCWh1bWFu LXJlYWRhYmxlIGNvbnRlbnRzIG9mIHN5c2xvZyBtZXNzYWdlcy4gVGhlIGF0dGFja2VyIGNvdWxk IHRoZW4gdXNlDQoJCQkJCXRoZSBrbm93bGVkZ2UgZ2FpbmVkIGZyb20gdGhlc2UgbWVzc2FnZXMg dG8gY29tcHJvbWlzZSBhIG1hY2hpbmUuIEl0IGlzDQoJCQkJCVJFQ09NTUVOREVEIHRoYXQgbm8g c2Vuc2l0aXZlIGluZm9ybWF0aW9uIGJlIHRyYW5zbWl0dGVkIHZpYSB0aGlzDQoJCQkJCXRyYW5z cG9ydCBtYXBwaW5nIG9yIHRoYXQgdHJhbnNtaXNzaW9uIG9mIHN1Y2ggaW5mb3JtYXRpb24gYmUN CgkJCQkJcmVzdHJpY3RlZCB0byBwcm9wZXJseSBzZWN1cmVkIG5ldHdvcmtzLiA8L3Q+DQoJCQk8 L3NlY3Rpb24+DQoJCQkNCgkJCTxzZWN0aW9uIGFuY2hvcj0iU2VjUmVwbGF5IiB0aXRsZT0iUmVw bGF5aW5nIj4NCgkJCQk8dD4gTWVzc2FnZSBmb3JnZXJ5IGFuZCBvYnNlcnZhdGlvbiBjYW4gYmUg Y29tYmluZWQgaW50byBhIHJlcGxheSBhdHRhY2suIEFuDQoJCQkJCWF0dGFja2VyIGNvdWxkIHJl Y29yZCBhIHNldCBvZiBtZXNzYWdlcyB0aGF0IGluZGljYXRlIG5vcm1hbCBhY3Rpdml0eSBvZiBh DQoJCQkJCW1hY2hpbmUuIEF0IGEgbGF0ZXIgdGltZSwgYW4gYXR0YWNrZXIgY291bGQgcmVtb3Zl IHRoYXQgbWFjaGluZSBmcm9tIHRoZQ0KCQkJCQluZXR3b3JrIGFuZCByZXBsYXkgdGhlIHN5c2xv ZyBtZXNzYWdlcyB3aXRoIG5ldyB0aW1lIHN0YW1wcy4gVGhlDQoJCQkJCWFkbWluaXN0cmF0b3Jz IGNvdWxkIGZpbmQgbm90aGluZyB1bnVzdWFsIGluIHRoZSByZWNlaXZlZCBtZXNzYWdlcywgYW5k DQoJCQkJCXRoZWlyIHJlY2VpcHQgd291bGQgZmFsc2VseSBpbmRpY2F0ZSBub3JtYWwgYWN0aXZp dHkgb2YgdGhlIG1hY2hpbmUuDQoJCQkJCTwvdD4NCgkJCTwvc2VjdGlvbj4NCgkJCQ0KCQkJPHNl Y3Rpb24gYW5jaG9yPSJTZWNSZWxEZWwiIHRpdGxlPSJVbnJlbGlhYmxlIERlbGl2ZXJ5Ij4NCgkJ CQk8dD4gQXMgd2FzIHByZXZpb3VzbHkgZGlzY3Vzc2VkIGluIHRoZSBSZWxpYWJpbGl0eSBDb25z aWRlcmF0aW9ucw0KCQkJCQlzZWN0aW9uLCB0aGUgVURQIHRyYW5zcG9ydCBpcyBub3QgcmVsaWFi bGUsIGFuZCBwYWNrZXRzIGNvbnRhaW5pbmcNCgkJCQkJc3lzbG9nIG1lc3NhZ2UgZGF0YWdyYW1z IGNhbiBiZSBsb3N0IGluIHRyYW5zaXQgd2l0aG91dCBhbnkgbm90aWNlLg0KCQkJCQlUaGVyZSBj YW4gYmUgc2VjdXJpdHkgY29uc2VxdWVuY2VzIHRvIHRoZSBsb3NzIG9mIG9uZSBvciBtb3JlIHN5 c2xvZw0KCQkJCQltZXNzYWdlcy4gQWRtaW5pc3RyYXRvcnMgY291bGQgYmUgdW5hd2FyZSBvZiBh IGRldmVsb3BpbmcgYW5kDQoJCQkJCXBvdGVudGlhbGx5IHNlcmlvdXMgcHJvYmxlbS4gTWVzc2Fn ZXMgY291bGQgYWxzbyBiZSBpbnRlcmNlcHRlZCBhbmQNCgkJCQkJZGlzY2FyZGVkIGJ5IGFuIGF0 dGFja2VyIGFzIGEgd2F5IHRvIGhpZGUgdW5hdXRob3JpemVkIGFjdGl2aXRpZXMuIDwvdD4NCgkJ CTwvc2VjdGlvbj4NCgkJCQ0KCQkJPHNlY3Rpb24gYW5jaG9yPSJTZWNQcmkiDQoJCQkJdGl0bGU9 Ik1lc3NhZ2UgUHJpb3JpdGl6YXRpb24gYW5kIERpZmZlcmVudGlhdGlvbiI+DQoJCQkJPHQ+IFRo aXMgdHJhbnNwb3J0IG1hcHBpbmcgZG9lcyBub3QgbWFuZGF0ZSBwcmlvcml0aXphdGlvbiBvZiBz eXNsb2cNCgkJCQkJbWVzc2FnZXMgb24gdGhlIHdpcmUgb3Igd2hlbiBwcm9jZXNzZWQgb24gdGhl IHJlY2VpdmluZyBob3N0IGJhc2VkIG9uDQoJCQkJCXRoZWlyIHNldmVyaXR5LiBVbmxlc3Mgc29t ZSBwcmlvcml0aXphdGlvbiBpcyBpbXBsZW1lbnRlZCBieSBzZW5kZXIsIHJlY2VpdmVyIGFuZC9v ciBuZXR3b3JrLCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb24gb2Ygc3VjaCBiZWhhdmlvciBpcyB0 aGF0IHRoZQ0KCQkJCQlzeXNsb2cgcmVjZWl2ZXIgb3IgbmV0d29yayBkZXZpY2VzIGNvdWxkIGdl dCBvdmVyd2hlbG1lZCB3aXRoDQoJCQkJCWxvdy1zZXZlcml0eSBtZXNzYWdlcyBhbmQgYmUgZm9y Y2VkIHRvIGRpc2NhcmQgcG90ZW50aWFsbHkNCgkJCQkJaGlnaC1zZXZlcml0eSBtZXNzYWdlcy48 L3Q+DQoJCQk8L3NlY3Rpb24+DQoJCQkNCgkJCTxzZWN0aW9uIGFuY2hvcj0iU2VjRGVuIiB0aXRs ZT0iRGVuaWFsIG9mIFNlcnZpY2UiPg0KCQkJCTx0PiBBbiBhdHRhY2tlciBjb3VsZCBvdmVyd2hl bG0gYSByZWNlaXZlciBieSBzZW5kaW5nIG1vcmUgbWVzc2FnZXMgdG8gaXQgdGhhbg0KCQkJCQlj b3VsZCBiZSBoYW5kbGVkIGJ5IHRoZSBpbmZyYXN0cnVjdHVyZSBvciB0aGUgZGV2aWNlIGl0c2Vs Zi4NCgkJCQkJSW1wbGVtZW50ZXJzIFNIT1VMRCBhdHRlbXB0IHRvIHByb3ZpZGUgZmVhdHVyZXMg dGhhdCBtaW5pbWl6ZSB0aGlzDQoJCQkJCXRocmVhdCBzdWNoIGFzIG9wdGlvbmFsbHkgcmVzdHJp Y3RpbmcgcmVjZXB0aW9uIG9mIG1lc3NhZ2VzIHRvIGEgc2V0IG9mDQoJCQkJCWtub3cgc291cmNl IElQIGFkZHJlc3Nlcy4gPC90Pg0KCQkJPC9zZWN0aW9uPg0KCQk8L3NlY3Rpb24+DQoJCQ0KCQk8 c2VjdGlvbiBhbmNob3I9ImlhbmEiIHRpdGxlPSJJQU5BIENvbnNpZGVyYXRpb25zIj4NCgkJCTx0 PiBJQU5BIE1VU1QgcmVzZXJ2ZSBVRFAgcG9ydCA1MTQgZm9yIHRoaXMgdHJhbnNwb3J0LiA8L3Q+ DQoJCTwvc2VjdGlvbj4NCgkJDQoJCTxzZWN0aW9uIGFuY2hvcj0icmZjLWVkaXRvciIgdGl0bGU9 Ik5vdGljZSB0byBSRkMgRWRpdG9yIj4NCgkJCTx0PiBUaGlzIGlzIGEgbm90aWNlIHRvIHRoZSBS RkMgZWRpdG9yLiBUaGlzIElEIGlzIHN1Ym1pdHRlZCBhbG9uZyB3aXRoIElEDQoJCQkJZHJhZnQt aWV0Zi1zeXNsb2ctcHJvdG9jb2wgYW5kIHRoZXkgY3Jvc3MtcmVmZXJlbmNlIGVhY2ggb3RoZXIu IFdoZW4NCgkJCQlSRkMgbnVtYmVycyBhcmUgZGV0ZXJtaW5lZCBmb3IgZWFjaCBvZiB0aGVzZSBJ RHMsIHBsZWFzZSByZXBsYWNlIGFsbA0KCQkJCXJlZmVyZW5jZXMgdG8gIlJGQy1wcm90b2NvbCIg d2l0aCB0aGUgUkZDIG51bWJlciBvZg0KCQkJCWRyYWZ0LWlldGYtc3lzbG9nLXByb3RvY29sIElE LiBBbHNvLCBwbGVhc2UgdXBkYXRlIHRoZSBkYXRlIGluIHRoZQ0KCQkJCXNlY3Rpb24gcmVmZXJl bmNpbmcgdGhlIG5ldyBSRkMuIFBsZWFzZSByZW1vdmUgdGhpcyBzZWN0aW9uIGFmdGVyIGVkaXRp bmcuDQoJCQkJPC90Pg0KCQk8L3NlY3Rpb24+DQoJCQ0KCQk8c2VjdGlvbiBhbmNob3I9ImFja3Mi IHRpdGxlPSJBY2tub3dsZWRnZW1lbnRzIj4NCgkJCTx0PiBUaGUgYXV0aG9yIGdyYXRlZnVsbHkg YWNrbm93bGVkZ2VzIHRoZSBjb250cmlidXRpb25zIG9mOiBDaHJpcyBMb252aWNrLA0KCQkJCVJh aW5lciBHZXJoYXJkcywgRGF2aWQgSGFycmluZ3RvbiwgQW5kcmV3IFJvc3MsIEFsYmVydCBNaWV0 dXMsIEJlcm5pZQ0KCQkJCVZvbHosIE1pY2thZWwgR3JhaGFtLCBHcmVnIE1vcnJpcywgQWxleGFu ZHJhIEZlZG9yb3ZhLCBEZXZpbiBLb3dhdGNoLA0KCQkJCVJpY2hhcmQgR3JhdmVtYW4sIGFuZCBh bGwgb3RoZXJzIHdobyBoYXZlIGNvbW1lbnRlZCBvbiB0aGUgdmFyaW91cyB2ZXJzaW9ucw0KCQkJ CW9mIHRoaXMgcHJvcG9zYWwuIDwvdD4NCgkJPC9zZWN0aW9uPg0KCTwvbWlkZGxlPg0KCQ0KCTxi YWNrPg0KCQkNCgkJPHJlZmVyZW5jZXMgdGl0bGU9Ik5vcm1hdGl2ZSBSZWZlcmVuY2VzIj4NCgkJ CQ0KCQkJPHJlZmVyZW5jZSBhbmNob3I9J1JGQzIxMTknPg0KCQkJCQ0KCQkJCTxmcm9udD4NCgkJ CQkJPHRpdGxlIGFiYnJldj0nUkZDIEtleSBXb3Jkcyc+S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZD cyB0byBJbmRpY2F0ZQ0KCQkJCQkJUmVxdWlyZW1lbnQgTGV2ZWxzPC90aXRsZT4NCgkJCQkJPGF1 dGhvciBpbml0aWFscz0nUy4nIHN1cm5hbWU9J0JyYWRuZXInDQoJCQkJCQlmdWxsbmFtZT0nU2Nv dHQgQnJhZG5lcic+DQoJCQkJCQk8b3JnYW5pemF0aW9uPkhhcnZhcmQgVW5pdmVyc2l0eTwvb3Jn YW5pemF0aW9uPg0KCQkJCQkJPGFkZHJlc3M+DQoJCQkJCQkJPHBvc3RhbD4NCgkJCQkJCQkJPHN0 cmVldD4xMzUwIE1hc3MuIEF2ZS48L3N0cmVldD4NCgkJCQkJCQkJPHN0cmVldD5DYW1icmlkZ2U8 L3N0cmVldD4NCgkJCQkJCQkJPHN0cmVldD5NQSAwMjEzODwvc3RyZWV0Pg0KCQkJCQkJCTwvcG9z dGFsPg0KCQkJCQkJCTxwaG9uZT4tICsxIDYxNyA0OTUgMzg2NDwvcGhvbmU+DQoJCQkJCQkJPGVt YWlsPnNvYkBoYXJ2YXJkLmVkdTwvZW1haWw+DQoJCQkJCQk8L2FkZHJlc3M+DQoJCQkJCTwvYXV0 aG9yPg0KCQkJCQk8ZGF0ZSBtb250aD0nTWFyY2gnIHllYXI9JzE5OTcnLz4NCgkJCQkJPGFyZWE+ R2VuZXJhbDwvYXJlYT4NCgkJCQkJPGtleXdvcmQ+a2V5d29yZDwva2V5d29yZD4NCgkJCQk8L2Zy b250Pg0KCQkJCTxzZXJpZXNJbmZvIG5hbWU9J0JDUCcgdmFsdWU9JzE0Jy8+DQoJCQkJPHNlcmll c0luZm8gbmFtZT0nUkZDJyB2YWx1ZT0nMjExOScvPg0KCQkJCTxmb3JtYXQgdHlwZT0nSFRNTCcg b2N0ZXRzPScxNDQ4NicNCgkJCQkJdGFyZ2V0PSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJs aWMvcmZjL2h0bWwvcmZjMjExOS5odG1sJy8+DQoJCQkJPGZvcm1hdCB0eXBlPSdYTUwnIG9jdGV0 cz0nNTY2MScNCgkJCQkJdGFyZ2V0PSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZj L3htbC9yZmMyMTE5LnhtbCcvPg0KCQkJPC9yZWZlcmVuY2U+DQoJCQkNCgkJCTxyZWZlcmVuY2Ug YW5jaG9yPSdSRkMtcHJvdG9jb2wnPg0KCQkJCTxmcm9udD4NCgkJCQkJPHRpdGxlPlRoZSBzeXNs b2cgUHJvdG9jb2w8L3RpdGxlPg0KCQkJCQk8YXV0aG9yIGluaXRpYWxzPSdSLicgc3VybmFtZT0n R2VyaGFyZHMnDQoJCQkJCQlmdWxsbmFtZT0nUi4gR2VyaGFyZHMnPg0KCQkJCQkJPG9yZ2FuaXph dGlvbj5uL2E8L29yZ2FuaXphdGlvbj4NCgkJCQkJPC9hdXRob3I+DQoJCQkJCTxkYXRlIG1vbnRo PSdKYW51YXJ5JyBkYXk9JzEnIHllYXI9JzIwMDcnLz4NCgkJCQk8L2Zyb250Pg0KCQkJCTxzZXJp ZXNJbmZvIG5hbWU9J1JGQycgdmFsdWU9J1JGQy1wcm90b2NvbCcvPg0KCQkJCTxmb3JtYXQgdHlw ZT0nVFhUJyBvY3RldHM9JzcyOTUxJw0KCQkJCQl0YXJnZXQ9J2Z0cDovL2Z0cC5pc2kuZWR1L2lu LW5vdGVzL3JmYy1wcm90b2NvbC50eHQnLz4NCgkJCTwvcmVmZXJlbmNlPg0KCQkJDQoJCQk8cmVm ZXJlbmNlIGFuY2hvcj0nUkZDMDc2OCc+DQoJCQkJPGZyb250Pg0KCQkJCQk8dGl0bGU+VXNlciBE YXRhZ3JhbSBQcm90b2NvbDwvdGl0bGU+DQoJCQkJCTxhdXRob3IgaW5pdGlhbHM9J0ouJyBzdXJu YW1lPSdQb3N0ZWwnIGZ1bGxuYW1lPSdKLiBQb3N0ZWwnPg0KCQkJCQkJPG9yZ2FuaXphdGlvbj5V bml2ZXJzaXR5IG9mIFNvdXRoZXJuIENhbGlmb3JuaWENCgkJCQkJCQkoVVNDKS9JbmZvcm1hdGlv biBTY2llbmNlcyBJbnN0aXR1dGU8L29yZ2FuaXphdGlvbj4NCgkJCQkJCTxhZGRyZXNzPg0KCQkJ CQkJCTxwb3N0YWw+DQoJCQkJCQkJCTxzdHJlZXQ+NDY3NiBBZG1pcmFsdHkgV2F5PC9zdHJlZXQ+ DQoJCQkJCQkJCTxjaXR5Pk1hcmluYSBkZWwgUmV5PC9jaXR5Pg0KCQkJCQkJCQk8cmVnaW9uPkNB PC9yZWdpb24+DQoJCQkJCQkJCTxjb2RlPjkwMjkxPC9jb2RlPg0KCQkJCQkJCQk8Y291bnRyeT5V UzwvY291bnRyeT4NCgkJCQkJCQk8L3Bvc3RhbD4NCgkJCQkJCQk8cGhvbmU+KzEgMjEzIDgyMiAx NTExPC9waG9uZT4NCgkJCQkJCTwvYWRkcmVzcz4NCgkJCQkJPC9hdXRob3I+DQoJCQkJCTxkYXRl IG1vbnRoPSdBdWd1c3QnIGRheT0nMjgnIHllYXI9JzE5ODAnLz4NCgkJCQk8L2Zyb250Pg0KCQkJ CTxzZXJpZXNJbmZvIG5hbWU9J1NURCcgdmFsdWU9JzYnLz4NCgkJCQk8c2VyaWVzSW5mbyBuYW1l PSdSRkMnIHZhbHVlPSc3NjgnLz4NCgkJCTwvcmVmZXJlbmNlPg0KCQkJDQoJCQk8cmVmZXJlbmNl IGFuY2hvcj0nUkZDMDc5MSc+DQoJCQkJPGZyb250Pg0KCQkJCQk8dGl0bGUgYWJicmV2PSdJbnRl cm5ldCBQcm90b2NvbCc+SW50ZXJuZXQgUHJvdG9jb2w8L3RpdGxlPg0KCQkJCQk8YXV0aG9yIGlu aXRpYWxzPSdKLicgc3VybmFtZT0nUG9zdGVsJyBmdWxsbmFtZT0nSm9uIFBvc3RlbCc+DQoJCQkJ CQk8b3JnYW5pemF0aW9uPlVuaXZlcnNpdHkgb2YgU291dGhlcm4gQ2FsaWZvcm5pYQ0KCQkJCQkJ CShVU0MpL0luZm9ybWF0aW9uIFNjaWVuY2VzIEluc3RpdHV0ZTwvb3JnYW5pemF0aW9uPg0KCQkJ CQkJPGFkZHJlc3M+DQoJCQkJCQkJPHBvc3RhbD4NCgkJCQkJCQkJPHN0cmVldD40Njc2IEFkbWly YWx0eSBXYXk8L3N0cmVldD4NCgkJCQkJCQkJPGNpdHk+TWFyaW5hIGRlbCBSZXk8L2NpdHk+DQoJ CQkJCQkJCTxyZWdpb24+Q0E8L3JlZ2lvbj4NCgkJCQkJCQkJPGNvZGU+OTAyOTE8L2NvZGU+DQoJ CQkJCQkJCTxjb3VudHJ5PlVTPC9jb3VudHJ5Pg0KCQkJCQkJCTwvcG9zdGFsPg0KCQkJCQkJPC9h ZGRyZXNzPg0KCQkJCQk8L2F1dGhvcj4NCgkJCQkJPGRhdGUgbW9udGg9J1NlcHRlbWJlcicgZGF5 PScxJyB5ZWFyPScxOTgxJy8+DQoJCQkJPC9mcm9udD4NCgkJCQk8c2VyaWVzSW5mbyBuYW1lPSdT VEQnIHZhbHVlPSc1Jy8+DQoJCQkJPHNlcmllc0luZm8gbmFtZT0nUkZDJyB2YWx1ZT0nNzkxJy8+ DQoJCQk8L3JlZmVyZW5jZT4NCgkJCQ0KCQkJPHJlZmVyZW5jZSBhbmNob3I9J1JGQzI0NjAnPg0K CQkJCTxmcm9udD4NCgkJCQkJPHRpdGxlIGFiYnJldj0nSVB2NiBTcGVjaWZpY2F0aW9uJz5JbnRl cm5ldCBQcm90b2NvbCwgVmVyc2lvbiA2DQoJCQkJCQkoSVB2NikgU3BlY2lmaWNhdGlvbjwvdGl0 bGU+DQoJCQkJCTxhdXRob3IgaW5pdGlhbHM9J1MuRS4nIHN1cm5hbWU9J0RlZXJpbmcnDQoJCQkJ CQlmdWxsbmFtZT0nU3RlcGhlbiBFLiBEZWVyaW5nJz4NCgkJCQkJCTxvcmdhbml6YXRpb24+Q2lz Y28gU3lzdGVtcywgSW5jLjwvb3JnYW5pemF0aW9uPg0KCQkJCQkJPGFkZHJlc3M+DQoJCQkJCQkJ PHBvc3RhbD4NCgkJCQkJCQkJPHN0cmVldD4xNzAgV2VzdCBUYXNtYW4gRHJpdmU8L3N0cmVldD4N CgkJCQkJCQkJPHN0cmVldD5TYW4gSm9zZTwvc3RyZWV0Pg0KCQkJCQkJCQk8cmVnaW9uPkNBPC9y ZWdpb24+DQoJCQkJCQkJCTxjb2RlPjk1MTM0LTE3MDY8L2NvZGU+DQoJCQkJCQkJCTxjb3VudHJ5 PlVTQTwvY291bnRyeT4NCgkJCQkJCQk8L3Bvc3RhbD4NCgkJCQkJCQk8cGhvbmU+KzEgNDA4IDUy NyA4MjEzPC9waG9uZT4NCgkJCQkJCQk8ZmFjc2ltaWxlPisxIDQwOCA1MjcgODI1NDwvZmFjc2lt aWxlPg0KCQkJCQkJCTxlbWFpbD5kZWVyaW5nQGNpc2NvLmNvbTwvZW1haWw+DQoJCQkJCQk8L2Fk ZHJlc3M+DQoJCQkJCTwvYXV0aG9yPg0KCQkJCQk8YXV0aG9yIGluaXRpYWxzPSdSLk0uJyBzdXJu YW1lPSdIaW5kZW4nDQoJCQkJCQlmdWxsbmFtZT0nUm9iZXJ0IE0uIEhpbmRlbic+DQoJCQkJCQk8 b3JnYW5pemF0aW9uPk5va2lhPC9vcmdhbml6YXRpb24+DQoJCQkJCQk8YWRkcmVzcz4NCgkJCQkJ CQk8cG9zdGFsPg0KCQkJCQkJCQk8c3RyZWV0PjIzMiBKYXZhIERyaXZlPC9zdHJlZXQ+DQoJCQkJ CQkJCTxzdHJlZXQ+U3Vubnl2YWxlPC9zdHJlZXQ+DQoJCQkJCQkJCTxyZWdpb24+Q0E8L3JlZ2lv bj4NCgkJCQkJCQkJPGNvZGU+OTQwODk8L2NvZGU+DQoJCQkJCQkJCTxjb3VudHJ5PlVTQTwvY291 bnRyeT4NCgkJCQkJCQk8L3Bvc3RhbD4NCgkJCQkJCQk8cGhvbmU+KzEgNDA4IDk5MCAyMDA0PC9w aG9uZT4NCgkJCQkJCQk8ZmFjc2ltaWxlPisxIDQwOCA3NDMgNTY3NzwvZmFjc2ltaWxlPg0KCQkJ CQkJCTxlbWFpbD5oaW5kZW5AaXByZy5ub2tpYS5jb208L2VtYWlsPg0KCQkJCQkJPC9hZGRyZXNz Pg0KCQkJCQk8L2F1dGhvcj4NCgkJCQkJPGRhdGUgbW9udGg9J0RlY2VtYmVyJyB5ZWFyPScxOTk4 Jy8+DQoJCQkJCTxhcmVhPkludGVybmV0PC9hcmVhPg0KCQkJCQk8a2V5d29yZD5pbnRlcm5ldCBw cm90b2NvbCB2ZXJzaW9uIDY8L2tleXdvcmQ+DQoJCQkJCTxrZXl3b3JkPklQdjY8L2tleXdvcmQ+ DQoJCQkJCTxhYnN0cmFjdD4NCgkJCQkJCTx0PiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB2ZXJz aW9uIDYgb2YgdGhlIEludGVybmV0IFByb3RvY29sDQoJCQkJCQkJKElQdjYpLCBhbHNvIHNvbWV0 aW1lcyByZWZlcnJlZCB0byBhcyBJUCBOZXh0IEdlbmVyYXRpb24gb3INCgkJCQkJCQlJUG5nLiA8 L3Q+DQoJCQkJCTwvYWJzdHJhY3Q+DQoJCQkJPC9mcm9udD4NCgkJCQk8c2VyaWVzSW5mbyBuYW1l PSdSRkMnIHZhbHVlPScyNDYwJy8+DQoJCQkJPGZvcm1hdCB0eXBlPSdIVE1MJyBvY3RldHM9Jzk5 NDk2Jw0KCQkJCQl0YXJnZXQ9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvaHRt bC9yZmMyNDYwLmh0bWwnLz4NCgkJCQk8Zm9ybWF0IHR5cGU9J1hNTCcgb2N0ZXRzPSc5MzM0MycN CgkJCQkJdGFyZ2V0PSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL3htbC9yZmMy NDYwLnhtbCcvPg0KCQkJPC9yZWZlcmVuY2U+DQoJCQkNCgkJPC9yZWZlcmVuY2VzPg0KCQkNCgkJ PHJlZmVyZW5jZXMgdGl0bGU9IkluZm9ybWF0aXZlIFJlZmVyZW5jZXMiPg0KCQkJDQoJCQk8cmVm ZXJlbmNlIGFuY2hvcj0nUkZDMzE2NCc+DQoJCQkJPGZyb250Pg0KCQkJCQk8dGl0bGU+VGhlIEJT RCBTeXNsb2cgUHJvdG9jb2w8L3RpdGxlPg0KCQkJCQk8YXV0aG9yIGluaXRpYWxzPSdDLicgc3Vy bmFtZT0nTG9udmljaycgZnVsbG5hbWU9J0MuIExvbnZpY2snPg0KCQkJCQkJPG9yZ2FuaXphdGlv bi8+DQoJCQkJCTwvYXV0aG9yPg0KCQkJCQk8ZGF0ZSBtb250aD0nQXVndXN0JyB5ZWFyPScyMDAx Jy8+DQoJCQkJPC9mcm9udD4NCgkJCQk8c2VyaWVzSW5mbyBuYW1lPSdSRkMnIHZhbHVlPSczMTY0 Jy8+DQoJCQkJPGZvcm1hdCB0eXBlPSdUWFQnIG9jdGV0cz0nNzI5NTEnDQoJCQkJCXRhcmdldD0n ZnRwOi8vZnRwLmlzaS5lZHUvaW4tbm90ZXMvcmZjMzE2NC50eHQnLz4NCgkJCTwvcmVmZXJlbmNl Pg0KCQkJDQoJCQk8cmVmZXJlbmNlIGFuY2hvcj0nUkZDMTE5MSc+DQoJCQkJDQoJCQkJPGZyb250 Pg0KCQkJCQk8dGl0bGU+UGF0aCBNVFUgZGlzY292ZXJ5PC90aXRsZT4NCgkJCQkJPGF1dGhvciBp bml0aWFscz0nSi4nIHN1cm5hbWU9J01vZ3VsJyBmdWxsbmFtZT0nSmVmZnJleSBNb2d1bCc+DQoJ CQkJCQk8b3JnYW5pemF0aW9uPkRpZ2l0YWwgRXF1aXBtZW50IENvcnBvcmF0aW9uIChERUMpICwg V2VzdGVybg0KCQkJCQkJCVJlc2VhcmNoIExhYm9yYXRvcnk8L29yZ2FuaXphdGlvbj4NCgkJCQkJ CTxhZGRyZXNzPg0KCQkJCQkJCTxwb3N0YWw+DQoJCQkJCQkJCTxzdHJlZXQ+MTAwIEhhbWlsdG9u IEF2ZW51ZTwvc3RyZWV0Pg0KCQkJCQkJCQk8Y2l0eT5QYWxvIEFsdG88L2NpdHk+DQoJCQkJCQkJ CTxyZWdpb24+Q0E8L3JlZ2lvbj4NCgkJCQkJCQkJPGNvZGU+OTQzMDE8L2NvZGU+DQoJCQkJCQkJ CTxjb3VudHJ5PlVTPC9jb3VudHJ5Pg0KCQkJCQkJCTwvcG9zdGFsPg0KCQkJCQkJCTxwaG9uZT4r MSA0MTUgODUzIDY2NDM8L3Bob25lPg0KCQkJCQkJCTxlbWFpbD5tb2d1bEBkZWN3cmwuZGVjLmNv bTwvZW1haWw+DQoJCQkJCQk8L2FkZHJlc3M+DQoJCQkJCTwvYXV0aG9yPg0KCQkJCQk8YXV0aG9y IGluaXRpYWxzPSdTLicgc3VybmFtZT0nRGVlcmluZycNCgkJCQkJCWZ1bGxuYW1lPSdTdGV2ZSBE ZWVyaW5nJz4NCgkJCQkJCTxvcmdhbml6YXRpb24+WGVyb3ggUGFsbyBBbHRvIFJlc2VhcmNoIENl bnRlcjwvb3JnYW5pemF0aW9uPg0KCQkJCQkJPGFkZHJlc3M+DQoJCQkJCQkJPHBvc3RhbD4NCgkJ CQkJCQkJPHN0cmVldD4zMzMzIENveW90ZSBIaWxsIFJvYWQ8L3N0cmVldD4NCgkJCQkJCQkJPGNp dHk+UGFsbyBBbHRvPC9jaXR5Pg0KCQkJCQkJCQk8cmVnaW9uPkNBPC9yZWdpb24+DQoJCQkJCQkJ CTxjb2RlPjk0MzA0PC9jb2RlPg0KCQkJCQkJCQk8Y291bnRyeT5VUzwvY291bnRyeT4NCgkJCQkJ CQk8L3Bvc3RhbD4NCgkJCQkJCQk8cGhvbmU+KzEgNDE1IDQ5NCA0ODM5PC9waG9uZT4NCgkJCQkJ CQk8ZW1haWw+ZGVlcmluZ0B4ZXJveC5jb208L2VtYWlsPg0KCQkJCQkJPC9hZGRyZXNzPg0KCQkJ CQk8L2F1dGhvcj4NCgkJCQkJPGRhdGUgeWVhcj0nMTk5MCcgZGF5PScxJyBtb250aD0nTm92ZW1i ZXInLz4NCgkJCQkJPGFic3RyYWN0Pg0KCQkJCQkJPHQ+VGhpcyBtZW1vIGRlc2NyaWJlcyBhIHRl Y2huaXF1ZSBmb3IgZHluYW1pY2FsbHkgZGlzY292ZXJpbmcNCgkJCQkJCQl0aGUgbWF4aW11bSB0 cmFuc21pc3Npb24gdW5pdCAoTVRVKSBvZiBhbiBhcmJpdHJhcnkgaW50ZXJuZXQNCgkJCQkJCQlw YXRoLiBJdCBzcGVjaWZpZXMgYSBzbWFsbCBjaGFuZ2UgdG8gdGhlIHdheSByb3V0ZXJzIGdlbmVy YXRlDQoJCQkJCQkJb25lIHR5cGUgb2YgSUNNUCBtZXNzYWdlLiBGb3IgYSBwYXRoIHRoYXQgcGFz c2VzIHRocm91Z2ggYQ0KCQkJCQkJCXJvdXRlciB0aGF0IGhhcyBub3QgYmVlbiBzbyBjaGFuZ2Vk LCB0aGlzIHRlY2huaXF1ZSBtaWdodCBub3QNCgkJCQkJCQlkaXNjb3ZlciB0aGUgY29ycmVjdCBQ YXRoIE1UVSwgYnV0IGl0IHdpbGwgYWx3YXlzIGNob29zZSBhIFBhdGgNCgkJCQkJCQlNVFUgYXMg YWNjdXJhdGUgYXMsIGFuZCBpbiBtYW55IGNhc2VzIG1vcmUgYWNjdXJhdGUgdGhhbiwgdGhlDQoJ CQkJCQkJUGF0aCBNVFUgdGhhdCB3b3VsZCBiZSBjaG9zZW4gYnkgY3VycmVudCBwcmFjdGljZS48 L3Q+DQoJCQkJCTwvYWJzdHJhY3Q+DQoJCQkJPC9mcm9udD4NCgkJCQkNCgkJCQk8c2VyaWVzSW5m byBuYW1lPSdSRkMnIHZhbHVlPScxMTkxJy8+DQoJCQkJPGZvcm1hdCB0eXBlPSdUWFQnIG9jdGV0 cz0nNDc5MzYnDQoJCQkJCXRhcmdldD0nZnRwOi8vZnRwLmlzaS5lZHUvaW4tbm90ZXMvcmZjMTE5 MS50eHQnLz4NCgkJCTwvcmVmZXJlbmNlPg0KCQkJDQoJCQk8cmVmZXJlbmNlIGFuY2hvcj0nUkZD NDMwMSc+DQoJCQkJDQoJCQkJPGZyb250Pg0KCQkJCQk8dGl0bGU+U2VjdXJpdHkgQXJjaGl0ZWN0 dXJlIGZvciB0aGUgSW50ZXJuZXQgUHJvdG9jb2w8L3RpdGxlPg0KCQkJCQk8YXV0aG9yIGluaXRp YWxzPSdTLicgc3VybmFtZT0nS2VudCcgZnVsbG5hbWU9J1MuIEtlbnQnPg0KCQkJCQkJPG9yZ2Fu aXphdGlvbi8+DQoJCQkJCTwvYXV0aG9yPg0KCQkJCQk8YXV0aG9yIGluaXRpYWxzPSdLLicgc3Vy bmFtZT0nU2VvJyBmdWxsbmFtZT0nSy4gU2VvJz4NCgkJCQkJCTxvcmdhbml6YXRpb24vPg0KCQkJ CQk8L2F1dGhvcj4NCgkJCQkJPGRhdGUgeWVhcj0nMjAwNScgbW9udGg9J0RlY2VtYmVyJy8+DQoJ CQkJPC9mcm9udD4NCgkJCQkNCgkJCQk8c2VyaWVzSW5mbyBuYW1lPSdSRkMnIHZhbHVlPSc0MzAx Jy8+DQoJCQkJPGZvcm1hdCB0eXBlPSdUWFQnIG9jdGV0cz0nMjYyMTIzJw0KCQkJCQl0YXJnZXQ9 J2Z0cDovL2Z0cC5pc2kuZWR1L2luLW5vdGVzL3JmYzQzMDEudHh0Jy8+DQoJCQk8L3JlZmVyZW5j ZT4NCgkJCQ0KCQkJPHJlZmVyZW5jZSBhbmNob3I9J1N0ZXZlbnMnPg0KCQkJCTxmcm9udD4NCgkJ CQkJPHRpdGxlPlRDUC9JUCBJbGx1c3RyYXRlZCBWb2x1bWUgMS4gVGhlIFByb3RvY29scy48L3Rp dGxlPg0KCQkJCQk8YXV0aG9yIGluaXRpYWxzPSdXLlIuJyBzdXJuYW1lPSdTdGV2ZW5zJw0KCQkJ CQkJZnVsbG5hbWU9J1cuIFJpY2hhcmQgU3RldmVucyc+DQoJCQkJCQk8b3JnYW5pemF0aW9uPkFk ZGlzb24gV2VzbGV5PC9vcmdhbml6YXRpb24+DQoJCQkJCTwvYXV0aG9yPg0KCQkJCQk8ZGF0ZSBt b250aD0nSmFudWFyeScgeWVhcj0nMTk5NCcvPg0KCQkJCTwvZnJvbnQ+DQoJCQk8L3JlZmVyZW5j ZT4NCgkJCQ0KCQk8L3JlZmVyZW5jZXM+DQoJCQ0KCTwvYmFjaz4NCjwvcmZjPg== ------_=_NextPart_001_01C6CD79.92D1103D Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ------_=_NextPart_001_01C6CD79.92D1103D-- From syslog-bounces@lists.ietf.org Mon Sep 04 04:51:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKA8t-0007Pf-My; Mon, 04 Sep 2006 04:49:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKA8s-0007Ma-8H for syslog@ietf.org; Mon, 04 Sep 2006 04:49:18 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKA8q-0007D7-Jw for syslog@ietf.org; Mon, 04 Sep 2006 04:49:18 -0400 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k848mxm9007307 for ; Mon, 4 Sep 2006 17:48:59 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k848mr5x021936 for ; Mon, 4 Sep 2006 17:48:59 +0900 (JST) Message-ID: <44FBE875.6040600@cysols.com> Date: Mon, 04 Sep 2006 17:48:53 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Working Group Last Calls References: <132101c6cad0$ab256200$0400a8c0@china.huawei.com> In-Reply-To: <132101c6cad0$ab256200$0400a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Sincere apologies for the delay in sending the following comments on the Syslog Protocol document. I faced problems with these while trying to align the mib document with the protocol document In section 6.2.1 a. The concept of Facility in the syslog protocol context should be explained b. In Table 1 references are made to "note 1" and "note 2" these notes do not exist in the document c. In Table 1 Facility 9,15 both denote the clock daemon Facility 4,14 both denote security/authorization messages I think that a,b are editorial matters while c is WG matter. Cheers Glenn David Harrington wrote: > Hi, > > The WGLC for -protocol-17 and -udp-07 documents will end later today. > Please review and comment on these documents today. > > 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 From syslog-bounces@lists.ietf.org Mon Sep 04 05:42:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKAxn-0000Kd-IA; Mon, 04 Sep 2006 05:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKAxm-0000Iq-Bh for syslog@ietf.org; Mon, 04 Sep 2006 05:41:54 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKAr9-0005PE-KL for syslog@ietf.org; Mon, 04 Sep 2006 05:35:05 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5200JZEAUV3J@szxga03-in.huawei.com> for syslog@ietf.org; Mon, 04 Sep 2006 17:40:07 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5200BRNAUUT9@szxga03-in.huawei.com> for syslog@ietf.org; Mon, 04 Sep 2006 17:40:07 +0800 (CST) Received: from m19684 ([10.111.12.92]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5200ELVAKCSO@szxml03-in.huawei.com> for syslog@ietf.org; Mon, 04 Sep 2006 17:33:51 +0800 (CST) Date: Mon, 04 Sep 2006 17:29:39 +0800 From: Miao Fuyou Subject: RE: [Syslog] Working Group Last Call: syslog-tls document In-reply-to: <14ed01c6cbb4$c17526f0$0400a8c0@china.huawei.com> To: syslog@ietf.org Message-id: <004c01c6d004$a51a5210$5c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iACkS6mUAA1NbhgARQI8uA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, One "major" change to the document is a "version" field for Syslog TLS transport is added to the frame header. The field is to make port reusing possible if the transport mapping document is updated in the future. An IANA paragraph is added accordingly. Another change is about frame length bounding, Min-max values(MUST, SHOULD) are added to the document. The two changed was made after discussion between editors and chairs. Discussion and feedback is welcome! Thanks! Miao > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, August 30, 2006 5:48 AM > To: syslog@ietf.org > Subject: [Syslog] Working Group Last Call: syslog-tls document > > > Hi, > > This message officially starts the Syslog Working Group Last > Call for the following document: > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 > .txt > > The Working Group Last Call for this document will end September 12. > > To help get these document reviewed throughly, we are seeking > volunteers to review the documents for the following special reviews: > 1) Spelling and grammar, > 2) boilerplates and reference review, > 3) security review > > The chairs want to see a minimum number of content reviews > before we submit the documents to the IESG. If you review the > document and it looks fine, please post a statement that you > have reviewed and found the document acceptable. Obviously, > if it does not look acceptable please identify your > objections, preferably with suggested text that would make it > acceptable. > > Thanks, > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > > > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Mon Sep 04 18:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKNFp-0007NB-Qx; Mon, 04 Sep 2006 18:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKNFp-0007N6-8V for syslog@ietf.org; Mon, 04 Sep 2006 18:49:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKNFn-0005U3-T4 for syslog@ietf.org; Mon, 04 Sep 2006 18:49:21 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Sep 2006 15:49:19 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k84MnJpv003985 for ; Mon, 4 Sep 2006 15:49:19 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k84MnJQW009597 for ; Mon, 4 Sep 2006 15:49:19 -0700 (PDT) Date: Mon, 4 Sep 2006 15:49:18 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Subject: version field in syslog-tls - was: RE: [Syslog] Working Group Last Call: syslog-tls document In-Reply-To: <004c01c6d004$a51a5210$5c0c6f0a@china.huawei.com> Message-ID: References: <004c01c6d004$a51a5210$5c0c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=2810; t=1157410159; x=1158274159; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:version=20field=20in=20syslog-tls=20-=20was=3A=20RE=3A=20[Syslog]=20Work ing=20Group=20Last=0A=20Call=3A=20syslog-tls=20document; X=v=3Dcisco.com=3B=20h=3DgbcYAwB1CUp+ckKsfd2Ec/tuVJ0=3D; b=JNZfM2qZZYPb1ukkVItd/MlIlVAAOG0D6MNWEllRv6WqPwxBOhO4O8aZddqigpA2ClrRL4wh 7w5hDqyG2LlafZMhoI3cfP8lHYAh2C85525WFsaP70iG88ZPG1v8tuKg; Authentication-Results: sj-dkim-2.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi All, Please do consider the version field. If we don't have one, we would have to live forever with the decisions we are making now. Having a version number in there would allow a future group to re-decide things (like byte-count v. special character) and to just change the version number rather than go asking for a new port number - or have a flag day. Please review the document and send in your thoughts on this. Thanks, Chris On Mon, 4 Sep 2006, Miao Fuyou wrote: > > Hi, > > One "major" change to the document is a "version" field for Syslog TLS > transport is added to the frame header. The field is to make port reusing > possible if the transport mapping document is updated in the future. An IANA > paragraph is added accordingly. > > Another change is about frame length bounding, Min-max values(MUST, SHOULD) > are added to the document. > > The two changed was made after discussion between editors and chairs. > Discussion and feedback is welcome! > > Thanks! > Miao > >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Wednesday, August 30, 2006 5:48 AM >> To: syslog@ietf.org >> Subject: [Syslog] Working Group Last Call: syslog-tls document >> >> >> Hi, >> >> This message officially starts the Syslog Working Group Last >> Call for the following document: >> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 >> .txt >> >> The Working Group Last Call for this document will end September 12. >> >> To help get these document reviewed throughly, we are seeking >> volunteers to review the documents for the following special reviews: >> 1) Spelling and grammar, >> 2) boilerplates and reference review, >> 3) security review >> >> The chairs want to see a minimum number of content reviews >> before we submit the documents to the IESG. If you review the >> document and it looks fine, please post a statement that you >> have reviewed and found the document acceptable. Obviously, >> if it does not look acceptable please identify your >> objections, preferably with suggested text that would make it >> acceptable. >> >> Thanks, >> David Harrington >> dharrington@huawei.com >> dbharrington@comcast.net >> ietfdbh@comcast.net >> co-chair, Syslog WG >> >> >> >> _______________________________________________ >> 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 From syslog-bounces@lists.ietf.org Mon Sep 04 20:57:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKPDg-00065T-6a; Mon, 04 Sep 2006 20:55:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKPDf-00065O-Hh for syslog@ietf.org; Mon, 04 Sep 2006 20:55:15 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKPDe-00063n-4H for syslog@ietf.org; Mon, 04 Sep 2006 20:55:15 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 879DB27C067; Tue, 5 Sep 2006 02:47:46 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14346-09; Tue, 5 Sep 2006 02:47:46 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 4988F27C061; Tue, 5 Sep 2006 02:47:46 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 02:55:07 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] WGLC: protocol, part 2 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Sep 2006 02:55:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174E73@grfint2.intern.adiscon.com> In-Reply-To: <136e01c6cafd$ec33eb40$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] WGLC: protocol, part 2 Thread-Index: AcbK/VCn78UvyZWPQhuvj8fLV8mTZQFgu/VA From: "Rainer Gerhards" To: "David Harrington" X-OriginalArrivalTime: 05 Sep 2006 00:55:07.0297 (UTC) FILETIME=[EE3EF910:01C6D085] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Just one quick comment, at least this one gets on list (I'll send a more thourough message after edit) > In 6.5 example 1, aren't these contrsdictory statements - "The > encoding is defined by the BOM, and also advertised in > STRUCTURED-DATA. There is no STRUCTURED-DATA present in the message, > this is indicated by "-" in the STRUCTURED-DATA field." So should this > read ""and MAY be advertised" >=20 > 7.3.3 Let's see. If BOM and enc are both specified, believe the BOM. > If BOM is not present and enc=3DUTF8 is present, then you should make = no > assumptions about the encoding. If the BOM is not present and the > encoding is not UTF8 then enc MUST NOT be specified. So when is this > field actually useful? Why have it if the value of the field is always > either duplicative or not-to-be-trusted? Let's either make it useful > when the BOM is not specified and/or when the encoding is not UTF8, or > let's eliminate it. I disliked the enc SD-PARAM ever since it is there. However, it was WG consensus to include it. I opted for just the BOM and would still prefer that.=20 > Section 8.2 specifies why it is a security risk to send control > characters in the MSG or PARAM-VALUE content. We should simply say, if > you want to be a standard-compliant implementation, you MUST NOT send > control characters in these fields. Period. Strip them out and add a > section to your release notes tahat explains this decision was made by > the IETF for security reasons. That was a veeeeery long discussion around one or two years ago. The bottom line was that we can not know which UTF-8 sequence is a control character - there may even be new ones defined in the future. An implementation is unlikely to know each of them. There were a lot of arguments that we should support any character inside these fields (please refer to list archive). I still back this. If we go back and change *that* decision, we must also reconsider the octet-counting decision for -tls. The reason is that if we would outrule control characters in -protocol, there would be no valid reason at all to not use LF as a stream separator. David Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Sep 04 20:57:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKPDi-00065d-Bb; Mon, 04 Sep 2006 20:55:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKPDh-00065Y-DP for syslog@ietf.org; Mon, 04 Sep 2006 20:55:17 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKPDf-00063k-W1 for syslog@ietf.org; Mon, 04 Sep 2006 20:55:17 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 93D3127C065; Tue, 5 Sep 2006 02:47:43 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14346-08; Tue, 5 Sep 2006 02:47:43 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 57AC727C061; Tue, 5 Sep 2006 02:47:43 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 02:55:04 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog] WG timeline update - again MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Sep 2006 02:55:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174E70@grfint2.intern.adiscon.com> In-Reply-To: <14ef01c6cbb5$7d530630$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] WG timeline update - again Thread-Index: AcbLB6M5QH3V/DkJTzuccOKfI+PU0QAfxYHgAAtaOrABMtR2AA== From: "Rainer Gerhards" To: "David Harrington" , X-OriginalArrivalTime: 05 Sep 2006 00:55:04.0546 (UTC) FILETIME=[EC9B3420:01C6D085] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi David, I'd got no connectivity the past days. Further, I am now on vacation. I will try to work on -protocol, but I can not promise to do so before I am back to office (Sept, 18th). Honestly, my top priority currently is to keep my family happy. I hope you understand. For the very same reason, I will probably be unable to comment on the other documents. I hope you understand. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Tuesday, August 29, 2006 5:53 PM > To: syslog@ietf.org > Subject: [Syslog] WG timeline update - again >=20 > =20 > Hi, >=20 > In the original timeline, we planned to start the WGLC for syslog-tls > on Aug 28, but we didn't have an updated document to work with. Now a > revision has been published, so we'll start the WGLC now. >=20 > Here is another update to the timeline >=20 > Aug 28 Close WGLC on protocol and udp > Aug 28 start WGLC on syslog-sign > Aug 29 tls drafts published with requested changes (before WGLC) > Aug 29 start WGLC on syslog-tls > Sep 1 mib draftspublished with requested changes (before WGLC) > Sep 4 start WGLC on mib draft > Sep 11 Close WGLC on syslog-sign > Sep 11 revisions of protocol and udp drafts (after WGLC) > Sep 12 Close WGLC on syslog-tls document > Sep 18 Close WGLC for mib > Sep 25 revisions of sign, tls, mib > Sep 25 start final WGLC on all modified documents if needed. > Oct 9 end final WGLCs > Oct 20 submit all final-WGLC-modified drafts to internet-drafts > Oct 23 publication cut-off preceding IETF67 > Nov 1 submit documents to the IESG. >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Sep 04 21:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKPQl-0005YO-27; Mon, 04 Sep 2006 21:08:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKPQj-0005U9-6y for syslog@ietf.org; Mon, 04 Sep 2006 21:08:45 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKPQh-0007yh-NK for syslog@ietf.org; Mon, 04 Sep 2006 21:08:45 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id A9AF227C065; Tue, 5 Sep 2006 03:01:21 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17568-01; Tue, 5 Sep 2006 03:01:21 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 42F7E27C061; Tue, 5 Sep 2006 03:01:21 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Sep 2006 03:08:41 +0200 Content-class: urn:content-classes:message Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working Group LastCall: syslog-tls document MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Sep 2006 03:08:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174E74@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: version field in syslog-tls - was: RE: [Syslog] Working Group LastCall: syslog-tls document Thread-Index: AcbQdLHr9F4ZXIJKQP20hLBBylSlWgAEwpDQ From: "Rainer Gerhards" To: "Chris Lonvick" , X-OriginalArrivalTime: 05 Sep 2006 01:08:41.0599 (UTC) FILETIME=[D39B98F0:01C6D087] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I strongly applaude the version number. Let's keep it in. More reviews if I manage to do so. Rainer=20 > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com]=20 > Sent: Monday, September 04, 2006 6:49 PM > To: syslog@ietf.org > Subject: version field in syslog-tls - was: RE: [Syslog]=20 > Working Group LastCall: syslog-tls document >=20 > Hi All, >=20 > Please do consider the version field. If we don't have one,=20 > we would have=20 > to live forever with the decisions we are making now. Having=20 > a version=20 > number in there would allow a future group to re-decide things (like=20 > byte-count v. special character) and to just change the=20 > version number=20 > rather than go asking for a new port number - or have a flag day. >=20 > Please review the document and send in your thoughts on this. >=20 > Thanks, > Chris >=20 > On Mon, 4 Sep 2006, Miao Fuyou wrote: >=20 > > > > Hi, > > > > One "major" change to the document is a "version" field for=20 > Syslog TLS > > transport is added to the frame header. The field is to=20 > make port reusing > > possible if the transport mapping document is updated in=20 > the future. An IANA > > paragraph is added accordingly. > > > > Another change is about frame length bounding, Min-max=20 > values(MUST, SHOULD) > > are added to the document. > > > > The two changed was made after discussion between editors=20 > and chairs. > > Discussion and feedback is welcome! > > > > Thanks! > > Miao > > > >> -----Original Message----- > >> From: David Harrington [mailto:ietfdbh@comcast.net] > >> Sent: Wednesday, August 30, 2006 5:48 AM > >> To: syslog@ietf.org > >> Subject: [Syslog] Working Group Last Call: syslog-tls document > >> > >> > >> Hi, > >> > >> This message officially starts the Syslog Working Group Last > >> Call for the following document: > >> > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 > >> .txt > >> > >> The Working Group Last Call for this document will end=20 > September 12. > >> > >> To help get these document reviewed throughly, we are seeking > >> volunteers to review the documents for the following=20 > special reviews: > >> 1) Spelling and grammar, > >> 2) boilerplates and reference review, > >> 3) security review > >> > >> The chairs want to see a minimum number of content reviews > >> before we submit the documents to the IESG. If you review the > >> document and it looks fine, please post a statement that you > >> have reviewed and found the document acceptable. Obviously, > >> if it does not look acceptable please identify your > >> objections, preferably with suggested text that would make it > >> acceptable. > >> > >> Thanks, > >> David Harrington > >> dharrington@huawei.com > >> dbharrington@comcast.net > >> ietfdbh@comcast.net > >> co-chair, Syslog WG > >> > >> > >> > >> _______________________________________________ > >> 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 > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Sep 05 00:48:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKSpt-0005oA-0G; Tue, 05 Sep 2006 00:46:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKSps-0005ji-18 for syslog@ietf.org; Tue, 05 Sep 2006 00:46:56 -0400 Received: from sinclair.provo.novell.com ([137.65.248.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKSpq-0004aD-Mw for syslog@ietf.org; Tue, 05 Sep 2006 00:46:56 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 04 Sep 2006 22:46:53 -0600 Message-Id: <44FCAD53.37FF.0081.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Mon, 04 Sep 2006 22:48:51 -0600 From: "John Calcote" To: "David Harrington" , "Miao Fuyou" , Subject: Re: [Syslog] Working Group Last Call: syslog-tls document References: <14ed01c6cbb4$c17526f0$0400a8c0@china.huawei.com> In-Reply-To: <14ed01c6cbb4$c17526f0$0400a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part7356C7A3.2__=" X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --=__Part7356C7A3.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Here are a few gnits: 1. Section 5.3, para 1, sentence 2, ...multiple TLS Records. 2. Section 5.3, ABNF, It's not necessarily obvious that the numeric fields are decimal (base 10). 3. Section 5.3.1, para 1, sentence 3, ...there is no upper limit. 4. Section 5.3.1, para 1, sentence 4, ...must be able to process frames with...2048 octets. 5. Section 5.3.1, para 1, sentence 5, ...be able to receive frames with...8192 octets. More later... John ----- John Calcote (jcalcote@novell.com) Sr. Software Engineeer Novell, Inc. >>> "David Harrington" 8/29/2006 3:47 PM >>> Hi, This message officially starts the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 .txt The Working Group Last Call for this document will end September 12. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, if it does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ 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 --=__Part7356C7A3.2__= Content-Type: text/plain; name="John Calcote.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="John Calcote.vcf" BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:John Calcote TEL;WORK:1-801-861-7517 ORG:;Unified Identity System Eng TE TEL;PREF;FAX:801/861-2292 EMAIL;WORK;PREF;NGW:JCALCOTE@novell.com N:Calcote;John;;Sr. Software Engineer TITLE:Sr. Software Engineer ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:John Calcote=0A= PRV-H-511=0A= Provo END:VCARD --=__Part7356C7A3.2__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --=__Part7356C7A3.2__=-- From syslog-bounces@lists.ietf.org Tue Sep 05 03:20:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKVD5-00062k-GV; Tue, 05 Sep 2006 03:19:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKVD3-00062c-Vt for syslog@ietf.org; Tue, 05 Sep 2006 03:19:01 -0400 Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKVD1-0007WY-Jk for syslog@ietf.org; Tue, 05 Sep 2006 03:19:01 -0400 Subject: Re: version field in syslog-tls - was: RE: [Syslog] Working Group Last Call: syslog-tls document From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: <004c01c6d004$a51a5210$5c0c6f0a@china.huawei.com> Content-Type: text/plain Date: Tue, 05 Sep 2006 09:18:44 +0200 Message-Id: <1157440724.6329.4.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote: > Hi All, > > Please do consider the version field. If we don't have one, we would have > to live forever with the decisions we are making now. Having a version > number in there would allow a future group to re-decide things (like > byte-count v. special character) and to just change the version number > rather than go asking for a new port number - or have a flag day. > > Please review the document and send in your thoughts on this. Sending the version field is a good idea in general, however I feel that adding it to _every single_ message in a conversation is too redundant, apart from the extra bandwidth used, it causes ambiguities what to do when different messages use a different version number. The version should be associated with the channel, and not individual messages. Having a simple negotiation at the start would IMHO be way better. Something like: HELLO OK START OK -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Sep 05 03:33:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKVQ4-0005Jd-IP; Tue, 05 Sep 2006 03:32:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKVQ2-0005JV-VD for syslog@ietf.org; Tue, 05 Sep 2006 03:32:26 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKVQ1-00021e-3c for syslog@ietf.org; Tue, 05 Sep 2006 03:32:26 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5400D8Y0CPPM@szxga02-in.huawei.com> for syslog@ietf.org; Tue, 05 Sep 2006 15:48:25 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5400FRC0CPAV@szxga02-in.huawei.com> for syslog@ietf.org; Tue, 05 Sep 2006 15:48:25 +0800 (CST) Received: from m19684 ([10.111.12.92]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5300LDAZPNQD@szxml03-in.huawei.com> for syslog@ietf.org; Tue, 05 Sep 2006 15:34:39 +0800 (CST) Date: Tue, 05 Sep 2006 15:30:24 +0800 From: Miao Fuyou Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working Group Last Call: syslog-tls document In-reply-to: <1157440724.6329.4.camel@bzorp.balabit> To: 'Balazs Scheidler' , 'Chris Lonvick' Message-id: <005101c6d0bd$2768be10$5c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbQu7YlM649UuzNQg2aOoKlHl8ZlgAAKJ0g X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Good point. I am considering make the version only available at the beginning of Syslog messages stream to reduce redundency. But, I don't like capabilies negotiation here because it adds extra complexity to implementation. Thanks! MIao > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu] > Sent: Tuesday, September 05, 2006 3:19 PM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > Working Group Last Call: syslog-tls document > > On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote: > > Hi All, > > > > Please do consider the version field. If we don't have > one, we would > > have to live forever with the decisions we are making now. > Having a > > version number in there would allow a future group to > re-decide things > > (like byte-count v. special character) and to just change > the version > > number rather than go asking for a new port number - or > have a flag day. > > > > Please review the document and send in your thoughts on this. > > Sending the version field is a good idea in general, however > I feel that adding it to _every single_ message in a > conversation is too redundant, apart from the extra bandwidth > used, it causes ambiguities what to do when different > messages use a different version number. > > The version should be associated with the channel, and not > individual messages. > > Having a simple negotiation at the start would IMHO be way better. > Something like: > > HELLO > OK > START > OK > > > -- > Bazsi > > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Tue Sep 05 16:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKh4Q-0004Sz-VQ; Tue, 05 Sep 2006 15:58:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKh4Q-0004St-C0 for syslog@ietf.org; Tue, 05 Sep 2006 15:58:54 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKh4O-0006Vf-1b for syslog@ietf.org; Tue, 05 Sep 2006 15:58:54 -0400 Received: from pc6 (1Cust98.tnt102.lnd4.gbr.da.uu.net [213.116.52.98]) by blaster.systems.pipex.net (Postfix) with SMTP id 09502E00024D; Tue, 5 Sep 2006 20:58:37 +0100 (BST) Message-ID: <001001c6d11c$83a42520$0601a8c0@pc6> From: "tom.petch" To: "Glenn M. Keeni" , References: <132101c6cad0$ab256200$0400a8c0@china.huawei.com> <44FBE875.6040600@cysols.com> Subject: Re: [Syslog] Working Group Last Calls Date: Tue, 5 Sep 2006 09:01:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Glenn M. Keeni" To: Sent: Monday, September 04, 2006 10:48 AM Subject: Re: [Syslog] Working Group Last Calls > Hi, > Sincere apologies for the delay in sending the following comments > on the Syslog Protocol document. I faced problems with these while > trying to align the mib document with the protocol document > > In section 6.2.1 > a. The concept of Facility in the syslog protocol context should > be explained > b. In Table 1 references are made to "note 1" and "note 2" > these notes do not exist in the document > c. In Table 1 > Facility 9,15 both denote the clock daemon > Facility 4,14 both denote security/authorization messages So what:-) This is a copy of RFC3164 which in turn is lifted from the mass of implementations so we are documenting what is, which is the point of the exercise. I am unclear what you would change it to since any change would make it wrong, IMHO. Tom Petch > > I think that a,b are editorial matters while c is WG matter. > > Cheers > > Glenn > > > David Harrington wrote: > > Hi, > > > > The WGLC for -protocol-17 and -udp-07 documents will end later today. > > Please review and comment on these documents today. > > > > 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 From syslog-bounces@lists.ietf.org Tue Sep 05 16:01:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKh5p-0004sT-3b; Tue, 05 Sep 2006 16:00:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKh5o-0004sO-2J for syslog@ietf.org; Tue, 05 Sep 2006 16:00:20 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKh5m-0006h5-LW for syslog@ietf.org; Tue, 05 Sep 2006 16:00:20 -0400 Received: from pc6 (1Cust98.tnt102.lnd4.gbr.da.uu.net [213.116.52.98]) by blaster.systems.pipex.net (Postfix) with SMTP id EA0B0E00021B; Tue, 5 Sep 2006 21:00:16 +0100 (BST) Message-ID: <001301c6d11c$bd6462c0$0601a8c0@pc6> From: "tom.petch" To: "Balazs Scheidler" , "Chris Lonvick" References: <004c01c6d004$a51a5210$5c0c6f0a@china.huawei.com> <1157440724.6329.4.camel@bzorp.balabit> Subject: Re: version field in syslog-tls - was: RE: [Syslog] Working GroupLast Call: syslog-tls document Date: Tue, 5 Sep 2006 20:51:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Balazs Scheidler" To: "Chris Lonvick" Cc: Sent: Tuesday, September 05, 2006 9:18 AM Subject: Re: version field in syslog-tls - was: RE: [Syslog] Working GroupLast Call: syslog-tls document > On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote: > > Hi All, > > > > Please do consider the version field. If we don't have one, we would have > > to live forever with the decisions we are making now. Having a version > > number in there would allow a future group to re-decide things (like > > byte-count v. special character) and to just change the version number > > rather than go asking for a new port number - or have a flag day. > > > > Please review the document and send in your thoughts on this. > > Sending the version field is a good idea in general, however I feel that > adding it to _every single_ message in a conversation is too redundant, > apart from the extra bandwidth used, it causes ambiguities what to do > when different messages use a different version number. > > The version should be associated with the channel, and not individual > messages. > > Having a simple negotiation at the start would IMHO be way better. > Something like: > > HELLO > OK > START > OK > > I too like starting with a simple negotiation. I notice that other applications that started with TCP and then added security have used character strings such as AUTH TLS which has the advantage of readily adding in SSH (or anything else) in the future. I also like being able to add later a choice as to which end is client and which server since I foresee problems here with security credentials (most other applications have the server on a well-connected device well able to verify secuirty credentials, something a remote network box is less well able to do). Tom Petch > -- > Bazsi > > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Tue Sep 05 18:44:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKjcy-00057o-Ew; Tue, 05 Sep 2006 18:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKjcx-00057j-17 for syslog@ietf.org; Tue, 05 Sep 2006 18:42:43 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKjcv-0005MN-BF for syslog@ietf.org; Tue, 05 Sep 2006 18:42:43 -0400 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k85Mgdm9026611 for ; Wed, 6 Sep 2006 07:42:39 +0900 (JST) Received: from [127.0.0.1] (kiras1.priv.cysol.co.jp [192.168.0.151]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k85MgW5x014604 for ; Wed, 6 Sep 2006 07:42:39 +0900 (JST) Message-ID: <44FDFD57.4070005@cysols.com> Date: Wed, 06 Sep 2006 07:42:31 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Working Group Last Calls References: <132101c6cad0$ab256200$0400a8c0@china.huawei.com> <44FBE875.6040600@cysols.com> <001001c6d11c$83a42520$0601a8c0@pc6> In-Reply-To: <001001c6d11c$83a42520$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org tom.petch wrote: >> c. In Table 1 >> Facility 9,15 both denote the clock daemon >> Facility 4,14 both denote security/authorization messages > > So what:-) a. I would consider that to be sloppy specs. I will not argue any further on that point :-) b. rfc3164 describes to the BSD syslog protocol. In BSD implementations (e.g. FreeBSD) there is a subtle difference between Facility 4 (LOG_AUTH) and 14(LOG_AUTHPRIV). Facility 15 is reserved for system use. c. The syslog protocol is defining a standard, not describing existing implementations. [Existing implementations will not inter-operate with the new protocol] Correct me if I am wrong. So what should we do ? Well, discuss it and decide that is what we have the working group for :-) [Apologies if this has been discussed already - I missed it. ] > > I am unclear what you would change it to since any change > would make it wrong, IMHO. > :-) Cheers Glenn > ----- Original Message ----- > From: "Glenn M. Keeni" > To: > Sent: Monday, September 04, 2006 10:48 AM > Subject: Re: [Syslog] Working Group Last Calls > > >> Hi, >> Sincere apologies for the delay in sending the following comments >> on the Syslog Protocol document. I faced problems with these while >> trying to align the mib document with the protocol document >> >> In section 6.2.1 >> a. The concept of Facility in the syslog protocol context should >> be explained >> b. In Table 1 references are made to "note 1" and "note 2" >> these notes do not exist in the document >> c. In Table 1 >> Facility 9,15 both denote the clock daemon >> Facility 4,14 both denote security/authorization messages > > So what:-) > > This is a copy of RFC3164 which in turn is lifted from the mass of > implementations so we are documenting what is, which is the point of the > exercise. > > I am unclear what you would change it to since any change would make it wrong, > IMHO. > > Tom Petch > >> I think that a,b are editorial matters while c is WG matter. >> >> Cheers >> >> Glenn >> >> >> David Harrington wrote: >>> Hi, >>> >>> The WGLC for -protocol-17 and -udp-07 documents will end later today. >>> Please review and comment on these documents today. >>> >>> 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 From syslog-bounces@lists.ietf.org Wed Sep 06 07:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKv9k-0003ry-UF; Wed, 06 Sep 2006 07:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKv9j-0003rt-Jb for syslog@ietf.org; Wed, 06 Sep 2006 07:01:19 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKv9h-0003Se-62 for syslog@ietf.org; Wed, 06 Sep 2006 07:01:19 -0400 Received: from pc6 (1Cust207.tnt21.lnd4.gbr.da.uu.net [62.188.150.207]) by blaster.systems.pipex.net (Postfix) with SMTP id 17F2FE0004DE; Wed, 6 Sep 2006 12:01:12 +0100 (BST) Message-ID: <022701c6d19a$9a3e9800$0601a8c0@pc6> From: "tom.petch" To: "Glenn M. Keeni" , References: <132101c6cad0$ab256200$0400a8c0@china.huawei.com><44FBE875.6040600@cysols.com> <001001c6d11c$83a42520$0601a8c0@pc6> <44FDFD57.4070005@cysols.com> Subject: Table 1 was Re: [Syslog] Working Group Last Calls Date: Wed, 6 Sep 2006 10:49:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org My thinking is that the detailed semantics of Table 1 (and 2 and 3) are not necessary for interoperability of the protocol, rather they are up in some higher layer. I think that the text which follows Table 1 "The above semantics for Facility values are not normative but often used. A receiver MUST NOT assume any specific semantics by default" expresses it rather well and that that is as far as we should go in -protocol. Tom Petch ----- Original Message ----- From: "Glenn M. Keeni" To: Sent: Wednesday, September 06, 2006 12:42 AM Subject: Re: [Syslog] Working Group Last Calls > tom.petch wrote: > >> c. In Table 1 > >> Facility 9,15 both denote the clock daemon > >> Facility 4,14 both denote security/authorization messages > > > > So what:-) > a. I would consider that to be sloppy specs. I will not argue > any further on that point :-) > b. rfc3164 describes to the BSD syslog protocol. > In BSD implementations (e.g. FreeBSD) there is a subtle > difference between Facility 4 (LOG_AUTH) and 14(LOG_AUTHPRIV). > Facility 15 is reserved for system use. > c. The syslog protocol is defining a standard, not describing > existing implementations. > [Existing implementations will not inter-operate with the > new protocol] Correct me if I am wrong. > > So what should we do ? Well, discuss it and decide that is what > we have the working group for :-) [Apologies if this has been > discussed already - I missed it. ] > > > > I am unclear what you would change it to since any change > > would make it wrong, IMHO. > > > :-) > > Cheers > > Glenn > > > > ----- Original Message ----- > > From: "Glenn M. Keeni" > > To: > > Sent: Monday, September 04, 2006 10:48 AM > > Subject: Re: [Syslog] Working Group Last Calls > > > > > >> Hi, > >> Sincere apologies for the delay in sending the following comments > >> on the Syslog Protocol document. I faced problems with these while > >> trying to align the mib document with the protocol document > >> > >> In section 6.2.1 > >> a. The concept of Facility in the syslog protocol context should > >> be explained > >> b. In Table 1 references are made to "note 1" and "note 2" > >> these notes do not exist in the document > >> c. In Table 1 > >> Facility 9,15 both denote the clock daemon > >> Facility 4,14 both denote security/authorization messages > > > > So what:-) > > > > This is a copy of RFC3164 which in turn is lifted from the mass of > > implementations so we are documenting what is, which is the point of the > > exercise. > > > > I am unclear what you would change it to since any change would make it wrong, > > IMHO. > > > > Tom Petch > > > >> I think that a,b are editorial matters while c is WG matter. > >> > >> Cheers > >> > >> Glenn > >> > >> > >> David Harrington wrote: > >>> Hi, > >>> > >>> The WGLC for -protocol-17 and -udp-07 documents will end later today. > >>> Please review and comment on these documents today. > >>> _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Sep 07 05:23:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLG55-0003XN-9z; Thu, 07 Sep 2006 05:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLG54-0003Ws-Dy for syslog@ietf.org; Thu, 07 Sep 2006 05:21:54 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLG52-0003DJ-Nu for syslog@ietf.org; Thu, 07 Sep 2006 05:21:54 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5700BCHTZYWV@szxga01-in.huawei.com> for syslog@ietf.org; Thu, 07 Sep 2006 17:21:34 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5700ELVTZX22@szxga01-in.huawei.com> for syslog@ietf.org; Thu, 07 Sep 2006 17:21:33 +0800 (CST) Received: from m19684 ([10.111.12.92]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5700LDOU1ILI@szxml03-in.huawei.com> for syslog@ietf.org; Thu, 07 Sep 2006 17:22:34 +0800 (CST) Date: Thu, 07 Sep 2006 17:17:58 +0800 From: Miao Fuyou Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working GroupLastCall: syslog-tls document In-reply-to: <001301c6d11c$bd6462c0$0601a8c0@pc6> To: "'tom.petch'" , 'Balazs Scheidler' , 'Chris Lonvick' Message-id: <012701c6d25e$82deb4f0$5c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcbRJgIMmkPnr56cSGCss7bxh4BgjwBNMf5w X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Starting from TCP and then upgrading to tls is quite different to current tls transport mapping document. If we decide to do UPGRADING, we may first need a TCP transport mapping for Syslog, and then define a specific string to indicate the other side to upgrade to TLS. We currently assume Syslog has a IANA allocated port for tls transport mapping, we may not need such complexity on upgrading. FYI, HTTP has two tls mechansims: RFC2818(standards track) is similiar to this draft, RFC2817(Informational) is on upgrading. > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, September 06, 2006 2:51 AM > To: Balazs Scheidler; Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > Working GroupLastCall: syslog-tls document > > ----- Original Message ----- > From: "Balazs Scheidler" > To: "Chris Lonvick" > Cc: > Sent: Tuesday, September 05, 2006 9:18 AM > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > Working GroupLast > Call: syslog-tls document > > > > On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote: > > > Hi All, > > > > > > Please do consider the version field. If we don't have one, we > > > would have to live forever with the decisions we are making now. > > > Having a version number in there would allow a future group to > > > re-decide things (like byte-count v. special character) > and to just > > > change the version number rather than go asking for a new > port number - or have a flag day. > > > > > > Please review the document and send in your thoughts on this. > > > > Sending the version field is a good idea in general, however I feel > > that adding it to _every single_ message in a conversation is too > > redundant, apart from the extra bandwidth used, it causes > ambiguities > > what to do when different messages use a different version number. > > > > The version should be associated with the channel, and not > individual > > messages. > > > > Having a simple negotiation at the start would IMHO be way better. > > Something like: > > > > HELLO > > OK > > START > > OK > > > > > I too like starting with a simple negotiation. I notice that > other applications that started with TCP and then added > security have used character strings such as AUTH TLS which > has the advantage of readily adding in SSH (or anything else) > in the future. > I also like being able to add later a choice as to which end > is client and which server since I foresee problems here with > security credentials (most other applications have the server > on a well-connected device well able to verify secuirty > credentials, something a remote network box is less well able to do). > > Tom Petch > > > -- > > Bazsi > > > > > > _______________________________________________ > > 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 From syslog-bounces@lists.ietf.org Thu Sep 07 07:39:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLID0-0006lp-HS; Thu, 07 Sep 2006 07:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLICz-0006lc-9A for syslog@ietf.org; Thu, 07 Sep 2006 07:38:13 -0400 Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLICv-00053Q-TB for syslog@ietf.org; Thu, 07 Sep 2006 07:38:13 -0400 Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working GroupLastCall: syslog-tls document From: Balazs Scheidler To: Miao Fuyou In-Reply-To: <012701c6d25e$82deb4f0$5c0c6f0a@china.huawei.com> References: <012701c6d25e$82deb4f0$5c0c6f0a@china.huawei.com> Content-Type: text/plain Date: Thu, 07 Sep 2006 13:37:52 +0200 Message-Id: <1157629073.7963.3.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Thu, 2006-09-07 at 17:17 +0800, Miao Fuyou wrote: > Starting from TCP and then upgrading to tls is quite different to current > tls transport mapping document. If we decide to do UPGRADING, we may first > need a TCP transport mapping for Syslog, and then define a specific string > to indicate the other side to upgrade to TLS. We currently assume Syslog has > a IANA allocated port for tls transport mapping, we may not need such > complexity on upgrading. > > FYI, HTTP has two tls mechansims: RFC2818(standards track) is similiar to > this draft, RFC2817(Informational) is on upgrading. We clearly stated in our charter that we won't define a plain TCP version (although I personally disagree). A simple capability negotiation can be useful for reasons beyond TLS upgrade, like an optional support for Application Layer acknowledgements. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Sep 07 09:03:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLJWj-0003Id-SZ; Thu, 07 Sep 2006 09:02:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLJWi-0003Hc-PD for syslog@ietf.org; Thu, 07 Sep 2006 09:02:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLJWg-00070Z-Ck for syslog@ietf.org; Thu, 07 Sep 2006 09:02:40 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 07 Sep 2006 05:22:31 -0700 X-IronPort-AV: i="4.08,225,1154934000"; d="scan'208"; a="318559169:sNHT10348873834" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k87CMVJq011831; Thu, 7 Sep 2006 05:22:31 -0700 Received: from sjc-cde-014.cisco.com (sjc-cde-014.cisco.com [171.69.20.40]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k87CMUw8012208; Thu, 7 Sep 2006 05:22:30 -0700 (PDT) Date: Thu, 7 Sep 2006 05:22:29 -0700 (PDT) From: Chris Lonvick To: Balazs Scheidler Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working GroupLastCall: syslog-tls document In-Reply-To: <1157629073.7963.3.camel@bzorp.balabit> Message-ID: References: <012701c6d25e$82deb4f0$5c0c6f0a@china.huawei.com> <1157629073.7963.3.camel@bzorp.balabit> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1634; t=1157631751; x=1158495751; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:RE=3A=20version=20field=20in=20syslog-tls=20-=20was=3A=20RE=3A=20[Syslog ]=20Working=0A=20GroupLastCall=3A=20syslog-tls=20document; X=v=3Dcisco.com=3B=20h=3D64WbCJP/WrD55Sp2hUINHNinZzg=3D; b=m47ljz+acM3xF9cHxcvBcEfMJDek88sDNcslmgwFaevmgfjNnpjFi/ULzF3HGwdhUSn+ZK6O o4S6xk+oMAFbqDw6/99RPJDk9xw2XpPVTYyI1lLGkoBxPRWg0b014xDN; Authentication-Results: sj-dkim-7.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Bazsi, On Thu, 7 Sep 2006, Balazs Scheidler wrote: > On Thu, 2006-09-07 at 17:17 +0800, Miao Fuyou wrote: >> Starting from TCP and then upgrading to tls is quite different to current >> tls transport mapping document. If we decide to do UPGRADING, we may first >> need a TCP transport mapping for Syslog, and then define a specific string >> to indicate the other side to upgrade to TLS. We currently assume Syslog has >> a IANA allocated port for tls transport mapping, we may not need such >> complexity on upgrading. >> >> FYI, HTTP has two tls mechansims: RFC2818(standards track) is similiar to >> this draft, RFC2817(Informational) is on upgrading. > > We clearly stated in our charter that we won't define a plain TCP > version (although I personally disagree). I think that we have discussed this before; you are free to write your own ID on this. I know that others support this so you should be able to find people to help. > > A simple capability negotiation can be useful for reasons beyond TLS > upgrade, like an optional support for Application Layer > acknowledgements. I fear that if we start going down that path we will reinvent RFC 3195. We need to continue addressing simplex syslog with syslog-transport-tls. We can address capabilities exchange either in 3195bis or it can be looked into in a future revision of syslog/tls (yet another good reason for a version field). If you get a lot of people doing syslog/tcp with a capabilities exchange mechanism then it should be simple to put that into a subsequent version of syslog-transport-tls. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Sep 08 03:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLaiN-0002RC-Nt; Fri, 08 Sep 2006 03:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLaiN-0002R7-6R for syslog@ietf.org; Fri, 08 Sep 2006 03:23:51 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLaiL-0000WJ-I5 for syslog@ietf.org; Fri, 08 Sep 2006 03:23:51 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5900EFDJVKD2@szxga02-in.huawei.com> for syslog@ietf.org; Fri, 08 Sep 2006 15:38:08 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5900I6DJVJ2W@szxga02-in.huawei.com> for syslog@ietf.org; Fri, 08 Sep 2006 15:38:08 +0800 (CST) Received: from m19684 ([10.111.12.92]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5900J59JLV75@szxml04-in.huawei.com> for syslog@ietf.org; Fri, 08 Sep 2006 15:32:23 +0800 (CST) Date: Fri, 08 Sep 2006 15:19:47 +0800 From: Miao Fuyou Subject: RE: [Syslog] Working Group Last Call: syslog-sign document In-reply-to: <133f01c6cadf$afa2d600$0400a8c0@china.huawei.com> To: syslog@ietf.org Message-id: <007e01c6d317$2a8d9c30$5c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iACkS6mUAINQssw X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org One review finding: Section 4.1, TAG of syslog-protocol is a little different to the one of bsd-syslog. In bsd-syslog(section 4.1.3) it is process name, but in syslog-protocol (section A.1) it is combination of APP-NAME, PROCID, and MSGID. So, for bsd-syslog, TAG should be "syslog"("syslog "? typo?), but for syslog-protocol, APP-NAME should be "syslog". Thanks! Miao > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, August 29, 2006 4:22 AM > To: syslog@ietf.org > Subject: [Syslog] Working Group Last Call: syslog-sign document > > > Hi, > > This message officially starts the Syslog Working Group Last > Call for the following document: > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt > > The Working Group Last Call for this document will end September 11. > > To help get these document reviewed throughly, we are seeking > volunteers to review the documents for the following special reviews: > 1) Spelling and grammar, > 2) boilerplates and reference review, > 3) security review > > The chairs want to see a minimum number of content reviews > before we submit the documents to the IESG. If you review the > document and it looks fine, please post a statement that you > have reviewed and found the document acceptable. Obviously, > if it does not look acceptable please identify your > objections, preferably with suggested text that would make it > acceptable. > > Thanks, > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > > > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Fri Sep 08 12:32:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLjFb-00056R-Ur; Fri, 08 Sep 2006 12:30:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLjDe-0003iF-1I for syslog@ietf.org; Fri, 08 Sep 2006 12:28:42 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLj2K-0003Do-BA for syslog@ietf.org; Fri, 08 Sep 2006 12:17:01 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5A000ZB7R45O@usaga01-in.huawei.com> for syslog@ietf.org; Fri, 08 Sep 2006 09:13:52 -0700 (PDT) Received: from Harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net [24.61.222.235]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5A009HR7R2YT@usaga01-in.huawei.com> for syslog@ietf.org; Fri, 08 Sep 2006 09:13:52 -0700 (PDT) Date: Fri, 08 Sep 2006 12:15:14 -0400 From: David Harrington In-reply-to: <44FD94B0.7070609@cysols.com> To: "'Glenn M. Keeni'" , 'Chris Lonvick' Message-id: <00e001c6d361$f8662510$0400a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbQ/uIVGVIlyAAaQ1yKDUjkBZ0NCQCXVZFQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: syslog@ietf.org Subject: [Syslog] RE: I-D submission draft-ietf-syslog-device-mib-09.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Glenn, I have not yet seen revision -09- announced, and it is not yet available from the I-D repository. Can you check on the progress of this please? I seem to have some problems getting email to you using the glenn@cysold.com; if there is another address I can use to contact you, please send it to me privately. An idnits-tool review of the copy of the -09- document you posted to the group complains of pages being too long. My copy of the -09- shows lots of white space between the footer and the next page header; are you adding extra lines by mistake, causing the pages to be too long? http://tools.ietf.org/tools/idnits/idnits.pyht also complains that the document is missing a Security Considerations section, which it obviously does have, so a bug must have been introduced into the idnits tool recently. dbh > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Tuesday, September 05, 2006 11:16 AM > To: Internet Draft Submission Manager; Chris Lonvick; > dharrington@huawei.com > Subject: I-D submission draft-ietf-syslog-device-mib-09.txt > > Hi, > Attached, please find the revised I-D > draft-ietf-syslog-device-mib-09.txt. > Please post this document to the archives. > > Thanks and cheers > > Glenn > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Sep 08 13:25:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLk5m-0004n7-IP; Fri, 08 Sep 2006 13:24:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLk5l-0004n1-B1 for syslog@ietf.org; Fri, 08 Sep 2006 13:24:37 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLk5k-0004PE-3y for syslog@ietf.org; Fri, 08 Sep 2006 13:24:37 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc11) with SMTP id <2006090817243301100cepv7e>; Fri, 8 Sep 2006 17:24:33 +0000 From: "David Harrington" To: Date: Fri, 8 Sep 2006 13:22:50 -0400 Message-ID: <00ea01c6d36b$694fb2b0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbTazxKWN+wJ+TuQjuypiB/M6ifcA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Syslog] WGLC and document advancement X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, There are good things and bad things that come with having a new WG co-chair. I think I have helped the WG by driving the completion of milestones. That's the good part. The bad part is I bring my own opinions of what adequate review means. The IETF has started using a new process, called document shepherding, for the advancement of documents to the standards-track. The chairs are given much more responsibility and authority to decide whether documents are ready for advancement. They are expected to write up their analyses of WG issues, consensus, and degree of review of the documents being submitted, and these analyses will be reviewed at every step of the process after this point, as the members of the IESG try to determine whether the document really is ready for advancment to standards-track. You can see the details they expect us to provide by reading draft-ietf-proto-wgchair-doc-shepherding-07 (which has been expanded quite a bit from the -05- draft used during your earlier WGLCs). I have shepherded a number of documents through the process, and I know how difficult it can be to get documents through the process, and how much the documents can be delayed during the standards-approval process if they are not really ready for submission to that process. I am concerned that the documents have not gotten adequate review during WGLC. There have been very few comments made, and I would like to see more reviews done by the members of the WG for each of these documents. If you have problems with the documents, speak up now, so the chairs can be sure your concerns are recognized and have been addressed. If you have read the document, and found no important problems and have no significant objections to the document, and belive it is ready to be submitted to the advancement process, please send a note to the WG saying so. 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 From syslog-bounces@lists.ietf.org Fri Sep 08 14:44:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLlJA-0005oQ-Fy; Fri, 08 Sep 2006 14:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLlJ8-0005oL-Pt for syslog@ietf.org; Fri, 08 Sep 2006 14:42:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLlJ6-0000Em-1M for syslog@ietf.org; Fri, 08 Sep 2006 14:42:30 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 Sep 2006 14:42:28 -0400 X-IronPort-AV: i="4.09,134,1157342400"; d="scan'208"; a="101440244:sNHT31790282" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k88IgRn1015381; Fri, 8 Sep 2006 14:42:27 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k88IgRdM021800; Fri, 8 Sep 2006 14:42:27 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 14:42:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] WGLC and document advancement Date: Fri, 8 Sep 2006 14:38:40 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B731223436FE@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] WGLC and document advancement thread-index: AcbTazxKWN+wJ+TuQjuypiB/M6ifcAAChUwQ From: "Anton Okmianski \(aokmians\)" To: "David Harrington" , X-OriginalArrivalTime: 08 Sep 2006 18:42:27.0001 (UTC) FILETIME=[881F9290:01C6D376] DKIM-Signature: a=rsa-sha1; q=dns; l=3136; t=1157740947; x=1158604947; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:RE=3A=20[Syslog]=20WGLC=20and=20document=20advancement |To:=22David=20Harrington=22=20,=20; X=v=3Dcisco.com=3B=20h=3DWuxSAbQ8kyDMUVgo8REjDzrS4/8=3D; b=QwDRBytOafAp8teyr/IjraKv00Z5RsHyfqtkU9+aQHwDd4+aWZHAnCgQ5tjL4UU6yMAUv+lt dlSOay/ueOChAGHWFJG/dlpRJt8WW5Vod2xK0zyfc4HbdtpQ+YvtUHkw; Authentication-Results: rtp-dkim-1.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David: Part of it is that we reviewed a lot of the syslog-protocol before the last WGLC, and it did not change much since. I think we just added the header, right?=20 So, I have not given this version a close review because I reviewed much of the same content for 2 years up to the last WGLC. =20 If there were significant other changes since the last WGLC, I'd like to know. If there were a lot of minor changes, I'd appreciate a document with tracked changes since last WGLC. Word Compare feature may help with that. =20 Thanks, Anton.=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, September 08, 2006 1:23 PM > To: syslog@ietf.org > Subject: [Syslog] WGLC and document advancement >=20 > Hi, >=20 > There are good things and bad things that come with having a=20 > new WG co-chair. > I think I have helped the WG by driving the completion of milestones. > That's the good part. > The bad part is I bring my own opinions of what adequate review means. >=20 > The IETF has started using a new process, called document=20 > shepherding, for the advancement of documents to the=20 > standards-track. The chairs are given much more=20 > responsibility and authority to decide whether documents are=20 > ready for advancement. They are expected to write up their=20 > analyses of WG issues, consensus, and degree of review of the=20 > documents being submitted, and these analyses will be=20 > reviewed at every step of the process after this point, as=20 > the members of the IESG try to determine whether the document=20 > really is ready for advancment to standards-track. You can=20 > see the details they expect us to provide by reading=20 > draft-ietf-proto-wgchair-doc-shepherding-07 (which has been=20 > expanded quite a bit from the -05- draft used during your=20 > earlier WGLCs). >=20 > I have shepherded a number of documents through the process,=20 > and I know how difficult it can be to get documents through=20 > the process, and how much the documents can be delayed during=20 > the standards-approval process if they are not really ready=20 > for submission to that process. >=20 > I am concerned that the documents have not gotten adequate=20 > review during WGLC. There have been very few comments made,=20 > and I would like to see more reviews done by the members of=20 > the WG for each of these documents.=20 >=20 > If you have problems with the documents, speak up now, so the=20 > chairs can be sure your concerns are recognized and have been=20 > addressed.=20 >=20 > If you have read the document, and found no important=20 > problems and have no significant objections to the document,=20 > and belive it is ready to be submitted to the advancement=20 > process, please send a note to the WG saying so.=20 >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Sep 08 20:48:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLqz3-0005qG-61; Fri, 08 Sep 2006 20:46:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLqz2-0005nF-HU for syslog@ietf.org; Fri, 08 Sep 2006 20:46:08 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLqz0-0002bn-V8 for syslog@ietf.org; Fri, 08 Sep 2006 20:46:08 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 41F199C00C; Sat, 9 Sep 2006 02:49:14 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06680-09; Sat, 9 Sep 2006 02:49:08 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id E4FB29C00B; Sat, 9 Sep 2006 02:49:08 +0200 (CEST) Content-class: urn:content-classes:message Subject: RE: [Syslog] WGLC and document advancement MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 9 Sep 2006 02:33:30 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174E97@grfint2.intern.adiscon.com> In-Reply-To: <00ea01c6d36b$694fb2b0$0400a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] WGLC and document advancement Thread-Index: AcbTazxKWN+wJ+TuQjuypiB/M6ifcAAOplZQ From: "Rainer Gerhards" To: "David Harrington" , X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David, Thanks for the reminder. I have read -transport-tls several times, only been unable to have a close look at the latest increment. To my understanding, there were only minor changes to the document, so I am still happy with it. I am concerned about the lack of feedback to my response to your concerns on the "enc" SD-ID and transparency of MSG and STRUCTURED-DATA in -protocol. I am hesitant to do any edits until there has been any final discussion of these issues (reminder: I am most probably able to edit starting September, 18th). I have roughly reviewed -transport-tls (due to my time constraints). All in all, it looks good enough to me. My main concerns have already been addressed by adding the version number. I think, however, this point needs some more discussion.=20 There are many other points in -tls that could be discussed. HOWEVER, I think discussing any of them now would make us miss our milestone. What is there is well enough. It could be better. Let's do that at later stage (version field permits this).=20 We have been discussing syslog-protocol and -tls (and the work leading to it) for 3 or 4 years now, often going in circles. Participation levels have varied greatly. My personal opinion is that many folks are finally bored with going ever and ever over the same arguments. But I may be wrong. Getting some work done would definitely help us. We should not aim for the perfect. In an ideal world, we would have only ideal solutions. But we do not life in an ideal world. If NASA feels strong enough to launch a shuttle with an imperfect fuel cell, we should probably feel strong enough in putting some non-ideal but obviously useful work to completion. So please comment on the drafts and open issues. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, September 08, 2006 1:23 PM > To: syslog@ietf.org > Subject: [Syslog] WGLC and document advancement >=20 > Hi, >=20 > There are good things and bad things that come with having a new WG > co-chair. > I think I have helped the WG by driving the completion of milestones. > That's the good part. > The bad part is I bring my own opinions of what adequate review means. >=20 > The IETF has started using a new process, called document shepherding, > for the advancement of documents to the standards-track. The chairs > are given much more responsibility and authority to decide whether > documents are ready for advancement. They are expected to write up > their analyses of WG issues, consensus, and degree of review of the > documents being submitted, and these analyses will be reviewed at > every step of the process after this point, as the members of the IESG > try to determine whether the document really is ready for advancment > to standards-track. You can see the details they expect us to provide > by reading draft-ietf-proto-wgchair-doc-shepherding-07 (which has been > expanded quite a bit from the -05- draft used during your earlier > WGLCs). >=20 > I have shepherded a number of documents through the process, and I > know how difficult it can be to get documents through the process, and > how much the documents can be delayed during the standards-approval > process if they are not really ready for submission to that process. >=20 > I am concerned that the documents have not gotten adequate review > during WGLC. There have been very few comments made, and I would like > to see more reviews done by the members of the WG for each of these > documents.=20 >=20 > If you have problems with the documents, speak up now, so the chairs > can be sure your concerns are recognized and have been addressed.=20 >=20 > If you have read the document, and found no important problems and > have no significant objections to the document, and belive it is ready > to be submitted to the advancement process, please send a note to the > WG saying so.=20 >=20 > David Harrington > dharrington@huawei.com=20 > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Sep 10 05:36:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMLhh-0002GE-33; Sun, 10 Sep 2006 05:34:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMLhg-0002G7-AE for syslog@ietf.org; Sun, 10 Sep 2006 05:34:16 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMLhc-000176-KV for syslog@ietf.org; Sun, 10 Sep 2006 05:34:14 -0400 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k8A9XHm9021245; Sun, 10 Sep 2006 18:33:17 +0900 (JST) Received: from [127.0.0.1] (kiras7.priv.cysol.co.jp [192.168.0.157]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k8A9X55x029917; Sun, 10 Sep 2006 18:33:17 +0900 (JST) Message-ID: <4503DBD0.30906@cysols.com> Date: Sun, 10 Sep 2006 18:33:04 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: David Harrington References: <00e001c6d361$f8662510$0400a8c0@china.huawei.com> In-Reply-To: <00e001c6d361$f8662510$0400a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: syslog@ietf.org Subject: [Syslog] Re: I-D submission draft-ietf-syslog-device-mib-09.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Dave, > I have not yet seen revision -09- announced, and it is not yet > available from the I-D repository. Can you check on the progress of > this please? That was my mistake, I sent it to the wrong address. Sorry about that. I have resent the draft to internet-drafts@ietf.org on 9/8/06. This time I have received the acknowledgment. So it should be in the archives shortly. > I seem to have some problems getting email to you using the > glenn@cysold.com; if there is another address I can use to contact > you, please send it to me privately. The correct address is glenn@cysols.com, that address MUST work. If it doesn't please let me know. > > An idnits-tool review of the copy of the -09- document you posted to > the group complains of pages being too long. My copy of the -09- shows > lots of white space between the footer and the next page header; are > you adding extra lines by mistake, causing the pages to be too long? I am not doing anything new - the same steps as given in the instruction to RFC editors. I will check this once again and have these removed in the next draft. > > http://tools.ietf.org/tools/idnits/idnits.pyht also complains that the > document is missing a Security Considerations section, which it > obviously does have, so a bug must have been introduced into the > idnits tool recently. Yes. That is correct. The "Security Considerations" is there. This is most likely a nit in the idnits script. > > dbh Cheers Glenn > >> -----Original Message----- >> From: Glenn M. Keeni [mailto:glenn@cysols.com] >> Sent: Tuesday, September 05, 2006 11:16 AM >> To: Internet Draft Submission Manager; Chris Lonvick; >> dharrington@huawei.com >> Subject: I-D submission draft-ietf-syslog-device-mib-09.txt >> >> Hi, >> Attached, please find the revised I-D >> draft-ietf-syslog-device-mib-09.txt. >> Please post this document to the archives. >> >> Thanks and cheers >> >> Glenn >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Sep 10 15:51:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMVJo-0004V6-DD; Sun, 10 Sep 2006 15:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMVJb-0004TE-E0; Sun, 10 Sep 2006 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMVJa-0000a0-4i; Sun, 10 Sep 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 1C691328A6; Sun, 10 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GMVJZ-00062h-VK; Sun, 10 Sep 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 10 Sep 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-09.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Syslog Management Information Base Author(s) : G. Keeni Filename : draft-ietf-syslog-device-mib-09.txt Pages : 35 Date : 2006-9-10 This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-device-mib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-device-mib-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-10105031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-device-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-device-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-10105031.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Mon Sep 11 10:47:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMn3B-00076s-0y; Mon, 11 Sep 2006 10:46:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMn39-00076K-Cl for syslog@ietf.org; Mon, 11 Sep 2006 10:46:15 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMn38-00086j-4z for syslog@ietf.org; Mon, 11 Sep 2006 10:46:15 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc11) with SMTP id <2006091114460701100cfu46e>; Mon, 11 Sep 2006 14:46:12 +0000 From: "David B Harrington" To: Date: Mon, 11 Sep 2006 10:44:21 -0400 Message-ID: <023f01c6d5b0$c7ebaf30$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iACkS6mUAA1NbhgAn8uQEA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Syslog] Working Group Last Call: syslog-mib document X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, This message officially starts the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx t The Working Group Last Call for this document will end September 25. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, if it does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ 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 From syslog-bounces@lists.ietf.org Mon Sep 11 12:56:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMp3c-0005nn-Gy; Mon, 11 Sep 2006 12:54:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMp3b-0005nf-Q7 for syslog@ietf.org; Mon, 11 Sep 2006 12:54:51 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMp3a-0001TP-Fp for syslog@ietf.org; Mon, 11 Sep 2006 12:54:51 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc12) with SMTP id <2006091116544701200038ege>; Mon, 11 Sep 2006 16:54:47 +0000 From: "David Harrington" To: "'Anton Okmianski \(aokmians\)'" , Subject: RE: [Syslog] WGLC and document advancement Date: Mon, 11 Sep 2006 12:53:01 -0400 Message-ID: <025c01c6d5c2$bdef5bf0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbTazxKWN+wJ+TuQjuypiB/M6ifcAAChUwQAJHr8bA= In-reply-to: <98AE08B66FAD1742BED6CB9522B731223436FE@xmb-rtp-20d.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, I realize the WG is tired of reviewing these documents. But the documents have been changed since the last WGLC, and it is the responsibility of the WG to review the documents for THIS WGLC. I wasn't co-chair at the time of the last WGLC. The last WGLC occurred more than a year ago. The documents have changed since protocol-14 and udp-05. I personally do not have copies of protocol-14 and udp-05 to do the diffs for you. Since that time, we have had a new charter, and debated issues such as: max message size, structured data, NUL octets, binary data, octet counts, field order, character encoding, MSGID, PROCID, APP-NAME, and VERSION in the header the standardization of message drops truncation I do not believe reviewing just the diffs will be adequate given the number and scope of changes. So, WG members should do a complete review again, as boring as such reviews will be. Hopefully, this WILL be the last one. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > Sent: Friday, September 08, 2006 2:39 PM > To: David Harrington; syslog@ietf.org > Subject: RE: [Syslog] WGLC and document advancement > > David: > > Part of it is that we reviewed a lot of the syslog-protocol before the > last WGLC, and it did not change much since. I think we just added the > header, right? > > So, I have not given this version a close review because I > reviewed much > of the same content for 2 years up to the last WGLC. > > If there were significant other changes since the last WGLC, > I'd like to > know. If there were a lot of minor changes, I'd appreciate a document > with tracked changes since last WGLC. Word Compare feature may help > with that. > > Thanks, > Anton. > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Friday, September 08, 2006 1:23 PM > > To: syslog@ietf.org > > Subject: [Syslog] WGLC and document advancement > > > > Hi, > > > > There are good things and bad things that come with having a > > new WG co-chair. > > I think I have helped the WG by driving the completion of > milestones. > > That's the good part. > > The bad part is I bring my own opinions of what adequate > review means. > > > > The IETF has started using a new process, called document > > shepherding, for the advancement of documents to the > > standards-track. The chairs are given much more > > responsibility and authority to decide whether documents are > > ready for advancement. They are expected to write up their > > analyses of WG issues, consensus, and degree of review of the > > documents being submitted, and these analyses will be > > reviewed at every step of the process after this point, as > > the members of the IESG try to determine whether the document > > really is ready for advancment to standards-track. You can > > see the details they expect us to provide by reading > > draft-ietf-proto-wgchair-doc-shepherding-07 (which has been > > expanded quite a bit from the -05- draft used during your > > earlier WGLCs). > > > > I have shepherded a number of documents through the process, > > and I know how difficult it can be to get documents through > > the process, and how much the documents can be delayed during > > the standards-approval process if they are not really ready > > for submission to that process. > > > > I am concerned that the documents have not gotten adequate > > review during WGLC. There have been very few comments made, > > and I would like to see more reviews done by the members of > > the WG for each of these documents. > > > > If you have problems with the documents, speak up now, so the > > chairs can be sure your concerns are recognized and have been > > addressed. > > > > If you have read the document, and found no important > > problems and have no significant objections to the document, > > and belive it is ready to be submitted to the advancement > > process, please send a note to the WG saying so. > > > > 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 From syslog-bounces@lists.ietf.org Wed Sep 13 15:28:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNaO7-0005XG-8n; Wed, 13 Sep 2006 15:27:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNaO5-0005X6-VF for syslog@ietf.org; Wed, 13 Sep 2006 15:27:09 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNaO3-0001of-E8 for syslog@ietf.org; Wed, 13 Sep 2006 15:27:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 13 Sep 2006 12:27:07 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8DJR6go026593 for ; Wed, 13 Sep 2006 12:27:06 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8DJR61F001652 for ; Wed, 13 Sep 2006 12:27:06 -0700 (PDT) Date: Wed, 13 Sep 2006 12:27:06 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=427; t=1158175626; x=1159039626; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Liaison=20from=20the=20OIF; X=v=3Dcisco.com=3B=20h=3DLRACh/v/errBHf+kjN56hHv4qss=3D; b=ZAoBGqWk3GzdbT5QyZJXLnyzt4bIDHoNOh6/w14yvV4i9jhvVKrII1eQqIiJGcaV+djjIRY2 5wmlgL08Wo2G9lm8NMrjIpyHRZ/g5UZODXY9JOKnwGqWxS8KLFmx+/9+; Authentication-Results: sj-dkim-4.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Syslog] Liaison from the OIF X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, We've received a liaison letter from the OIF. It's been accepted by the IETF Secretariat and posted in the Liaison Statement repository. https://datatracker.ietf.org/public/liaisons.cgi Please take a moment to review the importance of our work to the OAM&P Working Group of the Optical Internetworking Forum. This is a stong endorsement that our efforts are on the right track. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Sep 13 16:35:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNbRU-0008MS-68; Wed, 13 Sep 2006 16:34:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNbRT-0008MH-Fe for syslog@ietf.org; Wed, 13 Sep 2006 16:34:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNbRP-0002q6-4h for syslog@ietf.org; Wed, 13 Sep 2006 16:34:43 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 13 Sep 2006 13:34:38 -0700 X-IronPort-AV: i="4.09,160,1157353200"; d="scan'208"; a="443219379:sNHT27485468" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8DKYcsu006360 for ; Wed, 13 Sep 2006 13:34:38 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8DKYcQW028325 for ; Wed, 13 Sep 2006 13:34:38 -0700 (PDT) Date: Wed, 13 Sep 2006 13:34:38 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=738; t=1158179678; x=1159043678; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:Chris=20Lonvick=20 |Subject:Diffs=20on=20-protocol=20and=20-transport-udp; X=v=3Dcisco.com=3B=20h=3DFlGgRjsLh5v7ij6i7Q+3NtGl4Zc=3D; b=QZwS9kplz/+wl7WwTX9y64Xlw25Dpe5816a4WpPTDlLI4Ogbaa6Z3QiA0lwpk8+M/l4eofe/ FXtfpdt/ZneWl1pqD3pVfwGpLRAFDCbJGsCiHyPJVjkZPc60pnIzlv/R; Authentication-Results: sj-dkim-4.cisco.com; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Syslog] Diffs on -protocol and -transport-udp X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, We need some more reviews of our documents. There has been some discussion that the documents havn't changed much since the last time we went through a WGLC. I've made some diffs of -protocol and of -transport-udp so you can see what changes have been made. Diff from protocol-14 and protocol-17 http://www.employees.org/~lonvick/diff-14-17.html Diff from transport-udp-05 and transport-udp-07 http://www.employees.org/~lonvick/diff-udp-07-05.html Please look these over and comment to the WG list that you have done so. At a minimum your review to the group should be that you have read the document and are satisfied with its quality and content that it can become an RFC. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Sep 18 03:19:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNU-00018c-DC; Mon, 18 Sep 2006 03:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNT-00015U-1V for syslog@ietf.org; Mon, 18 Sep 2006 03:17:15 -0400 Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPDH1-0000cL-31 for syslog@ietf.org; Mon, 18 Sep 2006 03:10:35 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id E0B7C9C00C; Mon, 18 Sep 2006 09:14:37 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13912-07; Mon, 18 Sep 2006 09:14:33 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 27E129C00B; Mon, 18 Sep 2006 09:14:33 +0200 (CEST) Content-class: urn:content-classes:message Subject: RE: [Syslog] WGLC and document advancement MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Sep 2006 09:10:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174EB1@grfint2.intern.adiscon.com> In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA174E97@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] WGLC and document advancement thread-index: AcbTazxKWN+wJ+TuQjuypiB/M6ifcAAOplZQAdKgPCA= From: "Rainer Gerhards" To: "David Harrington" , X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org WG, still no WGLC comments or any further responses... Let me share my deep frustration with you. I have cautioned against low participation levels last year when the question was if the WG should be concluded or continue to work. Then, the overall opinion was that there were sufficient interest in the topic. With that on my mind, I put another round of effort into syslog-protocol. I am now working on this for several years. I spent considerable work on it. Each time when it looked close to finish, either some radical new thoughts came in (which is fine), an old issue was re-itereated (which I do not consider to be OK) or some other unexpected show-stopper showed up. This time, it is the insufficient review. I am thoroughly disappointed and now need to think that all the time I put into this effort is wasted. This is quite regrettable. However, I do not intend to spent any more time on it without the *solid* indication that the work can be completed and published. As such, I will NOT make any further edits at this time and I will also hold my planned review of other WG documents. I will also refrain from commenting on any technical issues. Probably the best option at this stage would be to recommend to the IESG to finally conclude the WG. Thanks, Rainer=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Saturday, September 09, 2006 2:34 AM > To: David Harrington; syslog@ietf.org > Subject: RE: [Syslog] WGLC and document advancement >=20 > David, >=20 > Thanks for the reminder. >=20 > I have read -transport-tls several times, only been unable to have a > close look at the latest increment. To my understanding,=20 > there were only > minor changes to the document, so I am still happy with it. >=20 > I am concerned about the lack of feedback to my response to your > concerns on the "enc" SD-ID and transparency of MSG and=20 > STRUCTURED-DATA > in -protocol. I am hesitant to do any edits until there has been any > final discussion of these issues (reminder: I am most probably able to > edit starting September, 18th). >=20 > I have roughly reviewed -transport-tls (due to my time=20 > constraints). All > in all, it looks good enough to me. My main concerns have already been > addressed by adding the version number. I think, however, this point > needs some more discussion.=20 >=20 > There are many other points in -tls that could be discussed.=20 > HOWEVER, I > think discussing any of them now would make us miss our=20 > milestone. What > is there is well enough. It could be better. Let's do that at later > stage (version field permits this).=20 >=20 > We have been discussing syslog-protocol and -tls (and the work leading > to it) for 3 or 4 years now, often going in circles. Participation > levels have varied greatly. My personal opinion is that many folks are > finally bored with going ever and ever over the same arguments. But I > may be wrong. Getting some work done would definitely help us. >=20 > We should not aim for the perfect. In an ideal world, we=20 > would have only > ideal solutions. But we do not life in an ideal world. If NASA feels > strong enough to launch a shuttle with an imperfect fuel=20 > cell, we should > probably feel strong enough in putting some non-ideal but obviously > useful work to completion. So please comment on the drafts and open > issues. >=20 > Rainer > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > > Sent: Friday, September 08, 2006 1:23 PM > > To: syslog@ietf.org > > Subject: [Syslog] WGLC and document advancement > >=20 > > Hi, > >=20 > > There are good things and bad things that come with having a new WG > > co-chair. > > I think I have helped the WG by driving the completion of=20 > milestones. > > That's the good part. > > The bad part is I bring my own opinions of what adequate=20 > review means. > >=20 > > The IETF has started using a new process, called document=20 > shepherding, > > for the advancement of documents to the standards-track. The chairs > > are given much more responsibility and authority to decide whether > > documents are ready for advancement. They are expected to write up > > their analyses of WG issues, consensus, and degree of review of the > > documents being submitted, and these analyses will be reviewed at > > every step of the process after this point, as the members=20 > of the IESG > > try to determine whether the document really is ready for advancment > > to standards-track. You can see the details they expect us=20 > to provide > > by reading draft-ietf-proto-wgchair-doc-shepherding-07=20 > (which has been > > expanded quite a bit from the -05- draft used during your earlier > > WGLCs). > >=20 > > I have shepherded a number of documents through the process, and I > > know how difficult it can be to get documents through the=20 > process, and > > how much the documents can be delayed during the standards-approval > > process if they are not really ready for submission to that process. > >=20 > > I am concerned that the documents have not gotten adequate review > > during WGLC. There have been very few comments made, and I=20 > would like > > to see more reviews done by the members of the WG for each of these > > documents.=20 > >=20 > > If you have problems with the documents, speak up now, so the chairs > > can be sure your concerns are recognized and have been addressed.=20 > >=20 > > If you have read the document, and found no important problems and > > have no significant objections to the document, and belive=20 > it is ready > > to be submitted to the advancement process, please send a=20 > note to the > > WG saying so.=20 > >=20 > > David Harrington > > dharrington@huawei.com=20 > > dbharrington@comcast.net > > ietfdbh@comcast.net > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Sep 18 03:37:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDgx-0008O1-E4; Mon, 18 Sep 2006 03:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDgw-0008Nu-3h for syslog@ietf.org; Mon, 18 Sep 2006 03:37:22 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPDgr-0007oy-Ar for syslog@ietf.org; Mon, 18 Sep 2006 03:37:22 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5S0057J2KV3I@szxga01-in.huawei.com> for syslog@ietf.org; Mon, 18 Sep 2006 15:38:56 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5S0015P2KVR1@szxga01-in.huawei.com> for syslog@ietf.org; Mon, 18 Sep 2006 15:38:55 +0800 (CST) Received: from m19684 ([10.111.12.92]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5S00FWW2MPW1@szxml03-in.huawei.com> for syslog@ietf.org; Mon, 18 Sep 2006 15:40:04 +0800 (CST) Date: Mon, 18 Sep 2006 15:35:04 +0800 From: Miao Fuyou Subject: RE: [Syslog] Diffs on -protocol and -transport-udp In-reply-to: To: 'Chris Lonvick' , syslog@ietf.org Message-id: <011901c6daf4$f554f960$5c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbXdDJ/nMvt3FP4Tgu7CbJyHkQORADgDg2A X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I had reviewed -protocol, -udp and -signing, and with several minor comments on -protocol and -signing. I believe the documents are in good quality for being published as RFCs. Thanks! Miao > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Thursday, September 14, 2006 4:35 AM > To: syslog@ietf.org > Subject: [Syslog] Diffs on -protocol and -transport-udp > > Hi Folks, > > We need some more reviews of our documents. There has been > some discussion that the documents havn't changed much since > the last time we went through a WGLC. I've made some diffs > of -protocol and of -transport-udp so you can see what > changes have been made. > > Diff from protocol-14 and protocol-17 > http://www.employees.org/~lonvick/diff-14-17.html > > Diff from transport-udp-05 and transport-udp-07 > http://www.employees.org/~lonvick/diff-udp-07-05.html > > Please look these over and comment to the WG list that you > have done so. > At a minimum your review to the group should be that you have > read the document and are satisfied with its quality and > content that it can become an RFC. > > Thanks, > Chris > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Mon Sep 18 10:05:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPJjO-0005JZ-9E; Mon, 18 Sep 2006 10:04:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPJjL-0005J5-LK for syslog@ietf.org; Mon, 18 Sep 2006 10:04:16 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPJjK-0003Mz-5j for syslog@ietf.org; Mon, 18 Sep 2006 10:04:15 -0400 Received: from pc6 (1Cust72.tnt14.lnd4.gbr.da.uu.net [62.188.143.72]) by galaxy.systems.pipex.net (Postfix) with SMTP id 71DB1E00097F; Mon, 18 Sep 2006 15:03:58 +0100 (BST) Message-ID: <10c901c6db22$164db440$0601a8c0@pc6> From: "tom.petch" To: "Miao Fuyou" , "'Balazs Scheidler'" , "'Chris Lonvick'" References: <012701c6d25e$82deb4f0$5c0c6f0a@china.huawei.com> Subject: Re: version field in syslog-tls - was: RE: [Syslog] Working GroupLastCall: syslog-tls document Date: Mon, 18 Sep 2006 09:22:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.2 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Apologies for my absence last week. Comments below Tom Petch ----- Original Message ----- From: "Miao Fuyou" To: "'tom.petch'" ; "'Balazs Scheidler'" ; "'Chris Lonvick'" Cc: Sent: Thursday, September 07, 2006 11:17 AM Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working GroupLastCall: syslog-tls document > > Starting from TCP and then upgrading to tls is quite different to current > tls transport mapping document. If we decide to do UPGRADING, we may first > need a TCP transport mapping for Syslog, and then define a specific string > to indicate the other side to upgrade to TLS. I am NOT suggesting that we have a TCP transport which can be switched dynamically to be or not be TLS; that was not my intended meaning of the words I used.. Rather I was saying that other applications, forget how they got there, found it useful to have a string at the front stating their intentions, eg to use TLS. Of course, no matter how simple, like a single digit for a version number, this is in some sense an application protocol. What does the recipient do if it agrees, what if it disagrees? Terminating the connection may cause the transmitter to try again and then what? All soluble problems. I also think that hard coding this 'information' into a well known port is wrong. Ports may or may not be in short supply but the management associated with them by anyone with firewall or gateway, ie many if not most enterprises. is a pain so I am very much of the view to keep the number of ports few in number, and reuse them by changing the initial string. We currently assume Syslog has > a IANA allocated port for tls transport mapping, we may not need such > complexity on upgrading. > > FYI, HTTP has two tls mechansims: RFC2818(standards track) is similiar to > this draft, RFC2817(Informational) is on upgrading. > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Wednesday, September 06, 2006 2:51 AM > > To: Balazs Scheidler; Chris Lonvick > > Cc: syslog@ietf.org > > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > > Working GroupLastCall: syslog-tls document > > > > ----- Original Message ----- > > From: "Balazs Scheidler" > > To: "Chris Lonvick" > > Cc: > > Sent: Tuesday, September 05, 2006 9:18 AM > > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > > Working GroupLast > > Call: syslog-tls document > > > > > > > On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote: > > > > Hi All, > > > > > > > > Please do consider the version field. If we don't have one, we > > > > would have to live forever with the decisions we are making now. > > > > Having a version number in there would allow a future group to > > > > re-decide things (like byte-count v. special character) > > and to just > > > > change the version number rather than go asking for a new > > port number - or have a flag day. > > > > > > > > Please review the document and send in your thoughts on this. > > > > > > Sending the version field is a good idea in general, however I feel > > > that adding it to _every single_ message in a conversation is too > > > redundant, apart from the extra bandwidth used, it causes > > ambiguities > > > what to do when different messages use a different version number. > > > > > > The version should be associated with the channel, and not > > individual > > > messages. > > > > > > Having a simple negotiation at the start would IMHO be way better. > > > Something like: > > > > > > HELLO > > > OK > > > START > > > OK > > > > > > > > I too like starting with a simple negotiation. I notice that > > other applications that started with TCP and then added > > security have used character strings such as AUTH TLS which > > has the advantage of readily adding in SSH (or anything else) > > in the future. > > I also like being able to add later a choice as to which end > > is client and which server since I foresee problems here with > > security credentials (most other applications have the server > > on a well-connected device well able to verify secuirty > > credentials, something a remote network box is less well able to do). > > > > Tom Petch > > > > > -- > > > Bazsi > > > > > > > > > _______________________________________________ > > > 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 From syslog-bounces@lists.ietf.org Mon Sep 18 14:59:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOKJ-0007LX-Fu; Mon, 18 Sep 2006 14:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOKI-0007LS-OZ for syslog@ietf.org; Mon, 18 Sep 2006 14:58:42 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPOKH-0008Vb-B4 for syslog@ietf.org; Mon, 18 Sep 2006 14:58:42 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc14) with SMTP id <20060918185819b1400krhufe>; Mon, 18 Sep 2006 18:58:40 +0000 From: "David Harrington" To: "'tom.petch'" , "'Miao Fuyou'" , "'Balazs Scheidler'" , "'Chris Lonvick'" Subject: RE: version field in syslog-tls - was: RE: [Syslog] WorkingGroupLastCall: syslog-tls document Date: Mon, 18 Sep 2006 14:56:28 -0400 Message-ID: <01f901c6db54$325efea0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbbK3zFDadpxo/eTmGayl9gTzlrmgAIZvYQ In-reply-to: <10c901c6db22$164db440$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Tom, Welcome back. I agree that section 5.3.2 should describe the behavior of the receiver if a message with a protocol version that is not supported is received, and it should recognize that future version #s are possible in this position. Could you suggest text for this? Can you identify which applications find it useful to have a string at the front, and what was found useful about it? Would the string be required, and the text be standard? I would be interested in seeing others' comments on this suggestion. Personally, I think using an assigned port serves the purpose of differentiating syslog from syslog/tls for receiving applications and for applications such as firewalls; use of a reserved port number alleviates the need for the string and is consistent with other Internet standards. Other protocols retrofitted to run over secure protocols have been assigned separate ports to differentiate the secure and non-secure versions of the protocol. Presumably there have been good justifications for the IESG to approve such port assignments. BCP 72, RFC 3552 section 4.5.2 supports the practice. I will note that so many applications are retrofitting to TLS that maybe IANA should consider port assignment ranges for udp, tcp, and tls/ssl ;-) David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Monday, September 18, 2006 3:23 AM > To: Miao Fuyou; 'Balazs Scheidler'; 'Chris Lonvick' > Cc: syslog@ietf.org > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > WorkingGroupLastCall: syslog-tls document > > Apologies for my absence last week. Comments below > > Tom Petch > ----- Original Message ----- > From: "Miao Fuyou" > To: "'tom.petch'" ; "'Balazs Scheidler'" > ; "'Chris Lonvick'" > Cc: > Sent: Thursday, September 07, 2006 11:17 AM > Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working > GroupLastCall: syslog-tls document > > > > > > Starting from TCP and then upgrading to tls is quite > different to current > > tls transport mapping document. If we decide to do > UPGRADING, we may first > > need a TCP transport mapping for Syslog, and then define a > specific string > > to indicate the other side to upgrade to TLS. > > I am NOT suggesting that we have a TCP transport which can be switched > dynamically to be or not be TLS; that was not my intended > meaning of the words I > used.. > > Rather I was saying that other applications, forget how they > got there, found it > useful to have a string at the front stating their > intentions, eg to use TLS. > Of course, no matter how simple, like a single digit for a > version number, this > is in some sense an application protocol. What does the > recipient do if it > agrees, what if it disagrees? Terminating the connection may > cause the > transmitter to try again and then what? All soluble problems. > > I also think that hard coding this 'information' into a well > known port is > wrong. Ports may or may not be in short supply but the > management associated > with them by anyone with firewall or gateway, ie many if not > most enterprises. > is a pain so I am very much of the view to keep the number of > ports few in > number, and reuse them by changing the initial string. > > > > > > > We currently assume Syslog has > > a IANA allocated port for tls transport mapping, we may not > need such > > complexity on upgrading. > > > > FYI, HTTP has two tls mechansims: RFC2818(standards track) > is similiar to > > this draft, RFC2817(Informational) is on upgrading. > > > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Sent: Wednesday, September 06, 2006 2:51 AM > > > To: Balazs Scheidler; Chris Lonvick > > > Cc: syslog@ietf.org > > > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > > > Working GroupLastCall: syslog-tls document > > > > > > ----- Original Message ----- > > > From: "Balazs Scheidler" > > > To: "Chris Lonvick" > > > Cc: > > > Sent: Tuesday, September 05, 2006 9:18 AM > > > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > > > Working GroupLast > > > Call: syslog-tls document > > > > > > > > > > On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote: > > > > > Hi All, > > > > > > > > > > Please do consider the version field. If we don't > have one, we > > > > > would have to live forever with the decisions we are > making now. > > > > > Having a version number in there would allow a future group to > > > > > re-decide things (like byte-count v. special character) > > > and to just > > > > > change the version number rather than go asking for a new > > > port number - or have a flag day. > > > > > > > > > > Please review the document and send in your thoughts on this. > > > > > > > > Sending the version field is a good idea in general, > however I feel > > > > that adding it to _every single_ message in a > conversation is too > > > > redundant, apart from the extra bandwidth used, it causes > > > ambiguities > > > > what to do when different messages use a different > version number. > > > > > > > > The version should be associated with the channel, and not > > > individual > > > > messages. > > > > > > > > Having a simple negotiation at the start would IMHO be > way better. > > > > Something like: > > > > > > > > HELLO > > > > OK > > > > START > > > > OK > > > > > > > > > > > I too like starting with a simple negotiation. I notice that > > > other applications that started with TCP and then added > > > security have used character strings such as AUTH TLS which > > > has the advantage of readily adding in SSH (or anything else) > > > in the future. > > > I also like being able to add later a choice as to which end > > > is client and which server since I foresee problems here with > > > security credentials (most other applications have the server > > > on a well-connected device well able to verify secuirty > > > credentials, something a remote network box is less well > able to do). > > > > > > Tom Petch > > > > > > > -- > > > > Bazsi > > > > > > > > > > > > _______________________________________________ > > > > 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 From syslog-bounces@lists.ietf.org Mon Sep 18 15:14:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOZI-0005QG-Pq; Mon, 18 Sep 2006 15:14:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOZG-0005Q5-R0 for syslog@ietf.org; Mon, 18 Sep 2006 15:14:10 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPOZE-0002zS-Ck for syslog@ietf.org; Mon, 18 Sep 2006 15:14:10 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc13) with SMTP id <20060918191357b1300perpde>; Mon, 18 Sep 2006 19:14:07 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] WGLC and document advancement Date: Mon, 18 Sep 2006 15:12:05 -0400 Message-ID: <01fd01c6db56$5ac8fe70$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbTazxKWN+wJ+TuQjuypiB/M6ifcAAOplZQAdKgPCAAGPeHYA== In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA174EB1@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, Welcome back. I hope the vacation with family was relaxing and fun. I understand your frustration. Let me be clear however, that requiring reviews during WGLC is certainly not a new requirement; reviews during WGLC have ALWAYS been a requirement of work being submitted to the IESG for advancement. Working group chairs got lax for a while, and submitted documents that were obviously not ready for advancement. The IESG now requires better reviews by the WG before accepting documents for advancement. If the WG provides the reviews, I believe we stand a very good chance of finally getting these through the process to RFCs. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Monday, September 18, 2006 3:10 AM > To: David Harrington; syslog@ietf.org > Subject: RE: [Syslog] WGLC and document advancement > > WG, > > still no WGLC comments or any further responses... > > Let me share my deep frustration with you. I have cautioned > against low > participation levels last year when the question was if the > WG should be > concluded or continue to work. Then, the overall opinion was > that there > were sufficient interest in the topic. With that on my mind, I put > another round of effort into syslog-protocol. I am now working on this > for several years. I spent considerable work on it. Each time when it > looked close to finish, either some radical new thoughts came > in (which > is fine), an old issue was re-itereated (which I do not consider to be > OK) or some other unexpected show-stopper showed up. This time, it is > the insufficient review. I am thoroughly disappointed and now need to > think that all the time I put into this effort is wasted. > This is quite > regrettable. > > However, I do not intend to spent any more time on it without the > *solid* indication that the work can be completed and published. As > such, I will NOT make any further edits at this time and I will also > hold my planned review of other WG documents. I will also refrain from > commenting on any technical issues. Probably the best option at this > stage would be to recommend to the IESG to finally conclude the WG. > > Thanks, > Rainer > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Saturday, September 09, 2006 2:34 AM > > To: David Harrington; syslog@ietf.org > > Subject: RE: [Syslog] WGLC and document advancement > > > > David, > > > > Thanks for the reminder. > > > > I have read -transport-tls several times, only been unable to have a > > close look at the latest increment. To my understanding, > > there were only > > minor changes to the document, so I am still happy with it. > > > > I am concerned about the lack of feedback to my response to your > > concerns on the "enc" SD-ID and transparency of MSG and > > STRUCTURED-DATA > > in -protocol. I am hesitant to do any edits until there has been any > > final discussion of these issues (reminder: I am most > probably able to > > edit starting September, 18th). > > > > I have roughly reviewed -transport-tls (due to my time > > constraints). All > > in all, it looks good enough to me. My main concerns have > already been > > addressed by adding the version number. I think, however, this point > > needs some more discussion. > > > > There are many other points in -tls that could be discussed. > > HOWEVER, I > > think discussing any of them now would make us miss our > > milestone. What > > is there is well enough. It could be better. Let's do that at later > > stage (version field permits this). > > > > We have been discussing syslog-protocol and -tls (and the > work leading > > to it) for 3 or 4 years now, often going in circles. Participation > > levels have varied greatly. My personal opinion is that > many folks are > > finally bored with going ever and ever over the same > arguments. But I > > may be wrong. Getting some work done would definitely help us. > > > > We should not aim for the perfect. In an ideal world, we > > would have only > > ideal solutions. But we do not life in an ideal world. If NASA feels > > strong enough to launch a shuttle with an imperfect fuel > > cell, we should > > probably feel strong enough in putting some non-ideal but obviously > > useful work to completion. So please comment on the drafts and open > > issues. > > > > Rainer > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Friday, September 08, 2006 1:23 PM > > > To: syslog@ietf.org > > > Subject: [Syslog] WGLC and document advancement > > > > > > Hi, > > > > > > There are good things and bad things that come with > having a new WG > > > co-chair. > > > I think I have helped the WG by driving the completion of > > milestones. > > > That's the good part. > > > The bad part is I bring my own opinions of what adequate > > review means. > > > > > > The IETF has started using a new process, called document > > shepherding, > > > for the advancement of documents to the standards-track. > The chairs > > > are given much more responsibility and authority to decide whether > > > documents are ready for advancement. They are expected to write up > > > their analyses of WG issues, consensus, and degree of > review of the > > > documents being submitted, and these analyses will be reviewed at > > > every step of the process after this point, as the members > > of the IESG > > > try to determine whether the document really is ready for > advancment > > > to standards-track. You can see the details they expect us > > to provide > > > by reading draft-ietf-proto-wgchair-doc-shepherding-07 > > (which has been > > > expanded quite a bit from the -05- draft used during your earlier > > > WGLCs). > > > > > > I have shepherded a number of documents through the process, and I > > > know how difficult it can be to get documents through the > > process, and > > > how much the documents can be delayed during the > standards-approval > > > process if they are not really ready for submission to > that process. > > > > > > I am concerned that the documents have not gotten adequate review > > > during WGLC. There have been very few comments made, and I > > would like > > > to see more reviews done by the members of the WG for > each of these > > > documents. > > > > > > If you have problems with the documents, speak up now, so > the chairs > > > can be sure your concerns are recognized and have been addressed. > > > > > > If you have read the document, and found no important problems and > > > have no significant objections to the document, and belive > > it is ready > > > to be submitted to the advancement process, please send a > > note to the > > > WG saying so. > > > > > > 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 From syslog-bounces@lists.ietf.org Tue Sep 19 10:20:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgQv-00071p-3D; Tue, 19 Sep 2006 10:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPgQs-0006xc-RW for syslog@ietf.org; Tue, 19 Sep 2006 10:18:42 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPgMG-0007wN-FG for syslog@ietf.org; Tue, 19 Sep 2006 10:13:59 -0400 Received: from pc6 (1Cust96.tnt16.lnd4.gbr.da.uu.net [62.188.145.96]) by blaster.systems.pipex.net (Postfix) with SMTP id 89F62E000542; Tue, 19 Sep 2006 15:13:40 +0100 (BST) Message-ID: <001701c6dbec$9a1a0880$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Miao Fuyou'" , "'Balazs Scheidler'" , "'Chris Lonvick'" References: <01f901c6db54$325efea0$0600a8c0@china.huawei.com> Subject: protocol was Re: version field in syslog-tls - was: RE: [Syslog] WorkingGroupLastCall: syslog-tls document Date: Tue, 19 Sep 2006 15:05:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; "'Miao Fuyou'" ; "'Balazs Scheidler'" ; "'Chris Lonvick'" Cc: Sent: Monday, September 18, 2006 8:56 PM Subject: RE: version field in syslog-tls - was: RE: [Syslog] WorkingGroupLastCall: syslog-tls document > > I agree that section 5.3.2 should describe the behavior of the > receiver if a message with a protocol version that is not supported is > received, and it should recognize that future version #s are possible > in this position. Could you suggest text for this? > Not yet; I do not yet see one obvious right action to text. Rather I see choices:- a) receiver terminates session unilaterally; currently this is only allowed after an 'idle timeout' and closure alert. 'protocol_version' alert would seem appropriate; do the TLS stacks allow syslog to generate this?. b) receiver returns syslog text message 'not ok' which rather implies a message 'ok' when it is, all of which is alien to this simplex application. c) receiver terminates session. simple, but likely to cause the sender to keep retrying for a while. Thoughts? Tom Petch > Can you identify which applications find it useful to have a string at > the front, and what was found useful about it? Would the string be > required, and the text be standard? I would be interested in seeing > others' comments on this suggestion. > > Personally, I think using an assigned port serves the purpose of > differentiating syslog from syslog/tls for receiving applications and > for applications such as firewalls; use of a reserved port number > alleviates the need for the string and is consistent with other > Internet standards. Other protocols retrofitted to run over secure > protocols have been assigned separate ports to differentiate the > secure and non-secure versions of the protocol. Presumably there have > been good justifications for the IESG to approve such port > assignments. BCP 72, RFC 3552 section 4.5.2 supports the practice. > > I will note that so many applications are retrofitting to TLS that > maybe IANA should consider port assignment ranges for udp, tcp, and > tls/ssl ;-) > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Monday, September 18, 2006 3:23 AM > > To: Miao Fuyou; 'Balazs Scheidler'; 'Chris Lonvick' > > Cc: syslog@ietf.org > > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > > WorkingGroupLastCall: syslog-tls document > > > > Apologies for my absence last week. Comments below > > > > Tom Petch > > ----- Original Message ----- > > From: "Miao Fuyou" > > To: "'tom.petch'" ; "'Balazs Scheidler'" > > ; "'Chris Lonvick'" > > Cc: > > Sent: Thursday, September 07, 2006 11:17 AM > > Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working > > GroupLastCall: syslog-tls document > > > > > > > > > > Starting from TCP and then upgrading to tls is quite > > different to current > > > tls transport mapping document. If we decide to do > > UPGRADING, we may first > > > need a TCP transport mapping for Syslog, and then define a > > specific string > > > to indicate the other side to upgrade to TLS. > > > > I am NOT suggesting that we have a TCP transport which can be > switched > > dynamically to be or not be TLS; that was not my intended > > meaning of the words I > > used.. > > > > Rather I was saying that other applications, forget how they > > got there, found it > > useful to have a string at the front stating their > > intentions, eg to use TLS. > > Of course, no matter how simple, like a single digit for a > > version number, this > > is in some sense an application protocol. What does the > > recipient do if it > > agrees, what if it disagrees? Terminating the connection may > > cause the > > transmitter to try again and then what? All soluble problems. > > > > I also think that hard coding this 'information' into a well > > known port is > > wrong. Ports may or may not be in short supply but the > > management associated > > with them by anyone with firewall or gateway, ie many if not > > most enterprises. > > is a pain so I am very much of the view to keep the number of > > ports few in > > number, and reuse them by changing the initial string. > > > > > > > > > > > > > > We currently assume Syslog has > > > a IANA allocated port for tls transport mapping, we may not > > need such > > > complexity on upgrading. > > > > > > FYI, HTTP has two tls mechansims: RFC2818(standards track) > > is similiar to > > > this draft, RFC2817(Informational) is on upgrading. > > > > > > > -----Original Message----- > > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > > Sent: Wednesday, September 06, 2006 2:51 AM > > > > To: Balazs Scheidler; Chris Lonvick > > > > Cc: syslog@ietf.org > > > > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > > > > Working GroupLastCall: syslog-tls document > > > > > > > > ----- Original Message ----- > > > > From: "Balazs Scheidler" > > > > To: "Chris Lonvick" > > > > Cc: > > > > Sent: Tuesday, September 05, 2006 9:18 AM > > > > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > > > > Working GroupLast > > > > Call: syslog-tls document > > > > > > > > > > > > > On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote: > > > > > > Hi All, > > > > > > > > > > > > Please do consider the version field. If we don't > > have one, we > > > > > > would have to live forever with the decisions we are > > making now. > > > > > > Having a version number in there would allow a future group > to > > > > > > re-decide things (like byte-count v. special character) > > > > and to just > > > > > > change the version number rather than go asking for a new > > > > port number - or have a flag day. > > > > > > > > > > > > Please review the document and send in your thoughts on > this. > > > > > > > > > > Sending the version field is a good idea in general, > > however I feel > > > > > that adding it to _every single_ message in a > > conversation is too > > > > > redundant, apart from the extra bandwidth used, it causes > > > > ambiguities > > > > > what to do when different messages use a different > > version number. > > > > > > > > > > The version should be associated with the channel, and not > > > > individual > > > > > messages. > > > > > > > > > > Having a simple negotiation at the start would IMHO be > > way better. > > > > > Something like: > > > > > > > > > > HELLO > > > > > OK > > > > > START > > > > > OK > > > > > > > > > > > > > > I too like starting with a simple negotiation. I notice that > > > > other applications that started with TCP and then added > > > > security have used character strings such as AUTH TLS which > > > > has the advantage of readily adding in SSH (or anything else) > > > > in the future. > > > > I also like being able to add later a choice as to which end > > > > is client and which server since I foresee problems here with > > > > security credentials (most other applications have the server > > > > on a well-connected device well able to verify secuirty > > > > credentials, something a remote network box is less well > > able to do). > > > > > > > > Tom Petch > > > > > > > > > -- > > > > > Bazsi > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 From syslog-bounces@lists.ietf.org Tue Sep 19 22:39:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPry9-0006yB-41; Tue, 19 Sep 2006 22:37:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPry8-0006wx-RG for syslog@ietf.org; Tue, 19 Sep 2006 22:37:48 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPry7-0003jy-3I for syslog@ietf.org; Tue, 19 Sep 2006 22:37:48 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5V00D75ESLK9@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 20 Sep 2006 10:55:33 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J5V00HDOESL5R@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 20 Sep 2006 10:55:33 +0800 (CST) Received: from m19684 ([10.111.12.92]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J5V008LEEITOE@szxml04-in.huawei.com> for syslog@ietf.org; Wed, 20 Sep 2006 10:49:44 +0800 (CST) Date: Wed, 20 Sep 2006 10:36:52 +0800 From: Miao Fuyou Subject: RE: protocol was Re: version field in syslog-tls - was: RE: [Syslog] WorkingGroupLastCall: syslog-tls document In-reply-to: <001701c6dbec$9a1a0880$0601a8c0@pc6> To: "'tom.petch'" , 'David Harrington' , 'Balazs Scheidler' , 'Chris Lonvick' Message-id: <00b101c6dc5d$a195dbe0$5c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acbb9d0ggXWc3dFxQAalE7B+/snL/gAWQpUw X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Comments inline. > Not yet; I do not yet see one obvious right action to text. > Rather I see > choices:- > a) receiver terminates session unilaterally; currently this > is only allowed after an 'idle timeout' and closure alert. > 'protocol_version' alert would seem appropriate; do the TLS > stacks allow syslog to generate this?. > "protocol_version" is only for TLS version, it may not be inappropriate to indicate unsupporting application protocol version, it also may invoke another TLS handshaking. I checked "user_canceled" alert, TLS suggests (not strongly) that it can only be permitted during TLS handshaking, not after handshaking. Another option is to use "internal_error" alert, it is not very proper to meet this requirement. I tend to use "user_canceled" to indicate that the server does not support the version. Openssl has a fucntion ssl3_send_alert() to serve this purpose. > b) receiver returns syslog text message 'not ok' which rather > implies a message 'ok' when it is, all of which is alien to > this simplex application. > > c) receiver terminates session. simple, but likely to cause > the sender to keep retrying for a while. > > Thoughts? > > Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Sep 20 16:33:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8kN-0002LX-TV; Wed, 20 Sep 2006 16:32:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ8kM-0002Iz-MA for syslog@ietf.org; Wed, 20 Sep 2006 16:32:42 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ8kL-0002dG-Ax for syslog@ietf.org; Wed, 20 Sep 2006 16:32:42 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2006 13:32:41 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KKWekL008437; Wed, 20 Sep 2006 13:32:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8KKWe1M007603; Wed, 20 Sep 2006 13:32:40 -0700 (PDT) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 13:32:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Sep 2006 13:32:35 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB024E2D7D@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-syslog-sign-19.txt Thread-Index: Acbc8+g/jZl4SDWATEChWON8ntejRg== From: "Alexander Clemm \(alex\)" To: X-OriginalArrivalTime: 20 Sep 2006 20:32:37.0124 (UTC) FILETIME=[E9054C40:01C6DCF3] DKIM-Signature: a=rsa-sha1; q=dns; l=2988; t=1158784360; x=1159648360; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=22Alexander=20Clemm=20\(alex\)=22=20 |Subject:draft-ietf-syslog-sign-19.txt; X=v=3Dcisco.com=3B=20h=3D1Wh9Lt5SjFVLsSizY+segkpq8EY=3D; b=Ku+iYn9pTClFWM6/hwaSfDTlnbG3D0TgPK66nR0cPfXV0Oa0lBnXfXndYfL2n9RJYXZiWNr5 0bmfo4y17pmV4WMfUPKUUyH7ClWfscn1ciT6njOBmwxPdt4YIJ71m67s; Authentication-Results: sj-dkim-3.cisco.com; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dbharrington@comcast.net Subject: [Syslog] draft-ietf-syslog-sign-19.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hello, I have just posted a new revision of draft-ietf-syslog-sign-19.txt, which should be posted shortly, taking into account the comments that I have received. =20 The following is a summary of the updates that were made: =20 * Section 3: Added requirement for syslog message length of 2048 octets to be supported. It does not make sense to keep this one optional, as any truncation that were to occur will render the mechanism that is specified useless. =20 * Section 4:=20 - Clarified the distinction between the Signature Block and the message that carries the Signature Block. Made this distinction clearer by calling out a separate subsection (4.1) that deals specifically with the message. =20 - Made clear distinction of how to use syslog-sign in conjunction with syslog protocol, as well as with "traditional" syslog. =20 - For use with syslog-protocol, I added recommendations for how to populate the APP-NAME and MSGID fields, recommending "syslog" as APP-NAME and "sig" as MSG-ID. =20 - Likewise, added recommendation for PRI value to use. Recommended to use 110 (facility 13, severity 6). =20 - Reboot Session ID: Clarified that 0 value is to be used only when reboot session ID cannot be persisted across reboots, otherwise values between 1 and 9999999999 are to be used. - Made editorial clarifications to the explanations surrounding Signature Group and Signature Priority. Added recommendation to use a single SPRI value for messages with SG 0, and to use the PRI value of the carrying syslog message as that SPRI (i.e., 110). =20 - Made clarifications that hashes are to be sequenced, also clarified what is precisely subjected to the hash. =20 * Section 5: - Made editorial alignments to align chapter structure and headings with those of Section 4 - Analogous updates as for section 4: Clarified the distinction between the Certificate Block and the message that carries the Certificate Block. Made this distinction clearer by calling out a separate subsection that deals specifically with the message. Made clear distinction of how to use syslog-sign in conjunction with syslog protocol, as well as with "traditional" syslog. For use with syslog-protocol, I added recommendations for how to populate the APP-NAME and MSGID fields, recommending "syslog" as APP-NAME and "cert" as MSG-ID. =20 - Likewise, added recommendation for PRI value to use. Recommended to use 110 (facility 13, severity 6). =20 * Section 9:=20 - removed "Cookie" discussion - added request to add structured data to the associated registry (ssign and ssign-cert SD-IDs, with the corresponding PARAM-NAMEs) - added request to register the APP-NAME and MSGIDs introduced above. (A registry needs to be introduced for those, currently not suggested in syslog-protocol, need working group chairs to advise.) =20 Working group, please comment, example on the choice of PRI and APP-NAME. =20 Best regards --- Alex _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Sep 20 16:52:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ93R-0008KU-Ey; Wed, 20 Sep 2006 16:52:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ93P-00089v-Hi for syslog@ietf.org; Wed, 20 Sep 2006 16:52:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ93O-0005w1-8b for syslog@ietf.org; Wed, 20 Sep 2006 16:52:23 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 20 Sep 2006 13:52:21 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KKqLMj016225; Wed, 20 Sep 2006 13:52:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8KKqAZH014012; Wed, 20 Sep 2006 13:52:21 -0700 (PDT) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 13:52:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Sep 2006 13:52:15 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB024E2D94@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Very minor nit, section 6.2.1 of draft-ietf-syslog-protocol-17.txt Thread-Index: Acbc9qdyU5p08lykTdySpN3rO+Bqvg== From: "Alexander Clemm \(alex\)" To: "Rainer Gerhards" X-OriginalArrivalTime: 20 Sep 2006 20:52:16.0900 (UTC) FILETIME=[A838D440:01C6DCF6] DKIM-Signature: a=rsa-sha1; q=dns; l=364; t=1158785541; x=1159649541; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=22Alexander=20Clemm=20\(alex\)=22=20 |Subject:Very=20minor=20nit, =20section=206.2.1=20of=20draft-ietf-syslog-protocol- 17.txt; X=v=3Dcisco.com=3B=20h=3DokQcyzyg4y7uGcqwWbHWvj4E+D8=3D; b=GoV240+rNz0KzIIVJHu54op5Tc+FsxlImZE+pr0HegbBZFrOtr7K+pvowL/z7POKc4jPbkKx 9U/4ri2W8ow+mGDXFlNTOTE6INhSCO2SH6Bwm0mUVYK/R9lqiQrJYPhP; Authentication-Results: sj-dkim-4.cisco.com; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: syslog@ietf.org Subject: [Syslog] Very minor nit, section 6.2.1 of draft-ietf-syslog-protocol-17.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hello Rainer, I noticed that the current draft of draft-ietf-syslog-protocol-17.txt contains references to two notes (note 1 and note 2) in section 6.2.1, in the facility table; however there are no notes in the document. This is apparently a copy-paste error in acarry-over from RFC 3164 during which the notes got dropped. =20 Best regards --- Alex _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Sep 20 17:48:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ9uj-0007Gp-0p; Wed, 20 Sep 2006 17:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ9uh-0007Gh-TQ for syslog@ietf.org; Wed, 20 Sep 2006 17:47:27 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ9uf-0004UJ-9G for syslog@ietf.org; Wed, 20 Sep 2006 17:47:27 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 20 Sep 2006 14:47:25 -0700 X-IronPort-AV: i="4.09,193,1157353200"; d="scan'208"; a="323426949:sNHT51924680" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8KLlOSX005735; Wed, 20 Sep 2006 14:47:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8KLlNid028952; Wed, 20 Sep 2006 14:47:24 -0700 (PDT) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 14:47:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] MIB document decision Date: Wed, 20 Sep 2006 14:47:22 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB024E2DE4@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] MIB document decision Thread-Index: AcbDVXIR0mkM9n4XQiWuftjYDihcuADRebkQBZhGePA= From: "Alexander Clemm \(alex\)" To: "Miao Fuyou" , "Glenn M. Keeni" , X-OriginalArrivalTime: 20 Sep 2006 21:47:23.0588 (UTC) FILETIME=[5B296040:01C6DCFE] DKIM-Signature: a=rsa-sha1; q=dns; l=5836; t=1158788844; x=1159652844; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=22Alexander=20Clemm=20\(alex\)=22=20 |Subject:RE=3A=20[Syslog]=20MIB=20document=20decision; X=v=3Dcisco.com=3B=20h=3DsDR9YhHlgvDOEG7sSzCojN8xZAI=3D; b=Wz6cWb8+c4BjmldDxMG4NFYRQsvhC0BcPAVUkl67ZlMrAmmXQHy9UOBu9t03U3BZkzTGuJa7 LAnvPMoLyr7JKiJcyI11lmEmk/pp7TXFdxBr+ZMDglTCr8y0ATrih0MY; Authentication-Results: sj-dkim-5.cisco.com; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org 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 =3D number of times each Certificate Block should = be sent before the first message is sent. certResendDelay =3D maximum time delay in seconds to delay before = next redundant sending. certResendCount =3D maximum number of sent messages to delay before next redundant sending. Configuration Parameters for Signature Blocks sigNumberResends =3D number of times a Signature Block is resent. sigResendDelay =3D maximum time delay in seconds from original = sending to next redundant sending. sigResendCount =3D maximum number of sent messages to delay before = next redundant sending. In addition:=20 currentRebootSessionId =3D 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. =20 Possibly (although not absolutely required) sigSendDelay =3D maximum time delay until a Signature Block is sent, = in case it does not fill up with enough hashes. =20 Regards --- Alex -----Original Message----- From: Miao Fuyou [mailto:miaofy@huawei.com]=20 Sent: Wednesday, August 23, 2006 3:05 AM To: 'Glenn M. Keeni'; syslog@ietf.org Subject: RE: [Syslog] MIB document decision Hi,=20 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=20 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 >=20 > Dave, > Thanks for the review. I am in full agreement with the=20 > observations. > This > present document belongs to the 3164 era. Now that the protocol, udp=20 > documents are stable, it is time for an update. > The following are TBDs > 1. Update terminology to bring it incline with the protocol=20 > 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,=20 > such > as passwords or user names? What will be the impact ? > c. Is the management functionality adequate? > 6. Editorial nits. > MO=3D> managed objects > 7. Make the changes and submit the revised I-D >=20 > 1-4, 6-7 is doable. I will do it. I will look for WG input on item 5. > Particularly on 5c. >=20 > Cheers >=20 > 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=20 > > 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=20 > > 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?=20 > > MIB Doctors will expect a section entitled "Relationship to > other MIB > > Modules". > > See > >=20 > 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=20 > > 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 > > =20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ 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 From syslog-bounces@lists.ietf.org Fri Sep 22 07:25:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQj8J-0004xG-7u; Fri, 22 Sep 2006 07:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQj8H-0004wz-1o for syslog@ietf.org; Fri, 22 Sep 2006 07:23:49 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQj8E-0001gd-L3 for syslog@ietf.org; Fri, 22 Sep 2006 07:23:49 -0400 Received: from pc6 (1Cust250.tnt101.lnd4.gbr.da.uu.net [213.116.50.250]) by blaster.systems.pipex.net (Postfix) with SMTP id DE3FFE000529; Fri, 22 Sep 2006 12:23:32 +0100 (BST) Message-ID: <04a701c6de30$5255f7c0$0601a8c0@pc6> From: "tom.petch" To: "Miao Fuyou" , "'David Harrington'" , "'Chris Lonvick'" References: <00b101c6dc5d$a195dbe0$5c0c6f0a@china.huawei.com> Subject: Re: protocol was Re: version field in syslog-tls - was: RE: [Syslog] WorkingGroupLastCall: syslog-tls document Date: Fri, 22 Sep 2006 12:14:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Miao Fuyou" To: "'tom.petch'" ; "'David Harrington'" ; "'Balazs Scheidler'" ; "'Chris Lonvick'" Cc: Sent: Wednesday, September 20, 2006 4:36 AM Subject: RE: protocol was Re: version field in syslog-tls - was: RE: [Syslog] WorkingGroupLastCall: syslog-tls document > Comments inline. > > > Not yet; I do not yet see one obvious right action to text. > > Rather I see > > choices:- > > a) receiver terminates session unilaterally; currently this > > is only allowed after an 'idle timeout' and closure alert. > > 'protocol_version' alert would seem appropriate; do the TLS > > stacks allow syslog to generate this?. > > > > "protocol_version" is only for TLS version, it may not be inappropriate to > indicate unsupporting application protocol version, it also may invoke > another TLS handshaking. > > I checked "user_canceled" alert, TLS suggests (not strongly) that it can > only be permitted during TLS handshaking, not after handshaking. Another > option is to use "internal_error" alert, it is not very proper to meet this > requirement. I tend to use "user_canceled" to indicate that the server does > not support the version. Openssl has a fucntion ssl3_send_alert() to serve > this purpose. > I agree; TLS alerts are attractive but seem to lack a user extension which allows TLS applications to specify their own, context-specific ones, so using one of them is a fudge. Alternatively, creating our own application level 'ok' or 'not ok' seems more alien to syslog; I await any other suggestions. Tom Petch > > b) receiver returns syslog text message 'not ok' which rather > > implies a message 'ok' when it is, all of which is alien to > > this simplex application. > > > > c) receiver terminates session. simple, but likely to cause > > the sender to keep retrying for a while. > > > > Thoughts? > > > > Tom Petch > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Sep 25 10:53:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrnl-0001tY-6D; Mon, 25 Sep 2006 10:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrnf-0001pC-DD; Mon, 25 Sep 2006 10:51:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrnb-0002f5-Lb; Mon, 25 Sep 2006 10:51:11 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GRrnY-0001SN-JN; Mon, 25 Sep 2006 10:51:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DC06B175D6; Mon, 25 Sep 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GRrmU-0005Jb-CM; Mon, 25 Sep 2006 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 25 Sep 2006 10:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-sign-19.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Signed syslog Messages Author(s) : J. Kelsey, et al. Filename : draft-ietf-syslog-sign-19.txt Pages : 38 Date : 2006-9-25 This document describes a mechanism to add origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification draws upon the work defined in RFC xxxx, "The syslog Protocol", however it may be used atop any message delivery mechanism, even that defined in RFC 3164, "The BSD syslog Protocol", or in the RAW mode of "RFC 3195, "The Reliable Delivery of syslog". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-19.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-sign-19.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-sign-19.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-25092246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-sign-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-sign-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-25092246.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Mon Sep 25 12:51:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtex-0002Nm-Rx; Mon, 25 Sep 2006 12:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtew-0002IN-Nw for syslog@ietf.org; Mon, 25 Sep 2006 12:50:22 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRtUO-0001aD-Mw for syslog@ietf.org; Mon, 25 Sep 2006 12:39:31 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k8PGdQd29431 for ; Mon, 25 Sep 2006 12:39:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 12:39:24 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40AF6EAF4@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-syslog-protocol-17.txt thread-index: AcbgwSiBjbwtZRMaSWqmTH99sPOEmg== From: "Sharon Chisholm" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Subject: [Syslog] Review of draft-ietf-syslog-protocol-17.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi It's been a few revisions since I've given the protocol draft a good read, so when Chris called for reviewers I figured I should give it's a go. In general, I think the document is in good shape, but I have some comments and nits. There was one major change while I was napping which I'm not sure was for the better. That is my item number 1 below: Comments -------- C-1. Section 6.3.2 says that standard SD-IDs don't have an @ sign in them while proprietary ones do. I much preferred the x-acme approach of earlier drafts. This provided a well-behaved namespace that I understood how to manage within my company and in fact was starting to be used. This foo@acme stuff opens syslog up to chaos and anarchy, or at the very least it will lead to a proliferation of duplicate parameters among different products from the same ACME. Plus, x-acme was much easier to read and understand. C-2. Section 6.1 does not actually use the term minimum maximum, although this term is used later in the document. I think it would be helpful if it did because otherwise there is some confusion in the first paragraph around whether we are specifying maximum message length.=20 C-3. In section 6.1, second paragraph I'm having deja-vu, because I thought we agreed to recommend one way or other whether messages were suppose to be dropped or truncated. The rest of the document talks in terms of truncation. C-4. In section 6.2.6, I was originally going to complain about the SHOULD, but then when I read all the way down to the end of the document I found some additional guidance in the non-normative section which explains some use cases as to when you might want to do something else. It seems these can be better linked. I'd suggest adding either a cross reference to the appendix of each of these sections to the specific spot where people can find more information about the specific SD-PARAM or have a general note at the start of section 6 before the different parameters start getting explained. C-5. In section 7.1, I got a little nervous about the implication that if the sender *was* confident in their time stuff they would not send this field. This would also be what someone would do if they didn't support it, I imagine. Can we tighten this up so that if the sender has any doubts about their time stuff they MUST support this timeQuality? C-6. In section 7.3.3, can we expand 'enc' to 'encode'. Those three extra letters add a lot of readability. C-7. In section 7.3.3, would be worth specifying some strings for other potentially popular encodings while we are here? C-8. In section 8.2 It says, "This document does not impose any restrictions on the MSG or PARAM-VALUE content. As such, they MAY contain control characters, including the NUL character." but in section 6.4 it says 'The sender SHOULD avoid octet values below 32 (the traditional US-ASCII control character range except DEL).' Not that this means people won't see them, but it does mean that technically some non-mandatory restrictions have been made by this document. C-9. In section 8.4, it makes replay sound like a features, rather then a security concern. Do we mean to? It is in some notification systems, but I just want to verify. C-10. In section 8.5, I would suggest that sequence numbers, if supported, can be used to detect problems. C-11. In section 8.8, it would seem that reliable transport solving this problem assumes that some form of mutual relationship is established. It might be worth expanding on this since one could in theory reliably deliver messages to the wrong host. C-12. In section A-2, last paragraph, did we mean to say 'larger minimum size', or 'larger minimum maximum size' Nits ---- N-1. In section 1, it claims 'This document has been written with the spirit of RFC 3164 [16] in mind.', what exactly does that mean? The 'spirit of'? N-2. In section 5, first paragraph, there is a reference to [15] without some friendly text in front of it. I'd suggest RFC XXXX, with an understanding that the RFC editor will fix that later. =20 N-3. In section 5, second paragraph, the phrase 'due to transmission or similar errors.' seems problematic to me. It implies transmission is an error, not transmission errors. How about 'transmission errors or other problems."? N-4. Section 6.1, third paragraph has the word 'trucation' instead of 'truncation'. N-5. In section 6.2.1 we are first introduced to definitive sounding set of values for Facility and Severity and then told they are non-normative. If they are non-normative, that should be made clear before they are introduced. N-6, In section 6.3.4, it says "An exception is the addition of a new OPTIONAL PARAM-NAME to an existing SD-ID, what MAY be done." which doesn't work. Should that say 'which MAY be done'? N-7 In section 9.1, I would replace 'according to this document' with 'Defined in RFCXXXX - RFC Editor: replace XXXX with actual RFC number & remove' Otherwise IANA might not have the right information for its database and/or the document might not get updated. N-8. Why is the author information twice in the document? N-9. In section A.5, technically you are using lower camel case. =20 Sharon Chisholm Nortel=20 Ottawa, Ontario Canada _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Sep 25 21:05:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS1N3-0001kE-Jc; Mon, 25 Sep 2006 21:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS1N2-0001k8-PH for syslog@ietf.org; Mon, 25 Sep 2006 21:04:24 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS1N0-0007pD-54 for syslog@ietf.org; Mon, 25 Sep 2006 21:04:24 -0400 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k8Q143m9021319; Tue, 26 Sep 2006 10:04:03 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k8Q13x5x000437; Tue, 26 Sep 2006 10:04:02 +0900 (JST) Message-ID: <45187C7F.6030302@cysols.com> Date: Tue, 26 Sep 2006 10:03:59 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Alexander Clemm (alex)" Subject: Re: [Syslog] MIB document decision References: <85B2F271FDF6B949B3672BA5A7BB62FB024E2DE4@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB024E2DE4@xmb-sjc-236.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org 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 From syslog-bounces@lists.ietf.org Thu Sep 28 11:30:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSxop-0000wL-TV; Thu, 28 Sep 2006 11:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSxnp-0000Ru-NX for syslog@ietf.org; Thu, 28 Sep 2006 11:27:57 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSxcR-0000jK-TA for syslog@ietf.org; Thu, 28 Sep 2006 11:16:13 -0400 Received: from pc6 (1Cust10.tnt109.lnd4.gbr.da.uu.net [62.188.172.10]) by galaxy.systems.pipex.net (Postfix) with SMTP id D2821E00033E; Thu, 28 Sep 2006 16:16:09 +0100 (BST) Message-ID: <004001c6e307$caa31740$0601a8c0@pc6> From: "tom.petch" To: "David B Harrington" , References: <023f01c6d5b0$c7ebaf30$0400a8c0@china.huawei.com> Subject: Re: [Syslog] Working Group Last Call: syslog-mib document Date: Thu, 28 Sep 2006 16:05:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I have looked at this I-D and appreciate the increased explanation at the beginning. It leaves me clearer, but still thinking that this document steers a different course to the other syslog ones, in its focus on a group of syslog entities. It's not that there cannot be more than one syslog entity running in a given host, just that bundling them together into a table seems an artificial complication; other syslog MIB modules I see are scalar in approach. Tom Petch ----- Original Message ----- From: "David B Harrington" To: Sent: Monday, September 11, 2006 4:44 PM Subject: [Syslog] Working Group Last Call: syslog-mib document > Hi, > > This message officially starts the Syslog Working Group Last Call for > the following document: > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx > t > > The Working Group Last Call for this document will end September 25. > > To help get these document reviewed throughly, we are seeking > volunteers to review the documents for the following special reviews: > 1) Spelling and grammar, > 2) boilerplates and reference review, > 3) security review > > The chairs want to see a minimum number of content reviews before we > submit the documents to the IESG. If you review the document and it > looks fine, please post a statement that you have reviewed and found > the document acceptable. Obviously, if it does not look acceptable > please identify your objections, preferably with suggested text that > would make it acceptable. > > Thanks, > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Sep 28 16:20:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT2ML-0000mX-CE; Thu, 28 Sep 2006 16:19:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT2MJ-0000l4-D5 for syslog@ietf.org; Thu, 28 Sep 2006 16:19:51 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT2MI-0001QL-3x for syslog@ietf.org; Thu, 28 Sep 2006 16:19:51 -0400 Received: from pc6 (1Cust55.tnt5.lnd4.gbr.da.uu.net [62.188.134.55]) by galaxy.systems.pipex.net (Postfix) with SMTP id 03CFBE0002F4; Thu, 28 Sep 2006 21:19:47 +0100 (BST) Message-ID: <02c301c6e332$3584bf80$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] Liaison from the OIF Date: Thu, 28 Sep 2006 18:23:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Mmmm I am not sure that suggesting 490 amendments to an I-D in Last Call is quite what I would describe as a 'stong endorsement' but perhaps I misconstrue the meaning of the word 'stong':-) . Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Wednesday, September 13, 2006 9:27 PM Subject: [Syslog] Liaison from the OIF > Hi Folks, > > We've received a liaison letter from the OIF. It's been accepted by the > IETF Secretariat and posted in the Liaison Statement repository. > > https://datatracker.ietf.org/public/liaisons.cgi > > Please take a moment to review the importance of our work to the OAM&P > Working Group of the Optical Internetworking Forum. This is a stong > endorsement that our efforts are on the right track. > > Thanks, > Chris > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Fri Sep 29 14:54:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTNTG-0004N9-FG; Fri, 29 Sep 2006 14:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTNTE-0004Kd-Vz for syslog@ietf.org; Fri, 29 Sep 2006 14:52:24 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTNTD-0006QQ-NH for syslog@ietf.org; Fri, 29 Sep 2006 14:52:24 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (rwcrmhc13) with SMTP id <20060929185222m1300m3tv1e>; Fri, 29 Sep 2006 18:52:22 +0000 From: "David Harrington" To: Date: Fri, 29 Sep 2006 14:50:17 -0400 Message-ID: <098401c6e3f8$1bfdcbd0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acbj95bzqHgNtYIxRyy5C2G8PNRfAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Syslog] WGLC closed for tls, sign, mib X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, This message officially closes the WG Last Calls for http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 .txt, started 8/29/2006 http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt, started 8/28/2006 http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx t, started 9/11/2006 The WG Last Calls for these documents had already been closed. http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt The chairs will collect and review the comments, and work with the editors to ensure the comments are addressed appropriately, prepare a report for the working group, have new documents published, and prepare the documents for submission to the IESG for approval. Thank you for your hard work. 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 From syslog-bounces@lists.ietf.org Fri Sep 29 16:36:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTP4r-0001au-2S; Fri, 29 Sep 2006 16:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTP4p-0001an-Qx for syslog@ietf.org; Fri, 29 Sep 2006 16:35:19 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTP4o-0007Yi-Ib for syslog@ietf.org; Fri, 29 Sep 2006 16:35:19 -0400 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (rwcrmhc15) with SMTP id <20060929203517m1500ld2g5e>; Fri, 29 Sep 2006 20:35:17 +0000 From: "David Harrington" To: Date: Fri, 29 Sep 2006 16:33:13 -0400 Message-ID: <099201c6e406$7cb57000$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcbkBlfDXrxWTJLNQq6QeyMhjj9q6g== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Syslog] WGLC results X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Will the editors of the WGLC'd documents please collect the comments made for each of your documents into a single document, preferably text, and indicate what was done in the document to address the issue raised. Send the summary document to the chairs, with a copy of your current in-process document containing the fixes thus far, so the chairs can review your fixes. Once we have reviewed the fixes, we may ask for some changes. Then we will have you publish a new I-D, which we will send to the WG. It would be good to separate the issues document into three sections: 1) purely editorial issues (spelling, grammar, etc.) 2) Closed issues Technical issues where consensus was obvious. For each issue, please describe who raised the issue, and how the document was changed to address the issue. The chairs will review the changes to make sure they represent what the chairs consider to be WG consensus. 3) Open issues Technical issues where the resolution is unclear. Please identify who raised the issue. If you have a proposed fix, please describe it. The chairs will review the issues and determine whether it is an issue that needs resolution, whether your proposal is acceptable and in keeping with WG consensus, or whether it needs to be discussed further by the WG. Thanks, 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 From syslog-bounces@lists.ietf.org Sat Sep 30 02:00:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTXrZ-0004My-A2; Sat, 30 Sep 2006 01:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTXrY-0004Mo-5P for syslog@ietf.org; Sat, 30 Sep 2006 01:58:12 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTXrT-0006IG-Tq for syslog@ietf.org; Sat, 30 Sep 2006 01:58:10 -0400 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k8U5vom9019634; Sat, 30 Sep 2006 14:57:50 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id k8U5vm5x023517; Sat, 30 Sep 2006 14:57:50 +0900 (JST) Message-ID: <451E075C.7090208@cysols.com> Date: Sat, 30 Sep 2006 14:57:48 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "tom.petch" Subject: Re: [Syslog] Working Group Last Call: syslog-mib document References: <023f01c6d5b0$c7ebaf30$0400a8c0@china.huawei.com> <004001c6e307$caa31740$0601a8c0@pc6> In-Reply-To: <004001c6e307$caa31740$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom, Your observation is correct. I guess that other MIBs deal with entities which are essentially singleton in the context of a host. An SNMP agent on the host services the information rquired to monitor "the" entity. Some entities may not be singleton - syslog is one of them. The syslog MIB nicely takes care of this case. It can service multiple syslog daemons. For example, one can ask - how many syslog messages were received by the experimental syslogd that I am running on UDP port 10512? - how many syslog messages were received by the standard syslogd that I am running on TCP port 512 ? etc. I think that this is a very nice feature. Am I missing something? Glenn tom.petch wrote: > I have looked at this I-D and appreciate the increased explanation at the > beginning. It leaves me clearer, but still thinking that this document steers a > different course to the other syslog ones, in its focus on a group of syslog > entities. It's not that there cannot be more than one syslog entity running in > a given host, just that bundling them together into a table seems an artificial > complication; other syslog MIB modules I see are scalar in approach. > > Tom Petch > > > ----- Original Message ----- > From: "David B Harrington" > To: > Sent: Monday, September 11, 2006 4:44 PM > Subject: [Syslog] Working Group Last Call: syslog-mib document > > >> Hi, >> >> This message officially starts the Syslog Working Group Last Call for >> the following document: >> >> http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx >> t >> >> The Working Group Last Call for this document will end September 25. >> >> To help get these document reviewed throughly, we are seeking >> volunteers to review the documents for the following special reviews: >> 1) Spelling and grammar, >> 2) boilerplates and reference review, >> 3) security review >> >> The chairs want to see a minimum number of content reviews before we >> submit the documents to the IESG. If you review the document and it >> looks fine, please post a statement that you have reviewed and found >> the document acceptable. Obviously, if it does not look acceptable >> please identify your objections, preferably with suggested text that >> would make it acceptable. >> >> Thanks, >> David Harrington >> dharrington@huawei.com >> dbharrington@comcast.net >> ietfdbh@comcast.net >> co-chair, Syslog WG > > > _______________________________________________ > 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