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
