I would agree with Brian, but phrase it differently.
The Trust Legal Provisions document specifies exactly how the trust, and
people acting based on the trust, are doing things.
There are (at least) two kinds of changes that can occur.
1) There can be changes in policy, particularly policy as
I agree with the proposed policy, except that I propose
calling it just "Procedure". It isn't policy, it's just
common sense about how to implement policy.
On 2009-08-18 07:57, Simon Josefsson wrote:
...
> This is another reason why the current approach of getting IETF
> consensus on an RFC and pu
Dear experts,
Generally, the idea of "provision" includes a kind of "bad debt allowance"
in accounting. How about expanding the idea of "Trust Legal Provision"?
Gathering statistically of mathematical probability of how setting for bad
debt allowance could be a kind of measurement of ability o
SM:
Does the IETF Trust want to stand in as a replacement for the old IPR WG?
Certainly not. The changes that people might suggest to the TLP
should be much less grand.
Russ.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/list
Hi Marshall,
I'll take this opportunity to say that I was pleasantly surprised to
hear that the IETF Trust implemented a IETF Trust Records Retention
and Management Policy over two years ago.
At 08:02 17-08-2009, Marshall Eubanks wrote:
Comments sought for: Standard Procedure for Modifying
Marc Blanchet writes:
> Marshall Eubanks a écrit :
>>
>> On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote:
>>
>>> Marshall Eubanks a écrit :
Emergencies. An emergency is defined as "there is a problem with the
TLP that is likely to be abused". In these cases, the trust can
>>
Marshall Eubanks a écrit :
>
> On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote:
>
>> Marshall Eubanks a écrit :
>>>
>>> Emergencies. An emergency is defined as "there is a problem with the
>>> TLP that is likely to be abused". In these cases, the trust can
>>> publish
>>> a modified text fo
Marshall Eubanks a écrit :
>
> Emergencies. An emergency is defined as "there is a problem with the
> TLP that is likely to be abused". In these cases, the trust can publish
> a modified text for a 2 week review period, then modify the TLP. The
> Trust must explain the reason for the chan
Glen Zorn wrote:
> Alan DeKok wrote:
> ... It would have been preferable ...
> To which I reply:
>
> So it seems that what you _really_ meant was "... well, screw 'em."
I think there is a miscommunication here.
Alan DeKok.
___
Ietf mailing list
Glen Zorn wrote:
> But none of the Attributes mentioned in Appendix B have anything to do with
> RADIUS security as I understand it. Can you explain?
From the document:
Appendix B includes a
listing of complex attributes used within [RFC2865], [RFC2868],
[RFC2869], [RFC3162], [RFC4818
Dear Simon;
Some quick responses just for myself only.
On Aug 17, 2009, at 11:36 AM, Simon Josefsson wrote:
Marshall Eubanks writes:
Comments sought for: Standard Procedure for Modifying the TLP
Is this a solution looking for a problem? RFC 5377 is an example of
where the IETF asks the
On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote:
Marshall Eubanks a écrit :
Emergencies. An emergency is defined as "there is a problem with the
TLP that is likely to be abused". In these cases, the trust can
publish
a modified text for a 2 week review period, then modify the TLP.
Marshall Eubanks writes:
> Comments sought for: Standard Procedure for Modifying the TLP
Is this a solution looking for a problem? RFC 5377 is an example of
where the IETF asks the Trust do something. What is wrong with using
the same approach in the future? The approach would be that someon
Hi Marshall, all,
This is a good proposal.
Would it be possible to enhance the review periods (steps 5 and 6) from
30/14 days to something like 60/30 days, respectively? Many people will
need to go through corporate counsel on matters like this, which can be time
consuming. 30 days is a quite t
Greetings;
During the last review of the Trust Legal Provisions (TLP),
it became clear that there is no clear
procedure for modifying the TLP. The current TLP only states that a new
version may be published for community review but not who can ask for
a change,
where announcements are sent, wh
Hi, Julian,
I agree with your point here (on how RFC 2119 works). I thought the document
would be clearer with 2119 language here, but it should not be included if
you aren't comfortable using it.
Thanks,
Spencer
Spencer Dawkins wrote:
...
3. WebDAV extended MKCOL
The WebDAV MKCOL re
Spencer Dawkins wrote:
...
3. WebDAV extended MKCOL
The WebDAV MKCOL request is extended to allow the inclusion of a
request body. The request body is an XML document containing a
single DAV:mkcol XML element as the root element. The Content-Type
Spencer (minor): if I'm reading this pa
Stephen
As Dan and Bert think and believe, I guess #1.
My experience with other technologies is that where enterprise systems
are involved, then authorisation is likely to be powerful and comprehensive (and
proprietary) but where network and operators are involved, then this is not so.
Tom Petch
18 matches
Mail list logo
