Message-Id: <6.2.1.2.2.20050817123041.045a0320@mail.afrac.org>
Date: Wed, 17 Aug 2005 12:57:42 +0200
To: "Peter Constable" <petercon@microsoft.com>, <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: RE: [Ltru] Re: WGLC security considerations
In-Reply-To: <F8ACB1B494D9734783AAB114D0CE68FE06D2695D@RED-MSG-52.redmon
	d.corp.microsoft.com>
References: <F8ACB1B494D9734783AAB114D0CE68FE06D2695D@RED-MSG-52.redmond.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

At 01:22 17/08/2005, Peter Constable wrote:
>JFC appears to be using this thread as an excuse to open up various
>topics on which he has a personal ax to grind.

Dear Peter,
"x-" not "ax". I am afraid you confuse the origin and the result. The 
purpose of the Security Section is to detail the risk increases. You 
certainly are one of the originator of that risks. Your rationale is 
probably to consider that the return is worth them. And you should document 
why, in your own words. Hiding them, as you seem to want it, would only 
tend to prove that the return is for you and not for the user.

>I wish to dissociate my
>qualified support for his original issue regarding specific text in
>section 6 of the draft from his further input, which I find to be at
>best not particularly good arguments for change to that section and at
>worst wholly off topic.

As mentioned in my response, I consider that your text is a reasonable 
improvement over the current text. The problem in dissociating yourself now 
is that I will propose that text in appeal as an acceptable compromise.

>Also, given that the WG last call is closed, I have no interest in nor
>see any particular value in extending this thread. As mentioned earlier,
>I think certain improvements to section could be made but that they not
>essential and certainly not worth any further delay of this draft.

This is a real and constant misunderstanding of the IETF process. Work on 
Drafts are to be carried in WGs. Not during the IETF last call as suggested 
by some and implicitly considered by you.  The verdict will probably 
further DISCUSS and delays.

I do not object, since I think that this Draft is to be discussed within 
the WSIS Multilingualisation Fora. But please do not claim that I delayed 
the process. Had we have followed a common sense approach I proposed we 
would most probably have a acceptable to all (except to you may be?) RFC by 
now.

"Qui top embrasse mal etreint".
jfc




>Peter Constable
>
>
>
> > -----Original Message-----
> > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]
>On Behalf Of r&d
> > afrac
> > Sent: Tuesday, August 16, 2005 3:44 PM
> > To: ltru@ietf.org
> > Subject: Re: [Ltru] Re: WGLC security considerations
> >
> > On 21:11 16/08/2005, Frank Ellermann said:
> > >Jefsey Morfin wrote:
> > > > I think the following text would be more appropriate:
> > >[...]
> > >
> > >The shorter version addresses the main issue more precisely.
> > >
> > >Your longer proposal is too broad, it covers more than only
> > >language tags, it's applicable to most kinds of information
> > >exchange.
> > >
> > >Putting vague threats related to many kinds of communication
> > >- not only language tags - in the "security considerations"
> > >would be a bad idea.  We were supposed to identify _specific_
> > >risks. not _general_ issues.
> >
> > Dear Frank,
> > The specific risks due to the language tags are numerous. I will
>identify
> > three of them:
> >
> > - risk of confusion as they introduce non network related information
>where
> > network related information is needed. This risk is structural and may
> > substantially delay the architectural development of the Internet due
>to
> > its probable support by dominant actors. I doubt the authors will
>document
> > it. This is the main risk I fight in opposing their Draft.
> >
> > - individual risks on content (filtering, censoring, etc.) and on
>persons
> > (identification, privacy violation, etc.). This kind of risk is never
> > absolute: it lies in its increase. There is a difference between
>sending an
> > information on a post card and in a letter under envelope because
>opening
> > all the envelopes costs time and money. Language tags greatly
>simplifies
> > the intelligence gathering, filtering, spying, censoring ... and their
> > errors. Not considering language tags in OPES context for example is
>big
> > mistake. But the main issue is that the user cannot turn it down. (NB.
>This
> > risks could have been greatly reduced through flexible "x-tags" and
>"0-"
> > escape sequence. I have no doubt people will die and suffer because of
>the
> > ABNF. Standardisation is also a risky activity.)
> >
> > - global risks. Let say the "9am-5pm" orientation of the Draft is well
> > known and will be increasingly known. The irritation resulting from
>the
> > limitations to cultural lifes and innovation all over the world this
>draft
> > will lead to, and the probable impact on IANA and IETF image, may be a
> > direct or indirect triggering factor in many nasty events to come (I
>am
> > sure you do not need I dwell on that point). The chances of this risk
>have
> > decreased. The ABNF rigidity against our Open Source/Standard
>proposition,
> > the resulting delays in excluding us, the exposure of the commercial
> > interests involved will most probably now lead the WSIS Internet
>Governance
> > Forum to take over the issue.
> >
> > A related risk would be that all this would delay a serious Internet
> > Multilingual Framework. This is a matter on which we now actively
>work.
> > jfc
> >
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > Ltru@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru