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

From: Chris Lonvick <[email-masked]>
Date: Wed, 28 Jun 2006 10:55:59 -0700 (PDT)

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 29 Jun 2006 11:11:21 +0200

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,
>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 29 Jun 2006 14:32:19 -0400

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]

> 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
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 30 Jun 2006 12:11:20 +0200

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

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, June 29, 2006 8:32 PM
> To: Rainer Gerhards; 'Chris Lonvick'; [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Fri, 30 Jun 2006 11:57:35 -0400

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]

> Sent: Friday, June 30, 2006 6:11 AM
> To: David Harrington; Chris Lonvick; [email-masked]

> > > 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
> > > 3195bis modifies the "cost" of finding alternate solutions.
Coming
> > to
> > > obviously one whose weight we need to decide on. But I think it
is
> > not
> > > where I track all contributions to this discussion (for an
example
> > of
> > > provides good argument when dealing with the IESG (in the case
we
> > need
> > > >     on the procedures with respect to rights in RFC 
> documents can
> > be
> > > >     assurances of licenses to be made available, or the 
> result of
> > an
> > > >     This memo lays out a conceptual framework and rules of
thumb
> > to

---

From: "John Calcote" <[email-masked]>
Date: Fri, 30 Jun 2006 12:23:05 -0600

Jumping in to add my two cents...
 
I quite agree with David on this point. If the syslog WG chose to begin
work on network management issues, it would be stepping into a realm
already well covered by other standards efforts. However - what the
world does need is a standardized and widely understood and deployed
_secure_transport_ for management events. One that will guarantee
deliver and sequencing, as well as privacy based on administrative
policy.
 
I work for Novell on the Audit Record Framework (ARF) - a part of the
Bandit Project (http://www.bandit-project.org). ARF is chartered to
provide an open source, portable, application audit instrumentation
library based on existing standards work. We've chosen to use the OASIS
WSDM Event Format - a W3C XML Schema-based approach. The ARF library
will send management events over a secure protocol - hopefully syslog -
to back-end event collection servers. Novell's eSecurity-acquired
Sentinel product already listens on syslog (3195) channels for such
event information. ARF will provide rich structured content from
instrumented applications on this channel.
 
My suggestion would be for the syslog-sec WG to simply define the
payload of syslog messages to be extensible and flexible, and not spend
much time on defining the management content itself. With efforts like
OASIS WSDM, DMTF CIM-XML (WBEM), and others already well underway, it
makes no sense to go farther down this road with syslog - an event
protocol whose charter makes it infeasible to try to cover the same
amount of network management ground as these other standards efforts
will.
 
John Calcote ([email-masked])
Software Engineer/Architect
Novell, Inc.

>>> "David Harrington" <[email-masked]> 6/30/2006 9:57 AM >>>
Hi,

David Harrington
[email-masked] 
[email-masked] 
[email-masked] 

And,
it
Coming
is
example
> http://www.eecs.iu ( http://www.eecs.iu/
)-bremen.de/wiki/index.php/Netconf_notifications).
we
thumb