Subject: Re: Ietf Digest, Vol 21, Issue 74

From: Neil Harwani <[email-masked]>
Date: Fri, 20 Jan 2006 17:43:22 +0530

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, [email-masked] <[email-masked]> wrote:
>
> Send Ietf mailing list submissions to
>         [email-masked]
>
> 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
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> 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 <[email-masked]>
> Subject: Re: I-D
>         ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> To: [email-masked]
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> 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 <[email-masked]>
> Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey)
>         Morfin
> To: Scott Hollenbeck <[email-masked]>
> Cc: [email-masked], [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> --On Thursday, 19 January, 2006 20:03 -0500 Sam Hartman
> <[email-masked]> 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 <[email-masked]>
> Subject: Re: I-D
>         ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> To: "[email-masked]" <[email-masked]>
> Message-ID: <[email-masked]>
> 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 <[email-masked]>
> > Responder a: <[email-masked]>
> > Fecha: Thu, 19 Jan 2006 22:00:10 -0500
> > Para: <[email-masked]>
> > CC: "[email-masked]" <[email-masked]>
> > 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
> > [email-masked]
> > 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 <[email-masked]>
> Subject: Re: I-D
>         ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> To: [email-masked]
> Cc: "[email-masked]" <[email-masked]>
> Message-ID: <[email-masked]>
> 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 <[email-masked]>
> Subject: Re: I-D
>         ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> To: "[email-masked]" <[email-masked]>
> Message-ID: <[email-masked]>
> 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 <[email-masked]>
> > Responder a: <[email-masked]>
> > Fecha: Thu, 19 Jan 2006 22:36:21 -0500
> > Para: <[email-masked]>
> > CC: "[email-masked]" <[email-masked]>
> > 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
> > [email-masked]
> > 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
> [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf