Re: [idn] WG last call summary

[D. J. Bernstein]

Marc Blanchet writes:
> We will be sending the documents for IESG consideration for Proposed 
> Standard on March 11th 2002.

That's outrageous. IDNA has received strong written objections from at
least fifteen regular WG participants and _hundreds_ of other people.
IDNA will cause a tremendous amount of damage, including bounced email,
web link failures, widespread user confusion, and massive costs---much
higher than necessary---for software development and deployment.

You say that you are obliged to ignore all these objections because the
IDN WG has to _do something_. But the IETF procedures don't say ``It's
okay to make an incredibly destructive modification to the Internet
protocol suite if you have to _do something_.''

I hope that the IDN WG can settle on a safe course of action. However,
until that happens, we will have to stick to the status quo.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Re: [idn] WG last call summary

[Dave Crocker]

At 03:58 AM 3/11/2002 +, D. J. Bernstein wrote:
>That's outrageous.

Hyperbole and sweeping, undocumented assertions are outrageous.

Forwarding specifications that have been carefully responsive to the 
problem that the group was tasked with solving... now that is NOT 
outrageous.  It's what supposed to happen in the IETF and what has, in 
fact, been done in IDN.


>IDNA will cause a tremendous amount of damage,

Such false claims have been dealt with repeatedly.  Continuing to make a 
false claim does not make it true.


>You say that you are obliged to ignore all these objections because the
>IDN WG has to _do something_.

He did not say that.  Hence there is no need to respond to the derivative 
assertions from that falsehood.

d/

--
Dave Crocker  
Brandenburg InternetWorking  
tel +1.408.246.8253;  (new)fax +1.408.850.1850

Re: [idn] WG last call summary

[Soobok Lee]

- Original Message - 
From: "D. J. Bernstein" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, March 11, 2002 12:58 PM
Subject: Re: [idn] WG last call summary


> Marc Blanchet writes:
> > We will be sending the documents for IESG consideration for Proposed 
> > Standard on March 11th 2002.
> 
> That's outrageous. IDNA has received strong written objections from at
> least fifteen regular WG participants and _hundreds_ of other people.
> IDNA will cause a tremendous amount of damage, including bounced email,
> web link failures, widespread user confusion, and massive costs---much
> higher than necessary---for software development and deployment.
> 
> You say that you are obliged to ignore all these objections because the
> IDN WG has to _do something_. But the IETF procedures don't say ``It's
> okay to make an incredibly destructive modification to the Internet
> protocol suite if you have to _do something_.''

I agree with you.
I believe IESG+IAB wouldn't be a rubber stamp this time.

> 
> I hope that the IDN WG can settle on a safe course of action. However,
> until that happens, we will have to stick to the status quo.
> 
> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago

Re: Last Call: IETF and ITU-T Collaboration Guidelines toInformational

[John W Noerenberg II]

At 8:53 AM -0500 3/9/02, John Stracke wrote:
>  >However, what's the point of tying someone to the
>>rails after the train wreck?
>
>As a deterrent, I think.  "Don't misrepresent the ITU position, because
>they know whom they sent, and you'll blow your credibility in the ITU."

The trouble here is the damage has already been done.  Perhaps this 
person would not cause further problems, but the idea of the 
Guidelines draft is to prevent the problem in the first place.

Because we want to find a way to collaborate, the draft should make 
some additional accommodations for differences between the ITU-T and 
the IETF.

It must be made clear in section 3.2.2 someone may put on an ITU 
"hat" for the purpose of reporting on status of some  ITU Working 
Party's work as it relates to the work of the IETF working group. 
However, the ITU hat confers no additional value to comments made by 
that person outside the purpose on reporting the ITU Working Party's 
status.  This is much the same as when a WG chair puts on his WG hat 
to clarify a point of procedure, but must remove it in order to 
comment on the work under discussion.

Section 3.2.1 is problematic, because it assumes that someone 
participating in an IETF Working Group and also participating in an 
ITU-T Working Party is capable of representing the IETF's point of 
view.  Rough consensus implies there is no single IETF point of view 
on an issue.  What is available is what the IETF has published as 
RFCs.  Those are the authoritative statements of the IETF, and 
represent the IETF's rough consensus.

I realize there is a need for collaboration before a document is 
published as an RFC.  However, it is a disservice to both the ITU-T 
and to the IETF to say that an individual can represent the IETF's 
view before an RFC is published. 3.2.2 should make clear that even if 
someone participating in an IETF working group has been designated as 
a delegate to an ITU-T meeting, that individual represents the point 
of view of the IETF only insofar as he is consistent with what is 
published in RFCs.  I-Ds may contain interesting information, but 
they aren't authoritative.

3.3.1 deals with I-Ds, but doesn't discuss I-Ds which aren't under 
the aegis of a IETF working group.  The IETF does not now restrict 
access to I-Ds (or any other document).  The ITU should not need 
permission to consider them.

best,
-- 

john noerenberg
[EMAIL PROTECTED]
   --
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, the makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   --

Re: [idn] WG last call summary

[Paul Hoffman / IMC]

At 3:58 AM + 3/11/02, D. J. Bernstein wrote:
>You say that you are obliged to ignore all these objections because the
>IDN WG has to _do something_.

You are lying again, Dan. Marc never said that, and you know it.

--Paul Hoffman, Director
--Internet Mail Consortium

RE: Last Call: IETF and ITU-T Collaboration Guidelines to Informational

[Larry Masinter]

Shouldn't this be considered as BCP rather than Informational?

Formal liaison rules don't substitute well for responsibility
and judgment.

I would suggest that a set of guidelines for collaboration
between IETF and other organizations in general should
include an analysis of common failure modes, and encourage
the participants to exercise good judgment and oversight
so that these don't occur.

Think of it like a set of "security considerations": analyze
the threats and describe how the threats can be mitigated
by the form of the liaison relationship.

Some examples of common failure modes:

*** Someone will misrepresent what's happening
in the other group and present their own or their company's
point of view as if it were the other group's. This was
the example given earlier. The threat is that someone
might be given more deference because they are "from the ITU".
(Note that this isn't so different from the case where a
'representative' from a Major Software vendor stands up and
makes statements like 'my company will never implement X'.)

*** Someone will "game" the system, for
example, to move forward a technical proposal by telling
each group that "the other group wants this". So, for example,
everyone in the IETF working group tries to help out the ITU by
endorsing a proposal because they think the ITU needs it,
while everyone in the ITU goes along with it because they
think the IETF has already approved it. Meanwhile, nobody
really cares or wants this feature.

*** People will "standards shop":
They'll choose one organization or another in response to different
requirements on intellectual property claims or assertions,
or different requirements for security considerations, or
independent interoperable implementations. One group or
the other winds up considering technologies or specifications
that don't meet their criteria.

*** Second-guessing:
When turned down by one organization because the proposal
is disruptive, inconsistent with that organization's architectural
or operational principals, individuals who were frustrated
will take the standards proposal to another organization
which doesn't have the same design principals or requirements.

*** Mutual deadlock: each group is waiting for the other
to finish a specification, and there is no way to easily
more forward with interlinking specifications.

*** Misunderstanding of other group's processes: working groups
in one organization avoid doing the coordination with the
other organization because of misunderstanding, fear, or
deliberate sabotage.

RE: Last Call: IETF and ITU-T Collaboration Guidelines to Informational

[John Stracke]

>*** Someone will "game" the system, for
>example, to move forward a technical proposal by telling
>each group that "the other group wants this".

One solution to this one might be to close the loop: if a WG is going to 
act on a claim that the ITU wants such-and-so, then the WG chair checks 
with the ITU (somehow...).  And vice versa, of course.

/\
|John Stracke|Principal Engineer |
|[EMAIL PROTECTED]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
||
|Earth: love it or leave it. |
\/

Re: Last Call: IETF and ITU-T Collaboration Guidelines to Informational

[Valdis . Kletnieks]

On Tue, 12 Mar 2002 15:45:15 EST, John Stracke <[EMAIL PROTECTED]>  said:
> One solution to this one might be to close the loop: if a WG is going to 
> act on a claim that the ITU wants such-and-so, then the WG chair checks 
> with the ITU (somehow...).  And vice versa, of course.

This would be a no-brainer, except that it's been asserted already that the
ITU will refuse to give a straight answer to a non-ITU member.  Thus all
the tap-dancing.
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg07700/pgp0.pgp
Description: PGP signature

Netmeeting - NAT issue

[Vivek Gupta]

 
Hi
I have been bugging U guys a lot for long now . 
especially Hari
 
OK here is another question quite similar to 
previous one:
 
Net meeting by Microsoft is not suppoted by NAT 
. this is the major problem 
 
--this is a problem with NAT or with NET 
meeting.??
 
I think I should rephrase my query 
...wait
 
--Is it that the net meeting doesn't support NAT 
 or the NAT doesn't support netmeeting.??
 
I know that Net Meeting doesn't work with NAT . 
but where exactly is the problem ...with NAT or with netmeeting
 
attached is my network set up
 
thanx
Vivek


NAT.doc
Description: MS-Word document

Re: Netmeeting - NAT issue

[Randy Bush]

> Net meeting by Microsoft is not suppoted by NAT . this is the major
> problem

you may not have noticed that
  o there is no ietf standards track document for net meeting
  o there is no ietf standards track document for nat

hence no one here is surprised.  caveat emptor.

we design and build the information superhighway.  we can not repair
you car.

randy

Re: Netmeeting - NAT issue

[Keith Moore]

> Net meeting by Microsoft is not suppoted by NAT . this is the major
> problem

NATs violate many of the assumptions of the Internet Protocol.  It's 
unrealistic to expect many kinds of IP applications to work in the 
presence of NATs,  unless they were specifically designed to do so.
And while it might seem desirable to make all applications NAT-tolerant,
NAT-tolerant design often imposes significant barriers to the 
performance and scalability of applications, and (due to the need 
for intermediaries to tunnel through NATs) to deployment of such 
applications.

Keith

Re: Netmeeting - NAT issue

[Jose Manuel Arronte Garcia]

Hi Vivek:
 
    I am behind a 
firewall, as Help-desk Mgr. we had to find some answers for our customers 
regarding the issues you ask. I am SURE the problem is with netmeeting and other 
MS comunications softwatre. Try the following links:
 
http://messenger.msn.com/support/knownissues.asp
 
http://r450.voice.microsoft.com/netinfo.asp?NAT=yes&PLCID=0c0a&Version=4.5&CLCID=080a&BrandID=MSMSGS&country=MX
 
http://messenger.microsoft.com/ES/support/helphome.asp?client=1#Q3b
 
the problem is with Netmeeting, not 
with NAT.
 
Saludos.Regards.José 
Manuel Arronte GarcíaSupervisor de Soporte Técnico Helpdesk
 
Meg@Red 
VeracruzOperadora MegaCable S. A. de C. V.Av. S. Díaz Mirón 
2625-AFracc. Moderno 91916Veracruz Ver. MÉXICO
 
+52 (229) 923-0400, 923-0410 ext. 
5http://www.megacable.com.mx/http://www.megared.net.mx/
 
"Who's the more 
foolish, the fool, or the fool who follows him?". --O. W. Kenobi (in 
Star Wars ep.IV: A New Hope)
 
 

  - Original Message - 
  From: 
  Vivek Gupta 
  
  To: [EMAIL PROTECTED] 
  Sent: Tuesday, March 12, 2002 3:48 
  PM
  Subject: Netmeeting - NAT issue
  
   
  Hi
  I have been bugging U guys a lot for long now 
  . especially Hari
   
  OK here is another question quite similar to 
  previous one:
   
  Net meeting by Microsoft is not suppoted by NAT 
  . this is the major problem 
   
  --this is a problem with NAT or with NET 
  meeting.??
   
  I think I should rephrase my query 
  ...wait
   
  --Is it that the net meeting doesn't support NAT 
   or the NAT doesn't support netmeeting.??
   
  I know that Net Meeting doesn't work with NAT 
  . but where exactly is the problem ...with NAT or with 
  netmeeting
   
  attached is my network set up
   
  thanx
  Vivek

Re: Netmeeting - NAT issue

[Joe Touch]

Vivek Gupta wrote:

>  
> Hi
> 
> I have been bugging U guys a lot for long now . especially Hari
> 
> OK here is another question quite similar to previous one:
> 
> Net meeting by Microsoft is not suppoted by NAT . this is the major 
> problem
> 
> --this is a problem with NAT or with NET meeting.??


Anything that works with regular IP addresses and breaks with IP 
addresses (as you describe in your figures), is, by definition, the NAT 
breaking.


> I think I should rephrase my query ...wait
> 
> --Is it that the net meeting doesn't support NAT  or the NAT doesn't 
> support netmeeting.??


NAT doesn't support Netmeeting. It uses H.323 encoding, which uses IP 
addresses and dynamically assigned ports in-band (inside the 
connection). The NAT is translating the outer IP addresses, but because 
your NAT doesn't understand H.323, it doesn't know it would have to also 
translate the inner addresses and ports. Netmeeting expects that it can 
dynamically select a port to use to connect back to your machine, but 
that defeats what a NAT "thinks" the Internet looks like (notably 
because it's incorrect).

The best solution: get real IP addresses. It's cheaper than wasting your 
time figuring out why things don't work.

Joe

Revisions to NOMCOM - RFC2727

[James M Galvin]

Discussions halted more than a month ago in deference to the active
NOMCOM process.  Now that they have completed their task we should pick
up the discussion of the revision to the Nominating Committee
Procedures (RFC2727).  I wanted to take this opportunity to remind
everyone about this important work and encourage more participation.

RFC2727bis specifies how the IESG and IAB members are selected.  It is
your community and they are your leaders.  Please do take an interest in
how the IETF is managed.


There is no physical working group for this document and hence no
meeting at this next or any IETF.  All work will be completed on the
mailing list:

[EMAIL PROTECTED]

To Subscribe:
a. send a message with the single word "subscribe" in the body
   to [EMAIL PROTECTED]
b. visit the following URL:
 http://lists.elistx.com/subscribe

However, I will be at the IETF next week for anyone who wants to have a
face-to-face discussion.


The Agenda has grown by a few items since the last publication.  I'm
sure there will be more items before we are done.  I've included a copy
below.

Finally, note that RFC2727 is a BCP.  When this revision is completed it
will replace RFC2727 and also be a BCP.


Thanks,

Jim

--
James M. Galvin <[EMAIL PROTECTED]>




AGENDA (as of 3/12/2002)

a. ISOC liaison

b. Handling disputes regarding the selection of NOMCOM members

c. NOMCOM announcements to all IETF mailing lists

d. Clarifications to Recall Process

e. Clarify filling an interim vacancy very late in an existing NOMCOM
   cycle, i.e., new NOMCOM is currently being created and there is a
   vacancy to be filled

   e.1. Who sends out call for nominations?  Two calls seems confusing
at best.

f. NOMCOM should retain information/documentation until the end of its
   cycle.



NEW AGENDA ITEMS SINCE 1/28/2002 (as of 3/12/2002)

g. Should there be term limits?

h. Should we relax the confidentiality requirement for *nominated*
   candidates?  The intent here is to facilitate getting comments from
   the community as it would permit announcements of all those who are
   to be considered.

i. Can we say more, perhaps more explicitly define the role of liaisons?
   In particular, is it reasonable for the NOMCOM to have deliberations
   explicitly in the absence of liaisons?  Perhaps the liaisons are
   really only needed early in the process to bring relevant experience
   and insight to be used by the NOMCOM?  Perhaps the liaisons should
   not be present during voting?



INCORPORATED - STILL OPEN FOR COMMENT (as of 3/12/2002)

   1.  A definition for "sitting member" was added.

   2.  An information retention policy was added requiring the Chair to
   submit a collection of all information related to the operation
   of and execution of the responsibilities of the nominating
   committee to the Internet Society President for long-term
   storage.  Previous Chairs have done this so the addition is just
   a formalization of existing practice.

   3.  A timeframe for the appointment of the Chair was added.  The
   timeframe could always be inferred from the text but to avoid
   confusion it is now explicitly stated.

   4.  Some explicit guidance was added regarding the timeframe for
   volunteering to serve on the nominating committee.

   5.  Some explicit guidance was added to the process of selecting the
   nominating committee members.  Among other things it must be
   possible to iterate the selection method more than just 10 times
   to ensure that unavailable or ineligible volunteers can be
   replaced.

   6.  It is now explicitly stated that no person may serve on both the
   IESG and the IAB concurrently.



COMPLETED (as of 3/12/2002)

RE: Last Call: IETF and ITU-T Collaboration Guidelines to Informational

[Larry Masinter]

> >*** Someone will "game" the system, for
> >example, to move forward a technical proposal by telling
> >each group that "the other group wants this".
> 
> One solution to this one might be to close the loop: if a WG is going
to 
> act on a claim that the ITU wants such-and-so, then the WG chair
checks 
> with the ITU (somehow...).  And vice versa, of course.

But, as we've established, it's hard to "check with the ITU"
when the liaisons are the ones playing the game; and folks with
an agenda are the ones most likely to volunteer for such roles.

Just as with protocol security, you can design all of the
feedback you want, but there may need to be some kind of "intrusion
detection" to decide if you're being hacked.