Todd:
IPR disclosures that are required by BCP 79 are automatically posted
on the IETF's public IPR disclosure page (www.ietf.org/ipr). These
disclosures may be viewed by anyone. In addition, under Section 4(A)
of BCP 79, the RFC Editor is required to include in each RFC a notice
of any IPR
This thread has already pointed to the financial statements that show
how much is paid for RFC Editor services.
Russ
At 08:56 PM 10/26/2008, TS Glassey wrote:
There must be some financial models available from the proposal
stage of the Editor Selection process, chair?
Todd Glassey
- Ori
Tim:
I agree that the value of anything is set by the market.
Please tone down the sarcasm. The IETF Discussion mail list and the
IETF IPR WG mail list both need to be inviting places for open discussion.
Thanks in advance,
Russ
At 11:42 AM 10/24/2008, Tim Bray wrote:
On Fri, Oct 24, 200
Nico:
So if I understand correctly then this document would have an
implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the
same TCP connection with different labels, *and* ensure that each packet
contains parts of no more than one (exactly one) NFSv4 RPC.
I am aware of several m
I know these are a few hours late, but I have a few comments. I have
divided them into TECHNICAL and EDITORIAL.
TECHNICAL COMMENTS
Section 1, 2nd para. It is unclear what version of DTLS is being
used. The reference to RFC4347 in this paragraph leads to one
conclusion, but in Section 4.1.
I'm not sure where you started, but I find the proceedings at:
http://www.ietf.org/proceedings/08jul/index.html
I go there directly from:
http://www.ietf.org/proceedings_directory.html
Russ
At 11:21 AM 9/22/2008, Adrian Farrel wrote:
http://www.ietf.org/proceedings_directory.html
points to
ht
> > Historically the work of the IETF has been conducted over mailing lists.
> > This practice ensures the widest possible involvement in the working
> > group process. This practice is not as efficient in terms of producing
> > specifications as extended face-to-face meetings but is much more
> >
On the Telechat today, the IESG made a decision to proceed with this
experiment. The IETF Secretariat has been directed to update the web
site to indicate that the IETF meeting will continue until 3:15 PM on Friday.
After each meeting the IAD conducts a survey. The IAD has been asked
to inclu
It has already been done: http://www.rfc-editor.org/rfc/rfc97.pdf
PDF is an ISO standard, and the RFC Editor has already set a
precedent by using this format when they are unable to locate an
electronic copy of a very old RFC.
This seems like a fine format to capture images, pictures, glyphs,
I am working on a solution for this with the Secretariat. It is one
aspect of the web site redesign project. I do not think that an
Internet-Draft is needed.
Russ
At 11:40 AM 8/9/2008, Bert Wijnen \(IETF\) wrote:
(1) Archive older versions in a plain text format as forI-Ds
(for use with
David:
I support this experiment. Why short sessions? Why not longer
sessions?
The reason for short sessions is that the Secretariat can assign
adjacent slots to the same WG to create a long one if that is what is needed.
Russ
___
Ietf mailing
Some of the slides came to me just in time. I should have posted the
ones that were available on time. I'll do better next time.
Russ
At 12:55 PM 7/31/2008, Dan York wrote:
Being a remote participant (for the first time) at this IETF 72
meeting, I have to say that my main disappointment was
e RFC Editor to implement.
Russ
At 03:37 AM 7/31/2008, Harald Alvestrand wrote:
The IESG (by way of Russ Housley <[EMAIL PROTECTED]>) wrote:
The attached describes the manner in which the IESG will be
processing RFC Errata for the IETF Stream. The current tools on the
RFC Editor site suppor
Michael:
There is at least one WG that never held a single face-to-face
meeting. They are certainly not required.
Many WGs do take advantage of non-face-to-face meeting alternatives
to resolve issues between meetings. For example, single-topic jabber
chats have been scheduled and used. Th
People seem to be forgetting that all I-D submissions used to be
processed an a person. The automated tool is very new. When the I-D
were processed by hand, the cut-off was necessary for the Secretariat
to handle the spike of submissions just prior to the meeting. Look
at the statistics repo
John:
But that, IMO perfectly sensible, combination of formal posting
cutoffs (whether to protect the Secretariat or to make sure
documents were available when they needed to be) with informal
provision for waivers, gradually morphed into a firm,
chiseled-in-stone rule with no exceptions and tha
No. The wireless network will offer an IPv6 ONLY network all week
long, but the IPv4 will not be turned off during the plenary at Dublin.
I agree that we learned a lot from the experiment, and I'm not
opposed to trying it again at a future meeting.
Russ
At 06:52 PM 7/18/2008, Olivier MJ Cre
Adrian:
This has been discussed many times, and there is no easy way for the
Secretariat to distinguish these document from others. With the
on-line Internet-Draft Submission Tool (IDST), it might be possible
to search the database for such documents and let them
through. However, we're try
Marshall:
I do not know of any repository for the attendance at interim
meetings other that the proceedings. Interim meeting minutes are
included with the proceedings of the following IETF meeting.
The reason that the experiment is scoped as proposed deals with the
contract that is already
Olafur:
I try to gather some data to see if this would help. My intuition is
that we need 2.5+ hours for some very significant working groups so
these groups would end up with multiple adjacent slots. But, maybe
the smaller slots would help with the things that they are scheduled against.
Brian:
> The proposed Friday schedule would be:
>
>0900-1130 Morning Session I
>1130-1300 Break
>1300-1400 Afternoon Session I
>1415-1515 Afternoon Session II
Try it. We've been having periodical email arguments about Friday
afternoon for years; an experiment is the best way to
Marshall:
Would there be a refreshment break in the afternoon ?
No. It is just 15 minutes to get between the two one-hour
sessions. The proposed extension to the meeting is 2.25 hours. We
regularly have 2.5 hour sessions with no refreshments, so I do not
see the need for additional food
rs:
[EMAIL PROTECTED]
Thanks,
Russ Housley
IETF Chair
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Lakshminath:
Consider a hypothetical case: a large WG has strong consensus on one
of their documents, they believe it is within the charter's scope
and think that the document is in the best interest of the
Internet. The WG chairs assess the consensus, and forward the
document to the shepher
I'm sorry for the way that this discussion has gone. I joined the
discussion in order to let the whole community see both sides of the
disagreement. However, in an attempt to provide clarity and correct
inaccurate statements, the discussion turned into tit for tat. The
back-and-forth banter d
Bernard:
The data is all public. Jari has done a very good job of extracting
the data from the I-D Tracker and making it accessible to
everyone. Of course, any requests for changes to additional graphs
need to go to Jari.
http://www.arkko.com/tools/admeasurements/stat/base.html
Russ
At 1
rception. Suggestions on making this more
objective and less subjective are greatly appreaciated.
Russ
At 10:41 PM 6/23/2008, Bernard Aboba wrote:
Russ Housley said:
"I agree with this principle. In fact, I think that the IESG has
taken many steps over the last four or more years to red
John:
Russ, that note was sent to the mailing list after I received
your "change the document or appeal" note. I believed that
note from you closed the door on any further dialogue with you
(or the IESG). The note to the SMTP list was simply to collect
opinions on which of the two choices you
Dave:
If you feel that group was rogue, please explain. If you do not,
what is the basis for your view that its considerations were
sufficiently faulty to warrant being overridden?
Prior to the appeal, this aspect of John's rationale was not
raised. It was not raised by John, the document PR
te the opposite.
However, even on the specifics of the 2821bis issues, we
obviously disagree. More on that below.
--On Wednesday, 18 June, 2008 22:35 -0400 Russ Housley
<[EMAIL PROTECTED]> wrote:
>...
> You are missing a few things that I consider to be relevant
> and important.
ed Hardie wrote:
At 10:50 AM -0700 6/19/08, Russ Housley wrote:
>
>That seems to be the crux of the appeal. Does every possible thing
>upon which an AD can raise a DISCUSS position need to align with a
>written rule? Don't we select leaders because we have some
>conf
Dave:
I'm not sure I did a wise thing by joining the discussion, but in for
a penny, in for a pound ...
>>- The examples in RFC 821 use different domains from the ones in RFC 2821.
>
>Where are the reports of problems with with that aspect of RFC 2821?
>
>Changes from Proposed to Draft are expec
Bob:
Insanity? I think not. Maybe you made the comment to get me post to
this thread. If so, it worked.
You are missing a few things that I consider to be relevant and important.
- We're talking about rfc2821bis (not RFC 2821 or RFC 821).
- The examples in RFC 821 use different domains from
At IETF 71, we conducted an IPv6-only experiment. I have received
many positive reports from the experience. Many people learned from
the experience. In fact, many people that use IPv6 on a daily basis
also reported learning new things. This is all good, and the v6ONLY
SSID will be offered
Stephane:
> > We are inviting the first ten (10) interested members of the IETF
> > community who respond to this email to become a part of the website
> > redesign team. If you are interested in assisting with this effort,
> > please respond to this email as soon as possible.
>
>It is no longer "
>One of the guidelines says:
>
> > 8. Changes that modify the working of a process, such as changing
> > an IANA registration procedure, to something that might be
> > different from the intended consensus when the document was
> > approved should be Archived.
>
>I do not unde
Phill:
When IETF lists are housed somewhere other than ietf.org, they are
supposed to include an archive recipient so that there is an archive
available at ietf.org (perhaps in addition to the one kept at the
place where the list is housed).
Russ
At 01:02 PM 4/14/2008, Hallam-Baker, Phillip
>solutions are not considered viable.
>
>Leslie.
>P.S.: Also -- good luck with ever having a "small" meeting -- with
>4 Chairs in the room, you'll be looking for end-tables pretty soon ;-)
>
>
>--On April 7, 2008 3:45:16 PM -0400 Russ Housley <[EMAIL PROTE
The IAOC and the IETF Trust have different focus. The idea behind
the separate chair is to make sure that someone is paying attention
to the items that need to be handled by each body in a timely
manner. It is simply a mechanism to help ensure that noting is
falling between the cracks.
Russ
John:
>(2) Because some members of the IAOC are appointed by (or
>ex-officio from) other bodies, I would prefer that, if there is
>going to be a separate Trust Chair, that person be required to
>be an IETF appointee and subject to recall. No matter how many
>"the Chair is nothing special" rules o
Simon:
> > Raising a technical problem anonymously does not seem to be a
> > concern. However, there could be significant IPR problems with
> > anonymous solutions to technical problems.
>
>What kind of problems?
If there is IPR associated with a potential solution, then a
malicious person coul
Simon:
> >> > Since IETF does not vote, it is certainly not an issue here?
> >>
> >> This is not totally true. A WG Chair or Area Director cannot
> >> judge rough consensus if they are unsure if the portion of the
> >> population that is representing a dissenting view is one person
> >> or many d
The PR-Action related aspects of a person using a bogus identity seem
easy to address, perhaps using the mechanism that Harald
suggested. However, the implications on IPR are much harder. In the
IETF, posting to a maillist and speaking at a meeting are two ways of
making contributions. If we
> > we had this exact problem with the many identities of "Jeff
> > Williams"; he had enough pseudo-personalities on the list that he
> > would sometimes claim to have a majority, jut from his own postings.
>
>Since IETF does not vote, it is certainly not an issue here?
This is not totally true.
During the Wednesday Plenary at IETF 71, I gave the IETF community a
"heads up" on two documents from the IPR WG that were nearing IETF
Last Call. Both of the documents have now reached IETF Last
call. The Last Call announcements are attached. Please review and comment.
Russ
== == == == ==
Phillip:
Have you tried the SSID at the IETF meetings that is configured to make
use of 802.1x?
Russ
At 01:49 PM 3/24/2008, Hallam-Baker, Phillip wrote:
Secure WiFi Connection
I would like to see some demonstration of the fact that the default WiFi
configuration on all existing platforms provide
I cannot find one. It seem to be a hole than needs filled.
Russ
At 11:45 AM 3/23/2008, Christian Huitema wrote:
>Does the IETF have a policy regarding misrepresented identities?
>
>In the particular incident, it is assumed that the person using the
>name of a famous French aviation pioneer is
ed.
>
>With my thanks and my best regards
>--
>LB
>
>2008/3/21, Russ Housley <[EMAIL PROTECTED]>:
> > LB:
> >
> > Randy has responded quite publicly. I think his position is quite
> > clear. So, the next step is up to you.
> >
> >
LB:
Randy has responded quite publicly. I think his position is quite
clear. So, the next step is up to you.
Russ
At 08:38 PM 3/20/2008, LB wrote:
>Dear Sir,
>Like other members of the multilinguistic working list to which I
>belong, since 2002 I received a copy of the mails exchanged betwee
The archives of the NomCom WG that generated RFC 3777 are now online:
http://lists.elistx.com/archives/ietf-nomcom/
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Jari:
> Challenge for our IT folks: Internationalized Internet Drafts,
> including file names. Doable?
Six or seven years ago we had a big discussion regarding the
language(s) to be used in the IETF. Harald was IETF Chair when this
discussion took place, and he declared the consensus to be t
If you will be unable to connect home jabber server during the IPv6
outage, you can make an account for tonight. It will disappear tomorrow.
A test jabber server, jabber6.ietf.org, has been set up in IPV6 only.
Russ
___
IETF mailing list
IETF@ietf.o
Ted:
> >I really disagree. Gen-ART Reviews begin this way:
> >
> >I have been selected as the General Area Review Team (Gen-ART)
> >reviewer for this draft (for background on Gen-ART, please see
> >_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
> >
> >Please resolve th
Ted:
> >I think you completely misunderstand my point. A reviewer can make a
> >comment, and the authors or WG can say that they disagree. This is
> >important for an AD to see. The AD now needs to figure out whether
> >the reviewer is in the rough part of the rough consensus or whether
> >the
Lakshminath:
>It's a fair thing to say that the ADs need to see a response. I
>also agree that cross-area review is important and at times unearths
>issues that may not have been raised in WG-level
>reviews. Personally, I prefer cross-area reviews to take place
>prior to the LC process and h
Lakshminath:
>>So, I'll tell everyone how I deal with Gen-ART Reviews. Other
>>General ADs may have done things slightly different.
>>When I use a Gen-ART Review as the basis of a DISCUSS, I put it in
>>one of two categories.
>>(1) The Gen-ART Review was ignored. Like any other Last Call
>>c
Ted, Lakshminath, and the Rest of the IETF Community:
>I fail to understand why this has to be a guessing game.
The handling of reviews by non-IESG members seems to be an important
part of this discussion. So, I'll tell everyone how I deal with
Gen-ART Reviews. Other General ADs may have done
Ted:
Not oall of the IONs were "approved" for posting by the IESG. There
is one from the IAOC, for example. That was the point of "figure out
what to do."
Russ
At 04:01 PM 3/6/2008, Ted Hardie wrote:
>At 12:42 PM -0800 3/6/08, Brian E Carpenter wrote:
> >Ted,
> >
> >Firstly, it's not for me
Ted:
The call for comments has resulted in some input, and the IESG plans
to discuss that input at our meeting on Sunday. In fact there is
also an experiment on mail list suspension that we will be discussing
as well. The two experiments are listed on the web page:
http://www.ietf.org/IESG/c
John:
> > Timing did not allow this approach. Registration for this
> > meeting is being handled by AMS, our new Secretariat vendor.
> > However, we needed to open registration for this meeting
> > before ietf.org was moved from the old Secretariat vendor to
> > the new one. This approach see
Timing did not allow this approach. Registration for this meeting is
being handled by AMS, our new Secretariat vendor. However, we needed
to open registration for this meeting before ietf.org was moved from
the old Secretariat vendor to the new one. This approach seemed like
the best way to
.
If anyone else had trouble, please retry your registration. Several
people, including John, have successfully registered since the fix was made.
Sorry for any inconvenience,
Russ Housley
IETF Chair
___
IETF mailing list
IETF@ietf.org
http
have broad community support. The intent is to
generate a document that can be easily approved as an update to RFC
2026 that contains only the proposed changes with broad community support.
Russ Housley
General Area Director
___
Ietf mailing list
Ietf
This just came in. I think it is rushed, but there really many need
to be a venue to discuss the issues that have been raised by the Last
Call of draft-carpenter-rfc2026-changes.
Russ
This is a proposal for a BoF at the 71st IETF meeting (Philadelphia).
Proposed BoF title:
Procedures
Scott:
There have been several attempts to generate discussion on prior
versions of this document by its author. Very little resulted. I am
using the Last Call to make sure that discussion happens, and it has
worked. It has generated review, and not just superficial
review. And the result
Harald:
This is my reservation as well. The ION process has not been as
light-weight as I would like. Frankly, it is easier to generate an
IESG Statement than an ION.
Russ
At 05:27 PM 1/17/2008, Harald Alvestrand wrote:
Being the RFC author, I'm naturally very much interested.
still
The archives are being transitions too.
At 10:51 AM 1/14/2008, TS Glassey wrote:
What are the retention requirements here Ray and what are the
availability requirements per the Stored Communications Act is the
US and has this transition ever been scoped out against these
constraints? or is it
I meant let's hold off until the transition is complete. I did not
mean to confuse.
Russ
At 04:45 PM 12/20/2007, Dave Crocker wrote:
Russ Housley wrote:
We are transitioning the ietf.org mail lists to a new Secretariat
next month. I'd like to table this idea until that tra
Franck:
> And see if you can fix message readability, if I send a multi-part
> signed e-mail (TEXT+HTML) with PGP
>
> Like this one ;)
I do not understand what this has to do with DKIM.
Obviously I was able to read your message. Are you talking about in
mail list archives?
Russ
__
Mike:
We are transitioning the ietf.org mail lists to a new Secretariat
next month. I'd like to table this idea until that transition is
complete, and then raise it again when the new servers are up,
running, and stable. Let's get what we have moved and working before
improvements are made.
Stephane:
That is an interesting idea. I'd like to do that at some point, but
not at the same time as this experiment.
Russ
At 03:27 AM 12/17/2007, Stephane Bortzmeyer wrote:
I suggest a more radical experiment. We should all run a DNSSEC-aware
resolver on our laptops with a policy of "acce
This URL works for me ...
At 08:34 AM 12/14/2007, Stephane Bortzmeyer wrote:
http://www.ietf.org/rfc/rfc4390.txt
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
, just in case.
Many thanks,
Russ Housley
IETF Chair
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
>You need both physical (power, hardware, location) and
>operational (different global prefixes, preferably different
>AS's) diversity for reliable DNS.
We knew about this problem, but choose to make the announcement
anyway. We are in the process of working out a secondary. I got a
Draft minutes for the IETF 70 Wednesday evening plenary session have
been posted:
http://www3.ietf.org/proceedings/07dec/minutes/plenaryw.txt
Please review. Please help fill in the ??s.
Russ
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org
Alexey:
The latter. If the Auth48 completes before the 60 day appeal timer
has expired, then the RFC Editor will hold off on publication until
the 60 days have gone by.
Russ
P.S. A document that I wrote was the first document to get snagged in
this situation. I guess it is only fair
John:
RFC 2026 gives two months to appeal any decision. IESG approval of a
document publication is one such decision. RFC 2026, section 6.5.4 says:
All appeals must be initiated within two months of the public
knowledge of the action or decision to be challenged.
So, the two month tim
/2007, Lars Eggert wrote:
On 2007-11-28, at 20:08, ext Russ Housley wrote:
The IAOC plan for 2008 and 2009 is to have three meetings in North
America, two meetings in Europe, and one meeting in Asia. This
3:2:1 ration will be repeated for 2010 and 2011. So far, we are on
track to make this h
Lars:
The IAOC plan for 2008 and 2009 is to have three meetings in North
America, two meetings in Europe, and one meeting in Asia. This 3:2:1
ration will be repeated for 2010 and 2011. So far, we are on track
to make this happen.
The IETF web site is aligned with this plan:
Spring 2008
Bernard:
The worst case latency comes from the expert review with
non-disclosure agreements.
We really do believe that this will make the latency much more consistent.
Russ
At 10:02 AM 11/6/2007, Bernard Aboba wrote:
>I also think this is an appropriate, even if significant,
>change of pol
Simon:
I believe that is a poor argument, because the only implementation I am
aware of is the one I wrote. And I'm opposed to publication of the
document.
I am aware of two others. I do not think it is appropriate for me to
indicate the sources of the implementations; their authors should
The Secretariat tells me that Spammers are responding to TDMA queries
so that their mail goes through. They have made the suggestion that
we clear the list of people once per year. This would mean that a
legitimate user of a list that uses TDMA would get a TDMA query once
a year if they are n
Ted:
To begin with, I want to say that I agree with your perception of the
appeal process. It is an important conflict resolution tool.
The first thing that was done in the drafting of the appeal response
was to list each of the claims in the appeal. That is why the
introduction lists them
Ted:
With great respect, I must disagree. The appeal says: "It is the
position of the appellants that this removal violates the IETF
process by which working groups are governed." This say to me that
the appellants believe that Cullen Jennings violated IETF process by
replacing the GEOPRIV
Ran:
See section 7.1.2 of IEEE Std 802.11-1999. Figure 12 shows the MAC
Frame format, and the payload can be up to 2312 octets. However, you
need to consider the whole system. On the wired side, most Access
Points will be connected to Ethernet, which becomes the point that
limits the MTU s
Sorry. No it does not make any changes. Our practices remain the same.
Russ
At 02:34 PM 8/27/2007, Spencer Dawkins wrote:
Hi, Russ,
Spencer:
This document is intended to set expectations. It does not make
any normative changes to RFC 2026.
Russ
Got that part.
I'm actually asking wh
Spencer:
This document is intended to set expectations. It does not make any
normative changes to RFC 2026.
Russ
At 01:08 PM 8/27/2007, Spencer Dawkins wrote:
Hi, Russ,
A quick comparison with version 02 of this draft (from 2006,
currently listed in DEAD state) is showing minor typo corre
One important thing needs to be considered in the Security and O&M
Areas. There are two ADs, and they are expected to have somewhat
different skill sets. For contrast, here are the requirements that
were provided to NomCom2006 for these positions.
Russ
--
Done.
At 06:29 PM 7/23/2007, Brian E Carpenter wrote:
Also these descriptions have evolved from year to year
(there is a version in the IESG wiki too, at
http://www3.tools.ietf.org/group/iesg/trac/wiki/AreasDescription,
maybe the IESG should bring it up to date...)
___
I used the train yesterday, and it worked as advertised. It took 45
minutes, and it was cheap. However, it will be even slower for
people arriving this weekend. The train will stop running on a
portion of the Blue Line Friday at 11PM (last night) until early
Monday morning. A shuttle bus wi
> To put it in the terms I learned from my college tutor, the transport
> protocol enters into a contract with the application protocol.
> Provided both sides meet the contract each is entirely free to
> implement in whatever way they like. In this case the contract is with
> TLS, not a particul
ulian Reschke wrote:
Russ Housley wrote:
That is not the way the document arrived to the IESG. It said:
The type of authentication deployed is a local decision made by the
server operator. Clients are likely to face authentication schemes
that vary across server deployments. At a mi
1.0, making it the only version
that is permitted.
Russ
At 02:33 PM 7/13/2007, Julian Reschke wrote:
Russ Housley wrote:
No one had any concern with the version of TLS that was selected by
the working group. However, there were two things that cause me to
want a change. I'll let o
No one had any concern with the version of TLS that was selected by
the working group. However, there were two things that cause me to
want a change. I'll let others provide their own point of view.
1) History has shown that TLS implementations do a very good job
handling backward compatibil
There is one thing that needs to be highlighted at this
point. John's message come close to saying it, but it falls short.
There are at least two implementations of this TLS authorization
extension. These implementations use the code point that was
assigned by IANA while this document was in
http://www.ietf.org/internet-drafts/draft-dawkins-nomcom-start-earlier-00.txt
I want to highlight the posting of this individual submission, and
point to the mail list where it will be discussed. The mail list
that lead to RFC 3777 will be revitalized for this discussion:
[EMAIL PROTEC
quely aware of that the
rest of the IETF isn't. That makes you liable IMHO for any damages
someone suffers because of this failure to disclose. And since you
are a IETF Manager its worse.
Todd Glassey
----- Original Message - From: "Russ Housley" <[EMAIL PROTECTED]>
To
a simple work for hire.
I have no investors in my very small consulting company: Vigil
Security, LLC. I am the owner, and I am the only full-time employee.
Russ
ItAt 07:47 PM 4/7/2007, Dean Anderson wrote:
On Fri, 6 Apr 2007, Russ Housley wrote:
> Dean:
>
> >I'm still n
Dean:
I'm still not clear on a few things:
-- When did Russ Housley learn of the Patent Filing?
I was aware that Mark Brown was working on a patent; however, I did
not begin working with him until after his provisional patent
application was filed. I did not see the claims unti
osures are refused???
Todd Glassey
- Original Message ----- From: "Russ Housley" <[EMAIL PROTECTED]>
To: "Dean Anderson" <[EMAIL PROTECTED]>
Cc: "Mark Brown" <[EMAIL PROTECTED]>;
Sent: Friday, April 06, 2007 2:37 PM
Subject: RE: Withdrawal of App
301 - 400 of 455 matches
Mail list logo
