Hi Russ,
At 12:07 07-09-2009, Russ Housley wrote:
I'm sorry that you read it that way. The first response that was
drafted was a point-by-point reply as you suggest. It was extremely
repetitive, with the same points being made over and over. I found
the reply cumbersome at best. It was my
Simon Josefsson wrote:
Marshall Eubanks t...@americafree.tv 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
Henk Uijterwaal h...@ripe.net writes:
Simon Josefsson wrote:
Marshall Eubanks t...@americafree.tv 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
On Sep 8, 2009, at 2:06 PM, Simon Josefsson wrote:
I'm strongly concerned that this puts the decision making of what
is and
what is not a problem into the Trust's hands.
No, there is always step 5: review of the new text or decision not
to change
the text. If a suggestion isn't
Simon,
I wish that is how it would work. The most recent change of the TLP was
not following that process -- instead the Trust proposed the change and
implemented it after some delay -- and, for example, it resulted in a
change to how BSD licensed portions extracted from IETF documents that
is
On Sep 8, 2009, at 4:13 PM, Polk, William T. wrote:
I believe Sam's suggestion offers a good compromise position: if the
IESG
and RFC Editor do not come to an agreement, we should last call the
proposed
IESG Note and let the community determine whether (1) this is an
exceptional
case
Pete Thomas:
This response is my own. I have not coordinated it with the Trustees.
Without taking positions on the specifics of the appeal or the
response, I have to say that my take on the response is that it
doesn't properly address the appeal and is inadequate.
I would have expected
Olaf Kolkman o...@nlnetlabs.nl writes:
On Sep 8, 2009, at 2:06 PM, Simon Josefsson wrote:
I'm strongly concerned that this puts the decision making of what
is and
what is not a problem into the Trust's hands.
No, there is always step 5: review of the new text or decision not
to change
Simon Josefsson wrote:
If a proposal from the IETF is in conflict with the terms of the Trust
Agreement or the law then a Trustee has the obligation to veto it (a
fairly academic possibility, I believe).
I don't see how that is related to step 4 above. There is plenty of
mechanisms left for
--On Tuesday, September 08, 2009 16:36 +0200 Olaf Kolkman
o...@nlnetlabs.nl wrote:
On Sep 8, 2009, at 4:13 PM, Polk, William T. wrote:
I believe Sam's suggestion offers a good compromise position:
if the IESG
and RFC Editor do not come to an agreement, we should last
call the proposed
Henk Uijterwaal h...@ripe.net writes:
Simon Josefsson wrote:
If a proposal from the IETF is in conflict with the terms of the Trust
Agreement or the law then a Trustee has the obligation to veto it (a
fairly academic possibility, I believe).
I don't see how that is related to step 4 above.
Hi Sean
Thanks for the response - all looks good to me.
In regards to the 'exact' matching, I raised that because the X.500/LDAP
countryName attribute behaves in a case insensitive manner for these country
codes - i.e. 'AU' will match 'au'.
Not that it matters at all - but if you're thinking
In my opinion, 3932bis is internally inconsistent about IESG notes. This
document expressly directs the IESG to reserve IESG notes for exceptional
cases, but then leaves the decision on whether the note should be included
to the RFC Editor:
In exceptional cases, when the
Olaf,
I meant the IETF community. Since the note would exist to clarify the
relationship with documents developed by the IETF community, that seems the
right one to evaluate whether a note is needed.
As to who calls the consensus, that is a tricky one. How about the IAB
chair?
Tim
On
Dear Trustees,
I agree with the message from Thomas Narten, cc:ed below. I expected,
and request that you provide, a reply to John Klensin's appeal that is
more directly responsive to the issues that John raised.
Also, I agree with John's concerns about discussion of this appeal
being
Tim, I definitely agree with you that it should be the IETF community
that is last called.
Normally, the IESG judges IETF consensus.
However, if it makes the IAB more comfortable for the IAB chair to do the
consensus call, that's fine with me. If we do that we'd need to make
it clear how this
Hello,
We have updated the draft to address all comments.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-1
1.txt
In summary, here is a list of the major changes:
1. Enhanced to the security text mainly under section 6.1. and section
13
Dear ietf@ietf.org,
Is it too late for me to submit comments for this draft?
Regards.
/thomas/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Polk, William T. wrote:
I believe Sam's suggestion offers a good compromise position: if the IESG
and RFC Editor do not come to an agreement, we should last call the proposed
IESG Note and let the community determine whether (1) this is an exceptional
case meriting a note and (2) if the text
Andrew,
I think that's a good idea. I'll switch it to be case insensitive.
Cheers,
spt
Andrew Sciberras (GMAIL) wrote:
Hi Sean
Thanks for the response - all looks good to me.
In regards to the 'exact' matching, I raised that because the X.500/LDAP
countryName attribute behaves in a case
Time to move to Draft Standard.
http://idle.slashdot.org/story/09/09/08/1414248/SAs-Largest-Telecomms-Provid
er-vs-a-Pigeon
Richard Shockey
PSTN Mobile: +1 703.593.2683
mailto:richard(at)shockey.us
skype/AIM: rshockey101
LinkedIn : http://www.linkedin.com/in/rshockey101
I don't disagree with what you're saying below. I'm advocating that a
privacy policy should exist -- what the policy says is another matter.
For example, the policy might say, The IETF collects your data and
sells it to identity thieves. Although I doubt that's what it would
say, it would
I view having the policy in place as the first step. Once there's a
policy, we can think about formalizing a process to update the policy.
Ideally, when a new experiment introduces a new kind of data
collection or use, we would think about the privacy impact in advance
of launching the
Alissa,
It's not totally clear because it is an EXPERIMENT and typically one
does not develop a bunch of policies for how a particular technology
might be used once it's up and running --- if we were to adopt it
prior to actually running the experiment. There is clearly, today,
no legal
At 4:21 PM -0700 9/8/09, Ole Jacobsen wrote:
Alissa,
It's not totally clear because it is an EXPERIMENT and typically one
does not develop a bunch of policies for how a particular technology
might be used once it's up and running --- if we were to adopt it
prior to actually running the
The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:
- 'Asynchronous Layered Coding (ALC) Protocol Instantiation '
draft-ietf-rmt-pi-alc-revised-08.txt as a Proposed Standard
This document has a normative reference to RFC 3738:
The IESG has approved the following document:
- 'Application of Ethernet Pseudowires to MPLS Transport Networks '
draft-ietf-pwe3-mpls-transport-04.txt as an Informational RFC
This document is the product of the Pseudowire Emulation Edge to Edge Working
Group.
The IESG contact persons are
The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Updated IANA Considerations for Diameter Command Code Allocations '
draft-ietf-dime-diameter-cmd-iana-01.txt as a Proposed Standard
The IESG plans to make a decision
The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records
for DNSSEC '
draft-ietf-dnsext-dnssec-rsasha256-14.txt as a Proposed Standard
The IESG plans to make a decision
The IESG has received a request from the Mobility for IP: Performance,
Signaling and Handoff Optimization WG (mipshop) to consider the following
document:
- 'Fast Handovers for Proxy Mobile IPv6 '
draft-ietf-mipshop-pfmipv6-09.txt as a Proposed Standard
The IESG plans to make a decision in
The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Requirements for Federated File Systems '
draft-ietf-nfsv4-federated-fs-reqts-03.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and
31 matches
Mail list logo
