Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Fri, 30 Jun 2006 15:43:08 -0400

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-masked]] 
> Sent: Friday, June 30, 2006 11:58 AM
> To: 'Rainer Gerhards'; Chris Lonvick (clonvick); [email-masked]
> 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-masked] 
> [email-masked]
> [email-masked]
> 
> 
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:[email-masked]] 
> > Sent: Friday, June 30, 2006 6:11 AM
> > To: David Harrington; Chris Lonvick; [email-masked]
> > 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-masked]] 
> > > Sent: Thursday, June 29, 2006 8:32 PM
> > > To: Rainer Gerhards; 'Chris Lonvick'; [email-masked]
> > > 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-masked]
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Rainer Gerhards [mailto:[email-masked]] 
> > > > Sent: Thursday, June 29, 2006 5:11 AM
> > > > To: Chris Lonvick; [email-masked]
> > > > 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-masked]] 
> > > > > Sent: Wednesday, June 28, 2006 7:56 PM
> > > > > To: [email-masked]
> > > > > 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-masked].
> > > > > --------------------------------------------------------------
> > > > > -----------
> > > > > 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-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/syslog
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > Syslog mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/syslog
> > > > 
> > > 
> > > 
> > 
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog