Hi Anton, I am not proposing to drop anything that has been developed by this WG so far; I am proposing that we focus our current and future discussions on what we are suppposed to be delivering.
I have concerns that there are numerous discussions that deal with issues other than security-related issues, and I think those discussions belong in the OPS area rather than the Security area. dbh > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] > Sent: Friday, June 30, 2006 3:43 PM > To: David Harrington; Rainer Gerhards; Chris Lonvick > (clonvick); [EMAIL PROTECTED] > Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim > > 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 > > > > > > 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
