David: Please clarify...
Are you suggesting we drop syslog-protocol, which actually defines message format, and just do a generic secure transport for events? Something that just does framing, app-level ack and had generic payload? And then we continue to live without syslog standard, waiting for others to standardize payload? Anton. > -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Friday, June 30, 2006 11:58 AM > To: 'Rainer Gerhards'; Chris Lonvick (clonvick); [EMAIL PROTECTED] > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > Hi, > > [posting as a contributor] > > I recommend this WG make a clear separation (as much as is possible) > between issues of security and issues of network management. > > Issues such as harmonization with the work of other SDOs, integration > with netconf, message formatting, content standardization, and so on, > are about syslog as a network management protocol. I strongly beleve > this work should **not** be done by the syslog-sec WG, but in a WG > chartered in the OPS area or the Application area, not the Security > area. There are many contributors who have worked on, and are > currently working on, other network management protocols and have > addressed issues similar to those facing syslog. > > In addition, there is an effort by the new OPS Management AD to > address the current isolated decision making (silos) that is occurring > regarding the management plane throughout the IETF. The contributors > to this WG should be involved in that discussion, which is likely to > be centered in the OPS area. > > This WG is about security for syslog, and we should focus our efforts > on solving the security problems, whether with tls or ssh or beep, and > publish. > > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > > -----Original Message----- > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > Sent: Friday, June 30, 2006 6:11 AM > > To: David Harrington; Chris Lonvick; [EMAIL PROTECTED] > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > David, > > > > I fully agree with your thought. I, too, think we must put emphasis > on > > the delivery of documents. In my personal opinion, this > > leaves only two > > realistic options: > > > > a) rfc 3195bis as you have described it (without the "rathole > > discussion") > > b) -transport-tls more or less as it is now > > > > I think there are enough comments on a) already in the list archive. > I > > will not repeat them. > > > > Comments on b) currently tend to focus on the IPR issue. Let's > ignore > > that for a moment and look at other arguments. We have > > intially opted in > > favor of -transport-tls because it already is in widespread > > use. What is > > done currently can not be standardized literally, but we can > > standardize > > something that is quite close to it. It was our opinion that > > -transport-tls should by fairly easy to implement, thus bringing > some > > immediate value to the community. > > > > Now some technical issues have come up on the list, things like > > app-layer ACKs, opening and closeing conversations. I have brought > up > > some of them. I am also of the view that we could craft a better > > framing, probably borrowing from NETCONF (and thus easing conversion > - > > the "big picture"). This is still sufficiently easy, but it is a big > > departure from the "let's standardize what is used in practice" > > approach. I fear that discussing a better framing/session management > > again takes up a lot of time and includes a high risk of missing our > > milestones again. BTW: we are scheduled to deliver by > > November 2006, and > > I do not expect that we will be granted an extension this time > again. > > November will be very soon, especially looking at the summer break. > > > > So I propose that we do NOT enter any new discussion. We > > should deliver > > either a) or b) (above), without introducing any new features > > or ideas. > > That means that the result will be sub-optimal. But > > delivering something > > usable is much better than aiming for the perfect one that will > never > > appear. > > > > Once we have delivered, we should discuss what to do next (but only > > AFTER delivery). I have to admit that I now see some good points in > a > > -transport-ssh and consider it implementable with reasonable effort. > > However, -transport-ssh should be done after we have reconsidered > the > > framing. Given the track record of this WG, I would suspect > > this can not > > be done in less than 12 to 24 month. There are also the issues that > > Anton brought up and the general question on configuration and event > > data models for syslog. A lot of useful work lying ahead (but > > depending > > on our ability to finish the base stuff first). > > > > I think this work can never be done if this WG fails. So I am > > desperately trying to get us to publish. I think what we have > > is useful > > and well-enough. If we do not publish soon, we will never be able to > > publish at all. IMHO, we have already received our third chance and > > there will be no fourth... > > > > Rainer > > > > > -----Original Message----- > > > From: David Harrington [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, June 29, 2006 8:32 PM > > > To: Rainer Gerhards; 'Chris Lonvick'; [EMAIL PROTECTED] > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > > > > > Hi Rainer, > > > > > > [speaking as a contributor] > > > > > > This WG needs to deliver documents soon or the WG could be closed. > > > > We need to deliver a secure transport solution. > > > If the WG decides to do a 3195bis as the secure transport > > solution, I > > > recommend the short-term deliverable be "good enough" to work with > > > syslog-protocol. That way we can get 3195bis AND the other > documents > > > (-protocol- and -udp-) published and onto the standards > > track, so the > > > industry can begin to implement, and the WG can stay open to do > > > additional work. > > > > > > Then we can address whether the 3195 design should be modified in > > > other ways. There have been suggestions to modify 3195 to > > "harmonize" > > > with the work of other Standards Development Organizations such as > > > OASIS and W3C. Doing that work would likely not be quick or easy. > I > > > fear it would be a real rathole that would prevent us > > getting 3195bis > > > published at all, and if 3195bis is the WG's choice as the secure > > > transport protocol, then that rathole would also prevent the > > > publication of -protocol- and -udp- on a timely basis. > > > > > > As a 14-year veteran of IETF WG efforts, I think it would > > be a bad WG > > > decision to put 3195bis on the critical path and to open it up to > a > > > rathole discussion. If 3195bis is on the critical path, we need to > > > avoid the rathole discussion for now; it can be considered for a > > > future "release". If the WG feels the rathole discussion is really > > > necessary, and 3195bis should not be done without having had such > a > > > possible-rathole discussion, then 3195bis should not be put on the > > > critical path. > > > > > > My $.02 > > > David Harrington > > > [EMAIL PROTECTED] > > > > > > > > > > -----Original Message----- > > > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, June 29, 2006 5:11 AM > > > > To: Chris Lonvick; [EMAIL PROTECTED] > > > > Subject: RE: [Syslog] Decisions to make about the Huawei IPR > claim > > > > > > > > Besides the somewhat political issue, I think there is also > > > technical > > > > issue that affects the question. I think we should consider that > > > > question in parallel to the IPR question. > > > > > > > > This question is if this WG intends to do a revision of 3195. > And, > > > if > > > > so, I think the very close next question is if we "just" update > it > > > to > > > > support syslog-protocol or if we intend to make any > > > > substantial changes. > > > > > > > > I see a relationship between the IPR and the 3195bis issue > because > > > > 3195bis modifies the "cost" of finding alternate solutions. > Coming > > > to > > > > this point, it would probably be helpful if we could actually > > > > weigh cost > > > > vs. utlity of the different approaches. IPR, IMHO, is just a > cost, > > > > obviously one whose weight we need to decide on. But I think it > is > > > not > > > > the only cost. If the WG finds such a "cost vs. utility" > > discussion > > > > useful, I could document my point of view as a starting point. I > > > > volunteer to create a summary document (a public web page, not a > > > I-D) > > > > where I track all contributions to this discussion (for an > example > > > of > > > > what I have in mind see Juergen Schoenwaelder's page on netconf > > > > notification requirements: > > > > > > http://www.eecs.iu-bremen.de/wiki/index.php/Netconf_notifications). > > > > > > > > I would find such a page very helpful. It documents the > > > > decision process > > > > and the decision criteria. In doing that, it helps us come to a > > > better > > > > decison because we than have all facts at a single place. > > > > Thus, it also > > > > provides good argument when dealing with the IESG (in the case > we > > > need > > > > to justify the decision). > > > > > > > > Thanks, > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, June 28, 2006 7:56 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: [Syslog] Decisions to make about the Huawei IPR claim > > > > > > > > > > Hi Folks, > > > > > > > > > > It's looking like we have a primary decision to make about > > > > > the IPR claim > > > > > that Huawei has made on syslog-transport-tls. First and > > > > > foremost, I want > > > > > everyone to be informed of the IETF stand on IPR claims and > > > > > on the IETF > > > > > process that we will follow. > > > > > > > > > > This is the position of the IETF on IPR claims: > > > > > -------------------------------------------------------------- > > > > > ----------- > > > > > Intellectual Property > > > > > > > > > > The IETF takes no position regarding the validity or > > > > scope of any > > > > > Intellectual Property Rights or other rights that might > > > > > be claimed to > > > > > pertain to the implementation or use of the technology > > > > > described in > > > > > this document or the extent to which any license under > > > > such rights > > > > > might or might not be available; nor does it represent > > > > that it has > > > > > made any independent effort to identify any such rights. > > > > > Information > > > > > on the procedures with respect to rights in RFC > > documents can > > > be > > > > > found in BCP 78 and BCP 79. > > > > > > > > > > Copies of IPR disclosures made to the IETF > > Secretariat and any > > > > > assurances of licenses to be made available, or the > > result of > > > an > > > > > attempt made to obtain a general license or permission > > > > > for the use of > > > > > such proprietary rights by implementers or users of this > > > > > specification can be obtained from the IETF on-line IPR > > > > > repository at > > > > > http://www.ietf.org/ipr. > > > > > > > > > > The IETF invites any interested party to bring to its > > > > > attention any > > > > > copyrights, patents or patent applications, or other > > > proprietary > > > > > rights that may cover technology that may be required > > > > to implement > > > > > this standard. Please address the information to > > the IETF at > > > > > [EMAIL PROTECTED] > > > > > -------------------------------------------------------------- > > > > > ----------- > > > > > This is at the bottom of all RFCs. It's pretty clear that we > > > > > (our Working > > > > > Group) has no place to appeal claims of IPR to. > > > > > > > > > > Also, the more detailed explanation of the IETF position is > > > > in BCP 79: > > > > > http://www.ietf.org/rfc/rfc3979.txt > > > > > I will ask that everyone read through this before > > expressing their > > > > > > > > opinion. > > > > > > > > > > One additional source of information for our process is > > RFC 3669: > > > > > http://www.ietf.org/rfc/rfc3669.txt > > > > > "Guidelines for Working Groups on Intellectual Property > Issues" > > > > > -------------------------------------------------------------- > > > > > ----------- > > > > > 1. Introduction > > > > > > > > > > This memo lays out a conceptual framework and rules of > thumb > > > to > > > > > assist working groups dealing with IPR issues. The > > goal is to > > > > > achieve a balance between the needs of IPR claimants and > the > > > > > implementers of IETF standards which is appropriate to > > > > > current times. > > > > > As part of trying to distill out principles for dealing > > > > > with IPR in > > > > > IETF working groups, it provides case studies of > > > > working group IPR > > > > > treatment. In other words, it documents the running code > > > > > of the IETF > > > > > process. > > > > > > > > > > This memo does not describe IPR procedures for document > > > > authors or > > > > > IPR claimants. Those are covered in two other memos, on > > > > > submission > > > > > rights [5] and IPR in the IETF [6]. Rather, this memo is > > > > > for working > > > > > groups that are trying to decide what to do about > technology > > > > > contributions which have associated IPR claims. > > > > > -------------------------------------------------------------- > > > > > ----------- > > > > > [5] and [6] are BCP78 and BCP79 respecively. > > > > > This document contains a lot of really good advice that we > > > > > should be aware > > > > > of while we make our decision. > > > > > > > > > > One part of RFC 3669 is a recommendation to take a critical > > > > > look at the > > > > > terms of the claim - Section 5.6. Essentially, if we can get > > > > > consensus > > > > > that the terms are acceptable for implementation, then the > > > > > IPR claim may > > > > > not be an issue - we can continue to progress > > > > > syslog-transport-tls. On > > > > > the other hand, if the terms are not acceptable then we can't > > > > > expect any > > > > > implementations. > > > > > > > > > > I'm going to ask that everyone please start considering these > > > > > inputs and > > > > > openly discuss your thoughts about the IETF process and the > > > options > > > > > available to our Working Group on the mailing list. > > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > > Do not declare your opinion yet. > > > > > +++ +++ +++ +++ +++ +++ +++ +++ +++ > > > > > In a week or so I will ask the group to decide how we should > > > > > process. I > > > > > want everyone to take the time now to get acquainted with the > > > > > process and > > > > > the information that we have available to us. > > > > > > > > > > I believe that ultimately, we will need to decide on whether > > > > > to continue > > > > > to progress syslog-transport-tls, or if we will want to > > > > > accept a different > > > > > path. If we start down a new path, then we will still need > > > > > to make sure > > > > > that we are meeting the security objectives that we feel are > > > > > important. > > > > > This discussion has already been started, which is good in > > > > that it can > > > > > bringing to light some of the issues that need to be > > > > > discussed around the > > > > > secure transport of syslog. Once we get this primary issue > > > > > resolved then > > > > > we can decide upon that. > > > > > > > > > > Also, the Milestone about delivering a TLS solution can be > > > > > easily changed. > > > > > I did submit it that way to the IESG and Tom Petch noted that > > > > > the Charter > > > > > just said "security" protocol while the Goal specified > > a specific > > > > > solution. Sam didn't want to change it after it had gone > > > > in but I'm > > > > > certain that it's not going to be a problem if we do want to > > > > > change it. > > > > > > > > > > Thanks, > > > > > Chris > > > > > > > > > > _______________________________________________ > > > > > Syslog mailing list > > > > > [email protected] > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > [email protected] > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
