ietf
[Top] [All Lists]

Re: Ietf Digest, Vol 21, Issue 74

2006-01-20 10:17:00
Guyz I am very happy and privileged to be among you all. I don't read all
messages but try to catch up when free.

Thanks,
Neil Harwani.

On 1/20/06, ietf-request(_at_)ietf(_dot_)org <ietf-request(_at_)ietf(_dot_)org> 
wrote:

Send Ietf mailing list submissions to
        ietf(_at_)ietf(_dot_)org

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(_at_)ietf(_dot_)org

You can reach the person managing the list at
        ietf-owner(_at_)ietf(_dot_)org

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(_at_)jck(_dot_)com>
Subject: Re: I-D
        ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
To: jordi(_dot_)palet(_at_)consulintel(_dot_)es
Cc: ietf(_at_)ietf(_dot_)org
Message-ID: <D381E2722F41534A94B8294F(_at_)p3(_dot_)JCK(_dot_)COM>
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(_at_)jck(_dot_)com>
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey)
        Morfin
To: Scott Hollenbeck <sah(_at_)428cobrajet(_dot_)net>
Cc: ietf(_at_)ietf(_dot_)org, iesg(_at_)ietf(_dot_)org
Message-ID: <6B00F5E2964A4A00C0C1323C(_at_)p3(_dot_)JCK(_dot_)COM>
Content-Type: text/plain; charset=us-ascii

--On Thursday, 19 January, 2006 20:03 -0500 Sam Hartman
<hartmans-ietf(_at_)mit(_dot_)edu> 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(_dot_)palet(_at_)consulintel(_dot_)es>
Subject: Re: I-D
        ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
To: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>
Message-ID: 
<BFF617FF(_dot_)152738%jordi(_dot_)palet(_at_)consulintel(_dot_)es>
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(_at_)jck(_dot_)com>
Responder a: <ietf-bounces(_at_)ietf(_dot_)org>
Fecha: Thu, 19 Jan 2006 22:00:10 -0500
Para: <jordi(_dot_)palet(_at_)consulintel(_dot_)es>
CC: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>
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(_at_)ietf(_dot_)org
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(_at_)shockey(_dot_)us>
Subject: Re: I-D
        ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
To: jordi(_dot_)palet(_at_)consulintel(_dot_)es
Cc: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>
Message-ID: <43D05AB5(_dot_)4090009(_at_)shockey(_dot_)us>
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(_dot_)palet(_at_)consulintel(_dot_)es>
Subject: Re: I-D
        ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
To: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>
Message-ID: 
<BFF61DA3(_dot_)15275E%jordi(_dot_)palet(_at_)consulintel(_dot_)es>
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(_at_)shockey(_dot_)us>
Responder a: <ietf-bounces(_at_)ietf(_dot_)org>
Fecha: Thu, 19 Jan 2006 22:36:21 -0500
Para: <jordi(_dot_)palet(_at_)consulintel(_dot_)es>
CC: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>
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(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>
  • Re: Ietf Digest, Vol 21, Issue 74, Neil Harwani <=