On Wed, 9 Feb 2005 09:56:22 -0800, Ted Hardie wrote:
ISOC has proposed this:
This document describes the structure of the IETF Administrative
Support Activity (IASA) as an IETF-managed activity housed within the
Internet Society (ISOC).
to replace this:
This document describes
Hi Dave,
Sitting on both sides of this particular fence, I actually _don't_
think that we have a strategic disagreement about who would control
(using that term in it's normal English sense) this activity. The
document is very clear that the IETF makes the rules about how the
IASA will work
--On 11. februar 2005 07:03 -0500 Margaret Wasserman
[EMAIL PROTECTED] wrote:
So, with my ISOC Board hat on (a hat which none of the ISOC Board members
are legally allowed to take off), I am not inclined to ignore legal
advice from ISOC's corporate counsel. Maybe the IETF Chair could ask the
In reviewing the IASA BCP I noticed a minor issue:
S 2.2 and 3.1 refer to perpetual right to use, display, etc.
The standard language here typically includes both royalty-free
(or fully-paid up) and irrevocable. I would particularly think
we want to specify that no future royalties are due.
-Ekr
On Fri, 11 Feb 2005 09:09:57 +0200 (EET), Pekka Savola
[EMAIL PROTECTED] wrote:
Yes, it was clear that this WG would only deal with IPv6.
It was not clear *why* this WG is being chartered to only deal with
IPv6.
What I fear is that unless the IETF does v4, someone else (ITU?)
will...
The current text says:
In no circumstances may the IAB or
ISOC Board of Trustees overturn a decision of the IAOC that nvolves
a binding contract or overturn a personnel-related action (such as
hiring, firing, promotion, demotion, performance reviews, salary
adjustments, etc.).
Margaret objected
--On 11. februar 2005 07:10 -0800 Eric Rescorla ekr@rtfm.com wrote:
In reviewing the IASA BCP I noticed a minor issue:
S 2.2 and 3.1 refer to perpetual right to use, display, etc.
The standard language here typically includes both royalty-free
(or fully-paid up) and irrevocable. I would
For myself, I find the arguments on both sides of controlled
and managed to be compelling -- perhaps because I am not a
lawyer.
However, I am conscious that the words we write down are scrutinized
and used by people the world over -- not always to our benefit,
and often without any of the context
A couple other comments:
Fred Baker wrote:
ISOC proposes to replace this:
Within the constraints outlined above, all other details of how to
structure this activity within ISOC (whether as a cost center, a
department, or a formal subsidiary) shall be determined by ISOC in
Russ Housley floated the idea that the BCP might contain more guidance to
the ISOC BoT on how to select an IAOC member.
I read the consensus of the list to be that it's more appropriate for the
ISOC BoT to figure out this on its own, and perhaps publish what procedure
and criteria they use at
--On 11. februar 2005 11:52 -0500 Leslie Daigle [EMAIL PROTECTED]
wrote:
To try to minimize the change from the original edits, may I suggest
this:
Should the IETF standards process at some future date come to
include other technical activities, the IAOC is responsible for
After listening to Fred and Ted about the possible ways ISOC can organize
the IASA formally, it occured to me that I don't think the words were
intended to be an exclusive list of the possibilities, just a list of some
imaginable possibilities.
So this is what I have in my edit buffer:
On Fri, 11 Feb 2005, Harald Tveit Alvestrand wrote:
Russ Housley floated the idea that the BCP might contain more guidance to
the ISOC BoT on how to select an IAOC member.
I read the consensus of the list to be that it's more appropriate for the
ISOC BoT to figure out this on its own, and
Title: Converted from Rich Text
SMS's for some languages are indeed in unicode, often one message is sent in a multipart message - i.e. - in more than one message. Even in various Nordic languages that have strange things like , , ... SMS's are sent in unicode.
Some cell phones sport
At 10:56 PM -0500 1/29/05, Bruce Lilly wrote:
Q: Is there a list of changes from RFC 2476? [As the request is to
advance to Draft status, it would be nice to know if any changes
are of such scope and substance as to warrant remaining at
Proposed. Such a list would also aid reviewers,
At 3:03 PM -0500 2/10/05, Bruce Lilly wrote:
On Thu February 10 2005 10:42, Nathaniel Borenstein wrote:
On Jan 29, 2005, at 10:56 PM, Bruce Lilly wrote:
Q: Is there a list of changes from RFC 2476? [As the request is to
advance to Draft status, it would be nice to know if any changes
At 3:03 PM -0500 2/10/05, Bruce Lilly wrote:
On Thu February 10 2005 10:42, Nathaniel Borenstein wrote:
On Jan 29, 2005, at 10:56 PM, Bruce Lilly wrote:
Q: Is there a list of changes from RFC 2476? [As the request is to
advance to Draft status, it would be nice to know if any changes
At 10:24 PM +0100 2/10/05, Harald Tveit Alvestrand wrote:
This sounds like a change that requires recycling at proposed.
I could argue this both ways; every implementation that is valid
under the draft standard would also be a valid implementation under
the proposed one, but not vice versa;
At 10:56 PM -0500 1/29/05, Bruce Lilly wrote:
Q: Is there a list of changes from RFC 2476? [As the request is to
advance to Draft status, it would be nice to know if any changes
are of such scope and substance as to warrant remaining at
Proposed. Such a list would also aid reviewers,
Leslie,
this works for ISOC.
Lynn
At 11:15 AM -0500 2/11/05, Leslie Daigle wrote:
That makes the entire abstract:
This document describes the structure of the IETF Administrative Support
Activity (IASA) as an activity housed within the Internet Society
(ISOC). It defines the roles and
Hi Leslie -
For myself, I find the arguments on both sides of controlled
and managed to be compelling -- perhaps because I am not a
lawyer.
Finding both sides compelling makes you very qualified
to be a lawyer. ;)
snip
So, if the token really doesn't mean anything (per Jorge) because
Hi Harald,
At 5:02 PM +0100 2/11/05, Harald Tveit Alvestrand wrote:
In no circumstances may the IAB or
ISOC Board of Trustees overturn a decision of the IAOC that involves
a binding contract or overturn a personnel-related action (such as
hiring, firing, promotion,
At 11:15 AM -0500 2/11/05, Leslie Daigle wrote:
So, if the token really doesn't mean anything (per Jorge) because
the import is in the text of the document, perhaps the right
answer is to just *drop* that clause.
This document describes the structure of the IETF Administrative
Support Activity
On rescanning (and rescanning) the text, I find that irrevocable is
already in there (!), but I have some problems with where to fit fully
paid up, since it is really only relevant to licensing, while most of the
text talks about rights.
There is one paragraph that does talk about licensing,
On re-reading this, I can't figure out how to make it scan properly - the
reason being that both paragraphs you point at talk about right to use,
while fully-paid-up, royalty-free and irrevocable typically applies
to one particular type of rights assignment - licensing.
Leslie has already
Harald Tveit Alvestrand [EMAIL PROTECTED] writes:
On rescanning (and rescanning) the text, I find that irrevocable is
already in there (!), but I have some problems with where to fit
fully paid up, since it is really only relevant to licensing, while
most of the text talks about rights.
I do not think that the ISOC BoT would be constrained to providing advice
in the situation you describe. It would, however, have to say this is an
actiobn we take because we have a responsibility for ISOC, not because
we're investigating this single issue.
While this sounds a lot like I am
--On 11. februar 2005 14:10 -0500 Margaret Wasserman
[EMAIL PROTECTED] wrote:
I'm also somewhat uncomfortable with the process that is resulting in
these changes (the ones that I have suggested, as well as the ones that I
don't like)... We seem to be changing the document quite frequently
--On 11. februar 2005 14:10 -0500 Margaret Wasserman
[EMAIL PROTECTED] wrote:
I continue to hold to the same theory: That I'll hold a DISCUSS for
the document at least 7 days past its final change.
Okay, that sounds reasonable.
I got confused somewhere along the line, and I though that you were
Margaret,
Four observations...
(1) While I can follow your concern, I see nothing in the text
that prevents the ISOC BoT from exerting whatever oversight and
review authority it has just because it became aware of
something because of an appeal. The text says as the _result_
of an appeal
--On torsdag, februar 10, 2005 10:49:50 -0500 Bruce Lilly
[EMAIL PROTECTED] wrote:
1. I have in mind a keyboard on a certain device which has
support for protocols which use domain names (HTTP, SMTP/
Internet Message Format, VPIM). It has a keyboard which
is at best inconvenient
So we checked with our lawyer. Unlike the IETF, which is always completely
smooth in its consensus and never finds experts differing in opinion, it
would appear that in the legal profession experts can differ in their opinions.
That said, he classed the issue as, in IETF terms, the difference
In reviewing the IASA BCP I noticed a minor issue:
S 2.2 and 3.1 refer to perpetual right to use, display, etc.
The standard language here typically includes both royalty-free
(or fully-paid up) and irrevocable. I would particularly think
we want to specify that no future royalties are due.
On February 10, draft-harrison-email-tracking-00.txt was
announced on the ID-announce mailing list.
Assuming that the draft is not intended to be a precursor of
an April 1 RFC, I have several comments. Since the draft
mentions no place for public discussion, I am copying the
IETF discussion
Date: 2005-02-10 19:09
From: Randall Gellens [EMAIL PROTECTED]
At 3:03 PM -0500 2/10/05, Bruce Lilly wrote:
There are some differences between what the draft says and that
description:
1. the draft explicitly permits operation on port 25
2. the draft section 4.3 doesn't mention
Date: 2005-02-11 12:55
From: John Loughney [EMAIL PROTECTED]
SMS's for some languages are indeed in unicode, often one message is sent in
a multipart message - i.e. - in more than one message. Even in various Nordic
languages that have strange things like , , ... SMS's are sent in
The IESG has received a request from the Simple Authentication and Security
Layer WG to consider the following document:
- 'The Plain SASL Mechanism '
draft-ietf-sasl-plain-06.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
37 matches
Mail list logo
