Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)

[Henk Uijterwaal]

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 Trust do something.  What is wrong with using
the same approach in the future?   The approach would be that someone
writes an I-D, there is IETF-wide last call on it, and it is either
approved or not.   If it is approved, the Trust needs to act.


Correct and this document specifies how the trust will react: it takes
the guidance (for example, RFC 5377), modifies the text, gets legal
advice and proposes an implementation to the community.  The community
reviews the changes and checks that what is implemented, is what is
requested.



2. Whoever brings up the problem, writes a problem statement.
   a. In case 1a: this can be an individual submission ID or a ID from
a WG
  chartered to discuss these items.
   b. In case 1b: A note from the trust to the community.
   c. In case 1c: A note from whoever brings up the issue.


For 2c, whom is the note to?  To only the trust or to the community?  If
the former, will be trust communicate the request to the community?


2c are cases where the Trust manages something for another stream, so in
first order, I'd say that the note is for the trust and that other stream.
I don't see a problem sending it else where though.




4. Trust (with legal counsel) reviews the issue and comes up with a
response:
   a. No, we don't think changing this is a good idea, because ...

   b. Yes, we suggest to modify the text as follows ... (perhaps with
  some background material why this is the answer).


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 considered a good idea by the Trust, the
reasons for not changing it can be discussed in this step.

The trust is there to protect the IPR held by the IETF, if the community
comes up with a suggestion that has a negative impact on that, I want the
Trust to be able to warn the community about this, rather than blindly
implement the change.

Henk

--
--
Henk Uijterwaal   Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre  http://www.xs4all.nl/~henku
P.O.Box 10096  Singel 258 Phone: +31.20.5354414
1001 EB Amsterdam  1016 AB Amsterdam  Fax: +31.20.5354445
The NetherlandsThe NetherlandsMobile: +31.6.55861746
--

Belgium: an unsolvable problem, discussed in endless meetings, with no
 hope for a solution, where everybody still lives happily.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)

[Simon Josefsson]

Henk Uijterwaal  writes:

> 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 Trust do something.  What is wrong with using
>> the same approach in the future?   The approach would be that someone
>> writes an I-D, there is IETF-wide last call on it, and it is either
>> approved or not.   If it is approved, the Trust needs to act.
>
> Correct and this document specifies how the trust will react: it takes
> the guidance (for example, RFC 5377), modifies the text, gets legal
> advice and proposes an implementation to the community.  The community
> reviews the changes and checks that what is implemented, is what is
> requested.

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 not consistent with common practice.

>>> 2. Whoever brings up the problem, writes a problem statement.
>>>a. In case 1a: this can be an individual submission ID or a ID from
>>> a WG
>>>   chartered to discuss these items.
>>>b. In case 1b: A note from the trust to the community.
>>>c. In case 1c: A note from whoever brings up the issue.
>>
>> For 2c, whom is the note to?  To only the trust or to the community?  If
>> the former, will be trust communicate the request to the community?
>
> 2c are cases where the Trust manages something for another stream, so in
> first order, I'd say that the note is for the trust and that other stream.
> I don't see a problem sending it else where though.

2c does not seem restricted for non-IETF streams from the writing above.
I think it is important that the IETF is notified for issues relating to
the IETF stream.

>>> 4. Trust (with legal counsel) reviews the issue and comes up with a
>>> response:
>>>a. No, we don't think changing this is a good idea, because ...
>>>
>>>b. Yes, we suggest to modify the text as follows ... (perhaps with
>>>   some background material why this is the answer).
>>
>> 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 considered a good idea by the Trust, the
> reasons for not changing it can be discussed in this step.

Step 4 puts a veto for changes into the Trust's hands.  Members on the
Trust can be removed by the IETF, but I don't believe that is a good way
to make the Trust to do something the IETF requests.

/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)

[Olaf Kolkman]

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 considered a good idea by the  
Trust, the

reasons for not changing it can be discussed in this step.


Step 4 puts a veto for changes into the Trust's hands.  Members on the
Trust can be removed by the IETF, but I don't believe that is a good  
way

to make the Trust to do something the IETF requests.




As a Trustee I've signed a statement that reads:

 3. The undersigned hereby agrees to serve as a Trustee to the Trust  
and to fulfill the
duties of a Trustee in accordance with the terms of the Trust  
Agreement and all
other requirements of law applicable to service as a trustee of a  
Virginia trust and
to comply with all requirements of the Trust Agreement applicable  
to his/her

service as a Trustee

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


However, if such happens I think that the Trust has the obligation  
(MUST) to explain the motivations in quite some detail, and explain  
why they did not catch the problem earlier in the process.



--Olaf




Olaf M. KolkmanNLnet Labs
   Science Park 140,
http://www.nlnetlabs.nl/   1098 XG Amsterdam



PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Proposed Policy for Modifications to Trust Legal Provisions (TLP)

[Henk Uijterwaal]

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 not consistent with common practice.


That is correct.  One of the things we learned from the discussions around
the last TLP changes, was that there was no clear process to follow when
the TLP needs to be changed.  This proposal is there to fix that.


2c does not seem restricted for non-IETF streams from the writing above.
I think it is important that the IETF is notified for issues relating to
the IETF stream.


2c says case 1c, 1c deals with all non IETF streams that the Trust manages.

(For the last point, please see Olaf's mail.)

Henk


--
--
Henk Uijterwaal   Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre  http://www.xs4all.nl/~henku
P.O.Box 10096  Singel 258 Phone: +31.20.5354414
1001 EB Amsterdam  1016 AB Amsterdam  Fax: +31.20.5354445
The NetherlandsThe NetherlandsMobile: +31.6.55861746
--

Belgium: an unsolvable problem, discussed in endless meetings, with no
 hope for a solution, where everybody still lives happily.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Olaf Kolkman]

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 meriting a note and (2) if the text accurately clarifies the
relationship.



Which community, The IETF community or the wider RFC community? And  
who calls the consensus?




--Olaf




Olaf M. KolkmanNLnet Labs
   Science Park 140,
http://www.nlnetlabs.nl/   1098 XG Amsterdam



PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Trust response to the appeal by John C Klensin (July 18, 2009

[Russ Housley]

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 the specific issues raised in the appeal to 
be responded to in a direct manner, with a clear response as to 
whether the point is agreed to (or not) and what (if any) remedy 
is forthcoming.


Instead, the response smacks of trying not to respond directly to 
the appeal, but say "here is what we have been doing, let's please 
just move on". IMO, that just doesn't cut it.


IMO, an appeal needs to be responded to with directness and with clarity.


I agree.


I'm sorry that you read it that way.


I'm sorry, Russ, but I didn't "read it that way." It *is* that way. 
It does not respond to the specific points and requests in the 
appeal. Saying that you are sorry that Thomas (and I) "read it that 
way" comes across as you saying "I'm sorry you were unable to read 
the true meaning." It's, frankly, a non-apology and a bit condescending.


My reply was certainly not meant to be condescending.  I was trying 
to indicate the process that was used.  Point-by-point responses were 
formulated in a group discussion.  When they were written done, the 
same points were made over and over.  This did not seem to me to be a 
useful reply.  So, I suggested restructuring the response with the 
same material.


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 suggestion that we take the points that were made 
over and over in that formulation of the response and structure it this way.


I see nothing in the appeal that would require repetition, which 
indicates to me that perhaps the Trustees did not actually attempt 
to answer the points of the appeal, or that the repetetive answers 
all amounted to "no, we're not going to do that".


I can tell you that is not the case.  In fact, the response indicates 
that the Trustees recognize places where they were deviation from the 
will of the community, and the actions that will be taken to 
improve.  They include no more proactive TLP changes as well as more 
timely and complete minutes.



How about answers to these questions:

On point (i) of the appeal: Will the Trustees cease taking action 
(except for "emergencies") until minutes are up to date? No answer 
was specifically given in the reply. If the answer is "yes", the 
Trustees will need a specific answer to (ii), since I have already 
seen the posting with regard to the new TLP due to go into effect 
September 12. Either the Trustees have hereby declared "an 
emergency", or the answer to point (i) is, "no, we will continue 
taking actions even though minutes are not up to date."


The appeal response indicates the actions that are being taken to get 
the minutes up to date.  There are several documents in the RFC 
Editor queue that were blocked waiting for TLP 3.0 to be posted.  I 
strongly encouraged the Trustees to proceed with the posting of TLP 
3.0 so that the real work product of the IETF was not further 
delayed.  This argument was persuasive to the other Trustees.


(For the record, the minutes wherein the decision to post the new 
TLP was taken are also not posted.)


Understood.

On point (ii) of the appeal: Have the Trustees found that an 
emergency exists now (and if so, where is the explanation of that 
emergency)? In the future, will the Trustees explain to the 
community when such an emergency exists? I find neither answer in the reply.


As explained above, we did feel some urgency to unblock IETF stream 
documents in the RFC Editor Queue.  there are other non-IETF stream 
documents that need other actions to unblock.  However, direction 
from each of those streams is needed before any action can be taken 
by the Trustees.  That is, the Trustees are not going to take 
proactive actions here.  The Trustees are waiting on the direction 
from those streams.


On point (iii) of the appeal: Did the Trustees find that a proper 
Last Call was done on the TLP? Did the Trustees find that changes 
made to the proposed TLP were small enough as to not warrant a new 
Last Call? Neither of these questions is answered in the reply.


This was not answered in the appeal response, but it was fully 
answered on the list.  With more than a week to go in the 30 day 
comment period, the Trustees listed the changes that would not be 
included based on the community comment, and the Trustees stated that 
several proposed changes had received no negative comment and the 
Trustees intended to implement those unless comments to the contrary 
were received in the remainder of the comment period.  Those changes 
were implemented in TLP 3.0.  The urgency for one of those changes 
has a

Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)

[Simon Josefsson]

Olaf Kolkman  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
>>> the text.  If a suggestion isn't considered a good idea by the
>>> Trust, the
>>> reasons for not changing it can be discussed in this step.
>>
>> Step 4 puts a veto for changes into the Trust's hands.  Members on the
>> Trust can be removed by the IETF, but I don't believe that is a good
>> way
>> to make the Trust to do something the IETF requests.
>
> As a Trustee I've signed a statement that reads:
>
>  3. The undersigned hereby agrees to serve as a Trustee to the Trust
> and to fulfill the
> duties of a Trustee in accordance with the terms of the Trust
> Agreement and all
> other requirements of law applicable to service as a trustee of a
> Virginia trust and
> to comply with all requirements of the Trust Agreement applicable
> to his/her
> service as a Trustee
>
> 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 the Trust to veto changes to become effective -- for
example, you can just refuse to approve the change -- however my point
is about having the trust be able to cancel the process to modify the
TLP even before it has been subject to community discussion.  That
approach appears contrary to the concept that the Trust carries out the
wishes of the IETF and not the other way around.

/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Proposed Policy for Modifications to Trust Legal Provisions (TLP)

[Henk Uijterwaal]

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 the Trust to veto changes to become effective -- for
example, you can just refuse to approve the change -- however my point
is about having the trust be able to cancel the process to modify the
TLP even before it has been subject to community discussion.  That
approach appears contrary to the concept that the Trust carries out the
wishes of the IETF and not the other way around.


I don't see how this is possible:  If the community believes that a
change should be made, the Trust has to (at least) review it and
explain why it believes that this is not a good idea.  This brings
us to phase 5, community discussion, where one can discuss the
arguments for not making the change.

At this point several things can happen.  One possibility is that the
community really wants the change but the Trust doesn't.  In that
case, there is an possibility for appeal.

Henk

--
--
Henk Uijterwaal   Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre  http://www.xs4all.nl/~henku
P.O.Box 10096  Singel 258 Phone: +31.20.5354414
1001 EB Amsterdam  1016 AB Amsterdam  Fax: +31.20.5354445
The NetherlandsThe NetherlandsMobile: +31.6.55861746
--

Belgium: an unsolvable problem, discussed in endless meetings, with no
 hope for a solution, where everybody still lives happily.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Tuesday, September 08, 2009 16:36 +0200 Olaf Kolkman
 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
>> IESG Note and let the community determine whether (1) this is
>> an   exceptional
>> case meriting a note and (2) if the text accurately clarifies
>> the relationship.
> 
> 
> Which community, The IETF community or the wider RFC
> community? And who calls the consensus?

Also, please remember, again, that the IESG _always_ has the
right and opportunity to publish a dissent as a separate RFC in
the IETF Track.  If that dissent is wildly out of line with the
wishes of the IETF community, the IETF community presumably has
ways to deal with that.  Anything sufficiently controversial to
justify the procedure above almost certainly justifies that
treatment because a separate RFC can document reasoning and
context, while any plausible note (and all such notes so far,
including the texts specified in 3932) merely provide a
statement of conclusions.

The main argument I've heard against that approach is that the
IESG doesn't have the time.  But, if it doesn't, then a full
community review as described above, with the inevitable
community fine-tuning of text, is certainly going to equally
time-consuming.  The issue justifying comment is either
important or it is not, and allowing the IESG to impose a note
by a cryptic comment (whether intentionally so or not) in
minutes and/or the tracker doesn't serve either the community
nor the separation of streams well.

Perhaps we should be discussing supplementing "Obsoletes" and
"Updates" in RFC headers and the index with "Dissents from",
"Heaps abuse upon", and/or "Ridicules" to make the intended
relationships among document more clear, but...

john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Proposed Policy for Modifications to Trust Legal Provisions (TLP)

[Simon Josefsson]

Henk Uijterwaal  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.  There is plenty of
>> mechanisms left for the Trust to veto changes to become effective -- for
>> example, you can just refuse to approve the change -- however my point
>> is about having the trust be able to cancel the process to modify the
>> TLP even before it has been subject to community discussion.  That
>> approach appears contrary to the concept that the Trust carries out the
>> wishes of the IETF and not the other way around.
>
> I don't see how this is possible:  If the community believes that a
> change should be made, the Trust has to (at least) review it and
> explain why it believes that this is not a good idea.  This brings
> us to phase 5, community discussion, where one can discuss the
> arguments for not making the change.

Exactly.  What step 4 does is to allow the trust to cancel the community
review by declaring that it doesn't agree.

> At this point several things can happen.  One possibility is that the
> community really wants the change but the Trust doesn't.  In that
> case, there is an possibility for appeal.

Step 6 allows the trust to evaluate the community request and veto the
request if needed.

What I'm objecting to is to allow the trust to veto the TLP changes as
early as step 4, before there has been community review of the proposal.

/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-turner-deviceowner-attribute (Device OwnerAttribute) to Informational RFC

[Andrew Sciberras (GMAIL)]

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 of altering the behavior
to be case insensitive, then this will align it with the way that country
codes are used in LDAP and X.500.  

Andrew. 

-Original Message-
From: Sean Turner [mailto:turn...@ieca.com] 
Sent: Thursday, 3 September 2009 3:41 AM
To: Andrew Sciberras (GMAIL)
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-turner-deviceowner-attribute (Device
OwnerAttribute) to Informational RFC

Andrew,

Thank for taking the time to review the draft.  Responses inline.

spt

Andrew Sciberras (GMAIL) wrote:
> Hello
> 
> I have a few minor comments:
> 
> 1.
> The definition of the deviceOwner attribute in section 2 indicates:
>   "IDENTIFIED BY   id-deviceOwner"
> 
> This should be updated to reflect the text in Appendix A:
>   "IDENTIFIED BYid-aa-KP-deviceOwner"

I'll update the oid name.

> 2. 
> The ASN.1 definitions (section 2 and appendix a) of DeviceOwner contain
the
> following:
>   "numericCountry INTEGER ( SIZE (0...999),"
> 
> The ASN.1 (X.680) notation for a range separator is ".." rather than an
> ellipsis. The syntax of the numericCountry choice should be changed to
this:
>   "numericCountry INTEGER ( SIZE (0..999),"

As somebody else pointed out SIZE constraints can't be applied to
INTEGER.  It needs to be "numericCountry INTEGER (0..999)".

> 3.
> The matching rule is defined to be:
>   "This rule returns a TRUE if and only if the DeviceOwner value exactly 
>matches the presented value. "
> 
> By "exactly" do you mean that case is sensitive for the Printable Strings?
> I.e. "AU" will not match "au"? 

Yes that's what it means.  But now that you ask I think something like
caseIgnoreMatch "The rule returns TRUE if the strings are the same
length and corresponding characters are identical except possibly with
regard to case" is probably more appropriate.

> 4.
> The ID indicates that no IANA considerations are required since the
> identifiers are already registered. 
> It would be preferable if the attribute type and matching rule definitions
> were registered with the IANA LDAP descriptors registry. 

After some discussions with Kurt Zeilenga, I think we're not going to
register the attributes.  I originally thought we could just say
something like the attribute could be used here, there, and everywhere
an attribute can be used.  I was unaware of the hoops to jump through to
claim that it could be used in LDAP.  I think it could be used in an
LDAP directory but we're going to target these attributes for public key
and attribute certificates.  If we end up needing to include these in a
directory, then we'll update this spec to add the required text to put
them in a directory (schema, transfer syntax, etc.).  I'll modify the
intro to say this:

This document specifies the Device Owner attribute.  This attribute may
be included in locations or protocols that support ASN.1 attribute
definitions to indicate the country or group that owns the device.

NOTE: This document does not provide LDAP equivalent schema
specification as this attribute is targeted at public key certificates
[RFC5280] and attribute certificates [RFC3281bis].  This is left to a
future specification.


> Regards,
> Andrew Sciberras
> 
> 
> 
>> -Original Message-
>> From: ietf-announce-boun...@ietf.org
> [mailto:ietf-announce-boun...@ietf.org] On
>> Behalf Of The IESG
>> Sent: Friday, 31 July 2009 9:52 PM
>> To: IETF-Announce
>> Subject: Last Call: draft-turner-deviceowner-attribute (Device
> OwnerAttribute) to
>> Informational RFC
>>
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>>
>> - 'Device Owner Attribute '
>>as an Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2009-08-28. Exceptionally,
>> comments may be sent to i...@ietf.org instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> The file can be obtained via
>>
http://www.ietf.org/internet-drafts/draft-turner-deviceowner-attribute-01.t
> xt
>>
>> IESG discussion can be tracked via
>>
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=177
> 56&rfc
>> _flag=0
>>
>> ___
>> IETF-Announce mailing list
>> ietf-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 





___
Ietf mailing lis

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Polk, William T.]

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 relationship of the document to the IETF
>standards process might be unclear, the IESG may request that the RFC
>Editor include an IESG note to clarify the relationship of the
>document to the IETF standards process, such a note is likely to
>include pointers to related IETF RFCs.

Personally, I think that the relationship is unclear in many cases, but it
is all a question of degree.  I interpret this text as directing the IESG to
reserve such notes for cases where serious conflicts exist and it is
particularly important to clarify the relationship and identify the
documents that represent community consensus.  In such a case, I would not
want to see the RFC Editor ignore the request or modify the note without
IESG agreement.  The current text of 3932bis seems to permit either.

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 accurately clarifies the
relationship.

Tim Polk

On 9/2/09 12:38 PM, "Sam Hartman"  wrote:
> 
> I'd also be happy with a
> mechanism where the IESG could propose a note, and the RFC editor had
> the option of accepting the note or asking the IESG to last-call its
> note within the IETF community.
> 
> I would not consider it acceptable if the note were purely advisory.
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Polk, William T.]

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 9/8/09 10:36 AM, "Olaf Kolkman"  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
>> IESG Note and let the community determine whether (1) this is an
>> exceptional
>> case meriting a note and (2) if the text accurately clarifies the
>> relationship.
> 
> 
> Which community, The IETF community or the wider RFC community? And
> who calls the consensus?
> 
> 
> 
> --Olaf
> 
> 
> 
> 
> Olaf M. KolkmanNLnet Labs
> Science Park 140,
> http://www.nlnetlabs.nl/   1098 XG Amsterdam
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Trust response to the appeal by John C Klensin (July 18, 2009

[Margaret Wasserman]

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 moved to the tlp-interest list.  I'm not on the tlp-interest  
list, because I don't have the time or interest to follow a discussion  
of the legal details of our licensing policy. I don't believe that I  
should have to read that list to know how the Trust plans to respond  
to the issues than John raised.


Margaret

On Sep 4, 2009, at 8:28 AM, Thomas Narten wrote:


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 the specific issues raised in the appeal to be
responded to in a direct manner, with a clear response as to whether
the point is agreed to (or not) and what (if any) remedy is
forthcoming.

Instead, the response smacks of trying not to respond directly to the
appeal, but say "here is what we have been doing, let's please just
move on". IMO, that just doesn't cut it.

IMO, an appeal needs to be responded to with directness and with
clarity.

Thomas





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Sam Hartman]

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 interacts with the IETF appeals process.  I'm not
thrilled with the appeals process starting with the IAB and only going
to the ISOC BOT in case there is no adequate process (6.5.3 in RFC
2026).  However I could live with that.  I suspect this may be one of
those cases where we know we've gotten a good compromise because no
one is happy with it.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10

[Ahmad Muhanna]

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 (Security Considerations) to address Ben comments. In addition, we
eliminated the Security Model section based on Ralph's comment.

2. Enhanced the text for MAG authorization and defined a default
mechanism as specified under section 13, Security Considerations.

3. Addressed Pasi's comments by adding text to clearly specify that the
current specification uses mobile node identifier option, MN-ID, with
subtype 1, as stated mainly under section 5.1. In addition, we defined
the format of "wild card" NAI as per the use of this specification, text
under section 8.1.1.

4. Addressed all the remaining of Ralph's detailed comments in several
places of the document.

5. Clarified that the responder sends BRA only if the Acknowledge (A)
bit is set. Text was tweaked in several places.

6. all nits and editorial comments

Please let me know if you still have any issue.

Thanks for all of your comments and help!

Regards,
Ahmad
 

> -Original Message-
> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Thursday, August 27, 2009 1:33 PM
> To: 'Ben Campbell'
> Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; 
> kchowdh...@starentnetworks.com; pyeg...@juniper.net; General 
> Area Review Team; ietf@ietf.org; Jari Arkko; 
> marc...@it.uc3m.es; Laganier, Julien
> Subject: RE: [PART-I] Gen-ART LC and Telechat Review of 
> draft-ietf-mext-binding-revocation-10
> 
> Hi, Ben,
> 
> > >
> > >> -Original Message-
> > >>
> > >> Summary: This draft is on the right track, but there are
> > open issues.
> > >> Additionally, I have a number of editorial comments.
> > >>
> > >> Major issues:
> > >>
> > >> -- I think the security considerations need quite a bit of
> > work. In
> > >> particular, there is very little guidance on authorization for 
> > >> sending BRI messages. This seem to me have utility for DoS
> > attacks,
> > >> particularly with the G bit set.
> > >> There is mention of reusing existing security associations
> > if IPSec
> > >> is used--but no mention of what to do if IPSec is not used.
> > > [Ahmad]
> > > Binding Revocation is used between two peers to 
> revoke/terminate a 
> > > mobility session(s) that have been created using an IPv6 mobility 
> > > protocol signaling (Client Mobile IPv6 or Proxy MIP6). 
> RFC3775 and 
> > > RFC5213, which are the main protocols targeted by this
> > specification,
> > > specify that "IPsec SHOULD" be used. On the other hand, 
> there is NO 
> > > other standard track specification which specify other security 
> > > mechanisms to secure the IPv6 mobility signaling.
> > Therefore, Binding
> > > Revocation specification assumes the use of whatever security 
> > > mechanism that currently available to secure the IPv6 mobility 
> > > signaling.
> > 
> > I think there are still a couple of issues here. First, Since the 
> > underlying RFCs only specify IPSec at SHOULD strength, this draft 
> > needs to discuss the consequences of not using it for BRI. 
> Depending 
> > on those consequences, it might be enough to just warn implementors 
> > that, if you don't use IPSec, certain bad things can happen.
> [Ahmad]
> It is NOT expected that BRI/BRA will use a different security 
> mechanism than what is being used for securing IPv6 mobility 
> signaling. Therefore, in order to alert implementors of the 
> danger if IPsec is NOT used, IMO, that needs to be discussed 
> in related IPv6 mobility specifications, e.g., RFC3775 and 
> RFC5213, which is already there. On the other hand, it is 
> very difficult to anticipate the criteria of other security 
> mechanisms that would possibly be used in the future to 
> secure IPv6 mobility signaling and consequently BRI/BRA. 
> 
> 
> > OTOH, it might be that BRI has
> > greater security risks than for 3775/5213, and you might (for
> > example) need to strengthen the IPSec requirement for BRI.
> > 
> > I admit to not being an expert on 3375/5213, so it may be true that 
> > BRI is no riskier than the underlying technology--but even 
> if that is 
> > true I'd like to see some discussion to support it.
> [Ahmad]
> Both IPv6 mobility signaling and BRI/BRA use the same IPv6 
> layer signaling. I am not sure what impact the underlying 
> technology has on BRI./BRA that does not have on BU/BA.
> 
> > 
> > Second, I think that there is probably more guidance needed on 
> > authorization decisions even if you do use IPSec. For 
> example, do you 
> > assume that any trusted peer can remove any binding?
> [Ahmad]
> No. The revoking mobility entity revokes only those mobility 
> session(s) which are registered with it. No mobility node can 
> revoke a mobility session that is registered with a different 
> trusted mobility node.
> 
> 
> > Is a truste

RE: Last Call: draft-ietf-krb-wg-cross-problem-statement (Problem statement on the cross-realm operation of Kerberos) to Informational RFC

[Thomas Hardjono]

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

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 accurately clarifies the
relationship.



On its face, this is certainly a reasonable path to follow.  However it has 
three practical problems.


One is effort and delay.  Adding more layers of decision-making and negotiation 
imposes non-trivial cost. The more barriers we place in the way of independent 
submission, the less it will get used. Worse, that's a stated goal for some folk.


The second is that it has become nearly impossible to find anything that looks 
like classic "rough consensus" on the IETF list.  The diversity of 
understanding, commitment and goals of participants on the IETF list has become 
far too diverse.  So as a mechanism for discerning how to resolve an impasse, it 
isn't likely to be very helpful.


The third is that it creates a negative incentive for the RFC Editor to act as 
an independent agency.  When it presses a point and finds a wall of hassle to 
deal with, this has a chilling effect on its likelihood of pressing.  They come 
to see such matters of principle as not worth the effort.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-turner-deviceowner-attribute (Device OwnerAttribute) to Informational RFC

[Sean Turner]

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 insensitive manner for these country
codes - i.e. 'AU' will match 'au'. 
Not that it matters at all - but if you're thinking of altering the behavior

to be case insensitive, then this will align it with the way that country
codes are used in LDAP and X.500.  

Andrew. 


-Original Message-
From: Sean Turner [mailto:turn...@ieca.com] 
Sent: Thursday, 3 September 2009 3:41 AM

To: Andrew Sciberras (GMAIL)
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-turner-deviceowner-attribute (Device
OwnerAttribute) to Informational RFC

Andrew,

Thank for taking the time to review the draft.  Responses inline.

spt

Andrew Sciberras (GMAIL) wrote:

Hello

I have a few minor comments:

1.
The definition of the deviceOwner attribute in section 2 indicates:
"IDENTIFIED BY   id-deviceOwner"

This should be updated to reflect the text in Appendix A:
"IDENTIFIED BYid-aa-KP-deviceOwner"


I'll update the oid name.

2. 
The ASN.1 definitions (section 2 and appendix a) of DeviceOwner contain

the

following:
"numericCountry INTEGER ( SIZE (0...999),"

The ASN.1 (X.680) notation for a range separator is ".." rather than an
ellipsis. The syntax of the numericCountry choice should be changed to

this:

"numericCountry INTEGER ( SIZE (0..999),"


As somebody else pointed out SIZE constraints can't be applied to
INTEGER.  It needs to be "numericCountry INTEGER (0..999)".


3.
The matching rule is defined to be:
  "This rule returns a TRUE if and only if the DeviceOwner value exactly 
   matches the presented value. "


By "exactly" do you mean that case is sensitive for the Printable Strings?
I.e. "AU" will not match "au"? 


Yes that's what it means.  But now that you ask I think something like
caseIgnoreMatch "The rule returns TRUE if the strings are the same
length and corresponding characters are identical except possibly with
regard to case" is probably more appropriate.


4.
The ID indicates that no IANA considerations are required since the
identifiers are already registered. 
It would be preferable if the attribute type and matching rule definitions
were registered with the IANA LDAP descriptors registry. 


After some discussions with Kurt Zeilenga, I think we're not going to
register the attributes.  I originally thought we could just say
something like the attribute could be used here, there, and everywhere
an attribute can be used.  I was unaware of the hoops to jump through to
claim that it could be used in LDAP.  I think it could be used in an
LDAP directory but we're going to target these attributes for public key
and attribute certificates.  If we end up needing to include these in a
directory, then we'll update this spec to add the required text to put
them in a directory (schema, transfer syntax, etc.).  I'll modify the
intro to say this:

This document specifies the Device Owner attribute.  This attribute may
be included in locations or protocols that support ASN.1 attribute
definitions to indicate the country or group that owns the device.

NOTE: This document does not provide LDAP equivalent schema
specification as this attribute is targeted at public key certificates
[RFC5280] and attribute certificates [RFC3281bis].  This is left to a
future specification.



Regards,
Andrew Sciberras




-Original Message-
From: ietf-announce-boun...@ietf.org

[mailto:ietf-announce-boun...@ietf.org] On

Behalf Of The IESG
Sent: Friday, 31 July 2009 9:52 PM
To: IETF-Announce
Subject: Last Call: draft-turner-deviceowner-attribute (Device

OwnerAttribute) to

Informational RFC

The IESG has received a request from an individual submitter to consider
the following document:

- 'Device Owner Attribute '
   as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2009-08-28. Exceptionally,
comments may be sent to i...@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via


http://www.ietf.org/internet-drafts/draft-turner-deviceowner-attribute-01.t

xt

IESG discussion can be tracked via


https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=177

56&rfc

_flag=0

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf









___
Ietf mailing list
Ietf@ietf.org
htt

New validation of RFC 2543

[Richard Shockey]

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

skype/AIM: rshockey101 
LinkedIn : http://www.linkedin.com/in/rshockey101






___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Important Information about IETF 76 Meeting Registration

[Alissa Cooper]

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 still be preferable for that policy to be published than  
to not be published. One of the core, widely accepted tenets of  
individual privacy is transparency. I personally doubt that the IETF's  
practices with respect to the data that it collects will be  
objectionable to many people, but I think those practices should be  
known so that the community can judge for itself. I think the  
practices should be documented -- whether they need to be changed or  
not is something to discuss once they've been documented.


It is unclear to me whether the data retention policy applies to the  
RFID data. Perhaps it counts as "Blue Sheets," in which case the data  
is retained permanently, but that is not immediately obvious from  
reading the policy. The note on the supplemental RFID page makes it  
sound as though the RFID data might not ultimately be stored  
electronically, but it's not totally clear.


Alissa

On Sep 2, 2009, at 4:02 AM, SM wrote:


Hi Alissa,
At 08:04 01-09-2009, Alissa Cooper wrote:

This entire thread is perfectly illustrative of why the IETF needs a
privacy policy. Without one, it is entirely unclear how the data
collected about IETF participants is used, disclosed and protected,
whether that data is part of an experiment or not. While the
supplemental information about the RFID tagging experiment (http://www.ietf.org/meeting/76/ebluesheet.html 
 ) is helpful, it is not complete (for example, how long the RFID-  
captured data is stored in electronic form is not disclosed), and

nothing equivalent exists (to my knowledge) for other kinds of data
about IETF participants, like registration data.


From the above webpage:

- The data will be printed and archived along with the paper blue  
sheets


- The data will NOT be distributed to anyone other than the IAOC, IAD,
  the Secretariat and  the host team that is organizing and supporting
  this experiment

- The data will be available for use if subpoenaed

It summarizes the use of the data after the meeting.  There is  
already a retention policy document and it may contain the answer to  
your question.


I don't have any concerns about this experiment.


In our protocol development work, many of us try very hard to design
privacy and security features in from the outset, whether we're
designing a highly experimental prototype or a core protocol. The  
same

should be true for the design of data collection mechanisms and
practices associated with IETF meetings.


You asked a similar question about a privacy policy a few weeks  
ago.  As we talking about IETF meetings, the question can be viewed  
from a different angle.  One of the goals of the Internet Standards  
Process is openness and fairness.  Participation in the IETF is  
open, i.e. anyone can join in.  We can already find out who are the  
"contributors" in a Working Group as there are open discussions on  
the relevant mailing list and there is a publicly accessible archive  
of the discussions.  The Working Group sessions (at a meeting) are  
not that different.


Everything a person says in a Working Group session is not private.   
For the process to be transparent, the list of individuals that are  
there also should not be considered as private.  In practice, the  
IETF offers you a some leeway.  Nobody will coerce you to sign the  
attendance list.  If you are going to the mic, you do have to  
identify yourself.  If you have any other concerns, please read the  
messages posted by Doug Ewell and Tony Hain on this thread on how to  
restrict what information is collected about you.


A list of session attendees is useful for:

(a) capacity planning (size of the meeting room to accommodate the  
number of participants)


(b) catering

(c) session scheduling

(d) cross-area participation

The Area Directors and Working Group Chairs might have a rough idea  
about item (d).  The IETF can gain a better view of (d) if the  
information is collected in electronic form.


I'll comment on Steve Crocker's questions:

(i) Do we need access controls on the information?

If the electronic process mimics existing practices, it is easier to  
publish the information.  That is already done for the meeting  
attendees list.  Note that this model may not be appropriate for  
other organizations.


(ii) Do we need an ability to edit information that's been collected  
if it's inaccurate?


The meeting registration form has a field for the "Name to appear on  
badge".  That can be used throughout the meeting.  The Working Group  
attendance collected during the session can be verified by the  
participants in the room.  Set up a procedure where they can contact  
the IETF Secretariat to correct a

Re: Important Information about IETF 76 Meeting Registration

[Alissa Cooper]

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 experiment, and adjust the policy accordingly. But it  
should no doubt be fluid.


This is not rocket science -- it's the process that many other  
organizations and companies use to address privacy. They develop a  
policy that covers existing practices, and when a new practice comes  
along, they analyze the impact of the new practice and whether the  
policy needs to change, and then they change the policy if necessary.  
This process might or might not result in constraining what happens to  
collected data, but the value is derived from having done the  
analysis, whether or not that analysis affects the ultimate outcome.


Alissa

On Sep 2, 2009, at 6:10 PM, Marshall Eubanks wrote:



On Sep 1, 2009, at 11:04 AM, Alissa Cooper wrote:

This entire thread is perfectly illustrative of why the IETF needs  
a privacy policy. Without one, it is entirely unclear how the data  
collected about IETF participants is used, disclosed and protected,  
whether that data is part of an experiment or not. While the  
supplemental information about the RFID tagging experiment (http://www.ietf.org/meeting/76/ebluesheet.html 
) is helpful, it is not complete (for example, how long the RFID- 
captured data is stored in electronic form is not disclosed), and  
nothing equivalent exists (to my knowledge) for other kinds of data  
about IETF participants, like registration data.


In our protocol development work, many of us try very hard to  
design privacy and security features in from the outset, whether  
we're designing a highly experimental prototype or a core protocol.  
The same should be true for the design of data collection  
mechanisms and practices associated with IETF meetings.




I fully agree with you about the need for a privacy policy. However,  
if we had one right now, it would likely not fully capture the full  
possibilities and potential dangers of an experiment like this.


In my opinion, these experiments are as much or more organizational  
as they are technological. In fact, I would assume that the  
technology is likely to work. The real questions concern the  
organization, have to be brought to the surface, weighed and  
discussed by the community, and the answers improved based on  
experience. Or, to put it another way, I expect that the privacy  
policy (and maybe the document retention policy) will be informed  
and hopefully improved by the results of this experiment.


Regards
Marshall


Alissa







___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf














___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Important Information about IETF 76 Meeting Registration

[Ole Jacobsen]

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 requirement that we retain the data from the experiment as
a substitute for bluesheets since we are not replacing the bluesheets
by RFID technology --- even if we are experimenting with how that
would work. (Obviously, the secretariat will need to securely retain
or destroy the data once the experiment is over, I don't see that as
being any different from all the other information which is collected
as a result of running an IETF meeting).

I agree that more details about the experiment need to be provided,
and they will be, it is still being worked out. And, you can opt out.

In the meantime, please see:

http://www.inet.info.hiroshima-cu.ac.jp/ietf76-exp/index.html#bluesheet


On Tue, 8 Sep 2009, Alissa Cooper wrote:

> It is unclear to me whether the data retention policy applies to the RFID
> data. Perhaps it counts as "Blue Sheets," in which case the data is retained
> permanently, but that is not immediately obvious from reading the policy. The
> note on the supplemental RFID page makes it sound as though the RFID data
> might not ultimately be stored electronically, but it's not totally clear.
> 
> Alissa
> 

Ole


Ole J. Jacobsen 
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Important Information about IETF 76 Meeting Registration

[Ted Hardie]

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

Hi Ole,

I think you are still missing Alissa's point.  She's asking for a privacy
policy to be in place that describes how the IETF uses the data it collects.
*How* it collects the data is secondary to that statement.  The experiment
seems to me to be about a how, not about a "what it does". 

She's also been pretty clear that it could say something like "the IETF
collects data for  experimental understanding of folks' willingness to
wave badges at boxes" and satisfy her. Less flippantly, she's saying that
getting a stated policy is job one.  What is says and how it is updated are,
to some degree secondary (because having a stated policy allows folks
to judge whether or not to share the data by, for example, participating
in the experiment).
regards,
Ted




>There is clearly, today,
>no legal requirement that we retain the data from the experiment as
>a substitute for bluesheets since we are not replacing the bluesheets
>by RFID technology --- even if we are experimenting with how that
>would work. (Obviously, the secretariat will need to securely retain
>or destroy the data once the experiment is over, I don't see that as
>being any different from all the other information which is collected
>as a result of running an IETF meeting).
>
>I agree that more details about the experiment need to be provided,
>and they will be, it is still being worked out. And, you can opt out.
>
>In the meantime, please see:
>
>http://www.inet.info.hiroshima-cu.ac.jp/ietf76-exp/index.html#bluesheet
>
>
>On Tue, 8 Sep 2009, Alissa Cooper wrote:
>
>> It is unclear to me whether the data retention policy applies to the RFID
>> data. Perhaps it counts as "Blue Sheets," in which case the data is retained
>> permanently, but that is not immediately obvious from reading the policy. The
>> note on the supplemental RFID page makes it sound as though the RFID data
>> might not ultimately be stored electronically, but it's not totally clear.
>>
>> Alissa
>>
>
>Ole
>
>
>Ole J. Jacobsen
>Editor and Publisher,  The Internet Protocol Journal
>Cisco Systems
>Tel: +1 408-527-8972   Mobile: +1 415-370-4628
>E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
>
>
>___
>Ietf mailing list
>Ietf@ietf.org
>https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf