Thanks,
Neil Harwani.
On 1/20/06, ietf-request@xxxxxxxx <ietf-request@xxxxxxxx
> wrote:
Send Ietf mailing list submissions to
ietf@xxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://www1.ietf.org/mailman/listinfo/ietf
or, via email, send a message with subject or body 'help' to
ietf-request@xxxxxxxx
You can reach the person managing the list at
ietf-owner@xxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ietf digest..."
Today's Topics:
1. Re: I-D
ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
(John C Klensin)
2. Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey)
Morfin (John C Klensin)
3. Re: I-D
ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
(JORDI PALET MARTINEZ)
4. Re: I-D
ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
(Richard Shockey)
5. Re: I-D
ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
(JORDI PALET MARTINEZ)
----------------------------------------------------------------------
Message: 1
Date: Thu, 19 Jan 2006 22:00:10 -0500
From: John C Klensin <john-ietf@xxxxxxx>
Subject: Re: I-D
ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
To: jordi.palet@xxxxxxxxxxxxxx
Cc: ietf@xxxxxxxx
Message-ID: <D381E2722F41534A94B8294F@xxxxxxxxxx >
Content-Type: text/plain; charset=us-ascii
Jordi,
Unlike several others and their comments, there are significant
parts of this I find useful, at least in terms of identifying
issues that should be examined. There are several other parts
of it with which I disagree. And, ultimately, the presentation
of a list of suggestions without prioritization lowers its
utility considerably. On the other hand, I doubt that consensus
even on the list of suggested principles is possible. Consensus
about how they should be prioritized would be more difficult
yet, and consensus among those with significant experience
planning and running IETF meetings would certainly be no less
difficult.
The difficulty, it seems to me, is the combination between that
problem with claiming consensus and what can and should be done
with the document operationally. It is just my opinion, but I
consider anything whose purpose is to tell the IAD, IAOC, or
IESG (or the IETF or IASA more generally) how to behave
procedurally or decide on things to be completely inappropriate
for publication as an independent submission RFC. If others
agree, then the only way to get this published as an RFC is via
the IESG and some IETF consensus process.
One possibility is to just leave it as an I-D, updating it
periodically as needed, but keeping it out there as a
perspective that the IAD might consider. That has certainly
been done with some IETF and meeting operational documents in
the past. Another would be to pass it to the IAOC (see note
below) along with a suggestion that they establish a set of
periodically-updated IETF operating procedure notes and put this
(or a modified version of it) into that series. Otherwise...
well, I just don't know, even independent of the aspects of it
with which I disagree.
I will try to find time to send you a list of particular topic
areas about which we appear to disagree, but I don't consider a
discussion of those specific topics to be appropriate or useful
on the IETF list unless the IESG decides that this document
should be an IETF topic (e.g., via a Last Call for BCP).
john
(note: in both the document and some of your comments in the
last 24 hours, I think you've gotten the IAOC (the oversight
committee/ IASA decision body) and IASA (the whole
administrative operation in principle, but, in practice, just
the conceptual realization of the IAOC, the IAD (whom they
supervise), and the set of tasks and those who carry them out
that are supervised by the IAD and/or IAOC directly).)
------------------------------
Message: 2
Date: Thu, 19 Jan 2006 22:25:43 -0500
From: John C Klensin <john-ietf@xxxxxxx>
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey)
Morfin
To: Scott Hollenbeck < sah@xxxxxxxxxxxxxxx>
Cc: ietf@xxxxxxxx, iesg@xxxxxxxx
Message-ID: <6B00F5E2964A4A00C0C1323C@xxxxxxxxxx >
Content-Type: text/plain; charset=us-ascii
--On Thursday, 19 January, 2006 20:03 -0500 Sam Hartman
<hartmans-ietf@xxxxxxx> wrote:
>...
> Even by his own admission Jefsey has been engaging in
> filibustering--a practice that I think we would agree is
> disruptive. Take a look at his most recent appeal to the IESG
> (http://www.ietf.org/IESG/APPEALS/jefsey-morfin-appeal.txt );
> quoting from that appeal:
>...
> As such, I agree that we need to adopt a strategy that
> prevents Jefsey from disrupting our processes excessively.
>
> However a PR action is an incredibly huge hammer. If passed,
> it removes any process barrier to shutting Jefsey out of any
> IETF process. While this PR action is specifically targeted
> at the ietf-languages list it would give the person running
> any IETF list the ability to unilaterally remove Jefsey from
> that list.
>
> Perhaps this is an appropriate measure to take when all of a
> person's participation are destructive and they have nothing
> to offer.
>
> That's not true for Jefsey. Jefsy has made significant
> positive contributions to the IETF list. He has worked to
> describe the perceptions that the IETF, IANA, ICAN, and
> related entities are creating a US-centric Internet. He has
> described concerns of global users and how our protocols,
> including IDN, may not meet user requirements. These concerns
> are real and parts of them have been worked on by
> long-standing members of the community. Take a look at RFC
> 4185 for an example of a concern that Jefsey shares that
> members of this organization have spent time working on. I
> personally have found Jefsey's formulations of these concerns
> enlightening; I think he has significantly helped me
> understand how the IETF might be perceived and what some user
> concerns with our protocol might be.
>...
I have to reluctantly agree with Sam. I'm reluctant because
there are far too many days when I wish Jefsey would just
quietly go away Of course, he is not the only person I'd put on
that list, and I imagine I'm on some similar lists kept by
others, but that is exactly the point and the problem.
I have many wishes about Jefsey and his behavior. I often wish
he would change his tone. I wish he would spend a little more
time trying to understand some of the protocols and operational
and procedural realities (such as the present decision-making
role of the IAB relative to IETF activities, the procedural
relationship of the DNS to other directory services, and so on)
before making loud and repeated assertions about them. And,
when he is told to take particular topics elsewhere, I wish he
would heed that advice.
That said, when he appears to be deliberately filibustering, or
otherwise repeating the same comments over and over again, I see
that as more than adequate justification for enforced time-outs
from the relevant lists. But I'm not convinced that any of this
is evidence of the type of deliberately offensive or abusive
behavior, name-calling, or attempts to create disruption for its
own sake that, in my view, would justify a blanket 3683 action.
For whatever it is worth, I want to remind the IESG that, before
there was RFC 3683, there was a notion, not only of 30 day
suspensions, but of exponential (or other rapidly increasing
series) back-off. If someone is being severely disruptive on a
particular list, it would seem reasonable to me for the relevant
AD to authorize a 60 day suspension if a 30 day one is
ineffective, a 120 day suspension if that is ineffective, and so
on. The nature of that arithmetic is such that someone could,
with sufficient repeated disruptive behavior, find themselves
rather effectively banned for the effective duration of a WG.
If the IESG believes that a formal RFC3933 experiment is needed
to do that, then let's write down and run that experiment.
But, until we have tried the above --and any other plausible
actions we can think of-- let's save the 3683 actions for those
whose behavior is more clearly inappropriate and
non-constructive than Jefsey's.
john
------------------------------
Message: 3
Date: Fri, 20 Jan 2006 04:30:55 +0100
From: JORDI PALET MARTINEZ < jordi.palet@xxxxxxxxxxxxxx>
Subject: Re: I-D
ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
To: "ietf@xxxxxxxx " <ietf@xxxxxxxx>
Message-ID: <BFF617FF.152738%jordi.palet@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"
Hi John,
I understand your points and somehow agree on some of them.
I can try to establish a prioritization if that can help, and certainly I
will be happy to keep updating the document if at the end the decision is to
keep it in a web page, or just as a live I-D, or whatever else.
Regards,
Jordi
> De: John C Klensin <john-ietf@xxxxxxx>
> Responder a: < ietf-bounces@xxxxxxxx>
> Fecha: Thu, 19 Jan 2006 22:00:10 -0500
> Para: <jordi.palet@xxxxxxxxxxxxxx>
> CC: " ietf@xxxxxxxx" <ietf@xxxxxxxx>
> Asunto: Re: I-D
> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
>
> Jordi,
>
> Unlike several others and their comments, there are significant
> parts of this I find useful, at least in terms of identifying
> issues that should be examined. There are several other parts
> of it with which I disagree. And, ultimately, the presentation
> of a list of suggestions without prioritization lowers its
> utility considerably. On the other hand, I doubt that consensus
> even on the list of suggested principles is possible. Consensus
> about how they should be prioritized would be more difficult
> yet, and consensus among those with significant experience
> planning and running IETF meetings would certainly be no less
> difficult.
>
> The difficulty, it seems to me, is the combination between that
> problem with claiming consensus and what can and should be done
> with the document operationally. It is just my opinion, but I
> consider anything whose purpose is to tell the IAD, IAOC, or
> IESG (or the IETF or IASA more generally) how to behave
> procedurally or decide on things to be completely inappropriate
> for publication as an independent submission RFC. If others
> agree, then the only way to get this published as an RFC is via
> the IESG and some IETF consensus process.
>
> One possibility is to just leave it as an I-D, updating it
> periodically as needed, but keeping it out there as a
> perspective that the IAD might consider. That has certainly
> been done with some IETF and meeting operational documents in
> the past. Another would be to pass it to the IAOC (see note
> below) along with a suggestion that they establish a set of
> periodically-updated IETF operating procedure notes and put this
> (or a modified version of it) into that series. Otherwise...
> well, I just don't know, even independent of the aspects of it
> with which I disagree.
>
> I will try to find time to send you a list of particular topic
> areas about which we appear to disagree, but I don't consider a
> discussion of those specific topics to be appropriate or useful
> on the IETF list unless the IESG decides that this document
> should be an IETF topic (e.g., via a Last Call for BCP).
>
> john
>
> (note: in both the document and some of your comments in the
> last 24 hours, I think you've gotten the IAOC (the oversight
> committee/ IASA decision body) and IASA (the whole
> administrative operation in principle, but, in practice, just
> the conceptual realization of the IAOC, the IAD (whom they
> supervise), and the set of tasks and those who carry them out
> that are supervised by the IAD and/or IAOC directly).)
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
------------------------------
Message: 4
Date: Thu, 19 Jan 2006 22:36:21 -0500
From: Richard Shockey < richard@xxxxxxxxxx>
Subject: Re: I-D
ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
To: jordi.palet@xxxxxxxxxxxxxx
Cc: " ietf@xxxxxxxx" <ietf@xxxxxxxx>
Message-ID: <43D05AB5.4090009@xxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
J
>> I'm assuming this is going to be Informational only and as such not
>> formally binding on the IAOC on the Secretariat.
>
> My personal view is that this should be an Informational document, as a
> guideline of the selection criteria, as I already tried to describe in the
> document.
>
> There should be no difference between this and any other IETF document, in
> that sense.
But there are differences Informational is just that Informational and
as such not binding on the parties as would be the Charter of the IAB
IAOC, NOMCOM etc.
>
> My opinion is that the binding is not related to the document type, but to
> how we want to manage the meetings the next years.
>
>
> Clearly, the old document that we have in the IETF site is insufficient and
> the decision is so *subjective* (not accusing to anyone, just a fact), that
> the situation is not fair neither acceptable.
My position is this A. if it an'nt broke dont fix it and I do not see
what is currently broken. B is is irrelevant whether the selection is
subjective or not. All selections of this type are ultimately
subjective. This class of IETF policy is the IMHO business of those to
whom the NOMCOM has appointed to oversee such activity in this case the
IAOC.
If the IAOC wishes to develop a criterion for site selections and then
seek community support for such criterion then fine , that is the IETF
way as I have come to understand it.
We appoint leadership for a reason ..to lead and make decisions. I dont
like binding leadership with rules unless they serve a specific defined
purpose necessary to the critical functioning of the organization. This
is one of those decisions best left to those to whom we duly appoint to
make such decisions.
In shorter words I believe in the concept of Management. The business of
IETF Management is to Manage so we can get on with our business which is
Internet Standards.
>
> I've complained during years, and I guess that was the reason Brian
> Carpenter pointed to me suggesting that I should write the document (not
> stating that Madrid should be the right venue), and I decided to take the
> "risk".
Well Madrid indeed anywhere in Spain is the right venue for _anything_
:-) IMHO!!! I personally would not have any objection to having all
future IETF meetings in Spain. Well maybe alternate the fall meetings in
Portugal .. Oporto Lisbon come to mind. Now I can see some objections
to Ibiza. That might be a stretch...but at least once???
IMHO Brian Carpenter was seriously wrong in suggesting that an
individual member of the community attempt to create such a policy
document especially since we have just gone through a brutal process to
set up a brand new management oversight committee to ultimately preform
such functions, the IAOC.
Please dont get my wrong. You have obviously put much work into this and
we should all be grateful for such contributions to the community. I
just dont think it was necessary right now and even if there was a
general consensus that it was necessary this is the proper task of the
IAOC.
Brian should have known better.
>> In fact that should be made explicit that nothing in this document
>> should be considered formally binding on the IAOC or the Secretariat and
>> that it only represents "useful suggestions".
>
> I think that's precisely against the original target of the document. As
> said is only a guideline, but it must be followed in an objective way.
NO on that I do disagree. That is why if this document is to become a
RFC and I believe that it should not, it must be Informational.
>
> My understanding is that the IAOC is not engaged in the day-to-day work, and
> that's the reason to have the IASA, the secretariat and the IAD. But they
> need community driven guidelines to be able to follow as much as possible an
> objective criteria.
The current set up is very new. I think it is a very very bad idea to
impose policy criterion on these bodies until the dust settles. It has
been a long hard struggle to get where we are at right now. Again if the
IAOC wishes to consider such criterion then your draft is better edited
there then presented to the community.
> Now, all that said, I don't recall having heard comments from your side on
> the document during all the process in any of the previous versions. It will
> be very helpful that you provide them now, but please, try to be
> constructive by commenting what exactly you dislike and even propose
> specific text. I'm sure everyone will be happy to consider all the inputs.
>
>
I have commented on the document.
I dont think it should exist and certainly not as a BCP or Standards
Track RFC.
1. Venue Selection Criterion is best left to the IAOC to determine
policy. 2. Even if there was a need for community input the current IETF
administrative structure is very new and some what fragile and we should
not for the time being impose unwanted solutions on them they did not
solicit support for.
--
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
------------------------------
Message: 5
Date: Fri, 20 Jan 2006 04:54:59 +0100
From: JORDI PALET MARTINEZ <jordi.palet@xxxxxxxxxxxxxx>
Subject: Re: I-D
ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
To: "ietf@xxxxxxxx" <ietf@xxxxxxxx>
Message-ID: < BFF61DA3.15275E%jordi.palet@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"
Hi Richard,
Just a short answer to avoid a long discussion on each of your replies ...
It is broken, anyone that has proposed to host an IETF meeting know it. What
you can read in the actual web page about hosting a meeting is not correct
in the reality, and can't be 100% subjective (yes there will be a decision
at the end, and that imply certain degree of subjectivity, but a criteria
helps to make it as much objective and fair as possible).
Remember my example, a real one: Venue A is proposed and is rejected because
reason "X". Some months later another venue "B" is hosting the IETF with
same problem "X" and even with a higher degree on the "X" problem compared
with venue "A". I don't thin you can still say isn't broken ! There are many
other examples and lot of people willing to host that has no starting point
to know if they can actually be a candidate venue or not.
Regards,
Jordi
> De: Richard Shockey < richard@xxxxxxxxxx>
> Responder a: <ietf-bounces@xxxxxxxx>
> Fecha: Thu, 19 Jan 2006 22:36:21 -0500
> Para: < jordi.palet@xxxxxxxxxxxxxx>
> CC: "ietf@xxxxxxxx" <ietf@xxxxxxxx>
> Asunto: Re: I-D
> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
>
> J
>>> I'm assuming this is going to be Informational only and as such not
>>> formally binding on the IAOC on the Secretariat.
>>
>> My personal view is that this should be an Informational document, as a
>> guideline of the selection criteria, as I already tried to describe in the
>> document.
>>
>> There should be no difference between this and any other IETF document, in
>> that sense.
>
> But there are differences Informational is just that Informational and
> as such not binding on the parties as would be the Charter of the IAB
> IAOC, NOMCOM etc.
>
>>
>> My opinion is that the binding is not related to the document type, but to
>> how we want to manage the meetings the next years.
>>
>>
>> Clearly, the old document that we have in the IETF site is insufficient and
>> the decision is so *subjective* (not accusing to anyone, just a fact), that
>> the situation is not fair neither acceptable.
>
>
> My position is this A. if it an'nt broke dont fix it and I do not see
> what is currently broken. B is is irrelevant whether the selection is
> subjective or not. All selections of this type are ultimately
> subjective. This class of IETF policy is the IMHO business of those to
> whom the NOMCOM has appointed to oversee such activity in this case the
> IAOC.
>
> If the IAOC wishes to develop a criterion for site selections and then
> seek community support for such criterion then fine , that is the IETF
> way as I have come to understand it.
>
> We appoint leadership for a reason ..to lead and make decisions. I dont
> like binding leadership with rules unless they serve a specific defined
> purpose necessary to the critical functioning of the organization. This
> is one of those decisions best left to those to whom we duly appoint to
> make such decisions.
>
> In shorter words I believe in the concept of Management. The business of
> IETF Management is to Manage so we can get on with our business which is
> Internet Standards.
>
>>
>> I've complained during years, and I guess that was the reason Brian
>> Carpenter pointed to me suggesting that I should write the document (not
>> stating that Madrid should be the right venue), and I decided to take the
>> "risk".
>
>
> Well Madrid indeed anywhere in Spain is the right venue for _anything_
> :-) IMHO!!! I personally would not have any objection to having all
> future IETF meetings in Spain. Well maybe alternate the fall meetings in
> Portugal .. Oporto Lisbon come to mind. Now I can see some objections
> to Ibiza. That might be a stretch...but at least once???
>
> IMHO Brian Carpenter was seriously wrong in suggesting that an
> individual member of the community attempt to create such a policy
> document especially since we have just gone through a brutal process to
> set up a brand new management oversight committee to ultimately preform
> such functions, the IAOC.
>
> Please dont get my wrong. You have obviously put much work into this and
> we should all be grateful for such contributions to the community. I
> just dont think it was necessary right now and even if there was a
> general consensus that it was necessary this is the proper task of the
> IAOC.
>
> Brian should have known better.
>
>
>>> In fact that should be made explicit that nothing in this document
>>> should be considered formally binding on the IAOC or the Secretariat and
>>> that it only represents "useful suggestions".
>>
>> I think that's precisely against the original target of the document. As
>> said is only a guideline, but it must be followed in an objective way.
>
> NO on that I do disagree. That is why if this document is to become a
> RFC and I believe that it should not, it must be Informational.
>
>
>>
>> My understanding is that the IAOC is not engaged in the day-to-day work, and
>> that's the reason to have the IASA, the secretariat and the IAD. But they
>> need community driven guidelines to be able to follow as much as possible an
>> objective criteria.
>
> The current set up is very new. I think it is a very very bad idea to
> impose policy criterion on these bodies until the dust settles. It has
> been a long hard struggle to get where we are at right now. Again if the
> IAOC wishes to consider such criterion then your draft is better edited
> there then presented to the community.
>
>
>> Now, all that said, I don't recall having heard comments from your side on
>> the document during all the process in any of the previous versions. It will
>> be very helpful that you provide them now, but please, try to be
>> constructive by commenting what exactly you dislike and even propose
>> specific text. I'm sure everyone will be happy to consider all the inputs.
>>
>>
>
> I have commented on the document.
>
> I dont think it should exist and certainly not as a BCP or Standards
> Track RFC.
>
> 1. Venue Selection Criterion is best left to the IAOC to determine
> policy. 2. Even if there was a need for community input the current IETF
> administrative structure is very new and some what fragile and we should
> not for the time being impose unwanted solutions on them they did not
> solicit support for.
>
> --
>
>
>>>>>>>>>>>>
> Richard Shockey, Director - Member of Technical Staff
> NeuStar Inc.
> 46000 Center Oak Plaza - Sterling, VA 20166
> sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com
> ENUM +87810-13313-31331
> PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
> Fax: +1 815.333.1237
> <mailto:richard(at)shockey.us> or
> <mailto:richard.shockey(at)neustar.biz>
> < http://www.neustar.biz> ; <http://www.enum.org>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
------------------------------
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
End of Ietf Digest, Vol 21, Issue 74
************************************
--
Thanking you,
Neil Harwani,
BE (Civil)
L D College of Engineering, Ahmedabad
MCA
ICFAI School of Information Technology,
Hyderabad
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf