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

From: "David Harrington" <[email-masked]>
Date: Tue, 4 Jul 2006 18:33:14 -0400

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-masked]] 
> Sent: Friday, June 30, 2006 3:43 PM
> To: David Harrington; Rainer Gerhards; Chris Lonvick 
> (clonvick); [email-masked]
> 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-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