From ietf-bounces@ietf.org Sun Jan 01 00:37:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsvuE-0006PZ-Fu; Sun, 01 Jan 2006 00:37:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esvu8-0006MN-9o for ietf@megatron.ietf.org; Sun, 01 Jan 2006 00:37:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20195 for ; Sun, 1 Jan 2006 00:36:04 -0500 (EST) Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Esvyq-000561-Tb for ietf@ietf.org; Sun, 01 Jan 2006 00:42:14 -0500 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k015WtYL018844 for ; Sun, 1 Jan 2006 07:32:55 +0200 (IST) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k015WsLx018838 for ; Sun, 1 Jan 2006 07:32:54 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 1 Jan 2006 07:36:35 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5205DCDB72@exrad2.ad.rad.co.il> Thread-Topic: Alternative formats for IDs Thread-Index: AcYOlVR9ovrFTyXdS6uaA3deoXfOpw== From: "Yaakov Stein" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0882860664==" Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org This is a multi-part message in MIME format. --===============0882860664== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C60E95.551F1835" This is a multi-part message in MIME format. ------_=_NextPart_001_01C60E95.551F1835 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Happy new year to everyone. =20 I would like to call your attention to a new ID http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt . =20 This ID is the result of discussions here on the general list, and proposes the use of formats other than plain ASCII for IDs and RFCs. In particular, it proposes the allowance of diagrams other than "ASCII-art" as normative. =20 The authors felt that further discussion on the list would not be productive,=20 but that the writing of an ID might force more serious consideration. We furthermore suggest that this ID be advanced as a BCP under the process for process change. =20 Y(J)S =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C60E95.551F1835 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Happy = new year to=20 everyone.
 
I = would like to call=20 your attention to a new ID
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt=  .
 
This ID is the=20 result of discussions here on the general = list,
and proposes=20 the use of formats other than plain ASCII
for IDs and=20 RFCs. In particular, it proposes the = allowance
of diagrams=20 other than "ASCII-art" as normative.
 
The authors=20 felt that further discussion on the list would not = be productive,=20
but=20 that the writing of an ID might force more serious = consideration.
We=20 furthermore suggest that this ID be advanced as a=20 BCP
under the=20 process for process change.
 
Y(J)S
 
 
 
 
 
 
------_=_NextPart_001_01C60E95.551F1835-- --===============0882860664== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --===============0882860664==-- From ietf-bounces@ietf.org Sun Jan 01 01:46:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EswzI-0003Mn-4B; Sun, 01 Jan 2006 01:46:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EswzF-0003Mf-4t for ietf@megatron.ietf.org; Sun, 01 Jan 2006 01:46:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25675 for ; Sun, 1 Jan 2006 01:45:25 -0500 (EST) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Esx42-00071E-BJ for ietf@ietf.org; Sun, 01 Jan 2006 01:51:36 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Eswyx-0007Hn-4I for ietf@ietf.org; Sun, 01 Jan 2006 07:46:19 +0100 Received: from 1cust5.tnt7.hbg2.deu.da.uu.net ([149.225.100.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jan 2006 07:46:19 +0100 Received: from nobody by 1cust5.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jan 2006 07:46:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Frank Ellermann Date: Sun, 01 Jan 2006 07:31:28 +0100 Organization: Lines: 204 Message-ID: <43B77740.32CE@xyzzy.claranet.de> References: <43A8893F.9010700@dcrocker.net> <43A8C2EC.4060401@dcrocker.net> <0b0d55f43c319b517cad80dd1d5d76d0@guppylake.com> <1135458563.17219.79.camel@bash.adsl-64-142-13-68> <983DD241-F8D4-4331-88BF-481A796333D0@mail-abuse.org> <43B1E85D.4F18@xyzzy.claranet.de> <22FDDD3D-C3A4-4099-8583-68EAF16BBA67@mail-abuse.org> <43B4F156.236C@xyzzy.claranet.de> <1135997824.17219.230.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust5.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.2 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: 7bit Subject: Re: SIQ, SPF, BATV, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Douglas Otis wrote: > The BATV draft seems to be a good start. Perhaps it can be > further simplified. Could this satisfy both camps? Which both camps, SES vs. BATV, STD 10 + SPF vs. STD 3 + 2821, or something else ? For the former I'm lost, I read the now expired BATV draft, and for SES all I know is that they can optionally use the SPF "exists"-mechanism somehow resulting in 1123 5.3.6(a) compatibility. I wasn't very interested because IIRC it worked only for domains with their own name server (?) > There is no question that better conventions are needed when > dealing with auto-responses. Conventions that limit the > alternative to MAILER-DAEMON@, instead of a null address > could be helpful. In 2004 SC still did not allow to report backscatter as abuse, my "rule collection" to extract this crap from all other spam was constantly growing until "my" spammer figured out SPF FAIL. One of these rules was MAILER-DAIMON@ (sic ;-) Yes, it could be helpful for applications behind a smart host or non-2476bis-MSA not supporting MAIL FROM:<> But that's a potential FUSSP-trap. Additionally you'd have to s/MAY/SHOULD/ in 3834 section 3.3. The latter might be possible without much ado, and I'd like a 3834bis as DS. Two implementation reports, anybody ? > could be introduced into a BATV expectation list, when needed 3834 lists owner-* and *-request in addition to MAILER-DAEMON. >> Hardcore "bounces-to" fans won't use BATV, they already hate >> the more flexible SPF. > This is not an issue for BATV. BATV does not depend upon any > third-party adoption. You can't use "your" Return-Path on any route you like if the returned messages are rejected by BATV. That's the same issue as for SPF, only more restrictive: SPF allows to aggregate unrelated sending routes per domain. BATV works for one and only one MON (all its MSAs plus the corresponding MRN). And I don't see how a "bounces-to" fan could accept this. > As part of the BATV draft, when the message is delivered, > removing the tag or obfuscating the BATV section in > what is normally prefixed as "Return-Path:" would also be a > helpful practice. IMHO that would break vacation-like 3834-applications, their auto-responses would be rejected by the originator's BATV-MRN. It's not that I don't like BATV, but it can't substitute SPF FAIL. For those who can do both they should certainly try it. You're not talking about creating BATV local parts in the MUA, or are you ? That would be another FUSSP trap. IIRC the BATV idea is to replace the local-part of the MAIL FROM at the MSAs (or mail-outs behind an MSA), and undo that modification later for the local part of the RCPT TO at the MXs (or MDA) in the case of "returned" mails, invisible from the sending MUA's POV. While the MXs reject all other identified bounces, that's the purpose of this coordinated MON + MRN effort known as BATV. >> doesn't address the real problem, the forged Return-Paths. > On the contrary, BATV eliminates the forged return-path as a > delivery strategy. Sorry, I fail to see how, not without "call-back-verification" at the side of the primary spam victims. Or an equivalent pre- abuse-address-quality-control-test by the spammer. The latter strategy worked for SPF FAIL because professional spammers use SA for their QoS-tests (1). Without knowing SA I doubt that it supports "call-back-verification", that's rather expensive, or isn't it ? [1: source = my crystal ball when "my" spammer stopped to abuse "my" addresses soon after SA 3.0 supported SPF, 2004-09-01] >> With SPF FAIL this crap can be rejected a.s.a.p. [...] > "As Soon As Possible" is not better than "As Painless As > Possible." : ) Well, the "SPF-opposition" is apparently determined to let SMTP die while preserving 1123-5.3.6(a) "251"-forwarding, and a dead SMTP won't feel the pain. Most SPF FAIL policies are a "die, spammer, die" voice against 1123 5.3.6(a). Excluding a few who publish -all without RTFM. > Rather than compiling lists of addresses for outbound servers > for a set of domains by issuing dozens of DNS lookups, NAK, still two lookups in my case before you have either PASS or FAIL. In theory one query would do, but I won't bother my ISP with this minor improvement before SPF is at least a PS. For an SES-exists variant it might be also two DNS queries (?) No idea what the average is, but it would surprise me if it's more than six, let alone one dozen, or your "dozens". Some of the most complex sender policies are huge ISPs sending lots of mail, and then you'd get many answers from your cache. >> 1123 5.3.6(a) does not work as expected in its own post-821 >> "bounces-to" world. > This is a problem only when a third-party attempts to verify > the return-path. What they actually do is use it as specified for their crappy "accept-then-bounce" setup. That was "state of the art" until 2001 as documented in 2821. Won't make it into any 2821bis. Verification with SPF started 2004, only a minority does this. Fortunately the spammers can't determine who checks SPF without rejecting FAIL, and therefore they're forced to avoid SPF FAIL protected addresses. Besides we're not yet in the phase where spammers are forced to pick their Return-Path depending on the target. Except from the obvious idea to use a plausible ccTLD matching that of the recipient in localized spam. Or the stoneage From = To tricks, I consider that as incentive for SPF FAIL publishers to join the "SPF checking elite" (that doesn't include my ISP, maybe they'll see the light in 2006 ;-) > Prevent the bounce delivery strategy from being successful, > and soon it will not be used. BATV prevents this strategy > from being successful without changing email practices. IMO it's in most cases no "delivery strategy". 2821-DDoS and Joe Jobs excluded I think the spammers just abuse any address surviving "call-back-verification". They really try to reach their primary RCPT TO victims, not the secondary MAIL FROM. And BATV does nothing for the existing primary victims, it only blocks most "user not found" + "user over quota" bounces at the MX of the secondary victim. At this time the spam was already accepted by an MX of the primary victim, rejected by the MDA, and queued for a bounce message in a "mail out" of this primary victim. At this time all other spams abusing the same MAIL FROM domain of the secondary victim are _delivered_ to all existing primary victims (minus "over quota" cases). BATV has none of the SPF FAIL advantages for primary victims, it only blocks some of the backscatter. BATV does nothing wrt obscure C/R systems. Behind an SPF PASS C/R systems might actually work as expected for the first time. Behind an SPF PASS the complete SMTP up to 3834 works again. BATV doesn't have this feature. BATV catches 100% of all bogus bounces, and that's a feature you won't get with SPF FAIL. For "all" read "the obvious bounces" as discussed above, not all the other backscatter (vacation + C/R + AV-"feedback" + ...) > SPF adds overhead and expects changes to email practices > before being fully effective. No, SPF FAIL works already for those who want it. It's a pure voluntary system, nobody is forced to participate. As far as changing 1123 5.3.6(a) forwarding is concerned, that's the job of the receivers: Check SPF at the first border MTA, and white list all forwarding MTAs on the receiving side if you check it "again" later. How they arrange this isn't the business of the sender, there are many ways to get it right. Not limited to ignoring the issue, if a "251" results in a "pseudo-551" it is in the spirit of STD 10 and SPF's "back to the routes". In that case let the sender figure it out, "551" is no new idea. > Those who publish SPF records are at risk of being block- > listed when these records have been exploited. : ( Yes. If you can't risk PASS don't, use NEUTRAL. But before a decent 2476bis 6.1 MSA you can always use PASS. So far only two users were seriously interested in some kind of "HARDPASS", I've noted that as op=auth. Pointless at the moment, because it's irrelevant for receivers, it's only relevant in conjuction with future "reputation systems". Enjoying the IETF tools see: http://tools.ietf.org/html?url=http://purl.net/xyzzy/home/test/draft-spf-6-3-options-09.txt#section-3.4 > SPF qualifying the return-path is defunct as there are no > records defined for this purpose, with this record usurped > by Sender-ID. The opt-out strategy still risks wholly unfair > treatment. Those unethical activities (we can rule out the mere "error" as proposed by Keith some months ago at this time) are no flaw in the SPF design. I've formally asked the SPF Council to support an appeal to the IAB: IIRC you also reported your concerns to iesg@ietf. It's all on public record, everybody can draw his conclusions, and I won't participate in any IESG-sponsored opt-out schemes. A happy new year to all spam fighters _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 02:47:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esxvf-0006YW-2F; Sun, 01 Jan 2006 02:46:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esxvb-0006Xh-ER for ietf@megatron.ietf.org; Sun, 01 Jan 2006 02:46:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00021 for ; Sun, 1 Jan 2006 02:45:42 -0500 (EST) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Esy0Q-0008T4-9H for ietf@ietf.org; Sun, 01 Jan 2006 02:51:54 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EsxvW-0005jo-7X for ietf@ietf.org; Sun, 01 Jan 2006 08:46:50 +0100 Received: from 1cust5.tnt7.hbg2.deu.da.uu.net ([149.225.100.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jan 2006 08:46:50 +0100 Received: from nobody by 1cust5.tnt7.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jan 2006 08:46:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Frank Ellermann Date: Sun, 01 Jan 2006 08:43:55 +0100 Organization: Lines: 29 Message-ID: <43B7883B.365D@xyzzy.claranet.de> References: <27A0F290348F8E45AEF79889DDE65A5205DCDB72@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust5.tnt7.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: Re: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Yaakov Stein wrote: > http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt Yes, it introduces at least five surprising and new concepts: 1: "rough consensus" is determined by taking 1000 default YES- opinions, and then consider up to 20 explicit objections as irrelevant. 2: Folks who can't read MS Word documents are also irrelevant. It's the "most 'standard' document exchange language on the Internet". (Actually all its versions are from the people who invented the Internet, please don't forget to submit an IPR note). 3: Discussing MS Word and empty security considerations are no contradiction. Not mentioning RFC 3285 at all is no issue. 4: An enumeration of "virtually all other SDOs" consisting of "ITU-T, MFA, and many other SDOs" confirms again the "clear consensus" already established in point 1. 5: Empty informative references are a good replacement for any IANA considerations. A normative 2119 reference without (?) using any 2119 keyword at all might be also new. OTOH the draft talks about 3933 without reference, For the statement that "many contributors to the thread" suggested MS Word among other additional formats I must have missed many articles in the thread. -- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 04:43:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eszk8-0002Na-Kf; Sun, 01 Jan 2006 04:43:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eszk6-0002Lt-6B for ietf@megatron.ietf.org; Sun, 01 Jan 2006 04:43:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05694 for ; Sun, 1 Jan 2006 04:41:56 -0500 (EST) Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eszot-00074x-8A for ietf@ietf.org; Sun, 01 Jan 2006 04:48:10 -0500 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k019d8YL011604 for ; Sun, 1 Jan 2006 11:39:08 +0200 (IST) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k019d7Lx011598; Sun, 1 Jan 2006 11:39:08 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Jan 2006 11:42:50 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5205DCDC48@exrad2.ad.rad.co.il> Thread-Topic: Alternative formats for IDs Thread-Index: AcYOqCVvJkKQBAt4Tx+s52Qu67KmXQAC+D7A From: "Yaakov Stein" To: "Frank Ellermann" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org =20 Yes, it introduces at least five surprising and new concepts: 1: "rough consensus" is determined by taking 1000 default YES- opinions, and then consider up to 20 explicit objections as irrelevant. [YJS] Humorous, but not what we said. We suggested taking a show of hands amongst the thousands who read IDs and RFC, and not only among the five or so very vocal people who respond to emails on the IETF general list within 5 minutes (even on January first) . 2: Folks who can't read MS Word documents are also irrelevant. It's the "most 'standard' document exchange language on the Internet". (Actually all its versions are from the people who invented the Internet, please don't forget to submit an IPR note).=20 [YJS] I don't really believe that there are many people who can not read MS Word documents. And I believe that the=20 number of people who can read neither Word nor PDF=20 is infinitesimally small. [YJS] There are free viewers for both of these formats for every operating system imaginable, and all popular web browsers have integral support or a free an add-on.=20 [YJS] But I guess there may be a few people who write=20 their own OS and browsers and only read ASCII format. Perhaps we can assume that these two or three people left who can read neither Word nor PDF can read HTML=20 with embedded gifs, and suppy a converter to that format? 3: Discussing MS Word and empty security considerations are no contradiction. Not mentioning RFC 3285 at all is no issue. [YJS] This was a draft put together to start discussion. We will add references later. [YJS] Was the issue of a security section a substantive one or a nit-picking one? If the latter, we will add a content-free one in a later version. If the former, please explain how reading IDs in PDF is more of a security risk than reading the ASCII version in a browser. 4: An enumeration of "virtually all other SDOs" consisting of "ITU-T, MFA, and many other SDOs" confirms again the "clear consensus" already established in point 1. [YJS] No it is just to point out that any IETF participant who participates works in ANY other SDO (or works in ANY company, or reads data-sheets or white-papers from ANY company, or ...) has the ability to read either Word or PDF. 5: Empty informative references are a good replacement for any IANA considerations. A normative 2119 reference without (?) using any 2119 keyword at all might be also new. OTOH the draft talks about 3933 without reference, [YJS] Already discussed above. For the statement that "many contributors to the thread"=20 suggested MS Word among other additional formats=20 I must have missed many articles in the thread. [YJS] I will have to sort this one out=20 (this line wasn't mine and my co-authors are out on New Years vacation). We did get quite a lot of off-list support and frequently the subject line was copied from messages on the list.=20 This makes it confusing as to what was said in public,=20 and what was seen only by us. Y(J)S _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 06:24:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et1KZ-0000Zg-8b; Sun, 01 Jan 2006 06:24:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et1KV-0000YD-Tz for ietf@megatron.ietf.org; Sun, 01 Jan 2006 06:24:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21834 for ; Sun, 1 Jan 2006 06:23:38 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et1PJ-0000pF-M2 for ietf@ietf.org; Sun, 01 Jan 2006 06:29:52 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 29CAE898C6; Sun, 1 Jan 2006 13:24:22 +0200 (EET) Message-ID: <43B7BC06.4040200@piuha.net> Date: Sun, 01 Jan 2006 13:24:54 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yaakov Stein References: <27A0F290348F8E45AEF79889DDE65A5205DCDB72@exrad2.ad.rad.co.il> In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDB72@exrad2.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org I am in favor of enhancing graphics formats that we allow for normative versions of our drafts and RFCs. (Note that this is already allowed for non-normative things, such as a graphic state machine descriptions in a .pdf when .txt has a state table.) However, I would like to limit a new graphic format to .pdf in the output. I am strongly opposed to employing the Word format. I also believe that introducing multiple formats when proposing a first step towards richer specification formats would be a mistake; it would be more prudent to start with one. We could also consider limiting the input format in these cases to .xml and .jpg/.gif/.png, so that we, the IETF, would always have the source to re-generate our documents when we need to switch from .pdf to something else in the future. --Jari P.S. I have prototype tools to deal with the generation of .pdf from .xml involving figures. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 07:32:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et2OM-0002in-Kv; Sun, 01 Jan 2006 07:32:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et2OK-0002hq-Ez for ietf@megatron.ietf.org; Sun, 01 Jan 2006 07:32:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02488 for ; Sun, 1 Jan 2006 07:31:40 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Et2T9-0002VM-DZ for ietf@ietf.org; Sun, 01 Jan 2006 07:37:54 -0500 Received: (qmail invoked by alias); 01 Jan 2006 12:32:38 -0000 Received: from p508F8176.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.129.118] by mail.gmx.net (mp028) with SMTP; 01 Jan 2006 13:32:38 +0100 X-Authenticated: #1915285 Message-ID: <43B7CB83.9080407@gmx.de> Date: Sun, 01 Jan 2006 13:30:59 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Frank Ellermann References: <27A0F290348F8E45AEF79889DDE65A5205DCDB72@exrad2.ad.rad.co.il> <43B7883B.365D@xyzzy.claranet.de> In-Reply-To: <43B7883B.365D@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Frank Ellermann wrote: > 2: Folks who can't read MS Word documents are also irrelevant. > It's the "most 'standard' document exchange language on the > Internet". (Actually all its versions are from the people > who invented the Internet, please don't forget to submit an > IPR note). Yes, that one was particularly entertaining. And I was thinking that HTML is slightly more successful :-) Seems I misses something. Best regards, Julian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 07:36:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et2Ra-0004YP-Hk; Sun, 01 Jan 2006 07:36:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et2RZ-0004YI-Dk for ietf@megatron.ietf.org; Sun, 01 Jan 2006 07:36:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02806 for ; Sun, 1 Jan 2006 07:35:01 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Et2WR-0002bw-BS for ietf@ietf.org; Sun, 01 Jan 2006 07:41:15 -0500 Received: (qmail invoked by alias); 01 Jan 2006 12:36:03 -0000 Received: from p508F8176.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.129.118] by mail.gmx.net (mp021) with SMTP; 01 Jan 2006 13:36:03 +0100 X-Authenticated: #1915285 Message-ID: <43B7CC50.5000902@gmx.de> Date: Sun, 01 Jan 2006 13:34:24 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Yaakov Stein References: <27A0F290348F8E45AEF79889DDE65A5205DCDC48@exrad2.ad.rad.co.il> In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDC48@exrad2.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Frank Ellermann , ietf@ietf.org Subject: Re: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Yaakov Stein wrote: > ... > We did get quite a lot of off-list support > and frequently the subject line was copied from messages on the list. > This makes it confusing as to what was said in public, > and what was seen only by us. > ... I see that argument from time to time, and frankly I don't buy it. If people reply off-list, they are not participating in the IETF process. Encourage them to participate instead. Best regards, Julian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 07:59:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et2oJ-0006Y1-NO; Sun, 01 Jan 2006 07:59:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et2oI-0006Xw-4T for ietf@megatron.ietf.org; Sun, 01 Jan 2006 07:59:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04540 for ; Sun, 1 Jan 2006 07:58:30 -0500 (EST) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et2tA-0003LT-2t for ietf@ietf.org; Sun, 01 Jan 2006 08:04:44 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Et2oA-0006ba-77 for ietf@ietf.org; Sun, 01 Jan 2006 13:59:34 +0100 Received: from pd9fba928.dip0.t-ipconnect.de ([217.251.169.40]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jan 2006 13:59:34 +0100 Received: from nobody by pd9fba928.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jan 2006 13:59:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Frank Ellermann Date: Sun, 01 Jan 2006 13:55:48 +0100 Organization: Lines: 64 Message-ID: <43B7D154.7B81@xyzzy.claranet.de> References: <27A0F290348F8E45AEF79889DDE65A5205DCDC48@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba928.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Subject: Re: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Yaakov Stein wrote: > We suggested taking a show of hands amongst the thousands > who read IDs and RFC, and not only among the five or so very > vocal people who respond to emails on the IETF general > list within 5 minutes (even on January first) . I read it the day before yesterday, so that "5 minutes" took me only an hour after finding your pointer here, including the time to lookup 3285. > There are free viewers for both of these formats for every > operating system imaginable, and all popular web browsers > have integral support or a free an add-on. I've never heard of a Word viewer for OS/2. Something with your "every", "many", "virtually all", "all popular", "five minutes" and so on doesn't work. No problem in a flamewar, but for an April 1st RFC this could give it away too soon. > I guess there may be a few people who write their own OS > and browsers and only read ASCII format. Perhaps we can > assume that these two or three people left who can read > neither Word nor PDF can read HTML with embedded gifs, and > suppy a converter to that format? Yes, that's AFAIK somewhere near File -> Save As in Word XP (no idea about earlier versions). If "two or three" covers most mobile devices (one), pre-W2K (?) users without Office (two), and me (three) that HTML conversion should help. > Was the issue of a security section a substantive one or a > nit-picking one? If you're not sure check out the security considerations in RFC 3285, Listing some relevant "Vulnerability Notes" could do the trick. Maybe mention that it's often not possible to send Word documents in mail, it won't survive many filters. > please explain how reading IDs in PDF is more of a security > risk than reading the ASCII version in a browser. Nothing I said was about PDF, I'm talking about MS Word. Some PDF "colorspace N not found" or "cannot extract embedded font" issues are no security risk from my AcroReader 3 POV. I've read that they plan to introduce a monthly patch day for actual versions of their reader. [enumeration of "virtually all other SDOs" consisting of "ITU-T, MFA, and many other SDOs"] > it is just to point out that any IETF participant who > participates works in ANY other SDO (or works in ANY > company, or reads data-sheets or white-papers from ANY > company, or ...) has the ability to read either Word or PDF. I've certainly never seen many W3C documents. The ECMA CDs were PDF, Most of the time I get away with "if it's neither ASCII nor (X)HTML ignore it". Proprietary and other formats come and go, ASCII stays. nroff, troff, TeX, texinfo, ps, MS quickhelp, OS/2 inf, etc. The oldest format I recall was something for VM/CMS. Now we have wiki and atom. Bye, Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 08:39:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et3QY-0003Sb-Jw; Sun, 01 Jan 2006 08:39:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et3QW-0003Qz-Qq for ietf@megatron.ietf.org; Sun, 01 Jan 2006 08:39:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07621 for ; Sun, 1 Jan 2006 08:38:00 -0500 (EST) Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et3VP-0004OV-9E for ietf@ietf.org; Sun, 01 Jan 2006 08:44:15 -0500 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 38CC337F77; Sun, 1 Jan 2006 14:38:46 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 058F537F68; Sun, 1 Jan 2006 14:38:46 +0100 (CET) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id DFF3A37E43; Sun, 1 Jan 2006 14:38:45 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.60) (envelope-from ) id 1Et3Q5-0002RV-2L; Sun, 01 Jan 2006 14:38:45 +0100 Message-ID: <43B7DB63.5010005@levkowetz.com> Date: Sun, 01 Jan 2006 14:38:43 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yaakov Stein References: <27A0F290348F8E45AEF79889DDE65A5205DCDB72@exrad2.ad.rad.co.il> In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDB72@exrad2.ad.rad.co.il> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Hi Yaakov, on 2006-01-01 06:36 Yaakov Stein said the following: > Happy new year to everyone. > > I would like to call your attention to a new ID > http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt > . > > This ID is the result of discussions here on the general list, > and proposes the use of formats other than plain ASCII > for IDs and RFCs. In particular, it proposes the allowance > of diagrams other than "ASCII-art" as normative. > > The authors felt that further discussion on the list would not be > productive, > but that the writing of an ID might force more serious consideration. > We furthermore suggest that this ID be advanced as a BCP > under the process for process change. I've read the ID, and have some comments. Overall: I personally think this is a bad idea. I'd have much more sympathy for a proposal to introduce PDF/A as a normative output format, and leave it at that; the introduction of a non-open non-standard format (MS-Word) as a normative output format seems like a huge step backwards. Specific comments and questions: > 3. Proposal for Process Change > > In addition to allowing the basic ASCII text as a normative format, > the authors propose that the I-D editor and RFC editor support three > other normative input/output formats: > > a) MS word (input/output) > b) XML (input only) > c) PDF (output only) * It is not specified whether XML means RFC 2629 format XML. I'll assume it does, but it should be specified. * It is not specified whether all RFCs MUST be provided in all formats, or whether they MAY be provided in any format. If it is the former case, we have non-trivial conversion problems in producing MS-Word documents from Ascii and XML. If it is the latter, you're forcing people to either buy and install specific software to be able to read the RFCs made available in MS-Word format only, or in the worst case it may not even be possible to read the format on all platforms. * You don't specify which version of the MS-Word format which is acceptable. Any? This means that people are forced into an upgrade carousel, as a result of MS' tendency to make new format versions incompatible (not readable) by older programs. Only old ones? Several of those have documented security problems. > > > > If necessary, other formats can be considered. The IETF tools team > will be tasked with producing any format conversion tools needed. No. The tools team is a team of volunteers, and the charter specifies why it exists and how it operates: http://tools.ietf.org/charter-page Being tasked with the far from trivial work of reverse-engineering the various MS-Word formats in order to produce format conversions is not part of this, and doesn't feel particularly meaningful. [snip] > Furthermore, the authors propose that the IESG carefully consider > declaring consensus in support of the change even if a large number > of 'nays' are posted to the IESG discussion list. In that regard, > Henrik Levkowetz posted the following comment > (http://www1.ietf.org/mail-archive/web/ietf/current/msg39170.html): > > "Following the debate from the sideline till now, it's clear to me > that there are at least a few people who are adamantly against > change. I'm not at all convinced that a large majority feels this > way. A poll might reveal more than the relative proportions of > highly engaged people voicing their views here." > > Judging consensus through a poll is sometimes difficult. There is a > vast "silent majority" that would support the proposed additional > formats, or at least not oppose them, but will not express their > opinion on the list. It is much more likely to hear from the very > vocal people who are opposed to the change. That is, assuming 1000s > of participants on the IETF discussion list, perhaps 20 expressed > 'nays', even strong nays, could be considered a clear consensus in > favor of change. No. Either you have to judge consensus from what's experessed on the mailing list, or you have to use some other means of soliciting *expressed* views. You MAY NOT assume that unvoiced views are biased in any direction, and then declare consensus based on such an assumption. My point was that I wasn't so sure that the views voiced on the list were representative of the majority of IETFers - *not* that I assumed that the majority had a particular viewpoint. [snip] > d) 'universal' editing format on the Internet: > > Even though proprietary, Word is probably the most universally used > of all document editors. In all likelihood it is the most 'standard' > document exchange language on the Internet, and that is probably why > most other SDOs use it as their standard format (except IETF). Also, > it is likely that the vast majority of IETFers have the ability to > read Word and other proprietary format documents, since it is vital > that they be able to do that to function well in today's world. In > addition, one only need look at the number of PowerPoint > presentations at IETF meetings to know that proprietary formats are > widely used by IETF participants. > > In the authors' view, it is also not well justified to reject > 'proprietary' formats out of hand: this is not a problem in any other > SDO. I see a lot of guesses here which I would not personally make, and assumptions which I don't share. I'd argue that HTML is the universal presentation format on the internet, and something which is designed for conversion to and from HTML - like XML - would be the closest answer to an internet-centric editing format. But arguing further about this will, I'm afraid, decend into the same discussion we've already had a few months ago. Henrik _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 09:49:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et4Wn-0000Os-GR; Sun, 01 Jan 2006 09:49:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et4Wk-0000O0-O7 for ietf@megatron.ietf.org; Sun, 01 Jan 2006 09:49:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12426 for ; Sun, 1 Jan 2006 09:48:29 -0500 (EST) Received: from [216.148.227.153] (helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et4bd-00065X-H8 for ietf@ietf.org; Sun, 01 Jan 2006 09:54:45 -0500 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (rwcrmhc13) with SMTP id <20060101144925015004s0qve>; Sun, 1 Jan 2006 14:49:25 +0000 Message-ID: <00b501c60ee2$6913a250$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <27A0F290348F8E45AEF79889DDE65A5205DCDB72@exrad2.ad.rad.co.il> <43B7DB63.5010005@levkowetz.com> Date: Sun, 1 Jan 2006 08:48:20 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Subject: Consensus based on reading tea leaves (was: Re: Alternative formats for IDs) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org I do appreciate the authors writing a draft, as opposed to participants who make a usual vague process change suggestion on ietf@ietf.org and generate confused discussion that results from no two commenters having the same understanding of the proposed process change... HOWEVER. I can't imagine that ever encouraging the IESG to decide that they know what IETF consensus "really" is, while disregarding public comment, is ever going to be a good thing to do. The community guidance to the IESG for the past N (where N is at least 3) years has been that the IESG needs to request and respect public comment on an increasing number of topics. I believe that any IESG declaration of consensus based on something beside public comment would be appealable ("all the way to the ISOC BoD") as a process violation, and that it would be a reasonable basis for an AD recall filing. I am also worried about the use of this precedent on other topics. Sorry! Spencer >> Furthermore, the authors propose that the IESG carefully consider >> declaring consensus in support of the change even if a large number >> of 'nays' are posted to the IESG discussion list. In that regard, >> Henrik Levkowetz posted the following comment >> (http://www1.ietf.org/mail-archive/web/ietf/current/msg39170.html): >> >> "Following the debate from the sideline till now, it's clear to me >> that there are at least a few people who are adamantly against >> change. I'm not at all convinced that a large majority feels this >> way. A poll might reveal more than the relative proportions of >> highly engaged people voicing their views here." >> >> Judging consensus through a poll is sometimes difficult. There is a >> vast "silent majority" that would support the proposed additional >> formats, or at least not oppose them, but will not express their >> opinion on the list. It is much more likely to hear from the very >> vocal people who are opposed to the change. That is, assuming 1000s >> of participants on the IETF discussion list, perhaps 20 expressed >> 'nays', even strong nays, could be considered a clear consensus in >> favor of change. > > No. Either you have to judge consensus from what's experessed on the > mailing list, or you have to use some other means of soliciting > *expressed* > views. You MAY NOT assume that unvoiced views are biased in any > direction, > and then declare consensus based on such an assumption. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 11:35:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et6BG-0000j0-Es; Sun, 01 Jan 2006 11:35:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et6BD-0000is-ME for ietf@megatron.ietf.org; Sun, 01 Jan 2006 11:35:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19756 for ; Sun, 1 Jan 2006 11:34:22 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et6G7-0000C9-Tz for ietf@ietf.org; Sun, 01 Jan 2006 11:40:40 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Et6B7-00023o-BY; Sun, 01 Jan 2006 11:35:29 -0500 Date: Sun, 01 Jan 2006 11:35:28 -0500 From: John C Klensin To: John Levine , ietf@ietf.org Message-ID: <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> In-Reply-To: <20060101043514.6985.qmail@xuxa.iecc.com> References: <20060101043514.6985.qmail@xuxa.iecc.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Subject: Re: bozoproofing the net, was The Value of Reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org --On Sunday, 01 January, 2006 04:35 +0000 John Levine wrote: > I hope the message here is not that we should restrict > ourselves to developing technology that is idiot-proof, since > a sufficiently determined idiot, of which there are many, will > do idiotic things with any technology that we never in a > million years would have anticipated. No. I don't believe in idiot-proof technologies. I do believe that it is not desirable to create standards that would give a gift of either technology or justification to those who would use them to fragment the network. I believe it is especially important to avoid those gifts when the people or groups involved are quite sophisticated about using technologies to maximize their short-term economic gain at the cost of global communications and interoperability. People and companies with those sorts of motivations will undoubtedly do their thing regardless of what we do. But we don't need to help them or provide them with justification via "we are just following the standard". And I still believe that we should do this work. I just believe that the work should include some real discussion, and analysis of workarounds, about how uses of the technology that are interoperability-hostile, or global-communications-hostile, can be prevented or clearly identified as inappropriate. Think of it as an explicit "interoperability considerations" section to supplement the usual "security considerations" one. >... > One favor that the SPF crowd did for us was to give the > aforementioned idiots a chance to find out what a bad idea it > is to reject mail arbitrarily from people who don't jump > through their hoops, so nobody rejects for SPF failure any > more. People who use C/R against people not on their > whitelists have found the same thing -- they all check the > folder of unconfirmed mail because they know there's lots of > real mail from people who won't hoop jump. > > If the idiots were to latch on to DKIM and start rejecting > valid mail, like they have to the past umpteen magic bullets, > why do you expect the results to be any different? I note that we have never standardized a magic bullet in the anti-spam area. I believe that to have been a good trend. To the credit of a significant fraction of the DKIM advocates, they haven't claimed it is a magic bullet, which is also a good trend. If there is agreement on what you say above (I think there probably is) and it can be documented, then some explicit warnings about that experience and its applicability would satisfy most or all of my concerns. I wouldn't expect to see merely "doing X is bad and you MUST NOT do that", but rather "X should be avoided because there is documented experience that its consequences are Y and Z". best, john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 12:15:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et6na-0006JZ-Mu; Sun, 01 Jan 2006 12:15:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et6nX-0006IN-3v for ietf@megatron.ietf.org; Sun, 01 Jan 2006 12:15:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22474 for ; Sun, 1 Jan 2006 12:13:57 -0500 (EST) Received: from tom.iecc.com ([208.31.42.38]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Et6sQ-0001CJ-1X for ietf@ietf.org; Sun, 01 Jan 2006 12:20:15 -0500 Received: (qmail 18726 invoked from network); 1 Jan 2006 17:14:59 -0000 Received: (ofmipd 127.0.0.1); 1 Jan 2006 17:14:37 -0000 Date: 1 Jan 2006 12:14:59 -0500 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> References: <20060101043514.6985.qmail@xuxa.iecc.com> <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ietf@ietf.org Subject: Re: bozoproofing the net, was The Value of Reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org > Think of it as an explicit "interoperability considerations" section to > supplement the usual "security considerations" one. That seems reasonable, so long as someone steps forward to write it. > I note that we have never standardized a magic bullet in the anti-spam > area. I believe that to have been a good trend. Perhaps this would be a good time to remind people that they can build a spam-proof walled garden today with S/MIME. R's, John _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 13:20:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et7oZ-00087X-Ei; Sun, 01 Jan 2006 13:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et7oW-00086A-W9 for ietf@megatron.ietf.org; Sun, 01 Jan 2006 13:20:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27703 for ; Sun, 1 Jan 2006 13:19:04 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et7tN-0002wI-5y for ietf@ietf.org; Sun, 01 Jan 2006 13:25:22 -0500 Received: from [192.168.0.3] (cpe-24-24-146-166.socal.res.rr.com [24.24.146.166]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k01IKBwN011193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jan 2006 10:20:21 -0800 Message-ID: <43B81D34.8030104@dcrocker.net> Date: Sun, 01 Jan 2006 10:19:32 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: John C Klensin References: <20060101043514.6985.qmail@xuxa.iecc.com> <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> In-Reply-To: <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id k01IKBwN011193 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org Subject: Re: bozoproofing the net, was The Value of Reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org John K., et al, Feliz a=F1o nuevo; Selamat tahun baru. > I do believe > that it is not desirable to create standards that would give a > gift of either technology or justification to those who would > use them to fragment the network. I believe it is especially I suspect we will not find anyone in the IETF who thinks otherwise. Cert= ainly=20 my own reaction to your statement, here, was "Yes!! Absolutely Correct!" Then I tried to consider the implications of the statement, in the curren= t=20 context, and I realized that I have no idea what pragmatic import it has. I have no idea how to apply this caveat to the DKIM work. DKIM is DKIM. As a technology it has a specific intent and its core is=20 well-defined -- and actually pretty simple -- with well-understood proper= ties.=20 The core is similar to a number of technologies that have been in use for= at=20 least 15 years. So I need to ask that you express your concern as a specific recommendati= on for=20 changes to the DKIM charter text, lest this thread be merely=20 comforting-but-irrelevant (or, worse, -distracting) to the DKIM effort. On the matter of insisting that specifications document various alerts an= d=20 caveats, again we are faced with a dilemma. After all, who could possibl= y=20 object to the task of educating potential users of a technology about its= =20 weaknesses? Yet an open-ended requirement for such warnings a) to my knowledge has no= =20 empirically demonstrated efficacy, and b) often has the real effect of=20 providing a large barrier with long delays. That is, we insist on including such discussions out of a sense of profes= sional=20 responsibility, rather than out of any knowledge that such discussions in= IETF=20 specifications have real utility for the success of those specifications. The real impact of this barrier is to delay gaining exactly the field exp= erience=20 that will demonstrate *real* efficacy and *real* problems, rather than im= agined=20 ones. (It seems to me that this underscores the problematic change in the proce= ss of=20 trying to do work in the IETF, namely that we should raise any and all ba= rriers=20 based on fear, rather than find ways to facilitate efforts so they gain=20 field-experience.) > People and companies with those sorts of motivations will > undoubtedly do their thing regardless of what we do. But we > don't need to help them or provide them with justification via > "we are just following the standard". There are legitimate technical weaknesses in any technology. It is essen= tial to=20 be aware of them and decide whether they need to be addressed with change= s to=20 the specification of that technology. However, that is quite different from attempting to engage in analysis of= the=20 psychosocial vagaries that can lead to abuse of an otherwise-legitimate=20 technology. The IETF has neither the mandate nor the community skill at conducting su= ch=20 analyses. Our efforts to perform such analyses is usually marked by an=20 amateurish FUD ogre and diffusion of constructive effort. > And I still believe that we should do this work. That's good to hear. I just believe > that the work should include some real discussion, and analysis > of workarounds, about how uses of the technology that are > interoperability-hostile, or global-communications-hostile, can Again: This sounds eminently reasonable, until I start to realize that I= do not=20 know what you mean. > If there is agreement on what you say above (I think there > probably is) and it can be documented, then some explicit > warnings about that experience and its applicability would > satisfy most or all of my concerns. =20 Again: Please translate this into a specific recommendation for charter=20 language, with appropriate modifications to the schedule. Please include= an=20 explanation for the intended benefit of the work item and the basis for=20 believing that the benefit will be realized. d/ --=20 Dave Crocker Brandenburg InternetWorking _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 14:04:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et8V8-0008Tn-SW; Sun, 01 Jan 2006 14:04:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et8V6-0008RX-NV for ietf@megatron.ietf.org; Sun, 01 Jan 2006 14:04:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01329 for ; Sun, 1 Jan 2006 14:03:04 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et8Zz-00047F-6T for ietf@ietf.org; Sun, 01 Jan 2006 14:09:22 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id A29361E8C4C; Sun, 1 Jan 2006 11:03:53 -0800 (PST) To: Bernard Aboba References: From: Eric Rescorla Date: Sun, 01 Jan 2006 11:03:53 -0800 In-Reply-To: (Bernard Aboba's message of "Sat, 31 Dec 2005 18:22:08 -0800 (PST)") Message-ID: <868xtzahye.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf@ietf.org Subject: Re: IETF Last Call: draft-salowey-tls-ticket-06.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Bernard Aboba writes: >> In the extreme case (client gets different server every time, and none >> of the servers can understand tickets generated by other servers), it >> will degrade to normal TLS (full handshake done every time). > >>From what I can see, the Ticket structure does not uniquely identify the > ticket type or ticket version, so that there is no easy way for the server > to determine what type of ticket has been submitted to it, or whether the > client is using the recommended format or not. The server checks the mac > in the last 20 octets, and if this is valid, then it decrypts the > encrypted_state. However, if the client were using the same mac, but a > different ticket format, the mac could check out, but the StatePlaintext > would not match. A Ticket Type/Version field would make it clear to the > server whether it is handling a Ticket of known type. I'm not sure I understand this, Bernard. The client doesn't need to know anything about the ticket format or get to decide anything about the mac. It's just the server talking to itself. -Ekr _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 15:48:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtA7r-0004vj-U3; Sun, 01 Jan 2006 15:48:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtA7p-0004ud-9g for ietf@megatron.ietf.org; Sun, 01 Jan 2006 15:48:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11864 for ; Sun, 1 Jan 2006 15:47:08 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtACi-0007Yh-Ot for ietf@ietf.org; Sun, 01 Jan 2006 15:53:28 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k01Km5FW025586; Sun, 1 Jan 2006 12:48:05 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k01Km02u025580; Sun, 1 Jan 2006 12:48:05 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 1 Jan 2006 12:48:00 -0800 (PST) From: "william(at)elan.net" To: Yaakov Stein In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDC48@exrad2.ad.rad.co.il> Message-ID: References: <27A0F290348F8E45AEF79889DDE65A5205DCDC48@exrad2.ad.rad.co.il> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Frank Ellermann , ietf@ietf.org Subject: RE: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org On Sun, 1 Jan 2006, Yaakov Stein wrote: > 2: Folks who can't read MS Word documents are also irrelevant. > It's the "most 'standard' document exchange language on the > Internet". (Actually all its versions are from the people > who invented the Internet, please don't forget to submit an > IPR note). > > [YJS] I don't really believe that there are many people who > can not read MS Word documents. And I believe that the > number of people who can read neither Word nor PDF > is infinitesimally small. It does not matter how many people can read MSWord. The only supported formats should be the ones where you know what the format is (and not the ones that depend on particular program). Now PDF does qualify but it is basicly an extended version of PostScript. Since IETF already accepts postscript, the question should be is there a need for features in PDF that are not in standard postscript. If there is then we can talk about it. BTW - PDF also still rather "fluid" format with multiple versions and not always clear if PDF you create could be read by all readers in the same way you intended. So if PDF is as format, then exact version must be specified as well. -- William Leibzon Elan Networks william@elan.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 16:34:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtAq7-0007KD-G8; Sun, 01 Jan 2006 16:34:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtAq5-0007K5-MS for ietf@megatron.ietf.org; Sun, 01 Jan 2006 16:34:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15471 for ; Sun, 1 Jan 2006 16:32:52 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtAuy-0000Su-Ik for ietf@ietf.org; Sun, 01 Jan 2006 16:39:09 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1EtApr-0002MS-Mx; Sun, 01 Jan 2006 16:33:51 -0500 Date: Sun, 01 Jan 2006 16:33:51 -0500 From: John C Klensin To: "william(at)elan.net" Message-ID: <343DF1B286FA08EA2DF3D261@p3.JCK.COM> In-Reply-To: References: <27A0F290348F8E45AEF79889DDE65A5205DCDC48@exrad2.ad.ra d.co.il> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: RE: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org --On Sunday, 01 January, 2006 12:48 -0800 "william(at)elan.net" wrote: >... > BTW - PDF also still rather "fluid" format with multiple > versions and not always clear if PDF you create could be read > by all readers in the same way you intended. So if PDF is as > format, then exact version must be specified as well. I've still got some misgivings about PDF because one of my requirements is to be able to extract things from documents and mark them up. That requirement applies to RFCs but much more strongly to I-Ds, where excepting as part of discussions of the drafts is extremely important. And I've discovered that marking up PDF documents, and sometimes extracting things from them, seems to often require very expensive tools, not just a freeware reader. Even with (most of?) those tools, if the PDF essentially consists of images of the relevant pages, rather than page description information plus the text, reliably extracting pieces of text is reasonably hopeless. However... This is just for my education, since I haven't followed PDF's evolution closely enough to know the answer. Is the description of PDF in RFC 3778 sufficiently specific wrt versions and feature sets that a reference to that document plus some test/verification tools would be sufficient to define a version for IETF use? Is that version adequately supported by stable, readily-available and inexpensive tools on multiple platforms? Or would we need something else in terms of either definition or reading/extracting tools? john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 18:34:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtCj2-0000aN-JF; Sun, 01 Jan 2006 18:34:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtCj0-0000ZF-1E for ietf@megatron.ietf.org; Sun, 01 Jan 2006 18:34:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23641 for ; Sun, 1 Jan 2006 18:33:40 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtCnv-00039L-UQ for ietf@ietf.org; Sun, 01 Jan 2006 18:40:02 -0500 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1EtCiw-000CHc-EA; Sun, 01 Jan 2006 18:34:50 -0500 Received: by internaut.com (Postfix, from userid 1000) id 4393C38AB8; Sun, 1 Jan 2006 15:34:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 32C1638AB3; Sun, 1 Jan 2006 15:34:49 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Sun, 1 Jan 2006 15:34:49 -0800 (PST) From: Bernard Aboba To: Eric Rescorla In-Reply-To: <868xtzahye.fsf@raman.networkresonance.com> Message-ID: References: <868xtzahye.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ietf@ietf.org Subject: Re: IETF Last Call: draft-salowey-tls-ticket-06.txt X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org > >>From what I can see, the Ticket structure does not uniquely identify the > > ticket type or ticket version, so that there is no easy way for the server > > to determine what type of ticket has been submitted to it, or whether the > > client is using the recommended format or not. The server checks the mac > > in the last 20 octets, and if this is valid, then it decrypts the > > encrypted_state. However, if the client were using the same mac, but a > > different ticket format, the mac could check out, but the StatePlaintext > > would not match. A Ticket Type/Version field would make it clear to the > > server whether it is handling a Ticket of known type. > > I'm not sure I understand this, Bernard. The client doesn't need > to know anything about the ticket format or get to decide > anything about the mac. It's just the server talking to itself. The client does not need to crack the ticket. However, it is possible for the client to submit a ticket to a server that doesn't understand it. For example, wireless LAN networks can span the globe, and require many backend servers, all of which may not be located at the same location, or run the same version of the same software. However, clients may only cache tickets by SSID. If a client obtains a ticket from Server A, running software version X, and then sends it to server B, running software version Y, how is Server B supposed to figure out that it is the wrong version? _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 18:49:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtCx5-0001Pe-Dq; Sun, 01 Jan 2006 18:49:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtCx3-0001PZ-Gx for ietf@megatron.ietf.org; Sun, 01 Jan 2006 18:49:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24486 for ; Sun, 1 Jan 2006 18:48:11 -0500 (EST) Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtD21-0003ST-Bg for ietf@ietf.org; Sun, 01 Jan 2006 18:54:33 -0500 Received: from [10.10.10.129] (c-24-2-41-71.hsd1.ca.comcast.net [24.2.41.71]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k01Nn9Gt004856 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 1 Jan 2006 15:49:09 -0800 In-Reply-To: <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> References: <20060101043514.6985.qmail@xuxa.iecc.com> <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Sun, 1 Jan 2006 15:49:31 -0800 To: John C Klensin X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: bozoproofing the net, was The Value of Reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org On Jan 1, 2006, at 8:35 AM, John C Klensin wrote: > --On Sunday, 01 January, 2006 04:35 +0000 John Levine > wrote: > >> I hope the message here is not that we should restrict ourselves >> to developing technology that is idiot-proof, since a sufficiently >> determined idiot, of which there are many, will do idiotic things >> with any technology that we never in a million years would have >> anticipated. > > No. I don't believe in idiot-proof technologies. I do believe > that it is not desirable to create standards that would give a gift > of either technology or justification to those who would use them > to fragment the network. I believe it is especially important to > avoid those gifts when the people or groups involved are quite > sophisticated about using technologies to maximize their short- > term economic gain at the cost of global communications and > interoperability. The risks related to interoperability will more likely result from assuming authorization authenticates the source. This authorization strategy may benefit larger domains, but will be corrosive to goals of interoperability and integrity. To avoid the misapplication of this mechanism, there are suitable alternatives to authorization for the DKIM effort. DKIM offers a significant value without authorization to establish expectations. Not endorsing authorization schemes also discourages possible burden-shifting of the short- comings of DKIM. Hopefully, not allowing this tactic will lead to a better, safer, and far more fair solutions. -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 21:22:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtFL0-0006Vs-3M; Sun, 01 Jan 2006 21:22:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtFKx-0006Sm-5f for ietf@megatron.ietf.org; Sun, 01 Jan 2006 21:22:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05677 for ; Sun, 1 Jan 2006 21:21:02 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtFPu-00077e-LJ for ietf@ietf.org; Sun, 01 Jan 2006 21:27:25 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1EtFKd-0002dg-Ce; Sun, 01 Jan 2006 21:21:55 -0500 Date: Sun, 01 Jan 2006 21:21:54 -0500 From: John C Klensin To: Douglas Otis Message-ID: <416F6B6F46586EDBC9410701@p3.JCK.COM> In-Reply-To: References: <20060101043514.6985.qmail@xuxa.iecc.com> <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: bozoproofing the net, was The Value of Reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org --On Sunday, 01 January, 2006 15:49 -0800 Douglas Otis wrote: >... > The risks related to interoperability will more likely result > from assuming authorization authenticates the source. This > authorization strategy may benefit larger domains, but will > be corrosive to goals of interoperability and integrity. To > avoid the misapplication of this mechanism, there are > suitable alternatives to authorization for the DKIM effort. > DKIM offers a significant value without authorization to > establish expectations. Not endorsing authorization schemes > also discourages possible burden-shifting of the short- > comings of DKIM. Hopefully, not allowing this tactic will > lead to a better, safer, and far more fair solutions. Indeed. And, along the lines of my response to John, and to Dave's request to be specific, that sort of analysis and description is _precisely_ what I believe should be required to be written into text, get WG rough consensus on its appropriateness and accuracy, and then make its way into the WG's deliverables. If agreement on such comments can be reached, I believe that such a requirement is reasonable and not particularly burdensome. If such agreement cannot be reached, then I think DKIM has much more serious problems about applicability and the definition of the problems being solved than whether or not this is required. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 22:00:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtFwQ-0008FZ-Jx; Sun, 01 Jan 2006 22:00:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtFwL-0008EJ-18 for ietf@megatron.ietf.org; Sun, 01 Jan 2006 22:00:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08128 for ; Sun, 1 Jan 2006 21:59:39 -0500 (EST) Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtG1J-0007zi-T0 for ietf@ietf.org; Sun, 01 Jan 2006 22:06:02 -0500 Received: from [10.10.10.129] (c-24-2-41-71.hsd1.ca.comcast.net [24.2.41.71]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0230fFc007815 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 1 Jan 2006 19:00:41 -0800 In-Reply-To: <43B77740.32CE@xyzzy.claranet.de> References: <43A8893F.9010700@dcrocker.net> <43A8C2EC.4060401@dcrocker.net> <0b0d55f43c319b517cad80dd1d5d76d0@guppylake.com> <1135458563.17219.79.camel@bash.adsl-64-142-13-68> <983DD241-F8D4-4331-88BF-481A796333D0@mail-abuse.org> <43B1E85D.4F18@xyzzy.claranet.de> <22FDDD3D-C3A4-4099-8583-68EAF16BBA67@mail-abuse.org> <43B4F156.236C@xyzzy.claranet.de> <1135997824.17219.230.camel@bash.adsl-64-142-13-68> <43B77740.32CE@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9311C223-E5F8-49C2-9786-5868DC13A528@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Date: Sun, 1 Jan 2006 19:01:03 -0800 To: Frank Ellermann X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: SIQ, SPF, BATV, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org On Dec 31, 2005, at 10:31 PM, Frank Ellermann wrote: > Douglas Otis wrote: > >> The BATV draft seems to be a good start. Perhaps it can be >> further simplified. Could this satisfy both camps? > > Which both camps, SES vs. BATV, STD 10 + SPF vs. STD 3 + 2821, or > something else ? For the former I'm lost, I read the now expired > BATV draft, and for SES all I know is that they can optionally use > the SPF "exists"-mechanism somehow resulting in 1123 5.3.6(a) > compatibility. I wasn't very interested because IIRC it worked > only for domains with their own name server (?) With authorization misuse, the desire would be to avoid an authorization approach. Finding a syntax compatible with the scheme defined in BATV and that of SES was simply to find consensus for the syntax to move forward. The "exists" scheme does not seem to make any sense either, but BATV does. >> BATV does not depend upon any third-party adoption. > > You can't use "your" Return-Path on any route you like if the > returned messages are rejected by BATV. That's the same issue as > for SPF, only more restrictive: SPF allows to aggregate unrelated > sending routes per domain. BATV works for one and only one MON > (all its MSAs plus the corresponding MRN). And I don't see how a > "bounces-to" fan could accept this. Just as domains are aggregated in SPF records, BATV signatures (with mutual arrangements), can be applied to allow a diversity of SMTP senders. Receiving domains can also make exceptions for individuals that wish to "opt-out". Coverage does not need to be 100% to be an effective deterrent for DSN or auto-response exploits. Alternatively, SPF would need a "per-user" lookup. Yet SPF still allows any miscreant to exploit open-ended records needed for the same reasons someone would want to opt-out, in addition to the alias address issues that will not affect BATV. Depending upon use of call- back, a message without a valid BATV tag would be more likely delivered with a comparable loss of DSNs to that of SPF with today's tactics. BATV allows a per-user opt-out strategy without any "per- user" lookup at the receiving MTA. The effort is completely contained within the domain implementing the BATV strategy. >> As part of the BATV draft, when the message is delivered, removing >> the tag or obfuscating the BATV section in that is normally >> prefixed as "Return-Path:" would also be a helpful practice. > > IMHO that would break vacation-like 3834-applications, their auto- > responses would be rejected by the originator's BATV-MRN. Those applications would need to be ahead of the obfuscation or sent to the From instead. The message has been delivered, and having a means to reduce the potential for replay would be helpful. > It's not that I don't like BATV, but it can't substitute SPF FAIL. > For those who can do both they should certainly try it. For those domains in commerce, BATV does not risk as many delivery issues, whereas SPF will when delivering to those using their Alma Mater email address, for example. Nevertheless, BATV can effectively deter the "side-stepping" exploit which is where spam is really abated. > You're not talking about creating BATV local parts in the MUA, or > are you ? That would be another FUSSP trap. IIRC the BATV idea is > to replace the local-part of the MAIL FROM at the MSAs (or mail- > outs behind an MSA), and undo that modification later for the local > part of the RCPT TO at the MXs (or MDA) in the case of "returned" > mails, invisible from the sending MUA's POV. Agreed, BATV would not be implemented at the MUA. >> On the contrary, BATV eliminates the forged return-path as a >> delivery strategy. > > Sorry, I fail to see how, not without "call-back-verification" at > the side of the primary spam victims. Or an equivalent pre-abuse- > address-quality-control-test by the spammer. The latter strategy > worked for SPF FAIL because professional spammers use SA for their > QoS-tests (1). Without knowing SA I doubt that it supports "call- > back-verification", that's rather expensive, or isn't it ? BATV would depend upon a different paradigm. Rather than receivers checking for closed-ended records that _may_ have been published by senders to curtail forged return-paths, the forged return-path is curtailed without such records being exchanged, simply because the receiver implemented BATV. The overall overhead is less, the effect more complete, and the impact upon email practices less. > Well, the "SPF-opposition" is apparently determined to let SMTP die > while preserving 1123-5.3.6(a) "251"-forwarding, and a dead SMTP > won't feel the pain. > > Most SPF FAIL policies are a "die, spammer, die" voice against 1123 > 5.3.6(a). Excluding a few who publish -all without RTFM. Avoiding the DSN and auto-response exploit curtails abuse, so perhaps better defining the problem would help. SPF records can be published by anyone, and there remains many records open to exploitation. >> Rather than compiling lists of addresses for outbound servers for >> a set of domains by issuing dozens of DNS lookups, > > NAK, still two lookups in my case before you have either PASS or > FAIL. In theory one query would do, but I won't bother my ISP with > this minor improvement before SPF is at least a PS. SPF requires as many as 111 DNS lookups. As these are published by anyone and with broad distribution, the number of records is unknown. With BATV, the number of DNS lookups is zero. >>> 1123 5.3.6(a) does not work as expected in its own post-821 >>> "bounces-to" world. > >> This is a problem only when a third-party attempts to verify the >> return-path. > > What they actually do is use it as specified for their crappy > "accept-then-bounce" setup. That was "state of the art" until 2001 > as documented in 2821. Won't make it into any 2821bis. It would be difficult to imagine a store and forward scheme where an exploit does not remain possible. This expects the recipient to fully vet all messages, perhaps even achieving delivery before accepting the message. There are many cases where better strategies should be implemented. There is a cost associated with this vetting however, such as holding sessions open. Being able to ensure forged return-paths are not effective when returned would better realize the efficiencies of a store and forward system. >> Prevent the bounce delivery strategy from being successful, and >> soon it will not be used. BATV prevents this strategy from being >> successful without changing email practices. > > IMO it's in most cases no "delivery strategy". 2821-DDoS and Joe > Jobs excluded I think the spammers just abuse any address surviving > "call-back-verification". They really try to reach their primary > RCPT TO victims, not the secondary MAIL FROM. There are those that do better vetting of the remote IP addresses, where this delivery strategy side-steps this vetting. > And BATV does nothing for the existing primary victims, it only > blocks most "user not found" + "user over quota" bounces at the MX > of the secondary victim. BATV depends upon the primary vetting of the source identifiers to abate abuse. As a result, BATV can be more effective at preventing abuse, but just with a different paradigm. SPF only changes the tactics without long term benefits. There is also a downside where SPF records will be used to unfairly accrue reputations. At that point, email would remain viable for mega-domains or those domains that run their own servers. > BATV has none of the SPF FAIL advantages for primary victims, it > only blocks some of the backscatter. SPF can be published by anyone. SPF does not afford any real protection without the application of reputation. When SPF authorization is used in conjunction with reputation, disaster. > BATV does nothing wrt obscure C/R systems. Behind an SPF PASS C/R > systems might actually work as expected for the first time. Behind > an SPF PASS the complete SMTP up to 3834 works again. > > BATV doesn't have this feature. BATV catches 100% of all bogus > bounces, and that's a feature you won't get with SPF FAIL. For > "all" read "the obvious bounces" as discussed above, not all the > other backscatter (vacation + C/R + AV-"feedback" + ...) The list of where BATV is expected can be modified as needed, when a legitimate domain has been exploited. Those of individuals on vacation bouncing with the initial RCPT TO address, then any problem will be evident immediately when the auto-responses are refused. This would be an indication that this "feature" is being exploited. With BATV, this blunder is self healing. -Doug _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 22:21:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtGG3-00011G-Qg; Sun, 01 Jan 2006 22:21:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtGFm-0000x1-4s for ietf@megatron.ietf.org; Sun, 01 Jan 2006 22:20:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09043 for ; Sun, 1 Jan 2006 22:19:45 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtGKk-0008Q5-RN for ietf@ietf.org; Sun, 01 Jan 2006 22:26:08 -0500 Received: from [192.168.0.3] (cpe-24-24-146-166.socal.res.rr.com [24.24.146.166]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k023LOcP024937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jan 2006 19:21:25 -0800 Message-ID: <43B89C0B.1090105@dcrocker.net> Date: Sun, 01 Jan 2006 19:20:43 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: John C Klensin References: <20060101043514.6985.qmail@xuxa.iecc.com> <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> <416F6B6F46586EDBC9410701@p3.JCK.COM> In-Reply-To: <416F6B6F46586EDBC9410701@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: bozoproofing the net, was The Value of Reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org > If such agreement cannot be reached, then I think > DKIM has much more serious problems about applicability and the > definition of the problems being solved than whether or not this > is required. John, Unfortunately what you appear to be saying is that you are certain of serious problems, and are happy to assert them as a barrier to progress -- after all, you want to insist that a requirement for dealing with your fears be included as a chartered deliverable -- but you do not feel compelled to provide a solid basis for these fears. Before imposing requirements on an IETF effort, one should make a pragmatic case for it. At base, the case you have so far made is that the reasonable mechanism of DKIM might get mis-used, just as any other reasonable mechanism might be. You keep implying that it is somehow a mysterious and big deal to have a voluntary, validated identity associated with message transit. It isn't. And the real fear that we all should have is that it is being characterized as a bigger deal than it is, including that its supposed "dangers" are vast and unknown. Let's start with something simple and useful, John: Are there technical deficiencies in the current DKIM specifications? If there aren't, then please cite previous IETF work that requires worrying about unknown, future abuses and imposes those fears as a barrier to chartering. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Sun Jan 01 22:53:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtGlJ-0000Ap-PN; Sun, 01 Jan 2006 22:53:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtGlD-000060-Bf for ietf@megatron.ietf.org; Sun, 01 Jan 2006 22:53:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10804 for ; Sun, 1 Jan 2006 22:52:13 -0500 (EST) Received: from tom.iecc.com ([208.31.42.38]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtGqD-0000f8-93 for ietf@ietf.org; Sun, 01 Jan 2006 22:58:37 -0500 Received: (qmail 5868 invoked from network); 2 Jan 2006 03:53:16 -0000 Received: (ofmipd 127.0.0.1); 2 Jan 2006 03:52:54 -0000 Date: 1 Jan 2006 22:53:15 -0500 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: <416F6B6F46586EDBC9410701@p3.JCK.COM> References: <20060101043514.6985.qmail@xuxa.iecc.com> <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> <416F6B6F46586EDBC9410701@p3.JCK.COM> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ietf@ietf.org Subject: Re: bozoproofing the net, was The Value of Reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org > Indeed. And, along the lines of my response to John, and to > Dave's request to be specific, that sort of analysis and > description is _precisely_ what I believe should be required to > be written into text, ... The more I think about this, the less sense it makes. DKIM is not the first misusable security technology to come along, nor will it be the last. What makes it so uniquely dangerous that it needs special warning labels? Consider HTTP over SSL. It has exactly the same balkanization problem today that you're concerned about. Browsers are shipped with a fairly random list of signing certs that have more to do with history and PR budgets than with an objective standard of merit, and pages from any https server that hasn't bought a signature from someone in the browser's list provoke a scary warning message. Yet I see no language in RFC 2818 or in sections 2.3 and 2.4 of RFC 2459 (user and administrator expectations) warning about the problem of balkanization due to arbitrary signer lists. Or consider S/MIME. S/MIME applications have a cert list similar to the one in a web browser, so they also have the problem of dividing the world into haves who can afford a cert with a signature from someone in the list and have-nots who can't. I haven't read every word of every S/MIME RFC (there sure are a lot of them), but if there's any warnings about balkanization, they're very well hidden. Or how about DNSSEC? As the problems of phishing and malware get worse, and ICANN and IANA start putting signatures into the root zone, people will inevitably come up with the bright idea that names in signed zones are "secure". Even better, in the absence of signatures all the way to the top, people will start making lists of the islands of security that they like to limit which signed zones they accept. I would think that warnings about this would have belonged in RFC 4033. I really need clarification of why DKIM RFCs need to tell people about the dangers of balkanization, even though HTTPS, S/MIME, and DNSSEC don't. Since we will certainly be seeing more anti-spam and anti-phishing proposals, what would be really useful would be a metric to decide when a future proposal is more dangerous like DKIM and requires warning language, or is less dangerous like the other three and doesn't. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I dropped the toothpaste", said Tom, crestfallenly. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 00:51:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtIbS-0006FZ-D3; Mon, 02 Jan 2006 00:51:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtIbP-0006CG-MK for ietf@megatron.ietf.org; Mon, 02 Jan 2006 00:51:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18994 for ; Mon, 2 Jan 2006 00:50:13 -0500 (EST) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtIgP-0003ZY-UD for ietf@ietf.org; Mon, 02 Jan 2006 00:56:38 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EtIbM-0003E0-6n for ietf@ietf.org; Mon, 02 Jan 2006 06:51:24 +0100 Received: from pd9fba902.dip0.t-ipconnect.de ([217.251.169.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Jan 2006 06:51:24 +0100 Received: from nobody by pd9fba902.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Jan 2006 06:51:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Frank Ellermann Date: Mon, 02 Jan 2006 06:41:58 +0100 Organization: Lines: 101 Message-ID: <43B8BD26.4615@xyzzy.claranet.de> References: <43A8893F.9010700@dcrocker.net> <43A8C2EC.4060401@dcrocker.net> <0b0d55f43c319b517cad80dd1d5d76d0@guppylake.com> <1135458563.17219.79.camel@bash.adsl-64-142-13-68> <983DD241-F8D4-4331-88BF-481A796333D0@mail-abuse.org> <43B1E85D.4F18@xyzzy.claranet.de> <22FDDD3D-C3A4-4099-8583-68EAF16BBA67@mail-abuse.org> <43B4F156.236C@xyzzy.claranet.de> <1135997824.17219.230.camel@bash.adsl-64-142-13-68> <43B77740.32CE@xyzzy.claranet.de> <9311C223-E5F8-49C2-9786-5868DC13A528@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba902.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Subject: Re: SIQ, SPF, BATV, etc. X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Douglas Otis wrote: > The "exists" scheme does not seem to make any sense either, AFAIK it's a way to check if mail claiming to be from ses-x@y was originally sent from x@y - if that's correct nothing is wrong with the idea so far, domain y only needs a name server returning 127.0.0.2 for ses-x.y and the "exists"-mechanism. SPF macros offer %{l} for the local part and similar tricks. As long as you stay within the limits listed in RFC 3696 you can do whatever you like. The SPF spec. mentions potential traps and pitfalls, 63, 255, 253, other magic numbers. Stick to VCHAR plus space minus dot in derived domain labels, %{l} does not yet come with a "ready for IMA / IEE" icon... :-) > BATV signatures (with mutual arrangements), can be applied > to allow a diversity of SMTP senders. The arrangement could be that user B submits mail at MSA a with MAIL FROM B@b. MSA a allows this and implements BATV resulting in MAIL FROM batv-B@b. Later the MX of b would accept a bounce to batv-B@b but not to B@b. Yes, that could work. It's beyond me why user B doesn't simply use his MAIL FROM a@A while sending via MSA a, but that wasn't the question... ;-) The hardcore "bounces-to" fans would still hate it more than SPF: With SPF they wouldn't need much cooperation from MON a to publish their MON a route in addition to their preferred MRN b return path. With BATV MON a would have to play along and encode b@B -> batv-B@b precisely as expected by MRN b. The "bounces-to" fans want to be free to use return-paths as it pleases them, without discussing this with their MON of the day, or with the MRN hit by the bounces. > Receiving domains can also make exceptions for individuals > that wish to "opt-out". Coverage does not need to be 100% > to be an effective deterrent for DSN or auto-response > exploits. That concept has the nickname "forward-master-plan" in the SPF community, it's the most simple solution to bypass SPF checks on a per user base behind traditional 1123 5.3.6(a) forwarding. > Alternatively, SPF would need a "per-user" lookup. See above for %{l}. Not nice for DNS caches, but otherwise it is possible. For premium accounts you can also offer per user policies ("premium" support costs). > SPF still allows any miscreant to exploit open-ended records Not really. You can't get a PASS claiming to send MAIL FROM me without being a claranet.de customer, and fixing that last hole is trivial, they could just implement 2476bis 6.1. Of course a spammer will find tons of policies where he can get a NEUTRAL result for forged mails. But by definition NEUTRAL is the same as NONE (no policy), and IIRC we used MUSTard for this concept. > BATV does not risk as many delivery issues, whereas SPF will > when delivering to those using their Alma Mater email > address, for example. That's no argument, nobody needs to use his Alma Mater address in the reverse path while in reality using an unrelated MSA xy. If you're allowed to use MSA xy you will also have an address related to xy, say user@xy, and that could forward all error messages via Alma Mater to your real mailbox of the day. The idea to analyze problems between xy and z by introducing a 3rd party Alma Mater as "bounces to" is obscure: More potential points of failure. Besides Alma Mater could offer its own MSA, why use MSA xy if you want replies and bounces at Alma Mater ? Now folks are free to be as stupid as they wish, and in theory Alma Mater can support this by just not publishing FAIL. FAIL is for those who desperately need it, not for folks celebrating their first university address for the rest of their live. > With BATV, the number of DNS lookups is zero. Yes, and the number of rejected forged MAIL FROMs at the primary victim based on BATV is also zero, you get what you pay for, from the primary victim's POV nothing... ;-) > Being able to ensure forged return-paths are not effective > when returned would better realize the efficiencies of a > store and forward system. Okay, SPF PASS offers only "it won't hit innocent bystanders", not too shabby for my tastes. With SPF FAIL you also get "it never reaches my existing users", together that's as powerful as it can get before DATA (BDAT / BURL / whatever). Well, let's agree to disagree, I guess we finished another full circle, and for the next round we'd need a fresh BATV draft. Bye, Frank _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 01:23:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtJ6h-00048q-En; Mon, 02 Jan 2006 01:23:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtJ6f-00046X-A0 for ietf@megatron.ietf.org; Mon, 02 Jan 2006 01:23:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20975 for ; Mon, 2 Jan 2006 01:22:30 -0500 (EST) Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtJBZ-0004Lc-Nz for ietf@ietf.org; Mon, 02 Jan 2006 01:28:55 -0500 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k026JLYL016517 for ; Mon, 2 Jan 2006 08:19:22 +0200 (IST) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k026JLLx016514; Mon, 2 Jan 2006 08:19:21 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jan 2006 08:23:02 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5205DCDD9A@exrad2.ad.rad.co.il> Thread-Topic: Consensus based on reading tea leaves (was: Re: Alternative formatsfor IDs) Thread-Index: AcYO4tPkuOQoNMLmSkSBXUMRLY9JoQAgSvXQ From: "Yaakov Stein" To: "Spencer Dawkins" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Consensus based on reading tea leaves (was: Re: Alternative formatsfor IDs) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org =20 > I can't imagine that ever encouraging the IESG to decide=20 > that they know what IETF consensus "really" is,=20 > while disregarding public comment,=20 > is ever going to be a good thing to do.=20 How did you read that into what we said? We never said that IETF consensus should not be gauged. Quite the contrary, we said that we don't want four emails=20 on the IETF list to be used as a proxy for consensus. We wrote a draft precisely in order to get the same treatment=20 that other drafts get. If there is no WG that deals with the subject, then perhaps the right way to check the will of the IETF community is to ask for a hum at one of the plenary sessions. We believe that in such a broad forum there will be strong support for leaving the dark ages of ASCII. Y(J)S _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 02:16:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtJvz-0004W3-RQ; Mon, 02 Jan 2006 02:16:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtJvv-0004UG-4W for ietf@megatron.ietf.org; Mon, 02 Jan 2006 02:16:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25335 for ; Mon, 2 Jan 2006 02:15:30 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtK0v-0005p4-E4 for ietf@ietf.org; Mon, 02 Jan 2006 02:21:54 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A3396898C6; Mon, 2 Jan 2006 09:16:26 +0200 (EET) Message-ID: <43B8D36A.10703@piuha.net> Date: Mon, 02 Jan 2006 09:16:58 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin References: <27A0F290348F8E45AEF79889DDE65A5205DCDC48@exrad2.ad.ra d.co.il> <343DF1B286FA08EA2DF3D261@p3.JCK.COM> In-Reply-To: <343DF1B286FA08EA2DF3D261@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: "william\(at\)elan.net" , ietf@ietf.org Subject: Re: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org John, >I've still got some misgivings about PDF because one of my >requirements is to be able to extract things from documents and >mark them up. > Good question. I do think that we need the ability to extract material for various purposes, including o Comparisons (rfcdiff etc) o Bis-construction o Verification and statistics tools o Alternative representations (even those offered outside the IETF) Now, I confess that I do not know much about how easy this is from PDF. I suspect its hard... But one way to look at this problem is to say that for you to submit .pdf we need to have your source available as well. And if the source format is standardized, then various operations are possible. --Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 02:32:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKAv-0004Da-78; Mon, 02 Jan 2006 02:32:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKAr-00049E-BL for ietf@megatron.ietf.org; Mon, 02 Jan 2006 02:32:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27428 for ; Mon, 2 Jan 2006 02:30:57 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtKFo-0006TI-5g for ietf@ietf.org; Mon, 02 Jan 2006 02:37:21 -0500 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k027Vu3F020173 for ; Mon, 2 Jan 2006 00:31:56 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ISG00C01FFJFR00@mail-amer.sun.com> (original mail from tbray@textuality.com) for ietf@ietf.org; Mon, 02 Jan 2006 00:31:55 -0700 (MST) Received: from [192.168.1.41] ([204.174.35.77]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ISG001NJFL716A0@mail-amer.sun.com>; Mon, 02 Jan 2006 00:31:55 -0700 (MST) Date: Sun, 01 Jan 2006 23:32:11 -0800 From: Tim Bray In-reply-to: <43B2AC49.7040708@gmx.de> To: Julian Reschke Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <001501c60670$36f0eaa0$0601a8c0@pc6> <001f01c607ad$08fa5d00$0601a8c0@pc6> <01LWWGAWH28600009C@mauve.mrochek.com> <015101c608b7$8d453c00$0601a8c0@pc6> <01LWY2922HSM00009C@mauve.mrochek.com> <002d01c60b8f$131c79e0$0601a8c0@pc6> <6A0F1BA75E94FF440F514D00@svartdal.hjemme.alvestrand.no> <020301c60bb6$ed87ef20$0601a8c0@pc6> <43B2AC49.7040708@gmx.de> X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7BIT Cc: ietf Subject: Re: Troubles with UTF-8 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org On Dec 28, 2005, at 7:16 AM, Julian Reschke wrote: >> The 'illegal syntax' is not yet an RFC but is in draft-ietf- >> netconf-ssh-05.txt >> which says >> "As the previous example illustrates, a special character >> sequence, >> ]]>]]>, MUST be sent by both the client and the server after >> each XML > > Why don't you use an illegal *character* instead, such as Formfeed? > That's certainly easier to parse... Or NULL, U+0000, which is illegal in XML. -Tim _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 02:40:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKJD-00086D-1p; Mon, 02 Jan 2006 02:40:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKJ9-000847-Tp for ietf@megatron.ietf.org; Mon, 02 Jan 2006 02:40:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28090 for ; Mon, 2 Jan 2006 02:39:31 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtKOB-0006jU-4S for ietf@ietf.org; Mon, 02 Jan 2006 02:45:56 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 79C8D259736; Mon, 2 Jan 2006 08:39:38 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05478-09; Mon, 2 Jan 2006 08:39:34 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA1F9259732; Mon, 2 Jan 2006 08:39:34 +0100 (CET) Date: Mon, 02 Jan 2006 08:44:05 +0100 From: Harald Tveit Alvestrand To: John R Levine , John C Klensin Message-ID: <6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no> In-Reply-To: References: <20060101043514.6985.qmail@xuxa.iecc.com> <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> <416F6B6F46586EDBC9410701@p3.JCK.COM> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org Subject: Re: bozoproofing the net, was The Value of Reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org --On s=F8ndag, januar 01, 2006 22:53:15 -0500 John R Levine = =20 wrote: > Or consider S/MIME. S/MIME applications have a cert list similar to the > one in a web browser, so they also have the problem of dividing the world > into haves who can afford a cert with a signature from someone in the = list > and have-nots who can't. I haven't read every word of every S/MIME RFC > (there sure are a lot of them), but if there's any warnings about > balkanization, they're very well hidden. I think you are making John's point....... There's a pair of facts (or what passes for facts) here: - the IETF community has rejected the idea of mandating a single root for=20 "just about anything" (except for the DNS, the IANA and the address spaces) - Multiple roots lead to balkanization (of lesser or greater severity) If these statements are both true, they might explain the lack of success=20 of S/MIME as a tool for general (rather than balkanized) communication. As far as I remember, neither of these statements have come out as=20 consensus statements in any IETF document - perhaps because "everyone"=20 knows that raising the issue will cause an endless debate and no consensus=20 document? Might be time to challenge that assumption.... Harald _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 02:40:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKJI-00088H-UG; Mon, 02 Jan 2006 02:40:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKJC-000868-5Q for ietf@megatron.ietf.org; Mon, 02 Jan 2006 02:40:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28096 for ; Mon, 2 Jan 2006 02:39:33 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtKO1-0006jP-9i for ietf@ietf.org; Mon, 02 Jan 2006 02:45:58 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k027eT3F007120 for ; Mon, 2 Jan 2006 00:40:31 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ISG00001AXRF400@mail-amer.sun.com> (original mail from tbray@textuality.com) for ietf@ietf.org; Mon, 02 Jan 2006 00:40:29 -0700 (MST) Received: from [192.168.1.41] ([204.174.35.77]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ISG008UCFZFZD50@mail-amer.sun.com>; Mon, 02 Jan 2006 00:40:28 -0700 (MST) Date: Sun, 01 Jan 2006 23:40:43 -0800 From: Tim Bray In-reply-to: <43B28DB5.7080501@necom830.hpcl.titech.ac.jp> To: Masataka Ohta Message-id: <519D27B9-4723-487E-8E15-DEB326600546@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <001501c60670$36f0eaa0$0601a8c0@pc6> <001f01c607ad$08fa5d00$0601a8c0@pc6> <01LWWGAWH28600009C@mauve.mrochek.com> <015101c608b7$8d453c00$0601a8c0@pc6> <01LWY2922HSM00009C@mauve.mrochek.com> <002d01c60b8f$131c79e0$0601a8c0@pc6> <43B28DB5.7080501@necom830.hpcl.titech.ac.jp> X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT Cc: Ned Freed , ietf Subject: Re: Troubles with UTF-8 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org On Dec 28, 2005, at 5:05 AM, Masataka Ohta wrote: > That problem is that Unicode is stateful with complex and > indefinitely long term states Has this ever caused a real problem to a real programmer in real life? I have written a whole bunch of mission-critical code that reads and generates UTF-8, and any correct implementation will have to deal with the fact that there is no necessary connection between the number of glyphs on the screen and bytes in its encoding. It would be perfectly reasonable for an implementation to declare a limitation, for example that it will not process than 32 trailing modifiers on any character, and this would not cause problems in production because sequences of such a length do not occur in the encoding of any known text. Which is to say, Ohta's statement about statefulness is true, but the conclusion that this is a "problem" is erroneous. -Tim _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 02:43:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKLu-0000Mj-Ed; Mon, 02 Jan 2006 02:43:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKLq-0000MW-Ho for ietf@megatron.ietf.org; Mon, 02 Jan 2006 02:43:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28272 for ; Mon, 2 Jan 2006 02:42:18 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtKQr-0006nn-PN for ietf@ietf.org; Mon, 02 Jan 2006 02:48:43 -0500 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k027hNuf008847 for ; Mon, 2 Jan 2006 00:43:23 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ISG00C01G21PM00@mail-amer.sun.com> (original mail from tbray@textuality.com) for ietf@ietf.org; Mon, 02 Jan 2006 00:43:23 -0700 (MST) Received: from [192.168.1.41] ([204.174.35.77]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ISG001O2G4A16A0@mail-amer.sun.com>; Mon, 02 Jan 2006 00:43:23 -0700 (MST) Date: Sun, 01 Jan 2006 23:43:39 -0800 From: Tim Bray In-reply-to: <004901c60bef$dee867e0$7f1afea9@oemcomputer> To: Randy Presuhn Message-id: <3CCC0432-14C1-497E-8B25-87628F3736F7@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-Priority: 3 References: <001501c60670$36f0eaa0$0601a8c0@pc6> <001f01c607ad$08fa5d00$0601a8c0@pc6> <01LWWGAWH28600009C@mauve.mrochek.com> <015101c608b7$8d453c00$0601a8c0@pc6> <01LWY2922HSM00009C@mauve.mrochek.com> <002d01c60b8f$131c79e0$0601a8c0@pc6> <6A0F1BA75E94FF440F514D00@svartdal.hjemme.alvestrand.no> <020301c60bb6$ed87ef20$0601a8c0@pc6> <43B2AC49.7040708@gmx.de> <032201c60bc9$6e930a20$0601a8c0@pc6> <004901c60bef$dee867e0$7f1afea9@oemcomputer> X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7BIT Cc: ietf Subject: Re: Troubles with UTF-8 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org On Dec 28, 2005, at 12:46 PM, Randy Presuhn wrote: > Reserving NUL as a special terminator is a C library-ism. I think > that > history has shown that the use of this kind of mechanism, rather than > explicitly tracking the string's length, was a mistake. I used to think so too, but I don't any more; twenty years of doing text processing has convinced me that C's null-terminated strings simply cannot be improved on in a low-level programming language. For more on the subject see http://www.tbray.org/ongoing/When/200x/ 2003/04/13/Strings -Tim _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 03:17:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKsN-0002PL-PU; Mon, 02 Jan 2006 03:17:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKsB-0002La-6w for ietf@megatron.ietf.org; Mon, 02 Jan 2006 03:17:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01108 for ; Mon, 2 Jan 2006 03:15:42 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtKxC-0007mm-NV for ietf@ietf.org; Mon, 02 Jan 2006 03:22:08 -0500 Received: from [192.168.0.3] (cpe-24-24-146-166.socal.res.rr.com [24.24.146.166]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k028HMvF018016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2006 00:17:23 -0800 Message-ID: <43B8E169.4000202@dcrocker.net> Date: Mon, 02 Jan 2006 00:16:41 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Harald Tveit Alvestrand References: <20060101043514.6985.qmail@xuxa.iecc.com> <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> <416F6B6F46586EDBC9410701@p3.JCK.COM> <6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no> In-Reply-To: <6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: bozoproofing the net, was The Value of Reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org > If these statements are both true, they might explain the lack of > success of S/MIME as a tool for general (rather than balkanized) > communication. and they might not. Since you and we have no empirical basis for asserting the association between poor adoption and any particular characteristic of the thing that is not being adopted, it is not at all helpful to cite a particular (mere) possibility in this discussion. It has no basis, so it has no relevance. In other words, Harald, no John L. did *not* make John K.'s point. Not even close. > - the IETF community has rejected the idea of mandating a single root > for "just about anything" (except for the DNS, the IANA and the address > spaces) I don't recall the citation that documents this community consensus. Can you provide it? Oh, I see by your later text that you can't. So what is your basis for saying "the IETF community has rejected"? For that matter, I suspect you are wrong. For example, the IETF did standardize private re-use of address space, which is its own bit of balkanization. > - Multiple roots lead to balkanization (of lesser or greater severity) Fine and true. And your point is what, exactly? I haven't seen anyone promoting multiple roots in this discussion, so how is this line of discussion at all relevant to the chartering of DKIM? > As far as I remember, neither of these statements have come out as > consensus statements in any IETF document - perhaps because "everyone" > knows that raising the issue will cause an endless debate and no > consensus document? and perhaps because they are not consensus statements. That's the problem with using guesses as facts. And to that end, thank *you* for making *my* point about the problems that accrue from taking a guess -- such as what people might do with a new technology -- and trying to inject into a decision about whether to standardize the technology. When did fear and psychosocial guesses become the basis for blocking IETF standards efforts? d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 04:40:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtMAp-0000gV-R6; Mon, 02 Jan 2006 04:40:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtMAn-0000d5-JL for ietf@megatron.ietf.org; Mon, 02 Jan 2006 04:40:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07037 for ; Mon, 2 Jan 2006 04:38:59 -0500 (EST) Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtMFm-0001cQ-Nz for ietf@ietf.org; Mon, 02 Jan 2006 04:45:25 -0500 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k029a9YN010266 for ; Mon, 2 Jan 2006 11:36:09 +0200 (IST) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k029a6Lx010255; Mon, 2 Jan 2006 11:36:06 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jan 2006 11:39:49 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.rad.co.il> Thread-Topic: Alternative formats for IDs Thread-Index: AcYPFMKIR7O25aQ0QZKouzJdAZoGTwAaxWFg From: "Yaakov Stein" To: "william\(at\)elan.net" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: Frank Ellermann , ietf@ietf.org Subject: RE: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org =20 > It does not matter how many people can read MSWord.=20 > The only supported formats should be the ones where you know=20 > what the format is (and not the ones that depend on particular program). Why ? If you take that as an axiom, then indeed it is easy to rule lots of formats out. But, what is the justification of the axiom? Why not say - only use formats for which there are decent editors easily available? And why do all the other SDOs get along with non-ASCII formats? On my intranet I have a list of 120+ SDOs in the communications and computer-science fields, and although I haven't gone through them all (I have asked someone to do so) I haven't found another group that uses ASCII files. If the axiom is so strong, then why doesn't it bother anyone else? Y(J)S _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 04:50:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtMLB-00078l-Cg; Mon, 02 Jan 2006 04:50:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtML8-00078P-Em for ietf@megatron.ietf.org; Mon, 02 Jan 2006 04:50:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07920 for ; Mon, 2 Jan 2006 04:49:41 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtMQB-0001vB-Dr for ietf@ietf.org; Mon, 02 Jan 2006 04:56:08 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 552C1259736; Mon, 2 Jan 2006 10:49:49 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08586-08; Mon, 2 Jan 2006 10:49:41 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id A6BC0259732; Mon, 2 Jan 2006 10:49:41 +0100 (CET) Date: Mon, 02 Jan 2006 10:54:12 +0100 From: Harald Tveit Alvestrand To: dcrocker@bbiw.net Message-ID: <33D8EA76B9350E63F056C2D8@svartdal.hjemme.alvestrand.no> In-Reply-To: <43B8E169.4000202@dcrocker.net> References: <20060101043514.6985.qmail@xuxa.iecc.com> <3556DA0FCA3E512F0BF5D041@p3.JCK.COM> <416F6B6F46586EDBC9410701@p3.JCK.COM> <6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no> <43B8E169.4000202@dcrocker.net> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: bozoproofing the net, was The Value of Reputation X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Dave, if you have any facts to contribute to the discussion, it would be nice if you included them. I've chosen to interpret your note as some questions and comments on the hypothesis I advanced in my previous message, and have tried to supply some additional information below. --On mandag, januar 02, 2006 00:16:41 -0800 Dave Crocker wrote: >> If these statements are both true, they might explain the lack of >> success of S/MIME as a tool for general (rather than balkanized) >> communication. > > and they might not. > > Since you and we have no empirical basis for asserting the association > between poor adoption and any particular characteristic of the thing that > is not being adopted, it is not at all helpful to cite a particular > (mere) possibility in this discussion. It has no basis, so it has no > relevance. The empirical fact is that I get some S/MIME signed mail. I cannot verify their origin, because my mailer does not have a certificate chain installed that allows the machinery installed in my mailer to do so. I have heard from others that the same thing happens to them. (And yes, my mailer has S/MIME verification software installed.) This is a phenomenon that I've seen rather consistently over the years, and it seems to me that "no single root" is a reasonable description of this phenomenon. It irritates me, and it's one reason why I use PGP/MIME rather than S/MIME when signing outgoing mail (I choose to have inflicted on me a different set of problems; neither solution works "well" for me, IMHO). So for me personally, the fact of multiple roots is contributing to my own non-adoption of S/MIME. It seems to me that this is consistent with what others have reported. I did not choose to repeat those observable facts; I chose to clearly label my hypothesis based on them a hypothesis ("might"). > In other words, Harald, no John L. did *not* make John K.'s point. Not > even close. > > > > - the IETF community has rejected the idea of mandating a single root > > for "just about anything" (except for the DNS, the IANA and the address > > spaces) > > I don't recall the citation that documents this community consensus. Can > you provide it? > > Oh, I see by your later text that you can't. So what is your basis for > saying "the IETF community has rejected"? For that matter, I suspect you > are wrong. For example, the IETF did standardize private re-use of > address space, which is its own bit of balkanization. I can't parse what I'm supposed to be wrong about here.... the IETF community seems to have rough consensus on what the IAB said in RFC 2826 about the DNS single root. In addressing, see RFC 1958 section 4. As for the rejection of single roots - that's a hypothesis, and I'm advancing it as a hypothesis that seems to have reasonable predictive value - what one would expect if the hypothesis was true seems to match fairly well what happens in reality (no security standards work apart from DNSSEC seriously considers the option of mandating a single security root, and even DNSSEC seems to choose to leave the decision on how the "root" is run to people outside the IETF community). > > > - Multiple roots lead to balkanization (of lesser or greater severity) > > Fine and true. > > And your point is what, exactly? > > I haven't seen anyone promoting multiple roots in this discussion, so how > is this line of discussion at all relevant to the chartering of DKIM? Actually, the subject line doesn't say anything about DKIM, so this thread is presumably about "Bozoproofing the net, was The Value of Reputation". But the current argument is actually somewhat relevant to DKIM. DKIM (as I interpret it, and for this version) chooses a trust path that says "keys belonging to a domain sign messages". This means that each domain is its own "root". The pieces that tie the "roots" together aren't specified in current DKIM; there's a good argument that it shouldn't be. One of the candidates for those pieces is called "reputation systems"; another, possibly orthogonal, is DNSSEC. FWIW, I'm in favour of approving the DKIM charter in its present form, or something reasonably close to it (I don't object to adopting the charter language from XMPP, but it's not a showstopper either way for me). Some day (probably after experimentation), I think the community should return to specifying pieces that can be used for "the rest of the solution". But I'm all in favour of specifying DKIM without doing that first. >> As far as I remember, neither of these statements have come out as >> consensus statements in any IETF document - perhaps because "everyone" >> knows that raising the issue will cause an endless debate and no >> consensus document? > > and perhaps because they are not consensus statements. > > That's the problem with using guesses as facts. As far as I know, I'm using guesses as guesses. Also known as "theories". > And to that end, thank *you* for making *my* point about the problems > that accrue from taking a guess -- such as what people might do with a > new technology -- and trying to inject into a decision about whether to > standardize the technology. > > When did fear and psychosocial guesses become the basis for blocking IETF > standards efforts? Have you stopped beating your wife? As far as I know, reasonable fears and well-funded guesses are a *reasonable* basis for making decisions, given that facts about what will happen in the future aren't available. It's my guess - and I think it's a reasonable one - that approving the DKIM charter roughly as-is will cause work to be done that has a good effect on the state of email in the future. But I can't claim that it's a fact. It's the quality of the guesses that makes a difference, and it's our business to try to make the best guesses we can, based on as much fact as we can figure out. Harald PS: BTW: I've now finished "Crimes against logic". http://www.alvestrand.no/books/crimes-against-logic.html _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 04:51:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtMM3-0007H5-9c; Mon, 02 Jan 2006 04:51:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtMLz-0007Gv-MQ for ietf@megatron.ietf.org; Mon, 02 Jan 2006 04:51:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07972 for ; Mon, 2 Jan 2006 04:50:34 -0500 (EST) Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtMR1-0001wM-R4 for ietf@ietf.org; Mon, 02 Jan 2006 04:57:01 -0500 Received: (qmail invoked by alias); 02 Jan 2006 09:51:35 -0000 Received: from p508FA941.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.169.65] by mail.gmx.net (mp036) with SMTP; 02 Jan 2006 10:51:35 +0100 X-Authenticated: #1915285 Message-ID: <43B8F740.6080108@gmx.de> Date: Mon, 02 Jan 2006 10:49:52 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Yaakov Stein References: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.rad.co.il> In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: "william\(at\)elan.net" , Frank Ellermann , ietf@ietf.org Subject: Re: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Yaakov Stein wrote: > > >> It does not matter how many people can read MSWord. >> The only supported formats should be the ones where you know >> what the format is (and not the ones that depend on particular > program). > > Why ? Formats are there to stay. Programs change. Microsoft has modified the Word format multiple times, sometimes breaking compatibility completely, sometimes just introducing minor compatibility problems affecting specific documents. (Anecdote: back when I was working for Motorola in the late 90s, Windows-based colleagues came over to us with Macs so that we would import their old documents and "save as" something their current Windows version would read) There is not a single "Word" format. There are partly-compatible "binary" versions, there is the XML format introduced in Office 11 (2003), and there's yet another incompatible XML format that will be introduced in Office 12. So exactly which one are you referring to? > If you take that as an axiom, then indeed it is easy to rule > lots of formats out. > > But, what is the justification of the axiom? > Why not say - only use formats for which there are decent > editors easily available? > > And why do all the other SDOs get along with non-ASCII formats? > On my intranet I have a list of 120+ SDOs in the communications > and computer-science fields, and although I haven't gone through > them all (I have asked someone to do so) I haven't found another > group that uses ASCII files. > > If the axiom is so strong, then why doesn't it bother anyone else? You're confusing the issue of whether ASCII is good enough with the one whether Word is an acceptable replacement for it, it seems. If you're concerned with the limitations of ASCII, I'd advise pushing for something that doesn't have these limitations, yet is open, stable and really widely available. Such as HTML 4 (strict). Best regards, Julian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 05:37:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtN45-0005n7-GS; Mon, 02 Jan 2006 05:37:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtN43-0005mx-BC for ietf@megatron.ietf.org; Mon, 02 Jan 2006 05:37:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12465 for ; Mon, 2 Jan 2006 05:36:05 -0500 (EST) Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtN95-0003JY-Hb for ietf@ietf.org; Mon, 02 Jan 2006 05:42:32 -0500 Received: (qmail invoked by alias); 02 Jan 2006 10:37:03 -0000 Received: from p54A7E445.dip.t-dialin.net (EHLO peter-dambier.de) [84.167.228.69] by mail.gmx.net (mp015) with SMTP; 02 Jan 2006 11:37:03 +0100 X-Authenticated: #8956597 Message-ID: <43B90245.4080307@peter-dambier.de> Date: Mon, 02 Jan 2006 11:36:53 +0100 From: Peter Dambier Organization: Peter and Karin Dambier User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.rad.co.il> In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.rad.co.il> X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Subject: Re: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: peter@peter-dambier.de List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Yaakov Stein wrote: > > > >>It does not matter how many people can read MSWord. >>The only supported formats should be the ones where you know >>what the format is (and not the ones that depend on particular > > program). They are written to be readable by everybody. Sun-cenrtic, IBM-centric and real computercompanies tend to receject mails and documents that need a special Operating System together with a special wordprocesser in a special version to be able to process, read or write a document. I remember there used to be several versions of Microsoft Word beeing incompatible over Mac, Dos, Windows and OS/2 . That was the time when companies decided a document has to be 7-bit ASCII without country specifics extensions. Alternatively EBCDIC was welcome to. There still exist programmes like kermit that can be used to transfer documents between flatfile ASCII and structured file EBCDIC over hardware borders. Even html is designed 7-bit ASCII and breaks when you use 8-bits and change hardware. With 7-Bit ASCII it does not matter wether you use an X-BOX with 8-bit words or a mainframe with 36-bit words. Using 16 bit words breaks when you move from the X-BOX to the X-BOX/360 both from the same company but building on different processors. > > Why ? > > If you take that as an axiom, then indeed it is easy to rule > lots of formats out. Otherwise you rule a lot of participants out. There was never a good reason for IBM to move from SNA to tcp/ip. On SNA they had document exchange. There was never a good reason for DEC to move from DDCMP to tcp/ip. DDCMP was much more flexible. Why should Microsoft move from NetBIOS to tcp/ip. They never got it working without quirks. So you rest with a handful of unix-centric companies, mostly sun and next. They do speak ASCII what now? > > But, what is the justification of the axiom? > Why not say - only use formats for which there are decent > editors easily available? > > And why do all the other SDOs get along with non-ASCII formats? > On my intranet I have a list of 120+ SDOs in the communications > and computer-science fields, and although I haven't gone through > them all (I have asked someone to do so) I haven't found another > group that uses ASCII files. I usually dont bother. If I cannot read it I delete it. Probably you never got an answer for documents I could not read. > > If the axiom is so strong, then why doesn't it bother anyone else? > > Y(J)S > You see, they delete it :) Maybe their virus scanner did in the first place :) Cheers Peter and Karin -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ietf-bounces@ietf.org Mon Jan 02 06:03:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtNSz-0002lI-52; Mon, 02 Jan 2006 06:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtNSv-0002kW-S9 for ietf@megatron.ietf.org; Mon, 02 Jan 2006 06:03:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15721 for ; Mon, 2 Jan 2006 06:01:47 -0500 (EST) Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtNXu-0004DI-W2 for ietf@ietf.org; Mon, 02 Jan 2006 06:08:15 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EtNSb-0000Ms-EX for ietf@ietf.org; Mon, 02 Jan 2006 12:02:41 +0100 Received: from pd9fbad0c.dip0.t-ipconnect.de ([217.251.173.12]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Jan 2006 12:02:41 +0100 Received: from nobody by pd9fbad0c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Jan 2006 12:02:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf@ietf.org From: Frank Ellermann Date: Mon, 02 Jan 2006 11:59:01 +0100 Organization: Lines: 45 Message-ID: <43B90775.5C7F@xyzzy.claranet.de> References: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.rad.co.il> <43B8F740.6080108@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad0c.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.9 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: Re: Alternative formats for IDs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org Julian Reschke wrote: > If you're concerned with the limitations of ASCII, I'd advise > pushing for something that doesn't have these limitations, > yet is open, stable and really widely available. Such as HTML > 4 (strict). I love the new tools.ietf.org/html rfcmarkup magic. I also love the new unpaginated xml2rfc output. And of course the ordinary ASCII xml2rfc output. But obviously the process XML -> xml2rfc -> ASCII -> rfcmarkup -> HTML loses some of the details in the XML source. xml2rfc has its own HTML output, but this doesn't reflect the look and feel of a "real" RFC like rfcmarkup or what faqs.org does. With a new xml2rfc HTML output "compatible" with the rfcmarkup style there would be no losses. Where "compatible" means precisely the same format as in the ASCII output, but with links, #page-1 etc. anchors, and #section anchors, like rfcmarkup. In addition xml2rfc could offer further anchors and links, anything rfcmarkup can't "see" because it works with the plain ASCII text instead of the XML source. Maybe it could also offer , , and while still creating monospaced 
 output.  Or rather content-based
 style tags (reserving  for links it will physically be
 bold, italics, or both.  That works with even Lynx if the
 monitor isn't monochrome)

 Last but not least, if we'd "allow" that as the "normative"
 output in addition to text/plain, then "and now allow also
 UTF-8 for the author address in THIS text/html" is trivial.

 This should also work with XHTML 1.0 strict or XHTML basic.
 Matter of taste, I think that XML is simpler than SGML for
 tools trying to do something with it.


OTOH the MS Word / PDF idea isn't a dream, it's a nightmare.

                            Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 06:19:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtNjC-0003ad-5t; Mon, 02 Jan 2006 06:19:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtNj9-0003aV-M6
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 06:19:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17268
	for ; Mon, 2 Jan 2006 06:18:33 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtNoD-0004pn-Fi
	for ietf@ietf.org; Mon, 02 Jan 2006 06:25:02 -0500
Received: from [192.168.0.3] (cpe-24-24-146-166.socal.res.rr.com
	[24.24.146.166]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k02BK7Qo001077
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Jan 2006 03:20:12 -0800
Message-ID: <43B90C3D.50405@bbiw.net>
Date: Mon, 02 Jan 2006 03:19:25 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: <20060101043514.6985.qmail@xuxa.iecc.com>
	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>
	
	<416F6B6F46586EDBC9410701@p3.JCK.COM>
	
	<6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no>
	<43B8E169.4000202@dcrocker.net>
	<33D8EA76B9350E63F056C2D8@svartdal.hjemme.alvestrand.no>
In-Reply-To: <33D8EA76B9350E63F056C2D8@svartdal.hjemme.alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dcrocker@bbiw.net
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Harald,

> Dave, if you have any facts to contribute to the discussion, it would be 
> nice if you included them.

Yes, it is always nice to include facts.  That is why I noted their absence from 
your assertions.

 > I've chosen to interpret your note as some
> questions and comments on the hypothesis I advanced in my previous 
> message, and have tried to supply some additional information below.

A note that says that you have made basic errors, that render your 
unconstructive to the current topic, probably qualifies as more than
"questions and comments".


> The empirical fact is that I get some S/MIME signed mail.  I cannot
> verify their origin, because my mailer does not have a certificate chain 
> installed that allows the machinery installed in my mailer to do so. I 
> have heard from others that the same thing happens to them. 

Taking a very small sampling, from a very limited community, and projecting it
onto a population of roughly 1 billion users, is not valid analytic methodology,
Harald.

Don't do it.


> This is a phenomenon that I've seen rather consistently over the years, 
> and it seems to me that "no single root" is a reasonable description of 
> this phenomenon.

Your discussion of no single root made two claims.  One was about the failure of 
s/mime failure and the second was about IETF community consensus.  The
fact that multiple roots can (and do) cause problems does not provide
substantiation for either of your claims.

So, you are taking my challenge on your logic as somehow indicating that I think
use of multiple roots is not often a problem.

Don't do that.


> I did not choose to repeat those observable facts; I chose to clearly 
> label my hypothesis based on them a hypothesis ("might").

The logic you are using is that a technology characteristic that causes you (and
some others) problems might be a reason for the relative failure of that
technology.  However, any interesting technology has lots of problems; this is
true even for successful ones.  Hence, the mere presence of a problem does not
qualify it as a basis for the failure of the technology.

In other words, Harald, anything "might" be a cause.  Adding the "might" does
not free up the speaker from being responsible for what they choose to suggest. 
  You chose what to claim "might" be responsible, but you have no basis for
that, other than a limited sampling of problem experiences.

In other words, Harald, absent a serious basis for citing the possible cause,
mentioning it is injecting mere noise into the dialogue.  Were we having a 
light-hearted discussion about the failure of s/mime, perhaps such casual 
reference to possible causes "might" make sense.  In a discussion about the 
chartering of DKIM, it makes none.


>> Oh, I see by your later text that you can't.  So what is your basis for
>> saying "the IETF community has rejected"?  For that matter, I suspect you
>> are wrong. For example, the IETF did standardize private re-use of
>> address space, which is its own bit of balkanization.
> 
> I can't parse what I'm supposed to be wrong about here....
> the IETF community seems to have rough consensus on what the IAB said in 
> RFC 2826 about the DNS single root. In addressing, see RFC 1958 section 4.

1. It represents IAB consensus.  IETF consensus on the document has never been
assessed, yet you appear to be claiming otherwise.

2. An assertion concerning the DNS root has no automatic generalization to a
principle that multiple roots is bad, yet that is what you have just attempted.


> As for the rejection of single roots - that's a hypothesis, and I'm 
> advancing it as a hypothesis that seems to have reasonable predictive 
> value - what one would expect if the hypothesis was true seems to match 
> fairly well what happens in reality (no security standards work apart 


Harald, let's cut to the chase.  How is any of this relevant to the chartering
of DKIM? So far, this has become a frustrating exercise in fears and sloppy
logic.  If you have any facts to contribute to the question of chartering DKIM,
it would be nice if you included them.

Given your statement, here, it appears that you are calling for DKIM chartering
to be preceded by some sort of research project that attempts to assess the
diffusion of innovation failures for message signing.  I suspect that would
entail rather more delay than is reasonable, nevermind the challenge in
producing useful research results.


>> I haven't seen anyone promoting multiple roots in this discussion, so how
>> is this line of discussion at all relevant to the chartering of DKIM?
> 
> Actually, the subject line doesn't say anything about DKIM, so this 
> thread is presumably about "Bozoproofing the net, was The Value of 
> Reputation". But the current argument is actually somewhat relevant to 
> DKIM.

You think that John K's note that you were responding to did not have DKIM as 
its focus?  I encourage you to re-read it.


> DKIM (as I interpret it, and for this version) chooses a trust path that 
> says "keys belonging to a domain sign messages". This means that each 
> domain is its own "root".

What an interesting bit of logic.  Good thing you raised it, since the
application of your logic means that the distributed administration of domain
name and IP Address mappings -- essentially the same thing as domain name/key 
mapping is the result of multiple roots.  We had better fix that fast, since it 
must be causing failure of adoption of the Internet.


> The pieces that tie the "roots" together aren't specified in current 
> DKIM;

It isn't?  You don't think that the administrative structure of the DNS might
mitigate this supposed problem, just a tad?


  there's a good argument that it shouldn't be. One of the
> candidates for those pieces is called "reputation systems"; another, 
> possibly orthogonal, is DNSSEC.

Huh?

Reputation systems have something to do with a single administrative root?

How?


> FWIW, I'm in favour of approving the DKIM charter in its present form, 

Good to know, since that is very much NOT what John K's note promotes.  He calls 
for adding a deliverable.


>> That's the problem with using guesses as facts.
> 
> As far as I know, I'm using guesses as guesses. Also known as "theories".

Harald, theories are supposed to have substantial basis, not stray bits of data.


>> When did fear and psychosocial guesses become the basis for blocking IETF
>> standards efforts?
> 
> As far as I know, reasonable fears and well-funded guesses are a 
> *reasonable* basis for making decisions, given that facts about what 

When we see any applied to this discussion, I'll agree with you.  So far, we 
haven't even come close, and I spent some effort explaining why.

Come to think of it, I do not recall seeing you respond to any of the substance 
of my comments.

Please consider less dismissive frivolity and more care and relevance in your 
assertions.

d/
-- 

Dave Crocker
Brandenburg InternetWorking



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 07:01:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtONd-0007Eq-KE; Mon, 02 Jan 2006 07:01:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtONb-0007Ei-2R
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 07:01:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20811
	for ; Mon, 2 Jan 2006 07:00:21 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtOSe-0005z6-L7
	for ietf@ietf.org; Mon, 02 Jan 2006 07:06:49 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 7C38725972F;
	Mon,  2 Jan 2006 13:00:29 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 11905-03; Mon,  2 Jan 2006 13:00:26 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 09D1B25972B;
	Mon,  2 Jan 2006 13:00:26 +0100 (CET)
Date: Mon, 02 Jan 2006 13:04:57 +0100
From: Harald Tveit Alvestrand 
To: Dave Crocker 
Message-ID: <6290ABA8A965FE150484933F@svartdal.hjemme.alvestrand.no>
In-Reply-To: <43B90C3D.50405@bbiw.net>
References: <20060101043514.6985.qmail@xuxa.iecc.com>
	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>
	
	<416F6B6F46586EDBC9410701@p3.JCK.COM>
	
	<6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no>
	<43B8E169.4000202@dcrocker.net>
	<33D8EA76B9350E63F056C2D8@svartdal.hjemme.alvestrand.no>
	<43B90C3D.50405@bbiw.net>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dave,

I seem to have managed to provoke you to anger.

You, by continuing to attack the validity of my arguments without even 
attempting to address their substance, and attempting to chastise me for my 
logic while failing to apply any standards of rigor to your own, have 
managed to provoke me.

I think that this discussion, if followed further, will provide neither 
entertainment nor information to the IETF community.

Until further notice, I will not respond further to any statement you make 
in the IETF.
It's unlikely that I'll even read them.

                        Harald


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 07:32:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtOrG-0006bg-Nf; Mon, 02 Jan 2006 07:32:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtOrE-0006b2-PL
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 07:32:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22979
	for ; Mon, 2 Jan 2006 07:30:58 -0500 (EST)
Received: from sokol.elan.net ([216.151.192.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtOwH-0006hd-Ub
	for ietf@ietf.org; Mon, 02 Jan 2006 07:37:27 -0500
Received: from sokol.elan.net (sokol [127.0.0.1])
	by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k02CW64L004434;
	Mon, 2 Jan 2006 04:32:06 -0800
Received: from localhost (william@localhost)
	by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k02CW1eW004431; 
	Mon, 2 Jan 2006 04:32:06 -0800
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Mon, 2 Jan 2006 04:32:00 -0800 (PST)
From: "william(at)elan.net" 
To: Yaakov Stein 
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.rad.co.il>
Message-ID: 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.rad.co.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: Frank Ellermann , ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Mon, 2 Jan 2006, Yaakov Stein wrote:

>> It does not matter how many people can read MSWord.
>> The only supported formats should be the ones where you know
>> what the format is (and not the ones that depend on particular
> program).
>
> Why ?
>
> If you take that as an axiom, then indeed it is easy to rule
> lots of formats out.
>
> But, what is the justification of the axiom?
> Why not say - only use formats for which there are decent
> editors easily available?

"Decent editor" is in the eye of the beholder ... We're all different 
people and what is good for one maybe bad for somebody else. What
matters is availability of choices and if type of format is not known, 
then it is not an open system and you're locked in one vendor (even if 
others claim to support it,without details of the format, that can not
be completely true). Where as when format is known, the software to 
read/write it can be created by anyone for any architecture.

So, like many people told you already on this list, MSWord is not a
format that IETF should support. If IETF is interested in supporting 
direct "editor" format in the future, then it should probably be
OpenDoc - once its more widely used and more then two implementations
for all major platforms.

Also with vendor-developed format, the actual format tends to change
from one version of the program to the other - that has been the problem 
with PDF as well, eventhough unlike MSWord it is an open format. So one
particular version that is well supported could in this case be chosen.

> And why do all the other SDOs get along with non-ASCII formats?
> On my intranet I have a list of 120+ SDOs in the communications
> and computer-science fields, and although I haven't gone through
> them all (I have asked someone to do so) I haven't found another
> group that uses ASCII files.

The question you should ask is can you find a platform where ASCII
file CAN NOT be read and created? Now substitute some other format
in place of ASCII and ask the same question....

> If the axiom is so strong, then why doesn't it bother anyone else?

Lets go ahead and ask then -
   Does anyone else think that IETF should allow documents which
   format/structure is not publicly known as one of the ways to
   distribute IETF specifications?

I think answers so far have been quite clear and from multiple people,
but if somebody else wants to support above, then lets hear it.

-- 
William Leibzon
Elan Networks
william@elan.net

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 07:40:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtOyr-00084p-0u; Mon, 02 Jan 2006 07:40:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtOyo-00084C-VA
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 07:40:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23528
	for ; Mon, 2 Jan 2006 07:38:48 -0500 (EST)
Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtP3s-0006tE-EA
	for ietf@ietf.org; Mon, 02 Jan 2006 07:45:18 -0500
Received: from [127.0.0.1] (www.caia.swin.edu.au [136.186.229.16])
	by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id XAA893915;
	Mon, 2 Jan 2006 23:39:46 +1100 (EST)
Message-ID: <43B91F0D.3040704@swin.edu.au>
Date: Mon, 02 Jan 2006 23:39:41 +1100
From: grenville armitage 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF list 
CC: ietf@ietf.org
References: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.rad.co.il>
	
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

william(at)elan.net wrote:
	[..]
> Lets go ahead and ask then -
>   Does anyone else think that IETF should allow documents which
>   format/structure is not publicly known as one of the ways to
>   distribute IETF specifications?

No.

cheers,
gja

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 07:47:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtP60-0005TR-Ab; Mon, 02 Jan 2006 07:47:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtP5v-0005Sr-8X
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 07:47:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24343
	for ; Mon, 2 Jan 2006 07:46:08 -0500 (EST)
Received: from mail.enyo.de ([212.9.189.167])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtPAw-00079X-HB
	for ietf@ietf.org; Mon, 02 Jan 2006 07:52:35 -0500
Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de)
	by mail.enyo.de with esmtp id 1EtP5G-0005RT-7H;
	Mon, 02 Jan 2006 13:46:42 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.60)
	(envelope-from )
	id 1EtP5D-00029p-IW; Mon, 02 Jan 2006 13:46:39 +0100
From: Florian Weimer 
To: "william(at)elan.net" 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDC48@exrad2.ad.rad.co.il>
	
Date: Mon, 02 Jan 2006 13:46:39 +0100
In-Reply-To:  (william elan
	net's message of "Sun, 1 Jan 2006 12:48:00 -0800 (PST)")
Message-ID: <87wthi7q6o.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: Frank Ellermann , ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

* william elan net:

> BTW - PDF also still rather "fluid" format with multiple versions
> and not always clear if PDF you create could be read by all readers
> in the same way you intended. So if PDF is as format, then exact
> version must be specified as well.

I fear that PDF shares a very obnoxious property with the Word
document format: the presentation form of a single documented,
interpreted by the same application, can change over time.

So if PDF is used, some constraints have to be imposed: The PDF must
be created by the RFC Editor, and it must not contain certain elements
(JavaScript and the like).

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 09:26:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtQdb-00060R-Ak; Mon, 02 Jan 2006 09:26:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtQdZ-0005zA-GV
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 09:26:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03998
	for ; Mon, 2 Jan 2006 09:25:00 -0500 (EST)
Received: from fep02-0.kolumbus.fi ([193.229.0.44] helo=fep02-app.kolumbus.fi)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtQid-0001g5-Hu
	for ietf@ietf.org; Mon, 02 Jan 2006 09:31:29 -0500
Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi
	with ESMTP
	id <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
	for ; Mon, 2 Jan 2006 16:25:59 +0200
X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912)
X-Originating-IP: [192.100.124.219]
From: John Loughney 
To: 
Date: Mon, 2 Jan 2006 16:25:59 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Content-Transfer-Encoding: 7bit
Subject: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi all,

Just out of curiosity, when browsing www.ietf.org, I noticed that the Neustar logo on www.ietf.org is larger than the ISOC logo.  Any particular reason why?  It just kind of jumps out at you ....

John


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 09:39:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtQq8-0003ww-7a; Mon, 02 Jan 2006 09:39:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtQq5-0003vD-Aa
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 09:39:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05001
	for ; Mon, 2 Jan 2006 09:37:56 -0500 (EST)
Received: from [216.148.227.153] (helo=rwcrmhc12.comcast.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtQvA-000213-7O
	for ietf@ietf.org; Mon, 02 Jan 2006 09:44:25 -0500
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165])
	by comcast.net (rwcrmhc13) with SMTP
	id <20060102143854015004rn8oe>; Mon, 2 Jan 2006 14:38:54 +0000
Message-ID: <021a01c60faa$16c230c0$0500a8c0@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDD9A@exrad2.ad.rad.co.il>
Date: Mon, 2 Jan 2006 08:37:42 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
Subject: Re: Consensus based on reading tea leaves (was: Re: Alternative
	formatsfor IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi, Yaakov,

Just FYI, I am actually fairly sympathetic to the idea that ASCII documents, 
including ASCII artwork, do not represent the highest possible evolution of 
protocol specification technology - my concern in this thread is only about 
how the IESG gauges IETF concensus.

*In the IETF*, where we have no concept of formal membership, no concept of 
voting, and no concept of required meeting attendance, we have chosen to 
require declared concensus to be based on public comments on relevant 
mailing lists.

We could certainly base declared consensus on other things. My point is that 
doing so likely requires a fundamental rethink of IETF process - simply 
encouraging the IESG to disregard the current IETF process BCPs on a 
case-by-case basis does not point me in any direction I'm comfortable with, 
and nicely justifies anyone who wants to appeal the decision as a process 
violation - not likely to make change happen MORE quickly...

Spencer

----- Original Message ----- 
From: "Yaakov Stein" 
To: "Spencer Dawkins" ; 
Sent: Monday, January 02, 2006 12:23 AM
Subject: RE: Consensus based on reading tea leaves (was: Re: Alternative 
formatsfor IDs)



> I can't imagine that ever encouraging the IESG to decide
> that they know what IETF consensus "really" is,
> while disregarding public comment,
> is ever going to be a good thing to do.

How did you read that into what we said?
We never said that IETF consensus should not be gauged.
Quite the contrary, we said that we don't want four emails
on the IETF list  to be used as a proxy for consensus.

We wrote a draft precisely in order to get the same treatment
that other drafts get.
If there is no WG that deals with the subject,
then perhaps the right way to check the will of the IETF community
is to ask for a hum at one of the plenary sessions.

We believe that in such a broad forum there will be
strong support for leaving the dark ages of ASCII.

Y(J)S 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 10:12:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtRM1-0004Li-VA; Mon, 02 Jan 2006 10:12:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtRLz-0004La-S6
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 10:12:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08854
	for ; Mon, 2 Jan 2006 10:10:54 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtRR3-00039J-1u
	for ietf@ietf.org; Mon, 02 Jan 2006 10:17:24 -0500
Received: from [10.0.0.138] by consulintel.es (MDaemon.PRO.v7.2.5.R)
	with ESMTP id md50001531505.msg
	for ; Mon, 02 Jan 2006 16:13:23 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Mon, 02 Jan 2006 16:11:22 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: Question about the Neustar logo on www.ietf.org
Thread-Index: AcYPrspWCPfm2nuiEdqMJAANky3PwA==
In-Reply-To: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-MDRemoteIP: 10.0.0.138
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Actually I believe that it should not be there any logo fro Neustar. Is a
paid service, right ?

I think if we agree, as a community to have a logo, then it will be fine,
but we can then consider having a logo for each of the contributors and the
companies that pay for their salaries and traveling expenses.

Regards,
Jordi




> De: John Loughney 
> Responder a: 
> Fecha: Mon, 2 Jan 2006 16:25:59 +0200
> Para: 
> Asunto: Question about the Neustar logo on www.ietf.org
> 
> Hi all,
> 
> Just out of curiosity, when browsing www.ietf.org, I noticed that the Neustar
> logo on www.ietf.org is larger than the ISOC logo.  Any particular reason why?
> It just kind of jumps out at you ....
> 
> John
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 10:15:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtRP0-0004h9-TV; Mon, 02 Jan 2006 10:15:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtROy-0004gZ-78
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 10:15:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09057
	for ; Mon, 2 Jan 2006 10:13:59 -0500 (EST)
Received: from sccrmhc13.comcast.net ([63.240.77.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtRU3-0003DR-Hl
	for ietf@ietf.org; Mon, 02 Jan 2006 10:20:28 -0500
Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149])
	by comcast.net (sccrmhc13) with SMTP
	id <2006010215145901300ooeeie>; Mon, 2 Jan 2006 15:14:59 +0000
From: "David B Harrington" 
To: "'william\(at\)elan.net'" ,
	"'Yaakov Stein'" 
Date: Mon, 2 Jan 2006 10:14:52 -0500
Message-ID: <009b01c60faf$4b5bd200$0300a8c0@DJYXPY41>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcYPmR0kHImhzZunS8WOYDVH/5+4NAAFbjKQ
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: 'Frank Ellermann' , ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

 

> Lets go ahead and ask then -
>    Does anyone else think that IETF should allow documents which
>    format/structure is not publicly known as one of the ways to
>    distribute IETF specifications?

Not me (or not I, whichever)

David Harrington
dbharrington@comcast.net




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 10:26:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtRa8-00035D-3z; Mon, 02 Jan 2006 10:26:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtRa6-000358-4J
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 10:26:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10403
	for ; Mon, 2 Jan 2006 10:25:28 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtRfA-0003dM-Bl
	for ietf@ietf.org; Mon, 02 Jan 2006 10:31:58 -0500
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k02FQVfj050262;
	Mon, 2 Jan 2006 07:26:31 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
References: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
Date: Mon, 2 Jan 2006 07:26:31 -0800
To: John Loughney , 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: 
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 4:25 PM +0200 1/2/06, John Loughney wrote:
>Just out of curiosity, when browsing www.ietf.org, I noticed that 
>the Neustar logo on www.ietf.org is larger than the ISOC logo.  Any 
>particular reason why?  It just kind of jumps out at you ....

Eeeew. Fully agree.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 10:27:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtRay-0003kI-A3; Mon, 02 Jan 2006 10:27:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtRav-0003jx-BF
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 10:27:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10474
	for ; Mon, 2 Jan 2006 10:26:20 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtRfz-0003f0-FX
	for ietf@ietf.org; Mon, 02 Jan 2006 10:32:49 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id A0A9A259723;
	Mon,  2 Jan 2006 16:26:23 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 16767-07; Mon,  2 Jan 2006 16:26:17 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 1EF5325971D;
	Mon,  2 Jan 2006 16:26:17 +0100 (CET)
Date: Mon, 02 Jan 2006 16:30:49 +0100
From: Harald Tveit Alvestrand 
To: John Loughney , ietf@ietf.org
Message-ID: 
In-Reply-To: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
References: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi >
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On mandag, januar 02, 2006 16:25:59 +0200 John Loughney 
 wrote:

> Hi all,
>
> Just out of curiosity, when browsing www.ietf.org, I noticed that the
> Neustar logo on www.ietf.org is larger than the ISOC logo.  Any
> particular reason why?  It just kind of jumps out at you ....

They seem to have it in place of the word "Neustar".... CNRI used to have 
their name there, and no logo. CNRI's had its name there at least since 
1996, so it's kind of traditional to name the operator.

                     Harald


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 10:36:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtRjZ-0007rv-Tx; Mon, 02 Jan 2006 10:36:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtRjX-0007rk-Pu
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 10:36:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11972
	for ; Mon, 2 Jan 2006 10:35:14 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtRoc-0003xx-JP
	for ietf@ietf.org; Mon, 02 Jan 2006 10:41:44 -0500
Received: (qmail 21466 invoked by uid 100); 2 Jan 2006 15:36:14 -0000
Date: 2 Jan 2006 15:36:14 -0000
Message-ID: <20060102153614.21465.qmail@xuxa.iecc.com>
From: John Levine 
To: ietf@ietf.org
Organization: I.E.C.C., Trumansburg NY USA
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit
Subject: Re: bozoproofing the IETF process, was bozoproofing the net
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Let's see if I can boil this argument down to the nub.

This started with a claim that there is something unusually dangerous
about DKIM so it needs warning labels or hazmat suits to prevent
people from using it to chop the net into pieces.

The first question is: is this problem unique to DKIM (and maybe a few
related techonologies), or is it a general problem that we now are
going to worry about all the time?

If the former, I need to understand concretely how to distinguish a
risky technology like DKIM from a less risky one like, say, S/MIME.
(The distinguishing rule should account for details like the fact that
the DKIM WG doesn't propose to standardize any authorization beyond
keys in the DNS, and that the evidence for partition due to similar
technologies like DNSBLs and SPF and S/MIME is pretty thin.)

If the latter, I share concerns about gratitous or accidental
partitioning, but they really need a WG of their own to produce their
own documents to which future work can refer, just as we refer to RFC
3833 when storing new data in the DNS rather than rehashing the fight
about how secure the DNS is.

If the partitioning issues are particularly related to e-mail, I would
be happy to continue them in the ASRG which is overdue for a good
argument.

If they're for the net in general, it would make a fascinating topic
for a WG where we can re-argue how bad private address space and NAT
are and whether the ICANN/IANA root is good and whether the de-facto
Verisign S/MIME root is bad, and about a hundred other things and wrap
it all up in about 2014 just as the last e-mail user gives up and
switches to one of three proprietary IM systems.


So can people give me guidance?  What problem are we trying to solve
with the danger warnings?

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 10:56:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtS2a-0002a1-Fg; Mon, 02 Jan 2006 10:56:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtS2Y-0002Zn-Ql
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 10:56:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13924
	for ; Mon, 2 Jan 2006 10:54:53 -0500 (EST)
Received: from mail.gmx.net ([213.165.64.21])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtS7e-0004a3-AR
	for ietf@ietf.org; Mon, 02 Jan 2006 11:01:23 -0500
Received: (qmail invoked by alias); 02 Jan 2006 15:55:49 -0000
Received: from p54A7E445.dip.t-dialin.net (EHLO peter-dambier.de)
	[84.167.228.69]
	by mail.gmx.net (mp036) with SMTP; 02 Jan 2006 16:55:49 +0100
X-Authenticated: #8956597
Message-ID: <43B94D06.40500@peter-dambier.de>
Date: Mon, 02 Jan 2006 16:55:50 +0100
From: Peter Dambier 
Organization: Peter and Karin Dambier
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <009b01c60faf$4b5bd200$0300a8c0@DJYXPY41>
In-Reply-To: <009b01c60faf$4b5bd200$0300a8c0@DJYXPY41>
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: peter@peter-dambier.de
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

David B Harrington wrote:
>  
> 
> 
>>Lets go ahead and ask then -
>>   Does anyone else think that IETF should allow documents which
>>   format/structure is not publicly known as one of the ways to
>>   distribute IETF specifications?
> 
> 
> Not me (or not I, whichever)
> 
> David Harrington
> dbharrington@comcast.net
> 
> 

Not for us either

Peter and Karin



-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@peter-dambier.de
mail: peter@echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 10:58:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtS5A-0003vB-BV; Mon, 02 Jan 2006 10:58:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtS59-0003uy-2H
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 10:58:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14243
	for ; Mon, 2 Jan 2006 10:57:33 -0500 (EST)
Received: from mail126.messagelabs.com ([216.82.254.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtSAA-0004fX-0V
	for ietf@ietf.org; Mon, 02 Jan 2006 11:04:03 -0500
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-7.tower-126.messagelabs.com!1136217506!10916848!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 28274 invoked from network); 2 Jan 2006 15:58:27 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-7.tower-126.messagelabs.com with SMTP;
	2 Jan 2006 15:58:27 -0000
Received: from [135.70.87.136] (unknown[135.70.87.136](misconfigured sender))
	by maillennium.att.com (mailgw1) with ESMTP
	id <20060102155825gw100lggdle> (Authid: tony);
	Mon, 2 Jan 2006 15:58:25 +0000
Message-ID: <43B94D9D.8030600@att.com>
Date: Mon, 02 Jan 2006 10:58:21 -0500
From: Tony Hansen 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <20060101043514.6985.qmail@xuxa.iecc.com>	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>		<416F6B6F46586EDBC9410701@p3.JCK.COM>		<6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no>	<43B8E169.4000202@dcrocker.net>	<33D8EA76B9350E63F056C2D8@svartdal.hjemme.alvestrand.no>	<43B90C3D.50405@bbiw.net>
	<6290ABA8A965FE150484933F@svartdal.hjemme.alvestrand.no>
In-Reply-To: <6290ABA8A965FE150484933F@svartdal.hjemme.alvestrand.no>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Subject: Back to chartering DKIM [was bozoproofing the net, was The Value
 of Reputation]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This thread was begun by the last call on the chartering of DKIM.

The thread of messages has wandered, with some people remembering its
roots (and others not), with some people taking into consideration the
history of the thread (and others not), and with some people trying to
keep the thread focused on its original topic (and others not). This has
led to different assumptions about what lies behind responses to
subsequent messages on the thread, and rancor because of those
assumptions and the messages arising from those assumptions. This is
disheartening.

Can we please get back to the question of chartering DKIM?

	Tony Hansen
	tony@att.com

Harald Tveit Alvestrand wrote:
> I think that this discussion, if followed further, will provide neither
> entertainment nor information to the IETF community.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 11:07:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtSDZ-00012O-9o; Mon, 02 Jan 2006 11:07:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtSDW-0000wA-OT
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 11:07:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15260
	for ; Mon, 2 Jan 2006 11:06:11 -0500 (EST)
Received: from mtagate3.uk.ibm.com ([195.212.29.136])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtSIX-000514-CU
	for ietf@ietf.org; Mon, 02 Jan 2006 11:12:41 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k02G7AQD239158
	for ; Mon, 2 Jan 2006 16:07:10 GMT
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com
	[9.149.37.213])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k02G7AST239106 for ; Mon, 2 Jan 2006 16:07:10 GMT
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k02G7AhL007368 for ; Mon, 2 Jan 2006 16:07:10 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k02G799C007361; Mon, 2 Jan 2006 16:07:09 GMT
Received: from zurich.ibm.com (sig-9-145-252-233.de.ibm.com [9.145.252.233])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA67938;
	Mon, 2 Jan 2006 17:07:07 +0100
Message-ID: <43B94FAD.80509@zurich.ibm.com>
Date: Mon, 02 Jan 2006 17:07:09 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi >
	
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, John Loughney 
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Harald Tveit Alvestrand wrote:
> 
> 
> --On mandag, januar 02, 2006 16:25:59 +0200 John Loughney 
>  wrote:
> 
>> Hi all,
>>
>> Just out of curiosity, when browsing www.ietf.org, I noticed that the
>> Neustar logo on www.ietf.org is larger than the ISOC logo.  Any
>> particular reason why?  It just kind of jumps out at you ....
> 
> 
> They seem to have it in place of the word "Neustar".... CNRI used to 
> have their name there, and no logo. CNRI's had its name there at least 
> since 1996, so it's kind of traditional to name the operator.
> 

It's traditional, and I think fair. I'll ask the IAD to see if we can get the scale
adjusted.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 11:10:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtSGg-000371-Uu; Mon, 02 Jan 2006 11:10:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtSGd-00032Q-Ph
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 11:10:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15478
	for ; Mon, 2 Jan 2006 11:09:24 -0500 (EST)
Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtSLg-00056Y-Ci
	for ietf@ietf.org; Mon, 02 Jan 2006 11:15:55 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k02G6WYL020482
	for ; Mon, 2 Jan 2006 18:06:32 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k02G6WLx020478;
	Mon, 2 Jan 2006 18:06:32 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 2 Jan 2006 18:10:15 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
Thread-Topic: Consensus based on reading tea leaves (was: Re:
	Alternativeformatsfor IDs)
Thread-Index: AcYPqqhbnJ92dbXpRtymxIRPJQOGaQABrl5A
From: "Yaakov Stein" 
To: "Spencer Dawkins" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: RE: Consensus based on reading tea leaves (was: Re:
	Alternativeformatsfor IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

=20



We could certainly base declared consensus on other things. My point is
that doing so likely requires a fundamental rethink of IETF process -
simply encouraging the IESG to disregard the current IETF process BCPs
on a case-by-case basis does not point me in any direction I'm
comfortable with, and nicely justifies anyone who wants to appeal the
decision as a process violation - not likely to make change happen MORE
quickly...

[YJS] That is why we proposed that the draft be part of a process change
process.

We purposely wanted to avoid the question that William Leibzon asked
here=20
on the general list, namely how many of the people who follow the
general list
are against using alternative formats. We have seen based on past
discussions
that there is a strong corrleation between following the general list
and
not admitting to be able to read any format other than ASCII.

We need some rethinking as to how to judge what the IETF community as a
whole
wants to do about some general issues. The only thing I am sure about is
that
consensus on this list is for keeping everything exactly as it is.

Y(J)S

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 11:15:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtSKs-0005A2-FV; Mon, 02 Jan 2006 11:15:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtSKq-00059u-4X
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 11:15:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16003
	for ; Mon, 2 Jan 2006 11:13:46 -0500 (EST)
Received: from filesrv1.baby-dragons.com ([199.33.245.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtSPv-0005HP-QV
	for ietf@ietf.org; Mon, 02 Jan 2006 11:20:17 -0500
Received: from localhost (localhost [127.0.0.1])
	by filesrv1.baby-dragons.com (8.13.4/8.13.4) with ESMTP id
	k02GEia6005090 for ; Mon, 2 Jan 2006 09:14:44 -0700
Date: Mon, 2 Jan 2006 09:14:44 -0700 (MST)
From: "Mr. James W. Laferriere" 
To: ietf maillist 
In-Reply-To: <009b01c60faf$4b5bd200$0300a8c0@DJYXPY41>
Message-ID: 
References: <009b01c60faf$4b5bd200$0300a8c0@DJYXPY41>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

 	Hello All ,

On Mon, 2 Jan 2006, David B Harrington wrote:
>> Lets go ahead and ask then -
>>    Does anyone else think that IETF should allow documents which
>>    format/structure is not publicly known as one of the ways to
>>    distribute IETF specifications?
>
> Not me (or not I, whichever)
> David Harrington
> dbharrington@comcast.net
 	I have to concur ,  No I do not want any document structure
 	that does not have a COMPLETELY publicly documented
 	specification as an IETF should allow document format .
 		JimL
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
+------------------------------------------------------------------+

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 11:40:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtSjK-0002qH-8L; Mon, 02 Jan 2006 11:40:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtSjG-0002pv-Sy
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 11:40:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18141
	for ; Mon, 2 Jan 2006 11:39:00 -0500 (EST)
Received: from woodstock.binhost.com ([144.202.243.4])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtSoN-0005xM-9z
	for ietf@ietf.org; Mon, 02 Jan 2006 11:45:31 -0500
Received: (qmail 5867 invoked by uid 0); 2 Jan 2006 16:40:04 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.32.62)
	by woodstock.binhost.com with SMTP; 2 Jan 2006 16:40:04 -0000
Message-Id: <7.0.0.16.2.20060102113007.05eee498@vigilsec.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Mon, 02 Jan 2006 11:39:56 -0500
To: ietf@ietf.org, iesg@ietf.org, ietf-dkim@mipassoc.org
From: Russ Housley 
In-Reply-To: <43A9EE2F.7080504@cs.utk.edu>
References: <20051221010622.1DE47222418@laser.networkresonance.com>
	<43A8BACF.50701@watson.ibm.com> <43A9618C.9000603@att.com>
	
	<43A9E6FB.8050706@watson.ibm.com> <43A9EE2F.7080504@cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc: 
Subject: Re: WG Review: Domain Keys Identified Mail (dkim)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I have been listening to this discussion.  As the area advisor for 
this proposed working group, I have made a few changes to the 
paragraph that has caused so much debate.  The revised text is 
largely based on the XMPP charter text posted by Tony 
Hansen.  However, we know that some changes are absolutely 
necessary.  Jim Fenton has given one example in the area of 
canonicalization.  While I expect each and every 
non-backwards-compatible change to be discussed on the mail list, I 
do not think that an RFC needs to include the rationale.  Thus, I 
have dropped the words that might be construed this way.

Here is the revised proposed charter text:

Domain Keys Identified Mail (dkim)
==================================

CHAIRS:


SECURITY AREA DIRECTORS:
Russ Housley 
Sam Hartman 

SECURITY AREA ADVISOR:
Russ Housley 

MAILING LISTS:
General Discussion: ietf-dkim@mipassoc.org
To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim
Archive: http://mipassoc.org/pipermail/ietf-dkim/

DESCRIPTION OF WORKING GROUP:

The Internet mail protocols and infrastructure allow mail sent from one
domain to purport to be from another. While there are sometimes
legitimate reasons for doing this, it has become a source of general
confusion, as well as a mechanism for fraud and for distribution of spam
(when done illegitimately, it's called "spoofing"). The DKIM working
group will produce standards-track specifications that allow a domain to
take responsibility, using digital signatures, for having taken part in
the transmission of an email message and to publish "policy" information
about how it applies those signatures. Taken together, these will assist
receiving domains in detecting (or ruling out) certain forms of spoofing
as it pertains to the signing domain.

The DKIM working group will produce a summary of the threats that are
addressed by the proposed standards-track specifications, while
acknowledging their limitations and scope. The DKIM working group will
also produce security requirements to guide their efforts, and will
analyze the impact on senders and receivers who are not using DKIM,
particularly any cases in which mail may be inappropriately labeled as
suspicious or spoofed.

While the techniques specified by the DKIM working group will not prevent
fraud or spam, they will provide a tool for defense against them by
assisting receiving domains in detecting some spoofing of known domains.
The standards-track specifications will not mandate any particular action
by the receiving domain when a signature fails to validate. That said,
with the understanding that guidance is necessary for implementors, the
DKIM documents should discuss a reasonable set of possible actions and
strategies, and analyze their likely effects on attacks and on normal
email delivery. The DKIM working group will not attempt to establish
requirements for trust relationships between domains nor to specify
reputation or accreditation systems.

The DKIM working group will consider mailing-list behaviour that is
currently deemed acceptable, will make every effort to allow such mailing
lists to continue to operate in a DKIM environment, and will provide a
plan for smooth transition of mailing lists that fail to operate. The
specifications will also advise mailing lists on how to take advantage of
DKIM if they should choose to do so.

The signatures will use public-key cryptography and will be based on
domain name identifiers. Public keys needed to validate the signatures
will be stored in the responsible identity's DNS hierarchy. The
specifications will be based on the following Internet Drafts:

    * draft-fenton-dkim-threats
    * draft-allman-dkim-base
    * draft-allman-dkim-ssp

These documents represent experimentation and consensus from a number of
designers and early implementors.

Experimentation has resulted in Internet deployment of these
specifications. Although not encouraged, non-backwards-compatible changes
to these specifications will be acceptable if the DKIM working group
determines that the changes are required to meet the group's technical
objectives.

The resulting protocols must meet typical criteria for success. In
addition to security, these include usability, scalability, ease of
deployment, and cryptographic algorithm independence.

To prevent this task from becoming unwieldy, several related topics are
considered out of scope for the DKIM working group. These topics include:

    * Reputation and accreditation systems. While we expect these to add
      value to what is defined by the DKIM working group, their development
      will be separate, and is out of scope for the DKIM working group.

    * Message content encryption.

    * Additional key management protocols or infrastructure.

    * Signatures that are intended to make long-term assertions beyond the
      expected transit time of a message from originator to recipient, which
      is normally only a matter of a few days at most.

    * Signatures that attempt to make strong assertions about the identity
      of the message author, and details of user-level signing of messages
      (as distinguished from domain-level keys that are restricted to
      specific users).

    * Duplication of prior work in signed email, including S/MIME and OpenPGP.

Once the primary goals are met, the DKIM working group may also study
whether to adopt a work item for specifying a common mechanism to
communicate the results of message verification to the message recipient.
The generation of a standards-track specification on this topic will
require an update to the DKIM working group charter.

The deliverables for the DKIM working group are these:

    * An informational RFC presenting a detailed threat analysis of, and
      security requirements for, DKIM. IESG approval of this document is
      a prerequisite for the submission of the standards-track
      specifications.

    * A standards-track specification for DKIM signature and verification.

    * A standards-track specification for DKIM policy handling.

    * A standards-track specification for DKIM DNS Resource Record(s).

    * An informational RFC providing an overview of DKIM and how it can
      fit into overall messaging systems, implementation and migration
      considerations, and outlining potential DKIM applications and
      future extensions.

GOALS AND MILESTONES:

02/06 WG last call on DKIM threats and security requirements
05/06 WG last call on DKIM signature specification
09/06 WG last call on DKIM policy specification
12/06 WG last call on DKIM DNS Resource Record
12/06 WG last call on overview document


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 12:32:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtTXy-0004te-PB; Mon, 02 Jan 2006 12:32:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtTXw-0004sj-A6
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 12:32:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23873
	for ; Mon, 2 Jan 2006 12:31:22 -0500 (EST)
Received: from b.mail.sonic.net ([64.142.19.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtTd2-0007Vo-CO
	for ietf@ietf.org; Mon, 02 Jan 2006 12:37:53 -0500
Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net
	[64.142.13.68]) (authenticated bits=0)
	by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k02HWKr2018994
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 2 Jan 2006 09:32:20 -0800
From: Douglas Otis 
To: Tony Hansen 
In-Reply-To: <43B94D9D.8030600@att.com>
References: <20060101043514.6985.qmail@xuxa.iecc.com>
	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>
	
	<416F6B6F46586EDBC9410701@p3.JCK.COM>
	
	<6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no>
	<43B8E169.4000202@dcrocker.net>
	<33D8EA76B9350E63F056C2D8@svartdal.hjemme.alvestrand.no>
	<43B90C3D.50405@bbiw.net>
	<6290ABA8A965FE150484933F@svartdal.hjemme.alvestrand.no>
	<43B94D9D.8030600@att.com>
Content-Type: text/plain
Date: Mon, 02 Jan 2006 09:32:19 -0800
Message-Id: <1136223139.17219.259.camel@bash.adsl-64-142-13-68>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Back to chartering DKIM [was bozoproofing the net, was The
	Value of Reputation]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 2006-01-02 at 10:58 -0500, Tony Hansen wrote:
> This thread was begun by the last call on the chartering of DKIM.

> Can we please get back to the question of chartering DKIM?

The concern raised was not specifically in regard to the base DKIM
draft.  There was concern with respect to the use of authorization in
conjunction with DKIM.  DKIM considered independent of the email-
addresses does not not have the same potential for disruption.

This is not true with SSP:

1) Authorization has great potential to disrupt normal email practices.

2) Authorization is not likely to reduced the levels of fraud, but
   rather changes tactics.

3) Misuse of authorization as authentication works to the benefit of
   large domains or those with private restrictive servers.

4) Authorization shifts the burden of reputation onto the email-domain
   owner, and may lead to a poorer systemic solutions.

5) Indications of an authorization to the recipient places them in
   greater peril of being defrauded.


The base DKIM draft does not directly introduce these problems.  When
used in conjunction with a recognition scheme (upon which expectations
can be based), far greater protection are provided without these
significant drawbacks caused by an authorization scheme.  This approach
also imposes significantly less overhead.

Include the base DKIM draft in the charter, but with the SSP draft
excluded.  DKIM permits many avenues for use.  Perhaps one way to look
at the DKIM signature is that it provides an alternative identifier to
that of the remote IP address that would be more stable as a source
identifier.

-Doug


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 12:46:49 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtTlh-0005Vr-2w; Mon, 02 Jan 2006 12:46:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtTlc-0005TH-6Y
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 12:46:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25672
	for ; Mon, 2 Jan 2006 12:45:30 -0500 (EST)
From: john.loughney@kolumbus.fi
Received: from fep30-0.kolumbus.fi ([193.229.0.32] helo=fep30-app.kolumbus.fi)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtTqi-00082t-BH
	for ietf@ietf.org; Mon, 02 Jan 2006 12:52:01 -0500
Received: from [85.156.31.73] by fep30-app.kolumbus.fi with ESMTP
	id <20060102174631.IJAT10520.fep30-app.kolumbus.fi@[85.156.31.73]>;
	Mon, 2 Jan 2006 19:46:31 +0200
To: Brian E Carpenter 
Date: Mon,  2 Jan 2006 17:43:29 +0200
Message-ID: 
X-Mailer: EPOC Email Version 2.10
MIME-Version: 1.0
Content-Language: i-default
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.3 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: quoted-printable
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: john.loughney@kolumbus.fi
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian,

I have no problem with it being there. I just thought the scale was a bit =
off ... The main page is a bit spartan by design, so I think we should keep =
it simple.

John

- original message -
Subject:	Re: Question about the Neustar logo on www.ietf.org
From:	Brian E Carpenter 
Date:		01/02/2006 4:07 pm

Harald Tveit Alvestrand wrote:
>=20
>=20
> --On mandag, januar 02, 2006 16:25:59 +0200 John Loughney=20
>  wrote:
>=20
>> Hi all,
>>
>> Just out of curiosity, when browsing www.ietf.org, I noticed that =
the
>> Neustar logo on www.ietf.org is larger than the ISOC logo.  Any
>> particular reason why?  It just kind of jumps out at you ....
>=20
>=20
> They seem to have it in place of the word "Neustar".... CNRI used to =

> have their name there, and no logo. CNRI's had its name there at least =

> since 1996, so it's kind of traditional to name the operator.
>=20

It's traditional, and I think fair. I'll ask the IAD to see if we can get =
the scale
adjusted.

     Brian



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 12:48:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtTmy-0005sf-4I; Mon, 02 Jan 2006 12:48:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtTmv-0005r6-4V
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 12:48:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25827
	for ; Mon, 2 Jan 2006 12:46:51 -0500 (EST)
From: john.loughney@kolumbus.fi
Received: from fep01-0.kolumbus.fi ([193.229.0.41] helo=fep01-app.kolumbus.fi)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtTs0-000856-Uk
	for ietf@ietf.org; Mon, 02 Jan 2006 12:53:22 -0500
Received: from [192.168.0.104] (really [84.231.143.173])
	by fep01-app.kolumbus.fi with ESMTP
	id <20060102174754.FJFX25092.fep01-app.kolumbus.fi@[192.168.0.104]>;
	Mon, 2 Jan 2006 19:47:54 +0200
To: Brian E Carpenter 
Date: Mon,  2 Jan 2006 17:45:07 +0200
Message-ID: 
X-Mailer: EPOC Email Version 2.10
MIME-Version: 1.0
Content-Language: i-default
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.3 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: quoted-printable
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: john.loughney@kolumbus.fi
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian,

I have no problem with it being there. I just thought the scale was a bit =
off ... The main page is a bit spartan by design, so I think we should keep =
it simple.

John

- original message -
Subject:	Re: Question about the Neustar logo on www.ietf.org
From:	Brian E Carpenter 
Date:		01/02/2006 4:07 pm

Harald Tveit Alvestrand wrote:
>=20
>=20
> --On mandag, januar 02, 2006 16:25:59 +0200 John Loughney=20
>  wrote:
>=20
>> Hi all,
>>
>> Just out of curiosity, when browsing www.ietf.org, I noticed that =
the
>> Neustar logo on www.ietf.org is larger than the ISOC logo.  Any
>> particular reason why?  It just kind of jumps out at you ....
>=20
>=20
> They seem to have it in place of the word "Neustar".... CNRI used to =

> have their name there, and no logo. CNRI's had its name there at least =

> since 1996, so it's kind of traditional to name the operator.
>=20

It's traditional, and I think fair. I'll ask the IAD to see if we can get =
the scale
adjusted.

     Brian



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 13:05:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtU47-0006uA-G6; Mon, 02 Jan 2006 13:05:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtU45-0006u2-S5
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 13:05:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27704
	for ; Mon, 2 Jan 2006 13:04:35 -0500 (EST)
Received: from [140.247.60.212] (helo=newdev.harvard.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtU8s-00009p-J7
	for ietf@ietf.org; Mon, 02 Jan 2006 13:11:07 -0500
Received: by newdev.harvard.edu (Postfix, from userid 501)
	id AB7895E8BA8; Mon,  2 Jan 2006 13:04:47 -0500 (EST)
To: ietf@ietf.org
Message-Id: <20060102180447.AB7895E8BA8@newdev.harvard.edu>
Date: Mon,  2 Jan 2006 13:04:47 -0500 (EST)
From: sob@harvard.edu (Scott Bradner)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



Brian sed
> It's traditional, and I think fair.

fwiw - it took a bit of adjusting when the ISOC logo was 1st put on
the home page (as I recall) - I also think its fine but should be 
about the same scale as the ISOC one

Scott

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 14:18:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtVC5-0000L5-5N; Mon, 02 Jan 2006 14:18:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtVC2-0000Kx-7w
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 14:18:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04287
	for ; Mon, 2 Jan 2006 14:16:53 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtVH9-000257-O5
	for ietf@ietf.org; Mon, 02 Jan 2006 14:23:24 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EtVBx-0003XO-84
	for ietf@ietf.org; Mon, 02 Jan 2006 20:18:01 +0100
Received: from c-134-88-221.hh.dial.de.ignite.net ([62.134.88.221])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Mon, 02 Jan 2006 20:18:01 +0100
Received: from nobody by c-134-88-221.hh.dial.de.ignite.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Mon, 02 Jan 2006 20:18:01 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Mon, 02 Jan 2006 20:17:27 +0100
Organization: 
Lines: 10
Message-ID: <43B97C47.528D@xyzzy.claranet.de>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: c-134-88-221.hh.dial.de.ignite.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 2.4 (++)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

john.loughney@kolumbus.fi wrote:

> The main page is a bit spartan by design,
> so I think we should keep it simple.

I'd put it as is on the IETF secretariat page,
align="right" next to the c/o Neustar address.

              Matter of taste, probably



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 14:22:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtVGG-00023G-Of; Mon, 02 Jan 2006 14:22:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtVGE-0001zP-3x
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 14:22:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04513
	for ; Mon, 2 Jan 2006 14:21:13 -0500 (EST)
Received: from wproxy.gmail.com ([64.233.184.199])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtVLJ-0002Cv-3Z
	for ietf@ietf.org; Mon, 02 Jan 2006 14:27:44 -0500
Received: by wproxy.gmail.com with SMTP id i14so2096062wra
	for ; Mon, 02 Jan 2006 11:22:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=A39qz9Gl5hL4K6to1e5APgP/me67A3s1uqFDnCcMQMmJMICfhXWayiqvn9qoNaok9anCpmtJeHRVsc5I3LDA7nXUqPbCWH3lKJuoRVPFx8q+vxeU4uu8DGxMXN/WdNT/OJ9chAf18BP95jJc2kzWAb+RhzAmWrj/U+Yg0U7MJWk=
Received: by 10.54.132.1 with SMTP id f1mr546424wrd;
	Mon, 02 Jan 2006 11:22:18 -0800 (PST)
Received: by 10.54.79.13 with HTTP; Mon, 2 Jan 2006 11:22:18 -0800 (PST)
Message-ID: 
Date: Mon, 2 Jan 2006 11:22:18 -0800
From: Clint Chaplin 
To: ietf@ietf.org
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: 
	
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: quoted-printable
Cc: iesg@ietf.org
Subject: Re: WG Review: EAP Method Update (emu)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Has an email list been set up for this effort yet?

On 12/22/05, Pekka Savola  wrote:
> On Wed, 21 Dec 2005, The IESG wrote:
> > - An update to RFC 2716 to bring EAP-TLS into standards track, clarify
> > specification, interoperability, and implementation issues gathered ove=
r the
> > years, and update the document to meet the requirements of RFC 3748, RF=
C 4017,
> > and EAP keying framework documents.
> > Backwards compatibility with RFC 2716 is a requirement.
>
> Is there a particular reason why the proposed charter does not mention
> EAP-TTLS?
>
> I know very little about different EAP types, but as a potential
> operator and user of EAP, I'd definitely want to see focus on
> something like EAP-TTLS.
>
> Given that EAP-TTLS seems to be becoming an industry standard in
> certain scenarios, it would be useful to clarify the relation of the
> work of this proposed WG wrt EAP-TTLS in the charter.  The relation
> may already be obvious to those who've been working on that space
> more, but as an EAP user, I'd like to make it explicit to ensure folks
> are on the same page..
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>


--
Clint (JOATMON) Chaplin
Wireless Security Technologist
Wireless Standards Manager

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 14:38:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtVW4-0001uL-MD; Mon, 02 Jan 2006 14:38:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtVW1-0001u8-TY
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 14:38:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06758
	for ; Mon, 2 Jan 2006 14:37:32 -0500 (EST)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtVb7-0002qY-UO
	for ietf@ietf.org; Mon, 02 Jan 2006 14:44:04 -0500
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51)
	id 1EtVVx-000BOp-L1
	for ietf@ietf.org; Mon, 02 Jan 2006 14:38:41 -0500
Received: by internaut.com (Postfix, from userid 1000)
	id 89BA3389FC; Mon,  2 Jan 2006 11:38:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by internaut.com (Postfix) with ESMTP id 7ABA634E28
	for ; Mon,  2 Jan 2006 11:38:40 -0800 (PST)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
Date: Mon, 2 Jan 2006 11:38:40 -0800 (PST)
From: Bernard Aboba 
To: ietf@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Subject: Re: bozo-proofing the net (or making better bozos?) 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Can we also conclude that SSL/TLS has failed as a tool for general 
communication?  

I think the issue here is whether we're talking about user-machine or 
machine-machine interaction.  When I bring up an https:// URL, very often 
I will encounter a cert-related error.  The certificate will be expired, 
or the altSubjectName may not match the name of the site, or it may not 
have a path to a pre-established trust anchor.  

If SSL/TLS is being used as a machine-machine security mechanism, these 
errors will often be fatal, implying the need for pre-configuration in 
order to ensure reliable operation.  SMTP over TLS is an example of a 
situation where pre-configuration is typically required. 

On the other hand, when user-machine interaction is occurring, the user 
may be given the opportunity to remedy the situation.  We can argue about 
whether this is likely to be effective (how many users have the expertise 
to really understand whether they should click "OK" or not?) but the point 
is that without a user bypass, general use of https would be difficult. 

The question in my mind is where DKIM fits in this continuum.  As long 
as the user is given the opportunity to look at the "spam" bucket, to see 
if anything important was mistakenly placed there, it seems more akin to 
the https:// case, than the S/MIME case.  The situation would be 
different, for example, if the technology were to be used to prevent mail 
delivery at all (e.g. mandatory use of SMTP over TLS with mutual 
authentication).  In that situation, the balkanization of trust 
hierarchies would prove highly disruptive. 


Harald Alvestrand said:

There's a pair of facts (or what passes for facts) here:

- the IETF community has rejected the idea of mandating a single root for 
"just about anything" (except for the DNS, the IANA and the address 
spaces)
- Multiple roots lead to balkanization (of lesser or greater severity)

If these statements are both true, they might explain the lack of success 
of S/MIME as a tool for general (rather than balkanized) communication.

As far as I remember, neither of these statements have come out as 
consensus statements in any IETF document - perhaps because "everyone" 
knows that raising the issue will cause an endless debate and no consensus 
document?

Might be time to challenge that assumption....

John Levine said:

The more I think about this, the less sense it makes.  DKIM is not the
first misusable security technology to come along, nor will it be the
last.  What makes it so uniquely dangerous that it needs special warning
labels?

Consider HTTP over SSL.  It has exactly the same balkanization problem
today that you're concerned about.  Browsers are shipped with a fairly
random list of signing certs that have more to do with history and PR
budgets than with an objective standard of merit, and pages from any https
server that hasn't bought a signature from someone in the browser's list
provoke a scary warning message.  Yet I see no language in RFC 2818 or in
sections 2.3 and 2.4 of RFC 2459 (user and administrator expectations)
warning about the problem of balkanization due to arbitrary signer lists.

Or consider S/MIME.  S/MIME applications have a cert list similar to the
one in a web browser, so they also have the problem of dividing the world
into haves who can afford a cert with a signature from someone in the list
and have-nots who can't.  I haven't read every word of every S/MIME RFC
(there sure are a lot of them), but if there's any warnings about
balkanization, they're very well hidden.

Or how about DNSSEC?  As the problems of phishing and malware get worse,
and ICANN and IANA start putting signatures into the root zone, people
will inevitably come up with the bright idea that names in signed zones
are "secure".  Even better, in the absence of signatures all the way to
the top, people will start making lists of the islands of security that
they like to limit which signed zones they accept.  I would think that
warnings about this would have belonged in RFC 4033.

I really need clarification of why DKIM RFCs need to tell people about the
dangers of balkanization, even though HTTPS, S/MIME, and DNSSEC don't.
Since we will certainly be seeing more anti-spam and anti-phishing
proposals, what would be really useful would be a metric to decide when a
future proposal is more dangerous like DKIM and requires warning language,
or is less dangerous like the other three and doesn't.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 14:43:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtVa8-00034g-3A; Mon, 02 Jan 2006 14:43:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtVa5-00033O-Ps
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 14:42:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07173
	for ; Mon, 2 Jan 2006 14:41:44 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtVfA-00030t-Oj
	for ietf@ietf.org; Mon, 02 Jan 2006 14:48:15 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EtVZp-00041G-W8; Mon, 02 Jan 2006 14:42:42 -0500
Date: Mon, 02 Jan 2006 14:42:41 -0500
From: John C Klensin 
To: Yaakov Stein 
Message-ID: <626228BDFFC0A7983CF2CBC3@p3.JCK.COM>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.r
 ad.co.il>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Monday, 02 January, 2006 11:39 +0200 Yaakov Stein
 wrote:

> And why do all the other SDOs get along with non-ASCII formats?
> On my intranet I have a list of 120+ SDOs in the communications
> and computer-science fields, and although I haven't gone
> through them all (I have asked someone to do so) I haven't
> found another group that uses ASCII files.
> 
> If the axiom is so strong, then why doesn't it bother anyone
> else?

At least one of the reasons is that most of those groups are
moving very slowly away from a paper-based mentality and, in
most cases, a charge-for-standards (on paper and surrogates for
paper) mentality.  With that combination, a format such as PDF
page images (without extractable text) is acceptable and may
actually be an advantage -- it can be read, printed, and is
guaranteed to reproduce the appearance of the printed page
exactly.  Similarly, concerns about proprietary formats with
widely-available "readers" such as MS Word may be less than the
concerns would be if  "editable without information loss" were a
requirement.

In many cases, distribution in Word or PDF has been justified as
increasing distribution speed and lowering (printing, postage,
and mailing) costs to the SDO, with no changes in procedures
about how those documents are handled, reviewed, and processed.

The IETF and its predecessors started with, and continues, a
collaborative norm in which the ability of everyone to read,
extract from, and manipulate an online document is vitally
important, in part because we have long believed that materials
and consensus need to be developed on mailing lists, not by
lengthy development meetings and whiteboards followed by
transcription into the next fixed-benchmark version of a
document.  I see a number of SDOs moving toward that norm, but
most of them are doing so in baby steps.  For several of them, I
would not expect the concept of proprietary formats, and
display-only distributed documents, to survive for very long
once they get to the state of online collaboration and editing
that we have been at for 20 or 30 years.

Finally, there is a longstanding and more or less explicit
decision in the IETF community to keep the costs of
participation as low as possible and, in particular, to not have
costs imposed by the SDO become a bar to effective
participation.  It is getting harder --much harder than I
personally considerable-- to participate effectively in the IETF
without ever setting foot in a meeting, but it is still possible
to do so.  Against our "minimal required costs" background,
effectively insisting a participant maintain a current version
of a particular operating system on which to run particular
versions of word processing and document presentation software
is a pretty steep cost requirement.

That sensitivity to costs of participation is not as important
to most of the SDOs on my list and, I would assume, on yours.
Instead, their norm is participation or membership fees that, in
many cases, I consider high enough to be barriers, requirements
for meeting attendance.  If the minimum entry cost for
participation in SDO X --including membership fees and minimal
meeting attendance costs-- is $5K or $10K or more, then maybe
maintaining even a dedicated machine for dealing with their
documents is a reasonable marginal cost.   But, for IETF
participation, it is not.

    john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 14:46:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtVdA-0005M6-3R; Mon, 02 Jan 2006 14:46:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtVd7-0005Li-8C
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 14:46:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07674
	for ; Mon, 2 Jan 2006 14:44:52 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtViE-00039H-Gp
	for ietf@ietf.org; Mon, 02 Jan 2006 14:51:23 -0500
Received: from [192.168.0.3] (cpe-24-24-146-166.socal.res.rr.com
	[24.24.146.166]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k02JkLtB015115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Jan 2006 11:46:22 -0800
Message-ID: <43B982E5.4010706@bbiw.net>
Date: Mon, 02 Jan 2006 11:45:41 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: <20060101043514.6985.qmail@xuxa.iecc.com>
	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>
	
	<416F6B6F46586EDBC9410701@p3.JCK.COM>
	
	<6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no>
	<43B8E169.4000202@dcrocker.net>
	<33D8EA76B9350E63F056C2D8@svartdal.hjemme.alvestrand.no>
	<43B90C3D.50405@bbiw.net>
	<6290ABA8A965FE150484933F@svartdal.hjemme.alvestrand.no>
In-Reply-To: <6290ABA8A965FE150484933F@svartdal.hjemme.alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dcrocker@bbiw.net
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Harald,


> I seem to have managed to provoke you to anger.

Not at all.  Were you trying to?


> You, by continuing to attack the validity of my arguments without even 
> attempting to address their substance,

Interesting assessment.  Your assertions lacked substance and relevance and my 
comments addressed exactly those failings.

I made a point of being extremely precise about the nature and basis for the 
criticisms.

It is frankly astonishing that you have so completely missed this.

It is unfortunate that you seem to take such criticism as meaning someone is 
angry with you.


  and attempting to chastise me for
> my logic while failing to apply any standards of rigor to your own, have 
> managed to provoke me.

Here, again, you make an assertion without bothering to offer an explanation for 
its basis.

(Given that I made a point of attempting that rigor and feel relatively 
confident I succeeded, it is not surprising that you refrain from justifying 
your accusation.)

Feel free to remedy that, such as by citing what statements lack the necessary 
rigor.


> Until further notice, I will not respond further to any statement you 
> make in the IETF.
> It's unlikely that I'll even read them.

But you won't refrain from posting this inflammatory declaration publicly?

How very constructive of you.

Come to think of it, your note has the qualities of being an ad hominem attack...

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 14:47:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtVei-00065S-1Z; Mon, 02 Jan 2006 14:47:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtVed-00063F-Fg
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 14:47:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07891
	for ; Mon, 2 Jan 2006 14:46:26 -0500 (EST)
Received: from oak.neustar.com ([209.173.53.70])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtVjm-0003DD-2l
	for ietf@ietf.org; Mon, 02 Jan 2006 14:52:58 -0500
Received: from MFOSTERLT43Pxp (stsc1260-corp-dns.va.neustar.com
	[209.173.53.65])
	by oak.neustar.com (8.12.8/8.11.0) with ESMTP id k02JlKQH022648;
	Mon, 2 Jan 2006 19:47:20 GMT
From: "Mark Foster" 
To: "'Brian E Carpenter'" ,
	"'Harald Tveit Alvestrand'" 
Date: Mon, 2 Jan 2006 14:45:42 -0500
Organization: NeuStar, Inc.
Message-ID: <001201c60fd5$1e268750$9001a8c0@cis.neustar.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcYPtuMNOHu/MUN7Rui9lR0HiY1jIwAHZMdg
In-Reply-To: <43B94FAD.80509@zurich.ibm.com>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8
Cc: ietf@ietf.org, 'John Loughney' 
Subject: RE: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0325717545=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0325717545==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0013_01C60FAB.35507F50"

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C60FAB.35507F50
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Would that this be the biggest transition issue we have to deal with ;-) 

 

Our offices are closed today, but we'll address shortly thereafter.

 

R, Mark

 

  _____  

From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
Brian E Carpenter
Sent: Monday, January 02, 2006 11:07 AM
To: Harald Tveit Alvestrand
Cc: ietf@ietf.org; John Loughney
Subject: Re: Question about the Neustar logo on www.ietf.org

 

Harald Tveit Alvestrand wrote:
>
>
> --On mandag, januar 02, 2006 16:25:59 +0200 John Loughney
>  wrote:
>
>> Hi all,
>>
>> Just out of curiosity, when browsing www.ietf.org, I noticed that the
>> Neustar logo on www.ietf.org is larger than the ISOC logo.  Any
>> particular reason why?  It just kind of jumps out at you ....
>
>
> They seem to have it in place of the word "Neustar".... CNRI used to
> have their name there, and no logo. CNRI's had its name there at least
> since 1996, so it's kind of traditional to name the operator.
>

It's traditional, and I think fair. I'll ask the IAD to see if we can get
the scale
adjusted.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


------=_NextPart_000_0013_01C60FAB.35507F50
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable







Re: Question about the Neustar logo on www.ietf.org










Would that this be the biggest =
transition
issue we have to deal with ;-) 



 



Our offices are closed today, but =
we’ll
address shortly thereafter.



 



R, =
Mark



 















From:
ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Brian E Carpenter

Sent: Monday, January 02, =
2006
11:07 AM

To: Harald Tveit =
Alvestrand

Cc: ietf@ietf.org; John =
Loughney

Subject: Re: Question =
about the
Neustar logo on www.ietf.org






 



Harald
Tveit Alvestrand wrote:

>

>

> --On mandag, januar 02, 2006 16:25:59 +0200 John Loughney

> <john.loughney@kolumbus.fi> wrote:

>

>> Hi all,

>>

>> Just out of curiosity, when browsing www.ietf.org, I noticed =
that the

>> Neustar logo on www.ietf.org is larger than the ISOC =
logo.  Any

>> particular reason why?  It just kind of jumps out at you =
....

>

>

> They seem to have it in place of the word "Neustar".... =
CNRI
used to

> have their name there, and no logo. CNRI's had its name there at =
least

> since 1996, so it's kind of traditional to name the operator.

>



It's traditional, and I think fair. I'll ask the IAD to see if we can =
get the
scale

adjusted.



     Brian





_______________________________________________

Ietf mailing list

Ietf@ietf.org

https://www1.ietf.or=
g/mailman/listinfo/ietf









------=_NextPart_000_0013_01C60FAB.35507F50--



--===============0325717545==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0325717545==--





From ietf-bounces@ietf.org Mon Jan 02 15:11:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtW26-0003SX-J4; Mon, 02 Jan 2006 15:11:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtW23-0003SG-Q5
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 15:11:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10125
	for ; Mon, 2 Jan 2006 15:10:38 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtW7B-0003uX-Qv
	for ietf@ietf.org; Mon, 02 Jan 2006 15:17:10 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EtW21-00043y-2S; Mon, 02 Jan 2006 15:11:49 -0500
Date: Mon, 02 Jan 2006 15:11:48 -0500
From: John C Klensin 
To: dcrocker@bbiw.net
Message-ID: <10BF89812A7939DA95EAA4D3@p3.JCK.COM>
In-Reply-To: <43B89C0B.1090105@dcrocker.net>
References: <20060101043514.6985.qmail@xuxa.iecc.com>
	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>
	
	<416F6B6F46586EDBC9410701@p3.JCK.COM>
	<43B89C0B.1090105@dcrocker.net>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Sunday, 01 January, 2006 19:20 -0800 Dave Crocker
 wrote:

>>   If such agreement cannot be reached, then I think
>> DKIM has much more serious problems about applicability and
>> the definition of the problems being solved than whether or
>> not this is required.
> 
> John,
> 
> Unfortunately what you appear to be saying is that you are
> certain of serious problems, and  are happy to assert them as
> a barrier to progress -- after all, you want to insist that a
> requirement for dealing with your fears be included as a
> chartered deliverable -- but you do not feel compelled to
> provide a solid basis for these fears.
> 
> Before imposing requirements on an IETF effort, one should
> make a pragmatic case for it.  At base, the case you have so
> far made is that the reasonable mechanism of DKIM might get
> mis-used, just as any other reasonable mechanism might be.

Dave, 

We seem to have reached a fundamental disconnect about how we
think consensus decisions are reached in the IETF and, for that
matter, in other situations. I'm going to try to avoid
characterizing your position, or even what it looks like to me,
because you could quite legitimately complain that I had no way
to understand your internal thought processes.  But I can, and I
think should, explain mine.

I think we find consensus around the IETF by giving plausible
objections the benefit of the doubt and trying to find middle
grounds to accommodate them.  If we can't do so, then we can't.
Then we need to figure out how "rough" a consensus we are
willing to tolerate and either move forward or give up.  I don't
believe we have ever turned "winning by exhaustion" or "winning
by intimidation" into virtues, even though those techniques are
sometimes demonstrably effective.  I also believe it is far more
useful to the IETF for us to struggle, together, to find,
understand, and, if appropriate, adjust to, a sincere concern or
objection, rather than to simply attack either the objection or
the objector.

We have both seen, and I believe we have both objected to,
situations in which a WG has said, in essence, "you approved our
charter, and we have done all this work, so you are obligated to
approve our result".  I don't like seeing the IETF get into that
position and have proposed remedies for it --including quicker
chartering, aggressive monitoring, and rapid termination of
groups that have gotten off course-- but those ideas haven't
gotten very much traction.  So we live with what we have, which
is the notion that conditions that should be imposed on a WG
(along with special freedoms that are to be given to it) must be
in the charter.

Now this proposed WG has asked for something exceptional, which
is the right to confine its discussions to a particular range of
alternatives determined by a self-selected design team (no
matter how much that design team consists of experienced IETF
folks and has asked for review within the broader IETF
community, the decision-making to this point remains vested in
that closed design team).  I think that the use of the design
team to develop a competent and consistent proposal is a
wonderful idea but, when the design team then shows up and says
what appears (at least to me) to be "charter the WG but confine
to working on our solution, presumably as we define it" then I
believe that the burden is on the design team to demonstrate
that approach is safe and consistent with IETF principles.  I
don't think the design team, or some of its members, get to say
"we have proposed this exceptional procedure and we are entitled
to use it unless someone can _prove_, to our satisfaction, that
it is harmful".  Your views, obviously, may differ but, to me,
the very essence of asking for an exceptional procedure is that
you justify and demonstrate the safety and appropriateness of
the exceptions, not that others be forced to prove that they are
harmful.

It seems to me that the IETF also has the right to ask a whole
range of "what problem does this solve" and, especially given
the requested constraint, "what value does an IETF WG add"
questions.  Those questions are, I believe, asked fairly
regularly of other proposed WGs although the presence of the
constraint request has caused them to be asked somewhat more
intensively this time than usual.   And, again, I suggest that
it is our precedent that the proposers of the WG need to respond
to those questions rather than saying, e.g., "unless you can
identify a technical flaw in our proposal, we are entitled to a
charter and provisions of our own choosing".  

> You keep implying that it is somehow a mysterious and big deal
> to have a voluntary, validated identity associated with
> message transit.

No, I keep "implying" (I've actually tried to be fairly
explicit) that it is not well-understood what problems this
proposed protocol solves and what operational side-effects its
deployment might cause.  If those issues were security ones, I
think there would be absolutely no doubt that explanations were
required.  But, to the extent that we understand the boundary
between "security issues" and other types of side effects, these
issues are on the other side of that line.  But the IESG has
always, at least as long as I can remember such things, had the
right to require an applicability statement for a protocol being
proposed for standardization and to require that applicability
statement cover either or both of the "what problem is being
solved?" question and the "what are the side-effects?" ones.

Those of us who believe that sort of statement should be
required of a proposed WG have three choices: 

	(i) we can ask that it be made a charter requirement, or 
	
	(ii) we can try to get into the WG and argue that it is
	a critical piece of work and that that protocol proposal
	isn't complete without it, or 
	
	(iii) we can wait until Last Call and, if the statement
	doesn't appear, argue that the protocol should not be
	approved until the A/S is provided.

Taking these in reverse order, the latter would almost certainly
be treated by the WG as the worst sort of "late surprise",
perhaps especially if it came from the community rather than,
e.g., an IESG member who had been suggesting it informally for
some time.  The second, it appears to me, could too easily be
blocked by a possibly-reasonable interpretation of the notion
that the existing documents determine the WG's scope.
Assurances by several potential participant-leaders of the WG
that such discussions would not be blocked seem to be to be
somewhat countered by aggressively-taken positions during the
charter discussions that anyone raising any procedurals issues
at all must either prove harm or demonstrate serious technical
flaws in the technical proposal.  And that leaves us with the
first option.

Again, all I'm asking for here is that the charter include
requirements for an explicit statement of the problems to which
the proposed protocol is applicable and for some analysis of the
consequences of applying it in some situations in which it is
not applicable.  If the work is worth doing, that should not be
hard.  I don't believe that it would be unreasonable for the
community to take a stronger step and require that those
statements be prepared and reach consensus pre-charter but, in
the spirit of trying to let the work go forward, I'm not asking
for that... only that the applicability materials be prepared as
part of generating a proposed standard.   If the charter draft
didn't contain an apparent request for a restriction of WG scope
to the content of the materials prepared by the design team, I
would be happy with a strong suggestion now and arguing for the
importance of the applicability materials in the WG after
chartering.  But I am concerned that the exclusion might
preclude this entire discussion.  I can't _prove_ that would
happen, but I don't believe I am under any obligation to do so,
no matter how many times you repeat that demand or its
variation: if you want this exceptional restriction in the
charter, then I believe it is your obligation to demonstrate
that it is safe and that all relevant issues will be dealt with
openly and appropriately rather than, e.g., having their
proponents shouted or verbally bludgeoned into submission.

      john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 15:20:13 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtWA9-0007sY-LA; Mon, 02 Jan 2006 15:20:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtWA5-0007pk-2N
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 15:20:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10982
	for ; Mon, 2 Jan 2006 15:18:56 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtWFC-0004AH-UJ
	for ietf@ietf.org; Mon, 02 Jan 2006 15:25:28 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EtW9z-00044k-8y; Mon, 02 Jan 2006 15:20:03 -0500
Date: Mon, 02 Jan 2006 15:20:02 -0500
From: John C Klensin 
To: Brian E Carpenter 
Message-ID: 
In-Reply-To: <43B94FAD.80509@zurich.ibm.com>
References: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.k olumbus.fi
	>	
	<43B94FAD.80509@zurich.ibm.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--On Monday, 02 January, 2006 17:07 +0100 Brian E Carpenter
 wrote:

> Harald Tveit Alvestrand wrote:
>> 
>> 
>> --On mandag, januar 02, 2006 16:25:59 +0200 John Loughney 
>>  wrote:
>> 
>>> Hi all,
>>> 
>>> Just out of curiosity, when browsing www.ietf.org, I noticed
>>> that the Neustar logo on www.ietf.org is larger than the
>>> ISOC logo.  Any particular reason why?  It just kind of
>>> jumps out at you ....
>> 
>> They seem to have it in place of the word "Neustar".... CNRI
>> used to  have their name there, and no logo. CNRI's had its
>> name there at least  since 1996, so it's kind of traditional
>> to name the operator.
> 
> It's traditional, and I think fair. I'll ask the IAD to see if
> we can get the scale adjusted.

Well, being very reluctant to get the IETF involved with
advertising any for-profit entity, I'm not sure it is fair.
More important,  I'd argue that the "traditional" part is
something we just got ourselves out of at great pain.  The CNRI/
Foretec logo belonged there as part of the general notion that
the secretariat was something that CNRI was supplying to the
IETF, not a set of services for which the IETF was contracting.
It went along with the notion of the secretariat being "hosted"
somewhere, rather than being an contractual activity for which
the IETF was paying.  Making that distinction, and obtaining the
control it implies, was arguably a significant part of the
motivation for the IASA.

In the present environment, there is, IMO, a significantly
stronger argument for adding logos for every company that is
supporting the IETF via significant earmarked contributions to
ISOC than there is for adding a logo for Neustar or any other
entity that is, in theory at least, providing a service to the
IETF for which the IETF/IASA are paying full value.   I don't
think we want all of those other logos either, and that suggests
that the home page should display only the IETF logo and perhaps
the ISOC one, but not those of any contractors the IASA should
happen to decide to hire.

    john



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 15:24:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtWEd-00010p-1e; Mon, 02 Jan 2006 15:24:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtWEZ-0000zh-OG
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 15:24:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11603
	for ; Mon, 2 Jan 2006 15:23:34 -0500 (EST)
Received: from mercury.lcs.mit.edu ([18.26.0.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtWJf-0004K3-GF
	for ietf@ietf.org; Mon, 02 Jan 2006 15:30:06 -0500
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178)
	id 5D22C86B00; Mon,  2 Jan 2006 15:24:35 -0500 (EST)
To: ietf@ietf.org
Message-Id: <20060102202435.5D22C86B00@mercury.lcs.mit.edu>
Date: Mon,  2 Jan 2006 15:24:35 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: jnc@mercury.lcs.mit.edu
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

    > From: John C Klensin 

    > the state of online collaboration and editing that we have been at for
    > 20 or 30 years.
    > Finally, there is a longstanding and more or less explicit decision in
    > the IETF community to keep the costs of participation as low as possible

There's one other thing, also tied to the IETF (and its predecessor's) long
existence, which is the long-term accessability of online documents - again,
another facet in which our experience is pretty unique. Is MS-Word (or
anything else) going to be 30 years from now?

In case you think this is a silly question, I just recently finished scanning
/ OCR'ing / proofing the oft-cited IEN-19 (Shoch, "Inter-Network Naming,
Addressing, and Routing"), from January 1978 - 28 years ago. The original of
this document was presumably in some Bravo format, and the printing version
was in PRESS - and I somehow doubt either is supported anywhere in the world
now. I only had a hardcopy, so the question's a bit moot, but I very much
doubt a machine-readable version of either form would have done me much good.


ASCII may be pretty lobotomized, but it *is* timeless.

(Not that I'm per-se against allowing more powerful forms, mind, but any
proprietary option is just not viable, IMO.)

	Noel

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 16:04:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtWqb-0004GF-Kf; Mon, 02 Jan 2006 16:04:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtWqZ-0004ED-99
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 16:04:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14441
	for ; Mon, 2 Jan 2006 16:02:50 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtWvh-0005LT-HD
	for ietf@ietf.org; Mon, 02 Jan 2006 16:09:22 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [)
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3461415; Mon, 02 Jan 2006 16:02:08 -0500
In-Reply-To: <20060102202435.5D22C86B00@mercury.lcs.mit.edu>
References: <20060102202435.5D22C86B00@mercury.lcs.mit.edu>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0BAA0751-C027-4D54-B5C2-BAA893E72C55@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Mon, 2 Jan 2006 16:03:54 -0500
To: jnc@mercury.lcs.mit.edu (Noel Chiappa)
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear Noel et al;

I trust that the whole IETF community  will have a Happy New Year.

On Jan 2, 2006, at 3:24 PM, Noel Chiappa wrote:

>> From: John C Klensin 
>
>> the state of online collaboration and editing that we have been at  
>> for
>> 20 or 30 years.
>> Finally, there is a longstanding and more or less explicit  
>> decision in
>> the IETF community to keep the costs of participation as low as  
>> possible
>
> There's one other thing, also tied to the IETF (and its  
> predecessor's) long
> existence, which is the long-term accessability of online documents  
> - again,
> another facet in which our experience is pretty unique. Is MS-Word (or
> anything else) going to be 30 years from now?
>
> In case you think this is a silly question, I just recently  
> finished scanning
> / OCR'ing / proofing the oft-cited IEN-19 (Shoch, "Inter-Network  
> Naming,
> Addressing, and Routing"), from January 1978 - 28 years ago. The  
> original of
> this document was presumably in some Bravo format, and the printing  
> version
> was in PRESS - and I somehow doubt either is supported anywhere in  
> the world
> now. I only had a hardcopy, so the question's a bit moot, but I  
> very much
> doubt a machine-readable version of either form would have done me  
> much good.
>
>

"Don't re-invent the wheel" is I think generally a good engineering  
principle. In this case, there
are a number of entities that are interested in long term archival   
storage of electronic documents; I think that the IETF should use   
their expertise and experience.

It seems that the library community has settled on PDF as its long  
term storage choice, and  is
moving to standardize this.

 From Harvard University's Report to the Digital Library Federation,  
October, 2004 :
http://www.diglib.org/pubs/news05_01/harvardnews5.htm

PDF/A

Adobe's Portable Document Format (PDF) has become the de-facto  
standard for web-based delivery of electronic documents. The  
International Organization for Standardization (ISO) has initiated an  
effort to create an standard for an archival profile of PDF that is  
amendable for long-term preservation. This standard, PDF/A, is  
intended to provide an unambiguous definition of the requirements  
necessary for the reliable and predictable future rendering of  
archived PDF documents. The second draft of the PDF/A standard was  
released in May 2004 and is currently undergoing a comment period by  
experts from the constituent national bodies of ISO. Stephen Abrams,  
the LDI Digital Library Program Manager at Harvard University, is the  
project leader and document editor for the ISO PDF/A joint working  
group.

-----

The next ISO meeting  on this is january 25-26 in Berlin, Germany

http://www.aiim.org/standards.asp?ID=25013

Here is the PR announcing the  project :

  A new joint activity has been initiated between NPES The  
Association for Suppliers of
Printing, Publishing and Converting Technologies, and the Association  
for Information and Image
Management, International (AIIM International) to develop an  
International standard that defines the
use of the Portable Document Format (PDF) for archiving and  
preserving documents.

  The project, currently referred to as PDF/A, will address the  
growing need to electronically
archive documents in a way that will ensure preservation of their  
contents over an extended period of
time, and will further ensure that those documents will be able to be  
retrieved and rendered with a
consistent and predictable result in the future.  This need exists in  
a growing number of international
government and industry segments, including legal systems, libraries,  
newspapers, regulated
industries, and others.

  The work will address the use of PDF for multi-page documents that  
may contain a mixture of
text, raster images and vector graphics.  It will also address the  
features and requirements that must be
supported by reading devices that will be used to retrieve and render  
the archived documents.

  This joint committee formed under AIIM and NPES will identify  
issues to be addressed, as
well as proposed solutions, and will develop a draft document that  
will then be presented to a Joint
Working Group of the International Organization for Standardization  
(ISO) for development and
approval as an International Standard.

-----
The Library of Congress has set up a web site devoted to this issue,
http://www.digitalpreservation.gov/ ,
which lists all of the formats being considered at

http://www.digitalpreservation.gov/formats/fdd/descriptions.shtml

and the ones specifically for text at
http://www.digitalpreservation.gov/formats/fdd/text_fdd.shtml

these being

DTB, Digital Talking Book
OEBPS_1_0, Open eBook Forum Publication Structure 1.0.1
OEBPS_1_2, Open eBook Forum Publication Structure 1.2
NCBIArch_1, NCBI/NLM Journal Archiving and Interchange DTD, version 1
NITF, News Industry Text Format

PDF, Portable Document Format
PDF_1_4, PDF, Versions 1.0-1.4
PDF_1_5, PDF, Version 1.5
PDF/A, PDF for Preservation
PDF/X, PDF for Prepress Graphics File Interchange

XML

with PDF/A  being further described at : http:// 
www.digitalpreservation.gov/formats/fdd/fdd000125.shtml

(Note : There is of course wording that says that "Inclusion of a  
format does not imply that it is preferred or acceptable for Library  
of Congress collections. Conversely, omission of a format from the  
list does not imply that it is not preferred or acceptable.  
Descriptions will be drafted and added over time.")

-----

My personal conclusion is

- I am in favor of moving beyond ASCII only.
- I am against using any non-standardized format, such as Word
- If there was a proposal to use PDF/A as standardized, I would  
support it.

Regards
Marshall Eubanks


> ASCII may be pretty lobotomized, but it *is* timeless.
>
> (Not that I'm per-se against allowing more powerful forms, mind,  
> but any
> proprietary option is just not viable, IMO.)
>
> 	Noel
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 16:34:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtXJv-00023d-IL; Mon, 02 Jan 2006 16:34:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtXJs-00023S-QN
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 16:34:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17136
	for ; Mon, 2 Jan 2006 16:33:07 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtXP1-00066R-6E
	for ietf@ietf.org; Mon, 02 Jan 2006 16:39:40 -0500
Received: (qmail 29422 invoked by uid 100); 2 Jan 2006 21:34:06 -0000
Date: 2 Jan 2006 21:34:06 -0000
Message-ID: <20060102213406.29421.qmail@xuxa.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: 
Organization: I.E.C.C., Trumansburg NY USA
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: aboba@internaut.com
Subject: Re: bozo-proofing the net (or making better bozos?)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>Can we also conclude that SSL/TLS has failed as a tool for general
>communication?

If we were holding it to the same requirements that some appear to be
asking for DKIM, I think we'd have to.

There is a certain amount of SMTP over TLS, an entirely automated
application, and the net hasn't collapsed.  I experimented with it for
a while before concluding that I didn't care about the threats against
which it defends, and was surprised how many SMTP hosts do TLS when
given the chance.

People have figured out reasonable ways to deal with TLS errors,
ranging from dropping the connection if it's suppposed to be part of a
private mail network to logging and ignoring the errors if it's
regular mail.  If they set up their regular mail servers to drop
connections on TLS failures, they'd lose a lot of mail.  So they
don't.

I don't see any reason to assume that mail admins will be any worse at
dealing with DKIM errors than they are with TLS errors.

So as I said several messages ago:

>I really need clarification of why DKIM RFCs need to tell people about the
>dangers of balkanization, even though HTTPS, S/MIME, and DNSSEC don't.
>Since we will certainly be seeing more anti-spam and anti-phishing
>proposals, what would be really useful would be a metric to decide when a
>future proposal is more dangerous like DKIM and requires warning language,
>or is less dangerous like the other three and doesn't.

R's,
John

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 16:36:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtXMB-0002Z2-1G; Mon, 02 Jan 2006 16:36:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtXM8-0002Yx-He
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 16:36:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17311
	for ; Mon, 2 Jan 2006 16:35:27 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtXRG-00069h-SN
	for ietf@ietf.org; Mon, 02 Jan 2006 16:42:00 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EtXM2-00049o-00; Mon, 02 Jan 2006 16:36:34 -0500
Date: Mon, 02 Jan 2006 16:36:33 -0500
From: John C Klensin 
To: Marshall Eubanks 
Message-ID: 
In-Reply-To: <0BAA0751-C027-4D54-B5C2-BAA893E72C55@multicasttech.com>
References: <20060102202435.5D22C86B00@mercury.lcs.mit.edu>
	<0BAA0751-C027-4D54-B5C2-BAA893E72C55@multicasttech.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Marshall,

--On Monday, 02 January, 2006 16:03 -0500 Marshall Eubanks
 wrote:

>...
>   The project, currently referred to as PDF/A, will address
> the  growing need to electronically
> archive documents in a way that will ensure preservation of
> their  contents over an extended period of
> time, and will further ensure that those documents will be
> able to be  retrieved and rendered with a
              ^^^^^^^^^^^^^^^^^^^^^^
> consistent and predictable result in the future.  This need
> exists in  a growing number of international
> government and industry segments, including legal systems,
> libraries,  newspapers, regulated industries, and others.
> 
>   The work will address the use of PDF for multi-page
> documents that  may contain a mixture of
> text, raster images and vector graphics.  It will also address
> the  features and requirements that must be
> supported by reading devices that will be used to retrieve and
> render  the archived documents.
  ^^^^^^

Emphasis added, of course.

As I have understood it, PDF/A is intended as an archival format
for the sorts of documents that exist on paper, with a primary
goal of being able to render things that look just like the
paper looked like.  It has not been a requirement that PDF/A
support extraction of text, editing, insertion of new materials,
and other forms of markup.  Indeed, some of the participants in
the PDF/A effort might consider support for some of those things
to be liabilities.  Your note reinforces that impression.  

As such, it is (IMO, barely) possible that PDF/A would be a
reasonable format for storing archival documents such as RFCs.
But it would be a terrible format for working documents such as
I-Ds, for the reasons discussed in my earlier note.

    john





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 16:41:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtXRB-0005zi-B1; Mon, 02 Jan 2006 16:41:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtXR8-0005wY-FF
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 16:41:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17803
	for ; Mon, 2 Jan 2006 16:40:37 -0500 (EST)
Received: from blaster.systems.pipex.net ([62.241.163.7])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtXWH-0006LR-31
	for ietf@ietf.org; Mon, 02 Jan 2006 16:47:10 -0500
Received: from pc6 (1Cust104.tnt5.lnd4.gbr.da.uu.net [62.188.134.104])
	by blaster.systems.pipex.net (Postfix) with SMTP id AA92DE000059
	for ; Mon,  2 Jan 2006 21:41:29 +0000 (GMT)
Message-ID: <027b01c60fdc$87e9b520$0601a8c0@pc6>
From: "Tom.Petch" 
To: "ietf maillist" 
References: <009b01c60faf$4b5bd200$0300a8c0@DJYXPY41>
	
Date: Mon, 2 Jan 2006 21:36:20 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Tom.Petch" 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I have always thought that ASCII had much to commend it  - ease of use,
compactness, open standard - which outweighed its limited functionality.

But while we debate this, have events already overtaken us?  I was surprised to
find, when reading
draft-fu-nsis-qos-nslp-statemachine-02.txt
repeated statements to the effect that if you want to see what this looks like,
look at the .pdf version.  It would seem that the system is giving tacit
support to .pdf (although I am cannot readily see just where the .pdf version is
filed:-(

What will anyone say when this I-D reaches last call?

Tom Petch

----- Original Message -----
From: "Mr. James W. Laferriere" 
To: "ietf maillist" 
Sent: Monday, January 02, 2006 5:14 PM
Subject: RE: Alternative formats for IDs


> Hello All ,
>
> On Mon, 2 Jan 2006, David B Harrington wrote:
> >> Lets go ahead and ask then -
> >>    Does anyone else think that IETF should allow documents which
> >>    format/structure is not publicly known as one of the ways to
> >>    distribute IETF specifications?
> >
> > Not me (or not I, whichever)
> > David Harrington
> > dbharrington@comcast.net
>   I have to concur ,  No I do not want any document structure
>   that does not have a COMPLETELY publicly documented
>   specification as an IETF should allow document format .
>   JimL
> --
> +------------------------------------------------------------------+
> | James   W.   Laferriere | System    Techniques | Give me VMS     |
> | Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
> | babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
> +------------------------------------------------------------------+
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 16:50:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtXZe-0003AB-UN; Mon, 02 Jan 2006 16:50:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtXZZ-00036r-VO
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 16:50:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19143
	for ; Mon, 2 Jan 2006 16:49:20 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtXei-0006kZ-DD
	for ietf@ietf.org; Mon, 02 Jan 2006 16:55:53 -0500
Received: from [192.168.0.3] (cpe-24-24-146-166.socal.res.rr.com
	[24.24.146.166]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k02Lof4V027794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Jan 2006 13:50:42 -0800
Message-ID: <43B9A008.4050001@dcrocker.net>
Date: Mon, 02 Jan 2006 13:50:00 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Brian E Carpenter 
References: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi
	>	
	<43B94FAD.80509@zurich.ibm.com>
In-Reply-To: <43B94FAD.80509@zurich.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


> It's traditional, and I think fair. I'll ask the IAD to see if we can 
> get the scale
> adjusted.


John Klensin's note does a very nice job of suggesting why it is not 
*automatically* the right thing to do.

In particular, his line of analysis points out the need to a) have an 
appropriate criterion, and b) apply it consistently.

The relationship with CNRI had characteristics vastly different from those with 
Neustar.

My personal opinion about the listing is that I don't know what is right. 
That's why I like John's effort to approach the question in terms of goals and 
balance, rather than simply invoking prior practise.

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 17:19:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtY1y-0002Pk-3O; Mon, 02 Jan 2006 17:19:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtY1v-0002O6-CT
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 17:19:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22240
	for ; Mon, 2 Jan 2006 17:18:37 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtY73-0007oS-HV
	for ietf@ietf.org; Mon, 02 Jan 2006 17:25:11 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LXAK08AOE8000ZEE@mauve.mrochek.com> for
	ietf@ietf.org; Mon, 2 Jan 2006 14:19:38 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1136240378;
	h=Date: 	 From:Subject:MIME-version;
	b=v+f2QIC2iAtM/3b1gR8Qj6vufbUefg3gciaAEb
	C5qofYvr4cYT3Gow/9A98tKdFgrtt8ORBra//YctacLDvK0Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LXAIIXLRNK00009C@mauve.mrochek.com> for ietf@ietf.org; Mon,
	02 Jan 2006 14:19:36 -0800 (PST)
To: ietf@ietf.org
Message-id: <01LXAK0766KY00009C@mauve.mrochek.com>
Date: Mon, 02 Jan 2006 13:46:57 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 02 Jan 2006 15:24:35 -0500 (EST)"
	<20060102202435.5D22C86B00@mercury.lcs.mit.edu>
MIME-version: 1.0
References: <20060102202435.5D22C86B00@mercury.lcs.mit.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Lets go ahead and ask then -

>   Does anyone else think that IETF should allow documents which
>   format/structure is not publicly known as one of the ways to
>   distribute IETF specifications?

For the record, my answer is "absolutely not".

> And why do all the other SDOs get along with non-ASCII formats?
> On my intranet I have a list of 120+ SDOs in the communications
> and computer-science fields, and although I haven't gone through
> them all (I have asked someone to do so) I haven't found another
> group that uses ASCII files.

First off, there's a big difference between using, say, an appropriately
constrained subset of HTML and using MS Word. Both may be non-ASCII, but one is
publicly specified whereas the other is not.

Second, your assumption that other SDOs have been able to blissfully make use
of private formats like MS Word without incident is simply untrue. One obvious
counterexample I know of is the CCITT/ITU, which has in the past used MS Word
as a distribution format for many of it's documents. I have quite a few of
these documents on hand and occasionally need to refer to old versions of them,
but when I try and read them using modern tools the results are rarely good.
Many of these documents simply refuse to open, sometimes crashing the tool I'm
using, while others do open but are misformatted, sometimes to the point of
being illegible.

Like it or not, compatibility with future versions is just not something you
can count on. Of course this is also true with formats whose specifications are
public, but at least with those you have the option of writing something to the
specification that will read the stuff.

>     > the state of online collaboration and editing that we have been at for
>     > 20 or 30 years.
>     > Finally, there is a longstanding and more or less explicit decision in
>     > the IETF community to keep the costs of participation as low as possible

Quite true. I don't like thinking about how much $$$ I've spent trying to deal
with proprietary formats of one sort or another.

> There's one other thing, also tied to the IETF (and its predecessor's) long
> existence, which is the long-term accessability of online documents - again,
> another facet in which our experience is pretty unique. Is MS-Word (or
> anything else) going to be 30 years from now?

Not if the past is any indicator.

> In case you think this is a silly question, I just recently finished scanning
> / OCR'ing / proofing the oft-cited IEN-19 (Shoch, "Inter-Network Naming,
> Addressing, and Routing"), from January 1978 - 28 years ago.

Access to old versions of specifications is often quite important. Even if you
ignore the frequent direct use of such specifications, it is not at all
uncommon for a modern RFC to have normative references to other RFCs written 25
years or more ago.

It is also worth noting that access to old drafts can be quite useful. And this
isn't confined to the IETF. To use the CCITT/ITU as an example again, back in
the day there was a widely used X.400 body part format that was only ever
specified in a particular draft of ISO 10021. (It never appears in any ITU
version of the specification, draft or otherwise.) You either had to have a
copy of this draft or you were reduced to dumping the ASN.1 and guessing what
the various fields were.

> The original of
> this document was presumably in some Bravo format, and the printing version
> was in PRESS - and I somehow doubt either is supported anywhere in the world
> now. I only had a hardcopy, so the question's a bit moot, but I very much
> doubt a machine-readable version of either form would have done me much good.

Well, I don't know about PRESS specifically, but I have a book describing the
Interpress format in a fair amount of detail. If it is the same it might
actually be possible to process it, probably most easily by converting it to
PostScript (which in many ways is it's descendant). So once again, it's all
about whether or not the details of the format are public.

> ASCII may be pretty lobotomized, but it *is* timeless.

Or as close to it as we can reasonably get.

> (Not that I'm per-se against allowing more powerful forms, mind, but any
> proprietary option is just not viable, IMO.)

I completely agree.

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 17:28:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtY9q-0005Gq-N6; Mon, 02 Jan 2006 17:28:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtY9o-0005Ge-Hq
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 17:28:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22834
	for ; Mon, 2 Jan 2006 17:26:46 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtYEx-00082y-BB
	for ietf@ietf.org; Mon, 02 Jan 2006 17:33:20 -0500
Received: (qmail 10215 invoked by uid 100); 2 Jan 2006 22:27:56 -0000
Date: 2 Jan 2006 22:27:56 -0000
Message-ID: <20060102222756.10191.qmail@xuxa.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: 
Organization: I.E.C.C., Trumansburg NY USA
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: william@elan.net
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>Now PDF does qualify but it is basicly an extended version of
>PostScript. Since IETF already accepts postscript, the question
>should be is there a need for features in PDF that are not
>in standard postscript. If there is then we can talk about it.

There is, actually.  Postscript is well specified as a programming
language, but somewhat underspecified as a document format.  It's not
hard to write postscript by mistake that renders OK in your viewer or
your printer but has bugs or environmental limits that would keep it
from displaying in other viewers or printers.  PDF is more tightly
specified than Postscript so there are fewer interoperability problems
among viewers that support the same version of PDF.

It should not come as a surprise to us that we are not the only people
in the world who are thinking about long-term storage of electronic
documents.  ISO 19005-1 defines PDF/A, specifically intended for
documents that have to be readable for a long long time, like court
opinions.  It's a constrained version of PDF 1.4.  I'd suggest
adopting PDF/A-1B, which leaves out some document structuring
requirements in the more stringent PDF/A-1A.

PDF is a fine display format, but it is a rather poor editing format
since it's hard to do any more with PDF (even PDF/A) than either to
print it or to extract the text from it.  XML on the other hand is a
putrid display format but it is easy to edit and is coded in ASCII so
even if the tools decay the document is still recoverable.  I would
say that the alternative to ASCII would be a pair of documents, RFC
2629 XML input and PDF output, with the PDF being optional since it
should be possible to regenerate it mechanically from the XML.

Word is of course out of the question since it is proprietary,
undocumented, and unstable.  I hope we have consensus on that.

R's,
John


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 17:32:19 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtYDz-0006j7-6W; Mon, 02 Jan 2006 17:32:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtYDs-0006iA-HA
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 17:32:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23217
	for ; Mon, 2 Jan 2006 17:30:58 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtYJ0-0008BL-BA
	for ietf@ietf.org; Mon, 02 Jan 2006 17:37:32 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFC.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44)
	id 1EtYDN-0006Gh-Jx; Mon, 02 Jan 2006 14:31:41 -0800
Message-Id: <6.2.3.4.2.20060102230849.03a8e670@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Mon, 02 Jan 2006 23:22:39 +0100
To: Brian E Carpenter 
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <43B9A008.4050001@dcrocker.net>
References: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi >
	
	<43B94FAD.80509@zurich.ibm.com> <43B9A008.4050001@dcrocker.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: ietf@ietf.org
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 22:50 02/01/2006, Dave Crocker wrote:
>>It's traditional, and I think fair. I'll ask the IAD to see if we 
>>can get the scale
>>adjusted.
>
>John Klensin's note does a very nice job of suggesting why it is not 
>*automatically* the right thing to do.
>In particular, his line of analysis points out the need to a) have 
>an appropriate criterion, and b) apply it consistently.
>The relationship with CNRI had characteristics vastly different from 
>those with Neustar.
>My personal opinion about the listing is that I don't know what is 
>right. That's why I like John's effort to approach the question in 
>terms of goals and balance, rather than simply invoking prior practise.

NeuStar is the ".us" Registy and has entered into an open root 
agreement with the GSMA, supporting the ".gprs" TLD. That the IETF 
pays to host a link to them may certainly be perceived as a political 
signal. After Harald's, John's and your mails, to maintain that link 
and the size of the logo will be perceived as a political RFC 3935 
decision. Three choices are possibles (keep it, reduce it, remove 
it). All now have a meaning.

It would probably be advisable that NeuStar proposes by its own to 
remove mention and link from the welcome page. A links to a "NeuStar 
Secretariat" page (not their main commercial page) in the IASA page 
seems adequate.
jfc

   


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 17:45:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtYQM-0007ka-6V; Mon, 02 Jan 2006 17:45:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtYQJ-0007ji-NA
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 17:45:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24364
	for ; Mon, 2 Jan 2006 17:43:50 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtYVQ-00005h-SI
	for ietf@ietf.org; Mon, 02 Jan 2006 17:50:24 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LXAKVM7H6O001152@mauve.mrochek.com> for
	ietf@ietf.org; Mon, 2 Jan 2006 14:44:56 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1136241896;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=IeYGu+iL0jQ2ivT885QWRs4UA
	/ZXQUmAk0vssTF7JxK9zEzigQRvlfu9SKRAMAaWVxoI3ZIqDHueXIFv2E4jjg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LXAIIXLRNK00009C@mauve.mrochek.com>; Mon,
	02 Jan 2006 14:44:52 -0800 (PST)
To: John C Klensin 
Message-id: <01LXAKVJVNIW00009C@mauve.mrochek.com>
Date: Mon, 02 Jan 2006 14:37:06 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 02 Jan 2006 15:20:02 -0500"
	
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: 
	<43B94FAD.80509@zurich.ibm.com> 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: ietf@ietf.org
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> > > They seem to have it in place of the word "Neustar".... CNRI
> > > used to  have their name there, and no logo. CNRI's had its
> > > name there at least  since 1996, so it's kind of traditional
> > > to name the operator.

> > It's traditional, and I think fair. I'll ask the IAD to see if
> > we can get the scale adjusted.

> Well, being very reluctant to get the IETF involved with
> advertising any for-profit entity, I'm not sure it is fair.

I agree and in fact would extend this to include non-profit entities not
directly involved in standards work.

> More important,  I'd argue that the "traditional" part is
> something we just got ourselves out of at great pain.  The CNRI/
> Foretec logo belonged there as part of the general notion that
> the secretariat was something that CNRI was supplying to the
> IETF, not a set of services for which the IETF was contracting.
> It went along with the notion of the secretariat being "hosted"
> somewhere, rather than being an contractual activity for which
> the IETF was paying.  Making that distinction, and obtaining the
> control it implies, was arguably a significant part of the
> motivation for the IASA.

Exactly so. The type of underlying relationship we have has changed (hopefully
for the better) and that argues strongly for a break with past precedents.

> In the present environment, there is, IMO, a significantly
> stronger argument for adding logos for every company that is
> supporting the IETF via significant earmarked contributions to
> ISOC than there is for adding a logo for Neustar or any other
> entity that is, in theory at least, providing a service to the
> IETF for which the IETF/IASA are paying full value.   I don't
> think we want all of those other logos either, and that suggests
> that the home page should display only the IETF logo and perhaps
> the ISOC one, but not those of any contractors the IASA should
> happen to decide to hire.

Complete agreement here.

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 18:15:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtYu0-0004vs-TG; Mon, 02 Jan 2006 18:15:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtYty-0004uI-5l
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 18:15:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26333
	for ; Mon, 2 Jan 2006 18:14:28 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtYz7-0000sJ-9o
	for ietf@ietf.org; Mon, 02 Jan 2006 18:21:02 -0500
Received: (qmail 16360 invoked by uid 100); 2 Jan 2006 23:15:38 -0000
Date: 2 Jan 2006 23:15:37 -0000
Message-ID: <20060102231537.16359.qmail@xuxa.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <6.2.3.4.2.20060102230849.03a8e670@mail.jefsey.com>
Organization: I.E.C.C., Trumansburg NY USA
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: jefsey@jefsey.com
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> NeuStar is the ".us" Registy and has entered into an open root
> agreement with the GSMA, supporting the ".gprs" TLD. That the IETF
> pays to host a link to them may certainly be perceived as a
> political signal.

Oh, no, not this again.  Neustar's .gprs TLD exists only on a special
purpose private network disjoint from the public Internet, used for
GSM signalling and invisible to anyone who doesn't run a GSM phone
switch.  It is not the network that GSM phone users see when they use
web or mail services over their phones.  I don't care what names the
GSMA uses on their private network, and I don't see any reason that
anyone else would, either.

There may be reasons not to like Neustar, but the fact that they
happen to provide network infrastructure to phone companies is not one
of them.

R's,
John

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 19:01:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtZcB-0002L4-Cf; Mon, 02 Jan 2006 19:01:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtZc8-0002I0-Px
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 19:01:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29082
	for ; Mon, 2 Jan 2006 19:00:06 -0500 (EST)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtZhI-0001te-LM
	for ietf@ietf.org; Mon, 02 Jan 2006 19:06:41 -0500
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51)
	id 1EtZc5-000FjB-Nx; Mon, 02 Jan 2006 19:01:17 -0500
Received: by internaut.com (Postfix, from userid 1000)
	id 3BE1638A66; Mon,  2 Jan 2006 16:01:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by internaut.com (Postfix) with ESMTP id 2C29E389FC;
	Mon,  2 Jan 2006 16:01:16 -0800 (PST)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
Date: Mon, 2 Jan 2006 16:01:16 -0800 (PST)
From: Bernard Aboba 
To: John Levine 
In-Reply-To: <20060102213406.29421.qmail@xuxa.iecc.com>
Message-ID: 
References: <20060102213406.29421.qmail@xuxa.iecc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: ietf@ietf.org
Subject: Re: bozo-proofing the net (or making better bozos?)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> >Can we also conclude that SSL/TLS has failed as a tool for general
> >communication?
> 
> If we were holding it to the same requirements that some appear to be
> asking for DKIM, I think we'd have to.

Right.

> There is a certain amount of SMTP over TLS, an entirely automated
> application, and the net hasn't collapsed.  
> People have figured out reasonable ways to deal with TLS errors,
> ranging from dropping the connection if it's suppposed to be part of a
> private mail network to logging and ignoring the errors if it's
> regular mail.  If they set up their regular mail servers to drop
> connections on TLS failures, they'd lose a lot of mail.  So they
> don't.
> 
> I don't see any reason to assume that mail admins will be any worse at
> dealing with DKIM errors than they are with TLS errors.

I don't see why DKIM is inherently different either.  If ISPs were looking 
for an excuse to not accept mail from unknown sources, they could use SMTP 
over TLS and a customized set of trust anchors to achieve that aim, 
without requiring any new protocols.  They didn't. 

> So as I said several messages ago:
> 
> >I really need clarification of why DKIM RFCs need to tell people about the
> >dangers of balkanization, even though HTTPS, S/MIME, and DNSSEC don't.

Don't hold your breath.  


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 19:17:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtZrY-0001X0-GK; Mon, 02 Jan 2006 19:17:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtZrW-0001Ux-HA
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 19:17:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00240
	for ; Mon, 2 Jan 2006 19:16:00 -0500 (EST)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtZwg-0002KI-Ho
	for ietf@ietf.org; Mon, 02 Jan 2006 19:22:35 -0500
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51)
	id 1EtZrU-000HO8-9U; Mon, 02 Jan 2006 19:17:12 -0500
Received: by internaut.com (Postfix, from userid 1000)
	id 0BD3C38AB7; Mon,  2 Jan 2006 16:17:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by internaut.com (Postfix) with ESMTP id 0031038A81;
	Mon,  2 Jan 2006 16:17:10 -0800 (PST)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
Date: Mon, 2 Jan 2006 16:17:10 -0800 (PST)
From: Bernard Aboba 
To: Eric Rescorla 
In-Reply-To: 
Message-ID: 
References: 
	
	<868xtzahye.fsf@raman.networkresonance.com>
	
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: ietf@ietf.org
Subject: Re: IETF Last Call: draft-salowey-tls-ticket-06.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> > I'm not sure I understand this, Bernard. The client doesn't need
> > to know anything about the ticket format or get to decide
> > anything about the mac. It's just the server talking to itself. 

In WLAN environments, the client has no way to restrict ticket submission 
to a given server.  Rather, clients assume that any server associated with 
a given SSID is a potential ticket validator.  Unfortunately, SSIDs 
(unlike domain names) are not globally unique.  In fact, millions of APs 
ship every year with same default SSID.  As a result, it will be very 
common for clients to submit tickets to servers who did not create them 
and are using completely different formats, algorithms and even protocol 
versions. 

Since the recommended ticket format includes only the client identity and 
not the server identity, and does not include information on the 
algorithms or formats used in constructing the ticket, the document is in 
effect setting a up a large scale "fuzzing experiment" in which random 
bits are submitted by clients to servers in order to see how they will 
react.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 19:29:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eta3e-00007i-Rs; Mon, 02 Jan 2006 19:29:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eta3c-00007Y-S7
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 19:29:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01540
	for ; Mon, 2 Jan 2006 19:28:30 -0500 (EST)
Received: from b.mail.sonic.net ([64.142.19.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eta8m-0002j6-Df
	for ietf@ietf.org; Mon, 02 Jan 2006 19:35:05 -0500
Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net
	[64.142.13.68]) (authenticated bits=0)
	by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k030TWT7015362
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 2 Jan 2006 16:29:33 -0800
From: Douglas Otis 
To: Frank Ellermann 
In-Reply-To: <43B8BD26.4615@xyzzy.claranet.de>
References: 
	 <43A8893F.9010700@dcrocker.net>
	 <43A8C2EC.4060401@dcrocker.net>
	
	
	
	
	<0b0d55f43c319b517cad80dd1d5d76d0@guppylake.com>
	<1135458563.17219.79.camel@bash.adsl-64-142-13-68>
	
	<983DD241-F8D4-4331-88BF-481A796333D0@mail-abuse.org>
	<43B1E85D.4F18@xyzzy.claranet.de>
	<22FDDD3D-C3A4-4099-8583-68EAF16BBA67@mail-abuse.org>
	<43B4F156.236C@xyzzy.claranet.de>
	<1135997824.17219.230.camel@bash.adsl-64-142-13-68>
	<43B77740.32CE@xyzzy.claranet.de>
	<9311C223-E5F8-49C2-9786-5868DC13A528@mail-abuse.org>
	<43B8BD26.4615@xyzzy.claranet.de>
Content-Type: text/plain
Date: Mon, 02 Jan 2006 16:29:31 -0800
Message-Id: <1136248172.17219.327.camel@bash.adsl-64-142-13-68>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: SIQ, SPF, BATV, etc.
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 2006-01-02 at 06:41 +0100, Frank Ellermann wrote:
> Douglas Otis wrote:
>
> AFAIK it's a way to check if mail claiming to be from ses-x@y
> was originally sent from x@y - if that's correct nothing is
> wrong with the idea so far, domain y only needs a name server
> returning 127.0.0.2 for ses-x.y and the "exists"-mechanism.

This requires at least three and perhaps several more DNS lookups to
resolve email-address authorization.  Placing greater burdens on the
recipient with additional external lookups does not make sense. 


> The "bounces-to" fans want to be free to use return-paths as
> it pleases them, without discussing this with their MON of the
> day, or with the MRN hit by the bounces.

A transparent scheme could allow complete freedom by encoding a
translated return-path in the BATV tag, which is de-encapsulated in a
manner illustrated in VERP for a list-server.

http://cr.yp.to/proto/verp.txt

The opt-out list avoids this effort.  Over time, nested tags could
become a common method to deal with this issue.  The exception lists
seemed easier. 


> > SPF still allows any miscreant to exploit open-ended records
> 
> Not really.  You can't get a PASS claiming to send MAIL FROM me
> without being a claranet.de customer, and fixing that last hole
> is trivial, they could just implement 2476bis 6.1.

Are you suggesting the MSA blocks submissions?  How does that prevent a
miscreant?


> Of course a spammer will find tons of policies where he can get a
> NEUTRAL result for forged mails.  But by definition NEUTRAL is the
> same as NONE (no policy), and IIRC we used MUSTard for this concept.

Unfortunately this may also result in those with open-ended records
becoming block-listed. : (


> > BATV does not risk as many delivery issues, whereas SPF will
> > when delivering to those using their Alma Mater email
> > address, for example.
> There will be a
> That's no argument, nobody needs to use his Alma Mater address
> in the reverse path while in reality using an unrelated MSA xy.

A transition period will last years, if not decades.  Looking for a
simple transition should consider this process.  I agree, opt-out is not
an optimal solution, and perhaps nesting would be preferable.


> > With BATV, the number of DNS lookups is zero.
> 
> Yes, and the number of rejected forged MAIL FROMs at the
> primary victim based on BATV is also zero, you get what you
> pay for, from the primary victim's POV nothing... ;-)

When the recipient can better depend upon source identifiers for vetting
email, then this improves abatement.  In that regard, BATV does indeed
provide the primary victim (the domain implementing BATV) much better
protection.  The expectation that SPF will directly prevent abuse is why
authorization is being abused as authentication.

Anyone can publish SPF records.  Anyone can implement BATV.  Preventing
the success of the exploit will likely alter the behavior of the spammer
as you suggested.  Those implementing BATV will be much less likely
targets, as this clearly indicates which sources are sending forged
return-paths.  Improving upon the source identifier block-list is where
protection is obtained, and BATV helps in that compilation. 


> > Being able to ensure forged return-paths are not effective
> > when returned would better realize the efficiencies of a
> > store and forward system.
> 
> Okay, SPF PASS offers only "it won't hit innocent bystanders",
> not too shabby for my tastes.  With SPF FAIL you also get "it
> never reaches my existing users", together that's as powerful
> as it can get before DATA (BDAT / BURL / whatever).

The disagreement seems to be what abates abuse.  No mechanism by itself
abates abuse.  I like the phrase "jumping through hoops" used by John
Levine.  Erecting more hoops will not abate abuse.  An authorization
scheme will not conform to existing practices, nor does it provide a
suitable identifier upon which reputation can be applied.
Unfortunately, as reputation is the active ingredient in abatement, the
unfair misuse of authorization as a source identifier is certainly
inevitable. This is especially true when open-ended lists are needed and
abuse persists.

-Doug



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 19:44:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtaI5-0007lX-Iv; Mon, 02 Jan 2006 19:44:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtaI2-0007kZ-Tu
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 19:44:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03134
	for ; Mon, 2 Jan 2006 19:43:24 -0500 (EST)
Received: from a.mail.sonic.net ([64.142.16.245])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtaNC-0003C9-QU
	for ietf@ietf.org; Mon, 02 Jan 2006 19:50:00 -0500
Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net
	[64.142.13.68]) (authenticated bits=0)
	by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k030i7Tf012243
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 2 Jan 2006 16:44:07 -0800
From: Douglas Otis 
To: John Levine 
In-Reply-To: <20060102222756.10191.qmail@xuxa.iecc.com>
References: <20060102222756.10191.qmail@xuxa.iecc.com>
Content-Type: text/plain
Date: Mon, 02 Jan 2006 16:44:06 -0800
Message-Id: <1136249047.17219.338.camel@bash.adsl-64-142-13-68>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: william@elan.net, ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 2006-01-02 at 22:27 +0000, John Levine wrote:

> PDF is a fine display format, but it is a rather poor editing format
> since it's hard to do any more with PDF (even PDF/A) than either to
> print it or to extract the text from it.  XML on the other hand is a
> putrid display format but it is easy to edit and is coded in ASCII so
> even if the tools decay the document is still recoverable.  I would
> say that the alternative to ASCII would be a pair of documents, RFC
> 2629 XML input and PDF output, with the PDF being optional since it
> should be possible to regenerate it mechanically from the XML.
> 
> Word is of course out of the question since it is proprietary,
> undocumented, and unstable.  I hope we have consensus on that.

Agreed.

The input draft should be in the form of XML converted to display
formats of PDF, HTML, or plain text.  Would Unicode need to be excluded
from the Plain Text version of the draft?  Would the plain text version
be dropped?  With XML, there could be elements that allow different
character repertoires that can be excluded from the plain text version.

-Doug




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 23:43:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ete13-00017l-Fx; Mon, 02 Jan 2006 23:43:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ete10-00017Z-JM
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 23:43:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25728
	for ; Mon, 2 Jan 2006 23:42:00 -0500 (EST)
Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ete67-00023T-FF
	for ietf@ietf.org; Mon, 02 Jan 2006 23:48:38 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k034cuYL020504
	for ; Tue, 3 Jan 2006 06:38:57 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k034ctLx020499;
	Tue, 3 Jan 2006 06:38:55 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 3 Jan 2006 06:40:41 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5201861026@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYP5RfHJ66puZZYTlyVPgho2c/r1wAOsJRH
From: "Yaakov Stein" 
To: "John C Klensin" ,
	"Marshall Eubanks" 
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0781778111=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0781778111==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C61020.206AFDBE"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61020.206AFDBE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As such, it is (IMO, barely) possible that PDF/A would be a
reasonable format for storing archival documents such as RFCs.
But it would be a terrible format for working documents such as
I-Ds, for the reasons discussed in my earlier note.

[YJS]  Which is exactly the reason all the other SDOs
use MS Word for input and PDF for output.
=20
(Partial results so far, from a list of 150 SDOs, I have only
found 2 that do not work that way, but the search continues ...)
=20
Y(J)S

------_=_NextPart_001_01C61020.206AFDBE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Re: Alternative formats for IDs=0A=
=0A=
=0A=

=0A=

As such, it is (IMO, barely) possible that =
PDF/A would =0A=
be a
reasonable format for storing archival documents such as =
RFCs.
But it =0A=
would be a terrible format for working documents such as
I-Ds, for =
the =0A=
reasons discussed in my earlier note.
=0A=

[YJS]  Which is exactly the reason =
all the =0A=
other SDOs
=0A=

use MS Word for input and PDF for =
output.
=0A=

 
=0A=

(Partial results so far, from a list of =
150 SDOs, I =0A=
have only
=0A=

found 2 that do not work that way, but the =
search =0A=
continues ...)
=0A=

 
=0A=

Y(J)S
=0A=
=0A=
=0A=

------_=_NextPart_001_01C61020.206AFDBE--


--===============0781778111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0781778111==--




From ietf-bounces@ietf.org Mon Jan 02 23:48:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ete5y-0002Sn-KO; Mon, 02 Jan 2006 23:48:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ete5s-0002Pe-8h
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 23:48:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26121
	for ; Mon, 2 Jan 2006 23:47:06 -0500 (EST)
Received: from mx1-b.rad.co.il ([62.219.98.8] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EteB4-0002Dn-U2
	for ietf@ietf.org; Mon, 02 Jan 2006 23:53:43 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k034iGYL020755
	for ; Tue, 3 Jan 2006 06:44:16 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k034iFLx020752;
	Tue, 3 Jan 2006 06:44:15 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 3 Jan 2006 06:47:59 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5201861027@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYP1Lg2RekyTrA8Qe6JNGYS+sYQogAS2zaM
From: "Yaakov Stein" 
To: "John C Klensin" 
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1701462219=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1701462219==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C61020.DF51B800"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61020.DF51B800
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

That sensitivity to costs of participation is not as important
to most of the SDOs on my list and, I would assume, on yours.
Instead, their norm is participation or membership fees that, in
many cases, I consider high enough to be barriers, requirements
for meeting attendance.  If the minimum entry cost for
participation in SDO X --including membership fees and minimal
meeting attendance costs-- is $5K or $10K or more, then maybe
maintaining even a dedicated machine for dealing with their
documents is a reasonable marginal cost.   But, for IETF
participation, it is not.

[YJS] This is the first cogent reason I have seen so far on this list
against Word. Of course,  out suggesting did not mandate Word,
and specifically allows anyone not having a copy to continue using
ASCII or XML, and since PDF would be available as output (and=20
has a free viewer) all RFCs would be available for all to read.
=20
The downside is that when a group is working on a document
in Word, anyone not having the SW would not be able to directly=20
contribute - but joint work is not really practical using any system
without tracking anyway.
=20
Y(J)S


------_=_NextPart_001_01C61020.DF51B800
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
RE: Alternative formats for IDs=0A=
=0A=
=0A=

=0A=

That sensitivity to costs of participation =
is not as =0A=
important
to most of the SDOs on my list and, I would assume, on =0A=
yours.
Instead, their norm is participation or membership fees that, =0A=
in
many cases, I consider high enough to be barriers, =
requirements
for =0A=
meeting attendance.  If the minimum entry cost for
participation =
in SDO =0A=
X --including membership fees and minimal
meeting attendance costs-- =
is $5K =0A=
or $10K or more, then maybe
maintaining even a dedicated machine for =
dealing =0A=
with their
documents is a reasonable marginal cost.   But, =
for =0A=
IETF
participation, it is not.

[YJS] This is the first cogent =
reason I =0A=
have seen so far on this list
=0A=

against Word. Of course,  out =
suggesting did not =0A=
mandate Word,
=0A=

and specifically allows anyone not having =
a copy to =0A=
continue using
=0A=

ASCII or XML, and since PDF would be =
available as =0A=
output (and 
=0A=

has a free viewer) all RFCs would be =
available for all =0A=
to read.
=0A=

 
=0A=

The downside is that when a group is =
working on a =0A=
document
=0A=

in Word, anyone not having the SW would =
not be able to =0A=
directly 
=0A=

contribute - but joint work is not really =
practical =0A=
using any system
=0A=

without tracking anyway.
=0A=

 
=0A=

Y(J)S
=0A=


=0A=
=0A=
=0A=

------_=_NextPart_001_01C61020.DF51B800--


--===============1701462219==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1701462219==--




From ietf-bounces@ietf.org Mon Jan 02 23:51:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ete93-0003zo-Nr; Mon, 02 Jan 2006 23:51:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ete8z-0003ze-F1
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 23:51:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26487
	for ; Mon, 2 Jan 2006 23:50:19 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EteEC-0002LV-4Y
	for ietf@ietf.org; Mon, 02 Jan 2006 23:56:56 -0500
Received: from [192.168.0.3] (cpe-24-24-146-166.socal.res.rr.com
	[24.24.146.166]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k034q114004941
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 2 Jan 2006 20:52:02 -0800
Message-ID: <43BA02C8.1050300@dcrocker.net>
Date: Mon, 02 Jan 2006 20:51:20 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: John C Klensin 
References: <20060101043514.6985.qmail@xuxa.iecc.com>	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>		<416F6B6F46586EDBC9410701@p3.JCK.COM>	<43B89C0B.1090105@dcrocker.net>
	<10BF89812A7939DA95EAA4D3@p3.JCK.COM>
In-Reply-To: <10BF89812A7939DA95EAA4D3@p3.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 1.4 (+)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> We seem to have reached a fundamental disconnect about how we
> think consensus decisions are reached in the IETF ...

John, that's not the disconnect.


> I think we find consensus around the IETF by giving plausible
> objections the benefit of the doubt and trying to find middle
> grounds to accommodate them. 

*That* is one of the major disconnects.

We have different views of the word "plausible".

I think the person raising the objection has significant responsibilities to 
make careful and precise statements, including careful and precise 
substantiation.  In other words, they need to make their case and they need to 
participate constructively in a dialogue about their concerns.

Of course, is also considered good taste for them to try to include a proposed 
fix.

I also think that "plausible" needs to be balanced against the risk of stopping 
forward progress, since there is always an infinite array of 
apparently-plausible objections one can make, if one insists on perfection.

Your use of the term seems to be wildly at variance with all of this.



>     I don't
> believe we have ever turned "winning by exhaustion" or "winning
> by intimidation" into virtues, even though those techniques are

Actually we have.

It is used with some regularity by various folk in IETF management, in lieu of 
honoring the requirements of "plausible" that I provided above.  Note the change 
that Russ is making to the charter.


>    I also believe it is far more
> useful to the IETF for us to struggle, together, to find,
> understand, and, if appropriate, adjust to, a sincere concern or
> objection, rather than to simply attack either the objection or
> the objector.

I believe this, too.


> Now this proposed WG has asked for something exceptional, which

I have repeatedly pointed out that the issue is far less exceptional than you 
represent it.

So far, you have never responded to those points.


> is the right to confine its discussions to a particular range of
> alternatives determined by a self-selected design team (no
> matter how much that design team consists of experienced IETF
> folks and has asked for review within the broader IETF

1. Although it is infrequent, there are multiple times that a group has brought 
existing technology to the IETF.  You appear intent on ignoring the pattern of 
choices made to handle such cases.  Instead you seem to insist on invoking the 
"start everything from scratch model" no matter how inappropriate and even 
destructive it might be to the technical work and the group momentum.

2. You express concern that a constrained charter might restrict choice, but 
feel no obligation to give examples of the choice.  Yet a charter is a contract 
and a contract is very much about restricting choice.

3. The "design team" for DKIM now numbers about 25 organizations. Note that this 
"design team" evolved version THREE of an effort that began with Yahoo and that 
that evolution was a full-group effort.  Again, you seem intent on ignoring this 
substantial history of evolution and community involvement.  Better still is 
that you are not proposing any other solution, merely complaining about this one.

4. Any IETF effort can benefit from random input from random folk, but it also 
can suffer from it.  The core of any serious effort has a constituency that is 
vigorously trying to solve a real problem, in a timely fashion.  A requirement 
for the IETF is to *facilitate* this work, rather than to throw up arbitrary 
barriers along the way.  Facilitation might well incur delays, when real and 
significant problems are uncovered.  But the burden of elucidating such problems 
lies with the person raising them.  You seem intent on making vague claims and 
no case to support them, regarding DKIM, and are not responding to the multiple 
people who observe that the problems you cite either do not exist or exist in a 
broad class of technologies that have already been standardized.

4. It has been fascinating to watch some folks attack the DKIM effort with false 
claims that DKIM folk (e.g., me) are unwilling to accept any criticisms or 
variations.  This is so grossly untrue that the assertion seems to require 
willfully pretending that the real record of open-participation DKIM discussions 
on its mailing list does not exist.


> community, the decision-making to this point remains vested in
> that closed design team). 

Wow.

You really have not tracked any of the work done on the open mailing list, have you?


>     when the design team then shows up and says
> what appears (at least to me) to be "charter the WG but confine
> to working on our solution, presumably as we define it" then I
> believe that the burden is on the design team to demonstrate
> that approach is safe and consistent with IETF principles.  I

An industry group brings existing technology to the IETF and seeks to have it 
evolved and standardized in the IETF.

Pursuing other solutions might well be a good and appropriate thing to do, but 
it has nothing to do with evolving an existing technology.  Again, you seem 
unable to make the distinction, even though there is plenty of precedent in the 
IETF.

If you want to pursue other solutions, then by all means do.  But please do not 
insist that a coherent and active constituency that is seeking to evolve an 
existing solution be coerced into your (different) effort.

If in fact, you think that DKIM should not be pursued by the IETF, then please 
say so and develop community support for rejecting it.  I'm sure the 
constituency of folk working on DKIM will be quite willing to pursue the work 
elsewhere.


>  Your views, obviously, may differ but, to me,
> the very essence of asking for an exceptional procedure is that
> you justify and demonstrate the safety and appropriateness of
> the exceptions, not that others be forced to prove that they are
> harmful.

Apparently you have not looked at the DKIM spec or the comments from others 
about it.

DKIM uses a collection of extremely well-understood techniques.  The amount of 
real innovation, involving core bits of mechanism, are somewhere between few and 
nil.  DKIM's innovation is in assembling these pieces into a useful whole.

Perhaps you have noticed that a number of other folk -- who happen to have 
little or nothing to do with DKIM -- have also taken exception to your peculiar 
fears about DKIM.

Feel free to respond to their specifics, even if you are not willing to respond 
to mine.


> It seems to me that the IETF also has the right to ask a whole
> range of "what problem does this solve" and, especially given
> the requested constraint, "what value does an IETF WG add"

What part of "I agreed that the original threats analysis work was needed" did 
you not understand?


> questions.  Those questions are, I believe, asked fairly
> regularly of other proposed WGs although the presence of the

Please point out the other working groups that have been required to produce a 
threat analysis before being chartered.


> constraint request has caused them to be asked somewhat more
> intensively this time than usual.   And, again, I suggest that
> it is our precedent that the proposers of the WG need to respond
> to those questions rather than saying, e.g., "unless you can
> identify a technical flaw in our proposal, we are entitled to a
> charter and provisions of our own choosing".  

Please stop raising entirely false claims, John.

Please try to include at least a modicum of reality in your claims.

What you have just described here simply never happened.


> No, I keep "implying" (I've actually tried to be fairly
> explicit) that it is not well-understood what problems this
> proposed protocol solves and what operational side-effects its
> deployment might cause. 

Since the threat analysis document addresses your first concern, you must 
disagree with its contents.  Please provide an explanation.

Since DKIM uses components of technology that are extremely well-understood, and 
since the few usage variations that the DKIM "service" might produce have been 
discussed extensively on the open mailing list, you appear to be unsatisfied 
with results.  Please provide an explanation.


> Again, all I'm asking for here is that the charter include
> requirements for an explicit statement of the problems to which
> the proposed protocol is applicable and for some analysis of the

1. That's not what you have been asking for.

2. Why are you not satisfied with the threat analysis document?

d/
-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 02 23:55:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EteD9-0005V5-O9; Mon, 02 Jan 2006 23:55:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EteD6-0005Si-B4
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 23:55:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26830
	for ; Mon, 2 Jan 2006 23:54:33 -0500 (EST)
Received: from mx1-b.rad.co.il ([62.219.98.8] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EteIH-0002Sy-JR
	for ietf@ietf.org; Tue, 03 Jan 2006 00:01:10 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k034plYL021075
	for ; Tue, 3 Jan 2006 06:51:47 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k034plLx021072;
	Tue, 3 Jan 2006 06:51:47 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 3 Jan 2006 06:55:31 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5201861028@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYP6wvMOIpP8NreTvu9XSgCqghDuQANfYxt
From: "Yaakov Stein" 
To: "Ned Freed" , 
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: 
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0468614913=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0468614913==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C61021.EC547C0D"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61021.EC547C0D
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Second, your assumption that other SDOs have been able to blissfully =
make use
of private formats like MS Word without incident is simply untrue. One =
obvious
counterexample I know of is the CCITT/ITU, which has in the past used MS =
Word
as a distribution format for many of it's documents. I have quite a few =
of
these documents on hand and occasionally need to refer to old versions =
of them,
but when I try and read them using modern tools the results are rarely =
good.
Many of these documents simply refuse to open, sometimes crashing the =
tool I'm
using, while others do open but are misformatted, sometimes to the point =
of
being illegible.

[YJS] I think that something has been lost in the translation here.
=20
ITU (I have participated in the ITU-T for many years, and ALWAYS
sent in my contributions in Word) ONLY accepts contributions in Word
and ONLY works on documents in Word (using ITU designed templates).
=20
The OUTPUT documents are available in Word and PDF, with PDF
the recommended format (due to Word's bad habit of changing pagination
when using different page sizes, etc). The PDF output should be readable
indefinitely.=20
=20
The Word format is mainly there for people who may need to work on=20
updates of the standard (unlike RFCs, ITU Recommendations are updated).=20
If such a Word doc is unreadable for anyone needing it, the
secretariat has tools to convert it.
=20
Y(J)S
=20

------_=_NextPart_001_01C61021.EC547C0D
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
RE: Alternative formats for IDs=0A=
=0A=
=0A=

=0A=

Second, your assumption that other SDOs =
have been able =0A=
to blissfully make use
of private formats like MS Word without =
incident is =0A=
simply untrue. One obvious
counterexample I know of is the CCITT/ITU, =
which =0A=
has in the past used MS Word
as a distribution format for many of =
it's =0A=
documents. I have quite a few of
these documents on hand and =
occasionally =0A=
need to refer to old versions of them,
but when I try and read them =
using =0A=
modern tools the results are rarely good.
Many of these documents =
simply =0A=
refuse to open, sometimes crashing the tool I'm
using, while others =
do open =0A=
but are misformatted, sometimes to the point of
being =0A=
illegible.
=0A=

[YJS] I think that something has been lost =
in the =0A=
translation here.
=0A=

 
=0A=

ITU (I have participated in the ITU-T for =
many years, =0A=
and ALWAYS
=0A=

sent in my contributions in Word) ONLY =
accepts =0A=
contributions in Word
=0A=

and ONLY works on documents in Word (using =
ITU =0A=
designed templates).
=0A=

 
=0A=

The OUTPUT documents are available in Word =
and PDF, =0A=
with PDF
the recommended format (due to Word's bad habit of changing =0A=
pagination
=0A=

when using different page sizes, etc). The =
PDF output =0A=
should be readable
=0A=

indefinitely. 
=0A=

 
=0A=

The Word format is mainly there for people =
who may =0A=
need to work on 
=0A=

updates of the standard (unlike RFCs, ITU =0A=
Recommendations are updated). 
=0A=

If such a Word doc is unreadable for =
anyone needing =0A=
it, the
=0A=

secretariat has tools to convert =
it.
=0A=

 
=0A=

Y(J)S
=0A=

 
=0A=
=0A=
=0A=

------_=_NextPart_001_01C61021.EC547C0D--


--===============0468614913==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0468614913==--




From ietf-bounces@ietf.org Mon Jan 02 23:55:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EteDB-0005WP-Ic; Mon, 02 Jan 2006 23:55:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EteD7-0005Tj-Lh
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 23:55:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26845
	for ; Mon, 2 Jan 2006 23:54:35 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EteIJ-0002Sz-Ej
	for ietf@ietf.org; Tue, 03 Jan 2006 00:01:12 -0500
Received: (qmail 2470 invoked by uid 100); 3 Jan 2006 04:55:32 -0000
Date: 3 Jan 2006 04:55:32 -0000
Message-ID: <20060103045532.2469.qmail@xuxa.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <7.0.0.16.2.20060102113007.05eee498@vigilsec.com>
Organization: I.E.C.C., Trumansburg NY USA
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Subject: Re: WG Review: Domain Keys Identified Mail (dkim)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>Here is the revised proposed charter text:

Thanks for pulling this together.

If I had unlimited time to waste, I might niggle about a word or two,
but it's fine as is, and I look forward to moving ahead and getting
some work done.

R's,
John


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 00:04:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EteLk-0004cG-7c; Tue, 03 Jan 2006 00:04:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EteLh-0004b5-6B
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 00:04:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28141
	for ; Tue, 3 Jan 2006 00:03:26 -0500 (EST)
Received: from mx1-b.rad.co.il ([62.219.98.8] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EteQs-00030a-R8
	for ietf@ietf.org; Tue, 03 Jan 2006 00:10:03 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k0350dYP021395
	for ; Tue, 3 Jan 2006 07:00:40 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k0350dLx021392;
	Tue, 3 Jan 2006 07:00:39 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 3 Jan 2006 07:04:23 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYP/z3Ihbb/dpdrSfCUUZIk5fxHNAAIuuZH
From: "Yaakov Stein" 
To: "Douglas Otis" , "John Levine" 
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Cc: william@elan.net, ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0467880032=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0467880032==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C61023.2978A4CA"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61023.2978A4CA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20
> Word is of course out of the question since it is proprietary,
> undocumented, and unstable.  I hope we have consensus on that.

Sorry, no such consensus.
=20
I don't see why the editor you use needs to be open-standard.
As far as I know the IETF is attempting to standardize IP-related
communications protocols, not editors.
=20
I do hope that the monitor and keyboard you are using
while reading and sending emails have their schematic diagrams
in the public domain. And please do not write any IETF documents
while using a mouse from a certain proprietary company who holds
dozens of patents on mouse technology.
=20
More seriously, Word is the only commonly used editor
with an integrated tracking mechanism. I assume that even
the purists who insist on nroff occasionally write an ID
with others. I personally prefer to use TeX as a typesetting
format when writing on my own, but use word for IDs=20
since I have to cooperate with co-authors.
=20
Y(J)S
=20
=20
=20

------_=_NextPart_001_01C61023.2978A4CA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Re: Alternative formats for IDs=0A=
=0A=
=0A=

=0A=

 
=0A=

> Word is of course out of the question =
since it is =0A=
proprietary,
> undocumented, and unstable.  I hope we have =
consensus =0A=
on that.
=0A=

Sorry, no such consensus.
=0A=

 
=0A=

I don't see why the editor you use needs =
to be =0A=
open-standard.
=0A=

As far as I know the IETF is attempting to =
standardize =0A=
IP-related
=0A=

communications protocols, not =
editors.
=0A=

 
=0A=

I do hope that the monitor and keyboard =
you are =0A=
using
=0A=

while reading and sending emails have =
their schematic =0A=
diagrams
=0A=

in the public domain. And please do not =
write any IETF =0A=
documents
=0A=

while using a mouse from a certain =
proprietary company =0A=
who holds
=0A=

dozens of patents on mouse =
technology.
=0A=

 
=0A=

More seriously, Word is the only commonly =
used =0A=
editor
=0A=

with an integrated tracking mechanism. I =
assume that =0A=
even
=0A=

the purists who insist on nroff =
occasionally write an =0A=
ID
=0A=

with others. I personally prefer to use =
TeX as a =0A=
typesetting
=0A=

format when writing on my own, but use =
word for IDs =0A=

=0A=

since I have to cooperate with =0A=
co-authors.
=0A=

 
=0A=

Y(J)S
=0A=

 
=0A=

 
=0A=

 
=0A=
=0A=
=0A=

------_=_NextPart_001_01C61023.2978A4CA--


--===============0467880032==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0467880032==--




From ietf-bounces@ietf.org Tue Jan 03 00:17:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EteYA-00042v-Jl; Tue, 03 Jan 2006 00:17:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EteY8-00041w-B4
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 00:17:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29578
	for ; Tue, 3 Jan 2006 00:16:18 -0500 (EST)
Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtedK-0003Rd-9C
	for ietf@ietf.org; Tue, 03 Jan 2006 00:22:56 -0500
Received: from [127.0.0.1] (www.caia.swin.edu.au [136.186.229.16])
	by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id QAA1032908;
	Tue, 3 Jan 2006 16:17:18 +1100 (EST)
Message-ID: <43BA08D7.8040700@swin.edu.au>
Date: Tue, 03 Jan 2006 16:17:11 +1100
From: grenville armitage 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Yaakov Stein wrote:

>  
>  > Word is of course out of the question since it is proprietary,
>  > undocumented, and unstable.  I hope we have consensus on that.
> Sorry, no such consensus.
>  
> I don't see why the editor you use needs to be open-standard.

The document format needs to be documented. (I think in the context of
this thread it is clear that "Word is... since it proprietary" was a
comment about Word's file format rather than the editor itself.)

	[..]
> I do hope that the monitor and keyboard you are using
> while reading and sending emails have their schematic diagrams
> in the public domain.

I believe most keyboards and monitors use interfaces whose definitions
are documented, available and implemented by multiple manufacturers.

cheers,
gja

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 00:23:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtedS-0005tp-Hi; Tue, 03 Jan 2006 00:23:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtedP-0005pq-Jw
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 00:22:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00158
	for ; Tue, 3 Jan 2006 00:21:45 -0500 (EST)
Received: from s2.cableone.net ([24.116.0.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eteib-0003ap-Fl
	for ietf@ietf.org; Tue, 03 Jan 2006 00:28:22 -0500
Received: from [192.168.168.10] (unverified [24.119.163.152]) 
	by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 40780699 
	for ; Mon, 02 Jan 2006 22:47:18 -0700
Message-ID: <43BA0A1F.8050207@Royer.com>
Date: Mon, 02 Jan 2006 22:22:39 -0700
From: Doug Royer 
Organization: IntelliCal.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
X-SpamDetect: *: 1.250000 NakedCR=2.0,Aspam=-0.8
X-NakedCr: Body contained naked cr characters
X-NotAscii: charset=utf-8;
X-IP-stats: Incoming Outgoing Last 0, First 14, in=71, out=54,
	spam=0 Known=true
X-External-IP: 24.119.163.152
X-Abuse-Info: Send abuse complaints to abuse@cableone.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0878410456=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a cryptographically signed message in MIME format.

--===============0878410456==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="------------ms040408090508030401020606"

This is a cryptographically signed message in MIME format.

--------------ms040408090508030401020606
Content-Type: multipart/mixed; boundary="------------020701060300030600040905"

This is a multi-part message in MIME format.
--------------020701060300030600040905
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Yaakov Stein wrote:

> I... And please do not write any IETF documents
> while using a mouse from a certain proprietary company who holds
> dozens of patents on mouse technology.

I would complain about that also, if I had to buy that mouse
in order to read a free ID.

> More seriously, Word is the only commonly used editor
> with an integrated tracking mechanism. I assume that even
> the purists who insist on nroff occasionally write an ID
> with others. I personally prefer to use TeX as a typesetting
> format when writing on my own, but use word for IDs
> since I have to cooperate with co-authors.

Try CVS or SVN and diff - works for everyone.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards


--------------020701060300030600040905
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:Doug@Royer.com
title:CEO
tel;work:866-594-8574
tel;fax:866-594-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: Support@INET-Consulting.com=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard


--------------020701060300030600040905--

--------------ms040408090508030401020606
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw
MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ
BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX
6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30
AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka
32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd
ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD
VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz
Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF
BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi
aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT
5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU
eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO
UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ
KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13
d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU
RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0
YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS
b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX
yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn
/F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc
h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5
ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX
AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI
KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G
A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD
VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq
hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+
I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK
I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI
yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTA2MDEwMzA1MjIzOVowIwYJKoZIhvcNAQkEMRYEFB/tfzSJbLS1qjWkakJLEkkV
4gAhMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG
SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw
gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y
cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB
IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp
o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl
cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5
ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt
UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA
BIIBAF/8LBnDUY9+BUqfSbVkdscqBDFY3gHLLqq94FR9JR9ayq3pY3KsUsA1rESSt+AuoNo8
EKrbWq1LHtVR0FRBynkfggNcnPOuzeXI/8ARA341g07/FlzgCb7wJL9LDeCD0STeDSYW4ybv
OwqrOUlt19Hxz4t3noesk1hlbjfxdzRDikL2K+ygCDMAQz5TvYjUxzfWhnntDfhFnPd1fC1a
yUxtD8/pifBgG9x76JW3wTSCaNSRFE/q/kpln7d+NtRGqtJyKVMOUPbtA0HGO29yf7ucDQQ7
DvFkOrtOtM0DQUY7pWt5i6JuNZUY1hNKeNHJY1+QnS9jfn+pZBp9z58ifNMAAAAAAAA=
--------------ms040408090508030401020606--


--===============0878410456==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0878410456==--




From ietf-bounces@ietf.org Tue Jan 03 00:50:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etf4G-0004Sp-Ks; Tue, 03 Jan 2006 00:50:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etf4A-0004Sk-GA
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 00:50:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03472
	for ; Tue, 3 Jan 2006 00:49:23 -0500 (EST)
Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etf9M-0004TY-Kc
	for ietf@ietf.org; Tue, 03 Jan 2006 00:56:01 -0500
Received: from h-68-165-6-123.snvacaid.dynamic.covad.net ([68.165.6.123]
	helo=oemcomputer)
	by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1Etf45-00000q-00
	for ietf@ietf.org; Tue, 03 Jan 2006 00:50:33 -0500
Message-ID: <00da01c6102a$69584060$7f1afea9@oemcomputer>
From: "Randy Presuhn" 
To: 
Date: Mon, 2 Jan 2006 21:56:15 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Subject: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi -

In http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt
section 3 says:

|   Furthermore, the authors propose that the IESG carefully consider
|   declaring consensus in support of the change even if a large number
|   of 'nays' are posted to the IESG discussion list.

I object to this text, as it might (mis)lead the reader into thinking
that the methods for declaring consensus were being modified, particularly
if this document somehow became a BCP.  To deal with this issue, I suggest
the removal of the following material from section 3:

|   Furthermore, the authors propose that the IESG carefully consider
|   declaring consensus in support of the change even if a large number
|   of 'nays' are posted to the IESG discussion list.  In that regard,
|   Henrik Levkowetz posted the following comment
|   (http://www1.ietf.org/mail-archive/web/ietf/current/msg39170.html):
|
|   "Following the debate from the sideline till now, it's clear to me
|   that there are at least a few people who are adamantly against
|   change.  I'm not at all convinced that a large majority feels this
|   way.  A poll might reveal more than the relative proportions of
|   highly engaged people voicing their views here."
|
|   Judging consensus through a poll is sometimes difficult.  There is a
|   vast "silent majority" that would support the proposed additional
|   formats, or at least not oppose them, but will not express their
|   opinion on the list.  It is much more likely to hear from the very
|   vocal people who are opposed to the change.  That is, assuming 1000s
|   of participants on the IETF discussion list, perhaps 20 expressed
|   'nays', even strong nays, could be considered a clear consensus in
|   favor of change.

Randy


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 00:56:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtfA7-0005hl-VM; Tue, 03 Jan 2006 00:56:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfA4-0005hc-Rj
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 00:56:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03935
	for ; Tue, 3 Jan 2006 00:55:30 -0500 (EST)
Received: from xenotime.net ([66.160.160.81])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtfFH-0004fG-Hi
	for ietf@ietf.org; Tue, 03 Jan 2006 01:02:08 -0500
Received: from midway ([71.111.157.99]) by xenotime.net for ;
	Mon, 2 Jan 2006 21:56:40 -0800
Date: Mon, 2 Jan 2006 21:57:19 -0800
From: "Randy.Dunlap" 
To: "Yaakov Stein" 
Message-Id: <20060102215719.40b2f490.rdunlap@xenotime.net>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
Organization: YPO4
X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: william@elan.net, ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Tue, 3 Jan 2006 07:04:23 +0200 Yaakov Stein wrote:

>  
> > Word is of course out of the question since it is proprietary,
> > undocumented, and unstable.  I hope we have consensus on that.
> 
> Sorry, no such consensus.

Well, you certainly don't have agreement/concensus that MS Word
should be used either.

> I don't see why the editor you use needs to be open-standard.
> As far as I know the IETF is attempting to standardize IP-related
> communications protocols, not editors.
>  
> I do hope that the monitor and keyboard you are using
> while reading and sending emails have their schematic diagrams
> in the public domain. And please do not write any IETF documents
> while using a mouse from a certain proprietary company who holds
> dozens of patents on mouse technology.

No need to be silly.


and from a different email from Y(J)S:
> Which is exactly the reason all the other SDOs
> use MS Word for input and PDF for output.

*all* others do?  That's hard to accept.

---
~Randy

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 00:59:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtfCx-0006ZF-8Q; Tue, 03 Jan 2006 00:59:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfCu-0006Yx-8V
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 00:59:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04283
	for ; Tue, 3 Jan 2006 00:58:25 -0500 (EST)
Received: from currant.srv.cs.cmu.edu ([128.2.194.193])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtfI6-0004mE-I8
	for ietf@ietf.org; Tue, 03 Jan 2006 01:05:04 -0500
Received: from CHOKECHERRY.SRV.CS.CMU.EDU ([128.2.185.41])
	by currant.srv.cs.cmu.edu id aa09173; 3 Jan 2006 0:59 EST
Received: from bistromath-home.pc.cs.cmu.edu
	(c-67-186-56-211.hsd1.pa.comcast.net [67.186.56.211])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id
	k035xTPU007113
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 3 Jan 2006 00:59:30 -0500 (EST)
Date: Mon, 02 Jan 2006 23:14:58 -0500
From: Jeffrey Hutzelman 
To: "Tom.Petch" , ietf maillist 
Message-ID: 
In-Reply-To: <027b01c60fdc$87e9b520$0601a8c0@pc6>
References: <009b01c60faf$4b5bd200$0300a8c0@DJYXPY41>
	
	<027b01c60fdc$87e9b520$0601a8c0@pc6>
Originator-Info: login-token=Mulberry:01hwVca/Ft0d/TUNTsuoOM2h53k5YOOdX0eorQvYU=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2,
	Antispam-Data: 2006.1.2.41
X-Spam-OK: 7%
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Monday, January 02, 2006 09:36:20 PM +0100 "Tom.Petch" 
 wrote:

> I have always thought that ASCII had much to commend it  - ease of use,
> compactness, open standard - which outweighed its limited functionality.
>
> But while we debate this, have events already overtaken us?  I was
> surprised to find, when reading
> draft-fu-nsis-qos-nslp-statemachine-02.txt
> repeated statements to the effect that if you want to see what this looks
> like, look at the .pdf version.  It would seem that the system is giving
> tacit support to .pdf (although I am cannot readily see just where the
> .pdf version is filed:-(
>
> What will anyone say when this I-D reaches last call?

Under our current process, if the responsible AD is doing his/her job, then 
the document will never _reach_ last call with normative references to 
non-ASCII content.

That is, after all, one of the major facets of the ongoing discussion.


Since someone has asked...

To a certain (large) extent, the format of IETF documents, including 
standards documents, needs to be future-proof.  That is, we need to be able 
to be reasonably sure that someone at some point in the future will still 
be able to read our documents.  There's been lots of discussion and 
arguments about how far in the future we should be worried about, and what 
level of effort is reasonable to expect of future readers, and about how 
well which formats meet these requirements.  However, I daresay there is 
rough concensus that some level of future-readability is required.

In order to achieve that future-readability, it is desirable to require our 
documents to use a specific format, or perhaps one of several specific 
formats.  Such formats should be well-documented as to their syntax and 
semantics, just as we would do for a network protocol.  It is not necessary 
to specify that documents be produced by a particular tool or that a 
particular tool be used to read them, only that they be in a particular 
form.

We don't specify network protocols in terms of specific implementations; 
why should we do so for our document formats?


-- Jeffrey T. Hutzelman (N3NHS) 
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 00:59:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtfD2-0006a3-4d; Tue, 03 Jan 2006 00:59:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfCu-0006Yy-AA
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 00:59:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04288
	for ; Tue, 3 Jan 2006 00:58:26 -0500 (EST)
Received: from currant.srv.cs.cmu.edu ([128.2.194.193])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtfI8-0004mE-5Y
	for ietf@ietf.org; Tue, 03 Jan 2006 01:05:04 -0500
Received: from CHOKECHERRY.SRV.CS.CMU.EDU ([128.2.185.41])
	by currant.srv.cs.cmu.edu id aa09175; 3 Jan 2006 0:59 EST
Received: from bistromath-home.pc.cs.cmu.edu
	(c-67-186-56-211.hsd1.pa.comcast.net [67.186.56.211])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id
	k035xTPW007113
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 3 Jan 2006 00:59:31 -0500 (EST)
Date: Mon, 02 Jan 2006 23:32:59 -0500
From: Jeffrey Hutzelman 
To: ietf@ietf.org
Message-ID: 
In-Reply-To: <626228BDFFC0A7983CF2CBC3@p3.JCK.COM>
References: <27A0F290348F8E45AEF79889DDE65A5205DCDE23@exrad2.ad.r ad.co.il>
	<626228BDFFC0A7983CF2CBC3@p3.JCK.COM>
Originator-Info: login-token=Mulberry:01X+gypslQpxqrM6onkmZiFfZaadHmHKvMXWALlWg=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2,
	Antispam-Data: 2006.1.2.41
X-Spam-OK: 7%
X-Spam-Score: 1.2 (+)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: 
Subject: participation sans meeting attendance (was RE: Alternative formats
 for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Monday, January 02, 2006 02:42:41 PM -0500 John C Klensin 
 wrote:

> Finally, there is a longstanding and more or less explicit
> decision in the IETF community to keep the costs of
> participation as low as possible and, in particular, to not have
> costs imposed by the SDO become a bar to effective
> participation.  It is getting harder --much harder than I
> personally considerable-- to participate effectively in the IETF
> without ever setting foot in a meeting, but it is still possible
> to do so.

Actually, I think that recently we've been getting _better_ in that regard, 
and I hope the trend continues:

- For several meetings, we've had jabber rooms for every session.
- More recently, we've also has streaming audio for every session.
- Chairs now have the ability to put slides online _during_ sessions.

Each of these tools has seen steadily increasing usage since its 
introduction.  These days, the chairs in nearly every session make an 
effort to find jabber scribes to report on the meeting and take questions 
from remote participants in real time.  People are getting better about 
always using the microphones, though we have a long way to go in this area. 
And, I know some groups have made an effort to get slides and presentations 
online before or during the meetings, even before the tools became 
available to conveniently do so in a standard place.

As a working group chair, I've conducted meetings in which key participants 
used these tools to effectively participate in a meeting without being 
physically present.  Of course, it doesn't scale to having _everyone_ 
participate remotely, or even a large fraction of very active participants, 
and I don't really think that would be desirable.  However, it is possible 
for large numbers of people to watch, listen, and even make an occaisonal 
comment.  I think we're doing better on this front than we have in many 
years.


-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 00:59:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtfD4-0006eO-DG; Tue, 03 Jan 2006 00:59:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfCv-0006ZA-7E
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 00:59:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04293
	for ; Tue, 3 Jan 2006 00:58:26 -0500 (EST)
Received: from currant.srv.cs.cmu.edu ([128.2.194.193])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtfI8-0004mE-L4
	for ietf@ietf.org; Tue, 03 Jan 2006 01:05:05 -0500
Received: from CHOKECHERRY.SRV.CS.CMU.EDU ([128.2.185.41])
	by currant.srv.cs.cmu.edu id aa09178; 3 Jan 2006 0:59 EST
Received: from bistromath-home.pc.cs.cmu.edu
	(c-67-186-56-211.hsd1.pa.comcast.net [67.186.56.211])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id
	k035xTPY007113
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for ; Tue, 3 Jan 2006 00:59:32 -0500 (EST)
Date: Mon, 02 Jan 2006 23:59:30 -0500
From: Jeffrey Hutzelman 
To: ietf@ietf.org
Message-ID: <3AC4FF1286781E0AD0831C12@bistromath.pc.cs.cmu.edu>
In-Reply-To: <0BAA0751-C027-4D54-B5C2-BAA893E72C55@multicasttech.com>
References: <20060102202435.5D22C86B00@mercury.lcs.mit.edu>
	<0BAA0751-C027-4D54-B5C2-BAA893E72C55@multicasttech.com>
Originator-Info: login-token=Mulberry:01Mp2W5JwFC1h+6A5lZRvGU8kPzQ+50Q+fEsRJaB0=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2,
	Antispam-Data: 2006.1.2.41
X-Spam-OK: 7%
X-Spam-Score: 1.2 (+)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Monday, January 02, 2006 04:03:54 PM -0500 Marshall Eubanks 
 wrote:

> It seems that the library community has settled on PDF as its long  term
> storage choice, and  is
> moving to standardize this.
>
>  From Harvard University's Report to the Digital Library Federation,
> October, 2004 :
> http://www.diglib.org/pubs/news05_01/harvardnews5.htm
>
> PDF/A
>
> Adobe's Portable Document Format (PDF) has become the de-facto  standard
> for web-based delivery of electronic documents. The  International
> Organization for Standardization (ISO) has initiated an  effort to create
> an standard for an archival profile of PDF that is  amendable for
> long-term preservation. This standard, PDF/A, is  intended to provide an
> unambiguous definition of the requirements  necessary for the reliable
> and predictable future rendering of  archived PDF documents. The second
> draft of the PDF/A standard was  released in May 2004 and is currently
> undergoing a comment period by  experts from the constituent national
> bodies of ISO. Stephen Abrams,  the LDI Digital Library Program Manager
> at Harvard University, is the  project leader and document editor for the
> ISO PDF/A joint working  group.

I think you're drawing too many conclusions from that report.
The report you quoted comes from the newsletter of a small consortium of 
libraries focused specifically on "digital library" issues, which largely 
(though not entirely) consists of storing, handling, and making available 
digital representations of traditional-format works.  It _may_ represent 
the consensus of that small consortium, but there is no evidence to 
indicate that it represents the opinion of librarians at large -- most of 
whom have no more expertise than we in the management and storage of data.

Further, the article does not say that the library community or the DLF has 
settled on PDF as its long-term storage format, or that it is moving to 
standardize it.  What it does say is:

- PDF has become the de-facto standard for _delivery_ of documents.
  This is arguably true, at least for the sort of documents they're
  interested in, and for cases where reproducing the precise appearance
  of a document is considered important.

- The ISO (not the library community) has initiated an effort to produce
  a standard profile of PDF suitable for archival use (_not_ an effort to
  cause any particular community to adopt such a format).



I agree that it is desirable to avoid gratuitously re-inventing the wheel. 
I don't think anyone here has suggested developing a new document format at 
all, let alone one specifically for IETF documents.  Several people have 
suggested adopting particular existing formats, but that is not 
re-inventing the wheel.  And those who have made the "archival format" 
argument most strenuously have also argued for retaining the current 7-bit 
ASCII format, a wheel which has been around for considerably longer than 
PDF/A.


The IETF has thrived for many years using a document format which is easy 
to produce, view, and edit on virtually any platform, and easy to 
distribute via virtually any means.  I'm not saying there is no room for 
change, but any new format needs to do reasonably well with respect to both 
of these properties -- only having one is _not_ sufficient.



Oh, one more thing.  The most widely-used archival form in use at libraries 
I've visited has been written or printed words on paper.  This form has 
much going for it -- it can represent any character set humans have ever 
used, can contain any diagram, and does not require any special software to 
to view or produce.  Editing is a bit of a pain, though, and its damned 
inconvenient to distribute, so this is probably not the best document 
format for the IETF.

But as John points out, it is what most other SDO's have been using. 
Sometimes being different doesn't mean you're wrong, just that you're ahead 
of your time.


-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 00:59:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtfD6-0006ey-Jw; Tue, 03 Jan 2006 00:59:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfD3-0006eC-LR
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 00:59:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04308
	for ; Tue, 3 Jan 2006 00:58:35 -0500 (EST)
Received: from currant.srv.cs.cmu.edu ([128.2.194.193])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtfIH-0004mi-Gd
	for ietf@ietf.org; Tue, 03 Jan 2006 01:05:13 -0500
Received: from CHOKECHERRY.SRV.CS.CMU.EDU ([128.2.185.41])
	by currant.srv.cs.cmu.edu id aa09180; 3 Jan 2006 0:59 EST
Received: from bistromath-home.pc.cs.cmu.edu
	(c-67-186-56-211.hsd1.pa.comcast.net [67.186.56.211])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id
	k035xTPa007113
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 3 Jan 2006 00:59:33 -0500 (EST)
Date: Tue, 03 Jan 2006 00:59:29 -0500
From: Jeffrey Hutzelman 
To: dcrocker@bbiw.net, John C Klensin 
Message-ID: <3FA36D130249957A8B65ABD8@bistromath.pc.cs.cmu.edu>
In-Reply-To: <43BA02C8.1050300@dcrocker.net>
References: <20060101043514.6985.qmail@xuxa.iecc.com>
	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>
	
	<416F6B6F46586EDBC9410701@p3.JCK.COM>	<43B89C0B.1090105@dcrocker.net>
	<10BF89812A7939DA95EAA4D3@p3.JCK.COM> <43BA02C8.1050300@dcrocker.net>
Originator-Info: login-token=Mulberry:012pt2TUQD68Em5u7ODRmmvHENrXhhz+9HEKSyEBs=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2,
	Antispam-Data: 2006.1.2.41
X-Spam-OK: 7%
X-Spam-Score: 1.2 (+)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Monday, January 02, 2006 08:51:20 PM -0800 Dave Crocker 
 wrote:

>>     I don't
>> believe we have ever turned "winning by exhaustion" or "winning
>> by intimidation" into virtues, even though those techniques are
>
> Actually we have.
>
> It is used with some regularity by various folk in IETF management, in
> lieu of honoring the requirements of "plausible" that I provided above.

If that's true (and I'm not expressing any opinion as to whether it is), 
that doesn't make it a virtue.



> Note the change that Russ is making to the charter.

I think a lot of people might be missing a key point about how our process 
works.  In fact, it's looked that way to me for a while, and so since you 
bring it up, I'll try to clear things up for anyone who might be confused. 
Please don't think I'm singling you out...


RFC2418 says:

   The formation of a working group requires a charter which is
   primarily negotiated between a prospective working group Chair and
   the relevant Area Director(s), although final approval is made by the
   IESG with advice from the Internet Architecture Board (IAB).  A
   charter is a contract between a working group and the IETF to perform
   a set of tasks.

According to my reading of that document, it is up to the IESG whether to 
approve a charter, and with what language.  Announcement to ietf-announce 
and new-work is required; discussion on the IETF list is not.  The content 
of a charter is determined by the IESG, not by a consensus of the group 
wishing to be chartered.

In other words, Russ is within his rights to make changes to the charter he 
is willing to bring to the IESG -- especially in a case such as this where 
the proposed charter has been discussed so publicly that the rest of the 
IESG cannot possibly be deceived into thinking the charter Russ brings them 
is exactly the one the DKIM proponents proposed.

This ability to determine what work will be done and under what terms is a 
fundamental part of what it means to "steer"; without it, the IESG would 
not be much of a "steering group".



In this case, particularly given the comments I've seen from a number of 
DKIM's proponents, I feel it is appropriate to constrain the group to 
produce a specification for attempting to address a particular aspect of 
the spam problem using a particular approach.  It's beneficial to apply 
constraints like only considering solutions with domain-level granularity, 
or only addressing how to _provide_ identity information and not what to do 
with it.  Particularly given the IETF's previous experience with attempted 
anti-spam work, I think such constraints are necessary to narrow the 
problem space to one for which a working group will produce something in a 
finite time.

Besides being necessary, those constraints are also acceptable because 
while they limit _this_ working group to solving one piece of the problem, 
there is no implication that other working groups will not be chartered to 
work on other pieces.  And, while _this_ working group is constrained to a 
particular approach, there is no implication that other approaches might 
not also be tried.  In fact, there seems to be the idea that multiple 
approaches could be deployed simultaneously, that doing so would likely be 
beneficial rather than harmful, and that developing one approach is likely 
to enable or at least benefit work on other parts of the problem.

So far, so good, I think.  I'm assuming you agree with me that constraints 
such as the one I've described are reasonable; please let me know if that's 
incorrect.


What I do _not_ think is reasonable is a demand that the working group be 
constrained to produce exactly the protocol proposed, making changes only 
if absolutely necessary.  If it is to produce a standards-track-quality 
protocol, the working group must have the freedom to correct flaws it 
identifies and to make improvements, even if not "absolutely necessary". 
Of course, it is reasonable to instruct the working group to start with an 
existing proposal.  It's reasonable to require it to maintain 
interoperability with an existing standard, or even to exclude changes to 
an existing standard from its scope.  But even that must be done with care; 
often a good solution involves an extension to one or more existing 
protocols.

Note that the XMPP case is somewhat different from this one.  In that case, 
a working group was formed to "adopt" an existing technology from another 
process, and develop an Internet standard.  High value was placed on 
compatibility with the existing widely-deployed protocol, which is 
appropriate and the same treatment we'd give to our own existing standards, 
or expect other SDO's to give them.

As I understand it, DKIM is _not_ a widely-deployed protocol developed by 
another SDO; it is a proposal developed by a design team with the specific 
intent of bringing it to the IETF.  There is absolutely nothing wrong with 
that approach.  However, the normal next step is to bring the design team 
output back to a working group, or to the IETF as a whole, and ask for 
comments and/or consensus to use the design team's output as input to the 
next step in the process.

In this case, it appears that instead of doing that, the design team is 
asking the _IESG_ to make the decision that the design team's work will be 
used for the next step in the process, without the benefit of working group 
or unconstrained consensus.  I must confess that I find that behavior 
shocking, given how bitterly some of the people involved have complained 
about IETF management rushing things through without benefit of community 
consensus.

Is there some concern among the proponents of this working group that 
without a tight constraint to make only minimal changes to the proposal, 
the WG will throw it away and start over from scratch?  I understand that 
doing so would be a huge waste of time, but given constraints on both the 
scope of the problem and the range of solutions, why is a tighter 
constraint necessary to prevent the disaster?


Dave, I confess I haven't read to the end of your message, but it's getting 
late and I'd like to get up _before_ noon, for a change.  Tomorrow I will 
finish reading, and perhaps comment on the rest...

-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 01:03:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtfGU-000079-In; Tue, 03 Jan 2006 01:03:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfGR-00005S-86
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 01:03:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04917
	for ; Tue, 3 Jan 2006 01:02:04 -0500 (EST)
Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtfLe-00050Q-TH
	for ietf@ietf.org; Tue, 03 Jan 2006 01:08:43 -0500
Received: from h-68-165-6-123.snvacaid.dynamic.covad.net ([68.165.6.123]
	helo=oemcomputer)
	by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10)
	id 1EtfGP-0002bx-00
	for ietf@ietf.org; Tue, 03 Jan 2006 01:03:17 -0500
Message-ID: <015f01c6102c$36b86f20$7f1afea9@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <27A0F290348F8E45AEF79889DDE65A5201861028@exrad2.ad.rad.co.il>
Date: Mon, 2 Jan 2006 22:09:10 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi -

I, too, have participated in other SDOs where, to a greater or lesser extent,
Word documents were used.  The experience was often bad; the shortcomings
of that particular tool for editing large or complex specifications (e.g., some
of those related to CMIP and GDMO) caused much grief.  Version compatibility
problems, both for Word and PDF, also wasted much time.  No good came of
it, and much bad, including some virus outbreaks caried by Word files exchanged
on floppies at editing meetings. Let's not repeat those mistakes.

If folks have high hopes for ISO 19005-1 or some other PDF flavor, let's
give them a short time, say five years, to see whether those formats prove
to be truly stable.  If they do, then committing to them might make sense.

Randy


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 01:05:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtfIe-0001jU-8P; Tue, 03 Jan 2006 01:05:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfIa-0001en-WE
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 01:05:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05318
	for ; Tue, 3 Jan 2006 01:04:18 -0500 (EST)
Received: from currant.srv.cs.cmu.edu ([128.2.194.193])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EtfNo-00058a-QU
	for ietf@ietf.org; Tue, 03 Jan 2006 01:10:57 -0500
Received: from CHOKECHERRY.SRV.CS.CMU.EDU ([128.2.185.41])
	by currant.srv.cs.cmu.edu id aa09212; 3 Jan 2006 1:05 EST
Received: from bistromath-home.pc.cs.cmu.edu
	(c-67-186-56-211.hsd1.pa.comcast.net [67.186.56.211])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id
	k0365MCL007122
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Tue, 3 Jan 2006 01:05:23 -0500 (EST)
Date: Tue, 03 Jan 2006 01:05:22 -0500
From: Jeffrey Hutzelman 
To: Randy Presuhn , ietf@ietf.org
Message-ID: <3607A154E1FD78B2A318CF71@bistromath.pc.cs.cmu.edu>
In-Reply-To: <00da01c6102a$69584060$7f1afea9@oemcomputer>
References: <00da01c6102a$69584060$7f1afea9@oemcomputer>
Originator-Info: login-token=Mulberry:01yKUDLjINeKIU8Huv+yMznV8XOllP2Xw1GjGT/iU=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2,
	Antispam-Data: 2006.1.2.41
X-Spam-OK: 7%
X-Spam-Score: 1.2 (+)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Monday, January 02, 2006 09:56:15 PM -0800 Randy Presuhn 
 wrote:

> Hi -
>
> In http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt
> section 3 says:
>
>|   Furthermore, the authors propose that the IESG carefully consider
>|   declaring consensus in support of the change even if a large number
>|   of 'nays' are posted to the IESG discussion list.
>
> I object to this text, as it might (mis)lead the reader into thinking
> that the methods for declaring consensus were being modified, particularly
> if this document somehow became a BCP.  To deal with this issue, I suggest
> the removal of the following material from section 3:

Agree.  If the authors actually wish to propose a change to the way 
consensus is determined in the IETF, then they should do so in a separate 
document.  Naturally, like any process change in any organization, such a 
change would have to be made under the _existing_ process before it could 
take effect.

-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 01:21:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtfXz-0006lE-B7; Tue, 03 Jan 2006 01:21:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfXw-0006gG-0b
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 01:21:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07273
	for ; Tue, 3 Jan 2006 01:20:08 -0500 (EST)
Received: from mx1-b.rad.co.il ([62.219.98.8] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etfd8-0005kO-IA
	for ietf@ietf.org; Tue, 03 Jan 2006 01:26:47 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k036HNYL027056
	for ; Tue, 3 Jan 2006 08:17:23 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k036HNLx027053
	for ; Tue, 3 Jan 2006 08:17:23 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jan 2006 08:21:07 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5205DCDF76@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYQJjqPqgp4HRqzQAWwokebrPA98AABrgnQ
From: "Yaakov Stein" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: quoted-printable
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

=20

> Try CVS or SVN and diff - works for everyone.

Sorry, although I have such toys on my home computer
I am not allowed to install such unsupported SW
on my work computer.=20

Also, please do not tell me that there is C code available.=20
C was a proprietary language designed by AT&T in order to=20
help porting their OS from the proprietary PDP-11 to other=20
proprietary computers.

(tongue only weakly in cheek)

Y(J)S


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 01:28:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtfeV-0000LD-Rz; Tue, 03 Jan 2006 01:28:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfeS-0000FD-5p
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 01:28:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07965
	for ; Tue, 3 Jan 2006 01:26:52 -0500 (EST)
Received: from mx1-b.rad.co.il ([62.219.98.8] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etfja-0005yz-B9
	for ietf@ietf.org; Tue, 03 Jan 2006 01:33:31 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k036O0YN027706
	for ; Tue, 3 Jan 2006 08:24:01 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k036NxLx027702;
	Tue, 3 Jan 2006 08:23:59 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jan 2006 08:27:43 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5205DCDF7B@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYQK29e77KMu+FDRRal0hmn/MGHAQAAp/QA
From: "Yaakov Stein" 
To: "Jeffrey Hutzelman" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

=20
The IETF has thrived for many years using a document format which is
easy to produce, view, and edit on virtually any platform, and easy to
distribute via virtually any means.  I'm not saying there is no room for
change, but any new format needs to do reasonably well with respect to
both of these properties -- only having one is _not_ sufficient.

[YJS] That is the whole problem. ASCII is NOT easy to produce,
it is close to impossible to produce with others,
and it is mind-breakingly frustrating to include even the
simplest figure. Until the tool team and others came up
with an on-line PDF converter it was also extremely
difficult and time-consuming to print.=20

Alternatively, it can be created using nroff,
(nroff: noun an obscure outdated mark-up language)
or by XML which was never meant to be a typesetting
language and requires installing a medley of tools
that don't work well together and also does not support
even simple graphics. Neither of these has any support=20
for cooperative work.

You must be using some new meaning for the word "easy"
that I haven't come across yet.

Y(J)S

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 01:37:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtfnN-0006ML-B8; Tue, 03 Jan 2006 01:37:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtfnI-0006Le-R4
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 01:37:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08699
	for ; Tue, 3 Jan 2006 01:36:02 -0500 (EST)
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtfsV-0006H1-Sp
	for ietf@ietf.org; Tue, 03 Jan 2006 01:42:41 -0500
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id 5C39F898C7;
	Tue,  3 Jan 2006 08:36:59 +0200 (EET)
Message-ID: <43BA1BAA.6040506@piuha.net>
Date: Tue, 03 Jan 2006 08:37:30 +0200
From: Jari Arkko 
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yaakov Stein 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF76@exrad2.ad.rad.co.il>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDF76@exrad2.ad.rad.co.il>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Diff tools (Was: Re: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Yaakov,

>>Try CVS or SVN and diff - works for everyone.
>>    
>>
>
>Sorry, although I have such toys on my home computer
>I am not allowed to install such unsupported SW
>on my work computer. 
>  
>
Fortunately, there's still a solution for you.
You can run the diff tools even in the web, e.g.,
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht

Personally, I like the diff tools better than the
integrated support in Word, because they work
entirely on the result, and don't care if someone
(a) forgot to set the change tracking on (b) changed
text but changed it back too or (c) copied entire
paragraphs or sections from list e-mails or
text sent by co-authors not working with Word.

Hope this helps,

--Jari


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 01:42:49 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etfse-00011h-UH; Tue, 03 Jan 2006 01:42:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etfsa-0000yt-L9
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 01:42:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09269
	for ; Tue, 3 Jan 2006 01:41:29 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etfxm-0006Ru-NQ
	for ietf@ietf.org; Tue, 03 Jan 2006 01:48:09 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 3A4392596FB;
	Tue,  3 Jan 2006 07:41:37 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 10781-03; Tue,  3 Jan 2006 07:41:33 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id B699B2596EF;
	Tue,  3 Jan 2006 07:41:33 +0100 (CET)
Date: Tue, 03 Jan 2006 07:46:10 +0100
From: Harald Tveit Alvestrand 
To: Yaakov Stein , Spencer Dawkins , 
	ietf@ietf.org
Message-ID: 
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: 
Subject: RE: Consensus based on reading tea leaves (was:
 Re:	Alternativeformatsfor IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein  
wrote:

> The only thing I am sure about is
> that
> consensus on this list is for keeping everything exactly as it is.

I'm pretty sure there's no such consensus.

I do, however, see a rather strong consensus-of-the-speakers against using 
MS-Word document format for anything "official".




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 01:50:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etfzl-0002zm-F3; Tue, 03 Jan 2006 01:50:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etfzi-0002xA-1n
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 01:50:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10012
	for ; Tue, 3 Jan 2006 01:48:51 -0500 (EST)
Received: from tom.iecc.com ([208.31.42.38])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Etg4w-0006fn-9o
	for ietf@ietf.org; Tue, 03 Jan 2006 01:55:30 -0500
Received: (qmail 5718 invoked from network); 3 Jan 2006 06:50:04 -0000
Received: (ofmipd 127.0.0.1); 3 Jan 2006 06:49:42 -0000
Date: 3 Jan 2006 01:50:03 -0500
Message-ID: 
From: "John R Levine" 
To: "Yaakov Stein" 
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> > undocumented, and unstable.  I hope we have consensus on that.
> Sorry, no such consensus.

No problem.  We've taken your tip and redefined consensus to exclude
anyone who disagrees with us.

> I don't see why the editor you use needs to be open-standard.

Actually, I don't care what editor you use and I doubt that anyone else
does, either.  I do care quite a lot what document formats you expect me
to deal with, and for reasons that other people have already explained,
undocumented, unstable, proprietary formats are non-starters for archival
documents such as RFCs.

> More seriously, Word is the only commonly used editor with an integrated
> tracking mechanism. I assume that even the purists who insist on nroff
> occasionally write an ID with others.

Indeed we do, and we appreciate the fact that Emacs integrates so well
with RCS and CVS.

What I see here is severe confusion between tools and formats, and a lack
of clarity about input and output formats.  I happen to write entire books
with other authors and editors, and although I am often stuck using Word
as an input format because that is the only editor they know, I cannot
begin to tell you how badly Word stinks for the purpose, particularly if I
need to do something with a document other than print it out.  I have
written whole books in subset troff and then mechanically translated it to
other formats such as RTF for the Word crowd, because the tools I can use
on ASCII files with explicit markup are so much better than the feeble set
that work on Word files.

Of the various additional formats people have proposed, the only one that
makes sense for I-D's is RFC2629 XML.  It's well specified, and it's ASCII
underneath so we can be confident it'll be readable in the future even if
our tools get lost.  If you want to use Word to edit it, fine, go hire
someone to write a Word converter for it.  (Best not to say "oh, that
would cost too much" unless you want to hear a whole lot of snickering.)

Since XML can be kind of hard to read, PDF/A is a reasonable alternate
presentation format, but I would be happier if every PDF/A I-D and RFC had
to come with an XML original so we can edit it reasonably.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I shook hands with Senators Dole and Inouye," said Tom, disarmingly.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 01:52:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etg2D-0004Lc-Tg; Tue, 03 Jan 2006 01:52:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etg2A-0004LR-Ul
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 01:52:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10237
	for ; Tue, 3 Jan 2006 01:51:24 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etg7P-0006li-3X
	for ietf@ietf.org; Tue, 03 Jan 2006 01:58:03 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id D12512596FD;
	Tue,  3 Jan 2006 07:51:33 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 10781-07; Tue,  3 Jan 2006 07:51:27 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 713132596FB;
	Tue,  3 Jan 2006 07:51:27 +0100 (CET)
Date: Tue, 03 Jan 2006 07:56:03 +0100
From: Harald Tveit Alvestrand 
To: Yaakov Stein , ietf@ietf.org
Message-ID: <1F114D8E60BD5DCD1CDF31A5@svartdal.hjemme.alvestrand.no>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDF76@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF76@exrad2.ad.rad.co.il>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: 
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On tirsdag, januar 03, 2006 08:21:07 +0200 Yaakov Stein 
 wrote:

>
>
>> Try CVS or SVN and diff - works for everyone.
>
> Sorry, although I have such toys on my home computer
> I am not allowed to install such unsupported SW
> on my work computer.




According to google, "subversion support" turns up mostly web hosting 
services that support it.

>
> (tongue only weakly in cheek)
>

careful. you might bite it.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 01:56:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etg6F-0007FG-Og; Tue, 03 Jan 2006 01:56:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etg6D-0007AE-4M
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 01:56:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10888
	for ; Tue, 3 Jan 2006 01:55:31 -0500 (EST)
Received: from smtp2.stanford.edu ([171.67.16.125])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtgBN-0006w1-Up
	for ietf@ietf.org; Tue, 03 Jan 2006 02:02:10 -0500
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147])
	by smtp2.Stanford.EDU (8.12.11/8.12.11) with ESMTP id k036uTfV013697
	for ; Mon, 2 Jan 2006 22:56:29 -0800
Received: by windlord.stanford.edu (Postfix, from userid 1000)
	id 77EEFE87C6; Mon,  2 Jan 2006 22:56:29 -0800 (PST)
From: Russ Allbery 
To: ietf@ietf.org
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDF7B@exrad2.ad.rad.co.il>
	(Yaakov Stein's message of "Tue, 3 Jan 2006 08:27:43 +0200")
Organization: The Eyrie
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF7B@exrad2.ad.rad.co.il>
Date: Mon, 02 Jan 2006 22:56:29 -0800
Message-ID: <87vex14x5u.fsf@windlord.stanford.edu>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Yaakov Stein  writes:

> Alternatively, it can be created using nroff, (nroff: noun an obscure
> outdated mark-up language) or by XML which was never meant to be a
> typesetting language and requires installing a medley of tools that
> don't work well together and also does not support even simple
> graphics.

While I was installing xml2rfc and Tcl to convert XML into text and to
HTML, fully supporting accompanying graphics, I failed to notice all of
these drawbacks that you seem to believe exist.  In fact, I believe my
entire interaction with this medley of tools with their extensive problems
consisted of:

    aptitude install xml2rfc
    xml2rfc protocol.xml protocol.txt
    xml2rfc protocol.xml protocol.html

Somehow this failed to frighten me off.

> Neither of these has any support for cooperative work.

There is dedicated software for this purpose that works quite well.  Your
inability to install it on your work computers due to local policies is of
about as much interest to me as my inability to install Word because I
don't use a platform to which it has been ported probably is to you.

-- 
Russ Allbery (rra@stanford.edu)             

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 02:01:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtgB6-0002gs-5K; Tue, 03 Jan 2006 02:01:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtgB1-0002dc-OK
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 02:01:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11580
	for ; Tue, 3 Jan 2006 02:00:32 -0500 (EST)
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtgGE-00077m-UD
	for ietf@ietf.org; Tue, 03 Jan 2006 02:07:12 -0500
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id 1720A898C7;
	Tue,  3 Jan 2006 09:01:37 +0200 (EET)
Message-ID: <43BA2170.9080002@piuha.net>
Date: Tue, 03 Jan 2006 09:02:08 +0200
From: Jari Arkko 
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yaakov Stein 
References: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201861029@exrad2.ad.rad.co.il>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: william@elan.net, ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Yaakov,

> > Word is of course out of the question since it is proprietary,
> > undocumented, and unstable.  I hope we have consensus on that.
> Sorry, no such consensus.

If you truly want to improve the IETF document format,
may I suggest that we drop the fighting on formats
that are known to be controversial, and concentrate on
finding solutions that have some likelihood of being
acceptable. For instance, we've got people backing
proposals involving PDF/A and HTML, possibly in
combination with XML. If we had a new proposal on
the table with the details it would be more constructive
to continue this discussion.

--Jari


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 05:22:11 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtjIx-0006xe-Cl; Tue, 03 Jan 2006 05:22:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtjIu-0006wc-IV
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 05:22:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03157
	for ; Tue, 3 Jan 2006 05:20:54 -0500 (EST)
Received: from dns2.dns.imagine.ie ([87.232.1.41] helo=relay.imagine.ie)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtjO8-0005MD-0Y
	for ietf@ietf.org; Tue, 03 Jan 2006 05:27:35 -0500
Received: from mail2.int.imagine.ie (mail2 [87.232.1.153])
	by relay.imagine.ie (Postfix) with ESMTP id 54B804065;
	Tue,  3 Jan 2006 10:21:32 +0000 (GMT)
Received: from [127.0.0.1] (dsl-102-234.cust.imagine.ie [87.232.102.234])
	by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id
	k03ALSRI024768; Tue, 3 Jan 2006 10:21:31 GMT
Message-ID: <43BA5023.1020800@cs.tcd.ie>
Date: Tue, 03 Jan 2006 10:21:23 +0000
From: Stephen Farrell 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeffrey Hutzelman 
References: <20060101043514.6985.qmail@xuxa.iecc.com>	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>		<416F6B6F46586EDBC9410701@p3.JCK.COM>	<43B89C0B.1090105@dcrocker.net>	<10BF89812A7939DA95EAA4D3@p3.JCK.COM>
	<43BA02C8.1050300@dcrocker.net>
	<3FA36D130249957A8B65ABD8@bistromath.pc.cs.cmu.edu>
In-Reply-To: <3FA36D130249957A8B65ABD8@bistromath.pc.cs.cmu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00] 
X-Canit-Stats-ID: 221196 - d8c30bc950b7 (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



Jeffrey Hutzelman wrote:
> 
> 
> On Monday, January 02, 2006 08:51:20 PM -0800 Dave Crocker 
>  wrote:
> 
>>>     I don't
>>> believe we have ever turned "winning by exhaustion" or "winning
>>> by intimidation" into virtues, even though those techniques are
>>
>>
>> Actually we have.
>>
>> It is used with some regularity by various folk in IETF management, in
>> lieu of honoring the requirements of "plausible" that I provided above.
> 
> If that's true (and I'm not expressing any opinion as to whether it is), 
> that doesn't make it a virtue.
> 
>> Note the change that Russ is making to the charter.
> 
> I think a lot of people might be missing a key point about how our 
> process works.  In fact, it's looked that way to me for a while, and so 
> since you bring it up, I'll try to clear things up for anyone who might 
> be confused. Please don't think I'm singling you out...
[...]
> In other words, Russ is within his rights to make changes to the charter 
> he is willing to bring to the IESG -- especially in a case such as this 
> where the proposed charter has been discussed so publicly that the rest 
> of the IESG cannot possibly be deceived into thinking the charter Russ 
> brings them is exactly the one the DKIM proponents proposed.

I agree. As I believe do a number of other dkim "proponents", most
of whom are, I'd say, much less concerned about these (IMO mainly
process-nit) issues with the charter text and who'd like to get on
with the work in a working group with all that that entails - most
especially including establishing wg-consensus on the text of the
chartered deliverables.

Stephen.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 06:20:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtkDB-0007a4-6g; Tue, 03 Jan 2006 06:20:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtkD8-0007Zt-7X
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 06:20:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10159
	for ; Tue, 3 Jan 2006 06:19:00 -0500 (EST)
From: Pasi.Eronen@nokia.com
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtkIO-00076e-Io
	for ietf@ietf.org; Tue, 03 Jan 2006 06:25:41 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k03BFwkw023774; Tue, 3 Jan 2006 13:15:59 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Jan 2006 13:20:12 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Jan 2006 13:20:11 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jan 2006 13:20:08 +0200
Message-ID: 
In-Reply-To: 
Thread-Topic: IETF Last Call: draft-salowey-tls-ticket-06.txt
Thread-Index: AcYOejNH1GTew+JeSI2NRuiPrN4SHQB3VnhA
To: 
X-OriginalArrivalTime: 03 Jan 2006 11:20:11.0174 (UTC)
	FILETIME=[A917B460:01C61057]
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: IETF Last Call: draft-salowey-tls-ticket-06.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bernard Aboba wrote:

> From what I can see, the Ticket structure does not uniquely
> identify the ticket type or ticket version, so that there is no
> easy way for the server to determine what type of ticket has been
> submitted to it, or whether the client is using the recommended
> format or not.  The server checks the mac in the last 20 octets,
> and if this is valid, then it decrypts the encrypted_state.
> However, if the client were using the same mac, but a different
> ticket format, the mac could check out, but the StatePlaintext
> would not match.  A Ticket Type/Version field would make it clear
> to the server whether it is handling a Ticket of known type.

The MAC will check out only if the servers are using the same key. =20
If the servers regularly generate new keys (as is suggested in the
document, although not with an uppercase keyword), this implies either
that they have different keys (so MAC won't match and the server won't
attempt to interpret the ticket) or there's some server-to-server key
distribution mechanism between cluster members.

Any server-to-server protocols are very much beyond the scope of
this document, so we don't expect any interoperability there. =20

But perhaps the document should contain more explicit requirements
about key management (e.g. the keys used to protect the tickets
must not be used for any other purpose, including sharing with other
non-identical nodes)...

> > What the specification does not currently have is a detailed
> > "instructions for those who want to design their own ticket
> > format" section. Personally I do not think it would be a very
> > useful thing to include. It might actually encourage people to
> > design their own ticket formats, and there's no way the section
> > could cover all the possible ways to get things wrong :-)
>=20
> The problem is that without normative language, almost any
> implementation can claim compliance, regardless of whether they=20
> use the recommended ticket format or heed the security=20
> considerations.

It's certainly true that "implements all the MUSTs in the document"
does not imply the system is secure, but that applies pretty much=20
to any document (unless it says "the system MUST be secure" :-).=20

> The server might at some point want to change algorithms for all
> clients, no? Or might it not want to be able to verify that the
> ticket was constructed using algorithms that it supports?  Or even
> that the ticket utilizes the format recommended in this
> specification, as opposed to another format?

Yes, changing the algorithm for all clients is a realistic
possibility. But if you generate new keys when you change the
algorithm (which you really should do anyway), then it's enough=20
to verify that the MAC is correct (if it isn't, it isn't really=20
important to know why it was not correct).

> > The recommended ticket construction does include a timestamp=20
> > saying when the ticket was issued.=20
>=20
> If a client submits a ticket that is unacceptable to the=20
> server for some reason (expired, not the right format, etc.)=20
> does it get back an error message letting it know whether=20
> to continue to cache the ticket?=20
>=20
> For example, if the server understands the ticket and says it=20
> has expired, this is different from not being able to understand=20
> the ticket.=20

Currently, there are not special error messages to communicate why the
ticket was not accepted, since I don't think the client really needs
to know the reason. If the ticket is not accepted, the server simply
starts full TLS handshake, and once that's done, may either send a new
ticket, or indicate that it doesn't want to use "stateless session
resumption" this time (by sending a zero-length ticket).

Best regards,
Pasi

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 06:24:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtkGq-00084m-4R; Tue, 03 Jan 2006 06:24:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtkGn-00084U-A7
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 06:24:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10711
	for ; Tue, 3 Jan 2006 06:22:46 -0500 (EST)
From: Pasi.Eronen@nokia.com
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtkM2-0007G4-CQ
	for ietf@ietf.org; Tue, 03 Jan 2006 06:29:27 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k03BNvi2027771; Tue, 3 Jan 2006 13:23:58 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Jan 2006 13:23:58 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Jan 2006 13:23:57 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jan 2006 13:23:54 +0200
Message-ID: 
In-Reply-To: 
Thread-Topic: IETF Last Call: draft-salowey-tls-ticket-06.txt
Thread-Index: AcYPK/wn+BGLpcQvSmePHb9hymeA0ABK7qew
To: , 
X-OriginalArrivalTime: 03 Jan 2006 11:23:57.0509 (UTC)
	FILETIME=[2FFFAF50:01C61058]
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: IETF Last Call: draft-salowey-tls-ticket-06.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bernard Aboba wrote:

> If a client obtains a ticket from Server A, running software
> version X, and then sends it to server B, running software
> version Y, how is Server B supposed to figure out that it is the
> wrong version?

This becomes a problem only if the servers are using the same key
to MAC the tickets. (If they're using different keys, the MAC=20
won't match anyway, and server B doesn't need to know what version=20
server A is using.)

But you're quite right, this could be a problem if one shares
the keys in heterogeneous environment, and the document should
probably warn about this.

Best regards,
Pasi

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 06:57:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtknZ-00005D-I7; Tue, 03 Jan 2006 06:57:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtknW-000050-Rb
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 06:57:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13701
	for ; Tue, 3 Jan 2006 06:56:36 -0500 (EST)
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etksm-0008EY-Go
	for ietf@ietf.org; Tue, 03 Jan 2006 07:03:17 -0500
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id 2CA55898C9;
	Tue,  3 Jan 2006 13:57:35 +0200 (EET)
Message-ID: <43BA66CE.4030408@piuha.net>
Date: Tue, 03 Jan 2006 13:58:06 +0200
From: Jari Arkko 
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pasi.Eronen@nokia.com
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, aboba@internaut.com
Subject: Re: IETF Last Call: draft-salowey-tls-ticket-06.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Pasi,

>The MAC will check out only if the servers are using the same key.  
>If the servers regularly generate new keys (as is suggested in the
>  
>
Yes.

>But perhaps the document should contain more explicit requirements
>about key management (e.g. the keys used to protect the tickets
>must not be used for any other purpose, including sharing with other
>non-identical nodes)...
>  
>
This change would be useful, I think. I would also like
to see the MAC/encryption-keys-are-independent requirement
that Bernard was talking about.

>Yes, changing the algorithm for all clients is a realistic
>possibility. But if you generate new keys when you change the
>algorithm (which you really should do anyway), then it's enough 
>to verify that the MAC is correct (if it isn't, it isn't really 
>important to know why it was not correct).
>  
>
Doesn't the key_version field also provide a hint
as to whether the ticket is something that you
can recognize? Presumably, you could have multiple
versions, if you wanted to support old/new algorithms
and associated keys for a while...

In any case, it seems that it would be useful to add
a requirement that new keys and key_version values
be generated upon algorithm/format changes.

--Jari


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 07:23:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtlCY-00062N-EM; Tue, 03 Jan 2006 07:23:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtlCV-0005zi-KV
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 07:23:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16059
	for ; Tue, 3 Jan 2006 07:22:25 -0500 (EST)
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtlHl-0000XA-Mz
	for ietf@ietf.org; Tue, 03 Jan 2006 07:29:07 -0500
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id DE30F898CE;
	Tue,  3 Jan 2006 14:23:28 +0200 (EET)
Message-ID: <43BA6CE0.9090208@piuha.net>
Date: Tue, 03 Jan 2006 14:24:00 +0200
From: Jari Arkko 
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Clint Chaplin 
References: 	
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: WG Review: EAP Method Update (emu)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Clint Chaplin wrote:

>Has an email list been set up for this effort yet?
>  
>
We are currently operating under the "secmech" list:

      General Discussion: secmech@ietf.org
      To Subscribe:       https://www1.ietf.org/mailman/listinfo/secmech
      Archive:            http://www.ietf.org/mail-archive/web/secmech/index.html

But a new list "emu@ietf.org" will be created upon
WG approval. Stay tuned for subscription instructions.

--Jari


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 08:38:40 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtmN6-0007MQ-OJ; Tue, 03 Jan 2006 08:38:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtmN4-0007MK-MS
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 08:38:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24169
	for ; Tue, 3 Jan 2006 08:37:23 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtmSL-0003Dt-DZ
	for ietf@ietf.org; Tue, 03 Jan 2006 08:44:06 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 03 Jan 2006 05:38:26 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,325,1131350400"; 
	d="scan'208"; a="18715863:sNHT27390280"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k03Dbf4L015093; 
	Tue, 3 Jan 2006 08:38:24 -0500 (EST)
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 3 Jan 2006 08:38:15 -0500
Received: from 10.21.88.248 ([10.21.88.248]) by xmb-rtp-205.amer.cisco.com
	([64.102.31.59]) via Exchange Front-End Server email.cisco.com
	([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; 
	Tue,  3 Jan 2006 13:38:15 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Tue, 03 Jan 2006 08:38:22 -0500
From: Melinda Shore 
To: Jeffrey Hutzelman , 
Message-ID: 
Thread-Topic: participation sans meeting attendance (was RE: Alternative
	formats for IDs)
Thread-Index: AcYQavbPNSwfIHxeEdqGRAAKleNSdA==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 03 Jan 2006 13:38:15.0673 (UTC)
	FILETIME=[F309EE90:01C6106A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: participation sans meeting attendance (was RE: Alternative
 formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 1/2/06 11:32 PM, "Jeffrey Hutzelman"  wrote:
> I think we're doing better on this front than we have in many
> years.

The technical support for remote participation really has become
terrific.  Some sessions are run with great sensitivity to remote
participation, others are not - it depends on the chairs.  However,
on the other hand it does seem as if groups have become more
likely to make "final" decisions during meetings and not on
mailing lists.  Rarely you run into the perfect storm of
no jabber scribe, poor microphone placement, and decisions made
in meetings only, but it does happen.  I haven't travelled to
a meeting in about a year but I have participated remotely, and
although the handling of remote participation has been inconsistent
from working group to working group overall it's been pretty good.

Melinda

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 08:47:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtmVQ-00018n-Bs; Tue, 03 Jan 2006 08:47:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtmVN-00018U-Ki
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 08:47:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24982
	for ; Tue, 3 Jan 2006 08:45:58 -0500 (EST)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etmae-0003V6-OO
	for ietf@ietf.org; Tue, 03 Jan 2006 08:52:41 -0500
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51)
	id 1EtmVH-0003cB-3i; Tue, 03 Jan 2006 08:47:07 -0500
Received: by internaut.com (Postfix, from userid 1000)
	id 559F838ABE; Tue,  3 Jan 2006 05:47:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by internaut.com (Postfix) with ESMTP id 45F2638A81;
	Tue,  3 Jan 2006 05:47:06 -0800 (PST)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
Date: Tue, 3 Jan 2006 05:47:06 -0800 (PST)
From: Bernard Aboba 
To: Jari Arkko 
In-Reply-To: <43BA66CE.4030408@piuha.net>
Message-ID: 
References: 
	<43BA66CE.4030408@piuha.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: ietf@ietf.org
Subject: Re: IETF Last Call: draft-salowey-tls-ticket-06.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> The MAC will check out only if the servers are using the same key.  If the
> servers regularly generate new keys (as is suggested in the

If there is no rnormative requirement that the MAC field actually contain 
a MAC, how can we assume this?  And if there is no algorithm indication, 
how do we know how long the MAC field is? 

> Doesn't the key_version field also provide a hint
> as to whether the ticket is something that you
> can recognize? 

If the key_version field was globally and temporally unique (for example, 
if it included the server name + a counter) then it would provide that 
information.  But it's just a 32-bit integer.  If servers start
at zero, the chance of collision will be qu ite high. 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 08:48:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtmWV-0001XJ-Ke; Tue, 03 Jan 2006 08:48:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKw0-0003mx-Ak
	for ietf@megatron.ietf.org; Mon, 02 Jan 2006 03:20:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01489
	for ; Mon, 2 Jan 2006 03:19:39 -0500 (EST)
Received: from p54a7e445.dip.t-dialin.net ([84.167.228.69]
	helo=echnaton.serveftp.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtL11-0007tT-5l
	for ietf@ietf.org; Mon, 02 Jan 2006 03:26:04 -0500
Received: from lumbamba.niflheim
	([192.168.208.226] helo=echnaton.serveftp.com ident=fafnir)
	by echnaton.serveftp.com with esmtp (Exim 4.40)
	id 1EtKvh-00008C-3U; Mon, 02 Jan 2006 09:20:33 +0100
Message-ID: <43B8E24D.2010304@echnaton.serveftp.com>
Date: Mon, 02 Jan 2006 09:20:29 +0100
From: Peter Dambier 
Organization: Public-Root
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray 
References: <001501c60670$36f0eaa0$0601a8c0@pc6>	<001f01c607ad$08fa5d00$0601a8c0@pc6>	<01LWWGAWH28600009C@mauve.mrochek.com>	<015101c608b7$8d453c00$0601a8c0@pc6>	<01LWY2922HSM00009C@mauve.mrochek.com>	<002d01c60b8f$131c79e0$0601a8c0@pc6>	<6A0F1BA75E94FF440F514D00@svartdal.hjemme.alvestrand.no>	<020301c60bb6$ed87ef20$0601a8c0@pc6>
	<43B2AC49.7040708@gmx.de>	<032201c60bc9$6e930a20$0601a8c0@pc6>	<004901c60bef$dee867e0$7f1afea9@oemcomputer>
	<3CCC0432-14C1-497E-8B25-87628F3736F7@textuality.com>
In-Reply-To: <3CCC0432-14C1-497E-8B25-87628F3736F7@textuality.com>
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 03 Jan 2006 08:48:19 -0500
Cc: ietf 
Subject: Re: Troubles with UTF-8
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: peter@echnaton.serveftp.com
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Tim Bray wrote:
> On Dec 28, 2005, at 12:46 PM, Randy Presuhn wrote:
> 
>> Reserving NUL as a special terminator is a C library-ism.  I think  that
>> history has shown that the use of this kind of mechanism, rather than
>> explicitly tracking the string's length, was a mistake.
> 

I guess variably lenght V-records of type

string {int type,
         int length,
         int data[] );

would be horror. That will lose you 4 bytes per word and 2 bytes for
every printable sign.

C-ASCII "Randy Presuhn" = 14 char + '\0'.

Compare it to

      99999, " R"," a"," n"," d"," y",
      99999, " P"," r"," e"," s"," h"," u"," n"

That is 28 characters now. No alternative.


> 
> I used to think so too, but I don't any more; twenty years of doing  
> text processing has convinced me that C's null-terminated strings  
> simply cannot be improved on in a low-level programming language.   For 
> more on the subject see http://www.tbray.org/ongoing/When/200x/ 
> 2003/04/13/Strings  -Tim
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 


-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@echnaton.serveftp.com
mail: peter@peter-dambier.de
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 09:03:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etmkk-0005Nd-QJ; Tue, 03 Jan 2006 09:03:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etmkh-0005N4-1Y
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 09:03:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26859
	for ; Tue, 3 Jan 2006 09:01:49 -0500 (EST)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etmpx-00044E-Sp
	for ietf@ietf.org; Tue, 03 Jan 2006 09:08:31 -0500
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247]
	helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51)
	id 1Etmke-0006OT-0X; Tue, 03 Jan 2006 09:03:00 -0500
Received: by internaut.com (Postfix, from userid 1000)
	id 32DFE38AB7; Tue,  3 Jan 2006 06:02:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by internaut.com (Postfix) with ESMTP id 247DF38A81;
	Tue,  3 Jan 2006 06:02:59 -0800 (PST)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.com (see
	http://www.mailhop.org/outbound/abuse.html for abuse reporting
	information)
X-MHO-User: aboba
Date: Tue, 3 Jan 2006 06:02:59 -0800 (PST)
From: Bernard Aboba 
To: Pasi.Eronen@nokia.com
In-Reply-To: 
Message-ID: 
References: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: ietf@ietf.org
Subject: RE: IETF Last Call: draft-salowey-tls-ticket-06.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> The MAC will check out only if the servers are using the same key.  

That's not necessarily true.  Since the ticket is not self-describing. 
and there is no normative language relating to ticket construction, there 
is no guarantee that implementations will put the MAC field in the same 
place or use the same algorithm.  This could be fixed by including a 
globally and temporally unique ticket identifier, and mandating that the 
MAC field be put at the end. 

> It's certainly true that "implements all the MUSTs in the document"
> does not imply the system is secure, but that applies pretty much 
> to any document (unless it says "the system MUST be secure" :-). 

While it's certainly true that normative language doesn't guarantee 
security, most specifications do use normative language, if only to pin 
down some basic features of the specification.  It is quite possible for 
this specification to allow innovation along many dimensions, by 
mandating a few critical items, enough to avoid interoperability problems, 
and leaving the rest open. 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 09:31:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtnCc-0003dd-34; Tue, 03 Jan 2006 09:31:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtnCZ-0003dM-Em; Tue, 03 Jan 2006 09:31:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29873;
	Tue, 3 Jan 2006 09:30:38 -0500 (EST)
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EtnHq-0004to-NL; Tue, 03 Jan 2006 09:37:20 -0500
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id C21C0898CE;
	Tue,  3 Jan 2006 16:31:35 +0200 (EET)
Message-ID: <43BA8AE7.8070908@piuha.net>
Date: Tue, 03 Jan 2006 16:32:07 +0200
From: Jari Arkko 
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pekka Savola 
References: 
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: WG Review: EAP Method Update (emu)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Pekka,

> Is there a particular reason why the proposed charter does not mention 
> EAP-TTLS?
>
> I know very little about different EAP types, but as a potential 
> operator and user of EAP, I'd definitely want to see focus on 
> something like EAP-TTLS.
>
> Given that EAP-TTLS seems to be becoming an industry standard in 
> certain scenarios, it would be useful to clarify the relation of the 
> work of this proposed WG wrt EAP-TTLS in the charter.  The relation 
> may already be obvious to those who've been working on that space 
> more, but as an EAP user, I'd like to make it explicit to ensure folks 
> are on the same page..

First, some background on the difference of EAP TLS vs. EAP-TTLS.
EAP TLS uses TLS mutual authentication (typically with certs).
In contrast, tunneled EAP methods, such as EAP-TTLS or PEAP employ
TLS and an inner method. Typically, the outer TLS authentication
is for the server only, and used to protect an inner authentication
that may happen, for instance, with passwords. Tunneled EAP methods
typically have also additional built-in functionality, for instance, to
exchange various parameters for configuration and verification
purposes.

EAP-TLS is an existing Experimental RFC that the EMU WG is
chartered to update and extend. Tunneled EAP methods have
been described in drafts, and there are a few different ones
and they have a few different versions.

There has been some discussion previously about working
on tunnel methods in EMU. Assuming there'd be willing
contributors & change control would be given to IETF, this
would be a useful area to work, since, as you point out, these
are widely used methods. Drawbacks include a lot of existing
deployment with sometimes incompletely documented
and proprietary methods. I also worry about doing too many
things in EMU at the same time; we are already on the limit.
But once work items get completed, new things can be
worked on. The EAP TLS update should be fairly easy and
non-controversial task, for instance, so hopefully it is
completed soon.

In any case, the charter does include work on "password-based
methods". The specific arrangement for how passwords are to
be used is TBD, but tunneled TLS- like methods are one
possibility. While password-based client/cert-based server
authentication is a special case of what existing tunnel
methods can do, it may be the most important case. If
we succeed in defining these methods, one can hope
that the new method would start to take over some
existing TTLS et al usage.

--Jari


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 09:32:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtnCz-0003hr-MP; Tue, 03 Jan 2006 09:32:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtnCv-0003g2-Sf
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 09:32:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29910
	for ; Tue, 3 Jan 2006 09:31:00 -0500 (EST)
From: Pasi.Eronen@nokia.com
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtnID-0004uz-2k
	for ietf@ietf.org; Tue, 03 Jan 2006 09:37:42 -0500
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k03ERugo021222; Tue, 3 Jan 2006 16:27:58 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Jan 2006 16:32:10 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 3 Jan 2006 16:32:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Jan 2006 16:32:08 +0200
Message-ID: 
In-Reply-To: 
Thread-Topic: IETF Last Call: draft-salowey-tls-ticket-06.txt
Thread-Index: AcYQbn5QKFrSbEcuSyubME9pvi1zdQAADtTg
To: 
X-OriginalArrivalTime: 03 Jan 2006 14:32:09.0964 (UTC)
	FILETIME=[7AD392C0:01C61072]
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: IETF Last Call: draft-salowey-tls-ticket-06.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bernard Aboba wrote:

> > The MAC will check out only if the servers are using the same key. =20
>=20
> That's not necessarily true.  Since the ticket is not
> self-describing.  and there is no normative language relating to
> ticket construction, there is no guarantee that implementations will
> put the MAC field in the same place or use the same algorithm.  This
> could be fixed by including a globally and temporally unique ticket
> identifier, and mandating that the MAC field be put at the end.

If the servers use different keys, it does not matter where the MAC
field is placed, or whether the same or different algorithm is used.
If it would, the MAC algorithm would be seriously flawed, and totally
unsuitable for this use even if the field locations were fixed...

> > It's certainly true that "implements all the MUSTs in the document"
> > does not imply the system is secure, but that applies pretty much=20
> > to any document (unless it says "the system MUST be secure" :-).=20
>=20
> While it's certainly true that normative language doesn't guarantee
> security, most specifications do use normative language, if only to
> pin down some basic features of the specification.  It is quite
> possible for this specification to allow innovation along many
> dimensions, by mandating a few critical items, enough to avoid
> interoperability problems, and leaving the rest open.

I don't share your enthusiasm about using the uppercase RFC2119
keywords, but would adding a couple of requirements along the
following lines satisfy your concerns?

"The key(s) used to protect the tickets
- MUST be generated securely, taking [RFC4086] into account
- MUST be at least 128 bits in strength
- MUST NOT be used for any other purpose than generating and
  verifying tickets of a particular ticket format in a single
  logical TLS server (which may encompass multiple CPUs or hosts
  in a distributed environment).
- MUST be changed regularly
- MUST be changed if the ticket format changes
- MUST NOT be used with multiple cryptographic algorithms"

Since the document is an extension of TLS session resumption (which
happens between a single logical TLS client and server who have been
in contact before), I don't think we need to include interoperability
between servers in the document. All that is required is that a server
can recognize whether the ticket is something it sent out earlier.
The simplest way to do this is to MAC the ticket with a key known only
to the server; addiong globally unique "issued-by-server-known-as-X"
fields is not necessary for this purpose, and would IMHO just encourage
clients to inspect the tickets and hurt interoperability.

Best regards,
Pasi

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 10:04:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etnhm-0002if-5C; Tue, 03 Jan 2006 10:04:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etnhi-0002iQ-7o
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 10:04:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03204
	for ; Tue, 3 Jan 2006 10:02:48 -0500 (EST)
Received: from mail121.messagelabs.com ([216.82.241.195])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Etnmx-0005tZ-BR
	for ietf@ietf.org; Tue, 03 Jan 2006 10:09:30 -0500
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-10.tower-121.messagelabs.com!1136300620!8843161!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 5875 invoked from network); 3 Jan 2006 15:03:41 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-10.tower-121.messagelabs.com with SMTP;
	3 Jan 2006 15:03:41 -0000
Received: from [135.70.129.65] (unknown[135.70.129.65](misconfigured sender))
	by maillennium.att.com (mailgw1) with ESMTP
	id <20060103150339gw100lggese> (Authid: tony);
	Tue, 3 Jan 2006 15:03:40 +0000
Message-ID: <43BA9248.3080800@att.com>
Date: Tue, 03 Jan 2006 10:03:36 -0500
From: Tony Hansen 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <20060103045532.2469.qmail@xuxa.iecc.com>
In-Reply-To: <20060103045532.2469.qmail@xuxa.iecc.com>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Subject: Re: WG Review: Domain Keys Identified Mail (dkim)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

agreed.

	Tony Hansen
	tony@att.com

John Levine wrote:
>>Here is the revised proposed charter text:
> 
> Thanks for pulling this together.
> 
> If I had unlimited time to waste, I might niggle about a word or two,
> but it's fine as is, and I look forward to moving ahead and getting
> some work done.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 10:39:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtoGD-0003GU-5y; Tue, 03 Jan 2006 10:39:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtoGA-0003GJ-Ti
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 10:39:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07227
	for ; Tue, 3 Jan 2006 10:38:25 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtoLQ-00073r-8a
	for ietf@ietf.org; Tue, 03 Jan 2006 10:45:08 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 34FF726C102; Tue,  3 Jan 2006 16:39:13 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 4C96B26C0F6; Tue,  3 Jan 2006 16:39:07 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k03Fd6Ya700517;
	Tue, 3 Jan 2006 16:39:07 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id E74FA16A9A4; Tue,  3 Jan 2006 16:39:06 +0100 (CET)
Date: Tue, 3 Jan 2006 16:39:06 +0100
From: Stephane Bortzmeyer 
To: Yaakov Stein 
Message-ID: <20060103153906.GA17718@nic.fr>
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF7B@exrad2.ad.rad.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCDF7B@exrad2.ad.rad.co.il>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: ietf@ietf.org
Subject: Support for cooperative work (Was: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Tue, Jan 03, 2006 at 08:27:43AM +0200,
 Yaakov Stein  wrote 
 a message of 31 lines which said:

> Neither of these has any support for cooperative work.

Support is not in the format (what we discuss here) but in the
tools. There are a lot of tools for cooperative work with text /
ASCII, text / UTF-8 or XML files (CVS, xmldiff, diff, Subversion,
darcs, Trac, etc).


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 10:40:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtoHH-0003Qt-Qw; Tue, 03 Jan 2006 10:40:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtoHG-0003Qo-3X
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 10:40:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07414
	for ; Tue, 3 Jan 2006 10:39:32 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtoMU-00077R-QB
	for ietf@ietf.org; Tue, 03 Jan 2006 10:46:12 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 467F226C0F6; Tue,  3 Jan 2006 16:40:40 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 5965126C10B; Tue,  3 Jan 2006 16:40:34 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k03FeYYa683210;
	Tue, 3 Jan 2006 16:40:34 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id 3974D16A9A4; Tue,  3 Jan 2006 16:40:34 +0100 (CET)
Date: Tue, 3 Jan 2006 16:40:34 +0100
From: Stephane Bortzmeyer 
To: Yaakov Stein 
Message-ID: <20060103154034.GB17718@nic.fr>
References: <27A0F290348F8E45AEF79889DDE65A5201861026@exrad2.ad.rad.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201861026@exrad2.ad.rad.co.il>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Tue, Jan 03, 2006 at 06:40:41AM +0200,
 Yaakov Stein  wrote 
 a message of 83 lines which said:

> Which is exactly the reason all the other SDOs use MS Word for input
> and PDF for output.

Blatantly false. For instance, W3C and Oasis do not use MS Word.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 12:33:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etq1s-0005iG-7F; Tue, 03 Jan 2006 12:33:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etq1p-0005gw-BW
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 12:32:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27702
	for ; Tue, 3 Jan 2006 12:31:42 -0500 (EST)
Received: from xenotime.net ([66.160.160.81])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Etq78-0003gR-0A
	for ietf@ietf.org; Tue, 03 Jan 2006 12:38:27 -0500
Received: from shark.he.net ([66.160.160.2]) by xenotime.net for
	; Tue, 3 Jan 2006 09:32:51 -0800
Date: Tue, 3 Jan 2006 09:32:51 -0800 (PST)
From: "Randy.Dunlap" 
X-X-Sender: rddunlap@shark.he.net
To: Stephane Bortzmeyer 
In-Reply-To: <20060103154034.GB17718@nic.fr>
Message-ID: 
References: <27A0F290348F8E45AEF79889DDE65A5201861026@exrad2.ad.rad.co.il>
	<20060103154034.GB17718@nic.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Tue, 3 Jan 2006, Stephane Bortzmeyer wrote:

> On Tue, Jan 03, 2006 at 06:40:41AM +0200,
>  Yaakov Stein  wrote
>  a message of 83 lines which said:
>
> > Which is exactly the reason all the other SDOs use MS Word for input
> > and PDF for output.
>
> Blatantly false. For instance, W3C and Oasis do not use MS Word.

It depends on how one defines "all other SDOs".  :)

or "concensus".
Maybe like .us politicians redefine words to suit their own meanings.

-- 
~Randy  [agreeing with Stephane]

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 13:13:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtqfK-0005DY-BQ; Tue, 03 Jan 2006 13:13:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtqfI-0005DS-Fk
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 13:13:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05374
	for ; Tue, 3 Jan 2006 13:12:29 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etqkb-0005LD-G8
	for ietf@ietf.org; Tue, 03 Jan 2006 13:19:14 -0500
Received: from [192.168.0.3] (cpe-24-24-146-166.socal.res.rr.com
	[24.24.146.166]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k03IDsP3019094
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2006 10:13:55 -0800
Message-ID: <43BABEBA.3000605@bbiw.net>
Date: Tue, 03 Jan 2006 10:13:14 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Jeffrey Hutzelman 
References: <20060101043514.6985.qmail@xuxa.iecc.com>
	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>
	
	<416F6B6F46586EDBC9410701@p3.JCK.COM>	<43B89C0B.1090105@dcrocker.net>
	<10BF89812A7939DA95EAA4D3@p3.JCK.COM>
	<43BA02C8.1050300@dcrocker.net>
	<3FA36D130249957A8B65ABD8@bistromath.pc.cs.cmu.edu>
In-Reply-To: <3FA36D130249957A8B65ABD8@bistromath.pc.cs.cmu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dcrocker@bbiw.net
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jeffrey,

(I have changed the subject line, so that this discussion is explicitly NOT 
about any current IETF chartering activities.  I hope folks will not take my 
comments as having any implication about any of those efforts or discussions 
about them...)


> I think a lot of people might be missing a key point about how our 
> process works.  


What makes things particularly challenging is the difference between Procrustean 
  attention to documented rules, versus applying them in an integrated manner 
with subjective assessment of the pragmatics of being productive.  Any 
organization that strictly resolves disputes based on the letter of its laws 
quickly alienates is workforce.

When we wrote the rules regarding chartering, the intent was to have the 
cognizant AD conduct whatever discussion were needed to create a working group 
that would be productive.  This is inherently a fuzzy process, so it was -- and 
remains -- important to avoid over-documenting the procedure.

For example, an AD who entirely ignores the concerns and desires of those who 
will do the bulk of the work risks having a working group without workers.

The pragmatics, therefore, require the AD to try to juggle various political, 
technical and project management concerns, and put forward a charter that they 
feel will offer the best chance at productive working group output.

Frequently -- maybe usually -- this is primarily through a private dialogue 
among those who will form the small core of the working group effort, including 
likely chairs.  However it is not uncommon for a public dialogue to be 
conducted.  For example, a BOF usually includes a review of candidate charter 
text.  That the open group's consensus is not binding on the AD merely indicates 
the delicate nature of chartering, rather than the irrelevance of that consensus.


> This ability to determine what work will be done and under what terms is 
> a fundamental part of what it means to "steer"; without it, the IESG 
> would not be much of a "steering group".

Actually, this highlights why "steering group" is exactly the wrong term for the 
IETF process management team.  They do not initiate work and they are not 
primary contributors to that work.  Hence, they do not really "steer" anything. 
  When the IESG tries to act like it does, they often find no workers and a mass 
of dissatsfaction.

The job of the IESG is to facilitate the initiatives of others and to ensure 
enforcement of useful quality assurance.


>     It's beneficial to apply 
> constraints like only considering solutions with domain-level 
> granularity, or only addressing how to _provide_ identity information 
> and not what to do with it.  Particularly given the IETF's previous 
> experience with attempted anti-spam work, I think such constraints are 
> necessary to narrow the problem space to one for which a working group 
> will produce something in a finite time.
> 
> Besides being necessary, those constraints are also acceptable because 
> while they limit _this_ working group to solving one piece of the 
> problem, there is no implication that other working groups will not be 
> chartered to work on other pieces.  And, while _this_ working group is 
> constrained to a particular approach, there is no implication that other 
> approaches might not also be tried.  

all of the above is nicely said, as comments about a class of working group 
startup efforts.


> What I do _not_ think is reasonable is a demand that the working group 
> be constrained to produce exactly the protocol proposed, making changes 
> only if absolutely necessary.  

And here is where we have the major disconnect.

Working groups start from a wide variety of places.  Some start with an idea. 
Some with a detailed proposal.  Some with a detailed specification and some with 
existing and deployed technology.  When a working group starts, it must make the 
strategic decision about how much prior work to preserve, versus how much new 
work to encourage or require.

There are obvious and significant trade-offs in this choice.  What is essential 
is that the trade-offs get serious consideration and that the choice be 
appropriate to the particular situation.  It absolutely is NOT true that all 
chartered working groups must be allowed to throw away any and all prior work. 
The loss of invested community effort and the loss of momentum would be disastrous.

At the least, an effort that seeks to use existing technology needs to explain 
clearly and convincingly what needs to be preserved.  Equally, any efforts to 
deny the stability of re-using that work must make a compelling and concrete 
case for the changes that are needed.


> Note that the XMPP case is somewhat different from this one.

Remembering that this new thread is about a general issue, rather than debating 
a particular working group effort, I'll comment on the particulars of your 
reference:

   In that
> case, a working group was formed to "adopt" an existing technology from 
> another process, and develop an Internet standard.  High value was 
> placed on compatibility with the existing widely-deployed protocol, 
> which is appropriate and the same treatment we'd give to our own 
> existing standards, or expect other SDO's to give them.
> 
> As I understand it, DKIM is _not_ a widely-deployed protocol developed 
> by another SDO; it is a proposal developed by a design team with the 
> specific intent of bringing it to the IETF.  There is absolutely nothing 
> wrong with that approach.  However, the normal next step is to bring the 
> design team output back to a working group, or to the IETF as a whole, 
> and ask for comments and/or consensus to use the design team's output as 
> input to the next step in the process.

Jabber did not come from another SDO.  Even if it had, I fail to see why that 
imparts special status.  DKIM came from a substantial -- albeit informal -- 
industry initiative with quite a few organizations participating. Nothing about 
Jabber's or DKIM's origins automatically make the technical quality of the work 
good or bad, or necessarily of interest to the IETF.

(Well, ok, I'll indulge in a particular, in order to correct a factual error: 
Mis-statements about DKIM's deployed base have been corrected quite a few times. 
  Suffice it to say that your understanding is incorrect.)


> In this case, it appears that instead of doing that, the design team is 
> asking the _IESG_ to make the decision that the design team's work will 
> be used for the next step in the process, without the benefit of working 
> group or unconstrained consensus. 

(Damn.  Have to correct another one:  I have been boringly pedantic about citing 
the TWO rounds of OPEN, online consensus effort surrounding the draft charter. 
This was not a tiny cabal or even a larger, albeit closed, group or 
organizations.  The draft charter text was produced by a highly open and 
responsive process over the course of months.)


d/
-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 14:32:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etrte-0003uO-PX; Tue, 03 Jan 2006 14:32:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etrtd-0003tS-2H
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 14:32:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16898
	for ; Tue, 3 Jan 2006 14:31:19 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etryu-0008SI-JV
	for ietf@ietf.org; Tue, 03 Jan 2006 14:38:06 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LXBSG1W1GG00140Y@mauve.mrochek.com> for
	ietf@ietf.org; Tue, 3 Jan 2006 11:32:15 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1136316735;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=aekfpAM9gaaM/yyELc9DFbM9N
	8Jpsi1jH/YKdEEjGS9IjJ+MI7edF0zfOuOJ+xD8KqvhPjeCjZR06MWq3leDuw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LXBLLO78RK00009C@mauve.mrochek.com>; Tue,
	03 Jan 2006 11:32:12 -0800 (PST)
To: John Levine 
Message-id: <01LXBSG0A4OQ00009C@mauve.mrochek.com>
Date: Tue, 03 Jan 2006 11:28:26 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 03 Jan 2006 04:55:32 +0000"
	<20060103045532.2469.qmail@xuxa.iecc.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
References: <7.0.0.16.2.20060102113007.05eee498@vigilsec.com>
	<20060103045532.2469.qmail@xuxa.iecc.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: ietf@ietf.org
Subject: Re: WG Review: Domain Keys Identified Mail (dkim)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> >Here is the revised proposed charter text:

> Thanks for pulling this together.

> If I had unlimited time to waste, I might niggle about a word or two,
> but it's fine as is, and I look forward to moving ahead and getting
> some work done.

Complete ageement here. This is plenty good enough to move forward.

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 14:56:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtsH4-0000em-Ja; Tue, 03 Jan 2006 14:56:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtsH2-0000ee-9n
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 14:56:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20387
	for ; Tue, 3 Jan 2006 14:55:33 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtsMM-0000ya-Dj
	for ietf@ietf.org; Tue, 03 Jan 2006 15:02:19 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LXBTADUXR40012AC@mauve.mrochek.com> for
	ietf@ietf.org; Tue, 3 Jan 2006 11:56:42 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1136318202;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=fVVUbNA9yNxSUX4eFYqHNRUDg
	DXogO2B2FAaHQ6BcPwPisQdk2PPh7BsYfpN1edWgp1OT2QW0jp3ehvh0nAELw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LXBLLO78RK00009C@mauve.mrochek.com>; Tue,
	03 Jan 2006 11:56:39 -0800 (PST)
To: Yaakov Stein 
Message-id: <01LXBTAC7GGU00009C@mauve.mrochek.com>
Date: Tue, 03 Jan 2006 11:41:29 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Tue, 03 Jan 2006 06:55:31 +0200"
	<27A0F290348F8E45AEF79889DDE65A5201861028@exrad2.ad.rad.co.il>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
References: <27A0F290348F8E45AEF79889DDE65A5201861028@exrad2.ad.rad.co.il>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: Ned Freed , ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> > Second, your assumption that other SDOs have been able to blissfully make use
> > of private formats like MS Word without incident is simply untrue. One obvious
> > counterexample I know of is the CCITT/ITU, which has in the past used MS Word
> > as a distribution format for many of it's documents. I have quite a few of
> > these documents on hand and occasionally need to refer to old versions of them,
> > but when I try and read them using modern tools the results are rarely good.
> > Many of these documents simply refuse to open, sometimes crashing the tool I'm
> > using, while others do open but are misformatted, sometimes to the point of
> > being illegible.

> [YJS] I think that something has been lost in the translation here.
 
Indeed it does: You appear to be unfamiliar with the specifics of your own
proposal, which quite clearly calls for MS Word as both an INPUT and OUTPUT
format.

> ITU (I have participated in the ITU-T for many years, and ALWAYS
> sent in my contributions in Word) ONLY accepts contributions in Word
> and ONLY works on documents in Word (using ITU designed templates).
 
I don't know and don't particularly care what process the ITU uses for this. My
comments were directed at the notion of using Word as an output format for
RFCs.

However, I note in passing that at least one other person has stated that the
procedure the ITU uses does not, in their opinion, work well at all. I cannot
say I'm surprised by this.

> The OUTPUT documents are available in Word and PDF, with PDF
> the recommended format (due to Word's bad habit of changing pagination
> when using different page sizes, etc). The PDF output should be readable
> indefinitely.

That appears to be true today. It wasn't true in the past. Many of the ITU
specifications I have are in Word format only.
 
> The Word format is mainly there for people who may need to work on
> updates of the standard (unlike RFCs, ITU Recommendations are updated).

Except when it's the only choice, in which case everyone who wants to
read the thing has to put up with it.

> If such a Word doc is unreadable for anyone needing it, the
> secretariat has tools to convert it.
 
I am extremely skeptical that the ITU Secretariat stands ready and willing
to assist any random schlub who comes along with a handful of old
ITU documents they acquired several decades back and can no longer read.

> > Try CVS or SVN and diff - works for everyone.

> Sorry, although I have such toys on my home computer
> I am not allowed to install such unsupported SW
> on my work computer. 

So? As it happens the place where I work has rules severely restricting the use
of various Microsoft products. CVS, SVN and diff, OTOH, are all fully supported
tools in my work environment.

As Russ pointed out, it is no more reasonable to expect you to be swayed by the
vagarities of my workplace than it is for me to give a damn about those of
yours. The intersection of the tools allowed by everyone's workplace is pretty
much guaranteed to be the empty.

In any case, since I've seen not even the slightest hint of any support for
your proposal to adopt proprietary formats for I-Ds and RFCs, it appears that
further discussion is a waste of time. So this will be my final message on this
topic.

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 14:59:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtsK3-00011t-8w; Tue, 03 Jan 2006 14:59:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtsK0-00011g-TU
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 14:59:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20890
	for ; Tue, 3 Jan 2006 14:58:37 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtsPJ-00015e-Bm
	for ietf@ietf.org; Tue, 03 Jan 2006 15:05:24 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EtsJj-00060t-6h; Tue, 03 Jan 2006 14:59:35 -0500
Date: Tue, 03 Jan 2006 14:59:34 -0500
From: John C Klensin 
To: Yaakov Stein 
Message-ID: 
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201861027@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A5201861027@exrad2.ad.r
 ad.co.il>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Tuesday, 03 January, 2006 06:47 +0200 Yaakov Stein
 wrote:

> The downside is that when a group is working on a document
> in Word, anyone not having the SW would not be able to
> directly  contribute - but joint work is not really practical
> using any system without tracking anyway.

That is an interesting observation.  It must be true since you
say it is.   

However, I wonder what it means that I have my name, as author
or editor, on, by rough count, 27 RFCs.  And I've been a major
contributor (of text, not just ideas, for a few more).  Of
those,  all but about three were collaborative, with multiple
people contributing text.   And, of that group, the number that
started in Word, including one of those non-listed-editor
collaborations, was two.

I guess the other 25+ documents must not have been practical to
produce.

At one level, I'm sympathetic to what you are saying and trying
to accomplish.  While there are many characteristics of Word
that I dislike, I like its tracking facilities and ability to
turn tracking displays and marginal comments on and off.  Used
properly, I find them much more satisfactory than anything I've
been able to do with CVS-like and Diff-like systems: the latter
are better at identifying what has been changed (although that
can be effectively simulated in Word by letting it generate
change tracking by comparing two documents) but far worse at
recording and identifying the reasons why the changes were made.
Unfortunately, even if one ignores most of the issues with
proprietary format and costs, it is hopeless for IETF use in
managing working documents and RFCs.  Among the problems:

	(1) Its template mechanism is very version-sensitive and
	fairly fragile.  If one makes template or option changes
	to accommodate IETF needs, one cannot then go back and
	forth with the formatting requirements of "day job"
	documents without risking making a royal, and
	essentially irreversible, mess.
	
	(2) Its Style model is even more version-sensitive and
	even more fragile.  It is also badly documented and
	idiosyncratic.  But it, or major template changes, or
	both, are necessary if one is going to produce IETF
	documents that correspond to RFC Editor norms (and I'm
	not just talking about ASCII output).
	
	(3) Its cross-reference model is so "smart" in terms of
	what can be referenced, what header styles it can be
	used with, etc., that cross-references in RFC Style and
	within RFC objects are not consistently possible.  The
	facilities of WordPerfect 4.2 in this area, nearly two
	decades ago, were far superior, I believe because of
	less of an attitude of "we know what you need and, if we
	don't supply it, you don't need it".
	
	(4) Others have pointed out the versioning problem in
	terms of reading documents, but it is worse than that.
	I've seen document formatting and structure destroyed
	beyond recognition or recovery by the simple mechanism
	of being moved back and forth among authors who are
	using different version of Word, even when Word 2000 is
	the oldest of them.   I know how to mitigate that
	problem but it would require far more drastic changes in
	how the IETF does business than merely switching working
	document formats.
	
	(5) Other than change-tracking, Word has very little
	built-in collaboration machinery.  I have the impression
	that there are even fewer such facilities in recent
	versions than in earlier ones.  Instead, the strong
	collaboration facilities require even more expensive
	versions of Office, use of Outlook for email, and other
	client and server conventions that would be far more
	problematic for the IETF.
	
	(6) While I had high hopes for the XML output from Word
	(again, available only with Office Professional and
	above, if there is an "above), the 2003 version turns
	out to be one of the stranger things I have every seen.
	The XML output from Office 12 is supposed to be much
	better -- I haven't seen it-- but it is, again,
	incompatible.

That is by no means my entire list, but it is indicative.  And
others may have other lists or entries.

For all of those reasons and others -- and I am still concerned
about costs and share the concerns of others about proprietary
and changing formats -- actually IETF use of Word seems to be to
be a non-starter.

I do believe that, if you want to do initial document
preparation in Word, you should be able to do that.  As others
have suggested, no one I know of is really interested in
standardizing on or requiring a particular editor.  But, to do
so, you need to be able to produce an editable format that is no
worse than ASCII.  You may have better ideas, but, as I have
explored that range of options, I've come to the conclusion that
there ought to be two ways to accomplish that end.  They are:

	(1) Development of an "IETF printer driver" that can be
	distributed as freeware or with minimal costs and
	restrictions and that would produce lines and pages of
	the right layouts _and_ would handle "smart character"
	to ASCII conversions, generation of appropriate
	line-ending sequences, etc.  Whomever developed this
	thing would need to make a long-term commitment to
	producing and maintaining versions for every version of
	Windows from, I think, Win98 through the indefinite
	future.  The generic printer and the conventions of RFC
	3285 are demonstrably not good enough.
	
	(2) Development of a converter between the MS-XML output
	of Word Pro 2003 and the XML input of RFC 2629bis so
	that xml2rfc and its friends could take responsibility
	for final formatting.  Note that, if the converter were
	two-way, you could edit happily in Word and others could
	edit happily in XML and both could interwork.  However,
	as with the above, I think this solution would rapidly
	deteriorate into uselessness unless there were a
	commitment to produce new versions as new versions of
	Office appeared -- at least until Microsoft stabilizes
	and documents their XML formats.

To the extent to which the trend toward a requirement --not just
an option-- for XML input to the RFC Editor process --
continues, the first of these options might easily become
unavailable.

    john



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 15:14:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtsYG-0004gq-9Q; Tue, 03 Jan 2006 15:14:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtsYD-0004gK-IA
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 15:14:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23024
	for ; Tue, 3 Jan 2006 15:13:20 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtsdW-0001iK-Lg
	for ietf@ietf.org; Tue, 03 Jan 2006 15:20:05 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k03KDtdJ021233; Tue, 3 Jan 2006 15:13:55 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13498; 
	Tue, 3 Jan 2006 15:13:54 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Tue, 3 Jan 2006 15:13:54 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886242@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'william(at)elan.net'" , Yaakov Stein 
Date: Tue, 3 Jan 2006 15:13:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: Frank Ellermann , ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--> Lets go ahead and ask then -
-->     Does anyone else think that IETF should allow documents which
-->     format/structure is not publicly known as one of the ways to
-->     distribute IETF specifications?

Clarifying that "publicly known" means "well defined and publicly 
available", I would answer no...

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 15:30:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etsnx-0007a9-TF; Tue, 03 Jan 2006 15:30:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etsnv-0007Zp-Lk
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 15:30:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25123
	for ; Tue, 3 Jan 2006 15:29:34 -0500 (EST)
Received: from fiji.merit.edu ([198.108.1.12])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtstE-0002JE-5C
	for ietf@ietf.org; Tue, 03 Jan 2006 15:36:19 -0500
Received: from localhost (localhost [127.0.0.1])
	by fiji.merit.edu (Postfix) with ESMTP id 9B84818B4;
	Tue,  3 Jan 2006 15:30:40 -0500 (EST)
Received: from fiji.merit.edu ([127.0.0.1])
	by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 22729-10; Tue,  3 Jan 2006 15:30:40 -0500 (EST)
Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151])
	by fiji.merit.edu (Postfix) with ESMTP id 5A61D18B1;
	Tue,  3 Jan 2006 15:30:40 -0500 (EST)
From: "Larry J. Blunk" 
Organization: Merit Network
To: ietf@ietf.org
Date: Tue, 3 Jan 2006 15:30:37 -0500
User-Agent: KMail/1.8.2
References: <27A0F290348F8E45AEF79889DDE65A5201861028@exrad2.ad.rad.co.il>
	<01LXBTAC7GGU00009C@mauve.mrochek.com>
In-Reply-To: <01LXBTAC7GGU00009C@mauve.mrochek.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200601031530.38084.ljb@merit.edu>
X-Virus-Scanned: amavisd-new at merit.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: Ned Freed 
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ljb@merit.edu
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

 From http://www.itu.int/ITU-T/edh/faqs-docsub.html

"When submitting a document which contains figures, it is highly recommended
that the figures be created using a graphic software and inserted into the
document rather than creating the figure using the default Picture Editor in
Word. Drawings made using Picture Editor do not convert properly in different
versions Word for Windows and in some cases, the figures do not appear at all.
In cases where the author has used the Picture Editor, the author must ensure
that all the elements or "objects" in the figure are grouped (defined as one
figure) to avoid objects being re-aligned when the margins or paper size
are modified."


  Not exactly confidence inspiring.   Good thing they "highly recommend" not
using the default Picture Editor in Word.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 16:46:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EttzC-0007PP-RQ; Tue, 03 Jan 2006 16:46:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EttzA-0007Ot-IF
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 16:46:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18866
	for ; Tue, 3 Jan 2006 16:45:14 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etu4U-0001Xn-JL
	for IETF@ietf.org; Tue, 03 Jan 2006 16:52:00 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 03 Jan 2006 13:46:17 -0800
Received: from [128.107.163.130] (dhcp-128-107-163-130.cisco.com
	[128.107.163.130])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k03LkEXX006757;
	Tue, 3 Jan 2006 13:46:16 -0800 (PST)
Message-ID: <43BAF0A6.2090601@cisco.com>
Date: Tue, 03 Jan 2006 13:46:14 -0800
From: Jim Fenton 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Leslie 
References: <43A8893F.9010700@dcrocker.net>		<43A8C2EC.4060401@dcrocker.net>					<0b0d55f43c319b517cad80dd1d5d76d0@guppylake.com>	<1135458563.17219.79.camel@bash.adsl-64-142-13-68>	
	<20051231043648.GA17422@verdi>
In-Reply-To: <20051231043648.GA17422@verdi>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: Nathaniel Borenstein ,
	IETF-DKIM , IETF@ietf.org
Subject: Re: The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John Leslie wrote:

>Nathaniel Borenstein  wrote:
>  
>
>>On Dec 24, 2005, at 4:09 PM, Douglas Otis wrote:
>>
>>    
>>
>>>Reputation remains the only solution able to abate the bulk of abuse.
>>>      
>>>
>>... I think most of us pretty much agree about the critical role of
>>reputation.
>>    
>>
>
>   I've noticed a lot of what I call "lip service" about the critical
>role of reputation. To say this differently, many folks seem to think
>you can choose a "reputation system" almost at random, and it's sure
>to improve your signal/noise ratio, "unless you've chosen the wrong one".
>(which, I suppose, is a tautology...)
>
>   But, in my view, we have no basis to choose the "right" one unless
>we have a good understanding of what it measures and a workable idea
>of how to "end run" when it falsely rejects good messages.
>  
>
I completely agree that reputation has a critical role (although
accreditation is important in many situations, as Phill has pointed out,
and should not be ignored).  However, I have come to believe that there
is a great deal of subtlety below the surface of any good reputation system:

- Preventing abusers from "gaming the system" to get good scores
- Preventing attackers from damaging the reputations of others
- Defending the reputation system against legal actions from those who
feel they have been hurt
- Making it all work within the law, considering privacy laws, restraint
of trade, and so forth, considering that the laws governing this vary by
jurisdiction

For this reason, I don't think the operation of reputation systems
themselves should be defined by IETF; different users will have
different needs.  However, standard protocols for communicating with
reputation systems will be needed, and this is a very important area for
IETF to address.  Transaction rates for lookups will be high, and
careful protocol design is needed.  The use of standard protocols in
this area will allow clients to pick a suitable reputation service, and
to change services without changing their infrastructure.  Both
reporting and query protocols will need to be defined.

Much of this applies to accreditation services as well, although there
are some different requirements (negotiating an accreditor to use
between sender and recipient/verifier, for example).

-Jim

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 16:56:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etu8g-0001IN-6J; Tue, 03 Jan 2006 16:56:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etu8d-0001Hx-9Y
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 16:56:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20987
	for ; Tue, 3 Jan 2006 16:55:01 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtuDy-000204-OE
	for ietf@ietf.org; Tue, 03 Jan 2006 17:01:47 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFC.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44)
	id 1Etu8S-0006oV-KC; Tue, 03 Jan 2006 13:56:05 -0800
Message-Id: <6.2.3.4.2.20060103152602.05b7aeb0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Tue, 03 Jan 2006 22:55:57 +0100
To: John Levine , ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <20060102231537.16359.qmail@xuxa.iecc.com>
References: <6.2.3.4.2.20060102230849.03a8e670@mail.jefsey.com>
	<20060102231537.16359.qmail@xuxa.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: 
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 00:15 03/01/2006, John Levine wrote:
> > NeuStar is the ".us" Registy and has entered into an open root
> > agreement with the GSMA, supporting the ".gprs" TLD. That the IETF
> > pays to host a link to them may certainly be perceived as a
> > political signal.
>
>Oh, no, not this again.  Neustar's .gprs TLD exists only on a special
>purpose private network disjoint from the public Internet, used for
>GSM signalling and invisible to anyone who doesn't run a GSM phone
>switch.

Dear John,
do you agree I ask your head the day I can reach ".gprs" names from my PC?

>It is not the network that GSM phone users see when they use
>web or mail services over their phones.  I don't care what names the
>GSMA uses on their private network, and I don't see any reason that
>anyone else would, either.

ICANN has suggested the IETF to run a testbed on this kind of 
evolution. It even suggested to use classes as per the adequate 
proposition of John Klensin. The IETF prefered not to.

>There may be reasons not to like Neustar, but the fact that they
>happen to provide network infrastructure to phone companies is not one
>of them.

No reason to dislike NeuStar. They introduce competition where there 
is none. IMHO this is a blessing for the native Internet and a 
challenge for the international network and the IGF. What is 
dangerous is to consider all this neutral.

jfc





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 17:22:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtuY6-00079K-N7; Tue, 03 Jan 2006 17:22:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtuY4-000792-V0
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 17:22:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24519
	for ; Tue, 3 Jan 2006 17:21:18 -0500 (EST)
Received: from [81.88.224.238] (helo=mx5b.aemcom.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtudL-0002uI-FQ
	for ietf@ietf.org; Tue, 03 Jan 2006 17:28:05 -0500
Received: from ws686 (unknown [81.88.244.151])
	by mx5b.aemcom.net (Postfix) with SMTP id 95E362040C7
	for ; Tue,  3 Jan 2006 23:20:30 +0100 (CET)
Message-ID: <001401c610b4$390e1620$1007140a@ws686>
From: "Daniele Giordano" 
To: 
Date: Tue, 3 Jan 2006 23:22:45 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Subject: optional clip screening in H.323 supplementary service
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

H.323 recommendation has supplementary services defined in H.450 ITU
recommendations.
One of them is H.450.3 call diversion service.
In many H.323 devices H.450.3 implements clip screening.
This function makes a manipulation of CLI (calling line identification) of
the caller:

 if A (generic user) calls B (my network client) and B has a H.450.3 call
forward unconditionally to C (mobile phone of B), C receive a call with the
CLI of A

A ----------> B ---------> C
|_________CLI_________|


 Usually this scenario is correct but in a case where billing is based on
CLI this is a problem because the call is generated from A (which isn't a
client of my network) and so i haven't the billing of the call.

Without clip screening:

A ----------> B ---------> C
|___CLI____| |___CLI___|

 C receive a call generated from B (my client) and so the billing is ok.

Is there a protocol/reccomendation which implements this function?
What is your opinion?
Thanks.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 17:25:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtubN-0008J9-WA; Tue, 03 Jan 2006 17:25:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtubM-0008J4-Je
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 17:25:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25063
	for ; Tue, 3 Jan 2006 17:24:42 -0500 (EST)
Received: from mailhost.jlc.net ([199.201.159.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etugi-00037r-Ve
	for IETF@ietf.org; Tue, 03 Jan 2006 17:31:29 -0500
Received: by mailhost.jlc.net (Postfix, from userid 104)
	id 4C17DE0435; Tue,  3 Jan 2006 17:25:46 -0500 (EST)
Date: Tue, 3 Jan 2006 17:25:46 -0500
From: John Leslie 
To: Jim Fenton 
Message-ID: <20060103222546.GA85080@verdi>
References: <43A8C2EC.4060401@dcrocker.net>
	
	
	
	
	<0b0d55f43c319b517cad80dd1d5d76d0@guppylake.com>
	<1135458563.17219.79.camel@bash.adsl-64-142-13-68>
	
	<20051231043648.GA17422@verdi> <43BAF0A6.2090601@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43BAF0A6.2090601@cisco.com>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: IETF@ietf.org
Subject: Re: The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jim Fenton  wrote:
> John Leslie wrote:
> 
>> But, in my view, we have no basis to choose the "right" one unless
>> we have a good understanding of what it measures and a workable idea
>> of how to "end run" when it falsely rejects good messages.
> 
> I completely agree that reputation has a critical role (although
> accreditation is important in many situations, as Phill has pointed out,
> and should not be ignored).  However, I have come to believe that there
> is a great deal of subtlety below the surface of any good reputation system:
> 
> - Preventing abusers from "gaming the system" to get good scores

   This, IMHO, can never be standardized. We can ask for a web page
(subject to change without notice) detailing what is measured, but I
doubt we could even standardize the questions such a web page should
answer.

> - Preventing attackers from damaging the reputations of others

   This is an area which could benefit from standardization, IMHO.
I'm not sure, though, whether consensus is attainable. I think CSV
did a reasonable job here. While I think SPF fails at this, I doubt
we'd ever get the SPF folks to agree.

> - Defending the reputation system against legal actions from those who
>   feel they have been hurt

   I think we should steer clear of this issue.

> - Making it all work within the law, considering privacy laws, restraint
>   of trade, and so forth, considering that the laws governing this vary
>   by jurisdiction

   I see no point in trying to standardize for conflicting jurisdictions.

> For this reason, I don't think the operation of reputation systems
> themselves should be defined by IETF; different users will have
> different needs. 

   I entirely agree.

> However, standard protocols for communicating with reputation systems
> will be needed, and this is a very important area for IETF to address. 

   I would very much like to do so.

> Transaction rates for lookups will be high, and careful protocol design
> is needed.  The use of standard protocols in this area will allow
> clients to pick a suitable reputation service, and to change services
> without changing their infrastructure. 

   Ease of changing reputation services trumps most other considerations,
in the real world.

> Both reporting and query protocols will need to be defined.

   Reporting, IMHO, needs a standardized minimal-set, not a full set.

   Query protocols should see _a_ standard query, which need not
necessarily return all available information.

> Much of this applies to accreditation services as well, although there
> are some different requirements (negotiating an accreditor to use
> between sender and recipient/verifier, for example).

   In CSV, we standardized a way for sender to advertise accreditor(s).
I'm not sure if anything beyond that will be practical.

   The question of standards for reputation and accreditation, IMHO,
deserves IETF work and could deliver great value. But to be clear, I
do not think it belongs in DKIM.

--
John Leslie 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 17:40:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etupe-0003fi-F6; Tue, 03 Jan 2006 17:40:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etupb-0003fa-Sh
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 17:40:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27125
	for ; Tue, 3 Jan 2006 17:39:25 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etuux-0003lB-DW
	for IETF@ietf.org; Tue, 03 Jan 2006 17:46:12 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-4.cisco.com with ESMTP; 03 Jan 2006 14:40:29 -0800
Received: from [128.107.163.130] (dhcp-128-107-163-130.cisco.com
	[128.107.163.130])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k03MeSGx010900;
	Tue, 3 Jan 2006 14:40:28 -0800 (PST)
Message-ID: <43BAFD5C.2080604@cisco.com>
Date: Tue, 03 Jan 2006 14:40:28 -0800
From: Jim Fenton 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Leslie 
References: <43A8C2EC.4060401@dcrocker.net>
	
	
	
	
	<0b0d55f43c319b517cad80dd1d5d76d0@guppylake.com>
	<1135458563.17219.79.camel@bash.adsl-64-142-13-68>
	
	<20051231043648.GA17422@verdi> <43BAF0A6.2090601@cisco.com>
	<20060103222546.GA85080@verdi>
In-Reply-To: <20060103222546.GA85080@verdi>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Cc: IETF@ietf.org
Subject: Re: The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John Leslie wrote:

>   The question of standards for reputation and accreditation, IMHO,
>deserves IETF work and could deliver great value. But to be clear, I
>do not think it belongs in DKIM.
>
>  
>
I strongly agree.  By CCing the ietf-dkim list on my message I didn't
mean to imply that the work belongs there.

-Jim

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 03 23:04:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etzsb-0006p7-9V; Tue, 03 Jan 2006 23:04:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtzsZ-0006ot-4g
	for ietf@megatron.ietf.org; Tue, 03 Jan 2006 23:04:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00734
	for ; Tue, 3 Jan 2006 23:02:48 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etzxw-0005UX-QY
	for ietf@ietf.org; Tue, 03 Jan 2006 23:09:38 -0500
Received: from pog.isi.edu (c1-vpn13.isi.edu [128.9.176.53])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0443Mi24490;
	Tue, 3 Jan 2006 20:03:22 -0800 (PST)
Message-Id: <5.1.0.14.2.20060103192703.00ab2b68@boreas.isi.edu>
X-Sender: braden@boreas.isi.edu
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 03 Jan 2006 19:31:16 -0800
To: "Randy Presuhn" , "ietf" 
From: Bob Braden 
In-Reply-To: <004901c60bef$dee867e0$7f1afea9@oemcomputer>
References: <001501c60670$36f0eaa0$0601a8c0@pc6>
	<001f01c607ad$08fa5d00$0601a8c0@pc6>
	<01LWWGAWH28600009C@mauve.mrochek.com>
	<015101c608b7$8d453c00$0601a8c0@pc6>
	<01LWY2922HSM00009C@mauve.mrochek.com>
	<002d01c60b8f$131c79e0$0601a8c0@pc6>
	<6A0F1BA75E94FF440F514D00@svartdal.hjemme.alvestrand.no>
	<020301c60bb6$ed87ef20$0601a8c0@pc6> <43B2AC49.7040708@gmx.de>
	<032201c60bc9$6e930a20$0601a8c0@pc6>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: 
Subject: Re: Troubles with UTF-8
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


The morality of string delimiters vs. character counts
  is a debate that has been going on for some 40 years!
Some things never change... ;-)

Bob Braden


>...
>
>I think the use of explicitly encoded length, rather than special terminator
>or deliminator sequences, is simpler to code and debug, as well as
>being more robust in avoiding buffer overflow problems, etc.

...

>Reserving NUL as a special terminator is a C library-ism.  I think that
>history has shown that the use of this kind of mechanism, rather than
>explicitly tracking the string's length, was a mistake.
>
>Randy
>





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 00:50:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu1Xe-0001bd-DA; Wed, 04 Jan 2006 00:50:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu1Xb-0001bS-G7
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 00:50:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10005
	for ; Wed, 4 Jan 2006 00:49:16 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.202])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu1cz-0000EU-N7
	for ietf@ietf.org; Wed, 04 Jan 2006 00:56:08 -0500
Received: by zproxy.gmail.com with SMTP id o37so3409680nzf
	for ; Tue, 03 Jan 2006 21:50:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=eY6DDNgZY/Gy+DWf14K+p8J4oZsxde0eYwOgt//qyJFMrXRIZWZ41/3sEZqHGcnhXZKH9DOISgW6lQDg5JpdR6eggJMvM3qcC3/kwtxq3/Slp9WXnCZNL/QX4wc/EbRIgXMJr2/vStu6kB8URctC7DBZXUndwUYDpJ7QfUTPM/Q=
Received: by 10.65.186.10 with SMTP id n10mr691791qbp;
	Tue, 03 Jan 2006 21:50:27 -0800 (PST)
Received: by 10.65.210.12 with HTTP; Tue, 3 Jan 2006 21:50:27 -0800 (PST)
Message-ID: <558a39a60601032150q6ff2cf26x603fea87309adb02@mail.gmail.com>
Date: Wed, 4 Jan 2006 13:50:27 +0800
From: James Seng 
To: "Tom.Petch" 
In-Reply-To: <001f01c607ad$08fa5d00$0601a8c0@pc6>
MIME-Version: 1.0
References: <001501c60670$36f0eaa0$0601a8c0@pc6>
	<001f01c607ad$08fa5d00$0601a8c0@pc6>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Cc: ietf 
Subject: Re: Troubles with UTF-8
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1690983342=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1690983342==
Content-Type: multipart/alternative; 
	boundary="----=_Part_35501_3199542.1136353827949"

------=_Part_35501_3199542.1136353827949
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: base64

T24gMTIvMjMvMDUsIFRvbS5QZXRjaCA8c2lzeXBodXNAZGlhbC5waXBleC5jb20+IHdyb3RlOgo+
Cj4gQSkgQ2hhcmFjdGVyIHNldC4gIFVURi04IGltcGxpY2l0bHkgc3BlY2lmaWVzIHRoZSB1c2Ug
b2YgVW5pY29kZS9JUzEwNjQ2Cj4gd2hpY2gKPiBjb250YWlucyA5NywwMDAgLSBhbmQgcmlzaW5n
IC0gY2hhcmFjdGVycy4gIFNvbWUgKHByb3Bvc2VkKSBzdGFuZGFyZHMKPiBsaW1pdAo+IHRoZW1z
ZWx2ZXMgdG8gMDAwMC4uMDA3Riwgd2hpY2ggaXMgbm90IGF0IGFsbCBpbnRlcm5hdGlvbmFsLCBv
dGhlcnMgdG8KPiAwMDAwLTAwRkYsIGVzc2VudGlhbGx5IExhdGluLTEsIHdoaWNoIHN1aXRzIG1h
bnkgV2VzdGVybiBsYW5ndWFnZXMgYnV0IGlzCj4gbm90Cj4gdHJ1bHkgaW50ZXJuYXRpb25hbC4g
IElzIDk3LDAwMCByZWFsbHkgYXBwcm9wcmlhdGUgb3Igc2hvdWxkIHRoZXJlIGJlIGEKPiBkZWZp
bmVkCj4gc3Vic2V0PwoKCldoeSBzaG91bGQgdGhlcmUgYmUgYSBzdWJzZXQ/IFlvdSByZWFsbHkg
cmVhbGx5IGRvbnQgd2FudCB0byBnbyBpbnRvIGEKZGViYXRlIG9mIHdoaWNoIHNjcmlwdCBpcyBt
b3JlIGltcG9ydGFudCB0aGVuIHRoZSBvdGhlci4KCkIpIENvZGUgcG9pbnQuIE1hbnkgc3RhbmRh
cmRzIGFyZSBkZWZpbmVkIGluIEFCTkYgW1JGQzQyMzRdIHdoaWNoIGFsbG93cwo+IGNvZGUKPiBw
b2ludHMgdG8gYmUgc3BlY2lmaWVkIGFzLCBlZywgICViMDAwMTAwMTEgJWQxMyBvciAleDBEIG5v
bmUgb2Ygd2hpY2ggYXJlCj4gdGVycmlibHkgVW5pY29kZS1saWtlIChVKzAwMEQpLiAgVGhlIHJl
c3VsdCBpcyBzdGFuZGFyZHMgdGhhdCB1c2Ugb25lCj4gbm90YXRpb24KPiBpbiB0aGUgQUJORiBh
bmQgYSBkaWZmZXJlbnQgb25lIGluIHRoZSBib2R5IG9mIHRoZSBkb2N1bWVudDsgc2hvdWxkIEFC
TkYKPiBhbGxvdwo+IHNvbWV0aGluZyBjbG9zZXIgdG8gVW5pY29kZSAoYXMgWE1MIGhhcyBkb25l
IHdpdGggJiMwMDBEOyk/CgoKRm9sbG93aW5nIFJGQzQyMzQsIFVuaWNvZGUgY29kZSBwb2ludCBV
K0FCQ0Qgd2lsbCBqdXN0IGJlIHJlcHJlc2VudGVkIGFzCiV4QUJDRC4KCkkgZG8gbm90IHNlZSB0
aGUgcHJvYmxlbSB5b3UgbWVudGlvbiBvciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPwoKCkMpIExl
bmd0aC4gVGV4dCBpcyBvZnRlbiB2YXJpYWJsZSBpbiBsZW5ndGggc28gdGhlIGxlbmd0aCBtdXN0
IGJlCj4gZGV0ZXJtaW5lZC4KPiBUaGlzIG1heSBiZSBpbXBsaWNpdCBmcm9tIHRoZSB1bmRlcmx5
aW5nIHByb3RvY29sIG9yIGV4cGxpY2l0IGFzIGluIGEKPiBUTFYuICBUaGUKPiBsYXR0ZXIgaXMg
dHJvdWJsZXNvbWUgaWYgdGhlIHByb3RvY29sIHBhc3NlcyB0aHJvdWdoIGFuIGFwcGxpY2F0aW9u
Cj4gZ2F0ZXdheQo+IHdoaWNoIHdhbnRzIHRvIG5vcm1hbGlzZSB0aGUgZW5jb2Rpbmcgc28gYXMg
dG8gaW1wcm92ZSBzZWN1cml0eSBhbmQgd2FudHMKPiB0bwo+IGNvbnZlcnQgVVRGIHRvIGl0cyBz
aG9ydGVzdCBmb3JtIHdpdGggY29ycmVzcG9uZGluZyBsZW5ndGggY2hhbmdlcwo+IChVbmljb2Rl
Cj4gbGFja3MgYSBuby1vcCwgYSBtZWFuaW5nbGVzcyBvY3RldCwgb25lIHRoYXQgY291bGQgYmUg
YWRkZWQgb3IgcmVtb3ZlZAo+IHdpdGhvdXQKPiBjYXVzaW5nIGFueSBjaGFuZ2UgdG8gdGhlIG1l
YW5pbmcgb2YgdGhlIHRleHQpLgoKCldoaWxlIHRoZSBzaW1wbGUgYnl0ZSBjb3VudGluZyBvYnZp
b3VzbHkgd29udCBnaXZlIHlvdSB0aGUgYWNjdXJhdGUgbGVuZ3RoCm9mIHRoZSB0ZXh0IChzaW5j
ZSBvbmUgY2hhcmFjdGVyIGluIFVuaWNvZGUgbWF5YmUgcmVwcmVzZW50ZWQgYnkgb25lIG9yIG1v
cmUKYnl0ZXMpLCBpdCBpcyBmYWlybHkgdHJpdmFsIHRvIHdyaXRlIGEgc2NyaXB0IHRvIGNvdW50
IHRoZSBsZW5ndGggb2YgdGhlCnRleHQgYWNjdXJhdGVseS4gSGVjaywgcGVybCA1LjYgb253YXJk
cyBldmVuIHN1cHBvcnQgVW5pY29kZSBuYXRpdmVseS4KCgo+IE90aGVyIHByb3RvY29scyB1c2Ug
YSB0ZXJtaW5hdGluZyBzZXF1ZW5jZS4gIE5VTCBpcyB3aWRlbHkgdXNlZCBpbiAqaXg7Cj4gc29t
ZQo+IHByb3RvY29scyBzcGVjaWZ5IHRoYXQgTlVMIG11c3QgdGVybWluYXRlIHRoZSB0ZXh0LCBz
b21lIHNwZWNpZnkgdGhhdCBpdAo+IG11c3QKPiBub3QsIG9uZSBhdCBsZWFzdCBzcGVjaWZpZXMg
dGhhdCBlbWJlZGRlZCBOVUwgbWVhbnMgdGhhdCB0ZXh0IGFmdGVyIGEgTlVMCj4gbXVzdAo+IG5v
dCBiZSBkaXNwbGF5ZWQgKGludGVyZXN0aW5nIGZvciBzZWN1cml0eSkuICBTaW5jZSBVVEYtOCBl
bmNvbXBhc3NlcyBzbwo+IG11Y2gsCj4gdGhlcmUgaXMgbm8gbmF0dXJhbCB0ZXJtaW5hdGluZyBz
ZXF1ZW5jZS4KCgpOVUwgaXMgZGVmaW5lZCBpbiBVbmljb2RlIGJ0dyBidXQgSSBhbSBkaXNncmVz
c2luZzsgWW91IGFscmVhZHkgc3RhcnRlZCB3aXRoCmEgd3JvbmcgZm9vdCBpZiB5b3UgdGhpbmsg
VVRGLTggYXMgc29tZSBzb3J0IG9mIHByb2dyYW1taW5nIGVuY29kaW5nIHNjaGVtZQpyYXRoZXIg
dGhlbiB3aGF0IGl0IGlzOyBhbiBlbmNvZGluZyBzY2hlbWUgZm9yIGEgY2hhcmFjdGVyIHJlcG9y
dGFpcnMuCgoKPiBEKSBUcmFuc3BhcmVuY3kuICBBbiBpc3N1ZSBsaW5rZWQgdG8gQyksIHByb3Rv
Y29scyBtYXkgaGF2ZSByZXNlcnZlZAo+IGNoYXJhY3RlcnMsCj4gdXNlZCB0byBwYXJzZSB0aGUg
ZGF0YSwgd2hpY2ggbXVzdCBub3QgdGhlbiBhcHBlYXIgaW4gdGV4dC4gIFNvbWUKPiBwcm90b2Nv
bHMKPiBwcm9oaWJpdCB0aGVzZSBjaGFyYWN0ZXJzIChvciBhdCBsZWFzdCB0aGUgc2luZ2xlIG9j
dGV0IGVuY29kaW5nIG9mIHRoZW0pLAo+IG90aGVycyBoYXZlIGEgdHJhbnNmZXIgc3ludGF4LCBz
dWNoIGFzIGJhc2U2NCwgcXVvdGVkLXByaW50YWJsZSwgJXh4IG9yIGFuCj4gZXNjYXBlIGNoYXJh
Y3RlciAoICIgXCAlKS4gIFdlIGNvdWxkIGRvIHdpdGggYSBzdGFuZGFyZCBzeW50YXguCgoKSW4g
dGhvc2UgY2FzZXMsIFVuaWNvZGUgVStBQkNEIG9yIEFOQkYgJXhBQkNEIGRvIG5pY2VseS4gV2h5
IGRvIHdlIG5lZWQKYW5vdGhlciBvbmU/CgpFKSBBY2Nlc3NpYmlsaXR5LiAgVGhlIGNoYXJhY3Rl
ciBlbmNvZGluZyBpcyBzcGVjaWZpZWQgaW4gVVRGLTggW1JGQzM2MjldCj4gd2hpY2gKPiBpcyBy
ZWFkaWx5IGFjY2Vzc2libGUgKG9mIGNvdXJzZTotKSBidXQgdG8gdXNlIGl0IHByb3Blcmx5IG5l
ZWRzIHJlZmVyZW5jZQo+IHRvCj4gSVMxMDY0Niwgd2hpY2ggaXMgbm90LiAgSSB3b3VsZCBsaWtl
IHRvIGNoZWNrIHRoZSBjb3JyZWN0IG5hbWUgb2YgZWcKPiBoeXBoZW4tbWludXMgKEh5cGhlbi1t
aW51cywgSHlwaGVuLU1pbnVzLCA/Pz8pIGFuZCBpbiB0aGUgYWJzZW5jZSBvZgo+IElTMTA2NDYg
YW0KPiB1bmFibGUgdG8gZG8gc28uCgoKSW4gYWJzZW5jZSBvZiBhIGRpY3Rpb25hcnksIEkgY291
bGRuJ3QgdW5kZXJzdGFuZCBtb3N0IG9mIHRoZSB3b3JkcyB5b3UgdXNlZAppbiBhbiBSRkMuIE9N
Rywgd2hhdCBzaG91bGQgSSBkbz8KCmh0dHA6Ly93d3cudW5pY29kZS5vcmcvY2hhcnRzLwoKLUph
bWVzIFNlbmcK
------=_Part_35501_3199542.1136353827949
Content-Type: text/html; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: base64

T24gMTIvMjMvMDUsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5Ub20uUGV0Y2g8L2I+ICZs
dDs8YSBocmVmPSJtYWlsdG86c2lzeXBodXNAZGlhbC5waXBleC5jb20iPnNpc3lwaHVzQGRpYWwu
cGlwZXguY29tPC9hPiZndDsgd3JvdGU6PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPjwv
c3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDog
MXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsg
cGFkZGluZy1sZWZ0OiAxZXg7Ij4KQSkgQ2hhcmFjdGVyIHNldC4mbmJzcDsmbmJzcDtVVEYtOCBp
bXBsaWNpdGx5IHNwZWNpZmllcyB0aGUgdXNlIG9mIFVuaWNvZGUvSVMxMDY0NiB3aGljaDxicj5j
b250YWlucyA5NywwMDAgLSBhbmQgcmlzaW5nIC0gY2hhcmFjdGVycy4mbmJzcDsmbmJzcDtTb21l
IChwcm9wb3NlZCkgc3RhbmRhcmRzIGxpbWl0PGJyPnRoZW1zZWx2ZXMgdG8gMDAwMC4uMDA3Riwg
d2hpY2ggaXMgbm90IGF0IGFsbCBpbnRlcm5hdGlvbmFsLCBvdGhlcnMgdG8KPGJyPjAwMDAtMDBG
RiwgZXNzZW50aWFsbHkgTGF0aW4tMSwgd2hpY2ggc3VpdHMgbWFueSBXZXN0ZXJuIGxhbmd1YWdl
cyBidXQgaXMgbm90PGJyPnRydWx5IGludGVybmF0aW9uYWwuJm5ic3A7Jm5ic3A7SXMgOTcsMDAw
IHJlYWxseSBhcHByb3ByaWF0ZSBvciBzaG91bGQgdGhlcmUgYmUgYSBkZWZpbmVkPGJyPnN1YnNl
dD88L2Jsb2NrcXVvdGU+PGRpdj48YnI+V2h5IHNob3VsZCB0aGVyZSBiZSBhIHN1YnNldD8gWW91
IHJlYWxseSByZWFsbHkgZG9udCB3YW50IHRvIGdvIGludG8gYSBkZWJhdGUgb2Ygd2hpY2ggc2Ny
aXB0IGlzIG1vcmUgaW1wb3J0YW50IHRoZW4gdGhlIG90aGVyLgo8YnI+PC9kaXY+PGJyPjxibG9j
a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQg
cmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxl
ZnQ6IDFleDsiPkIpIENvZGUgcG9pbnQuIE1hbnkgc3RhbmRhcmRzIGFyZSBkZWZpbmVkIGluIEFC
TkYgW1JGQzQyMzRdIHdoaWNoIGFsbG93cyBjb2RlPGJyPgpwb2ludHMgdG8gYmUgc3BlY2lmaWVk
IGFzLCBlZywmbmJzcDsmbmJzcDslYjAwMDEwMDExICVkMTMgb3IgJXgwRCBub25lIG9mIHdoaWNo
IGFyZTxicj50ZXJyaWJseSBVbmljb2RlLWxpa2UgKFUrMDAwRCkuJm5ic3A7Jm5ic3A7VGhlIHJl
c3VsdCBpcyBzdGFuZGFyZHMgdGhhdCB1c2Ugb25lIG5vdGF0aW9uPGJyPmluIHRoZSBBQk5GIGFu
ZCBhIGRpZmZlcmVudCBvbmUgaW4gdGhlIGJvZHkgb2YgdGhlIGRvY3VtZW50OyBzaG91bGQgQUJO
RiBhbGxvdwo8YnI+c29tZXRoaW5nIGNsb3NlciB0byBVbmljb2RlIChhcyBYTUwgaGFzIGRvbmUg
d2l0aCAmYW1wOyMwMDBEOyk/PC9ibG9ja3F1b3RlPjxkaXY+PGJyPkZvbGxvd2luZyBSRkM0MjM0
LCBVbmljb2RlIGNvZGUgcG9pbnQgVStBQkNEIHdpbGwganVzdCBiZSByZXByZXNlbnRlZCBhcyAl
eEFCQ0QuIDxicj48YnI+SSBkbyBub3Qgc2VlIHRoZSBwcm9ibGVtIHlvdSBtZW50aW9uIG9yIGFt
IEkgbWlzc2luZyBzb21ldGhpbmc/Cjxicj4mbmJzcDs8L2Rpdj48YnI+PGJsb2NrcXVvdGUgY2xh
c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAy
MDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+
QykgTGVuZ3RoLiBUZXh0IGlzIG9mdGVuIHZhcmlhYmxlIGluIGxlbmd0aCBzbyB0aGUgbGVuZ3Ro
IG11c3QgYmUgZGV0ZXJtaW5lZC4KPGJyPlRoaXMgbWF5IGJlIGltcGxpY2l0IGZyb20gdGhlIHVu
ZGVybHlpbmcgcHJvdG9jb2wgb3IgZXhwbGljaXQgYXMgaW4gYSBUTFYuJm5ic3A7Jm5ic3A7VGhl
PGJyPmxhdHRlciBpcyB0cm91Ymxlc29tZSBpZiB0aGUgcHJvdG9jb2wgcGFzc2VzIHRocm91Z2gg
YW4gYXBwbGljYXRpb24gZ2F0ZXdheTxicj53aGljaCB3YW50cyB0byBub3JtYWxpc2UgdGhlIGVu
Y29kaW5nIHNvIGFzIHRvIGltcHJvdmUgc2VjdXJpdHkgYW5kIHdhbnRzIHRvCjxicj5jb252ZXJ0
IFVURiB0byBpdHMgc2hvcnRlc3QgZm9ybSB3aXRoIGNvcnJlc3BvbmRpbmcgbGVuZ3RoIGNoYW5n
ZXMgKFVuaWNvZGU8YnI+bGFja3MgYSBuby1vcCwgYSBtZWFuaW5nbGVzcyBvY3RldCwgb25lIHRo
YXQgY291bGQgYmUgYWRkZWQgb3IgcmVtb3ZlZCB3aXRob3V0PGJyPmNhdXNpbmcgYW55IGNoYW5n
ZSB0byB0aGUgbWVhbmluZyBvZiB0aGUgdGV4dCkuPC9ibG9ja3F1b3RlPgo8ZGl2Pjxicj5XaGls
ZSB0aGUgc2ltcGxlIGJ5dGUgY291bnRpbmcgb2J2aW91c2x5IHdvbnQgZ2l2ZSB5b3UgdGhlIGFj
Y3VyYXRlIGxlbmd0aCBvZiB0aGUgdGV4dCAoc2luY2Ugb25lIGNoYXJhY3RlciBpbiBVbmljb2Rl
IG1heWJlIHJlcHJlc2VudGVkIGJ5IG9uZSBvciBtb3JlIGJ5dGVzKSwgaXQgaXMgZmFpcmx5IHRy
aXZhbCB0byB3cml0ZSBhIHNjcmlwdCB0byBjb3VudCB0aGUgbGVuZ3RoIG9mIHRoZSB0ZXh0IGFj
Y3VyYXRlbHkuIEhlY2ssIHBlcmwgCjUuNiBvbndhcmRzIGV2ZW4gc3VwcG9ydCBVbmljb2RlIG5h
dGl2ZWx5Ljxicj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0
eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAw
cHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij5PdGhlciBwcm90b2NvbHMgdXNl
IGEgdGVybWluYXRpbmcgc2VxdWVuY2UuJm5ic3A7Jm5ic3A7TlVMIGlzIHdpZGVseSB1c2VkIGlu
ICppeDsgc29tZQo8YnI+cHJvdG9jb2xzIHNwZWNpZnkgdGhhdCBOVUwgbXVzdCB0ZXJtaW5hdGUg
dGhlIHRleHQsIHNvbWUgc3BlY2lmeSB0aGF0IGl0IG11c3Q8YnI+bm90LCBvbmUgYXQgbGVhc3Qg
c3BlY2lmaWVzIHRoYXQgZW1iZWRkZWQgTlVMIG1lYW5zIHRoYXQgdGV4dCBhZnRlciBhIE5VTCBt
dXN0PGJyPm5vdCBiZSBkaXNwbGF5ZWQgKGludGVyZXN0aW5nIGZvciBzZWN1cml0eSkuJm5ic3A7
Jm5ic3A7U2luY2UgVVRGLTggZW5jb21wYXNzZXMgc28gbXVjaCwKPGJyPnRoZXJlIGlzIG5vIG5h
dHVyYWwgdGVybWluYXRpbmcgc2VxdWVuY2UuPC9ibG9ja3F1b3RlPjxkaXY+PGJyPk5VTCBpcyBk
ZWZpbmVkIGluIFVuaWNvZGUgYnR3IGJ1dCBJIGFtIGRpc2dyZXNzaW5nOyBZb3UgYWxyZWFkeSBz
dGFydGVkIHdpdGggYSB3cm9uZyBmb290IGlmIHlvdSB0aGluayBVVEYtOCBhcyBzb21lIHNvcnQg
b2YgcHJvZ3JhbW1pbmcgZW5jb2Rpbmcgc2NoZW1lIHJhdGhlciB0aGVuIHdoYXQgaXQgaXM7IGFu
IGVuY29kaW5nIHNjaGVtZSBmb3IgYSBjaGFyYWN0ZXIgcmVwb3J0YWlycy4KPGJyPiZuYnNwOzwv
ZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAx
cHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBw
YWRkaW5nLWxlZnQ6IDFleDsiPkQpIFRyYW5zcGFyZW5jeS4mbmJzcDsmbmJzcDtBbiBpc3N1ZSBs
aW5rZWQgdG8gQyksIHByb3RvY29scyBtYXkgaGF2ZSByZXNlcnZlZCBjaGFyYWN0ZXJzLDxicj4K
dXNlZCB0byBwYXJzZSB0aGUgZGF0YSwgd2hpY2ggbXVzdCBub3QgdGhlbiBhcHBlYXIgaW4gdGV4
dC4mbmJzcDsmbmJzcDtTb21lIHByb3RvY29sczxicj5wcm9oaWJpdCB0aGVzZSBjaGFyYWN0ZXJz
IChvciBhdCBsZWFzdCB0aGUgc2luZ2xlIG9jdGV0IGVuY29kaW5nIG9mIHRoZW0pLDxicj5vdGhl
cnMgaGF2ZSBhIHRyYW5zZmVyIHN5bnRheCwgc3VjaCBhcyBiYXNlNjQsIHF1b3RlZC1wcmludGFi
bGUsICV4eCBvciBhbgo8YnI+ZXNjYXBlIGNoYXJhY3RlciAoICZxdW90OyBcICUpLiZuYnNwOyZu
YnNwO1dlIGNvdWxkIGRvIHdpdGggYSBzdGFuZGFyZCBzeW50YXguPC9ibG9ja3F1b3RlPjxkaXY+
PGJyPkluIHRob3NlIGNhc2VzLCBVbmljb2RlIFUrQUJDRCBvciBBTkJGICV4QUJDRCBkbyBuaWNl
bHkuIFdoeSBkbyB3ZSBuZWVkIGFub3RoZXIgb25lPzxicj48L2Rpdj48YnI+PGJsb2NrcXVvdGUg
Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0
LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4
OyI+CkUpIEFjY2Vzc2liaWxpdHkuJm5ic3A7Jm5ic3A7VGhlIGNoYXJhY3RlciBlbmNvZGluZyBp
cyBzcGVjaWZpZWQgaW4gVVRGLTggW1JGQzM2MjldIHdoaWNoPGJyPmlzIHJlYWRpbHkgYWNjZXNz
aWJsZSAob2YgY291cnNlOi0pIGJ1dCB0byB1c2UgaXQgcHJvcGVybHkgbmVlZHMgcmVmZXJlbmNl
IHRvPGJyPklTMTA2NDYsIHdoaWNoIGlzIG5vdC4mbmJzcDsmbmJzcDtJIHdvdWxkIGxpa2UgdG8g
Y2hlY2sgdGhlIGNvcnJlY3QgbmFtZSBvZiBlZwo8YnI+aHlwaGVuLW1pbnVzIChIeXBoZW4tbWlu
dXMsIEh5cGhlbi1NaW51cywgPz8/KSBhbmQgaW4gdGhlIGFic2VuY2Ugb2YgSVMxMDY0NiBhbTxi
cj51bmFibGUgdG8gZG8gc28uPC9ibG9ja3F1b3RlPjxkaXY+PGJyPkluIGFic2VuY2Ugb2YgYSBk
aWN0aW9uYXJ5LCBJIGNvdWxkbid0IHVuZGVyc3RhbmQgbW9zdCBvZiB0aGUgd29yZHMgeW91IHVz
ZWQgaW4gYW4gUkZDLiBPTUcsIHdoYXQgc2hvdWxkIEkgZG8/Cjxicj48YnI+PGEgaHJlZj0iaHR0
cDovL3d3dy51bmljb2RlLm9yZy9jaGFydHMvIj5odHRwOi8vd3d3LnVuaWNvZGUub3JnL2NoYXJ0
cy88L2E+PGJyPjxicj4tSmFtZXMgU2VuZzxicj48L2Rpdj48L2Rpdj4K
------=_Part_35501_3199542.1136353827949--


--===============1690983342==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1690983342==--




From ietf-bounces@ietf.org Wed Jan 04 01:15:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu1vu-0006qv-0Y; Wed, 04 Jan 2006 01:15:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu1vr-0006qo-RY
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 01:15:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12767
	for ; Wed, 4 Jan 2006 01:14:19 -0500 (EST)
Received: from mx1-b.rad.co.il ([62.219.98.8] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu21C-0001Ar-G2
	for ietf@ietf.org; Wed, 04 Jan 2006 01:21:11 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k046BHYL018757
	for ; Wed, 4 Jan 2006 08:11:17 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k046BGLx018754;
	Wed, 4 Jan 2006 08:11:16 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 4 Jan 2006 08:15:01 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5205DCE1C5@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYQolL+YGxZU54lTrCU3U2ZhM0h4QAU7Krg
From: "Yaakov Stein" 
To: "Gray, Eric" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

=20

> Clarifying that "publicly known" means "well defined and publicly
available", I would answer no...

and if it is restricted to mean=20
  "open description so that you could write your own editor to read and
write this format" ?



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 02:12:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu2oy-0001in-AN; Wed, 04 Jan 2006 02:12:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu2ow-0001ii-BG
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 02:12:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19418
	for ; Wed, 4 Jan 2006 02:11:14 -0500 (EST)
Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eu2uK-0003PK-W4
	for ietf@ietf.org; Wed, 04 Jan 2006 02:18:07 -0500
Received: (qmail 19091 invoked from network); 4 Jan 2006 07:54:39 -0000
Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp)
	(131.112.32.134)
	by necom830.hpcl.titech.ac.jp with SMTP; 4 Jan 2006 07:54:39 -0000
Message-ID: <43BB7552.6010904@necom830.hpcl.titech.ac.jp>
Date: Wed, 04 Jan 2006 16:12:18 +0900
From: Masataka Ohta 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: Tim Bray 
References: <001501c60670$36f0eaa0$0601a8c0@pc6>
	<001f01c607ad$08fa5d00$0601a8c0@pc6>
	<01LWWGAWH28600009C@mauve.mrochek.com>
	<015101c608b7$8d453c00$0601a8c0@pc6>
	<01LWY2922HSM00009C@mauve.mrochek.com>
	<002d01c60b8f$131c79e0$0601a8c0@pc6>
	<43B28DB5.7080501@necom830.hpcl.titech.ac.jp>
	<519D27B9-4723-487E-8E15-DEB326600546@textuality.com>
In-Reply-To: <519D27B9-4723-487E-8E15-DEB326600546@textuality.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Cc: Ned Freed , ietf 
Subject: Re: Troubles with UTF-8
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Tim Bray wrote:

>> That problem is that Unicode is stateful with complex and
>> indefinitely long term states

> Has this ever caused a real problem to a real programmer in real life?

Yes, of course. State information preserved between lines is
really annoying.

But, you miss the point in my original mail:

: Unicode is not even finite state, which means some pattern
: matching and normalization problems are hard or insolvable.

that is, with Unicode, you can not search strings in reasonable
amount of time.

> I have written a whole bunch of mission-critical code that reads and  
> generates UTF-8, and any correct implementation will have to deal  with 
> the fact that there is no necessary connection between the  number of 
> glyphs on the screen and bytes in its encoding.

You completely miss the point. It has nothing to do with the long
term state.

> It would  be perfectly 
> reasonable for an implementation to declare a  limitation, for example 
> that it will not process than 32 trailing  modifiers on any character, 
> and this would not cause problems in  production because sequences of 
> such a length do not occur in the  encoding of any known text.

I said "long term state", which, of course, is not confined in a
character with or without modifiers.

> Which is to say, Ohta's statement about statefulness is true, but the  
> conclusion that this is a "problem" is erroneous. -Tim

Instead, your statement: "I have written a whole bunch of mission-
critical code that reads and generates UTF-8" is untrustworthy.

Of course, it is perfectly reasonable for an implementation to
declare a limitation, for example, that it will not process
non-ASCII characters, which may also be the assumption of your
code.

						Masataka Ohta 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 03:56:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu4RV-0004yB-KU; Wed, 04 Jan 2006 03:56:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu4RS-0004y6-QQ
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 03:56:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29099
	for ; Wed, 4 Jan 2006 03:55:08 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eu4Ws-0006dw-Oa
	for ietf@ietf.org; Wed, 04 Jan 2006 04:02:00 -0500
Received: (qmail invoked by alias); 04 Jan 2006 08:56:09 -0000
Received: from p508F8EA8.dip0.t-ipconnect.de (EHLO [192.168.178.21])
	[80.143.142.168]
	by mail.gmx.net (mp017) with SMTP; 04 Jan 2006 09:56:09 +0100
X-Authenticated: #1915285
Message-ID: <43BB8D46.7080203@gmx.de>
Date: Wed, 04 Jan 2006 09:54:30 +0100
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Yaakov Stein 
References: <27A0F290348F8E45AEF79889DDE65A5205DCE1C5@exrad2.ad.rad.co.il>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205DCE1C5@exrad2.ad.rad.co.il>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Yaakov Stein wrote:
>  
> 
>> Clarifying that "publicly known" means "well defined and publicly
> available", I would answer no...
> 
> and if it is restricted to mean 
>   "open description so that you could write your own editor to read and
> write this format" ?

...without having to sign a contract to the owner of the format, being 
able to rely on its stability, and not having to pay for it...?

Best regards, Julian

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 04:25:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu4tS-0002kW-Ni; Wed, 04 Jan 2006 04:25:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu4tP-0002gN-1x; Wed, 04 Jan 2006 04:25:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02127;
	Wed, 4 Jan 2006 04:24:01 -0500 (EST)
From: Pasi.Eronen@nokia.com
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Eu4yq-0007lK-6F; Wed, 04 Jan 2006 04:30:53 -0500
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k049KsRX008573; Wed, 4 Jan 2006 11:20:58 +0200
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Jan 2006 11:25:10 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Jan 2006 11:25:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 4 Jan 2006 11:25:10 +0200
Message-ID: 
Thread-Topic: Last call comments about "Repeated Authentication in IKEv2"
Thread-Index: AcYREMKT4WFgsDPjSAWeFuAytOPDDg==
To: 
X-OriginalArrivalTime: 04 Jan 2006 09:25:09.0453 (UTC)
	FILETIME=[C1C267D0:01C61110]
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable
Cc: ipsec@ietf.org
Subject: Last call comments about "Repeated Authentication in IKEv2"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


1) Overall: Being able to reauthenticate the client (either
periodically or by some other trigger) is a common requirement in
remote access deployments. It's a good idea to have one documented
way to do this, instead of each vendor inventing its own proprietary
payloads. Thus, I think this document is a very useful extension to
IKEv2, and deserves to be published.

2) The document could be more precise about in describing what
messages can contain the AUTH_LIFETIME notification. The intent was
clearly "in the last IKE_AUTH response or in any INFORMATIONAL
request", but this is not exactly the same as saying "in a separate
Informational exchange" (which might be interpreted as including
both the request and response messages) or "MAY be sent by the
original Responder at any time".

3) Section 2: "It is recommended that an INITIAL-CONTACT
notification be included in the AUTH exchange."=20

This is probably not correct. RFC4306 says that "This notification
MUST NOT be sent by an entity that may be replicated (e.g., a
roaming user's credentials where the user is allowed to connect to
the corporate firewall from two remote systems at the same time)."

Even if the corporate IT department has decided not to allow this,
the initiator probably does not know this, so it should not include
the notification.=20

Furthermore, the INITIAL_CONTACT notification is not really needed=20
for anything in this case, since the client has not crashed,
and it still has all the information it needs to properly close=20
the old IKE_SA (once the new one has been established).

4) Section 7 (IANA Considerations): The text should say that the
number needs to be assigned from the "Status Types" range (and not
the "Error Types" part)

5) Typos etc.
Section 2: the Informational response should be "HDR, SK{}"=20
Section 3, s/AUTH_LEFETIME/AUTH_LIFETIME/
Section 6, should explicitly say that both references are normative

Best regards,
Pasi

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 06:59:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu7IJ-0002M2-CI; Wed, 04 Jan 2006 06:59:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu7IH-0002Ls-EU
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 06:59:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19244
	for ; Wed, 4 Jan 2006 06:57:50 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu7Ni-0004pU-82
	for IETF@ietf.org; Wed, 04 Jan 2006 07:04:45 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 5EC181790AB; Wed,  4 Jan 2006 06:59:04 -0500 (EST)
To: "william(at)elan.net" 
References: 
	 <43A8893F.9010700@dcrocker.net>
	 <43A8C2EC.4060401@dcrocker.net>
	
	
	
	
From: Sam Hartman 
Date: Wed, 04 Jan 2006 06:59:04 -0500
In-Reply-To:  (william
	elan net's message of "Wed, 21 Dec 2005 09:23:15 -0800 (PST)")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: Harald Tveit Alvestrand , ietf-dkim@mipassoc.org,
	IETF@ietf.org
Subject: Alternatives to DKIM
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "william(at)elan" == william(at)elan net  writes:
    william(at)elan> And yes in case you don't know BoF chairs and AD
    william(at)elan> did deny request to present alternatives to DKIM
    william(at)elan> when it was still called MASS BoF.


Russ did state an explicit course of action for those with
alternatives to DKIM.  He asked them to get a specific proposal
together and ask for their own BOF.

I don't know what mail Russ has received, but I know that even though
we have had another IETF meeting since that BOF, no requests were
copied to me for other related BOFs.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 07:12:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu7VV-0005Yr-LK; Wed, 04 Jan 2006 07:12:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu7VT-0005Yk-69
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 07:12:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20847
	for ; Wed, 4 Jan 2006 07:11:28 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu7av-0005LO-LX
	for ietf@ietf.org; Wed, 04 Jan 2006 07:18:22 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 39780160059; Wed,  4 Jan 2006 07:12:40 -0500 (EST)
To: dcrocker@bbiw.net
References: <20060101043514.6985.qmail@xuxa.iecc.com>
	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM> <43B81D34.8030104@dcrocker.net>
From: Sam Hartman 
Date: Wed, 04 Jan 2006 07:12:40 -0500
In-Reply-To: <43B81D34.8030104@dcrocker.net> (Dave Crocker's message of
	"Sun, 01 Jan 2006 10:19:32 -0800")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: quoted-printable
Cc: John C Klensin , ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Dave" =3D=3D Dave Crocker  writes:

    Dave> John K., et al, Feliz a=F1o nuevo; Selamat tahun baru.


    >> I do believe that it is not desirable to create standards that
    >> would give a gift of either technology or justification to
    >> those who would use them to fragment the network.  I believe it
    >> is especially

    Dave> I suspect we will not find anyone in the IETF who thinks
    Dave> otherwise.  Certainly my own reaction to your statement,
    Dave> here, was "Yes!!  Absolutely Correct!"

    Dave> Then I tried to consider the implications of the statement,
    Dave> in the current context, and I realized that I have no idea
    Dave> what pragmatic import it has.

    Dave> I have no idea how to apply this caveat to the DKIM work.

    Dave> DKIM is DKIM. As a technology it has a specific intent and
    Dave> its core is well-defined -- and actually pretty simple --
    Dave> with well-understood properties. The core is similar to a
    Dave> number of technologies that have been in use for at least 15
    Dave> years.

I think John is expressing a concern similar to the one I expressed at
the BOF.

Roughly we need to consider how DKIM is used, not just define a
technology.  We need to talk about bad uses of DKIM as soon as we are
aware that they are sufficinetly likely that they are worth
considering.

We need to write BCPs as soon as we are in a position to know what
best practice actually is.

Now, other than acknowledging that we need to eventually do these
things, I don't think this has any impact on the charter.  On the
other hand, John replied to a message about three levels removed from
the charter and proposed no specific changes to the charter.  So I
don't have any evidence that he planned to change the charter either.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 08:22:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu8aW-0004Hi-NK; Wed, 04 Jan 2006 08:22:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu8aT-0004HF-9K; Wed, 04 Jan 2006 08:21:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28892;
	Wed, 4 Jan 2006 08:20:41 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Eu8fw-00082H-RE; Wed, 04 Jan 2006 08:27:38 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id B3926160059; Wed,  4 Jan 2006 08:21:54 -0500 (EST)
To: Russ Housley 
References: <20051221010622.1DE47222418@laser.networkresonance.com>
	<43A8BACF.50701@watson.ibm.com> <43A9618C.9000603@att.com>
	 <43A9E6FB.8050706@watson.ibm.com>
	<43A9EE2F.7080504@cs.utk.edu>
	<7.0.0.16.2.20060102113007.05eee498@vigilsec.com>
From: Sam Hartman 
Date: Wed, 04 Jan 2006 08:21:54 -0500
In-Reply-To: <7.0.0.16.2.20060102113007.05eee498@vigilsec.com> (Russ
	Housley's message of "Mon, 02 Jan 2006 11:39:56 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d62ab47271805379d7172ee693a45db
Cc: ietf-dkim@mipassoc.org, ietf@ietf.org, iesg@ietf.org
Subject: Re: WG Review: Domain Keys Identified Mail (dkim)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I support the new charter and thank those who spent the time
discussing it and walking through alternatives.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 08:40:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu8sP-0008UK-It; Wed, 04 Jan 2006 08:40:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu5Up-0002LV-Bv; Wed, 04 Jan 2006 05:03:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07000;
	Wed, 4 Jan 2006 05:02:40 -0500 (EST)
Received: from michael.checkpoint.com ([194.29.32.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Eu5aG-0000tN-5z; Wed, 04 Jan 2006 05:09:33 -0500
Received: from YnirNew (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	k04A3XY9024169; Wed, 4 Jan 2006 12:03:33 +0200 (IST)
Message-Id: <200601041003.k04A3XY9024169@michael.checkpoint.com>
From: "Yoav Nir" 
To: , 
Date: Wed, 4 Jan 2006 12:03:33 +0200
Organization: Check Point
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcYREMKT4WFgsDPjSAWeFuAytOPDDgABDrew
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
In-Reply-To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 04 Jan 2006 08:40:25 -0500
Cc: ipsec@ietf.org
Subject: RE: [Ipsec] Last call comments about "Repeated Authentication in
	IKEv2"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Comments inline 

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] 
> On Behalf Of Pasi.Eronen@nokia.com
> 
> 1) Overall: Being able to reauthenticate the client (either
> periodically or by some other trigger) is a common requirement in
> remote access deployments. It's a good idea to have one documented
> way to do this, instead of each vendor inventing its own proprietary
> payloads. Thus, I think this document is a very useful extension to
> IKEv2, and deserves to be published.
> 
> 2) The document could be more precise about in describing what
> messages can contain the AUTH_LIFETIME notification. The intent was
> clearly "in the last IKE_AUTH response or in any INFORMATIONAL
> request", but this is not exactly the same as saying "in a separate
> Informational exchange" (which might be interpreted as including
> both the request and response messages) or "MAY be sent by the
> original Responder at any time".

You're right about the former, but I think the latter needs to stay. It
refers to the timing of sending the message.

> 3) Section 2: "It is recommended that an INITIAL-CONTACT
> notification be included in the AUTH exchange." 
> 
> This is probably not correct. RFC4306 says that "This notification
> MUST NOT be sent by an entity that may be replicated (e.g., a
> roaming user's credentials where the user is allowed to connect to
> the corporate firewall from two remote systems at the same time)."
> 
> Even if the corporate IT department has decided not to allow this,
> the initiator probably does not know this, so it should not include
> the notification. 
> 
> Furthermore, the INITIAL_CONTACT notification is not really needed 
> for anything in this case, since the client has not crashed,
> and it still has all the information it needs to properly close 
> the old IKE_SA (once the new one has been established).

I thought INITIAL_CONTACT would be a shorter way to achieve the same goal,
but I forgot about the replication problem. I agree.  This line must go.

> 4) Section 7 (IANA Considerations): The text should say that the
> number needs to be assigned from the "Status Types" range (and not
> the "Error Types" part)

Well, if and when this is published, This would change to a specific,
allocated number.  I did write this in the IANA application.
 
> 5) Typos etc.
> Section 2: the Informational response should be "HDR, SK{}" 
> Section 3, s/AUTH_LEFETIME/AUTH_LIFETIME/
> Section 6, should explicitly say that both references are normative

Agreed.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 08:51:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eu93J-0002hT-Rw; Wed, 04 Jan 2006 08:51:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu93I-0002hO-AT
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 08:51:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02429
	for ; Wed, 4 Jan 2006 08:50:28 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eu98m-0000aV-1K
	for ietf@ietf.org; Wed, 04 Jan 2006 08:57:25 -0500
Received: (qmail 18679 invoked by uid 100); 4 Jan 2006 13:51:33 -0000
Date: 4 Jan 2006 13:51:33 -0000
Message-ID: <20060104135133.18678.qmail@xuxa.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: 
Organization: I.E.C.C., Trumansburg NY USA
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: hartmans-ietf@mit.edu
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Roughly we need to consider how DKIM is used, not just define a
> technology.  We need to talk about bad uses of DKIM as soon as we
> are aware that they are sufficinetly likely that they are worth
> considering.

Here's a concrete suggestion: it is clear that the bad uses of DKIM
people have mentioned are a subset of the bad uses of STARTTLS.

I have seen concerns that third party reputation lists might be used
to create walled gardens or closed networks with DKIM.  This is not
just a theoretical risk with STARTTLS.  People have already done
exactly that, since TLS unlike DKIM already includes the facilities
for third parties to indicate which keys they like and which ones they
don't.  And the TLS world is dominated by a single signer whose
signing policies are opaque.

So how about if we simply reuse the warning language about STARTTLS
from RFC 3207?  If that's not adequate, do we need to write similar
warnings about STARTTLS?

R's,
John

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 09:55:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuA2Z-000881-AG; Wed, 04 Jan 2006 09:55:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuA2X-00087T-99
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 09:55:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09992
	for ; Wed, 4 Jan 2006 09:53:47 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuA81-0002vT-C1
	for ietf@ietf.org; Wed, 04 Jan 2006 10:00:42 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 393A6160059; Wed,  4 Jan 2006 09:54:56 -0500 (EST)
To: John Levine 
References: <20060104135133.18678.qmail@xuxa.iecc.com>
From: Sam Hartman 
Date: Wed, 04 Jan 2006 09:54:56 -0500
In-Reply-To: <20060104135133.18678.qmail@xuxa.iecc.com> (John Levine's
	message of "4 Jan 2006 13:51:33 -0000")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "John" == John Levine  writes:

    >> Roughly we need to consider how DKIM is used, not just define a
    >> technology.  We need to talk about bad uses of DKIM as soon as
    >> we are aware that they are sufficinetly likely that they are
    >> worth considering.

    John> Here's a concrete suggestion: it is clear that the bad uses
    John> of DKIM people have mentioned are a subset of the bad uses
    John> of STARTTLS.

That's not clear to me.
I'd never really considered the question though so it may well be true.

    John> I have seen concerns that third party reputation lists might
    John> be used to create walled gardens or closed networks with
    John> DKIM.  This is not just a theoretical risk with STARTTLS.
    John> People have already done exactly that, since TLS unlike DKIM
    John> already includes the facilities for third parties to
    John> indicate which keys they like and which ones they don't.


Interesting I'll admit that I have not run into people who seem to
have a problem with a self-signed starttls cert in practice, although
I might not have noticed.  Also, I don't configure MTAs or my MUA to
offer a client cert, only a server cert.

I agree it is possible and am happy to take your word for it that someone has done so.

    John> And the TLS world is dominated by a single signer whose
    John> signing policies are opaque.

Really?  Are you sure the TLS world is not dominated by users clicking
OK trust this cert for anything they see, combined with a lot of self
signed certs and certs from a variety of CAs?  I do expect that most
web sites tend to have Verisign certs, but I have no idea about other
uses of TLS.

    John> So how about if we simply reuse the warning language about
    John> STARTTLS from RFC 3207?  

What warning language?  I can't find anything related to this problem.
I may not be looking carefully enough.


    John> If that's not adequate, do we need
    John> to write similar warnings about STARTTLS?

Quite possibly.


--Sam

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 10:27:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuAXy-0007rC-Nn; Wed, 04 Jan 2006 10:27:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuAXv-0007r0-Tv
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 10:27:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14736
	for ; Wed, 4 Jan 2006 10:26:13 -0500 (EST)
Received: from tom.iecc.com ([208.31.42.38])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuAdP-0004HV-5G
	for ietf@ietf.org; Wed, 04 Jan 2006 10:33:08 -0500
Received: (qmail 1263 invoked from network); 4 Jan 2006 15:27:16 -0000
Received: (ofmipd 127.0.0.1); 4 Jan 2006 15:26:54 -0000
Date: 4 Jan 2006 10:27:16 -0500
Message-ID: 
From: "John R Levine" 
To: "Sam Hartman" 
In-Reply-To: 
References: <20060104135133.18678.qmail@xuxa.iecc.com>
	
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>     John> Here's a concrete suggestion: it is clear that the bad uses
>     John> of DKIM people have mentioned are a subset of the bad uses
>     John> of STARTTLS.
>
> That's not clear to me.
> I'd never really considered the question though so it may well be true.

If walled gardens are the problem or the goal, STARTTLS is a swell way to
do it.

>     John> And the TLS world is dominated by a single signer whose
>     John> signing policies are opaque.
>
> Really?  Are you sure the TLS world is not dominated by users clicking
> OK trust this cert for anything they see, combined with a lot of self
> signed certs and certs from a variety of CAs?

The CAs that people use in web SSL are overwhelmingly signed by Verisign
or its subsidiaries like Thawte.  Geotrust is a distant second.

I honestly don't know what signers people use for STARTTLS but since
everyone uses the same small set of TLS libraries, my working assumption
is that they use the same small set of authorities, too.

>     John> So how about if we simply reuse the warning language about
>     John> STARTTLS from RFC 3207?
>
> What warning language?  I can't find anything related to this problem.
> I may not be looking carefully enough.

There isn't any.  That's my point.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 10:30:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuAaW-0008Gx-NK; Wed, 04 Jan 2006 10:30:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuAaU-0008Fd-DD
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 10:30:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15173
	for ; Wed, 4 Jan 2006 10:28:52 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuAfy-0004PX-Ic
	for ietf@ietf.org; Wed, 04 Jan 2006 10:35:48 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id CC114160059; Wed,  4 Jan 2006 10:30:07 -0500 (EST)
To: "John R Levine" 
References: <20060104135133.18678.qmail@xuxa.iecc.com>
	
	
From: Sam Hartman 
Date: Wed, 04 Jan 2006 10:30:07 -0500
In-Reply-To:  (John R.
	Levine's message of "4 Jan 2006 10:27:16 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "John" == John R Levine  writes:

    John> The CAs that people use in web SSL are overwhelmingly signed
    John> by Verisign or its subsidiaries like Thawte.  Geotrust is a
    John> distant second.

    John> I honestly don't know what signers people use for STARTTLS
    John> but since everyone uses the same small set of TLS libraries,
    John> my working assumption is that they use the same small set of
    John> authorities, too.

OK.  If this is just an assumption and not backed by evidence, I would
suspect that outside of the web you see a lot less use of the big CAs.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 10:32:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuAd3-0000GX-QM; Wed, 04 Jan 2006 10:32:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuAd1-0000GO-CX
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 10:32:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15431
	for ; Wed, 4 Jan 2006 10:31:29 -0500 (EST)
Received: from tom.iecc.com ([208.31.42.38])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuAiV-0004Uh-P3
	for ietf@ietf.org; Wed, 04 Jan 2006 10:38:25 -0500
Received: (qmail 2113 invoked from network); 4 Jan 2006 15:32:41 -0000
Received: (ofmipd 127.0.0.1); 4 Jan 2006 15:32:19 -0000
Date: 4 Jan 2006 10:32:41 -0500
Message-ID: 
From: "John R Levine" 
To: "Sam Hartman" 
In-Reply-To: 
References: <20060104135133.18678.qmail@xuxa.iecc.com>
	
	
	
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> OK.  If this is just an assumption and not backed by evidence, I would
> suspect that outside of the web you see a lot less use of the big CAs.

Probably true.  And since DKIM has no provision for authorities at all, it
definitely doesn't use them.

So remind me, what is the problem with DKIM that we're all supposed to be
worried about?

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 10:41:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuAln-0003Ru-NI; Wed, 04 Jan 2006 10:41:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuAll-0003Rk-Dn
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 10:41:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17260
	for ; Wed, 4 Jan 2006 10:40:31 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuArF-000529-3v
	for ietf@ietf.org; Wed, 04 Jan 2006 10:47:27 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 88ABD2596F8;
	Wed,  4 Jan 2006 16:40:37 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 31786-05; Wed,  4 Jan 2006 16:40:34 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id D037E2596F4;
	Wed,  4 Jan 2006 16:40:33 +0100 (CET)
Date: Wed, 04 Jan 2006 16:45:18 +0100
From: Harald Tveit Alvestrand 
To: Sam Hartman , John Levine 
Message-ID: <9478170016DE96F81B51EA1C@svartdal.hjemme.alvestrand.no>
In-Reply-To: 
References: <20060104135133.18678.qmail@xuxa.iecc.com>
	
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On onsdag, januar 04, 2006 09:54:56 -0500 Sam Hartman 
 wrote:

>     John> And the TLS world is dominated by a single signer whose
>     John> signing policies are opaque.
>
> Really?  Are you sure the TLS world is not dominated by users clicking
> OK trust this cert for anything they see, combined with a lot of self
> signed certs and certs from a variety of CAs?  I do expect that most
> web sites tend to have Verisign certs, but I have no idea about other
> uses of TLS.

Here's an interesting thing you can do if you're an Opera user:

Go into the preferences/advanced/security section and mark all your root 
certs as "warn me before I use this cert".
Then Opera will tell you which root cert the website got its cert from 
every time you click on a HTTPS link.

If most of the Net uses Verisign, Verisign's got a bewildering array of 
names....



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 10:44:19 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuAoF-0004NU-DG; Wed, 04 Jan 2006 10:44:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuAoD-0004NM-52
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 10:44:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17672
	for ; Wed, 4 Jan 2006 10:43:02 -0500 (EST)
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuAte-0005AE-5l
	for ietf@ietf.org; Wed, 04 Jan 2006 10:49:58 -0500
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51223)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1EuAnr-0000DX-2H (Exim 4.54)
	(return-path ); Wed, 04 Jan 2006 15:43:55 +0000
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1EuAnr-0003f2-Lm (Exim 4.53)
	(return-path ); Wed, 04 Jan 2006 15:43:55 +0000
Date: Wed, 4 Jan 2006 15:43:55 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Sam Hartman 
In-Reply-To: 
Message-ID: 
References: <20060104135133.18678.qmail@xuxa.iecc.com>
	
	
	
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Wed, 4 Jan 2006, Sam Hartman wrote:
>
> OK.  If this is just an assumption and not backed by evidence, I would
> suspect that outside of the web you see a lot less use of the big CAs.

Web-style TLS is used for authenticating the server in other protocols
too, such as IMAP, submission-mode SMTP, XMPP, etc. etc. and in all these
cases it is extremely desirable not to have to set up a local CA because
the user interface for configuring client software is so bad.

Tony.
-- 
f.a.n.finch    http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 10:58:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuB1x-0008UH-Bp; Wed, 04 Jan 2006 10:58:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuB1u-0008SO-J0; Wed, 04 Jan 2006 10:58:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19701;
	Wed, 4 Jan 2006 10:57:12 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EuB7P-0005nc-A1; Wed, 04 Jan 2006 11:04:08 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id BDF89160059; Wed,  4 Jan 2006 10:58:23 -0500 (EST)
To: Clint Chaplin 
References: 
	
	
From: Sam Hartman 
Date: Wed, 04 Jan 2006 10:58:23 -0500
In-Reply-To: 
	(Clint Chaplin's message of "Mon, 2 Jan 2006 11:22:18 -0800")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: WG Review: EAP Method Update (emu)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Clint" == Clint Chaplin  writes:

    Clint> Has an email list been set up for this effort yet?
    Clint> On 12/22/05, Pekka Savola  wrote:


So, pre-wg this is being discussed on secmech@ietf.org.

However the WG will get its own mailing list if approved.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 11:03:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuB6U-0001fy-5I; Wed, 04 Jan 2006 11:03:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuB6P-0001bL-Kr
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 11:03:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20328
	for ; Wed, 4 Jan 2006 11:01:51 -0500 (EST)
Received: from mtagate2.uk.ibm.com ([195.212.29.135])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuBBt-0005zf-FN
	for ietf@ietf.org; Wed, 04 Jan 2006 11:08:47 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k04G2MWT029610
	for ; Wed, 4 Jan 2006 16:02:26 GMT
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com
	[9.149.37.213])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k04G1uJq106808 for ; Wed, 4 Jan 2006 16:01:56 GMT
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k04G1uwj013297 for ; Wed, 4 Jan 2006 16:01:56 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k04G1rjQ013213; Wed, 4 Jan 2006 16:01:54 GMT
Received: from zurich.ibm.com (sig-9-146-220-184.de.ibm.com [9.146.220.184])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA55660;
	Wed, 4 Jan 2006 17:01:52 +0100
Message-ID: <43BBF16B.4030708@zurich.ibm.com>
Date: Wed, 04 Jan 2006 17:01:47 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Jeffrey Hutzelman 
References: <00da01c6102a$69584060$7f1afea9@oemcomputer>
	<3607A154E1FD78B2A318CF71@bistromath.pc.cs.cmu.edu>
In-Reply-To: <3607A154E1FD78B2A318CF71@bistromath.pc.cs.cmu.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jeffrey Hutzelman wrote:
> 
> 
> On Monday, January 02, 2006 09:56:15 PM -0800 Randy Presuhn 
>  wrote:
> 
>> Hi -
>>
>> In http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt
>> section 3 says:
>>
>> |   Furthermore, the authors propose that the IESG carefully consider
>> |   declaring consensus in support of the change even if a large number
>> |   of 'nays' are posted to the IESG discussion list.
>>
>> I object to this text, as it might (mis)lead the reader into thinking
>> that the methods for declaring consensus were being modified, 
>> particularly
>> if this document somehow became a BCP.  To deal with this issue, I 
>> suggest
>> the removal of the following material from section 3:
> 
> 
> Agree.  If the authors actually wish to propose a change to the way 
> consensus is determined in the IETF, then they should do so in a 
> separate document.  Naturally, like any process change in any 
> organization, such a change would have to be made under the _existing_ 
> process before it could take effect.

Speaking for myself, I agree. The whole point of rough consensus is to
leave scope for some nay-sayers, but it's for the WG Chairs (if relevant)
and the IESG to judge whether the number of objections is significant.
That's not going to change any time soon, and certainly not as a side effect.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 11:06:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuBA2-0002uB-98; Wed, 04 Jan 2006 11:06:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuB9z-0002u5-VJ
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 11:06:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20901
	for ; Wed, 4 Jan 2006 11:05:33 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuBFU-0006C6-6s
	for ietf@ietf.org; Wed, 04 Jan 2006 11:12:29 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id D3C01160059; Wed,  4 Jan 2006 11:06:45 -0500 (EST)
To: John C Klensin 
References: <20060102142559.HRZC29001.fep02-app.kolumbus.fi@smtp.k olumbus.fi
	> 
	<43B94FAD.80509@zurich.ibm.com> 
From: Sam Hartman 
Date: Wed, 04 Jan 2006 11:06:45 -0500
In-Reply-To:  (John C. Klensin's
	message of "Mon, 02 Jan 2006 15:20:02 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: ietf@ietf.org
Subject: Re: Question about the Neustar logo on www.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John, perhaps the logos on the IETF website are an issue on which we
can agree to let the IAOC decide reasonable policy and apply it.  It
seems like a long discussion here does not advance our goals.
-
--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 11:10:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuBE2-0003hL-Vr; Wed, 04 Jan 2006 11:10:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBDy-0003gG-Rv
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 11:10:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21532
	for ; Wed, 4 Jan 2006 11:09:39 -0500 (EST)
Received: from xenotime.net ([66.160.160.81])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuBJS-0006Mj-Vh
	for ietf@ietf.org; Wed, 04 Jan 2006 11:16:36 -0500
Received: from shark.he.net ([66.160.160.2]) by xenotime.net for
	; Wed, 4 Jan 2006 08:10:48 -0800
Date: Wed, 4 Jan 2006 08:10:47 -0800 (PST)
From: "Randy.Dunlap" 
X-X-Sender: rddunlap@shark.he.net
To: Julian Reschke 
In-Reply-To: <43BB8D46.7080203@gmx.de>
Message-ID: 
References: <27A0F290348F8E45AEF79889DDE65A5205DCE1C5@exrad2.ad.rad.co.il>
	<43BB8D46.7080203@gmx.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Wed, 4 Jan 2006, Julian Reschke wrote:

> Yaakov Stein wrote:
> >
> >
> >> Clarifying that "publicly known" means "well defined and publicly
> > available", I would answer no...
> >
> > and if it is restricted to mean
> >   "open description so that you could write your own editor to read and
> > write this format" ?
>
> ...without having to sign a contract to the owner of the format, being
> able to rely on its stability, and not having to pay for it...?

IOW, no IPR issues, no lawsuits for implementing/using it
or letting others use what someone has written (documentation
or source code) (?)

-- 
~Randy

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 11:14:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuBHN-0004Um-Vr; Wed, 04 Jan 2006 11:14:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBHL-0004Ty-QM
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 11:14:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22127
	for ; Wed, 4 Jan 2006 11:13:09 -0500 (EST)
Received: from raman.networkresonance.com ([198.144.196.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuBMq-0006W3-OF
	for ietf@ietf.org; Wed, 04 Jan 2006 11:20:06 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001)
	id 414891E8C4C; Wed,  4 Jan 2006 08:14:05 -0800 (PST)
To: "John R Levine" 
References: <20060104135133.18678.qmail@xuxa.iecc.com>
	
	
	
	
From: Eric Rescorla 
Date: Wed, 04 Jan 2006 08:14:05 -0800
In-Reply-To:  (John R. Levine's
	message of "4 Jan 2006 10:32:41 -0500")
Message-ID: <86oe2s6kdu.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: Sam Hartman , ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

"John R Levine"  writes:

>> OK.  If this is just an assumption and not backed by evidence, I would
>> suspect that outside of the web you see a lot less use of the big CAs.

This is my impression as well. And a fair amount of the reason here
is UI: the browsers are set up to check the server's cert and
the MTAs generally are not.


> Probably true.  And since DKIM has no provision for authorities at all, it
> definitely doesn't use them.

Well, yes and no. DKIM depends for its security on the DNS,
which means that it depends on the security of the DNS.
In order for this to be strong (i.e., cryptographic) security,
the relevant DNS records need to be signed and that means 
that there's a dependency on the DNSSEC roots.


> So remind me, what is the problem with DKIM that we're all supposed to be
> worried about?

AS I understand it the concern is that people who don't use DKIM
will eventually not be able to send e-mail to people who are using
it. I'm not sure that this is something that people should be concerned
about, indeed, the logic of this kind of system is that if it succeeds
that's exactly what will happen. 

That said, I don't think that the comparison with STARTTLS is particularly
illuminating. While in principle one could use STARTTLS as a measure
to discriminate between classes of senders, in practice it's not used
that way but instead used primarily for confidentiality. However,
DKIM's only real use is to discriminate between classes of senders,
so we do need to expect it to be used that way.

-Ekr

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 11:16:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuBIz-0004lU-E3; Wed, 04 Jan 2006 11:16:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBIx-0004lH-03
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 11:16:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22245
	for ; Wed, 4 Jan 2006 11:14:48 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuBOQ-0006YT-UF
	for ietf@ietf.org; Wed, 04 Jan 2006 11:21:44 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 04 Jan 2006 17:15:51 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k04GFmFZ024093; 
	Wed, 4 Jan 2006 17:15:49 +0100 (MET)
Received: from [64.103.64.233] (dhcp-rea-gp250-64-103-64-233.cisco.com
	[64.103.64.233])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA24870;
	Wed, 4 Jan 2006 16:15:47 GMT
Message-ID: <43BBF4B3.4080801@cisco.com>
Date: Wed, 04 Jan 2006 16:15:47 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian E Carpenter 
References: <00da01c6102a$69584060$7f1afea9@oemcomputer>	<3607A154E1FD78B2A318CF71@bistromath.pc.cs.cmu.edu>
	<43BBF16B.4030708@zurich.ibm.com>
In-Reply-To: <43BBF16B.4030708@zurich.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian E Carpenter wrote:

> Speaking for myself, I agree. The whole point of rough consensus is to
> leave scope for some nay-sayers, but it's for the WG Chairs (if relevant)
> and the IESG to judge whether the number of objections is significant.

That is what were asking for in this case.

Stewart

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 12:05:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuC4z-00017t-NW; Wed, 04 Jan 2006 12:05:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuC4x-00017o-Jn
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 12:05:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29098
	for ; Wed, 4 Jan 2006 12:04:24 -0500 (EST)
Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuCAS-00007f-TU
	for ietf@ietf.org; Wed, 04 Jan 2006 12:11:22 -0500
Received: from root (helo=think.thunk.org)
	by thunker.thunk.org with local-esmtps 
	(tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32)  (Exim 4.50 #1 (Debian))
	id 1EuC4q-0007Ew-RY; Wed, 04 Jan 2006 12:05:33 -0500
Received: from tytso by think.thunk.org with local (Exim 4.60)
	(envelope-from )
	id 1EuC2r-0001KH-FM; Wed, 04 Jan 2006 12:03:29 -0500
Date: Wed, 4 Jan 2006 12:03:29 -0500
From: "Theodore Ts'o" 
To: John C Klensin 
Message-ID: <20060104170329.GA4629@thunk.org>
References: <27A0F290348F8E45AEF79889DDE65A5201861027@exrad2.ad.rad.co.il>
	
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.11
X-SA-Exim-Connect-IP: 
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Tue, Jan 03, 2006 at 02:59:34PM -0500, John C Klensin wrote:
> 	(2) Development of a converter between the MS-XML output
> 	of Word Pro 2003 and the XML input of RFC 2629bis so
> 	that xml2rfc and its friends could take responsibility
> 	for final formatting.  Note that, if the converter were
> 	two-way, you could edit happily in Word and others could
> 	edit happily in XML and both could interwork.  However,
> 	as with the above, I think this solution would rapidly
> 	deteriorate into uselessness unless there were a
> 	commitment to produce new versions as new versions of
> 	Office appeared -- at least until Microsoft stabilizes
> 	and documents their XML formats.

And even when Microsoft stablizes their XML formats, each person who
wants to use the converter will have to apply individually to
Microsoft for a patent license, for which Microsoft has apparently
reserved the right to deny in the future for any reason.  Sweet....

						- Ted

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 12:19:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuCIo-0006Vu-Qj; Wed, 04 Jan 2006 12:19:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCIm-0006Vk-6U
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 12:19:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01155
	for ; Wed, 4 Jan 2006 12:18:41 -0500 (EST)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuCOD-0000mU-0u
	for ietf@ietf.org; Wed, 04 Jan 2006 12:25:38 -0500
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C9481378; 
	Wed,  4 Jan 2006 18:19:36 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Jan 2006 18:19:36 +0100
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Jan 2006 18:19:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 4 Jan 2006 18:19:34 +0100
Message-ID: <026F8EEDAD2C4342A993203088C1FC0502104AFE@esealmw109.eemea.ericsson.se>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYP6+f/vRIz6COCQcGugavuwsSzegBZTCNQ
From: "Lars-Erik Jonsson \(LU/EAB\)" 
To: "John Levine" , 
X-OriginalArrivalTime: 04 Jan 2006 17:19:36.0346 (UTC)
	FILETIME=[09598FA0:01C61153]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: quoted-printable
Cc: william@elan.net
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Word is of course out of the question since it is proprietary,
> undocumented, and unstable.  I hope we have consensus on that.

I hope so too!

I initially thought the proposal to use M$ Word as an official
format was a joke. The IETF has a tradition of not caring how
our documents are prepared, that is up to the editor, while we
have a simple common format for our working and published
documents. I personally use Word for preparing my drafts, as
Word works well for me when kept in a single environment (and
"at one point" in time). However, based on experience from
trying to get standards documents from other SDOs, I consider
Word completely broken for publishing purposes. It produces
complex files, the format is unstable and not even compatible
with itself, etc.=20

Personally, I do not agree ASCII is insufficient. But if others
do I would support taking small steps towards a new format, if
that format is as openly specified, stable, non-proprietary,
and can be expected to be generally readable over time and in
*all* environments.

/L-E

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 12:37:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuCZj-0002md-Kw; Wed, 04 Jan 2006 12:37:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCZg-0002ht-Ue
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 12:37:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04421
	for ; Wed, 4 Jan 2006 12:36:10 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuCfD-0001gU-DT
	for ietf@ietf.org; Wed, 04 Jan 2006 12:43:07 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k04HbCdJ014012; Wed, 4 Jan 2006 12:37:13 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11006; 
	Wed, 4 Jan 2006 12:37:12 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Wed, 4 Jan 2006 12:37:09 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886253@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Brian E Carpenter'" , Jeffrey Hutzelman
	
Date: Wed, 4 Jan 2006 12:36:57 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: ietf@ietf.org
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian,

	Yours is sort of a general reply to a question which has 
very specific relevance in this case.

	Yes, the current process allows for getting around a few
nay-sayers.

	However, the text objected to in this case argues that 
this process should be extended by a process of counting the 
people who don't publicly participate in the discussion, either 
way, as having tacitly given their approval to whatever side of 
the argument the authors, the WG chairs or the IESG choose.

	If we suppose that this might be the ongoing model for
determining consensus, it will never be necessary for anyone
other than the authors, WG chairs and IESG to agree on some
choice to declare consensus - even if the proposal is the most
ghastly nonsense to ever see the light of day - since it will 
always be the case that the majority of people lurking on the 
mailing list will not actively participate in list discussion.

	The text argues for this extreme interpretation of the 
current process - where the proponents of an idea consist almost
entirely of its authors, and they need only get the IESG behind
it to make it happen.  I've seen this done once before, where a
WG chair and AD jointly declared consensus against a continuous
stream of objections.  It wasn't pretty then, and it wouldn't be
pretty now.

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Brian E Carpenter
--> Sent: Wednesday, January 04, 2006 11:02 AM
--> To: Jeffrey Hutzelman
--> Cc: ietf@ietf.org
--> Subject: Re: objection to proposed change to "consensus"
--> 
--> Jeffrey Hutzelman wrote:
--> > 
--> > 
--> > On Monday, January 02, 2006 09:56:15 PM -0800 Randy Presuhn 
--> >  wrote:
--> > 
--> >> Hi -
--> >>
--> >> In 
--> http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt
--> >> section 3 says:
--> >>
--> >> |   Furthermore, the authors propose that the IESG 
--> carefully consider
--> >> |   declaring consensus in support of the change even if 
--> a large number
--> >> |   of 'nays' are posted to the IESG discussion list.
--> >>
--> >> I object to this text, as it might (mis)lead the reader 
--> into thinking
--> >> that the methods for declaring consensus were being modified, 
--> >> particularly
--> >> if this document somehow became a BCP.  To deal with 
--> this issue, I 
--> >> suggest
--> >> the removal of the following material from section 3:
--> > 
--> > 
--> > Agree.  If the authors actually wish to propose a change 
--> to the way 
--> > consensus is determined in the IETF, then they should do so in a 
--> > separate document.  Naturally, like any process change in any 
--> > organization, such a change would have to be made under 
--> the _existing_ 
--> > process before it could take effect.
--> 
--> Speaking for myself, I agree. The whole point of rough 
--> consensus is to
--> leave scope for some nay-sayers, but it's for the WG Chairs 
--> (if relevant)
--> and the IESG to judge whether the number of objections is 
--> significant.
--> That's not going to change any time soon, and certainly not 
--> as a side effect.
--> 
-->      Brian
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 12:43:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuCf9-0005zd-MK; Wed, 04 Jan 2006 12:43:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCf7-0005zH-Ou
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 12:43:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05010
	for ; Wed, 4 Jan 2006 12:41:46 -0500 (EST)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuCkd-0001u2-BX
	for ietf@ietf.org; Wed, 04 Jan 2006 12:48:44 -0500
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3CCE54DB; 
	Wed,  4 Jan 2006 18:42:59 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Jan 2006 18:42:59 +0100
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Jan 2006 18:42:58 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 4 Jan 2006 18:42:57 +0100
Message-ID: <026F8EEDAD2C4342A993203088C1FC0502104B05@esealmw109.eemea.ericsson.se>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYQoImP55jwzBVkTq2PiABBfsRCDwAtARdg
From: "Lars-Erik Jonsson \(LU/EAB\)" 
To: "John C Klensin" , "Yaakov Stein" 
X-OriginalArrivalTime: 04 Jan 2006 17:42:58.0719 (UTC)
	FILETIME=[4D3AB2F0:01C61156]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> I do believe that, if you want to do initial document
> preparation in Word, you should be able to do that.  As others
> have suggested, no one I know of is really interested in
> standardizing on or requiring a particular editor.  But, to do
> so, you need to be able to produce an editable format that is no
> worse than ASCII.  You may have better ideas, but, as I have
> explored that range of options, I've come to the conclusion that
> there ought to be two ways to accomplish that end.  They are:
>=20
> 	(1) Development of an "IETF printer driver" that can be
> 	distributed as freeware or with minimal costs and
> 	restrictions and that would produce lines and pages of
> 	the right layouts _and_ would handle "smart character"
> 	to ASCII conversions, generation of appropriate
> 	line-ending sequences, etc.  Whomever developed this
> 	thing would need to make a long-term commitment to
> 	producing and maintaining versions for every version of
> 	Windows from, I think, Win98 through the indefinite
> 	future.  The generic printer and the conventions of RFC
> 	3285 are demonstrably not good enough.

A completely correct observation:
Since the draft-stage of RFC 3285, I have been using MS-Word
as editing tool, and appreciated the WYSIWYG and tracking
advantages of it. However, since the output of the M$ generic
printer driver has changed for *EACH* version of Windows,
I have had to update the parser each time I wanted to support
a new Windows variant, I now have one parser for NT4, one for
98, one for 2000, one for XP, and I even had to improve the
XP version to work properly with Office 2003 under 2000.=20

This could be done, and it only affected me who decided to
still use Word as my editing tool. I still believe Word may
be a proper choice for draft editors, but they should be
aware of the problems, and Word is for sure not a proper
format for publishing documents.

/L-E

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 12:46:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuCiC-0007CH-Fb; Wed, 04 Jan 2006 12:46:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCi9-0007Bn-9p
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 12:46:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05364
	for ; Wed, 4 Jan 2006 12:44:54 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuCnf-00020l-On
	for ietf@ietf.org; Wed, 04 Jan 2006 12:51:52 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k04HjudJ014171; Wed, 4 Jan 2006 12:45:56 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA12026; 
	Wed, 4 Jan 2006 12:45:56 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Wed, 4 Jan 2006 12:45:55 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886254@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Theodore Ts'o'" , John C Klensin 
Date: Wed, 4 Jan 2006 12:45:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ted,

	If that happens, don't you think that we would be
obliged to object to their claims?

	IMO, such claims would be easily defeated on the 
same basis as most "look & feel" claims have been beaten
in the past.  In fact, I am not aware of issues with any
sort of rights assertion relative to existing converters
for MS (or Adobe) document formats.

--
Eric 

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Theodore Ts'o
--> Sent: Wednesday, January 04, 2006 12:03 PM
--> To: John C Klensin
--> Cc: ietf@ietf.org
--> Subject: Re: Alternative formats for IDs
--> 
--> On Tue, Jan 03, 2006 at 02:59:34PM -0500, John C Klensin wrote:
--> > 	(2) Development of a converter between the MS-XML output
--> > 	of Word Pro 2003 and the XML input of RFC 2629bis so
--> > 	that xml2rfc and its friends could take responsibility
--> > 	for final formatting.  Note that, if the converter were
--> > 	two-way, you could edit happily in Word and others could
--> > 	edit happily in XML and both could interwork.  However,
--> > 	as with the above, I think this solution would rapidly
--> > 	deteriorate into uselessness unless there were a
--> > 	commitment to produce new versions as new versions of
--> > 	Office appeared -- at least until Microsoft stabilizes
--> > 	and documents their XML formats.
--> 
--> And even when Microsoft stablizes their XML formats, each person who
--> wants to use the converter will have to apply individually to
--> Microsoft for a patent license, for which Microsoft has apparently
--> reserved the right to deny in the future for any reason.  Sweet....
--> 
--> 						- Ted
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 12:50:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuCm2-0008TU-4j; Wed, 04 Jan 2006 12:50:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCm0-0008TN-A0
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 12:50:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05845
	for ; Wed, 4 Jan 2006 12:48:53 -0500 (EST)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuCrV-0002BV-RM
	for ietf@ietf.org; Wed, 04 Jan 2006 12:55:51 -0500
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 794FD501; 
	Wed,  4 Jan 2006 18:50:05 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Jan 2006 18:50:05 +0100
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Jan 2006 18:50:05 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 4 Jan 2006 18:50:02 +0100
Message-ID: <026F8EEDAD2C4342A993203088C1FC0502104B06@esealmw109.eemea.ericsson.se>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYP/z3Ihbb/dpdrSfCUUZIk5fxHNAAIuuZHAE0SHfA=
From: "Lars-Erik Jonsson \(LU/EAB\)" 
To: "Yaakov Stein" , "Douglas Otis" , 
	"John Levine" 
X-OriginalArrivalTime: 04 Jan 2006 17:50:05.0167 (UTC)
	FILETIME=[4B697FF0:01C61157]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: quoted-printable
Cc: william@elan.net, ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> I don't see why the editor you use needs to be open-standard.
> As far as I know the IETF is attempting to standardize IP-related
> communications protocols, not editors.

Anyone should be able to contribute to the IETF, not just those
who work for big companies who have been fooled into using the
expensive and unstable application environments from M$.


> More seriously, Word is the only commonly used editor
> with an integrated tracking mechanism. I assume that even
> the purists who insist on nroff occasionally write an ID
> with others. I personally prefer to use TeX as a typesetting
> format when writing on my own, but use word for IDs
> since I have to cooperate with co-authors.

Sure, and you are free to do so. Every IETF document editor can
choose his preferred editing tool, as long as it can generate
the basic official ASCII output. If you do not know how to do
that with Word, there is help to get.

BR
/L-E

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 12:57:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuCsq-0002GW-LU; Wed, 04 Jan 2006 12:57:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCso-0002GM-5x
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 12:57:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06905
	for ; Wed, 4 Jan 2006 12:55:55 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuCyJ-0002Qv-Sv
	for ietf@ietf.org; Wed, 04 Jan 2006 13:02:53 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k04HuxdJ014389; Wed, 4 Jan 2006 12:56:59 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13263; 
	Wed, 4 Jan 2006 12:56:58 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Wed, 4 Jan 2006 12:56:56 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886255@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Yaakov Stein'" , "Gray, Eric" 
Date: Wed, 4 Jan 2006 12:56:52 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Yaakov,

	Yes, that would be most of what I meant by "publicly 
available."   Since we're trying to be very precise, I also
include the notion of "readily available documentation" in
the broader concept to "publicly available" where "readily"
may be implied in your use of "open" - and essentially means
that I can get a copy without signing another mortgage.

--
Eric

--> -----Original Message-----
--> From: Yaakov Stein [mailto:yaakov_s@rad.com] 
--> Sent: Wednesday, January 04, 2006 1:15 AM
--> To: Gray, Eric
--> Cc: ietf@ietf.org
--> Subject: RE: Alternative formats for IDs
--> 
-->  
--> 
--> > Clarifying that "publicly known" means "well defined and publicly
--> available", I would answer no...
--> 
--> and if it is restricted to mean 
-->   "open description so that you could write your own editor 
--> to read and
--> write this format" ?
--> 
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 13:00:40 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuCwC-0003UW-EU; Wed, 04 Jan 2006 13:00:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuCwA-0003UN-92
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 13:00:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07238
	for ; Wed, 4 Jan 2006 12:59:23 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuD1c-0002Y7-Nh
	for ietf@ietf.org; Wed, 04 Jan 2006 13:06:21 -0500
Received: from [192.168.0.3] (cpe-24-24-146-166.socal.res.rr.com
	[24.24.146.166]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k04I0d9a007983
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2006 10:00:42 -0800
Message-ID: <43BC0D1E.5000907@dcrocker.net>
Date: Wed, 04 Jan 2006 09:59:58 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: EKR 
References: <20060104135133.18678.qmail@xuxa.iecc.com>				
	<86oe2s6kdu.fsf@raman.networkresonance.com>
In-Reply-To: <86oe2s6kdu.fsf@raman.networkresonance.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: bozoproofing DKIM concerns
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

E> AS I understand it the concern is that people who don't use DKIM
> will eventually not be able to send e-mail to people who are using
> it. I'm not sure that this is something that people should be concerned
> about, indeed, the logic of this kind of system is that if it succeeds
> that's exactly what will happen. 


Interesting.

I have not heard any DKIM proponent use that logic.

I have, however, heard critics fail to understand the difference between

    a) special handling of "good" identities, versus continuing to have 
suspicious handling of "unknown" identities, and

    b) acceptance of good addresses and rejection of unknown.

Proponents seek to use DKIM for a), not b).

Critics keep asserting that b) is the only avenue that is possible.

So, they are wrong that it is the intent and they have no empirical basis for 
asserting that it is certain or even likely to occur.

d/


-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 13:43:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuDbh-0005lW-KJ; Wed, 04 Jan 2006 13:43:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuDbf-0005lQ-08
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 13:43:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11722
	for ; Wed, 4 Jan 2006 13:42:15 -0500 (EST)
Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuDhB-0003sQ-9O
	for ietf@ietf.org; Wed, 04 Jan 2006 13:49:14 -0500
Received: from root (helo=think.thunk.org)
	by thunker.thunk.org with local-esmtps 
	(tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32)  (Exim 4.50 #1 (Debian))
	id 1EuDbW-0007mN-U4; Wed, 04 Jan 2006 13:43:23 -0500
Received: from tytso by think.thunk.org with local (Exim 4.60)
	(envelope-from )
	id 1EuDZV-0001Sc-Om; Wed, 04 Jan 2006 13:41:17 -0500
Date: Wed, 4 Jan 2006 13:41:17 -0500
From: "Theodore Ts'o" 
To: "Gray, Eric" 
Message-ID: <20060104184117.GC5271@thunk.org>
References: <313680C9A886D511A06000204840E1CF0C886254@whq-msgusr-02.pit.comms.marconi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886254@whq-msgusr-02.pit.comms.marconi.com>
User-Agent: Mutt/1.5.11
X-SA-Exim-Connect-IP: 
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: John C Klensin , ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Wed, Jan 04, 2006 at 12:45:40PM -0500, Gray, Eric wrote:
> Ted,
> 
> 	If that happens, don't you think that we would be
> obliged to object to their claims?
> 
> 	IMO, such claims would be easily defeated on the 
> same basis as most "look & feel" claims have been beaten
> in the past.  In fact, I am not aware of issues with any
> sort of rights assertion relative to existing converters
> for MS (or Adobe) document formats.

It is my understanding that Microsoft have been granted one or more
patents relating to their use of XML in their new, incompatible MS
Office document formats that will be used in their upcoming MS Office
release, such that writing programs which manipulate said propietary
XML schemas may require patent licenses.

Whether or not such patent claims are bogus or not, and whether or not
the US Patent Office has their heads in some very dark orifice is
somewhat out of scope of this mailing list, I think.  I just wanted to
warn people that there may be some patent issues relating to working
with the new MS Office XML formats.  And while the Microsoft has
offered some "free" patent licenses for their patents, said patent
rights are not sublicensable, so each end user who wants to use a
converter would have to go on bended knee to Microsoft and request
their own individual patent license.

This should be a very strong argument to not touch the new MS Word
document formats with a ten foot pole, IMHO.

						- Ted

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 13:43:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuDbm-0005mO-NA; Wed, 04 Jan 2006 13:43:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuDbk-0005mI-OS
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 13:43:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11725
	for ; Wed, 4 Jan 2006 13:42:21 -0500 (EST)
Received: from raman.networkresonance.com ([198.144.196.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuDhH-0003sP-Ph
	for ietf@ietf.org; Wed, 04 Jan 2006 13:49:20 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001)
	id 0CF711E8C4C; Wed,  4 Jan 2006 10:43:27 -0800 (PST)
To: dcrocker@bbiw.net
References: <20060104135133.18678.qmail@xuxa.iecc.com>
	
	
	
	
	<86oe2s6kdu.fsf@raman.networkresonance.com>
	<43BC0D1E.5000907@dcrocker.net>
From: Eric Rescorla 
Date: Wed, 04 Jan 2006 10:43:27 -0800
In-Reply-To: <43BC0D1E.5000907@dcrocker.net> (Dave Crocker's message of "Wed,
	04 Jan 2006 09:59:58 -0800")
Message-ID: <86ek3n7s1c.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: ietf@ietf.org
Subject: Re: bozoproofing DKIM concerns
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dave Crocker  writes:

> E> AS I understand it the concern is that people who don't use DKIM
>> will eventually not be able to send e-mail to people who are using
>> it. I'm not sure that this is something that people should be concerned
>> about, indeed, the logic of this kind of system is that if it succeeds
>> that's exactly what will happen.
>
>
> Interesting.
>
> I have not heard any DKIM proponent use that logic.

Maybe not, but I think that it's the likely endgame.


> I have, however, heard critics fail to understand the difference between
>
>     a) special handling of "good" identities, versus continuing to
>     have suspicious handling of "unknown" identities, and
>
>     b) acceptance of good addresses and rejection of unknown.
>
> Proponents seek to use DKIM for a), not b).
>
> Critics keep asserting that b) is the only avenue that is possible.
>
> So, they are wrong that it is the intent and they have no empirical
> basis for asserting that it is certain or even likely to occur.

No, I don't have any empirical evidence for asserting that it's
certain or likely to occur. But in truth nobody has much empirical
evidence for anything here, so we're reduced to theorizing.

Now that we've got that out of the way, it's worth working through the
reasoning of why I think (b) is the likely endgame.  

The basic value proposition of any sender authentication system as an
input to filtering is that lets you increase the sensitivity of the
filters, while still obtaining an acceptable overall false positive
rate. Imagine that without sender auth, your filters have a false
positive rate of P and a false negative rate of N. With sender auth,
some fraction of those false positives will be eliminated, letting you
dial up the sensitivity of the filter. If we assume that the sender
authentication is perfect, then we get the following:

                      Message 
                      Authenticated
                 
                      Yes           No    
False positive        0             P' (P' > P)  
False negatives       0             N' (N' < N)


But this makes it even more attractive for the good senders to
authenticate their messages (because otherwise they stand a higher
chance of being rejected) which means that the receivers can increase
the sensitivity of their filters, and so on.  So, at the end of the
day, if something like DKIM is successful, I would expect an
equilibrium where filters are set extremely high and nearly all good
senders authenticate their messages because otherwise they stand
an unacceptably high chance of having them rejected.

-Ekr



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 13:46:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuDeA-0006gn-OB; Wed, 04 Jan 2006 13:46:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuDe8-0006gf-LG
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 13:46:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12017
	for ; Wed, 4 Jan 2006 13:44:49 -0500 (EST)
Received: from a.mail.sonic.net ([64.142.16.245])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuDjd-0003zF-Fj
	for ietf@ietf.org; Wed, 04 Jan 2006 13:51:47 -0500
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG
	[168.61.10.151]) (authenticated bits=0)
	by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k04Ijmj6012063
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 4 Jan 2006 10:45:49 -0800
In-Reply-To: <43BC0D1E.5000907@dcrocker.net>
References: <20060104135133.18678.qmail@xuxa.iecc.com>				
	<86oe2s6kdu.fsf@raman.networkresonance.com>
	<43BC0D1E.5000907@dcrocker.net>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <97BAAE72-BBB9-463C-AF2A-E9997BA10B0C@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis 
Date: Wed, 4 Jan 2006 10:46:13 -0800
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: bozoproofing DKIM concerns
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 4, 2006, at 9:59 AM, Dave Crocker wrote:

> E> AS I understand it the concern is that people who don't use DKIM
>> will eventually not be able to send e-mail to people who are using  
>> it. I'm not sure that this is something that people should be  
>> concerned about, indeed, the logic of this kind of system is that  
>> if it succeeds that's exactly what will happen.
>
>
> Interesting.
>
> I have not heard any DKIM proponent use that logic.
>
> I have, however, heard critics fail to understand the difference  
> between
>
>    a) special handling of "good" identities, versus continuing to  
> have suspicious handling of "unknown" identities, and
>
>    b) acceptance of good addresses and rejection of unknown.


The current proposed charter includes both the DKIM signature element  
that indeed provides a stable identifier.  No additional problem  
should be created as a result of this more stable identifier of which  
I can foresee.

There is also a proposal to introduce an email-address authorization  
scheme that transposes the Sender-ID email-addresses with signatures  
and uses a far more disruptive From header rather than the less  
disruptive PRA.  Will there be a PRA proposal for the SSP header  
selection soon?

The concern with this authorization scheme is that many email-address  
domains will likely be coerced into publishing some form of  
authorization to mitigate the high overhead otherwise imposed by the  
scheme.  The next possible point of coercion would be to restrict  
authorization to a limited set of signatures which dramatically  
alters current practices and is inherently unfair.  In general, when  
this authorization is used to accrue reputation as was done with  
Sender-ID, this imposes an unfair and highly disruptive element into  
how email functions.


> Proponents seek to use DKIM for a), not b).

This mischaracterizes the concern raised significantly.


> Critics keep asserting that b) is the only avenue that is possible.


Reputation based upon some identifier is already ubiquitously used to  
block abusive email.  A stronger method of identification does not  
increase any concern related to 'b' except when applied to the SSP  
authorization instead of the signature.  Even the SSP draft holds the  
email-address domain that provided the authorization accountable by  
way of complaints.  The authorization scheme introduces a weaker and  
unfair method of identification.


> So, they are wrong that it is the intent and they have no empirical  
> basis for asserting that it is certain or even likely to occur.

There has already been a scheme implemented a major vender that uses  
authorization as suggested.  A minor tweak to widely deploy system  
and instant problem.

-Doug


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 14:38:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuESs-0004NL-SJ; Wed, 04 Jan 2006 14:38:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuESr-0004NC-65
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 14:38:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15329
	for ; Wed, 4 Jan 2006 14:37:13 -0500 (EST)
Received: from raman.networkresonance.com ([198.144.196.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuEYO-0005Sr-LX
	for ietf@ietf.org; Wed, 04 Jan 2006 14:44:13 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001)
	id B3DE11E8C4C; Wed,  4 Jan 2006 11:38:19 -0800 (PST)
To: Dave Crocker 
References: <20060104135133.18678.qmail@xuxa.iecc.com>
	
	
	
	
	<86oe2s6kdu.fsf@raman.networkresonance.com>
	<43BC0D1E.5000907@dcrocker.net>
	<86ek3n7s1c.fsf@raman.networkresonance.com>
	<43BC1AD8.3030208@bbiw.net>
From: Eric Rescorla 
Date: Wed, 04 Jan 2006 11:38:19 -0800
In-Reply-To: <43BC1AD8.3030208@bbiw.net> (Dave Crocker's message of "Wed,
	04 Jan 2006 10:58:32 -0800")
Message-ID: <8664oz7phw.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: ietf@ietf.org
Subject: Re: Likely DKIM endgame
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dave Crocker  writes:
>> The basic value proposition of any sender authentication system as an
>> input to filtering is that lets you increase the sensitivity of the
>> filters, while still obtaining an acceptable overall false positive
>> rate.
>
> Nicely said.  (And, by the way, I agree with the statement.)
>
>
>   Imagine that without sender auth, your filters have a false
>> positive rate of P and a false negative rate of N. With sender auth,
>> some fraction of those false positives will be eliminated, letting you
>> dial up the sensitivity of the filter. If we assume that the sender
>> authentication is perfect, then we get the following:
>>                       Message                       Authenticated
>>                                        Yes           No    False
>> positive        0             P' (P' > P)  False negatives       0
>> N' (N' < N)
>> But this makes it even more attractive for the good senders to
>> authenticate their messages (because otherwise they stand a higher
>> chance of being rejected) which means that the receivers can increase
>> the sensitivity of their filters, and so on.
>  > So, at the end of the
>> day, if something like DKIM is successful, I would expect an
>> equilibrium where filters are set extremely high and nearly all good
>> senders authenticate their messages because otherwise they stand
>> an unacceptably high chance of having them rejected.
>
> I am less certain of "expect" than I am of "hope for".
>
> In any event, that is quite different from *requiring* everyone to
> sign, or automatically rejecting all unsigned mail.  Yet these are
> what you were putting forward.

I don't know what you mean by "putting forward". Here's what I wrote:

   AS I understand it the concern is that people who don't use DKIM
   will eventually not be able to send e-mail to people who are using
   it. I'm not sure that this is something that people should be
   concerned about, indeed, the logic of this kind of system is that
   if it succeeds that's exactly what will happen.

I guess it depends on how significant you think the difference between
"automatically rejecting all unsigned e-mail" and "unacceptably high
chance of having them rejected" is. My view is that it's more a
difference of degree than kind, but I apologize for speaking
imprecisely.


> Further as was pointed out at the BOF, the scenario you have describe
> is a voluntary community collaboration.  So if the outcome you
> describe occurs, it will be because the community agrees that they
> like that outcome.
>
> This makes it really perplexing to view it as a problem.

And I didn't say it was a problem. Indeed, I said "I'm not sure that
this is something that people should be concerned about..."


-Ekr


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 14:45:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuEZu-0005t8-2l; Wed, 04 Jan 2006 14:45:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuEZe-0005qV-PW
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 14:45:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16365
	for ; Wed, 4 Jan 2006 14:44:14 -0500 (EST)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuEfB-0005ru-1F
	for ietf@ietf.org; Wed, 04 Jan 2006 14:51:14 -0500
Received: from sb7.songbird.com ([208.184.79.137])
	by mx2.foretec.com with esmtp (Exim 4.24) id 1EuDr1-0001V5-UI
	for ietf@ietf.org; Wed, 04 Jan 2006 13:59:24 -0500
Received: from [192.168.0.3] (cpe-24-24-146-166.socal.res.rr.com
	[24.24.146.166]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k04IxAF5015455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2006 10:59:10 -0800
Message-ID: <43BC1AD8.3030208@bbiw.net>
Date: Wed, 04 Jan 2006 10:58:32 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: EKR 
References: <20060104135133.18678.qmail@xuxa.iecc.com>					<86oe2s6kdu.fsf@raman.networkresonance.com>	<43BC0D1E.5000907@dcrocker.net>
	<86ek3n7s1c.fsf@raman.networkresonance.com>
In-Reply-To: <86ek3n7s1c.fsf@raman.networkresonance.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dcrocker@bbiw.net
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Likely DKIM endgame
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Eric,


> No, I don't have any empirical evidence for asserting that it's
> certain or likely to occur. But in truth nobody has much empirical
> evidence for anything here, so we're reduced to theorizing.

Serious theorizing works carefully from an empirical base, with a clear logic 
sequence.  This never guarantees that they are correct, but does serve to vet 
their legitimacy.

Theorizing absent this kind of effort is not theorizing.  It is fantasizing.

There are an infinite number of possible fantasies and their injection into a 
project management effort, such as the start of a standards process, mostly -- I 
even suspect exclusively -- serves as distraction, particularly when they are 
repeated forcefully.


> Now that we've got that out of the way, it's worth working through the
> reasoning of why I think (b) is the likely endgame.  

It certainly is.


> The basic value proposition of any sender authentication system as an
> input to filtering is that lets you increase the sensitivity of the
> filters, while still obtaining an acceptable overall false positive
> rate.

Nicely said.  (And, by the way, I agree with the statement.)


  Imagine that without sender auth, your filters have a false
> positive rate of P and a false negative rate of N. With sender auth,
> some fraction of those false positives will be eliminated, letting you
> dial up the sensitivity of the filter. If we assume that the sender
> authentication is perfect, then we get the following:
> 
>                       Message 
>                       Authenticated
>                  
>                       Yes           No    
> False positive        0             P' (P' > P)  
> False negatives       0             N' (N' < N)
> 
> 
> But this makes it even more attractive for the good senders to
> authenticate their messages (because otherwise they stand a higher
> chance of being rejected) which means that the receivers can increase
> the sensitivity of their filters, and so on. 
 > So, at the end of the
> day, if something like DKIM is successful, I would expect an
> equilibrium where filters are set extremely high and nearly all good
> senders authenticate their messages because otherwise they stand
> an unacceptably high chance of having them rejected.

I am less certain of "expect" than I am of "hope for".

In any event, that is quite different from *requiring* everyone to sign, or 
automatically rejecting all unsigned mail.  Yet these are what you were putting 
forward.

Further as was pointed out at the BOF, the scenario you have describe is a 
voluntary community collaboration.  So if the outcome you describe occurs, it 
will be because the community agrees that they like that outcome.

This makes it really perplexing to view it as a problem.


d/
-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 14:49:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuEdc-0006eL-TP; Wed, 04 Jan 2006 14:49:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuEda-0006da-RE
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 14:49:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17180
	for ; Wed, 4 Jan 2006 14:48:19 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EuEj6-00066X-DC
	for ietf@ietf.org; Wed, 04 Jan 2006 14:55:18 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-1.cisco.com with ESMTP; 04 Jan 2006 11:49:23 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k04JnMk7007303;
	Wed, 4 Jan 2006 11:49:22 -0800 (PST)
Received: from [171.71.193.105] (dhcp-171-71-193-105.cisco.com
	[171.71.193.105])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k04Jt1pt011163;
	Wed, 4 Jan 2006 11:55:03 -0800
Message-ID: <43BC26C6.5060906@cisco.com>
Date: Wed, 04 Jan 2006 11:49:26 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
	rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: <20060101043514.6985.qmail@xuxa.iecc.com>	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>		<416F6B6F46586EDBC9410701@p3.JCK.COM>		<6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no>	<43B8E169.4000202@dcrocker.net>	<33D8EA76B9350E63F056C2D8@svartdal.hjemme.alvestrand.no>	<43B90C3D.50405@bbiw.net>
	<6290ABA8A965FE150484933F@svartdal.hjemme.alvestrand.no>
In-Reply-To: <6290ABA8A965FE150484933F@svartdal.hjemme.alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1;  q=dns; l=180; t=1136404505; x=1136836705;
	c=nowsp; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; 
	d=cisco.com; i=mat@cisco.com; 
	z=Subject:Re=3A=20bozoproofing=20the=20net,
	=20was=20The=20Value=20of=20Reputation|
	From:Michael=20Thomas=20|
	Date:Wed,=2004=20Jan=202006=2011=3A49=3A26=20-0800|
	Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed|
	Content-Transfer-Encoding:7bit;
	b=kYMvh34SZh/MGBhyOmcKVMX3lOWug4D+39hh7+52L59+zen+C0ItvymzFT2NIXXZJbM47X3S
	r/KCl34IXnbKXDR+ZJVO4++Y5ww4nBOfY2wq+Mc6pI/XDidIhCa+KY4oFqo93Ys+mAKaaZU2irx
	dItjHs2zILR6k3sz4UViw1Tg=
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Cc: Dave Crocker , ietf@ietf.org
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Harald Tveit Alvestrand wrote:
[]

Sigh. Can I suggest that a little exponential backoff on
all parts may be appropriate? As one of the authors of the
dkim draft, this has been an extremely painful thread to
watch.

		Mike

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 15:16:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuF3u-0008Sp-Fa; Wed, 04 Jan 2006 15:16:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuF3s-0008Oq-3u
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 15:16:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20062
	for ; Wed, 4 Jan 2006 15:15:28 -0500 (EST)
Received: from front2.mail.megapathdsl.net ([66.80.60.30]
	helo=mail.megapathdsl.net) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EuF9M-00076D-SP
	for ietf@ietf.org; Wed, 04 Jan 2006 15:22:28 -0500
Received: from [64.32.194.73] (HELO l-w865gbf-ws)
	by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 5.0.4)
	with ESMTP id 344727589 for ietf@ietf.org;
	Wed, 04 Jan 2006 12:16:19 -0800
From: Scott Kitterman 
To: ietf@ietf.org
Date: Wed, 4 Jan 2006 15:16:18 -0500
User-Agent: KMail/1.7
References: <313680C9A886D511A06000204840E1CF0C886254@whq-msgusr-02.pit.comms.marconi.com>
	<20060104184117.GC5271@thunk.org>
In-Reply-To: <20060104184117.GC5271@thunk.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200601041516.18528.scott@kitterman.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I've been following this thread and I'm a bit surprised that no one has 
suggested Open Document Format:

http://www.oasis-open.org/committees/office/faq.php

Although it's still pretty new, it is fully documented, useable by editors 
available on multiple platforms, and appears to be free of any significant 
encumbrances.  

It's probably premature to condider this today, but I don't imagine that the 
alternative format discussion is going to resolve itself anytime soon.  

Scott Kitterman

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 15:32:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuFIu-0004Vp-2Q; Wed, 04 Jan 2006 15:32:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFIq-0004VR-Bp
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 15:32:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21728
	for ; Wed, 4 Jan 2006 15:30:56 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuFON-0007dS-DF
	for ietf@ietf.org; Wed, 04 Jan 2006 15:37:56 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 7863526C0A3; Wed,  4 Jan 2006 21:32:04 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 5BA9726C081; Wed,  4 Jan 2006 21:32:03 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k04KW3Ya942172;
	Wed, 4 Jan 2006 21:32:03 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id 24CE416AA99; Wed,  4 Jan 2006 21:32:03 +0100 (CET)
Date: Wed, 4 Jan 2006 21:32:03 +0100
From: Stephane Bortzmeyer 
To: "Lars-Erik Jonsson (LU/EAB)" 
Message-ID: <20060104203203.GA1459@nic.fr>
References: <026F8EEDAD2C4342A993203088C1FC0502104B06@esealmw109.eemea.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0502104B06@esealmw109.eemea.ericsson.se>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Wed, Jan 04, 2006 at 06:50:02PM +0100,
 Lars-Erik Jonsson (LU/EAB)  wrote 
 a message of 28 lines which said:

> If you do not know how to do that with Word, there is help to get.

Yes, in RFC 3285.

3285 Using Microsoft Word to create Internet Drafts and RFCs. M.
     Gahrns, T. Hain. May 2002. (Format: TXT=34556 bytes) (Status:
     INFORMATIONAL)

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 15:36:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuFMk-0006UT-1u; Wed, 04 Jan 2006 15:36:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFMh-0006UA-NT
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 15:36:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22151
	for ; Wed, 4 Jan 2006 15:34:55 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuFSF-0007nZ-V0
	for ietf@ietf.org; Wed, 04 Jan 2006 15:41:56 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 70CEC26C0C6; Wed,  4 Jan 2006 21:36:10 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 6DB0B26C081; Wed,  4 Jan 2006 21:36:09 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k04Ka9Ya737331;
	Wed, 4 Jan 2006 21:36:09 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id 3AE4516AA99; Wed,  4 Jan 2006 21:36:09 +0100 (CET)
Date: Wed, 4 Jan 2006 21:36:09 +0100
From: Stephane Bortzmeyer 
To: Scott Kitterman 
Message-ID: <20060104203609.GB1459@nic.fr>
References: <313680C9A886D511A06000204840E1CF0C886254@whq-msgusr-02.pit.comms.marconi.com>
	<20060104184117.GC5271@thunk.org>
	<200601041516.18528.scott@kitterman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200601041516.18528.scott@kitterman.com>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Wed, Jan 04, 2006 at 03:16:18PM -0500,
 Scott Kitterman  wrote 
 a message of 18 lines which said:

> I've been following this thread and I'm a bit surprised that no one
> has suggested Open Document Format:

If we use a XML format, why the very large and complexe (700 pages)
OpenDocument and not "our" RFC 2629?
 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 15:44:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuFUS-0007sd-IZ; Wed, 04 Jan 2006 15:44:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFUQ-0007sT-Kv
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 15:44:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23093
	for ; Wed, 4 Jan 2006 15:42:54 -0500 (EST)
Received: from rwcrmhc12.comcast.net ([216.148.227.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuFZx-00083V-Ee
	for ietf@ietf.org; Wed, 04 Jan 2006 15:49:54 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (rwcrmhc12) with SMTP
	id <2006010420435401400pk95de>; Wed, 4 Jan 2006 20:43:54 +0000
Message-ID: <0bcc01c6116f$6d795cb0$0500a8c0@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: <313680C9A886D511A06000204840E1CF0C886253@whq-msgusr-02.pit.comms.marconi.com>
Date: Wed, 4 Jan 2006 14:42:49 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Brian,
>
> Yours is sort of a general reply to a question which has
> very specific relevance in this case.
>
> Yes, the current process allows for getting around a few
> nay-sayers.
>
> However, the text objected to in this case argues that
> this process should be extended by a process of counting the
> people who don't publicly participate in the discussion, either
> way, as having tacitly given their approval to whatever side of
> the argument the authors, the WG chairs or the IESG choose.

... and this was what concerned me, too.

It's been a couple of years, but we had some discussions are part of the 
IETF Problem Statement about people who aren't comfortable commenting in 
public on technical issues for a variety of reasons (including, but not 
limited to, cultural reasons). The context at that time was people who DO 
comment - just not on public mailing lists.

The guidance we ended up with was that we don't know how to make 
"commenting, just not publically" part of the consensus determination.

In this context, the question is about the IETF toolset, not about protocol 
specifics, but since we insist on using the protocol 
specification/standardization BCPs for process discussions, I'm really 
concerned about asking the IESG to violate those BCPs in determining 
consensus on a process question. It's a slippery slope to "We know what 
consensus is on this protocol question, even if the people who agree don't 
post"...

Spencer

Spencer

Spencer 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 15:48:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuFYn-0001EI-9G; Wed, 04 Jan 2006 15:48:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFYl-0001BQ-4w
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 15:48:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23903
	for ; Wed, 4 Jan 2006 15:47:22 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuFeG-0008El-Bb
	for ietf@ietf.org; Wed, 04 Jan 2006 15:54:23 -0500
Received: (qmail 10065 invoked by uid 100); 4 Jan 2006 20:48:23 -0000
Date: 4 Jan 2006 20:48:23 -0000
Message-ID: <20060104204823.10064.qmail@xuxa.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <86ek3n7s1c.fsf@raman.networkresonance.com>
Organization: I.E.C.C., Trumansburg NY USA
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: bozoproofing DKIM concerns
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> if something like DKIM is successful, I would expect an equilibrium
> where filters are set extremely high and nearly all good senders
> authenticate their messages because otherwise they stand an
> unacceptably high chance of having them rejected.

That seems plausible at some point, maybe five years or more from now,
if DKIM catches on and something doesn't blindside us from left field
in the meantime.

Does anyone consider it to be a problem?

R's,
John



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 17:12:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuGra-0007qO-Mo; Wed, 04 Jan 2006 17:12:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuGrY-0007pH-Jo
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 17:12:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10613
	for ; Wed, 4 Jan 2006 17:10:53 -0500 (EST)
Received: from mail.gmx.net ([213.165.64.21])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuGx6-0005Dk-Av
	for ietf@ietf.org; Wed, 04 Jan 2006 17:17:53 -0500
Received: (qmail invoked by alias); 04 Jan 2006 22:11:52 -0000
Received: from p508F8EA8.dip0.t-ipconnect.de (EHLO [192.168.178.21])
	[80.143.142.168]
	by mail.gmx.net (mp028) with SMTP; 04 Jan 2006 23:11:52 +0100
X-Authenticated: #1915285
Message-ID: <43BC47B7.9070404@gmx.de>
Date: Wed, 04 Jan 2006 23:09:59 +0100
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Stephane Bortzmeyer 
References: <313680C9A886D511A06000204840E1CF0C886254@whq-msgusr-02.pit.comms.marconi.com>	<20060104184117.GC5271@thunk.org>	<200601041516.18528.scott@kitterman.com>
	<20060104203609.GB1459@nic.fr>
In-Reply-To: <20060104203609.GB1459@nic.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Cc: Scott Kitterman , ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stephane Bortzmeyer wrote:
> If we use a XML format, why the very large and complexe (700 pages)
> OpenDocument and not "our" RFC 2629?

Indeed. Although, at some point of time we'll have also to realize that 
there most people when they say "RFC2629" they really mean RFC2629bis. 
So, sooner or later, we'll have to start work on a proper spec revision.

Best regards, Julian

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 04 23:25:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuMhD-00064m-Pa; Wed, 04 Jan 2006 23:25:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuMh7-00063V-D1
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 23:25:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17431
	for ; Wed, 4 Jan 2006 23:24:29 -0500 (EST)
Received: from radmail1.rad.co.il ([62.0.23.193] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuMmf-0000fk-B6
	for ietf@ietf.org; Wed, 04 Jan 2006 23:31:32 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k054LVYL013339
	for ; Thu, 5 Jan 2006 06:21:31 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k054LULx013336;
	Thu, 5 Jan 2006 06:21:30 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 5 Jan 2006 06:25:15 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A520186102B@exrad2.ad.rad.co.il>
Thread-Topic: objection to proposed change to "consensus"
Thread-Index: AcYRVawjmWCHSYr7TYiQFWaOp0/x7QAWVHxA
From: "Yaakov Stein" 
To: "Gray, Eric" ,
	"Brian E Carpenter" 
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: ietf@ietf.org
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0669437816=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0669437816==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C611B0.071BA288"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C611B0.071BA288
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   However, the text objected to in this case argues that
this process should be extended by a process of counting the
people who don't publicly participate in the discussion, either
way, as having tacitly given their approval to whatever side of
the argument the authors, the WG chairs or the IESG choose.

Wow, did we say all that?
=20
All we are saying is that for the issue we are discussing
there is no WG. The only list that is open to its discussion=20
is the general list, where there is no support.
=20
However, quite a large number of people who actively participate
in IETF WGs (people who are interested in working on technical topics,=20
but not on the internal workings of the IETF) who want the process
changed.
=20
We proposed gauging interest by a show of hands at a plenary
meeting, rather than by the number of yes votes on this list.
Yes, even that is not optimal since there are people who prefer
working in the terminal room or touring in the evenings,
but it certainly seems to be a better way of finding out what
MOST IETF participants want than only reading this list.
=20
I fail to see how this is equivalent to allowing authors or chairs=20
to decide for themselves what should be done.
=20
Y(J)S
=20

------_=_NextPart_001_01C611B0.071BA288
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
RE: objection to proposed change to "consensus"=0A=
=0A=
=0A=

=0A=

>   However, the text =
objected to in this =0A=
case argues that
this process should be extended by a process of =
counting =0A=
the
people who don't publicly participate in the discussion, =
either
way, =0A=
as having tacitly given their approval to whatever side of
the =
argument the =0A=
authors, the WG chairs or the IESG choose.

Wow, did we say all =0A=
that?
=0A=

 
=0A=

All we are saying is that for the issue we =
are =0A=
discussing
=0A=

there is no WG. The only list that is open =
to its =0A=
discussion 
=0A=

is the general list, where there is no =0A=
support.
=0A=

 
=0A=

However, quite a large number of people =
who actively =0A=
participate
=0A=

in IETF WGs (people who are =
interested in working =0A=
on technical topics, 
=0A=

but not on the internal workings of the =
IETF) who want =0A=
the process
=0A=

changed.
=0A=

 
=0A=

We proposed gauging interest by a show of =
hands at a =0A=
plenary
=0A=

meeting, rather than by the number of yes =
votes on =0A=
this list.
=0A=

Yes, even that is not optimal since there =
are people =0A=
who prefer
=0A=

working in the terminal room or touring in =
the =0A=
evenings,
=0A=

but it certainly seems to be a better way =
of finding =0A=
out what
=0A=

MOST IETF participants want than only =
reading this =0A=
list.
=0A=

 
=0A=

I fail to see how this is equivalent to =
allowing =0A=
authors or chairs 
=0A=

to decide for =
themselves what =0A=
should be done.
=0A=

 
=0A=

Y(J)S
=0A=

 
=0A=
=0A=
=0A=

------_=_NextPart_001_01C611B0.071BA288--


--===============0669437816==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0669437816==--




From ietf-bounces@ietf.org Wed Jan 04 23:46:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuN18-0004Aw-GI; Wed, 04 Jan 2006 23:46:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuN15-0004AJ-Et
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 23:46:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19508
	for ; Wed, 4 Jan 2006 23:45:07 -0500 (EST)
Received: from radmail1.rad.co.il ([62.0.23.193] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuN6d-0001MW-DD
	for ietf@ietf.org; Wed, 04 Jan 2006 23:52:10 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k054gBYN014104
	for ; Thu, 5 Jan 2006 06:42:12 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k054g8Lx014101;
	Thu, 5 Jan 2006 06:42:08 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 5 Jan 2006 06:45:54 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A520186102C@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYRblBHnezZFSb5Qnq1dUtbgCk/NAAQxUTe
From: "Yaakov Stein" 
To: "Stephane Bortzmeyer" ,
	"Lars-Erik Jonsson \(LU/EAB\)" 
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1726156605=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1726156605==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C611B2.E92CFD48"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C611B2.E92CFD48
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> If you do not know how to do that with Word, there is help to get.

Yes, in RFC 3285.

3285 Using Microsoft Word to create Internet Drafts and RFCs. M.
     Gahrns, T. Hain. May 2002. (Format: TXT=3D34556 bytes) (Status:
     INFORMATIONAL)

[YJS] Yes of course we all have used that.
=20
However, unfortunately there are problems with that route
and no-one is supporting it (as XML2RFC is supported).=20
=20
For example, when printing directly from Word (rather
than first producing the ASCII and then printing)
the margins are all wrong.
=20
Also, certain combinations of characters I use in ASCII art
cause (for some unknown and undocumented reason)
strange unprintable characters to appear in the ASCII version.
=20
In the past I have reported problems to the authors of the RFC,
who responded but obviously did not have the time
to look into the specifics.
=20
I also tried the TeX tools. I am a TeX fanatic and have=20
written countless articles and two large books in TeX,
including my own styles and "low level" programming.
=20
The LaTeX style is not very good and also apparently
unsupported. The several dvi2txt tools I tried all had bugs.
I was going to hack up something myself, but then was scared
off by my own experiences, realizing that if I started I would
have to support the thing for the rest of my mortal life.
=20
So I returned to XML except for cooperative drafts.
And I suffer. But at  least when I contribute to  ITU, MFA,
MEF, ETSI, etc I don't have to shop around.
I simply use the editor already installed on my
computer.
=20
Y(J)S
=20

------_=_NextPart_001_01C611B2.E92CFD48
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Re: Alternative formats for IDs=0A=
=0A=
=0A=

=0A=

> If you do not know how to do that with Word, there =
is help to =0A=
get.

Yes, in RFC 3285.

3285 Using Microsoft Word to create =0A=
Internet Drafts and RFCs. M.
     Gahrns, T. =
Hain. May =0A=
2002. (Format: TXT=3D34556 bytes) (Status:
     =0A=
INFORMATIONAL)

[YJS] Yes of course we all have used that.
=0A=

 
=0A=

However, unfortunately there are problems with that =
route
=0A=

and no-one is supporting it (as XML2RFC is supported). =

=0A=

 
=0A=

For example, when printing directly from Word =
(rather
=0A=

than first producing the ASCII and then printing)
=0A=

the margins are all wrong.
=0A=

 
=0A=

Also, certain combinations of characters I use in ASCII =
art
=0A=

cause (for some unknown and undocumented reason)
=0A=

strange unprintable characters to appear in the ASCII =0A=
version.
=0A=

 
=0A=

In the past I have reported problems to the authors of =
the =0A=
RFC,
=0A=

who responded but obviously did not have the =
time
=0A=

to look into the specifics.
=0A=

 
=0A=

I also tried the TeX tools. I am a TeX fanatic and have =

=0A=

written countless articles and two large books in =
TeX,
=0A=

including my own styles and "low level" programming.
=0A=

 
=0A=

The LaTeX style is not very good and also apparently
=0A=

unsupported. The several dvi2txt tools I tried all had =
bugs.
=0A=

I was going to hack up something myself, but then was =
scared
=0A=

off by my own experiences, realizing that if I started I =0A=
would
=0A=

have to support the thing for the rest of my mortal =
life.
=0A=

 
=0A=

So I returned to XML except for cooperative drafts.
=0A=

And I suffer. But at  least when I =
contribute to =0A=
 ITU, MFA,
=0A=

MEF, ETSI, etc I don't have to shop around.
=0A=

I simply use the editor already installed on my
=0A=

computer.
=0A=

 
=0A=

Y(J)S
=0A=

 
=0A=
=0A=
=0A=

------_=_NextPart_001_01C611B2.E92CFD48--


--===============1726156605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1726156605==--




From ietf-bounces@ietf.org Wed Jan 04 23:57:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuNC8-0006Bl-MA; Wed, 04 Jan 2006 23:57:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuNC5-0006Ap-3g
	for ietf@megatron.ietf.org; Wed, 04 Jan 2006 23:57:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20688
	for ; Wed, 4 Jan 2006 23:56:29 -0500 (EST)
Received: from radmail1.rad.co.il ([62.0.23.193] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuNHd-0001wa-UP
	for ietf@ietf.org; Thu, 05 Jan 2006 00:03:33 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k054rcYL014694
	for ; Thu, 5 Jan 2006 06:53:38 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k054raLx014686;
	Thu, 5 Jan 2006 06:53:36 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 5 Jan 2006 06:57:22 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A520186102D@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYQoDr1oon44LwTT326fRsGeRf4vgBEsb65
From: "Yaakov Stein" 
To: "John C Klensin" 
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1068787871=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1068787871==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C611B4.8372DA95"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C611B4.8372DA95
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

John
=20
Thanks for the thorough summary
of the cons about using Word.
=20
I agree with much of what you say,
and am fully aware that Word is not the ideal tool.
=20
However, I haven't had the same harrowing experiences
that I have seen described here on the list.
=20
Just for the fun of it I went through a dozen
documents on a backup from 7 years ago.
All were perfectly readable, all but one came up
on the first try with the correct formatting
and figures (some asked if I wished to update the
outdated format, to which I answered yes).
=20
Only one caused any problems. It was a multilanguage
document (with two directions) and some of the text
jumped off the page in a wierd way. But that text wouldn't
have written in ASCII anyway.
=20
I have never had a problem opening an old file
with an up-to-date version of the SW. The problems
arise when you try to do the reverse. That makes sense
of course, since if you could do everything with the
old version, then no-one would buy the new one.
After all, a company with 95% market has to be inventive=20
in order to continue selling.
=20
Y(J)S
=20

------_=_NextPart_001_01C611B4.8372DA95
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
RE: Alternative formats for IDs=0A=
=0A=
=0A=

=0A=

John
=0A=

 
=0A=

Thanks for the =0A=
thorough summary
=0A=

of the cons about using =
Word.
=0A=

 
=0A=

I agree with much of what you =
say,
=0A=

and am fully aware that Word is not the =
ideal =0A=
tool.
=0A=

 
=0A=

However, I haven't had the same harrowing =0A=
experiences
=0A=

that I have seen described here on the =0A=
list.
=0A=

 
=0A=

Just for the fun of it I went through a =0A=
dozen
=0A=

documents on a backup from 7 years =
ago.
=0A=

All were perfectly readable, all but one =
came =0A=
up
=0A=

on the first try with the correct =0A=
formatting
=0A=

and figures (some asked if I wished to =
update =0A=
the
=0A=

outdated format, to which I answered =0A=
yes).
=0A=

 
=0A=

Only one caused any problems. It was a =0A=
multilanguage
=0A=

document (with two directions) and =
some of the =0A=
text
=0A=

jumped off the page in a wierd way. But =
that text =0A=
wouldn't
=0A=

have written in ASCII anyway.
=0A=

 
=0A=

I have never had a problem opening an old =0A=
file
=0A=

with an up-to-date version of the SW. The =0A=
problems
=0A=

arise when you try to do the reverse. That =
makes =0A=
sense
=0A=

of course, since if you could do =
everything with =0A=
the
=0A=

old version, then no-one would buy the new =0A=
one.
=0A=

After all, a company =
with 95% =0A=
market has to be inventive 
=0A=

in order to continue selling.
=0A=

 
=0A=

Y(J)S
=0A=

 
=0A=
=0A=
=0A=

------_=_NextPart_001_01C611B4.8372DA95--


--===============1068787871==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1068787871==--




From ietf-bounces@ietf.org Thu Jan 05 00:08:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuNMi-0004D5-0X; Thu, 05 Jan 2006 00:08:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuNMf-0004Cu-13
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 00:08:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21918
	for ; Thu, 5 Jan 2006 00:07:25 -0500 (EST)
Received: from radmail1.rad.co.il ([62.0.23.193] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuNSD-0002Mq-Re
	for ietf@ietf.org; Thu, 05 Jan 2006 00:14:28 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k0554WYN015263
	for ; Thu, 5 Jan 2006 07:04:33 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k0554ULx015259;
	Thu, 5 Jan 2006 07:04:30 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 5 Jan 2006 07:03:39 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A520186102E@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYQK29e77KMu+FDRRal0hmn/MGHAQBifTHP
From: "Yaakov Stein" 
To: "Jeffrey Hutzelman" , 
X-Spam-Score: 0.8 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: 
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1388302609=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1388302609==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C611B6.092D3CF4"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C611B6.092D3CF4
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Oh, one more thing.  The most widely-used archival form in use at =
libraries
I've visited has been written or printed words on paper.  This form has
much going for it -- it can represent any character set humans have ever
used, can contain any diagram, and does not require any special software =
to
to view or produce. =20
=20
[YJS] Actually, cuneiform on clay tablets and hieroglyphics on marble =
stelai
seem to be better than paper if you really want your message to last a
long time.
=20
=20

------_=_NextPart_001_01C611B6.092D3CF4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Re: Alternative formats for IDs=0A=
=0A=
=0A=

=0A=

Oh, one more thing.  The most =
widely-used =0A=
archival form in use at libraries
I've visited has been written or =
printed =0A=
words on paper.  This form has
much going for it -- it can =
represent any =0A=
character set humans have ever
used, can contain any diagram, and =
does not =0A=
require any special software to
to view or produce.  =

=0A=

 
=0A=

[YJS] Actually, cuneiform on clay tablets =
and =0A=
hieroglyphics on marble stelai
=0A=

seem to be better than paper if you really =
want your =0A=
message to last a
=0A=

long time.
=0A=

 
=0A=

 
=0A=
=0A=
=0A=

------_=_NextPart_001_01C611B6.092D3CF4--


--===============1388302609==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1388302609==--




From ietf-bounces@ietf.org Thu Jan 05 00:52:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuO3K-000146-SF; Thu, 05 Jan 2006 00:52:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuO3G-00013v-I8
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 00:52:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26442
	for ; Thu, 5 Jan 2006 00:51:27 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuO8t-0003r7-6B
	for ietf@ietf.org; Thu, 05 Jan 2006 00:58:31 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EuO3D-0002qf-5z
	for ietf@ietf.org; Thu, 05 Jan 2006 06:52:39 +0100
Received: from pd9fba8e8.dip0.t-ipconnect.de ([217.251.168.232])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Thu, 05 Jan 2006 06:52:39 +0100
Received: from nobody by pd9fba8e8.dip0.t-ipconnect.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for ; Thu, 05 Jan 2006 06:52:39 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Thu, 05 Jan 2006 06:51:09 +0100
Organization: 
Lines: 16
Message-ID: <43BCB3CD.13D0@xyzzy.claranet.de>
References: <27A0F290348F8E45AEF79889DDE65A520186102E@exrad2.ad.rad.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fba8e8.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Yaakov Stein wrote:

> Actually, cuneiform on clay tablets and hieroglyphics on
> marble stelai seem to be better than paper if you really
> want your message to last a long time.

Libraries have books that are several hundred years old,
and they have problems with some only sixty years old books
depending on the quality of the paper.  What medium available
since say 1946 do you have in mind for archives ?  PDF/A is
at most one part of _this_ puzzle.  

Maybe we should use RFC 2070, after all it's "ours", and AFAIK
 would be a
nice challenge for validator.w3.org (testing... STRRRIKE... ;-)



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 03:26:20 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuQRv-0008UD-On; Thu, 05 Jan 2006 03:26:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQRs-0008Ts-LF
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 03:26:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10462
	for ; Thu, 5 Jan 2006 03:25:00 -0500 (EST)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuQXW-0000Fl-3Q
	for ietf@ietf.org; Thu, 05 Jan 2006 03:32:07 -0500
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	F00914F0002; Thu,  5 Jan 2006 09:26:13 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 5 Jan 2006 09:26:13 +0100
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 5 Jan 2006 09:26:13 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 5 Jan 2006 09:26:12 +0100
Message-ID: <026F8EEDAD2C4342A993203088C1FC0502104B80@esealmw109.eemea.ericsson.se>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYRblBHnezZFSb5Qnq1dUtbgCk/NAAQxUTeAAfH2uA=
From: "Lars-Erik Jonsson \(LU/EAB\)" 
To: "Yaakov Stein" ,
	"Stephane Bortzmeyer" 
X-OriginalArrivalTime: 05 Jan 2006 08:26:13.0498 (UTC)
	FILETIME=[B0943DA0:01C611D1]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>> If you do not know how to do that with Word, there is help to get.
>=20
> Yes, in RFC 3285.
>=20
> 3285 Using Microsoft Word to create Internet Drafts and RFCs. M.
>      Gahrns, T. Hain. May 2002. (Format: TXT=3D34556 bytes) (Status:   =

> INFORMATIONAL)=20
>=20
> [YJS] Yes of course we all have used that.
>=20
> However, unfortunately there are problems with that route
> and no-one is supporting it (as XML2RFC is supported).

True, this had not been a problem if the output from Word had
been consistent. Anyway, Joe Touch has been updating these tools
and you can find them at:
http://www.isi.edu/touch/tools/


> For example, when printing directly from Word (rather
> than first producing the ASCII and then printing)
> the margins are all wrong.

True, printing directly is a missing feature of the tools
provided by RFC 3285. Joe's version fixes this, so you should be
happy with his version also for that reason.

=20
> Also, certain combinations of characters I use in ASCII art
> cause (for some unknown and undocumented reason)
> strange unprintable characters to appear in the ASCII version.

Probably this is because you have used characters not part of
7-bit ASCII. It is a good idea to always turn off the auto-correct
features of Word, otherwise you will probably get strange characters.
=20
Rgds,
/L-E

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 04:18:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuRGO-0000qr-7T; Thu, 05 Jan 2006 04:18:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRGI-0000qX-Qi
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 04:18:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15877
	for ; Thu, 5 Jan 2006 04:17:05 -0500 (EST)
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuRLs-00020S-LE
	for ietf@ietf.org; Thu, 05 Jan 2006 04:24:13 -0500
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id 7DE07898D0;
	Thu,  5 Jan 2006 11:18:03 +0200 (EET)
Message-ID: <43BCE46A.1010009@piuha.net>
Date: Thu, 05 Jan 2006 11:18:34 +0200
From: Jari Arkko 
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yaakov Stein 
References: <27A0F290348F8E45AEF79889DDE65A520186102B@exrad2.ad.rad.co.il>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A520186102B@exrad2.ad.rad.co.il>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Yaakov Stein wrote:

> >   However, the text objected to in this case argues that
> this process should be extended by a process of counting the
> people who don't publicly participate in the discussion

(snip)

> We proposed gauging interest by a show of hands at a plenary
> meeting, rather than by the number of yes votes on this list.
> Yes, even that is not optimal since there are people who prefer
> working in the terminal room or touring in the evenings,
> but it certainly seems to be a better way of finding out what
> MOST IETF participants want than only reading this list.

Perhaps we can move past the discussion of what
you originally proposed or did not propose. That
does not seem very productive. And it must feel
frustrating to get criticism for something that you
did not propose.

FWIW, I believe that what you suggest above for using
the plenary is the best way to determine IETF consensus
for some IETF-encompassing issues. (With a follow-up
on this list of course, but unless that generates hundreds
of responses, its unlikely to make a difference to what
the room thought. And there should be some preparation
in the list prior to the meeting, like announcing that people
should read these drafts and that certain questions are
going to be asked.)

--Jari


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 05:07:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuS1U-0000m4-Mn; Thu, 05 Jan 2006 05:07:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuS1S-0000jC-ED
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 05:07:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20550
	for ; Thu, 5 Jan 2006 05:05:51 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EuS76-0003Ya-LK
	for ietf@ietf.org; Thu, 05 Jan 2006 05:12:57 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-2.cisco.com with ESMTP; 05 Jan 2006 02:06:56 -0800
Received: from chappe.cisco.com (chappe.cisco.com [171.71.182.172])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k05A6tjt003501;
	Thu, 5 Jan 2006 02:06:55 -0800 (PST)
Received: from chappe.cisco.com (chappe.cisco.com [171.71.182.172])
	by chappe.cisco.com (8.13.4/8.13.4) with ESMTP id k05A6qpj006515;
	Thu, 5 Jan 2006 02:06:52 -0800
Date: Thu, 5 Jan 2006 02:06:52 -0800 (PST)
From: Ole Jacobsen 
To: "Lars-Erik Jonsson (LU/EAB)" 
In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0502104B80@esealmw109.eemea.ericsson.se>
Message-ID: 
References: <026F8EEDAD2C4342A993203088C1FC0502104B80@esealmw109.eemea.ericsson.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Ole Jacobsen 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


As far as I can tell, Microsoft has no idea what ASCII means. You would
expect that "Save As... Text Only" would produce clean ASCII from a
"pretty" Word file, but it does not. Instead, you get a file which
contains various 8-bit encodings of common characters such as curly
quotation marks, en- and em-dashes, bullets and so on, in spite of the
fact that there are perfectly good, and commonly-used ASCII conventions
for all of this stuff (' " * -- --- ...). I can't tell you how much time I
spend "fixing" problems caused by this kind of stupidity. Auto-correct or
not, why can't Word have a simple "ASCII-fy" feature???

Ole

PS. Speaking about Word 11.2 for the Mac, your mileage may vary.


Ole J. Jacobsen 
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   GSM: +1 415-370-4628
E-mail: ole@cisco.com  URL: http://www.cisco.com/ipj


On Thu, 5 Jan 2006, Lars-Erik Jonsson (LU/EAB) wrote:

[ ... ]

> 
> Probably this is because you have used characters not part of
> 7-bit ASCII. It is a good idea to always turn off the auto-correct
> features of Word, otherwise you will probably get strange characters.
>  
> Rgds,
> /L-E

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 06:15:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuT61-0007NM-Mv; Thu, 05 Jan 2006 06:15:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuT5y-0007ND-W5
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 06:15:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27697
	for ; Thu, 5 Jan 2006 06:14:35 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuTBd-0005lN-TF
	for ietf@ietf.org; Thu, 05 Jan 2006 06:21:42 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EuT5v-0009YD-6L; Thu, 05 Jan 2006 06:15:47 -0500
Date: Thu, 05 Jan 2006 06:15:46 -0500
From: John C Klensin 
To: Yaakov Stein 
Message-ID: 
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A520186102D@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A520186102D@exrad2.ad.r
 ad.co.il>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Thursday, 05 January, 2006 06:57 +0200 Yaakov Stein
 wrote:

>...
> I have never had a problem opening an old file
> with an up-to-date version of the SW. The problems
> arise when you try to do the reverse. That makes sense
> of course, since if you could do everything with the
> old version, then no-one would buy the new one.
> After all, a company with 95% market has to be inventive 
> in order to continue selling.

Well, our experiences differ.  Let's put philosophical and
individual economic issues aside for a moment.  Let's also
temporarily ignore the observation that many members of our
community do their work on operating systems on which the
current version of Word is not supported.  I continue to
consider those issues to be showstoppers, but perhaps the
compatibility argument is worth pursuing a bit.   I think there
are two problems here, plus one raised in a note by Lars-Erik.  

(1) I have had problems opening and using documents from
sufficiently old versions, sometimes as recently as two versions
ago.  I even know the source of some of those problems.   For
example, I have never had a problem opening, in a clean and
unmodified current version of Word, an old document that uses
exactly one template and that one unmodified as if out of the
box, contains no macros and no workarounds for obscure bugs, and
does not use cross-references or a host of other specialized
features.  For the record, I don't suggest that any document
that uses any of those features runs into trouble, only that a
sufficiently complex combination of them do.  It has often
appeared to me that the machinery that converts from the formats
of an older version of Word to a newer one will handle the
simple cases well but, especially when the original document is
several versions older, there seems to be some tendency for Word
to get itself into trouble.  And, if the old document contains
macros or styles that are already present in the normal document
template of  the new version but with different definitions for
some of the set... my experience has been that occasionally
things work without side-effects.

For some of these cases, one even has to be careful about what
it means to successfully open an older document.  For example,
there was a considerable period in which a document written in
the then-current (not even previous-generation) version of
Windows Word could be opened just fine with the then-current
version of Mac Word... as long either the Windows version
contained no comments or one did not care that they disappeared
in the transition.

Now, you could reasonably suggest that good document hygiene
would argue for avoiding most of those features, or removing
them in the old system before trying to move documents to the
new one.   You would, of course, be correct.  But to avoid all
of those features eliminates much of the power of Word relative
to, e.g., ASCII editors that are available for all platforms at
negligible cost.  And those extended features, once inserted in
a document, are not easy to remove.  It is, for example,
possible to configure Word 2003 to issue a warning every time
one tries to save a document containing change-tracking or
comments to a file.  But, at least as far as I have been able to
discover, there are no warnings for macros, styles, and the
like.  And, while one can say "don't save", there are, as far as
I know, no options built into Word for cleanly removing all of
that stuff and getting a document into the safest of
forward-compatible forms.  Similarly, there is a configurable
warning when one opens a document with embedded macros.  But the
effect of "run safely" is not "remove all of those macros
forever" but "disable them in this session".  If they are
hostile and if, for one reason or another, the macro-removal
tool (which I'd lay good odds most users of Word don't even know
where to find) won't touch them because of how they are
installed (a common case), they just lie around as traps for
some future unwary person.

(2) If I understood correctly, one of the main arguments you
made for Word was its change-tracking and collaboration
facilities.  I certainly agree about the change-tracking.  But,
as for collaboration, it seems to me that you cannot
simultaneously argue that it is unreasonable to expect
version-downgrading to work and also argue that Word provides
good and useful support for collaborative work in a
heterogeneous community.  Again, even putting aside economic and
similar constraints, we have no way to get everyone in the
community to do an upgrade on the same day.  Even Microsoft
can't keep the feature sets in current versions of Windows Word
and Mac Word identical, if only because their release cycles
differ (nor are those versions bug-compatible, of course).  Even
if we could somehow get around those problems, few people who
obtain Word in enterprise settings are permitted to install a
newer version ahead of the rest of the enterprise, precisely
because of that downgrade problem.   So, to have collaboration
in an arbitrary IETF WG, using a single version of Word, you
would need to be sure that no Mac user is likely to be involved
with the WG (or, given the apparently-risking number of Macs
around IETF, no Windows user) and you would need to organize a
global flag day for upgrades.  Not likely, it seems to me.

Again ignoring a host of other issues, it might be possible for
IETF to agree on a particular, sufficiently-old, version of
Word.  But one can't do that either, since installation of a
current version for one's day job would uninstall and/or destroy
the earlier version.



--On Thursday, 05 January, 2006 09:26 +0100 "Lars-Erik Jonsson
\\(LU/EAB\\)"  wrote:

>> Also, certain combinations of characters I use in ASCII art
>> cause (for some unknown and undocumented reason)
>> strange unprintable characters to appear in the ASCII version.
> 
> Probably this is because you have used characters not part of
> 7-bit ASCII. It is a good idea to always turn off the
> auto-correct features of Word, otherwise you will probably get
> strange characters.

Exactly correct.  But this is a symptom of another part of the
problem described above.  Some of the auto-correct functionality
is on the list of things that make Word attractive.  The "smart
character" subset is a serious problem for the IETF and
conversion to ASCII, but getting those characters is an
important part of the style manual for many organizations.  To
the best of my knowledge, there is no way to switch the specific
problematic options off entirely and then be able to turn them
back on other than with a checklist and stepping through them
one at a time, other than "logging out" and "logging in as
another user".   Back with Windows 3.1 and corresponding version
of Office, I could figure out how to exit from Word, run an
extremely small batch job to rename a few .INI files, and then
reenter Word, reversing the process as needed, in order to
switch out one complete option set and switch in another one.
But now the bits are scattered through the registry, often in
obscurely-named keys or hidden in parts of the directory tree
that Microsoft doesn't want me to look at (and that I'm in
violation of their license provisions if I try to figure out).  

Now, a solution for this, as Ole pointed out, would be a "save
in plain, ordinary, ASCII, with no non-ASCII characters" option.
A different solution, more satisfactory in some ways but less in
others, would be a well-supported ASCII output "text printer".
I don't think it is any secret that both were suggested to
Microsoft around the time that RFC 3285 was being assembled.
At least with respect to this particular issue, it is two
versions later, we don't have an especially responsive vendor,
and, as others have pointed out, "roll your own extension" is
not really practical, especially since the behavior of a given
version of Word can differ depending on the operating system
version on which it is running.

I will strongly defend your right to use Word, or anything else
you like, as an editor.  But, as a distribution format, or even
a collaboration format within the IETF, much less as an archival
format, I think it is a complete non-starter.  And, again, that
is even if the economic and availability arguments are ignored,
but they would be, IMO, showstoppers on their own.

Finally, as an aside, you made the observation in one of your
notes that you want to use Word because it is already installed
on your machine.  I don't know where you work or who sets up
your machines.  But if I go to my local computer store and buy a
Windows-compatible machine with an OEM copy of Windows bundled
in, Word doesn't come on it, especially not the XML-(sort
of-)compatible MS Office Pro version.  That is an extra-cost
option that can nearly double the bottom-line price of the
computer.  If I build my own boxes, or have them built to my
specifications (because I prefer my choice of options to someone
else's undocumented ways to cut costs and save a few dollars
while including capabilities I won't use), I'm in even worse
trouble: Windows itself is a high-cost option, and no Windows
equals no MS Office equals no Word.  One consequence is that,
while I use several machines in the course of a typical week,
the current version of Word is just not installed on all of
them.  Not coincidentally, emacs clones are installed no all of
them -- and their output formats are forward and backward
compatible.

I should also point out that, if you are running Windows, ASCII
editors _are_ installed on your machine in the form of NotePad
and WordPad.  They aren't my idea of a fun or easy to use
editor, but you can't claim to not have them.

    john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 07:37:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuUMo-0002De-9H; Thu, 05 Jan 2006 07:37:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuUMl-0002DY-J6
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 07:37:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07623
	for ; Thu, 5 Jan 2006 07:35:59 -0500 (EST)
Received: from mtagate4.uk.ibm.com ([195.212.29.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuUSP-00005b-DV
	for ietf@ietf.org; Thu, 05 Jan 2006 07:43:07 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k05CaD4X175752
	for ; Thu, 5 Jan 2006 12:36:17 GMT
Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com
	[9.149.165.212])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k05Ca47M165064 for ; Thu, 5 Jan 2006 13:36:04 +0100
Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k05Ca3Bg022307 for ; Thu, 5 Jan 2006 13:36:03 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k05Ca3OI022288; Thu, 5 Jan 2006 13:36:03 +0100
Received: from zurich.ibm.com (sig-9-145-249-55.de.ibm.com [9.145.249.55])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA50050;
	Thu, 5 Jan 2006 13:36:02 +0100
Message-ID: <43BD12AC.1010203@zurich.ibm.com>
Date: Thu, 05 Jan 2006 13:35:56 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
	
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Engineering our way out of a brown paper bag [Re: Consensus based
 on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Harald Tveit Alvestrand wrote:
> 
> 
> --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein 
>  wrote:
> 
>> The only thing I am sure about is
>> that
>> consensus on this list is for keeping everything exactly as it is.
> 
> 
> I'm pretty sure there's no such consensus.
> 
> I do, however, see a rather strong consensus-of-the-speakers against 
> using MS-Word document format for anything "official".

I think we need to tackle this whole issue, if we do decide to
tackle it, in a much more systematic way.

- what are our functional requirements?
- which of them are not met today?
- what are the possible solutions, and what is their practical
   and operational cost?
- which, if any, solutions should we adopt, on what timescale?

I believe that if we took a systematic approach like that, the issue
of how we determine consensus would be broken into enough small
steps that it really wouldn't be an issue.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 08:09:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuUs3-0006BA-MA; Thu, 05 Jan 2006 08:09:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuUs1-0006B5-LT
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 08:09:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11334
	for ; Thu, 5 Jan 2006 08:08:15 -0500 (EST)
Received: from mtagate3.uk.ibm.com ([195.212.29.136])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuUxf-0001MM-6e
	for ietf@ietf.org; Thu, 05 Jan 2006 08:15:24 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k05D8VFB105170
	for ; Thu, 5 Jan 2006 13:08:35 GMT
Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com
	[9.149.37.228])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k05D8LeJ221990 for ; Thu, 5 Jan 2006 13:08:21 GMT
Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k05D8KoC031994 for ; Thu, 5 Jan 2006 13:08:20 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k05D8K5O031984 for ; Thu, 5 Jan 2006 13:08:20 GMT
Received: from zurich.ibm.com (sig-9-145-249-55.de.ibm.com [9.145.249.55])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA68424
	for ; Thu, 5 Jan 2006 14:08:20 +0100
Message-ID: <43BD1A3F.7000607@zurich.ibm.com>
Date: Thu, 05 Jan 2006 14:08:15 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: ietf@ietf.org
References: <20060101043514.6985.qmail@xuxa.iecc.com>	<3556DA0FCA3E512F0BF5D041@p3.JCK.COM>		<416F6B6F46586EDBC9410701@p3.JCK.COM>		<6720DA0BFF0ED02EC1B25700@svartdal.hjemme.alvestrand.no>	<43B8E169.4000202@dcrocker.net>	<33D8EA76B9350E63F056C2D8@svartdal.hjemme.alvestrand.no>	<43B90C3D.50405@bbiw.net>	<6290ABA8A965FE150484933F@svartdal.hjemme.alvestrand.no>
	<43BC26C6.5060906@cisco.com>
In-Reply-To: <43BC26C6.5060906@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Subject: Re: bozoproofing the net, was The Value of Reputation
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Michael Thomas wrote:
> Harald Tveit Alvestrand wrote:
> []
> 
> Sigh. Can I suggest that a little exponential backoff on
> all parts may be appropriate? As one of the authors of the
> dkim draft, this has been an extremely painful thread to
> watch.
> 

Correct. This is way beyond the point of being productive
and beyond the point where busy people will even read 5%
of the messages.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 08:17:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuUzb-0007tu-6b; Thu, 05 Jan 2006 08:17:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuUzZ-0007t7-Ib
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 08:17:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12236
	for ; Thu, 5 Jan 2006 08:16:05 -0500 (EST)
Received: from mail.gmx.net ([213.165.64.21])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuV5F-0001fg-MD
	for ietf@ietf.org; Thu, 05 Jan 2006 08:23:14 -0500
Received: (qmail invoked by alias); 05 Jan 2006 13:16:59 -0000
Received: from p54A7FD89.dip.t-dialin.net (EHLO peter-dambier.de)
	[84.167.253.137]
	by mail.gmx.net (mp005) with SMTP; 05 Jan 2006 14:16:59 +0100
X-Authenticated: #8956597
Message-ID: <43BD1C41.2080800@peter-dambier.de>
Date: Thu, 05 Jan 2006 14:16:49 +0100
From: Peter Dambier 
Organization: Peter and Karin Dambier
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: ietf@ietf.org
References: <27A0F290348F8E45AEF79889DDE65A520186102D@exrad2.ad.r ad.co.il>
	
In-Reply-To: 
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: peter@peter-dambier.de
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John C Klensin wrote:
> 
> --On Thursday, 05 January, 2006 06:57 +0200 Yaakov Stein
>  wrote:
> 
> 
>>...
>>I have never had a problem opening an old file
>>with an up-to-date version of the SW. The problems
>>arise when you try to do the reverse. That makes sense
>>of course, since if you could do everything with the
>>old version, then no-one would buy the new one.
>>After all, a company with 95% market has to be inventive 
>>in order to continue selling.
> 

I have had that very same experience, only worse:

There was no way of accessing documents from word for OS/2 after somebody
had been reading them with winword. Winword cold, but for word for OS/2
they were lost. Only transfering them to CP/M 86 with kermit and processing
them with wordstar and then transfering back with kermit again made them
workable again. Dont ask what happened to the typesetting.

> 
> Well, our experiences differ.  Let's put philosophical and
> individual economic issues aside for a moment.  Let's also
> temporarily ignore the observation that many members of our
> community do their work on operating systems on which the
> current version of Word is not supported.  I continue to
> consider those issues to be showstoppers, but perhaps the
> compatibility argument is worth pursuing a bit.   I think there
> are two problems here, plus one raised in a note by Lars-Erik.  
> 
> (1) I have had problems opening and using documents from
> sufficiently old versions, sometimes as recently as two versions
> ago.  I even know the source of some of those problems.   For
> example, I have never had a problem opening, in a clean and
> unmodified current version of Word, an old document that uses
> exactly one template and that one unmodified as if out of the
> box, contains no macros and no workarounds for obscure bugs, and
> does not use cross-references or a host of other specialized
> features.  For the record, I don't suggest that any document
> that uses any of those features runs into trouble, only that a
> sufficiently complex combination of them do.  It has often
> appeared to me that the machinery that converts from the formats
> of an older version of Word to a newer one will handle the
> simple cases well but, especially when the original document is
> several versions older, there seems to be some tendency for Word
> to get itself into trouble.  And, if the old document contains
> macros or styles that are already present in the normal document
> template of  the new version but with different definitions for
> some of the set... my experience has been that occasionally
> things work without side-effects.
> 
> For some of these cases, one even has to be careful about what
> it means to successfully open an older document.  For example,
> there was a considerable period in which a document written in
> the then-current (not even previous-generation) version of
> Windows Word could be opened just fine with the then-current
> version of Mac Word... as long either the Windows version
> contained no comments or one did not care that they disappeared
> in the transition.
> 
> Now, you could reasonably suggest that good document hygiene
> would argue for avoiding most of those features, or removing
> them in the old system before trying to move documents to the
> new one.   You would, of course, be correct.  But to avoid all
> of those features eliminates much of the power of Word relative
> to, e.g., ASCII editors that are available for all platforms at
> negligible cost.  And those extended features, once inserted in
> a document, are not easy to remove.  It is, for example,
> possible to configure Word 2003 to issue a warning every time
> one tries to save a document containing change-tracking or
> comments to a file.  But, at least as far as I have been able to
> discover, there are no warnings for macros, styles, and the
> like.  And, while one can say "don't save", there are, as far as
> I know, no options built into Word for cleanly removing all of
> that stuff and getting a document into the safest of
> forward-compatible forms.  Similarly, there is a configurable
> warning when one opens a document with embedded macros.  But the
> effect of "run safely" is not "remove all of those macros
> forever" but "disable them in this session".  If they are
> hostile and if, for one reason or another, the macro-removal
> tool (which I'd lay good odds most users of Word don't even know
> where to find) won't touch them because of how they are
> installed (a common case), they just lie around as traps for
> some future unwary person.
> 
> (2) If I understood correctly, one of the main arguments you
> made for Word was its change-tracking and collaboration
> facilities.  I certainly agree about the change-tracking.  But,
> as for collaboration, it seems to me that you cannot
> simultaneously argue that it is unreasonable to expect
> version-downgrading to work and also argue that Word provides
> good and useful support for collaborative work in a
> heterogeneous community.  Again, even putting aside economic and
> similar constraints, we have no way to get everyone in the
> community to do an upgrade on the same day.  Even Microsoft
> can't keep the feature sets in current versions of Windows Word
> and Mac Word identical, if only because their release cycles
> differ (nor are those versions bug-compatible, of course).  Even
> if we could somehow get around those problems, few people who
> obtain Word in enterprise settings are permitted to install a
> newer version ahead of the rest of the enterprise, precisely
> because of that downgrade problem.   So, to have collaboration
> in an arbitrary IETF WG, using a single version of Word, you
> would need to be sure that no Mac user is likely to be involved
> with the WG (or, given the apparently-risking number of Macs
> around IETF, no Windows user) and you would need to organize a
> global flag day for upgrades.  Not likely, it seems to me.
> 
> Again ignoring a host of other issues, it might be possible for
> IETF to agree on a particular, sufficiently-old, version of
> Word.  But one can't do that either, since installation of a
> current version for one's day job would uninstall and/or destroy
> the earlier version.
> 

The problem starts a lot earlier. Never have I seen a word for
my old CP/M 86. Never have I seen a word for my linux .

There is an abiword arround but comparing abiword RTF files with
Open Office RTF does not look very encourageing. Why not RTF in
the first place? Word can read it - even across versions.


After all word documents wont pass firewalls. You can hide trojans
and virae in word documents. That is why many firewalls block
emails and html pages that contain word documents.

Many email filters say plain text and no attachements.

> 
> 
> --On Thursday, 05 January, 2006 09:26 +0100 "Lars-Erik Jonsson
> \\(LU/EAB\\)"  wrote:
> 
> 
>>>Also, certain combinations of characters I use in ASCII art
>>>cause (for some unknown and undocumented reason)
>>>strange unprintable characters to appear in the ASCII version.
>>
>>Probably this is because you have used characters not part of
>>7-bit ASCII. It is a good idea to always turn off the
>>auto-correct features of Word, otherwise you will probably get
>>strange characters.
> 
> 
> Exactly correct.  But this is a symptom of another part of the
> problem described above.  Some of the auto-correct functionality
> is on the list of things that make Word attractive.  The "smart
> character" subset is a serious problem for the IETF and
> conversion to ASCII, but getting those characters is an
> important part of the style manual for many organizations.  To
> the best of my knowledge, there is no way to switch the specific
> problematic options off entirely and then be able to turn them
> back on other than with a checklist and stepping through them
> one at a time, other than "logging out" and "logging in as
> another user".   Back with Windows 3.1 and corresponding version
> of Office, I could figure out how to exit from Word, run an
> extremely small batch job to rename a few .INI files, and then
> reenter Word, reversing the process as needed, in order to
> switch out one complete option set and switch in another one.
> But now the bits are scattered through the registry, often in
> obscurely-named keys or hidden in parts of the directory tree
> that Microsoft doesn't want me to look at (and that I'm in
> violation of their license provisions if I try to figure out).  
> 
> Now, a solution for this, as Ole pointed out, would be a "save
> in plain, ordinary, ASCII, with no non-ASCII characters" option.
> A different solution, more satisfactory in some ways but less in
> others, would be a well-supported ASCII output "text printer".
> I don't think it is any secret that both were suggested to
> Microsoft around the time that RFC 3285 was being assembled.
> At least with respect to this particular issue, it is two
> versions later, we don't have an especially responsive vendor,
> and, as others have pointed out, "roll your own extension" is
> not really practical, especially since the behavior of a given
> version of Word can differ depending on the operating system
> version on which it is running.
> 
> I will strongly defend your right to use Word, or anything else
> you like, as an editor.  But, as a distribution format, or even
> a collaboration format within the IETF, much less as an archival
> format, I think it is a complete non-starter.  And, again, that
> is even if the economic and availability arguments are ignored,
> but they would be, IMO, showstoppers on their own.
> 
> Finally, as an aside, you made the observation in one of your
> notes that you want to use Word because it is already installed
> on your machine.  I don't know where you work or who sets up
> your machines.  But if I go to my local computer store and buy a
> Windows-compatible machine with an OEM copy of Windows bundled
> in, Word doesn't come on it, especially not the XML-(sort
> of-)compatible MS Office Pro version.  That is an extra-cost
> option that can nearly double the bottom-line price of the
> computer.  If I build my own boxes, or have them built to my
> specifications (because I prefer my choice of options to someone
> else's undocumented ways to cut costs and save a few dollars
> while including capabilities I won't use), I'm in even worse
> trouble: Windows itself is a high-cost option, and no Windows
> equals no MS Office equals no Word.  One consequence is that,
> while I use several machines in the course of a typical week,
> the current version of Word is just not installed on all of
> them.  Not coincidentally, emacs clones are installed no all of
> them -- and their output formats are forward and backward
> compatible.
> 
> I should also point out that, if you are running Windows, ASCII
> editors _are_ installed on your machine in the form of NotePad
> and WordPad.  They aren't my idea of a fun or easy to use
> editor, but you can't claim to not have them.
> 

I remember a lot of people destroying there config.sys and autoexec.bat
files with both wordstar and word. That is why microsoft originally
said edit those files only with edlin or notepad. Never use word or
write or winword on system configuration. I dont know wordpad. It could
do plain text it could do things like word.

I know vi. I can even use it on an asr-33 teletype processing punched
paper tapes. Using kermit for filetransfer I can even use it on
punched cards in EBCDIC. Many documents have been produced using
decks of punched cards in place of an editor. Those documents are
still valid although I think there are html versions around today.

On punched cards and perforated tape I can litterally see what my
editor does. Try reading a perforated tape from a word document.
Of course you can use od to dump a word file. No need for punched
cards :)

Reading that dump will tell you why printers go into limbo when fed
with a word document. When you deal with data that has to be suffed
into max 512 bytes then you cannot waste your brain on documents that
use 512 bytes per character.

I remember back in 1978 when I was studying computerscience that
problem with documentation and typesetting was already solved before
Intel started building microprocessors and before Microsoft got
their basic interpreter running on those microprocessors.

Ever heard of TeX? It is still used by bookprinting companies and
by resaerchers. It does not bite ascii terminals and it does give
you readable access to the original source of the document.

How come those windows people reenvited the whell again and again
doing the same known mistakes again and again. Why not go into an
antique bookstore and by a book about Tex and LaTeX and then
download it from the internet. It not only saves the mony for your
original version of word, it also saves you the headaches on all
those fixes and patches and updates and different behaviour of
versions. It saves you the expenses on virusscanners and their
updates as well.

If one day you happen to be in Uganda and want to fix a typo in
your document at O'Reillies somewhere in the US but you only have
ssh and a 1200 baud modem then you still can do it using good
old vi. Try that with an unknow version of word in Uganda and
a 20 Kb overhead for an empty word ducument.

-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@peter-dambier.de
mail: peter@echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 08:17:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuUzH-0007lB-N0; Thu, 05 Jan 2006 08:17:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuUzF-0007jY-RJ
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 08:17:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12214
	for ; Thu, 5 Jan 2006 08:15:46 -0500 (EST)
Received: from front2.mail.megapathdsl.net ([66.80.60.30]
	helo=mail.megapathdsl.net) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EuV4v-0001fR-Ra
	for ietf@ietf.org; Thu, 05 Jan 2006 08:22:55 -0500
Received: from [64.32.194.73] (HELO l-w865gbf-ws)
	by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 5.0.4)
	with ESMTP id 344953335 for ietf@ietf.org;
	Thu, 05 Jan 2006 05:16:25 -0800
From: Scott Kitterman 
To: ietf@ietf.org
Date: Thu, 5 Jan 2006 08:16:24 -0500
User-Agent: KMail/1.7
References: <313680C9A886D511A06000204840E1CF0C886254@whq-msgusr-02.pit.comms.marconi.com>
	<20060104203609.GB1459@nic.fr> <43BC47B7.9070404@gmx.de>
In-Reply-To: <43BC47B7.9070404@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200601050816.24487.scott@kitterman.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 01/04/2006 17:09, Julian Reschke wrote:
> Stephane Bortzmeyer wrote:
> > If we use a XML format, why the very large and complexe (700 pages)
> > OpenDocument and not "our" RFC 2629?
>
> Indeed. Although, at some point of time we'll have also to realize that
> there most people when they say "RFC2629" they really mean RFC2629bis.
> So, sooner or later, we'll have to start work on a proper spec revision.
>
> Best regards, Julian

As I understand it, one of the major concerns of the people pushing for 
alternative formats is a desire to be able to include drawings and diagrams 
with something other than ASCII art.  

I don't believe that XML does much to help that.  

If one is worried about things like including pictures, diagrams, revision 
marks, etc. then I think looking into something like Open Document Format 
would make a lot more sense than considering a proprietary format like MS 
Word.

OTOH, if ASCII is good enough, then I guess there's nothing to worry about.  I 
don't have enough IETF experience to have a strong opinion either way.  I 
just think that if alternatives are going to be looked at, then ODF ought to 
be one of them.

Scott Kitterman

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 08:23:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuV5Z-0002Ho-QN; Thu, 05 Jan 2006 08:23:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuV5X-0002Hj-UW
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 08:23:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13243
	for ; Thu, 5 Jan 2006 08:22:16 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EuVBE-0001vr-Qe
	for ietf@ietf.org; Thu, 05 Jan 2006 08:29:25 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 05 Jan 2006 05:04:02 -0800
X-IronPort-AV: i="3.99,334,1131350400"; 
	d="scan'208"; a="387648288:sNHT951645242"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k05D3pjx006948
	for ; Thu, 5 Jan 2006 05:04:02 -0800 (PST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 5 Jan 2006 08:04:01 -0500
Received: from 10.86.242.30 ([10.86.242.30]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Thu,  5 Jan 2006 13:04:01 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Thu, 05 Jan 2006 08:04:00 -0500
From: Ralph Droms 
To: 
Message-ID: 
Thread-Topic: Engineering our way out of a brown paper bag [Re: Consensus
	based on reading tea leaves]
Thread-Index: AcYR+H6WvOc/hn3rEdqdEQARJOT6eg==
In-Reply-To: <43BD12AC.1010203@zurich.ibm.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 05 Jan 2006 13:04:01.0198 (UTC)
	FILETIME=[7F4D6CE0:01C611F8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus
 based on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian - you've hit on an important point here.  It strikes me that the
process for defining our own document standards has no fundamental
differences from the process for defining any other standard.  Why shouldn't
this archival document standard be developed and adopted as a Standard in
the same way?

I've explicitly refrained from contributing any observations from my 15
years of experiences working with IETF docs in vi, emacs, nroff, Word,
LaTeX, PDF, ASCII-art diagrams, XML2RFC, dot-matrix printers, etc., as well
as experience with Word in CableLabs/DOCSIS specs - because those
contributions would not be part of an engineering process like the one you
describe, and would be simply more hot air if posted outside of a process.

Well, one might say, haven't we tried the IETF process on the archival
document format problem in the past?  And the document format hasn't
changed.  Yup, and there are a couple of (not necessarily mutually
exclusive) conclusions we might draw:

* the current format is the best solution we can devise for our requirements
* the IETF engineering process is flawed

- Ralph


On 1/5/06 7:35 AM, "Brian E Carpenter"  wrote:

> Harald Tveit Alvestrand wrote:
>> 
>> 
>> --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein
>>  wrote:
>> 
>>> The only thing I am sure about is
>>> that
>>> consensus on this list is for keeping everything exactly as it is.
>> 
>> 
>> I'm pretty sure there's no such consensus.
>> 
>> I do, however, see a rather strong consensus-of-the-speakers against
>> using MS-Word document format for anything "official".
> 
> I think we need to tackle this whole issue, if we do decide to
> tackle it, in a much more systematic way.
> 
> - what are our functional requirements?
> - which of them are not met today?
> - what are the possible solutions, and what is their practical
>    and operational cost?
> - which, if any, solutions should we adopt, on what timescale?
> 
> I believe that if we took a systematic approach like that, the issue
> of how we determine consensus would be broken into enough small
> steps that it really wouldn't be an issue.
> 
>      Brian
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 09:22:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuW0g-0005ls-0D; Thu, 05 Jan 2006 09:22:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuW0b-0005lb-Ef
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 09:22:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19571
	for ; Thu, 5 Jan 2006 09:21:13 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuW6H-00040M-Oz
	for ietf@ietf.org; Thu, 05 Jan 2006 09:28:23 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 05 Jan 2006 15:22:19 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k05EMGFZ011293; 
	Thu, 5 Jan 2006 15:22:16 +0100 (MET)
Received: from [64.103.64.233] (dhcp-rea-gp250-64-103-64-233.cisco.com
	[64.103.64.233])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA03899;
	Thu, 5 Jan 2006 14:22:15 GMT
Message-ID: <43BD2B97.3070400@cisco.com>
Date: Thu, 05 Jan 2006 14:22:15 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian E Carpenter 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>	
	<43BD12AC.1010203@zurich.ibm.com>
In-Reply-To: <43BD12AC.1010203@zurich.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus
 based on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian E Carpenter wrote:

> Harald Tveit Alvestrand wrote:
>
>>
>>
>> --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein 
>>  wrote:
>>
>>> The only thing I am sure about is
>>> that
>>> consensus on this list is for keeping everything exactly as it is.
>>
>>
>>
>> I'm pretty sure there's no such consensus.
>>
>> I do, however, see a rather strong consensus-of-the-speakers against 
>> using MS-Word document format for anything "official".
>
>
> I think we need to tackle this whole issue, if we do decide to
> tackle it, in a much more systematic way.

I am in favour of any practical method that allows us to progress towards
the best tools for the job.

My personal end-goal is simple: I want us to be able to use modern
graphical techniques in normative text to help me to describe problems
and their solutions. There are many other nice-to-have's, but at the end
of the day it is the diagrams that are the key missing feature in
our document process.

The following would be a fine set up steps on the way to
determining the way forward. Perhaps my co-authors and I should
attempt another draft with this structure.

> - what are our functional requirements?
> - which of them are not met today?
> - what are the possible solutions, and what is their practical
>   and operational cost?
> - which, if any, solutions should we adopt, on what timescale?
>
> I believe that if we took a systematic approach like that, the issue
> of how we determine consensus would be broken into enough small
> steps that it really wouldn't be an issue.

Maybe.

The discussion on the list illustrates the well known problem
of determining consensus in the presence of highly vocal members
of the IETF community. This, as I recall,  is a problem that was
discussed some time ago in the "Miss Manners" talk. However it is 
separate problem from the issue of document formats and
should be addressed as a different work item.

- Stewart

>
>     Brian
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 09:26:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuW4A-0007I3-Il; Thu, 05 Jan 2006 09:26:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuW47-0007Fc-PO
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 09:26:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19914
	for ; Thu, 5 Jan 2006 09:24:51 -0500 (EST)
Received: from mail121.messagelabs.com ([216.82.241.195])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuW9k-00048r-5T
	for ietf@ietf.org; Thu, 05 Jan 2006 09:32:01 -0500
X-VirusChecked: Checked
X-Env-Sender: gash@att.com
X-Msg-Ref: server-12.tower-121.messagelabs.com!1136471129!8562908!8
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 22553 invoked from network); 5 Jan 2006 14:25:51 -0000
Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4)
	by server-12.tower-121.messagelabs.com with SMTP;
	5 Jan 2006 14:25:51 -0000
Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by
	attrh3i.attrh.att.com (7.2.052)
	id 43AED14A000DF445; Thu, 5 Jan 2006 09:25:51 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 5 Jan 2006 08:25:51 -0600
Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: Baby Steps (was RE: Alternative formats for IDs)
Thread-Index: AcYOlVR9ovrFTyXdS6uaA3deoXfOpwDak4Fw
From: "Ash, Gerald R \(Jerry\)" 
To: "Yaakov Stein" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \(Jerry\)" 
Subject: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Happy New Year to all!

Many thanks to Yaakov for his excellent handling of the list discussion. =
 I'm not very surprised with the way it has gone.  D=E9j=E0 vu all over =
again :-)

The challenge is to focus the discussion to try to reach consensus on =
moving forward with a process change, i.e., we need to take baby steps =
to make progress.

I'd suggest we try to reach consensus first on the following:
Alternative format(s) for IDs, in addition to ASCII text, should be =
allowed. =20

One requirement/motivation for this change (as set forth in the ID) is =
to be able to include drawings and diagrams with something much more =
flexible than ASCII art.

Based on the prior discussion of 'ASCII art', and the current =
discussion, I see few people arguing that ASCII text is all we need and =
that no other formats should ever be allowed.

Let's set aside for now which format(s), and take that as a later step =
if we can take this first step.

Thanks,
Regards,
Jerry=20

________________________________

From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of =
Yaakov Stein
Sent: Sunday, January 01, 2006 12:37 AM
To: ietf@ietf.org
Subject: Alternative formats for IDs

Happy new year to everyone.
=20
I would like to call your attention to a new ID
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt.
=20
This ID is the result of discussions here on the general list,
and proposes the use of formats other than plain ASCII
for IDs and RFCs. In particular, it proposes the allowance
of diagrams other than "ASCII-art" as normative.
=20
The authors felt that further discussion on the list would not be =
productive,=20
but that the writing of an ID might force more serious consideration.
We furthermore suggest that this ID be advanced as a BCP
under the process for process change.
=20
Y(J)S

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 10:53:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuXQI-0001E6-Dw; Thu, 05 Jan 2006 10:53:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXQG-0001DB-IN
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 10:53:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00023
	for ; Thu, 5 Jan 2006 10:51:49 -0500 (EST)
Received: from biscayne-one-station.mit.edu ([18.7.7.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuXVw-0007Gc-1Q
	for ietf@ietf.org; Thu, 05 Jan 2006 10:58:58 -0500
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id
	k05FqutS001467; Thu, 5 Jan 2006 10:52:56 -0500 (EST)
Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0)
	(User authenticated as raeburn@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k05Fqntj004747
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Thu, 5 Jan 2006 10:52:50 -0500 (EST)
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EVS1.ugd.att.com>
References: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EVS1.ugd.att.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2C5717A8-6C92-481A-9FEC-CEA433CA9D9D@mit.edu>
From: Ken Raeburn 
Date: Thu, 5 Jan 2006 10:52:48 -0500
To: "Ash, Gerald R ((Jerry))" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: IETF General Discussion Mailing List 
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jan 5, 2006, at 09:25, Ash, Gerald R ((Jerry)) wrote:
> I'd suggest we try to reach consensus first on the following:
> Alternative format(s) for IDs, in addition to ASCII text, should be  
> allowed.
>
> One requirement/motivation for this change (as set forth in the ID)  
> is to be able to include drawings and diagrams with something much  
> more flexible than ASCII art.
>
> Based on the prior discussion of 'ASCII art', and the current  
> discussion, I see few people arguing that ASCII text is all we need  
> and that no other formats should ever be allowed.
>
> Let's set aside for now which format(s), and take that as a later  
> step if we can take this first step.

Splitting the question this way paves the way for those pushing for  
alternative formats to frame the next question as, "Which alternative  
format are we going to allow?", as if it's already decided that we're  
going to allow *some* alternative and just have to find the best, or  
at least the least objectionable, even if there aren't any that  
fulfill the IETF's overall needs as well as plain ASCII text.  If you  
add the qualifier, "if they meet our requirements" ("... better than  
plain ASCII text"?), then I doubt you'll get much disagreement with  
that statement, though you'll probably get a lot of discussion about  
how we don't yet *have* a specific list of requirements.  As Brian's  
brown paper bag note suggests, we should start there, not with the  
assumption that we *will* allow some alternate format....

Personally, I'm skeptical that we'll find an alternative that meets  
our requirements as well, but perhaps we'll wind up with plain UTF-8  
text or something.

Ken

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 10:57:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuXUT-0002CK-Fa; Thu, 05 Jan 2006 10:57:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXUR-0002Br-9I
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 10:57:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00596;
	Thu, 5 Jan 2006 10:56:08 -0500 (EST)
Received: from mtagate1.uk.ibm.com ([195.212.29.134])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EuXa7-0007Sk-Iq; Thu, 05 Jan 2006 11:03:17 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k05FuasE167038; 
	Thu, 5 Jan 2006 15:56:52 GMT
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com
	[9.149.37.213])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k05FuZeJ216898; Thu, 5 Jan 2006 15:56:35 GMT
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k05FuZ2Q013710; Thu, 5 Jan 2006 15:56:35 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k05FuZn9013705; Thu, 5 Jan 2006 15:56:35 GMT
Received: from zurich.ibm.com (sig-9-146-216-120.de.ibm.com [9.146.216.120])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA80278;
	Thu, 5 Jan 2006 16:56:33 +0100
Message-ID: <43BD41AF.2000907@zurich.ibm.com>
Date: Thu, 05 Jan 2006 16:56:31 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Spencer Dawkins 
References: 
	<11ed01c6081d$60fa7ba0$d0087c0a@china.huawei.com>
In-Reply-To: <11ed01c6081d$60fa7ba0$d0087c0a@china.huawei.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Content-Transfer-Encoding: 7bit
Cc: iad@ietf.org, ietf@ietf.org
Subject: Re: More on the Secretariat Statement of Work (SOW)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Firstly, I'll observe that this is outside the strict scope
of the Secretariat SOW, since it covers the process cradle-to-grave,
including WG, IESG, IANA and RFC Editor actions.

Secondly, yes, "dashboard" metrics are a good idea, and are on the
Tools team agenda, but often the devil is in the details and it's
only by looking at specific cases of apparently stuck drafts
that we can understand why things are moving slowly.

     Brian

Spencer Dawkins wrote:
> Bernard/All,
> 
> Ack on Bernard's note.
> 
> I know that speed isn't the only thing that matters, but if we move 
> slowly enough, the other stuff that matters won't matter.
> 
> I'm remembering from previous discussions (sometime around the time of 
> http://www3.ietf.org/proceedings/03mar/134.htm? or 
> http://www3.ietf.org/proceedings/04mar/981.htm?) that the states we 
> track in the ID tracker are sometimes overloaded, so it's hard to tell 
> who has the token and exactly what is happening with the draft, and 
> there are limits on what we've been able to do with metrics in the past.
> 
> It's definitely worth thinking about this from a metrics perspective.
> 
> Spencer
> 
> 
>> In thinking through the Statement of Work (SoW), I think that an 
>> important
>> component is to provide the IETF with sufficient information on how well
>> the organization is performing.
>>
>> There are many metrics for that, but an important one is the time 
>> taken in
>> various stages of the IETF process.
>>
>> Unfortunately, it is not clear to me that we are currently collecting 
>> this
>> information in a form that makes it easy to analyze.  We are also not
>> analyzing the data on a regular basis, using it in a systematic effort to
>> improve IETF performance (or at least to prevent it from deteriorating
>> further).
>>
>> Researchers such as Tim Simcoe of the University of Toronto have studied
>> metrics of IETF performance and have come to some interesting 
>> conclusions.
>> For example, it appears that time from an initial -00 to RFC publication
>> varies considerably by area, as well as by designation (Information,
>> Experiemntal, Proposed).  In the process of developing this research, Tim
>> has also had to do significant work to adjust the data to make it 
>> suitable
>> for analysis.
>>
>> My suggestion is that the IAOC needs to start thinking about what data
>> and reports are needed to enable the IETF to measure and improve its
>> performance.
>>
>> References
>> ----------
>>
>> Simcoe, T., "Delays and de Jure Standards: What Caused the Slowdown in
>> Internet Standards Development?", UC Berkeley Haas  School of Business,
>> April 2004.
>>
>> Simcoe, T., "Standards Setting Committees", J.L Rotman School of
>> Management, University of Toronto, Decmeber 2005.
>>
>> Available at: http://www.drizzle.com/~aboba/IAB/simcoe/
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 11:28:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuXyT-0004M0-5x; Thu, 05 Jan 2006 11:28:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXyR-0004Lf-He
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 11:28:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05004
	for ; Thu, 5 Jan 2006 11:27:08 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuY49-0000IT-Qk
	for ietf@ietf.org; Thu, 05 Jan 2006 11:34:18 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EuXyJ-0009zO-0n; Thu, 05 Jan 2006 11:28:15 -0500
Date: Thu, 05 Jan 2006 11:28:14 -0500
From: John C Klensin 
To: "Ash, Gerald R \\(Jerry\\)" ,
	Yaakov Stein , ietf@ietf.org
Message-ID: 
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EVS1.ugd.att.com>
References: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EV
	S1.ugd.att.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
\\(Jerry\\)"  wrote:

> Happy New Year to all!
>=20
> Many thanks to Yaakov for his excellent handling of the list
> discussion.  I'm not very surprised with the way it has gone.
> D=C3=A9j=C3=A0 vu all over again :-)
>=20
> The challenge is to focus the discussion to try to reach
> consensus on moving forward with a process change, i.e., we
> need to take baby steps to make progress.
>=20
> I'd suggest we try to reach consensus first on the following:
> Alternative format(s) for IDs, in addition to ASCII text,
> should be allowed. =20
>=20
> One requirement/motivation for this change (as set forth in
> the ID) is to be able to include drawings and diagrams with
> something much more flexible than ASCII art.
>=20
> Based on the prior discussion of 'ASCII art', and the current
> discussion, I see few people arguing that ASCII text is all we
> need and that no other formats should ever be allowed.

Even those of us who are strongly supportive of ASCII as our
primary base format and those who believe that the effort needed
to simplify illustrations and diagrams sufficiently that they
can be accurately represented in ASCII artwork is helpful in
forcing clarity are reluctant to say "never".

> Let's set aside for now which format(s), and take that as a
> later step if we can take this first step.

Jerry, one of the nice things about baby steps is that you
sometimes discover that the baby learned to take the steps
without any instruction.

Unless the IESG has changed the rules while I was not looking,
it has been permitted to post I-Ds in PDF in addition to ASCII
for some years. I find it interesting that it has not been taken
advantage of more often (and, for the record, I'm one of those
who has taken advantage of it).  When it has been done for
artwork purposes, the artwork in the ASCII version has sometimes
been pretty rudimentary.   In practice, whether it is "good
enough" has been made on a case by case basis by WG Chairs and
WGs or, for non-WG documents, by whether or not the relevant
people are willing to read and consider those documents.
Similarly, when PDF has been posted in order to exhibit
non-ASCII characters, it has proven helpful to have Unicode
character offsets (i.e., U+nnnn representations)  in both the
ASCII and PDF forms to ensure complete precision even though the
character-glyphs themselves appear only in the PDF form. =20

So, consider the first baby step to have been taken: nothing
prevents you from posting an I-D in both ASCII and PDF today,
and the relevant sub-community will sort out, on a case by case
basis, whether the ASCII is good enough.   If you do more of it,
perhaps we can move some of the interoperability problems into
the realm of actual IETF experience and out of the realm of
extrapolation from other situations mixed with pure speculation.

Free advice: if and when you want to move beyond that point,
drop (or isolate into separate documents):

	(1) Recommendations for IETF process change or specific
	ways to determine consensus.  They should be separate so
	they can be considered separately, using an appropriate
	process.

	(2) Distinguish clearly between what is required or
	tolerable for I-Ds and what is required or tolerable for
	RFCs.  RFCs, in general, put a less strong requirement
	on easy extraction and modification of text than I-Ds.
	And, since I-Ds in theory expire after six months, you
	might be able to convince the community that the "be
	sure it can be read twenty years later" requirement for
	archival documents should not be taken as seriously for
	I-Ds.
	
	(3) Recommendations to permit any format that is (i)
	proprietary, or (ii) dependent on particular software
	for processing where that software carries either high
	costs, onerous licensing requirements,  or licensing
	requirement that attempt to prohibit the development of
	independent tools to work with the format, or (iii)
	significantly operating-system dependent, or (iv)
	significantly version-dependent in the sense that the
	documents are not forward and backward compatible.

I would suggest to you that the fact that Word hits a jackpot by
satisfying all of the negative criteria in that third suggestion
is the reason why it has been regularly rejected for IETF
posting and working use in the past and is almost certain to be
rejected in the future.  If you want to consider that =
d=C3=A9j=C3=A0 vu
(or deja vu, for ASCII-readers), it certainly is in the sense
that we have been here before... but that rather misses the
point: it has been rejected in the past for substantial and
substantive reasons and the d=C3=A9j=C3=A0 vu situation, for me =
at
least, is that someone decides to bring it up again every few
years as if it had never been considered in the past.

regards,
    john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 11:45:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuYEs-000144-9h; Thu, 05 Jan 2006 11:45:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYEp-00013a-Qq
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 11:45:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07156
	for ; Thu, 5 Jan 2006 11:43:59 -0500 (EST)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuYKS-00011A-BR
	for ietf@ietf.org; Thu, 05 Jan 2006 11:51:09 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170])
	by minbar.fac.cs.cmu.edu id aa00680; 5 Jan 2006 11:44 EST
Date: Thu, 05 Jan 2006 11:44:47 -0500
From: Jeffrey Hutzelman 
To: Yaakov Stein , ietf@ietf.org
Message-ID: 
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A520186102E@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A520186102E@exrad2.ad.rad.co.il>
Originator-Info: login-token=Mulberry:01GEIB0YKqdkVkjXlSS8AxQK+0OPyfdnqFty82TsI=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: 
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Thursday, January 05, 2006 07:03:39 AM +0200 Yaakov Stein 
 wrote:

> [YJS] Actually, cuneiform on clay tablets and hieroglyphics on marble
> stelai seem to be better than paper if you really want your message to
> last a long time.

I'm not convinced clay is better than paper; marble certainly is.
However, neither is as widely deployed, probably due to the high costs of 
production and distribution.  :-)

-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 11:49:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuYJH-0002wO-1V; Thu, 05 Jan 2006 11:49:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYJF-0002wB-4O
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 11:49:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08312
	for ; Thu, 5 Jan 2006 11:48:38 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYOv-0001MF-Lk
	for ietf@ietf.org; Thu, 05 Jan 2006 11:55:48 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 05 Jan 2006 17:49:42 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k05GncFZ021133; 
	Thu, 5 Jan 2006 17:49:39 +0100 (MET)
Received: from [64.103.64.233] (dhcp-rea-gp250-64-103-64-233.cisco.com
	[64.103.64.233])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA18220;
	Thu, 5 Jan 2006 16:49:37 GMT
Message-ID: <43BD4E21.4050208@cisco.com>
Date: Thu, 05 Jan 2006 16:49:37 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ken Raeburn 
References: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EVS1.ugd.att.com>
	<2C5717A8-6C92-481A-9FEC-CEA433CA9D9D@mit.edu>
In-Reply-To: <2C5717A8-6C92-481A-9FEC-CEA433CA9D9D@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Cc: "Ash, Gerald R \(\(Jerry\)\)" ,
	IETF General Discussion Mailing List 
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ken Raeburn wrote:

> On Jan 5, 2006, at 09:25, Ash, Gerald R ((Jerry)) wrote:
>
>> I'd suggest we try to reach consensus first on the following:
>> Alternative format(s) for IDs, in addition to ASCII text, should be  
>> allowed.
>>
>> One requirement/motivation for this change (as set forth in the ID)  
>> is to be able to include drawings and diagrams with something much  
>> more flexible than ASCII art.
>>
>> Based on the prior discussion of 'ASCII art', and the current  
>> discussion, I see few people arguing that ASCII text is all we need  
>> and that no other formats should ever be allowed.
>>
>> Let's set aside for now which format(s), and take that as a later  
>> step if we can take this first step.
>
>
> Splitting the question this way paves the way for those pushing for  
> alternative formats to frame the next question as, "Which alternative  
> format are we going to allow?", as if it's already decided that we're  
> going to allow *some* alternative and just have to find the best, or  
> at least the least objectionable, even if there aren't any that  
> fulfill the IETF's overall needs as well as plain ASCII text.  If you  
> add the qualifier, "if they meet our requirements" ("... better than  
> plain ASCII text"?), then I doubt you'll get much disagreement with  
> that statement, though you'll probably get a lot of discussion about  
> how we don't yet *have* a specific list of requirements.  As Brian's  
> brown paper bag note suggests, we should start there, not with the  
> assumption that we *will* allow some alternate format....
>
> Personally, I'm skeptical that we'll find an alternative that meets  
> our requirements as well, but perhaps we'll wind up with plain UTF-8  
> text or something.
>
How would I encode graphics in UTF-8?

Stewart

> Ken
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 11:51:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuYL0-0003qk-Qh; Thu, 05 Jan 2006 11:51:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYKu-0003lH-SK
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 11:51:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08422
	for ; Thu, 5 Jan 2006 11:50:21 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYQa-0001R7-NK
	for ietf@ietf.org; Thu, 05 Jan 2006 11:57:31 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k05GpMdJ004453; Thu, 5 Jan 2006 11:51:22 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11460; 
	Thu, 5 Jan 2006 11:51:17 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 5 Jan 2006 11:51:17 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Yaakov Stein'" 
Date: Thu, 5 Jan 2006 11:50:55 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 0.6 (/)
X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221
Cc: ietf@ietf.org
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1927093638=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1927093638==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C61216.D9A1512A"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C61216.D9A1512A
Content-Type: text/plain

Yaakov,
 
    Here's the text that says "all that"...
 
"It is much more likely to hear from the very vocal people who are 
 opposed to the change. That is, assuming 1000s of participants 
 on the IETF discussion list, perhaps 20 expressed 'nays', even 
 strong nays, could be considered a clear consensus in favor of 
 change."
 
    The clear implication here is that we could choose to regard
the 20 expressed 'nays', even  strong nays, as atypical among
the silent majority - if that assumption suits our purpose.  Or, we
could assume the reverse...
 
    The current process requires weighing of voices, not weighing
of the supposed opinions of the silent.
 
--
Eric


  _____  

From: Yaakov Stein [mailto:yaakov_s@rad.com] 
Sent: Wednesday, January 04, 2006 11:25 PM
To: Gray, Eric; Brian E Carpenter
Cc: ietf@ietf.org
Subject: RE: objection to proposed change to "consensus"


>   However, the text objected to in this case argues that
this process should be extended by a process of counting the
people who don't publicly participate in the discussion, either
way, as having tacitly given their approval to whatever side of
the argument the authors, the WG chairs or the IESG choose.

Wow, did we say all that?
 
All we are saying is that for the issue we are discussing
there is no WG. The only list that is open to its discussion 
is the general list, where there is no support.
 
However, quite a large number of people who actively participate
in IETF WGs (people who are interested in working on technical topics, 
but not on the internal workings of the IETF) who want the process
changed.
 
We proposed gauging interest by a show of hands at a plenary
meeting, rather than by the number of yes votes on this list.
Yes, even that is not optimal since there are people who prefer
working in the terminal room or touring in the evenings,
but it certainly seems to be a better way of finding out what
MOST IETF participants want than only reading this list.
 
I fail to see how this is equivalent to allowing authors or chairs 
to decide for themselves what should be done.
 
Y(J)S
 


------_=_NextPart_001_01C61216.D9A1512A
Content-Type: text/html




RE: objection to proposed change to "consensus"




Yaakov,


 


    Here's the text that says "all 
that"...


 


"It is much more likely to hear from the 
very vocal people who are 


 opposed to the change. That is, 
assuming 1000s of participants 


 on the IETF discussion list, 
perhaps 20 expressed 'nays', even 


 strong nays, could be considered 
a clear consensus in favor of 


 change."


 


    The clear implication here is that we 
could choose to regard


the 20 expressed 'nays', even  strong nays, as atypical 
among


the silent majority - if 
that assumption suits our purpose.  Or, we


could assume the 
reverse...


 


    The 
current process requires weighing of voices, not 
weighing


of the supposed opinions of 
the silent.


 


--


Eric




  

  

  From: Yaakov Stein [mailto:yaakov_s@rad.com] 
  
Sent: Wednesday, January 04, 2006 11:25 PM
To: Gray, 
  Eric; Brian E Carpenter
Cc: ietf@ietf.org
Subject: RE: 
  objection to proposed change to "consensus"


  

  

  
>   However, the text objected to in 
  this case argues that
this process should be extended by a process of 
  counting the
people who don't publicly participate in the discussion, 
  either
way, as having tacitly given their approval to whatever side 
  of
the argument the authors, the WG chairs or the IESG choose.

Wow, 
  did we say all that?

  
 

  
All we are saying is that for the issue we are 
  discussing

  
there is no WG. The only list that is open to its 
  discussion 

  
is the general list, where there is no 
  support.

  
 

  
However, quite a large number of people who actively 
  participate

  
in IETF WGs (people who are interested in 
  working on technical topics, 

  
but not on the internal workings of the IETF) who 
  want the process

  
changed.

  
 

  
We proposed gauging interest by a show of hands at a 
  plenary

  
meeting, rather than by the number of yes votes on 
  this list.

  
Yes, even that is not optimal since there are people 
  who prefer

  
working in the terminal room or touring in the 
  evenings,

  
but it certainly seems to be a better way of finding 
  out what

  
MOST IETF participants want than only reading this 
  list.

  
 

  
I fail to see how this is equivalent to allowing 
  authors or chairs 

  
to decide for themselves what 
  should be done.

  
 

  
Y(J)S

  
 


------_=_NextPart_001_01C61216.D9A1512A--


--===============1927093638==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1927093638==--




From ietf-bounces@ietf.org Thu Jan 05 11:53:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuYN8-00055f-9o; Thu, 05 Jan 2006 11:53:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYN5-00054x-1v
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 11:53:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08857
	for ; Thu, 5 Jan 2006 11:52:35 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EuYSk-0001Xf-G3
	for ietf@ietf.org; Thu, 05 Jan 2006 11:59:45 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-1.cisco.com with ESMTP; 05 Jan 2006 08:53:33 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k05Gr9R2029856;
	Thu, 5 Jan 2006 08:53:31 -0800 (PST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 5 Jan 2006 11:53:06 -0500
Received: from [10.86.240.157] ([10.86.240.157]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 11:53:05 -0500
Message-ID: <43BD4EF1.5010309@cisco.com>
Date: Thu, 05 Jan 2006 11:53:05 -0500
From: Scott W Brim 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.3.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John C Klensin 
References: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EV	S1.ugd.att.com>
	
In-Reply-To: 
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Jan 2006 16:53:06.0008 (UTC)
	FILETIME=[7FD8FD80:01C61218]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: "Ash, Gerald R \\\(Jerry\\\)" , ietf@ietf.org
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 01/05/2006 11:28 AM, John C Klensin allegedly wrote:
> Even those of us who are strongly supportive of ASCII as our
> primary base format and those who believe that the effort needed
> to simplify illustrations and diagrams sufficiently that they
> can be accurately represented in ASCII artwork is helpful in
> forcing clarity are reluctant to say "never".

> Unless the IESG has changed the rules while I was not looking,
> it has been permitted to post I-Ds in PDF in addition to ASCII
> for some years.

Yes.  I support ASCII as the output format.  I appreciate the
discipline it encourages of separating protocol specification from
descriptive text and figures, and of being very clear about state
machines, etc.  However, there are cases where descriptive text and
figures are much more informative in some other format, so I wouldn't
say never (nor should I be forced into a position of choosing between
never and always).

> I find it interesting that it has not been taken
> advantage of more often (and, for the record, I'm one of those
> who has taken advantage of it).  

For heuristic value ... Do you think there is a correlation between
restricting ourselves to formats which are good for protocol
specifications but not much else, and the skew in our success record
toward problems solved by protocol specifications as opposed to the
really complex system problems? :-)

By the way, I like emacs picture mode.  You can bind the keypad keys
so that e.g. "3" means "draw toward the upper right".

swb

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 12:01:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuYUZ-00075Y-QE; Thu, 05 Jan 2006 12:01:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYUX-00075L-C7
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 12:01:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09915
	for ; Thu, 5 Jan 2006 12:00:18 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYaC-0001qG-Mh
	for ietf@ietf.org; Thu, 05 Jan 2006 12:07:25 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 05 Jan 2006 18:01:20 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k05H1HFZ024047; 
	Thu, 5 Jan 2006 18:01:17 +0100 (MET)
Received: from [64.103.64.233] (dhcp-rea-gp250-64-103-64-233.cisco.com
	[64.103.64.233])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA19484;
	Thu, 5 Jan 2006 17:01:16 GMT
Message-ID: <43BD50DC.8090100@cisco.com>
Date: Thu, 05 Jan 2006 17:01:16 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John C Klensin 
References: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EV	S1.ugd.att.com>
	
In-Reply-To: 
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227
Cc: "Ash, Gerald R \\\(Jerry\\\)" , ietf@ietf.org
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1776014194=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.
--===============1776014194==
Content-Type: multipart/alternative;
	boundary="------------060507000609040906070000"

This is a multi-part message in MIME format.
--------------060507000609040906070000
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA09915

John C Klensin wrote:

>--On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
>\\(Jerry\\)"  wrote:
>
> =20
>
>>Happy New Year to all!
>>
>>Many thanks to Yaakov for his excellent handling of the list
>>discussion.  I'm not very surprised with the way it has gone.
>>D=C3=A9j=C3=A0 vu all over again :-)
>>
>>The challenge is to focus the discussion to try to reach
>>consensus on moving forward with a process change, i.e., we
>>need to take baby steps to make progress.
>>
>>I'd suggest we try to reach consensus first on the following:
>>Alternative format(s) for IDs, in addition to ASCII text,
>>should be allowed. =20
>>
>>One requirement/motivation for this change (as set forth in
>>the ID) is to be able to include drawings and diagrams with
>>something much more flexible than ASCII art.
>>
>>Based on the prior discussion of 'ASCII art', and the current
>>discussion, I see few people arguing that ASCII text is all we
>>need and that no other formats should ever be allowed.
>>   =20
>>
>
>Even those of us who are strongly supportive of ASCII as our
>primary base format and those who believe that the effort needed
>to simplify illustrations and diagrams sufficiently that they
>can be accurately represented in ASCII artwork is helpful in
>forcing clarity are reluctant to say "never".
>
> =20
>
>>Let's set aside for now which format(s), and take that as a
>>later step if we can take this first step.
>>   =20
>>
>
>Jerry, one of the nice things about baby steps is that you
>sometimes discover that the baby learned to take the steps
>without any instruction.
>
>Unless the IESG has changed the rules while I was not looking,
>it has been permitted to post I-Ds in PDF in addition to ASCII
>for some years.=20
>
BUT the pdf is not allowed to be normative. Changing that rule alone woul=
d
be sufficient to allow modern graphics to be called up in normative texts.

>I find it interesting that it has not been taken
>advantage of more often (and, for the record, I'm one of those
>who has taken advantage of it).  When it has been done for
>artwork purposes, the artwork in the ASCII version has sometimes
>been pretty rudimentary.   In practice, whether it is "good
>enough" has been made on a case by case basis by WG Chairs and
>WGs or, for non-WG documents, by whether or not the relevant
>people are willing to read and consider those documents.
> =20
>
Please clarify this. Are you saying that if the WG/WGchairs/ADs agree=20
that the non-ASCII
version should be the normative version (because they want the better=20
artwork), then  that's
OK? I thought  I asked this a long time ago and was told no.
=20

>Similarly, when PDF has been posted in order to exhibit
>non-ASCII characters, it has proven helpful to have Unicode
>character offsets (i.e., U+nnnn representations)  in both the
>ASCII and PDF forms to ensure complete precision even though the
>character-glyphs themselves appear only in the PDF form. =20
>
>So, consider the first baby step to have been taken: nothing
>prevents you from posting an I-D in both ASCII and PDF today,
>and the relevant sub-community will sort out, on a case by case
>basis, whether the ASCII is good enough.  =20
>
...and if it's not the pdf version of the text including graphics will=20
become the RFC?

- Stewart

--------------060507000609040906070000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA09915




  
  


John C Klensin wrote:



  
--On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
\\(Jerry\\)" <gash@att.com> wrote:

  

  

    
Happy New Year to all!

Many thanks to Yaakov for his excellent handling of the list
discussion.  I'm not very surprised with the way it has gone.
D=C3=A9j=C3=A0 vu all over again :-)

The challenge is to focus the discussion to try to reach
consensus on moving forward with a process change, i.e., we
need to take baby steps to make progress.

I'd suggest we try to reach consensus first on the following:
Alternative format(s) for IDs, in addition to ASCII text,
should be allowed. =20

One requirement/motivation for this change (as set forth in
the ID) is to be able to include drawings and diagrams with
something much more flexible than ASCII art.

Based on the prior discussion of 'ASCII art', and the current
discussion, I see few people arguing that ASCII text is all we
need and that no other formats should ever be allowed.
    

  

  

Even those of us who are strongly supportive of ASCII as our
primary base format and those who believe that the effort needed
to simplify illustrations and diagrams sufficiently that they
can be accurately represented in ASCII artwork is helpful in
forcing clarity are reluctant to say "never".

  

  

    
Let's set aside for now which format(s), and take that=
 as a
later step if we can take this first step.
    

  

  

Jerry, one of the nice things about baby steps is that you
sometimes discover that the baby learned to take the steps
without any instruction.

Unless the IESG has changed the rules while I was not looking,
it has been permitted to post I-Ds in PDF in addition to ASCII
for some years. 



BUT the pdf is not allowed to be normative. Changing that rule alone
would 

be sufficient to allow modern graphics to be called up in normative
texts.





  
I find it interesting that it has not been taken
advantage of more often (and, for the record, I'm one of those
who has taken advantage of it).  When it has been done for
artwork purposes, the artwork in the ASCII version has sometimes
been pretty rudimentary.   In practice, whether it is "good
enough" has been made on a case by case basis by WG Chairs and
WGs or, for non-WG documents, by whether or not the relevant
people are willing to read and consider those documents.
  



Please clarify this. Are you saying that if the WG/WGchairs/ADs agree
that the non-ASCII

version should be the normative version (because they want the better
artwork), then=C2=A0 that's

OK? I thought=C2=A0 I asked this a long time ago and was told no.

=C2=A0



  
Similarly, when PDF has been posted in order to exhibit
non-ASCII characters, it has proven helpful to have Unicode
character offsets (i.e., U+nnnn representations)  in both the
ASCII and PDF forms to ensure complete precision even though the
character-glyphs themselves appear only in the PDF form. =20

So, consider the first baby step to have been taken: nothing
prevents you from posting an I-D in both ASCII and PDF today,
and the relevant sub-community will sort out, on a case by case
basis, whether the ASCII is good enough.   



...and if it's not the pdf version of the text including graphics will
become the RFC?



- Stewart




--------------060507000609040906070000--


--===============1776014194==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1776014194==--




From ietf-bounces@ietf.org Thu Jan 05 12:26:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuYt6-0003bN-2X; Thu, 05 Jan 2006 12:26:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYt1-0003ZO-CY
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 12:26:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13753
	for ; Thu, 5 Jan 2006 12:25:35 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYyh-0002vs-UN
	for ietf@ietf.org; Thu, 05 Jan 2006 12:32:46 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k05HQadJ005128; Thu, 5 Jan 2006 12:26:37 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA15519; 
	Thu, 5 Jan 2006 12:26:35 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 5 Jan 2006 12:26:34 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886263@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Brian E Carpenter'" , Harald Tveit Alvestrand
	
Date: Thu, 5 Jan 2006 12:25:23 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: ietf@ietf.org
Subject: RE: Engineering our way out of a brown paper bag [Re: Consensus b
	ased on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian,

	I think it is somewhat unfair to say that we have
not tried the steps you outline below.  Where we run into 
trouble is when different sets of people disagree as to
which of the steps we are currently working on.

	Quite frankly, I believe we can address the second
step (which of the requirements are not met today?) with 
a firm "none."

	This is - IMO - the basis for the apparent stodgy
resistance to change.

--
Eric 

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Brian E Carpenter
--> Sent: Thursday, January 05, 2006 7:36 AM
--> To: Harald Tveit Alvestrand
--> Cc: ietf@ietf.org
--> Subject: Engineering our way out of a brown paper bag [Re: 
--> Consensus based on reading tea leaves]
--> 
--> Harald Tveit Alvestrand wrote:
--> > 
--> > 
--> > --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein 
--> >  wrote:
--> > 
--> >> The only thing I am sure about is
--> >> that
--> >> consensus on this list is for keeping everything exactly 
--> as it is.
--> > 
--> > 
--> > I'm pretty sure there's no such consensus.
--> > 
--> > I do, however, see a rather strong 
--> consensus-of-the-speakers against 
--> > using MS-Word document format for anything "official".
--> 
--> I think we need to tackle this whole issue, if we do decide to
--> tackle it, in a much more systematic way.
--> 
--> - what are our functional requirements?
--> - which of them are not met today?
--> - what are the possible solutions, and what is their practical
-->    and operational cost?
--> - which, if any, solutions should we adopt, on what timescale?
--> 
--> I believe that if we took a systematic approach like that, the issue
--> of how we determine consensus would be broken into enough small
--> steps that it really wouldn't be an issue.
--> 
-->      Brian
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 12:27:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuYtv-0003kC-MM; Thu, 05 Jan 2006 12:27:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYtt-0003k7-At
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 12:27:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13854
	for ; Thu, 5 Jan 2006 12:26:29 -0500 (EST)
Received: from ms-smtp-02-smtplb.tampabay.rr.com ([65.32.5.132]
	helo=ms-smtp-02.tampabay.rr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYza-0002yf-Qs
	for ietf@ietf.org; Thu, 05 Jan 2006 12:33:40 -0500
Received: from WEIJax.com (131-37.121-70.tampabay.res.rr.com [70.121.37.131])
	by ms-smtp-02.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id
	k05HRVb6021599; Thu, 5 Jan 2006 12:27:31 -0500 (EST)
Message-ID: <43BD567D.6080106@WEIJax.com>
Date: Thu, 05 Jan 2006 12:25:17 -0500
From: Sandy Wills 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott W Brim 
References: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EV	S1.ugd.att.com>	
	<43BD4EF1.5010309@cisco.com>
In-Reply-To: <43BD4EF1.5010309@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Scott W Brim wrote:

> For heuristic value ... Do you think there is a correlation between 
> restricting ourselves to formats which are good for protocol 
> specifications but not much else, and the skew in our success record 
> toward problems solved by protocol specifications as opposed to the 
> really complex system problems? :-)

Of course.

> By the way, I like emacs picture mode.  You can bind the keypad keys 
> so that e.g. "3" means "draw toward the upper right".

This seems intuituve and easy, if your normal input device is a
telephone keypad.  Otherwise, why choose this example?

-- 
Unable to locate coffee.
Operator halted.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 12:34:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZ0q-0005Zu-2U; Thu, 05 Jan 2006 12:34:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZ0n-0005Zm-El
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 12:34:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14907
	for ; Thu, 5 Jan 2006 12:33:37 -0500 (EST)
Received: from mail126.messagelabs.com ([216.82.254.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuZ6S-0003JR-IK
	for ietf@ietf.org; Thu, 05 Jan 2006 12:40:48 -0500
X-VirusChecked: Checked
X-Env-Sender: gash@att.com
X-Msg-Ref: server-9.tower-126.messagelabs.com!1136482452!11368419!9
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 18926 invoked from network); 5 Jan 2006 17:34:38 -0000
Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4)
	by server-9.tower-126.messagelabs.com with SMTP;
	5 Jan 2006 17:34:38 -0000
Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by
	attrh3i.attrh.att.com (7.2.052)
	id 43AED14A000EA439; Thu, 5 Jan 2006 12:34:35 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 5 Jan 2006 11:34:34 -0600
Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9873@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: Baby Steps (was RE: Alternative formats for IDs)
Thread-Index: AcYSGa2rI8rJG7q0TtOZai+biWbYFQAA6iqg
From: "Ash, Gerald R \(Jerry\)" 
To: "Stewart Bryant" , "John C Klensin" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \(Jerry\)" , ietf@ietf.org
Subject: RE: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> > Unless the IESG has changed the rules while I was not looking,
> > it has been permitted to post I-Ds in PDF in addition to ASCII
> > for some years.=20

> BUT the pdf is not allowed to be normative.=20

Right.  The ASCII version is the only normative format.  Furthermore,
all diagrams, no matter how complex in the PDF version, must be
converted to ASCII stick figures in the normative ASCII version.  There
are no tools I'm aware of to aid that conversion, and in many cases much
is lost in the conversion.

> Changing that rule alone would be sufficient to allow modern
> graphics to be called up in normative texts.

Agreed.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 12:35:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZ1T-0005hE-PW; Thu, 05 Jan 2006 12:35:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZ1R-0005gN-6U
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 12:35:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14993
	for ; Thu, 5 Jan 2006 12:34:17 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EuZ79-0003Kb-Ek
	for ietf@ietf.org; Thu, 05 Jan 2006 12:41:28 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 05 Jan 2006 09:35:21 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k05HZKjt009890;
	Thu, 5 Jan 2006 09:35:21 -0800 (PST)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp4149.cisco.com [10.61.80.52])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k05Heud0020044;
	Thu, 5 Jan 2006 09:40:58 -0800
Message-ID: <43BD58D3.3070006@cisco.com>
Date: Thu, 05 Jan 2006 18:35:15 +0100
From: Eliot Lear 
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C886263@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886263@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1;  q=dns; l=1947; t=1136482859; x=1136915059;
	c=nowsp; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; 
	d=cisco.com; i=lear@cisco.com; 
	z=Subject:Re=3A=20Engineering=20our=20way=20out=20of=20a=20brown=20paper=20bag=20[
	Re=3A=20Consensus=20b=0A=20ased=20on=20reading=20tea=20leaves]|
	From:Eliot=20Lear=20|
	Date:Thu,=2005=20Jan=202006=2018=3A35=3A15=20+0100|
	Content-Type:text/plain=3B=20charset=3DISO-8859-1|
	Content-Transfer-Encoding:7bit;
	b=d1oKgiS0n4wsSO8JcH82GwSQJs1pbE91p/7brv8gRAOIGxKVv7Zk0d4hlu2r/BU1nR457PYp
	hMQtbkPLpcb29hOO2YYUO5vMO8Iw/umi7H29AwIkFZfDWICjGUHzcOk7Hd5hl/1mSqXQ81JHfog
	fvOGp8AYW/WvjlmoipWIZuJM=
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com;
	dkim=pass ( message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus b
 ased on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I agree.  As usual we seem to be stuck in an infinite loop on this
mailing list with the cycle being somewhere between 6 months and 3 years.

Eliot

Gray, Eric wrote:
> Brian,
>
> 	I think it is somewhat unfair to say that we have
> not tried the steps you outline below.  Where we run into 
> trouble is when different sets of people disagree as to
> which of the steps we are currently working on.
>
> 	Quite frankly, I believe we can address the second
> step (which of the requirements are not met today?) with 
> a firm "none."
>
> 	This is - IMO - the basis for the apparent stodgy
> resistance to change.
>
> --
> Eric 
>
> --> -----Original Message-----
> --> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
> --> On Behalf Of Brian E Carpenter
> --> Sent: Thursday, January 05, 2006 7:36 AM
> --> To: Harald Tveit Alvestrand
> --> Cc: ietf@ietf.org
> --> Subject: Engineering our way out of a brown paper bag [Re: 
> --> Consensus based on reading tea leaves]
> --> 
> --> Harald Tveit Alvestrand wrote:
> --> > 
> --> > 
> --> > --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein 
> --> >  wrote:
> --> > 
> --> >> The only thing I am sure about is
> --> >> that
> --> >> consensus on this list is for keeping everything exactly 
> --> as it is.
> --> > 
> --> > 
> --> > I'm pretty sure there's no such consensus.
> --> > 
> --> > I do, however, see a rather strong 
> --> consensus-of-the-speakers against 
> --> > using MS-Word document format for anything "official".
> --> 
> --> I think we need to tackle this whole issue, if we do decide to
> --> tackle it, in a much more systematic way.
> --> 
> --> - what are our functional requirements?
> --> - which of them are not met today?
> --> - what are the possible solutions, and what is their practical
> -->    and operational cost?
> --> - which, if any, solutions should we adopt, on what timescale?
> --> 
> --> I believe that if we took a systematic approach like that, the issue
> --> of how we determine consensus would be broken into enough small
> --> steps that it really wouldn't be an issue.
> --> 
> -->      Brian
> --> 
> --> 
> --> _______________________________________________
> --> Ietf mailing list
> --> Ietf@ietf.org
> --> https://www1.ietf.org/mailman/listinfo/ietf
> --> 
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
>   

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 12:42:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZ8I-0000kO-1Z; Thu, 05 Jan 2006 12:42:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZ8G-0000kF-BP
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 12:42:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15853
	for ; Thu, 5 Jan 2006 12:41:21 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZDz-0003hW-CE
	for ietf@ietf.org; Thu, 05 Jan 2006 12:48:31 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k05HgMdJ005774; Thu, 5 Jan 2006 12:42:22 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA19020; 
	Thu, 5 Jan 2006 12:42:20 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 5 Jan 2006 12:42:20 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886265@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Ash, Gerald R (Jerry)'" 
Date: Thu, 5 Jan 2006 12:41:54 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jerry,

	And this is a d=E9j=E0 vu over and over again as well.

	We could - in theory - allow draft versions in any
format an author chooses.  It would make quite a mess of
the draft repository and - eventually - the RFC library.

	But we need to agree on one or more versions that=20
can be (more or less) viewed by anyone, if we expect that
everyone will actually read and use them.

	I believe the current practice allows for multiple
formats, but requires that at least one is in ASCII text.
And, in cases where the document is expected to be of an
authoritative nature, the "authoritative version" is the
one in the common (ASCII text) format.

	If that were acceptable to everyone, we could stop
there, rather than taking the next "baby step" off the=20
top stair.  :-)

	However, there are a number of people who feel that
complex figures are required to understand authoritative
text in at least some cases - and this is a good argument
for making a version that contains these complex figures
authoritative.

	At this point, all agreement breaks down.  The only
way to go forward (assuming that change is part of the
definition of "going forward") is through arbitration.  I
am certain that (d=E9j=E0 vu, yet again) arbitration has been=20
tried again and again...

--
Eric=20

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]=20
--> On Behalf Of Ash, Gerald R (Jerry)
--> Sent: Thursday, January 05, 2006 9:26 AM
--> To: Yaakov Stein; ietf@ietf.org
--> Cc: Ash, Gerald R (Jerry)
--> Subject: Baby Steps (was RE: Alternative formats for IDs)
-->=20
--> Happy New Year to all!
-->=20
--> Many thanks to Yaakov for his excellent handling of the=20
--> list discussion.  I'm not very surprised with the way it=20
--> has gone.  D=E9j=E0 vu all over again :-)
-->=20
--> The challenge is to focus the discussion to try to reach=20
--> consensus on moving forward with a process change, i.e., we=20
--> need to take baby steps to make progress.
-->=20
--> I'd suggest we try to reach consensus first on the following:
--> Alternative format(s) for IDs, in addition to ASCII text,=20
--> should be allowed. =20
-->=20
--> One requirement/motivation for this change (as set forth in=20
--> the ID) is to be able to include drawings and diagrams with=20
--> something much more flexible than ASCII art.
-->=20
--> Based on the prior discussion of 'ASCII art', and the=20
--> current discussion, I see few people arguing that ASCII=20
--> text is all we need and that no other formats should ever=20
--> be allowed.
-->=20
--> Let's set aside for now which format(s), and take that as a=20
--> later step if we can take this first step.
-->=20
--> Thanks,
--> Regards,
--> Jerry=20
-->=20
--> ________________________________
-->=20
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]=20
--> On Behalf Of Yaakov Stein
--> Sent: Sunday, January 01, 2006 12:37 AM
--> To: ietf@ietf.org
--> Subject: Alternative formats for IDs
-->=20
--> Happy new year to everyone.
--> =20
--> I would like to call your attention to a new ID
--> http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt.
--> =20
--> This ID is the result of discussions here on the general list,
--> and proposes the use of formats other than plain ASCII
--> for IDs and RFCs. In particular, it proposes the allowance
--> of diagrams other than "ASCII-art" as normative.
--> =20
--> The authors felt that further discussion on the list would=20
--> not be productive,=20
--> but that the writing of an ID might force more serious=20
--> consideration.
--> We furthermore suggest that this ID be advanced as a BCP
--> under the process for process change.
--> =20
--> Y(J)S
-->=20
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 12:48:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZDq-0003eZ-BY; Thu, 05 Jan 2006 12:48:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZDn-0003eJ-81
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 12:48:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16798
	for ; Thu, 5 Jan 2006 12:47:03 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZJW-0003wi-1B
	for ietf@ietf.org; Thu, 05 Jan 2006 12:54:14 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k05HludJ005889; Thu, 5 Jan 2006 12:47:56 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20172; 
	Thu, 5 Jan 2006 12:47:52 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 5 Jan 2006 12:47:51 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886266@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'John C Klensin'" , "Ash, Gerald R \\(Jerry\\)"
	, Yaakov Stein , ietf@ietf.org
Date: Thu, 5 Jan 2006 12:46:06 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: RE: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John,

	I believe - for the record - that Post-Script is also
allowed.

--
Eric=20

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]=20
--> On Behalf Of John C Klensin
--> Sent: Thursday, January 05, 2006 11:28 AM
--> To: Ash, Gerald R \(Jerry\); Yaakov Stein; ietf@ietf.org
--> Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
-->=20
-->=20
-->=20
--> --On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
--> \\(Jerry\\)"  wrote:
-->=20
--> > Happy New Year to all!
--> >=20
--> > Many thanks to Yaakov for his excellent handling of the list
--> > discussion.  I'm not very surprised with the way it has gone.
--> > D=E9j=E0 vu all over again :-)
--> >=20
--> > The challenge is to focus the discussion to try to reach
--> > consensus on moving forward with a process change, i.e., we
--> > need to take baby steps to make progress.
--> >=20
--> > I'd suggest we try to reach consensus first on the following:
--> > Alternative format(s) for IDs, in addition to ASCII text,
--> > should be allowed. =20
--> >=20
--> > One requirement/motivation for this change (as set forth in
--> > the ID) is to be able to include drawings and diagrams with
--> > something much more flexible than ASCII art.
--> >=20
--> > Based on the prior discussion of 'ASCII art', and the current
--> > discussion, I see few people arguing that ASCII text is all we
--> > need and that no other formats should ever be allowed.
-->=20
--> Even those of us who are strongly supportive of ASCII as our
--> primary base format and those who believe that the effort needed
--> to simplify illustrations and diagrams sufficiently that they
--> can be accurately represented in ASCII artwork is helpful in
--> forcing clarity are reluctant to say "never".
-->=20
--> > Let's set aside for now which format(s), and take that as a
--> > later step if we can take this first step.
-->=20
--> Jerry, one of the nice things about baby steps is that you
--> sometimes discover that the baby learned to take the steps
--> without any instruction.
-->=20
--> Unless the IESG has changed the rules while I was not looking,
--> it has been permitted to post I-Ds in PDF in addition to ASCII
--> for some years. I find it interesting that it has not been taken
--> advantage of more often (and, for the record, I'm one of those
--> who has taken advantage of it).  When it has been done for
--> artwork purposes, the artwork in the ASCII version has sometimes
--> been pretty rudimentary.   In practice, whether it is "good
--> enough" has been made on a case by case basis by WG Chairs and
--> WGs or, for non-WG documents, by whether or not the relevant
--> people are willing to read and consider those documents.
--> Similarly, when PDF has been posted in order to exhibit
--> non-ASCII characters, it has proven helpful to have Unicode
--> character offsets (i.e., U+nnnn representations)  in both the
--> ASCII and PDF forms to ensure complete precision even though the
--> character-glyphs themselves appear only in the PDF form. =20
-->=20
--> So, consider the first baby step to have been taken: nothing
--> prevents you from posting an I-D in both ASCII and PDF today,
--> and the relevant sub-community will sort out, on a case by case
--> basis, whether the ASCII is good enough.   If you do more of it,
--> perhaps we can move some of the interoperability problems into
--> the realm of actual IETF experience and out of the realm of
--> extrapolation from other situations mixed with pure speculation.
-->=20
--> Free advice: if and when you want to move beyond that point,
--> drop (or isolate into separate documents):
-->=20
--> 	(1) Recommendations for IETF process change or specific
--> 	ways to determine consensus.  They should be separate so
--> 	they can be considered separately, using an appropriate
--> 	process.
-->=20
--> 	(2) Distinguish clearly between what is required or
--> 	tolerable for I-Ds and what is required or tolerable for
--> 	RFCs.  RFCs, in general, put a less strong requirement
--> 	on easy extraction and modification of text than I-Ds.
--> 	And, since I-Ds in theory expire after six months, you
--> 	might be able to convince the community that the "be
--> 	sure it can be read twenty years later" requirement for
--> 	archival documents should not be taken as seriously for
--> 	I-Ds.
--> =09
--> 	(3) Recommendations to permit any format that is (i)
--> 	proprietary, or (ii) dependent on particular software
--> 	for processing where that software carries either high
--> 	costs, onerous licensing requirements,  or licensing
--> 	requirement that attempt to prohibit the development of
--> 	independent tools to work with the format, or (iii)
--> 	significantly operating-system dependent, or (iv)
--> 	significantly version-dependent in the sense that the
--> 	documents are not forward and backward compatible.
-->=20
--> I would suggest to you that the fact that Word hits a jackpot by
--> satisfying all of the negative criteria in that third suggestion
--> is the reason why it has been regularly rejected for IETF
--> posting and working use in the past and is almost certain to be
--> rejected in the future.  If you want to consider that d=E9j=E0 vu
--> (or deja vu, for ASCII-readers), it certainly is in the sense
--> that we have been here before... but that rather misses the
--> point: it has been rejected in the past for substantial and
--> substantive reasons and the d=E9j=E0 vu situation, for me at
--> least, is that someone decides to bring it up again every few
--> years as if it had never been considered in the past.
-->=20
--> regards,
-->     john
-->=20
-->=20
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 12:50:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZG6-00047Z-Kt; Thu, 05 Jan 2006 12:50:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZG4-00047E-3A
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 12:50:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17099
	for ; Thu, 5 Jan 2006 12:49:24 -0500 (EST)
Received: from ms-smtp-03-smtplb.tampabay.rr.com ([65.32.5.133]
	helo=ms-smtp-03.tampabay.rr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZLm-00041T-8s
	for ietf@ietf.org; Thu, 05 Jan 2006 12:56:35 -0500
Received: from WEIJax.com (131-37.121-70.tampabay.res.rr.com [70.121.37.131])
	by ms-smtp-03.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id
	k05HoSGK013060; Thu, 5 Jan 2006 12:50:29 -0500 (EST)
Message-ID: <43BD5BDE.4070905@WEIJax.com>
Date: Thu, 05 Jan 2006 12:48:14 -0500
From: Sandy Wills 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Gray, Eric wrote:

> "It is much more likely to hear from the very vocal people who are 
>  opposed to the change. That is, assuming 1000s of participants 
>  on the IETF discussion list, perhaps 20 expressed 'nays', even 
>  strong nays, could be considered a clear consensus in favor of 
>  change."

While I can't speak for everyone else, this seems correct to me.  "Do I 
have anything useful or enteresting to add?" and "Do I think that my 
input will change the output?" must both evaluate to "Yes" before I post 
to any discussion.  I occasionally post for humor or interest, but 
generally I follow the discussion and stay out of it unless I believe it 
to be going badly awry.

   To be blunt, do we want every question to be answered by several 
thousand AOL "Me too"'s?  The silent masses are silent because they 
don't have anything useful to add, and believe that an endless stream of 
agreements would do nothing useful except test our bandwidth.

   We do, on the other hand, chime in when necessary.  So, it is "good" 
and "right" and "fair" to assume that a public question with a default 
answer has concensus, if the only response is a minor negative one.  I, 
and I believe many others, will simply move on to the next post when we 
see the question, if we agree with the default answer.

   A simple mental experiment: If we have, say, 2000 readers, and we 
post the question

   "Will the sun rise tomorrow?  We think yes."

  then we can expect a small number of disagreements, a small number of 
arguments from readers who didn't understand the question, a small 
number of AOL's, a small number of "Of course, you twit!  Why are you 
wasting our time with this?" and nothing else.  The vast majority of the 
readers will not reply, because they agree with the default answer, and 
they have other things to do.
   If there is a reader who disagrees in his mind, but is constrained by 
cultural conditioning or natural manners from speaking out, how are we 
supposed to coax his "better way" from this reader?  We have already 
posited that he/she/it won't speak up.
   I submit that the IETF culture should, by policy, assume that anyone 
subscribed to an IETF list will speak out on any question if he/she/it 
thinks it right.

>     The current process requires weighing of voices, not weighing
> of the supposed opinions of the silent.

Yes, _but_ anyone who agrees will not argue.  You will only get argument 
from those who disagree with the post.  Unless you want to change the 
culture here to require an answer from every reader, on every question, 
thus adding significantly to our daily workload.  I'd rather not.

-- 
Unable to locate coffee.
Operator halted.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 13:16:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZf3-0005zK-DV; Thu, 05 Jan 2006 13:16:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZf0-0005yu-1i
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 13:16:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21584
	for ; Thu, 5 Jan 2006 13:15:10 -0500 (EST)
Received: from handynerds.com ([207.234.208.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZke-0004xh-3V
	for ietf@ietf.org; Thu, 05 Jan 2006 13:22:21 -0500
Received: from apache by HandyNerds.com with local (Exim 4.41)
	id 1EuZez-00005L-Gd
	for ietf@ietf.org; Thu, 05 Jan 2006 13:16:25 -0500
Received: from motive.ravenwing.com ([66.100.85.194])
	(SquirrelMail authenticated user bthorson);
	by www.handynerds.com with HTTP; Thu, 5 Jan 2006 13:16:25 -0500 (EST)
Message-ID: <52422.66.100.85.194.1136484985.squirrel@66.100.85.194>
In-Reply-To: <43BD58D3.3070006@cisco.com>
References: <43BD58D3.3070006@cisco.com>
Date: Thu, 5 Jan 2006 13:16:25 -0500 (EST)
From: "Brett Thorson" 
To: ietf@ietf.org
User-Agent: SquirrelMail/1.4.3a-0.f1.1
X-Mailer: SquirrelMail/1.4.3a-0.f1.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Content-Transfer-Encoding: 8bit
Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus b 
 ased on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@handynerds.com
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I wonder if that time frame represents the amount of critical mass
turnover for these topics to be refreshed, but previous discussion
forgotten.

I don't know if there is something that would fulfill this roll, but from
40 feet back, here is a suggestion.

A bulletin board (Not BBS, but like an old cork one).

Take what Brian said, that we need to look at this in sections.  True.
Take what Eric said, we are doing that, but different people at different
times at different sections.  True.

Wouldn't it be nice to compartmentalize some of these systematic
functions, but still keep them as neighbors so that if someone wants to
talk about _requirements_, you step over and look at that section, and all
the notes that people have stuck to the board.  If someone wants to look
at _solutions_ they look there.  If they just want an overview, they
glance at the whole thing.

If people think an idea is not great, it gets stuck to the bottom, if it
is well liked by many, then it bubbles up to the top (allowing many to
bubble up or down).  The reasons could be discussed on the list, but the
result might end up on the board.

What is nice is that if we just shrug our shoulders and walk away from it,
we can come back to it in .5-3 years time and look back at this simple
"cork board" rather than spilling through mounds of mail archives.

I think (after watching the IETF for a while) that a fair amount of time
is spent rehashing good ideas (and bad ones).  Maybe a "cork board" that a
newcomer could come up to, see the note, see the notes about the note
would be useful.  (Think persistance of knowledge in the new-comers
orientation information presented at each IETF).

Again, I'm just tossing this out there as a brainstorm idea.  I think the
problem (ID-Format) is real.  I think it is solvable.  I think we have too
many great brains jumping around the systematic process of solving it,
thus spending time on thought swapping and bringing newcomers up to speed.

In other words, an e-mail list might not be the best way to solve the
problem, and an e-mail archive might not be the best way to keep the
summary knowledge around and accessible for newcomers to the task.

--Brett

> I agree.  As usual we seem to be stuck in an infinite loop on this
> mailing list with the cycle being somewhere between 6 months and 3 years.
>
> Eliot
>
> Gray, Eric wrote:
>> Brian,
>>
>> 	I think it is somewhat unfair to say that we have
>> not tried the steps you outline below.  Where we run into
>> trouble is when different sets of people disagree as to
>> which of the steps we are currently working on.
>>
>> 	Quite frankly, I believe we can address the second
>> step (which of the requirements are not met today?) with
>> a firm "none."
>>
>> 	This is - IMO - the basis for the apparent stodgy
>> resistance to change.
>>
>> --
>> Eric
>>
>> --> -----Original Message-----
>> --> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]
>> --> On Behalf Of Brian E Carpenter
>> --> Sent: Thursday, January 05, 2006 7:36 AM
>> --> To: Harald Tveit Alvestrand
>> --> Cc: ietf@ietf.org
>> --> Subject: Engineering our way out of a brown paper bag [Re:
>> --> Consensus based on reading tea leaves]
>> -->
>> --> Harald Tveit Alvestrand wrote:
>> --> >
>> --> >
>> --> > --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein
>> --> >  wrote:
>> --> >
>> --> >> The only thing I am sure about is
>> --> >> that
>> --> >> consensus on this list is for keeping everything exactly
>> --> as it is.
>> --> >
>> --> >
>> --> > I'm pretty sure there's no such consensus.
>> --> >
>> --> > I do, however, see a rather strong
>> --> consensus-of-the-speakers against
>> --> > using MS-Word document format for anything "official".
>> -->
>> --> I think we need to tackle this whole issue, if we do decide to
>> --> tackle it, in a much more systematic way.
>> -->
>> --> - what are our functional requirements?
>> --> - which of them are not met today?
>> --> - what are the possible solutions, and what is their practical
>> -->    and operational cost?
>> --> - which, if any, solutions should we adopt, on what timescale?
>> -->
>> --> I believe that if we took a systematic approach like that, the issue
>> --> of how we determine consensus would be broken into enough small
>> --> steps that it really wouldn't be an issue.
>> -->
>> -->      Brian
>> -->
>> -->
>> --> _______________________________________________
>> --> Ietf mailing list
>> --> Ietf@ietf.org
>> --> https://www1.ietf.org/mailman/listinfo/ietf
>> -->
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>>
>>
>
>
>


-- 
Please note that my e-mail address has changed.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 13:19:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZiF-0007JN-In; Thu, 05 Jan 2006 13:19:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZiA-0007Co-Lh
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 13:19:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22213
	for ; Thu, 5 Jan 2006 13:18:26 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZns-000568-HF
	for ietf@ietf.org; Thu, 05 Jan 2006 13:25:38 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 05 Jan 2006 19:19:30 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k05IJQFZ006723; 
	Thu, 5 Jan 2006 19:19:27 +0100 (MET)
Received: from [64.103.64.233] (dhcp-rea-gp250-64-103-64-233.cisco.com
	[64.103.64.233])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA25919;
	Thu, 5 Jan 2006 18:19:24 GMT
Message-ID: <43BD632C.20103@cisco.com>
Date: Thu, 05 Jan 2006 18:19:24 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C886263@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886263@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus b
 ased on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Gray, Eric wrote:

>Brian,
>
>	I think it is somewhat unfair to say that we have
>not tried the steps you outline below.  Where we run into 
>trouble is when different sets of people disagree as to
>which of the steps we are currently working on.
>
>	Quite frankly, I believe we can address the second
>step (which of the requirements are not met today?) with 
>a firm "none."
>  
>

That is not true, we don't address the need to include diagrams.

- Stewart.

>	This is - IMO - the basis for the apparent stodgy
>resistance to change.
>
>--
>Eric 
>
>--> -----Original Message-----
>--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
>--> On Behalf Of Brian E Carpenter
>--> Sent: Thursday, January 05, 2006 7:36 AM
>--> To: Harald Tveit Alvestrand
>--> Cc: ietf@ietf.org
>--> Subject: Engineering our way out of a brown paper bag [Re: 
>--> Consensus based on reading tea leaves]
>--> 
>--> Harald Tveit Alvestrand wrote:
>--> > 
>--> > 
>--> > --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein 
>--> >  wrote:
>--> > 
>--> >> The only thing I am sure about is
>--> >> that
>--> >> consensus on this list is for keeping everything exactly 
>--> as it is.
>--> > 
>--> > 
>--> > I'm pretty sure there's no such consensus.
>--> > 
>--> > I do, however, see a rather strong 
>--> consensus-of-the-speakers against 
>--> > using MS-Word document format for anything "official".
>--> 
>--> I think we need to tackle this whole issue, if we do decide to
>--> tackle it, in a much more systematic way.
>--> 
>--> - what are our functional requirements?
>--> - which of them are not met today?
>--> - what are the possible solutions, and what is their practical
>-->    and operational cost?
>--> - which, if any, solutions should we adopt, on what timescale?
>--> 
>--> I believe that if we took a systematic approach like that, the issue
>--> of how we determine consensus would be broken into enough small
>--> steps that it really wouldn't be an issue.
>--> 
>-->      Brian
>--> 
>--> 
>--> _______________________________________________
>--> Ietf mailing list
>--> Ietf@ietf.org
>--> https://www1.ietf.org/mailman/listinfo/ietf
>--> 
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>
>
>  
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 13:20:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZiS-0007Ti-G6; Thu, 05 Jan 2006 13:20:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZiQ-0007Ta-6k
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 13:19:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22242
	for ; Thu, 5 Jan 2006 13:18:42 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZo4-00056a-Jz
	for ietf@ietf.org; Thu, 05 Jan 2006 13:25:54 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k05IJbdJ006827; Thu, 5 Jan 2006 13:19:38 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA24673; 
	Thu, 5 Jan 2006 13:19:37 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 5 Jan 2006 13:19:36 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886267@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Stewart Bryant'" , John C Klensin 
Date: Thu, 5 Jan 2006 13:17:45 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \\\(Jerry\\\)" , ietf@ietf.org
Subject: RE: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart,
=20
    You bring up a good point.  I have been assuming that - since=20
IDs can be submitted in multiple formats - that the additional
formats would also become part of the RFC library on publication.
=20
    I just took a quick peek at the RFCs and there does not appear=20
to be a single example of a version that is not in text format.  I=20
don't know if that is because they are not stored in the same place,=20
or they are not carried forward as part of the publishing process.
=20
    Frankly, if the process of getting an ID published as an RFC=20
seems to require (or at least encourage) use of at least one=20
additional format, then the additional format(s) should also be=20
incorporated in the RFC library.  In other words, if there was a=20
non-ASCII version of the ID, there should also be a non-ASCII=20
version of the RFC.
=20
    For some reason I thought this at least used to be the case. =20
If it is not, then that should be fixed - for exactly the reasons=20
you point out.
=20
    Irrespective of questions about the "legitimacy" of using a=20
non-ASCII version as normative or authoritative, the fact that a=20
non-ASCII version might contain useful explanatory material is=20
more than sufficient cause to keep it.
=20
--
Eric


________________________________

	From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
Of Stewart Bryant
	Sent: Thursday, January 05, 2006 12:01 PM
	To: John C Klensin
	Cc: Ash, Gerald R \(Jerry\); ietf@ietf.org
	Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
=09
=09
	John C Klensin wrote:
=09

		--On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
		\\(Jerry\\)"    wrote:
	=09
		 =20

			Happy New Year to all!
		=09
			Many thanks to Yaakov for his excellent handling of
the list
			discussion.  I'm not very surprised with the way it
has gone.
			D=E9j=E0 vu all over again :-)
		=09
			The challenge is to focus the discussion to try to
reach
			consensus on moving forward with a process change,
i.e., we
			need to take baby steps to make progress.
		=09
			I'd suggest we try to reach consensus first on the
following:
			Alternative format(s) for IDs, in addition to ASCII
text,
			should be allowed. =20
		=09
			One requirement/motivation for this change (as set
forth in
			the ID) is to be able to include drawings and
diagrams with
			something much more flexible than ASCII art.
		=09
			Based on the prior discussion of 'ASCII art', and
the current
			discussion, I see few people arguing that ASCII text
is all we
			need and that no other formats should ever be
allowed.
			   =20

	=09
		Even those of us who are strongly supportive of ASCII as our
		primary base format and those who believe that the effort
needed
		to simplify illustrations and diagrams sufficiently that
they
		can be accurately represented in ASCII artwork is helpful in
		forcing clarity are reluctant to say "never".
	=09
		 =20

			Let's set aside for now which format(s), and take
that as a
			later step if we can take this first step.
			   =20

	=09
		Jerry, one of the nice things about baby steps is that you
		sometimes discover that the baby learned to take the steps
		without any instruction.
	=09
		Unless the IESG has changed the rules while I was not
looking,
		it has been permitted to post I-Ds in PDF in addition to
ASCII
		for some years.=20

	BUT the pdf is not allowed to be normative. Changing that rule alone
would=20
	be sufficient to allow modern graphics to be called up in normative
texts.
=09
=09

		I find it interesting that it has not been taken
		advantage of more often (and, for the record, I'm one of
those
		who has taken advantage of it).  When it has been done for
		artwork purposes, the artwork in the ASCII version has
sometimes
		been pretty rudimentary.   In practice, whether it is "good
		enough" has been made on a case by case basis by WG Chairs
and
		WGs or, for non-WG documents, by whether or not the relevant
		people are willing to read and consider those documents.
		 =20

	Please clarify this. Are you saying that if the WG/WGchairs/ADs
agree that the non-ASCII
	version should be the normative version (because they want the
better artwork), then  that's
	OK? I thought  I asked this a long time ago and was told no.
	=20
=09

		Similarly, when PDF has been posted in order to exhibit
		non-ASCII characters, it has proven helpful to have Unicode
		character offsets (i.e., U+nnnn representations)  in both
the
		ASCII and PDF forms to ensure complete precision even though
the
		character-glyphs themselves appear only in the PDF form. =20
	=09
		So, consider the first baby step to have been taken: nothing
		prevents you from posting an I-D in both ASCII and PDF
today,
		and the relevant sub-community will sort out, on a case by
case
		basis, whether the ASCII is good enough.  =20

	...and if it's not the pdf version of the text including graphics
will become the RFC?
=09
	- Stewart
=09


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 13:21:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZk3-0008BP-QE; Thu, 05 Jan 2006 13:21:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZk1-0008Ao-6D
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 13:21:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22555
	for ; Thu, 5 Jan 2006 13:20:21 -0500 (EST)
Received: from sokol.elan.net ([216.151.192.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZpi-0005Az-VC
	for ietf@ietf.org; Thu, 05 Jan 2006 13:27:32 -0500
Received: from sokol.elan.net (sokol [127.0.0.1])
	by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k05ILC82015667;
	Thu, 5 Jan 2006 10:21:12 -0800
Received: from localhost (william@localhost)
	by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k05ILB9T015664; 
	Thu, 5 Jan 2006 10:21:12 -0800
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Thu, 5 Jan 2006 10:21:11 -0800 (PST)
From: "william(at)elan.net" 
To: Scott Kitterman 
In-Reply-To: <200601050816.24487.scott@kitterman.com>
Message-ID: 
References: <313680C9A886D511A06000204840E1CF0C886254@whq-msgusr-02.pit.comms.marconi.com>
	<20060104203609.GB1459@nic.fr> <43BC47B7.9070404@gmx.de>
	<200601050816.24487.scott@kitterman.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Thu, 5 Jan 2006, Scott Kitterman wrote:

> As I understand it, one of the major concerns of the people pushing for
> alternative formats is a desire to be able to include drawings and diagrams
> with something other than ASCII art.
>
> I don't believe that XML does much to help that.

It does in the same way HTML does i.e. you can create separate drawing
as jpg or png and include it in the document along with information as
to how it would fit in that document. That means that if we use XML as
publication or submission format, then data submitted for one draft/rfc
can be more then just document itself (probably some rfc editor tools
would need to be modified to take care of managing this too).

In general it is a good idea to keep just document (i.e. it includes
embedded pictures) for at least publication as official standard so
I believe most appropriate is indeed to support PDF/A as official
publication format but keep the source (XML & pictures) available for
those who need it as well.

> If one is worried about things like including pictures, diagrams, revision
> marks, etc. then I think looking into something like Open Document Format
> would make a lot more sense than considering a proprietary format like MS
> Word.

You probably missed it, but I did in fact say in my earlier post that if
we do want to consider direct "editor" format,then only good choice would 
be opendoc. The problem is that it is still relatively new and not enough
programs and tools are available that support it on all platforms (but it
is already supported in more systems then MS Word can!). That will surely 
change in the next few years if the format proves itself.

Ultimately what I believe will happen is that there would be free (and
commercial) tools to convert from MSWord XML (if that format stabilizes) 
to OpenDoc and back without any loss (at least as far as document text
and its presentation) and so this means that those who want to use Word 
will be able to do it easily.

-- 
William Leibzon
Elan Networks
william@elan.net

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 13:21:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZkF-0008FW-OF; Thu, 05 Jan 2006 13:21:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZkC-0008F9-Nj
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 13:21:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22581
	for ; Thu, 5 Jan 2006 13:20:33 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZpv-0005CH-GB
	for ietf@ietf.org; Thu, 05 Jan 2006 13:27:44 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 05 Jan 2006 19:21:38 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k05ILZFZ007060; 
	Thu, 5 Jan 2006 19:21:35 +0100 (MET)
Received: from [64.103.64.233] (dhcp-rea-gp250-64-103-64-233.cisco.com
	[64.103.64.233])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA26261;
	Thu, 5 Jan 2006 18:21:34 GMT
Message-ID: <43BD63AE.2080501@cisco.com>
Date: Thu, 05 Jan 2006 18:21:34 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eliot Lear 
References: <313680C9A886D511A06000204840E1CF0C886263@whq-msgusr-02.pit.comms.marconi.com>
	<43BD58D3.3070006@cisco.com>
In-Reply-To: <43BD58D3.3070006@cisco.com>
X-Spam-Score: 1.0 (+)
X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665
Cc: ietf@ietf.org, Harald Tveit Alvestrand 
Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus b
 ased on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0573405397=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0573405397==
Content-Type: multipart/alternative;
	boundary="------------030905000701070302020604"

This is a multi-part message in MIME format.
--------------030905000701070302020604
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Eliot Lear wrote:

>I agree.  As usual we seem to be stuck in an infinite loop on this
>mailing list with the cycle being somewhere between 6 months and 3 years.
>
>  
>
The fact that we keep coming back to this topic may be a message in itself!

- Stewart

>Eliot
>
>Gray, Eric wrote:
>  
>
>>Brian,
>>
>>	I think it is somewhat unfair to say that we have
>>not tried the steps you outline below.  Where we run into 
>>trouble is when different sets of people disagree as to
>>which of the steps we are currently working on.
>>
>>	Quite frankly, I believe we can address the second
>>step (which of the requirements are not met today?) with 
>>a firm "none."
>>
>>	This is - IMO - the basis for the apparent stodgy
>>resistance to change.
>>
>>--
>>Eric 
>>
>>--> -----Original Message-----
>>--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
>>--> On Behalf Of Brian E Carpenter
>>--> Sent: Thursday, January 05, 2006 7:36 AM
>>--> To: Harald Tveit Alvestrand
>>--> Cc: ietf@ietf.org
>>--> Subject: Engineering our way out of a brown paper bag [Re: 
>>--> Consensus based on reading tea leaves]
>>--> 
>>--> Harald Tveit Alvestrand wrote:
>>--> > 
>>--> > 
>>--> > --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein 
>>--> >  wrote:
>>--> > 
>>--> >> The only thing I am sure about is
>>--> >> that
>>--> >> consensus on this list is for keeping everything exactly 
>>--> as it is.
>>--> > 
>>--> > 
>>--> > I'm pretty sure there's no such consensus.
>>--> > 
>>--> > I do, however, see a rather strong 
>>--> consensus-of-the-speakers against 
>>--> > using MS-Word document format for anything "official".
>>--> 
>>--> I think we need to tackle this whole issue, if we do decide to
>>--> tackle it, in a much more systematic way.
>>--> 
>>--> - what are our functional requirements?
>>--> - which of them are not met today?
>>--> - what are the possible solutions, and what is their practical
>>-->    and operational cost?
>>--> - which, if any, solutions should we adopt, on what timescale?
>>--> 
>>--> I believe that if we took a systematic approach like that, the issue
>>--> of how we determine consensus would be broken into enough small
>>--> steps that it really wouldn't be an issue.
>>--> 
>>-->      Brian
>>--> 
>>--> 
>>--> _______________________________________________
>>--> Ietf mailing list
>>--> Ietf@ietf.org
>>--> https://www1.ietf.org/mailman/listinfo/ietf
>>--> 
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf
>>
>>  
>>    
>>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>
>
>  
>


--------------030905000701070302020604
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Eliot Lear wrote:



  
I agree.  As usual we seem to be stuck in an infinite loop on this
mailing list with the cycle being somewhere between 6 months and 3 years.

  



The fact that we keep coming back to this topic may be a message in
itself!



- Stewart



  
Eliot

Gray, Eric wrote:
  

  

    
Brian,

	I think it is somewhat unfair to say that we have
not tried the steps you outline below.  Where we run into 
trouble is when different sets of people disagree as to
which of the steps we are currently working on.

	Quite frankly, I believe we can address the second
step (which of the requirements are not met today?) with 
a firm "none."

	This is - IMO - the basis for the apparent stodgy
resistance to change.

--
Eric 

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Brian E Carpenter
--> Sent: Thursday, January 05, 2006 7:36 AM
--> To: Harald Tveit Alvestrand
--> Cc: ietf@ietf.org
--> Subject: Engineering our way out of a brown paper bag [Re: 
--> Consensus based on reading tea leaves]
--> 
--> Harald Tveit Alvestrand wrote:
--> > 
--> > 
--> > --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein 
--> > <yaakov_s@rad.com> wrote:
--> > 
--> >> The only thing I am sure about is
--> >> that
--> >> consensus on this list is for keeping everything exactly 
--> as it is.
--> > 
--> > 
--> > I'm pretty sure there's no such consensus.
--> > 
--> > I do, however, see a rather strong 
--> consensus-of-the-speakers against 
--> > using MS-Word document format for anything "official".
--> 
--> I think we need to tackle this whole issue, if we do decide to
--> tackle it, in a much more systematic way.
--> 
--> - what are our functional requirements?
--> - which of them are not met today?
--> - what are the possible solutions, and what is their practical
-->    and operational cost?
--> - which, if any, solutions should we adopt, on what timescale?
--> 
--> I believe that if we took a systematic approach like that, the issue
--> of how we determine consensus would be broken into enough small
--> steps that it really wouldn't be an issue.
--> 
-->      Brian
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

  
    

  

  

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


  








--------------030905000701070302020604--


--===============0573405397==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0573405397==--




From ietf-bounces@ietf.org Thu Jan 05 13:34:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuZwV-0004Py-Az; Thu, 05 Jan 2006 13:34:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZwT-0004N3-40
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 13:34:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23892
	for ; Thu, 5 Jan 2006 13:33:12 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Eua2A-0005gG-MZ
	for ietf@ietf.org; Thu, 05 Jan 2006 13:40:23 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-2.cisco.com with ESMTP; 05 Jan 2006 10:34:15 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k05IYEjt022304;
	Thu, 5 Jan 2006 10:34:14 -0800 (PST)
Received: from [212.254.247.3] (ams-clip-vpn-dhcp4149.cisco.com [10.61.80.52])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k05Idppi020671;
	Thu, 5 Jan 2006 10:39:52 -0800
Message-ID: <43BD66A3.8020500@cisco.com>
Date: Thu, 05 Jan 2006 19:34:11 +0100
From: Eliot Lear 
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Stewart Bryant 
References: <313680C9A886D511A06000204840E1CF0C886263@whq-msgusr-02.pit.comms.marconi.com>
	<43BD58D3.3070006@cisco.com> <43BD63AE.2080501@cisco.com>
In-Reply-To: <43BD63AE.2080501@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1;  q=dns; l=397; t=1136486393; x=1136918593;
	c=nowsp; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; 
	d=cisco.com; i=lear@cisco.com; 
	z=Subject:Re=3A=20Engineering=20our=20way=20out=20of=20a=20brown=20paper=20bag=20[
	Re=3A=20Consensus=20b=0A=20ased=20on=20reading=20tea=20leaves]|
	From:Eliot=20Lear=20|
	Date:Thu,=2005=20Jan=202006=2019=3A34=3A11=20+0100|
	Content-Type:text/plain=3B=20charset=3DISO-8859-1|
	Content-Transfer-Encoding:7bit;
	b=hNrkyt6T9Yynuml/2YknwnAwGIIGqMU43W32lBp2Ag1iPiF0IqmOw6cXdmAqrz94nO4h5vSm
	x2XM0LZYWHIOE/nCHAKaljrM85R7vZRPTVRtvg2DuWUe0BWIS6PvFBq4asV1ozMaY4KQGazxpm4
	9IYfZQ+AE/yDcUdAcI3L1Oe4=
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com;
	dkim=pass ( message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, Harald Tveit Alvestrand 
Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus b
 ased on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart Bryant wrote:
> Eliot Lear wrote:
>> I agree.  As usual we seem to be stuck in an infinite loop on this
>> mailing list with the cycle being somewhere between 6 months and 3 years.
>>
>>   
> The fact that we keep coming back to this topic may be a message in
> itself!
>
It reminds me of a "pick your favorite" special interest lobby who
continually wants change, even if the rest of us don't.  Either
eventually we get convinced or we don't, but in the process we sure get
an earful.

Eliot

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 13:46:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eua8B-0003ef-Ok; Thu, 05 Jan 2006 13:46:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eua89-0003e9-S9
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 13:46:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25302
	for ; Thu, 5 Jan 2006 13:45:17 -0500 (EST)
Received: from biscayne-one-station.mit.edu ([18.7.7.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaDs-00069m-Cw
	for ietf@ietf.org; Thu, 05 Jan 2006 13:52:29 -0500
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id
	k05IkULB005066; Thu, 5 Jan 2006 13:46:30 -0500 (EST)
Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160])
	(authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k05IkMMP008879
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Thu, 5 Jan 2006 13:46:23 -0500 (EST)
In-Reply-To: <43BD4E21.4050208@cisco.com>
References: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EVS1.ugd.att.com>
	<2C5717A8-6C92-481A-9FEC-CEA433CA9D9D@mit.edu>
	<43BD4E21.4050208@cisco.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6D25B9A1-06EA-4A63-978E-14C55C9A91DD@mit.edu>
From: Ken Raeburn 
Date: Thu, 5 Jan 2006 13:46:20 -0500
To: IETF General Discussion Mailing List 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jan 5, 2006, at 11:49, Stewart Bryant wrote:
> Ken Raeburn wrote:
>> Personally, I'm skeptical that we'll find an alternative that  
>> meets  our requirements as well, but perhaps we'll wind up with  
>> plain UTF-8  text or something.
>>
> How would I encode graphics in UTF-8?

Same as you do in ASCII now (i.e., poorly), but you get a few more  
characters to choose from. :-)

Ken


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 13:50:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuaCI-0004VF-Me; Thu, 05 Jan 2006 13:50:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaCG-0004V9-RN
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 13:50:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25817
	for ; Thu, 5 Jan 2006 13:49:33 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaHz-0006IL-Q9
	for ietf@ietf.org; Thu, 05 Jan 2006 13:56:45 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EuaC8-000ADr-71; Thu, 05 Jan 2006 13:50:40 -0500
Date: Thu, 05 Jan 2006 13:50:39 -0500
From: John C Klensin 
To: "Gray, Eric" 
Message-ID: <4731D3AE25EB8EFDD5F3D838@p3.JCK.COM>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886267@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF0C886267@whq-msgusr-
	02.pit.comms.marconi.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Thursday, 05 January, 2006 13:17 -0500 "Gray, Eric"
 wrote:

> Stewart,
>  
>     You bring up a good point.  I have been assuming that -
> since  IDs can be submitted in multiple formats - that the
> additional formats would also become part of the RFC library
> on publication.  
>     I just took a quick peek at the RFCs and there does not
> appear  to be a single example of a version that is not in
> text format.  I  don't know if that is because they are not
> stored in the same place,  or they are not carried forward as
> part of the publishing process. 
>...

The number is not huge, but some RFCs have, in fact, been
published formally in PS and/or PDF as well as in ASCII (and I'm
on the hook for another one... something else in a too-long
queue).   See RFC 3550 and 3551 for recent standards-track
examples and RFC 1119 for an a Full Standard example that is
legendary in some parts of the community for incomprehensibility
if one has only the ASCII text and diagrams.

     john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 13:58:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuaKA-0006kl-Gq; Thu, 05 Jan 2006 13:58:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaK8-0006k7-3l
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 13:58:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26883
	for ; Thu, 5 Jan 2006 13:57:40 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaPr-0006hH-1s
	for ietf@ietf.org; Thu, 05 Jan 2006 14:04:52 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EuaK0-000AEt-5W; Thu, 05 Jan 2006 13:58:48 -0500
Date: Thu, 05 Jan 2006 13:58:47 -0500
From: John C Klensin 
To: "Gray, Eric" ,
	"Ash, Gerald R \\\\(Jerry\\\\)" ,
	Yaakov Stein , ietf@ietf.org
Message-ID: <266A4D6A4BC4722364791F3A@p3.JCK.COM>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886266@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF0C886266@whq-msgusr-
	02.pit.comms.marconi.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Permitting PDF and Postscript (was: RE: Baby Steps (was
 RE: Alternative formats for IDs))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Thursday, 05 January, 2006 12:46 -0500 "Gray, Eric"
 wrote:

> John,
> 
> 	I believe - for the record - that Post-Script is also
> allowed.

It is indeed.  And it, as well as PDF, are allowed in RFCs (see
earlier note).

As others have noted, an ASCII form is still required.  I
consider that a feature and, for various worst cases,
futureproofing, but some others do not.

And, as yet others have noted, it would be wise for us to get
very specific about versioning and permitted feature-sets for
PDF.  It is arguably even more important to get specific about
versions and feature sets for PS although my own personal
opinion is that, given PDF, Postscript has about outlived its
usefulness as a separate posting format.  YMMD, of course, and
this thread on the IETF list is probably not the optimal way to
address that question in any event.

    john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 14:31:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuapZ-0007Xv-9J; Thu, 05 Jan 2006 14:31:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuapX-0007Wh-4c
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 14:31:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01445
	for ; Thu, 5 Jan 2006 14:30:07 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuavG-00083t-5b
	for ietf@ietf.org; Thu, 05 Jan 2006 14:37:19 -0500
Received: (qmail 16049 invoked by uid 100); 5 Jan 2006 19:31:06 -0000
Date: 5 Jan 2006 19:31:06 -0000
Message-ID: <20060105193106.16048.qmail@xuxa.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886263@whq-msgusr-02.pit.comms.marconi.com>
Organization: I.E.C.C., Trumansburg NY USA
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus b
	ased on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> 	Quite frankly, I believe we can address the second step (which
> of the requirements are not met today?) with a firm "none."

At some level that's clearly true, since RFCs are emerging at a brisk
clip.

I've seen two different sets of concerns.

One is that ASCII doesn't permit adequately beautiful pictures.  If
that's the problem to be solved, it seems to me that a straightforward
solution would be to allow authors to submit image files along with
the ASCII text.  I'd suggest requiring that the image format be GIF,
since it's simple, stable, well documented, widely supported in both
freeware and commercial software, and the patents have expired.  (Or
maybe PNG, any stable public format will do.)

The other is that the editorial process is more tedious than it needs
to be, because RFCs have a mandatory structure that plain ASCII
doesn't express.  RFC 2629 or 2629bis captures the structure while
being well supported in free and commercial software and, in a pinch,
legible without tools since it's ASCII underneath.

This confirms to me that what we need to decide is what the problem
is, since the solutions to each problem are straighforward.

R's,
John

PS: I gather that clay is quite stable if properly fired, and is
probably less subject to chipping and acid rain pitting than marble.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 14:44:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eub2I-0005Y3-HT; Thu, 05 Jan 2006 14:44:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eub2G-0005VH-FR
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 14:44:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02939
	for ; Thu, 5 Jan 2006 14:43:16 -0500 (EST)
Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net
	([65.67.187.82] helo=defiant.dfw.nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eub7z-0000A0-C0
	for ietf@ietf.org; Thu, 05 Jan 2006 14:50:28 -0500
Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1])
	by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id k05JcX924643;
	Thu, 5 Jan 2006 13:38:33 -0600
Message-ID: <017d01c6122f$9d601340$640016ac@ssprunk>
From: "Stephen Sprunk" 
To: "Sandy Wills" , "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>
	<43BD5BDE.4070905@WEIJax.com>
Date: Thu, 5 Jan 2006 13:38:33 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Thus spake "Sandy Wills" 
> Gray, Eric wrote:
>> "It is much more likely to hear from the very vocal people who are 
>> opposed to the change. That is, assuming 1000s of participants on the 
>> IETF discussion list, perhaps 20 expressed 'nays', even strong nays, 
>> could be considered a clear consensus in favor of change."
>
> While I can't speak for everyone else, this seems correct to me.  "Do I 
> have anything useful or enteresting to add?" and "Do I think that my input 
> will change the output?" must both evaluate to "Yes" before I post to any 
> discussion.  I occasionally post for humor or interest, but generally I 
> follow the discussion and stay out of it unless I believe it to be going 
> badly awry.

I think this thread long ago passed into "badly awry", hence the volume of 
responses.

>>     The current process requires weighing of voices, not weighing
>> of the supposed opinions of the silent.
>
> Yes, _but_ anyone who agrees will not argue.  You will only get argument 
> from those who disagree with the post.  Unless you want to change the 
> culture here to require an answer from every reader, on every question, 
> thus adding significantly to our daily workload.  I'd rather not.

Very true for the original post, but once one person (or, in the instant 
case, a couple dozen) has argued with the OP, there is no way to determine 
which side the silent majority agrees with.  It is possible that there are 
thousands of people agree with Yakov but have cultural prohibitions on 
backing him, or it could be that there are thousands that don't agree but 
have no new points to add -- or both.  All we can measure are the people who 
do speak up.

Right now it looks like there is a very strong consensus against MS Word as 
an output format, a weaker one against it as an input format, and no real 
consensus yet about other options like HTML, OpenDoc, PDF/A, etc.

IMHO, the normative output text should remain the ASCII version, perhaps 
with UTF-8 to allow authors to add a native rendering of their name.  Any 
other output versions should be optional and explicitly non-normative. 
Input forms should remain the same as today plus optional UTF-8.  I think 
that's about as "progressive" as we'll likely build consensus for any time 
soon.  The bad artwork that this saddles us with is, IMHO, a feature and not 
a bug.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 14:51:11 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eub8h-0001QA-Ht; Thu, 05 Jan 2006 14:51:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eub8e-0001Lf-O6
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 14:51:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03849
	for ; Thu, 5 Jan 2006 14:49:52 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EubEN-0000Ri-Rb
	for ietf@ietf.org; Thu, 05 Jan 2006 14:57:05 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k05JovdJ008862; Thu, 5 Jan 2006 14:50:57 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04924; 
	Thu, 5 Jan 2006 14:50:55 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 5 Jan 2006 14:50:55 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886269@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Sandy Wills'" 
Date: Thu, 5 Jan 2006 14:50:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Cc: ietf@ietf.org
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sandy,

	What you say is correct, as far as it goes.  However,
the implication in the wording is that people disagreeing
with a proposal will post and people disagreeing with them
will not.  This is the case - as you suggest - when there 
is a clear "default outcome".

	In fact, contrary to what we observe in nature, change
is not the "default outcome" in most human organizations.
That is because - as a careful analysis of this discussion
over the years will disclose - there are as many ways to go
with a change as there are people prepared to make changes.

	Consequently, it is at least as valid to assume that 
- particularly when a proposal represents a departure from
status quo - that people may not be responding because they 
agree with the _objections_ already made and _also_ do not 
want to add to the general hub-bub.

	Consequently, if we see 10-20 people posting in favor 
of a _specific_ proposal and similar numbers posting against 
that same _specific_ proposal, then it is out of line for us 
to assume that any particular opinion is indicated by silence.

	Note that it is _very_ important to distinguish support
for a particular change from support for the idea that some
change is required.  For example, if you have well over 100 
people who all agree that change is required, and only 20 who
argue that no change is required, you have to evaluate the
agreement for a specific change (or at least a specific change
direction) rather than a general discontent with status quo.
If no more than 5 or 10 people agree to a specific proposal,
then the net effect is a consensus for the status quo (better
the devil you know).

	As one of the people arguing for status quo, I can tell
you that it is not that I am happy with it.  It is because I
do not see a reasonably well supported alternative to status
quo being proposed.

	In fact, a big part of the discussion right now stems 
from the fact that a lot of people have not really understood
exactly what the status quo is.  People who believe that they
cannot submit an ID containing complex graphics in some form 
other than text, clearly do not realize that this is not the
case.

	I like the quote about "coffee", by the way...

--
Eric

--> -----Original Message-----
--> From: Sandy Wills [mailto:sandy@WEIJax.com] 
--> Sent: Thursday, January 05, 2006 12:48 PM
--> To: Gray, Eric
--> Cc: 'Yaakov Stein'; ietf@ietf.org
--> Subject: Re: objection to proposed change to "consensus"
--> 
--> Gray, Eric wrote:
--> 
--> > "It is much more likely to hear from the very vocal 
--> people who are 
--> >  opposed to the change. That is, assuming 1000s of participants 
--> >  on the IETF discussion list, perhaps 20 expressed 'nays', even 
--> >  strong nays, could be considered a clear consensus in favor of 
--> >  change."
--> 
--> While I can't speak for everyone else, this seems correct 
--> to me.  "Do I 
--> have anything useful or enteresting to add?" and "Do I 
--> think that my 
--> input will change the output?" must both evaluate to "Yes" 
--> before I post 
--> to any discussion.  I occasionally post for humor or interest, but 
--> generally I follow the discussion and stay out of it unless 
--> I believe it 
--> to be going badly awry.
--> 
-->    To be blunt, do we want every question to be answered by several 
--> thousand AOL "Me too"'s?  The silent masses are silent because they 
--> don't have anything useful to add, and believe that an 
--> endless stream of 
--> agreements would do nothing useful except test our bandwidth.
--> 
-->    We do, on the other hand, chime in when necessary.  So, 
--> it is "good" 
--> and "right" and "fair" to assume that a public question 
--> with a default 
--> answer has concensus, if the only response is a minor 
--> negative one.  I, 
--> and I believe many others, will simply move on to the next 
--> post when we 
--> see the question, if we agree with the default answer.
--> 
-->    A simple mental experiment: If we have, say, 2000 
--> readers, and we 
--> post the question
--> 
-->    "Will the sun rise tomorrow?  We think yes."
--> 
-->   then we can expect a small number of disagreements, a 
--> small number of 
--> arguments from readers who didn't understand the question, a small 
--> number of AOL's, a small number of "Of course, you twit!  
--> Why are you 
--> wasting our time with this?" and nothing else.  The vast 
--> majority of the 
--> readers will not reply, because they agree with the default 
--> answer, and 
--> they have other things to do.
-->    If there is a reader who disagrees in his mind, but is 
--> constrained by 
--> cultural conditioning or natural manners from speaking out, 
--> how are we 
--> supposed to coax his "better way" from this reader?  We 
--> have already 
--> posited that he/she/it won't speak up.
-->    I submit that the IETF culture should, by policy, assume 
--> that anyone 
--> subscribed to an IETF list will speak out on any question 
--> if he/she/it 
--> thinks it right.
--> 
--> >     The current process requires weighing of voices, not weighing
--> > of the supposed opinions of the silent.
--> 
--> Yes, _but_ anyone who agrees will not argue.  You will only 
--> get argument 
--> from those who disagree with the post.  Unless you want to 
--> change the 
--> culture here to require an answer from every reader, on 
--> every question, 
--> thus adding significantly to our daily workload.  I'd rather not.
--> 
--> -- 
--> Unable to locate coffee.
--> Operator halted.
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 15:00:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EubHy-0003Qu-N2; Thu, 05 Jan 2006 15:00:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EubHv-0003Q1-71
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 15:00:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05064
	for ; Thu, 5 Jan 2006 14:59:27 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EubNf-0000kY-AF
	for ietf@ietf.org; Thu, 05 Jan 2006 15:06:39 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EubHZ-000ALA-T7; Thu, 05 Jan 2006 15:00:22 -0500
Date: Thu, 05 Jan 2006 15:00:20 -0500
From: John C Klensin 
To: Stewart Bryant 
Message-ID: <53C6FBCFE711922F6B7789D8@p3.JCK.COM>
In-Reply-To: <43BD50DC.8090100@cisco.com>
References: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EV	
	S1.ugd.att.com> 
	<43BD50DC.8090100@cisco.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Content-Transfer-Encoding: 7bit
Cc: "Ash, Gerald R \\\\\(Jerry\\\\\)" , ietf@ietf.org
Subject: PDF, Postscript, and "normative" versions (was: Re: Baby
 Steps (was RE: Alternative formats for IDs))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Thursday, 05 January, 2006 17:01 +0000 Stewart Bryant
 wrote:

>...
>> I find it interesting that it has not been taken
>> advantage of more often (and, for the record, I'm one of those
>> who has taken advantage of it).  When it has been done for
>> artwork purposes, the artwork in the ASCII version has
>> sometimes been pretty rudimentary.   In practice, whether it
>> is "good enough" has been made on a case by case basis by WG
>> Chairs and WGs or, for non-WG documents, by whether or not
>> the relevant people are willing to read and consider those
>> documents.
 
> Please clarify this. Are you saying that if the
> WG/WGchairs/ADs agree that the non-ASCII
> version should be the normative version (because they want the
> better artwork), then  that's
> OK? I thought  I asked this a long time ago and was told no.

No, I'm not saying that.  But the distinction I was trying to
make is pretty subtle.   The ASCII is the ASCII.  "Normative"
doesn't mean much for an I-D (see below for RFCs).  The rule
about PDF or Postscript versions is that they are supposed to be
equivalent to the ASCII (and vice versa).  But "equivalent" gets
a little subjective...

We know perfectly well that there are a few cases in which, no
matter what one does with ASCII art, it is not sufficient to
make whatever point is being made and supplemental text --more
description, in words, of what would be in the pictures-- will
not help much either.   Now, part of the point that the people
who have said "if you can't do it in ASCII art, you generally
shouldn't be doing it -- use the ASCII art and write a better
description" are making is that the cases in which we really
need fancy pictures are very few and that, except for those
cases, we are better off without them or at least being able to
treat them as strictly supplementary.

Before I go on, I continue to be fascinated by the observation
that, each time the "we really need pictures and fancy
formatting and need them frequently" argument comes up, the vast
majority of those who make it most strongly are people whose
contributions to the IETF -- in designer, editor, or other
leadership roles-- have been fairly minimal.  Now, of course,
some of them might argue that our current rules prevent them
from contributing and that, if only we would let them submit
documents written with the DeathRay word processor in Klingon
script, not only would their productivity rise, but everyone
else's would too --once we bought copies of DeathRay, learned
Klingon, and persuaded UTC to get the characters into Unicode.

However, that aside, assume that you are describing the new Mona
Lisa protocol, and that it is really impossible to adequately
describe the protocol without a high-resolution scale picture of
the Mona Lisa overlaid with your coordinate system.  The ASCII
form of your document could (and must under our current rules)
describe the coordinate system, include all of the measurements,
and describe what you are doing with them.  That text is
normative (and the important thing is "the text", not whether it
is in ASCII or not) and has to be.  But it is going to be _very_
hard for anyone to understand your protocol without seeing the
picture unless they have a good mental image of it.  

Under those conditions, our precedents are that you can probably
convince the WG/WGchairs/ADs, and eventually the RFC Editor,
that a PDF document containing a picture of the Mona Lisa and an
ASCII document with 

      _        -----
              /     \
      _       | o o |
              |  |  |
              | __  |
      _       |     |
              \_____/
      _
            |   |  |  |

as a substitute for that picture, with the marginal lines
roughly identifying your grid marks and coordinate system, is
"equivalent" or as close to it as one can get.  I would expect
that to be a hard sell.  I, personally, would _want_ it to be a
hard sell.  If it is really necessary, folks will figure out how
to get the picture (maybe only the picture, which will probably
not change from one version of the I-D to the next) to those who
can't handle the PDF (or Postscript).  But we have done it
before, all of the needed rules and procedures are in place, and
nothing new is needed other than your understanding that you are
going to have to get consensus that the artwork is vital before
making that great a departure between the ASCII and the PDF
versions.

>> Similarly, when PDF has been posted in order to exhibit
>> non-ASCII characters, it has proven helpful to have Unicode
>> character offsets (i.e., U+nnnn representations)  in both the
>> ASCII and PDF forms to ensure complete precision even though
>> the character-glyphs themselves appear only in the PDF form.  
>> 
>> So, consider the first baby step to have been taken: nothing
>> prevents you from posting an I-D in both ASCII and PDF today,
>> and the relevant sub-community will sort out, on a case by
>> case basis, whether the ASCII is good enough.   
>> 
> ...and if it's not the pdf version of the text including
> graphics will become the RFC?

No, they both become the RFC, and concerns about which one is
"normative" are just distractions.   For standards-track
documents, if it is posted as an official form of an RFC, it is
normative.   But, the more whatever-is-in-the-PDF differs from
whatever-is-in- the-ASCII --or, to put it differently, the more
the text depends on images that appear only in the PDF rather
than on the text standing alone or with ASCII art-- the harder
it is going to be for you to convince the community, the IESG,
and the RFC Editor that the PDF version is "equivalent" and, to
the extent to which it is obviously not equivalent, sufficiently
necessary to justify its posting.

    john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 15:04:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EubM3-0005BU-MU; Thu, 05 Jan 2006 15:04:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EubM1-0005BN-L3
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 15:04:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05436
	for ; Thu, 5 Jan 2006 15:03:41 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EubRk-0000sh-Vf
	for ietf@ietf.org; Thu, 05 Jan 2006 15:10:54 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k05K4fdJ009173; Thu, 5 Jan 2006 15:04:42 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06665; 
	Thu, 5 Jan 2006 15:04:41 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 5 Jan 2006 15:04:40 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88626A@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Stewart Bryant'" 
Date: Thu, 5 Jan 2006 15:04:16 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
Cc: ietf@ietf.org
Subject: RE: Engineering our way out of a brown paper bag [Re: Consensus b
	ased on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart,
 
    Of course it is.  I think virtually everyone would like to live in 
a perfect world and most of us recognize that this is not it.
 
    Therefore, it is clear that - whatever we might say in any particular
argument - we all want things to get better.  Consequently, proposals 
to change "what is" will always be a recurring event.
 
    The question we really have to ask - as dissected by Brian in some
detail - is whether or not a specific proposal is enough "better" than 
what we have already (assuming that what we have already is both under-
stood and used appropriately) to overcome the "steady-state friction" 
typically used to prevent change for the sake of marginal gain with an 
unquantifiable risk for unanticipated side effects.
 
--
Eric


________________________________

	From: Stewart Bryant [mailto:stbryant@cisco.com] 
	Sent: Thursday, January 05, 2006 1:22 PM
	To: Eliot Lear
	Cc: Gray, Eric; Harald Tveit Alvestrand; ietf@ietf.org
	Subject: Re: Engineering our way out of a brown paper bag [Re:
Consensus b ased on reading tea leaves]
	
	
	Eliot Lear wrote:
	

		I agree.  As usual we seem to be stuck in an infinite loop
on this
		mailing list with the cycle being somewhere between 6 months
and 3 years.
		
		  

	The fact that we keep coming back to this topic may be a message in
itself!
	
	- Stewart
	

		Eliot
		
		Gray, Eric wrote:
		  

			Brian,
			
				I think it is somewhat unfair to say that we
have
			not tried the steps you outline below.  Where we run
into 
			trouble is when different sets of people disagree as
to
			which of the steps we are currently working on.
			
				Quite frankly, I believe we can address the
second
			step (which of the requirements are not met today?)
with 
			a firm "none."
			
				This is - IMO - the basis for the apparent
stodgy
			resistance to change.
			
			--
			Eric 
			
			--> -----Original Message-----
			--> From: ietf-bounces@ietf.org
[mailto:ietf-bounces@ietf.org] 
			--> On Behalf Of Brian E Carpenter
			--> Sent: Thursday, January 05, 2006 7:36 AM
			--> To: Harald Tveit Alvestrand
			--> Cc: ietf@ietf.org
			--> Subject: Engineering our way out of a brown
paper bag [Re: 
			--> Consensus based on reading tea leaves]
			--> 
			--> Harald Tveit Alvestrand wrote:
			--> > 
			--> > 
			--> > --On mandag, januar 02, 2006 18:10:15 +0200
Yaakov Stein 
			--> >  
wrote:
			--> > 
			--> >> The only thing I am sure about is
			--> >> that
			--> >> consensus on this list is for keeping
everything exactly 
			--> as it is.
			--> > 
			--> > 
			--> > I'm pretty sure there's no such consensus.
			--> > 
			--> > I do, however, see a rather strong 
			--> consensus-of-the-speakers against 
			--> > using MS-Word document format for anything
"official".
			--> 
			--> I think we need to tackle this whole issue, if
we do decide to
			--> tackle it, in a much more systematic way.
			--> 
			--> - what are our functional requirements?
			--> - which of them are not met today?
			--> - what are the possible solutions, and what is
their practical
			-->    and operational cost?
			--> - which, if any, solutions should we adopt, on
what timescale?
			--> 
			--> I believe that if we took a systematic approach
like that, the issue
			--> of how we determine consensus would be broken
into enough small
			--> steps that it really wouldn't be an issue.
			--> 
			-->      Brian
			--> 
			--> 
			--> _______________________________________________
			--> Ietf mailing list
			--> Ietf@ietf.org
			--> https://www1.ietf.org/mailman/listinfo/ietf
			--> 
			
			_______________________________________________
			Ietf mailing list
			Ietf@ietf.org
			https://www1.ietf.org/mailman/listinfo/ietf
			
			  
			    

		
		_______________________________________________
		Ietf mailing list
		Ietf@ietf.org
		https://www1.ietf.org/mailman/listinfo/ietf
		
		
		  



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 15:18:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EubZ7-0002Q1-TR; Thu, 05 Jan 2006 15:18:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EubZ5-0002Oz-Sl
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 15:18:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07303
	for ; Thu, 5 Jan 2006 15:17:11 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eubel-0001Ml-Bc
	for ietf@ietf.org; Thu, 05 Jan 2006 15:24:24 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k05KICdJ009474; Thu, 5 Jan 2006 15:18:12 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08180; 
	Thu, 5 Jan 2006 15:18:11 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 5 Jan 2006 15:18:11 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88626B@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Stewart Bryant'" 
Date: Thu, 5 Jan 2006 15:17:57 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: ietf@ietf.org
Subject: RE: Engineering our way out of a brown paper bag [Re: Consensus b
	ased on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart,

	I didn't want to go through all the RFCs to find a specific 
example, but I distinctly recall seeing an RFC at one point that 
had "figures" which contained only the text "see associated PS
version".  However, I know I can't expect anyone to take my word
for it.

	However, there was an easy way to get around that.  I simply 
ftp'd all 48 of the RFCs that are available in PS format.  I am
still somewhat at a loss to understand why there are none in PDF,
but the observation that other formats may be used obviously still
stands.

	The very first RFC available in PS was RFC 1119.  Surprisingly 
enough, the entire contents of the ASCII version is as follows:

'RFC-1119 "Network Time Protocol (Version 2) Specification and

Implementation" is available only in PostScript form in the file

RFC1119.PS'

	So, what exactly are we arguing about?  :-)

--
Eric

--> -----Original Message-----
--> From: Stewart Bryant [mailto:stbryant@cisco.com] 
--> Sent: Thursday, January 05, 2006 1:19 PM
--> To: Gray, Eric
--> Cc: 'Brian E Carpenter'; Harald Tveit Alvestrand; ietf@ietf.org
--> Subject: Re: Engineering our way out of a brown paper bag 
--> [Re: Consensus b ased on reading tea leaves]
--> 
--> Gray, Eric wrote:
--> 
--> >Brian,
--> >
--> >	I think it is somewhat unfair to say that we have
--> >not tried the steps you outline below.  Where we run into 
--> >trouble is when different sets of people disagree as to
--> >which of the steps we are currently working on.
--> >
--> >	Quite frankly, I believe we can address the second
--> >step (which of the requirements are not met today?) with 
--> >a firm "none."
--> >  
--> >
--> 
--> That is not true, we don't address the need to include diagrams.
--> 
--> - Stewart.
--> 
--> >	This is - IMO - the basis for the apparent stodgy
--> >resistance to change.
--> >
--> >--
--> >Eric 
--> >
--> >--> -----Original Message-----
--> >--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> >--> On Behalf Of Brian E Carpenter
--> >--> Sent: Thursday, January 05, 2006 7:36 AM
--> >--> To: Harald Tveit Alvestrand
--> >--> Cc: ietf@ietf.org
--> >--> Subject: Engineering our way out of a brown paper bag [Re: 
--> >--> Consensus based on reading tea leaves]
--> >--> 
--> >--> Harald Tveit Alvestrand wrote:
--> >--> > 
--> >--> > 
--> >--> > --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein 
--> >--> >  wrote:
--> >--> > 
--> >--> >> The only thing I am sure about is
--> >--> >> that
--> >--> >> consensus on this list is for keeping everything exactly 
--> >--> as it is.
--> >--> > 
--> >--> > 
--> >--> > I'm pretty sure there's no such consensus.
--> >--> > 
--> >--> > I do, however, see a rather strong 
--> >--> consensus-of-the-speakers against 
--> >--> > using MS-Word document format for anything "official".
--> >--> 
--> >--> I think we need to tackle this whole issue, if we do decide to
--> >--> tackle it, in a much more systematic way.
--> >--> 
--> >--> - what are our functional requirements?
--> >--> - which of them are not met today?
--> >--> - what are the possible solutions, and what is their practical
--> >-->    and operational cost?
--> >--> - which, if any, solutions should we adopt, on what timescale?
--> >--> 
--> >--> I believe that if we took a systematic approach like 
--> that, the issue
--> >--> of how we determine consensus would be broken into enough small
--> >--> steps that it really wouldn't be an issue.
--> >--> 
--> >-->      Brian
--> >--> 
--> >--> 
--> >--> _______________________________________________
--> >--> Ietf mailing list
--> >--> Ietf@ietf.org
--> >--> https://www1.ietf.org/mailman/listinfo/ietf
--> >--> 
--> >
--> >_______________________________________________
--> >Ietf mailing list
--> >Ietf@ietf.org
--> >https://www1.ietf.org/mailman/listinfo/ietf
--> >
--> >
--> >  
--> >
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 15:22:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eubcz-0003X9-NU; Thu, 05 Jan 2006 15:22:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eubcx-0003Ww-K1
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 15:22:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08070
	for ; Thu, 5 Jan 2006 15:21:11 -0500 (EST)
Received: from a.mail.sonic.net ([64.142.16.245])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eubih-0001ZK-Am
	for ietf@ietf.org; Thu, 05 Jan 2006 15:28:24 -0500
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG
	[168.61.10.151]) (authenticated bits=0)
	by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k05KMBLw001657
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 5 Jan 2006 12:22:11 -0800
In-Reply-To: <20060105193106.16048.qmail@xuxa.iecc.com>
References: <20060105193106.16048.qmail@xuxa.iecc.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Douglas Otis 
Date: Thu, 5 Jan 2006 12:22:38 -0800
To: John Levine 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus b
	ased on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 5, 2006, at 11:31 AM, John Levine wrote:

>> Quite frankly, I believe we can address the second step (which of  
>> the requirements are not met today?) with a firm "none."
>
> One is that ASCII doesn't permit adequately beautiful pictures.  If  
> that's the problem to be solved, it seems to me that a  
> straightforward solution would be to allow authors to submit image  
> files along with the ASCII text.  I'd suggest requiring that the  
> image format be GIF, since it's simple, stable, well documented,  
> widely supported in both freeware and commercial software, and the  
> patents have expired.  (Or maybe PNG, any stable public format will  
> do.)

A minor problem with independent graphic files is they are difficult  
to manage.  A graphic image has also become a vehicle for Trojans, as  
file extensions often do not take precedence within rendering  
engines.  This would impose a new risk for the editor.  An interim  
solution could be a drawing application (or a regular editor) that  
uses Unicode "Box Drawing" characters rather than ACSII hyphens,  
under-score, plus symbols, greater-than, less-than, and vertical  
bars.  For these to provide a clean output, the line spacing would  
need to be controlled for a clean look.  This can be done using HTML  
and PDF outputs.


> The other is that the editorial process is more tedious than it  
> needs to be, because RFCs have a mandatory structure that plain  
> ASCII doesn't express.  RFC 2629 or 2629bis captures the structure  
> while being well supported in free and commercial software and, in  
> a pinch, legible without tools since it's ASCII underneath.

These tools can already utilize the "Box Drawing" characters, so a  
utillity to assist with the creation of the box drawings would make  
this less painful.  The utility could also add the needed XML wrapper  
to make this an easy cut and paste.  If desired, these characters  
could be translated back into the ASCII equivalent for the ASCII  
version.  It would also seem that bibliography and author names could  
also include a Unicode element used by the HTML and PDF outputs, but  
then not the ASCII versions.  The alternative elements for titles and  
authors would be assuming a desire to retain the ASCII only version.   
If the ASCII version is not retained, then the effort would be even  
more straight forward.

-Doug


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 15:36:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eubqv-0003TW-29; Thu, 05 Jan 2006 15:36:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eubqt-0003TP-7x
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 15:36:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10157
	for ; Thu, 5 Jan 2006 15:35:34 -0500 (EST)
Received: from ms-smtp-03-smtplb.tampabay.rr.com ([65.32.5.133]
	helo=ms-smtp-03.tampabay.rr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eubwc-00029I-CO
	for ietf@ietf.org; Thu, 05 Jan 2006 15:42:47 -0500
Received: from WEIJax.com (131-37.121-70.tampabay.res.rr.com [70.121.37.131])
	by ms-smtp-03.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id
	k05KaeGK026026; Thu, 5 Jan 2006 15:36:41 -0500 (EST)
Message-ID: <43BD82D2.7070201@WEIJax.com>
Date: Thu, 05 Jan 2006 15:34:26 -0500
From: Sandy Wills 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C886269@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886269@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Gray, Eric wrote:

> Sandy,
> 
> 	In fact, contrary to what we observe in nature, change
> is not the "default outcome" in most human organizations.
> That is because - as a careful analysis of this discussion
> over the years will disclose - there are as many ways to go
> with a change as there are people prepared to make changes.

    I think that there is also a very strong element of emotional 
attachment to any system or solution, from those people who had a hand 
in creating it (Certainly, I'm just as guilty of this as the next guy!). 
  Any job is harder if you have to change your tools every time you get 
used to them.
    It's also true that some people will object to anything in front of 
them, simply because it was done by someone else.
    We also have the "religious" responses, both pro and con, where 
someone either approves (or disapproves) of it simply because of the 
source.  We've all seen "It's gotta be good, Jon Postel wrote it", as 
well as "I'll cut my wrists before I use MS software"

    It appears that, if we want to judge solution-quality by mob volume, 
we need to find some way to separate the emotional responses from the 
reasoned responses.  Unfortunately, I don't have one handy.

> 	Note that it is _very_ important to distinguish support
> for a particular change from support for the idea that some
> change is required.  For example, if you have well over 100 
> people who all agree that change is required, and only 20 who
> argue that no change is required, you have to evaluate the
> agreement for a specific change (or at least a specific change
> direction) rather than a general discontent with status quo.
> If no more than 5 or 10 people agree to a specific proposal,
> then the net effect is a consensus for the status quo (better
> the devil you know).
> 
> 	As one of the people arguing for status quo, I can tell
> you that it is not that I am happy with it.  It is because I
> do not see a reasonably well supported alternative to status
> quo being proposed.

...And we are back to what has been said many times already.  "Do we 
want to change? Answer yes/no" and "What do we want to change to?" are 
_not_ completely separable.  You admit that you aren't happy about the 
status quo, but will still answer "No" to the first question because you 
don't trust us as a community to come up with a sane answer to the 
second question.

    The only quick and easy solution I see would be a multiple-choice 
question, perhaps on a web site, with options like:

   A) The world is perfect.  Change nothing.
   B) I hate our system, but don't trust you bozos.  Change nothing.
   C) Change to cunieform-and-clay, for everything.
   D) Change to marble for ID submission, and MS Word '95 for RFC 
publication.
   etc, etc, etc.

   I choose to _NOT_ volunteer to write and host this website.

> 
> 	I like the quote about "coffee", by the way...

Thanks!  While it's not original with me, I certainly still remember the 
pain involved with the source "Unable to locate COMMAND.COM - Processor 
halted"

-- 
Unable to locate coffee.
Operator halted.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 16:15:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EucRv-0000qX-5e; Thu, 05 Jan 2006 16:15:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EucRr-0000oF-HL
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 16:15:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18791
	for ; Thu, 5 Jan 2006 16:13:45 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EucXV-00059C-MR
	for ietf@ietf.org; Thu, 05 Jan 2006 16:20:59 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k05LEjdJ010889; Thu, 5 Jan 2006 16:14:46 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA14591; 
	Thu, 5 Jan 2006 16:14:44 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 5 Jan 2006 16:14:43 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88626F@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Sandy Wills'" 
Date: Thu, 5 Jan 2006 16:12:56 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Cc: ietf@ietf.org
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sandy,

	My point - as may be clearer in other posts - is that 
the first question "do we want change" is a no-op at best.
Change is natural and inevitable whether we want it or not.
The first useful question is - paraphrasing what Brian said 
- what do we need that we do not already have?

	All of us have "needs" that are not satisfied by what
we have - hence the inevitability of change.  But it is not
useful, nor realistic, for any of us to assume that everyone
else is going to drop what they're doing to help us satisfy
our individual "needs."  So the question becomes "Is there a 
common subset of our collective individual needs that a large
subset of affected people agree on, that cannot be satisfied 
by what we have now?"

	IMO, that is the question we keep coming back to...

--
Eric

--> -----Original Message-----
--> From: Sandy Wills [mailto:sandy@WEIJax.com] 
--> Sent: Thursday, January 05, 2006 3:34 PM
--> To: Gray, Eric
--> Cc: ietf@ietf.org
--> Subject: Re: objection to proposed change to "consensus"
--> 
--> Gray, Eric wrote:
--> 
--> > Sandy,
--> > 
--> > 	In fact, contrary to what we observe in nature, change
--> > is not the "default outcome" in most human organizations.
--> > That is because - as a careful analysis of this discussion
--> > over the years will disclose - there are as many ways to go
--> > with a change as there are people prepared to make changes.
--> 
-->     I think that there is also a very strong element of emotional 
--> attachment to any system or solution, from those people who 
--> had a hand 
--> in creating it (Certainly, I'm just as guilty of this as 
--> the next guy!). 
-->   Any job is harder if you have to change your tools every 
--> time you get 
--> used to them.
-->     It's also true that some people will object to anything 
--> in front of 
--> them, simply because it was done by someone else.
-->     We also have the "religious" responses, both pro and con, where 
--> someone either approves (or disapproves) of it simply 
--> because of the 
--> source.  We've all seen "It's gotta be good, Jon Postel 
--> wrote it", as 
--> well as "I'll cut my wrists before I use MS software"
--> 
-->     It appears that, if we want to judge solution-quality 
--> by mob volume, 
--> we need to find some way to separate the emotional 
--> responses from the 
--> reasoned responses.  Unfortunately, I don't have one handy.
--> 
--> > 	Note that it is _very_ important to distinguish support
--> > for a particular change from support for the idea that some
--> > change is required.  For example, if you have well over 100 
--> > people who all agree that change is required, and only 20 who
--> > argue that no change is required, you have to evaluate the
--> > agreement for a specific change (or at least a specific change
--> > direction) rather than a general discontent with status quo.
--> > If no more than 5 or 10 people agree to a specific proposal,
--> > then the net effect is a consensus for the status quo (better
--> > the devil you know).
--> > 
--> > 	As one of the people arguing for status quo, I can tell
--> > you that it is not that I am happy with it.  It is because I
--> > do not see a reasonably well supported alternative to status
--> > quo being proposed.
--> 
--> ...And we are back to what has been said many times 
--> already.  "Do we 
--> want to change? Answer yes/no" and "What do we want to 
--> change to?" are 
--> _not_ completely separable.  You admit that you aren't 
--> happy about the 
--> status quo, but will still answer "No" to the first 
--> question because you 
--> don't trust us as a community to come up with a sane answer to the 
--> second question.
--> 
-->     The only quick and easy solution I see would be a 
--> multiple-choice 
--> question, perhaps on a web site, with options like:
--> 
-->    A) The world is perfect.  Change nothing.
-->    B) I hate our system, but don't trust you bozos.  Change nothing.
-->    C) Change to cunieform-and-clay, for everything.
-->    D) Change to marble for ID submission, and MS Word '95 for RFC 
--> publication.
-->    etc, etc, etc.
--> 
-->    I choose to _NOT_ volunteer to write and host this website.
--> 
--> > 
--> > 	I like the quote about "coffee", by the way...
--> 
--> Thanks!  While it's not original with me, I certainly still 
--> remember the 
--> pain involved with the source "Unable to locate COMMAND.COM 
--> - Processor 
--> halted"
--> 
--> -- 
--> Unable to locate coffee.
--> Operator halted.
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 16:22:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EucZU-0004cg-Lp; Thu, 05 Jan 2006 16:22:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EucZT-0004c3-5c
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 16:22:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21605
	for ; Thu, 5 Jan 2006 16:21:38 -0500 (EST)
Received: from galaxy.systems.pipex.net ([62.241.162.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EucfC-00066z-FD
	for ietf@ietf.org; Thu, 05 Jan 2006 16:28:51 -0500
Received: from pc6 (1Cust165.tnt9.lnd4.gbr.da.uu.net [62.188.138.165])
	by galaxy.systems.pipex.net (Postfix) with SMTP id B95EDE0006E0;
	Thu,  5 Jan 2006 21:22:42 +0000 (GMT)
Message-ID: <001a01c61235$62639d60$0601a8c0@pc6>
From: "Tom.Petch" 
To: "James Seng" 
References: <001501c60670$36f0eaa0$0601a8c0@pc6>
	<001f01c607ad$08fa5d00$0601a8c0@pc6>
	<558a39a60601032150q6ff2cf26x603fea87309adb02@mail.gmail.com>
Date: Thu, 5 Jan 2006 21:14:45 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: ietf 
Subject: ABNF Re: Troubles with UTF-8
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Tom.Petch" 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

You say that a Unicode code point can be represented by %xABCD but that is not
spelt out in ABNF [RFC4234].  And when it refers to 'one printable character' as
'%x20-7E' I get the impressions that coded character sets like Unicode, with
more than 256 code points, do not fall within its remit.  I have yet to see any
use of this in an I-D or RFC. I did post a question about this to this list on
24th December and the lack of response reinforces my view that this is uncharted
territory.

Tom Petch
----- Original Message -----
From: "James Seng" 
To: "Tom.Petch" 
Cc: "ietf" 
Sent: Wednesday, January 04, 2006 6:50 AM
Subject: Re: Troubles with UTF-8


> On 12/23/05, Tom.Petch  wrote:
> >
> > A) Character set.  UTF-8 implicitly specifies the use of Unicode/IS10646
> > which
> > contains 97,000 - and rising - characters.  Some (proposed) standards
> > limit
> > themselves to 0000..007F, which is not at all international, others to
> > 0000-00FF, essentially Latin-1, which suits many Western languages but is
> > not
> > truly international.  Is 97,000 really appropriate or should there be a
> > defined
> > subset?
>
>
> Why should there be a subset? You really really dont want to go into a
> debate of which script is more important then the other.
>
> B) Code point. Many standards are defined in ABNF [RFC4234] which allows
> > code
> > points to be specified as, eg,  %b00010011 %d13 or %x0D none of which are
> > terribly Unicode-like (U+000D).  The result is standards that use one
> > notation
> > in the ABNF and a different one in the body of the document; should ABNF
> > allow
> > something closer to Unicode (as XML has done with �D;)?
>
>
> Following RFC4234, Unicode code point U+ABCD will just be represented as
> %xABCD.
>
> I do not see the problem you mention or am I missing something?
>
>

> http://www.unicode.org/charts/
>
> -James Seng
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 16:44:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EucuH-0003yl-Rw; Thu, 05 Jan 2006 16:44:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EucuF-0003ul-9T
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 16:44:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25773
	for ; Thu, 5 Jan 2006 16:43:06 -0500 (EST)
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euczz-0007Yr-Lp
	for ietf@ietf.org; Thu, 05 Jan 2006 16:50:21 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 16C86FB27F;
	Thu,  5 Jan 2006 16:44:14 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id CA00F3C0204;
	Thu,  5 Jan 2006 16:44:12 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: John C Klensin 
In-Reply-To: (Your message of "Thu, 05 Jan 2006 13:58:47 EST.")
	<266A4D6A4BC4722364791F3A@p3.JCK.COM> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 05 Jan 2006 16:44:12 -0500
Message-Id: <20060105214412.CA00F3C0204@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: ietf@ietf.org, "Ash,     Gerald R \\\\\(Jerry\\\\\)" 
Subject: Re: Permitting PDF and Postscript (was: RE: Baby Steps (was RE:
	Alternative formats for IDs)) 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In message <266A4D6A4BC4722364791F3A@p3.JCK.COM>, John C Klensin writes:
>
>
>--On Thursday, 05 January, 2006 12:46 -0500 "Gray, Eric"
> wrote:
>
>> John,
>> 
>> 	I believe - for the record - that Post-Script is also
>> allowed.
>
>It is indeed.  And it, as well as PDF, are allowed in RFCs (see
>earlier note).
>
>As others have noted, an ASCII form is still required.  I
>consider that a feature and, for various worst cases,
>futureproofing, but some others do not.
>
>And, as yet others have noted, it would be wise for us to get
>very specific about versioning and permitted feature-sets for
>PDF.  It is arguably even more important to get specific about
>versions and feature sets for PS although my own personal
>opinion is that, given PDF, Postscript has about outlived its
>usefulness as a separate posting format.  YMMD, of course, and
>this thread on the IETF list is probably not the optimal way to
>address that question in any event.
>
Producing good, portable PDF isn't obvious.  I just added the following 
text to a Call for Papers of a conference I'm chairing, based on many 
sad experiences trying to read random PDF files submitted by others:

	PDF users should use "Type 1" fonts instead of "Type 3", and 
	should "Embed" and "Subset" all fonts.  You can find 
	instructions on how to do this at 
	https://www.fastlane.nsf.gov/documents/pdf_create/pdfcreate_01.jsp
	and http://ismir2005.ismir.net/pdf.html

Among the problems I've encountered have been version skew, missing 
fonts (especially Asian language fonts that are frequently not 
installed elsewhere), fuzzy text from LaTeX users who are generating 
bitmap fonts, ligatures getting changed into weird characters, and more.

When I sent the PDF for the second edition of my book to the publisher, 
I had to use these options to dvips:

	-P pdf -G0 

and

	-dMaxSubsetPct=100 -dCompatibilityLevel=1.3 -dSubsetFonts=true -dEmbedAllFonts=true

for ps2pdf.  (I've left out the resolution.)  I should note that it 
didn't work, either -- but if I sent them the PS, they could convert it 
to PDF.  We never did figure out that problem....


		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 16:53:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eud3T-0006pb-Qt; Thu, 05 Jan 2006 16:53:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eud3R-0006oy-AI
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 16:53:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27015
	for ; Thu, 5 Jan 2006 16:52:36 -0500 (EST)
Received: from lonsmimeo.rit.reuters.com ([192.165.213.23]
	helo=lonsmime03.rit.reuters.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eud9A-0007wR-MV
	for ietf@ietf.org; Thu, 05 Jan 2006 16:59:51 -0500
Received: from eupig1 (unverified [196.7.183.8]) by 
	lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with 
	ESMTP id ;
	Thu, 5 Jan 2006 21:53:36 +0000
Message-ID: 
Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by 
	eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id 
	<0ISN003663HB76@eupig1.dtc.lon.ime.reuters.com>; Thu, 05 Jan 2006 
	21:53:35 +0000 (GMT)
Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by 
	dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); 
	Thu, 05 Jan 2006 21:53:35 +0000
Date: Thu, 05 Jan 2006 21:53:34 +0000
From: Misha Wolf 
To: "Tom.Petch" 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: quoted-printable
Thread-Topic: ABNF Re: Troubles with UTF-8
Thread-Index: AcYSPsDyxwrhLEaPQeq1uW2PgRnKsQAA3IbQ
Content-class: urn:content-classes:message
X-OriginalArrivalTime: 05 Jan 2006 21:53:35.0160 (UTC) 
	FILETIME=[7A0F4380:01C61242]
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: quoted-printable
Cc: ietf 
Subject: RE: ABNF Re: Troubles with UTF-8
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

See:
   2.2.  ABNF for IRI References and IRIs
in:
   http://www.ietf.org/rfc/rfc3987.txt=20

Misha

-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
Tom.Petch
Sent: 05 January 2006 20:15
To: James Seng
Cc: ietf
Subject: ABNF Re: Troubles with UTF-8

You say that a Unicode code point can be represented by %xABCD but that
is not
spelt out in ABNF [RFC4234].  And when it refers to 'one printable
character' as
'%x20-7E' I get the impressions that coded character sets like Unicode,
with
more than 256 code points, do not fall within its remit.  I have yet to
see any
use of this in an I-D or RFC. I did post a question about this to this
list on
24th December and the lack of response reinforces my view that this is
uncharted
territory.

Tom Petch


To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, exc=
ept where the sender specifically states them to be the views of Reuters Lt=
d.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 17:20:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EudTQ-0003dw-4z; Thu, 05 Jan 2006 17:20:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EudTN-0003bf-S4
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 17:20:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01208
	for ; Thu, 5 Jan 2006 17:19:26 -0500 (EST)
Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EudZ6-0000rv-2I
	for ietf@ietf.org; Thu, 05 Jan 2006 17:26:39 -0500
Received: from [127.0.0.1] (www.caia.swin.edu.au [136.186.229.16])
	by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id JAA1031666;
	Fri, 6 Jan 2006 09:20:22 +1100 (EST)
Message-ID: <43BD9BA0.2000204@swin.edu.au>
Date: Fri, 06 Jan 2006 09:20:16 +1100
From: grenville armitage 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>
	<43BD5BDE.4070905@WEIJax.com>
In-Reply-To: <43BD5BDE.4070905@WEIJax.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sandy Wills wrote:
	[..]
>   A simple mental experiment: If we have, say, 2000 readers, and we post 
> the question
> 
>   "Will the sun rise tomorrow?  We think yes."

Then you invite ridicule upon anyone who says "no".

However, consider this case: you post "Should we move to using MS Word?"
and 5 minutes later some hardy soul posts "No". Over the next few minutes to
hours some hundreds or thousands of list members' mail servers will receieve 
these two emails. Many of the human recipients will, in one quick glance, see
two positions staked out - one for MS Word, one against.

With which one does the silent majority agree?

cheers,
gja


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 18:37:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euefg-0007Xm-G2; Thu, 05 Jan 2006 18:37:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euefe-0007Xh-39
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 18:37:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11130
	for ; Thu, 5 Jan 2006 18:36:10 -0500 (EST)
Received: from ms-smtp-02-smtplb.tampabay.rr.com ([65.32.5.132]
	helo=ms-smtp-02.tampabay.rr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuelP-0003dt-Gd
	for ietf@ietf.org; Thu, 05 Jan 2006 18:43:24 -0500
Received: from WEIJax.com (131-37.121-70.tampabay.res.rr.com [70.121.37.131])
	by ms-smtp-02.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id
	k05NbGb6015459; Thu, 5 Jan 2006 18:37:17 -0500 (EST)
Message-ID: <43BDAD26.9020909@WEIJax.com>
Date: Thu, 05 Jan 2006 18:35:02 -0500
From: Sandy Wills 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: grenville armitage 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>	<43BD5BDE.4070905@WEIJax.com>
	<43BD9BA0.2000204@swin.edu.au>
In-Reply-To: <43BD9BA0.2000204@swin.edu.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

grenville armitage wrote:

> However, consider this case: you post "Should we move to using MS Word?"
> and 5 minutes later some hardy soul posts "No". Over the next few 
> minutes to
> hours some hundreds or thousands of list members' mail servers will 
> receieve these two emails. Many of the human recipients will, in one 
> quick glance, see
> two positions staked out - one for MS Word, one against.
> 
> With which one does the silent majority agree?

Indeterminate, of course.  This is why, as so many people have pointed 
out time & time again, if concensus is to be requested or claimed, 
propositions on this list
    a) MUST be kept simple, and
    b) MUST include a default.

What you gave us is an example of a "discussion", which can include more 
than one topic, including more than one possible answer.  This should 
not be confused with, or used as justification for, a claim of concensus.

Eventually, we will all be exhausted by this interminal discussion, and 
someone (I think Brian Carpenter is the poor guy stuck with this job) 
will post a simple statement and ask if the statement has concensus.  No 
multiple choice, no discussion, just statement.  I hope it happens soon...

   "The IETF should publish RFCs in the traditional text format, plus 
WordStar version 2.0 of 4/1/1987.  Henceforth, all posters suggesting MS 
Word will be drug from their homes and stoned in the street."

   People who agree will mumble "yeah" under their breath and otherwise 
ignore the post.  People who disagree will reply on the list.  After two 
weeks, someone will compare the size of the subscriber list to the 
number of negative replies, and we'll all start gathering rocks together.

-- 
Unable to locate coffee.
Operator halted.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 19:00:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euf1Y-0000n9-SP; Thu, 05 Jan 2006 19:00:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euf1U-0000lt-J6
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 19:00:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14841
	for ; Thu, 5 Jan 2006 18:58:44 -0500 (EST)
Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euf7F-0004sM-EB
	for ietf@ietf.org; Thu, 05 Jan 2006 19:05:59 -0500
Received: from [127.0.0.1] (www.caia.swin.edu.au [136.186.229.16])
	by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id KAA1042721;
	Fri, 6 Jan 2006 10:59:47 +1100 (EST)
Message-ID: <43BDB2EC.7070002@swin.edu.au>
Date: Fri, 06 Jan 2006 10:59:40 +1100
From: grenville armitage 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>	<43BD5BDE.4070905@WEIJax.com>	<43BD9BA0.2000204@swin.edu.au>
	<43BDAD26.9020909@WEIJax.com>
In-Reply-To: <43BDAD26.9020909@WEIJax.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sandy Wills wrote:

> grenville armitage wrote:
> 
>> However, consider this case: you post "Should we move to using MS Word?"
>> and 5 minutes later some hardy soul posts "No". Over the next few 
>> minutes to
>> hours some hundreds or thousands of list members' mail servers will 
>> receieve these two emails. Many of the human recipients will, in one 
>> quick glance, see
>> two positions staked out - one for MS Word, one against.
>>
>> With which one does the silent majority agree?
> 
> 
> Indeterminate, of course.  This is why, as so many people have pointed 
> out time & time again, if concensus is to be requested or claimed, 
> propositions on this list
>    a) MUST be kept simple, and
>    b) MUST include a default.

My example was (a) simple, and (b) had a default.

> What you gave us is an example of a "discussion",

What I demonstrated is that any posed question on a mailing list will, if it
solicits replies taking positions for or against, lead to an indeterminate
state when interpreted through logic that states "the silent majority agrees
with the position stated on the mailing list."  Every subsequent response to
the 'first' question will itself stake out a position, and you have no right
to assume the 'majority' care more about the 'first post' of the question than
the followups.

cheers,
gja


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 20:56:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eugpp-0004xH-40; Thu, 05 Jan 2006 20:56:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eugpn-0004vp-Hh
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 20:56:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23044
	for ; Thu, 5 Jan 2006 20:54:47 -0500 (EST)
Received: from ms-smtp-03-smtplb.tampabay.rr.com ([65.32.5.133]
	helo=ms-smtp-03.tampabay.rr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eugvb-0008Ib-5V
	for ietf@ietf.org; Thu, 05 Jan 2006 21:02:03 -0500
Received: from WEIJax.com (131-37.121-70.tampabay.res.rr.com [70.121.37.131])
	by ms-smtp-03.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id
	k061ttGK021993; Thu, 5 Jan 2006 20:55:55 -0500 (EST)
Message-ID: <43BDCDA5.5080409@WEIJax.com>
Date: Thu, 05 Jan 2006 20:53:41 -0500
From: Sandy Wills 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: grenville armitage 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>	<43BD5BDE.4070905@WEIJax.com>	<43BD9BA0.2000204@swin.edu.au>	<43BDAD26.9020909@WEIJax.com>
	<43BDB2EC.7070002@swin.edu.au>
In-Reply-To: <43BDB2EC.7070002@swin.edu.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

(comments inline, but the summary is that _I_ read your words and 
apparently get a different meaning from when _you_ read your words)


grenville armitage wrote:

> Sandy Wills wrote:
> 
>> grenville armitage wrote:
>>
>>> However, consider this case: you post "Should we move to using MS Word?"

A simple yes/no question, with no default given by the poster.  Those 
are your words, not mine.

>>> and 5 minutes later some hardy soul posts "No".

This is, in your example, the first "choice" available, since the 
original question had no default/assumed answer.

>>> Over the next few minutes to
>>> hours some hundreds or thousands of list members' mail servers will 
>>> receieve these two emails. Many of the human recipients will, in one 
>>> quick glance, see
>>> two positions staked out - one for MS Word, one against.

Thus we have a "discussion"

>>> With which one does the silent majority agree?
>>
>> Indeterminate, of course.  This is why, as so many people have pointed 
>> out time & time again, if concensus is to be requested or claimed, 
>> propositions on this list
>>    a) MUST be kept simple, and
>>    b) MUST include a default.
> 
> 
> My example was (a) simple, and (b) had a default.

    Please read your words again.  Your example was an open question, 
with no default, leading to a "discussion".


    Maybe I'm not expressing myself clearly enough.  Okay, maybe that's 
because we don't use the same definitions for the words and phrases we 
are passing back and forth.

    You keep describing our "discussions", and I agree that, yep, that's 
the way our discussions work.  I keep trying to point out that this is 
different from how we "call for concensus", and you keep going back to 
"but that's not how our discussions work".  You're right, because a 
"discussion" is _different_ from a "call for concensus" (henceforth 
CfC), and we will never be able to REACH a concensus if you can't tell 
the difference.  (and I think that this confusion is one of the IETF's 
big problems)

For the sake of this discussion, here are a couple of working 
definitions.  Please let me know if you see a problem with them:

    A "Discussion" has many speakers, many viewpoints, many issues, many 
proposed solutions, and, well, discussion about them all, lasting for 
(sometimes) a long time.

    A "CfC" usually follows a "Discussion" and has ONE (count 'em) 
statement, by ONE (count 'em) person, expressing a clear value or 
decision, asking for agreement or disagreement.  It may or may not be 
bundled with justifying data or logic, as long as the readers can find 
the CfC.  This CfC is followed by a variable number of replies agreeing 
or disagreeing with the statement.  Once that is done, the group can 
take the results of that CfC and move forward, with either another 
discussion, or a further CfC, as seems useful.

If your example had been a _statement_ "We should move to MSWord", then 
that would have worked for a CfC.  (I believe that such a CfC would 
collect a large number of "No"s, with many of them giving reasons.) 
However, wording it as a question "Should we..." is asking for a 
discussion, not a CfC.  And we cannot ever reach a concensus if we can't 
  tell the two apart.

For the record, I believe that the Chair should issue a CfC on "We 
should allow non-ASCII graphics to accompany IDs and RFCs."  If, and 
only if, that CfC passes, we should explore what format those graphics 
might be.

-- 
Unable to locate coffee.
Operator halted.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 21:35:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuhS7-0003gi-9A; Thu, 05 Jan 2006 21:35:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuhS4-0003gF-8V
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 21:35:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25691
	for ; Thu, 5 Jan 2006 21:34:19 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuhXn-00011i-9m
	for ietf@ietf.org; Thu, 05 Jan 2006 21:41:35 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EuhRj-0008Il-Ib
	for ietf@ietf.org; Fri, 06 Jan 2006 03:35:15 +0100
Received: from 1cust152.tnt6.hbg2.deu.da.uu.net ([149.225.18.152])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Fri, 06 Jan 2006 03:35:15 +0100
Received: from nobody by 1cust152.tnt6.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Fri, 06 Jan 2006 03:35:15 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Fri, 06 Jan 2006 03:30:25 +0100
Organization: 
Lines: 22
Message-ID: <43BDD641.389@xyzzy.claranet.de>
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>
	<43BD5BDE.4070905@WEIJax.com>
	<43BD9BA0.2000204@swin.edu.au> <43BDAD26.9020909@WEIJax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust152.tnt6.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sandy Wills wrote:

> someone (I think Brian Carpenter is the poor guy stuck with
> this job) will post a simple statement and ask if the
> statement has concensus.  No multiple choice, no discussion,
> just statement.  I hope it happens soon...

> "The IETF should publish RFCs in the traditional text format,
>  plus WordStar version 2.0 of 4/1/1987.  Henceforth, all
>  posters suggesting MS Word will be drug from their homes
>  and stoned in the street."
[...]
> and we'll all start gathering rocks together.

Without an opportunity to sell fake beards for this episode in
the "Life of Brian" the proposal could meet some resistance ;-)

Not new, see http://article.gmane.org/gmane.ietf.general/13554
or the clear http://article.gmane.org/gmane.ietf.general/13658

                            Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 22:22:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuiBE-0004BB-F4; Thu, 05 Jan 2006 22:22:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuiBC-0004Av-Qs
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 22:22:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27848
	for ; Thu, 5 Jan 2006 22:20:57 -0500 (EST)
Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuiGx-00025g-Ow
	for ietf@ietf.org; Thu, 05 Jan 2006 22:28:14 -0500
Received: from [127.0.0.1] (www.caia.swin.edu.au [136.186.229.16])
	by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id OAA550133;
	Fri, 6 Jan 2006 14:21:59 +1100 (EST)
Message-ID: <43BDE250.20204@swin.edu.au>
Date: Fri, 06 Jan 2006 14:21:52 +1100
From: grenville armitage 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>	<43BD5BDE.4070905@WEIJax.com>	<43BD9BA0.2000204@swin.edu.au>	<43BDAD26.9020909@WEIJax.com>	<43BDB2EC.7070002@swin.edu.au>
	<43BDCDA5.5080409@WEIJax.com>
In-Reply-To: <43BDCDA5.5080409@WEIJax.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sandy Wills wrote:

	[..]
>    A "CfC" usually follows a "Discussion" and has ONE (count 'em) 
> statement, by ONE (count 'em) person, expressing a clear value or 
> decision, asking for agreement or disagreement.

"...asking for agreement or disagreement."

If it quacks like a question...

cheers,
gja

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 05 22:48:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euiax-0005Bw-80; Thu, 05 Jan 2006 22:48:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euias-0005Bk-IQ
	for ietf@megatron.ietf.org; Thu, 05 Jan 2006 22:48:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29448
	for ; Thu, 5 Jan 2006 22:47:29 -0500 (EST)
Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Euigf-0002qd-Fa
	for ietf@ietf.org; Thu, 05 Jan 2006 22:54:47 -0500
Received: (qmail 71012 invoked from network); 6 Jan 2006 04:31:28 -0000
Received: from softbank219178199025.bbtec.net (HELO
	necom830.hpcl.titech.ac.jp) (219.178.199.25)
	by necom830.hpcl.titech.ac.jp with SMTP; 6 Jan 2006 04:31:28 -0000
Message-ID: <43BDE8AA.50406@necom830.hpcl.titech.ac.jp>
Date: Fri, 06 Jan 2006 12:48:58 +0900
From: Masataka Ohta 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: "Steven M. Bellovin" 
References: <20060105214412.CA00F3C0204@berkshire.machshav.com>
In-Reply-To: <20060105214412.CA00F3C0204@berkshire.machshav.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: John C Klensin , "Ash,
	Gerald R \\\\\(Jerry\\\\\)" , ietf@ietf.org
Subject: Re: Permitting PDF and Postscript
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Steven M. Bellovin wrote:

> Producing good, portable PDF isn't obvious.

My recent experience is that I got a paper in PDF, though
plain text was more than enough for the paper, and
it included an e-mail address to which I send a mail. I used
Adobe original PDF reader (version 7.0) and, to make sure that I
won't wrongly type or copy the address, used reader's function
to automatically detect e-mail addresses in PDF files (PDF may
contain hyperlinks and recent PDF reader of Adobe optionally
detect additional hyperlinks in text automatically. Both types
of links are not distinguishable). Later, I have noticed that the
mail failed, because the PDF reader has a bug that the auto
detection does not work for e-mail addresses containing "-".

IMHO, the person who choosed the PDF format should be
responsible for the failure.

I hope IETF won't make similar mistakes.

						Masataka Ohta


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 06:43:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euq0G-0003xc-Gt; Fri, 06 Jan 2006 06:43:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euq0E-0003xU-A1
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 06:43:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25675
	for ; Fri, 6 Jan 2006 06:42:10 -0500 (EST)
Received: from biscayne-one-station.mit.edu ([18.7.7.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euq65-0007DA-Nx
	for ietf@ietf.org; Fri, 06 Jan 2006 06:49:31 -0500
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id
	k06BhMbb028548; Fri, 6 Jan 2006 06:43:22 -0500 (EST)
Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0)
	(User authenticated as raeburn@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k06BhKYA007653
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Fri, 6 Jan 2006 06:43:21 -0500 (EST)
In-Reply-To: <43BDAD26.9020909@WEIJax.com>
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>	<43BD5BDE.4070905@WEIJax.com>
	<43BD9BA0.2000204@swin.edu.au> <43BDAD26.9020909@WEIJax.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
From: Ken Raeburn 
Date: Fri, 6 Jan 2006 06:43:19 -0500
To: Sandy Wills 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Cc: IETF General Discussion Mailing List 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jan 5, 2006, at 18:35, Sandy Wills wrote:
>   People who agree will mumble "yeah" under their breath and  
> otherwise ignore the post.  People who disagree will reply on the  
> list.  After two weeks, someone will compare the size of the  
> subscriber list to the number of negative replies, and we'll all  
> start gathering rocks together.

Then there are people who will mumble, "that's so stupid/bad/foolish/ 
misguided, and virtually all of the many responses are negative,  
it'll never pass", and otherwise ignore the post.  I doubt I'm the  
only one who sometimes finds himself in that camp.

Then there are those who will mumble, "I don't care about this", and  
otherwise ignore the post.  Like I do for the majority of the IETF- 
wide last-call announcements on things like, say, IP over MPEG-2, or  
Calendar Access Protocol.

Personally, I object to the suggestion that my "vote" should be  
counted one way or another if I am silent.  At most, it should be  
counted as "no strong opinion".  Or should I now start responding to  
all the Last Calls with "I don't care about this, so please don't  
count me as supporting it"?

For an IETF-wide last call, I do think it's reasonable to assume that  
the proposing working group -- the "rough consensus" of the group,  
not necessarily every participant -- is indicating approval of the  
document by bringing it forward.  But that's a *small* bias in favor,  
not a large one.

Ken

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 09:04:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EusD1-0002RP-Rx; Fri, 06 Jan 2006 09:04:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EusCz-0002RE-LY
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 09:04:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03241
	for ; Fri, 6 Jan 2006 09:03:29 -0500 (EST)
Received: from ms-smtp-03-smtplb.tampabay.rr.com ([65.32.5.133]
	helo=ms-smtp-03.tampabay.rr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EusIs-0002Zo-MX
	for ietf@ietf.org; Fri, 06 Jan 2006 09:10:51 -0500
Received: from WEIJax.com (131-37.121-70.tampabay.res.rr.com [70.121.37.131])
	by ms-smtp-03.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id
	k06E4aGK023746; Fri, 6 Jan 2006 09:04:36 -0500 (EST)
Message-ID: <43BE786D.6050006@WEIJax.com>
Date: Fri, 06 Jan 2006 09:02:21 -0500
From: Sandy Wills 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ken Raeburn 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>	<43BD5BDE.4070905@WEIJax.com>
	<43BD9BA0.2000204@swin.edu.au> <43BDAD26.9020909@WEIJax.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: IETF General Discussion Mailing List 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ken Raeburn wrote:
> Personally, I object to the suggestion that my "vote" should be  counted 
> one way or another if I am silent.  At most, it should be  counted as 
> "no strong opinion".  Or should I now start responding to  all the Last 
> Calls with "I don't care about this, so please don't  count me as 
> supporting it"?

We wouldn't count you as "supporting it".  We would count you as "not 
objecting".  That's all.

Maybe there's another way to put it.  How about:

    "I think we have reached substantial agreement on the following 
statement:  ASCII text was good enough for my Grandfather, and it's 
going to be good enough for my grandchildren.  Please reply to this CfC 
if you object."

   Do we need to put into the CfC that we are assuming agreement, and 
that people who don't care don't have to respond?  I thought it obvious 
and understood by all (maybe that's my mistake, right there) that a CfC 
is a request to respond if you object.

    This is not a change; this seems to be the way the IETF works.  Many 
group gatherings work the same way; to me its an intuitive way of 
getting any/all objections brought up, or establishing that there aren't 
any, after a period of free discussion.
    It's the same as at a wedding, when the preacher asks "if anyone 
objects, speak now, or forever hold your peace."  A CfC is assuming an 
agreement (or don't-care), and only those who do NOT agree need to 
respond.  Any other response is undesired.  It's just noise that makes 
it harder to hear the useful "objection" responses.  When you got 
married, did you want every person in the audience to stand up and say 
"I'm okay with this marriage!"?  No, you wanted the entire room silent, 
so that you could hear any objection.

-- 
Unable to locate coffee.
Operator halted.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 09:11:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EusJP-0006TK-74; Fri, 06 Jan 2006 09:11:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EusJM-0006T5-Uz
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 09:11:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03645
	for ; Fri, 6 Jan 2006 09:10:04 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EusPF-0002nb-WB
	for ietf@ietf.org; Fri, 06 Jan 2006 09:17:27 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44)
	id 1EusJ4-0001Vz-2j
	for ietf@ietf.org; Fri, 06 Jan 2006 06:11:02 -0800
Message-Id: <6.2.3.4.2.20060106122620.05c551a0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Fri, 06 Jan 2006 13:39:32 +0100
To: ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <53C6FBCFE711922F6B7789D8@p3.JCK.COM>
References: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EV	
	S1.ugd.att.com> 
	<43BD50DC.8090100@cisco.com> <53C6FBCFE711922F6B7789D8@p3.JCK.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Subject: ancients-moderns dispute (was: PDF, Postscript, and
 "normative" versions (was: Re: Baby Steps (was RE: Alternative formats
 for IDs)))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

We need to get out this ancients vs moderns dispute. Ancients saying 
they have no experience of actual need by moderns, and moderns saying 
this is because the ancient culture does not permit it.

Is there an objection to quote non-ascii documents hyperlinks? I suppose not.

Why not to just to proceed step by step and experiment? Let create an 
optional non-ascii art RFC-Editor repositories, for images quoted in 
RFCs. This will not permit non-ASCII art to be normative but will 
permit non-ASCII art to be _better_ descriptive in a first time. 
Experience will show if there are many such images. If there is a 
real need for normative non-ASCII art, it will provide experience to 
create a non-ASCII art IANA registry making sure they will survive, 
at an adeqate place.

jfc

At 21:00 05/01/2006, John C Klensin wrote:
>No, I'm not saying that.  But the distinction I was trying to
>make is pretty subtle.   The ASCII is the ASCII.  "Normative"
>doesn't mean much for an I-D (see below for RFCs).  The rule
>about PDF or Postscript versions is that they are supposed to be
>equivalent to the ASCII (and vice versa).  But "equivalent" gets
>a little subjective...
>
>We know perfectly well that there are a few cases in which, no
>matter what one does with ASCII art, it is not sufficient to
>make whatever point is being made and supplemental text --more
>description, in words, of what would be in the pictures-- will
>not help much either.   Now, part of the point that the people
>who have said "if you can't do it in ASCII art, you generally
>shouldn't be doing it -- use the ASCII art and write a better
>description" are making is that the cases in which we really
>need fancy pictures are very few and that, except for those
>cases, we are better off without them or at least being able to
>treat them as strictly supplementary.
>
>Before I go on, I continue to be fascinated by the observation
>that, each time the "we really need pictures and fancy
>formatting and need them frequently" argument comes up, the vast
>majority of those who make it most strongly are people whose
>contributions to the IETF -- in designer, editor, or other
>leadership roles-- have been fairly minimal.  Now, of course,
>some of them might argue that our current rules prevent them
>from contributing and that, if only we would let them submit
>documents written with the DeathRay word processor in Klingon
>script, not only would their productivity rise, but everyone
>else's would too --once we bought copies of DeathRay, learned
>Klingon, and persuaded UTC to get the characters into Unicode.
>
>However, that aside, assume that you are describing the new Mona
>Lisa protocol, and that it is really impossible to adequately
>describe the protocol without a high-resolution scale picture of
>the Mona Lisa overlaid with your coordinate system.  The ASCII
>form of your document could (and must under our current rules)
>describe the coordinate system, include all of the measurements,
>and describe what you are doing with them.  That text is
>normative (and the important thing is "the text", not whether it
>is in ASCII or not) and has to be.  But it is going to be _very_
>hard for anyone to understand your protocol without seeing the
>picture unless they have a good mental image of it.
>
>Under those conditions, our precedents are that you can probably
>convince the WG/WGchairs/ADs, and eventually the RFC Editor,
>that a PDF document containing a picture of the Mona Lisa and an
>ASCII document with
>
>       _        -----
>               /     \
>       _       | o o |
>               |  |  |
>               | __  |
>       _       |     |
>               \_____/
>       _
>             |   |  |  |
>
>as a substitute for that picture, with the marginal lines
>roughly identifying your grid marks and coordinate system, is
>"equivalent" or as close to it as one can get.  I would expect
>that to be a hard sell.  I, personally, would _want_ it to be a
>hard sell.  If it is really necessary, folks will figure out how
>to get the picture (maybe only the picture, which will probably
>not change from one version of the I-D to the next) to those who
>can't handle the PDF (or Postscript).  But we have done it
>before, all of the needed rules and procedures are in place, and
>nothing new is needed other than your understanding that you are
>going to have to get consensus that the artwork is vital before
>making that great a departure between the ASCII and the PDF
>versions.
>
> >> Similarly, when PDF has been posted in order to exhibit
> >> non-ASCII characters, it has proven helpful to have Unicode
> >> character offsets (i.e., U+nnnn representations)  in both the
> >> ASCII and PDF forms to ensure complete precision even though
> >> the character-glyphs themselves appear only in the PDF form.
> >>
> >> So, consider the first baby step to have been taken: nothing
> >> prevents you from posting an I-D in both ASCII and PDF today,
> >> and the relevant sub-community will sort out, on a case by
> >> case basis, whether the ASCII is good enough.
> >>
> > ...and if it's not the pdf version of the text including
> > graphics will become the RFC?
>
>No, they both become the RFC, and concerns about which one is
>"normative" are just distractions.   For standards-track
>documents, if it is posted as an official form of an RFC, it is
>normative.   But, the more whatever-is-in-the-PDF differs from
>whatever-is-in- the-ASCII --or, to put it differently, the more
>the text depends on images that appear only in the PDF rather
>than on the text standing alone or with ASCII art-- the harder
>it is going to be for you to convince the community, the IESG,
>and the RFC Editor that the PDF version is "equivalent" and, to
>the extent to which it is obviously not equivalent, sufficiently
>necessary to justify its posting.
>
>     john
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 09:16:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EusOX-0007lu-IZ; Fri, 06 Jan 2006 09:16:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EusOV-0007lm-98
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 09:16:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04083
	for ; Fri, 6 Jan 2006 09:15:22 -0500 (EST)
Received: from sccrmhc11.comcast.net ([63.240.77.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EusUC-0002z8-Ar
	for ietf@ietf.org; Fri, 06 Jan 2006 09:22:33 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (sccrmhc11) with SMTP
	id <2006010614161601100co4t5e>; Fri, 6 Jan 2006 14:16:16 +0000
Message-ID: <01b401c612cb$9d59b1c0$d0087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: "IETF General Discussion Mailing List" 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>	<43BD5BDE.4070905@WEIJax.com><43BD9BA0.2000204@swin.edu.au>
	<43BDAD26.9020909@WEIJax.com>
	
Date: Fri, 6 Jan 2006 08:15:14 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

So... here's the problem.

> Personally, I object to the suggestion that my "vote" should be  counted 
> one way or another if I am silent.  At most, it should be  counted as "no 
> strong opinion".  Or should I now start responding to  all the Last Calls 
> with "I don't care about this, so please don't  count me as supporting 
> it"?

Our technology support for "do we have consensus" stinks. We ask for 
feedback to a mailing list, knowing that "me, too" postings are (and should 
be) discouraged in most shared e-mail environments. What we get is exactly 
what you described - postings from a non-random subset of participants, and 
then we try to figure out what the sampling error is, and in which 
direction, based on not a lot more information. There is a safety mechanism, 
because when we REALLY miscount we can be appealed, but we don't use it 
often, and it's really an expensive mechanism to use.

Sometimes chairs even remember to say, "we also need to hear from people who 
AGREE", but not always. The mailing list archives would be even worse if 
everyone DID respond to all the Last Calls, so we need to be careful about 
what we ask for...

It shouldn't be a vote (we don't vote - I know you know this, because you 
put "vote" in quotes), but if we had some way to let people say "you know, I 
just don't care", that would help, too.

Spencer 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 09:25:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EusWa-0001nL-DG; Fri, 06 Jan 2006 09:25:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EusWX-0001kL-Qs
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 09:24:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04584
	for ; Fri, 6 Jan 2006 09:23:41 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuscR-0003E0-2o
	for ietf@ietf.org; Fri, 06 Jan 2006 09:31:04 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id B4D6A2596DC;
	Fri,  6 Jan 2006 15:23:49 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 17727-10; Fri,  6 Jan 2006 15:23:46 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id F03AA2596DB;
	Fri,  6 Jan 2006 15:23:45 +0100 (CET)
Date: Fri, 06 Jan 2006 15:28:43 +0100
From: Harald Tveit Alvestrand 
To: Sandy Wills , Ken Raeburn 
Message-ID: 
In-Reply-To: <43BE786D.6050006@WEIJax.com>
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms
	.marconi.com>	<43BD5BDE.4070905@WEIJax.com>	<43BD9BA0.2000204@swin.edu.au>
	<43BDAD26.9020909@WEIJax.com>	
	<43BE786D.6050006@WEIJax.com>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: IETF General Discussion Mailing List 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On fredag, januar 06, 2006 09:02:21 -0500 Sandy Wills  
wrote:

>     This is not a change; this seems to be the way the IETF works.  Many
> group gatherings work the same way; to me its an intuitive way of getting
> any/all objections brought up, or establishing that there aren't any,
> after a period of free discussion.
>     It's the same as at a wedding, when the preacher asks "if anyone
> objects, speak now, or forever hold your peace."  A CfC is assuming an
> agreement (or don't-care), and only those who do NOT agree need to
> respond.  Any other response is undesired.

In this case, we've already had the loud shouts of "no", so we're into the 
much more tricky case of either convincing the consensus-deciders that the 
naysayers are loud, argumentative loonies, or convincing the ones who asked 
for the "consensus call" that despite their strongly held convictions, 
there are good reasons why we shouldn't just do what they want.....

The CfC (if the original draft could be seen as one) has failed - or rather 
- succeded most brilliantly in proving that there is no present proposal 
that enjoys a strong consensus.

                   Harald



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 09:44:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euspp-0003De-H6; Fri, 06 Jan 2006 09:44:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euspm-0003DW-Nq
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 09:44:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05829
	for ; Fri, 6 Jan 2006 09:43:34 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.207])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eusvg-0003r5-7t
	for ietf@ietf.org; Fri, 06 Jan 2006 09:50:57 -0500
Received: by zproxy.gmail.com with SMTP id f1so3431666nzc
	for ; Fri, 06 Jan 2006 06:44:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=Wpe9ePVodfDpwts7RtSPymu9AQiL1dUQ0R1Bdo0rpaWxOXs0O2Jliw/l7iO7F/QqS4vnfZfzj8uciHP9yZwz3Vhjmhzfs7HpqtD9yEvuMF8nA+gv0+m59f/WB49f4BSN+jC0Q6+r0UvnGRsXAG5XZpvbLC1RlNIFIfeAkPBA6Z4=
Received: by 10.64.241.19 with SMTP id o19mr1889552qbh;
	Fri, 06 Jan 2006 06:44:48 -0800 (PST)
Received: by 10.64.193.12 with HTTP; Fri, 6 Jan 2006 06:44:48 -0800 (PST)
Message-ID: 
Date: Fri, 6 Jan 2006 09:44:48 -0500
From: Bill Fenner 
To: "Tom.Petch" 
In-Reply-To: <001a01c61235$62639d60$0601a8c0@pc6>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <001501c60670$36f0eaa0$0601a8c0@pc6>
	<001f01c607ad$08fa5d00$0601a8c0@pc6>
	<558a39a60601032150q6ff2cf26x603fea87309adb02@mail.gmail.com>
	<001a01c61235$62639d60$0601a8c0@pc6>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: quoted-printable
Cc: James Seng , ietf 
Subject: Re: ABNF Re: Troubles with UTF-8
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 1/5/06, Tom.Petch  wrote:
> You say that a Unicode code point can be represented by %xABCD but that i=
s not
> spelt out in ABNF [RFC4234].

ABNF uses non-negative integers to represent characters - note that it
explicitly doesn't specify a range (2nd sentence of section 2.3).  RFC
4234 specifies the encoding of those integers into ASCII, and says
that other encodings may be specified.  There's an implicit (obvious)
encoding of ABNF characters into Unicode, and as Misha pointed out the
IRI spec uses it - technically maybe it needs to be spelled out
somewhere.

>  And when it refers to 'one printable character' as
> '%x20-7E' I get the impressions that coded character sets like Unicode, w=
ith
> more than 256 code points, do not fall within its remit.

That's an example, which is probably missing the word "US-ASCII"
between "printable" and "character".

  Bill

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 10:17:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EutLV-0007HC-4v; Fri, 06 Jan 2006 10:17:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EutLS-0007Dn-F4
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 10:17:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07302
	for ; Fri, 6 Jan 2006 10:16:17 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EutRM-0004ec-6P
	for ietf@ietf.org; Fri, 06 Jan 2006 10:23:41 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3526635; Fri, 06 Jan 2006 10:15:23 -0500
In-Reply-To: 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms
	.marconi.com>	<43BD5BDE.4070905@WEIJax.com>	<43BD9BA0.2000204@swin.edu.au>
	<43BDAD26.9020909@WEIJax.com>	
	<43BE786D.6050006@WEIJax.com>
	
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Fri, 6 Jan 2006 10:17:25 -0500
To: Harald Tveit Alvestrand 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc: Ken Raeburn ,
	IETF General Discussion Mailing List ,
	Sandy Wills 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hello;

On Jan 6, 2006, at 9:28 AM, Harald Tveit Alvestrand wrote:

>
>
> --On fredag, januar 06, 2006 09:02:21 -0500 Sandy Wills  
>  wrote:
>
>>     This is not a change; this seems to be the way the IETF  
>> works.  Many
>> group gatherings work the same way; to me its an intuitive way of  
>> getting
>> any/all objections brought up, or establishing that there aren't any,
>> after a period of free discussion.
>>     It's the same as at a wedding, when the preacher asks "if anyone
>> objects, speak now, or forever hold your peace."  A CfC is  
>> assuming an
>> agreement (or don't-care), and only those who do NOT agree need to
>> respond.  Any other response is undesired.
>
> In this case, we've already had the loud shouts of "no", so we're  
> into the much more tricky case of either convincing the consensus- 
> deciders that the naysayers are loud, argumentative loonies, or  
> convincing the ones who asked for the "consensus call" that despite  
> their strongly held convictions, there are good reasons why we  
> shouldn't just do what they want.....
>

To me, this is the trouble with such proposals.

If there is a last call, and _nobody_ objects, then I think it is  
fair to say that the majority either
was in favor, or at least acquiesced. At least, if people complain  
later, you can say, "you should have spoken up when appropriate." (I  
suppose, for symmetry, that the same could be said against a proposal  
if there are only objections, and absolutely no support, but this  
must be rare indeed.)

But, as soon as there are _any_ objections, then people could remain  
silent saying to themselves "I agree" or "I don't care" or "I agree  
with the objections, which have been much better stated than I could  
do." You just don't know.

So, I regard it as improper to assume support either way from the  
"silent majority" if there is
any dissension at all. That doesn't mean that you can't have  
consensus in the face of objections, but
it does mean that you can't just wave them away by pointing to all  
the people who remain silent.

Regards
Marshall

> The CfC (if the original draft could be seen as one) has failed -  
> or rather - succeded most brilliantly in proving that there is no  
> present proposal that enjoys a strong consensus.
>
>                   Harald
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 10:24:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EutS4-0001ka-FJ; Fri, 06 Jan 2006 10:24:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EutS0-0001kO-8J
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 10:24:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07814
	for ; Fri, 6 Jan 2006 10:23:03 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EutXs-0004rx-Nc
	for ietf@ietf.org; Fri, 06 Jan 2006 10:30:27 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id EB8F9E006A; Fri,  6 Jan 2006 10:24:15 -0500 (EST)
To: "Ash, Gerald R (Jerry)" 
References: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EVS1.ugd.att.com>
From: Sam Hartman 
Date: Fri, 06 Jan 2006 10:24:15 -0500
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9870@KCCLUST06EVS1.ugd.att.com>
	(Gerald R. Ash's message of "Thu, 5 Jan 2006 08:25:51 -0600")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: Experiments as a Gateway to Process Change
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Ash," =3D=3D Ash, Gerald R (Jerry)  writes:

    Ash,> Happy New Year to all!  Many thanks to Yaakov for his
    Ash,> excellent handling of the list discussion.  I'm not very
    Ash,> surprised with the way it has gone.  D=E9j=E0 vu all over
    Ash,> again :-)

    Ash,> The challenge is to focus the discussion to try to reach
    Ash,> consensus on moving forward with a process change, i.e., we
    Ash,> need to take baby steps to make progress.

    Ash,> I'd suggest we try to reach consensus first on the
    Ash,> following: Alternative format(s) for IDs, in addition to
    Ash,> ASCII text, should be allowed.


I'd like to propose something I hope is simpler to act on.

I'd like to get in the habit of asking people who propose process
changes that are hard to get consensus on to conduct RFC 3933
experiments.  So in this particular case please restructure your draft
as in experiment.  Find some working groups or authors who would
benefit.  Find some rfc editor staff and an AD who would be willing to
help you out.  Propose a time limit and let's see if the world comes
to an end if we publish a few documents that are not in ASCII.  I
suspect we'll all survive.

I think there are a lot of good reasons why we should do this.

The first is that as part of evaluating plausibility of experiments we
can make sure that the experiment could take place.  It seems
reasonable to require that those wanting to change the process spend
the effort to make their changes possible.  "Hey.  I've got these
people over in the PWE3 working group who would really like to have
better diagrams in their specifications.  The AD says he would be able
to review the diagrams and thinks it might be more clear.  The rfc
editor says they have time and would be willing to try publishing a
few specs with diagrams if the community thinks it is reasonable," is
a lot more compelling as a starting point than "I want the process to
change.  I'm going to write text to change the process and you should
all approve it."  If in trying to put together the experiment you find
that no one actually would take advantage of your process change or
you find that people along the way don't have time to do additional
work required by your proposed change, then perhaps that's not where
we should be spending our process change energy.

Second, a lot of objections (more so for other process changes than
for this one) fall into the category of "That will never work," or
"that will drown us all in additional paperwork."  The nice thing
about experiments is that they can be constructed so that
participation is optional and so that you have flow control at all
stages.  "Well, it will either work or not.  If it doesn't we will
delay a few documents or efforts that agreed to participate in the
experiment," is a more compelling response than "It will work fine!
I'm willing to risk the entire IETF process on it!"  Even if you are
absolutely sure it will work fine, what harm is there in starting out
slow?  Also, opt-in experiments are an excellent response to questions
about whether something is useful.  If you start out with enough
people who think it is to justify the IESG review cycle and
publication of an experimental RFC, then you have a strong response to
those who question utility: "We think it is useful; let us waste our
own time.  We will either be right or wrong."

Another good thing about experiments is that they often do get people
to become familiar with something and that tends to defuse a lot of
negative feelings steming from anxiety about change.  I certainly know
I've had strong negative reactions to things in the past and have
reluctantly agreed to try something.  Typically I find it is not
nearly as bad as I had feared.  Sometimes I find that I was completely
right but that I have significant evidence to point to now helping
others understand the problem.  I don't think I'm atypical in this
regard.

Finally, I'm hoping that we can build a culture of constructive
progress around experiments.  I think we have consensus that the IETF
needs to change and evolve.  Perhaps we can come to consensus that
experiments are a way we can make forward progress.  We may not all
like the experiments but perhaps e can decide that a culture in which
we've all agreed to constructively work towards conducting plausible
experiments is the best compromise we can come up with.  I'm hoping
that we can get to a point where it is culturally unacceptable to
object to plausible experiments without explaining what the proponents
of the experiment would need to do in order to get around the
objection.  I'm also hoping that we can get to a culture where the
response to a long flame war like this quickly becomes "Well, write it
up, convince the people whose work would be influenced to give it a
try and let's go for it."  There will still need to be a lot of
compromise; when people have concerns we will need to try and find
ways of collecting the data we need to evaluate the change.  We
probably want to establish a culture of conducting experiments anyway
even if we understand that there are some questions they will not
answer.  For example I think an experiment about alternative RFC
formats is valuable even though there is no way it will answer
questions about the archival value of things other than ASCII.  Still,
if we get to a point where that is the only open question we will have
made significant progress.

Now, there is one thing that people may not like about how I've tried
to define plausible.  I claim that the proponents of an experiment
need to convince people who would be doing work to join the
experiment.  Implicit in that is the idea that if you are going to
change how the IESG does things, you need to recruit an IESG member at
a minimum.  If you want to try a new way of running a working group,
you need to find a WG chair.  If you want the RFC editor to do
something different, you need to convince someone from their staff
that they should go along.  I think this is a fairly important
constraint because it prevents people from being over committed.  It
also provides somewhat of a selection criteria for experiments: we
work on the ones that attract interest at the right places.

One possible objection is that the IESG or other leadership could
starve out experiments.  I think it is fair to ask the IESG what
experiments it is working on and if the IESG is not spending time
supporting process change experiments to complain and demand
improvement.  It doesn't bother me that the IESG will end up being
able to focus energy on experiments that the IESG believes are most
beneficial/interesting.  That does sound like a management
responsibility that it is reasonable for the IESG to be involved in.
If you don't like the results you can try and convince the IESG to
change, you can give feedback to nomcom or in extreme cases you can
dust off that recall petition you've had sitting on your shelf.

So, a challenge.  Let's see if we can put together a plausible
experiment for this or some other topic that interests the community.
Let's see if we can get a well-oiled RFC 3933 process running and
let's go improve our organization while building a better Internet. =20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 10:40:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euthj-0000HP-8x; Fri, 06 Jan 2006 10:40:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euthg-0000H6-R9
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 10:40:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08863
	for ; Fri, 6 Jan 2006 10:39:13 -0500 (EST)
Received: from mtagate4.de.ibm.com ([195.212.29.153])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EutnY-0005MH-6F
	for ietf@ietf.org; Fri, 06 Jan 2006 10:46:37 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id k06FeEln243760
	for ; Fri, 6 Jan 2006 15:40:14 GMT
Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com
	[9.149.165.229])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k06FeE1n174056 for ; Fri, 6 Jan 2006 16:40:14 +0100
Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k06FeDTm018934 for ; Fri, 6 Jan 2006 16:40:13 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k06FeCma018926; Fri, 6 Jan 2006 16:40:12 +0100
Received: from zurich.ibm.com (sig-9-145-249-81.de.ibm.com [9.145.249.81])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA80470;
	Fri, 6 Jan 2006 16:40:11 +0100
Message-ID: <43BE8F58.4020901@zurich.ibm.com>
Date: Fri, 06 Jan 2006 16:40:08 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C886267@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886267@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: John C Klensin , "Ash,
	Gerald R \\\(Jerry\\\)" , ietf@ietf.org,
	'Stewart Bryant' 
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Gray, Eric wrote:
> Stewart,
>  
>     You bring up a good point.  I have been assuming that - since 
> IDs can be submitted in multiple formats - that the additional
> formats would also become part of the RFC library on publication.
>  
>     I just took a quick peek at the RFCs and there does not appear 
> to be a single example of a version that is not in text format.  I 
> don't know if that is because they are not stored in the same place, 
> or they are not carried forward as part of the publishing process.

You must have looked in the wrong place. Where there are PS or PDF
versions, they can be found via the search page at
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl

It's less clear that all mirror sites carry them.

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 10:46:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eutmy-0002Qx-LH; Fri, 06 Jan 2006 10:46:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eutmv-0002QM-PN
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 10:45:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09326
	for ; Fri, 6 Jan 2006 10:44:40 -0500 (EST)
Received: from mtagate2.de.ibm.com ([195.212.29.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eutsp-0005Y5-J5
	for ietf@ietf.org; Fri, 06 Jan 2006 10:52:05 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k06FjkI5203118
	for ; Fri, 6 Jan 2006 15:45:47 GMT
Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com
	[9.149.165.212])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k06Fjk1n128788 for ; Fri, 6 Jan 2006 16:45:46 +0100
Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k06FjjHC017265 for ; Fri, 6 Jan 2006 16:45:46 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k06FjjMf017240; Fri, 6 Jan 2006 16:45:45 +0100
Received: from zurich.ibm.com (sig-9-145-249-81.de.ibm.com [9.145.249.81])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA63926;
	Fri, 6 Jan 2006 16:45:44 +0100
Message-ID: <43BE90A5.5070400@zurich.ibm.com>
Date: Fri, 06 Jan 2006 16:45:41 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: "Ash, Gerald R \(Jerry\)" 
References: <9473683187ADC049A855ED2DA739ABCA09FA9873@KCCLUST06EVS1.ugd.att.com>
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9873@KCCLUST06EVS1.ugd.att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: John C Klensin , ietf@ietf.org,
	Stewart Bryant 
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ash, Gerald R (Jerry) wrote:
>>>Unless the IESG has changed the rules while I was not looking,
>>>it has been permitted to post I-Ds in PDF in addition to ASCII
>>>for some years. 
> 
> 
>>BUT the pdf is not allowed to be normative. 
> 
> 
> Right.  The ASCII version is the only normative format.  Furthermore,
> all diagrams, no matter how complex in the PDF version, must be
> converted to ASCII stick figures in the normative ASCII version.  There
> are no tools I'm aware of to aid that conversion, and in many cases much
> is lost in the conversion.
> 
> 
>>Changing that rule alone would be sufficient to allow modern
>>graphics to be called up in normative texts.

It would, and the same would apply to mathematical formulae.

As a matter of fact, the relatively unmodern RFC 1119 that John mentioned
does use some graphics and mathematics that would be annoying to
code in ASCII. We can certainly ask the question whether that is a big
enough benefit to be worth the cost.

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 10:50:40 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EutrT-0003sW-VJ; Fri, 06 Jan 2006 10:50:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EutrS-0003sR-2J
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 10:50:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09687
	for ; Fri, 6 Jan 2006 10:49:20 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EutxN-0005ho-49
	for ietf@ietf.org; Fri, 06 Jan 2006 10:56:45 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 0E4AFE0075; Fri,  6 Jan 2006 10:50:41 -0500 (EST)
To: "Spencer Dawkins" 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>
	<43BD5BDE.4070905@WEIJax.com> <43BD9BA0.2000204@swin.edu.au>
	<43BDAD26.9020909@WEIJax.com>
	
	<01b401c612cb$9d59b1c0$d0087c0a@china.huawei.com>
From: Sam Hartman 
Date: Fri, 06 Jan 2006 10:50:41 -0500
In-Reply-To: <01b401c612cb$9d59b1c0$d0087c0a@china.huawei.com> (Spencer
	Dawkins's message of "Fri, 6 Jan 2006 08:15:14 -0600")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: IETF General Discussion Mailing List 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Spencer" == Spencer Dawkins  writes:

    Spencer> So... here's the problem.
    >> Personally, I object to the suggestion that my "vote" should be
    >> counted one way or another if I am silent.  At most, it should
    >> be counted as "no strong opinion".  Or should I now start
    >> responding to all the Last Calls with "I don't care about this,
    >> so please don't count me as supporting it"?

    Spencer> Our technology support for "do we have consensus"
    Spencer> stinks. We ask for feedback to a mailing list, knowing
    Spencer> that "me, too" postings are (and should be) discouraged
    Spencer> in most shared e-mail environments. What we get is
    Spencer> exactly what you described - postings from a non-random
    Spencer> subset of participants, and then we try to figure out
    Spencer> what the sampling error is, and in which direction, based
    Spencer> on not a lot more information. There is a safety
    Spencer> mechanism, because when we REALLY miscount we can be
    Spencer> appealed, but we don't use it often, and it's really an
    Spencer> expensive mechanism to use.

I'm not sure I consider this very broken.  If I'm reading a last call
and I have opinions that differ from the way the discussion is going,
I'm certainly going to speak up.  It seems to work fairly well in
practice at determining rough consensus when there is a rough
consensus to be determined.  It gives questionable results in cases
where the results are questionable; I'm not sure this a bug.

    Spencer> some way to let people say "you know, I just don't care",
    Spencer> that would help, too.

And what do we do with those people anyway?  How would it help me to
know there are 30 people who don't care?


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 10:52:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eutt9-0004ok-OD; Fri, 06 Jan 2006 10:52:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eutt7-0004oe-UG
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 10:52:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09870
	for ; Fri, 6 Jan 2006 10:51:02 -0500 (EST)
Received: from mtagate1.uk.ibm.com ([195.212.29.134])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eutyy-0005mb-92
	for ietf@ietf.org; Fri, 06 Jan 2006 10:58:26 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k06FpJsE041664
	for ; Fri, 6 Jan 2006 15:51:21 GMT
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com
	[9.149.37.216])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k06FpJpI138232 for ; Fri, 6 Jan 2006 15:51:19 GMT
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k06FpI7L018476 for ; Fri, 6 Jan 2006 15:51:18 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k06FpGiJ018412; Fri, 6 Jan 2006 15:51:16 GMT
Received: from zurich.ibm.com (sig-9-145-249-81.de.ibm.com [9.145.249.81])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA63830;
	Fri, 6 Jan 2006 16:51:15 +0100
Message-ID: <43BE91EF.3050006@zurich.ibm.com>
Date: Fri, 06 Jan 2006 16:51:11 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Melinda Shore 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: participation sans meeting attendance (was RE: Alternative
 formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Melinda Shore wrote:
> On 1/2/06 11:32 PM, "Jeffrey Hutzelman"  wrote:
> 
>>I think we're doing better on this front than we have in many
>>years.
> 
> 
> The technical support for remote participation really has become
> terrific.  Some sessions are run with great sensitivity to remote
> participation, others are not - it depends on the chairs.  However,
> on the other hand it does seem as if groups have become more
> likely to make "final" decisions during meetings and not on
> mailing lists.  

I'd like to point out that this would be an appealable process failure,
i.e. there should always be (at the minimum) an email call for consensus
about decisions embedded in the minutes, and important decisions should
certainly have their own email consensus call.

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 11:34:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuuYN-0007d3-Fg; Fri, 06 Jan 2006 11:34:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euu2T-0001lu-Q6
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 11:02:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10559
	for ; Fri, 6 Jan 2006 11:00:44 -0500 (EST)
Received: from ranger.systems.pipex.net ([62.241.162.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euu8N-00067z-Nl
	for ietf@ietf.org; Fri, 06 Jan 2006 11:08:09 -0500
Received: from pc6 (1Cust211.tnt101.lnd4.gbr.da.uu.net [213.116.50.211])
	by ranger.systems.pipex.net (Postfix) with SMTP id 1F60DE0002B6;
	Fri,  6 Jan 2006 16:01:35 +0000 (GMT)
Message-ID: <01d101c612d1$b2733f80$0601a8c0@pc6>
From: "Tom Petch" 
To: "Misha Wolf" 
References: 
Date: Fri, 6 Jan 2006 15:42:11 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 06 Jan 2006 11:34:57 -0500
Cc: ietf 
Subject: Re: ABNF Re: Troubles with UTF-8
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

----- Original Message -----
From: "Misha Wolf" 
To: "Tom.Petch" 
Cc: "ietf" 
Sent: Thursday, January 05, 2006 10:53 PM
Subject: RE: ABNF Re: Troubles with UTF-8


> See:
>    2.2.  ABNF for IRI References and IRIs
> in:
>    http://www.ietf.org/rfc/rfc3987.txt=20
>
> Misha
>
Misha

Yes, spot on, thanks for that; I had read the IRI RFC and forgotten it.  There
is a (Standards Track) precedent for specifying UCS in ABNF.

Tom Petch

>
> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
> Tom.Petch
> Sent: 05 January 2006 20:15
> To: James Seng
> Cc: ietf
> Subject: ABNF Re: Troubles with UTF-8
>
> You say that a Unicode code point can be represented by %xABCD but that
> is not
> spelt out in ABNF [RFC4234].  And when it refers to 'one printable
> character' as
> '%x20-7E' I get the impressions that coded character sets like Unicode,
> with
> more than 256 code points, do not fall within its remit.  I have yet to
> see any
> use of this in an I-D or RFC. I did post a question about this to this
> list on
> 24th December and the lack of response reinforces my view that this is
> uncharted
> territory.
>
> Tom Petch
>
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 12:50:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuvjQ-0005f8-Fx; Fri, 06 Jan 2006 12:50:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvjN-0005ex-Hw
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 12:50:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17787
	for ; Fri, 6 Jan 2006 12:49:09 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuvpI-0000xA-Ah
	for ietf@ietf.org; Fri, 06 Jan 2006 12:56:33 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k06HnCi13739;
	Fri, 6 Jan 2006 09:49:12 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id JAA09268;
	Fri, 6 Jan 2006 09:49:12 -0800 (PST)
Date: Fri, 6 Jan 2006 09:49:12 -0800 (PST)
Message-Id: <200601061749.JAA09268@gra.isi.edu>
To: ietf@ietf.org, jefsey@jefsey.com
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
Subject: Re: ancients-moderns dispute (was: PDF, Postscript, and
 "normative" versions (was: Re: Baby Steps (was RE: Alternative formats
 for IDs)))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


  *> 
  *> Why not to just to proceed step by step and experiment? Let create an 
  *> optional non-ascii art RFC-Editor repositories, for images quoted in 
  *> RFCs. This will not permit non-ASCII art to be normative but will 
  *> permit non-ASCII art to be _better_ descriptive in a first time. 
  *> Experience will show if there are many such images. If there is a 
  *> real need for normative non-ASCII art, it will provide experience to 
  *> create a non-ASCII art IANA registry making sure they will survive, 
  *> at an adeqate place.
  *> 
  *> jfc

This has been in place for many years, in the form of PS and/or
PDF versions of RFCs.  What am I missing?

Bob Braden


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 12:55:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euvno-0006KG-Jt; Fri, 06 Jan 2006 12:55:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euvnl-0006K2-JU
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 12:54:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18041
	for ; Fri, 6 Jan 2006 12:53:41 -0500 (EST)
Received: from ms-smtp-01-smtplb.tampabay.rr.com ([65.32.5.131]
	helo=ms-smtp-01.tampabay.rr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euvtf-00015c-KH
	for ietf@ietf.org; Fri, 06 Jan 2006 13:01:05 -0500
Received: from WEIJax.com (131-37.121-70.tampabay.res.rr.com [70.121.37.131])
	by ms-smtp-01.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id
	k06Hsg7S020074; Fri, 6 Jan 2006 12:54:43 -0500 (EST)
Message-ID: <43BEAE5C.1040705@WEIJax.com>
Date: Fri, 06 Jan 2006 12:52:28 -0500
From: Sandy Wills 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF General Discussion Mailing List 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms	.marconi.com>	<43BD5BDE.4070905@WEIJax.com>	<43BD9BA0.2000204@swin.edu.au>	<43BDAD26.9020909@WEIJax.com>		<43BE786D.6050006@WEIJax.com>	
	
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit
Cc: Ken Raeburn ,
	Harald Tveit Alvestrand 
Subject: Trying to invent a way of determining "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Are you guys taking turns, saying the same thing over and over again?

For the record, I'm not taking sides in any of the current questions 
about ASCII/Word/AmiPro/etc, or DKIM, or the other discussions filling 
my inbox.  I'm trying to come up with a way for the participants in 
those discussions to determine if they are done yet.

I am proposing a formal construct, called a "Call for Concensus", or 
appreviated as "CfC" (because I'm lazy and can't spell that third word 
the same way two times in a row anyway), for a specific purpose: to 
determine if we have reached an agreement during a discussion.

It is _not_ used _IN_ a discussion, it is used when the discussers are 
tired of the endless circles that these discussions turn in, _AFTER_ all 
the different options have been mentioned.

In order for such a test to work, it MUST be posted as a statement, 
which can be agreed with, or not.  Simple enough.  In order to cut down 
on the noise level, you word the statement such that it includes the 
supposed-agreement.  People who agree don't need to reply.  People who 
don't care, either from lack of expertise or apathy, don't need to 
reply.  ONLY PEOPLE WHO OBJECT to that statement should reply to the 
CfC.  If you have a rough idea of how many people received the CfC post, 
and you can easily see how many people objected, then you can easily see 
if your statement does, in fact, state a concensus agreement.

I don't see how this can be too complicated for people who create software.

The CfC is not part of the "discussion".  It is a test to see if the 
discussion has had a result.

Is this a bad idea?  I don't think so, but I keep getting replies, from 
differing posters, with differing words, that all evaluate to "But 
someone will disagree, and then you can't tell...."  Yes, you can.

There are only four meaningful groups of people here, the matrix of 
care/don't care and agree/don't agree:

   Anyone who disagrees with the CfC statement, but didn't reply, is too 
apathetic to participate.  Don't count them, because they themselves 
don't think that their opinion is worth your time.

   Anyone who agrees, and did reply, has trouble understanding 
instructions like "Only reply to this CfC if you disagree".  Given that, 
should these people be making decisions for the group?.

   Who's left?  The two groups that we care about:

   Anyone who disagrees, and replies, will have their voices heard, 
because their opinion is the one asked for by the CfC.  If their 
objections (or volume) are significant, then the discussion will turn to 
ways to make progress while satisfying their concerns.

   Anyone who agrees with the CfC statement, and doesn't say anything, 
is fine, because the CfC doesn't need or want their support.  The CfC 
will stand or fall based upon the size of the "disagree and replied" group.


Marshall Eubanks wrote:
> 
> If there is a last call, and _nobody_ objects, then I think it is  fair 
> to say that the majority either
> was in favor, or at least acquiesced. At least, if people complain  
> later, you can say, "you should have spoken up when appropriate." (I  
> suppose, for symmetry, that the same could be said against a proposal  
> if there are only objections, and absolutely no support, but this  must 
> be rare indeed.)
> 
> But, as soon as there are _any_ objections, then people could remain  
> silent saying to themselves "I agree" or "I don't care" or "I agree  
> with the objections, which have been much better stated than I could  
> do." You just don't know.
> 
> So, I regard it as improper to assume support either way from the  
> "silent majority" if there is
> any dissension at all. That doesn't mean that you can't have  consensus 
> in the face of objections, but
> it does mean that you can't just wave them away by pointing to all  the 
> people who remain silent.
> 
> Regards
> Marshall


-- 
Unable to locate coffee.
Operator halted.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 13:07:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euvzp-0003x8-AU; Fri, 06 Jan 2006 13:07:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euvzn-0003x0-0G
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 13:07:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19030
	for ; Fri, 6 Jan 2006 13:06:07 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euw5g-0001X2-KK
	for ietf@ietf.org; Fri, 06 Jan 2006 13:13:31 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k06I6Vi20594;
	Fri, 6 Jan 2006 10:06:31 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA09296;
	Fri, 6 Jan 2006 10:06:31 -0800 (PST)
Date: Fri, 6 Jan 2006 10:06:31 -0800 (PST)
Message-Id: <200601061806.KAA09296@gra.isi.edu>
To: Eric.Gray@marconi.com, brc@zurich.ibm.com
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: ietf@ietf.org
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

  *> >  
  *> >     I just took a quick peek at the RFCs and there does not appear 
  *> > to be a single example of a version that is not in text format.  I 
  *> > don't know if that is because they are not stored in the same place, 
  *> > or they are not carried forward as part of the publishing process.
  *> 

You must not be looking at the official RFC repository maintained by
the RFC Editor.  For Unix fans, looking at the ~in-notes directory:

31% ls -al rfc*.ps|wc
      55     440    3127
32% ls -al rfc*.pdf|wc
      54     432    3124

That is, there are 55 Postscript RFCs and 54 PDF RFCs (they don't
exactly match because some early Postscript files could not be
converted to PDF).

Bob Braden

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 13:17:11 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euw9H-0006n0-C7; Fri, 06 Jan 2006 13:17:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euw9F-0006lX-4E
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 13:17:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19687
	for ; Fri, 6 Jan 2006 13:15:52 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwF9-0001oc-SS
	for ietf@ietf.org; Fri, 06 Jan 2006 13:23:17 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k06IGvdJ001759; Fri, 6 Jan 2006 13:16:57 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10054; 
	Fri, 6 Jan 2006 13:16:57 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Fri, 6 Jan 2006 13:16:56 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886280@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Sandy Wills'" , Ken Raeburn 
Date: Fri, 6 Jan 2006 13:16:55 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: IETF General Discussion Mailing List 
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--> 
-->     "I think we have reached substantial agreement on the following 
--> statement:  ASCII text was good enough for my Grandfather, and it's 
--> going to be good enough for my grandchildren.  Please reply to this
--> CfC if you object."
--> 

I object.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 13:20:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuwCt-0007lb-Mc; Fri, 06 Jan 2006 13:20:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwCr-0007lW-Ac
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 13:20:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19988
	for ; Fri, 6 Jan 2006 13:19:37 -0500 (EST)
Received: from xenotime.net ([66.160.160.81])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuwIm-0001vc-0w
	for ietf@ietf.org; Fri, 06 Jan 2006 13:27:01 -0500
Received: from shark.he.net ([66.160.160.2]) by xenotime.net for
	; Fri, 6 Jan 2006 10:20:46 -0800
Date: Fri, 6 Jan 2006 10:20:46 -0800 (PST)
From: "Randy.Dunlap" 
X-X-Sender: rddunlap@shark.he.net
To: "Gray, Eric" 
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886280@whq-msgusr-02.pit.comms.marconi.com>
Message-ID: 
References: <313680C9A886D511A06000204840E1CF0C886280@whq-msgusr-02.pit.comms.marconi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: Ken Raeburn ,
	IETF General Discussion Mailing List ,
	'Sandy Wills' 
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Fri, 6 Jan 2006, Gray, Eric wrote:

> -->     "I think we have reached substantial agreement on the following
> --> statement:  ASCII text was good enough for my Grandfather, and it's
> --> going to be good enough for my grandchildren.  Please reply to this
> --> CfC if you object."

IMO an objection should be required to also have an explanation.

> I object.

Why?  to which parts?  the grandfather/grandchildren?

-- 
~Randy

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 13:21:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuwD7-0007ut-Cs; Fri, 06 Jan 2006 13:21:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwD4-0007u6-Qg
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 13:21:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19999
	for ; Fri, 6 Jan 2006 13:19:50 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwJ0-0001vl-TA
	for ietf@ietf.org; Fri, 06 Jan 2006 13:27:15 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k06IKvdJ001871; Fri, 6 Jan 2006 13:20:57 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA10572; 
	Fri, 6 Jan 2006 13:20:56 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Fri, 6 Jan 2006 13:20:54 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886281@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Spencer Dawkins'" 
Date: Fri, 6 Jan 2006 13:20:45 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: IETF General Discussion Mailing List 
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Spencer,

--> 
--> It shouldn't be a vote (we don't vote - I know you know this, because
you 
--> put "vote" in quotes), but if we had some way to let people say "you
know,
--> I just don't care", that would help, too.
--> 

I agree, and it could also be very useful should we ever start
to realize that it is important to gauge who is paying attention
as well as who is subscribed.

--> Spencer 
--> 
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 13:27:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuwJC-0002PH-FT; Fri, 06 Jan 2006 13:27:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwJ8-0002P4-Qb
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 13:27:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20551
	for ; Fri, 6 Jan 2006 13:26:06 -0500 (EST)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwP4-0002Ai-2y
	for ietf@ietf.org; Fri, 06 Jan 2006 13:33:31 -0500
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	k06IR5oS025620
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 6 Jan 2006 10:27:06 -0800
Received: from [129.46.225.69] (dhcp-campbell-23.qualcomm.com [129.46.225.69])
	by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	k06IR2Yg021102; Fri, 6 Jan 2006 10:27:03 -0800 (PST)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <43BE786D.6050006@WEIJax.com>
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.
	com>	<43BD5BDE.4070905@WEIJax.com>	<43BD9BA0.2000204@swin.edu.au>
	<43BDAD26.9020909@WEIJax.com>
	
	<43BE786D.6050006@WEIJax.com>
Date: Fri, 6 Jan 2006 10:27:01 -0800
To: Sandy Wills , Ken Raeburn 
From: Ted Hardie 
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: IETF General Discussion Mailing List 
Subject: Digression was-Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 9:02 AM -0500 1/6/06, Sandy Wills wrote:
>When you got married, did you want every person in the audience to stand up and say "I'm okay with this marriage!"?  No, you wanted the entire room silent, so that you could hear any objection.


Hi,
	This is a digression.  Hit delete now unless you're willing to digress.	

	Speaking as a liturgical die-hard, let me just note that the affirmative
*is* asked in many forms of the marriage ceremony.  In the Episcopal church,
for example, the question takes this form:
 
(Celebrant)
Will all of you witnessing these promises do all in your power to uphold these two persons in their marriage?

(People)
We will.

(see http://vidicon.dandello.net/bocp/bocp4.htm for the full text)

	This requires that those who are present at the wedding take the affirmative step
of saying they will support the marriage, which is considerably more than "I'm okay with this".
For many who see marriage in sacramental terms, this single statement is why the sacrament
is a public one, rather than a private one.  The key sacramental act here is the commitment
of the two people to throw their lot in together and be a family; it does not need onlookers
(or even a celebrant, as the individuals can exchange vows without one).  But the public act
is a request for the support of the community for the marriage and is the public participation in the
sacrament.
	I think there is far too much treating of IETF documents like holy writ now, so
I not only would not draw a parallel here, I actively discourage any one else from doing so.
This, in other words, is pure digression.  Don't say I didn't warn you.
				
				Ted

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 13:55:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euwkb-0006Nm-94; Fri, 06 Jan 2006 13:55:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwkZ-0006MN-AR
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 13:55:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22468
	for ; Fri, 6 Jan 2006 13:54:27 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwqU-00031M-Pn
	for ietf@ietf.org; Fri, 06 Jan 2006 14:01:52 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k06ItWdJ002872; Fri, 6 Jan 2006 13:55:32 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15650; 
	Fri, 6 Jan 2006 13:55:27 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Fri, 6 Jan 2006 13:55:26 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886282@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Randy.Dunlap'" 
Date: Fri, 6 Jan 2006 13:54:59 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: Ken Raeburn ,
	IETF General Discussion Mailing List ,
	'Sandy Wills' 
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Randy,

	Nosey, aren't we?  :-) 

	If you must know, let's see:  one grandfather worked in a
machine shop during WWII, retired in the late 50s; the other was 
in the Army for WWI and a farmer, sawyer, moon-shiner and road 
worker the rest of his life (being a farmer isn't a living, it's 
a hobby).  I doubt ASCII figured much into either of their lives.

	ASCII isn't good enough for me, but PDF is useful where the
problem is really bad.  Between them (counting PS as a variation
of PDF - especially since I have to convert PS to PDF to read it)
they are what there is.

	I don't even pretend to know what will be good for my own
grandchildren because - so far - I don't even know that I will
ever have any.

	My point in making a terse response was that all that was 
asked for was objections.  Sometimes, reasons are neither asked
for nor needed.

	I suspect that - now that you know the reasons - you might
agree that this was one of those times...

--
Eric

--> -----Original Message-----
--> From: Randy.Dunlap [mailto:rdunlap@xenotime.net] 
--> Sent: Friday, January 06, 2006 1:21 PM
--> To: Gray, Eric
--> Cc: 'Sandy Wills'; Ken Raeburn; IETF General Discussion Mailing List
--> Subject: RE: objection to proposed change to "consensus"
--> 
--> On Fri, 6 Jan 2006, Gray, Eric wrote:
--> 
--> > -->     "I think we have reached substantial agreement on 
--> the following
--> > --> statement:  ASCII text was good enough for my 
--> Grandfather, and it's
--> > --> going to be good enough for my grandchildren.  Please 
--> reply to this
--> > --> CfC if you object."
--> 
--> IMO an objection should be required to also have an explanation.
--> 
--> > I object.
--> 
--> Why?  to which parts?  the grandfather/grandchildren?
--> 
--> -- 
--> ~Randy
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 13:57:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Euwm5-0007MG-5i; Fri, 06 Jan 2006 13:57:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Euwm3-0007M3-FG
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 13:57:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22652
	for ; Fri, 6 Jan 2006 13:55:59 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euwry-00035s-SM
	for ietf@ietf.org; Fri, 06 Jan 2006 14:03:24 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k06Iuhi05475;
	Fri, 6 Jan 2006 10:56:43 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA09340;
	Fri, 6 Jan 2006 10:56:43 -0800 (PST)
Date: Fri, 6 Jan 2006 10:56:43 -0800 (PST)
Message-Id: <200601061856.KAA09340@gra.isi.edu>
To: sandy@WEIJax.com
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: ietf@ietf.org
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


  *> 
  *> --> 
  *> -->     "I think we have reached substantial agreement on the following 
  *> --> statement:  ASCII text was good enough for my Grandfather, and it's 
  *> --> going to be good enough for my grandchildren.  Please reply to this
  *> --> CfC if you object."
  *> --> 
  *> 

"Are we all in favor of Motherhood and Apple Pie?"  "Well, mostly."

No one (well, the IETF is a big tent, so that's probably too strong...
almost no one) questions the desirability of a better format for
publishing RFCs than pure ASCII text.  This has been the subject of
repeated discussions over the last 20 years.  Will the same discussion
be taking place 20 years from now?  I, for one, certainly hope not.

However, simply wishing we had a better solution is not enough.  We
need to have such a reasonable solution in hand before we agree to
adopt it.  We believe we want vendor neutrality, ubiquity, convenience,
searchability, editability, etc..  The obvious, simple suggestions have
all failed on one criterion or another, and ASCII has continued to be
the best (if flawed) compromise.

For many years, PS and PDF files have been allowed as secondary formats
for RFCs.  (You can find them by searching rfc-index.txt for the
strings 'PS=' and 'PDF=', respectively).  This provision does not
handle things like state diagrams, which are presumably normative.  In
practice, creating the PS/PDF forms has been a major pain, because the
documentswere created by the authors using a wide variety of
different editors and tools.

On the other hand, it does appear that the availability of ASCII
support as a common denominator is decreasing over time.  As has been
observed, some software vendors seem to go out of their way to make
simple ASCII hard to use.  So there is increasing pressure to find
a (truly) better solution.

Bob Braden

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 14:33:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuxLM-0005px-El; Fri, 06 Jan 2006 14:33:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxLK-0005pi-2I
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 14:33:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27713
	for ; Fri, 6 Jan 2006 14:32:25 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuxRF-0004wa-L9
	for ietf@ietf.org; Fri, 06 Jan 2006 14:39:51 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 06 Jan 2006 20:33:29 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k06JXPFZ026082; 
	Fri, 6 Jan 2006 20:33:26 +0100 (MET)
Received: from [10.61.64.108] (ams-clip-vpn-dhcp108.cisco.com [10.61.64.108])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA11946;
	Fri, 6 Jan 2006 19:33:23 GMT
Message-ID: <43BEC603.6050704@cisco.com>
Date: Fri, 06 Jan 2006 19:33:23 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Randy.Dunlap" 
References: <313680C9A886D511A06000204840E1CF0C886280@whq-msgusr-02.pit.comms.marconi.com>
	
In-Reply-To: 
X-Spam-Score: 1.4 (+)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: Ken Raeburn ,
	IETF General Discussion Mailing List ,
	'Sandy Wills' 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0725706122=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0725706122==
Content-Type: multipart/alternative;
	boundary="------------020706060304010608040802"

This is a multi-part message in MIME format.
--------------020706060304010608040802
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Randy.Dunlap wrote:

>On Fri, 6 Jan 2006, Gray, Eric wrote:
>
>  
>
>>-->     "I think we have reached substantial agreement on the following
>>--> statement:  ASCII text was good enough for my Grandfather, and it's
>>--> going to be good enough for my grandchildren.  Please reply to this
>>--> CfC if you object."
>>    
>>
>
>IMO an objection should be required to also have an explanation.
>
>  
>
>>I object.
>>    
>>
>
>Why?  to which parts?  the grandfather/grandchildren?
>
>  
>
OK, I object on the basis that ASCII diagrams are inadequate for
our purposes.

- Stewart

--------------020706060304010608040802
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Randy.Dunlap wrote:



  
On Fri, 6 Jan 2006, Gray, Eric wrote:

  

  

    
-->     "I think we have reached substantial agreement on the following
--> statement:  ASCII text was good enough for my Grandfather, and it's
--> going to be good enough for my grandchildren.  Please reply to this
--> CfC if you object."
    

  

  

IMO an objection should be required to also have an explanation.

  

  

    
I object.
    

  

  

Why?  to which parts?  the grandfather/grandchildren?

  



OK, I object on the basis that ASCII diagrams are inadequate for

our purposes.



- Stewart





--------------020706060304010608040802--


--===============0725706122==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0725706122==--




From ietf-bounces@ietf.org Fri Jan 06 15:26:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuyAo-00089u-Vu; Fri, 06 Jan 2006 15:26:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuyAn-00089k-H2
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 15:26:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04886
	for ; Fri, 6 Jan 2006 15:25:36 -0500 (EST)
Received: from xenotime.net ([66.160.160.81])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EuyGj-0007Vv-GU
	for ietf@ietf.org; Fri, 06 Jan 2006 15:33:03 -0500
Received: from shark.he.net ([66.160.160.2]) by xenotime.net for
	; Fri, 6 Jan 2006 12:26:47 -0800
Date: Fri, 6 Jan 2006 12:26:47 -0800 (PST)
From: "Randy.Dunlap" 
X-X-Sender: rddunlap@shark.he.net
To: "Gray, Eric" 
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886282@whq-msgusr-02.pit.comms.marconi.com>
Message-ID: 
References: <313680C9A886D511A06000204840E1CF0C886282@whq-msgusr-02.pit.comms.marconi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: Ken Raeburn ,
	IETF General Discussion Mailing List ,
	'Sandy Wills' 
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Fri, 6 Jan 2006, Gray, Eric wrote:

> Randy,
>
> 	Nosey, aren't we?  :-)

Nah, I was interested in technical objections, not family history.

[snippage]

> 	ASCII isn't good enough for me, but PDF is useful where the
> problem is really bad.  Between them (counting PS as a variation
> of PDF - especially since I have to convert PS to PDF to read it)
> they are what there is.
>
> 	My point in making a terse response was that all that was
> asked for was objections.  Sometimes, reasons are neither asked
> for nor needed.

and sometimes they are...

> 	I suspect that - now that you know the reasons - you might
> agree that this was one of those times...

Yes.

> --
> Eric
>
> --> -----Original Message-----
> --> From: Randy.Dunlap [mailto:rdunlap@xenotime.net]
> --> Sent: Friday, January 06, 2006 1:21 PM
> --> To: Gray, Eric
> --> Cc: 'Sandy Wills'; Ken Raeburn; IETF General Discussion Mailing List
> --> Subject: RE: objection to proposed change to "consensus"
> -->
> --> On Fri, 6 Jan 2006, Gray, Eric wrote:
> -->
> --> > -->     "I think we have reached substantial agreement on
> --> the following
> --> > --> statement:  ASCII text was good enough for my
> --> Grandfather, and it's
> --> > --> going to be good enough for my grandchildren.  Please
> --> reply to this
> --> > --> CfC if you object."
> -->
> --> IMO an objection should be required to also have an explanation.
> -->
> --> > I object.
> -->
> --> Why?  to which parts?  the grandfather/grandchildren?

-- 
~Randy

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 16:31:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuzBe-0000qE-No; Fri, 06 Jan 2006 16:31:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuzBc-0000q8-RI
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 16:31:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13354
	for ; Fri, 6 Jan 2006 16:30:31 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuzHY-0002XU-NT
	for ietf@ietf.org; Fri, 06 Jan 2006 16:37:59 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k06LVbdJ007415; Fri, 6 Jan 2006 16:31:37 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA08361; 
	Fri, 6 Jan 2006 16:31:36 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Fri, 6 Jan 2006 16:31:35 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88628D@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Sam Hartman'" , Spencer Dawkins
	
Date: Fri, 6 Jan 2006 16:31:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: IETF General Discussion Mailing List 
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam,

	It is useful sometimes to differentiate those who have
no stake in a particular issue from those who are not paying
attention.  Sometimes (maybe most of the time) it is not a 
very important distinction, and the IETF treats it this way 
all of the time.  Maybe that's the right way to go.  Maybe not.

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Sam Hartman
--> Sent: Friday, January 06, 2006 10:51 AM
--> To: Spencer Dawkins
--> Cc: IETF General Discussion Mailing List
--> Subject: Re: objection to proposed change to "consensus"
--> 
--> >>>>> "Spencer" == Spencer Dawkins  writes:
--> 
-->     Spencer> So... here's the problem.
-->     >> Personally, I object to the suggestion that my 
--> "vote" should be
-->     >> counted one way or another if I am silent.  At most, 
--> it should
-->     >> be counted as "no strong opinion".  Or should I now start
-->     >> responding to all the Last Calls with "I don't care 
--> about this,
-->     >> so please don't count me as supporting it"?
--> 
-->     Spencer> Our technology support for "do we have consensus"
-->     Spencer> stinks. We ask for feedback to a mailing list, knowing
-->     Spencer> that "me, too" postings are (and should be) discouraged
-->     Spencer> in most shared e-mail environments. What we get is
-->     Spencer> exactly what you described - postings from a non-random
-->     Spencer> subset of participants, and then we try to figure out
-->     Spencer> what the sampling error is, and in which 
--> direction, based
-->     Spencer> on not a lot more information. There is a safety
-->     Spencer> mechanism, because when we REALLY miscount we can be
-->     Spencer> appealed, but we don't use it often, and it's really an
-->     Spencer> expensive mechanism to use.
--> 
--> I'm not sure I consider this very broken.  If I'm reading a 
--> last call
--> and I have opinions that differ from the way the discussion 
--> is going,
--> I'm certainly going to speak up.  It seems to work fairly well in
--> practice at determining rough consensus when there is a rough
--> consensus to be determined.  It gives questionable results in cases
--> where the results are questionable; I'm not sure this a bug.
--> 
-->     Spencer> some way to let people say "you know, I just 
--> don't care",
-->     Spencer> that would help, too.
--> 
--> And what do we do with those people anyway?  How would it help me to
--> know there are 30 people who don't care?
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 17:11:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuzoT-0000m9-NV; Fri, 06 Jan 2006 17:11:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuzoR-0000ln-TC
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 17:11:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16156
	for ; Fri, 6 Jan 2006 17:10:38 -0500 (EST)
Received: from dx28.winwebhosting.com ([70.85.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuzuP-0003kp-4w
	for ietf@ietf.org; Fri, 06 Jan 2006 17:18:06 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP)
	by dx28.winwebhosting.com with esmtpa (Exim 4.52)
	id 1EuzoO-0001Ix-28; Fri, 06 Jan 2006 16:11:52 -0600
From: "Brian Rosen" 
To: "'Bob Braden'" , 
Date: Fri, 6 Jan 2006 17:09:45 -0500
Message-ID: <03f601c6130d$ea87d1b0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcYS83B5nk0owuVkT8STYpqoiSAQOgAFQ9GQ
In-Reply-To: <200601061856.KAA09340@gra.isi.edu>
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: br@brianrosen.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This

>On the other hand, it does appear that the availability of ASCII
>support as a common denominator is decreasing over time.  As has been
>observed, some software vendors seem to go out of their way to make
>simple ASCII hard to use.  So there is increasing pressure to find
>a (truly) better solution.

This is the nut of the output representation problem for me.

Most people who object to changing the output format talk about ASCII as if
it always was the standard, and always will be the standard.  If we were
having this discussion 30 or 35 years ago, we would be discussing whether
ASCII would take over EBCDIC or not.  35 years ago, it would not be clear
that ASCII would survive.  There was a holy war about that.  ASCII did in
fact take over from EBCDIC, but it wasn't always clear that it would.

As Bob points out, we are, in fact, coming to the end of the line for ASCII.
It's not in trouble this year, except that it's pretty damn tough to print
it satisfactorily on the machines most of us have to work with.  I suspect
it will get increasingly difficult to create and edit in the not too distant
future.  That would make it a possible minimum common denominator archive
format, but not a useful reading format.

It's probably true that we can push this problem off another year, but maybe
not, and definitely not for very much longer.

Brian  



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 19:37:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ev24s-0001RQ-An; Fri, 06 Jan 2006 19:37:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev24q-0001RL-FE
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 19:37:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28720
	for ; Fri, 6 Jan 2006 19:35:44 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev2Ao-0000N6-V8
	for ietf@ietf.org; Fri, 06 Jan 2006 19:43:12 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44)
	id 1Ev24f-0000Ph-Rp; Fri, 06 Jan 2006 16:36:50 -0800
Message-Id: <6.2.3.4.2.20060106233737.05962af0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Fri, 06 Jan 2006 23:40:07 +0100
To: Bob Braden , ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <200601061749.JAA09268@gra.isi.edu>
References: <200601061749.JAA09268@gra.isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: 
Subject: Re: ancients-moderns dispute (was: PDF, Postscript, and
 "normative" versions (was: Re: Baby Steps (was RE: Alternative formats
 for IDs)))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 18:49 06/01/2006, Bob Braden wrote:

>   *>
>   *> Why not to just to proceed step by step and experiment? Let create an
>   *> optional non-ascii art RFC-Editor repositories, for images quoted in
>   *> RFCs. This will not permit non-ASCII art to be normative but will
>   *> permit non-ASCII art to be _better_ descriptive in a first time.
>   *> Experience will show if there are many such images. If there is a
>   *> real need for normative non-ASCII art, it will provide experience to
>   *> create a non-ASCII art IANA registry making sure they will survive,
>   *> at an adeqate place.
>   *>
>   *> jfc
>
>This has been in place for many years, in the form of PS and/or
>PDF versions of RFCs.  What am I missing?

I am not suggesting a repository of the RFC PDF version. But a 
repository of the _art_ attached to an ASCII version. So we first see 
if there is a real need through the usage made.
jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 19:45:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ev2Ca-0004OG-V5; Fri, 06 Jan 2006 19:45:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev2CY-0004O9-Kv
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 19:44:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29276
	for ; Fri, 6 Jan 2006 19:43:42 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev2IV-0000c0-8I
	for ietf@ietf.org; Fri, 06 Jan 2006 19:51:10 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k070iidJ010725; Fri, 6 Jan 2006 19:44:44 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA26393; 
	Fri, 6 Jan 2006 19:44:43 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Fri, 6 Jan 2006 19:44:42 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886294@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Bob Braden'" 
Date: Fri, 6 Jan 2006 19:43:15 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: ietf@ietf.org
Subject: RE: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bob,

	State Diagrams is a bad example.  State machines can, and
should always be, described definitively in text.  State machine
diagrams must be derived from textual description.  Consequently,
if we want to create a document with a pictorial representation,
that document could contain normative references to a document
containing a textual description and not the other way around.

	Being able to put both in the same document and have that
document be authoritative would be a plus, provided we could be
sure that everyone could read that document.

	Perhaps a better example might be complex functional block
diagrams.  Or mathematical expressions as someone else pointed
out earlier.

	If your point is that there are things that are painfully
hard to represent in text, obviously that is true - although we
have had several people argue that this is a good thing, most
of the time.

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Bob Braden
--> Sent: Friday, January 06, 2006 1:57 PM
--> To: sandy@WEIJax.com
--> Cc: ietf@ietf.org
--> Subject: RE: objection to proposed change to "consensus"
--> 
--> 
-->   *> 
-->   *> --> 
-->   *> -->     "I think we have reached substantial agreement 
--> on the following 
-->   *> --> statement:  ASCII text was good enough for my 
--> Grandfather, and it's 
-->   *> --> going to be good enough for my grandchildren.  
--> Please reply to this
-->   *> --> CfC if you object."
-->   *> --> 
-->   *> 
--> 
--> "Are we all in favor of Motherhood and Apple Pie?"  "Well, mostly."
--> 
--> No one (well, the IETF is a big tent, so that's probably 
--> too strong...
--> almost no one) questions the desirability of a better format for
--> publishing RFCs than pure ASCII text.  This has been the subject of
--> repeated discussions over the last 20 years.  Will the same 
--> discussion
--> be taking place 20 years from now?  I, for one, certainly hope not.
--> 
--> However, simply wishing we had a better solution is not enough.  We
--> need to have such a reasonable solution in hand before we agree to
--> adopt it.  We believe we want vendor neutrality, ubiquity, 
--> convenience,
--> searchability, editability, etc..  The obvious, simple 
--> suggestions have
--> all failed on one criterion or another, and ASCII has 
--> continued to be
--> the best (if flawed) compromise.
--> 
--> For many years, PS and PDF files have been allowed as 
--> secondary formats
--> for RFCs.  (You can find them by searching rfc-index.txt for the
--> strings 'PS=' and 'PDF=', respectively).  This provision does not
--> handle things like state diagrams, which are presumably 
--> normative.  In
--> practice, creating the PS/PDF forms has been a major pain, 
--> because the
--> documentswere created by the authors using a wide variety of
--> different editors and tools.
--> 
--> On the other hand, it does appear that the availability of ASCII
--> support as a common denominator is decreasing over time.  
--> As has been
--> observed, some software vendors seem to go out of their way to make
--> simple ASCII hard to use.  So there is increasing pressure to find
--> a (truly) better solution.
--> 
--> Bob Braden
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 23:11:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ev5QI-0003q6-Qs; Fri, 06 Jan 2006 23:11:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev5QG-0003pz-IS
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 23:11:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11352
	for ; Fri, 6 Jan 2006 23:10:02 -0500 (EST)
Received: from ms-smtp-02-smtplb.tampabay.rr.com ([65.32.5.132]
	helo=ms-smtp-02.tampabay.rr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev5WG-00066l-KA
	for ietf@ietf.org; Fri, 06 Jan 2006 23:17:33 -0500
Received: from WEIJax.com (131-37.121-70.tampabay.res.rr.com [70.121.37.131])
	by ms-smtp-02.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id
	k074BAb6013747; Fri, 6 Jan 2006 23:11:10 -0500 (EST)
Message-ID: <43BF3F5E.9030704@WEIJax.com>
Date: Fri, 06 Jan 2006 23:11:10 -0500
From: Sandy Wills 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF General Discussion Mailing List 
References: <313680C9A886D511A06000204840E1CF0C88628D@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C88628D@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Gray, Eric wrote:

> 	It is useful sometimes to differentiate those who have
> no stake in a particular issue from those who are not paying
> attention.
(rest of post snipped)

Here I must become two-faced.

    Personally, I agree with you.  Often, there are many shades
of grey between the white and black binary choices.  Often,
being able to communicate those shades of grey will be essential
to creating a usable compromise.

    Unfortunately, there seems to be a religious dogma among the
long-time IETF participants that they never take votes.  All they
do is judge rough or smooth concensus, and that reduces our options
to simple binary choices.  Thus, my attempt to create a binary
method for asserting and testing a claim of concensus.

    I truly believe that we will have to go to some kind of multiple-
choice voting system to reach decisions in these multi-valued cases.
   We have already seen a couple of examples on this list, where
someone set up an opinion poll on the web, and later reported the
results.  Of course, in order for us to actually use them, they
would have to be hosted by the IETF, or the "winners" of any poll
would spend the rest of their lives fighting off charges of cheating.

-- 
Unable to locate coffee.
Operator halted.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 06 23:15:40 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ev5US-00054x-6R; Fri, 06 Jan 2006 23:15:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev5UP-00051I-O0
	for ietf@megatron.ietf.org; Fri, 06 Jan 2006 23:15:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11563
	for ; Fri, 6 Jan 2006 23:14:20 -0500 (EST)
Received: from ms-smtp-04-smtplb.tampabay.rr.com ([65.32.5.134]
	helo=ms-smtp-04.tampabay.rr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev5aQ-0006DO-9U
	for ietf@ietf.org; Fri, 06 Jan 2006 23:21:51 -0500
Received: from WEIJax.com (131-37.121-70.tampabay.res.rr.com [70.121.37.131])
	by ms-smtp-04.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id
	k074FSVq003606; Fri, 6 Jan 2006 23:15:28 -0500 (EST)
Message-ID: <43BF405F.901@WEIJax.com>
Date: Fri, 06 Jan 2006 23:15:27 -0500
From: Sandy Wills 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <03f601c6130d$ea87d1b0$640fa8c0@cis.neustar.com>
In-Reply-To: <03f601c6130d$ea87d1b0$640fa8c0@cis.neustar.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: 'Bob Braden' 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian Rosen wrote (about the format issue):

> It's probably true that we can push this problem off another year, but maybe
> not, and definitely not for very much longer.

I think that everyone here is aware of that, which is why we keep coming 
back to it, and will continue to until the agents of change win.  I've 
only been following the IETF for a couple of years now, but this 
discussion seems to come closer to adopting a change every time I see it.

-- 
Unable to locate coffee.
Operator halted.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 07 00:20:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ev6Ux-0003c3-K5; Sat, 07 Jan 2006 00:20:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev6Uv-0003bG-My
	for ietf@megatron.ietf.org; Sat, 07 Jan 2006 00:20:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15286
	for ; Sat, 7 Jan 2006 00:18:55 -0500 (EST)
Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev6aw-0007zH-4s
	for ietf@ietf.org; Sat, 07 Jan 2006 00:26:27 -0500
Received: from [127.0.0.1] (www.caia.swin.edu.au [136.186.229.16])
	by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id QAA731535;
	Sat, 7 Jan 2006 16:19:56 +1100 (EST)
Message-ID: <43BF4F75.9080106@swin.edu.au>
Date: Sat, 07 Jan 2006 16:19:49 +1100
From: grenville armitage 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <03f601c6130d$ea87d1b0$640fa8c0@cis.neustar.com>
	<43BF405F.901@WEIJax.com>
In-Reply-To: <43BF405F.901@WEIJax.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


For an organisation that, apparently, ought to be stymied and
ineffectual because of its reliance on ASCII, the IETF appears to
have had a remarkably productive run these past 20 years.

Dare I suggest a certain organisational maturity is evidenced by the
IETF's unwillingness to swing with every change in the winds of popular
editing and presentation formats over these 20 years.

gja



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 07 06:33:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvCJf-0007x6-Dl; Sat, 07 Jan 2006 06:32:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvCJc-0007wy-Sc
	for ietf@megatron.ietf.org; Sat, 07 Jan 2006 06:32:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02539
	for ; Sat, 7 Jan 2006 06:31:38 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvCPi-0008AF-0w
	for ietf@ietf.org; Sat, 07 Jan 2006 06:39:14 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44)
	id 1EvCJS-0000uu-Pp; Sat, 07 Jan 2006 03:32:47 -0800
Message-Id: <6.2.3.4.2.20060107114329.0572aa90@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Sat, 07 Jan 2006 12:12:08 +0100
To: Sandy Wills ,
	IETF General Discussion Mailing List 
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <43BEAE5C.1040705@WEIJax.com>
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms	.marconi.com>
	<43BD5BDE.4070905@WEIJax.com> <43BD9BA0.2000204@swin.edu.au>
	<43BDAD26.9020909@WEIJax.com>
	
	<43BE786D.6050006@WEIJax.com>
	
	
	<43BEAE5C.1040705@WEIJax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Cc: 
Subject: Re: Trying to invent a way of determining "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sandy,
experience shows that you would only create more traffic. The smart 
people who support the statement will not answer your call, but will 
comment what those who object will answer. As I doubt you can word a 
statement in such a way people who object may simply answer "no".....

There are ways to reach a true consensus, to address the users 
expectations, to come with neatly finished documents, etc. They are 
not the IETF ways. And they would not produce RFCs.

There is a growing consensus the general architecture is to change. 
This includes the architecture of the Internet SSDOs. PESCI is/was 
(?) an effort into that direction. IAB-discuss was another one. NSF's 
GENI is another one. WSIS' IGF will probably propose another one. 
Grassroots efforts are all over.  There are too many interests, 
habits, egos, creeds involved in the IETF. WG consensus by exhaustion 
+ IETF consensus by disinterest + IESG consensus by inability to 
share in every thing (the new architecture should be _mastered_ by a 
"standard" participant in one month training). This is at least a 
working status quo.

But nothing prevents you to create an ietf-poll.org site. To try to 
summarise the debates at hand as a single statement, with a 
"placet/non placet/placet juxta modum". To report the current results 
(I think you cannot advertise your site, but you can report in a 
debate such a poll). If this helps, it will take over. If it does 
not, I suspect you will have gained experience towards other possibilities.

NB: I think the most important response for a consensus is "placet 
juxta modum". There is _no_ consensus if there is a small reasonable 
number of them (unsatisfied supporters). They also remove the idea of 
a "winner", except general consensus, because they show "NP" people, 
some of their positions are listen to (without detailling). And show 
"P" people they are not the truth owners they often think they are. I 
tend to think that if we could force a vote on the IETF current 
system, "PJM" responses would be overwhelming.

All the best.
jfc



At 18:52 06/01/2006, Sandy Wills wrote:
>Are you guys taking turns, saying the same thing over and over again?
>
>For the record, I'm not taking sides in any of the current questions 
>about ASCII/Word/AmiPro/etc, or DKIM, or the other discussions 
>filling my inbox.  I'm trying to come up with a way for the 
>participants in those discussions to determine if they are done yet.
>
>I am proposing a formal construct, called a "Call for Concensus", or 
>appreviated as "CfC" (because I'm lazy and can't spell that third 
>word the same way two times in a row anyway), for a specific 
>purpose: to determine if we have reached an agreement during a discussion.
>
>It is _not_ used _IN_ a discussion, it is used when the discussers 
>are tired of the endless circles that these discussions turn in, 
>_AFTER_ all the different options have been mentioned.
>
>In order for such a test to work, it MUST be posted as a statement, 
>which can be agreed with, or not.  Simple enough.  In order to cut 
>down on the noise level, you word the statement such that it 
>includes the supposed-agreement.  People who agree don't need to 
>reply.  People who don't care, either from lack of expertise or 
>apathy, don't need to reply.  ONLY PEOPLE WHO OBJECT to that 
>statement should reply to the CfC.  If you have a rough idea of how 
>many people received the CfC post, and you can easily see how many 
>people objected, then you can easily see if your statement does, in 
>fact, state a concensus agreement.
>
>I don't see how this can be too complicated for people who create software.
>
>The CfC is not part of the "discussion".  It is a test to see if the 
>discussion has had a result.
>
>Is this a bad idea?  I don't think so, but I keep getting replies, 
>from differing posters, with differing words, that all evaluate to 
>"But someone will disagree, and then you can't tell...."  Yes, you can.
>
>There are only four meaningful groups of people here, the matrix of 
>care/don't care and agree/don't agree:
>
>   Anyone who disagrees with the CfC statement, but didn't reply, is 
> too apathetic to participate.  Don't count them, because they 
> themselves don't think that their opinion is worth your time.
>
>   Anyone who agrees, and did reply, has trouble understanding 
> instructions like "Only reply to this CfC if you disagree".  Given 
> that, should these people be making decisions for the group?.
>
>   Who's left?  The two groups that we care about:
>
>   Anyone who disagrees, and replies, will have their voices heard, 
> because their opinion is the one asked for by the CfC.  If their 
> objections (or volume) are significant, then the discussion will 
> turn to ways to make progress while satisfying their concerns.
>
>   Anyone who agrees with the CfC statement, and doesn't say 
> anything, is fine, because the CfC doesn't need or want their 
> support.  The CfC will stand or fall based upon the size of the 
> "disagree and replied" group.
>
>
>Marshall Eubanks wrote:
>>If there is a last call, and _nobody_ objects, then I think it 
>>is  fair to say that the majority either
>>was in favor, or at least acquiesced. At least, if people complain
>>later, you can say, "you should have spoken up when appropriate." (I
>>suppose, for symmetry, that the same could be said against a proposal
>>if there are only objections, and absolutely no support, but 
>>this  must be rare indeed.)
>>But, as soon as there are _any_ objections, then people could remain
>>silent saying to themselves "I agree" or "I don't care" or "I agree
>>with the objections, which have been much better stated than I could
>>do." You just don't know.
>>So, I regard it as improper to assume support either way from the
>>"silent majority" if there is
>>any dissension at all. That doesn't mean that you can't 
>>have  consensus in the face of objections, but
>>it does mean that you can't just wave them away by pointing to 
>>all  the people who remain silent.
>>Regards
>>Marshall
>
>
>--
>Unable to locate coffee.
>Operator halted.
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 07 08:59:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvEb0-0001sL-2U; Sat, 07 Jan 2006 08:59:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvEay-0001sD-Hf
	for ietf@megatron.ietf.org; Sat, 07 Jan 2006 08:59:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10687
	for ; Sat, 7 Jan 2006 08:57:43 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvEh4-0003Xg-5h
	for ietf@ietf.org; Sat, 07 Jan 2006 09:05:19 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 17A702596FF;
	Sat,  7 Jan 2006 14:57:49 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 23527-01; Sat,  7 Jan 2006 14:57:45 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 2C75E2596F9;
	Sat,  7 Jan 2006 14:57:45 +0100 (CET)
Date: Sat, 07 Jan 2006 15:02:48 +0100
From: Harald Tveit Alvestrand 
To: Sandy Wills ,
	IETF General Discussion Mailing List 
Message-ID: 
In-Reply-To: <43BF3F5E.9030704@WEIJax.com>
References: <313680C9A886D511A06000204840E1CF0C88628D@whq-msgusr-02.pit.comms
	.marconi.com> <43BF3F5E.9030704@WEIJax.com>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Binary choices, polling and so on (Re: objection to proposed change
 to "consensus")
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

(changing the subject since the subject is changed...)

--On fredag, januar 06, 2006 23:11:10 -0500 Sandy Wills  
wrote:

>     Unfortunately, there seems to be a religious dogma among the
> long-time IETF participants that they never take votes.  All they
> do is judge rough or smooth concensus, and that reduces our options
> to simple binary choices.  Thus, my attempt to create a binary
> method for asserting and testing a claim of concensus.

I wouldn't call it "religious", but it's part of the package deal that 
allows us to get away with not having members, and being very hard to take 
over effectively...... as soon as there's a set of rules, and a mechanistic 
method for deciding on the outcome of a decision, the price of buying an 
IETF decision becomes a known quantity instead of a "you might try, but 
you're unlikely to get away with it if someone catches you" uncertainty.

That said... I like opinion polls, of various forms, and use them 
frequently (some would say "too frequently"... I guess I've demonstrated 
most of the bad sides of opinion polls over the years...).
In the good cases, they allow us to quickly and clearly distinguish the 
pattern of opponents and proponents. In the bad case, they confirm what we 
already knew - that the group is deadlocked and unable to make a decision.

That's the time to pull out Ted Hardie's RFC 3929 and look for some 
alternate methods - majority voting isn't listed there, and for good reason.

                       Harald





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 07 09:19:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvEuc-0000ZL-0o; Sat, 07 Jan 2006 09:19:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvEuZ-0000ZG-MS
	for ietf@megatron.ietf.org; Sat, 07 Jan 2006 09:19:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11754
	for ; Sat, 7 Jan 2006 09:17:58 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EvF0f-00043B-H1
	for ietf@ietf.org; Sat, 07 Jan 2006 09:25:34 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-2.cisco.com with ESMTP; 07 Jan 2006 06:19:05 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k07EJ4Qi017462;
	Sat, 7 Jan 2006 06:19:05 -0800 (PST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Sat, 7 Jan 2006 09:19:04 -0500
Received: from [10.86.240.147] ([10.86.240.147]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 Jan 2006 09:19:04 -0500
Message-ID: <43BFCDD7.8050402@cisco.com>
Date: Sat, 07 Jan 2006 09:19:03 -0500
From: Scott W Brim 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.3.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: <313680C9A886D511A06000204840E1CF0C88628D@whq-msgusr-02.pit.comms	.marconi.com>
	<43BF3F5E.9030704@WEIJax.com>
	
In-Reply-To: 
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Jan 2006 14:19:04.0270 (UTC)
	FILETIME=[502B2EE0:01C61395]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: IETF General Discussion Mailing List ,
	Sandy Wills 
Subject: Re: Binary choices, polling and so on (Re: objection to proposed
 change to "consensus")
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 01/07/2006 09:02 AM, Harald Tveit Alvestrand allegedly wrote:
> That said... I like opinion polls, of various forms, and use them
> frequently (some would say "too frequently"... I guess I've demonstrated
> most of the bad sides of opinion polls over the years...).

a useful function

> In the good cases, they allow us to quickly and clearly distinguish the
> pattern of opponents and proponents. In the bad case, they confirm what
> we already knew - that the group is deadlocked and unable to make a
> decision.

that too

> That's the time to pull out Ted Hardie's RFC 3929 and look for some
> alternate methods - majority voting isn't listed there, and for good
> reason.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 07 09:33:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvF7w-0005y9-8t; Sat, 07 Jan 2006 09:33:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvF7u-0005y1-4D
	for ietf@megatron.ietf.org; Sat, 07 Jan 2006 09:33:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12559
	for ; Sat, 7 Jan 2006 09:31:45 -0500 (EST)
Received: from rwcrmhc14.comcast.net ([216.148.227.154]
	helo=rwcrmhc12.comcast.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvFDz-0004P5-Vh
	for ietf@ietf.org; Sat, 07 Jan 2006 09:39:21 -0500
Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149])
	by comcast.net (rwcrmhc14) with SMTP
	id <20060107143250014002fevte>; Sat, 7 Jan 2006 14:32:51 +0000
From: "David B Harrington" 
To: "'John C Klensin'" ,
	"'Marshall Eubanks'" 
Date: Sat, 7 Jan 2006 08:32:39 -0600
Message-ID: <01cf01c61397$37830280$0400a8c0@DJYXPY41>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
thread-index: AcYP5UQI3XxphTsaQhK3aq0u1z+UjwBBJDag
In-Reply-To: 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi,

As a MIB Doctor and chair of the Bridge WG, I have been working with
the IEEE 802.1 WG, who will assume maintenance responsiblities for the
Bridge WG Mib modules.

IEEE 802.1 publishes their standards in PDF. We had to make a special
request that they make the MIB portion of their documents available in
ASCII format, partly so, as part of the transition process, IETF MIB
Doctors could review their documents (e.g., running the MIB module
through smilint and other compilers), but also so the MIB modules
could be extracted for importing into network management applications,
such as NET-SNMP and HP OvenView.

A similar issue will exist for documents that contain code snippets.

While I personally like PDF for many things, I find PDF to be a poor
choice for IETF works-in-progress, or even for RFCs because they lack
many of the characteristics that ASCII files offer.

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On 
> Behalf Of John C Klensin
> Sent: Monday, January 02, 2006 3:37 PM
> To: Marshall Eubanks
> Cc: ietf@ietf.org
> Subject: Re: Alternative formats for IDs
> 
> Marshall,
> 
> --On Monday, 02 January, 2006 16:03 -0500 Marshall Eubanks
>  wrote:
> 
> >...
> >   The project, currently referred to as PDF/A, will address
> > the  growing need to electronically
> > archive documents in a way that will ensure preservation of
> > their  contents over an extended period of
> > time, and will further ensure that those documents will be
> > able to be  retrieved and rendered with a
>               ^^^^^^^^^^^^^^^^^^^^^^
> > consistent and predictable result in the future.  This need
> > exists in  a growing number of international
> > government and industry segments, including legal systems,
> > libraries,  newspapers, regulated industries, and others.
> > 
> >   The work will address the use of PDF for multi-page
> > documents that  may contain a mixture of
> > text, raster images and vector graphics.  It will also address
> > the  features and requirements that must be
> > supported by reading devices that will be used to retrieve and
> > render  the archived documents.
>   ^^^^^^
> 
> Emphasis added, of course.
> 
> As I have understood it, PDF/A is intended as an archival format
> for the sorts of documents that exist on paper, with a primary
> goal of being able to render things that look just like the
> paper looked like.  It has not been a requirement that PDF/A
> support extraction of text, editing, insertion of new materials,
> and other forms of markup.  Indeed, some of the participants in
> the PDF/A effort might consider support for some of those things
> to be liabilities.  Your note reinforces that impression.  
> 
> As such, it is (IMO, barely) possible that PDF/A would be a
> reasonable format for storing archival documents such as RFCs.
> But it would be a terrible format for working documents such as
> I-Ds, for the reasons discussed in my earlier note.
> 
>     john
> 
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 07 10:14:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvFmI-0003fC-BT; Sat, 07 Jan 2006 10:14:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvFmG-0003dS-9n
	for ietf@megatron.ietf.org; Sat, 07 Jan 2006 10:14:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14769
	for ; Sat, 7 Jan 2006 10:13:27 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EvFsM-0005Rw-GA
	for ietf@ietf.org; Sat, 07 Jan 2006 10:21:03 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-2.cisco.com with ESMTP; 07 Jan 2006 07:14:33 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k07FEWjt021270;
	Sat, 7 Jan 2006 07:14:33 -0800 (PST)
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Sat, 7 Jan 2006 10:14:32 -0500
Received: from 10.21.97.151 ([10.21.97.151]) by xmb-rtp-205.amer.cisco.com
	([64.102.31.59]) via Exchange Front-End Server email.cisco.com
	([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; 
	Sat,  7 Jan 2006 15:14:32 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Sat, 07 Jan 2006 10:14:38 -0500
From: Melinda Shore 
To: Sandy Wills ,
	IETF General Discussion Mailing List 
Message-ID: 
Thread-Topic: objection to proposed change to "consensus"
Thread-Index: AcYTnRM6Ub1nrH+QEdqGRAAKleNSdA==
In-Reply-To: <43BF3F5E.9030704@WEIJax.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 07 Jan 2006 15:14:32.0777 (UTC)
	FILETIME=[101D0B90:01C6139D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 1/6/06 11:11 PM, "Sandy Wills"  wrote:
>     Unfortunately, there seems to be a religious dogma among the
> long-time IETF participants that they never take votes.  All they
> do is judge rough or smooth concensus, and that reduces our options
> to simple binary choices.  Thus, my attempt to create a binary
> method for asserting and testing a claim of concensus.

I think part of the problem we're having with decision making (to
the extent that we're having a problem with decision-making) is that
too many people really don't understand consensus at all.  Consensus
process leads to decisions being made through synthesis and
restatement, and by the time that the question is asked "Do we have
consensus?" we should pretty much have consensus already.  Consensus
is not a form of voting with overwhelming results, and I think that's
where you're going somewhat far afield.

Sometimes I think the IETF should change its decision-making processes -
if nothing else, consensus-style decision-making doesn't work that
well when some number of participants don't share the same investment
in the process itself.  But even so, I think better training of both
participants and chairs would probably solve the bulk of the problems
that have come up and should be tried before the organization gives
serious consideration to changing how decisions are made.

Melinda

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 07 15:20:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvKXg-0005to-LX; Sat, 07 Jan 2006 15:20:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvKXe-0005rf-Fr
	for ietf@megatron.ietf.org; Sat, 07 Jan 2006 15:19:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02618
	for ; Sat, 7 Jan 2006 15:18:41 -0500 (EST)
Received: from dx28.winwebhosting.com ([70.85.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvKdo-0005Rr-83
	for ietf@ietf.org; Sat, 07 Jan 2006 15:26:20 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP)
	by dx28.winwebhosting.com with esmtpa (Exim 4.52)
	id 1EvKXf-0003mb-OM; Sat, 07 Jan 2006 14:20:00 -0600
From: "Brian Rosen" 
To: , "'John C Klensin'" ,
	"'Marshall Eubanks'" 
Date: Sat, 7 Jan 2006 15:18:08 -0500
Message-ID: <001d01c613c7$7b85e530$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
In-Reply-To: <01cf01c61397$37830280$0400a8c0@DJYXPY41>
Thread-Index: AcYP5UQI3XxphTsaQhK3aq0u1z+UjwBBJDagALJGB7A=
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: br@brianrosen.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

So, the problem you are citing is the issue that you want to harvest data
out of the ID or RFC.  That's common now, and getting more common.  You then
immediately move to say ASCII is the right output format because it makes
harvesting the data you want easy.

Well, probably not as easy as publishing the ID/RFC in some way that is
designed to make harvesting of the data within it easy.  Say, xml (2629 and
follow ons).

I believe this issue has been raised before, but we have three uses for the
ID and RFC files: we read them, we harvest data from them and we archive
them (RFCs anyway) for later use.

Any format can be used for any purpose, but it might be time to fully stand
up to requirements to harvest data, and to recognize (as I did on another
side thread), that reading is getting harder and harder for ASCII.  It may
be a decent archive format still, but I'm not sure it's going to stay that
way.

Of course, if you have three different uses, and you end up with more than
one format to satisfy all of your requirements, then you have the
"normative" problem.  I really think some of you wave that particular flag a
bit too strongly, but I think that most of us would be okay with publishing
in multiple formats, including ASCII (for now), and even with saying that
the ASCII text is the normative one, if and when there is any difference
that matters between the formats.

I think publishing the xml for harvesting really is the best thing we can
do.  If we do, we may want some more work done to make more harvesting
possible.  The schema now is really organized around readability.  This
probably has less to do with defining new tags than in using some metadata
to mark things like ABNF, code, MIBs and the like.  

I am a proponent of PDF output format; I find it very useful for reading.  I
have had very few problems with PDF, fewer than with ASCII these days.  I am
also pretty pleased with HTML as the current tool (xml2rfc) creates. 

That would mean the the I-D editor and the RFC editor uses xml2rfc, we
publish the xml, the ASCII and possibly PDF and/or html from the xml.  If
you want, the ASCII can be normative.  That also implies the desired input
format is xml.  We can discuss if we want the RFC editor to accept something
else and bear the burden of converting to xml.

I've heard the RFC editor has tried using xml and xml2rfc and is not
satisfied with the results as far as creating ASCII versions of RFC text.
It would be interesting to hear what problems they have seen.

Brian

-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
David B Harrington
Sent: Saturday, January 07, 2006 9:33 AM
To: 'John C Klensin'; 'Marshall Eubanks'
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs

Hi,

As a MIB Doctor and chair of the Bridge WG, I have been working with
the IEEE 802.1 WG, who will assume maintenance responsiblities for the
Bridge WG Mib modules.

IEEE 802.1 publishes their standards in PDF. We had to make a special
request that they make the MIB portion of their documents available in
ASCII format, partly so, as part of the transition process, IETF MIB
Doctors could review their documents (e.g., running the MIB module
through smilint and other compilers), but also so the MIB modules
could be extracted for importing into network management applications,
such as NET-SNMP and HP OvenView.

A similar issue will exist for documents that contain code snippets.

While I personally like PDF for many things, I find PDF to be a poor
choice for IETF works-in-progress, or even for RFCs because they lack
many of the characteristics that ASCII files offer.

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On 
> Behalf Of John C Klensin
> Sent: Monday, January 02, 2006 3:37 PM
> To: Marshall Eubanks
> Cc: ietf@ietf.org
> Subject: Re: Alternative formats for IDs
> 
> Marshall,
> 
> --On Monday, 02 January, 2006 16:03 -0500 Marshall Eubanks
>  wrote:
> 
> >...
> >   The project, currently referred to as PDF/A, will address
> > the  growing need to electronically
> > archive documents in a way that will ensure preservation of
> > their  contents over an extended period of
> > time, and will further ensure that those documents will be
> > able to be  retrieved and rendered with a
>               ^^^^^^^^^^^^^^^^^^^^^^
> > consistent and predictable result in the future.  This need
> > exists in  a growing number of international
> > government and industry segments, including legal systems,
> > libraries,  newspapers, regulated industries, and others.
> > 
> >   The work will address the use of PDF for multi-page
> > documents that  may contain a mixture of
> > text, raster images and vector graphics.  It will also address
> > the  features and requirements that must be
> > supported by reading devices that will be used to retrieve and
> > render  the archived documents.
>   ^^^^^^
> 
> Emphasis added, of course.
> 
> As I have understood it, PDF/A is intended as an archival format
> for the sorts of documents that exist on paper, with a primary
> goal of being able to render things that look just like the
> paper looked like.  It has not been a requirement that PDF/A
> support extraction of text, editing, insertion of new materials,
> and other forms of markup.  Indeed, some of the participants in
> the PDF/A effort might consider support for some of those things
> to be liabilities.  Your note reinforces that impression.  
> 
> As such, it is (IMO, barely) possible that PDF/A would be a
> reasonable format for storing archival documents such as RFCs.
> But it would be a terrible format for working documents such as
> I-Ds, for the reasons discussed in my earlier note.
> 
>     john
> 
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 08 02:25:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvUva-0008G9-DI; Sun, 08 Jan 2006 02:25:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvUvY-0008BN-4z
	for ietf@megatron.ietf.org; Sun, 08 Jan 2006 02:25:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07394
	for ; Sun, 8 Jan 2006 02:24:01 -0500 (EST)
Received: from mx1-b.rad.co.il ([62.219.98.8] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvV1g-00051j-Cf
	for ietf@ietf.org; Sun, 08 Jan 2006 02:31:46 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k087L2YN009165
	for ; Sun, 8 Jan 2006 09:21:03 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k087L1Lx009160;
	Sun, 8 Jan 2006 09:21:01 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 8 Jan 2006 09:24:48 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5205F03081@exrad2.ad.rad.co.il>
Thread-Topic: Engineering our way out of a brown paper bag [Re: Consensus
	based on reading tea leaves]
thread-index: AcYSLt5Y7q+54W3MQG6zNTf64Qu8IwB9RYag
From: "Yaakov Stein" 
To: "John Levine" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: RE: Engineering our way out of a brown paper bag [Re: Consensus
	based on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> I'd suggest requiring that the image format be GIF,=20
> since it's simple, stable, well documented, widely supported in both
freeware and commercial software,=20
> and the patents have expired.

Actually that is not quite right YET.

There are patents relating to the compression used in GIF
that only expire in August 2006,
and a possible that goes into 2007 in some places.
And from experience, these IPR holders have actively defended their
rights.=20

But, I doubt that we will come to agreement on this subject
before 2007 anyway ;)

Y(J)S

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 08 07:31:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvZi4-0004q5-9F; Sun, 08 Jan 2006 07:31:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvZi2-0004pq-R2
	for ietf@megatron.ietf.org; Sun, 08 Jan 2006 07:31:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21104
	for ; Sun, 8 Jan 2006 07:30:23 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvZoK-00087r-8P
	for ietf@ietf.org; Sun, 08 Jan 2006 07:38:13 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3622862; Sun, 08 Jan 2006 07:29:27 -0500
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205F03081@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A5205F03081@exrad2.ad.rad.co.il>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2EBC52E6-92B2-4394-8C35-E18BDDE9ADBA@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Sun, 8 Jan 2006 07:31:32 -0500
To: "Yaakov Stein" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus
	based on reading tea leaves]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 8, 2006, at 2:24 AM, Yaakov Stein wrote:

>> I'd suggest requiring that the image format be GIF,
>> since it's simple, stable, well documented, widely supported in both
> freeware and commercial software,
>> and the patents have expired.
>
> Actually that is not quite right YET.
>
> There are patents relating to the compression used in GIF
> that only expire in August 2006,
> and a possible that goes into 2007 in some places.
> And from experience, these IPR holders have actively defended their
> rights.
>

GNUPLOT long ago dropped support for GIF in favor of PNG for exactly  
this reason.
I have never heard of IPR claims against PNG.

Regards
Marshall


> But, I doubt that we will come to agreement on this subject
> before 2007 anyway ;)
>
> Y(J)S
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 08 07:42:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvZsd-0007a3-H2; Sun, 08 Jan 2006 07:42:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvZsb-0007Zv-32
	for ietf@megatron.ietf.org; Sun, 08 Jan 2006 07:42:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21653
	for ; Sun, 8 Jan 2006 07:41:17 -0500 (EST)
Received: from mx1-b.rad.co.il ([62.219.98.8] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvZyq-0008PD-27
	for ietf@ietf.org; Sun, 08 Jan 2006 07:49:06 -0500
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k08CcSYN014111
	for ; Sun, 8 Jan 2006 14:38:29 +0200 (IST)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k08CcRLx014108;
	Sun, 8 Jan 2006 14:38:27 +0200 (IST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 8 Jan 2006 14:42:14 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5205F031D0@exrad2.ad.rad.co.il>
Thread-Topic: Alternative formats for IDs
thread-index: AcYP5UQI3XxphTsaQhK3aq0u1z+UjwBBJDagANmtd1A=
From: "Yaakov Stein" 
To: , "John C Klensin" ,
	"Marshall Eubanks" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

=20

> While I personally like PDF for many things, I find PDF to be a poor
choice for IETF works-in-progress,=20
> or even for RFCs because they lack many of the characteristics that
ASCII files offer.

Don't you mean that ASCII lacks many of the features PDF offers
(font faces, font styles, diagrams, etc. etc. etc.) ?

The characteristic you apparently want, i.e. being easy to plug into SW
that accepts only ASCII characters, is recovered by "text selection" in
the PDF viewer.

Y(J)S

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 08 11:08:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Evd5Y-0004oG-Bf; Sun, 08 Jan 2006 11:08:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Evd5V-0004k7-IS
	for ietf@megatron.ietf.org; Sun, 08 Jan 2006 11:08:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02589
	for ; Sun, 8 Jan 2006 11:06:51 -0500 (EST)
Received: from sccrmhc12.comcast.net ([204.127.202.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvdBn-0005C4-4w
	for ietf@ietf.org; Sun, 08 Jan 2006 11:14:40 -0500
Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149])
	by comcast.net (sccrmhc12) with SMTP
	id <2006010816075401200jnu2pe>; Sun, 8 Jan 2006 16:07:54 +0000
From: "David B Harrington" 
To: "'Yaakov Stein'" ,
	"'John C Klensin'" ,
	"'Marshall Eubanks'" 
Date: Sun, 8 Jan 2006 11:07:54 -0500
Message-ID: <001101c6146d$afa08040$0400a8c0@DJYXPY41>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcYP5UQI3XxphTsaQhK3aq0u1z+UjwBBJDagANmtd1AABz5yYA==
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205F031D0@exrad2.ad.rad.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Yaakov,

I think my wording was clear:

While I personally like PDF for many things, I find PDF to be a poor
choice for IETF works-in-progress, or even for RFCs because they lack
many of the characteristics that
ASCII files offer. 

dbh

> -----Original Message-----
> From: Yaakov Stein [mailto:yaakov_s@rad.com] 
> Sent: Sunday, January 08, 2006 7:42 AM
> To: ietfdbh@comcast.net; John C Klensin; Marshall Eubanks
> Cc: ietf@ietf.org
> Subject: RE: Alternative formats for IDs
> 
>  
> 
> > While I personally like PDF for many things, I find PDF to be a
poor
> choice for IETF works-in-progress, 
> > or even for RFCs because they lack many of the characteristics
that
> ASCII files offer.
> 
> Don't you mean that ASCII lacks many of the features PDF offers
> (font faces, font styles, diagrams, etc. etc. etc.) ?
> 
> The characteristic you apparently want, i.e. being easy to 
> plug into SW
> that accepts only ASCII characters, is recovered by "text 
> selection" in
> the PDF viewer.
> 
> Y(J)S
> 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 08 11:37:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvdXf-0002Bx-M2; Sun, 08 Jan 2006 11:37:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvdXc-0002Ai-Vj
	for ietf@megatron.ietf.org; Sun, 08 Jan 2006 11:37:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04276
	for ; Sun, 8 Jan 2006 11:35:54 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evddw-0005zG-3f
	for ietf@ietf.org; Sun, 08 Jan 2006 11:43:45 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EvdXI-000GIy-LS; Sun, 08 Jan 2006 11:36:53 -0500
Date: Sun, 08 Jan 2006 11:36:51 -0500
From: John C Klensin 
To: Yaakov Stein , ietfdbh@comcast.net,
	Marshall Eubanks 
Message-ID: <7C38A6DF176244425116FFF2@p3.JCK.COM>
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5205F031D0@exrad2.ad.rad.co.il>
References: <27A0F290348F8E45AEF79889DDE65A5205F031D0@exrad2.ad.r
 ad.co.il>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Sunday, 08 January, 2006 14:42 +0200 Yaakov Stein
 wrote:

>> While I personally like PDF for many things, I find PDF to be
>> a poor
> choice for IETF works-in-progress, 
>> or even for RFCs because they lack many of the
>> characteristics that
> ASCII files offer.
> 
> Don't you mean that ASCII lacks many of the features PDF offers
> (font faces, font styles, diagrams, etc. etc. etc.) ?
> 
> The characteristic you apparently want, i.e. being easy to
> plug into SW that accepts only ASCII characters, is recovered
> by "text selection" in the PDF viewer.

Yaakov,  while I think most of this thread has continued past
usefulness without a new, and narrower, proposal, because I
remain interested in the potential of PDF for some purposes...

I think this helps make it clear that any "use PDF" proposal,
especially for I-Ds, needs to be very specific about a PDF
profile and required feature set.  It is possible to create
perfectly good PDF files from which "text selection" won't work
at all.  It is possible to create PDF files that imbed font
faces and styles from which text copying and pasting won't work
in many operating systems even if "text selection" is available.
Extracting a diagram from a PDF file so that _it_ can be edited
is rarely an obvious operation.   And so on.

Unless those things are available, PDF may be fine for
representing a finished document where the only requirement is
accurate rendering, but it is fairly terrible for working
documents, which I think is what David was trying to suggest.
Even with them, it may be worse than importing ASCII into the
editor of your choice, even if that editor is MS Word.

One way to look at this is that one of the advantages of ASCII
is that it is sufficiently feature-poor as to not require any
(or much -- we still have the line-end problem) versioning or
profiling. From that point of view, part of the problem with
either PDF or Word is that they are feature-rich and growing
(new versions are being produced with additional capabilities).
So, to use them effectively in a contract in which material must
be selected and worked on, one has to get into the business of
specifying particular versions, features and must or must not be
used, and so on.   While XML formats can get quite complex, one
of the advantages of that particular model is that it is
extremely easy to test for whether any prohibited features have
been used.   My guess it that, for these complex and
feature-rich systems, we will find it even harder to reach
agreement on those profiling issues than on whether to permit
these formats.

As an example, assuming you would still like to see MS Word
accepted as a submission and display format, suppose we agreed
on Word 95's features and file formats.  There might actually be
some reasons for doing so, starting from the observation that
Word<-> RTF conversions were much less likely to lose
information than might be the case for Word 2003.  But I can't
go to the store and buy a copy of Word 95, no one is supporting
it, and so on.  Conversely, while I think Word 2003 claims to be
able to write out Word 95-compatible files, we have no
guarantees that capability will exist in Word 2006 or Word 2008
(?): your own observation about Microsoft's incentives about new
versions would suggest that the backward support will be dropped
at some stage.  Worse, it is not easy to tell a Word 2003 file
from a Word 97 one, at least without some serious
reverse-engineering, so it is fair to predict that we would see
leakage and other side effects, some with significant ill
effects.

So, while applauding your current I-D as a useful first step (I
_really_ dislike having these discussions in the absence of a
draft), if you want to propose PDF, I think it is time that you
(or others) produce a starting-point draft that specifies or
discusses at least:

	* What the PDF is to be used for (several people, not
	just myself, have pointed out that the rules might
	plausibly be different for I-Ds and RFCs)
	
	* What version of the file format is to be used.
	
	* Consistent with that version, what features are
	required to be supported in the PDF file
	
	* Consistent with that version, what features are
	prohibited in the PDF file.

	* What is to be required about font-embedding and
	whether any restrictions on fonts and styles or the size
	and definition of image are needed.

	* Probably answers to some other questions I don't know
	enough to ask
	
	* How, or if, it is possible to design and build good,
	multiplatform, tools to test for whether or not those
	requirements have been met.

I think it would also be helpful if the draft would identify a
selection of tools, for a variety of platforms, that could be
used to create the relevant documents and, ideally, enforce
whatever requirements are specified.   If that list implies a
requirement for any tools that require high-powered machines,
large amounts of disk space or memory, particular versions of
particular operating systems, and/or expensive per-machine
licenses, then we need to know, and consider, that as well.

   john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 08 16:01:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvhfX-00019h-PE; Sun, 08 Jan 2006 16:01:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvhfU-00019Z-Tr
	for ietf@megatron.ietf.org; Sun, 08 Jan 2006 16:01:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18667
	for ; Sun, 8 Jan 2006 16:00:19 -0500 (EST)
Received: from biscayne-one-station.mit.edu ([18.7.7.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evhlp-0004He-SO
	for ietf@ietf.org; Sun, 08 Jan 2006 16:08:12 -0500
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id
	k08L1WiQ003099; Sun, 8 Jan 2006 16:01:32 -0500 (EST)
Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0)
	(User authenticated as raeburn@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k08L1OXj018311
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Sun, 8 Jan 2006 16:01:26 -0500 (EST)
In-Reply-To: <43BE786D.6050006@WEIJax.com>
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>	<43BD5BDE.4070905@WEIJax.com>
	<43BD9BA0.2000204@swin.edu.au> <43BDAD26.9020909@WEIJax.com>
	
	<43BE786D.6050006@WEIJax.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
From: Ken Raeburn 
Date: Sun, 8 Jan 2006 16:01:21 -0500
To: Sandy Wills 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
Cc: IETF General Discussion Mailing List 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jan 6, 2006, at 09:02, Sandy Wills wrote:
>    This is not a change; this seems to be the way the IETF works.   
> Many group gatherings work the same way; to me its an intuitive way  
> of getting any/all objections brought up, or establishing that  
> there aren't any, after a period of free discussion.

If it's not a change, then there's no need for text suggesting how  
the IESG should judge consensus in this matter, is there?

Ken

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 08 20:21:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Evlii-0004jo-93; Sun, 08 Jan 2006 20:21:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Evlig-0004iG-1z
	for ietf@megatron.ietf.org; Sun, 08 Jan 2006 20:21:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02470
	for ; Sun, 8 Jan 2006 20:19:49 -0500 (EST)
Received: from ms-smtp-05-smtplb.tampabay.rr.com ([65.32.5.135]
	helo=ms-smtp-05.tampabay.rr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evlp3-0002On-3u
	for ietf@ietf.org; Sun, 08 Jan 2006 20:27:46 -0500
Received: from WEIJax.com (131-37.121-70.tampabay.res.rr.com [70.121.37.131])
	by ms-smtp-05.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id
	k091KteP029580
	for ; Sun, 8 Jan 2006 20:20:56 -0500 (EST)
Message-ID: <43C1BAB0.3070301@WEIJax.com>
Date: Sun, 08 Jan 2006 20:21:52 -0500
From: Sandy Wills 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms.marconi.com>	<43BD5BDE.4070905@WEIJax.com>	<43BD9BA0.2000204@swin.edu.au>
	<43BDAD26.9020909@WEIJax.com>		<43BE786D.6050006@WEIJax.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ken Raeburn wrote:
>>    This is not a change; this seems to be the way the IETF works.   
>> Many group gatherings work the same way; to me its an intuitive way  
>> of getting any/all objections brought up, or establishing that  there 
>> aren't any, after a period of free discussion.
> 
> If it's not a change, then there's no need for text suggesting how  the 
> IESG should judge consensus in this matter, is there?

Apparently not.

I entered into what looked to me like a discussion-becoming-an-argument 
with what seemed like a useful clarification of the "rules", but even 
the desirability of doing so seems to have to fight to establish 
"concensus".  That, to me, is more than I want to put on my plate.

I think I'll go back to lurking, and let those who are paid for this 
continue this discussion.

-- 
Unable to locate coffee.
Operator halted.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 08:17:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvwtT-0005I3-SR; Mon, 09 Jan 2006 08:17:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvwtR-0005Hy-QA
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 08:17:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13890
	for ; Mon, 9 Jan 2006 08:15:40 -0500 (EST)
Received: from mtagate3.uk.ibm.com ([195.212.29.136])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evwzr-0004UC-RT
	for ietf@ietf.org; Mon, 09 Jan 2006 08:23:43 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k09DG2FB040530
	for ; Mon, 9 Jan 2006 13:16:16 GMT
Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com
	[9.149.37.228])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k09DFxd3148758 for ; Mon, 9 Jan 2006 13:15:59 GMT
Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k09DFwKj000586 for ; Mon, 9 Jan 2006 13:15:58 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k09DFwLG000556; Mon, 9 Jan 2006 13:15:58 GMT
Received: from zurich.ibm.com (sig-9-145-249-55.de.ibm.com [9.145.249.55])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA61520;
	Mon, 9 Jan 2006 14:15:46 +0100
Message-ID: <43C261FF.5020106@zurich.ibm.com>
Date: Mon, 09 Jan 2006 14:15:43 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Sandy Wills 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms	.marconi.com>	<43BD5BDE.4070905@WEIJax.com>	<43BD9BA0.2000204@swin.edu.au>	<43BDAD26.9020909@WEIJax.com>		<43BE786D.6050006@WEIJax.com>		
	<43BEAE5C.1040705@WEIJax.com>
In-Reply-To: <43BEAE5C.1040705@WEIJax.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand ,
	Ken Raeburn ,
	IETF General Discussion Mailing List 
Subject: Re: Trying to invent a way of determining "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

...
>   Anyone who agrees with the CfC statement, and doesn't say anything, is 
> fine, because the CfC doesn't need or want their support.  The CfC will 
> stand or fall based upon the size of the "disagree and replied" group.

That's pretty much how I've seen IETF consensus work over the years.
As Harald said, a straw poll can be very handy in getting an idea how
things are stacking up in the discussion, but the ultimate test is
whether the residual dissent at the end of the conversation is important
enough to matter. And that is the judgement that the IETF process leaves
to the deciders (WG Chairs or IESG in most cases) following a Last Call
message.

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 09:27:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Evxzn-0001MQ-M7; Mon, 09 Jan 2006 09:27:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Evxzm-0001MC-0N
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 09:27:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18151
	for ; Mon, 9 Jan 2006 09:26:19 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evy6H-0006M5-1w
	for ietf@ietf.org; Mon, 09 Jan 2006 09:34:22 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 810B0E0053; Mon,  9 Jan 2006 09:27:26 -0500 (EST)
To: Sandy Wills 
References: <313680C9A886D511A06000204840E1CF0C88628D@whq-msgusr-02.pit.comms.marconi.com>
	<43BF3F5E.9030704@WEIJax.com>
From: Sam Hartman 
Date: Mon, 09 Jan 2006 09:27:26 -0500
In-Reply-To: <43BF3F5E.9030704@WEIJax.com> (Sandy Wills's message of "Fri,
	06 Jan 2006 23:11:10 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: IETF General Discussion Mailing List 
Subject: Binary Choices?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Sandy" == Sandy Wills  writes:

    Sandy> Gray, Eric wrote:
    >> It is useful sometimes to differentiate those who have no stake
    >> in a particular issue from those who are not paying attention.
    Sandy> (rest of post snipped)

    Sandy> Here I must become two-faced.

    Sandy>     Personally, I agree with you.  Often, there are many
    Sandy> shades of grey between the white and black binary choices.
    Sandy> Often, being able to communicate those shades of grey will
    Sandy> be essential to creating a usable compromise.

Agreed.

    Sandy>     Unfortunately, there seems to be a religious dogma
    Sandy> among the long-time IETF participants that they never take
    Sandy> votes.  All they do is judge rough or smooth concensus, and
    Sandy> that reduces our options to simple binary choices.  

I'm very confused here; as far as I can tell judging consensus works
much better with things in the middle than any sort of votes.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 09:29:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Evy1k-0001pc-VI; Mon, 09 Jan 2006 09:29:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Evy1i-0001pN-9W
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 09:29:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18293
	for ; Mon, 9 Jan 2006 09:28:19 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evy8D-0006QE-Nz
	for ietf@ietf.org; Mon, 09 Jan 2006 09:36:21 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id A84ACE0053; Mon,  9 Jan 2006 09:29:32 -0500 (EST)
To: Sandy Wills 
References: <03f601c6130d$ea87d1b0$640fa8c0@cis.neustar.com>
	<43BF405F.901@WEIJax.com>
From: Sam Hartman 
Date: Mon, 09 Jan 2006 09:29:32 -0500
In-Reply-To: <43BF405F.901@WEIJax.com> (Sandy Wills's message of "Fri, 06
	Jan 2006 23:15:27 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: 'Bob Braden' , ietf@ietf.org
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Sandy" == Sandy Wills  writes:

    Sandy> Brian Rosen wrote (about the format issue):
    >> It's probably true that we can push this problem off another
    >> year, but maybe not, and definitely not for very much longer.

    Sandy> I think that everyone here is aware of that, which is why
    Sandy> we keep coming back to it, and will continue to until the
    Sandy> agents of change win.  I've only been following the IETF
    Sandy> for a couple of years now, but this discussion seems to
    Sandy> come closer to adopting a change every time I see it.


And that's what we call building consensus.  It how we conduct our
business and while for things like this it is conservative, it does move.

I do think that if the proponents pull together an experiment, we may
find that within two years, we have a proposal that can get consensus.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 10:42:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Evz9z-0008W9-QC; Mon, 09 Jan 2006 10:42:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Evz9w-0008W2-Gs
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 10:42:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22804
	for ; Mon, 9 Jan 2006 10:40:54 -0500 (EST)
Received: from stratton-five-twenty.mit.edu ([18.187.7.9]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvzGS-000059-C0
	for ietf@ietf.org; Mon, 09 Jan 2006 10:48:57 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 56984E0074; Mon,  9 Jan 2006 10:41:59 -0500 (EST)
To: Stewart Bryant 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
	
	<43BD12AC.1010203@zurich.ibm.com> <43BD2B97.3070400@cisco.com>
From: Sam Hartman 
Date: Mon, 09 Jan 2006 10:41:59 -0500
In-Reply-To: <43BD2B97.3070400@cisco.com> (Stewart Bryant's message of "Thu,
	05 Jan 2006 14:22:15 +0000")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Stewart" == Stewart Bryant  writes:

    Stewart> I am in favour of any practical method that allows us to
    Stewart> progress towards the best tools for the job.

    Stewart> My personal end-goal is simple: I want us to be able to
    Stewart> use modern graphical techniques in normative text to help
    Stewart> me to describe problems and their solutions. There are
    Stewart> many other nice-to-have's, but at the end of the day it
    Stewart> is the diagrams that are the key missing feature in our
    Stewart> document process.


Are you looking for normative figures?  If so, can you point to an
example where you think they are necessary?  (I'd like to avoid a
discussion of packet diagrams for the moment if that's OK)


Or are you looking at normative text that is easier to understand with
illustrative figures?


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 10:53:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvzLH-0002SV-FT; Mon, 09 Jan 2006 10:53:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzLF-0002SC-10
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 10:53:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24200
	for ; Mon, 9 Jan 2006 10:52:34 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EvzRh-0000fw-Rn
	for ietf@ietf.org; Mon, 09 Jan 2006 11:00:38 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 09 Jan 2006 07:53:39 -0800
X-IronPort-AV: i="3.99,347,1131350400"; 
	d="scan'208"; a="389266991:sNHT31980938"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k09Frdjt001396;
	Mon, 9 Jan 2006 07:53:39 -0800 (PST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 9 Jan 2006 10:53:39 -0500
Received: from [10.86.242.97] ([10.86.242.97]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 10:53:38 -0500
Message-ID: <43C28701.4000203@cisco.com>
Date: Mon, 09 Jan 2006 10:53:37 -0500
From: Scott W Brim 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.3.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Hartman 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>		<43BD12AC.1010203@zurich.ibm.com>
	<43BD2B97.3070400@cisco.com> 
In-Reply-To: 
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Jan 2006 15:53:38.0604 (UTC)
	FILETIME=[DB2956C0:01C61534]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand , ietf@ietf.org,
	Stewart Bryant 
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
> Are you looking for normative figures?  If so, can you point to an
> example where you think they are necessary?  (I'd like to avoid a
> discussion of packet diagrams for the moment if that's OK)

Normative figures perhaps.  Normative equations definitely.

Is there any input format for *just* equations (or figures), standing
by themselves, which we can agree is open, standardized, stable and
deterministic in output?

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 11:05:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvzWt-0006oD-Qe; Mon, 09 Jan 2006 11:05:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvzWq-0006nP-HR
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 11:05:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26661
	for ; Mon, 9 Jan 2006 11:04:33 -0500 (EST)
Received: from stratton-five-twenty.mit.edu ([18.187.7.9]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvzdL-0001eD-Uh
	for ietf@ietf.org; Mon, 09 Jan 2006 11:12:37 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id CDEA1E006A; Mon,  9 Jan 2006 11:05:40 -0500 (EST)
To: Scott W Brim 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
	
	<43BD12AC.1010203@zurich.ibm.com> <43BD2B97.3070400@cisco.com>
	 <43C28701.4000203@cisco.com>
From: Sam Hartman 
Date: Mon, 09 Jan 2006 11:05:40 -0500
In-Reply-To: <43C28701.4000203@cisco.com> (Scott W. Brim's message of "Mon,
	09 Jan 2006 10:53:37 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: Harald Tveit Alvestrand , ietf@ietf.org,
	Stewart Bryant 
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Scott" == Scott W Brim  writes:

    Scott> On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
    >> Are you looking for normative figures?  If so, can you point to
    >> an example where you think they are necessary?  (I'd like to
    >> avoid a discussion of packet diagrams for the moment if that's
    >> OK)

    Scott> Normative figures perhaps.  Normative equations definitely.

    Scott> Is there any input format for *just* equations (or
    Scott> figures), standing by themselves, which we can agree is
    Scott> open, standardized, stable and deterministic in output?

Mmm.  I have some significant accessibility concerns with that if you
expect me to review the documents.  I think that's a small (although
probably impossible at the current point) matter of technology.


If you go so far as normative figures I have a lot more questions
about why and what you are trying to accomplish.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 11:55:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew0Il-00074z-0s; Mon, 09 Jan 2006 11:55:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0Ih-00072d-R4
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 11:55:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01305
	for ; Mon, 9 Jan 2006 11:54:01 -0500 (EST)
Received: from stratton-five-twenty.mit.edu ([18.187.7.9]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew0PC-0003ah-9F
	for ietf@ietf.org; Mon, 09 Jan 2006 12:02:05 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id C9E7EE0053; Mon,  9 Jan 2006 11:55:04 -0500 (EST)
To: Sandy Wills 
References: <313680C9A886D511A06000204840E1CF0C886269@whq-msgusr-02.pit.comms.marconi.com>
	<43BD82D2.7070201@WEIJax.com>
From: Sam Hartman 
Date: Mon, 09 Jan 2006 11:55:04 -0500
In-Reply-To: <43BD82D2.7070201@WEIJax.com> (Sandy Wills's message of "Thu,
	05 Jan 2006 15:34:26 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: ietf@ietf.org
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Sandy" == Sandy Wills  writes:

    Sandy> Gray, Eric wrote:
    >> Sandy, In fact, contrary to what we observe in nature, change
    >> is not the "default outcome" in most human organizations.  That
    >> is because - as a careful analysis of this discussion over the
    >> years will disclose - there are as many ways to go with a
    >> change as there are people prepared to make changes.

    Sandy>     I think that there is also a very strong element of
    Sandy> emotional attachment to any system or solution, from those
    Sandy> people who had a hand in creating it (Certainly, I'm just
    Sandy> as guilty of this as the next guy!). Any job is harder if
    Sandy> you have to change your tools every time you get used to
    Sandy> them.  

I think that's a valuable thing to consider in consensus building.
"This makes me retool how I do things; it works well today," is
actually a valid input to a discussion.


    Sandy> It's also true that some people will object to
    Sandy> anything in front of them, simply because it was done by
    Sandy> someone else.  

I'm having a hard time arguing that this is a good thing.

    Sandy> We also have the "religious" responses, both
    Sandy> pro and con, where someone either approves (or disapproves)
    Sandy> of it simply because of the source.  We've all seen "It's
    Sandy> gotta be good, Jon Postel wrote it", as well as "I'll cut
    Sandy> my wrists before I use MS software"

I think these are valuable inputs as well.  There are people involved;
whether these people are happy, whether they will continue to work,
are important factors.  Of course there are religious arguments on the
other side: "I want my architectural diagrams; they work well in the
ITU and I want them here," is on the same level as "I won't use MS
software."

Note that related to religious arguments may be more practical issues
as well.

    Sandy>     It appears that, if we want to judge solution-quality
    Sandy> by mob volume, we need to find some way to separate the
    Sandy> emotional responses from the reasoned responses.


I disagree that discarding the emotional responses is appropriate.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 12:02:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew0Q6-0000HW-OD; Mon, 09 Jan 2006 12:02:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0Q4-0000HP-OU
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 12:02:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01814
	for ; Mon, 9 Jan 2006 12:01:37 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew0WZ-0003oK-MP
	for ietf@ietf.org; Mon, 09 Jan 2006 12:09:42 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k09H32xJ024928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2006 09:03:03 -0800
Message-ID: <43C2971D.1040800@dcrocker.net>
Date: Mon, 09 Jan 2006 09:02:21 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Sam Hartman 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>		<43BD12AC.1010203@zurich.ibm.com>
	<43BD2B97.3070400@cisco.com>	
	<43C28701.4000203@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Accessibility issues affecting IETF document format choices
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


> Mmm.  I have some significant accessibility concerns with that if you
> expect me to review the documents.  I think that's a small (although
> probably impossible at the current point) matter of technology.


Sam,

Thank you for raising this basic point.  Since the IETF seeks the widest 
possible availability for its documents, it might help discussion about format 
choices to understand how your ability to review documents is affected.

For starters, what sorts of things about the *current* IETF document format make 
your reviewing easier or more difficult?

(Given the discussion that triggered this note, specific comments on figures and 
formulas would be helpful.  I will add my own curiosity about the extent to 
which punctuation choices aid or hinder review.)

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 12:47:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew17K-0000AP-Jy; Mon, 09 Jan 2006 12:47:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew17I-00008I-4l
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 12:47:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06442
	for ; Mon, 9 Jan 2006 12:46:17 -0500 (EST)
Received: from stratton-five-twenty.mit.edu ([18.187.7.9]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew1Do-0005dF-S4
	for ietf@ietf.org; Mon, 09 Jan 2006 12:54:22 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 03E17E0053; Mon,  9 Jan 2006 12:47:28 -0500 (EST)
To: dcrocker@bbiw.net
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
	
	<43BD12AC.1010203@zurich.ibm.com> <43BD2B97.3070400@cisco.com>
	 <43C28701.4000203@cisco.com>
	 <43C2971D.1040800@dcrocker.net>
From: Sam Hartman 
Date: Mon, 09 Jan 2006 12:47:28 -0500
In-Reply-To: <43C2971D.1040800@dcrocker.net> (Dave Crocker's message of
	"Mon, 09 Jan 2006 09:02:21 -0800")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: ietf@ietf.org
Subject: Re: Accessibility issues affecting IETF document format choices
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Dave" == Dave Crocker  writes:

    >> Mmm.  I have some significant accessibility concerns with that
    >> if you expect me to review the documents.  I think that's a
    >> small (although probably impossible at the current point)
    >> matter of technology.


    Dave> Sam,

    Dave> Thank you for raising this basic point.  Since the IETF
    Dave> seeks the widest possible availability for its documents, it
    Dave> might help discussion about format choices to understand how
    Dave> your ability to review documents is affected.


Hi.  I was actually not trying to raise the general issue of how
accessible the IETF should make its documents.

I was simply trying to raise the practical issue that while I'm on the
IESG, I will hold a discuss if I cannot understand some aspect of a
document well enough to review it.
It's not trying to make a political statement, just that I've been asked to do a job by the nomcom and I will try and do that job.

Naturally should I hold such a discuss I'd work with the authors to
try and figure out enough detail to quickly understand their document.

I think the general issue is important but should be examined in the
broader context of the document format issue.

However I'd like to wait and see if we're going to actually do
anything about the broader issue before spending cycles on this
question.  I proposed a specific set of steps that the proponents
could take to conduct an experiment; so far no one has disagreed with
that proposal.  So let's see if it looks like people are going to try
that approach.  If so, I agree this would be an important thing to at
least start thinking about.  It may well not matter for the
experiment, but it may matter long-term.

If anyone wants to chat about document accessibility in person I'd be
happy to do so.  I just would rather not get into a long email
discussion right now.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 12:58:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew1Hi-0003lu-3Q; Mon, 09 Jan 2006 12:58:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1Hf-0003lp-La
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 12:58:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07663
	for ; Mon, 9 Jan 2006 12:57:00 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew1OA-0006A3-Rn
	for ietf@ietf.org; Mon, 09 Jan 2006 13:05:05 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k09Hw6dJ005060; Mon, 9 Jan 2006 12:58:07 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10760; 
	Mon, 9 Jan 2006 12:58:05 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Mon, 9 Jan 2006 12:58:04 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88629F@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Sam Hartman'" , Sandy Wills 
Date: Mon, 9 Jan 2006 12:57:56 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: IETF General Discussion Mailing List 
Subject: RE: Binary Choices?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam/Sandy,

	See below...

--
Eric

--- [SNIP] --- 
-->     Sandy>     Unfortunately, there seems to be a religious dogma
-->     Sandy> among the long-time IETF participants that they never take
-->     Sandy> votes.  All they do is judge rough or smooth concensus, and
-->     Sandy> that reduces our options to simple binary choices.  
--> 
--> I'm very confused here; as far as I can tell judging consensus works
--> much better with things in the middle than any sort of votes.

Ultimately, you're both right.

Usually, before you can actually seek consensus, you must have an
essentially "binary" choice.  It is hard enough to reach consensus
on simple choices without turning up the process noise by having a
plethora of possible choices.

However, the process of seeking consensus does tend to solicit the
reasons and feelings involved in making choices and this can lead
to solution searches in the "gray-areas" between proposals.

--> 
--> --Sam
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 12:59:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew1Iv-000421-QE; Mon, 09 Jan 2006 12:59:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1Iu-00041w-ER
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 12:59:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07811
	for ; Mon, 9 Jan 2006 12:58:17 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew1PR-0006EA-Af
	for ietf@ietf.org; Mon, 09 Jan 2006 13:06:22 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 09 Jan 2006 18:59:25 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k09HxMFZ029551; 
	Mon, 9 Jan 2006 18:59:23 +0100 (MET)
Received: from [10.82.240.165] (rtp-vpn2-165.cisco.com [10.82.240.165])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA25894;
	Mon, 9 Jan 2006 17:59:20 GMT
Message-ID: <43C2A477.9060608@cisco.com>
Date: Mon, 09 Jan 2006 17:59:19 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Hartman 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>		<43BD12AC.1010203@zurich.ibm.com>
	<43BD2B97.3070400@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam Hartman wrote:

>>>>>>"Stewart" == Stewart Bryant  writes:
>>>>>>            
>>>>>>
>
>    Stewart> I am in favour of any practical method that allows us to
>    Stewart> progress towards the best tools for the job.
>
>    Stewart> My personal end-goal is simple: I want us to be able to
>    Stewart> use modern graphical techniques in normative text to help
>    Stewart> me to describe problems and their solutions. There are
>    Stewart> many other nice-to-have's, but at the end of the day it
>    Stewart> is the diagrams that are the key missing feature in our
>    Stewart> document process.
>
>
>Are you looking for normative figures?  
>
Yes

>If so, can you point to an
>example where you think they are necessary?  (I'd like to avoid a
>discussion of packet diagrams for the moment if that's OK)
>  
>
Sam

In no particular order:

State diagrams - The issue here is density and line-crossing.

Packet Diagrams

Annotated network scenarios - I have particularly seen this problem
in BGP with ASBRs, packets, ASs and filters, but it applies to
any case where we wish to say this is the state in this node,
so this packet flows, so this is the resultant state this node.
The problem is particularly difficult when you get to four or
more nodes and need to show their topological context.
The problem here is the need for higher density line and
object density than you can achieve with ASCII art as well
as the need for small fonts to include the annotation.

Network snapshots, which require a set of network states to
be presented side by side by side. This is needed in showing
the dynamics of network state change such as the dynamics
of routing convergence.

Overlay networks of the sort that get built with tunnels - I have
seen problems in PWE3, RTGWG (with IP fast re-route), and L*VPN.
I would think that there are similar problems of expression in
the mobile area. This is an area that really benefits from both
lines and colours.

Non-trivial network scenarios where you want to show asymetric
costs commonly needed in routing.

Scenarios where you wish to illustrate reachibility of different
regions of a network.

Equations in general.

Network diagrams annotated with equations (such as routing costs
or timing).

Graphs, in general, but they become normative when you
wish to apply a performance mask.

Timing diagrams

G.802 diagrams (this is a formalized notation for layered
networks). These are sort of like equations in that the symbols
are well known. The diagrams can be quite complex.

It has also been pointed out that you can't write a draft showing
the dependency relationships between other drafts using the tools
group tools output. Not that such a draft would be normative.

I am planning to write a draft to illustrate the problem, which
I will submit in both ASCII and pdf using the current dual
submission procedure. This in itself will be an interesting
exercise to see if it still works.

- Stewart
 

>
>Or are you looking at normative text that is easier to understand with
>illustrative figures?
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>
>
>  
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 12:59:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew1J6-00046C-N0; Mon, 09 Jan 2006 12:59:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1J5-00043q-3V
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 12:59:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07819
	for ; Mon, 9 Jan 2006 12:58:27 -0500 (EST)
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew1Pb-0006Ee-UN
	for ietf@ietf.org; Mon, 09 Jan 2006 13:06:33 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 58FA0FB27C;
	Mon,  9 Jan 2006 17:59:39 +0000 (UTC)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id 2B6233C01C9;
	Mon,  9 Jan 2006 12:59:38 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: Scott W Brim 
In-Reply-To: (Your message of "Mon, 09 Jan 2006 10:53:37 EST.")
	<43C28701.4000203@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 09 Jan 2006 12:59:38 -0500
Message-Id: <20060109175938.2B6233C01C9@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Harald Tveit Alvestrand ,
	Sam Hartman , ietf@ietf.org,
	Stewart Bryant 
Subject: Re: Normative figures 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In message <43C28701.4000203@cisco.com>, Scott W Brim writes:
>On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
>> Are you looking for normative figures?  If so, can you point to an
>> example where you think they are necessary?  (I'd like to avoid a
>> discussion of packet diagrams for the moment if that's OK)
>
>Normative figures perhaps.  Normative equations definitely.
>
>Is there any input format for *just* equations (or figures), standing
>by themselves, which we can agree is open, standardized, stable and
>deterministic in output?
>

LaTeX is the standard in the math and theory world.  It's free, and 
runs on just about everything.  If I recall correctly what Kernighan
once said, eqn was designed so that its input language was more or 
less what one mathematician would say to another over the phone, which 
(I assume) would help with accessibility.  There are open source versions
of eqn; I think that they run on more or less anything, too.
In the pure HTML world, there's MathML, though it's *really* ugly to 
read.  I have no idea how much it's supported by today's browsers.  
(Kernighan started working on an eqn to HTML translator some years ago, 
but back then no browser really worked properly for it.)

Note that I'm *not* saying we should adopt any of these for RFCs; I'm 
simply saying that there are some well-known systems that satisfy at 
least your four criteria.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 13:17:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew1aZ-00028i-Bb; Mon, 09 Jan 2006 13:17:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1aW-00028d-HP
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 13:17:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09196
	for ; Mon, 9 Jan 2006 13:16:29 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew1h4-0006pB-Ku
	for ietf@ietf.org; Mon, 09 Jan 2006 13:24:34 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 09 Jan 2006 19:17:39 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k09IHaFZ002350; 
	Mon, 9 Jan 2006 19:17:37 +0100 (MET)
Received: from [10.82.240.165] (rtp-vpn2-165.cisco.com [10.82.240.165])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA27996;
	Mon, 9 Jan 2006 18:17:32 GMT
Message-ID: <43C2A8BC.2030407@cisco.com>
Date: Mon, 09 Jan 2006 18:17:32 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Hartman 
References: <313680C9A886D511A06000204840E1CF0C886269@whq-msgusr-02.pit.comms.marconi.com>	<43BD82D2.7070201@WEIJax.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, Sandy Wills 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


>I think these are valuable inputs as well.  There are people involved;
>whether these people are happy, whether they will continue to work,
>are important factors.  Of course there are religious arguments on the
>other side: "I want my architectural diagrams; they work well in the
>ITU and I want them here," is on the same level as "I won't use MS
>software."
>  
>

Sam

I disagree that the use of diagrams is a religious issue. Diagrams
are a very simple way to put specification and context together
in a compact notation such that it is easy to move from key point
to key point in a non-linear way. They provide visual hyperlinking.

Here is a good way to judge the value of a diagram:

Look at a diagram presented in an IETF WG session and ask the
questions : does this diagram make the draft easier to understand?
If the answer is yes, then the diagram should probably be in the
draft.

The problem is that it is frequently impossible to translate the
clarity of the graphics used in the presentation to the technology
of ASCII art.

- Stewart

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 13:52:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew28Q-0002vz-Ex; Mon, 09 Jan 2006 13:52:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew28P-0002vu-0G
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 13:52:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11759
	for ; Mon, 9 Jan 2006 13:51:29 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2Ex-0007uX-4V
	for ietf@ietf.org; Mon, 09 Jan 2006 13:59:35 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k09IpFi18829;
	Mon, 9 Jan 2006 10:51:15 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA09906;
	Mon, 9 Jan 2006 10:51:15 -0800 (PST)
Date: Mon, 9 Jan 2006 10:51:15 -0800 (PST)
Message-Id: <200601091851.KAA09906@gra.isi.edu>
To: hartmans-ietf@mit.edu, sbrim@cisco.com
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: harald@alvestrand.no, ietf@ietf.org, stbryant@cisco.com
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


  *> 
  *> Normative figures perhaps.  Normative equations definitely.

Scott,

How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
of readable equations in ASCII?  I my experience, normative protocol
technical specifications rarely need equations much more complex than
these examples.  The only significant exception I can think of is the
NTP spec.

People who REALLY use equations generally prefer LaTeX.

Bob Braden


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 14:01:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew2Gv-0005JR-E4; Mon, 09 Jan 2006 14:01:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2Gt-0005JG-2L
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 14:01:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12330
	for ; Mon, 9 Jan 2006 14:00:15 -0500 (EST)
Received: from stratton-five-twenty.mit.edu ([18.187.7.9]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2NP-00089j-Kk
	for ietf@ietf.org; Mon, 09 Jan 2006 14:08:21 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 4E139E0053; Mon,  9 Jan 2006 14:01:23 -0500 (EST)
To: Stewart Bryant 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
	
	<43BD12AC.1010203@zurich.ibm.com> <43BD2B97.3070400@cisco.com>
	 <43C2A477.9060608@cisco.com>
From: Sam Hartman 
Date: Mon, 09 Jan 2006 14:01:23 -0500
In-Reply-To: <43C2A477.9060608@cisco.com> (Stewart Bryant's message of "Mon,
	09 Jan 2006 17:59:19 +0000")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi.  With the exception of packet diagrams, I think all the examples
you bring up benefit significantly from clear textual description.  I
believe I'd think that even if I could see the diagrams and I believe
I have enough experience with visualization (although not sight) to be
confident in that belief.

As such, I don't believe these diagrams should be normative.


I actually thin that many of the tunnel overlay network documents
(PWE3, L2VPN, L3VPN) could benefit significantly from more focus on
the text of the descriptions of situations being described.

If you believe that normative documents are required, I'd like you to
explain why the diagrams cannot be described in the text, why doing so
would decrease the quality of the specification, or why doing so would
not be a useful investment in our time.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 14:03:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew2IN-0005Sl-Ka; Mon, 09 Jan 2006 14:03:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2IL-0005SQ-J5
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 14:03:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12400
	for ; Mon, 9 Jan 2006 14:01:45 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2Or-0008Bx-Ql
	for ietf@ietf.org; Mon, 09 Jan 2006 14:09:52 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1Ew2IG-000IZr-Dl; Mon, 09 Jan 2006 14:03:00 -0500
Date: Mon, 09 Jan 2006 14:02:59 -0500
From: John C Klensin 
To: Stewart Bryant , Sam Hartman 
Message-ID: <07E7D8FF42ED6429ABFC943F@p3.JCK.COM>
In-Reply-To: <43C2A8BC.2030407@cisco.com>
References: <313680C9A886D511A06000204840E1CF0C886269@whq-msgusr-0
	2.pit.comms.marconi.com>	<43BD82D2.7070201@WEIJax.com>
	 <43C2A8BC.2030407@cisco.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, Sandy Wills 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--On Monday, 09 January, 2006 18:17 +0000 Stewart Bryant
 wrote:

>> I think these are valuable inputs as well.  There are people
>> involved; whether these people are happy, whether they will
>> continue to work, are important factors.  Of course there are
>> religious arguments on the other side: "I want my
>> architectural diagrams; they work well in the ITU and I want
>> them here," is on the same level as "I won't use MS software."

> I disagree that the use of diagrams is a religious issue.
> Diagrams
> are a very simple way to put specification and context together
> in a compact notation such that it is easy to move from key
> point to key point in a non-linear way. They provide visual
> hyperlinking.

Stewart, 

While I agree that diagrams are not simply a religious issue, I
think that there are many cases in which the use of diagrams,
especially complex ones, leaves people with the impression that
they have understood something when, in fact, they do not.  Ed
Tufte's work, among many others, has provided repeated
graphical, and often humorous, illustrations of that point.
Part of that issue overlaps the resistance to WG sessions that
are dominated by PowerPoint presentations every time that
discussion breaks out, although some of that discussion is
driven by what are clearly religious issues.

This brings us back to one on the early comments in these
threads -- that the need to describe a complex concept in text
or in ASCII art imposes a discipline that is actually quite
useful.  I agree with you that there are some things that cannot
be thus described with a sensible amount of effort, but it has
seemed to me that it would be helpful, from a document quality
standpoint, to examine each case and to try to strive for the
minimum diagram complexity that is actually necessary.

I get even more concerned when it is suggested that not only are
diagrams are needed, but that color documents may be needed.
While things are easier than they were a decade or two ago, the
need to transmit and render color images imposes costs in both
printing facilities and transmission sizes of documents that I,
at least, would prefer to avoid unless necessity can be
demonstrated.  Sam can, and I hope will, speak for himself, but
my experience working with programmers with visual difficulties
some years ago suggests that while monochrome line art --whether
conveniently expressible in ASCII or not-- can often be made
comprehensible with sufficient effort, either continuous-tone
materials or line-art drawings that depend on color are fairly
close to impossible.

> Here is a good way to judge the value of a diagram:
> 
> Look at a diagram presented in an IETF WG session and ask the
> questions : does this diagram make the draft easier to
> understand?
> If the answer is yes, then the diagram should probably be in
> the draft.

I think that criterion leads down a slippery slope toward
documents that are collections of PowerPoint images.   The
understanding of a document in a WG session can be improved by
an oral presentation with selected bullet points on slides, too,
but that doesn't automatically make the case that either that
the bullet points ought to be precisely the section headings of
the document or that the slides should be included with the text.

> The problem is that it is frequently impossible to translate
> the clarity of the graphics used in the presentation to the
> technology of ASCII art.

Assuming we agree on that, can we figure out some criteria or
guidelines for keeping graphics to the minimum complexity needed
to express ideas, for being sure that graphics are accompanied
by good  explanations whenever possible, and generally for
preventing people from going hog-wild with complex colored
illustrations?   It seems to me that, if possible, we also need
to find ways to be sure that any normative graphics that appear
in I-Ds can be edited with tools that are easily accessible on
all relevant platforms.

Most of the above of course are probably best taken as input to,
or evaluation criteria for, precisely the sort of experiment
that Sam suggests.

    john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 14:22:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew2ae-00035C-3F; Mon, 09 Jan 2006 14:22:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2ac-000356-9S
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 14:21:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13840
	for ; Mon, 9 Jan 2006 14:20:38 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2h7-0000Nl-Hc
	for ietf@ietf.org; Mon, 09 Jan 2006 14:28:45 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 09 Jan 2006 20:21:43 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k09JLaFZ011527; 
	Mon, 9 Jan 2006 20:21:36 +0100 (MET)
Received: from [10.82.240.165] (rtp-vpn2-165.cisco.com [10.82.240.165])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA04711;
	Mon, 9 Jan 2006 19:21:33 GMT
Message-ID: <43C2B7BC.8080406@cisco.com>
Date: Mon, 09 Jan 2006 19:21:32 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bob Braden 
References: <200601091851.KAA09906@gra.isi.edu>
In-Reply-To: <200601091851.KAA09906@gra.isi.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: harald@alvestrand.no, hartmans-ietf@mit.edu, ietf@ietf.org, sbrim@cisco.com
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bob Braden wrote:

>  *> 
>  *> Normative figures perhaps.  Normative equations definitely.
>
>Scott,
>
>How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
>of readable equations in ASCII?  I my experience, normative protocol
>technical specifications rarely need equations much more complex than
>these examples.  The only significant exception I can think of is the
>NTP spec.
>
>People who REALLY use equations generally prefer LaTeX.
>
>Bob Braden
>
>
>  
>
The draft has expired so I need to point to an external version. This draft
which is looking at the properties of a routing network under conditions of
failure would have been much clearer if it could have used mathematical
notation rather than ASCIIised equations

http://www.faqs.org/ftp/pub/internet-drafts/draft-atlas-ip-local-protect-uturn-02.txt

Of course the diagrams could have also been clearer, as is seen by
comparing them to the ones that Alia used in her presentatons on the
subject.

- Stewart


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 14:34:19 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew2mZ-0005o1-BW; Mon, 09 Jan 2006 14:34:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2mX-0005nr-LC
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 14:34:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14636
	for ; Mon, 9 Jan 2006 14:32:57 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2t5-0000lI-Dn
	for ietf@ietf.org; Mon, 09 Jan 2006 14:41:04 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2006 14:34:07 -0500
X-IronPort-AV: i="3.99,347,1131339600"; 
	d="scan'208"; a="79847452:sNHT31481684"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k09JXQ6p012820; 
	Mon, 9 Jan 2006 14:34:05 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 9 Jan 2006 14:33:42 -0500
Received: from [10.86.242.97] ([10.86.242.97]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 14:33:36 -0500
Message-ID: <43C2BA90.7030505@cisco.com>
Date: Mon, 09 Jan 2006 14:33:36 -0500
From: Scott W Brim 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.3.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John C Klensin 
References: <313680C9A886D511A06000204840E1CF0C886269@whq-msgusr-0	2.pit.comms.marconi.com>	<43BD82D2.7070201@WEIJax.com>	
	<43C2A8BC.2030407@cisco.com> <07E7D8FF42ED6429ABFC943F@p3.JCK.COM>
In-Reply-To: <07E7D8FF42ED6429ABFC943F@p3.JCK.COM>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Jan 2006 19:33:37.0062 (UTC)
	FILETIME=[960E3460:01C61553]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: Sam Hartman , ietf@ietf.org,
	Sandy Wills , Stewart Bryant 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 01/09/2006 14:02 PM, John C Klensin allegedly wrote:
> While I agree that diagrams are not simply a religious issue, I
> think that there are many cases in which the use of diagrams,
> especially complex ones, leaves people with the impression that
> they have understood something when, in fact, they do not.  

> the need to describe a complex concept in text
> or in ASCII art imposes a discipline that is actually quite
> useful. 

Yup, although we've seen plenty of cases where people understand text
differently as well.

I think I'm beginning to like TeX again.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 14:47:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew2ys-0001mp-Fe; Mon, 09 Jan 2006 14:47:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2yp-0001mS-JU
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 14:46:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16118
	for ; Mon, 9 Jan 2006 14:45:39 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew35O-000186-2p
	for ietf@ietf.org; Mon, 09 Jan 2006 14:53:46 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 09 Jan 2006 20:46:50 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k09JklFZ015570; 
	Mon, 9 Jan 2006 20:46:47 +0100 (MET)
Received: from [10.82.240.165] (rtp-vpn2-165.cisco.com [10.82.240.165])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA06903;
	Mon, 9 Jan 2006 19:46:43 GMT
Message-ID: <43C2BDA2.30908@cisco.com>
Date: Mon, 09 Jan 2006 19:46:42 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Hartman 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>		<43BD12AC.1010203@zurich.ibm.com>
	<43BD2B97.3070400@cisco.com>	
	<43C2A477.9060608@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam Hartman wrote:

>Hi.  With the exception of packet diagrams, I think all the examples
>you bring up benefit significantly from clear textual description.
>
Sam

I am not saying that clear text is not needed to accompany a diagram.
However a diagram allows a lot less text to be written producing a
shorter clearer draft with less clutter.

For example you could say the following in text : router A connects to
router B and D, the cost from A to B is 2, and the cost from A to D is 4.
Router B connects to router C. The cost to router A is 6, and the cost to
router C is 10. Router C connects to router D. The cost to router B is 9
and the cost to router D is 8. The cost from router D to router A is 16
and the cost to router A is 99.

In fact you would probably need a table to make sure that you did not
make a mistake. In either case it is hard for most people to figure
out the  what the topology is much less imagine packet actions.

Now compare this to:

"The network and costs are as shown in figure foo."

Simple text and the visualisation is already done for you so you
can focus on the problem.

Now I realise the above could be done in ascii art, but we have problems
that need 13 or more nodes to set up.

>  I
>believe I'd think that even if I could see the diagrams and I believe
>I have enough experience with visualization (although not sight) to be
>confident in that belief.
>
>  
>
>As such, I don't believe these diagrams should be normative.
>
>
>I actually thin that many of the tunnel overlay network documents
>(PWE3, L2VPN, L3VPN) could benefit significantly from more focus on
>the text of the descriptions of situations being described.
>  
>
It is probably a question of how we work and the tools that we
find most effective.

>If you believe that normative documents are required, I'd like you to
>explain why the diagrams cannot be described in the text, why doing so
>would decrease the quality of the specification, or why doing so would
>not be a useful investment in our time.
>
>
>  
>
One reason is that it takes a lot of text to describe what can be drawn
with a few lines and symbols. Many people will get lost in the text and
in any case would have to transcribe the text into a diagram for
themselves before they could understand what is happening.

- Stewart





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 14:48:20 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew308-0001yR-Bu; Mon, 09 Jan 2006 14:48:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew305-0001y8-1v
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 14:48:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16287
	for ; Mon, 9 Jan 2006 14:46:56 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew36Z-0001A1-Bw
	for ietf@ietf.org; Mon, 09 Jan 2006 14:55:00 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k09JluTn009209; Mon, 9 Jan 2006 14:47:56 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28945; 
	Mon, 9 Jan 2006 14:47:56 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Mon, 9 Jan 2006 14:47:54 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C8862A2@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Stewart Bryant'" , Bob Braden 
Date: Mon, 9 Jan 2006 14:47:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: harald@alvestrand.no, hartmans-ietf@mit.edu, ietf@ietf.org, sbrim@cisco.com
Subject: RE: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart,

	There's a joke that goes something like this: there are three 
kinds of people in this world - those that are good at Math and those
that are not.

	Funny thing is that there are at least three ways in which
people approach mathematical expressions:

1) Some see a nice, clean, symbolic expression and mentally reject it 
   out of hand (for these people, a "summation symbol" terminates a
   line of readable text);
2) Some see a symbolic expression, look at it briefly and become (as
   one person said earlier about figures) convinced they understand 
   it while actually they do not (this can be established by a simple
   search for published material in which non-sensical mathematical
   expressions were included without comment in peer reviews);
3) Some people see any symbolic expression and play with it until 
   either they understand it or they know what is wrong with it.

In the first two cases - in which, I think we can agree, most people
would fall - it is much better to have made the effort to put the
expression in "plain English" - however much prettier it would have
been in symbolic representation.

--
Eric
 

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Stewart Bryant
--> Sent: Monday, January 09, 2006 2:22 PM
--> To: Bob Braden
--> Cc: harald@alvestrand.no; hartmans-ietf@mit.edu; 
--> ietf@ietf.org; sbrim@cisco.com
--> Subject: Re: Normative figures
--> 
--> Bob Braden wrote:
--> 
--> >  *> 
--> >  *> Normative figures perhaps.  Normative equations definitely.
--> >
--> >Scott,
--> >
--> >How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), 
--> for examples
--> >of readable equations in ASCII?  I my experience, 
--> normative protocol
--> >technical specifications rarely need equations much more 
--> complex than
--> >these examples.  The only significant exception I can 
--> think of is the
--> >NTP spec.
--> >
--> >People who REALLY use equations generally prefer LaTeX.
--> >
--> >Bob Braden
--> >
--> >
--> >  
--> >
--> The draft has expired so I need to point to an external 
--> version. This draft
--> which is looking at the properties of a routing network 
--> under conditions of
--> failure would have been much clearer if it could have used 
--> mathematical
--> notation rather than ASCIIised equations
--> 
--> http://www.faqs.org/ftp/pub/internet-drafts/draft-atlas-ip-l
--> ocal-protect-uturn-02.txt
--> 
--> Of course the diagrams could have also been clearer, as is seen by
--> comparing them to the ones that Alia used in her presentatons on the
--> subject.
--> 
--> - Stewart
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 14:59:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew3BE-0004m1-Qw; Mon, 09 Jan 2006 14:59:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew3BB-0004kX-MT
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 14:59:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17941
	for ; Mon, 9 Jan 2006 14:58:25 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew3Hj-0001cb-9r
	for ietf@ietf.org; Mon, 09 Jan 2006 15:06:32 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LXK74LVLW0001KXE@mauve.mrochek.com> for
	ietf@ietf.org; Mon, 9 Jan 2006 11:59:16 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1136836755;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=WrYcBe8ImOeyennsQnkrmj5U2
	FM+PrHoOrI7cbnqBWDfX/WmqSy4bkWi0fs3Jg3nrOo1pNqytfo54dal9FW5MQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LXDGWDO8BK00009C@mauve.mrochek.com>; Mon,
	09 Jan 2006 11:59:11 -0800 (PST)
To: Steven M Bellovin 
Message-id: <01LXK74JQTPU00009C@mauve.mrochek.com>
Date: Mon, 09 Jan 2006 11:35:00 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 09 Jan 2006 12:59:38 -0500"
	<20060109175938.2B6233C01C9@berkshire.machshav.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <43C28701.4000203@cisco.com>
	<20060109175938.2B6233C01C9@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: Harald Tveit Alvestrand ,
	Sam Hartman , ietf@ietf.org,
	Scott W Brim , Stewart Bryant 
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> In message <43C28701.4000203@cisco.com>, Scott W Brim writes:
> >On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
> >> Are you looking for normative figures?  If so, can you point to an
> >> example where you think they are necessary?  (I'd like to avoid a
> >> discussion of packet diagrams for the moment if that's OK)
> >
> >Normative figures perhaps.  Normative equations definitely.
> >
> >Is there any input format for *just* equations (or figures), standing
> >by themselves, which we can agree is open, standardized, stable and
> >deterministic in output?
> >

> LaTeX is the standard in the math and theory world.  It's free, and
> runs on just about everything.

LaTeX or some other TeX variant. AMS-TeX is one such but there are a bunch of
others. (Always fun when you get TeX source that uses a macro package you don't
have available.)

> If I recall correctly what Kernighan
> once said, eqn was designed so that its input language was more or
> less what one mathematician would say to another over the phone, which
> (I assume) would help with accessibility.  There are open source versions
> of eqn; I think that they run on more or less anything, too.

Personally, I'm unconvinced that design goal was met.

> In the pure HTML world, there's MathML, though it's *really* ugly to
> read.  I have no idea how much it's supported by today's browsers.
> (Kernighan started working on an eqn to HTML translator some years ago,
> but back then no browser really worked properly for it.)

It is probably worth noting that another very popular format in the math world
for equations is essentially ASCII art. This is what you tend to get as output
from the various symbolic manipulation packages like Reduce, Macsyma, Maple,
and last time I looked, Mathematica. Stuff like:

                            2    3   2         2    3   3
             w    w x   (w k  + w ) x    (3 w k  + w ) x
(D7)/T/      -- + --- - -------------- - ---------------- + . . .
              4    3            4                 3
             k    k          6 k               6 k 

is actually pretty readable. And any of these packages can be used to generate
this sort of thing; no need to piddle around in an editor. (The example above
is a Taylor series expansion from Maxima.) These packages often have TeX and
eqn output modes as well.

Another interesting development in this space is the new programming language
Fortress being developed by Guy Steele, which sticks with simple character
strings but uses the full UTF-8 repetoire to advantage. I personally find it
hard to get used to after so many years of looking at ASCII art equations,
especially when lots of matrix and vectoor stuff is involved, but this might be
an interesting avenue to pursue if we ever started allowing UTF-8. See:

   http://research.sun.com/projects/plrg/

for additional information.

> Note that I'm *not* saying we should adopt any of these for RFCs; I'm
> simply saying that there are some well-known systems that satisfy at
> least your four criteria.

Indeed. I will also point out that as with anything having to do with which
notation is better or best, getting agreement even in the relatively narrow
confines of the math community is next to impossible. You know how it is: "The
arguments are nasty because the stakes are so low."

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 15:31:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew3g0-0005ny-RQ; Mon, 09 Jan 2006 15:31:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew3fy-0005ng-TN
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 15:31:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19892
	for ; Mon, 9 Jan 2006 15:30:16 -0500 (EST)
Message-Id: <200601092030.PAA19892@ietf.org>
Received: from venus3.veridas.net ([202.52.32.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew3mW-0002Rw-PP
	for ietf@ietf.org; Mon, 09 Jan 2006 15:38:22 -0500
Received: (qmail 3109 invoked from network); 10 Jan 2006 06:31:21 +1000
Received: from dassa@dhs.org by venus3 by uid 1001 with qmail-scanner-1.15 
	( Clear:. Processed in 2.043315 secs); 09 Jan 2006 20:31:21 -0000
Received: from dsl-125-209-164-118.nsw.veridas.net (HELO dhs) (125.209.164.118)
	by 202.52.49.177 with SMTP; 10 Jan 2006 06:31:19 +1000
Received: (qmail 31647 invoked by uid 453); 9 Jan 2006 17:27:24 -0000
Received: from dassa.dhs (HELO dassa) (192.168.0.2)
	by dhs (qpsmtpd/0.31-dev) with ESMTP; Tue, 10 Jan 2006 04:27:24 +1100
From: "Dassa" 
To: "'Stewart Bryant'" ,
	"'Sam Hartman'" 
Date: Tue, 10 Jan 2006 07:31:15 +1100
Organization: DHS International Pty Ltd Australia
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
In-Reply-To: <43C2BDA2.30908@cisco.com>
Thread-Index: AcYVVeEfbA3oNdAESsi83Q/gfy4HfQAA08XA
X-Qmail-Scanner-Message-ID: <11368386795023055@venus3>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
Cc: 'Harald Tveit Alvestrand' , ietf@ietf.org
Subject: RE: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dassa@dhs.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

|> -----Original Message-----
|> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
|> On Behalf Of Stewart Bryant
|> Sent: Tuesday, January 10, 2006 6:47 AM
|> To: Sam Hartman
|> Cc: Harald Tveit Alvestrand; ietf@ietf.org
|> Subject: Re: Normative figures
|> 
|> Sam Hartman wrote:
|> 
|> >Hi.  With the exception of packet diagrams, I think all the 
|> examples 
|> >you bring up benefit significantly from clear textual description.
|> >
|> Sam
|> 
|> I am not saying that clear text is not needed to accompany a diagram.
|> However a diagram allows a lot less text to be written 
|> producing a shorter clearer draft with less clutter.


Perhaps this is getting to the crux of the issues.  I see the IETF documents
as breaking down the problems into smaller chunks that can be dealt with one
at a time and which add up to a big picture description of the whole Internet.
I see each individual document as being simple within itself, limiting the
context to the smallest level an issue may be dealt with.  By adding more
complexity to the documents I feel it is allowing more complex issues to be
described in the documents but the documents then become larger, more
difficult to comprehend and will be more difficult to process.

Using the example you gave for routing costs, I see the description of routing
cost basics or specifics as one document and the description of how they may
be dealt with as another.

By forcing the documents to be in a simple format, there are limitations on
the complexity that may be explained in a single document, but I consider this
a good thing.  It forces everyone to break the problems and issues down to
their lowest levels and forces simple explanations that make it easier for
everyone to understand.

If more complex documents with full diagramatic process flows are required,
these could be books written linking a number of IETF documents together to
describe a more general practical picture of their implementation.

Darryl (Dassa) Lynch 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 15:40:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew3oI-0006wb-OQ; Mon, 09 Jan 2006 15:40:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew3oF-0006up-C6
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 15:40:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20304
	for ; Mon, 9 Jan 2006 15:38:49 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew3un-0002eu-Kj
	for ietf@ietf.org; Mon, 09 Jan 2006 15:46:55 -0500
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k09KdxMj001469
	for ; Mon, 9 Jan 2006 12:40:00 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <01LXK74JQTPU00009C@mauve.mrochek.com>
References: <43C28701.4000203@cisco.com>
	<20060109175938.2B6233C01C9@berkshire.machshav.com>
	<01LXK74JQTPU00009C@mauve.mrochek.com>
Date: Mon, 9 Jan 2006 12:40:06 -0800
To: ietf@ietf.org
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>  > LaTeX is the standard in the math and theory world.  It's free, and
>>  runs on just about everything.
>
>LaTeX or some other TeX variant. AMS-TeX is one such but there are a bunch of
>others. (Always fun when you get TeX source that uses a macro 
>package you don't
>have available.)

Why are we talking about the input formats and not the output 
formats? Are people suggesting that we allow LaTeX and so on as 
*output* formats and appear in Internet Drafts and RFCs?

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 17:05:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew593-0002Ys-IB; Mon, 09 Jan 2006 17:05:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew591-0002Yk-2Y
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 17:05:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02545
	for ; Mon, 9 Jan 2006 17:04:20 -0500 (EST)
Received: from smtp136.iad.emailsrvr.com ([207.97.245.136])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew5Fa-0007iW-72
	for ietf@ietf.org; Mon, 09 Jan 2006 17:12:27 -0500
Received: from [192.168.2.6] (69-170-29-227.chvlva.adelphia.net
	[69.170.29.227]) (Authenticated sender: rpelletier@isoc.org)
	by relay3.r3.iad.emailsrvr.com (SMTP Server) with ESMTP id 41BD744CF34
	for ; Mon,  9 Jan 2006 17:05:27 -0500 (EST)
Message-ID: <43C2DEB4.8010406@isoc.org>
Date: Mon, 09 Jan 2006 17:07:48 -0500
From: Ray Pelletier 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
X-Virus-Scanned: OK
X-Spam-Score: 1.1 (+)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Subject: IETF Meeting Survey
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2074756467=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.
--===============2074756467==
Content-Type: multipart/alternative;
	boundary="------------060104080807060202040300"

This is a multi-part message in MIME format.
--------------060104080807060202040300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

All:
To assist the planning of future meetings, we ask you kindly to spend a 
minute or two responding
to the on-line survey at https://www.surveymonkey.com/s.asp?u=465231656574

Even if you did not attend IETF 64 in Vancouver, we would value your 
responses.
All responses will be treated anonymously, and a summary will be 
available on-line.

Please respond by January 20, 2006 at the latest.

Thanks,

Ray Pelletier
IETF Administrative Director.


--------------060104080807060202040300
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


All:

To
assist the planning of future meetings, we
ask you kindly to spend a minute or two responding 

to the on-line survey at https://www.surveymonkey.com/s.asp?u=465231656574



Even if
you did not attend IETF 64 in Vancouver, we would
value your responses. 

All responses will be treated anonymously, and a summary will be
available on-line. 



Please respond by January 20, 2006 at the latest.



Thanks,



Ray Pelletier

IETF Administrative Director.







--------------060104080807060202040300--


--===============2074756467==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============2074756467==--




From ietf-bounces@ietf.org Mon Jan 09 17:09:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew5CK-0002zt-Cc; Mon, 09 Jan 2006 17:09:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5CI-0002zo-Lj
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 17:09:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02711
	for ; Mon, 9 Jan 2006 17:07:43 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew5Iq-0007oH-GQ
	for ietf@ietf.org; Mon, 09 Jan 2006 17:15:51 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k09M9H3l029661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 9 Jan 2006 14:09:18 -0800
Message-ID: <43C2DEE4.2030407@dcrocker.net>
Date: Mon, 09 Jan 2006 14:08:36 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: IETF General Discussion Mailing List 
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms	.marconi.com>	<43BD5BDE.4070905@WEIJax.com>	<43BD9BA0.2000204@swin.edu.au>	<43BDAD26.9020909@WEIJax.com>		<43BE786D.6050006@WEIJax.com>			<43BEAE5C.1040705@WEIJax.com>
	<43C261FF.5020106@zurich.ibm.com>
In-Reply-To: <43C261FF.5020106@zurich.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Content-Transfer-Encoding: 7bit
Subject: Re: Trying to invent a way of determining "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Folks,

>>   Anyone who agrees with the CfC statement, and doesn't say anything, 
>> is fine, because the CfC doesn't need or want their support.  ...
> 
> That's pretty much how I've seen IETF consensus work over the years.


There are two, essential assumptions that serve as underpinnings for the IETF's 
rough consensus construct:

    1.  Participation in the IETF is dominated by those with sufficient 
expertise for making informed assessment, and

    2.  Participation in the IETF is dominated by those with sufficient interest
to ensure forward progress is made in a timely fashion.

Today's IETF is marked by massively more diversity than was present 15 years
ago. For most IETF activities, most IETF participants do *not* have very much
knowledge or interest.

While this violates the stated assumptions, it also means that such folk stay
pretty quiet, about most IETF activities.  For these cases, the "see who 
objects" model makes sense and appears to work acceptably...  once the basic 
competence of a proposal or specification is assessed.

However, many IETF activities draw the attention of these folk who lack
knowledge and/or lack a desire for making near-term progress (or any progress at
all.)  If a topic is sufficiently "interesting" it draws quite a few of these
people and the current model effectively gives them a veto.

We need to fix this.

      The IETF needs to modify its method of assessing rough consensus, to
      distinguish between those motivated to make timely progress and those with
      other agendas.  Of course, this needs to be accomplished in a way that
      continues to attend to basic technical and operational competence.

Other agendas include such sources of delay and distraction as expanding the
scope of the work, pressing for alternate solutions, or raising a myriad of
generic concerns that really are present for all new work.  (Hence, attending to 
them represents either a strategic issue for the IETF or an unsolvable problem.)

In other words, those trying to solve a particular problem in a competent
fashion, and to get it deployed in a timely manner, need to be able to make
progress efficiently.

Anyone, at any time, may expose a critical risk or critical failure in a
proposal or specification.  No IETF procedure should *ever* work against having
such exposures gain attention.

That said, the current IETF process allows delay and distraction for many 
reasons that are entirely secondary.

I believe that utility, quality and timely progress are not mutually exclusive 
and that a rather simple framework can accommodate all of them:

    1. A constituency is a group of otherwise-independent individuals seeking to 
produce a specification that provides a set of desirable enhancements or fixes 
an acknowledged set of problems.

    2. A charter specifies the scope, schedule and deliverables for a 
constituency's efforts.  Those claiming to be part of the constituency are 
committing to that scope, schedule and deliverables.

    3. On-going review and input by others are essential to a constituency's 
efforts.  Anyone can come up with a good idea or solve a difficult problem. This 
is a key lesson of the IETF.

    4. A particular bit of input that addresses a critical failing MUST be 
heeded, no matter when it is offered.

    5. Other bits of input MAY be heeded, when the constituency agrees that the 
input is within scope, does not endanger the schedule, and is supported by the 
constituency.  Otherwise the input MAY be deferred or even ignored.

    6. The chair(s) enforce these constraints.

Of course, any suggestion like this list of rules requires that the community be 
willing to exercise self-discipline, rather than permit individuals to veto 
valid group efforts.

d/
-- 

Dave Crocker
Brandenburg InternetWorking




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 17:33:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew5a3-00023u-WB; Mon, 09 Jan 2006 17:33:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5a1-00023m-D3
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 17:33:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04076
	for ; Mon, 9 Jan 2006 17:32:14 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew5ga-0008Rd-Pg
	for ietf@ietf.org; Mon, 09 Jan 2006 17:40:22 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3714385; Mon, 09 Jan 2006 17:31:07 -0500
In-Reply-To: <20060109175938.2B6233C01C9@berkshire.machshav.com>
References: <20060109175938.2B6233C01C9@berkshire.machshav.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <529EBC00-E189-4C46-A89C-06C81E9093AA@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Mon, 9 Jan 2006 17:33:23 -0500
To: "Steven M. Bellovin" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand ,
	Sam Hartman , ietf@ietf.org,
	Scott W Brim , Stewart Bryant 
Subject: Re: Normative figures 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Note that LaTeX is an input format - it will output to many output  
formats - even to ASCII. (And, of course, it sits on  top of and  
drives TeX itself.)

As a physicist, I have used LaTeX a lot. It has a steep learning  
curve - much more than with, say, html.
When I did a set of conference proceedings in LaTEX -

Proc. USNO Workshop on Relativistic Models for use in Space Geodesy,  
1991.

most of the  papers went  fine, a few just would not display  
correctly and took a lot of tweaking just
to get them to look halfway right. These last took a lot of time.  
TeX / LaTeX is like that.

So, most journals today use style sheets, such as the AMS-TEX ones,  
and templates, to enforce their look and feel.
I suspect they have issues from time to time even with that.

Oh, and if an email line begins with "From" and get turns into  
">From", LaTex will turn that into
"From", which you can see in the strangest places,  
once you know to look for it.

There are a few WSIWYG editors for Tex/LaTex, but most people I know  
use a text editor.

I certainly would not regard moving  everything to LaTeX as a trivial  
change.

Regards
Marshall Eubanks

On Jan 9, 2006, at 12:59 PM, Steven M. Bellovin wrote:

> In message <43C28701.4000203@cisco.com>, Scott W Brim writes:
>> On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
>>> Are you looking for normative figures?  If so, can you point to an
>>> example where you think they are necessary?  (I'd like to avoid a
>>> discussion of packet diagrams for the moment if that's OK)
>>
>> Normative figures perhaps.  Normative equations definitely.
>>
>> Is there any input format for *just* equations (or figures), standing
>> by themselves, which we can agree is open, standardized, stable and
>> deterministic in output?
>>
>
> LaTeX is the standard in the math and theory world.  It's free, and
> runs on just about everything.  If I recall correctly what Kernighan
> once said, eqn was designed so that its input language was more or
> less what one mathematician would say to another over the phone, which
> (I assume) would help with accessibility.  There are open source  
> versions
> of eqn; I think that they run on more or less anything, too.
> In the pure HTML world, there's MathML, though it's *really* ugly to
> read.  I have no idea how much it's supported by today's browsers.
> (Kernighan started working on an eqn to HTML translator some years  
> ago,
> but back then no browser really worked properly for it.)
>
> Note that I'm *not* saying we should adopt any of these for RFCs; I'm
> simply saying that there are some well-known systems that satisfy at
> least your four criteria.
>
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 17:37:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew5dj-0003CH-IM; Mon, 09 Jan 2006 17:37:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5dg-0003C5-UR
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 17:37:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04278
	for ; Mon, 9 Jan 2006 17:36:01 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew5kG-00005W-2C
	for ietf@ietf.org; Mon, 09 Jan 2006 17:44:09 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k09Mb5SD013486; Mon, 9 Jan 2006 17:37:06 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA22551; 
	Mon, 9 Jan 2006 17:37:05 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Mon, 9 Jan 2006 17:37:03 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C8862A8@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Stewart Bryant'" 
Date: Mon, 9 Jan 2006 17:35:51 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186
Cc: ietf@ietf.org
Subject: RE: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart,

	You realize that the text "example" you gave is meaningless - 
without making some (potentially non-obvious) assumptions, right? 

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Stewart Bryant
--> Sent: Monday, January 09, 2006 2:47 PM
--> To: Sam Hartman
--> Cc: Harald Tveit Alvestrand; ietf@ietf.org
--> Subject: Re: Normative figures
--> 
--> Sam Hartman wrote:
--> 
--> >Hi.  With the exception of packet diagrams, I think all 
--> the examples
--> >you bring up benefit significantly from clear textual description.
--> >
--> Sam
--> 
--> I am not saying that clear text is not needed to accompany 
--> a diagram.
--> However a diagram allows a lot less text to be written producing a
--> shorter clearer draft with less clutter.
--> 
--> For example you could say the following in text : router A connects to
--> router B and D, the cost from A to B is 2, and the cost from A to D is
4.

	A --(2)--> B
      |
      +---(4)--> D

--> Router B connects to router C. The cost to router A is 6, and
--> the cost to router C is 10. 

     + A <--(6)--+
     | |         |
     | +--(2)--> B --(10)--> C
     |
     +--(4)--> D

(Assumes "cost" is from router B in both cases)

--> Router C connects to router D. The cost to router B is 9
--> and the cost to router D is 8. 

     + A <--(6)--+
     | |         |
     | +--(2)--> B <--(9)---+
     |           |          |
     |           +--(10)--> C
     |                      |
     +--(4)--> D <----(8)---+

(Assumes "cost" is from router C in both cases)

--> The cost from router D to router A is 16 and ...

  +------+
  |      |
  |  +-> A <--(6)--+
  |  |   |         |
  |  |   +--(2)--> B <--(9)---+
  |  |             |          |
  |  +--(16)----+  +--(10)--> C
  |             |             |
  +------(4)--> D <----(8)----+

--> 
--> ... the cost to router A is 99.

?

(Assuming you meant the cost from D to C - not A)

  +------+
  |      |
  |  +-> A <--(6)--+
  |  |   |         |
  |  |   +--(2)--> B <--(9)---+
  |  |             |          |
  |  +--(16)----+  +--(10)--> C <-+
  |             |             |   |
  +------(4)--> D <----(8)----+   |
                |                 |
                +-----(99)--------+

		(Figure foo?)


-->
--> In fact you would probably need a table to make sure that 
--> you did not make a mistake. In either case it is hard for 
--> most people to figure out the what the topology is much 
--> less imagine packet actions.

Actually, you need a figure to make sure that you did not
make a mistake, and a second set of eyes to compare what 
you said to what you apparently meant.

--> 
--> Now compare this to:
--> 
--> "The network and costs are as shown in figure foo."
--> 

Is the above actually figure foo?

The reality is that it would be better to break it this way:

"In the network in figure foo, the link costs are as follows:

    A -> B =  2
    B -> A =  6             +-> A <----> B <-+
    A -> D =  4             |                |
    D -> A = 16             +-> D <----> C <-+
    B -> C = 10
    C -> B =  9                 Figure foo
    C -> D =  8
    D -> C = 99                                          "

--> Simple text and the visualisation is already done for you
--> so you can focus on the problem.
-->

The reality is that putting things entirely in pictures means
that less validation of the intent of the picture is possible.
Keeping pictures as simple as possible is, therefore, a goal
since it is far easier to make mistakes in complex figures and 
far more difficult to determine that a mistake has been made.

Using a mixture of text and figure(s), tables or - possibly -
equations makes it both more understandable and easier to be
certain of conveying the idea(s).

For example, in the above, I could verify that I understand 
your intent by asking:

"From this it is apparent that the link cost (D->C) is 99, 
 but the actual minimum cost of getting from D to C given by 
 the formula:

 (D->A) + (A->B) + (B->C) = 16 + 2 + 10 = 28

 Is that correct?"

If we choose to use a simple combination of representations,
rather than strictly expecting a figure to explain it all,
the figure is likely to be far simpler.  For example, using
an approach similar to the above, you could probably describe
a much more complex network than 13, or 20 or maybe even 30
nodes using ASCII art.  The purpose of the picture is to be
a simplified referent.

--> 
--> Now I realise the above could be done in ascii art, but we 
--> have problems that need 13 or more nodes to set up.
--> 
--> >  I believe I'd think that even if I could see the diagrams 
--> >  and I believe I have enough experience with visualization 
--> >  (although not sight) to be confident in that belief.
--> >
--> >  
--> >
--> >As such, I don't believe these diagrams should be normative.
--> >
--> >
--> >I actually thin that many of the tunnel overlay network documents
--> >(PWE3, L2VPN, L3VPN) could benefit significantly from more focus on
--> >the text of the descriptions of situations being described.
--> >  
--> >
--> It is probably a question of how we work and the tools that we
--> find most effective.
--> 
--> >If you believe that normative documents are required, I'd 
--> like you to
--> >explain why the diagrams cannot be described in the text, 
--> why doing so
--> >would decrease the quality of the specification, or why 
--> doing so would
--> >not be a useful investment in our time.
--> >
--> >
--> >  
--> >
--> One reason is that it takes a lot of text to describe what 
--> can be drawn
--> with a few lines and symbols. Many people will get lost in 
--> the text and
--> in any case would have to transcribe the text into a diagram for
--> themselves before they could understand what is happening.
--> 
--> - Stewart
--> 
--> 
--> 
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 18:36:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew6ZG-0005fa-D4; Mon, 09 Jan 2006 18:36:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew6ZE-0005fV-RI
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 18:36:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08036
	for ; Mon, 9 Jan 2006 18:35:29 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew6fp-0001oE-Fq
	for ietf@ietf.org; Mon, 09 Jan 2006 18:43:37 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 10 Jan 2006 00:36:40 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k09NaaFZ019455; 
	Tue, 10 Jan 2006 00:36:36 +0100 (MET)
Received: from [10.61.64.13] (ams-clip-vpn-dhcp13.cisco.com [10.61.64.13])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA28158;
	Mon, 9 Jan 2006 23:36:34 GMT
Message-ID: <43C2F381.4050202@cisco.com>
Date: Mon, 09 Jan 2006 23:36:33 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dassa@dhs.org
References: <4m6448$4ph98u@sj-inbound-c.cisco.com>
In-Reply-To: <4m6448$4ph98u@sj-inbound-c.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit
Cc: 'Sam Hartman' ,
	'Harald Tveit Alvestrand' , ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dassa wrote:

>|> -----Original Message-----
>|> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
>|> On Behalf Of Stewart Bryant
>|> Sent: Tuesday, January 10, 2006 6:47 AM
>|> To: Sam Hartman
>|> Cc: Harald Tveit Alvestrand; ietf@ietf.org
>|> Subject: Re: Normative figures
>|> 
>|> Sam Hartman wrote:
>|> 
>|> >Hi.  With the exception of packet diagrams, I think all the 
>|> examples 
>|> >you bring up benefit significantly from clear textual description.
>|> >
>|> Sam
>|> 
>|> I am not saying that clear text is not needed to accompany a diagram.
>|> However a diagram allows a lot less text to be written 
>|> producing a shorter clearer draft with less clutter.
>
>
>Perhaps this is getting to the crux of the issues.  I see the IETF documents
>as breaking down the problems into smaller chunks that can be dealt with one
>at a time and which add up to a big picture description of the whole Internet.
>I see each individual document as being simple within itself, limiting the
>context to the smallest level an issue may be dealt with.  By adding more
>complexity to the documents I feel it is allowing more complex issues to be
>described in the documents but the documents then become larger, more
>difficult to comprehend and will be more difficult to process.
>
>Using the example you gave for routing costs, I see the description of routing
>cost basics or specifics as one document and the description of how they may
>be dealt with as another.
>
>By forcing the documents to be in a simple format, there are limitations on
>the complexity that may be explained in a single document, but I consider this
>a good thing.  It forces everyone to break the problems and issues down to
>their lowest levels and forces simple explanations that make it easier for
>everyone to understand.
>  
>
That does not work if you need the costs to set up a scenario that you 
are about to describe
the solution to.

>If more complex documents with full diagramatic process flows are required,
>these could be books written linking a number of IETF documents together to
>describe a more general practical picture of their implementation.
>
>  
>
It may not be possible to do that. It depends on what we are describing.

- Stewart



>Darryl (Dassa) Lynch 
>
>
>  
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 18:50:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew6mc-0001Dp-SS; Mon, 09 Jan 2006 18:50:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew6ma-0001Dc-LB
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 18:50:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08829
	for ; Mon, 9 Jan 2006 18:49:17 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew6tB-00029r-48
	for ietf@ietf.org; Mon, 09 Jan 2006 18:57:25 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 10 Jan 2006 00:50:27 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k09NoOFZ021107; 
	Tue, 10 Jan 2006 00:50:25 +0100 (MET)
Received: from [10.61.64.13] (ams-clip-vpn-dhcp13.cisco.com [10.61.64.13])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA29144;
	Mon, 9 Jan 2006 23:50:23 GMT
Message-ID: <43C2F6BF.8060905@cisco.com>
Date: Mon, 09 Jan 2006 23:50:23 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C8862A8@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C8862A8@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Eric

You are missing the point.

I was picking an example out of thin air, but it is the type of construct
that we use all the time in fast-reroute.

The example was  four routers connected together in a square with some
randomly chosen asymetric costs. Such a network is trivial, but FRR
need to cope with arbitary network fragments with arbitary costs,
so there are lots of fragments that we have created for study the
properties of.

One of the ways to operate on the fragment is to draw it and
then to figure out the packet flows, consequences of failure etc
etc.

Now the question is why should the examples in our drafts be forced
by our ability to describe them, rather than being the example that
most clearly illustrates the problem and its solution?

- Stewart


Gray, Eric wrote:

>Stewart,
>
>	You realize that the text "example" you gave is meaningless - 
>without making some (potentially non-obvious) assumptions, right? 
>
>--> -----Original Message-----
>--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
>--> On Behalf Of Stewart Bryant
>--> Sent: Monday, January 09, 2006 2:47 PM
>--> To: Sam Hartman
>--> Cc: Harald Tveit Alvestrand; ietf@ietf.org
>--> Subject: Re: Normative figures
>--> 
>--> Sam Hartman wrote:
>--> 
>--> >Hi.  With the exception of packet diagrams, I think all 
>--> the examples
>--> >you bring up benefit significantly from clear textual description.
>--> >
>--> Sam
>--> 
>--> I am not saying that clear text is not needed to accompany 
>--> a diagram.
>--> However a diagram allows a lot less text to be written producing a
>--> shorter clearer draft with less clutter.
>--> 
>--> For example you could say the following in text : router A connects to
>--> router B and D, the cost from A to B is 2, and the cost from A to D is
>4.
>
>	A --(2)--> B
>      |
>      +---(4)--> D
>
>--> Router B connects to router C. The cost to router A is 6, and
>--> the cost to router C is 10. 
>
>     + A <--(6)--+
>     | |         |
>     | +--(2)--> B --(10)--> C
>     |
>     +--(4)--> D
>
>(Assumes "cost" is from router B in both cases)
>
>--> Router C connects to router D. The cost to router B is 9
>--> and the cost to router D is 8. 
>
>     + A <--(6)--+
>     | |         |
>     | +--(2)--> B <--(9)---+
>     |           |          |
>     |           +--(10)--> C
>     |                      |
>     +--(4)--> D <----(8)---+
>
>(Assumes "cost" is from router C in both cases)
>
>--> The cost from router D to router A is 16 and ...
>
>  +------+
>  |      |
>  |  +-> A <--(6)--+
>  |  |   |         |
>  |  |   +--(2)--> B <--(9)---+
>  |  |             |          |
>  |  +--(16)----+  +--(10)--> C
>  |             |             |
>  +------(4)--> D <----(8)----+
>
>--> 
>--> ... the cost to router A is 99.
>
>?
>
>(Assuming you meant the cost from D to C - not A)
>
>  +------+
>  |      |
>  |  +-> A <--(6)--+
>  |  |   |         |
>  |  |   +--(2)--> B <--(9)---+
>  |  |             |          |
>  |  +--(16)----+  +--(10)--> C <-+
>  |             |             |   |
>  +------(4)--> D <----(8)----+   |
>                |                 |
>                +-----(99)--------+
>
>		(Figure foo?)
>
>
>-->
>--> In fact you would probably need a table to make sure that 
>--> you did not make a mistake. In either case it is hard for 
>--> most people to figure out the what the topology is much 
>--> less imagine packet actions.
>
>Actually, you need a figure to make sure that you did not
>make a mistake, and a second set of eyes to compare what 
>you said to what you apparently meant.
>
>--> 
>--> Now compare this to:
>--> 
>--> "The network and costs are as shown in figure foo."
>--> 
>
>Is the above actually figure foo?
>
>The reality is that it would be better to break it this way:
>
>"In the network in figure foo, the link costs are as follows:
>
>    A -> B =  2
>    B -> A =  6             +-> A <----> B <-+
>    A -> D =  4             |                |
>    D -> A = 16             +-> D <----> C <-+
>    B -> C = 10
>    C -> B =  9                 Figure foo
>    C -> D =  8
>    D -> C = 99                                          "
>
>--> Simple text and the visualisation is already done for you
>--> so you can focus on the problem.
>-->
>
>The reality is that putting things entirely in pictures means
>that less validation of the intent of the picture is possible.
>Keeping pictures as simple as possible is, therefore, a goal
>since it is far easier to make mistakes in complex figures and 
>far more difficult to determine that a mistake has been made.
>
>Using a mixture of text and figure(s), tables or - possibly -
>equations makes it both more understandable and easier to be
>certain of conveying the idea(s).
>
>For example, in the above, I could verify that I understand 
>your intent by asking:
>
>"From this it is apparent that the link cost (D->C) is 99, 
> but the actual minimum cost of getting from D to C given by 
> the formula:
>
> (D->A) + (A->B) + (B->C) = 16 + 2 + 10 = 28
>
> Is that correct?"
>
>If we choose to use a simple combination of representations,
>rather than strictly expecting a figure to explain it all,
>the figure is likely to be far simpler.  For example, using
>an approach similar to the above, you could probably describe
>a much more complex network than 13, or 20 or maybe even 30
>nodes using ASCII art.  The purpose of the picture is to be
>a simplified referent.
>
>--> 
>--> Now I realise the above could be done in ascii art, but we 
>--> have problems that need 13 or more nodes to set up.
>--> 
>--> >  I believe I'd think that even if I could see the diagrams 
>--> >  and I believe I have enough experience with visualization 
>--> >  (although not sight) to be confident in that belief.
>--> >
>--> >  
>--> >
>--> >As such, I don't believe these diagrams should be normative.
>--> >
>--> >
>--> >I actually thin that many of the tunnel overlay network documents
>--> >(PWE3, L2VPN, L3VPN) could benefit significantly from more focus on
>--> >the text of the descriptions of situations being described.
>--> >  
>--> >
>--> It is probably a question of how we work and the tools that we
>--> find most effective.
>--> 
>--> >If you believe that normative documents are required, I'd 
>--> like you to
>--> >explain why the diagrams cannot be described in the text, 
>--> why doing so
>--> >would decrease the quality of the specification, or why 
>--> doing so would
>--> >not be a useful investment in our time.
>--> >
>--> >
>--> >  
>--> >
>--> One reason is that it takes a lot of text to describe what 
>--> can be drawn
>--> with a few lines and symbols. Many people will get lost in 
>--> the text and
>--> in any case would have to transcribe the text into a diagram for
>--> themselves before they could understand what is happening.
>--> 
>--> - Stewart
>--> 
>--> 
>--> 
>--> 
>--> 
>--> _______________________________________________
>--> Ietf mailing list
>--> Ietf@ietf.org
>--> https://www1.ietf.org/mailman/listinfo/ietf
>--> 
>
>
>  
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 19:30:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew7PV-00078e-Vs; Mon, 09 Jan 2006 19:30:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew7PU-00078Z-HY
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 19:30:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13232
	for ; Mon, 9 Jan 2006 19:29:28 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew7W5-0003wW-Gs
	for ietf@ietf.org; Mon, 09 Jan 2006 19:37:38 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0A0UcSD015162; Mon, 9 Jan 2006 19:30:38 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA04320; 
	Mon, 9 Jan 2006 19:30:38 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Mon, 9 Jan 2006 19:30:36 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C8862AE@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Stewart Bryant'" 
Date: Mon, 9 Jan 2006 19:28:52 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b
Cc: ietf@ietf.org
Subject: RE: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart,

	See below...

--
Eric 

--> -----Original Message-----
--> From: Stewart Bryant [mailto:stbryant@cisco.com] 
--> Sent: Monday, January 09, 2006 6:50 PM
--> To: Gray, Eric
--> Cc: ietf@ietf.org
--> Subject: Re: Normative figures
--> 
--> Eric
--> 
--> You are missing the point.
--> 

Out of politeness, let's consider the possibility that I am 
not missing the point.

-->
--> I was picking an example out of thin air, but it is the 
--> type of construct that we use all the time in fast-reroute.
-->

I follow that discussion in each WG in which it has come up.

--> 
--> The example was four routers connected together in a 
--> square with some randomly chosen asymetric costs. Such a 
--> network is trivial, but FRR need to cope with arbitary 
--> network fragments with arbitary costs, so there are lots 
--> of fragments that we have created for study the properties 
--> of.
-->

Yes.  And, if we're talking about wanting to make the figures
normative, I assume we are talking about a specification.  In
that case, it is far more important that the description MUST 
be precise, than it is that it MAY be convenient.

As I indicated in my response, it is possible to represent a
lot of different topologies in simplistic figures with textual
descriptions and - potentially other means of helping readers
to understand _and_ verify the specification.

--> 
--> One of the ways to operate on the fragment is to draw it and
--> then to figure out the packet flows, consequences of failure etc
--> etc.
--> 
--> Now the question is why should the examples in our drafts be forced
--> by our ability to describe them, rather than being the example that
--> most clearly illustrates the problem and its solution?
-->

There are two issues built into this question: 

1) Are the available tools preventing completion of the task, or
   do they merely constrain the ways in which it can be done?
2) Is the purpose of the task to describe, or to illustrate, the
   specified solution?

I believe these two questions - taken separately - have been 
beaten utterly to death.

In the first issue, it is clear that a number of people feel that
the current tools merely constrain the specification process.  To
many of those people, this is a good thing.  In addition, nobody 
has yet been able to demonstrate an example of a case where the 
tools - as they are (and including the potential for PDF use) are
preventing the completion of any specification task.

In the second issue, it SHOULD be clear that the task is to give
as precise a description as possible.  Most everyone agrees that
figures, tables and equations MAY help.  Most everyone agrees that
they MAY occasionally be necessary for correct understanding of a
specification.  And most people agree that text MUST be precise
and complete for specification wherever it is possible to do so.

Figures help to understand.  In many cases, they are not required.
The fact that an accurate description in text may not be easy to
produce is not nearly as important as the fact that a description
in text is easier to test for correctness.

We write specifications so that they are easier to read, validate 
and understand, not so that they are easier to write.

--> 
--> - Stewart
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >Stewart,
--> >
--> >	You realize that the text "example" you gave is meaningless - 
--> >without making some (potentially non-obvious) assumptions, right? 
--> >
--> >--> -----Original Message-----
--> >--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> >--> On Behalf Of Stewart Bryant
--> >--> Sent: Monday, January 09, 2006 2:47 PM
--> >--> To: Sam Hartman
--> >--> Cc: Harald Tveit Alvestrand; ietf@ietf.org
--> >--> Subject: Re: Normative figures
--> >--> 
--> >--> Sam Hartman wrote:
--> >--> 
--> >--> >Hi.  With the exception of packet diagrams, I think all 
--> >--> the examples
--> >--> >you bring up benefit significantly from clear textual 
--> description.
--> >--> >
--> >--> Sam
--> >--> 
--> >--> I am not saying that clear text is not needed to accompany 
--> >--> a diagram.
--> >--> However a diagram allows a lot less text to be written 
--> producing a
--> >--> shorter clearer draft with less clutter.
--> >--> 
--> >--> For example you could say the following in text : 
--> router A connects to
--> >--> router B and D, the cost from A to B is 2, and the 
--> cost from A to D is
--> >4.
--> >
--> >	A --(2)--> B
--> >      |
--> >      +---(4)--> D
--> >
--> >--> Router B connects to router C. The cost to router A is 6, and
--> >--> the cost to router C is 10. 
--> >
--> >     + A <--(6)--+
--> >     | |         |
--> >     | +--(2)--> B --(10)--> C
--> >     |
--> >     +--(4)--> D
--> >
--> >(Assumes "cost" is from router B in both cases)
--> >
--> >--> Router C connects to router D. The cost to router B is 9
--> >--> and the cost to router D is 8. 
--> >
--> >     + A <--(6)--+
--> >     | |         |
--> >     | +--(2)--> B <--(9)---+
--> >     |           |          |
--> >     |           +--(10)--> C
--> >     |                      |
--> >     +--(4)--> D <----(8)---+
--> >
--> >(Assumes "cost" is from router C in both cases)
--> >
--> >--> The cost from router D to router A is 16 and ...
--> >
--> >  +------+
--> >  |      |
--> >  |  +-> A <--(6)--+
--> >  |  |   |         |
--> >  |  |   +--(2)--> B <--(9)---+
--> >  |  |             |          |
--> >  |  +--(16)----+  +--(10)--> C
--> >  |             |             |
--> >  +------(4)--> D <----(8)----+
--> >
--> >--> 
--> >--> ... the cost to router A is 99.
--> >
--> >?
--> >
--> >(Assuming you meant the cost from D to C - not A)
--> >
--> >  +------+
--> >  |      |
--> >  |  +-> A <--(6)--+
--> >  |  |   |         |
--> >  |  |   +--(2)--> B <--(9)---+
--> >  |  |             |          |
--> >  |  +--(16)----+  +--(10)--> C <-+
--> >  |             |             |   |
--> >  +------(4)--> D <----(8)----+   |
--> >                |                 |
--> >                +-----(99)--------+
--> >
--> >		(Figure foo?)
--> >
--> >
--> >-->
--> >--> In fact you would probably need a table to make sure that 
--> >--> you did not make a mistake. In either case it is hard for 
--> >--> most people to figure out the what the topology is much 
--> >--> less imagine packet actions.
--> >
--> >Actually, you need a figure to make sure that you did not
--> >make a mistake, and a second set of eyes to compare what 
--> >you said to what you apparently meant.
--> >
--> >--> 
--> >--> Now compare this to:
--> >--> 
--> >--> "The network and costs are as shown in figure foo."
--> >--> 
--> >
--> >Is the above actually figure foo?
--> >
--> >The reality is that it would be better to break it this way:
--> >
--> >"In the network in figure foo, the link costs are as follows:
--> >
--> >    A -> B =  2
--> >    B -> A =  6             +-> A <----> B <-+
--> >    A -> D =  4             |                |
--> >    D -> A = 16             +-> D <----> C <-+
--> >    B -> C = 10
--> >    C -> B =  9                 Figure foo
--> >    C -> D =  8
--> >    D -> C = 99                                          "
--> >
--> >--> Simple text and the visualisation is already done for you
--> >--> so you can focus on the problem.
--> >-->
--> >
--> >The reality is that putting things entirely in pictures means
--> >that less validation of the intent of the picture is possible.
--> >Keeping pictures as simple as possible is, therefore, a goal
--> >since it is far easier to make mistakes in complex figures and 
--> >far more difficult to determine that a mistake has been made.
--> >
--> >Using a mixture of text and figure(s), tables or - possibly -
--> >equations makes it both more understandable and easier to be
--> >certain of conveying the idea(s).
--> >
--> >For example, in the above, I could verify that I understand 
--> >your intent by asking:
--> >
--> >"From this it is apparent that the link cost (D->C) is 99, 
--> > but the actual minimum cost of getting from D to C given by 
--> > the formula:
--> >
--> > (D->A) + (A->B) + (B->C) = 16 + 2 + 10 = 28
--> >
--> > Is that correct?"
--> >
--> >If we choose to use a simple combination of representations,
--> >rather than strictly expecting a figure to explain it all,
--> >the figure is likely to be far simpler.  For example, using
--> >an approach similar to the above, you could probably describe
--> >a much more complex network than 13, or 20 or maybe even 30
--> >nodes using ASCII art.  The purpose of the picture is to be
--> >a simplified referent.
--> >
--> >--> 
--> >--> Now I realise the above could be done in ascii art, but we 
--> >--> have problems that need 13 or more nodes to set up.
--> >--> 
--> >--> >  I believe I'd think that even if I could see the diagrams 
--> >--> >  and I believe I have enough experience with visualization 
--> >--> >  (although not sight) to be confident in that belief.
--> >--> >
--> >--> >  
--> >--> >
--> >--> >As such, I don't believe these diagrams should be normative.
--> >--> >
--> >--> >
--> >--> >I actually thin that many of the tunnel overlay 
--> network documents
--> >--> >(PWE3, L2VPN, L3VPN) could benefit significantly from 
--> more focus on
--> >--> >the text of the descriptions of situations being described.
--> >--> >  
--> >--> >
--> >--> It is probably a question of how we work and the tools that we
--> >--> find most effective.
--> >--> 
--> >--> >If you believe that normative documents are required, I'd 
--> >--> like you to
--> >--> >explain why the diagrams cannot be described in the text, 
--> >--> why doing so
--> >--> >would decrease the quality of the specification, or why 
--> >--> doing so would
--> >--> >not be a useful investment in our time.
--> >--> >
--> >--> >
--> >--> >  
--> >--> >
--> >--> One reason is that it takes a lot of text to describe what 
--> >--> can be drawn
--> >--> with a few lines and symbols. Many people will get lost in 
--> >--> the text and
--> >--> in any case would have to transcribe the text into a 
--> diagram for
--> >--> themselves before they could understand what is happening.
--> >--> 
--> >--> - Stewart
--> >--> 
--> >--> 
--> >--> 
--> >--> 
--> >--> 
--> >--> _______________________________________________
--> >--> Ietf mailing list
--> >--> Ietf@ietf.org
--> >--> https://www1.ietf.org/mailman/listinfo/ietf
--> >--> 
--> >
--> >
--> >  
--> >
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 21:04:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ew8sA-0004Ex-7d; Mon, 09 Jan 2006 21:04:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew8s8-0004En-48
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 21:04:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21469
	for ; Mon, 9 Jan 2006 21:03:08 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew8yj-0007N0-Tl
	for ietf@ietf.org; Mon, 09 Jan 2006 21:11:18 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LXKJV5D5GW001P31@mauve.mrochek.com> for
	ietf@ietf.org; Mon, 9 Jan 2006 18:04:15 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1136858654;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=pFkN+JjDaI/WzGgV8j+fgQsSS
	fxCgEW8XWahrYqwDgw54JmC7lOr/uyWy2esqh5CfQCHt9Kq7pFqg+c+YnGX2w==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LXDGWDO8BK00009C@mauve.mrochek.com>; Mon,
	09 Jan 2006 18:04:10 -0800 (PST)
To: John C Klensin 
Message-id: <01LXKJV31COE00009C@mauve.mrochek.com>
Date: Mon, 09 Jan 2006 17:16:18 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 09 Jan 2006 14:02:59 -0500"
	<07E7D8FF42ED6429ABFC943F@p3.JCK.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <43BD82D2.7070201@WEIJax.com> 
	<43C2A8BC.2030407@cisco.com> <07E7D8FF42ED6429ABFC943F@p3.JCK.COM>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Cc: Sam Hartman , ietf@ietf.org,
	Sandy Wills , Stewart Bryant 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> > I disagree that the use of diagrams is a religious issue. Diagrams
> > are a very simple way to put specification and context together
> > in a compact notation such that it is easy to move from key
> > point to key point in a non-linear way. They provide visual
> > hyperlinking.

> Stewart,

> While I agree that diagrams are not simply a religious issue, I
> think that there are many cases in which the use of diagrams,
> especially complex ones, leaves people with the impression that
> they have understood something when, in fact, they do not.  Ed
> Tufte's work, among many others, has provided repeated
> graphical, and often humorous, illustrations of that point.

That's an interesting way of looking at it that I hadn't considered before.
Tufte's work is for the most part focused on elaboration of the best techniques
for presenting things visually - lessons that few us seem to heed. But it also
provides a catalog of how and sometimes even why things go wrong, as well as
providing ample evidence of how surprisingly hard it is to get this stuff
right.

> Part of that issue overlaps the resistance to WG sessions that
> are dominated by PowerPoint presentations every time that
> discussion breaks out, although some of that discussion is
> driven by what are clearly religious issues.

I guess, although I find Tufte's monograph on PowerPoint to be pretty
levelheaded but a savage indictment nevertheless.

> This brings us back to one on the early comments in these
> threads -- that the need to describe a complex concept in text
> or in ASCII art imposes a discipline that is actually quite
> useful.  I agree with you that there are some things that cannot
> be thus described with a sensible amount of effort, but it has
> seemed to me that it would be helpful, from a document quality
> standpoint, to examine each case and to try to strive for the
> minimum diagram complexity that is actually necessary.

Not to sound trite, but whether or not a diagram works to advantage is highly
dependent on the visual aspects of the thing being diagrammed. And sometimes
finding those aspects (or not finding them, as the case may be) requires some
effort.

For example, one time I drew out a state diagram for SMTP (which is
surprisingly complex, BTW) with the intention of asking you to include it in
821bis (now 2821). I don't recall if I ever showed it to you or not, but it's a
case where a diagram hurts rather than helps. But you have to draw it and
fiddle with it in order to see it.

The TCP state diagram, OTOH, is one where a diagram really helps. At least
part of this is due to the fact that there are symmetries in the state
flow that most easily observed in a diagram - they'd be hard to see in text.

Another example is the teletex state machine (T.101 or something like that -
I'm not going to bother to search for it) is so complex that the state diagram
fills at least two pages and still leaves out some details. It seems likely
that no amount of graphical or prose ingenuity would be sufficient to tame this
particular beast. The authors of the specification that includes appear to have
tried (and IMO failed).

In any case, while I think better diagrams would be helpful, I am concerned
that if we make them cheap and easy we will actually lower the quality of
our specifications, not raise it.

> I get even more concerned when it is suggested that not only are
> diagrams are needed, but that color documents may be needed.
> While things are easier than they were a decade or two ago, the
> need to transmit and render color images imposes costs in both
> printing facilities and transmission sizes of documents that I,
> at least, would prefer to avoid unless necessity can be
> demonstrated.  Sam can, and I hope will, speak for himself, but
> my experience working with programmers with visual difficulties
> some years ago suggests that while monochrome line art --whether
> conveniently expressible in ASCII or not-- can often be made
> comprehensible with sufficient effort, either continuous-tone
> materials or line-art drawings that depend on color are fairly
> close to impossible.

It is incredibly easy to misuse color coding - in fact we have a good example
in our own current processes. These days the RFC Editor makes available
differences listings showing the changes been the draft and the final RFC.
These listings show deleted stuff in struck out red letters and added stuff in
dark green. This scheme may sound fine, but it isn't: Try finding an added
commas or single letter change inside of a big block of black text. That one
bit of green simply vanishes unless you look really, really close. And
sometimes a comma  can change the meaning of something quite dramatically. (I
addressed this problem personally by regenerating the differences using my own
tools that make more appropriate color choices.)

I have to say I still find it amazing given the prevalence of red-green color
blindness how much material on the web and how many applications blunder badly
in their use of red and green signals. 

> > Here is a good way to judge the value of a diagram:

> > Look at a diagram presented in an IETF WG session and ask the
> > questions : does this diagram make the draft easier to understand?
> > If the answer is yes, then the diagram should probably be in
> > the draft.

> I think that criterion leads down a slippery slope toward
> documents that are collections of PowerPoint images.

I'm afraid I have to agree.

> ...

> > The problem is that it is frequently impossible to translate
> > the clarity of the graphics used in the presentation to the
> > technology of ASCII art.

> Assuming we agree on that, can we figure out some criteria or
> guidelines for keeping graphics to the minimum complexity needed
> to express ideas, for being sure that graphics are accompanied
> by good  explanations whenever possible, and generally for
> preventing people from going hog-wild with complex colored
> illustrations?   It seems to me that, if possible, we also need
> to find ways to be sure that any normative graphics that appear
> in I-Ds can be edited with tools that are easily accessible on
> all relevant platforms.

These are precisely the issues that have to be addressed. I'd love to have
the ability to include better diagrams, but not if it means compromising
on any of these points.

> Most of the above of course are probably best taken as input to,
> or evaluation criteria for, precisely the sort of experiment
> that Sam suggests.

I agree, but with one important caveat: Some aspects of this problem cannot
possibly be tested by any short-lived experiment. The most obvious example is
format longevity and stability: Microsoft Word as a format might be
sufficiently stable for the duraction of such an experiment, but that says
little if anything about the stability of the format for a couple of decades.
Like it or not, the only thing we have to go on in this space is past
experience.

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 22:43:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwAPw-0006yP-Kr; Mon, 09 Jan 2006 22:43:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwAPt-0006y7-F4
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 22:43:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27707
	for ; Mon, 9 Jan 2006 22:42:06 -0500 (EST)
Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwAWV-0001h2-Er
	for ietf@ietf.org; Mon, 09 Jan 2006 22:50:16 -0500
Received: from root (helo=think.thunk.org)
	by thunker.thunk.org with local-esmtps 
	(tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32)  (Exim 4.50 #1 (Debian))
	id 1EwAPo-0005QN-2o; Mon, 09 Jan 2006 22:43:20 -0500
Received: from tytso by think.thunk.org with local (Exim 4.60)
	(envelope-from )
	id 1EwAPm-0003tD-Gi; Mon, 09 Jan 2006 22:43:18 -0500
Date: Mon, 9 Jan 2006 22:43:18 -0500
From: "Theodore Ts'o" 
To: "Gray, Eric" 
Message-ID: <20060110034318.GE12151@thunk.org>
References: <313680C9A886D511A06000204840E1CF0C88629F@whq-msgusr-02.pit.comms.marconi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <313680C9A886D511A06000204840E1CF0C88629F@whq-msgusr-02.pit.comms.marconi.com>
User-Agent: Mutt/1.5.11
X-SA-Exim-Connect-IP: 
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: 'Sam Hartman' ,
	IETF General Discussion Mailing List ,
	Sandy Wills 
Subject: Re: Binary Choices?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, Jan 09, 2006 at 12:57:56PM -0500, Gray, Eric wrote:
> 
> Usually, before you can actually seek consensus, you must have an
> essentially "binary" choice.  It is hard enough to reach consensus
> on simple choices without turning up the process noise by having a
> plethora of possible choices.
> 

I disagree here.  The process of seeking consensus means you have to
sort *through* the plethora of possible choices, and see which ones
meets the needs and requirements of the stakeholder.  If you have a
binary choice, all you can really do is force a vote.  So hopefully by
the time that you come up to your last two choices, they hopefully
aren't "binary" in the sense of 0 and 1 being diametric opposites.
Hopefully the two or three final choices are pretty closely except for
a few minor details (and then we end up spending huge amount of time
arguing over those tiny details :-)

						- Ted


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 23:37:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwBGC-0002uv-HP; Mon, 09 Jan 2006 23:37:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwBGA-0002uo-9a
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 23:37:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00920
	for ; Mon, 9 Jan 2006 23:36:07 -0500 (EST)
Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwBMm-00035N-TY
	for ietf@ietf.org; Mon, 09 Jan 2006 23:44:18 -0500
Received: from root (helo=think.thunk.org)
	by thunker.thunk.org with local-esmtps 
	(tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32)  (Exim 4.50 #1 (Debian))
	id 1EwBFs-0005ZO-0N; Mon, 09 Jan 2006 23:37:08 -0500
Received: from tytso by think.thunk.org with local (Exim 4.60)
	(envelope-from )
	id 1EwBFq-0003w7-FY; Mon, 09 Jan 2006 23:37:06 -0500
Date: Mon, 9 Jan 2006 23:37:06 -0500
From: "Theodore Ts'o" 
To: Brian Rosen 
Message-ID: <20060110043706.GH12151@thunk.org>
References: <01cf01c61397$37830280$0400a8c0@DJYXPY41>
	<001d01c613c7$7b85e530$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001d01c613c7$7b85e530$640fa8c0@cis.neustar.com>
User-Agent: Mutt/1.5.11
X-SA-Exim-Connect-IP: 
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: 'John C Klensin' , ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote:
> Any format can be used for any purpose, but it might be time to fully stand
> up to requirements to harvest data, and to recognize (as I did on another
> side thread), that reading is getting harder and harder for ASCII.  It may
> be a decent archive format still, but I'm not sure it's going to stay that
> way.

Huh?  "Harvesting data" from ASCII, in terms of pulling out MIB's to
be fed into MIB compiler, or reference C code for algorithms like MD5
(RFC 1321) is *trivial* under ASCII.  Last I checked, C compilers and
MIB compilers still use ASCII text as input, and not Word documents or
XML documents.  Maybe part of what is going on is that IETF is getting
populated with people who aren't close to coding as much as before?
You can get perfectly decent text editors for all operating systems,
even Windows.

And even Word can import text (i.e., plain ASCII) documents Just Fine.

							- Ted

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 09 23:40:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwBJD-0004Pl-B0; Mon, 09 Jan 2006 23:40:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwBJA-0004Pg-Pv
	for ietf@megatron.ietf.org; Mon, 09 Jan 2006 23:40:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01169
	for ; Mon, 9 Jan 2006 23:39:13 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwBPn-0003BX-7p
	for ietf@ietf.org; Mon, 09 Jan 2006 23:47:24 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 10 Jan 2006 05:40:22 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0A4eJFZ022173; 
	Tue, 10 Jan 2006 05:40:19 +0100 (MET)
Received: from [10.61.64.13] (ams-clip-vpn-dhcp13.cisco.com [10.61.64.13])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id EAA19100;
	Tue, 10 Jan 2006 04:40:18 GMT
Message-ID: <43C33AB2.9000804@cisco.com>
Date: Tue, 10 Jan 2006 04:40:18 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C8862AE@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C8862AE@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


>We write specifications so that they are easier to read, validate 
>and understand, not so that they are easier to write.
>
>  
>

Eric

We write specs so that they will be correctly implemented.
Anything that makes a specification easier to correctly understand
surely makes it more likely that it will be correctly implemented?

The cost of incorrect implementation is so high that we can
can afford to pay a relatively high cost in the effort and
technology needed to read and write the specification.

- Stewart






_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 00:01:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwBd5-0001ip-JU; Tue, 10 Jan 2006 00:01:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwBd2-0001fI-2t
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 00:01:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02362
	for ; Mon, 9 Jan 2006 23:59:44 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwBje-0003rH-6d
	for ietf@ietf.org; Tue, 10 Jan 2006 00:07:55 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 10 Jan 2006 06:00:53 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0A50oFZ023960; 
	Tue, 10 Jan 2006 06:00:51 +0100 (MET)
Received: from [10.61.64.13] (ams-clip-vpn-dhcp13.cisco.com [10.61.64.13])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id FAA20481;
	Tue, 10 Jan 2006 05:00:49 GMT
Message-ID: <43C33F81.8050806@cisco.com>
Date: Tue, 10 Jan 2006 05:00:49 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C8862AE@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C8862AE@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


>Yes.  And, if we're talking about wanting to make the figures
>normative, I assume we are talking about a specification.  In
>that case, it is far more important that the description MUST 
>be precise, than it is that it MAY be convenient.
>
>  
>
Please can we clarify the existing rules:

For a standards track document is it technically acceptable to provide:

A .pdf that is complete (but is non-normative under current rules)

plus

An ASCII text in which the background material refers to figures in the
.pdf  but which contains the essential normative statements.

i.e. Is a standards track RFC approvable when it is correct in the 
technical
sense, even if it is almost incomprehensible without the text, figures and
equations from its non-normative twin.

- Stewart

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 01:52:13 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwDMa-00023y-EE; Tue, 10 Jan 2006 01:52:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwDMX-00023t-Ug
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 01:52:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08862
	for ; Tue, 10 Jan 2006 01:50:50 -0500 (EST)
Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwDTB-0006gm-58
	for ietf@ietf.org; Tue, 10 Jan 2006 01:59:02 -0500
Received: from [127.0.0.1] (www.caia.swin.edu.au [136.186.229.16])
	by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id RAA714256;
	Tue, 10 Jan 2006 17:51:52 +1100 (EST)
Message-ID: <43C35983.1040507@swin.edu.au>
Date: Tue, 10 Jan 2006 17:51:47 +1100
From: grenville armitage 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <313680C9A886D511A06000204840E1CF0C8862AE@whq-msgusr-02.pit.comms.marconi.com>
	<43C33AB2.9000804@cisco.com>
In-Reply-To: <43C33AB2.9000804@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart Bryant wrote:

> 
>> We write specifications so that they are easier to read, validate and 
>> understand, not so that they are easier to write.

> Eric
> 
> We write specs so that they will be correctly implemented.
> Anything that makes a specification easier to correctly understand
> surely makes it more likely that it will be correctly implemented?

I'm a little confused. What is it about Eric's formulation of the statement
that you take exception to in your followup question? They sound the same
to me. (Or is it that you believe "easier to write" necessarily leads to
"will be more likely to be correctly implemented", and therefore "easier
to write" should not be excluded as a desirable goal of our specification
writing process?)

cheers,
gja

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 02:10:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwDee-0007CX-H9; Tue, 10 Jan 2006 02:10:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwDec-0007CD-OA
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 02:10:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09808
	for ; Tue, 10 Jan 2006 02:09:30 -0500 (EST)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwDlH-00079w-1f
	for ietf@ietf.org; Tue, 10 Jan 2006 02:17:43 -0500
X-IronPort-AV: i="3.99,349,1131339600"; 
	d="scan'208"; a="25728931:sNHT131754744"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Jan 2006 02:10:38 -0500
Message-ID: <330A23D8336C0346B5C1A5BB1966664701F542C3@ATLANTIS.Brooktrout.com>
Thread-Topic: Working Group chartering
Thread-Index: AcYQkbDWolLFdz9ZSru8nzTV/kc1VAFFKsbw
From: "Burger, Eric" 
To: "Dave Crocker" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

IMHO, *way* too many I*E*TF work groups get chartered based on an idea.
We then spend tons of resources on figuring out if the idea will work.
We produce lots of half-baked documents with little basis in working
code.  Then folks try implementing what's been spec'ed, find it doesn't
work, but then find a ton of resistance to change, because the specs are
three years old and "we don't want to break draft-mumble-05
implementations."

If something is an idea, let's make it politically acceptable for the
"work" to be done in the I*R*TF first.

Yes, I agree that the process should be fuzzy - the AD should be able to
figure out if something is likely to work in the real world.  However,
building a work group out of an idea, rather than somewhat working code
or a demonstration framework, should be the exception, rather than the
rule.=20

-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
Dave Crocker
Sent: Tuesday, January 03, 2006 1:13 PM
To: Jeffrey Hutzelman
Cc: ietf@ietf.org
Subject: Working Group chartering

[snip]

And here is where we have the major disconnect.

Working groups start from a wide variety of places.  Some start with an
idea.  Some with a detailed proposal.  Some with a detailed
specification and some with existing and deployed technology.  When a
working group starts, it must make the strategic decision about how much
prior work to preserve, versus how much new work to encourage or
require.
[snip]

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 04:30:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwFpo-0007CZ-JN; Tue, 10 Jan 2006 04:30:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwFpm-0007CR-Ce
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 04:30:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17227
	for ; Tue, 10 Jan 2006 04:29:11 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwFwP-0002m6-FE
	for ietf@ietf.org; Tue, 10 Jan 2006 04:37:24 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 62B0D26C0E3; Tue, 10 Jan 2006 10:30:03 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 6406D26C0D4; Tue, 10 Jan 2006 10:29:55 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k0A9TsYa579013;
	Tue, 10 Jan 2006 10:29:55 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id BB61116AA99; Tue, 10 Jan 2006 10:29:54 +0100 (CET)
Date: Tue, 10 Jan 2006 10:29:54 +0100
From: Stephane Bortzmeyer 
To: Stewart Bryant 
Message-ID: <20060110092954.GA1954@nic.fr>
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
	
	<43BD12AC.1010203@zurich.ibm.com> <43BD2B97.3070400@cisco.com>
	 <43C2A477.9060608@cisco.com>
	 <43C2BDA2.30908@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43C2BDA2.30908@cisco.com>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: Sam Hartman ,
	Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, Jan 09, 2006 at 07:46:42PM +0000,
 Stewart Bryant  wrote 
 a message of 73 lines which said:

> For example you could say the following in text : [long and
> complicated example deleted]

For such examples (do note that your example is an illustration of a
point and therefore does not need to be normative, like, say, a state
diagram), graph people produced several languages which are
non-ambiguous, expressed as ASCII and produce nice output. Some even
are free (as in free speech and as in free beer). (Unfortunately, none
is "standard" in any way, AFAIK.)

The one I recommend is Graphviz
(http://www.research.att.com/sw/tools/graphviz/). An example of
Graphviz code for a real network:

http://www.seekingfire.com/projects/metanetwork/maps/meta.dot

(See http://www.seekingfire.com/projects/metanetwork/info.html for the
context)

See also:

"Managing IP Networks with Free Software"
http://www.nanog.org/mtg-0210/ppt/stephen.pdf has a chapter about
Graphviz

"A Systematic Approach to BGP Configuration Checking"
http://www.nanog.org/mtg-0310/pdf/feamster.pdf uses cflow to produce
Graphviz ".dot" files.

(ACL compilers like Netspoc http://netspoc.berlios.de/ also have an
ASCII language to represent networks.)

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 04:33:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwFsh-0007Uw-F7; Tue, 10 Jan 2006 04:33:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwFse-0007Ub-Kc
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 04:33:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17431
	for ; Tue, 10 Jan 2006 04:32:09 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwFzJ-0002rL-Ey
	for ietf@ietf.org; Tue, 10 Jan 2006 04:40:22 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 2EF5F26C0E3; Tue, 10 Jan 2006 10:33:26 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id DAED526C0D4; Tue, 10 Jan 2006 10:33:24 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k0A9XOYa658291;
	Tue, 10 Jan 2006 10:33:24 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id B409416AA99; Tue, 10 Jan 2006 10:33:24 +0100 (CET)
Date: Tue, 10 Jan 2006 10:33:24 +0100
From: Stephane Bortzmeyer 
To: "Gray, Eric" 
Message-ID: <20060110093324.GB1954@nic.fr>
References: <313680C9A886D511A06000204840E1CF0C8862A8@whq-msgusr-02.pit.comms.marconi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <313680C9A886D511A06000204840E1CF0C8862A8@whq-msgusr-02.pit.comms.marconi.com>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: ietf@ietf.org, 'Stewart Bryant' 
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, Jan 09, 2006 at 05:35:51PM -0500,
 Gray, Eric  wrote 
 a message of 211 lines which said:

> The reality is that putting things entirely in pictures means that
> less validation of the intent of the picture is possible.

Automatic validation (by a program) is not possible either with
unstructured ASCII art. To do so, you would need a formal graph
language (like Graphviz I mentioned before and even Graphviz is too
low-level, too drawing-oriented to do so).

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 08:11:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwJHX-0007ET-E8; Tue, 10 Jan 2006 08:11:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwJHV-0007Aq-36
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 08:11:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29727
	for ; Tue, 10 Jan 2006 08:10:01 -0500 (EST)
Received: from dx28.winwebhosting.com ([70.85.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwJOC-00008f-46
	for ietf@ietf.org; Tue, 10 Jan 2006 08:18:17 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP)
	by dx28.winwebhosting.com with esmtpa (Exim 4.52)
	id 1EwJHP-0002ao-CE; Tue, 10 Jan 2006 07:11:15 -0600
From: "Brian Rosen" 
To: "'Theodore Ts'o'" 
Date: Tue, 10 Jan 2006 08:09:10 -0500
Message-ID: <01e401c615e7$0e014230$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20060110043706.GH12151@thunk.org>
Thread-Index: AcYVn4rXptvxMfPtSamGADB+Vb5tEgAReKaw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
Cc: 'John C Klensin' , ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: br@brianrosen.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

It's trivial for a human, but not for a computer.
Many things trivial for humans are not trivial for computers.

The kind of harvesting you are talking about is trivial for a human from any
format as long as your editor can paste while losing formatting.

What we are seeing is increasing use of fully automated tools that don't
have humans identifying which octets are MIB and which are code.  You can't
do that with plain ASCII.

Your statement that the IETF is getting populated with people who don't code
is true.  It's a fact, and we need to adapt.  Most (but not all) of the
people who design protocols these days don't code; they have people who work
with them who do.  Part of that is unavoidable.  The part I regret, which
could be avoided, is the loss of "running code" that we used to care about.
Another thread.

Brian

-----Original Message-----
From: Theodore Ts'o [mailto:tytso@mit.edu] 
Sent: Monday, January 09, 2006 11:37 PM
To: Brian Rosen
Cc: ietfdbh@comcast.net; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org
Subject: Re: Alternative formats for IDs

On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote:
> Any format can be used for any purpose, but it might be time to fully
stand
> up to requirements to harvest data, and to recognize (as I did on another
> side thread), that reading is getting harder and harder for ASCII.  It may
> be a decent archive format still, but I'm not sure it's going to stay that
> way.

Huh?  "Harvesting data" from ASCII, in terms of pulling out MIB's to
be fed into MIB compiler, or reference C code for algorithms like MD5
(RFC 1321) is *trivial* under ASCII.  Last I checked, C compilers and
MIB compilers still use ASCII text as input, and not Word documents or
XML documents.  Maybe part of what is going on is that IETF is getting
populated with people who aren't close to coding as much as before?
You can get perfectly decent text editors for all operating systems,
even Windows.

And even Word can import text (i.e., plain ASCII) documents Just Fine.

							- Ted



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 08:51:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwJtz-0000Of-BU; Tue, 10 Jan 2006 08:51:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwJtH-0008UF-Cd
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 08:51:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03522
	for ; Tue, 10 Jan 2006 08:49:02 -0500 (EST)
Received: from sccrmhc12.comcast.net ([204.127.202.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwJzx-0001bZ-7K
	for ietf@ietf.org; Tue, 10 Jan 2006 08:57:19 -0500
Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149])
	by comcast.net (sccrmhc12) with SMTP
	id <2006011013500901200jo50qe>; Tue, 10 Jan 2006 13:50:09 +0000
From: "David B Harrington" 
To: , "'Theodore Ts'o'" 
Date: Tue, 10 Jan 2006 08:50:07 -0500
Message-ID: <00fc01c615ec$c4f40770$0400a8c0@DJYXPY41>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcYVn4rXptvxMfPtSamGADB+Vb5tEgAReKawAAGXwtA=
In-Reply-To: <01e401c615e7$0e014230$640fa8c0@cis.neustar.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Content-Transfer-Encoding: 7bit
Cc: 'John C Klensin' , ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi,

> What we are seeing is increasing use of fully automated tools 
> that don't
> have humans identifying which octets are MIB and which are 
> code.  You can't
> do that with plain ASCII.

MIB modules may be a bad example for you to use. All MIB modules start
with a BEGIN character string and end with an END character string.
Plain ASCII works perfectly well for this purpose. Binary formatted
documents, such as MS-Word and PDF, require much more work from the
tools  to find those BEGIN and END statements.

David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net] 
> Sent: Tuesday, January 10, 2006 8:09 AM
> To: 'Theodore Ts'o'
> Cc: ietfdbh@comcast.net; 'John C Klensin'; 'Marshall 
> Eubanks'; ietf@ietf.org
> Subject: RE: Alternative formats for IDs
> 
> It's trivial for a human, but not for a computer.
> Many things trivial for humans are not trivial for computers.
> 
> The kind of harvesting you are talking about is trivial for a 
> human from any
> format as long as your editor can paste while losing formatting.
> 
> What we are seeing is increasing use of fully automated tools 
> that don't
> have humans identifying which octets are MIB and which are 
> code.  You can't
> do that with plain ASCII.
> 
> Your statement that the IETF is getting populated with people 
> who don't code
> is true.  It's a fact, and we need to adapt.  Most (but not 
> all) of the
> people who design protocols these days don't code; they have 
> people who work
> with them who do.  Part of that is unavoidable.  The part I 
> regret, which
> could be avoided, is the loss of "running code" that we used 
> to care about.
> Another thread.
> 
> Brian
> 
> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso@mit.edu] 
> Sent: Monday, January 09, 2006 11:37 PM
> To: Brian Rosen
> Cc: ietfdbh@comcast.net; 'John C Klensin'; 'Marshall 
> Eubanks'; ietf@ietf.org
> Subject: Re: Alternative formats for IDs
> 
> On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote:
> > Any format can be used for any purpose, but it might be 
> time to fully
> stand
> > up to requirements to harvest data, and to recognize (as I 
> did on another
> > side thread), that reading is getting harder and harder for 
> ASCII.  It may
> > be a decent archive format still, but I'm not sure it's 
> going to stay that
> > way.
> 
> Huh?  "Harvesting data" from ASCII, in terms of pulling out MIB's to
> be fed into MIB compiler, or reference C code for algorithms like
MD5
> (RFC 1321) is *trivial* under ASCII.  Last I checked, C compilers
and
> MIB compilers still use ASCII text as input, and not Word documents
or
> XML documents.  Maybe part of what is going on is that IETF is
getting
> populated with people who aren't close to coding as much as before?
> You can get perfectly decent text editors for all operating systems,
> even Windows.
> 
> And even Word can import text (i.e., plain ASCII) documents Just
Fine.
> 
> 							- Ted
> 
> 
> 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 08:58:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwK1A-0001Hx-Os; Tue, 10 Jan 2006 08:58:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwK18-0001H0-OI
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 08:58:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04145
	for ; Tue, 10 Jan 2006 08:57:10 -0500 (EST)
Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwK7o-0001sp-QQ
	for ietf@ietf.org; Tue, 10 Jan 2006 09:05:27 -0500
Received: from root (helo=think.thunk.org)
	by thunker.thunk.org with local-esmtps 
	(tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32)  (Exim 4.50 #1 (Debian))
	id 1EwK0y-00079u-AB; Tue, 10 Jan 2006 08:58:20 -0500
Received: from tytso by think.thunk.org with local (Exim 4.60)
	(envelope-from )
	id 1EwK0w-0004Tr-Pt; Tue, 10 Jan 2006 08:58:18 -0500
Date: Tue, 10 Jan 2006 08:58:18 -0500
From: "Theodore Ts'o" 
To: Brian Rosen 
Message-ID: <20060110135818.GA17183@thunk.org>
References: <20060110043706.GH12151@thunk.org>
	<01e401c615e7$0e014230$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01e401c615e7$0e014230$640fa8c0@cis.neustar.com>
User-Agent: Mutt/1.5.11
X-SA-Exim-Connect-IP: 
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 'John C Klensin' , ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Tue, Jan 10, 2006 at 08:09:10AM -0500, Brian Rosen wrote:
> It's trivial for a human, but not for a computer.
> Many things trivial for humans are not trivial for computers.
> 
> The kind of harvesting you are talking about is trivial for a human from any
> format as long as your editor can paste while losing formatting.
> 
> What we are seeing is increasing use of fully automated tools that don't
> have humans identifying which octets are MIB and which are code.  You can't
> do that with plain ASCII.

True.  So what?  Do you think that it is possible, or even a good
idea, that tools be able to rip out a MIB without reading the rest of
the text?  If so, why the heck do we spend so much time working on a
the human-readable sections, like Security Considerations?

And how much time does it really save to have an automated tool pull
out the MIB, instead of having a human do it?  And what percentage of
the effort does that represent out of the effort to create a product,
anyway?  0.0001%   0.00001%?   

I can usually do it in under a minute with some emacs macros, but I'm
willing to admit that I may be a bit better at it than others.  Other
people could probably do it in a few minutes using sed and awk, or
even (gasp) perl.

						- Ted

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 08:58:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwK1U-0001Op-6A; Tue, 10 Jan 2006 08:58:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwK1S-0001OZ-A6
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 08:58:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04177
	for ; Tue, 10 Jan 2006 08:57:30 -0500 (EST)
Received: from mtagate2.de.ibm.com ([195.212.29.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwK89-0001tF-Ft
	for ietf@ietf.org; Tue, 10 Jan 2006 09:05:47 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0ADwMI5244600
	for ; Tue, 10 Jan 2006 13:58:27 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com
	[9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0ADw663180316
	for ; Tue, 10 Jan 2006 14:58:06 +0100
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0ADw5Ol003459 for ; Tue, 10 Jan 2006 14:58:05 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0ADw4XU003441; Tue, 10 Jan 2006 14:58:04 +0100
Received: from zurich.ibm.com (sig-9-145-252-37.de.ibm.com [9.145.252.37])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA80844;
	Tue, 10 Jan 2006 14:58:02 +0100
Message-ID: <43C3BD69.3070009@zurich.ibm.com>
Date: Tue, 10 Jan 2006 14:58:01 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Bob Braden 
References: <200601091851.KAA09906@gra.isi.edu>
In-Reply-To: <200601091851.KAA09906@gra.isi.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: harald@alvestrand.no, hartmans-ietf@mit.edu, ietf@ietf.org, sbrim@cisco.com,
	stbryant@cisco.com
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bob Braden wrote:
>   *> 
>   *> Normative figures perhaps.  Normative equations definitely.
> 
> Scott,
> 
> How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
> of readable equations in ASCII?  I my experience, normative protocol
> technical specifications rarely need equations much more complex than
> these examples.  The only significant exception I can think of is the
> NTP spec.

RFC 3247 is quite tricky too.

> 
> People who REALLY use equations generally prefer LaTeX.
> 

Yes, and if the equations are informative that's fine; they can publish
where they want to. But we have a genuine issue when equations
are both normative and complicated.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 09:11:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwKDc-0005V9-KG; Tue, 10 Jan 2006 09:11:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKDa-0005V4-EL
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 09:11:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05380
	for ; Tue, 10 Jan 2006 09:10:02 -0500 (EST)
Received: from mtagate1.uk.ibm.com ([195.212.29.134])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwKKH-0002NS-R7
	for ietf@ietf.org; Tue, 10 Jan 2006 09:18:19 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0AE6YtO190392
	for ; Tue, 10 Jan 2006 14:11:10 GMT
Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com
	[9.149.165.212])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0ADr163203654
	for ; Tue, 10 Jan 2006 14:53:01 +0100
Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0ADr1Fi022688 for ; Tue, 10 Jan 2006 14:53:01 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0ADr0hp022679; Tue, 10 Jan 2006 14:53:01 +0100
Received: from zurich.ibm.com (sig-9-145-252-37.de.ibm.com [9.145.252.37])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA44328;
	Tue, 10 Jan 2006 14:52:59 +0100
Message-ID: <43C3BC3B.1030304@zurich.ibm.com>
Date: Tue, 10 Jan 2006 14:52:59 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: br@brianrosen.net
References: <01e401c615e7$0e014230$640fa8c0@cis.neustar.com>
In-Reply-To: <01e401c615e7$0e014230$640fa8c0@cis.neustar.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

...
> What we are seeing is increasing use of fully automated tools that don't
> have humans identifying which octets are MIB and which are code.  You can't
> do that with plain ASCII.

You can do that with meta-data encoded in plain ASCII. In fact, that
would work better for automated extraction than anything visual such as
using multiple fonts.

...

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 09:47:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwKmZ-0005xn-LD; Tue, 10 Jan 2006 09:47:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKmY-0005ww-5A
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 09:47:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07385
	for ; Tue, 10 Jan 2006 09:46:09 -0500 (EST)
Received: from dx28.winwebhosting.com ([70.85.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwKtH-0003Mc-0n
	for ietf@ietf.org; Tue, 10 Jan 2006 09:54:27 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP)
	by dx28.winwebhosting.com with esmtpa (Exim 4.52)
	id 1EwKmd-0000Fj-7v; Tue, 10 Jan 2006 08:47:36 -0600
From: "Brian Rosen" 
To: "'Theodore Ts'o'" 
Date: Tue, 10 Jan 2006 09:45:41 -0500
Message-ID: <01f601c615f4$89f77fa0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20060110135818.GA17183@thunk.org>
Thread-Index: AcYV7fIc79NnzMkGQTqDTQbAXi44ngAA7AHQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc: 'John C Klensin' , ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: br@brianrosen.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ted

You are arguing that we have been producing documents for a long time with
only primitive tools and we don't need to make any new tools.  You are
losing that argument.   We are increasing the number, and usefulness of
tools, and most of us appreciate these tools and want more of them.  The
range of useful tools we can produce is related to how much meta-data we put
in the source files.  The more meta-data we put in, the more usefulness we
can get out of the data.  There is very little downside to adding meta-data
as long as it's easy to put in.  For most of these things, we have to do
special formatting, so we are already marking the octets in some way.  

Do you have any idea how painful it is to build any kind of product that has
good management simply because there is no library of MIBs, with references
to documents?  There isn't even a LIST of IETF MIBs.  You can't figure out
if a document has a MIB unless you actually look at the text (although many
have a big hint in the title of the document).  So yes, I believe better MIB
tools would lead to better products, although it would be hard to prove it.

I would like to enable automated testing of ABNF.  I'd like to be able to
cross check the ABNF from one document against its normative references to
see what changes or conflicts.  I'd like to be able to generate a complete
list of SIP error messages a UA may be expected to encounter.  I'd like to
see a lot more hyperlinking of things.  All of these are much easier with
meta-data.

Brian


-----Original Message-----
From: Theodore Ts'o [mailto:tytso@mit.edu] 
Sent: Tuesday, January 10, 2006 8:58 AM
To: Brian Rosen
Cc: ietfdbh@comcast.net; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org
Subject: Re: Alternative formats for IDs

On Tue, Jan 10, 2006 at 08:09:10AM -0500, Brian Rosen wrote:
> It's trivial for a human, but not for a computer.
> Many things trivial for humans are not trivial for computers.
> 
> The kind of harvesting you are talking about is trivial for a human from
any
> format as long as your editor can paste while losing formatting.
> 
> What we are seeing is increasing use of fully automated tools that don't
> have humans identifying which octets are MIB and which are code.  You
can't
> do that with plain ASCII.

True.  So what?  Do you think that it is possible, or even a good
idea, that tools be able to rip out a MIB without reading the rest of
the text?  If so, why the heck do we spend so much time working on a
the human-readable sections, like Security Considerations?

And how much time does it really save to have an automated tool pull
out the MIB, instead of having a human do it?  And what percentage of
the effort does that represent out of the effort to create a product,
anyway?  0.0001%   0.00001%?   

I can usually do it in under a minute with some emacs macros, but I'm
willing to admit that I may be a bit better at it than others.  Other
people could probably do it in a few minutes using sed and awk, or
even (gasp) perl.

						- Ted



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 09:47:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwKma-0005zS-O7; Tue, 10 Jan 2006 09:47:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwKmZ-0005xY-Bw
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 09:47:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07388
	for ; Tue, 10 Jan 2006 09:46:10 -0500 (EST)
Received: from dx28.winwebhosting.com ([70.85.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwKtH-0003Mc-JL
	for ietf@ietf.org; Tue, 10 Jan 2006 09:54:27 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP)
	by dx28.winwebhosting.com with esmtpa (Exim 4.52)
	id 1EwK2Q-0005OU-6t; Tue, 10 Jan 2006 07:59:50 -0600
From: "Brian Rosen" 
To: "'Brian E Carpenter'" 
Date: Tue, 10 Jan 2006 08:57:24 -0500
Message-ID: <01ee01c615ed$cb3db850$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <43C3BC3B.1030304@zurich.ibm.com>
Thread-Index: AcYV7ZeCOtBEcf3cTnCtO2uFfsLdagAAAQIA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: br@brianrosen.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


You mean, like xml?


-----Original Message-----
From: Brian E Carpenter [mailto:brc@zurich.ibm.com] 
Sent: Tuesday, January 10, 2006 8:53 AM
To: br@brianrosen.net
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs

...
> What we are seeing is increasing use of fully automated tools that don't
> have humans identifying which octets are MIB and which are code.  You
can't
> do that with plain ASCII.

You can do that with meta-data encoded in plain ASCII. In fact, that
would work better for automated extraction than anything visual such as
using multiple fonts.

...

     Brian




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 10:30:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwLRm-0008PZ-D4; Tue, 10 Jan 2006 10:30:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwLRk-0008PT-8b
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 10:30:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10296
	for ; Tue, 10 Jan 2006 10:28:45 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwLYQ-0004cu-CF
	for ietf@ietf.org; Tue, 10 Jan 2006 10:37:01 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 77E9226C0E3; Tue, 10 Jan 2006 16:29:54 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 66FD026C0E0; Tue, 10 Jan 2006 16:29:48 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k0AFTmYa862359;
	Tue, 10 Jan 2006 16:29:48 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id 401F416AA99; Tue, 10 Jan 2006 16:29:48 +0100 (CET)
Date: Tue, 10 Jan 2006 16:29:48 +0100
From: Stephane Bortzmeyer 
To: Stewart Bryant 
Message-ID: <20060110152948.GA8175@nic.fr>
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
	
	<43BD12AC.1010203@zurich.ibm.com> <43BD2B97.3070400@cisco.com>
	 <43C2A477.9060608@cisco.com>
	 <43C2BDA2.30908@cisco.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5"
Content-Disposition: inline
In-Reply-To: <43C2BDA2.30908@cisco.com>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Cc: ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--bg08WKrSYDhXBjb5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Jan 09, 2006 at 07:46:42PM +0000,
 Stewart Bryant  wrote 
 a message of 73 lines which said:

> For example you could say the following in text : router A connects
> to router B and D, the cost from A to B is 2, and the cost from A to
> D is 4.  Router B connects to router C. The cost to router A is 6,
> and the cost to router C is 10. Router C connects to router D. The
> cost to router B is 9 and the cost to router D is 8. The cost from
> router D to router A is 16 and the cost to router A is 99.

Here is the Graphviz code, to compare (I also attached the
automatically produced PNG but Graphviz can make PDF or SVG as well):

// See http://www1.ietf.org/mail-archive/web/ietf/current/msg39858.html

digraph bryantnetwork {
  
  label = "Stewart Bryant's network";
	 
 // Routers
 node [shape=box, fontsize=15];

 // Links
 edge [len=2.0];
    A -> B [label="2"];
    A -> D [label="4"];
    B -> A [label="6"];
    B -> C [label="10"];
    C -> B [label="9"];
    C -> D [label="8"];
    D -> A [label="16"];
    D -> C [label="99"];
    
}

--bg08WKrSYDhXBjb5
Content-Type: image/png
Content-Disposition: attachment; filename="bryant.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAOIAAAG/BAMAAAC3WRZ5AAAAJ1BMVEX+//+Li4tvb283Nzff
399fX1+/v79/f38/Pz8fHx+fn58AAAD////MI07OAAAAAXRSTlMAQObYZgAACeBJREFUeJzt
3cF2m7gaAOB5pnmG5tYZs4yn6bWXTacZs2zT25rNPafpJLGXaWvX3namGbO6x47jwBIbDP9D
XQljI5Ag4EjqhIhFiwDps4QgBvmHn0D29JMSlahEPqJVYLK5ineUVmQbJSpRiUpUohKrLx5J
F7uaZNGxDMniYjySLNYWt5LF985csjiCri5V9A1o96SKHvpCPJEqvgJwp1LFC3xEahLFJU52
WxLF45kG/nAmUdxpGyUqUYlKVKISlfgAxR96fzWwt0uCIlXfTQyIWUuGSJZsWRCLliiRbNOk
WKKSZUSiTXEXkiAmq5gQSzRrCTHRbbYHQSQWr2QJMdFtZIipKqbE4s26k8ioY/FKFhcTRW4r
FX4OMWKQTFFi4WYtLNqpVErk33OSVYz9tWinVvMXA2qOfx2TJcoX41SQ+p+bmNWoVRKzGvUH
isW7TjExs1ErJGYdjcLErFNctUX/D02oaMO7uUn6zpmW/jCcxcWzbjyugZD9HpEQIv4Gfjyu
YZOjVWLEAAyA+FuFDcspsS49w0dE04BILabdr8JFZ0akVrfOUBctutsxOLTDgtF2KEeMiDvF
vpYUN5eS4sQDsuTVCFaiRVcnS17YGBUn4rJOAPQtD/41BC2xovvH2zdGLMIZXGlixTG6rtCI
gvdOD+KV/MXE+StdsHgxffqsoEiVW0GR+iv4qMTCXwLKiXRFlHh/kS61ciLjCKiEaBH33BiF
VkIk7mSyTmSVEanShYqQuxuJZQ9bzNmNFREDcpxBkphXpEiR/UVGhAh5u5GLWG5wmodYJKcS
lahEJSpRiUqUKy47N2efdJkiviFeoyJjRIt0ZIxoEYayRfl1fHUtV7SsuS5XtJ0ryXVE+/FG
tii/r4L0vkpH4wk9rzbnZ31dpsielKhEJSpRiUpUomhR/v1VqoDccXchYu7v7/mJRMVyf4Ev
QswPwuEnErtRjsgI5ZIn5oducBOJ7I9AvCPOiJfIDuaSJN4RQ8lLTO5GCWLy3J1b1IMV7ZxU
RcScwIMcsegP5v4Zop2bVOJOYjqrEnmIaUGSuNxBDPN8f72b6A9wvNGzddppHJrZ4ngj4jxQ
+3AHmCW+nANcaZ4RplcGfMoUne0vzXAep38XmNmqcxy14ofP47I7Goz1LHGxuaUd4FvNHvUE
rxKifw1OGAFkdwHqrSzxJCG2s7YrIi7Qxw0HAeyhBkEvI//ESIjNQyIUrKzo2dEggN00cZwM
e5pCQhya+9TgSGFxO+xgtz87nV5G/uukOIclNThSWIzruOxOxwY7+9JOi/kXuLlivB+B+ZDF
cPImT4ZPCHHAGI4pLOK+OovSS+ohctFUj39Pu+45RPBZaTE+HslYQHrjRKui4zbrw+WIwVqE
K/Ba60KXmaectOj1/MvdxCPrT/CfRefVXxp6VvYg3m8BzuMcNrTdRHKynezsAXP23mJOdiXu
KOaWxEdMVUqJfMQgJ/W4RX7XyDLEZObKisSXFSli4mlRUkRLtmjJFgPpovw6pm5Uy+o5Ba/v
OR4dkkV4DGIgXQTmuK1QMZAnlhu35iEWyadEJSpRiUpUohJli0f9s7emTHHxFZyuVLGpA3jp
cQCRYjiMtJQpuuEAjS5R9JjFiBRX0kX2cKJIccEcaBMpskePhB6P+F1SjilT9Gaa812TKcL3
Qd9M56na3w4lKlGIyJ5VohKVSM4WHQxUohSx5P1VDmJq2paT8VsmkSK7uQWKGa8FEirecQki
QGSSYkVWu/IX4xLZQReCRUYlRYt0JUWLdCWr1arsd1iJFVl/V4SKzL9kIkV2oZUTGc1aPZEu
tXoi3ax29qqHKlJNp0QOYk5aiaVE/5SIREI7MoxM2mtciBM7mh+/5x2JYWTSF1i1xIhBGD1B
PM/KBhyZ9NsEB2OIEi3NIe7P29AFqB/amzglEWLn0rskF+DIpHMyvoW76FoXiQU4MunTbdTU
/MWw69xo5AIcmfRxrj9N1rHwH6sC4uKgOyIXhJFJr6x/b2J4+ItNzZsRC3DRODLJ28Tw8Bfn
yScTBtHYUjt5PPITA3w8JsLE7DAyKQo7FCJ2TD/xfDk7jEw6bokT0XlVJ5fUGzo4334FcSJz
iQbCxNxvxcR84RPAP1HMaNZKifnNKkTMu9j4gWLxg6OASH98xoDcQxep0uSLjO8afMUiV43F
u2ohMadZBYlUeRsxvh/JW8y6bNyKJXbj/cTtM5K4i1nNuhVLNGpxMVEN8WJgp4aR7K1IfACe
IgQBSwSRYuouuXwx2Iild2NRMT3ase06osSAGu3YdB2C5ypa0kVIjx9HikCReuhbpJTfjYXF
aFeWGki/p5gMbcueeIpk2JcksdAOU6ISlahEJSoxu7Tv1tn5r1JFfHe505Isgp/zihYxIh79
kCzWe7JF6ruPcJGKHRIvjvK34S/K348dU7KY98okMeJY6jnnSP55dbdtlKhEJSpRiUpU4oMT
Zd9f5TQpUYmPR/S1OzZIPWGEEK/6b/XsbPhd0Myy6wZraTw5neRJIRb9Wxib1PNHQg3/g98F
zXiyhQ6BSS1KTqss0bPBNZz0RTae9qN8jEfIo+09nVpUUFyhGhg1xmnR6W7yUW+7BbT9QqMW
FRQXc/RhO9OW//zj0jI7X+G5tvfmg/Ou9j+rsc63nKLUpD2DWgutWb7bm+toewdqDVRmmIRv
fbyofevOzcWl2zjVnl529+3lVGeJTneq4XLfQ1drat4I/oYB9H3r/edh9EmPL3HKvQYPr3Gs
1+Ne+PkHcICy46RrehP8It4JnINvnsL+5Xh2dWy7JrOO4Fqf8fuXbRgbbdOdQAtOYYh/drwW
LWuu4RS69D9ar0Fbh6KlvQAIk3XwZ7gxbqGjLfwJapXVBC1OXEmTx2PN0le2j/7GtVa9xcxB
l/i/4HIj0XbG69cRNLWTaE0kNsPffuLk2LKmeFEfmsYefhTOHKVWUyNLhCZqJRd3NXey99zV
wT0gRdxX8Wy91YvWRKJnfYjEd1FH6TxpjE7ClyqE4oQt/olvsiERr3ZmJ+1XKCMkRLDC2cW1
Ea2JRLi6icSOtt6w/vbldc9DnX+AxcmALe7jW16oVafoIIHz3uoLPhoSojMPZ5dof85JsRW+
NSRs1Ra4eJHXh4Hhz9Anx6LdbjHFoIXOOd71i+HFf3Q0h+s6/H34Ahndl9rm/fMhfrZZs7LR
9gAT6Efi6uavj3iRj7sO6vNuLxTdW6bofTu8gOXA2MN7ZQVOD2D8ufOzdQLHX/B5dX7e15+i
FKDjB6/5r2WMZ2h71BRvUA4fJ53mjRYuGkEN9YbTZ05n9qIz+5f1miUmJif+GS493flyF5w5
8yUDO/y18qk7Y6Wm8uLY0iSL+9S7xEWL952UqEQlKlGJfKf/A41C/jaah3NNAAAAAElFTkSu
QmCC

--bg08WKrSYDhXBjb5
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--bg08WKrSYDhXBjb5--




From ietf-bounces@ietf.org Tue Jan 10 10:54:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwLpH-0006n9-5P; Tue, 10 Jan 2006 10:54:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwLpE-0006mu-HG
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 10:54:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12977
	for ; Tue, 10 Jan 2006 10:53:01 -0500 (EST)
Received: from bulk.resource.org ([192.101.98.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwLvt-0005li-HV
	for ietf@ietf.org; Tue, 10 Jan 2006 11:01:14 -0500
Received: from bulk.resource.org (localhost.resource.org [127.0.0.1])
	by bulk.resource.org (8.12.2/8.12.2) with ESMTP id k0AFrwAq023969
	for ; Tue, 10 Jan 2006 07:53:58 -0800 (PST)
Received: (from carl@localhost)
	by bulk.resource.org (8.12.2/8.12.2/Submit) id k0AFrwr7023968
	for ietf@ietf.org; Tue, 10 Jan 2006 07:53:58 -0800 (PST)
From: Carl Malamud 
Message-Id: <200601101553.k0AFrwr7023968@bulk.resource.org>
To: ietf@ietf.org
Date: Tue, 10 Jan 2006 07:53:58 -0800 (PST)
Organization: Memory Palace Press
X-Winch: Warn 9.5i
X-Mailer: ELM [version 2.4ME+ PL94 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Subject: informal survey
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi -

I'm conducting an informal, non-scientific survey with the aim of trying
to understand within an order of magnitude how much it costs folks to
contribute to open source software.

If any of you have 30 seconds and feel like answering 3 questions, please
mail your responses back to me.  Please do NOT send your responses to
the entire list.

Questions:

1. What country do you live in?

2. Did you contribute time to any open source development efforts in
   2005? (*)

3. If the answer to 2 is yes, how much would you estimate your
   out-of-pocket costs were in 2005? (**)

 * Where "contribute" and "open source" are defined any way you 
   feel is appropriate.  
** Out-of-pocket costs are direct personal expenditures not
   reiumbursed by your employer.  Your time is worth nothing
   for purposes of this calculation.  Examples of costs might 
   be web hosting, computers, or directly related travel.

Thanks!

Carl

P.S. Privacy policy: I will not put your name on a mailing list
or in any other way release your name or email address.  Any 
results released will be aggregated over the entire survey
population.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 10:56:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwLrS-0007GO-Ca; Tue, 10 Jan 2006 10:56:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwLrQ-0007G6-83
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 10:56:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13295
	for ; Tue, 10 Jan 2006 10:55:16 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwLy6-0005vp-Jk
	for ietf@ietf.org; Tue, 10 Jan 2006 11:03:33 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0AFuMSD028205; Tue, 10 Jan 2006 10:56:22 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29848; 
	Tue, 10 Jan 2006 10:56:21 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Tue, 10 Jan 2006 10:56:20 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C8862B3@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Theodore Ts'o'" 
Date: Tue, 10 Jan 2006 10:56:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: 'Sam Hartman' ,
	IETF General Discussion Mailing List ,
	Sandy Wills 
Subject: RE: Binary Choices?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ted,

	I think we disagree on fine points and agree on the bigger
points.

	As Melinda Shore aptly put it ('objection to proposed change 
to "consensus"' on Saturday, 1/7/2006, at 10:15 AM Eastern Time):

'Consensus process leads to decisions being made through synthesis 
 and restatement, and by the time that the question is asked "Do we 
 have consensus?" we should pretty much have consensus already.' 

While the point at which a question can be asked that is likely to
engender consensus is not always going to be quite this binary, it
is often the case that people will not try to 'call' for consensus
until there are no more than three choices - and usually it will be
when there are no more than two.

--
Eric

--> -----Original Message-----
--> From: Theodore Ts'o [mailto:tytso@mit.edu] 
--> Sent: Monday, January 09, 2006 10:43 PM
--> To: Gray, Eric
--> Cc: 'Sam Hartman'; Sandy Wills; IETF General Discussion Mailing List
--> Subject: Re: Binary Choices?
--> 
--> On Mon, Jan 09, 2006 at 12:57:56PM -0500, Gray, Eric wrote:
--> > 
--> > Usually, before you can actually seek consensus, you must have an
--> > essentially "binary" choice.  It is hard enough to reach consensus
--> > on simple choices without turning up the process noise by having a
--> > plethora of possible choices.
--> > 
--> 
--> I disagree here.  The process of seeking consensus means you have to
--> sort *through* the plethora of possible choices, and see which ones
--> meets the needs and requirements of the stakeholder.  If you have a
--> binary choice, all you can really do is force a vote.  So 
--> hopefully by
--> the time that you come up to your last two choices, they hopefully
--> aren't "binary" in the sense of 0 and 1 being diametric opposites.
--> Hopefully the two or three final choices are pretty closely 
--> except for
--> a few minor details (and then we end up spending huge amount of time
--> arguing over those tiny details :-)
--> 
--> 						- Ted
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 11:02:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwLx4-0000r9-7T; Tue, 10 Jan 2006 11:02:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwLx1-0000qs-CX
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 11:02:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14520
	for ; Tue, 10 Jan 2006 11:01:04 -0500 (EST)
Received: from omr6.networksolutionsemail.com ([205.178.146.56]
	helo=mail.networksolutionsemail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwM3h-0006P2-Ro
	for ietf@ietf.org; Tue, 10 Jan 2006 11:09:21 -0500
Received: (qmail 1282 invoked from network); 10 Jan 2006 16:02:02 -0000
Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237)
	by omr6.mgt.bos.netsol.com with SMTP; 10 Jan 2006 16:02:02 -0000
Message-ID: <43C3DAF3.3030509@andybierman.com>
Date: Tue, 10 Jan 2006 08:04:03 -0800
From: Andy Bierman 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Burger, Eric" 
References: <330A23D8336C0346B5C1A5BB1966664701F542C3@ATLANTIS.Brooktrout.com>
In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701F542C3@ATLANTIS.Brooktrout.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit
Cc: Dave Crocker , ietf@ietf.org
Subject: Re: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Burger, Eric wrote:

>IMHO, *way* too many I*E*TF work groups get chartered based on an idea.
>We then spend tons of resources on figuring out if the idea will work.
>We produce lots of half-baked documents with little basis in working
>code.  Then folks try implementing what's been spec'ed, find it doesn't
>work, but then find a ton of resistance to change, because the specs are
>three years old and "we don't want to break draft-mumble-05
>implementations."
>  
>

I completely agree with you.
I wonder if we are in the minority opinion?
Standardize stuff that already works -- what a concept.

When we see a proposal without any "running code"
to back it up, we should be asking:
"If this is so good, then why aren't you using it yourself?"

>If something is an idea, let's make it politically acceptable for the
>"work" to be done in the I*R*TF first.
>
>  
>

I don't care how the technology gets developed.
IRTF, vendors, universities, whatever.  Show us
running code that's reasonably close to what you
want to standardize.  Let's get feedback from people who
have used the technology, too.


>Yes, I agree that the process should be fuzzy - the AD should be able to
>figure out if something is likely to work in the real world.  However,
>building a work group out of an idea, rather than somewhat working code
>or a demonstration framework, should be the exception, rather than the
>rule. 
>  
>

Agreed, but I'm no fan of more process rules.
Area Directors who want to produce successful standards
will know how to make this decision.  ADs have to be tough
enough to say "Come back when you've done more work."


Andy

>-----Original Message-----
>From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
>Dave Crocker
>Sent: Tuesday, January 03, 2006 1:13 PM
>To: Jeffrey Hutzelman
>Cc: ietf@ietf.org
>Subject: Working Group chartering
>
>[snip]
>
>And here is where we have the major disconnect.
>
>Working groups start from a wide variety of places.  Some start with an
>idea.  Some with a detailed proposal.  Some with a detailed
>specification and some with existing and deployed technology.  When a
>working group starts, it must make the strategic decision about how much
>prior work to preserve, versus how much new work to encourage or
>require.
>[snip]
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>
>
>  
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 11:11:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwM5N-00065w-Gk; Tue, 10 Jan 2006 11:11:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwM5M-000659-1P
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 11:11:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17148
	for ; Tue, 10 Jan 2006 11:09:40 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMC1-0007OV-LH
	for ietf@ietf.org; Tue, 10 Jan 2006 11:17:57 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0AGBLjv018833
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2006 08:11:21 -0800
Message-ID: <43C3DC80.7040809@bbiw.net>
Date: Tue, 10 Jan 2006 08:10:40 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Andy Bierman 
References: <330A23D8336C0346B5C1A5BB1966664701F542C3@ATLANTIS.Brooktrout.com>
	<43C3DAF3.3030509@andybierman.com>
In-Reply-To: <43C3DAF3.3030509@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dcrocker@bbiw.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



>> IMHO, *way* too many I*E*TF work groups get chartered based on an idea.
...
> Standardize stuff that already works -- what a concept.
> 
...
> I don't care how the technology gets developed.
> IRTF, vendors, universities, whatever.  


The current model in the IETF appears to be:  Your running code does suggest 
that this is worth pursuing.  So, now let's start all over, with no real concern 
for preserving that work and develop a fresh wish-list of features.

My suggestion is that we stop doing that, instead using the core of workers who 
are committed to delivering that running code, to define the requirements.  The 
community then gets to review potential problems with that work. 
Pseudo-problems, such as "it should do more things" and "I can't give you any 
specifics, but there might be problems" are out of bounds.

d/
-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 11:17:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwMC7-0003s6-AU; Tue, 10 Jan 2006 11:17:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMC4-0003rl-8j
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 11:17:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17914
	for ; Tue, 10 Jan 2006 11:16:37 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMIl-0007k1-EZ
	for ietf@ietf.org; Tue, 10 Jan 2006 11:24:54 -0500
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k0AGHiDo052690
	for ; Tue, 10 Jan 2006 08:17:45 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <01f601c615f4$89f77fa0$640fa8c0@cis.neustar.com>
References: <01f601c615f4$89f77fa0$640fa8c0@cis.neustar.com>
Date: Tue, 10 Jan 2006 08:15:02 -0800
To: ietf@ietf.org
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 9:45 AM -0500 1/10/06, Brian Rosen wrote:
>Do you have any idea how painful it is to build any kind of product that has
>good management simply because there is no library of MIBs, with references
>to documents?  There isn't even a LIST of IETF MIBs.  You can't figure out
>if a document has a MIB unless you actually look at the text (although many
>have a big hint in the title of the document).  So yes, I believe better MIB
>tools would lead to better products, although it would be hard to prove it.

Why does this need to be done in the RFCs or Internet Drafts 
themselves? Why, for example, can't a human with a bit of training 
extract all the MIBs from the current RFCs and put them into a 
repository that is machine-accessible? Doing so would probably take 
less time than writing the tool to make human-readable RFCs also 
machine-readable.

As for Internet Drafts (if we really want people implementing from 
Internet Drafts), it is trivial to create a convention that says "if 
you want the MIB in your draft to be machine-readable, copy the MIB 
to a public web server and, in the draft, put on a line by itself: 
THE-MIB-IS-AT ". No changes are needed to any input or output 
tools, yet the problem of finding MIBs is solved.

>I would like to enable automated testing of ABNF.  I'd like to be able to
>cross check the ABNF from one document against its normative references to
>see what changes or conflicts.  I'd like to be able to generate a complete
>list of SIP error messages a UA may be expected to encounter.  I'd like to
>see a lot more hyperlinking of things.  All of these are much easier with
>meta-data.

Sure. If any of those features came free or very cheap, that would be 
great. None of them do, particularly when you factor in the 
design-by-entire-IETF-mailing-list work factor. Instead, a bit of 
human interaction is much less expensive.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 11:26:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwMJw-0005Af-BT; Tue, 10 Jan 2006 11:26:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMJt-0005AT-RE
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 11:26:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18475
	for ; Tue, 10 Jan 2006 11:24:42 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMQb-00080N-Tl
	for ietf@ietf.org; Tue, 10 Jan 2006 11:32:59 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0AGQNSS020869
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2006 08:26:24 -0800
Message-ID: <43C3E006.6050803@dcrocker.net>
Date: Tue, 10 Jan 2006 08:25:42 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Andy Bierman 
References: <330A23D8336C0346B5C1A5BB1966664701F542C3@ATLANTIS.Brooktrout.com>
	<43C3DAF3.3030509@andybierman.com>
In-Reply-To: <43C3DAF3.3030509@andybierman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



>> IMHO, *way* too many I*E*TF work groups get chartered based on an idea.
...
> Standardize stuff that already works -- what a concept.
> 
...
> I don't care how the technology gets developed.
> IRTF, vendors, universities, whatever.  


The current model in the IETF appears to be:  Your running code does suggest
that this is worth pursuing.  So, now let's start all over, with no real concern
for preserving that work and develop a fresh wish-list of features.

My suggestion is that we stop doing that, instead using the core of workers who
are committed to delivering that running code, to define the requirements.  The
community then gets to review potential problems with that work.
Pseudo-problems, such as "it should do more things" and "I can't give you any
specifics, but there might be problems" are out of bounds.

d/
-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 11:31:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwMPd-0007Z9-50; Tue, 10 Jan 2006 11:31:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMPb-0007YN-BW
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 11:31:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19092
	for ; Tue, 10 Jan 2006 11:30:36 -0500 (EST)
Received: from xenotime.net ([66.160.160.81])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwMWJ-0008Ft-Bk
	for ietf@ietf.org; Tue, 10 Jan 2006 11:38:53 -0500
Received: from shark.he.net ([66.160.160.2]) by xenotime.net for
	; Tue, 10 Jan 2006 08:31:48 -0800
Date: Tue, 10 Jan 2006 08:31:48 -0800 (PST)
From: "Randy.Dunlap" 
X-X-Sender: rddunlap@shark.he.net
To: Brian E Carpenter 
In-Reply-To: <43C3BC3B.1030304@zurich.ibm.com>
Message-ID: 
References: <01e401c615e7$0e014230$640fa8c0@cis.neustar.com>
	<43C3BC3B.1030304@zurich.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Tue, 10 Jan 2006, Brian E Carpenter wrote:

> ...
> > What we are seeing is increasing use of fully automated tools that don't
> > have humans identifying which octets are MIB and which are code.  You can't
> > do that with plain ASCII.
>
> You can do that with meta-data encoded in plain ASCII. In fact, that
> would work better for automated extraction than anything visual such as
> using multiple fonts.
>
> ...

Does the RFC editor accept HTML in plain ASCII RFCs?

-- 
~Randy

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 11:39:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwMWo-0002F6-3Q; Tue, 10 Jan 2006 11:39:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMWm-0002F1-3B
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 11:39:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19585
	for ; Tue, 10 Jan 2006 11:38:00 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMdU-0008U4-JM
	for ietf@ietf.org; Tue, 10 Jan 2006 11:46:17 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0AGd8SD029472; Tue, 10 Jan 2006 11:39:08 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06190; 
	Tue, 10 Jan 2006 11:39:07 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Tue, 10 Jan 2006 11:39:07 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C8862B7@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Stewart Bryant'" 
Date: Tue, 10 Jan 2006 11:38:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: ietf@ietf.org
Subject: RE: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart,

	Yes, you are correct.  But, if you had correctly understood
the comment you quote below, you would realize that we're clearly
in agreement already - at least on that aspect of the discussion.

	:-)

	My point is that we make inclusion of elaborate figures more
difficult because elaborate figures don't necessarily make for a
better understanding - any more than complicated equations do.  If
people generally agree that complicated diagrams, tables, figures
or equations is necessary to understanding a specification - then
it is quite possible to do so.

	The fact that this makes it (at least slightly) harder to
write a specification if it must include complex art, does not 
impact on the difficulty in reading the resulting specification.
However, as pointed out several times, making it trivially easy
to include complex art MAY make reading specifications that do
not require it much harder.

	Since the vast majority of documents produced by the IETF
do not appear to require complex art, our process is optimized
for the normal case - just as it should be...

--
Eric

--> -----Original Message-----
--> From: Stewart Bryant [mailto:stbryant@cisco.com] 
--> Sent: Monday, January 09, 2006 11:40 PM
--> To: Gray, Eric
--> Cc: ietf@ietf.org
--> Subject: Re: Normative figures
--> 
--> 
--> >We write specifications so that they are easier to read, validate 
--> >and understand, not so that they are easier to write.
--> >
--> >  
--> >
--> 
--> Eric
--> 
--> We write specs so that they will be correctly implemented.
--> Anything that makes a specification easier to correctly understand
--> surely makes it more likely that it will be correctly implemented?
--> 
--> The cost of incorrect implementation is so high that we can
--> can afford to pay a relatively high cost in the effort and
--> technology needed to read and write the specification.
--> 
--> - Stewart
--> 
--> 
--> 
--> 
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 11:53:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwMkp-0007ba-3m; Tue, 10 Jan 2006 11:53:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMkn-0007bV-C2
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 11:53:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20717
	for ; Tue, 10 Jan 2006 11:52:29 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwMrX-0000WW-2e
	for ietf@ietf.org; Tue, 10 Jan 2006 12:00:47 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0AGrcSD029825; Tue, 10 Jan 2006 11:53:38 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08174; 
	Tue, 10 Jan 2006 11:53:38 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Tue, 10 Jan 2006 11:53:37 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C8862B8@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Stewart Bryant'" 
Date: Tue, 10 Jan 2006 11:53:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: ietf@ietf.org
Subject: RE: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart,

	You address this to me - though I do not make these rules.

	However, I will do my best to answer your question.  In the
case you pose below, "almost incomprehensible" is the key phrase.
Had you not qualified "incomprehensible", the answer would be no,
at least IMO.

	Moreover, I believe there is evidence to this effect, as
pointed out previously, in the fact that at least one RFC is 
essentially only available in PS and PDF format.

	However, as long as a text version is comprehensible, it
should be the normative version - simply because, however hard
it might be to overcome the difficulty in comprehending it for
the average reader, it is not sufficient to justify making it
absolutely impossible to comprehend for any specific minority
of readers (at least among those "minorities" that are likely
to be required to understand it).  Minorities in this context
inclide anyone who does not have the ability to use the needed
document display tools - either because they do not have them
or because they are otherwise prevented from using them.

	However, as must be apparent from other discussion in 
various related threads, this is only a minority consideration.

--
Eric

--> -----Original Message-----
--> From: Stewart Bryant [mailto:stbryant@cisco.com] 
--> Sent: Tuesday, January 10, 2006 12:01 AM
--> To: Gray, Eric
--> Cc: ietf@ietf.org
--> Subject: Re: Normative figures
--> 
--> 
--> >Yes.  And, if we're talking about wanting to make the figures
--> >normative, I assume we are talking about a specification.  In
--> >that case, it is far more important that the description MUST 
--> >be precise, than it is that it MAY be convenient.
--> >
--> >  
--> >
--> Please can we clarify the existing rules:
--> 
--> For a standards track document is it technically acceptable 
--> to provide:
--> 
--> A .pdf that is complete (but is non-normative under current rules)
--> 
--> plus
--> 
--> An ASCII text in which the background material refers to 
--> figures in the
--> .pdf  but which contains the essential normative statements.
--> 
--> i.e. Is a standards track RFC approvable when it is correct in the 
--> technical
--> sense, even if it is almost incomprehensible without the 
--> text, figures and
--> equations from its non-normative twin.
--> 
--> - Stewart
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 12:03:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwMtp-0000YW-1N; Tue, 10 Jan 2006 12:03:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMtm-0000YF-JF
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 12:03:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21290
	for ; Tue, 10 Jan 2006 12:01:47 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwN0V-0000lY-H0
	for ietf@ietf.org; Tue, 10 Jan 2006 12:10:04 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0AH2sSD000031; Tue, 10 Jan 2006 12:02:54 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA09294; 
	Tue, 10 Jan 2006 12:02:53 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Tue, 10 Jan 2006 12:02:53 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C8862B9@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Burger, Eric'" 
Date: Tue, 10 Jan 2006 12:02:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: ietf@ietf.org
Subject: RE: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Eric,

--- [SNIP ---
--> IMHO, *way* too many I*E*TF work groups get chartered based on
--> an idea. We then spend tons of resources on figuring out if the
--> idea will work. We produce lots of half-baked documents with 
--> little basis in working code.  Then folks try implementing 
--> what's been spec'ed, find it doesn't work, but then find a ton 
--> of resistance to change, because the specs are three years old 
--> and "we don't want to break draft-mumble-05 implementations."
--> 
--> If something is an idea, let's make it politically acceptable 
--> for the "work" to be done in the I*R*TF first.
--> 
--- [SNIP] ---

I think this is a gross mischaraterization of current practice in
the IETF generally - however many exceptions we might find.

Usually - at least among those of us that work for a living - we
would not bring something to the IETF unless we were already in
the process of implementing it and we have been encouraged by our
employers (or - indirectly - by our customers) to bring it to the
IETF.

When people bring ideas to the IETF that "seem like a good thing"
but aren't practical or implementable at the current time, they
are usually encouraged to take those ideas to the IRTF.

--
Eric

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 12:34:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwNNn-0003Ey-IC; Tue, 10 Jan 2006 12:34:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNNl-0003DM-BW
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 12:34:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23506
	for ; Tue, 10 Jan 2006 12:32:45 -0500 (EST)
Received: from stratton-three-twelve.mit.edu ([18.187.6.57]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwNUU-0001kA-J3
	for ietf@ietf.org; Tue, 10 Jan 2006 12:41:03 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id C6F10E0053; Tue, 10 Jan 2006 12:33:58 -0500 (EST)
To: Stewart Bryant 
References: <313680C9A886D511A06000204840E1CF0C886269@whq-msgusr-02.pit.comms.marconi.com>
	<43BD82D2.7070201@WEIJax.com> 
	<43C2A8BC.2030407@cisco.com>
From: Sam Hartman 
Date: Tue, 10 Jan 2006 12:33:57 -0500
In-Reply-To: <43C2A8BC.2030407@cisco.com> (Stewart Bryant's message of "Mon,
	09 Jan 2006 18:17:32 +0000")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: ietf@ietf.org, Sandy Wills 
Subject: Re: objection to proposed change to "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Stewart" == Stewart Bryant  writes:

    >> I think these are valuable inputs as well.  There are people
    >> involved; whether these people are happy, whether they will
    >> continue to work, are important factors.  Of course there are
    >> religious arguments on the other side: "I want my architectural
    >> diagrams; they work well in the ITU and I want them here," is
    >> on the same level as "I won't use MS software."
    >> 
    >> 

    Stewart> Sam

    Stewart> I disagree that the use of diagrams is a religious
    Stewart> issue. Diagrams are a very simple way to 

I think the discussion has reached an all time low.  We're arguing
about whether something is a religious issue or not.

I think I'll add one more reason to why I think it is important to
consider religious issues: that way,you don't have to argue about
whether something is religious.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 12:55:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwNia-0002s9-0T; Tue, 10 Jan 2006 12:55:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwNiY-0002rz-Id
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 12:55:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24813
	for ; Tue, 10 Jan 2006 12:54:14 -0500 (EST)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwNpH-0002MC-VX
	for ietf@ietf.org; Tue, 10 Jan 2006 13:02:33 -0500
X-IronPort-AV: i="3.99,351,1131339600"; 
	d="scan'208"; a="25759165:sNHT41772456"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Jan 2006 12:55:31 -0500
Message-ID: <330A23D8336C0346B5C1A5BB1966664701F54541@ATLANTIS.Brooktrout.com>
Thread-Topic: Working Group chartering
Thread-Index: AcYWB7TUXfUJychOQ7uRBtnT+oQNdwABrXxA
From: "Burger, Eric" 
To: "Gray, Eric" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Normally, I would agree, but in one area in particular where I'm active,
RAI, I've seen it all.  There has been a ton of work that was
"interesting" and "nice to have."

Also, I am a big proponent of microeconomics, which would have rational
actors only put forth and push stuff clearly needed for products.
HOWEVER, in the "highest" IETF fashion, I've regularly seen multiple
folks from the same company arguing against each other in the working
groups.  I would have much more appreciated their working out their
differences at home and bring in their 'corporate' position :)

Likewise, often I see folks bring something that "needs to be solved" to
the IETF.  This can generate lots of interest, especially if the person
with the problem is a customer.  However, that still doesn't mean the
solution space is in the realm of the IETF.

-----Original Message-----
From: Gray, Eric [mailto:Eric.Gray@marconi.com]=20
Sent: Tuesday, January 10, 2006 12:03 PM
To: Burger, Eric
Cc: ietf@ietf.org
Subject: RE: Working Group chartering

Eric,

--- [SNIP ---
--> IMHO, *way* too many I*E*TF work groups get chartered based on
--> an idea. We then spend tons of resources on figuring out if the
--> idea will work. We produce lots of half-baked documents with=20
--> little basis in working code.  Then folks try implementing=20
--> what's been spec'ed, find it doesn't work, but then find a ton=20
--> of resistance to change, because the specs are three years old=20
--> and "we don't want to break draft-mumble-05 implementations."
-->=20
--> If something is an idea, let's make it politically acceptable=20
--> for the "work" to be done in the I*R*TF first.
-->=20
--- [SNIP] ---

I think this is a gross mischaraterization of current practice in
the IETF generally - however many exceptions we might find.

Usually - at least among those of us that work for a living - we
would not bring something to the IETF unless we were already in
the process of implementing it and we have been encouraged by our
employers (or - indirectly - by our customers) to bring it to the
IETF.

When people bring ideas to the IETF that "seem like a good thing"
but aren't practical or implementable at the current time, they
are usually encouraged to take those ideas to the IRTF.

--
Eric

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 13:24:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwOAR-0001rj-RG; Tue, 10 Jan 2006 13:24:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOAQ-0001r4-Ps
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 13:24:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26848
	for ; Tue, 10 Jan 2006 13:23:02 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EwOHB-0003FR-0m
	for ietf@ietf.org; Tue, 10 Jan 2006 13:31:21 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-3.cisco.com with ESMTP; 10 Jan 2006 10:24:13 -0800
X-IronPort-AV: i="3.99,351,1131350400"; 
	d="scan'208"; a="389933603:sNHT36490256"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0AIO3Wf028738;
	Tue, 10 Jan 2006 10:24:12 -0800 (PST)
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 10 Jan 2006 13:23:50 -0500
Received: from 10.21.81.30 ([10.21.81.30]) by xmb-rtp-205.amer.cisco.com
	([64.102.31.59]) via Exchange Front-End Server email.cisco.com
	([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; 
	Tue, 10 Jan 2006 18:23:52 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Tue, 10 Jan 2006 13:23:57 -0500
From: Melinda Shore 
To: "Burger, Eric" 
Message-ID: 
Thread-Topic: Working Group chartering
Thread-Index: AcYWB7TUXfUJychOQ7uRBtnT+oQNdwABrXxAAAEmjFc=
In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701F54541@ATLANTIS.Brooktrout.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 10 Jan 2006 18:23:50.0359 (UTC)
	FILETIME=[00FFC670:01C61613]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 1/10/06 12:55 PM, "Burger, Eric"  wrote:
> Normally, I would agree, but in one area in particular where I'm active,
> RAI, I've seen it all.  There has been a ton of work that was
> "interesting" and "nice to have."

I'm going to hazard a guess here and suggest that that area has
more interaction with/more interdependencies with other standards
bodies, where it's more typical to be very, very top-down.  In a
number of cases those bodies have said "We need an internet
protocol that does ; the IETF is the organization that standardizes
internet protocols so we'll send the work there."  To the extent that
the other option is to have other bodies standardizing internet
protocols I expect that's actually somewhat desirable.  If the
alternative were that the work went on hold until something had something
that was technically acceptable and reasonably mature, what would
happen outside the IETF?  Would those other bodies go along (even though
that's not how they work, themselves) or would they start producing
more internet protocols?

On the upside, one considerable benefit to the way the IETF does
its work, I think, is that it's usually pretty difficult to do
the kind of horse trading ("I'll agree to your unnecessary feature
if you'll agree to my unnecessary feature") that sometimes takes
place elsewhere.

Melinda

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 13:26:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwOCC-0002Js-L8; Tue, 10 Jan 2006 13:26:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOCA-0002FN-Kd
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 13:26:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27015
	for ; Tue, 10 Jan 2006 13:24:50 -0500 (EST)
Received: from stratton-three-twelve.mit.edu ([18.187.6.57]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwOIu-0003KD-9V
	for ietf@ietf.org; Tue, 10 Jan 2006 13:33:09 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id B3A6CE0053; Tue, 10 Jan 2006 13:26:02 -0500 (EST)
To: dcrocker@bbiw.net
References: <313680C9A886D511A06000204840E1CF0C88625D@whq-msgusr-02.pit.comms
	.marconi.com> <43BD5BDE.4070905@WEIJax.com>
	<43BD9BA0.2000204@swin.edu.au> <43BDAD26.9020909@WEIJax.com>
	
	<43BE786D.6050006@WEIJax.com>
	
	
	<43BEAE5C.1040705@WEIJax.com> <43C261FF.5020106@zurich.ibm.com>
	<43C2DEE4.2030407@dcrocker.net>
From: Sam Hartman 
Date: Tue, 10 Jan 2006 13:26:02 -0500
In-Reply-To: <43C2DEE4.2030407@dcrocker.net> (Dave Crocker's message of
	"Mon, 09 Jan 2006 14:08:36 -0800")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: IETF General Discussion Mailing List 
Subject: Re: Trying to invent a way of determining "consensus"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I strongly disagree with David's characterization of the IETF, his
characterization of how things should work, his claim that the problem
he has identified should be fixed and the proposed solution.

Consider this a vote of "wrong direction."  If it becomes apparent
that David is attracting significant interest in his proposal then I
will respond in more detail.  Until then I'll try and work on
directions of improving the IETF that I like better.  

the only reason I'm writing this message is that I don't want silence
to be taken as agreement in this instance.  Clearly if a number of
people come forward and agree with David then I must either provide
more constructive suggestions or accept that my objection will have
little weight.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 13:27:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwOD8-0002hs-BS; Tue, 10 Jan 2006 13:27:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwOD6-0002da-5f
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 13:27:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27176
	for ; Tue, 10 Jan 2006 13:25:48 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwOJp-0003N1-HW
	for ietf@ietf.org; Tue, 10 Jan 2006 13:34:06 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-5.cisco.com with ESMTP; 10 Jan 2006 10:26:26 -0800
X-IronPort-AV: i="3.99,351,1131350400"; 
	d="scan'208"; a="248149091:sNHT4566649362"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0AIQOcX012053;
	Tue, 10 Jan 2006 10:26:26 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 10 Jan 2006 10:26:24 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.145.179]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 10 Jan 2006 10:26:23 -0800
Message-Id: <4.3.2.7.2.20060110121944.03704f08@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 10 Jan 2006 12:26:22 -0600
To: "Burger, Eric" 
From: "James M. Polk" 
In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701F54541@ATLANTIS.Brooktro
	ut.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 10 Jan 2006 18:26:23.0807 (UTC)
	FILETIME=[5C7614F0:01C61613]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: ietf@ietf.org
Subject: RE: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 12:55 PM 1/10/2006 -0500, Burger, Eric wrote:
>Also, I am a big proponent of microeconomics, which would have rational
>actors only put forth and push stuff clearly needed for products.
>HOWEVER, in the "highest" IETF fashion, I've regularly seen multiple
>folks from the same company arguing against each other in the working
>groups.

Now, which company does this sound like?

>I would have much more appreciated their working out their
>differences at home and bring in their 'corporate' position :)

I do hope you're not even remotely serious with this suggestion...


>Likewise, often I see folks bring something that "needs to be solved" to
>the IETF.  This can generate lots of interest, especially if the person
>with the problem is a customer.  However, that still doesn't mean the
>solution space is in the realm of the IETF.
>
>-----Original Message-----
>From: Gray, Eric [mailto:Eric.Gray@marconi.com]
>Sent: Tuesday, January 10, 2006 12:03 PM
>To: Burger, Eric
>Cc: ietf@ietf.org
>Subject: RE: Working Group chartering
>
>Eric,
>
>--- [SNIP ---
>--> IMHO, *way* too many I*E*TF work groups get chartered based on
>--> an idea. We then spend tons of resources on figuring out if the
>--> idea will work. We produce lots of half-baked documents with
>--> little basis in working code.  Then folks try implementing
>--> what's been spec'ed, find it doesn't work, but then find a ton
>--> of resistance to change, because the specs are three years old
>--> and "we don't want to break draft-mumble-05 implementations."
>-->
>--> If something is an idea, let's make it politically acceptable
>--> for the "work" to be done in the I*R*TF first.
>-->
>--- [SNIP] ---
>
>I think this is a gross mischaraterization of current practice in
>the IETF generally - however many exceptions we might find.
>
>Usually - at least among those of us that work for a living - we
>would not bring something to the IETF unless we were already in
>the process of implementing it and we have been encouraged by our
>employers (or - indirectly - by our customers) to bring it to the
>IETF.
>
>When people bring ideas to the IETF that "seem like a good thing"
>but aren't practical or implementable at the current time, they
>are usually encouraged to take those ideas to the IRTF.
>
>--
>Eric
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 14:39:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwPLM-00078v-WC; Tue, 10 Jan 2006 14:39:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwPLL-00076u-8C
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 14:39:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02338
	for ; Tue, 10 Jan 2006 14:38:22 -0500 (EST)
Received: from stratton-three-twelve.mit.edu ([18.187.6.57]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwPS6-0005ZG-GC
	for ietf@ietf.org; Tue, 10 Jan 2006 14:46:42 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id E31F8E0053; Tue, 10 Jan 2006 14:39:35 -0500 (EST)
To: ietf@ietf.org
From: Sam Hartman 
Date: Tue, 10 Jan 2006 14:39:35 -0500
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Subject: Accessibility of Documents
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



Hi.  I'd hoped to avoid this, but a number of people both on and
off-list have asked me to discuss the issue of accessibility of documents.
for those who may not know, I'm blind.


I try and avoid such discussions.  It is fairly clear to me that my
standards of accessibility are different than other blind peoples'.
The one time I was involved in accessibility consulting,the I was told
by the blind users that there is no way a blind person could use the
system we had designed.  So, I can speak for myself, but I will not
claim that  anyone else will agree with me.


I do find IETF specs significantly easier to read than most other
SDOs.  Much of this is the fact that RFCs are available as text.  I'd
find HTML almost as convenient.  

I think HTML would be much more accessible than PDF.  Some PDFs are
reasonably OK.  However some PDFs tend to have images instead of text
and that roughly requires printing out, scanning and then OCRing the
get information out.  (In theory you could just OCR the PDF; I have
not had as good of luck with that as I should, but a new solution I've
been working with for OCR might do much better that way.)


Some PDFs are just hard to extract text from even if they don't use
images.  I think it is a font encoding issue.  PDFs using the computer
modern fonts are notoriously bad in this regard.

I also find that IETF specs are more readable because they do tend to
focus less on figures and actually spend the time to explain what is
going on rather than depending on a picture.  

I'd like to focus on several types of possible figures and discuss
ways they could be handled.

network packet diagrams: I can get enough content out of these in
ASCII text so that I know what is in the packet and roughly what
order.  I find determining how long fields are to be challenging
without help from someone else.  I believe the accessibility of our
documents would be significantly reduced if we replaced these with
images without having an alternate representation of the information.

equations: ASCII equations are generally as easy to follow for me as
for others--which is to say sometimes not so great.  I agree that
visually appealing equations could be useful.  LaTex is easier to read
than mathml; I'm not sure how to provide both the image and the latex
in the same document.  Perhaps alt tags could be used.


Graphs: A lot of diagrams attempt to show relations between entities,
state transitions or other things that fall into the category of
mathematical graphs (sets of nodes and edges).  I can generally get
the names of nodes out of ASCII descriptions but no more.  Here's a
case where I really think the diagram should not be normative and that
you need good text to go along with the diagram.  It should be
possible to find the names of the nodes, the edges and the labels on
the edges by reading the text.  In general if you are doing a good job
of explaining your protocol you'll want this in your text anyway.  The
one case where this might not be true is state transition diagrams: if
you don't manage to explain why your state machine works the way it
does, then you might not have any reason to describe the states in the
text.  My opinion as an IESG member and document reviewer is that it's
worth it to explain the reasoning behind your states.  That gives you
an excuse to have your text be complete and makes your document much
easier to review.

function graphs: Another class of diagram would be a graph of some
function.  I'm likely to get nothing out of the diagram in ASCII.
Here, if I really cared, I actually could do something with an image;
there are ways to print the image in such a way that I could at least
look at the shape of the function.  It is useful to describe the
variables and the domain and range of the function.  It is useful if
the text describes the basic conclusion of the graph.  "As you can
see, the performance of this protocol is exponential in the number of
participants in the session.  We recommend against large sessions."

pictures: I guess someone might want to include a photo or other
picture in an IETF spec.  I'd kind of like to know why.  Be sure to
explain what the point of the photo is in the text.

--Sam

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 16:09:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwQjt-0007jU-5O; Tue, 10 Jan 2006 16:09:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQjr-0007jG-3J
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 16:09:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09742
	for ; Tue, 10 Jan 2006 16:07:47 -0500 (EST)
Received: from stratton-three-twelve.mit.edu ([18.187.6.57]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQqb-0000GA-3n
	for ietf@ietf.org; Tue, 10 Jan 2006 16:16:06 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id D44E1E0053; Tue, 10 Jan 2006 16:08:57 -0500 (EST)
To: Stewart Bryant 
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
	
	<43BD12AC.1010203@zurich.ibm.com> <43BD2B97.3070400@cisco.com>
	 <43C2A477.9060608@cisco.com>
	 <43C2BDA2.30908@cisco.com>
From: Sam Hartman 
Date: Tue, 10 Jan 2006 16:08:57 -0500
In-Reply-To: <43C2BDA2.30908@cisco.com> (Stewart Bryant's message of "Mon,
	09 Jan 2006 19:46:42 +0000")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Stewart" == Stewart Bryant  writes:


    Stewart> For example you could say the following in text : router
    Stewart> A connects to router B and D, the cost from A to B is 2,
    Stewart> and the cost from A to D is 4.  Router B connects to
    Stewart> router C. The cost to router A is 6, and the cost to
    Stewart> router C is 10. Router C connects to router D. The cost
    Stewart> to router B is 9 and the cost to router D is 8. The cost
    Stewart> from router D to router A is 16 and the cost to router A
    Stewart> is 99.


I think we fundamentally disagree here that the text is not needed.
There's a bit of fuzz in that I think the normative text needs to
describe the properties of the graph necessary to make your point and
to make it obvious that such a graph exists; it may not need to
describe all the labels of all edges.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 17:59:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwSSr-0005X1-Gh; Tue, 10 Jan 2006 17:59:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSSp-0005Vz-2R
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 17:59:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16827
	for ; Tue, 10 Jan 2006 17:58:19 -0500 (EST)
Received: from rwcrmhc12.comcast.net ([216.148.227.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwSZa-0003P1-QR
	for ietf@ietf.org; Tue, 10 Jan 2006 18:06:40 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (rwcrmhc12) with SMTP
	id <2006011022592701400pk5aqe>; Tue, 10 Jan 2006 22:59:27 +0000
Message-ID: <019d01c61639$5acdedf0$d0087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: 
Date: Tue, 10 Jan 2006 16:58:19 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 1.0 (+)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Subject: Re: Accessibility of Documents (veering off-topic)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi, Sam,

Thank you for taking the time to explain this stuff to us. It is very 
helpful.

Just on your last point:

> pictures: I guess someone might want to include a photo or other
> picture in an IETF spec.  I'd kind of like to know why.  Be sure to
> explain what the point of the photo is in the text.

In RFC 2397, "The "data" URL scheme", the following URL appears:

   Larry

If you cut-and-paste this text into an HTML document and view it with a 
browser that supports RFC 2397 (last I looked, Netscape and Mozilla did and 
IE did not, but that's been a while), you see either a black-and-white GIF 
of Larry Masinter that's about the size of your thumbnail, or "Larry" as the 
ALT text.

That's not quite "putting a picture in an RFC", but it's close :-)

I'm also thinking that if an RFC is bad enough, having pictures of 
authors/editors might make it easier to recognize the guilty parties and 
organize a lynch mob, and that might do more to improve our quality than 
anything since Kobe...

Have a great day,

Spencer 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 18:24:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwSqT-0006N1-7G; Tue, 10 Jan 2006 18:24:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSqR-0006MD-23
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 18:24:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18631
	for ; Tue, 10 Jan 2006 18:22:43 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwSxD-00049u-Ep
	for ietf@ietf.org; Tue, 10 Jan 2006 18:31:04 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 34BFF2596E0;
	Wed, 11 Jan 2006 00:22:52 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 32181-06; Wed, 11 Jan 2006 00:22:46 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 32E8E2596DC;
	Wed, 11 Jan 2006 00:22:46 +0100 (CET)
Date: Wed, 11 Jan 2006 00:23:46 +0100
From: Harald Tveit Alvestrand 
To: "James M. Polk" , "Burger, Eric" 
Message-ID: <14EA2DF5A74E9D790A998C09@svartdal.hjemme.alvestrand.no>
In-Reply-To: <4.3.2.7.2.20060110121944.03704f08@email.cisco.com>
References: <4.3.2.7.2.20060110121944.03704f08@email.cisco.com>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On tirsdag, januar 10, 2006 12:26:22 -0600 "James M. Polk" 
 wrote:

> At 12:55 PM 1/10/2006 -0500, Burger, Eric wrote:
>> Also, I am a big proponent of microeconomics, which would have rational
>> actors only put forth and push stuff clearly needed for products.
>> HOWEVER, in the "highest" IETF fashion, I've regularly seen multiple
>> folks from the same company arguing against each other in the working
>> groups.
>
> Now, which company does this sound like?
>
>> I would have much more appreciated their working out their
>> differences at home and bring in their 'corporate' position :)
>
> I do hope you're not even remotely serious with this suggestion...

Seconding James.. a requirement to have unanimous intra-company signoff on 
anything presented to the IETF would be the single quickest way to reduce 
the contributions to the IETF from the companies I've been involved in....

"we are all individuals", in addition to its other properties, is a way to 
let me say things (like this message) in public WITHOUT having to check 
with my "representative" or my "coordinating committee" before sending it.
If my company says "why did you say ", I can always say "it 
was my personal contribution, you don't have to take the blame for it".
Has worked for me so far....



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 18:49:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwTF9-0004Nb-Oy; Tue, 10 Jan 2006 18:49:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwTF6-0004Mk-UE
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 18:49:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20143
	for ; Tue, 10 Jan 2006 18:48:12 -0500 (EST)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwTLu-0004nW-6a
	for ietf@ietf.org; Tue, 10 Jan 2006 18:56:34 -0500
X-IronPort-AV: i="3.99,352,1131339600"; 
	d="scan'208,217"; a="25775218:sNHT52707192"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 10 Jan 2006 18:49:26 -0500
Message-ID: <330A23D8336C0346B5C1A5BB1966664701A58B2B@ATLANTIS.Brooktrout.com>
Thread-Topic: Working Group chartering
Thread-Index: AcYWPOzaQO8+yYyMTD6RZEGHdzoD3wAA5Cp3
From: "Burger, Eric" 
To: "Harald Tveit Alvestrand" ,
	"James M. Polk" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
Cc: ietf@ietf.org
Subject: RE: Working Group chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1580625933=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1580625933==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C61640.7D6D4CFE"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61640.7D6D4CFE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I was responding to the assertion that stuff got to the IETF because the =
individuals are, for the most part, paid by companies, and thus if =
someone was proposing a work item, it obviously was motivated by a =
corporate need.  My statements was an obvious COUNTER-example.  Sorry I =
didn't make the smiley larger.

 -----Original Message-----
From: 	Harald Tveit Alvestrand [mailto:harald@alvestrand.no]
Sent:	Tue Jan 10 18:23:55 2006
To:	James M. Polk; Burger, Eric
Cc:	ietf@ietf.org
Subject:	RE: Working Group chartering



--On tirsdag, januar 10, 2006 12:26:22 -0600 "James M. Polk"=20
 wrote:

> At 12:55 PM 1/10/2006 -0500, Burger, Eric wrote:
>> Also, I am a big proponent of microeconomics, which would have =
rational
>> actors only put forth and push stuff clearly needed for products.
>> HOWEVER, in the "highest" IETF fashion, I've regularly seen multiple
>> folks from the same company arguing against each other in the working
>> groups.
>
> Now, which company does this sound like?
>
>> I would have much more appreciated their working out their
>> differences at home and bring in their 'corporate' position :)
>
> I do hope you're not even remotely serious with this suggestion...

Seconding James.. a requirement to have unanimous intra-company signoff =
on=20
anything presented to the IETF would be the single quickest way to =
reduce=20
the contributions to the IETF from the companies I've been involved =
in....

"we are all individuals", in addition to its other properties, is a way =
to=20
let me say things (like this message) in public WITHOUT having to check=20
with my "representative" or my "coordinating committee" before sending =
it.
If my company says "why did you say ", I can always say =
"it=20
was my personal contribution, you don't have to take the blame for it".
Has worked for me so far....


------_=_NextPart_001_01C61640.7D6D4CFE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




RE: Working Group chartering





I was responding to the assertion that stuff got to =
the IETF because the individuals are, for the most part, paid by =
companies, and thus if someone was proposing a work item, it obviously =
was motivated by a corporate need.  My statements was an obvious =
COUNTER-example.  Sorry I didn't make the smiley larger.



 -----Original Message-----

From:   Harald Tveit Alvestrand [mailto:harald@alvestrand.no]
=

Sent:   Tue Jan 10 18:23:55 2006

To:     James M. Polk; Burger, Eric

Cc:     ietf@ietf.org

Subject:        RE: Working Group =
chartering







--On tirsdag, januar 10, 2006 12:26:22 -0600 "James M. =
Polk"

<jmpolk@cisco.com> wrote:



> At 12:55 PM 1/10/2006 -0500, Burger, Eric wrote:

>> Also, I am a big proponent of microeconomics, which would have =
rational

>> actors only put forth and push stuff clearly needed for =
products.

>> HOWEVER, in the "highest" IETF fashion, I've =
regularly seen multiple

>> folks from the same company arguing against each other in the =
working

>> groups.

>

> Now, which company does this sound like?

>

>> I would have much more appreciated their working out their

>> differences at home and bring in their 'corporate' position =
:)

>

> I do hope you're not even remotely serious with this =
suggestion...



Seconding James.. a requirement to have unanimous intra-company signoff =
on

anything presented to the IETF would be the single quickest way to =
reduce

the contributions to the IETF from the companies I've been involved =
in....



"we are all individuals", in addition to its other properties, =
is a way to

let me say things (like this message) in public WITHOUT having to =
check

with my "representative" or my "coordinating =
committee" before sending it.

If my company says "why did you say <stupid thing>", I =
can always say "it

was my personal contribution, you don't have to take the blame for =
it".

Has worked for me so far....









------_=_NextPart_001_01C61640.7D6D4CFE--


--===============1580625933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1580625933==--




From ietf-bounces@ietf.org Tue Jan 10 19:04:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwTTB-0001ia-42; Tue, 10 Jan 2006 19:04:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwTT8-0001fk-Lh
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 19:04:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22773
	for ; Tue, 10 Jan 2006 19:02:42 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwTZv-0005nm-Ug
	for ietf@ietf.org; Tue, 10 Jan 2006 19:11:04 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EwTSr-0001dY-Ew
	for ietf@ietf.org; Wed, 11 Jan 2006 01:03:45 +0100
Received: from pd9fba8ec.dip0.t-ipconnect.de ([217.251.168.236])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Wed, 11 Jan 2006 01:03:45 +0100
Received: from nobody by pd9fba8ec.dip0.t-ipconnect.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for ; Wed, 11 Jan 2006 01:03:45 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Wed, 11 Jan 2006 01:02:55 +0100
Organization: 
Lines: 11
Message-ID: <43C44B2F.25BA@xyzzy.claranet.de>
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
	
	<43BD12AC.1010203@zurich.ibm.com> <43BD2B97.3070400@cisco.com>
	 <43C2A477.9060608@cisco.com>
	 <43C2BDA2.30908@cisco.com>
	<20060110152948.GA8175@nic.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fba8ec.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stephane Bortzmeyer wrote:

> Here is the Graphviz code, to compare (I also attached the
> automatically produced PNG but Graphviz can make PDF or SVG
> as well)

Nice, I've always loved graph theory.  Now let it colour the
shortest path fromn B to D, and then ask it for some decent
ASCII art output...   Joke off, this "code" should work as
it is forever for everybody who wants it to work.  Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 19:28:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwTrD-0002U5-AW; Tue, 10 Jan 2006 19:28:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwTrC-0002U0-1d
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 19:28:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24942
	for ; Tue, 10 Jan 2006 19:27:34 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwTxy-0006gr-UU
	for ietf@ietf.org; Tue, 10 Jan 2006 19:35:56 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EwTqy-000LDh-OI; Tue, 10 Jan 2006 19:28:40 -0500
Date: Tue, 10 Jan 2006 19:28:39 -0500
From: John C Klensin 
To: Spencer Dawkins , ietf@ietf.org
Message-ID: 
In-Reply-To: <019d01c61639$5acdedf0$d0087c0a@china.huawei.com>
References: 
	<019d01c61639$5acdedf0$d0087c0a@china.huawei.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: Accessibility of Documents (veering off-topic)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Tuesday, 10 January, 2006 16:58 -0600 Spencer Dawkins
 wrote:

>...
> I'm also thinking that if an RFC is bad enough, having
> pictures of authors/editors might make it easier to recognize
> the guilty parties and organize a lynch mob, and that might do
> more to improve our quality than anything since Kobe...

As an occasional fan of lynch mobs in the service of rough
consensus, I believe your objective would be better accomplished
by a photo gallery of recent RFC authors and editors, WG chairs,
and IESG and IAB members rather than making RFCs longer and more
bulky.  

You might suggest this to the IAOC; I am fairly certain they
would give it the appropriate priority :-)

    john




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 19:43:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwU5C-000642-MF; Tue, 10 Jan 2006 19:43:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwU5A-00063s-KZ
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 19:43:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26075
	for ; Tue, 10 Jan 2006 19:42:00 -0500 (EST)
Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwUBw-0007Au-Lp
	for ietf@ietf.org; Tue, 10 Jan 2006 19:50:23 -0500
Received: from darkwing.uoregon.edu (llynch@localhost [127.0.0.1])
	by darkwing.uoregon.edu (8.13.5/8.13.5) with ESMTP id k0B0h89r021559;
	Tue, 10 Jan 2006 16:43:09 -0800 (PST)
Received: from localhost (llynch@localhost)
	by darkwing.uoregon.edu (8.13.5/8.13.5/Submit) with ESMTP id
	k0B0h89v021556; Tue, 10 Jan 2006 16:43:08 -0800 (PST)
Date: Tue, 10 Jan 2006 16:43:08 -0800 (PST)
From: "Lucy E. Lynch" 
To: John C Klensin 
In-Reply-To: 
Message-ID: 
References: 
	<019d01c61639$5acdedf0$d0087c0a@china.huawei.com>
	
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: ietf@ietf.org
Subject: Re: Accessibility of Documents (veering off-topic)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Tue, 10 Jan 2006, John C Klensin wrote:

>
>
> --On Tuesday, 10 January, 2006 16:58 -0600 Spencer Dawkins
>  wrote:
>
> >...
> > I'm also thinking that if an RFC is bad enough, having
> > pictures of authors/editors might make it easier to recognize
> > the guilty parties and organize a lynch mob, and that might do
> > more to improve our quality than anything since Kobe...
>
> As an occasional fan of lynch mobs in the service of rough
> consensus, I believe your objective would be better accomplished
> by a photo gallery of recent RFC authors and editors, WG chairs,
> and IESG and IAB members rather than making RFCs longer and more
> bulky.
>
> You might suggest this to the IAOC; I am fairly certain they
> would give it the appropriate priority :-)

Gents,

watch how you use the word "lynch" please. As the oldest of six
I'm a bit *sensitive* to mob comments. ;-)

Lucy E. Lynch                           Academic User Services
Computing Center                        University of Oregon
llynch  @darkwing.uoregon.edu           (541) 346-1774



>     john
>
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 19:54:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwUFV-0001WX-J3; Tue, 10 Jan 2006 19:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwUFU-0001WS-4q
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 19:54:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26817
	for ; Tue, 10 Jan 2006 19:52:39 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwUMH-0007VG-Fv
	for ietf@ietf.org; Tue, 10 Jan 2006 20:01:01 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EwUFI-0003Zq-OG
	for ietf@ietf.org; Wed, 11 Jan 2006 01:53:48 +0100
Received: from pd9fba8ec.dip0.t-ipconnect.de ([217.251.168.236])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Wed, 11 Jan 2006 01:53:48 +0100
Received: from nobody by pd9fba8ec.dip0.t-ipconnect.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for ; Wed, 11 Jan 2006 01:53:48 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Wed, 11 Jan 2006 01:53:10 +0100
Organization: 
Lines: 11
Message-ID: <43C456F6.B41@xyzzy.claranet.de>
References: <01f601c615f4$89f77fa0$640fa8c0@cis.neustar.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fba8ec.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Paul Hoffman wrote:

> If any of those features came free or very cheap, that
> would be great.

JFTR:  The last xml2rfc version under test (pre3) supported
to validate ABNF on the fly for  if the
source asks for "strict" processing.

                         Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 20:16:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwUbb-0000Kw-Py; Tue, 10 Jan 2006 20:16:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwUbY-0000Kd-BD
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 20:16:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28202
	for ; Tue, 10 Jan 2006 20:15:27 -0500 (EST)
Received: from dx28.winwebhosting.com ([70.85.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwUiM-00088c-D0
	for ietf@ietf.org; Tue, 10 Jan 2006 20:23:50 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP)
	by dx28.winwebhosting.com with esmtpa (Exim 4.52)
	id 1EwUbZ-0007Lz-1J; Tue, 10 Jan 2006 19:16:49 -0600
From: "Brian Rosen" 
To: "'Paul Hoffman'" , 
Date: Tue, 10 Jan 2006 20:13:35 -0500
Message-ID: <031101c6164c$41104a30$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: 
Thread-Index: AcYWAvfQexRjnXflQHeNyGe7E/HaAAAR+Yzg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: 7bit
Cc: 
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: br@brianrosen.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I'd mostly agree if this was a one off, but it's not; it requires continuous
effort to maintain.  My experience that manual is usually cheapest if it
only has to be done once, and automation is cheapest if it has to be
continuously maintained.  YMMV.

Most of the harvesting of sections of things that are now text that could be
harvested apply to RFCs and not IDs, but things like ABNF checking and even
MIB checking could be part of ID nits.  Hyperlinks apply to both.

There are many ways to put meta-data in files, but I'd rather not invent a
new one.  xml is just fine, thank you.  And we have a nice tool that puts
out text and html, and with a small amount of effort, PDF from xml.  Our
reluctance to use it is mostly:
	The RFC editor has some problems which have not, to my knowledge,
been	enumerated.

	There are currently other ways to produce ASCII output that people
are
	reluctant to give up on.

I suspect we can fix the former.  The question is whether the usefulness of
the harvesting and alternative outputs outweighs the latter, assuming we
accept ASCII output as required and normative.

Brian


-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Paul
Hoffman
Sent: Tuesday, January 10, 2006 11:15 AM
To: ietf@ietf.org
Subject: RE: Alternative formats for IDs

At 9:45 AM -0500 1/10/06, Brian Rosen wrote:
>Do you have any idea how painful it is to build any kind of product that
has
>good management simply because there is no library of MIBs, with references
>to documents?  There isn't even a LIST of IETF MIBs.  You can't figure out
>if a document has a MIB unless you actually look at the text (although many
>have a big hint in the title of the document).  So yes, I believe better
MIB
>tools would lead to better products, although it would be hard to prove it.

Why does this need to be done in the RFCs or Internet Drafts 
themselves? Why, for example, can't a human with a bit of training 
extract all the MIBs from the current RFCs and put them into a 
repository that is machine-accessible? Doing so would probably take 
less time than writing the tool to make human-readable RFCs also 
machine-readable.

As for Internet Drafts (if we really want people implementing from 
Internet Drafts), it is trivial to create a convention that says "if 
you want the MIB in your draft to be machine-readable, copy the MIB 
to a public web server and, in the draft, put on a line by itself: 
THE-MIB-IS-AT ". No changes are needed to any input or output 
tools, yet the problem of finding MIBs is solved.

>I would like to enable automated testing of ABNF.  I'd like to be able to
>cross check the ABNF from one document against its normative references to
>see what changes or conflicts.  I'd like to be able to generate a complete
>list of SIP error messages a UA may be expected to encounter.  I'd like to
>see a lot more hyperlinking of things.  All of these are much easier with
>meta-data.

Sure. If any of those features came free or very cheap, that would be 
great. None of them do, particularly when you factor in the 
design-by-entire-IETF-mailing-list work factor. Instead, a bit of 
human interaction is much less expensive.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 10 20:47:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwV5N-0001Mm-Lo; Tue, 10 Jan 2006 20:47:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwV5L-0001Mh-2k
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 20:47:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00051
	for ; Tue, 10 Jan 2006 20:46:14 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwVC5-0000XZ-2l
	for ietf@ietf.org; Tue, 10 Jan 2006 20:54:37 -0500
Received: from [192.168.1.107] (ppp-71-139-26-86.dsl.snfc21.pacbell.net
	[71.139.26.86]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0B1lhwS021829
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2006 17:47:44 -0800
Message-ID: <43C46396.7030406@dcrocker.net>
Date: Tue, 10 Jan 2006 17:47:02 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: "Lucy E. Lynch" 
References: 	<019d01c61639$5acdedf0$d0087c0a@china.huawei.com>	
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Accessibility of Documents (veering off-topic)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


> watch how you use the word "lynch" please. As the oldest of six
> I'm a bit *sensitive* to mob comments. ;-)



Lucy, I suspect that they merely were making a spelling error, since I'm sure 
they were referring to folk who are truly essential, and therefore qualify as 
linch pins...

d/

ps.  As one who constantly wishes people would find a different dismissive label 
than "crock" I do, however, share your sensitivity.


-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 00:18:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwYNM-0004bv-BX; Wed, 11 Jan 2006 00:18:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwYNJ-0004bd-Iz
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 00:18:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13333
	for ; Wed, 11 Jan 2006 00:17:01 -0500 (EST)
Received: from rwcrmhc12.comcast.net ([216.148.227.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwYU8-0006S0-RD
	for ietf@ietf.org; Wed, 11 Jan 2006 00:25:26 -0500
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165])
	by comcast.net (rwcrmhc12) with SMTP
	id <2006011105175901400qbsfbe>; Wed, 11 Jan 2006 05:18:02 +0000
Message-ID: <030901c6166e$3c8c2930$d0087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: 	<019d01c61639$5acdedf0$d0087c0a@china.huawei.com>	
	<43C46396.7030406@dcrocker.net>
Date: Tue, 10 Jan 2006 23:16:04 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Subject: Re: Accessibility of Documents (veering off-topic)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear Dave and Lucy,

>> watch how you use the word "lynch" please. As the oldest of six
>> I'm a bit *sensitive* to mob comments. ;-)
>
> Lucy, I suspect that they merely were making a spelling error, since I'm 
> sure they were referring to folk who are truly essential, and therefore 
> qualify as linch pins...
>
> d/
>
> ps.  As one who constantly wishes people would find a different dismissive 
> label than "crock" I do, however, share your sensitivity.

My sincerest ("chuckle, snort!") apologies :-)

It is difficult to come up with useful terms that clearly describe a 
barely-controlled riot ... I thought the reference to July14 in the name of 
the draft that became RFC 3933 was very witty, but so few people caught the 
reference to Bastille Day that I finally decided it was only half-witty.

I guess, based on the IETF's previous experience, I should be using "Kobe" 
as a verb?

Thanks,

Spencer 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 03:24:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwbHS-0004Fp-1Y; Wed, 11 Jan 2006 03:24:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwbHN-0004E8-T5
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 03:24:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24307
	for ; Wed, 11 Jan 2006 03:23:04 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwbOD-0002yp-Om
	for ietf@ietf.org; Wed, 11 Jan 2006 03:31:32 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 81C1426C10D; Wed, 11 Jan 2006 09:24:16 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 7F55926C100; Wed, 11 Jan 2006 09:24:15 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k0B8OFYa995684;
	Wed, 11 Jan 2006 09:24:15 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id 4ECE116AA06; Wed, 11 Jan 2006 09:24:15 +0100 (CET)
Date: Wed, 11 Jan 2006 09:24:15 +0100
From: Stephane Bortzmeyer 
To: Frank Ellermann 
Message-ID: <20060111082415.GA15697@nic.fr>
References: <27A0F290348F8E45AEF79889DDE65A5205DCDF00@exrad2.ad.rad.co.il>
	
	<43BD12AC.1010203@zurich.ibm.com> <43BD2B97.3070400@cisco.com>
	 <43C2A477.9060608@cisco.com>
	 <43C2BDA2.30908@cisco.com>
	<20060110152948.GA8175@nic.fr> <43C44B2F.25BA@xyzzy.claranet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43C44B2F.25BA@xyzzy.claranet.de>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Wed, Jan 11, 2006 at 01:02:55AM +0100,
 Frank Ellermann  wrote 
 a message of 11 lines which said:

> this "code" should work as it is forever for everybody who wants it
> to work.

Yes, the good point about Graphviz is that it is readable even if you
do not know / have the software and that it is represented in ASCII,
therefore requiring no change to the procedures or rules.

For an ASCII-art output of an arbitrary graph, I wait for a clever CS
student to modify Graphviz in that way :-) 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 07:48:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwfOr-0004GL-Q0; Wed, 11 Jan 2006 07:48:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfOp-0004FX-1l
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 07:48:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08643
	for ; Wed, 11 Jan 2006 07:47:00 -0500 (EST)
Received: from mtagate1.uk.ibm.com ([195.212.29.134])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwfVd-0001LW-4T
	for ietf@ietf.org; Wed, 11 Jan 2006 07:55:26 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0BClHsE033220
	for ; Wed, 11 Jan 2006 12:47:26 GMT
Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com
	[9.149.37.228])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0BCjkV9114312 for ; Wed, 11 Jan 2006 12:45:46 GMT
Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0BCjkYo014900 for ; Wed, 11 Jan 2006 12:45:46 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0BCjknr014891; Wed, 11 Jan 2006 12:45:46 GMT
Received: from zurich.ibm.com (sig-9-146-218-26.de.ibm.com [9.146.218.26])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA52202;
	Wed, 11 Jan 2006 13:45:45 +0100
Message-ID: <43C4FDF9.3000609@zurich.ibm.com>
Date: Wed, 11 Jan 2006 13:45:45 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C8862B8@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C8862B8@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, 'Stewart Bryant' 
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Eric,
...
> 	Moreover, I believe there is evidence to this effect, as
> pointed out previously, in the fact that at least one RFC is 
> essentially only available in PS and PDF format.

That is an RFC that predates not only RFC 2026 but also its
predecessors, RFC 1602 and 1310. So it doesn't tell us anything
about the current rules.
...
> --> -----Original Message-----
> --> From: Stewart Bryant [mailto:stbryant@cisco.com] 
> --> Sent: Tuesday, January 10, 2006 12:01 AM
> --> To: Gray, Eric
> --> Cc: ietf@ietf.org
> --> Subject: Re: Normative figures
> --> 
> --> 
> --> >Yes.  And, if we're talking about wanting to make the figures
> --> >normative, I assume we are talking about a specification.  In
> --> >that case, it is far more important that the description MUST 
> --> >be precise, than it is that it MAY be convenient.
> --> >
> --> >  
> --> >
> --> Please can we clarify the existing rules:
> --> 
> --> For a standards track document is it technically acceptable 
> --> to provide:
> --> 
> --> A .pdf that is complete (but is non-normative under current rules)
> --> 
> --> plus
> --> 
> --> An ASCII text in which the background material refers to 
> --> figures in the
> --> .pdf  but which contains the essential normative statements.
> --> 
> --> i.e. Is a standards track RFC approvable when it is correct in the 
> --> technical
> --> sense, even if it is almost incomprehensible without the 
> --> text, figures and
> --> equations from its non-normative twin.

I'd have great difficulty approving such a document for the standards track
under RFC 2026:

       *  A stricter requirement applies to standards-track    *
       *  specifications:  the ASCII text version is the       *
       *  definitive reference, and therefore it must be a     *
       *  complete and accurate specification of the standard, *
       *  including all necessary diagrams and illustrations.  *

I don't think 'almost incomprehensible' would pass this test.
But in practice, incomprehensible diagrams or equations aren't
a problem that I've seen. That's not to deny that (e.g.) PNG
graphics might be easier to read sometimes. I'm wondering about
non-normative graphical and mathematical annexes to normative
documents.

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 07:52:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwfSq-0004zY-0H; Wed, 11 Jan 2006 07:52:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfSn-0004zT-PM
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 07:52:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08885
	for ; Wed, 11 Jan 2006 07:51:09 -0500 (EST)
Received: from mtagate2.uk.ibm.com ([195.212.29.135])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwfZh-0001RS-3k
	for ietf@ietf.org; Wed, 11 Jan 2006 07:59:38 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0BCpNWT148224
	for ; Wed, 11 Jan 2006 12:51:34 GMT
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com
	[9.149.37.216])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0BCpKV9219620 for ; Wed, 11 Jan 2006 12:51:20 GMT
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0BCpJQa019665 for ; Wed, 11 Jan 2006 12:51:19 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0BCpC57019423; Wed, 11 Jan 2006 12:51:15 GMT
Received: from zurich.ibm.com (sig-9-146-218-26.de.ibm.com [9.146.218.26])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA80618;
	Wed, 11 Jan 2006 13:51:11 +0100
Message-ID: <43C4FF3F.7020905@zurich.ibm.com>
Date: Wed, 11 Jan 2006 13:51:11 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: "Randy.Dunlap" 
References: <01e401c615e7$0e014230$640fa8c0@cis.neustar.com>
	<43C3BC3B.1030304@zurich.ibm.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Randy.Dunlap wrote:
> On Tue, 10 Jan 2006, Brian E Carpenter wrote:
> 
> 
>>...
>>
>>>What we are seeing is increasing use of fully automated tools that don't
>>>have humans identifying which octets are MIB and which are code.  You can't
>>>do that with plain ASCII.
>>
>>You can do that with meta-data encoded in plain ASCII. In fact, that
>>would work better for automated extraction than anything visual such as
>>using multiple fonts.
>>
>>...
> 
> 
> Does the RFC editor accept HTML in plain ASCII RFCs?

They accept ASCII.  looks like ASCII to me.
Actually  looks like ASCII too :-)

Seriously. If we want to embed metatdata tags in RFCs, we can just do it.

    Brian

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 08:02:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewfcd-0000Hv-Sl; Wed, 11 Jan 2006 08:02:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwPk7-0006Ai-3N
	for ietf@megatron.ietf.org; Tue, 10 Jan 2006 15:05:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04248
	for ; Tue, 10 Jan 2006 15:03:58 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwPqr-0006Lc-K4
	for ietf@ietf.org; Tue, 10 Jan 2006 15:12:19 -0500
Received: (qmail 7989 invoked from network); 10 Jan 2006 20:05:05 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 10 Jan 2006 20:05:05 -0000
Date: 10 Jan 2006 20:05:05 -0000
Message-ID: <20060110200505.76979.qmail@simone.iecc.com>
From: johnl@simone.iecc.com
To: ietf@ietf.org
X-Newsgroups: iecc.lists.ietf.ietf
In-Reply-To: <330A23D8336C0346B5C1A5BB1966664701F54541@ATLANTIS.Brooktrout.com>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
X-Mailman-Approved-At: Wed, 11 Jan 2006 08:02:36 -0500
Subject: Re: Working Group not chartering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>Likewise, often I see folks bring something that "needs to be solved"
>to the IETF.  This can generate lots of interest, especially if the
>person with the problem is a customer.  However, that still doesn't
>mean the solution space is in the realm of the IETF.

It seems to me that if the problem is not yet well enough understood
that we can see the path to engineer something to deal with it, it
belongs down the hall in the IRTF.

In the always exciting anti-spam arena I have been trying for over a
year to get some activity going in the ASRG on exactly this kind of
topic, where we know what the problem is but we don't understand what
the solutions are, yet.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 14:04:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwlGo-0006Bm-Hq; Wed, 11 Jan 2006 14:04:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwlGn-0006Bh-CQ
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 14:04:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04027
	for ; Wed, 11 Jan 2006 14:03:08 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwlNk-0004Dv-2D
	for ietf@ietf.org; Wed, 11 Jan 2006 14:11:41 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0BJ39i16171;
	Wed, 11 Jan 2006 11:03:09 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA10992;
	Wed, 11 Jan 2006 11:03:09 -0800 (PST)
Date: Wed, 11 Jan 2006 11:03:09 -0800 (PST)
Message-Id: <200601111903.LAA10992@gra.isi.edu>
To: john-ietf@jck.com
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: ietf@ietf.org
Subject: Re: PDF, Postscript, and "normative" versions (was: Re: Baby
 Steps (was RE: Alternative formats for IDs))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


   *> 
  *> Under those conditions, our precedents are that you can probably
  *> convince the WG/WGchairs/ADs, and eventually the RFC Editor,
  *> that a PDF document containing a picture of the Mona Lisa and an
  *> ASCII document with 
  *> 
  *>       _        -----
  *>               /     \
  *>       _       | o o |
  *>               |  |  |
  *>               | __  |
  *>       _       |     |
  *>               \_____/
  *>       _
  *>             |   |  |  |
  *> 
  *> as a substitute for that picture, with the marginal lines
  *> roughly identifying your grid marks and coordinate system, is
  *> "equivalent" or as close to it as one can get. 

John,

AFAIK, there is one worked example of this ... RFC 1119 on NTP.

Philosophers may speculate on the resemblance of NTP to the Mona Lisa...

Bob Braden
  *> 
  *> 
  *> _______________________________________________
  *> Ietf mailing list
  *> Ietf@ietf.org
  *> https://www1.ietf.org/mailman/listinfo/ietf
  *> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 14:33:11 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwliZ-0005IJ-N9; Wed, 11 Jan 2006 14:33:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwliX-0005Fn-GJ
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 14:33:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05534
	for ; Wed, 11 Jan 2006 14:31:48 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwlpT-0004yg-4b
	for ietf@ietf.org; Wed, 11 Jan 2006 14:40:21 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0BJUXi24942;
	Wed, 11 Jan 2006 11:30:33 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA11029;
	Wed, 11 Jan 2006 11:30:32 -0800 (PST)
Date: Wed, 11 Jan 2006 11:30:32 -0800 (PST)
Message-Id: <200601111930.LAA11029@gra.isi.edu>
To: braden@ISI.EDU, stbryant@cisco.com
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

 
  *> The draft has expired so I need to point to an external version. This draft
  *> which is looking at the properties of a routing network under conditions of
  *> failure would have been much clearer if it could have used mathematical
  *> notation rather than ASCIIised equations
  *> 
  *> http://www.faqs.org/ftp/pub/internet-drafts/draft-atlas-ip-local-protect-uturn-02.txt
  *> 
  *> Of course the diagrams could have also been clearer, as is seen by
  *> comparing them to the ones that Alia used in her presentatons on the
  *> subject.
  *> 
  *> - Stewart
  *> 

Stewart,

I just looked over this document, and it actually seems to me to
support the "ASCII art and equations are [just] enough to serve the
explanatory purpose" school of thought.

I really do not see that it would be "much clearer if it could have
used mathemtical notation".  As experienced programmers, we are
used to reading linearized formulas, aren't we?  And these particular
formulas seem quite simple.

Note that if and when this document is published as an RFC, the RFC
Editor will supply some additional blank lines and clean up the
indentation, which will make the equations much easier to read.  Also,
as you note, the ASCII art diagrams could really use a cleanup.  They
are unnecessarily ugly, kind of dyslexic.

It is true that the discipline of ASCII art forces the author to give
some thought to the clarity and modularity of the text.  Opinions
differ on whether this is a good thing or a bad thing.

Bob Braden

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 14:42:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewls2-0000N1-I2; Wed, 11 Jan 2006 14:42:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewlrw-0000Mw-70
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 14:42:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06273
	for ; Wed, 11 Jan 2006 14:41:31 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewlys-0005IT-Nj
	for ietf@ietf.org; Wed, 11 Jan 2006 14:50:04 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0BJgRi29160;
	Wed, 11 Jan 2006 11:42:27 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA11067;
	Wed, 11 Jan 2006 11:42:27 -0800 (PST)
Date: Wed, 11 Jan 2006 11:42:27 -0800 (PST)
Message-Id: <200601111942.LAA11067@gra.isi.edu>
To: braden@ISI.EDU, brc@zurich.ibm.com
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


  *> > Scott,
  *> > 
  *> > How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
  *> > of readable equations in ASCII?  I my experience, normative protocol
  *> > technical specifications rarely need equations much more complex than
  *> > these examples.  The only significant exception I can think of is the
  *> > NTP spec.
  *> 
  *> RFC 3247 is quite tricky too.
  *> 
  *> > 

Yes, in fact, the RFC Editor could have been persuaded that this
particular document fell into the RFC 1119 category -- PDF-only.
But note that it is not a standards track document, and that
very few areas of IETF endeavor have the mathematical depth
of queue management algorithms.

Bob  


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 14:53:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewm1n-00022N-N3; Wed, 11 Jan 2006 14:53:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm1m-00022H-2F
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 14:53:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07336
	for ; Wed, 11 Jan 2006 14:51:41 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewm8j-0005Xf-Vy
	for ietf@ietf.org; Wed, 11 Jan 2006 15:00:14 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0BJpgi02499;
	Wed, 11 Jan 2006 11:51:42 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA11088;
	Wed, 11 Jan 2006 11:51:41 -0800 (PST)
Date: Wed, 11 Jan 2006 11:51:41 -0800 (PST)
Message-Id: <200601111951.LAA11088@gra.isi.edu>
To: tytso@mit.edu, br@brianrosen.net
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: john-ietf@jck.com, ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

 

  *> I would like to enable automated testing of ABNF. 

Note that the RFC Editor has been running ABNF through an
automated checker, for quite a long time.  We find errors.

RFC Editor/bb

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 16:05:20 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewn9k-00060K-L7; Wed, 11 Jan 2006 16:05:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewn9i-00060F-NG
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 16:05:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12660
	for ; Wed, 11 Jan 2006 16:03:57 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwnGg-0007is-EP
	for ietf@ietf.org; Wed, 11 Jan 2006 16:12:31 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0BL2ii26277;
	Wed, 11 Jan 2006 13:02:44 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id NAA11191;
	Wed, 11 Jan 2006 13:02:44 -0800 (PST)
Date: Wed, 11 Jan 2006 13:02:44 -0800 (PST)
Message-Id: <200601112102.NAA11191@gra.isi.edu>
To: paul.hoffman@vpnc.org, br@brianrosen.net
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

  *> From: "Brian Rosen" 
  *> To: "'Paul Hoffman'" , 
  *> Date: Tue, 10 Jan 2006 20:13:35 -0500



  *> 	The RFC editor has some problems which have not, to my knowledge,
  *> been	enumerated.
  *> 

Your knowledge is apparently incomplete.  The RFC Editor has been
actively experimenting with using xml2rfc for publication, and we have
been passing our problems along to the tools team.  As we get more
experience, new ones show up.  There is not currently a version of
xml2rfc that meets our needs.  Some of our editors do the major
editing in XML, but they find it most efficient and effective to
switch to nroff for the final cleanup of the (ASCII) document format.

Bob Braden

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 16:48:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewnpl-0006Ns-QE; Wed, 11 Jan 2006 16:48:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewnpk-0006Nl-MK
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 16:48:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16803
	for ; Wed, 11 Jan 2006 16:47:22 -0500 (EST)
Received: from a.mail.sonic.net ([64.142.16.245])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewnwi-00013Z-GR
	for ietf@ietf.org; Wed, 11 Jan 2006 16:55:57 -0500
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG
	[168.61.10.151]) (authenticated bits=0)
	by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0BLmUg7030682
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 11 Jan 2006 13:48:31 -0800
In-Reply-To: <43C46396.7030406@dcrocker.net>
References: 	<019d01c61639$5acdedf0$d0087c0a@china.huawei.com>	
	
	<43C46396.7030406@dcrocker.net>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <624233B2-B4CC-42E8-8DE2-C2BCD630004E@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis 
Date: Wed, 11 Jan 2006 13:49:05 -0800
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Accessibility of Documents (veering off-topic)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 10, 2006, at 5:47 PM, Dave Crocker wrote:
>
> Lucy, I suspect that they merely were making a spelling error,  
> since I'm sure they were referring to folk who are truly essential,  
> and therefore qualify as linch pins...

I have never heard of a linching party.  RFCs filled with base64  
encoded images may invite an en masse response however.. : )

-Doug

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 16:52:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewnti-0007HB-V6; Wed, 11 Jan 2006 16:52:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewntg-0007Fg-Eq
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 16:52:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17046
	for ; Wed, 11 Jan 2006 16:51:26 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewo0c-0001Bn-DF
	for ietf@ietf.org; Wed, 11 Jan 2006 17:00:01 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EwntQ-000N3n-S6; Wed, 11 Jan 2006 16:52:33 -0500
Date: Wed, 11 Jan 2006 16:52:31 -0500
From: John C Klensin 
To: Bob Braden , paul.hoffman@vpnc.org, br@brianrosen.net
Message-ID: <5353FF6EB5D6B446638740EE@p3.JCK.COM>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden
 wrote:

>  *> 	The RFC editor has some problems which have not, to my
> knowledge,   *> been	enumerated.
>   *> 
> 
> Your knowledge is apparently incomplete.  The RFC Editor has
> been actively experimenting with using xml2rfc for
> publication, and we have been passing our problems along to
> the tools team.  As we get more experience, new ones show up.
> There is not currently a version of xml2rfc that meets our
> needs.  Some of our editors do the major editing in XML, but
> they find it most efficient and effective to switch to nroff
> for the final cleanup of the (ASCII) document format.

Bob,

Let me suggest a way to look at the above, deriving in large
measure from the experiences Ned Freed and I (mostly Ned, who
did the heavy lifting) had with what are now RFCs 4288 and 4289.
To the extent to which authors can hand XML to you, and get XML
back with whatever substantive/ editorial changes you have made,
it should ultimately not be a concern of anyone in the community
how you make the transition between the final XML, with all of
the text worked out, and the final formatting.  In particular,
if that step requires you to convert the XML to nroff and then
massage the nroff, I don't think it should be an issue.  The
issue arises from handing you a format that contains generic
markup and is editable but, because of your "via nroff" process,
requires authors to deduce substantive and editorial changes
from diffs and then retrofit them back into the XML for future
use.

Just my opinion, of course -- others may have other perspectives
or agendas.

   john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 17:06:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewo6g-0005lG-AX; Wed, 11 Jan 2006 17:06:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewo6e-0005iw-3x
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 17:06:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18547
	for ; Wed, 11 Jan 2006 17:04:52 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwoDc-0001q7-CP
	for ietf@ietf.org; Wed, 11 Jan 2006 17:13:25 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LXN45BXLF4001P8J@mauve.mrochek.com> for
	ietf@ietf.org; Wed, 11 Jan 2006 14:05:55 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1137017155;
	h=Date: 	 From:Subject:MIME-version;
	b=yzeZ2NFYLcAvzUEfkM0XoX7V8ZvOSxGW1aZ1wq
	yVWV8oMsVsO58RvPbdA0x6eu/KG9hlpIoZvV3a1rjKxrxg1Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LXN1TUJKXC00009C@mauve.mrochek.com>; Wed,
	11 Jan 2006 14:05:51 -0800 (PST)
To: Bob Braden 
Message-id: <01LXN459XW5K00009C@mauve.mrochek.com>
Date: Wed, 11 Jan 2006 14:00:48 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Wed, 11 Jan 2006 13:02:44 -0800 (PST)"
	<200601112102.NAA11191@gra.isi.edu>
MIME-version: 1.0
References: <200601112102.NAA11191@gra.isi.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: ietf@ietf.org, paul.hoffman@vpnc.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>   *> From: "Brian Rosen" 
>   *> To: "'Paul Hoffman'" , 
>   *> Date: Tue, 10 Jan 2006 20:13:35 -0500



>   *> 	The RFC editor has some problems which have not, to my knowledge,
>   *> been	enumerated.
>   *>

> Your knowledge is apparently incomplete.  The RFC Editor has been
> actively experimenting with using xml2rfc for publication, and we have
> been passing our problems along to the tools team.  As we get more
> experience, new ones show up.  There is not currently a version of
> xml2rfc that meets our needs.  Some of our editors do the major
> editing in XML, but they find it most efficient and effective to
> switch to nroff for the final cleanup of the (ASCII) document format.

Rather than sending such suggestions to the IETF tools team, why not bring them
up on the xml2rfc list? Given that I don't see names like "Charles Levert" and
"Julian Reschke" and "Marshall Rose" on the current tools team list, I'm a
little concerned that certain things might be lost in process of getting them
from the tools team to the actual xml2rfc tool maintainers.

In any case, Paul can hardly be blamed for being uninformed when the issues
aren't being brought up in what I, at least, think is clearly the correct
venue.

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 17:53:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewoqp-00020M-GW; Wed, 11 Jan 2006 17:53:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewoqn-00020H-Ud
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 17:53:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21612
	for ; Wed, 11 Jan 2006 17:52:34 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewoxm-0003CV-L7
	for ietf@ietf.org; Wed, 11 Jan 2006 18:01:08 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0BMsJTB024438
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2006 14:54:19 -0800
Message-ID: <43C58C72.6020702@dcrocker.net>
Date: Wed, 11 Jan 2006 14:53:38 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: John C Klensin 
References: <5353FF6EB5D6B446638740EE@p3.JCK.COM>
In-Reply-To: <5353FF6EB5D6B446638740EE@p3.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: Bob Braden , ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>> There is not currently a version of xml2rfc that meets our
>> needs. 

I do not recall seeing any input from the RFC Editor, on the XML2RFC mailing 
list, citing xml2rfc's deficiencies.

That makes it difficult to get those deficiencies fixed.

Please, please, please. Post those deficiencies to that list.


>   The
> issue arises from handing you a format that contains generic
> markup and is editable but, because of your "via nroff" process,
> requires authors to deduce substantive and editorial changes
> from diffs and then retrofit them back into the XML for future
> use.


This point has been made a number of times, recently.  Its importance appears to 
remain under-appreciated.

IETF documents are subject to revision by new editors.  They currently find it 
difficult or impossible to ensure that they are starting from the correct master 
version.

To the extent that they must start from the .txt version, they have significant 
startup costs (with significant potential for introducing new errors) in order 
to convert the document to a format better suited to editing -- e.g., better 
able to manipulate the document's structure.

What the IETF community needs is to be able to obtain an accurate, 
revisable-form version of published documents.  xml2rfc is the best candidate 
for that form.  We therefore need to find a way for the RFC Editor to maintain 
the master version of RFCs in that form.

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 17:54:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewoqx-000219-EP; Wed, 11 Jan 2006 17:54:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewoqw-000214-AY
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 17:54:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21625
	for ; Wed, 11 Jan 2006 17:52:42 -0500 (EST)
Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewoxu-0003Cj-Fh
	for ietf@ietf.org; Wed, 11 Jan 2006 18:01:15 -0500
Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502)
	id BF2FB37EF7; Wed, 11 Jan 2006 23:53:48 +0100 (CET)
Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net
	[81.228.8.92]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP
	id 9F35037E53; Wed, 11 Jan 2006 23:53:48 +0100 (CET)
Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com
	[81.224.201.50])
	by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 9E22437E42;
	Wed, 11 Jan 2006 23:53:47 +0100 (CET)
Received: from localhost ([127.0.0.1])
	by shiraz.levkowetz.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1Ewoqh-0004FN-00; Wed, 11 Jan 2006 23:53:47 +0100
Message-ID: <43C58C7B.3090406@levkowetz.com>
Date: Wed, 11 Jan 2006 23:53:47 +0100
From: Henrik Levkowetz 
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bob Braden 
References: <200601112102.NAA11191@gra.isi.edu>
In-Reply-To: <200601112102.NAA11191@gra.isi.edu>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on shiraz.levkowetz.com);
	SAEximRunCond expanded to false
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



on 2006-01-11 22:02 Bob Braden said the following:
>   *> From: "Brian Rosen" 
>   *> To: "'Paul Hoffman'" , 
>   *> Date: Tue, 10 Jan 2006 20:13:35 -0500
> 
> 
> 
>   *> 	The RFC editor has some problems which have not, to my knowledge,
>   *> been	enumerated.
>   *> 
> 
> Your knowledge is apparently incomplete.  The RFC Editor has been
> actively experimenting with using xml2rfc for publication, and we have
> been passing our problems along to the tools team.  As we get more
> experience, new ones show up.  There is not currently a version of
> xml2rfc that meets our needs.  Some of our editors do the major
> editing in XML, but they find it most efficient and effective to
> switch to nroff for the final cleanup of the (ASCII) document format.

This must be a different tools team than the IETF Tools-team.  We've
not seen any such feedback.  

Presumably you mean the xml2rfc maintainers?  Although in that case it's
a bit disappointing that this feedback then must have been passed along
in private, rather than on the xml2rfc mailing list - I've not noticed
such there.  

It would have been instructive to see the feedback on the list in order
to better understand what would make things easier in the RFC editing
work.


	Henrik (for the Tools team)

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 17:59:20 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewow4-0002tr-1S; Wed, 11 Jan 2006 17:59:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewow1-0002pM-GX
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 17:59:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21945
	for ; Wed, 11 Jan 2006 17:57:57 -0500 (EST)
Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewp30-0003MG-63
	for ietf@ietf.org; Wed, 11 Jan 2006 18:06:31 -0500
Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502)
	id EB5F937EE0; Wed, 11 Jan 2006 23:59:05 +0100 (CET)
Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net
	[81.228.9.102]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP
	id B6D6237E62; Wed, 11 Jan 2006 23:59:05 +0100 (CET)
Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com
	[81.224.201.50])
	by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 16D0237E43;
	Wed, 11 Jan 2006 23:59:02 +0100 (CET)
Received: from localhost ([127.0.0.1])
	by shiraz.levkowetz.com with esmtp (Exim 4.60)
	(envelope-from )
	id 1Ewovl-0004rz-Dz; Wed, 11 Jan 2006 23:59:01 +0100
Message-ID: <43C58DB5.4070301@levkowetz.com>
Date: Wed, 11 Jan 2006 23:59:01 +0100
From: Henrik Levkowetz 
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ned Freed 
References: <200601112102.NAA11191@gra.isi.edu>
	<01LXN459XW5K00009C@mauve.mrochek.com>
In-Reply-To: <01LXN459XW5K00009C@mauve.mrochek.com>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on shiraz.levkowetz.com);
	SAEximRunCond expanded to false
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: Bob Braden , ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



on 2006-01-11 23:00 Ned Freed said the following:
>>   *> From: "Brian Rosen" 
>>   *> To: "'Paul Hoffman'" , 
>>   *> Date: Tue, 10 Jan 2006 20:13:35 -0500
> 
> 
> 
>>   *> 	The RFC editor has some problems which have not, to my knowledge,
>>   *> been	enumerated.
>>   *>
> 
>> Your knowledge is apparently incomplete.  The RFC Editor has been
>> actively experimenting with using xml2rfc for publication, and we have
>> been passing our problems along to the tools team.  As we get more
>> experience, new ones show up.  There is not currently a version of
>> xml2rfc that meets our needs.  Some of our editors do the major
>> editing in XML, but they find it most efficient and effective to
>> switch to nroff for the final cleanup of the (ASCII) document format.
> 
> Rather than sending such suggestions to the IETF tools team, why not bring them
> up on the xml2rfc list? Given that I don't see names like "Charles Levert" and
> "Julian Reschke" and "Marshall Rose" on the current tools team list, I'm a
> little concerned that certain things might be lost in process of getting them
> from the tools team to the actual xml2rfc tool maintainers.

I fully agree.  Comments should go to the xml2rfc list.  And as a matter of
fact, the tools team has not received any feedback or comments from the
RFC-Editor regarding the xml2rfc tool.  If we had, we would have forwarded it
to the xml2rfc list.


	Henrik

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 18:32:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwpS1-0004lG-3W; Wed, 11 Jan 2006 18:32:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwpRz-0004jm-88
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 18:32:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24221
	for ; Wed, 11 Jan 2006 18:30:59 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwpYu-0004QA-VQ
	for ietf@ietf.org; Wed, 11 Jan 2006 18:39:30 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LXN756FGQ8001W3G@mauve.mrochek.com> for
	ietf@ietf.org; Wed, 11 Jan 2006 15:32:05 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1137022324;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=lCJYGgIUuKpvs70hgdNm2gfCb
	XHo8z9StHKrGFPZjis43qChErxY9DOqumugIIv1q0LkKcFWNJ8crIcbFW4cQw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LXN1TUJKXC00009C@mauve.mrochek.com>; Wed,
	11 Jan 2006 15:32:02 -0800 (PST)
To: Dave Crocker 
Message-id: <01LXN754WDXO00009C@mauve.mrochek.com>
Date: Wed, 11 Jan 2006 15:26:15 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Wed, 11 Jan 2006 14:53:38 -0800"
	<43C58C72.6020702@dcrocker.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <5353FF6EB5D6B446638740EE@p3.JCK.COM>
	<43C58C72.6020702@dcrocker.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: John C Klensin , Bob Braden ,
	ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> >> There is not currently a version of xml2rfc that meets our
> >> needs.

> I do not recall seeing any input from the RFC Editor, on the XML2RFC mailing
> list, citing xml2rfc's deficiencies.

> That makes it difficult to get those deficiencies fixed.

> Please, please, please. Post those deficiencies to that list.

Absolutely.

> >   The
> > issue arises from handing you a format that contains generic
> > markup and is editable but, because of your "via nroff" process,
> > requires authors to deduce substantive and editorial changes
> > from diffs and then retrofit them back into the XML for future
> > use.


> This point has been made a number of times, recently.  Its importance appears to
> remain under-appreciated.

> IETF documents are subject to revision by new editors.  They currently find it
> difficult or impossible to ensure that they are starting from the correct master
> version.

These are issues even when the editor doesn't change.

> To the extent that they must start from the .txt version, they have significant
> startup costs (with significant potential for introducing new errors) in order
> to convert the document to a format better suited to editing -- e.g., better
> able to manipulate the document's structure.

> What the IETF community needs is to be able to obtain an accurate,
> revisable-form version of published documents.  xml2rfc is the best candidate
> for that form.  We therefore need to find a way for the RFC Editor to maintain
> the master version of RFCs in that form.

While I agree that this needs to be the goal, when the RFC does use xml2rfc for
most of the editing process getting back a revised XML spec from the RFC Editor
that has all the changes made prior to the nroff step would be a HUGE
improvement. The time needed to retrofit all the RFC Editor changes into the
XML is nonnegligable - I wish I didn't epeak from recent experience, but I do.

For once let's not let the best be the enemy of the good.

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 18:53:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewpma-0002Zb-Mx; Wed, 11 Jan 2006 18:53:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwpmY-0002ZT-Mf
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 18:53:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26067
	for ; Wed, 11 Jan 2006 18:52:14 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwptV-0005Cu-Ub
	for ietf@ietf.org; Wed, 11 Jan 2006 19:00:49 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0BNrlln031913
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2006 15:53:48 -0800
Message-ID: <43C59A62.9050204@dcrocker.net>
Date: Wed, 11 Jan 2006 15:53:06 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Ned Freed 
References: <5353FF6EB5D6B446638740EE@p3.JCK.COM>
	<43C58C72.6020702@dcrocker.net>
	<01LXN754WDXO00009C@mauve.mrochek.com>
In-Reply-To: <01LXN754WDXO00009C@mauve.mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: Bob Braden , ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

  when the RFC does use
> xml2rfc for
> most of the editing process getting back a revised XML spec from the RFC 
> Editor
> that has all the changes made prior to the nroff step would be a HUGE
> improvement. The time needed to retrofit all the RFC Editor changes into 
> the
> XML is nonnegligable - I wish I didn't epeak from recent experience, but 
> I do.


Agree completely.

1. Constraining the initial requirement -- for maintaining the master in xml2rfc 
format -- to apply only to documents that are submitted to the RFC Editor in 
that format -- that is, the RFC Editor does not create a conversion, they merely 
retain the format -- strikes me as far too pragmatic to disagree with, and for 
the reason you cite.

2. Given that the RFC Editor has the current practice of converting .txt 
submissions to nroff, it is equally reasonable to pursue their changing that 
conversion, to instead be into xml2rfc.  By 'equally reasonable' I mean as a 
parallel effort, on its own schedule.  As with any transition, the folks doing 
the work need to remain productive; this requires concessions in the details of 
the transition process.

3. I believe that we should not plan to prohibit nroff submissions, for the 
foreseeable future.  I'd rather deprecate the activity by virtue of community 
preference than by imposition of a rule.

d/


-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 18:53:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewpmj-0002bh-MI; Wed, 11 Jan 2006 18:53:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewpmh-0002bH-SG
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 18:53:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26109
	for ; Wed, 11 Jan 2006 18:52:22 -0500 (EST)
Received: from a.mail.sonic.net ([64.142.16.245])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewptf-0005DE-Vs
	for ietf@ietf.org; Wed, 11 Jan 2006 19:00:57 -0500
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG
	[168.61.10.151]) (authenticated bits=0)
	by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0BNrPbR014830
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 11 Jan 2006 15:53:27 -0800
In-Reply-To: <5353FF6EB5D6B446638740EE@p3.JCK.COM>
References: <5353FF6EB5D6B446638740EE@p3.JCK.COM>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4C0BCC0B-89DB-415F-A3A9-5184D8ACE1CF@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis 
Date: Wed, 11 Jan 2006 15:54:01 -0800
To: John C Klensin 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: Bob Braden , ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 11, 2006, at 1:52 PM, John C Klensin wrote:
>
> --On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden
>  wrote:
>>
>> Your knowledge is apparently incomplete.  The RFC Editor has been  
>> actively experimenting with using xml2rfc for publication, and we  
>> have been passing our problems along to the tools team.  As we get  
>> more experience, new ones show up. There is not currently a  
>> version of xml2rfc that meets our needs.  Some of our editors do  
>> the major editing in XML, but they find it most efficient and  
>> effective to switch to nroff for the final cleanup of the (ASCII)  
>> document format.
>
> Bob,
>
> Let me suggest a way to look at the above, deriving in large  
> measure from the experiences Ned Freed and I (mostly Ned, who did  
> the heavy lifting) had with what are now RFCs 4288 and 4289. To the  
> extent to which authors can hand XML to you, and get XML back with  
> whatever substantive/ editorial changes you have made, it should  
> ultimately not be a concern of anyone in the community how you make  
> the transition between the final XML, with all of the text worked  
> out, and the final formatting.  In particular, if that step  
> requires you to convert the XML to nroff and then massage the  
> nroff, I don't think it should be an issue.  The issue arises from  
> handing you a format that contains generic markup and is editable  
> but, because of your "via nroff" process, requires authors to  
> deduce substantive and editorial changes from diffs and then  
> retrofit them back into the XML for future
> use.

The xml2rfc tools permits injection of unformatted text using the  
following syntax:

   

     
    This text represents the desired structure (without formatting)...

    blah, blah, blah...
     blah, blah, blah, ...

        blah, blah, blah, ...
     
   


This mechanism allows authors to bypass the formatting limitations  
within the xlm2rfc tool.  As nroff is also a support input, nroff  
represents yet another method of achieving a desired output.

-Doug

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 11 20:41:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwrSY-00008t-3z; Wed, 11 Jan 2006 20:41:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwrSV-00008l-Rm
	for ietf@megatron.ietf.org; Wed, 11 Jan 2006 20:40:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03895
	for ; Wed, 11 Jan 2006 20:39:38 -0500 (EST)
Received: from tom.iecc.com ([208.31.42.38])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwrZV-0000Gy-Vw
	for ietf@ietf.org; Wed, 11 Jan 2006 20:48:15 -0500
Received: (qmail 18635 invoked from network); 12 Jan 2006 01:40:39 -0000
Received: (ofmipd 208.31.42.47); 12 Jan 2006 01:40:17 -0000
Date: 11 Jan 2006 20:40:40 -0500
Message-ID: <20060111204006.V6924@simone.iecc.com>
From: "John L" 
To: ietf@ietf.org
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Subject: Venue for Dallas IETF ?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Do we know where the meeting will be yet?  I see that registration was 
supposed to start today.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 06:07:11 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex0IQ-0002vo-VK; Thu, 12 Jan 2006 06:07:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex0IO-0002vT-Sq
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 06:07:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09630
	for ; Thu, 12 Jan 2006 06:05:48 -0500 (EST)
Received: from mtagate4.uk.ibm.com ([195.212.29.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex0PT-0008VR-VA
	for ietf@ietf.org; Thu, 12 Jan 2006 06:14:29 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0CB6vfw210254
	for ; Thu, 12 Jan 2006 11:06:58 GMT
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com
	[9.149.37.213])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0CB6ark233398 for ; Thu, 12 Jan 2006 11:06:36 GMT
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0CB6arc005302 for ; Thu, 12 Jan 2006 11:06:36 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0CB6a70005293; Thu, 12 Jan 2006 11:06:36 GMT
Received: from zurich.ibm.com (sig-9-145-130-120.de.ibm.com [9.145.130.120])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA83036;
	Thu, 12 Jan 2006 12:06:35 +0100
Message-ID: <43C63836.9080006@zurich.ibm.com>
Date: Thu, 12 Jan 2006 12:06:30 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: John L 
References: <20060111204006.V6924@simone.iecc.com>
In-Reply-To: <20060111204006.V6924@simone.iecc.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Venue for Dallas IETF ?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John L wrote:
> Do we know where the meeting will be yet?  I see that registration was 
> supposed to start today.

I believe it will start in another couple of days.

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 06:19:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex0Uc-0006Zu-Iv; Thu, 12 Jan 2006 06:19:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex0Ua-0006Zc-NS
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 06:19:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10220
	for ; Thu, 12 Jan 2006 06:18:24 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex0bf-0000M3-Vb
	for ietf@ietf.org; Thu, 12 Jan 2006 06:27:05 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 12 Jan 2006 12:19:34 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0CBJVgT022566; 
	Thu, 12 Jan 2006 12:19:32 +0100 (MET)
Received: from [10.61.80.215] (ams-clip-vpn-dhcp4312.cisco.com [10.61.80.215])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA11262;
	Thu, 12 Jan 2006 11:19:31 GMT
Message-ID: <43C63B42.1070504@cisco.com>
Date: Thu, 12 Jan 2006 11:19:30 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bob Braden 
References: <200601111930.LAA11029@gra.isi.edu>
In-Reply-To: <200601111930.LAA11029@gra.isi.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bob Braden wrote:

> 
>  *> The draft has expired so I need to point to an external version. This draft
>  *> which is looking at the properties of a routing network under conditions of
>  *> failure would have been much clearer if it could have used mathematical
>  *> notation rather than ASCIIised equations
>  *> 
>  *> http://www.faqs.org/ftp/pub/internet-drafts/draft-atlas-ip-local-protect-uturn-02.txt
>  *> 
>  *> Of course the diagrams could have also been clearer, as is seen by
>  *> comparing them to the ones that Alia used in her presentatons on the
>  *> subject.
>  *> 
>  *> - Stewart
>  *> 
>
>Stewart,
>
>I just looked over this document, and it actually seems to me to
>support the "ASCII art and equations are [just] enough to serve the
>explanatory purpose" school of thought.
>  
>
However the versions of this work that are published without the 72
char ASCII constraint are MUCH easier to read and understand. You
need to consider how much attention it reasonable to direct towards
understanding the notation and how much towards understanding the
technology. You may gather that I think that all the concentration
should be directed at the technology.

Also if this is JUST, then we are clearly working on the limit,
i.e. what we do to "make the Internet work better" risks being
limited by our ability to describe to each other the problems
and solutions. Indeed we cannot be sure that we are not
already in that limiting state.

>I really do not see that it would be "much clearer if it could have
>used mathemtical notation".  As experienced programmers, we are
>used to reading linearized formulas, aren't we?  And these particular
>formulas seem quite simple.
>  
>
If linearised formulas were a good idea mathematicians would use them :)
Translation to ASCII representation should surely be the final step in
implementation not something imposed during the understanding and
description phase.

>Note that if and when this document is published as an RFC, the RFC
>Editor will supply some additional blank lines and clean up the
>indentation, which will make the equations much easier to read.  Also,
>as you note, the ASCII art diagrams could really use a cleanup.  They
>are unnecessarily ugly, kind of dyslexic.
>  
>
The non-ASCII versions presented at the RTGWG looked fine.

>It is true that the discipline of ASCII art forces the author to give
>some thought to the clarity and modularity of the text.  Opinions
>differ on whether this is a good thing or a bad thing.
>
>  
>
Indeed, or whether as to whether it enhances of detracts from out ability
to do the right thing for the Internet.

- Stewart

>  
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 06:27:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex0bt-0007wT-Mo; Thu, 12 Jan 2006 06:27:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex0br-0007sy-1S
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 06:27:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10647
	for ; Thu, 12 Jan 2006 06:25:54 -0500 (EST)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex0iq-0000Yt-5Q
	for ietf@ietf.org; Thu, 12 Jan 2006 06:34:35 -0500
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	B48654F0009; Thu, 12 Jan 2006 12:26:48 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 12 Jan 2006 12:26:48 +0100
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 12 Jan 2006 12:26:48 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Jan 2006 12:28:22 +0100
Message-ID: <026F8EEDAD2C4342A993203088C1FC05021D1564@esealmw109.eemea.ericsson.se>
Thread-Topic: PDF, Postscript,
	and "normative" versions (was: Re: Baby Steps (was RE:
	Alternative formats for IDs))
Thread-Index: AcYSMvm8/JZMVdA/T1matJMr3jV9CgFN1mUA
From: "Lars-Erik Jonsson \(LU/EAB\)" 
To: "John C Klensin" , "Stewart Bryant" 
X-OriginalArrivalTime: 12 Jan 2006 11:26:48.0533 (UTC)
	FILETIME=[13A7A050:01C6176B]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \\\\\(Jerry\\\\\)" , ietf@ietf.org
Subject: RE: PDF, Postscript,
	and "normative" versions (was: Re: Baby Steps (was RE: Alternative
	formats for IDs))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Before I go on, I continue to be fascinated by the observation
> that, each time the "we really need pictures and fancy
> formatting and need them frequently" argument comes up, the vast
> majority of those who make it most strongly are people whose
> contributions to the IETF -- in designer, editor, or other
> leadership roles-- have been fairly minimal. =20

This fascinates me too...

With experience, I believe most people learn that the strict
ASCII format used for RFC's is actually a strong feature of=20
our ways of working. When I wrote my first drafts, I also
believed non-ASCII graphics were needed and I made multiple
versions (one TXT and one PS) of each draft, but I do not
waste my time on that anymore since I have learned that I
can manage very well without non-ASCII graphics.

/L-E

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 08:50:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex2qX-00033x-Cw; Thu, 12 Jan 2006 08:50:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex2qV-00032d-CY
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 08:50:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18399
	for ; Thu, 12 Jan 2006 08:49:10 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.207])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex2xc-0004PA-3z
	for ietf@ietf.org; Thu, 12 Jan 2006 08:57:53 -0500
Received: by zproxy.gmail.com with SMTP id k1so404407nzf
	for ; Thu, 12 Jan 2006 05:50:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=sqkdyOnL2OJ21nFoikhA3z4WNP/MvT8mLoNHGDPpWXaokYXrleRIV9AdAhP2ry9k6Pm6dig8jE/8uqgHB2ZsE5Z2mOusdhjZi78QclHrh8d2H+ZC6p31Wy8CwhhlCxy0rMPXGhCn+rjfAw9xARv5nKh29BVw3cWK3jXAyzPo9JU=
Received: by 10.65.153.18 with SMTP id f18mr688318qbo;
	Thu, 12 Jan 2006 05:50:26 -0800 (PST)
Received: by 10.64.193.12 with HTTP; Thu, 12 Jan 2006 05:50:26 -0800 (PST)
Message-ID: 
Date: Thu, 12 Jan 2006 08:50:26 -0500
From: Bill Fenner 
To: Henrik Levkowetz 
In-Reply-To: <43C58DB5.4070301@levkowetz.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <200601112102.NAA11191@gra.isi.edu>
	<01LXN459XW5K00009C@mauve.mrochek.com>
	<43C58DB5.4070301@levkowetz.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: quoted-printable
Cc: Bob Braden , Ned Freed ,
	ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 1/11/06, Henrik Levkowetz  wrote:
>  the tools team has not received any feedback or comments from the
> RFC-Editor regarding the xml2rfc tool.  If we had, we would have forwarde=
d it
> to the xml2rfc list.

Aaron (for the RFC Editor) asked me to proxy their findings, and I
worked with Charles and Marshall directly instead of going through the
list; perhaps this was a mistake.

The comments from the RFC Editor can be found at
http://rtg.ietf.org/Members/BillFenner/rfced-xml/FrontPage/issuetracker,
and many of them are fixed in xml2rfc 1.31a4.

  Bill

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 09:26:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex3PT-0003uV-7m; Thu, 12 Jan 2006 09:26:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex3PQ-0003uQ-FX
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 09:26:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20842
	for ; Thu, 12 Jan 2006 09:25:14 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex3WX-0005WC-Am
	for ietf@ietf.org; Thu, 12 Jan 2006 09:33:58 -0500
Received: by zproxy.gmail.com with SMTP id q3so403509nzb
	for ; Thu, 12 Jan 2006 06:26:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=cx6Fq4gsVmy03fkt1BY/9NhQzNP6kBh37EBL8SGd13vuLy55L/uq//uXYkO2A1J1GEinclmBWukMFZFI8ak7lgsVrDn+OTcrvj3OM6NK8De+dku6zcQrarE0sBtHSjdEX7SlLOOQbvJG+CphjP41GKUMsWPNTCj49LBajkOIVI8=
Received: by 10.65.233.8 with SMTP id k8mr710353qbr;
	Thu, 12 Jan 2006 06:26:34 -0800 (PST)
Received: by 10.64.193.12 with HTTP; Thu, 12 Jan 2006 06:26:34 -0800 (PST)
Message-ID: 
Date: Thu, 12 Jan 2006 09:26:34 -0500
From: Bill Fenner 
To: Paul Hoffman 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <01f601c615f4$89f77fa0$640fa8c0@cis.neustar.com>
	
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 1/10/06, Paul Hoffman  wrote:
> At 9:45 AM -0500 1/10/06, Brian Rosen wrote:
> >Do you have any idea how painful it is to build any kind of product that=
 has
> >good management simply because there is no library of MIBs, with referen=
ces
> >to documents?  There isn't even a LIST of IETF MIBs.  You can't figure o=
ut
> >if a document has a MIB unless you actually look at the text (although m=
any
> >have a big hint in the title of the document).  So yes, I believe better=
 MIB
> >tools would lead to better products, although it would be hard to prove =
it.
>
> Why does this need to be done in the RFCs or Internet Drafts
> themselves? Why, for example, can't a human with a bit of training
> extract all the MIBs from the current RFCs and put them into a
> repository that is machine-accessible?

Something like http://www.icir.org/fenner/mibs/mib-index.html and
http://www.icir.org/fenner/mibs/extracted/ ?

  Bill

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 09:42:19 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex3ec-0008NL-UT; Thu, 12 Jan 2006 09:42:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex3eb-0008NG-1N
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 09:42:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21825
	for ; Thu, 12 Jan 2006 09:40:55 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex3li-0005yc-4s
	for ietf@ietf.org; Thu, 12 Jan 2006 09:49:39 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150])
	by ams-iport-1.cisco.com with ESMTP; 12 Jan 2006 15:42:03 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0CEfxgT017311; 
	Thu, 12 Jan 2006 15:42:00 +0100 (MET)
Received: from [10.61.80.215] (ams-clip-vpn-dhcp4312.cisco.com [10.61.80.215])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA00500;
	Thu, 12 Jan 2006 14:41:58 GMT
Message-ID: <43C66AB6.8020601@cisco.com>
Date: Thu, 12 Jan 2006 14:41:58 +0000
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Lars-Erik Jonsson (LU/EAB)" 
References: <026F8EEDAD2C4342A993203088C1FC05021D1564@esealmw109.eemea.ericsson.se>
In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05021D1564@esealmw109.eemea.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: John C Klensin , "Ash,
	Gerald R \\\\\(Jerry\\\\\)" , ietf@ietf.org
Subject: Re: PDF, Postscript, and "normative" versions (was: Re: Baby Steps
 (was RE: Alternative	formats for IDs))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Lars-Erik Jonsson (LU/EAB) wrote:

>>Before I go on, I continue to be fascinated by the observation
>>that, each time the "we really need pictures and fancy
>>formatting and need them frequently" argument comes up, the vast
>>majority of those who make it most strongly are people whose
>>contributions to the IETF -- in designer, editor, or other
>>leadership roles-- have been fairly minimal.  
>>    
>>
>
>This fascinates me too...
>  
>
That is a completly inapproriate response to the issue at hand
- in many dimensions.

- Stewart


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 11:40:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex5VT-0000eC-U7; Thu, 12 Jan 2006 11:40:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex5VR-0000e2-BE
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 11:40:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29721
	for ; Thu, 12 Jan 2006 11:39:34 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex5cY-0001Kr-71
	for ietf@ietf.org; Thu, 12 Jan 2006 11:48:20 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1Ex5V8-000OrP-7B; Thu, 12 Jan 2006 11:40:38 -0500
Date: Thu, 12 Jan 2006 11:40:37 -0500
From: John C Klensin 
To: "Lars-Erik Jonsson \\(LU/EAB\\)" ,
	Stewart Bryant 
Message-ID: <7F1BC59F2494C09E2865196F@p3.JCK.COM>
In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05021D1564@esealmw109.eemea.ericsson.se>
References: <026F8EEDAD2C4342A993203088C1FC05021D1564@esealmw109.
	eemea.ericsson.se>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: "Ash, Gerald R \\\\\\\\\\\(Jerry\\\\\\\\\\\)" , ietf@ietf.org
Subject: RE: PDF, Postscript, and "normative" versions (was: Re:
 Baby Steps (was RE: Alternative formats for IDs))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Thursday, 12 January, 2006 12:28 +0100 "Lars-Erik Jonsson
\\(LU/EAB\\)"  wrote:

>> Before I go on, I continue to be fascinated by the observation
>> that, each time the "we really need pictures and fancy
>> formatting and need them frequently" argument comes up, the
>> vast majority of those who make it most strongly are people
>> whose contributions to the IETF -- in designer, editor, or
>> other leadership roles-- have been fairly minimal.  
> 
> This fascinates me too...
> 
> With experience, I believe most people learn that the strict
> ASCII format used for RFC's is actually a strong feature of 
> our ways of working. When I wrote my first drafts, I also
> believed non-ASCII graphics were needed and I made multiple
> versions (one TXT and one PS) of each draft, but I do not
> waste my time on that anymore since I have learned that I
> can manage very well without non-ASCII graphics.

While I agree with you, I should stress that the authors of the
current proposal have been much more in touch with IETF work and
much more active than many of their predecessors.  We also owe
them thanks for actually preparing a proposal in I-D form rather
than simply complaining about our antiquated methods on the
mailing list.  Most of the point I was trying to make was
precisely the one you make, more appropriately, above:
increasing experience within the IETF and with our style of
developing and working on documents (not just publishing them)
tends to cause both patience and respect for the ASCII graphics
and formats to rise.  Experience from other standards bodies or
similar entities that work in different ways may or may not be a
good basis for inference.

best,
   john



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 13:33:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex7Gl-0007fP-VA; Thu, 12 Jan 2006 13:33:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex7Gj-0007fK-Sx
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 13:33:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06205
	for ; Thu, 12 Jan 2006 13:32:32 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.194])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex7Ns-0004R2-R8
	for ietf@ietf.org; Thu, 12 Jan 2006 13:41:18 -0500
Received: by zproxy.gmail.com with SMTP id l1so421244nzf
	for ; Thu, 12 Jan 2006 10:33:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=fHWBjQ8Yye1AWbR9h2SMTUBu+GL8Rf4YZngDG9Xw4lHBbd/8UINpOZllUb11GE6dziYkfrfI3btWp+odbJKnyUuI23/Yy0i00QWZQIuY3ciCWbkzUhor/tCtM52+bDXS1YBvps5sHSXED6pyPt4RMYNlL4E2KGSOFCIyb762IW8=
Received: by 10.36.4.18 with SMTP id 18mr2069816nzd;
	Thu, 12 Jan 2006 10:33:51 -0800 (PST)
Received: by 10.37.12.71 with HTTP; Thu, 12 Jan 2006 10:33:51 -0800 (PST)
Message-ID: <68fba5c50601121033n793c170as25719b4e3e0dc6db@mail.gmail.com>
Date: Thu, 12 Jan 2006 13:33:51 -0500
From: Robert Sayre 
To: John C Klensin 
In-Reply-To: <7F1BC59F2494C09E2865196F@p3.JCK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <026F8EEDAD2C4342A993203088C1FC05021D1564@esealmw109.eemea.ericsson.se>
	<7F1BC59F2494C09E2865196F@p3.JCK.COM>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \\\\\(Jerry\\\\\)" , ietf@ietf.org,
	"Lars-Erik Jonsson \(LU/EAB\)" ,
	Stewart Bryant 
Subject: Re: PDF, Postscript,
	and "normative" versions (was: Re: Baby Steps (was RE: Alternative
	formats for IDs))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 1/12/06, John C Klensin  wrote:
>
> increasing experience within the IETF and with our style of
> developing and working on documents (not just publishing them)
> tends to cause both patience and respect for the ASCII graphics
> and formats to rise.

I'm surprised folks are apologizing for the initial impression ASCII
text gives, and that people feel MS Word or PDF would represent some
sort of advance. I find both of those formats difficult to use, and my
reaction when I see a spec in PDF or MS Word is to assume the
responsible organization is clueless. The rare specification requiring
elaborate illustrations would be better as HTML with a liberal
sprinkling of fragment identifiers.

--

Robert Sayre

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 13:58:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex7es-0007Wo-TT; Thu, 12 Jan 2006 13:58:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex7eq-0007Wi-Mb
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 13:58:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08751
	for ; Thu, 12 Jan 2006 13:57:27 -0500 (EST)
Received: from htr2.enterasys.com ([63.160.138.51] ident=firewall-user)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex7lz-0005Qt-QD
	for ietf@ietf.org; Thu, 12 Jan 2006 14:06:13 -0500
Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2 [134.141.79.124])
	by htr2.enterasys.com (0.25.1/8.12.6) with ESMTP id k0CIqBPO026700
	for ; Thu, 12 Jan 2006 13:52:11 -0500 (EST)
Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by
	134.141.79.124 with InterScan Messaging Security Suite;
	Thu, 12 Jan 2006 13:58:35 -0500
Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; 
	Thu, 12 Jan 2006 13:58:35 -0500
Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by
	NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); 
	Thu, 12 Jan 2006 13:58:34 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Jan 2006 13:58:34 -0500
Message-ID: <3CFB564E055A594B82C4FE89D215656006B795@MABOSEVS2.ets.enterasys.com>
Thread-Topic: Normative figures
Thread-Index: AcYXamcvO05gI1QuQP+RFC1bTyX3kQAPt6bQ
From: "Nelson, David" 
To: 
X-OriginalArrivalTime: 12 Jan 2006 18:58:35.0031 (UTC)
	FILETIME=[3062FA70:01C617AA]
X-pstn-version: pmps:sps_win32_1_1_1c0 pase:2.8
X-pstn-levels: (C:79.5348 M:97.4817 P:95.9108 R:95.9108 S:99.9000 )
X-pstn-settings: 4 (0.2500:0.7500) p:14 m:14 C:14 r:14
X-pstn-addresses: from  forward (org good) 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: quoted-printable
Subject: RE: Normative figures
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stewart Bryant writes...

> If linearised formulas were a good idea mathematicians would use them
:)
> Translation to ASCII representation should surely be the final step in
> implementation not something imposed during the understanding and
> description phase.

If symbolic formulas were useful in protocol implementations, then
programming languages like C or C++ would accept them. IMHO, if it's
good enough for the implementation, it's good enough for the
specification.

Academic and scholarly articles often make extensive use of symbolic
mathematical expressions, because that's the language of mathematics,
and the accepted format for those publications.  I would not like to see
these formats used in protocol specifications, as a general rule.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 14:45:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex8O6-0005Ej-Dy; Thu, 12 Jan 2006 14:45:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex8O3-0005Cd-22
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 14:45:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12745
	for ; Thu, 12 Jan 2006 14:44:09 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ex8VC-00076c-IL
	for ietf@ietf.org; Thu, 12 Jan 2006 14:52:55 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-1.cisco.com with ESMTP; 12 Jan 2006 11:45:20 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0CJjKjt003242
	for ; Thu, 12 Jan 2006 11:45:20 -0800 (PST)
Received: from [212.254.247.5] (ams-clip-vpn-dhcp516.cisco.com [10.61.66.4])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0CJoV6r026921
	for ; Thu, 12 Jan 2006 11:50:32 -0800
Message-ID: <43C6B1CD.4080605@cisco.com>
Date: Thu, 12 Jan 2006 20:45:17 +0100
From: Eliot Lear 
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: ietf@ietf.org
References: <3CFB564E055A594B82C4FE89D215656006B795@MABOSEVS2.ets.enterasys.com>
In-Reply-To: <3CFB564E055A594B82C4FE89D215656006B795@MABOSEVS2.ets.enterasys.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1;  q=dns; l=40; t=1137095432; x=1137527632;
	c=nowsp; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; 
	d=cisco.com; i=lear@cisco.com; 
	z=Subject:OK=20this=20discussion=20is=20OLD!!!=20=20(was=3A=20Re=3A=20Normative=20
	figures)| From:Eliot=20Lear=20|
	Date:Thu,=2012=20Jan=202006=2020=3A45=3A17=20+0100|
	Content-Type:text/plain=3B=20charset=3DISO-8859-1|
	Content-Transfer-Encoding:7bit;
	b=BsVVCIEDqaqZ5CrgW4EW+WHf7ESsG4B0koe2nWHXncAd5kZQMqZs40y0g+tTxkA9uaIvha5x
	ZtadtvppIYDQPoUAXxZNAvpQuT1cNMLwEj0av4xphLojj/bDviVJM7EQ91LWJWqSnE+KcBeMUKY
	OdcvXvfpAbRf6Hv3BJK3/pqY=
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com;
	dkim=pass ( message from cisco.com verified; ); 
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574
Content-Transfer-Encoding: 7bit
Subject: OK this discussion is OLD!!!  (was: Re: Normative figures)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

How about a new mailing list or some such?!

Eliot

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 15:36:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ex9Bf-0001hM-Vr; Thu, 12 Jan 2006 15:36:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9Bd-0001hH-V3
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 15:36:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15950
	for ; Thu, 12 Jan 2006 15:35:24 -0500 (EST)
Received: from robin.verisign.com ([65.205.251.75])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex9Ip-000085-2S
	for ietf@ietf.org; Thu, 12 Jan 2006 15:44:11 -0500
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com
	[65.205.251.33])
	by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0CKaDRt025838;
	Thu, 12 Jan 2006 12:36:13 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by
	MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 12 Jan 2006 12:36:13 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Jan 2006 12:36:11 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD3787A6E0@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Thread-Topic: PDF, Postscript,
	and "normative" versions (was: Re: Baby Steps (was RE:
	Alternativeformats for IDs))
Thread-Index: AcYSMvm8/JZMVdA/T1matJMr3jV9CgFN1mUAAA8la3A=
From: "Hallam-Baker, Phillip" 
To: "Lars-Erik Jonsson \(LU/EAB\)" ,
	"John C Klensin" , "Stewart Bryant" 
X-OriginalArrivalTime: 12 Jan 2006 20:36:13.0083 (UTC)
	FILETIME=[D40EC6B0:01C617B7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \\\\\(Jerry\\\\\)" , ietf@ietf.org
Subject: RE: PDF, Postscript,
	and "normative" versions (was: Re: Baby Steps (was RE:
	Alternativeformats for IDs))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20
> Behalf Of Lars-Erik Jonsson (LU/EAB)

> > Before I go on, I continue to be fascinated by the=20
> observation that,=20
> > each time the "we really need pictures and fancy formatting=20
> and need=20
> > them frequently" argument comes up, the vast majority of those who=20
> > make it most strongly are people whose contributions to the=20
> IETF -- in=20
> > designer, editor, or other leadership roles-- have been fairly=20
> > minimal.
>=20
> This fascinates me too...
>=20
> With experience, I believe most people learn that the strict=20
> ASCII format used for RFC's is actually a strong feature of=20
> our ways of working. When I wrote my first drafts, I also=20
> believed non-ASCII graphics were needed and I made multiple=20
> versions (one TXT and one PS) of each draft, but I do not=20
> waste my time on that anymore since I have learned that I can=20
> manage very well without non-ASCII graphics.

As the editor of the XKMS 2.0 standard, the core document of the SAML
1.0 standard and a co-editor of WS-Security 1.0 I think I can fairly
claim to have made a significant contribution to the security protocol
field.

I think that what you see there is the result of self-selection. I think
it is rather more interesting that of the 20 or so engineers who were at
the core of the Web project but did not have a previous history of
working with the IETF I am one of the very few who is currently actively
engaged in IETF work even though most are still actively engaged in
protocol design work.

Nor is it very surprising that people who suggest that the workings of
the IETF are anything less than perfect have not found leadership
positions within it. The NOMCON process is very effective at excluding
anyone who might be a squeaky wheel.

Either the IETF will become more responsive to the community of Internet
users or it will be treated as damage and routed around. The IETF has
changed significantly in the past few years and I expect those changes
to continue and at this stage it appears to me that the first outcome is
the more likely. We still have to face the fact that the Internet does
not meet user expectations for safety, security or usability. People who
have the uncompromising attitude necessary to succeed in those areas
tend to have uncompromising attitudes with respect to  other issues that
others consider trivial and unimportant such as document formats.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 16:31:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExA2I-0002eR-0S; Thu, 12 Jan 2006 16:31:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex3C3-0000n9-TA
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 09:12:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19927
	for ; Thu, 12 Jan 2006 09:11:26 -0500 (EST)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex3J6-000582-Dr
	for ietf@ietf.org; Thu, 12 Jan 2006 09:20:09 -0500
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	440774F0009; Thu, 12 Jan 2006 15:12:32 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 12 Jan 2006 15:12:32 +0100
Received: from [147.214.237.61] ([147.214.237.61]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 12 Jan 2006 15:12:32 +0100
Message-ID: <43C66396.6040004@ericsson.com>
Date: Thu, 12 Jan 2006 15:11:34 +0100
From: Henrik Levkowetz 
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bill Fenner 
References: <200601112102.NAA11191@gra.isi.edu>	
	<01LXN459XW5K00009C@mauve.mrochek.com>	
	<43C58DB5.4070301@levkowetz.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Jan 2006 14:12:32.0030 (UTC)
	FILETIME=[3A70DBE0:01C61782]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 12 Jan 2006 16:31:07 -0500
Cc: paul.hoffman@vpnc.org, Bob Braden ,
	Ned Freed ,
	Henrik Levkowetz , ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On 2006-01-12 14:50 Bill Fenner said the following:

> Aaron (for the RFC Editor) asked me to proxy their findings, and I
> worked with Charles and Marshall directly instead of going through the
> list; perhaps this was a mistake.
> 
> The comments from the RFC Editor can be found at
> http://rtg.ietf.org/Members/BillFenner/rfced-xml/FrontPage/issuetracker,
> and many of them are fixed in xml2rfc 1.31a4.

Ah. Thank you. Good to see the issues. And in an issue tracker, even :-)


	Henrik


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 16:34:13 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExA5F-0003ao-3U; Thu, 12 Jan 2006 16:34:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExA5C-0003aV-Ny
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 16:34:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26735
	for ; Thu, 12 Jan 2006 16:32:48 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExACL-0004OP-QS
	for ietf@ietf.org; Thu, 12 Jan 2006 16:41:36 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0CLV4i14009;
	Thu, 12 Jan 2006 13:31:04 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id NAA11427;
	Thu, 12 Jan 2006 13:31:03 -0800 (PST)
Date: Thu, 12 Jan 2006 13:31:03 -0800 (PST)
Message-Id: <200601122131.NAA11427@gra.isi.edu>
To: braden@ISI.EDU, john-ietf@jck.com
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 2.2 (++)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: ietf@ietf.org
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


  *> From john-ietf@jck.com  Wed Jan 11 13:53:32 2006
  *> X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
  *> 	version=3.1.0
  *> Date: Wed, 11 Jan 2006 16:52:31 -0500
  *> From: John C Klensin 
  *> To: Bob Braden , paul.hoffman@vpnc.org, br@brianrosen.net
  *> cc: ietf@ietf.org
  *> Subject: RE: Alternative formats for IDs
  *> Content-Transfer-Encoding: 7bit
  *> X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
  *> 
  *> 
  *> 
  *> --On Wednesday, 11 January, 2006 13:02 -0800 Bob Braden
  *>  wrote:
  *> 
  *> >  *> 	The RFC editor has some problems which have not, to my
  *> > knowledge,   *> been	enumerated.
  *> >   *> 
  *> > 
  *> > Your knowledge is apparently incomplete.  The RFC Editor has
  *> > been actively experimenting with using xml2rfc for
  *> > publication, and we have been passing our problems along to
  *> > the tools team.  As we get more experience, new ones show up.
  *> > There is not currently a version of xml2rfc that meets our
  *> > needs.  Some of our editors do the major editing in XML, but

  *> Bob,
  *> 
  *> Let me suggest a way to look at the above, deriving in large
  *> measure from the experiences Ned Freed and I (mostly Ned, who
  *> did the heavy lifting) had with what are now RFCs 4288 and 4289.
  *> To the extent to which authors can hand XML to you, and get XML
  *> back with whatever substantive/ editorial changes you have made,
  *> it should ultimately not be a concern of anyone in the community
  *> how you make the transition between the final XML, with all of
  *> the text worked out, and the final formatting.  In particular,
  *> if that step requires you to convert the XML to nroff and then
  *> massage the nroff, I don't think it should be an issue.  The
  *> issue arises from handing you a format that contains generic
  *> markup and is editable but, because of your "via nroff" process,
  *> requires authors to deduce substantive and editorial changes
  *> from diffs and then retrofit them back into the XML for future
  *> use.

John,

We have thought about what you suggest, and it may be workable.
The problem with it is this: during the "AUTH48" stage, we give the
author(s) the exact final version ready for publication, for
final verification.  (There was a time when this was mostly pro forma,
but for a variety of reasons, some good and some bad, the
AUTH48 stagetoday not infrequently invovles significant changes to a
document.)  Suppose that we edit the document in XML (we are already
doing this part of the time), do a final nroffing pass to get the
format just right, and then give the author(s) the edited xml,
final .txt, and a diff file.  (We could easily do this today).
The author(s) change the .xml (or give us a patch file for us
to make the changes.)  We have to make a new nroff version and
PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME.

Now, this may not actually be too bad; most of the changes at the nroff
stage are very cosmetic, and we could use diffs and perhaps other tools
to make it quite easy.  OR, we could change the AUTH48 policy to let
the author(s) deal only with the edited xml, without the final
formatting cleanups.  We would then translate to nroff and do the
final formatting AFTER AUTH48.  (Or, we could have two stages of
AUTH48). 

Perhaps we should run some more experiments.

Bob Braden for the RFC Editor

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 16:43:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExADl-0007VX-Ne; Thu, 12 Jan 2006 16:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExADj-0007Sx-1Q
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 16:42:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28267
	for ; Thu, 12 Jan 2006 16:41:36 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExAKt-00050G-FJ
	for ietf@ietf.org; Thu, 12 Jan 2006 16:50:24 -0500
Received: (qmail invoked by alias); 12 Jan 2006 21:42:46 -0000
Received: from p508FAD67.dip0.t-ipconnect.de (EHLO [192.168.178.21])
	[80.143.173.103]
	by mail.gmx.net (mp031) with SMTP; 12 Jan 2006 22:42:46 +0100
X-Authenticated: #1915285
Message-ID: <43C6CCE6.9050706@gmx.de>
Date: Thu, 12 Jan 2006 22:40:54 +0100
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Bob Braden 
References: <200601122131.NAA11427@gra.isi.edu>
In-Reply-To: <200601122131.NAA11427@gra.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: john-ietf@jck.com, ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bob Braden wrote:
> ...
> Now, this may not actually be too bad; most of the changes at the nroff
> stage are very cosmetic, and we could use diffs and perhaps other tools
> to make it quite easy.  OR, we could change the AUTH48 policy to let
> the author(s) deal only with the edited xml, without the final
> formatting cleanups.  We would then translate to nroff and do the
> final formatting AFTER AUTH48.  (Or, we could have two stages of
> AUTH48). 
> 
> Perhaps we should run some more experiments.

I think, the latter (two stages) is clearly the best way to do that. I 
would appreciate it if this would be tried (optimally, with one of my 
documents :-).

Best regards, Julian

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 17:07:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExAbq-0001H0-MP; Thu, 12 Jan 2006 17:07:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExAbo-0001Gn-9r
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 17:07:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29807
	for ; Thu, 12 Jan 2006 17:06:30 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExAiz-0005js-6p
	for ietf@ietf.org; Thu, 12 Jan 2006 17:15:18 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0CM8AEV022195
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2006 14:08:10 -0800
Message-ID: <43C6D321.3040807@dcrocker.net>
Date: Thu, 12 Jan 2006 14:07:29 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Bob Braden 
References: <200601122131.NAA11427@gra.isi.edu>
In-Reply-To: <200601122131.NAA11427@gra.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bob,

>   Suppose that we edit the document in XML (we are already
> doing this part of the time), do a final nroffing pass to get the
> format just right, and then give the author(s) the edited xml,
> final .txt, and a diff file.  (We could easily do this today).
> The author(s) change the .xml (or give us a patch file for us
> to make the changes.)  We have to make a new nroff version and
> PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME.


This sound like quite a good approach.

d/


-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 18:08:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExBY8-0002WY-SK; Thu, 12 Jan 2006 18:08:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBY5-0002W1-6u
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 18:08:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03861
	for ; Thu, 12 Jan 2006 18:06:44 -0500 (EST)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExBfG-0007ap-PL
	for ietf@ietf.org; Thu, 12 Jan 2006 18:15:32 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170])
	by minbar.fac.cs.cmu.edu id aa22647; 12 Jan 2006 18:08 EST
Date: Thu, 12 Jan 2006 18:07:54 -0500
From: Jeffrey Hutzelman 
To: Bill Fenner , Henrik Levkowetz 
Message-ID: 
In-Reply-To: 
References: <200601112102.NAA11191@gra.isi.edu>
	<01LXN459XW5K00009C@mauve.mrochek.com>	<43C58DB5.4070301@levkowetz.com>
	
Originator-Info: login-token=Mulberry:01yCQ+FTKMs4kUb7aW+6JuhF+WdUBPWLc1mWx6/qQ=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: Bob Braden , Ned Freed ,
	ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Thursday, January 12, 2006 08:50:26 AM -0500 Bill Fenner 
 wrote:


> Aaron (for the RFC Editor) asked me to proxy their findings, and I
> worked with Charles and Marshall directly instead of going through the
> list; perhaps this was a mistake.

I don't think so.  In order to work correctly, our process requires that 
protocol design and decision-making be done in public.

It does not require that bug reports be filed in public.

-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 18:16:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExBgd-0006rp-Ld; Thu, 12 Jan 2006 18:16:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBgb-0006rk-Sx
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 18:16:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04542
	for ; Thu, 12 Jan 2006 18:15:33 -0500 (EST)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExBnl-0007vL-CC
	for ietf@ietf.org; Thu, 12 Jan 2006 18:24:20 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170])
	by minbar.fac.cs.cmu.edu id aa22653; 12 Jan 2006 18:16 EST
Date: Thu, 12 Jan 2006 18:16:26 -0500
From: Jeffrey Hutzelman 
To: dcrocker@bbiw.net, Bob Braden 
Message-ID: 
In-Reply-To: <43C6D321.3040807@dcrocker.net>
References: <200601122131.NAA11427@gra.isi.edu> <43C6D321.3040807@dcrocker.net>
Originator-Info: login-token=Mulberry:01NJztGp4EYo6A52WbZxodicsOJEW70GahERt/ahw=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Thursday, January 12, 2006 02:07:29 PM -0800 Dave Crocker 
 wrote:

> Bob,
>
>>   Suppose that we edit the document in XML (we are already
>> doing this part of the time), do a final nroffing pass to get the
>> format just right, and then give the author(s) the edited xml,
>> final .txt, and a diff file.  (We could easily do this today).
>> The author(s) change the .xml (or give us a patch file for us
>> to make the changes.)  We have to make a new nroff version and
>> PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME.
>
>
> This sound like quite a good approach.

It sounds like an awful waste of time and effort to me.

It seems like the more efficient approach would be to essentially have two 
stages, where the authors first sign off on the result of copy-editing, and 
then on whatever cosmetic changes are needed after the final conversion.

In the few cases where I've had the chance to observe the AUTH48 process on 
a large, complex document (mostly as a WG chair), the majority of issues 
have been related to changes in wording the authors were unhappy with, 
missed spelling errors, etc.  If these issues were resolved using only the 
XML and the output of xml2rfc, with the nroff and final text not being 
generated until the authors were happy with the copy, I'd bet that 95% of 
documents would result in no additional comments from the author based on 
the final text.

-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 18:25:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExBon-0001Hg-F1; Thu, 12 Jan 2006 18:25:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBol-0001HP-6Q
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 18:25:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05120
	for ; Thu, 12 Jan 2006 18:23:58 -0500 (EST)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExBvq-0008D8-A7
	for ietf@ietf.org; Thu, 12 Jan 2006 18:32:45 -0500
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DDEB3907; 
	Fri, 13 Jan 2006 00:25:07 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 13 Jan 2006 00:25:07 +0100
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 13 Jan 2006 00:25:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Jan 2006 00:25:06 +0100
Message-ID: <026F8EEDAD2C4342A993203088C1FC05021D176C@esealmw109.eemea.ericsson.se>
Thread-Topic: PDF, Postscript,
	and "normative" versions (was: Re: Baby Steps (was RE:
	Alternative formats for IDs))
Thread-Index: AcYXlu346dFk0xYwTcilb7+q1EJTfAANl7cw
From: "Lars-Erik Jonsson \(LU/EAB\)" 
To: "John C Klensin" , "Stewart Bryant" 
X-OriginalArrivalTime: 12 Jan 2006 23:25:07.0458 (UTC)
	FILETIME=[6C9DAE20:01C617CF]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \\\\\\\\\\\(Jerry\\\\\\\\\\\)" , ietf@ietf.org
Subject: RE: PDF, Postscript,
	and "normative" versions (was: Re: Baby Steps (was RE: Alternative
	formats for IDs))
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John, Stewart and others,

I believe some might have taken my previous note more
personally than intended, as well as John's. As also
made clear by John below, we both looked at this with
a significantly longer time-perspective than just the
last weeks or months, as these issues have been brought
up many times before. I am sorry if someone felt
insulted, that was for sure not the intent.

It is good that we now have discussions trying to figure
out actual cases when more graphics are *really* needed,
then we might actually get out of these discussions with
some new conclusions and agreements that can guide us on
the way forward.

Cheers,
/L-E


----Original Message----
From: John C Klensin [mailto:john-ietf@jck.com]
Sent: den 12 januari 2006 17:41
To: Lars-Erik Jonsson (LU/EAB); Stewart Bryant
Cc: Ash, Gerald R \\\\\(Jerry\\\\\); ietf@ietf.org
Subject: RE: PDF, Postscript, and "normative" versions (was:
Re: Baby Steps (was RE: Alternative formats for IDs))

> --On Thursday, 12 January, 2006 12:28 +0100 "Lars-Erik Jonsson
> \\(LU/EAB\\)"  wrote:
>=20
>>> Before I go on, I continue to be fascinated by the observation
>>> that, each time the "we really need pictures and fancy
>>> formatting and need them frequently" argument comes up, the
>>> vast majority of those who make it most strongly are people
>>> whose contributions to the IETF -- in designer, editor, or
>>> other leadership roles-- have been fairly minimal.
>>=20
>> This fascinates me too...
>>=20
>> With experience, I believe most people learn that the strict
>> ASCII format used for RFC's is actually a strong feature of
>> our ways of working. When I wrote my first drafts, I also
>> believed non-ASCII graphics were needed and I made multiple
>> versions (one TXT and one PS) of each draft, but I do not
>> waste my time on that anymore since I have learned that I
>> can manage very well without non-ASCII graphics.
>=20
> While I agree with you, I should stress that the authors of the
> current proposal have been much more in touch with IETF work and
> much more active than many of their predecessors.  We also owe
> them thanks for actually preparing a proposal in I-D form rather
> than simply complaining about our antiquated methods on the
> mailing list.  Most of the point I was trying to make was
> precisely the one you make, more appropriately, above:
> increasing experience within the IETF and with our style of
> developing and working on documents (not just publishing them)
> tends to cause both patience and respect for the ASCII graphics
> and formats to rise.  Experience from other standards bodies or
> similar entities that work in different ways may or may not be a good
> basis for inference.=20
>=20
> best,
>    john

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 18:31:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExBuH-0002Nz-Bq; Thu, 12 Jan 2006 18:31:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBuG-0002Nu-3s
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 18:31:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05566
	for ; Thu, 12 Jan 2006 18:29:39 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExC1R-0008PP-DZ
	for ietf@ietf.org; Thu, 12 Jan 2006 18:38:26 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0CNQHi26824;
	Thu, 12 Jan 2006 15:26:17 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id PAA11534;
	Thu, 12 Jan 2006 15:26:16 -0800 (PST)
Date: Thu, 12 Jan 2006 15:26:16 -0800 (PST)
Message-Id: <200601122326.PAA11534@gra.isi.edu>
To: braden@ISI.EDU, ietf@ietf.org
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: 
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Who is volunteering to maintain xml2rfc and guarantee backwards
compatibility for the next 20 years?  (And why should
we believe them?)

Bob Braden

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 18:45:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExC83-0007Q6-Fo; Thu, 12 Jan 2006 18:45:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExC81-0007On-PF
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 18:45:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06609
	for ; Thu, 12 Jan 2006 18:43:53 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExCFD-0000Rn-Gx
	for ietf@ietf.org; Thu, 12 Jan 2006 18:52:40 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0CNaQi00800;
	Thu, 12 Jan 2006 15:36:26 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id PAA11557;
	Thu, 12 Jan 2006 15:36:26 -0800 (PST)
Date: Thu, 12 Jan 2006 15:36:26 -0800 (PST)
Message-Id: <200601122336.PAA11557@gra.isi.edu>
To: ned.freed@mrochek.com, dcrocker@bbiw.net
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: braden@ISI.EDU, ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


  *> 
  *> 2. Given that the RFC Editor has the current practice of converting .txt 
  *> submissions to nroff, it is equally reasonable to pursue their changing that 
  *> conversion, to instead be into xml2rfc.

Dave,

Are you suggesting that the IETF adopt the xml2rfc source as the
normative version of a specification, rather than the .txt (or .pdf)
version?

Bob Braden

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 19:23:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExCih-0006rg-Us; Thu, 12 Jan 2006 19:23:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCif-0006oE-Nd
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 19:23:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12444
	for ; Thu, 12 Jan 2006 19:21:44 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExCps-0002si-Ph
	for ietf@ietf.org; Thu, 12 Jan 2006 19:30:33 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0D0NZ5v006915
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2006 16:23:35 -0800
Message-ID: <43C6F2DD.4040108@bbiw.net>
Date: Thu, 12 Jan 2006 16:22:53 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Bob Braden 
References: <200601122336.PAA11557@gra.isi.edu>
In-Reply-To: <200601122336.PAA11557@gra.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dcrocker@bbiw.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org




> Are you suggesting that the IETF adopt the xml2rfc source as the
> normative version of a specification, rather than the .txt (or .pdf)
> version?

yes.

as I understand your current operation, the *real* normative version is in nroff.

i believe that an incremental process of switching to xml2rfc -- with easy 
access to that source version for follow-on editing -- would be a considerable 
improvement over the status quo.



 > Who is volunteering to maintain xml2rfc and guarantee backwards
 > compatibility for the next 20 years?  (And why should
 > we believe them?)

Maintaining xml2rfc is going to far less fragile than maintaining nroff.  Nroff 
has no current industry penetration.  XML has quite a lot.

(Both are textual encodings, so that the fall-back position of reverting to pure 
text is probably equally painful.)


d/
-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 20:28:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExDjU-00047G-Nx; Thu, 12 Jan 2006 20:28:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExDjS-00047B-RO
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 20:27:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16765
	for ; Thu, 12 Jan 2006 20:26:37 -0500 (EST)
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExDqf-0004xP-Kx
	for ietf@ietf.org; Thu, 12 Jan 2006 20:35:26 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id D5009FB28A;
	Fri, 13 Jan 2006 01:27:45 +0000 (UTC)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id 8AB583C0207;
	Thu, 12 Jan 2006 20:27:44 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: Jeffrey Hutzelman 
In-Reply-To: (Your message of "Thu, 12 Jan 2006 18:16:26 EST.")
	 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 12 Jan 2006 20:27:44 -0500
Message-Id: <20060113012744.8AB583C0207@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: Bob Braden , dcrocker@bbiw.net, ietf@ietf.org
Subject: Re: Alternative formats for IDs 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In message , Jeffrey Hutzelman 
writes:
>

>
>It seems like the more efficient approach would be to essentially have two 
>stages, where the authors first sign off on the result of copy-editing, and 
>then on whatever cosmetic changes are needed after the final conversion.
>
That assumes that the xml->nroff conversion is always error-free.  I 
think that that's an overassumption.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 20:46:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExE1C-0000pm-OR; Thu, 12 Jan 2006 20:46:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExE18-0000ph-JA
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 20:46:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18253
	for ; Thu, 12 Jan 2006 20:44:53 -0500 (EST)
Received: from shu.cs.utk.edu ([160.36.56.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExE8L-0005dh-CO
	for ietf@ietf.org; Thu, 12 Jan 2006 20:53:42 -0500
Received: from localhost (shu [127.0.0.1])
	by shu.cs.utk.edu (Postfix) with ESMTP id E224A13B42;
	Thu, 12 Jan 2006 20:46:09 -0500 (EST)
Received: from shu.cs.utk.edu ([127.0.0.1])
	by localhost (shu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 32424-09; Thu, 12 Jan 2006 20:46:08 -0500 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by shu.cs.utk.edu (Postfix) with ESMTP id 5A76313B39;
	Thu, 12 Jan 2006 20:46:08 -0500 (EST)
Date: Thu, 12 Jan 2006 20:46:07 -0500
From: Keith Moore 
To: "Steven M. Bellovin" 
Message-Id: <20060112204607.4845ba3e.moore@cs.utk.edu>
In-Reply-To: <20060113012744.8AB583C0207@berkshire.machshav.com>
References: 
	<20060113012744.8AB583C0207@berkshire.machshav.com>
X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Cc: braden@ISI.EDU, ietf@ietf.org, dcrocker@bbiw.net
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> >It seems like the more efficient approach would be to essentially have two 
> >stages, where the authors first sign off on the result of copy-editing, and 
> >then on whatever cosmetic changes are needed after the final conversion.
> >
> That assumes that the xml->nroff conversion is always error-free.  I 
> think that that's an overassumption.

I've seen several cases where "cosmetic changes" introduced technical errors
in a document.

Keith

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 20:55:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExE9y-0004Yq-BP; Thu, 12 Jan 2006 20:55:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExE9w-0004VQ-7Z
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 20:55:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18926
	for ; Thu, 12 Jan 2006 20:53:58 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExEH9-0005yX-4x
	for ietf@ietf.org; Thu, 12 Jan 2006 21:02:48 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0D1sYi16362;
	Thu, 12 Jan 2006 17:54:34 -0800 (PST)
Received: (from faber@localhost)
	by hut.isi.edu (8.13.4/8.13.4/Submit) id k0D1sYtP012887;
	Thu, 12 Jan 2006 17:54:34 -0800 (PST) (envelope-from faber)
Date: Thu, 12 Jan 2006 17:54:34 -0800
From: Ted Faber 
To: Dave Crocker 
Message-ID: <20060113015434.GD1391@hut.isi.edu>
References: <200601122336.PAA11557@gra.isi.edu> <43C6F2DD.4040108@bbiw.net>
Mime-Version: 1.0
In-Reply-To: <43C6F2DD.4040108@bbiw.net>
User-Agent: Mutt/1.4.2.1i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: Bob Braden , ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1171593681=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============1171593681==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="Q0rSlbzrZN6k9QnT"
Content-Disposition: inline


--Q0rSlbzrZN6k9QnT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 12, 2006 at 04:22:53PM -0800, Dave Crocker wrote:
> Maintaining xml2rfc is going to far less fragile than maintaining nroff. =
=20
> Nroff has no current industry penetration.  XML has quite a lot.

I'd be cautious here.

Equating the XML communities and the xml2rfc communities is not correct.

There's an important distinction between the XML meta-language and the
xml2rfc language and its associated formatting tools.  Lots of places
express languages in XML DTDs and use one of the many XML parsers in
their tools to parse those DTDs.  That widespread adoption of the
meta-language and the resultant support for XML parsing libraries in a
large number of implementation languages and environments does simplify
the specification of the xml2rfc language and the generation and
maintenance of the xml2rfc program.  However, the actual community of
that uses the XML-based RFC authoring tools is a subset of the
contributors to the IETF; the maintainers of the xml2rfc formatter(s)
are a subset of that.  That smaller community is the one that is needed
to keep a working xml2rfc language and formatting program available to
the IETF.

It's by no means obvious to me that xml2rfc has reached a critical mass
of developers and users, nor that it will necessarily do so organically.
A financial IETF commitment to the system might mitigate that problem,
though I recognize the trolls under *that* bridge.  (Please do not take
this is not a slap at the rfc2xml developers.  I use the program and I
like the program.)

All that said, I do think that an XML-based encoding of RFC contents is
a good idea (seriously - that's not just lip service), but let's assess
the situation with open eyes.  If we're talking about changing formats
from ASCII -> rfc2xml, Bob's concerns about the long-term viability of
the xml2rfc formatting program(s) do need to be addressed, and the
assertion that there's a lot of interest and activity in XML doesn't do
so adequately.  IMHO.

--=20
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.=
asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#=
SIG

--Q0rSlbzrZN6k9QnT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDxwhaaUz3f+Zf+XsRAmPiAJ0RreeLQqye9TmebFY0G6pmx/T1+wCeLoLV
IuvLqqla4dh4ptIXX/eR5Ls=
=cSFq
-----END PGP SIGNATURE-----

--Q0rSlbzrZN6k9QnT--


--===============1171593681==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1171593681==--




From ietf-bounces@ietf.org Thu Jan 12 21:04:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExEIQ-0006dx-HD; Thu, 12 Jan 2006 21:04:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExEIO-0006ds-Up
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 21:04:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19483
	for ; Thu, 12 Jan 2006 21:02:43 -0500 (EST)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExEPb-0006Fj-R4
	for ietf@ietf.org; Thu, 12 Jan 2006 21:11:33 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170])
	by minbar.fac.cs.cmu.edu id aa22768; 12 Jan 2006 21:03 EST
Date: Thu, 12 Jan 2006 21:03:11 -0500
From: Jeffrey Hutzelman 
To: "Steven M. Bellovin" 
Message-ID: <9D8F4178A4D4BFD2A620CC6B@sirius.fac.cs.cmu.edu>
In-Reply-To: <20060113012744.8AB583C0207@berkshire.machshav.com>
References: <20060113012744.8AB583C0207@berkshire.machshav.com>
Originator-Info: login-token=Mulberry:01x/ksyjFhoT4TRKRL+ndcOV5rY/VOLaU0blov/Xk=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: Bob Braden , dcrocker@bbiw.net, ietf@ietf.org
Subject: Re: Alternative formats for IDs 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Thursday, January 12, 2006 08:27:44 PM -0500 "Steven M. Bellovin" 
 wrote:

> In message , Jeffrey
> Hutzelman  writes:
>>
>
>>
>> It seems like the more efficient approach would be to essentially have
>> two  stages, where the authors first sign off on the result of
>> copy-editing, and  then on whatever cosmetic changes are needed after
>> the final conversion.
>>
> That assumes that the xml->nroff conversion is always error-free.  I
> think that that's an overassumption.

I don't think it makes that assumption.  It assumes that the conversion
is usually error-free with respect to content, and thus that the vast
majority of problems will be discovered in the first phase, when any
corrections can be incorporated into XML that will then hopefully be 
available when the time comes to work on the next protocol version.

Of course, any changes introduced in the XML->nroff conversion would have 
to be corrected, which is why the authors would still need to sign off
on the final published text.

-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 22:18:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExFSp-0005jx-He; Thu, 12 Jan 2006 22:18:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExFSn-0005js-8a
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 22:18:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24039
	for ; Thu, 12 Jan 2006 22:17:31 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.193])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExFa0-00005e-Uv
	for ietf@ietf.org; Thu, 12 Jan 2006 22:26:22 -0500
Received: by zproxy.gmail.com with SMTP id l8so570566nzf
	for ; Thu, 12 Jan 2006 19:18:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=iQiv/kwIitxJG479WRxUWfHxfv+14rMtEFg9+ezsGde6WitgaSCLrSv9PvJwusUSt3rLy6YbmryMuQPLe93jkhm9BGhXHI+d3E1VExAg1mlZGibYxu/GCQQj66FD0Mcb+16Sv9lSatBDYm1D81jS+T0DzTgaP2/69MJkMM1XC+A=
Received: by 10.65.186.11 with SMTP id n11mr1586449qbp;
	Thu, 12 Jan 2006 19:18:50 -0800 (PST)
Received: by 10.64.193.12 with HTTP; Thu, 12 Jan 2006 19:18:50 -0800 (PST)
Message-ID: 
Date: Thu, 12 Jan 2006 22:18:50 -0500
From: Bill Fenner 
To: dcrocker@bbiw.net
In-Reply-To: <43C59A62.9050204@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <5353FF6EB5D6B446638740EE@p3.JCK.COM>
	<43C58C72.6020702@dcrocker.net> <01LXN754WDXO00009C@mauve.mrochek.com>
	<43C59A62.9050204@dcrocker.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: quoted-printable
Cc: Bob Braden , Ned Freed ,
	ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 1/11/06, Dave Crocker  wrote:
> 2. Given that the RFC Editor has the current practice of converting .txt
> submissions to nroff, it is equally reasonable to pursue their changing t=
hat
> conversion, to instead be into xml2rfc.

I don't think that converting to xml is the same class of work.=20
There's a great deal of semantic information that should be encoded in
the XML that isn't in the submitted text and doesn't have to be in the
nroff.

  Bill

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 12 22:26:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExFa1-0008E8-Lw; Thu, 12 Jan 2006 22:26:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExFZz-0008Db-A4
	for ietf@megatron.ietf.org; Thu, 12 Jan 2006 22:26:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24637
	for ; Thu, 12 Jan 2006 22:24:56 -0500 (EST)
Received: from newdev.eecs.harvard.edu ([140.247.60.212]
	helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ExFhC-0000MQ-FV
	for ietf@ietf.org; Thu, 12 Jan 2006 22:33:47 -0500
Received: by newdev.harvard.edu (Postfix, from userid 501)
	id 5CD57608A3D; Thu, 12 Jan 2006 22:26:06 -0500 (EST)
To: ietf@ietf.org
Message-Id: <20060113032606.5CD57608A3D@newdev.harvard.edu>
Date: Thu, 12 Jan 2006 22:26:06 -0500 (EST)
From: sob@harvard.edu (Scott Bradner)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Dave sed:
> Nroff has no current industry penetration.

fwiw - Nroff is on every Mac OSX shipped

it is a shell procedure that fronts groff

Scott

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 00:44:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExHjh-0000wB-L7; Fri, 13 Jan 2006 00:44:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExHje-0000rI-KB
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 00:44:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02382
	for ; Fri, 13 Jan 2006 00:43:05 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExHqt-0004GO-0U
	for ietf@ietf.org; Fri, 13 Jan 2006 00:51:56 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0D5ilgf010611
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2006 21:44:47 -0800
Message-ID: <43C73E25.1050601@bbiw.net>
Date: Thu, 12 Jan 2006 21:44:05 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Bill Fenner 
References: <5353FF6EB5D6B446638740EE@p3.JCK.COM>	
	<43C58C72.6020702@dcrocker.net>
	<01LXN754WDXO00009C@mauve.mrochek.com>	
	<43C59A62.9050204@dcrocker.net>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dcrocker@bbiw.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org




> I don't think that converting to xml is the same class of work. 
> There's a great deal of semantic information that should be encoded in
> the XML that isn't in the submitted text and doesn't have to be in the
> nroff.


Strictly speaking, you are certainly right.

But I lived with nroff for quite a few years and I have had to do quite a few 
txt-2-xml2rfc conversions recently.  The difference in semantic encoding, that 
you cite, is offset by how easily nroff formatting errors can be made and not 
readily detected.

Mostly, this sort of conversion work has a small, relatively standardized 
"vocabulary" of text to add or change and one gets into a rhythm. From that 
perspective, I suspect the work is about the same.  The real difference is that 
debugging the xml2rfc conversion is probably MUCH easier.

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 11:18:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExRdQ-0004iL-VD; Fri, 13 Jan 2006 11:18:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRdP-0004hj-6I
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 11:18:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19181
	for ; Fri, 13 Jan 2006 11:17:13 -0500 (EST)
Received: from colibri.verisign.com ([65.205.251.74])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExRkg-0001wB-8w
	for ietf@ietf.org; Fri, 13 Jan 2006 11:26:11 -0500
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com
	[65.205.251.35])
	by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0DGINVl018710;
	Fri, 13 Jan 2006 08:18:23 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by
	MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 13 Jan 2006 08:18:23 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Jan 2006 08:18:22 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD3787A7A4@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Thread-Topic: Offtopic: Alternative XML markup RE: Alternative formats for IDs
Thread-Index: AcYYBLU6z3QGvlaFSUukFybmncBPggAVZ4YA
From: "Hallam-Baker, Phillip" 
To: "Dave Crocker" , "Bill Fenner" 
X-OriginalArrivalTime: 13 Jan 2006 16:18:23.0349 (UTC)
	FILETIME=[F9CA7250:01C6185C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org, paul.hoffman@vpnc.org
Subject: Offtopic: Alternative XML markup RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

=20
I think that a lot of the objections made against XML/HTML vs nroff are
ultimately due the fact that adding end elements as well as start
elements makes for twice the work.

One way around this is to use better editing tools. I remain
consistently disappointed by the XML editing tools I have tried.

Another approach I have been experimenting with is to drop in an
alternative lexical analyzer into an existing XML parser. Instead of the
'strict' format required by the specification the lexer has a bunch of
intelligent rules to make the process of editing less tedious.

For example the feature I like of Wikipedia markup is that paragraph
breaks are automatically infered from a blank separating line (i.e. look
for nl ws* nl).

Other obvious changes are to get rid of namespace prexixes unless there
is actual ambiguity, to automatically infer end tags at paragraph breaks
and to allow /> as a means of closing the current lexical context. In
the rare case that block structure is actually needed beyond this
explicit blocking can be used.

The feature of wikipedia markup that I do not like is the fact that the
markup soon becomes unweildy once you go beyond the most commonly used
features. I don't know many people who can use the wiki table markup for
example.

I am currently experimenting with a markup where elements and attributes
have the same consistent syntax 
 becomes 
>

In short we end up more or less back to S-expressions with angle
brackets instead of round ones.


The main difference is that in document structure it is really not
necessary to throw in all the close tags, they only distract. If
something can be infered then infer it.=20


> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20
> Behalf Of Dave Crocker
> Sent: Friday, January 13, 2006 12:44 AM
> To: Bill Fenner
> Cc: ietf@ietf.org; paul.hoffman@vpnc.org
> Subject: Re: Alternative formats for IDs
>=20
>=20
>=20
>=20
> > I don't think that converting to xml is the same class of work.=20
> > There's a great deal of semantic information that should be=20
> encoded in=20
> > the XML that isn't in the submitted text and doesn't have=20
> to be in the=20
> > nroff.
>=20
>=20
> Strictly speaking, you are certainly right.
>=20
> But I lived with nroff for quite a few years and I have had=20
> to do quite a few txt-2-xml2rfc conversions recently.  The=20
> difference in semantic encoding, that you cite, is offset by=20
> how easily nroff formatting errors can be made and not=20
> readily detected.
>=20
> Mostly, this sort of conversion work has a small, relatively=20
> standardized "vocabulary" of text to add or change and one=20
> gets into a rhythm. From that perspective, I suspect the work=20
> is about the same.  The real difference is that debugging the=20
> xml2rfc conversion is probably MUCH easier.
>=20
> d/
>=20
> --=20
>=20
> Dave Crocker
> Brandenburg InternetWorking
> 
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>=20
>=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 14:26:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExUZ4-0000kD-2m; Fri, 13 Jan 2006 14:26:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExUZ2-0000k8-UO
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 14:26:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00135
	for ; Fri, 13 Jan 2006 14:24:59 -0500 (EST)
Received: from igw2.watson.ibm.com ([129.34.20.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExUgO-00081m-SA
	for ietf@ietf.org; Fri, 13 Jan 2006 14:33:58 -0500
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com
	[129.34.20.41])
	by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with
	ESMTP id k0DJSL0b006832
	for ; Fri, 13 Jan 2006 14:28:21 -0500
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1])
	by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with
	ESMTP id k0DJQ7k410792
	for ; Fri, 13 Jan 2006 14:26:07 -0500
Received: from [9.2.43.127] (saturn.watson.ibm.com [9.2.43.127])
	by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with
	ESMTP id k0DJQ6u410790
	for ; Fri, 13 Jan 2006 14:26:07 -0500
Message-ID: <43C7FECE.30106@watson.ibm.com>
Date: Fri, 13 Jan 2006 14:26:06 -0500
From: Barry Leiba 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: ietf@ietf.org
References: <200601122131.NAA11427@gra.isi.edu>
In-Reply-To: <200601122131.NAA11427@gra.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bob Braden wrote:
> Suppose that we edit the document in XML (we are already
> doing this part of the time), do a final nroffing pass to get the
> format just right, and then give the author(s) the edited xml,
...
> We have to make a new nroff version and
> PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME.
> 
> Now, this may not actually be too bad; most of the changes at the nroff
> stage are very cosmetic

Maybe we're attacking that part of it the wrong way.
What is it that makes those "cosmetic" changes, to "get the format
just right", so important?  Do we really care whether there's an
extra blank line, or the indentation is one character too much?

When I run xml2rfc and look at the results, the formatting looks
"just right" to me, at least for any value of "just right" that
I care about.  Why does the IETF (or others) care for a greater
value of "just right"?

Or am I missing something basic in the formatting changes you're
looking at, at that stage?

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 14:50:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExUwD-00062q-GF; Fri, 13 Jan 2006 14:50:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExUwA-00062J-Mp
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 14:50:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02147
	for ; Fri, 13 Jan 2006 14:48:52 -0500 (EST)
Received: from raman.networkresonance.com ([198.144.196.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExV3W-0000YI-Tb
	for ietf@ietf.org; Fri, 13 Jan 2006 14:57:52 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001)
	id 915BC1E8C4C; Fri, 13 Jan 2006 11:49:53 -0800 (PST)
To: Jeffrey Hutzelman 
References: <200601122131.NAA11427@gra.isi.edu> <43C6D321.3040807@dcrocker.net>
	
From: Eric Rescorla 
Importance: high
Date: Fri, 13 Jan 2006 11:49:53 -0800
In-Reply-To:  (Jeffrey
	Hutzelman's message of "Thu, 12 Jan 2006 18:16:26 -0500")
Message-ID: <86oe2f3o2m.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: Bob Braden , dcrocker@bbiw.net, ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jeffrey Hutzelman  writes:
> It sounds like an awful waste of time and effort to me.
>
> It seems like the more efficient approach would be to essentially have
> two stages, where the authors first sign off on the result of
> copy-editing, and then on whatever cosmetic changes are needed after
> the final conversion.

It's worth mentioning that this is exactly how book publication
works. Indeed, the copy-edit stage is often done on something
with entirely different formatting from the final version
(e.g., double-spaced). The proofreader is then responsible
for ensuring that (1) Each proposed copy-edit change actually
gets handled and (2) No superfluous changes are introduced
in the typesetting/page layout stage. Then there's a final
author approval of the galleys.

-Ekr

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 14:54:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExUzv-0006uk-LG; Fri, 13 Jan 2006 14:54:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExUzt-0006uc-2j
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 14:54:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02387
	for ; Fri, 13 Jan 2006 14:52:43 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExV7F-0000hl-D5
	for ietf@ietf.org; Fri, 13 Jan 2006 15:01:42 -0500
Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0DJidi17020;
	Fri, 13 Jan 2006 11:44:39 -0800 (PST)
Message-ID: <43C80328.9080002@isi.edu>
Date: Fri, 13 Jan 2006 11:44:40 -0800
From: Joe Touch 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ted Faber 
References: <200601122336.PAA11557@gra.isi.edu> <43C6F2DD.4040108@bbiw.net>
	<20060113015434.GD1391@hut.isi.edu>
In-Reply-To: <20060113015434.GD1391@hut.isi.edu>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit
Cc: Bob Braden , Dave Crocker ,
	ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Ted Faber wrote:
> On Thu, Jan 12, 2006 at 04:22:53PM -0800, Dave Crocker wrote:
> 
>>Maintaining xml2rfc is going to far less fragile than maintaining nroff.  
>>Nroff has no current industry penetration.  XML has quite a lot.
> 
> 
> I'd be cautious here.
> 
> Equating the XML communities and the xml2rfc communities is not correct.
> 
> There's an important distinction between the XML meta-language and the
> xml2rfc language and its associated formatting tools.  Lots of places
> express languages in XML DTDs and use one of the many XML parsers in
> their tools to parse those DTDs.  That widespread adoption of the
> meta-language and the resultant support for XML parsing libraries in a
> large number of implementation languages and environments does simplify
> the specification of the xml2rfc language and the generation and
> maintenance of the xml2rfc program.  However, the actual community of
> that uses the XML-based RFC authoring tools is a subset of the
> contributors to the IETF; the maintainers of the xml2rfc formatter(s)
> are a subset of that.  That smaller community is the one that is needed
> to keep a working xml2rfc language and formatting program available to
> the IETF.
> 
> It's by no means obvious to me that xml2rfc has reached a critical mass
> of developers and users, nor that it will necessarily do so organically.

This is my impression, from trying to use it as well. I was troubled by
'yet another embedded text system' that necessitated editing source,
which seemed like a stone-age throwback when I abandoned such systems in
the mid 1980s (Scribe, nroff, etc. at the time).

While I appreciate that, in theory:

	1. there are WYSIWYG XML editors that *can* be loaded with DTDs
	2. Word et al. are moving to XML

it's worth noting that:

	(1) requires users to enter data into XML fields, which can
	be very tedious. it also assumes that the XML editor can be
	loaded with the current IETF RFC DTD, which is by no means
	guaranteed or easy
	
	(2) AFAICT, Word uses its own DTD, and isn't particularly
	cooperative with using your own (I've asked others on the tools
	list about this, and they have had similar experience)

...
> All that said, I do think that an XML-based encoding of RFC contents is
> a good idea 

I do not; there is very little in RFCs that needs to be tagged except:
	MIBs
	lists of authors
	lists of references

I can't see why pushing the whole document into 'yet another tagged data
format' does anything for the utility of the remainder.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDyAMoE5f5cImnZrsRAjRYAKCjPWwgFL5CvOksicDDWC3RRMrKPACg2+Sm
+PyT8AAXATtZN3fps0K9ezI=
=rR0F
-----END PGP SIGNATURE-----

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 14:56:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExV2V-0007Zh-SR; Fri, 13 Jan 2006 14:56:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExV2T-0007ZM-F3
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 14:56:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02552
	for ; Fri, 13 Jan 2006 14:55:23 -0500 (EST)
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExV9n-0000nj-AI
	for ietf@ietf.org; Fri, 13 Jan 2006 15:04:22 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 303E6FB290;
	Fri, 13 Jan 2006 19:56:33 +0000 (UTC)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id BFDD33C0132;
	Fri, 13 Jan 2006 14:56:31 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: EKR 
In-Reply-To: (Your message of "Fri, 13 Jan 2006 11:49:53 PST.")
	<86oe2f3o2m.fsf@raman.networkresonance.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 13 Jan 2006 14:56:31 -0500
Message-Id: <20060113195631.BFDD33C0132@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Bob Braden , ietf@ietf.org, dcrocker@bbiw.net
Subject: Re: Alternative formats for IDs 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In message <86oe2f3o2m.fsf@raman.networkresonance.com>, Eric Rescorla writes:
>Jeffrey Hutzelman  writes:
>> It sounds like an awful waste of time and effort to me.
>>
>> It seems like the more efficient approach would be to essentially have
>> two stages, where the authors first sign off on the result of
>> copy-editing, and then on whatever cosmetic changes are needed after
>> the final conversion.
>
>It's worth mentioning that this is exactly how book publication
>works. Indeed, the copy-edit stage is often done on something
>with entirely different formatting from the final version
>(e.g., double-spaced). The proofreader is then responsible
>for ensuring that (1) Each proposed copy-edit change actually
>gets handled and (2) No superfluous changes are introduced
>in the typesetting/page layout stage. Then there's a final
>author approval of the galleys.
>
Right.  And I've heard authors gripe that they wrote their books with 
state-of-the-art distributed systems and version control, but because 
the publisher's typesetting was done on a different, incompatible 
system, the copy-edit changes were not fed back into the authors' 
system, making any second edition much more difficult.

AUTH48 is often quite prolonged and painful -- and I've experienced 
this as an author, WG chair, and AD.  Let's not make it any worse.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 14:58:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExV4M-0007pi-5Y; Fri, 13 Jan 2006 14:58:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExV4J-0007os-V0
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 14:58:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02739
	for ; Fri, 13 Jan 2006 14:57:18 -0500 (EST)
Received: from rwcrmhc13.comcast.net ([204.127.198.39]
	helo=rwcrmhc12.comcast.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExVBh-0000sV-FV
	for ietf@ietf.org; Fri, 13 Jan 2006 15:06:17 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (rwcrmhc13) with SMTP
	id <20060113195825015009mj6fe>; Fri, 13 Jan 2006 19:58:25 +0000
Message-ID: <108a01c6187b$8905f1b0$d0087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: <200601122131.NAA11427@gra.isi.edu> <43C7FECE.30106@watson.ibm.com>
Date: Fri, 13 Jan 2006 13:57:07 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Agree with Barry that we need to balance things wisely.

If we are routinely taking up RFC-Editor resources for cosmetic reformatting 
of XML2RFC output, I'm thinking that this is not a good use of resources.

If someone submitted one XML2RFC input that triggered some XML2RFC boundary 
condition bug and caused a blank page to be emitted in the middle of a 
document, maybe it's "better" to quickly fix the output than to fix XML2RFC, 
but I'd really like to get to the point where there is no reformatting of 
XML2RFC output for most/all XML2RFC input files that were submitted for 
publication as RFCs.

Thanks,

Spencer

From: "Barry Leiba" 


> Bob Braden wrote:
>> Suppose that we edit the document in XML (we are already
>> doing this part of the time), do a final nroffing pass to get the
>> format just right, and then give the author(s) the edited xml,
> ...
>> We have to make a new nroff version and
>> PUT THE SAME CHANGES INTO IT THAT WE DID THE FIRST TIME.
>>
>> Now, this may not actually be too bad; most of the changes at the nroff
>> stage are very cosmetic
>
> Maybe we're attacking that part of it the wrong way.
> What is it that makes those "cosmetic" changes, to "get the format
> just right", so important?  Do we really care whether there's an
> extra blank line, or the indentation is one character too much?
>
> When I run xml2rfc and look at the results, the formatting looks
> "just right" to me, at least for any value of "just right" that
> I care about.  Why does the IETF (or others) care for a greater
> value of "just right"?
>
> Or am I missing something basic in the formatting changes you're
> looking at, at that stage?
>
> Barry
>
> --
> Barry Leiba, Pervasive Computing Technology  (leiba@watson.ibm.com)
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 14:59:13 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExV4r-000851-Ig; Fri, 13 Jan 2006 14:59:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExV4o-00084Q-NA
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 14:59:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02788
	for ; Fri, 13 Jan 2006 14:57:48 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExVCB-0000v2-5k
	for ietf@ietf.org; Fri, 13 Jan 2006 15:06:48 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0DJxJOU010053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2006 11:59:20 -0800
Message-ID: <43C8066E.1080500@bbiw.net>
Date: Fri, 13 Jan 2006 11:58:38 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: EKR 
References: <200601122131.NAA11427@gra.isi.edu>	<43C6D321.3040807@dcrocker.net>	
	<86oe2f3o2m.fsf@raman.networkresonance.com>
In-Reply-To: <86oe2f3o2m.fsf@raman.networkresonance.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dcrocker@bbiw.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


>> It seems like the more efficient approach would be to essentially have
>> two stages, where the authors first sign off on the result of
>> copy-editing, and then on whatever cosmetic changes are needed after
>> the final conversion.
> 
> It's worth mentioning that this is exactly how book publication
> works. 

Exactly right.  So, the question is whether the IETF needs to use an operational 
model that guarantees certain, high overhead, or whether we can enjoy a model 
that permits us to move much of the grunt work out to the authors. 
(Interestingly, we can have the second-stage copy-editing either way, but with 
far more of the grunt work done by authors, for one of the models.)

The quality of the copy-editing that the rfc editor does is quite high.  But it 
also imposes a very high aggregate cost on the IETF.  Do we *really* need to 
spend that money, for that benefit?

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 15:07:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExVD1-0001z7-8z; Fri, 13 Jan 2006 15:07:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExVCz-0001yG-P9
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 15:07:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03466
	for ; Fri, 13 Jan 2006 15:06:15 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExVKL-0001I2-1U
	for ietf@ietf.org; Fri, 13 Jan 2006 15:15:15 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0DK82tk011256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2006 12:08:03 -0800
Message-ID: <43C80879.3040906@dcrocker.net>
Date: Fri, 13 Jan 2006 12:07:21 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Ted Faber 
References: <200601122336.PAA11557@gra.isi.edu> <43C6F2DD.4040108@bbiw.net>
	<20060113015434.GD1391@hut.isi.edu>
In-Reply-To: <20060113015434.GD1391@hut.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: Bob Braden , Dave Crocker ,
	ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Equating the XML communities and the xml2rfc communities is not correct.

Actually, it is.

xml2rfc uses some tailored dtd/xslt files.  They semantics in them is 
significant but what is far more important is the xml infrastructure that is 
available, in terms of expertise and tools.

I now produce drafts using an off-the-shelf xml tool that take the standard-form 
xml2rfc dtd and xslt files and produce excellent output.  (To be entirely fair, 
yes, there is some special software that produces the txt version.)  The xml 
tool and knowledge of xml are broadly applicable, and growing.  Knowledge of 
nroff is now sufficiently obscure as to be beyond mere characterization as 
"marginalized".  A word like "archaic" is more appropriate.

And by the way, please note that the use of nroff for rfcs also requires special 
conventions.

What is important is not the files used to tailor the production service, but 
the prevalence of expertise and tools for that service.

In reality, nroff expertise is isolated in a tiny community.  In reality, xml 
expertise has become global.  That's not an assessment of hypothetical, future 
adoption.  It is an assessment of *existing* adoption.



d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 15:08:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExVE6-0002oM-LK; Fri, 13 Jan 2006 15:08:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExVE4-0002o9-4P
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 15:08:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03586
	for ; Fri, 13 Jan 2006 15:07:22 -0500 (EST)
Received: from raman.networkresonance.com ([198.144.196.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExVLQ-0001Mj-Cr
	for ietf@ietf.org; Fri, 13 Jan 2006 15:16:21 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001)
	id B94EA1E8C4C; Fri, 13 Jan 2006 12:08:30 -0800 (PST)
To: "Steven M. Bellovin" 
References: <20060113195631.BFDD33C0132@berkshire.machshav.com>
From: Eric Rescorla 
Date: Fri, 13 Jan 2006 12:08:30 -0800
In-Reply-To: <20060113195631.BFDD33C0132@berkshire.machshav.com> (Steven M.
	Bellovin's message of "Fri, 13 Jan 2006 14:56:31 -0500")
Message-ID: <86k6d33n7l.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: Bob Braden , ietf@ietf.org, dcrocker@bbiw.net
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

"Steven M. Bellovin"  writes:
> Right.  And I've heard authors gripe that they wrote their books with 
> state-of-the-art distributed systems and version control, but because 
> the publisher's typesetting was done on a different, incompatible 
> system, the copy-edit changes were not fed back into the authors' 
> system, making any second edition much more difficult.

Fair enough, but consider that this problem already exists in the
RFC-Ed system because the RFC-Ed's final version is in a set
of tools that almost nobody uses. This includes many nroff
users, btw, because the RFC-Ed's nroff is too primitive to
really edit with yourself.


-Ekr

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 15:15:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExVKe-0005Gl-QY; Fri, 13 Jan 2006 15:15:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExVKd-0005Gg-2r
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 15:15:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04039
	for ; Fri, 13 Jan 2006 15:14:09 -0500 (EST)
Received: from rwcrmhc12.comcast.net ([216.148.227.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExVRz-0001dB-LU
	for ietf@ietf.org; Fri, 13 Jan 2006 15:23:08 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (rwcrmhc12) with SMTP
	id <2006011320152001400cs7hbe>; Fri, 13 Jan 2006 20:15:20 +0000
Message-ID: <109b01c6187d$e5e72ff0$d0087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: <200601122131.NAA11427@gra.isi.edu>
	<43C6D321.3040807@dcrocker.net>
	<86oe2f3o2m.fsf@raman.networkresonance.com>
Date: Fri, 13 Jan 2006 14:14:02 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Agree with EKR that such a two-stage author review SHOULD make sense, and if 
our median time in AUTH48 wasn't something like 10 days now[1], I'd be a lot 
more excited about adopting this and going through AUTH48 (or its nearest 
equivalent) twice ...

:-(

Spencer

[1] ftp://ftp.rfc-editor.org/in-notes/IETFreports/2005/ietf64-report.pdf and 
http://www3.ietf.org/proceedings/05nov/slides/plenaryw-2.pdf


> Jeffrey Hutzelman  writes:
>> It sounds like an awful waste of time and effort to me.
>>
>> It seems like the more efficient approach would be to essentially have
>> two stages, where the authors first sign off on the result of
>> copy-editing, and then on whatever cosmetic changes are needed after
>> the final conversion.
>
> It's worth mentioning that this is exactly how book publication
> works. Indeed, the copy-edit stage is often done on something
> with entirely different formatting from the final version
> (e.g., double-spaced). The proofreader is then responsible
> for ensuring that (1) Each proposed copy-edit change actually
> gets handled and (2) No superfluous changes are introduced
> in the typesetting/page layout stage. Then there's a final
> author approval of the galleys.
>
> -Ekr 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 15:45:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExVnP-0004FW-AG; Fri, 13 Jan 2006 15:45:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExVnN-0004FR-Ea
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 15:45:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05794
	for ; Fri, 13 Jan 2006 15:43:51 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExVuk-0002Yy-9N
	for ietf@ietf.org; Fri, 13 Jan 2006 15:52:51 -0500
Received: from pog.isi.edu (c1-vpn1.isi.edu [128.9.176.27])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0DKaVi06156;
	Fri, 13 Jan 2006 12:36:31 -0800 (PST)
Message-Id: <5.1.0.14.2.20060113120153.0339a050@boreas.isi.edu>
X-Sender: braden@boreas.isi.edu
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 13 Jan 2006 12:04:00 -0800
To: Barry Leiba , ietf@ietf.org
From: Bob Braden 
In-Reply-To: <43C7FECE.30106@watson.ibm.com>
References: <200601122131.NAA11427@gra.isi.edu>
	<200601122131.NAA11427@gra.isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


>
>
>Maybe we're attacking that part of it the wrong way.
>What is it that makes those "cosmetic" changes, to "get the format
>just right", so important?  Do we really care whether there's an
>extra blank line, or the indentation is one character too much?


Well, yes, we do.  At least, the RFC Editor cares, and we believe
you should care too.  Blank lines are not just randomly inserted... they 
are put in
to enhance readability, and they can make a significant difference.

RFCs are input to human readers, not machines.

Bob Braden


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 15:53:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExVv0-0006ET-1F; Fri, 13 Jan 2006 15:53:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExVux-0006E4-Vf
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 15:53:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06550
	for ; Fri, 13 Jan 2006 15:51:41 -0500 (EST)
Received: from igw2.watson.ibm.com ([129.34.20.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExW2K-0002w1-TG
	for ietf@ietf.org; Fri, 13 Jan 2006 16:00:42 -0500
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com
	[129.34.20.40])
	by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with
	ESMTP id k0DKt6oo027606
	for ; Fri, 13 Jan 2006 15:55:07 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1])
	by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with
	ESMTP id k0DKqrc125774
	for ; Fri, 13 Jan 2006 15:52:53 -0500
Received: from mars (mars.watson.ibm.com [9.2.40.64])
	by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with
	ESMTP id k0DKqqs125770
	for ; Fri, 13 Jan 2006 15:52:52 -0500
Received: from saturn ([9.2.43.127])
	by mars.watson.ibm.com (IMF.2005.07.16.1050.haw)
	with SMTP ID IMFd1137185571.507; Fri, 13 Jan 2006 15:52:51 -0400
Date: Fri, 13 Jan 2006 15:52:51 -0500
From: Barry Leiba 
To: Bob Braden , ietf@ietf.org
Message-ID: <73B61DC49861C01271AD9186@saturn.watson.ibm.com>
In-Reply-To: <5.1.0.14.2.20060113120153.0339a050@boreas.isi.edu>
References: <200601122131.NAA11427@gra.isi.edu>
	<200601122131.NAA11427@gra.isi.edu>
	<5.1.0.14.2.20060113120153.0339a050@boreas.isi.edu>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>> Maybe we're attacking that part of it the wrong way.
>> What is it that makes those "cosmetic" changes, to "get the format
>> just right", so important?  Do we really care whether there's an
>> extra blank line, or the indentation is one character too much?
> 
> Well, yes, we do.  At least, the RFC Editor cares, and we believe
> you should care too.  Blank lines are not just randomly inserted...
> they are put in to enhance readability

Oh, sure, I get that, and I'm not suggesting that we ignore that.  I'm
asking this: If the author and the last-call commentors think the
output of xml2rfc looks good, what is that that you "tweak" with nroff
that's necessary at that point?

When you say that you make cosmetic changes beyond what's been done
with xml2rfc, and agreed to by those who've reviewed it, I presume
you're making stylistic changes that the RFC editor cares about that
"we" didn't (if we did, we'd have already made those changes).  I'm
wonder what sorts of things those are, and whether they're really worth
all the extra overhead.

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 15:57:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExVzI-0007ym-AF; Fri, 13 Jan 2006 15:57:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExVzF-0007yX-NQ
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 15:57:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07722
	for ; Fri, 13 Jan 2006 15:56:07 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExW6a-0003WB-Bl
	for ietf@ietf.org; Fri, 13 Jan 2006 16:05:07 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0DKvq7B017572
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2006 12:57:53 -0800
Message-ID: <43C81427.4000700@dcrocker.net>
Date: Fri, 13 Jan 2006 12:57:11 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Bob Braden 
References: <200601122131.NAA11427@gra.isi.edu>	<200601122131.NAA11427@gra.isi.edu>
	<5.1.0.14.2.20060113120153.0339a050@boreas.isi.edu>
In-Reply-To: <5.1.0.14.2.20060113120153.0339a050@boreas.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



>> Maybe we're attacking that part of it the wrong way.
>> What is it that makes those "cosmetic" changes, to "get the format
>> just right", so important?  Do we really care whether there's an
>> extra blank line, or the indentation is one character too much?
> 
> 
> Well, yes, we do.  


Bob, the question is not whether it is good to have a standard format, design 
for easy readability.

The question how much it is worth ensuring that all the spacing is always and 
exactly correct.  How much is it worth in time/delay and how much is it worth in 
dollars?

And specifically, how bad would it be to spend far less -- bordering on nothing 
-- and get "pretty close" to that desired format?

For a community built upon the construct of efficient use of scarce resources, 
we do an impressively good job of ignoring that construct in our own operation.

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 16:13:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExWEd-0006rV-IE; Fri, 13 Jan 2006 16:13:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWEa-0006ou-Th
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 16:13:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11597
	for ; Fri, 13 Jan 2006 16:11:58 -0500 (EST)
Received: from rwcrmhc11.comcast.net ([216.148.227.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExWLv-000557-RN
	for ietf@ietf.org; Fri, 13 Jan 2006 16:20:59 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (rwcrmhc11) with SMTP
	id <2006011321130301300cjjete>; Fri, 13 Jan 2006 21:13:03 +0000
Message-ID: <117501c61885$f6293310$d0087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: <200601122131.NAA11427@gra.isi.edu><200601122131.NAA11427@gra.isi.edu><5.1.0.14.2.20060113120153.0339a050@boreas.isi.edu>
	<73B61DC49861C01271AD9186@saturn.watson.ibm.com>
Date: Fri, 13 Jan 2006 15:11:45 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

(clipped down to)


>>> Maybe we're attacking that part of it the wrong way.
>>> What is it that makes those "cosmetic" changes, to "get the format
>>> just right", so important?  Do we really care whether there's an
>>> extra blank line, or the indentation is one character too much?
>>
>> Well, yes, we do.  At least, the RFC Editor cares, and we believe
>> you should care too.  Blank lines are not just randomly inserted...
>> they are put in to enhance readability
>
> When you say that you make cosmetic changes beyond what's been done
> with xml2rfc, and agreed to by those who've reviewed it, I presume
> you're making stylistic changes that the RFC editor cares about that
> "we" didn't (if we did, we'd have already made those changes).  I'm
> wonder what sorts of things those are, and whether they're really worth
> all the extra overhead.

... and whether it would be good if the working group had been reviewing a 
more-readable version of the document, and had forwarded a more-readable 
version for last call and IESG review...

Given that the RFC Editor has published more documents than I've written in 
my life, I don't question what's being done. I'm just asking if it might be 
done automatically, and be done earlier in the process.

I'm guessing these are changes that the RFC Editor has been feeding to the 
XML2RFC authors via Bill Fenner in 
http://rtg.ietf.org/Members/BillFenner/rfced-xml/FrontPage/issuetracker, and 
that we're moving closer to "fire and forget" XML2RFC operation, so maybe 
all is well, or at least improving?

Spencer 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 16:14:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExWG7-0000oC-D5; Fri, 13 Jan 2006 16:14:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWG4-0000md-Kb
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 16:14:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11823
	for ; Fri, 13 Jan 2006 16:13:30 -0500 (EST)
Received: from colibri.verisign.com ([65.205.251.74])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExWNR-0005DD-Ge
	for ietf@ietf.org; Fri, 13 Jan 2006 16:22:30 -0500
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com
	[65.205.251.35])
	by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0DLEjo3002221;
	Fri, 13 Jan 2006 13:14:45 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by
	MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 13 Jan 2006 13:14:45 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Jan 2006 13:14:44 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD3787A7FF@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Thread-Topic: Alternative formats for IDs
Thread-Index: AcYYfKM0xflbcyp/RFWKQUebTkbMZgACWcSQ
From: "Hallam-Baker, Phillip" 
To: "Spencer Dawkins" , 
X-OriginalArrivalTime: 13 Jan 2006 21:14:45.0337 (UTC)
	FILETIME=[60AE7C90:01C61886]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: RE: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20
> Behalf Of Spencer Dawkins

> Agree with Barry that we need to balance things wisely.
>=20
> If we are routinely taking up RFC-Editor resources for=20
> cosmetic reformatting of XML2RFC output, I'm thinking that=20
> this is not a good use of resources.

I heartily agree.=20

I find it completely bizare that we have people saying that TXT is good
enough then say that the process has to allow for pretification.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 17:37:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExXY4-00010C-Hd; Fri, 13 Jan 2006 17:37:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXY2-0000zW-C1
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 17:37:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17649
	for ; Fri, 13 Jan 2006 17:36:07 -0500 (EST)
Received: from b.mail.sonic.net ([64.142.19.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExXfP-0008JL-VM
	for ietf@ietf.org; Fri, 13 Jan 2006 17:45:09 -0500
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG
	[168.61.10.151]) (authenticated bits=0)
	by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0DMbHMu028506
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 13 Jan 2006 14:37:17 -0800
In-Reply-To: <43C80879.3040906@dcrocker.net>
References: <200601122336.PAA11557@gra.isi.edu> <43C6F2DD.4040108@bbiw.net>
	<20060113015434.GD1391@hut.isi.edu> <43C80879.3040906@dcrocker.net>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <09ADFA83-0EA7-4077-9594-BDEDDC8F152D@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis 
Date: Fri, 13 Jan 2006 14:37:16 -0800
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 13, 2006, at 12:07 PM, Dave Crocker wrote:

> What is important is not the files used to tailor the production  
> service, but the prevalence of expertise and tools for that service.
>
> In reality, nroff expertise is isolated in a tiny community.  In  
> reality, xml expertise has become global.  That's not an assessment  
> of hypothetical, future adoption.  It is an assessment of  
> *existing* adoption.

Agreed.

Adopting an XML structure for the creation of RFCs and related  
documents should be moving in the right direction.  At some point,  
even removing nroff as a crutch may ensure greater conformity for  
tools used to process documents.  Although nroff is an extremely  
powerful and efficient word processing application, building upon  
more versatile and hierarchical structures offers many possibilities  
for managing the growing complexity of information being amassed.

Both approaches requires post processing together with the cut and  
paste of some templates.  As long as xml2rfc allows a means to bypass  
formatting difficulties in getting a good looking draft, regardless  
whether this requires 120 characters or 12, the end results in text  
form of either process _can_ be identical.  Cut and paste does not  
take much effort either way, and even the clumsiness for some  
operations in xml2rfc can be readily overcome.  XML data structures  
enable new features with less effort, like automatic generation of  
bibliographies or the insertion of hyperlinks in html output  
versions.  XML also has the ability to add new elements to  
accommodate new features without disrupting other forms of output.

-Doug


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 17:55:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExXpQ-0005nA-OG; Fri, 13 Jan 2006 17:55:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXpO-0005n5-Gt
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 17:55:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18608
	for ; Fri, 13 Jan 2006 17:54:03 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExXwm-0000Rk-DX
	for ietf@ietf.org; Fri, 13 Jan 2006 18:03:05 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LXPYG11T2800237I@mauve.mrochek.com> for
	ietf@ietf.org; Fri, 13 Jan 2006 14:55:07 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1137192907;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=mRK787QKvDv9x4rx0xPIEygZg
	fK3YAeZ9guUTDLBQKQL5PNiQsXC2Xfng4fo7ppt5AqA9hKX15vY/lw1B3KAGQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LXPSHT4JK000009C@mauve.mrochek.com>; Fri,
	13 Jan 2006 14:55:05 -0800 (PST)
To: Steven M Bellovin 
Message-id: <01LXPYG04RJ200009C@mauve.mrochek.com>
Date: Fri, 13 Jan 2006 14:37:37 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 13 Jan 2006 14:56:31 -0500"
	<20060113195631.BFDD33C0132@berkshire.machshav.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <86oe2f3o2m.fsf@raman.networkresonance.com>
	<20060113195631.BFDD33C0132@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: Bob Braden , dcrocker@bbiw.net, ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Right.  And I've heard authors gripe that they wrote their books with
> state-of-the-art distributed systems and version control, but because
> the publisher's typesetting was done on a different, incompatible
> system, the copy-edit changes were not fed back into the authors'
> system, making any second edition much more difficult.

> AUTH48 is often quite prolonged and painful -- and I've experienced
> this as an author, WG chair, and AD.  Let's not make it any worse.

If by "worse" you mean I'll get back the vast majority of changes in the form
of a revised version of the XML file I handed in, which I can then edit and
send back, saving me hours of work retrofitting the changes into my copy, them
I'm for making this as "worse" as possible.

In my case at least this changes the first pass of AUTH48 to a simple
differences check-and-merge. I do these routinely, often on much larger
documents than any RFC I've written, and it is rare for the process to take
more than 15-20 minutes. (It does help to have sharp tools for this: BBEdit in
my case.)  In contrast, the two recent RFCs I recently dealt with required
several hours of work apiece. That pushes things from an activity I can pretty
much squeeze in anywhere to one I have to budget time for, and that in turn
tends to stretch AUTH48 into the realm of AUTH96 or even more.

As long as the second pass doesn't involve wording changes I don't anticipate
it taking very long. I view layout as the RFC Editor's for the most part.

Bottom line: This will be a HUGE improvement for anyone that uses xml2rfc. I
would not be adverse to retaining the old process for RFCs submitted to the
editor as ASCII text, but holding xml2rfc users hostage to the old way of
working makes no sense whatsoever.

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 18:04:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExXxx-00071v-Hg; Fri, 13 Jan 2006 18:04:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXxv-00071U-A6
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 18:04:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19095
	for ; Fri, 13 Jan 2006 18:02:52 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExY5I-0000jE-V1
	for ietf@ietf.org; Fri, 13 Jan 2006 18:11:54 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0DMrKi22233;
	Fri, 13 Jan 2006 14:53:20 -0800 (PST)
Received: (from faber@localhost)
	by hut.isi.edu (8.13.4/8.13.4/Submit) id k0DMrKqp075920;
	Fri, 13 Jan 2006 14:53:20 -0800 (PST) (envelope-from faber)
Date: Fri, 13 Jan 2006 14:53:20 -0800
From: Ted Faber 
To: dcrocker@bbiw.net
Message-ID: <20060113225319.GQ21742@hut.isi.edu>
References: <200601122336.PAA11557@gra.isi.edu> <43C6F2DD.4040108@bbiw.net>
	<20060113015434.GD1391@hut.isi.edu> <43C80879.3040906@dcrocker.net>
Mime-Version: 1.0
In-Reply-To: <43C80879.3040906@dcrocker.net>
User-Agent: Mutt/1.4.2.1i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: Bob Braden , ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1745172355=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============1745172355==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="K9fy5ol1Oes4Q/ix"
Content-Disposition: inline


--K9fy5ol1Oes4Q/ix
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 13, 2006 at 12:07:21PM -0800, Dave Crocker wrote:
> >Equating the XML communities and the xml2rfc communities is not correct.
>=20
> Actually, it is.
>=20
> xml2rfc uses some tailored dtd/xslt files.  They semantics in them is=20
> significant but what is far more important is the xml infrastructure that=
=20
> is available, in terms of expertise and tools.

The xml2rfc tool that I am familiar with (available from here:
http://xml.resource.org/ ) formats the text itself, without using
standard xslt (or dsssl or any standard formatting language).  Unless
I'm really misreading it, it's a 13,000 line tcl script that does
all its own text/html/nroff formatting.  I don't think tcl code is an
XML standard.

I was operating under the assumption that rfc2xml from the above site is
the program you were talking about.  A system that produces RFC output
from the xml2rfc markup using only (or even primarily) standard,
well-supported XML parsing and formatting tools would make the
communities much more congruent and reap the obvious benefits.   That's
not the tool I see in operation today.=20

I'd be more likely to believe that the formatting was robust and that
the system was maintainable if there was such a tool for the RFC editor
to adopt.  I'd also be more likely to believe your assertions that the
toolchain was benefiting from the growing XML community.

>=20
> I now produce drafts using an off-the-shelf xml tool that take the=20
> standard-form xml2rfc dtd and xslt files and produce excellent output.  (=
To=20
> be entirely fair, yes, there is some special software that produces the t=
xt=20
> version.)  The xml tool and knowledge of xml are broadly applicable, and=
=20
> growing.

There's no need to copy IETFdom Assembled on this, but I'm curious what
toolchain you're using and what limitations you've encountered. =20

>           Knowledge of nroff is now sufficiently obscure as to be beyond=
=20
> mere characterization as "marginalized".  A word like "archaic" is more=
=20
> appropriate.
>=20
> And by the way, please note that the use of nroff for rfcs also requires=
=20
> special conventions.
>=20
> What is important is not the files used to tailor the production service,=
=20
> but the prevalence of expertise and tools for that service.
>=20
> In reality, nroff expertise is isolated in a tiny community.  In reality,=
=20
> xml expertise has become global.  That's not an assessment of hypothetica=
l,=20
> future adoption.  It is an assessment of *existing* adoption.

You'll note that I make no assertions about the stability of
nroff nor about the size of its user community in the message you're
responding to.  That was not accidental.

If the only issue were the existence of a markup language that reliably
produced plain text RFCs, I *would* be arguing that *roff would be
sufficient if not optimal.  The reson I'm studiously avoiding having
that argument (and will continue to do so) is that I think changing to
an RFC representation that is strictly a formatting language - like
*roff - is not very interesting.

If there's a benefit to be had, IMHO, it's from content-based markup.
Right now the only serious contender I've heard for CBM of RFCs is
rfc2xml (the language).  And, IMHO, it's OKish.  I think the tools and
language will continue to improve.  I don't feel confortable with their
maturity to advocate for them now.

(Again - I'm really not trying to run down xml2rfc.  I think it's on the
right track and I support the idea and the work.  I'm an enthusiastic
user.)

I am looking forward to the day when we not only agree about where to
go, but how to get there. :-)

--=20
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.=
asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#=
SIG

--K9fy5ol1Oes4Q/ix
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDyC9faUz3f+Zf+XsRAuyGAJ9LWURJPIXSBDkuqjetlBbivVxfAACg1ON+
ez5/RYmn7X1Z2DtyzzDbsck=
=K7zU
-----END PGP SIGNATURE-----

--K9fy5ol1Oes4Q/ix--


--===============1745172355==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1745172355==--




From ietf-bounces@ietf.org Fri Jan 13 18:43:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExYa2-0001k6-O5; Fri, 13 Jan 2006 18:43:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYZz-0001j9-3L
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 18:43:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22119
	for ; Fri, 13 Jan 2006 18:42:11 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExYhJ-0002Hk-NC
	for ietf@ietf.org; Fri, 13 Jan 2006 18:51:14 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1ExYZd-0002X2-JI
	for ietf@ietf.org; Sat, 14 Jan 2006 00:43:13 +0100
Received: from pd9fba9b5.dip0.t-ipconnect.de ([217.251.169.181])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Sat, 14 Jan 2006 00:43:13 +0100
Received: from nobody by pd9fba9b5.dip0.t-ipconnect.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for ; Sat, 14 Jan 2006 00:43:13 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Sat, 14 Jan 2006 00:40:23 +0100
Organization: 
Lines: 51
Message-ID: <43C83A67.4EE4@xyzzy.claranet.de>
References: <200601122336.PAA11557@gra.isi.edu> <43C6F2DD.4040108@bbiw.net>
	<20060113015434.GD1391@hut.isi.edu> <43C80328.9080002@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fba9b5.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Joe Touch wrote:

> requires users to enter data into XML fields, which can
> be very tedious. it also assumes that the XML editor can be
> loaded with the current IETF RFC DTD, which is by no means
> guaranteed or easy

Authors could create their own input format, transformed into
the 2629bis XML by a script.  Something like "Wiki" would be
far more than good enough, and that's not very tedious.

An XML editor not knowing the latest and greatest DTD would
still guarantee proper nesting of tags.  And if authors use
US ASCII as document charset their worst problem would be to
convince their XML editor that symbolic entities like &nbhy;
are no nonsense, but defined in the xml2rfc DTD.

If authors use UTF-8 (or anything else that's not ASCII) they
deserve to be in serious trouble for the resulting text/plain
output, that's a point for the I18N considerations in a future
2629bis 

> AFAICT, Word uses its own DTD, and isn't particularly
> cooperative with using your own

Maybe Word isn't an ideal XML-editor then.  Any decent text
editor will do.  If authors don't like vi or notepad they use
something else.  My favourite text editor is based on XEDIT,
about 23 years old.

>> I do think that an XML-based encoding of RFC contents is
>> a good idea
 
> I do not; there is very little in RFCs that needs to be
> tagged except:
>         MIBs
>         lists of authors
>         lists of references

That list is not complete, e.g. you forgot to mention ABNF.
Another point are the keywords for many RfCs, example:

http://purl.net/net/rfc/2070
http://tools.ietf.org/html/2070

The latter tool doesn't "see" some meta-data like keywords,
because it's not part of the ASCII version.  But it's simple
to specify meta-data in an XML version.

                           Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 18:57:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ExYn1-0005Dk-7x; Fri, 13 Jan 2006 18:57:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYmy-0005Df-Re
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 18:57:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23236
	for ; Fri, 13 Jan 2006 18:55:37 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExYuN-0002qV-Cv
	for ietf@ietf.org; Fri, 13 Jan 2006 19:04:40 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0DNvIeY006632
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2006 15:57:19 -0800
Message-ID: <43C83E35.10807@dcrocker.net>
Date: Fri, 13 Jan 2006 15:56:37 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Ted Faber 
References: <200601122336.PAA11557@gra.isi.edu>
	<43C6F2DD.4040108@bbiw.net>	<20060113015434.GD1391@hut.isi.edu>
	<43C80879.3040906@dcrocker.net>
	<20060113225319.GQ21742@hut.isi.edu>
In-Reply-To: <20060113225319.GQ21742@hut.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



> I was operating under the assumption that rfc2xml from the above site is
> the program you were talking about.

I use it, or a version that runs on windows, to create the txt output.  But, no, 
it's not what I work with otherwise.  What i work with normally is a commercial 
somewhat-wysiwyg xml editor that is driven by standard xml metafiles.


> I'd be more likely to believe that the formatting was robust and that
> the system was maintainable if there was such a tool for the RFC editor
> to adopt. 

There is.


> There's no need to copy IETFdom Assembled on this, but I'm curious what
> toolchain you're using and what limitations you've encountered.  

My impression is that there are now a number of entirely competent xml editing 
systems.  I happen to use oXygen.


> If the only issue were the existence of a markup language that reliably
> produced plain text RFCs, 

the reason xml is interesting is that it makes editing easier, not just display.

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 13 20:21:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Exa7D-0002Fa-76; Fri, 13 Jan 2006 20:21:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Exa7B-0002FV-AS
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 20:21:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28370
	for ; Fri, 13 Jan 2006 20:20:35 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExaEZ-0005ec-5L
	for ietf@ietf.org; Fri, 13 Jan 2006 20:29:37 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0E1Kci03872;
	Fri, 13 Jan 2006 17:20:38 -0800 (PST)
Received: (from faber@localhost)
	by hut.isi.edu (8.13.4/8.13.4/Submit) id k0E1Kbgw097280;
	Fri, 13 Jan 2006 17:20:37 -0800 (PST) (envelope-from faber)
Date: Fri, 13 Jan 2006 17:20:37 -0800
From: Ted Faber 
To: dcrocker@bbiw.net
Message-ID: <20060114012037.GA96929@hut.isi.edu>
References: <200601122336.PAA11557@gra.isi.edu> <43C6F2DD.4040108@bbiw.net>
	<20060113015434.GD1391@hut.isi.edu> <43C80879.3040906@dcrocker.net>
	<20060113225319.GQ21742@hut.isi.edu> <43C83E35.10807@dcrocker.net>
Mime-Version: 1.0
In-Reply-To: <43C83E35.10807@dcrocker.net>
User-Agent: Mutt/1.4.2.1i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1307873233=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============1307873233==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC"
Content-Disposition: inline


--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 13, 2006 at 03:56:37PM -0800, Dave Crocker wrote:
> >There's no need to copy IETFdom Assembled on this, but I'm curious what
> >toolchain you're using and what limitations you've encountered. =20
>=20
> My impression is that there are now a number of entirely competent xml=20
> editing systems.  I happen to use oXygen.

Oxygen looks like an interesting tool, but I wasn't able to readily see
that it applies stylesheets to XML to produce printable/readable
documents.  For example, can I go from a docbook document to
cmaera-ready postscript/pdf using oxygen?  Or xml2rfc -> txt? If so,
your argument is better than I thought; if not, I think that's a sign
that we're not ready to move.  Yet.

I don't think editing systems by themselves are a reason to go to an XML
format.  Again, I think that making the RFC content and metadata
available to both machines & humans is facilitated by an XML format.

[snip]
> the reason xml is interesting is that it makes editing easier, not just=
=20
> display.

XML does not interest me for that reason.

--=20
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.=
asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#=
SIG

--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDyFHlaUz3f+Zf+XsRAgb2AJwIiRTb+ExP23AYah2VrceG0oJjNgCgspeO
M8HPzkemahfgZ6uoM2JAWtw=
=66Al
-----END PGP SIGNATURE-----

--wRRV7LY7NUeQGEoC--


--===============1307873233==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1307873233==--




From ietf-bounces@ietf.org Fri Jan 13 22:23:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Exc0a-00055i-V6; Fri, 13 Jan 2006 22:23:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Exc0X-00054O-RQ
	for ietf@megatron.ietf.org; Fri, 13 Jan 2006 22:23:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12389
	for ; Fri, 13 Jan 2006 22:21:51 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exc7z-0003Y4-5L
	for ietf@ietf.org; Fri, 13 Jan 2006 22:30:55 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id E2DAC2596E5;
	Sat, 14 Jan 2006 04:22:01 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 09968-03; Sat, 14 Jan 2006 04:21:57 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 8FF16259711;
	Sat, 14 Jan 2006 04:21:56 +0100 (CET)
Date: Sat, 14 Jan 2006 04:21:44 +0100
From: Harald Tveit Alvestrand 
To: Joe Touch 
Message-ID: 
In-Reply-To: <43C80328.9080002@isi.edu>
References: <200601122336.PAA11557@gra.isi.edu>
	<43C6F2DD.4040108@bbiw.net>	<20060113015434.GD1391@hut.isi.edu>
	<43C80328.9080002@isi.edu>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: ietf@ietf.org
Subject: A plug for XXE (Re: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1363130984=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1363130984==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========9DCBA846C340C48ED545=========="

--==========9DCBA846C340C48ED545==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable



--On 13. januar 2006 11:44 -0800 Joe Touch  wrote:

> This is my impression, from trying to use it as well. I was troubled by
> 'yet another embedded text system' that necessitated editing source,
> which seemed like a stone-age throwback when I abandoned such systems in
> the mid 1980s (Scribe, nroff, etc. at the time).
>
> While I appreciate that, in theory:
>
> 	1. there are WYSIWYG XML editors that *can* be loaded with DTDs
> 	2. Word et al. are moving to XML

Bill Fenner has made a plugin available for the XMLMind XML Editor that=20
gives you a lot of assistance in writing XML2RFC documents.

I haven't used it for "production" yet, but it looks wonderful - not=20
WYSIWYG, but WYSIPU - What You See Is Pretty Useful.

Details on 

                           Harald




--==========9DCBA846C340C48ED545==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDyG5IOMj+2+WY0F4RAh3CAKCN+iTldJaLDazsKIvWH7th99GnQwCg2Xtr
TVyg0PevRV64Zerm1WqEJ0g=
=ONny
-----END PGP SIGNATURE-----

--==========9DCBA846C340C48ED545==========--



--===============1363130984==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1363130984==--





From ietf-bounces@ietf.org Sun Jan 15 11:23:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyAfH-0005f4-MV; Sun, 15 Jan 2006 11:23:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAfG-0005ey-50
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 11:23:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01541
	for ; Sun, 15 Jan 2006 11:20:49 -0500 (EST)
Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExnTl-0000Ks-BL
	for ietf@ietf.org; Sat, 14 Jan 2006 10:38:10 -0500
Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43)
	id 1ExnLr-00025Y-B0; Sat, 14 Jan 2006 15:29:59 +0000
Message-ID: <43C91974.2000105@dial.pipex.com>
Date: Sat, 14 Jan 2006 15:32:04 +0000
From: Elwyn Davies 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: <200601122336.PAA11557@gra.isi.edu>	<43C6F2DD.4040108@bbiw.net>	<20060113015434.GD1391@hut.isi.edu>	<43C80328.9080002@isi.edu>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, Joe Touch 
Subject: Re: A plug for XXE (Re: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Seconded.

I *have* used it for a production run and whilst it is not perfect it
makes document creation and editing significantly easier than typing
'raw' xml even into a syntax-aware text editor.

It is also very helpful for proof reading and commenting (spell checker
provided).

And the standard version is free.. and supported on Windows, Linux and Mac.

I used to use the Word template but the freedom from hassle of generating the 
final documents, the ease of generating references and support of complex 
numbered lists (almost impossible to achieve in Word) makes
xxe/xml2rfc my current tool chain of choice and means I am never going back to Word.

Regards,
Elwyn
(addict)


Harald Tveit Alvestrand wrote:

>
>
> --On 13. januar 2006 11:44 -0800 Joe Touch  wrote:
>
>> This is my impression, from trying to use it as well. I was troubled by
>> 'yet another embedded text system' that necessitated editing source,
>> which seemed like a stone-age throwback when I abandoned such systems in
>> the mid 1980s (Scribe, nroff, etc. at the time).
>>
>> While I appreciate that, in theory:
>>
>>     1. there are WYSIWYG XML editors that *can* be loaded with DTDs
>>     2. Word et al. are moving to XML
>
>
> Bill Fenner has made a plugin available for the XMLMind XML Editor 
> that gives you a lot of assistance in writing XML2RFC documents.
>
> I haven't used it for "production" yet, but it looks wonderful - not 
> WYSIWYG, but WYSIPU - What You See Is Pretty Useful.
>
> Details on 
>
>                           Harald
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>  
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 15 12:34:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyBj5-0006lm-TV; Sun, 15 Jan 2006 12:31:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyBgw-0005jW-N3
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 12:29:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09666
	for ; Sun, 15 Jan 2006 11:53:15 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExjK4-0000yZ-JJ
	for ietf@ietf.org; Sat, 14 Jan 2006 06:11:55 -0500
Received: (qmail invoked by alias); 14 Jan 2006 11:03:54 -0000
Received: from p508FBAC7.dip0.t-ipconnect.de (EHLO [192.168.178.21])
	[80.143.186.199]
	by mail.gmx.net (mp019) with SMTP; 14 Jan 2006 12:03:54 +0100
X-Authenticated: #1915285
Message-ID: <43C8DA2A.8060103@gmx.de>
Date: Sat, 14 Jan 2006 12:02:02 +0100
From: Julian Reschke 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Ted Faber 
References: <200601122336.PAA11557@gra.isi.edu>
	<43C6F2DD.4040108@bbiw.net>	<20060113015434.GD1391@hut.isi.edu>
	<43C80879.3040906@dcrocker.net>
	<20060113225319.GQ21742@hut.isi.edu>
In-Reply-To: <20060113225319.GQ21742@hut.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: Bob Braden , dcrocker@bbiw.net, ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ted Faber wrote:
> On Fri, Jan 13, 2006 at 12:07:21PM -0800, Dave Crocker wrote:
>>> Equating the XML communities and the xml2rfc communities is not correct.
>> Actually, it is.
>>
>> xml2rfc uses some tailored dtd/xslt files.  They semantics in them is 
>> significant but what is far more important is the xml infrastructure that 
>> is available, in terms of expertise and tools.
> 
> The xml2rfc tool that I am familiar with (available from here:
> http://xml.resource.org/ ) formats the text itself, without using
> standard xslt (or dsssl or any standard formatting language).  Unless
> I'm really misreading it, it's a 13,000 line tcl script that does
> all its own text/html/nroff formatting.  I don't think tcl code is an
> XML standard.
> 
> I was operating under the assumption that rfc2xml from the above site is
> the program you were talking about.  A system that produces RFC output
> from the xml2rfc markup using only (or even primarily) standard,
> well-supported XML parsing and formatting tools would make the
> communities much more congruent and reap the obvious benefits.   That's
> not the tool I see in operation today. 
> ...

That's correct, in that the only xml2rfc processor that currently 
produces usable ASCII output is the TCL version maintained by MTR and 
Charles Levert.

There are other xml2rfc processors that are useful during the editing 
stage, such as rfc2629.xslt that allows you to open a text editor and a 
browser and basically gives you a nearly instantaneous (depending on 
browser and CPU power) preview of an HTML version of the text.

Best regards, Julian

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 15 12:34:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyBha-0006Lm-Va; Sun, 15 Jan 2006 12:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyBhO-0005zS-2x
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 12:29:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07883
	for ; Sun, 15 Jan 2006 11:48:28 -0500 (EST)
Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exkx1-0007WM-CH
	for ietf@ietf.org; Sat, 14 Jan 2006 07:56:12 -0500
Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43)
	id 1ExkpC-00079n-6U; Sat, 14 Jan 2006 12:48:06 +0000
Message-ID: <43C8F385.4050204@dial.pipex.com>
Date: Sat, 14 Jan 2006 12:50:13 +0000
From: Elwyn Davies 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: <200601122336.PAA11557@gra.isi.edu>	<43C6F2DD.4040108@bbiw.net>	<20060113015434.GD1391@hut.isi.edu>	<43C80328.9080002@isi.edu>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, Joe Touch 
Subject: Re: A plug for XXE (Re: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Seconded.

I *have* used it for a production run and whilst it is not perfect it 
makes document creation and editing significantly easier than typing 
'raw' xml even into a syntax-aware text editor.

It is also very helpful for proof reading and commenting (spell checker 
provided).

And the standard version is free.. and supported on Windows, Linux and Mac.

I used to use the Word template but the freedom from hassle of 
generating the final documents, the ease of generating references makes 
xxe/xml2rfc
and support of complex numbered lists (almost impossible to achieve in 
Word) means I am never going back.

Regards,
Elwyn
(addict)


Harald Tveit Alvestrand wrote:

>
>
> --On 13. januar 2006 11:44 -0800 Joe Touch  wrote:
>
>> This is my impression, from trying to use it as well. I was troubled by
>> 'yet another embedded text system' that necessitated editing source,
>> which seemed like a stone-age throwback when I abandoned such systems in
>> the mid 1980s (Scribe, nroff, etc. at the time).
>>
>> While I appreciate that, in theory:
>>
>>     1. there are WYSIWYG XML editors that *can* be loaded with DTDs
>>     2. Word et al. are moving to XML
>
>
> Bill Fenner has made a plugin available for the XMLMind XML Editor 
> that gives you a lot of assistance in writing XML2RFC documents.
>
> I haven't used it for "production" yet, but it looks wonderful - not 
> WYSIWYG, but WYSIPU - What You See Is Pretty Useful.
>
> Details on 
>
>                           Harald
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>  
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 15 12:42:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyBrR-0001EZ-PM; Sun, 15 Jan 2006 12:40:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyBr3-0000xE-76
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 12:39:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21277
	for ; Sun, 15 Jan 2006 12:38:24 -0500 (EST)
Received: from netcore.fi ([193.94.160.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyBym-0000pb-99
	for ietf@ietf.org; Sun, 15 Jan 2006 12:47:50 -0500
Received: from netcore.fi (localhost [127.0.0.1])
	by netcore.fi (8.12.8/8.12.8) with ESMTP id k0FHdUYG008936;
	Sun, 15 Jan 2006 19:39:30 +0200
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0FHdUP0008933;
	Sun, 15 Jan 2006 19:39:30 +0200
Date: Sun, 15 Jan 2006 19:39:30 +0200 (EET)
From: Pekka Savola 
To: Bill Fenner 
In-Reply-To: 
Message-ID: 
References: <01f601c615f4$89f77fa0$640fa8c0@cis.neustar.com>
	
	
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: ClamAV 0.87.1/1242/Sun Jan 15 02:00:41 2006 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-0.6 required=5.0 tests=ALL_TRUSTED,AWL,
	URIBL_WS_SURBL autolearn=ham version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: Paul Hoffman , ietf@ietf.org
Subject: Re: Alternative formats for IDs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Thu, 12 Jan 2006, Bill Fenner wrote:
> On 1/10/06, Paul Hoffman  wrote:
>> Why does this need to be done in the RFCs or Internet Drafts
>> themselves? Why, for example, can't a human with a bit of training
>> extract all the MIBs from the current RFCs and put them into a
>> repository that is machine-accessible?
>
> Something like http://www.icir.org/fenner/mibs/mib-index.html and
> http://www.icir.org/fenner/mibs/extracted/ ?

Now, if there just was somekind of a visual MIB browser on a website 
[1], I'd be very happy.  Maybe something the Tools team could 
investigate...

[1] Based on quick google search, something a bit like:
http://www.freedownloadscenter.com/Network_and_Internet/Network_Management_Tools/Visual_MIBrowser_Pro.html

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 15 12:48:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyBtZ-0002Op-CM; Sun, 15 Jan 2006 12:42:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyBdP-0005XE-Nr
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 12:25:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16811
	for ; Sun, 15 Jan 2006 12:16:28 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExfE0-0004TN-MO
	for ietf@ietf.org; Sat, 14 Jan 2006 01:49:21 -0500
Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net
	[71.106.130.244])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0E6egi24890;
	Fri, 13 Jan 2006 22:40:42 -0800 (PST)
Message-ID: <43C89CE4.9050407@isi.edu>
Date: Fri, 13 Jan 2006 22:40:36 -0800
From: Joe Touch 
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: <200601122336.PAA11557@gra.isi.edu>
	<43C6F2DD.4040108@bbiw.net>	<20060113015434.GD1391@hut.isi.edu>
	<43C80328.9080002@isi.edu>
	
In-Reply-To: 
X-Enigmail-Version: 0.93.0.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: ietf@ietf.org
Subject: Re: A plug for XXE (Re: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0593899194=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0593899194==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigDCA54B08B04B33FE06E9BD74"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDCA54B08B04B33FE06E9BD74
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Harald Tveit Alvestrand wrote:
>=20
>=20
> --On 13. januar 2006 11:44 -0800 Joe Touch  wrote:
>=20
>> This is my impression, from trying to use it as well. I was troubled b=
y
>> 'yet another embedded text system' that necessitated editing source,
>> which seemed like a stone-age throwback when I abandoned such systems =
in
>> the mid 1980s (Scribe, nroff, etc. at the time).
>>
>> While I appreciate that, in theory:
>>
>>     1. there are WYSIWYG XML editors that *can* be loaded with DTDs
>>     2. Word et al. are moving to XML
>=20
> Bill Fenner has made a plugin available for the XMLMind XML Editor that=

> gives you a lot of assistance in writing XML2RFC documents.
>=20
> I haven't used it for "production" yet, but it looks wonderful - not
> WYSIWYG, but WYSIPU - What You See Is Pretty Useful.

Pretty useful compared to text-editing the source code, yes. Compared to
WYSIWYG, still primitive, unfortunately.

If the goal is to allow the output - i.e., the RFC - to be useful for
data mining, why not allow the XML tags to be used *just* for the
portions that we expect to extract (i.e., for the data to be mined), and
let WYSIWYG editors format the rest of the document structure.

I.e., let each tool be used where it works?

That would allow us to generate the documents with whatever editor we
wanted, in whatever format we wanted, so long as the mined data were
extractable as ASCII text *with* XML tags. At that point, the choice of
archive format is decoupled from the decision of the editor, which it
should be IMO.

Joe


--------------enigDCA54B08B04B33FE06E9BD74
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDyJzkE5f5cImnZrsRApYpAKC2/yTzS0Dw0hxG7YpWfYLJ8C9QhQCdH2LO
QAv5rZUznjOfORC7CAridb0=
=+kIP
-----END PGP SIGNATURE-----

--------------enigDCA54B08B04B33FE06E9BD74--


--===============0593899194==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0593899194==--




From ietf-bounces@ietf.org Sun Jan 15 12:51:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyBzU-0006Ct-NR; Sun, 15 Jan 2006 12:48:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyByn-0002Y5-A8
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 12:47:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22685
	for ; Sun, 15 Jan 2006 10:55:11 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exi2S-0003mA-2e
	for ietf@ietf.org; Sat, 14 Jan 2006 04:49:37 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 4F263259711;
	Sat, 14 Jan 2006 10:40:39 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 18558-03; Sat, 14 Jan 2006 10:40:35 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 0E82E25970B;
	Sat, 14 Jan 2006 10:40:34 +0100 (CET)
Date: Sat, 14 Jan 2006 10:35:46 +0100
From: Harald Tveit Alvestrand 
To: Joe Touch 
Message-ID: 
In-Reply-To: <43C89CE4.9050407@isi.edu>
References: <200601122336.PAA11557@gra.isi.edu>
	<43C6F2DD.4040108@bbiw.net>	<20060113015434.GD1391@hut.isi.edu>
	<43C80328.9080002@isi.edu>
	
	<43C89CE4.9050407@isi.edu>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: ietf@ietf.org
Subject: Re: A plug for XXE (Re: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1013513339=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1013513339==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========8746FCC7642BA125681E=========="

--==========8746FCC7642BA125681E==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable



--On 13. januar 2006 22:40 -0800 Joe Touch  wrote:

>> I haven't used it for "production" yet, but it looks wonderful - not
>> WYSIWYG, but WYSIPU - What You See Is Pretty Useful.
>
> Pretty useful compared to text-editing the source code, yes. Compared to
> WYSIWYG, still primitive, unfortunately.
>
> If the goal is to allow the output - i.e., the RFC - to be useful for
> data mining, why not allow the XML tags to be used *just* for the
> portions that we expect to extract (i.e., for the data to be mined), and
> let WYSIWYG editors format the rest of the document structure.
>
> I.e., let each tool be used where it works?

FWIW - I hate WYSIWYG with a passion.
I *never* want to consider pages, fonts, indentation, section numbers or=20
justification when I'm typing. I want to get the text in there, mark=20
clearly where the sections are, make my lists as lists, and *get the text=20
written*.

Then I want to get it readable with minimal effort - and be able to change=20
it later *without* having to guess at the difference between a section=20
heading and a line that just happens to start with a number.

Semantic markup works for me - for the *whole* document.

But YMMV.


--==========8746FCC7642BA125681E==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDyMXyOMj+2+WY0F4RAv1EAJ0SN0Od1n+k+KVusiO6IO8IpSjyUACgwGSw
TTAueHW65b/zvIWLHRPEJYU=
=Q9vE
-----END PGP SIGNATURE-----

--==========8746FCC7642BA125681E==========--



--===============1013513339==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1013513339==--





From ietf-bounces@ietf.org Sun Jan 15 12:53:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyC1x-0008Nd-MT; Sun, 15 Jan 2006 12:51:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyC1W-0005wN-AY
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 12:50:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29143
	for ; Sun, 15 Jan 2006 11:12:12 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExpTg-0007V4-FC
	for ietf@ietf.org; Sat, 14 Jan 2006 12:46:13 -0500
Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net
	[71.106.130.244])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0EHbni29173;
	Sat, 14 Jan 2006 09:37:49 -0800 (PST)
Message-ID: <43C936E6.3010701@isi.edu>
Date: Sat, 14 Jan 2006 09:37:42 -0800
From: Joe Touch 
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: <200601122336.PAA11557@gra.isi.edu>
	<43C6F2DD.4040108@bbiw.net>	<20060113015434.GD1391@hut.isi.edu>
	<43C80328.9080002@isi.edu>
	
	<43C89CE4.9050407@isi.edu>
	
In-Reply-To: 
X-Enigmail-Version: 0.93.0.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: ietf@ietf.org
Subject: Re: A plug for XXE (Re: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1324380877=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1324380877==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig957DFD85C4B73C4454D9991E"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig957DFD85C4B73C4454D9991E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Harald Tveit Alvestrand wrote:
>=20
>=20
> --On 13. januar 2006 22:40 -0800 Joe Touch  wrote:
>=20
>>> I haven't used it for "production" yet, but it looks wonderful - not
>>> WYSIWYG, but WYSIPU - What You See Is Pretty Useful.
>>
>> Pretty useful compared to text-editing the source code, yes. Compared =
to
>> WYSIWYG, still primitive, unfortunately.
>>
>> If the goal is to allow the output - i.e., the RFC - to be useful for
>> data mining, why not allow the XML tags to be used *just* for the
>> portions that we expect to extract (i.e., for the data to be mined), a=
nd
>> let WYSIWYG editors format the rest of the document structure.
>>
>> I.e., let each tool be used where it works?
>=20
> FWIW - I hate WYSIWYG with a passion.
> I *never* want to consider pages, fonts, indentation, section numbers o=
r
> justification when I'm typing. I want to get the text in there, mark
> clearly where the sections are, make my lists as lists, and *get the
> text written*.
>=20
> Then I want to get it readable with minimal effort - and be able to
> change it later *without* having to guess at the difference between a
> section heading and a line that just happens to start with a number.

I agree completely. Everything you're describing is a function of
WYSIWYG with named styles - which is what it has been for 20+ years,
rather than just "make this bold", "make this 12pt". That's the WYSIWYG
I was assuming (style-WYSIWYG?).

Every system I've seen to date for XML tries very hard to approach what
S-WYSIWYG was capable of 20+ years ago. While some XML editors are
certainly better than editing source, it's nowhere near as capable as
S-WYSIWYG.

> Semantic markup works for me - for the *whole* document.

Agreed, but my point is that there's no reason to force each of us to
use a particular semantic markup where the semantics of the result are
not relevant. There's no utility to plowing through all the markup
associated with lists and headings, when that's not what data needs to
be mined.

What I'm proposing is that RFCs use text/PDF/PS as the archived,
authoritative file (sure - we can argue about which of those three, or
maybe others), but that to extract MIBs/authors/references those tags
need to be in the authoritative version, but the others do not.

Joe


--------------enig957DFD85C4B73C4454D9991E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDyTbmE5f5cImnZrsRAqTPAJ4nokf9LF9zBW18Wc3nwxMXaPxItQCgve1F
nXd6of/3pWKsbu0FbVX17fI=
=EWdw
-----END PGP SIGNATURE-----

--------------enig957DFD85C4B73C4454D9991E--


--===============1324380877==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1324380877==--




From ietf-bounces@ietf.org Sun Jan 15 14:01:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyD8S-00085g-9L; Sun, 15 Jan 2006 14:01:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD8Q-00084n-0v
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 14:01:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04936
	for ; Sun, 15 Jan 2006 14:00:25 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyDGA-0006pg-PW
	for ietf@ietf.org; Sun, 15 Jan 2006 14:09:52 -0500
Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net
	[71.106.130.244])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0FJ0qi14187;
	Sun, 15 Jan 2006 11:00:52 -0800 (PST)
Message-ID: <43CA9BDE.7000900@isi.edu>
Date: Sun, 15 Jan 2006 11:00:46 -0800
From: Joe Touch 
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: Elwyn Davies 
References: <200601122336.PAA11557@gra.isi.edu>	<43C6F2DD.4040108@bbiw.net>	<20060113015434.GD1391@hut.isi.edu>	<43C80328.9080002@isi.edu>
	
	<43C8F385.4050204@dial.pipex.com>
In-Reply-To: <43C8F385.4050204@dial.pipex.com>
X-Enigmail-Version: 0.93.0.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: A plug for XXE (Re: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1883001514=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1883001514==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigFE06616DA5D8DC65BBDC3F31"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFE06616DA5D8DC65BBDC3F31
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Elwyn Davies wrote:
> Seconded.
>=20
> I *have* used it for a production run and whilst it is not perfect it
> makes document creation and editing significantly easier than typing
> 'raw' xml even into a syntax-aware text editor.
>=20
> It is also very helpful for proof reading and commenting (spell checker=

> provided).
>=20
> And the standard version is free.. and supported on Windows, Linux and =
Mac.
>=20
> I used to use the Word template but the freedom from hassle of
> generating the final documents

I'm not sure what freedom this means; XML still needs to run through a
script, just as Word does.

> the ease of generating references

Commercial software allows BIBTEX references to be imported into
citation databases, so this is moot as well.

> makes
> xxe/xml2rfc
> and support of complex numbered lists (almost impossible to achieve in
> Word)

I checked your three current I-Ds and five RFCs, and the most complex
numbering I saw was "G1, G2, ...", "P1, P2...", and paragraphs numbered
"G.1:, G.2:...". Word has been able to handle all of these since the
late 1980's. Was there a more complex example I missed, or one in a
pending document that hasn't been issued that you could give as an exampl=
e?

Joe


--------------enigFE06616DA5D8DC65BBDC3F31
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDypveE5f5cImnZrsRAsDyAKCjKSj+qFDO0dfLa9TWLU5gUXQw4wCgyLiR
qSJDuB5YKWmZxveK7UYgmXk=
=GcrJ
-----END PGP SIGNATURE-----

--------------enigFE06616DA5D8DC65BBDC3F31--


--===============1883001514==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1883001514==--




From ietf-bounces@ietf.org Sun Jan 15 15:23:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyEPC-0000tL-IZ; Sun, 15 Jan 2006 15:23:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyEPA-0000tG-UZ
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 15:23:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12656
	for ; Sun, 15 Jan 2006 15:21:50 -0500 (EST)
Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyEWv-0001RM-Sp
	for ietf@ietf.org; Sun, 15 Jan 2006 15:31:16 -0500
Received: from [192.168.0.41] (pool-138-89-39-108.mad.east.verizon.net
	[138.89.39.108]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id
	k0FKN9hi024340
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
	for ; Sun, 15 Jan 2006 15:23:09 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Transfer-Encoding: 7bit
Message-Id: <20A3DCDC-A9BC-4916-9E03-6B985EE02964@cs.columbia.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: ietf@ietf.org
From: Henning Schulzrinne 
Date: Sun, 15 Jan 2006 15:23:01 -0500
X-Mailer: Apple Mail (2.746.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Subject: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

http://www.nmrc.org/pub/present/shmoocon-2006-sn.ppt describes what  
seems to explain the appearance of IETF6x named computer-to-computer  
wireless networks at IETF meetings. Apparently, there is a feature  
that has systems automatically advertise the last AP SSID after  
(involuntary) disconnection. The slides are skimpy on details, but  
provide a bit more background than the usual "turn of ad-hoc mode"  
exhortations at IETF meetings.

Henning

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 15 16:10:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyF9J-0003iN-Dy; Sun, 15 Jan 2006 16:10:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyF9E-0003hq-Lp
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 16:10:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15160
	for ; Sun, 15 Jan 2006 16:09:25 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFH0-000313-TK
	for ietf@ietf.org; Sun, 15 Jan 2006 16:18:52 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id F1B552596D5;
	Sun, 15 Jan 2006 22:09:31 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 15999-09; Sun, 15 Jan 2006 22:09:27 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 0F45B2596CD;
	Sun, 15 Jan 2006 22:09:27 +0100 (CET)
Date: Sun, 15 Jan 2006 22:10:30 +0100
From: Harald Tveit Alvestrand 
To: Henning Schulzrinne , ietf@ietf.org
Message-ID: 
In-Reply-To: <20A3DCDC-A9BC-4916-9E03-6B985EE02964@cs.columbia.edu>
References: <20A3DCDC-A9BC-4916-9E03-6B985EE02964@cs.columbia.edu>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Tangential:
At the IEEE meeting following the IETF, someone asked me "how do I turn off =

ad hoc mode".

I was hard put to find an answer for Windows XP with the standard drivers=20
(I use 2000 and a Cisco driver kit).

Suggestion: Make instructions *with screenshots* of how to turn off ad hoc=20
mode on Windows XP available at the next IETF.

                        Harald


--On s=F8ndag, januar 15, 2006 15:23:01 -0500 Henning Schulzrinne=20
 wrote:

> http://www.nmrc.org/pub/present/shmoocon-2006-sn.ppt describes what
> seems to explain the appearance of IETF6x named computer-to-computer
> wireless networks at IETF meetings. Apparently, there is a feature  that
> has systems automatically advertise the last AP SSID after  (involuntary)
> disconnection. The slides are skimpy on details, but  provide a bit more
> background than the usual "turn of ad-hoc mode"  exhortations at IETF
> meetings.
>
> Henning
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 15 16:36:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyFXx-0000vy-NV; Sun, 15 Jan 2006 16:36:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFXv-0000vH-0s
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 16:36:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16981
	for ; Sun, 15 Jan 2006 16:34:55 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFfh-0003xS-DP
	for ietf@ietf.org; Sun, 15 Jan 2006 16:44:22 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3795475; Sun, 15 Jan 2006 16:33:24 -0500
In-Reply-To: <20A3DCDC-A9BC-4916-9E03-6B985EE02964@cs.columbia.edu>
References: <20A3DCDC-A9BC-4916-9E03-6B985EE02964@cs.columbia.edu>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <63F52A41-F7E8-4A4A-871D-7F8D70922479@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Sun, 15 Jan 2006 16:36:01 -0500
To: Henning Schulzrinne 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This gives a summary :

http://blogs.washingtonpost.com/securityfix/2006/01/windows_feature.html

Regards
Marshall

On Jan 15, 2006, at 3:23 PM, Henning Schulzrinne wrote:

> http://www.nmrc.org/pub/present/shmoocon-2006-sn.ppt describes what  
> seems to explain the appearance of IETF6x named computer-to- 
> computer wireless networks at IETF meetings. Apparently, there is a  
> feature that has systems automatically advertise the last AP SSID  
> after (involuntary) disconnection. The slides are skimpy on  
> details, but provide a bit more background than the usual "turn of  
> ad-hoc mode" exhortations at IETF meetings.
>
> Henning
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 15 16:40:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyFbX-0001tE-Jm; Sun, 15 Jan 2006 16:40:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyFbW-0001sh-1H
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 16:40:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17319
	for ; Sun, 15 Jan 2006 16:38:38 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyFjI-00048i-MZ
	for ietf@ietf.org; Sun, 15 Jan 2006 16:48:05 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3795486; Sun, 15 Jan 2006 16:37:05 -0500
In-Reply-To: 
References: <20A3DCDC-A9BC-4916-9E03-6B985EE02964@cs.columbia.edu>
	
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <2745D979-9BEE-4316-8A09-C64C4680B9D1@multicasttech.com>
Content-Transfer-Encoding: quoted-printable
From: Marshall Eubanks 
Date: Sun, 15 Jan 2006 16:39:29 -0500
To: Harald Tveit Alvestrand 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I think (and suggested to the IAOC) that there should be
an information sheet and / or web site for each meeting with =20
information on how to determine Ad Hoc Mode, how
to turn it off, etc., for all major OS choices.

Regards
Marshall


On Jan 15, 2006, at 4:10 PM, Harald Tveit Alvestrand wrote:

> Tangential:
> At the IEEE meeting following the IETF, someone asked me "how do I =20
> turn off ad hoc mode".
>
> I was hard put to find an answer for Windows XP with the standard =20
> drivers (I use 2000 and a Cisco driver kit).
>
> Suggestion: Make instructions *with screenshots* of how to turn off =20=

> ad hoc mode on Windows XP available at the next IETF.
>
>                        Harald
>
>
> --On s=F8ndag, januar 15, 2006 15:23:01 -0500 Henning Schulzrinne =20
>  wrote:
>
>> http://www.nmrc.org/pub/present/shmoocon-2006-sn.ppt describes what
>> seems to explain the appearance of IETF6x named computer-to-computer
>> wireless networks at IETF meetings. Apparently, there is a =20
>> feature  that
>> has systems automatically advertise the last AP SSID after  =20
>> (involuntary)
>> disconnection. The slides are skimpy on details, but  provide a =20
>> bit more
>> background than the usual "turn of ad-hoc mode"  exhortations at IETF
>> meetings.
>>
>> Henning
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>>
>
>
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 15 17:33:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyGRS-00082c-BC; Sun, 15 Jan 2006 17:33:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyGRP-00082X-UW
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 17:33:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20727
	for ; Sun, 15 Jan 2006 17:32:16 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyGZA-0006BD-Tu
	for ietf@ietf.org; Sun, 15 Jan 2006 17:41:44 -0500
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k0FMXSUI033327
	for ; Sun, 15 Jan 2006 14:33:28 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: <20A3DCDC-A9BC-4916-9E03-6B985EE02964@cs.columbia.edu>
	
Date: Sun, 15 Jan 2006 14:33:25 -0800
To: ietf@ietf.org
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 10:10 PM +0100 1/15/06, Harald Tveit Alvestrand wrote:
>Suggestion: Make instructions *with screenshots* of how to turn off 
>ad hoc mode on Windows XP available at the next IETF.

Given the amount of damage due to time wasted for other participants, 
it might be worthwhile to print it up ahead of time and include it in 
the registration packet. The cost of a ream of paper is small 
relative to the lost productivity this causes. Heck, maybe even put 
it on the IETF web site ahead of time.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 15 18:11:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyH22-0008Sr-HS; Sun, 15 Jan 2006 18:11:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyH20-0008R8-5e
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 18:11:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22793
	for ; Sun, 15 Jan 2006 18:10:04 -0500 (EST)
Received: from a.painless.aaisp.net.uk ([81.187.81.51] helo=smtp.aaisp.net.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyH9m-0007LT-3q
	for ietf@ietf.org; Sun, 15 Jan 2006 18:19:32 -0500
Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43)
	id 1EyH1c-00005g-Dr; Sun, 15 Jan 2006 23:11:04 +0000
Message-ID: <43CAD704.6080005@dial.pipex.com>
Date: Sun, 15 Jan 2006 23:13:08 +0000
From: Elwyn Davies 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Touch 
References: <200601122336.PAA11557@gra.isi.edu>	<43C6F2DD.4040108@bbiw.net>	<20060113015434.GD1391@hut.isi.edu>	<43C80328.9080002@isi.edu>
	
	<43C8F385.4050204@dial.pipex.com> <43CA9BDE.7000900@isi.edu>
In-Reply-To: <43CA9BDE.7000900@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: A plug for XXE (Re: Alternative formats for IDs)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



Joe Touch wrote:

>Elwyn Davies wrote:
>  
>
>>I used to use the Word template but the freedom from hassle of
>>generating the final documents
>>    
>>
>
>I'm not sure what freedom this means; XML still needs to run through a
>script, just as Word does.
>  
>
you can't do it from inside Word and in my experience the Word process 
broke about 80% of the time (mostly due to the generic text printer 
being horribly buggy) but maybe it is better now since I gave up with 
Word some time ago. [Microsoft were never interested in fixing these 
bugs - reducing some lines to heights of a fraction of a point and 
rendering one character per line in an apparently random fashion - and 
they persisted across multiple releases of Word.]

>  
>
>>the ease of generating references
>>    
>>
>
>Commercial software allows BIBTEX references to be imported into
>citation databases, so this is moot as well.
>
>  
>
I am sure I could buy some tools but how well integrated with Word would 
this be and how much would it cost me?

>>makes
>>xxe/xml2rfc
>>and support of complex numbered lists (almost impossible to achieve in
>>Word)
>>    
>>
>
>I checked your three current I-Ds and five RFCs, and the most complex
>numbering I saw was "G1, G2, ...", "P1, P2...", and paragraphs numbered
>"G.1:, G.2:...". Word has been able to handle all of these since the
>late 1980's. Was there a more complex example I missed, or one in a
>pending document that hasn't been issued that you could give as an example?
>  
>

In theory.. my experience was that multiple sets of numbered paragraphs 
spread across sections was painful and error prone.

But ultimately it was just the level of repeated niggles and panics when 
conversion fails close to the I-D deadline that I don't get with xml2rfc 
and especially with xxe.

Don't let me stop you using Word but I know which set of tools I prefer.

Elwyn

>Joe
>
>  
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 15 21:01:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyJh1-00051G-Ji; Sun, 15 Jan 2006 21:01:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyJgz-0004zQ-Lx
	for ietf@megatron.ietf.org; Sun, 15 Jan 2006 21:01:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01963
	for ; Sun, 15 Jan 2006 21:00:32 -0500 (EST)
Received: from monster.hopcount.ca ([199.212.90.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyJom-0004mU-5c
	for ietf@ietf.org; Sun, 15 Jan 2006 21:10:03 -0500
Received: from yxu1a20.hopcount.ca ([199.212.90.20])
	by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.60 (FreeBSD)) (envelope-from )
	id 1EyJgU-000Lkz-3L; Mon, 16 Jan 2006 02:01:26 +0000
In-Reply-To: 
References: <20A3DCDC-A9BC-4916-9E03-6B985EE02964@cs.columbia.edu>
	
	
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <75886FCC-16BF-42EF-A0B4-4F9AE32211B6@isc.org>
Content-Transfer-Encoding: 7bit
From: Joe Abley 
Date: Sun, 15 Jan 2006 21:01:23 -0500
To: Paul Hoffman 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On 15-Jan-2006, at 17:33, Paul Hoffman wrote:

> At 10:10 PM +0100 1/15/06, Harald Tveit Alvestrand wrote:
>> Suggestion: Make instructions *with screenshots* of how to turn  
>> off ad hoc mode on Windows XP available at the next IETF.
>
> Given the amount of damage due to time wasted for other  
> participants, it might be worthwhile to print it up ahead of time  
> and include it in the registration packet.

I'd go further and confiscate the laptops of those who persist in  
creating ad-hoc networks. And destroy the hardware either by way of  
controlled explosion, or by impaling it on large spikes around the  
bar and letting it serve as a warning to others.

Maybe some of each, in the interests of variety.


Joe


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 16 05:15:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyROc-0005QI-8f; Mon, 16 Jan 2006 05:15:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyROa-0005QD-Il
	for ietf@megatron.ietf.org; Mon, 16 Jan 2006 05:15:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00228
	for ; Mon, 16 Jan 2006 05:14:04 -0500 (EST)
Received: from mtagate2.uk.ibm.com ([195.212.29.135])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyRWS-0002mj-FS
	for ietf@ietf.org; Mon, 16 Jan 2006 05:23:39 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0GAEnoM195628
	for ; Mon, 16 Jan 2006 10:14:54 GMT
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com
	[9.149.37.216])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0GAEmGN164706 for ; Mon, 16 Jan 2006 10:14:49 GMT
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0GAEmmY016735 for ; Mon, 16 Jan 2006 10:14:48 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0GAEmh9016723 for ; Mon, 16 Jan 2006 10:14:48 GMT
Received: from zurich.ibm.com (sig-9-145-131-198.de.ibm.com [9.145.131.198])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA65336
	for ; Mon, 16 Jan 2006 11:14:47 +0100
Message-ID: <43CB7218.1020008@zurich.ibm.com>
Date: Mon, 16 Jan 2006 11:14:48 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: IETF discussion list 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Subject: An important day for the IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Greetings,

The first IETF meeting took place 20 years ago today,
on January 16th, 1986, in San Diego, California. There were
21 attendees and Mike Corrigan was in the chair.

The IETF has come a long way since then. We'll celebrate
this in fine style during the 65th IETF meeting in
Dallas, Texas from March 19 to 24, 2006.

    Brian Carpenter
    IETF Chair No. 6



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 16 06:42:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EySko-0001oJ-5T; Mon, 16 Jan 2006 06:42:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EySkj-0001nS-Lh
	for ietf@megatron.ietf.org; Mon, 16 Jan 2006 06:42:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05402
	for ; Mon, 16 Jan 2006 06:41:01 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EySsb-0005EM-Ie
	for ietf@ietf.org; Mon, 16 Jan 2006 06:50:36 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 615572596E6;
	Mon, 16 Jan 2006 12:41:09 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 09878-02; Mon, 16 Jan 2006 12:41:05 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 2B1C02596E5;
	Mon, 16 Jan 2006 12:41:05 +0100 (CET)
Date: Mon, 16 Jan 2006 12:30:13 +0100
From: Harald Tveit Alvestrand 
To: Brian E Carpenter ,
	IETF discussion list 
Message-ID: 
In-Reply-To: <43CB7218.1020008@zurich.ibm.com>
References: <43CB7218.1020008@zurich.ibm.com>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: 
Subject: Re: An important day for the IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0767794831=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============0767794831==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========268C7176261DE63FBC77=========="

--==========268C7176261DE63FBC77==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Happy birthday, IETF!

And remember to raise an extra toast to Mike St. Johns, who should be=20
coming to his 63rd or so IETF meeting in Dallas..... for some of us, this=20
has gotten to be a habit!

Wonder how many of the original 21 are still around????

             Harald, attendee since #22 (but missed #29)

--On 16. januar 2006 11:14 +0100 Brian E Carpenter =20
wrote:

> Greetings,
>
> The first IETF meeting took place 20 years ago today,
> on January 16th, 1986, in San Diego, California. There were
> 21 attendees and Mike Corrigan was in the chair.
>
> The IETF has come a long way since then. We'll celebrate
> this in fine style during the 65th IETF meeting in
> Dallas, Texas from March 19 to 24, 2006.
>
>     Brian Carpenter
>     IETF Chair No. 6
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
>




--==========268C7176261DE63FBC77==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDy4PFOMj+2+WY0F4RAma+AKChYHq2UGbqJ1Ar30y4bl0gEA8dogCg2Wol
Rao3d/feqvZLR1TNJTKCSp8=
=ie0G
-----END PGP SIGNATURE-----

--==========268C7176261DE63FBC77==========--



--===============0767794831==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0767794831==--





From ietf-bounces@ietf.org Mon Jan 16 09:39:49 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyVWP-0007qk-Bk; Mon, 16 Jan 2006 09:39:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyVWM-0007py-RM
	for ietf@megatron.ietf.org; Mon, 16 Jan 2006 09:39:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17055
	for ; Mon, 16 Jan 2006 09:38:22 -0500 (EST)
Received: from mercury.lcs.mit.edu ([18.26.0.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyVeH-0003u0-Pz
	for ietf@ietf.org; Mon, 16 Jan 2006 09:47:58 -0500
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178)
	id 1110586AEE; Mon, 16 Jan 2006 09:39:36 -0500 (EST)
To: ietf@ietf.org
Message-Id: <20060116143936.1110586AEE@mercury.lcs.mit.edu>
Date: Mon, 16 Jan 2006 09:39:36 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: An important day for the IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

    > From: Harald Tveit Alvestrand 

    > Wonder how many of the original 21 are still around????

You rang? :-)

	Noel

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 16 10:00:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyVqT-0006AG-8B; Mon, 16 Jan 2006 10:00:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyVqR-0006A7-9z
	for ietf@megatron.ietf.org; Mon, 16 Jan 2006 10:00:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18679
	for ; Mon, 16 Jan 2006 09:59:07 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyVyJ-0004rS-Tc
	for ietf@ietf.org; Mon, 16 Jan 2006 10:08:44 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id B65882596C7;
	Mon, 16 Jan 2006 15:59:13 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 14873-01; Mon, 16 Jan 2006 15:59:09 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 0F63C2596EA;
	Mon, 16 Jan 2006 15:59:09 +0100 (CET)
Date: Mon, 16 Jan 2006 16:00:12 +0100
From: Harald Tveit Alvestrand 
To: Noel Chiappa , ietf@ietf.org
Message-ID: <64C91C00D46DC52AA27AF3EB@svartdal.hjemme.alvestrand.no>
In-Reply-To: <20060116143936.1110586AEE@mercury.lcs.mit.edu>
References: <20060116143936.1110586AEE@mercury.lcs.mit.edu>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: An important day for the IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On mandag, januar 16, 2006 09:39:36 -0500 Noel Chiappa 
 wrote:

>     > From: Harald Tveit Alvestrand 
>
>     > Wonder how many of the original 21 are still around????
>
> You rang? :-)

That's one :-)

The minutes of the first meeting are now online (scanned PDF)(!), and there 
the attendees are listed as:

Braun, Hans-Werner
Bresica, Mike
Callon, Ross
Chiappa, Noel
Eldridge, Charles
Gross, Phill
Hinden, Robert
Mathis, James
Mills, David
Nagle, John
Natalie, Ronald
Rokitansky, Carl
Shacham, Nachum
Su, Zaw-Sing
Topolcic, Claudio
Zhang, Lixia

Clark, David
Corrigan, Mike
Deering, Steve
Means, Robert
St. Johns, Mike

The only email address that *might* still work is Hans-Werner Braun's.... 
none of the others have FQDNs.....



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 16 10:30:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyWJi-0006R9-6m; Mon, 16 Jan 2006 10:30:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyWJg-0006R4-AK
	for ietf@megatron.ietf.org; Mon, 16 Jan 2006 10:30:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20594
	for ; Mon, 16 Jan 2006 10:29:20 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyWRc-0006Fw-6D
	for ietf@ietf.org; Mon, 16 Jan 2006 10:38:57 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1EyWJO-0008Il-Rv; Mon, 16 Jan 2006 07:30:27 -0800
Message-Id: <6.2.3.4.2.20060116151422.0395e2b0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Mon, 16 Jan 2006 16:30:13 +0100
To: Harald Tveit Alvestrand ,
	Brian E Carpenter ,
	IETF discussion list 
From: "JFC (Jefsey) Morfin" 
In-Reply-To: 
References: <43CB7218.1020008@zurich.ibm.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: 
Subject: Re: An important day for the IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 12:30 16/01/2006, Harald Tveit Alvestrand wrote:
>Happy birthday, IETF!

Dear Harald,
you are right, happy birthday! An impressive continuity we should 
strive to protect. In avoiding the status quo that some stakeholders 
may favor, and areas outside of network engineering (such as 
linguistic and country political definition :-)).

>Wonder how many of the original 21 are still around????
>Harald, attendee since #22 (but missed #29)

Impressive. My own agenda that sad fortnight might help better 
understand the past, present and future of the network.

- on 12-15 January 1986 I attended the eight Telecommunications 
Council Eighth Annual Conference at he Hawaiian Regent Hotel in 
Honolulu. The theme was  "Evolution of the Digital Pacific". Audience 
was probably 200 to 300 people. I had a lunch there with two lady 
training consultant for the US Army TV network, to discuss how to 
support their program on packet switch network, with Compression Lab tools.
- on the 16 I had a diner at the Bonaventure (LA) with Father Bourret 
(http://www.kuangchi.com/english/history.htm). On the agenda: packet 
switching in TW and a Vatican State International Packet Switch Gateway
- then I brought international data services experience in meetings 
with an LA based Bank and for a complete turn-key online banking 
service to a group NY banks. Multi-currency accounts, ATM 
connections. I explained our experience with air-line reservation 
services for most of the major airlines, hotels chains and 
rent-a-cars, and how it worked at regular Travel Agents using a 
service you would call a smart OPES today.
- met with Mobil Oil international communications manager (NY) and 
routine meetings with the International Carriers. I was in Washington 
on the 28th.

We used to refer to ARPANET as the "grand father" :-). Minitel users 
were probably already 3 millions in France, plus Prestel in UK, plus 
Germany, etc.. Over these 20 years since these Tymnet times, OSI, 
then the Internet made us to step from 7+ to 70+ to 700+ millions of 
active users worldwide.

But you may understand why I feel the architectural evolution is 
sometimes dismaying and why constraints and rigidity cannot bring 
innovation and expansion. We need now another technology leap frog 
towards the 7+ billions users.

Only a multilingual, multinational, multilateral, multitechnology, 
multiservice continuity architecture can deliver now.
Good luck to everyone for the next decade which will be decisive.

I do hope you will permit it to be in cooperation with the IGF,. That 
we can proceed fast on a stable, reasonable and acceptable equal 
opportunity but competitive fair basis. As we all agreed in Tunis.
jfc






_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 16 11:40:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyXPN-0000br-4b; Mon, 16 Jan 2006 11:40:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyXPK-0000bj-4z
	for ietf@megatron.ietf.org; Mon, 16 Jan 2006 11:40:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25845
	for ; Mon, 16 Jan 2006 11:39:14 -0500 (EST)
Received: from handynerds.com ([207.234.208.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyXXE-0000q5-GQ
	for ietf@ietf.org; Mon, 16 Jan 2006 11:48:51 -0500
Received: from apache by HandyNerds.com with local (Exim 4.41)
	id 1EyXPM-0002tf-EH; Mon, 16 Jan 2006 11:40:40 -0500
Received: from pool-71-126-159-30.washdc.fios.verizon.net ([71.126.159.30])
	(SquirrelMail authenticated user bthorson);
	by www.handynerds.com with HTTP;
	Mon, 16 Jan 2006 11:40:40 -0500 (EST)
Message-ID: <63740.71.126.159.30.1137429640.squirrel@71.126.159.30>
In-Reply-To: 
References: 
Date: Mon, 16 Jan 2006 11:40:40 -0500 (EST)
From: "Brett Thorson" 
To: "Paul Hoffman" 
User-Agent: SquirrelMail/1.4.3a-0.f1.1
X-Mailer: SquirrelMail/1.4.3a-0.f1.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 8bit
Cc: ietf@ietf.org
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@handynerds.com
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

2 parts to this message, read it all for twice the fun :-)

> Given the amount of damage due to time wasted for other participants,
> it might be worthwhile to print it up ahead of time and include it in
> the registration packet. The cost of a ream of paper is small
> relative to the lost productivity this causes. Heck, maybe even put
> it on the IETF web site ahead of time.
>
> --Paul Hoffman, Director
> --VPN Consortium

1----Wireless at IETF----

We tried this once.  It is hard to determine how well it worked because if
they fixed it, we didn't know about it (as they blended in to the
background infrastructure).

Seems to me that most of the people running in ad-hoc mode don't even know
it (thus, why bother to read the sheet).

Continuing along those lines, sometimes Working Groups have been known to
put MAC Addresses on the screens of people in the room (running ad-hoc). 
I don't know how much success this has either, as the networks still stay
up and running.

I'll see if I can dig out the "How to turn off ad-hoc mode" sheet from a
few meetings back and send it to the upcoming hosts.

We have tried to solve some of these problems by taking the MAC addresses
of those doing mean things to the net, and stuffing them in a "Penalty
Box" so they would come down to the terminal room, and we could track them
to a switch port.  I actually think this worked pretty darn well.

Much of the problem was (wo)man power.  We didn't have enough people to
run the network, and enough left over for a brute squad.

Hopefully with more companies coming back to host the networks (YAY, Thank
you!!) we can start doing cool things like this again.

2----Ad-Hoc mode in airports/airplanes

So at the talk that started all of this at shmoocon (I haven't reviewed
the slides, I'm just going from what I remember from the talk).  A few
extra notes.

The issue was ad-hoc mode on the W-NIC and the goofy 169 address you get
from 3927.  Microsoft said they would patch this in their next service
pack.  Patch the fact that you get the auto address or work to disable
ad-hoc.  Chances are that it would be the auto address.  (So then you
setup a DHCP server, also mentioned in the talk, and you are back to
square 1)

MS was there and a rep. said that it was made so you and a bunch of your
co-workers could walk outside of the building at lunch with your laptops,
and the network still appears to work.  I'm guessing he is going off of
the fact you would only share networking interests with your buddies,
unless they are coming up with some kind of link local grid that has one
card acting as a bridge back to to the main network implementation.  (Pure
speculation)

Simple Nomad also discussed during the presentation that he was tinkering
with his (recalling from my full brain from the weekend) Palm OS, and this
it may also have a problem too.  (Add another doc to the IETF packet)

Anyway to sum all of this up, some of the people he was playing with were
on the plane and unpatched.  While I hope & expect (more hope I guess)
that the people at an IETF meeting are more saavy than the plane riders,
can you imagine walking up to one of these people and handing them a note
on how to turn of ad-hoc networking on their wireless lan card?  I'd
imagine you would get a response similar to handing them a document on how
to engage the CAT 3 ILS and land the plane.  Simple if you know what you
are doing, totally alien if you don't.

Cheers!

--Brett

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 16 13:46:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyZNO-0002PA-Bf; Mon, 16 Jan 2006 13:46:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyZNM-0002P4-DN
	for ietf@megatron.ietf.org; Mon, 16 Jan 2006 13:46:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05739
	for ; Mon, 16 Jan 2006 13:45:19 -0500 (EST)
Received: from fiji.merit.edu ([198.108.1.12])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyZVK-0005XZ-2P
	for ietf@ietf.org; Mon, 16 Jan 2006 13:54:59 -0500
Received: from localhost (localhost [127.0.0.1])
	by fiji.merit.edu (Postfix) with ESMTP id 1BF8E1851;
	Mon, 16 Jan 2006 13:46:42 -0500 (EST)
Received: from fiji.merit.edu ([127.0.0.1])
	by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 25512-02; Mon, 16 Jan 2006 13:46:41 -0500 (EST)
Received: from ablate.merit.edu (ablate.merit.edu [198.108.62.151])
	by fiji.merit.edu (Postfix) with ESMTP id CB40912E1;
	Mon, 16 Jan 2006 13:46:41 -0500 (EST)
From: "Larry J. Blunk" 
Organization: Merit Network
To: ietf@ietf.org
Date: Mon, 16 Jan 2006 13:46:39 -0500
User-Agent: KMail/1.8.2
References: <20060116143936.1110586AEE@mercury.lcs.mit.edu>
	<64C91C00D46DC52AA27AF3EB@svartdal.hjemme.alvestrand.no>
In-Reply-To: <64C91C00D46DC52AA27AF3EB@svartdal.hjemme.alvestrand.no>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200601161346.39630.ljb@merit.edu>
X-Virus-Scanned: amavisd-new at merit.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand ,
	Noel Chiappa 
Subject: Re: An important day for the IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ljb@merit.edu
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Monday 16 January 2006 10:00, Harald Tveit Alvestrand wrote:
> 
> --On mandag, januar 16, 2006 09:39:36 -0500 Noel Chiappa 
>  wrote:
> 
> >     > From: Harald Tveit Alvestrand 
> >
> >     > Wonder how many of the original 21 are still around????
> >
> > You rang? :-)
> 
> That's one :-)
> 

   The first IETF chair seems to have made a foray into politics --
http://www.gcn.com/vol19_no14/community/2133-1.html

    Since I could find no record of a Congressman Mike Corrigan, I assume
he lost the race   :)

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 16 14:51:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyaOI-0006Mn-H9; Mon, 16 Jan 2006 14:51:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyaOF-0006Mc-52
	for ietf@megatron.ietf.org; Mon, 16 Jan 2006 14:51:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10638
	for ; Mon, 16 Jan 2006 14:50:18 -0500 (EST)
Received: from eastrmmtao03.cox.net ([68.230.240.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyaWE-0007rS-5D
	for ietf@ietf.org; Mon, 16 Jan 2006 14:59:58 -0500
Received: from Home1 ([68.98.162.248]) by eastrmmtao03.cox.net
	(InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP
	id <20060116195135.GJXV29285.eastrmmtao03.cox.net@Home1>
	for ; Mon, 16 Jan 2006 14:51:35 -0500
Message-ID: <003101c61ad6$3e53f150$01061f0a@Home1>
From: "Patrice Lyons" 
To: 
References: <20060116154032.GSGZ12737.eastrmmtai02.cox.net@EastRMIMPI02>
Date: Mon, 16 Jan 2006 14:51:26 -0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba
Content-Transfer-Encoding: 7bit
Subject: Re: Ietf Digest, Vol 21, Issue 63
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bob,

They are talking about the first IETF meeting as taking place on Jan. 16, 
1986.  What about the IETF meeting as one of the several task forces that 
Barry Leiner put together while you were still at DARPA?  There was also the 
working group series that preceded the IETF.  I recall that Jon Postel had 
kept the records of this work on the early Internet.  Also, do you plan to 
go to Dallas?  The last message to Harold mentions some agreement reached at 
Tunis with respect to IETF work with the to be formed Internet Governance 
Forum (at least I think that is what it is going to be called) (see early 
work on it at http://www.intgovforum.org/.

Patrice
----- Original Message ----- 
From: 
To: 
Sent: Monday, January 16, 2006 10:40 AM
Subject: Ietf Digest, Vol 21, Issue 63


> ------------------------------
>
> Message: 6
> Date: Mon, 16 Jan 2006 11:14:48 +0100
> From: Brian E Carpenter 
> Subject: An important day for the IETF
> To: IETF discussion list 
> Message-ID: <43CB7218.1020008@zurich.ibm.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Greetings,
>
> The first IETF meeting took place 20 years ago today,
> on January 16th, 1986, in San Diego, California. There were
> 21 attendees and Mike Corrigan was in the chair.
>
> The IETF has come a long way since then. We'll celebrate
> this in fine style during the 65th IETF meeting in
> Dallas, Texas from March 19 to 24, 2006.
>
>    Brian Carpenter
>    IETF Chair No. 6
>
> ------------------------------
>
> Message: 7
> Date: Mon, 16 Jan 2006 12:30:13 +0100
> From: Harald Tveit Alvestrand 
> Subject: Re: An important day for the IETF
> To: Brian E Carpenter , IETF discussion list
> 
> Message-ID: 
> Content-Type: text/plain; charset="us-ascii"
>
> Happy birthday, IETF!
>
> And remember to raise an extra toast to Mike St. Johns, who should be
> coming to his 63rd or so IETF meeting in Dallas..... for some of us, this
> has gotten to be a habit!
>
> Wonder how many of the original 21 are still around????
>
>             Harald, attendee since #22 (but missed #29)
>
> --On 16. januar 2006 11:14 +0100 Brian E Carpenter 
> wrote:
>
>> Greetings,
>>
>> The first IETF meeting took place 20 years ago today,
>> on January 16th, 1986, in San Diego, California. There were
>> 21 attendees and Mike Corrigan was in the chair.
>>
>> The IETF has come a long way since then. We'll celebrate
>> this in fine style during the 65th IETF meeting in
>> Dallas, Texas from March 19 to 24, 2006.
>>
>>     Brian Carpenter
>>     IETF Chair No. 6
>>
>>
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>>
>>
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 16 Jan 2006 16:00:12 +0100
> From: Harald Tveit Alvestrand 
> Subject: Re: An important day for the IETF
> To: Noel Chiappa , ietf@ietf.org
> Message-ID: <64C91C00D46DC52AA27AF3EB@svartdal.hjemme.alvestrand.no>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
>
>
> --On mandag, januar 16, 2006 09:39:36 -0500 Noel Chiappa
>  wrote:
>
>>     > From: Harald Tveit Alvestrand 
>>
>>     > Wonder how many of the original 21 are still around????
>>
>> You rang? :-)
>
> That's one :-)
>
> The minutes of the first meeting are now online (scanned PDF)(!), and 
> there
> the attendees are listed as:
>
> Braun, Hans-Werner
> Bresica, Mike
> Callon, Ross
> Chiappa, Noel
> Eldridge, Charles
> Gross, Phill
> Hinden, Robert
> Mathis, James
> Mills, David
> Nagle, John
> Natalie, Ronald
> Rokitansky, Carl
> Shacham, Nachum
> Su, Zaw-Sing
> Topolcic, Claudio
> Zhang, Lixia
>
> Clark, David
> Corrigan, Mike
> Deering, Steve
> Means, Robert
> St. Johns, Mike
>
> The only email address that *might* still work is Hans-Werner Braun's....
> none of the others have FQDNs.....
>
>
>
>
>
> ------------------------------
>
> Message: 10
> Date: Mon, 16 Jan 2006 16:30:13 +0100
> From: "JFC (Jefsey) Morfin" 
> Subject: Re: An important day for the IETF
> To: Harald Tveit Alvestrand , Brian E Carpenter
> , IETF discussion list 
> Message-ID: <6.2.3.4.2.20060116151422.0395e2b0@mail.jefsey.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> At 12:30 16/01/2006, Harald Tveit Alvestrand wrote:
>>Happy birthday, IETF!
>
> Dear Harald,
> you are right, happy birthday! An impressive continuity we should
> strive to protect. In avoiding the status quo that some stakeholders
> may favor, and areas outside of network engineering (such as
> linguistic and country political definition :-)).
>
>>Wonder how many of the original 21 are still around????
>>Harald, attendee since #22 (but missed #29)
>
> Impressive. My own agenda that sad fortnight might help better
> understand the past, present and future of the network.
>
> - on 12-15 January 1986 I attended the eight Telecommunications
> Council Eighth Annual Conference at he Hawaiian Regent Hotel in
> Honolulu. The theme was  "Evolution of the Digital Pacific". Audience
> was probably 200 to 300 people. I had a lunch there with two lady
> training consultant for the US Army TV network, to discuss how to
> support their program on packet switch network, with Compression Lab 
> tools.
> - on the 16 I had a diner at the Bonaventure (LA) with Father Bourret
> (http://www.kuangchi.com/english/history.htm). On the agenda: packet
> switching in TW and a Vatican State International Packet Switch Gateway
> - then I brought international data services experience in meetings
> with an LA based Bank and for a complete turn-key online banking
> service to a group NY banks. Multi-currency accounts, ATM
> connections. I explained our experience with air-line reservation
> services for most of the major airlines, hotels chains and
> rent-a-cars, and how it worked at regular Travel Agents using a
> service you would call a smart OPES today.
> - met with Mobil Oil international communications manager (NY) and
> routine meetings with the International Carriers. I was in Washington
> on the 28th.
>
> We used to refer to ARPANET as the "grand father" :-). Minitel users
> were probably already 3 millions in France, plus Prestel in UK, plus
> Germany, etc.. Over these 20 years since these Tymnet times, OSI,
> then the Internet made us to step from 7+ to 70+ to 700+ millions of
> active users worldwide.
>
> But you may understand why I feel the architectural evolution is
> sometimes dismaying and why constraints and rigidity cannot bring
> innovation and expansion. We need now another technology leap frog
> towards the 7+ billions users.
>
> Only a multilingual, multinational, multilateral, multitechnology,
> multiservice continuity architecture can deliver now.
> Good luck to everyone for the next decade which will be decisive.
>
> I do hope you will permit it to be in cooperation with the IGF,. That
> we can proceed fast on a stable, reasonable and acceptable equal
> opportunity but competitive fair basis. As we all agreed in Tunis.
> jfc
>
> 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 16 15:12:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyaiF-00044y-Cm; Mon, 16 Jan 2006 15:12:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyaiD-00044f-3J
	for ietf@megatron.ietf.org; Mon, 16 Jan 2006 15:12:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12047
	for ; Mon, 16 Jan 2006 15:10:55 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyaqC-0000ME-48
	for ietf@ietf.org; Mon, 16 Jan 2006 15:20:36 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3798018; Mon, 16 Jan 2006 15:09:23 -0500
In-Reply-To: <003101c61ad6$3e53f150$01061f0a@Home1>
References: <20060116154032.GSGZ12737.eastrmmtai02.cox.net@EastRMIMPI02>
	<003101c61ad6$3e53f150$01061f0a@Home1>
Mime-Version: 1.0 (Apple Message framework v746.2)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <764D3B99-9E59-4E22-958E-14EA4050D28A@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Mon, 16 Jan 2006 15:12:10 -0500
To: "Patrice Lyons" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Ietf Digest, Vol 21, Issue 63
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

While we are on the subject, in the archives of the IETF there are  
proceedings of one Internet Architecture Task Force meeting, in May,  
1986.

Can anyone fill me in on this entity and what happened to it ?

Regards
Marshall Eubanks

On Jan 16, 2006, at 2:51 PM, Patrice Lyons wrote:

> Bob,
>
> They are talking about the first IETF meeting as taking place on  
> Jan. 16, 1986.  What about the IETF meeting as one of the several  
> task forces that Barry Leiner put together while you were still at  
> DARPA?  There was also the working group series that preceded the  
> IETF.  I recall that Jon Postel had kept the records of this work  
> on the early Internet.  Also, do you plan to go to Dallas?  The  
> last message to Harold mentions some agreement reached at Tunis  
> with respect to IETF work with the to be formed Internet Governance  
> Forum (at least I think that is what it is going to be called) (see  
> early work on it at http://www.intgovforum.org/.
>
> Patrice
> ----- Original Message ----- From: 
> To: 
> Sent: Monday, January 16, 2006 10:40 AM
> Subject: Ietf Digest, Vol 21, Issue 63
>
>
>> ------------------------------
>>
>> Message: 6
>> Date: Mon, 16 Jan 2006 11:14:48 +0100
>> From: Brian E Carpenter 
>> Subject: An important day for the IETF
>> To: IETF discussion list 
>> Message-ID: <43CB7218.1020008@zurich.ibm.com>
>> Content-Type: text/plain; charset=us-ascii; format=flowed
>>
>> Greetings,
>>
>> The first IETF meeting took place 20 years ago today,
>> on January 16th, 1986, in San Diego, California. There were
>> 21 attendees and Mike Corrigan was in the chair.
>>
>> The IETF has come a long way since then. We'll celebrate
>> this in fine style during the 65th IETF meeting in
>> Dallas, Texas from March 19 to 24, 2006.
>>
>>    Brian Carpenter
>>    IETF Chair No. 6
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Mon, 16 Jan 2006 12:30:13 +0100
>> From: Harald Tveit Alvestrand 
>> Subject: Re: An important day for the IETF
>> To: Brian E Carpenter , IETF discussion list
>> 
>> Message-ID: 
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Happy birthday, IETF!
>>
>> And remember to raise an extra toast to Mike St. Johns, who should be
>> coming to his 63rd or so IETF meeting in Dallas..... for some of  
>> us, this
>> has gotten to be a habit!
>>
>> Wonder how many of the original 21 are still around????
>>
>>             Harald, attendee since #22 (but missed #29)
>>
>> --On 16. januar 2006 11:14 +0100 Brian E Carpenter  
>> 
>> wrote:
>>
>>> Greetings,
>>>
>>> The first IETF meeting took place 20 years ago today,
>>> on January 16th, 1986, in San Diego, California. There were
>>> 21 attendees and Mike Corrigan was in the chair.
>>>
>>> The IETF has come a long way since then. We'll celebrate
>>> this in fine style during the 65th IETF meeting in
>>> Dallas, Texas from March 19 to 24, 2006.
>>>
>>>     Brian Carpenter
>>>     IETF Chair No. 6
>>>
>>>
>>>
>>> _______________________________________________
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ietf
>>>
>>>
>>
>>
>> ------------------------------
>>
>> Message: 9
>> Date: Mon, 16 Jan 2006 16:00:12 +0100
>> From: Harald Tveit Alvestrand 
>> Subject: Re: An important day for the IETF
>> To: Noel Chiappa , ietf@ietf.org
>> Message-ID: <64C91C00D46DC52AA27AF3EB@svartdal.hjemme.alvestrand.no>
>> Content-Type: text/plain; charset=us-ascii; format=flowed
>>
>>
>>
>> --On mandag, januar 16, 2006 09:39:36 -0500 Noel Chiappa
>>  wrote:
>>
>>>     > From: Harald Tveit Alvestrand 
>>>
>>>     > Wonder how many of the original 21 are still around????
>>>
>>> You rang? :-)
>>
>> That's one :-)
>>
>> The minutes of the first meeting are now online (scanned PDF)(!),  
>> and there
>> the attendees are listed as:
>>
>> Braun, Hans-Werner
>> Bresica, Mike
>> Callon, Ross
>> Chiappa, Noel
>> Eldridge, Charles
>> Gross, Phill
>> Hinden, Robert
>> Mathis, James
>> Mills, David
>> Nagle, John
>> Natalie, Ronald
>> Rokitansky, Carl
>> Shacham, Nachum
>> Su, Zaw-Sing
>> Topolcic, Claudio
>> Zhang, Lixia
>>
>> Clark, David
>> Corrigan, Mike
>> Deering, Steve
>> Means, Robert
>> St. Johns, Mike
>>
>> The only email address that *might* still work is Hans-Werner  
>> Braun's....
>> none of the others have FQDNs.....
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 10
>> Date: Mon, 16 Jan 2006 16:30:13 +0100
>> From: "JFC (Jefsey) Morfin" 
>> Subject: Re: An important day for the IETF
>> To: Harald Tveit Alvestrand , Brian E Carpenter
>> , IETF discussion list 
>> Message-ID: <6.2.3.4.2.20060116151422.0395e2b0@mail.jefsey.com>
>> Content-Type: text/plain; charset="us-ascii"; format=flowed
>>
>> At 12:30 16/01/2006, Harald Tveit Alvestrand wrote:
>>> Happy birthday, IETF!
>>
>> Dear Harald,
>> you are right, happy birthday! An impressive continuity we should
>> strive to protect. In avoiding the status quo that some stakeholders
>> may favor, and areas outside of network engineering (such as
>> linguistic and country political definition :-)).
>>
>>> Wonder how many of the original 21 are still around????
>>> Harald, attendee since #22 (but missed #29)
>>
>> Impressive. My own agenda that sad fortnight might help better
>> understand the past, present and future of the network.
>>
>> - on 12-15 January 1986 I attended the eight Telecommunications
>> Council Eighth Annual Conference at he Hawaiian Regent Hotel in
>> Honolulu. The theme was  "Evolution of the Digital Pacific". Audience
>> was probably 200 to 300 people. I had a lunch there with two lady
>> training consultant for the US Army TV network, to discuss how to
>> support their program on packet switch network, with Compression  
>> Lab tools.
>> - on the 16 I had a diner at the Bonaventure (LA) with Father Bourret
>> (http://www.kuangchi.com/english/history.htm). On the agenda: packet
>> switching in TW and a Vatican State International Packet Switch  
>> Gateway
>> - then I brought international data services experience in meetings
>> with an LA based Bank and for a complete turn-key online banking
>> service to a group NY banks. Multi-currency accounts, ATM
>> connections. I explained our experience with air-line reservation
>> services for most of the major airlines, hotels chains and
>> rent-a-cars, and how it worked at regular Travel Agents using a
>> service you would call a smart OPES today.
>> - met with Mobil Oil international communications manager (NY) and
>> routine meetings with the International Carriers. I was in Washington
>> on the 28th.
>>
>> We used to refer to ARPANET as the "grand father" :-). Minitel users
>> were probably already 3 millions in France, plus Prestel in UK, plus
>> Germany, etc.. Over these 20 years since these Tymnet times, OSI,
>> then the Internet made us to step from 7+ to 70+ to 700+ millions of
>> active users worldwide.
>>
>> But you may understand why I feel the architectural evolution is
>> sometimes dismaying and why constraints and rigidity cannot bring
>> innovation and expansion. We need now another technology leap frog
>> towards the 7+ billions users.
>>
>> Only a multilingual, multinational, multilateral, multitechnology,
>> multiservice continuity architecture can deliver now.
>> Good luck to everyone for the next decade which will be decisive.
>>
>> I do hope you will permit it to be in cooperation with the IGF,. That
>> we can proceed fast on a stable, reasonable and acceptable equal
>> opportunity but competitive fair basis. As we all agreed in Tunis.
>> jfc
>>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 16 16:07:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EybZu-0003Bj-S2; Mon, 16 Jan 2006 16:07:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EybZr-0003AK-7j
	for ietf@megatron.ietf.org; Mon, 16 Jan 2006 16:07:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15751
	for ; Mon, 16 Jan 2006 16:06:23 -0500 (EST)
Received: from ns.cnri.reston.va.us ([132.151.1.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eybhr-0002jv-0H
	for ietf@ietf.org; Mon, 16 Jan 2006 16:16:03 -0500
Received: from mailbox.cnri.reston.va.us ([132.151.7.39])
	by ns.cnri.reston.va.us with esmtp (Exim 4.52)
	id 1EybZp-0003Uy-MA; Mon, 16 Jan 2006 16:07:45 -0500
Received: from localhost ([127.0.0.1] helo=boblaptop.cnri.reston.va.us)
	by mailbox.cnri.reston.va.us with esmtp (Exim 4.12)
	id 1EybZp-0007j8-00; Mon, 16 Jan 2006 16:07:45 -0500
Message-Id: <6.1.2.0.2.20060116153037.02f04b20@newcnri.cnri.reston.va.us>
X-Sender: rkahn@newcnri.cnri.reston.va.us (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Mon, 16 Jan 2006 16:12:05 -0500
To: "Patrice Lyons" , 
From: Robert Kahn 
In-Reply-To: <003101c61ad6$3e53f150$01061f0a@Home1>
References: <20060116154032.GSGZ12737.eastrmmtai02.cox.net@EastRMIMPI02>
	<003101c61ad6$3e53f150$01061f0a@Home1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7
Cc: 
Subject: Re: Ietf Digest, Vol 21, Issue 63
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Patrice,

You ask a relevant historical question, so let me try my hand at an answer.

The history here is like this. Vint Cerf set up something called the 
Internet Configuration Control Board (ICCB) in the late 1970s when we were 
both at DARPA. It was intended to be an informal group that would meet from 
time to time, provide inputs and guidance as necessary and also inform a 
small but critical group of implementers about what we were doing at 
DARPA.with respect to the Internet. The ICCB consisted of twelve folks from 
the research community, essentially all of whom were involved in 
implementing Internet protocols. Dave Clark of MIT chaired the ICCB and it 
met at various places usually in connection with another set of meetings 
such as the Packet Satellite Meetings that I ran, or perhaps the Packet 
Radio meetings or other network meetings at which larger groups would 
gather. Over a period of years, we had numerous requests from others to sit 
in for the purpose of just listening to the discussions. At first there 
were a small number of others sitting in, but over time the number grew to 
several hundred and large meeting halls were then needed to house the 
twelve ICCB members plus Vint and me. Logistics soon became unwieldy, and 
when Vint left to go to MCI in late 1982, I took over the responsibility 
for the ICCB on behalf of DARPA for about a year at that point. Dave Clark 
continued to chair the group and I brought Barry Leiner into the picture 
and helped him to learn about the developing Internet so he could take over 
for me. Once that happened (late 1983 as I recall), he and Dave Clark 
recommended that we no longer try to hold such large ICCB meetings and 
proposed instead to establish an Internet Activities Board (IAB) in place 
of the ICCB. The IAB would have (initially) ten working groups underneath 
it to focus on specific technical topics such as routing, end-end 
protocols, autonomous systems and the like. In this new alternative 
structure, the twleve members of the IAB would be responsible for 
chartering and overseeing the working groups and the IAB could now meet by 
itself since the other attendees were now free to attendee the various 
working group meetings, which were held at various sites (often and usually 
research participant sites) around the country, if not around the world. 
Dave Clark continued to chair the IAB as he had done for the ICCB. When 
DARPA decided to get out of networking (temporarily as it turned out) in 
the mid 1980s, the DARPA oversight went away as well. NSF later assumed 
responsibility for providing support to the IAB (and thus to the IETF) and 
CNRI was asked by NSF to create a dedicated Secretariat for that purpose, 
which we did. CNRI ran the Secretariat until just recently, with support 
from NSF until 1998 and with meeting fees helping to offset secretariat 
costs starting in the early 1990s. CNRI formed a subsidiary, Foretec 
Seminars, to carry out the secretariat functions under contract to CNRI. On 
December 15, 2005 after considerable discussion with the IETF leadership 
and others, CNRI completed the sale of Foretec to NeuStar Secretariat Services.

One of the original ten working groups under the IAB was called "Internet 
Engineering" and it was led by Ed  Cain of the Defense Communications 
Agency (DCA). The job of this working group was to maintain a vigil over 
the "punch list" items needed to get the Internet up and running smoothly 
at that time (1983). By about 1985 or so, its original job was primarily 
done, but the number of working groups had by then grown to a number closer 
to perhaps fifty. The IAB was now burdened by the need to oversee a much 
larger number of subordinate activities and it asked the Internet 
Engineering group to assume that responsibility on its behalf and reporting 
to the IAB. Thus did the Internet Engineering Task Force (as we know it 
today) come into being as a transition of the original Internet Engineer 
working group. While there were numerous meetings of the original Internet 
Engineering group, the first meeting of the group that reflected the new 
arrangement took place in early 1986 in San Diego.

I do not know what the plans are yet for Dallas, but I suspect the IETF 
wants to just move ahead and if so I would probably not plan to attend the 
Dallas meeting. If there is an effort to reflect on some of the historical 
elements of the IETF, it might make sense for me to attend.

bob

>Bob,
>
>They are talking about the first IETF meeting as taking place on Jan. 16, 
>1986.  What about the IETF meeting as one of the several task forces that 
>Barry Leiner put together while you were still at DARPA?  There was also 
>the working group series that preceded the IETF.  I recall that Jon Postel 
>had kept the records of this work on the early Internet.  Also, do you 
>plan to go to Dallas?  The last message to Harold mentions some agreement 
>reached at Tunis with respect to IETF work with the to be formed Internet 
>Governance Forum (at least I think that is what it is going to be called) 
>(see early work on it at http://www.intgovforum.org/.
>
>Patrice
>----- Original Message ----- From: 
>To: 
>Sent: Monday, January 16, 2006 10:40 AM
>Subject: Ietf Digest, Vol 21, Issue 63
>
>
>>------------------------------
>>
>>Message: 6
>>Date: Mon, 16 Jan 2006 11:14:48 +0100
>>From: Brian E Carpenter 
>>Subject: An important day for the IETF
>>To: IETF discussion list 
>>Message-ID: <43CB7218.1020008@zurich.ibm.com>
>>Content-Type: text/plain; charset=us-ascii; format=flowed
>>
>>Greetings,
>>
>>The first IETF meeting took place 20 years ago today,
>>on January 16th, 1986, in San Diego, California. There were
>>21 attendees and Mike Corrigan was in the chair.
>>
>>The IETF has come a long way since then. We'll celebrate
>>this in fine style during the 65th IETF meeting in
>>Dallas, Texas from March 19 to 24, 2006.
>>
>>    Brian Carpenter
>>    IETF Chair No. 6
>>
>>------------------------------
>>
>>Message: 7
>>Date: Mon, 16 Jan 2006 12:30:13 +0100
>>From: Harald Tveit Alvestrand 
>>Subject: Re: An important day for the IETF
>>To: Brian E Carpenter , IETF discussion list
>>
>>Message-ID: 
>>Content-Type: text/plain; charset="us-ascii"
>>
>>Happy birthday, IETF!
>>
>>And remember to raise an extra toast to Mike St. Johns, who should be
>>coming to his 63rd or so IETF meeting in Dallas..... for some of us, this
>>has gotten to be a habit!
>>
>>Wonder how many of the original 21 are still around????
>>
>>             Harald, attendee since #22 (but missed #29)
>>
>>--On 16. januar 2006 11:14 +0100 Brian E Carpenter 
>>wrote:
>>
>>>Greetings,
>>>
>>>The first IETF meeting took place 20 years ago today,
>>>on January 16th, 1986, in San Diego, California. There were
>>>21 attendees and Mike Corrigan was in the chair.
>>>
>>>The IETF has come a long way since then. We'll celebrate
>>>this in fine style during the 65th IETF meeting in
>>>Dallas, Texas from March 19 to 24, 2006.
>>>
>>>     Brian Carpenter
>>>     IETF Chair No. 6
>>>
>>>
>>>
>>>_______________________________________________
>>>Ietf mailing list
>>>Ietf@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/ietf
>>>
>>
>>
>>------------------------------
>>
>>Message: 9
>>Date: Mon, 16 Jan 2006 16:00:12 +0100
>>From: Harald Tveit Alvestrand 
>>Subject: Re: An important day for the IETF
>>To: Noel Chiappa , ietf@ietf.org
>>Message-ID: <64C91C00D46DC52AA27AF3EB@svartdal.hjemme.alvestrand.no>
>>Content-Type: text/plain; charset=us-ascii; format=flowed
>>
>>
>>
>>--On mandag, januar 16, 2006 09:39:36 -0500 Noel Chiappa
>> wrote:
>>
>>>     > From: Harald Tveit Alvestrand 
>>>
>>>     > Wonder how many of the original 21 are still around????
>>>
>>>You rang? :-)
>>
>>That's one :-)
>>
>>The minutes of the first meeting are now online (scanned PDF)(!), and there
>>the attendees are listed as:
>>
>>Braun, Hans-Werner
>>Bresica, Mike
>>Callon, Ross
>>Chiappa, Noel
>>Eldridge, Charles
>>Gross, Phill
>>Hinden, Robert
>>Mathis, James
>>Mills, David
>>Nagle, John
>>Natalie, Ronald
>>Rokitansky, Carl
>>Shacham, Nachum
>>Su, Zaw-Sing
>>Topolcic, Claudio
>>Zhang, Lixia
>>
>>Clark, David
>>Corrigan, Mike
>>Deering, Steve
>>Means, Robert
>>St. Johns, Mike
>>
>>The only email address that *might* still work is Hans-Werner Braun's....
>>none of the others have FQDNs.....
>>
>>
>>
>>
>>
>>------------------------------
>>
>>Message: 10
>>Date: Mon, 16 Jan 2006 16:30:13 +0100
>>From: "JFC (Jefsey) Morfin" 
>>Subject: Re: An important day for the IETF
>>To: Harald Tveit Alvestrand , Brian E Carpenter
>>, IETF discussion list 
>>Message-ID: <6.2.3.4.2.20060116151422.0395e2b0@mail.jefsey.com>
>>Content-Type: text/plain; charset="us-ascii"; format=flowed
>>
>>At 12:30 16/01/2006, Harald Tveit Alvestrand wrote:
>>>Happy birthday, IETF!
>>
>>Dear Harald,
>>you are right, happy birthday! An impressive continuity we should
>>strive to protect. In avoiding the status quo that some stakeholders
>>may favor, and areas outside of network engineering (such as
>>linguistic and country political definition :-)).
>>
>>>Wonder how many of the original 21 are still around????
>>>Harald, attendee since #22 (but missed #29)
>>
>>Impressive. My own agenda that sad fortnight might help better
>>understand the past, present and future of the network.
>>
>>- on 12-15 January 1986 I attended the eight Telecommunications
>>Council Eighth Annual Conference at he Hawaiian Regent Hotel in
>>Honolulu. The theme was  "Evolution of the Digital Pacific". Audience
>>was probably 200 to 300 people. I had a lunch there with two lady
>>training consultant for the US Army TV network, to discuss how to
>>support their program on packet switch network, with Compression Lab tools.
>>- on the 16 I had a diner at the Bonaventure (LA) with Father Bourret
>>(http://www.kuangchi.com/english/history.htm). On the agenda: packet
>>switching in TW and a Vatican State International Packet Switch Gateway
>>- then I brought international data services experience in meetings
>>with an LA based Bank and for a complete turn-key online banking
>>service to a group NY banks. Multi-currency accounts, ATM
>>connections. I explained our experience with air-line reservation
>>services for most of the major airlines, hotels chains and
>>rent-a-cars, and how it worked at regular Travel Agents using a
>>service you would call a smart OPES today.
>>- met with Mobil Oil international communications manager (NY) and
>>routine meetings with the International Carriers. I was in Washington
>>on the 28th.
>>
>>We used to refer to ARPANET as the "grand father" :-). Minitel users
>>were probably already 3 millions in France, plus Prestel in UK, plus
>>Germany, etc.. Over these 20 years since these Tymnet times, OSI,
>>then the Internet made us to step from 7+ to 70+ to 700+ millions of
>>active users worldwide.
>>
>>But you may understand why I feel the architectural evolution is
>>sometimes dismaying and why constraints and rigidity cannot bring
>>innovation and expansion. We need now another technology leap frog
>>towards the 7+ billions users.
>>
>>Only a multilingual, multinational, multilateral, multitechnology,
>>multiservice continuity architecture can deliver now.
>>Good luck to everyone for the next decade which will be decisive.
>>
>>I do hope you will permit it to be in cooperation with the IGF,. That
>>we can proceed fast on a stable, reasonable and acceptable equal
>>opportunity but competitive fair basis. As we all agreed in Tunis.
>>jfc
>>
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 08:02:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyqTz-00049i-7L; Tue, 17 Jan 2006 08:02:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyqTw-000497-DT
	for ietf@megatron.ietf.org; Tue, 17 Jan 2006 08:02:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13797
	for ; Tue, 17 Jan 2006 08:01:15 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyqc0-00071g-6v
	for ietf@ietf.org; Tue, 17 Jan 2006 08:11:04 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EyqTd-0002MR-Iv
	for ietf@ietf.org; Tue, 17 Jan 2006 14:02:21 +0100
Received: from 1cust116.tnt8.hbg2.deu.da.uu.net ([149.225.138.116])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Tue, 17 Jan 2006 14:02:21 +0100
Received: from nobody by 1cust116.tnt8.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Tue, 17 Jan 2006 14:02:21 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Tue, 17 Jan 2006 14:00:57 +0100
Organization: 
Lines: 29
Message-ID: <43CCEA89.4007@xyzzy.claranet.de>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust116.tnt8.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

The IESG wrote:

> consider the following document:
> - 'Location Types Registry '
>    
> as a Proposed Standard

I'm lost with the purpose of this document.  Does 'water'
cover WC, bathroom, bathtube ?  What is a "criminal mental
institution" ?  Can "an entity" be on a 'cycle' 'outdoors'
in the 'street' simultaneously, and if yes, how do we know
that 'water' 'airplane' 'cycle' is somewhat strange ?

If all that is relevant somewhere for indiscreet devices,
shouldn't there be an enumeration of the IANA registered
locations ?

Will the next IANA registry be a complete dictionary, and
will it by definition include the location registry ?

Is it a good idea to have dictionaries on standards track ?
Is it acceptable to have no "I18N considerations" in the
proposed "location" standard ?

The dummy "security considerations" might be incomplete, if
locations could be used for say search and rescue purposes.

                        Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 08:44:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eyr8V-00049T-7f; Tue, 17 Jan 2006 08:44:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyr8T-00048w-5I
	for ietf@megatron.ietf.org; Tue, 17 Jan 2006 08:44:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16788
	for ; Tue, 17 Jan 2006 08:43:07 -0500 (EST)
Received: from monster.hopcount.ca ([199.212.90.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyrGa-0000wZ-8t
	for ietf@ietf.org; Tue, 17 Jan 2006 08:52:57 -0500
Received: from yxu1a20.hopcount.ca ([199.212.90.20])
	by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.60 (FreeBSD)) (envelope-from )
	id 1Eyr7s-000DzU-9G; Tue, 17 Jan 2006 13:43:56 +0000
In-Reply-To: <43CCEA89.4007@xyzzy.claranet.de>
References: 
	<43CCEA89.4007@xyzzy.claranet.de>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Joe Abley 
Date: Tue, 17 Jan 2006 08:43:53 -0500
To: Frank Ellermann 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On 17-Jan-2006, at 08:00, Frank Ellermann wrote:

> The IESG wrote:
>
>> consider the following document:
>> - 'Location Types Registry '
>>    
>> as a Proposed Standard
>
> I'm lost with the purpose of this document.

It seems from a quick glance through it that draft-ietf-simple- 
rpid-08 gives context.

The initial list of locations seems entirely arbitrary, and most of  
the definitions seem woolly and imprecise. Maybe the arbitrariness is  
intentional, though, and maybe the quality of definitions doesn't  
matter. I don't know enough about the goals of the underlying effort  
to comment.

There are some spelling mistakes. That's about as far as my informed  
commentary on this draft goes :-)


Joe

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 09:01:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyrOO-0001R3-SA; Tue, 17 Jan 2006 09:01:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyrOM-0001Qy-M5
	for ietf@megatron.ietf.org; Tue, 17 Jan 2006 09:00:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17836
	for ; Tue, 17 Jan 2006 08:59:33 -0500 (EST)
Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyrWT-0001b3-ER
	for ietf@ietf.org; Tue, 17 Jan 2006 09:09:23 -0500
Received: from [192.168.0.41] (pool-138-89-39-108.mad.east.verizon.net
	[138.89.39.108]) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0HE0n5f018581
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Tue, 17 Jan 2006 09:00:54 -0500 (EST)
In-Reply-To: 
References: 
	<43CCEA89.4007@xyzzy.claranet.de>
	
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0833000E-1350-47EE-8137-9FD54B072D94@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne 
Date: Tue, 17 Jan 2006 09:00:46 -0500
To: Joe Abley 
X-Mailer: Apple Mail (2.746.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: Frank Ellermann , ietf@ietf.org
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> It seems from a quick glance through it that draft-ietf-simple- 
> rpid-08 gives context.
>
> The initial list of locations seems entirely arbitrary, and most of  
> the definitions seem woolly and imprecise. Maybe the arbitrariness  
> is intentional, though, and maybe the quality of definitions  
> doesn't matter. I don't know enough about the goals of the  
> underlying effort to comment.

More precise definitions are always helpful, but I don't think it is  
necessary to have a complete catalogue of all possible types of  
locations suitable for an insurance company policy. The goal is that  
if there's a location, that if two people are asked to pick the  
closest label, they'll likely agree and they'll likely find something  
that matches. Clearly, this can be pushed to precision beyond need.  
For example, I doubt that we need to identify median strips on roads  
separately.


>
> There are some spelling mistakes. That's about as far as my  
> informed commentary on this draft goes :-)
>
>
> Joe
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 09:07:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyrV5-0003gH-EK; Tue, 17 Jan 2006 09:07:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyrV2-0003g4-I7
	for ietf@megatron.ietf.org; Tue, 17 Jan 2006 09:07:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18297
	for ; Tue, 17 Jan 2006 09:06:26 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyrd6-0001nG-Eu
	for ietf@ietf.org; Tue, 17 Jan 2006 09:16:17 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EyrUh-0000PH-Oj
	for ietf@ietf.org; Tue, 17 Jan 2006 15:07:31 +0100
Received: from 1cust116.tnt8.hbg2.deu.da.uu.net ([149.225.138.116])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Tue, 17 Jan 2006 15:07:31 +0100
Received: from nobody by 1cust116.tnt8.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Tue, 17 Jan 2006 15:07:31 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Tue, 17 Jan 2006 15:06:47 +0100
Organization: 
Lines: 21
Message-ID: <43CCF9F7.694B@xyzzy.claranet.de>
References: 
	<43CCEA89.4007@xyzzy.claranet.de>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust116.tnt8.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Joe Abley wrote:

> It seems from a quick glance through it that
> draft-ietf-simple-rpid-08 gives context.

ACK, thanks for info.  So now I'm _anxiously_ awaiting an
Internet standard for IANA registered moods...

  
  
  
  
  

...yes, can do.  It also offers 'grumpy' and 'sarcastic'.  Bye



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 12:31:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyugJ-00010D-4S; Tue, 17 Jan 2006 12:31:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyugH-0000ze-3B
	for ietf@megatron.ietf.org; Tue, 17 Jan 2006 12:31:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02884
	for ; Tue, 17 Jan 2006 12:30:16 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyuoR-0008KX-Fl
	for ietf@ietf.org; Tue, 17 Jan 2006 12:40:07 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1Eyug3-0002rh-QN; Tue, 17 Jan 2006 09:31:28 -0800
Message-Id: <6.2.3.4.2.20060117182225.0494e640@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Tue, 17 Jan 2006 18:31:24 +0100
To: Frank Ellermann , ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <43CCF9F7.694B@xyzzy.claranet.de>
References: 
	<43CCEA89.4007@xyzzy.claranet.de>
	
	<43CCF9F7.694B@xyzzy.claranet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-28BE7AF7
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: 
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At last!
you start understanding what multimode means in languages. I am 
sorry, but in approving RFC 3066 bis, i.e. declaring itself and the 
IETF authoritative, this is exactly the RFC 3935 responsibility the 
IETF has accepted.
jfc


At 15:06 17/01/2006, Frank Ellermann wrote:

>Joe Abley wrote:
>
> > It seems from a quick glance through it that
> > draft-ietf-simple-rpid-08 gives context.
>
>ACK, thanks for info.  So now I'm _anxiously_ awaiting an
>Internet standard for IANA registered moods...
>
>        type="empty"/>
>        type="empty"/>
>        type="empty"/>
>        type="empty"/>
>        type="empty" />
>
>...yes, can do.  It also offers 'grumpy' and 'sarcastic'.  Bye
>
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 15:32:19 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyxV5-00076H-DF; Tue, 17 Jan 2006 15:32:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxV3-000768-3B
	for ietf@megatron.ietf.org; Tue, 17 Jan 2006 15:32:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15628
	for ; Tue, 17 Jan 2006 15:30:51 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyxdA-0005cP-Jn
	for ietf@ietf.org; Tue, 17 Jan 2006 15:40:45 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EyxUj-00076Q-Ub
	for ietf@ietf.org; Tue, 17 Jan 2006 21:31:58 +0100
Received: from 1cust12.tnt2.hbg2.deu.da.uu.net ([149.225.12.12])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Tue, 17 Jan 2006 21:31:57 +0100
Received: from nobody by 1cust12.tnt2.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Tue, 17 Jan 2006 21:31:57 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Tue, 17 Jan 2006 21:30:44 +0100
Organization: 
Lines: 7
Message-ID: <43CD53F4.7EC2@xyzzy.claranet.de>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust12.tnt2.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit
Subject: Re: Volume 1 Issue 2 of the IETF Journal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian Carpenter wrote in 

> Volume 1 Issue 2 of the IETF Journal is now available at:
> http://ietfjournal.isoc.org/

It has an HTML version, how about a link to it on www.ietf.org ?



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 18:00:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyzoN-0004y5-UQ; Tue, 17 Jan 2006 18:00:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyzoL-0004xl-Cn; Tue, 17 Jan 2006 18:00:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02895;
	Tue, 17 Jan 2006 17:58:56 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EyzwX-0004Ud-EB; Tue, 17 Jan 2006 18:08:50 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 4A187E006A; Tue, 17 Jan 2006 17:57:54 -0500 (EST)
To: ietf@ietf.org
References: 
	<43CCEA89.4007@xyzzy.claranet.de>
From: Sam Hartman 
Date: Tue, 17 Jan 2006 17:57:54 -0500
In-Reply-To: <43CCEA89.4007@xyzzy.claranet.de> (Frank Ellermann's message of
	"Tue, 17 Jan 2006 14:00:57 +0100")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: iesg@ietf.org
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I have only had a brief look at this document but I'd like to second
some of the concerns raised so far.

1) If locations can be registered on a fcfs basis we can expect
   receivers to see locations that they are unfamiliar with.  As such,
   we need to do better about internationalization for locations.  It
   is not good enough to treat locations as identifiers that are not
   displayed to a user if receivers are often going to run into
   locations.


2) Many of the definitions seem arbitrary.  club vs bar vs cafe vs
   restaurant as an example.


3) The fact that some entries describe holonym relations without any
   defined structure to deal with this is at least concerning.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 18:30:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ez0HW-0004lR-Rl; Tue, 17 Jan 2006 18:30:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ez0HV-0004lJ-2t; Tue, 17 Jan 2006 18:30:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05178;
	Tue, 17 Jan 2006 18:29:04 -0500 (EST)
Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ez0Ph-0005WY-SX; Tue, 17 Jan 2006 18:38:59 -0500
Received: from [10.131.244.248] ([::ffff:216.168.239.87])
	(AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA)
	by zeke.ecotroph.net with esmtp; Tue, 17 Jan 2006 18:29:40 -0500
	id 0158801C.43CD7DE4.000001D8
In-Reply-To: 
References: 
	<43CCEA89.4007@xyzzy.claranet.de> 
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Andrew Newton 
Date: Tue, 17 Jan 2006 18:30:08 -0500
To: Sam Hartman 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 17, 2006, at 5:57 PM, Sam Hartman wrote:

> I have only had a brief look at this document but I'd like to second
> some of the concerns raised so far.
>
> 1) If locations can be registered on a fcfs basis we can expect
>    receivers to see locations that they are unfamiliar with.  As such,
>    we need to do better about internationalization for locations.  It
>    is not good enough to treat locations as identifiers that are not
>    displayed to a user if receivers are often going to run into
>    locations.

Not that I fully understand your concern, but would you want expert  
review of new additions?

> 2) Many of the definitions seem arbitrary.  club vs bar vs cafe vs
>    restaurant as an example.

Do you have a suggestion about how this can be less arbitrary?

> 3) The fact that some entries describe holonym relations without any
>    defined structure to deal with this is at least concerning.

Maybe this can be remedied with some guidelines as to what  
constitutes a reasonable entry.  I'm not sure if that is possible,  
but it certainly seems like "car" would be a useful entry as opposed  
to "seat" which would both be valid if somebody were riding in a seat  
in a car.

-andy

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 19:29:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ez1D4-0003Dv-UM; Tue, 17 Jan 2006 19:29:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez1D3-0003Di-3a
	for ietf@megatron.ietf.org; Tue, 17 Jan 2006 19:29:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15334
	for ; Tue, 17 Jan 2006 19:28:31 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez1LC-0001C9-Hb
	for ietf@ietf.org; Tue, 17 Jan 2006 19:38:27 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1Ez1Cn-0000PL-8o
	for ietf@ietf.org; Wed, 18 Jan 2006 01:29:41 +0100
Received: from 1cust12.tnt2.hbg2.deu.da.uu.net ([149.225.12.12])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Wed, 18 Jan 2006 01:29:41 +0100
Received: from nobody by 1cust12.tnt2.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Wed, 18 Jan 2006 01:29:41 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Wed, 18 Jan 2006 01:27:53 +0100
Organization: 
Lines: 34
Message-ID: <43CD8B89.564D@xyzzy.claranet.de>
References: 
	<43CCEA89.4007@xyzzy.claranet.de>
	
	<43CCF9F7.694B@xyzzy.claranet.de>
	<6.2.3.4.2.20060117182225.0494e640@mail.jefsey.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust12.tnt2.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

JFC (Jefsey) Morfin wrote:
 
> you start understanding what multimode means in languages.

Maybe I understand "abuse IANA as cheap dictionary for a random
list of locations".  But the list of smileys has some technical
potential, devices could output them as icons, audio, localized
text, or as traditional ASCII art.  For that the list of moods
could give the ASCII art, that's the most limited and shortest
form, plus a corresponding English word as explanation useable
directly in localized text output for "en".

I18N for ASCII art smileys might be tricky, maybe that depends
on the script.  At least BiDi is no issue.  Attempts to smuggle
smileys into Unicode as characters are probably futile, but an
RfC could do.  With the option to create an official registry
of smileys later.  Funny, but not necessarily nonsense.

> I am sorry, but in approving RFC 3066 bis, i.e. declaring
> itself and the IETF authoritative, this is exactly the RFC
> 3935 responsibility the IETF has accepted.

Well, you know what "bis" stands for, you know the now three
ISO sources for this registry, you know the executive summary
"3066 + scripts, for certain charsets and languages and other
situations where that's not obvious or irrelevant", you know
where to find draft-lilly-content-script, and you know that
3066 didn't guarantee stable tags.

That's not exactly the same situation as starting a "location
dictionary" hosted by IANA with a proposed Internet standard.

                           Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 20:42:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ez2LR-0005F9-D2; Tue, 17 Jan 2006 20:42:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ez2LP-0005Eo-Ap; Tue, 17 Jan 2006 20:42:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20726;
	Tue, 17 Jan 2006 20:41:13 -0500 (EST)
Received: from stratton-three-sixty-two.mit.edu ([18.187.6.107]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ez2Td-0003it-9z; Tue, 17 Jan 2006 20:51:10 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id CFE38E006A; Tue, 17 Jan 2006 20:40:07 -0500 (EST)
To: Andrew Newton 
References: 
	<43CCEA89.4007@xyzzy.claranet.de> 
	
From: Sam Hartman 
Date: Tue, 17 Jan 2006 20:40:07 -0500
In-Reply-To:  (Andrew Newton's
	message of "Tue, 17 Jan 2006 18:30:08 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Andrew" == Andrew Newton  writes:

    Andrew> On Jan 17, 2006, at 5:57 PM, Sam Hartman wrote:

    >> I have only had a brief look at this document but I'd like to
    >> second some of the concerns raised so far.
    >> 
    >> 1) If locations can be registered on a fcfs basis we can expect
    >> receivers to see locations that they are unfamiliar with.  As
    >> such, we need to do better about internationalization for
    >> locations.  It is not good enough to treat locations as
    >> identifiers that are not displayed to a user if receivers are
    >> often going to run into locations.

    Andrew> Not that I fully understand your concern, but would you
    Andrew> want expert review of new additions?


So, I'me a receiver.  I receieve a location that I'm unfamiliar with.
How do I render it in my native locale?

I'm not sure expert review would help with this.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 21:07:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ez2j1-0001qw-UL; Tue, 17 Jan 2006 21:07:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ez2j0-0001qi-Q3; Tue, 17 Jan 2006 21:07:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22048;
	Tue, 17 Jan 2006 21:05:36 -0500 (EST)
Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ez2rE-0004O8-UM; Tue, 17 Jan 2006 21:15:34 -0500
Received: from [192.168.0.41] (pool-138-89-39-108.mad.east.verizon.net
	[138.89.39.108]) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0I26s2i029762
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Tue, 17 Jan 2006 21:06:59 -0500 (EST)
In-Reply-To: 
References: 
	<43CCEA89.4007@xyzzy.claranet.de> 
	
	
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7667D236-C317-4B19-BB45-1ACC2089709B@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne 
Date: Tue, 17 Jan 2006 21:06:50 -0500
To: Sam Hartman 
X-Mailer: Apple Mail (2.746.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>
> So, I'me a receiver.  I receieve a location that I'm unfamiliar with.
> How do I render it in my native locale?
>

I don't think there is any way to accomplish this in general. You  
have two unpleasant choices:
- render the token as-is, hoping that it makes sense to the recipient;
- automatically translate the token, risking that the translation  
will be nonsensical.

This is no different than for any other token meant to be rendered to  
humans.

In RPID, where this is more relevant than in the Registry draft,  
there is a free-text field with the usual XML 'lang' attribute, which  
can be used to describe the location in internationalized text.  
However, in many systems, this is not particularly helpful. As an  
example, in presence, if your watchers are from many different  
language communities, the publisher likely can't pick a language that  
all watchers will understand. Thus, the use of tokens.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 17 23:51:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ez5IS-0003lA-0i; Tue, 17 Jan 2006 23:51:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez5IM-0003kp-To
	for ietf@megatron.ietf.org; Tue, 17 Jan 2006 23:51:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02729
	for ; Tue, 17 Jan 2006 23:50:16 -0500 (EST)
Received: from smtpout1.bayarea.net ([209.128.95.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez5Qb-0000w7-1e
	for ietf@ietf.org; Wed, 18 Jan 2006 00:00:14 -0500
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1])
	by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id k0I4pTcU022334; 
	Tue, 17 Jan 2006 20:51:29 -0800
Received: from shell4.bayarea.net (localhost [127.0.0.1])
	by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id k0I4nr5a000722;
	Tue, 17 Jan 2006 20:49:53 -0800
Received: from localhost (heard@localhost)
	by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id
	k0I4nqAf000715; Tue, 17 Jan 2006 20:49:53 -0800
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Tue, 17 Jan 2006 20:49:52 -0800 (PST)
From: "C. M. Heard" 
X-Sender: heard@shell4.bayarea.net
To: ietf@ietf.org
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: newtrk@lists.uoregon.edu
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 16 Jan 2006, The IESG wrote:
> The IESG has received a request from the Geographic Location/Privacy WG to 
> consider the following document:
> 
> - 'Location Types Registry '
>     as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-30.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-registry-03.txt

What I would like to know is how a document that creates a registry can be
considered for Proposed Standard, as opposed to BCP.  A Proposed Standard is
supposed to be something that can be advanced on the standards track.  How on
Earth does one have multiple interoperable genetically unrelated
implementations of a registry?

//cmh

P.S.  Yes I know we do this all the time but that does not mean that it
makes sense!


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 02:31:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ez7ml-0004Xa-7K; Wed, 18 Jan 2006 02:31:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ez7mi-0004XJ-Ab; Wed, 18 Jan 2006 02:31:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13195;
	Wed, 18 Jan 2006 02:29:46 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ez7uz-0005o8-Ps; Wed, 18 Jan 2006 02:39:46 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id B241C2596E5;
	Wed, 18 Jan 2006 08:29:57 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 22001-03; Wed, 18 Jan 2006 08:29:51 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 8F69A2596E3;
	Wed, 18 Jan 2006 08:29:51 +0100 (CET)
Date: Wed, 18 Jan 2006 08:30:56 +0100
From: Harald Tveit Alvestrand 
To: iesg@ietf.org
Message-ID: <961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
In-Reply-To: 
References: 
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Content-Transfer-Encoding: 7bit
Cc: geopriv@ietf.org, ietf@ietf.org
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I oppose approval of this document as-is.

Four reasons:

1) FCFS is inappropriate
2) The document gives inadequate context for use
3) The document gives inadequate procedures
4) The definition of "automobile" is wrong

Further explanation:

1) FCFS: This token registry will have value chiefly when the recipient of 
such a token has a complete list of tokens available to him, and can 
perform adequate localization. Thus, value is maximized if the churn of the 
registry is slow. With FCFS, one risks a number of trends that could 
jeopardize this (consider registering, in addition to "cafe", "McDonalds", 
"Wendy's", "Burger King", "Jack-in-the-box", "7-eleven"... or in addition 
to "school", registering "university", "middle school", "gymnasium", 
"hochschule", "kindergarten", "vocational-training-institution"....)

I consider "expert review", with a list of criteria that includes "names a 
type of place not described by any existing token", to be a more 
appropriate mechanism.

If we think unlimited growth is a problem, someone needs to be able to say 
"no"; if we don't think unlimited growth is a problem, we need to say so.

2) Inadequate context for use:

The document does not make reference to RPID, except in "acknowledgement". 
Thus, it has to be interpreted as stand-alone, and must contain its own 
guidance. RPID states:

   The  element describes the type of place the person is
   currently at.  This offers the watcher an indication what kind of
   communication is likely to be appropriate.

The XML definiton says:

     
       
         
           Describes the type of place the person is currently at.
         
       
       
         
           
           
             

and while I'm not an XML expert, it seems to say that
 is a legal construct.
I don't know if it's possible to say whether or not 
 is different from 
.

These things guide the usage of place-types in RPID, but cannot be found 
from the registry document.

This document SHOULD give guidance for usage, saying at least:

- whether it's intended that several of these values can be used together
- whether it's intended that a sequence of location types gives a 
progressively more precise set of terms (in which case internationalizing 
the last type you understand is appropriate) or names an intersection of 
the classes (in which case you would have to internationalize all of them).
- whether having a text string alongside it (the "note" above) is a 
recommended practice.

It MAY be appropriate to say something about field of use, like RPID does 
("what types of communication is appropriate" would lead one to distinguish 
between "driving a car" and "passenger in a car", while one could imagine 
that other usages might want to distinguish between "expensive restaurant" 
and "cheap restaurant").

3) Inadequate procedures:

It's a fact of life that any registry will need updating. This document 
describes registration, but no updates. It needs to say:

- Who's authorized to update a registration (FCFS, Expert approval, 
original registrant, not at all)

- Guidelines for updates (anything-goes, refinements only, redefinitions 
with expert approval only)

- Whether registrations can be deleted or not

- Whether there is a mechanism for marking entries as "deprecated, use this 
other term"


4) Self explanatory:

   automobile:

      The entity is in a railroad car.

Nit: The terms show signs of having been alphabetized at one time. They are 
no longer alphabetized - "residence" is in a place in the list that would 
have been appropriate for "home".


--On mandag, januar 16, 2006 21:33:45 -0500 The IESG 
 wrote:

> The IESG has received a request from the Geographic Location/Privacy WG
> to  consider the following document:
>
> - 'Location Types Registry '
>     as a Proposed
> Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-30.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-reg
> istry-0 3.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 07:33:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzCVc-0005wQ-QJ; Wed, 18 Jan 2006 07:33:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzCVa-0005vL-V3; Wed, 18 Jan 2006 07:33:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06247;
	Wed, 18 Jan 2006 07:32:25 -0500 (EST)
Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzCdu-0007Om-BC; Wed, 18 Jan 2006 07:42:27 -0500
Received: from dul1shollenbl1 ([::ffff:216.168.239.87])
	(AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5)
	by zeke.ecotroph.net with esmtp; Wed, 18 Jan 2006 07:32:54 -0500
	id 0158800A.43CE3576.00002566
From: "Scott Hollenbeck" 
To: ietf@ietf.org, ietf-announce@ietf.org
Date: Wed, 18 Jan 2006 07:34:41 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcYcK41Eh3BPPBEbS8mRclqBF5FVLg==
Message-ID: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org
Subject: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

The IESG has received a request from Harald Alvestrand to approve an RFC
3683 PR-action  ("posting rights" action) for JFC (Jefsey) Morfin as a
result of a pattern of prior warning and posting rights suspensions for
off-topic postings to the LTRU working group and ietf-languages mailing
lists that have not produced a change in behavior.  This behavior has been
characterized as a "denial-of-service" attack to disrupt the
consensus-driven process as described in Section 1 of RFC 3683.  A timeline
of warnings and posting rights suspensions related to this request is
included below.

The IESG will consider this request.  If approved, the PR-action described
in Section 2 of RFC 3683 includes provisions to allow list administrators to
suspend Mr. Morfin's posting rights to the LTRU working group and
ietf-languages mailing list for at least one year.  Maintainers of other
IETF mailing lists may also remove posting rights to their mailing lists at
their discretion.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action.  Please send any comments to the iesg@ietf.org or
ietf@ietf.org mailing lists by 17 February 2006.

For the IESG,
Scott Hollenbeck
Applications Area Director
--------------------------

Private warnings sent for LTRU working group mailing list postings:
7 July 2005
16 July 2005
23 September 2005
26 October 2005

Public warnings and suspensions for LTRU working group and ietf-languages
mailing list postings:

17 March 2005 (ietf-languages warning)
http://www.alvestrand.no/pipermail/ietf-languages/2005-March/003236.html

5 April 2005 (LTRU warning)
http://www1.ietf.org/mail-archive/web/ltru/current/msg00564.html

12 May 2005 (LTRU suspension)
http://www1.ietf.org/mail-archive/web/ltru/current/msg01737.html

26 May 2005 (LTRU warning)
http://www1.ietf.org/mail-archive/web/ltru/current/msg01897.html
(Used as basis for 4 July suspension.)

15 June 2005 (ietf-languages suspension)
http://www.alvestrand.no/pipermail/ietf-languages/2005-June/003474.html

4 July 2005 (LTRU suspension)
http://www1.ietf.org/mail-archive/web/ltru/current/msg02532.html
(Appealed to AD, appeal upheld, new warning given.)

5 July 2005 (LTRU warning)
http://www1.ietf.org/mail-archive/web/ltru/current/msg02548.html

15 September 2005 (ietf-languages suspension)
http://www.alvestrand.no/pipermail/ietf-languages/2005-September/003585.html

26 September 2005 (LTRU warning)
http://www1.ietf.org/mail-archive/web/ltru/current/msg03755.html

7 October 2005
PR-Action request sent to IESG
http://www1.ietf.org/mail-archive/web/ietf/current/msg38183.html

15 October 2005 (LTRU warning)
http://www1.ietf.org/mail-archive/web/ltru/current/msg03941.html

8 November 2005 (LTRU suspension)
http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html
(Appealed to AD, appeal denied by AD.)

20 November 2005 (ietf-languages suspension)
http://www.alvestrand.no/pipermail/ietf-languages/2005-November/003811.html
(Appealed to AD/IESG, appeal denied by IESG, appealed to the IAB.)

13 January 2006 (ietf-languages suspension)
http://www.alvestrand.no/pipermail/ietf-languages/2006-January/003854.html


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 09:49:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzEcl-0000FG-3q; Wed, 18 Jan 2006 09:49:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzEci-0000CD-TB; Wed, 18 Jan 2006 09:49:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19737;
	Wed, 18 Jan 2006 09:47:54 -0500 (EST)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzEl3-0004Vb-Ir; Wed, 18 Jan 2006 09:57:58 -0500
Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0IEnCKG017631
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 18 Jan 2006 09:49:12 -0500 (EST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id k0IEn7Q4009048;
	Wed, 18 Jan 2006 09:49:08 -0500
Message-ID: <43CE5567.8050302@cs.columbia.edu>
Date: Wed, 18 Jan 2006 09:49:11 -0500
From: Henning Schulzrinne 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: 
	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
In-Reply-To: <961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0,
	__USER_AGENT 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Content-Transfer-Encoding: 7bit
Cc: geopriv@ietf.org, iesg@ietf.org, ietf@ietf.org
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Thanks for your comments. I generally agree with your feedback and we'll 
revise the document accordingly.

Harald Tveit Alvestrand wrote:
> I oppose approval of this document as-is.
> 
> Four reasons:
> 
> 1) FCFS is inappropriate
> 2) The document gives inadequate context for use
> 3) The document gives inadequate procedures
> 4) The definition of "automobile" is wrong
> 
> Further explanation:
> 
> 1) FCFS: This token registry will have value chiefly when the recipient 
> of such a token has a complete list of tokens available to him, and can 
> perform adequate localization. Thus, value is maximized if the churn of 
> the registry is slow. With FCFS, one risks a number of trends that could 
> jeopardize this (consider registering, in addition to "cafe", 
> "McDonalds", "Wendy's", "Burger King", "Jack-in-the-box", "7-eleven"... 
> or in addition to "school", registering "university", "middle school", 
> "gymnasium", "hochschule", "kindergarten", 
> "vocational-training-institution"....)
> 
> I consider "expert review", with a list of criteria that includes "names 
> a type of place not described by any existing token", to be a more 
> appropriate mechanism.
> 
> If we think unlimited growth is a problem, someone needs to be able to 
> say "no"; if we don't think unlimited growth is a problem, we need to 
> say so.
> 
> 2) Inadequate context for use:
> 
> The document does not make reference to RPID, except in 
> "acknowledgement". Thus, it has to be interpreted as stand-alone, and 
> must contain its own guidance. RPID states:
> 
>   The  element describes the type of place the person is
>   currently at.  This offers the watcher an indication what kind of
>   communication is likely to be appropriate.
> 
> The XML definiton says:
> 
>     
>       
>         
>           Describes the type of place the person is currently at.
>         
>       
>       
>         
>           
>           
>             
> 
> and while I'm not an XML expert, it seems to say that
>  is a legal construct.
> I don't know if it's possible to say whether or not 
>  is different from 
> .
> 
> These things guide the usage of place-types in RPID, but cannot be found 
> from the registry document.
> 
> This document SHOULD give guidance for usage, saying at least:
> 
> - whether it's intended that several of these values can be used together
> - whether it's intended that a sequence of location types gives a 
> progressively more precise set of terms (in which case 
> internationalizing the last type you understand is appropriate) or names 
> an intersection of the classes (in which case you would have to 
> internationalize all of them).
> - whether having a text string alongside it (the "note" above) is a 
> recommended practice.
> 
> It MAY be appropriate to say something about field of use, like RPID 
> does ("what types of communication is appropriate" would lead one to 
> distinguish between "driving a car" and "passenger in a car", while one 
> could imagine that other usages might want to distinguish between 
> "expensive restaurant" and "cheap restaurant").
> 
> 3) Inadequate procedures:
> 
> It's a fact of life that any registry will need updating. This document 
> describes registration, but no updates. It needs to say:
> 
> - Who's authorized to update a registration (FCFS, Expert approval, 
> original registrant, not at all)
> 
> - Guidelines for updates (anything-goes, refinements only, redefinitions 
> with expert approval only)
> 
> - Whether registrations can be deleted or not
> 
> - Whether there is a mechanism for marking entries as "deprecated, use 
> this other term"
> 
> 
> 4) Self explanatory:
> 
>   automobile:
> 
>      The entity is in a railroad car.
> 
> Nit: The terms show signs of having been alphabetized at one time. They 
> are no longer alphabetized - "residence" is in a place in the list that 
> would have been appropriate for "home".
> 
> 
> --On mandag, januar 16, 2006 21:33:45 -0500 The IESG 
>  wrote:
> 
>> The IESG has received a request from the Geographic Location/Privacy WG
>> to  consider the following document:
>>
>> - 'Location Types Registry '
>>     as a Proposed
>> Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send any comments to the
>> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-30.
>>
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-reg
>> istry-0 3.txt
>>
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf-announce
>>
> 
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 12:26:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzH4Q-00035a-PW; Wed, 18 Jan 2006 12:26:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzH4K-00035U-If
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 12:26:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05484
	for ; Wed, 18 Jan 2006 12:24:35 -0500 (EST)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]
	helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzHCg-0002BC-L0
	for ietf@ietf.org; Wed, 18 Jan 2006 12:34:39 -0500
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com
	[47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	k0IHLrI03814; Wed, 18 Jan 2006 12:21:53 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Jan 2006 12:25:34 -0500
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5051A8505@zcarhxm2.corp.nortel.com>
Thread-Topic: Wireless at IETF
Thread-Index: AcYaHE+yd+/hr6VBQ9q2Zd+rw+iPEgCN36/g
From: "Ed Juskevicius" 
To: "Marshall Eubanks" ,
	"Harald Tveit Alvestrand" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In addition to the content suggested below, I think a few words on "Why =
ad-hoc mode is BAD during IETF meetings" should also be included.  Not =
everyone knows the issues caused by ad-hoc mode (e.g. newbie attendees).

Regards and Happy New Year ...

Ed

-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of =
Marshall Eubanks
Sent: Sunday, January 15, 2006 4:39 PM
To: Harald Tveit Alvestrand
Cc: ietf@ietf.org
Subject: Re: Wireless at IETF


I think (and suggested to the IAOC) that there should be
an information sheet and / or web site for each meeting with =20
information on how to determine Ad Hoc Mode, how
to turn it off, etc., for all major OS choices.

Regards
Marshall


On Jan 15, 2006, at 4:10 PM, Harald Tveit Alvestrand wrote:

> Tangential:
> At the IEEE meeting following the IETF, someone asked me "how do I
> turn off ad hoc mode".
>
> I was hard put to find an answer for Windows XP with the standard
> drivers (I use 2000 and a Cisco driver kit).
>
> Suggestion: Make instructions *with screenshots* of how to turn off
> ad hoc mode on Windows XP available at the next IETF.
>
>                        Harald
>
>
> --On s=F8ndag, januar 15, 2006 15:23:01 -0500 Henning Schulzrinne
>  wrote:
>
>> http://www.nmrc.org/pub/present/shmoocon-2006-sn.ppt describes what=20
>> seems to explain the appearance of IETF6x named computer-to-computer=20
>> wireless networks at IETF meetings. Apparently, there is a
>> feature  that
>> has systems automatically advertise the last AP SSID after  =20
>> (involuntary)
>> disconnection. The slides are skimpy on details, but  provide a =20
>> bit more
>> background than the usual "turn of ad-hoc mode"  exhortations at IETF
>> meetings.
>>
>> Henning
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>>
>
>
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 13:30:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzI4w-0005TG-9J; Wed, 18 Jan 2006 13:30:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzI4u-0005So-JN
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 13:30:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11145
	for ; Wed, 18 Jan 2006 13:29:15 -0500 (EST)
Received: from colibri.verisign.com ([65.205.251.74])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzIDI-0004WD-5D
	for ietf@ietf.org; Wed, 18 Jan 2006 13:39:20 -0500
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com
	[65.205.251.33])
	by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0IIUW8d008418;
	Wed, 18 Jan 2006 10:30:32 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by
	MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 10:30:31 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Jan 2006 10:30:31 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD3787AABC@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Thread-Topic: Wireless at IETF
Thread-Index: AcYaHE+yd+/hr6VBQ9q2Zd+rw+iPEgCN36/gAAIi/IA=
From: "Hallam-Baker, Phillip" 
To: "Ed Juskevicius" ,
	"Marshall Eubanks" ,
	"Harald Tveit Alvestrand" 
X-OriginalArrivalTime: 18 Jan 2006 18:30:31.0769 (UTC)
	FILETIME=[43901490:01C61C5D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

That is solving the problem for ourselves only.

802.11 is a classic case of what happens when unfinished technology is =
thrown at consumers.

Think about VLSI manufacture, thirty or so production steps each with a =
finite chance of error. If you have a 5% error rate at each stage your =
overall yield drops to 20%

Computers are much more complex than VLSI manufacture, the explanations =
of the technology are much worse than 95% accurate.

All my hardware is allegedly capable of doing WPA or 801.X. I have not =
got the slightest idea what I would have to do to enable it though, or =
how it would work, or what the authentication process would be.

It is unfortunate that the cryptographic failures in WEP obscured the =
much more significant usability failures. The wireless world still does =
not 'get' it.

The result is that 70% of wireless access points are open and can be =
used by Internet criminals to achieve anonymous access.



> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20
> Behalf Of Ed Juskevicius
> Sent: Wednesday, January 18, 2006 12:26 PM
> To: Marshall Eubanks; Harald Tveit Alvestrand
> Cc: ietf@ietf.org
> Subject: RE: Wireless at IETF
>=20
> In addition to the content suggested below, I think a few=20
> words on "Why ad-hoc mode is BAD during IETF meetings" should=20
> also be included.  Not everyone knows the issues caused by=20
> ad-hoc mode (e.g. newbie attendees).
>=20
> Regards and Happy New Year ...
>=20
> Ed
>=20
> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20
> Behalf Of Marshall Eubanks
> Sent: Sunday, January 15, 2006 4:39 PM
> To: Harald Tveit Alvestrand
> Cc: ietf@ietf.org
> Subject: Re: Wireless at IETF
>=20
>=20
> I think (and suggested to the IAOC) that there should be an=20
> information sheet and / or web site for each meeting with=20
> information on how to determine Ad Hoc Mode, how to turn it=20
> off, etc., for all major OS choices.
>=20
> Regards
> Marshall
>=20
>=20
> On Jan 15, 2006, at 4:10 PM, Harald Tveit Alvestrand wrote:
>=20
> > Tangential:
> > At the IEEE meeting following the IETF, someone asked me "how do I=20
> > turn off ad hoc mode".
> >
> > I was hard put to find an answer for Windows XP with the standard=20
> > drivers (I use 2000 and a Cisco driver kit).
> >
> > Suggestion: Make instructions *with screenshots* of how to=20
> turn off ad=20
> > hoc mode on Windows XP available at the next IETF.
> >
> >                        Harald
> >
> >
> > --On s=F8ndag, januar 15, 2006 15:23:01 -0500 Henning Schulzrinne=20
> >  wrote:
> >
> >> http://www.nmrc.org/pub/present/shmoocon-2006-sn.ppt=20
> describes what=20
> >> seems to explain the appearance of IETF6x named=20
> computer-to-computer=20
> >> wireless networks at IETF meetings. Apparently, there is a=20
> feature =20
> >> that
> >> has systems automatically advertise the last AP SSID after  =20
> >> (involuntary)
> >> disconnection. The slides are skimpy on details, but =20
> provide a bit=20
> >> more background than the usual "turn of ad-hoc mode" =20
> exhortations at=20
> >> IETF meetings.
> >>
> >> Henning
> >>
> >> _______________________________________________
> >> Ietf mailing list
> >> Ietf@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ietf
> >>
> >
> >
> >
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
>=20
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>=20
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>=20
>=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 13:57:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzIVI-0004Tx-GH; Wed, 18 Jan 2006 13:57:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIVH-0004Ts-IT
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 13:57:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13160
	for ; Wed, 18 Jan 2006 13:56:29 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzIde-0005Oy-Al
	for ietf@ietf.org; Wed, 18 Jan 2006 14:06:35 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0IIv0i27618
	for ; Wed, 18 Jan 2006 10:57:00 -0800 (PST)
Received: (from faber@localhost)
	by hut.isi.edu (8.13.4/8.13.4/Submit) id k0IIv0SI079553
	for ietf@ietf.org; Wed, 18 Jan 2006 10:57:00 -0800 (PST)
	(envelope-from faber)
Date: Wed, 18 Jan 2006 10:57:00 -0800
From: Ted Faber 
To: ietf@ietf.org
Message-ID: <20060118185700.GS96731@hut.isi.edu>
References: <198A730C2044DE4A96749D13E167AD3787AABC@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Mime-Version: 1.0
In-Reply-To: <198A730C2044DE4A96749D13E167AD3787AABC@MOU1WNEXMB04.vcorp.ad.vrsn.com>
User-Agent: Mutt/1.4.2.1i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0322251692=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0322251692==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="b2ktwntdbf0dPnbx"
Content-Disposition: inline


--b2ktwntdbf0dPnbx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 18, 2006 at 10:30:31AM -0800, Hallam-Baker, Phillip wrote:
> The result is that 70% of wireless access points are open and can be
> used by Internet criminals to achieve anonymous access.

Loaded statement?  Check.
Precise statement? Check.
Supported statement? Hmmmm.....

--=20
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.=
asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#=
SIG

--b2ktwntdbf0dPnbx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDzo97aUz3f+Zf+XsRAmoqAKDtYJrlBp/g8ABXoizrMC52CFkpzQCeM48w
QERd+bm0rz94goyxTPmJKdw=
=XgXu
-----END PGP SIGNATURE-----

--b2ktwntdbf0dPnbx--


--===============0322251692==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0322251692==--




From ietf-bounces@ietf.org Wed Jan 18 14:00:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzIYA-0005BH-2v; Wed, 18 Jan 2006 14:00:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIY7-0005Ax-PV
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 14:00:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13430
	for ; Wed, 18 Jan 2006 13:59:25 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzIgS-0005WH-EC
	for ietf@ietf.org; Wed, 18 Jan 2006 14:09:31 -0500
Received: from [10.10.10.11] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001568703.msg
	for ; Wed, 18 Jan 2006 20:02:24 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Wed, 18 Jan 2006 19:59:59 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: Venue Selection Criteria - new (last ?) version
Thread-Index: AcYcYWDqn49dxIhUEdqhXQANky3PwA==
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060118:ietf@ietf.org::IOgN/vaRXlRUT5+r:00002uT7
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Wed, 18 Jan 2006 20:02:27 +0100
X-MDAV-Processed: consulintel.es, Wed, 18 Jan 2006 20:02:40 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Subject: Venue Selection Criteria - new (last ?) version
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi all,

I've sent to the secretariat a couple of days ago, version 4 of this
document, but is still not there. Meanwhile, you can access to it at:

http://www.consulintel.euro6ix.org/ietf/draft-palet-ietf-meeting-venue-selec
tion-criteria-04.txt

Please, provide your final inputs so we can declare this done ASAP !

One more comment. The network (wired/wireless), terminal room and other
technical details, which *are* part of the selection criteria have been
moved to a new document (which is already referenced in the venue selection
one), to make it easier to read and to differentiate the most
"administrative" or logistic things from the rest. I hope to have a first
version of this document at the end of this week.

Regards,
Jordi






**********************************************
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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 14:24:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzIua-0004Ji-J3; Wed, 18 Jan 2006 14:24:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIuY-0004Jd-JB
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 14:24:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15261
	for ; Wed, 18 Jan 2006 14:22:36 -0500 (EST)
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzJ2v-0006Kn-Ov
	for ietf@ietf.org; Wed, 18 Jan 2006 14:32:43 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 6F281FB28D;
	Wed, 18 Jan 2006 19:23:50 +0000 (UTC)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id 287E13BFE5C;
	Wed, 18 Jan 2006 14:23:49 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: Ted Faber 
In-Reply-To: (Your message of "Wed, 18 Jan 2006 10:57:00 PST.")
	<20060118185700.GS96731@hut.isi.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 18 Jan 2006 14:23:49 -0500
Message-Id: <20060118192349.287E13BFE5C@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: ietf@ietf.org
Subject: Re: Wireless at IETF 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In message <20060118185700.GS96731@hut.isi.edu>, Ted Faber writes:
>
>
>On Wed, Jan 18, 2006 at 10:30:31AM -0800, Hallam-Baker, Phillip wrote:
>> The result is that 70% of wireless access points are open and can be
>> used by Internet criminals to achieve anonymous access.
>
>Loaded statement?  Check.
>Precise statement? Check.
>Supported statement? Hmmmm.....
>

I'm not sure which part your claiming is unsupported; my own informal 
measurements agree with the 70% number.  I'm not at all convinced that 
"Internet criminals" use such access points as a major means of access, 
though.

However, Phillip's larger point -- that our security mechanisms and 
products have lousy user interfaces -- is absolutely correct.  It's a 
major issue.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 14:51:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzJKg-0004K3-Q2; Wed, 18 Jan 2006 14:51:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJKe-0004Jy-Ir
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 14:51:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17779
	for ; Wed, 18 Jan 2006 14:49:34 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzJT0-0007Ny-Rm
	for ietf@ietf.org; Wed, 18 Jan 2006 14:59:41 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0IJo9i17020;
	Wed, 18 Jan 2006 11:50:09 -0800 (PST)
Received: (from faber@localhost)
	by hut.isi.edu (8.13.4/8.13.4/Submit) id k0IJo97W090608;
	Wed, 18 Jan 2006 11:50:09 -0800 (PST) (envelope-from faber)
Date: Wed, 18 Jan 2006 11:50:09 -0800
From: Ted Faber 
To: "Steven M. Bellovin" 
Message-ID: <20060118195009.GT96731@hut.isi.edu>
References: <20060118185700.GS96731@hut.isi.edu>
	<20060118192349.287E13BFE5C@berkshire.machshav.com>
Mime-Version: 1.0
In-Reply-To: <20060118192349.287E13BFE5C@berkshire.machshav.com>
User-Agent: Mutt/1.4.2.1i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: ietf@ietf.org
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0888058913=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0888058913==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="0WGqsT62A4RTsSXf"
Content-Disposition: inline


--0WGqsT62A4RTsSXf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 18, 2006 at 02:23:49PM -0500, Steven M. Bellovin wrote:
> In message <20060118185700.GS96731@hut.isi.edu>, Ted Faber writes:
> >
> >
> >On Wed, Jan 18, 2006 at 10:30:31AM -0800, Hallam-Baker, Phillip wrote:
> >> The result is that 70% of wireless access points are open and can be
> >> used by Internet criminals to achieve anonymous access.
> >
> >Loaded statement?  Check.
> >Precise statement? Check.
> >Supported statement? Hmmmm.....
> >
>=20
> I'm not sure which part your claiming is unsupported; my own informal=20
> measurements agree with the 70% number.  I'm not at all convinced that=20
> "Internet criminals" use such access points as a major means of access,=
=20
> though.

Well, none of it's supported.  Your statement above about informal
measurements is support for your statement of 70% and indirectly of his.

"70% are open," meaning 70% of wireless (access points|networks) have no
admission control at the link layer seems plausible, but there are lots
of things that seem plausible to me that I'm wrong about later.  Having
a number and not even saying "Bellovin's measurements indicate" always
tweaks my interest.

Going from an open access point to anonymous criminal access seems much
more implausible to me.  There are all sorts of hurdles one could put up
between "no link level protection" and "anonymous criminal access."  But
again, I'm wrong all the time and a citation for that much more damning
statement would be very welcome.  Without one I feel like I'm watching
local news.

The combination of a very provacative statelment "anonymous criminals
access" and precise number makes me uneasy.  After all 90% of all
statictics are made up.

"An awful lot of access points can be used to anonymously get on the
Internet for criminal purposes" doesn't concern me as much.  But if you
found a number somewhere, let me know where, too.  A real study is
valuable information; an uncited, incorrect (and I don't know it's
incorrect) number is hard to kill.

> However, Phillip's larger point -- that our security mechanisms and=20
> products have lousy user interfaces -- is absolutely correct.  It's a=20
> major issue.

I absolutely agree.

--=20
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.=
asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#=
SIG

--0WGqsT62A4RTsSXf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDzpvxaUz3f+Zf+XsRAgIfAJ9ElUQcBvdBkKGOXf2CA2+cCTXAkwCgyedc
JsMQBoLSrmK/+jq1G3IT7EE=
=AEIC
-----END PGP SIGNATURE-----

--0WGqsT62A4RTsSXf--


--===============0888058913==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0888058913==--




From ietf-bounces@ietf.org Wed Jan 18 15:35:40 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzK1s-0007jg-Ay; Wed, 18 Jan 2006 15:35:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzK1r-0007jY-2X
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 15:35:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21398
	for ; Wed, 18 Jan 2006 15:34:12 -0500 (EST)
Message-Id: <200601182034.PAA21398@ietf.org>
Received: from venus3.veridas.net ([202.52.32.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzKAE-0000WK-FY
	for ietf@ietf.org; Wed, 18 Jan 2006 15:44:20 -0500
Received: (qmail 3759 invoked from network); 19 Jan 2006 06:35:20 +1000
Received: from dassa@dhs.org by venus3 by uid 1001 with qmail-scanner-1.15 
	( Clear:. Processed in 0.971627 secs); 18 Jan 2006 20:35:20 -0000
Received: from dsl-125-209-164-118.nsw.veridas.net (HELO dhs) (125.209.164.118)
	by 202.52.49.177 with SMTP; 19 Jan 2006 06:35:19 +1000
Received: (qmail 5458 invoked by uid 453); 18 Jan 2006 16:43:18 -0000
Received: from dassa.dhs (HELO dassa) (192.168.0.2)
	by dhs (qpsmtpd/0.31-dev) with ESMTP; Thu, 19 Jan 2006 03:43:18 +1100
From: "Dassa" 
To: 
Date: Thu, 19 Jan 2006 07:35:19 +1100
Organization: DHS International Pty Ltd Australia
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Thread-Index: AcYcYao6WvUJP9r5Soui/QLatcnB6AAC5yOw
In-Reply-To: <20060118185700.GS96731@hut.isi.edu>
X-Qmail-Scanner-Message-ID: <11376165195023746@venus3>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Subject: RE: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dassa@dhs.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

|> -----Original Message-----
|> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
|> On Behalf Of Ted Faber
|> Sent: Thursday, January 19, 2006 5:57 AM
|> To: ietf@ietf.org
|> Subject: Re: Wireless at IETF
|> 
|> On Wed, Jan 18, 2006 at 10:30:31AM -0800, Hallam-Baker, 
|> Phillip wrote:
|> > The result is that 70% of wireless access points are open and can be 
|> > used by Internet criminals to achieve anonymous access.
|> 
|> Loaded statement?  Check.
|> Precise statement? Check.
|> Supported statement? Hmmmm.....

I don't see the 70% of access points being open actually.  My own figures
indicate less than 20% within the local area, information from capital cities
tends to suggest a slightly higher figure but certainly not that high.  But
then, how many wired networks have link layer access controls?  I don't see
very many of those and implementing it is extremely difficult unless you have
everything set up exactly as the hardware has been designed for.  For example
trying to use password/password combinations instead of token/password has
proven problematic in one practical case I'm aware of for activating port
locking.  It amuses me just how easy it is to walk into a business and plug a
system in with full access to the network.

Most people/businesses do not appear to have security as a high priority.

Darryl (Dassa) Lynch 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 16:37:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzKza-0006oq-2x; Wed, 18 Jan 2006 16:37:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKzV-0006lY-5z
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 16:37:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06239
	for ; Wed, 18 Jan 2006 16:35:50 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzL7q-0006NP-Jy
	for ietf@ietf.org; Wed, 18 Jan 2006 16:45:58 -0500
Received: from [10.10.10.11] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001568912.msg
	for ; Wed, 18 Jan 2006 22:39:10 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Wed, 18 Jan 2006 22:36:49 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
Thread-Index: AcYcd0m2iDphvohqEdqhXQANky3PwA==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060118:ietf@ietf.org::10Aq6jUXpdPvPTLp:00004r9X
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Wed, 18 Jan 2006 22:39:12 +0100
X-MDAV-Processed: consulintel.es, Wed, 18 Jan 2006 22:39:14 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Content-Transfer-Encoding: 7bit
Subject: FW: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi,

Here is the original announcement and the IETF URL.

Comments please !

Regards,
Jordi



------ Mensaje reenviado
De: "Internet-Drafts@ietf.org" 
Responder a: "Internet-Drafts@ietf.org" 
Fecha: Wed, 18 Jan 2006 15:50:01 -0500
Para: 
Asunto: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


 Title  : IETF Meeting Venue Selection Criteria
 Author(s) : J. Palet
 Filename : draft-palet-ietf-meeting-venue-selection-criteria-04.txt
 Pages  : 18
 Date  : 2006-1-18
 
This document provides the IAD with technical and logistic criteria
   for selecting venues for IETF meetings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection
-criteria-04.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
 "get draft-palet-ietf-meeting-venue-selection-criteria-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
 mailserv@ietf.org.
In the body type:
 "FILE 
/internet-drafts/draft-palet-ietf-meeting-venue-selection-criteria-04.txt".
 
NOTE: The mail server at ietf.org can return the document in
 MIME-encoded form by using the "mpack" utility.  To use this
 feature, insert the command "ENCODING mime" before the "FILE"
 command.  To decode the response(s), you will need "munpack" or
 a MIME-compliant mail reader.  Different MIME-compliant mail readers
 exhibit different behavior, especially when dealing with
 "multipart" MIME messages (i.e. documents which have been split
 up into multiple messages), so check your local documentation on
 how to manipulate these messages.
  
  
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2006-1-18120040.I-D@ietf.org>

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

------ Fin del mensaje reenviado




**********************************************
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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 16:54:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzLGW-0007Fq-5n; Wed, 18 Jan 2006 16:54:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLGT-00079c-SG
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 16:54:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11747
	for ; Wed, 18 Jan 2006 16:53:22 -0500 (EST)
Received: from monster.hopcount.ca ([199.212.90.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzLOp-0008QE-2t
	for ietf@ietf.org; Wed, 18 Jan 2006 17:03:30 -0500
Received: from octopus.hopcount.ca ([199.212.90.5])
	by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.60 (FreeBSD)) (envelope-from )
	id 1EzLFr-0003Lu-Sj; Wed, 18 Jan 2006 21:54:12 +0000
In-Reply-To: <200601182034.PAA21398@ietf.org>
References: <200601182034.PAA21398@ietf.org>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Joe Abley 
Date: Wed, 18 Jan 2006 16:54:10 -0500
To: dassa@dhs.org
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On 18-Jan-2006, at 15:35, Dassa wrote:

> I don't see the 70% of access points being open actually.  My own  
> figures
> indicate less than 20% within the local area, information from  
> capital cities
> tends to suggest a slightly higher figure but certainly not that high.

It depends a lot on the nature of local internet services, I think.

Where I live, flate-rate 3-5Mbit/s cable/DSL internet service is  
cheaper than buying a dedicated phone line to use with a modem at  
~56k, and consumer-grade 802.11g access points can be had for a  
couple of dollars after mail-in rebates.

 From informal wandering around my residential neighbourhood, I would  
say that >98% of access points reachable from the street have no  
access control.

Since there are no scary bills that arrive from ISPs at the end of  
the month if someone outside has been red-lining the DSL, I suspect  
that people have little incentive to keep other people out.

I also suspect that since DSL and cable internet service is so cheap  
here, for most people it's far more sensible to pay for their own  
rather than to stand out on the street in the snow with a laptop and  
a pringles can.

I doubt that it's possible to reverse the trend of widespread,  
unsecured network access. Any manufacturer of access points who turns  
on security measures by default with a random, device-specific  
initial password supplied in the documentation is (a) going to have  
higher production costs, and (b) much higher support costs than  
competitors who ship everything open and ready to run with no  
configuration.

Maybe it doesn't matter. I struggle with the idea that there might be  
roving gangs of organised criminals stealing internet access from  
wifi-equipped black vans. There are surely much cheaper, less labour- 
intensive ways to gain illicit access to the network than that.

(It has certainly been very handy for me, more than once, to be able  
to use my neighbour's cable modem from my living room via 802.11  
while my DSL was down.)

If there's a lesson to be learned here, maybe it's this: if you  
aspire to see your protocol or service reach widespread, consumer- 
level acceptance, and it is desirable that the service or protocol be  
deployed securely, remember that if the security is optional nobody  
will turn it on.


Joe


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 17:26:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzLkw-00050n-CY; Wed, 18 Jan 2006 17:26:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLks-00050V-O1
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 17:26:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16112
	for ; Wed, 18 Jan 2006 17:24:47 -0500 (EST)
Received: from robin.verisign.com ([65.205.251.75])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzLtH-0001u2-8t
	for ietf@ietf.org; Wed, 18 Jan 2006 17:34:56 -0500
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com
	[65.205.251.34])
	by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k0IMPweC023141;
	Wed, 18 Jan 2006 14:25:58 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by
	mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 18 Jan 2006 14:25:58 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Jan 2006 14:25:56 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD3787AB4F@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Thread-Topic: Wireless at IETF
Thread-Index: AcYcaKFugdYXDLNVShOrIRCdz1r3FgAEzNEA
From: "Hallam-Baker, Phillip" 
To: "Ted Faber" , "Steven M. Bellovin" 
X-OriginalArrivalTime: 18 Jan 2006 22:25:58.0188 (UTC)
	FILETIME=[27908EC0:01C61C7E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20
> Behalf Of Ted Faber

> On Wed, Jan 18, 2006 at 02:23:49PM -0500, Steven M. Bellovin wrote:
> > In message <20060118185700.GS96731@hut.isi.edu>, Ted Faber writes:
> > >
> > >
> > >On Wed, Jan 18, 2006 at 10:30:31AM -0800, Hallam-Baker,=20
> Phillip wrote:
> > >> The result is that 70% of wireless access points are=20
> open and can=20
> > >> be used by Internet criminals to achieve anonymous access.
> > >
> > >Loaded statement?  Check.
> > >Precise statement? Check.
> > >Supported statement? Hmmmm.....
> > >
> >=20
> > I'm not sure which part your claiming is unsupported; my=20
> own informal=20
> > measurements agree with the 70% number.  I'm not at all=20
> convinced that=20
> > "Internet criminals" use such access points as a major means of=20
> > access, though.
>=20
> Well, none of it's supported.  Your statement above about=20
> informal measurements is support for your statement of 70%=20
> and indirectly of his.

The figure came from a presentation at an (anti-) Internet crime
meeting. I do not remember the source.=20

Although I do have similar concerns about figures like that being
repeated without verification it is certainly believable and compatible
with my own experience.=20


> Going from an open access point to anonymous criminal access=20
> seems much more implausible to me.  There are all sorts of=20
> hurdles one could put up between "no link level protection"=20
> and "anonymous criminal access."  But again, I'm wrong all=20
> the time and a citation for that much more damning statement=20
> would be very welcome.  Without one I feel like I'm watching=20
> local news.

As for the use made by criminals, that has been documented and the
frequency is increasing. In one case in Toronto a pedophile was caught
surfing the Internet from his car with no trousers on... We see quite a
few script kiddie level hackers using open WiFi connections.


It would not have been difficult to design WiFi in such a way that it
was secure by default. None of the mechanisms provided to consumers has
met that requirement.=20



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 18:09:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzMQN-0003H9-DC; Wed, 18 Jan 2006 18:09:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzMQK-0003Em-Ik; Wed, 18 Jan 2006 18:09:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18896;
	Wed, 18 Jan 2006 18:07:39 -0500 (EST)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1EzMYj-0003ER-Ce; Wed, 18 Jan 2006 18:17:46 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170])
	by minbar.fac.cs.cmu.edu id aa20341; 18 Jan 2006 18:08 EST
Date: Wed, 18 Jan 2006 18:08:15 -0500
From: Jeffrey Hutzelman 
To: Harald Tveit Alvestrand , iesg@ietf.org
Message-ID: 
In-Reply-To: <961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
References: 
	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
Originator-Info: login-token=Mulberry:01WaY0ZsMOqdql8aznjCRk1fAYa5Hg2q3GG2LLjyY=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: geopriv@ietf.org, ietf@ietf.org
Subject: Re: Last Call: 'Location Types Registry' to Proposed Standard 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Wednesday, January 18, 2006 08:30:56 AM +0100 Harald Tveit Alvestrand 
 wrote:

> I oppose approval of this document as-is.
>
> Four reasons:
>
> 1) FCFS is inappropriate
> 2) The document gives inadequate context for use
> 3) The document gives inadequate procedures

Agree.

> 4) The definition of "automobile" is wrong

Eh.  It's a protocol constant; they can define it however they want.
As long as they let me register 'wyoming' to mean the entity is in a 
fictional location.

-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 18:50:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzN4I-0002ZN-Gi; Wed, 18 Jan 2006 18:50:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzN4G-0002Yb-8d
	for ietf@megatron.ietf.org; Wed, 18 Jan 2006 18:50:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21774
	for ; Wed, 18 Jan 2006 18:48:54 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzNCg-0004Ym-E6
	for ietf@ietf.org; Wed, 18 Jan 2006 18:59:02 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0INlxi09832;
	Wed, 18 Jan 2006 15:47:59 -0800 (PST)
Received: (from faber@localhost)
	by hut.isi.edu (8.13.4/8.13.4/Submit) id k0INlxOn094157;
	Wed, 18 Jan 2006 15:47:59 -0800 (PST) (envelope-from faber)
Date: Wed, 18 Jan 2006 15:47:59 -0800
From: Ted Faber 
To: "Hallam-Baker, Phillip" 
Message-ID: <20060118234759.GU96731@hut.isi.edu>
References: <198A730C2044DE4A96749D13E167AD3787AB4F@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Mime-Version: 1.0
In-Reply-To: <198A730C2044DE4A96749D13E167AD3787AB4F@MOU1WNEXMB04.vcorp.ad.vrsn.com>
User-Agent: Mutt/1.4.2.1i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: ietf@ietf.org, "Steven M. Bellovin" 
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1462514972=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============1462514972==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="DFFMAMYvrfM3lt66"
Content-Disposition: inline


--DFFMAMYvrfM3lt66
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 18, 2006 at 02:25:56PM -0800, Hallam-Baker, Phillip wrote:
> > Well, none of it's supported.  Your statement above about=20
> > informal measurements is support for your statement of 70%=20
> > and indirectly of his.
>=20
> The figure came from a presentation at an (anti-) Internet crime
> meeting. I do not remember the source.=20
>=20
> Although I do have similar concerns about figures like that being
> repeated without verification it is certainly believable and compatible
> with my own experience.=20

I am being something of a stickler, which isn't your fault.  I actually
agree with the number's plausibility if it's a measure of networks run
without any authentication at the link level.  I certainly think the
technology is much more insecure than it needs to be.

>=20
>=20
> > Going from an open access point to anonymous criminal access=20
> > seems much more implausible to me.  There are all sorts of=20
> > hurdles one could put up between "no link level protection"=20
> > and "anonymous criminal access."  But again, I'm wrong all=20
> > the time and a citation for that much more damning statement=20
> > would be very welcome.  Without one I feel like I'm watching=20
> > local news.
>=20
> As for the use made by criminals, that has been documented and the
> frequency is increasing. In one case in Toronto a pedophile was caught
> surfing the Internet from his car with no trousers on... We see quite a
> few script kiddie level hackers using open WiFi connections.

One pedophile: check. :-)

I'm not sure that the pedophile surfing the net from his paid-for DSL
line is any better from a societal perspective, but it might make
prosecution easier.=20

I think that predatory behavior does not come disproportionately from
WiFi users who gain access through hacking open access points.  I can't
support that, but my guess is that people tend to stay out of public
when committing acts they know to be frowned on by most.  It certainly
would have been the best interest of the fellow in your example to have
been in private.

The script-kiddie attacks on WiFi installations are much more on point,
IMHO.  That's a denial of service that is only possible because the
securty system of the media was screwed up.  It's much less melodramatic
than the fellow wardriving with no pants, though.

> It would not have been difficult to design WiFi in such a way that it
> was secure by default. None of the mechanisms provided to consumers has
> met that requirement.=20

Secure design is usually difficult in my experience, but I agree that
it's unfortunate that we didn't do better and haven't really done
better.  But the situation really is bad enough without adding
half-naked pedophiles to the mix.

--=20
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.=
asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#=
SIG

--DFFMAMYvrfM3lt66
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDztOvaUz3f+Zf+XsRAqsDAKD+T1K9vxPaEloTcsNstb+h0tCurgCeM3KH
rsk68Vuue9KO2M+ozm+VqQ0=
=/gHQ
-----END PGP SIGNATURE-----

--DFFMAMYvrfM3lt66--


--===============1462514972==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1462514972==--




From ietf-bounces@ietf.org Wed Jan 18 20:07:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzOGe-0004v9-Qr; Wed, 18 Jan 2006 20:07:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzOGd-0004tk-0o; Wed, 18 Jan 2006 20:07:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27275;
	Wed, 18 Jan 2006 20:05:44 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzOP4-000762-0k; Wed, 18 Jan 2006 20:15:54 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0J16pnA029142; Wed, 18 Jan 2006 20:06:52 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA15196; 
	Wed, 18 Jan 2006 20:06:52 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Wed, 18 Jan 2006 20:06:51 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88633E@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'iesg@ietf.org'" 
Date: Wed, 18 Jan 2006 20:06:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: ietf@ietf.org
Subject: RE: Last Call: 'A Roadmap for TCP Specification Documents' to  In
	formational RFC 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

If we can make positive comments, I think this is a really
useful document to have...

--
Eric

--> -----Original Message-----
--> From: ietf-announce-bounces@ietf.org 
--> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG
--> Sent: Wednesday, January 18, 2006 4:39 PM
--> To: IETF-Announce
--> Cc: tcpm@ietf.org
--> Subject: Last Call: 'A Roadmap for TCP Specification 
--> Documents' to Informational RFC 
--> 
--> The IESG has received a request from the TCP Maintenance 
--> and Minor Extensions 
--> WG to consider the following document:
--> 
--> - 'A Roadmap for TCP Specification Documents '
-->     as an Informational RFC
--> 
--> The IESG plans to make a decision in the next few weeks, 
--> and solicits
--> final comments on this action.  Please send any comments to the
--> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-01.
--> 
--> The file can be obtained via
--> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-road
--> map-05.txt
--> 
--> 
--> _______________________________________________
--> IETF-Announce mailing list
--> IETF-Announce@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf-announce
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 18 22:49:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzQnq-0001cS-4k; Wed, 18 Jan 2006 22:49:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzQnk-0001bN-RY; Wed, 18 Jan 2006 22:49:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13856;
	Wed, 18 Jan 2006 22:48:05 -0500 (EST)
Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzQwC-0005if-BI; Wed, 18 Jan 2006 22:58:17 -0500
Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net
	[141.153.211.136]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id
	k0J3nSwx016640
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Wed, 18 Jan 2006 22:49:28 -0500 (EST)
In-Reply-To: <961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
References: 
	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne 
Date: Wed, 18 Jan 2006 22:49:27 -0500
To: Harald Tveit Alvestrand 
X-Mailer: Apple Mail (2.746.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: 7bit
Cc: geopriv@ietf.org, iesg@ietf.org, ietf@ietf.org
Subject: Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed
	Standard 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Some additional comments on closer reading and a general comment:

This registry intentionally (if you look at the RPID document) is not  
meant to directly extend the RPID schema. I suppose that one could  
add that any location types added automatically become XML elements  
in the urn:ietf:params:xml:ns:pidf:rpid namespace. I don't know if  
that's appropriate. I think it's appropriate (and necessary to add)  
that any registrations must be legal XML element names.

>
> 2) Inadequate context for use:
>
> The document does not make reference to RPID, except in  
> "acknowledgement". Thus, it has to be interpreted as stand-alone,  
> and must contain its own guidance. RPID states:
>
>
>
> These things guide the usage of place-types in RPID, but cannot be  
> found from the registry document.
>

Since usage will strongly depend on the context and since this  
registry is not limited to RPID, I think this would belong into RPID  
(or other documents), not the registry.

> This document SHOULD give guidance for usage, saying at least:
>
> - whether it's intended that several of these values can be used  
> together

I'd assume yes, in general, but defining that seems to be the role of  
the protocol using these elements, not a registry.

I think of the registry like a dictionary. A dictionary does not  
define which words you can use together.

> - whether it's intended that a sequence of location types gives a  
> progressively more precise set of terms (in which case  
> internationalizing the last type you understand is appropriate) or  
> names an intersection of the classes (in which case you would have  
> to internationalize all of them).

There is no implication of hierarchy. In general, this seems  
difficult to achieve since not all location types are hierarchical.  
For example, an airport might contain a bank or a shopping-area, but  
that does not make either a subcategory of an airport.

I also don't understand the need for I18N, since these are tokens  
that would be translated by a local application, not rendered to users.


> - whether having a text string alongside it (the "note" above) is a  
> recommended practice.

That's again an RPID issue. Not every protocol using these tokens  
will have notes.

>
> It MAY be appropriate to say something about field of use, like  
> RPID does ("what types of communication is appropriate" would lead  
> one to distinguish between "driving a car" and "passenger in a  
> car", while one could imagine that other usages might want to  
> distinguish between "expensive restaurant" and "cheap restaurant").

We are not trying to define a service location protocol that  
describes numerical properties of locations. I don't know how to rule  
this out by legal wording; presumably the expert reviewer can make  
common-sense judgement.




>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 01:05:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzSvU-0003YN-L2; Thu, 19 Jan 2006 01:05:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzSvR-0003YD-1x
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 01:05:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22002
	for ; Thu, 19 Jan 2006 01:04:11 -0500 (EST)
Received: from [202.54.124.151] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzT3k-0001T2-4p
	for ietf@ietf.org; Thu, 19 Jan 2006 01:14:23 -0500
Received: (qmail 7254 invoked by uid 510); 19 Jan 2006 06:04:57 -0000
Date: 19 Jan 2006 06:04:57 -0000
Message-ID: <20060119060457.7253.qmail@webmail6.rediffmail.com>
Received: from unknown (61.8.146.249) by rediffmail.com via HTTP;
	19 jan 2006 06:04:57 -0000
MIME-Version: 1.0
From: "JAGADEESH  PRASAD" 
To: ietf@ietf.org
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Subject: Transport layer Protocol Implementation in GLOMOSIM
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: JAGADEESH  PRASAD 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1349209152=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

 This is a multipart mime message


--===============1349209152==
Content-type: multipart/alternative;
	boundary="Next_1137650697---0-202.54.124.151-7112"

 This is a multipart mime message


--Next_1137650697---0-202.54.124.151-7112
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello all;=0A =A0I am student doing My BE in Electronics & Communication En=
gg.=0A =0AI am starting My BE Final project on stimulation of a Transport l=
ayer protocol. The protocol is proposed for mobile multimedia communication=
 over wireless links.I am considering to use the network simulator - GLOMOS=
IM. =0A =0ASince I am a beginner in the Glomosim. I don't know where to sta=
rt and how to modify it to make it suit my purpose.=0A=0Aplease help.=0ATha=
nk you. =0A=0A=0A=0A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0D=0A<<<<<< JAGDEESH PRA=
SAD >>>>>>=0D=0A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--Next_1137650697---0-202.54.124.151-7112
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=0AHello all;
=0A  I am student doing My BE in Electronics &=
 Communication Engg.
=0A 
=0AI am starting My BE Final project on sti=
mulation of a Transport layer protocol. The protocol is proposed for mobile=
 multimedia communication over wireless links.I am considering to use the n=
etwork simulator - GLOMOSIM. 
=0A 
=0ASince I am a beginner in the Gl=
omosim. I don't know where to start and how to modify it to make it suit my=
 purpose.
=0A
=0Aplease help.
=0AThank you. 
=0A
=0A=0A
=
=0A=0A=0A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0D
=0A<<<<<< J=
AGDEESH PRASAD >>>>>>=0D
=0A~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~

=0A=0A
--Next_1137650697---0-202.54.124.151-7112--



--===============1349209152==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1349209152==--





From ietf-bounces@ietf.org Thu Jan 19 01:08:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzSxw-0003q5-FT; Thu, 19 Jan 2006 01:08:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzSxu-0003q0-Dz
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 01:08:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22153
	for ; Thu, 19 Jan 2006 01:06:44 -0500 (EST)
Received: from [202.54.124.216] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzT6M-0001Xg-Os
	for ietf@ietf.org; Thu, 19 Jan 2006 01:16:56 -0500
Received: (qmail 21032 invoked by uid 510); 19 Jan 2006 06:07:43 -0000
Date: 19 Jan 2006 06:07:43 -0000
Message-ID: <20060119060743.21031.qmail@webmail50.rediffmail.com>
Received: from unknown (61.8.146.249) by rediffmail.com via HTTP;
	19 jan 2006 06:07:43 -0000
MIME-Version: 1.0
From: "JAGADEESH  PRASAD" 
To: ietf@ietf.org
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Subject: Transport layer Protocol Implementation in GLOMOSIM
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: JAGADEESH  PRASAD 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0261358389=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

 This is a multipart mime message


--===============0261358389==
Content-type: multipart/alternative;
	boundary="Next_1137650863---0-202.54.124.216-20963"

 This is a multipart mime message


--Next_1137650863---0-202.54.124.216-20963
Content-type: text/plain;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello all;=0A =A0I am student doing My BE in Electronics & Communication En=
gg.=0A =0AI am starting My BE Final project on stimulation of a Transport l=
ayer protocol. The protocol is proposed for mobile multimedia communication=
 over wireless links.I am considering to use the network simulator - GLOMOS=
IM. =0A =0ASince I am a beginner in the Glomosim. I don't know where to sta=
rt and how to modify it to make it suit my purpose.=0A=0Aplease help.=0ATha=
nk you. =0A=0A=0A=0A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0D=0A<<<<<< JAGDEESH PRA=
SAD >>>>>>=0D=0A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--Next_1137650863---0-202.54.124.216-20963
Content-type: text/html;
	charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=0AHello all;
=0A  I am student doing My BE in Electronics &=
 Communication Engg.
=0A 
=0AI am starting My BE Final project on sti=
mulation of a Transport layer protocol. The protocol is proposed for mobile=
 multimedia communication over wireless links.I am considering to use the n=
etwork simulator - GLOMOSIM. 
=0A 
=0ASince I am a beginner in the Gl=
omosim. I don't know where to start and how to modify it to make it suit my=
 purpose.
=0A
=0Aplease help.
=0AThank you. 
=0A
=0A=0A
=
=0A=0A=0A~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=0D
=0A<<<<<< J=
AGDEESH PRASAD >>>>>>=0D
=0A~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~

=0A=0A
--Next_1137650863---0-202.54.124.216-20963--



--===============0261358389==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0261358389==--





From ietf-bounces@ietf.org Thu Jan 19 02:44:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzUTN-00016a-Br; Thu, 19 Jan 2006 02:44:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzUTI-000163-Tn; Thu, 19 Jan 2006 02:44:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27415;
	Thu, 19 Jan 2006 02:43:14 -0500 (EST)
Received: from relay.imagine.ie ([87.232.1.41])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzUbm-0004IB-Ex; Thu, 19 Jan 2006 02:53:27 -0500
Received: from mail1.int.imagine.ie (mail1 [87.232.1.152])
	by relay.imagine.ie (Postfix) with ESMTP id 89297406E;
	Thu, 19 Jan 2006 07:44:17 +0000 (GMT)
Received: from [127.0.0.1] (dsl-102-234.cust.imagine.ie [87.232.102.234])
	by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id
	k0J7iEto015020; Thu, 19 Jan 2006 07:44:16 GMT
Message-ID: <43CF434B.6070009@cs.tcd.ie>
Date: Thu, 19 Jan 2006 07:44:11 +0000
From: Stephen Farrell 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Henning Schulzrinne 
References: 	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
	<9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
In-Reply-To: <9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00] 
X-Canit-Stats-ID: 282627 - 08aa9332bdf3 (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: geopriv@ietf.org, ietf@ietf.org
Subject: Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed
 Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


A different question:

Henning Schulzrinne wrote:
> Some additional comments on closer reading and a general comment:
> 
> This registry intentionally (if you look at the RPID document) is not 
> meant to directly extend the RPID schema. I suppose that one could add 
> that any location types added automatically become XML elements in the 
> urn:ietf:params:xml:ns:pidf:rpid namespace. I don't know if that's 
> appropriate. 

Doesn't this make it hard/impossible to check if an RPID
document is schema-valid? (I mean keeping some element
names in a list that's not a schema.)

Perhaps that's not important for this application though.

Stephen.




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 05:49:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzXLs-0000Z4-1B; Thu, 19 Jan 2006 05:49:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzXLp-0000Yz-CY
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 05:49:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10655
	for ; Thu, 19 Jan 2006 05:47:42 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzXUI-00024b-14
	for ietf@ietf.org; Thu, 19 Jan 2006 05:57:56 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0JAmtQx023504; 
	Thu, 19 Jan 2006 04:48:55 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 19 Jan 2006 11:48:52 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509155322@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" 
To: "Gray, Eric" 
Date: Thu, 19 Jan 2006 11:48:51 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: ietf@ietf.org
Subject: RE: Last Call: 'A Roadmap for TCP Specification Documents' to  In
	formational RFC 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Thanks Eric, and let me add and make clear that I (and as far
as I know ALL ADs) appreciate these types of comment very much.
Knowing that there are people who read the document, understand 
it and find it useful is good input into our IETF review and
approval process. Much better than silence.

Bert

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On Behalf Of
> Gray, Eric
> Sent: Thursday, January 19, 2006 02:07
> To: 'iesg@ietf.org'
> Cc: ietf@ietf.org
> Subject: RE: Last Call: 'A Roadmap for TCP Specification Documents' to
> In formational RFC 
> 
> 
> If we can make positive comments, I think this is a really
> useful document to have...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: ietf-announce-bounces@ietf.org 
> --> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG
> --> Sent: Wednesday, January 18, 2006 4:39 PM
> --> To: IETF-Announce
> --> Cc: tcpm@ietf.org
> --> Subject: Last Call: 'A Roadmap for TCP Specification 
> --> Documents' to Informational RFC 
> --> 
> --> The IESG has received a request from the TCP Maintenance 
> --> and Minor Extensions 
> --> WG to consider the following document:
> --> 
> --> - 'A Roadmap for TCP Specification Documents '
> -->     as an Informational RFC
> --> 
> --> The IESG plans to make a decision in the next few weeks, 
> --> and solicits
> --> final comments on this action.  Please send any comments to the
> --> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-01.
> --> 
> --> The file can be obtained via
> --> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-road
> --> map-05.txt
> --> 
> --> 
> --> _______________________________________________
> --> IETF-Announce mailing list
> --> IETF-Announce@ietf.org
> --> https://www1.ietf.org/mailman/listinfo/ietf-announce
> --> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 07:59:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzZNW-00088J-3z; Thu, 19 Jan 2006 07:59:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzZNT-00087d-PW; Thu, 19 Jan 2006 07:58:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19696;
	Thu, 19 Jan 2006 07:57:33 -0500 (EST)
Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzZW0-0006MF-7e; Thu, 19 Jan 2006 08:07:49 -0500
Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net
	[141.153.211.136]) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0JCvnmg001502
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Thu, 19 Jan 2006 07:58:48 -0500 (EST)
In-Reply-To: <43CF434B.6070009@cs.tcd.ie>
References: 	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
	<9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
	<43CF434B.6070009@cs.tcd.ie>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <11281FB9-844C-4FD1-8F04-CAEE10CCB899@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne 
Date: Thu, 19 Jan 2006 07:58:46 -0500
To: Stephen Farrell 
X-Mailer: Apple Mail (2.746.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: geopriv@ietf.org, ietf@ietf.org
Subject: Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed
	Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>

Yes, unfortunately it does. Extending element sets seems to be rather  
tedious in the current XML tool set. Either you have the new elements  
extend the old namespace, yielding the problem you mention, or each  
new element (location type, here) gets a new namespace, yielding a  
namespace list a mile long if there are lots of extensions.


> Henning Schulzrinne wrote:
>> Some additional comments on closer reading and a general comment:
>> This registry intentionally (if you look at the RPID document) is  
>> not meant to directly extend the RPID schema. I suppose that one  
>> could add that any location types added automatically become XML  
>> elements in the urn:ietf:params:xml:ns:pidf:rpid namespace. I  
>> don't know if that's appropriate.
>
> Doesn't this make it hard/impossible to check if an RPID
> document is schema-valid? (I mean keeping some element
> names in a list that's not a schema.)
>
> Perhaps that's not important for this application though.
>
> Stephen.
>
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 08:15:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzZdX-0005ng-Fs; Thu, 19 Jan 2006 08:15:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzZdU-0005n6-It; Thu, 19 Jan 2006 08:15:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21498;
	Thu, 19 Jan 2006 08:14:06 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzZm0-00074b-OC; Thu, 19 Jan 2006 08:24:22 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 03511259703;
	Thu, 19 Jan 2006 14:14:16 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 06604-03; Thu, 19 Jan 2006 14:14:09 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 11114259702;
	Thu, 19 Jan 2006 14:14:09 +0100 (CET)
Date: Thu, 19 Jan 2006 14:15:17 +0100
From: Harald Tveit Alvestrand 
To: Henning Schulzrinne 
Message-ID: 
In-Reply-To: <9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
References: 
	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
	<9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Content-Transfer-Encoding: 7bit
Cc: geopriv@ietf.org, ietf@ietf.org
Subject: Re: [Geopriv] Re: Last Call: 'Location Types Registry' to
 Proposed	Standard 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

[taking out the iesg from CC list, but leaving WG and ietf list in]

--On onsdag, januar 18, 2006 22:49:27 -0500 Henning Schulzrinne 
 wrote:

> Some additional comments on closer reading and a general comment:

>> 2) Inadequate context for use:
>>
>> The document does not make reference to RPID, except in
>> "acknowledgement". Thus, it has to be interpreted as stand-alone,
>> and must contain its own guidance. RPID states:
>>
>>
>>
>> These things guide the usage of place-types in RPID, but cannot be
>> found from the registry document.
>>
>
> Since usage will strongly depend on the context and since this  registry
> is not limited to RPID, I think this would belong into RPID  (or other
> documents), not the registry.

Sigh.... I guess we disagree on principles here pretty strongly.

I think that in order for a vocabulary like this to be useful, it has to 
fit its purpose. A vocabulary that is made to fit multiple purposes will in 
the end fit neither - for one recent example, see the discussion between 
the "mail folks" and the "RTP folks" over the proper registration and 
meaning of MIME content-types.

You're defining the vocabulary now, and have the chance for establishing a 
reasonable context. Once it's being used for two purposes with conflicting 
requirements, it's too late to fix it.

>
>> This document SHOULD give guidance for usage, saying at least:
>>
>> - whether it's intended that several of these values can be used
>> together
>
> I'd assume yes, in general, but defining that seems to be the role of
> the protocol using these elements, not a registry.
>
> I think of the registry like a dictionary. A dictionary does not  define
> which words you can use together.

Yes, it does. By implication, a dictionary is for a language, and a 
language is (among other things) a set of rules on how to put the words 
together - and it VERY strongly implies that in order to understand a 
word's meaning, you have to look at its context.

But it's easy to forget about the enormous amount of baggage we have when 
considering a concept like "word", and that there's so little baggage 
attached to a label type like this one.

>> - whether it's intended that a sequence of location types gives a
>> progressively more precise set of terms (in which case
>> internationalizing the last type you understand is appropriate) or
>> names an intersection of the classes (in which case you would have
>> to internationalize all of them).
>
> There is no implication of hierarchy. In general, this seems  difficult
> to achieve since not all location types are hierarchical.  For example,
> an airport might contain a bank or a shopping-area, but  that does not
> make either a subcategory of an airport.

Good - then say so!

> I also don't understand the need for I18N, since these are tokens  that
> would be translated by a local application, not rendered to users.

My mistake - this should have been "localize".

To illustrate: In the flat case, "restroom, cafe, airport" could be 
localized as "Toalett, , Flyplass" in Norwegian if the 
application doesn't know the translation of "cafe"; in the hierarchical 
case, one could imagine "McDonalds, cafe, eating-place, public building, 
indoors" - it would be OK to localize that as "Spisested" if "cafe" isn't 
known.

>
>> - whether having a text string alongside it (the "note" above) is a
>> recommended practice.
>
> That's again an RPID issue. Not every protocol using these tokens  will
> have notes.

There's no second protocol at the moment, so you have the chance to provide 
guidance...

>>
>> It MAY be appropriate to say something about field of use, like
>> RPID does ("what types of communication is appropriate" would lead
>> one to distinguish between "driving a car" and "passenger in a
>> car", while one could imagine that other usages might want to
>> distinguish between "expensive restaurant" and "cheap restaurant").
>
> We are not trying to define a service location protocol that  describes
> numerical properties of locations. I don't know how to rule  this out by
> legal wording; presumably the expert reviewer can make  common-sense
> judgement.

Legal wording isn't what I'm looking for. Hints to the reviewer about what 
the WG considers "common sense" would be helpful.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 10:12:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzbSY-0006bj-CF; Thu, 19 Jan 2006 10:12:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzbSU-0006aX-0o; Thu, 19 Jan 2006 10:12:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29856;
	Thu, 19 Jan 2006 10:10:51 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ezbb2-0002Z4-Cb; Thu, 19 Jan 2006 10:21:08 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1EzbSD-0004Lf-8G; Thu, 19 Jan 2006 07:12:01 -0800
Message-Id: <6.2.3.4.2.20060119152629.07a63790@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Thu, 19 Jan 2006 16:11:52 +0100
To: Harald Tveit Alvestrand ,
	Henning Schulzrinne 
From: "JFC (Jefsey) Morfin" 
In-Reply-To: 
References: 
	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
	<9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-203F1C60
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f
Cc: geopriv@ietf.org, ietf@ietf.org, iesg@iesg.org
Subject: Re: [Geopriv] Re: Last Call: 'Location Types Registry' to
 Proposed	Standard 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi! Harald,
We fully agree on this. But I see you are fighting here the same 
difficulty I fight against you for languages. They propose words in 
their language context as you propose languages tags in your 
internationalised context. They do the same layer violation as you 
do. The only solution to this is to conceptualise and to universalise 
the concept. ISO 11179. You define a concept, give it a unique ID 
(building a referent) and as many names as you need which name the 
concept, not its version in a given context. However I agree 
JTC1/SG32/W2 has not yet addressed the multilingual and the networked 
aspects. But IETF have clumsily approached it with IDNA and very well 
with the DNS.

The problem is that the whole process has to be "multiterative". When 
you consider your "internationalization", the concept named in 
English is to be adapted into the locale culture which tries to 
understand your concept the same way as you do (this is monologue). 
This is workable but gives leadership (and economical, cultural, 
political, technical advantages to the American end). Better you have 
a true dialog where the American concepts includes the other end's 
concepts. Unicode very partly does that for texts items.

"multinationalisation" calls for the concept to be equally understood 
(what does "understand" mean?) the same way between every cultures 
(every ends are equal). Either because the concept is truly 
universal. Or because you built all the cross-national in-between 
extended services to permit a polylogual relation. This means that 
when an American end says "kitchen", the French end will receive 
"American style Kitchen" (our kithens are not _built_ the same way 
and do not include the same set of things).

I take a very common example. Many languages have the same term for 
blue and green and only consider them as different shades. Recent 
studies shown that people of different languages describe the 
different variations of blue/green the same way with the right eye 
(left brain) but differently with the left eye (right brain), 
depending on the language.

A friend of mine works on dictionary about kids: the way kids 
understand the same thing around the world. Example: "bring me some 
water" implies many different things to do if the kid lives in a 
flat, in a farm, in a desert, in the USA, in Bangladesh, etc. and the 
water may be very different.

Welcome in multinationalisation and DRS preparatory work. BTW IAB 
will say if this is an IETF matter or not.
jfc


At 14:15 19/01/2006, Harald Tveit Alvestrand wrote:
>[taking out the iesg from CC list, but leaving WG and ietf list in]
>
>--On onsdag, januar 18, 2006 22:49:27 -0500 Henning Schulzrinne 
> wrote:
>
>>Some additional comments on closer reading and a general comment:
>
>>>2) Inadequate context for use:
>>>
>>>The document does not make reference to RPID, except in
>>>"acknowledgement". Thus, it has to be interpreted as stand-alone,
>>>and must contain its own guidance. RPID states:
>>>
>>>
>>>
>>>These things guide the usage of place-types in RPID, but cannot be
>>>found from the registry document.
>>
>>Since usage will strongly depend on the context and since this  registry
>>is not limited to RPID, I think this would belong into RPID  (or other
>>documents), not the registry.
>
>Sigh.... I guess we disagree on principles here pretty strongly.
>
>I think that in order for a vocabulary like this to be useful, it 
>has to fit its purpose. A vocabulary that is made to fit multiple 
>purposes will in the end fit neither - for one recent example, see 
>the discussion between the "mail folks" and the "RTP folks" over the 
>proper registration and meaning of MIME content-types.
>
>You're defining the vocabulary now, and have the chance for 
>establishing a reasonable context. Once it's being used for two 
>purposes with conflicting requirements, it's too late to fix it.
>
>>
>>>This document SHOULD give guidance for usage, saying at least:
>>>
>>>- whether it's intended that several of these values can be used
>>>together
>>
>>I'd assume yes, in general, but defining that seems to be the role of
>>the protocol using these elements, not a registry.
>>
>>I think of the registry like a dictionary. A dictionary does not  define
>>which words you can use together.
>
>Yes, it does. By implication, a dictionary is for a language, and a 
>language is (among other things) a set of rules on how to put the 
>words together - and it VERY strongly implies that in order to 
>understand a word's meaning, you have to look at its context.
>
>But it's easy to forget about the enormous amount of baggage we have 
>when considering a concept like "word", and that there's so little 
>baggage attached to a label type like this one.
>
>>>- whether it's intended that a sequence of location types gives a
>>>progressively more precise set of terms (in which case
>>>internationalizing the last type you understand is appropriate) or
>>>names an intersection of the classes (in which case you would have
>>>to internationalize all of them).
>>
>>There is no implication of hierarchy. In general, this seems  difficult
>>to achieve since not all location types are hierarchical.  For example,
>>an airport might contain a bank or a shopping-area, but  that does not
>>make either a subcategory of an airport.
>
>Good - then say so!
>
>>I also don't understand the need for I18N, since these are tokens  that
>>would be translated by a local application, not rendered to users.
>
>My mistake - this should have been "localize".
>
>To illustrate: In the flat case, "restroom, cafe, airport" could be 
>localized as "Toalett, , Flyplass" in Norwegian if the 
>application doesn't know the translation of "cafe"; in the 
>hierarchical case, one could imagine "McDonalds, cafe, eating-place, 
>public building, indoors" - it would be OK to localize that as 
>"Spisested" if "cafe" isn't known.
>
>>
>>>- whether having a text string alongside it (the "note" above) is a
>>>recommended practice.
>>
>>That's again an RPID issue. Not every protocol using these tokens  will
>>have notes.
>
>There's no second protocol at the moment, so you have the chance to 
>provide guidance...
>
>>>
>>>It MAY be appropriate to say something about field of use, like
>>>RPID does ("what types of communication is appropriate" would lead
>>>one to distinguish between "driving a car" and "passenger in a
>>>car", while one could imagine that other usages might want to
>>>distinguish between "expensive restaurant" and "cheap restaurant").
>>
>>We are not trying to define a service location protocol that  describes
>>numerical properties of locations. I don't know how to rule  this out by
>>legal wording; presumably the expert reviewer can make  common-sense
>>judgement.
>
>Legal wording isn't what I'm looking for. Hints to the reviewer 
>about what the WG considers "common sense" would be helpful.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 14:28:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzfSs-0000Fh-NG; Thu, 19 Jan 2006 14:28:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzfSq-0000FN-9s
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 14:28:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19478
	for ; Thu, 19 Jan 2006 14:27:29 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzfbN-0002NT-Ux
	for ietf@ietf.org; Thu, 19 Jan 2006 14:37:49 -0500
Received: from [10.31.13.193] (neustargw.va.neustar.com [209.173.53.233])
	(authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0JJTIFh009023
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 19 Jan 2006 11:29:20 -0800
Message-ID: <43CFE866.8030405@shockey.us>
Date: Thu, 19 Jan 2006 14:28:38 -0500
From: Richard Shockey 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: IETF list 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Subject: Re: FW: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

JORDI PALET MARTINEZ wrote:
> Hi,
> 
> Here is the original announcement and the IETF URL.
> 
> Comments please !
> 


I'm assuming this is going to be Informational only and as such not 
formally binding on the IAOC on the Secretariat.

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".

This IMHO should have come directly out of the IAOC as the subject 
matter is directly within their oversight and charter.

What is the relationship of this document to the IAOC?

Frankly there is'nt much about this document I like. It's a classic 
example of the current IETF fashion for process over substance.



> 
> 
>  Title  : IETF Meeting Venue Selection Criteria
>  Author(s) : J. Palet
>  Filename : draft-palet-ietf-meeting-venue-selection-criteria-04.txt
>  Pages  : 18
>  Date  : 2006-1-18
>  
> This document provides the IAD with technical and logistic criteria
>    for selecting venues for IETF meetings.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection
> -criteria-04.txt
-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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
 or

 ; 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 14:57:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezfux-0002aS-JA; Thu, 19 Jan 2006 14:57:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezfuv-0002aA-NM
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 14:57:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21964
	for ; Thu, 19 Jan 2006 14:56:31 -0500 (EST)
Received: from relay1.mail.uk.clara.net ([80.168.70.141])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezg3U-0003Dm-ON
	for ietf@ietf.org; Thu, 19 Jan 2006 15:06:51 -0500
Received: from du-069-0039.access.clara.net ([217.158.132.39] helo=Puppy)
	by relay1.mail.uk.clara.net with esmtp (Exim 4.46)
	id 1Ezfua-0004ty-Ia
	for ietf@ietf.org; Thu, 19 Jan 2006 19:57:37 +0000
Message-ID: <075701c61d33$23bb8fb0$82849ed9@Puppy>
From: "Adrian Farrel" 
To: "IETF list" 
References: 
	<43CFE866.8030405@shockey.us>
Date: Thu, 19 Jan 2006 20:01:25 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Subject: Re: FW:
	I-DACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Well Jordi,

That told you, didn't it?

Richard, do you speak for the Secretariat, for NeuStar, or for yourself?

Adrian


Richard Shockey  might have said...

> I'm assuming this is going to be Informational only and as such not
> formally binding on the IAOC on the Secretariat.
>
> 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".
>
> This IMHO should have come directly out of the IAOC as the subject
> matter is directly within their oversight and charter.
>
> What is the relationship of this document to the IAOC?
>
> Frankly there is'nt much about this document I like. It's a classic
> example of the current IETF fashion for process over substance.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>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
> or
>
> ; 
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 15:36:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzgW7-0001sr-Ok; Thu, 19 Jan 2006 15:36:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzgW6-0001lO-HZ
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 15:36:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24739
	for ; Thu, 19 Jan 2006 15:34:52 -0500 (EST)
Received: from netcore.fi ([193.94.160.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezged-0004Sv-KK
	for ietf@ietf.org; Thu, 19 Jan 2006 15:45:13 -0500
Received: from netcore.fi (localhost [127.0.0.1])
	by netcore.fi (8.12.8/8.12.8) with ESMTP id k0JKZvHa027676
	for ; Thu, 19 Jan 2006 22:35:57 +0200
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0JKZvsN027673
	for ; Thu, 19 Jan 2006 22:35:57 +0200
Date: Thu, 19 Jan 2006 22:35:57 +0200 (EET)
From: Pekka Savola 
To: IETF list 
In-Reply-To: <43CFE866.8030405@shockey.us>
Message-ID: 
References: 
	<43CFE866.8030405@shockey.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: ClamAV 0.87.1/1245/Wed Jan 18 18:57:44 2006 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed 
	version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Subject: Re: FW: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Thu, 19 Jan 2006, Richard Shockey wrote:
> This IMHO should have come directly out of the IAOC as the subject matter is 
> directly within their oversight and charter.
>
> What is the relationship of this document to the IAOC?

I agree that these are valid points.  Spending cycles on this document 
isn't much use unless IAOC et al "buy in" into it.  Could someone from 
the "powers that be" say something on their thoughts on how venue 
selection criteria (etc.) should be developed?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 15:58:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezgrt-0004GP-Qm; Thu, 19 Jan 2006 15:58:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezgrr-0004Fr-LU; Thu, 19 Jan 2006 15:58:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26582;
	Thu, 19 Jan 2006 15:57:24 -0500 (EST)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ezh0R-0005Ml-P1; Thu, 19 Jan 2006 16:07:45 -0500
Received: from lion.cs.columbia.edu
	(IDENT:yjQJxrE6blirg+uEtNdTc8wMJ13OIf2c@lion.cs.columbia.edu
	[128.59.16.120])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k0JKwgKG026174
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); 
	Thu, 19 Jan 2006 15:58:42 -0500 (EST)
Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206])
	(authenticated bits=0)
	by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k0JKwfnE028621
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Thu, 19 Jan 2006 15:58:42 -0500
Message-ID: <43CFFCF5.1090007@cs.columbia.edu>
Date: Thu, 19 Jan 2006 15:56:21 -0500
From: Henning Schulzrinne 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Harald Tveit Alvestrand 
References: 
	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
	<9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: geopriv@ietf.org, ietf@ietf.org
Subject: Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed
 Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> I think that in order for a vocabulary like this to be useful, it has to 
> fit its purpose. A vocabulary that is made to fit multiple purposes will 
> in the end fit neither - for one recent example, see the discussion 
> between the "mail folks" and the "RTP folks" over the proper 
> registration and meaning of MIME content-types.

I can't prove or disprove that statement, unfortunately. We won't know 
whether the location types will be useful until somebody uses them. I 
suspect that "real" GIS applications will need a far more specialized 
vocabulary, but it turns out that, for example, a proposal for crime 
scene labeling more or less fits into the proposed registered list. (We 
found this out after creating the list.)

Currently, there are two potential customers: RPID and AAA.


> Yes, it does. By implication, a dictionary is for a language, and a 
> language is (among other things) a set of rules on how to put the words 
> together - and it VERY strongly implies that in order to understand a 
> word's meaning, you have to look at its context.

Dictionaries I know generally define the word by itself. Indeed, many of 
the definitions in the document are very close to (English) dictionary 
definitions.


> To illustrate: In the flat case, "restroom, cafe, airport" could be 
> localized as "Toalett, , Flyplass" in Norwegian if the 
> application doesn't know the translation of "cafe"; in the hierarchical 
> case, one could imagine "McDonalds, cafe, eating-place, public building, 
> indoors" - it would be OK to localize that as "Spisested" if "cafe" 
> isn't known.

We'll note in the draft that there is no implied hierarchy, except where 
noted. (For example, 'restaurant' is an umbrella term that includes 
'cafe' and 'bar'.)


> 
>>
>>> - whether having a text string alongside it (the "note" above) is a
>>> recommended practice.
>>
>> That's again an RPID issue. Not every protocol using these tokens  will
>> have notes.
> 
> There's no second protocol at the moment, so you have the chance to 
> provide guidance...

Yes: AAA 
(http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt)


> Legal wording isn't what I'm looking for. Hints to the reviewer about 
> what the WG considers "common sense" would be helpful.

To better understand what you have in mind, can you give an example? 
There are some obvious things, like:

- not specific to a country
- not a specific company or organization
- well-defined
- widely recognized

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 16:43:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzhZV-0002OA-3D; Thu, 19 Jan 2006 16:43:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzhZS-0002O5-W3
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 16:43:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29349
	for ; Thu, 19 Jan 2006 16:42:27 -0500 (EST)
Received: from above.proper.com ([208.184.76.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezhi3-0006bg-JG
	for ietf@ietf.org; Thu, 19 Jan 2006 16:52:49 -0500
Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net
	[66.125.125.65]) (authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JLhkf0085086;
	Thu, 19 Jan 2006 13:43:47 -0800 (PST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <43CFE866.8030405@shockey.us>
References: 
	<43CFE866.8030405@shockey.us>
Date: Thu, 19 Jan 2006 12:43:42 -0800
To: Richard Shockey , IETF list 
From: Paul Hoffman 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Cc: 
Subject: Re: FW: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 2:28 PM -0500 1/19/06, Richard Shockey wrote:
>It's a classic example of the current IETF fashion for process over substance.

Fully agree. What is the justification for this becoming an RFC?

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 16:57:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzhmK-0008M2-3O; Thu, 19 Jan 2006 16:57:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzhmH-0008LL-Aw; Thu, 19 Jan 2006 16:57:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00676;
	Thu, 19 Jan 2006 16:55:42 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ezhus-000770-9X; Thu, 19 Jan 2006 17:06:03 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 7B89B25972B;
	Thu, 19 Jan 2006 22:55:52 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 21234-10; Thu, 19 Jan 2006 22:55:47 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 8FB2F25972A;
	Thu, 19 Jan 2006 22:55:47 +0100 (CET)
Date: Thu, 19 Jan 2006 22:56:53 +0100
From: Harald Tveit Alvestrand 
To: Henning Schulzrinne 
Message-ID: <28764B6ADD3E0BD23A546D2F@svartdal.hjemme.alvestrand.no>
In-Reply-To: <43CFFCF5.1090007@cs.columbia.edu>
References: 
	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
	<9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
	
	<43CFFCF5.1090007@cs.columbia.edu>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: geopriv@ietf.org, ietf@ietf.org
Subject: Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed
 Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On torsdag, januar 19, 2006 15:56:21 -0500 Henning Schulzrinne 
 wrote:

>>> That's again an RPID issue. Not every protocol using these tokens  will
>>> have notes.
>>
>> There's no second protocol at the moment, so you have the chance to
>> provide guidance...
>
> Yes: AAA
> (http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt)

Right - the wording there is an argument in favour of centralizing guidance 
(it has none).....

>> Legal wording isn't what I'm looking for. Hints to the reviewer about
>> what the WG considers "common sense" would be helpful.
>
> To better understand what you have in mind, can you give an example?
> There are some obvious things, like:
>
> - not specific to a country
> - not a specific company or organization
> - well-defined
> - widely recognized

That's good guidelines for a reviewer. It would allow him to reject both 
"McDonalds" (company) and "Lavvo" (Sami tent, not widely recognized), but 
would probably accept "open ocean" and "river" (if it was used in a context 
about where a boat is, these might make sense).

I'd say "not specific to a country or language".
Go for it.







_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 17:03:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezhry-0002MR-PJ; Thu, 19 Jan 2006 17:03:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezhrw-0002LZ-Gt
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 17:03:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01205
	for ; Thu, 19 Jan 2006 17:01:33 -0500 (EST)
Received: from rwcrmhc14.comcast.net ([216.148.227.154]
	helo=rwcrmhc12.comcast.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezi0T-0007KN-H0
	for ietf@ietf.org; Thu, 19 Jan 2006 17:11:54 -0500
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165])
	by comcast.net (rwcrmhc14) with SMTP
	id <20060119220244014002e8ste>; Thu, 19 Jan 2006 22:02:44 +0000
Message-ID: <2d2701c61d43$e8f8c670$d0087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: "IETF list" 
References: <43CFE866.8030405@shockey.us>
	
Date: Thu, 19 Jan 2006 16:01:32 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Subject: Re: FW: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

From: "Paul Hoffman" 
> At 2:28 PM -0500 1/19/06, Richard Shockey wrote:
>>It's a classic example of the current IETF fashion for process over 
>>substance.
>
> Fully agree. What is the justification for this becoming an RFC?

Well, backing up slightly ...

How much of our process stuff (including existing BCPs) really needs to be 
published as an RFC?

Some does, I suppose, but "never changes" doesn't seem like the model we 
should search for on venue selection (the venue selection model used for the 
first 10 IETF meetings probably wouldn't have even booked us into 
Minneapolis, much less Adelaide!).

Having said this, I hope the IAOC does find this document useful input 
(because if they don't, people have sure been wasting zeros and ones on THIS 
list...

Thanks,

Spencer 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 17:21:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezi9i-0000ih-F0; Thu, 19 Jan 2006 17:21:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezi9f-0000i8-T2; Thu, 19 Jan 2006 17:21:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02856;
	Thu, 19 Jan 2006 17:19:52 -0500 (EST)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1EziIG-0007zd-UX; Thu, 19 Jan 2006 17:30:14 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170])
	by minbar.fac.cs.cmu.edu id aa22606; 19 Jan 2006 17:20 EST
Date: Thu, 19 Jan 2006 17:20:57 -0500
From: Jeffrey Hutzelman 
To: Henning Schulzrinne ,
	Harald Tveit Alvestrand 
Message-ID: <8C5CD199116024CF932FB859@sirius.fac.cs.cmu.edu>
In-Reply-To: <43CFFCF5.1090007@cs.columbia.edu>
References: 
	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
	<9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
	
	<43CFFCF5.1090007@cs.columbia.edu>
Originator-Info: login-token=Mulberry:011oo0zEDyqUAi1axNCQhkO238a/ddvq1D/2IxDAo=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: geopriv@ietf.org, ietf@ietf.org
Subject: Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed
 Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Thursday, January 19, 2006 03:56:21 PM -0500 Henning Schulzrinne 
 wrote:

> Dictionaries I know generally define the word by itself. Indeed, many of
> the definitions in the document are very close to (English) dictionary
> definitions.

Dictionaries define a word, including specifying one or more parts of 
speech, which are the places in the language syntax where the word can be 
used.  And, as already noted, dictionaries are not abstract lists of words; 
they are tied to specific languages.  For some languages, they provide 
additional information affecting the syntax surrounding the word.

Good dictionaries also provide examples of real-world usage.  In fact, 
according its website, the OED normally requires several examples of use 
before a word will be included, and it is these examples which are used to 
determine the word's definition.


Note that the process is considerably different for protocol parameters, 
where we first decide exactly what we want to be able to say, and then 
assign a protocol parameter which means that.  Then, the parameter is not 
in any natural language, but in the "language" of whatever wire protocol 
uses it -- that is why we can name protocol parameters in English without 
needing to worry about how to "localize" -- the meaning is 
language-independent.  Of course, non-English-speaking implementors would 
probably appreciate translations of the definitions, just as they would 
appreciate translations of the protocol specs.  But the presence or absence 
of such translations won't change whether a correct implementation works, 
or which other implementations it interoperates with, or even which users 
can use the software (the last _does_ depend on localization of whatever 
user interface the software has, but that's an implementation issue, not a 
protocol design issue).

If you're going to define a value intended for consumption by humans, 
rather than by software, then it should probably be free-form, rather than 
subject to a registry, and then you do have to worry about 
internationalization and language tagging.  What you don't need in this 
case is a registry for the contents of the field.

Now, one solution to the problem (and a widely adopted one) is to replace 
the free-form field with a parameter which only _looks_ free-form, but 
actually has well-defined values, allowing them to be localized.  That 
would be a legitimate reason for creating a registry such as the one 
described by this document, but then the document would need to describe 
the issue and how the registry is meant to be used to solve it.


In any case, whether you are writing a dictionary, a protocol parameter 
registry, or a message catalog, it is necessary to specify a domain of 
applicability, which the document under discussion fails to do.

-- Jeffrey T. Hutzelman (N3NHS) 
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 18:25:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzjA3-00023q-Lw; Thu, 19 Jan 2006 18:25:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzjA0-00023S-HL; Thu, 19 Jan 2006 18:25:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07279;
	Thu, 19 Jan 2006 18:24:16 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzjIc-0001Ux-9W; Thu, 19 Jan 2006 18:34:39 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id BFCACE0053; Thu, 19 Jan 2006 18:25:34 -0500 (EST)
To: Henning Schulzrinne 
References: 
	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
	<9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
From: Sam Hartman 
Date: Thu, 19 Jan 2006 18:25:34 -0500
In-Reply-To: <9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu> (Henning
	Schulzrinne's message of "Wed, 18 Jan 2006 22:49:27 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: geopriv@ietf.org, Harald Tveit Alvestrand ,
	iesg@ietf.org, ietf@ietf.org
Subject: Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed
 Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Henning" == Henning Schulzrinne  writes:

    >>  2) Inadequate context for use:
    >> 
    >> The document does not make reference to RPID, except in
    >> "acknowledgement". Thus, it has to be interpreted as
    >> stand-alone, and must contain its own guidance. RPID states:
    >> 
    >> 
    >> 
    >> These things guide the usage of place-types in RPID, but cannot
    >> be found from the registry document.
    >> 

    Henning> Since usage will strongly depend on the context and since
    Henning> this registry is not limited to RPID, I think this would
    Henning> belong into RPID (or other documents), not the registry.

    >> This document SHOULD give guidance for usage, saying at least:
    >> 
    >> - whether it's intended that several of these values can be
    >> used together

    Henning> I'd assume yes, in general, but defining that seems to be
    Henning> the role of the protocol using these elements, not a
    Henning> registry.

    Henning> I think of the registry like a dictionary. A dictionary
    Henning> does not define which words you can use together.


Here I think is the crux of the problem.  The IETF and IANA should not
be in the business of creating dictionaries.

The document under discussion creates a named set of place
descriptions.

There is no guidance given on how this information should be used, why
you would want this registry or what constraints should be placed on
it.

That's a big problem.  First, there are likely to be concerns that
matter to almost all uses of the registry.  It's desirable to require
using applications to consider these concerns and probably even to
describe how they handle the concerns.


Another reason not giving guidance is problematic has to do with
different assumptions about how the registry is used.  Some
applications may assume that there will be a small number of entries
in the registry.  That's fine until someone comes along and say
registers all the different major food chains with presence in more
than one country.

One application may assume that location is single valued; another may
have multi-valued location.  These applications will expect different
things from the registry.

Even when we've tried to have guidance for registries we've run into
problems.  Witness the recent debate about whether RTP and MIME should
use the same media type registry.

As such, with my AD hat off, I do not support publication of an RFC
that establishes a dictionary for place names I would probably support
publication of an RFC that established a well-coped place name
registry for some purpose.  I'd want to limit the size of the registry
for localization reasons.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 20:04:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzkhD-0008Eq-2w; Thu, 19 Jan 2006 20:04:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzkhA-0008Ec-DZ; Thu, 19 Jan 2006 20:04:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17223;
	Thu, 19 Jan 2006 20:02:38 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ezkpo-0005P5-07; Thu, 19 Jan 2006 20:13:00 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 22571E0053; Thu, 19 Jan 2006 20:03:56 -0500 (EST)
To: "Scott Hollenbeck" 
References: 
From: Sam Hartman 
Date: Thu, 19 Jan 2006 20:03:56 -0500
In-Reply-To:  (Scott
	Hollenbeck's message of "Wed, 18 Jan 2006 07:34:41 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Hi.

I agree that Jefsey's participation in LTRU and the ietf-languages
lists has been problematic.


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:

This is why I chose to give the necessary time to common
sense to prevail, in exposing their mistakes in a way they could
forced to correct some of them. The democratic method for that is
work and filibustering. Filibustering is not pleasant. But it
permitted to obtain what users' protection demanded:


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've also found some of his security comments and some of his comments
on IETF process issues useful.


So, I think it would be inappropriate to apply this hammer in this
case.  Instead, I propose that we find a tool appropriate for the
problem: a way of limiting Jefsey's ability to block progress in areas
where he is clearly blocking our work but not preventing him from
participating in the IETF.


I'd first ask why repeated 30-day suspensions are ineffective.  Harald
seems to be getting fairly efficient at suspending Jefsey on
ietf-languages.  I believe he's been suspended on LTRU before.  Is
Jefsey actually doing much damage there with all these suspensions?

If so, why not give Harald and the LTRU chairs the ability to suspend
Jefsey for longer?  That might involve a new BCP (or a process
experiment), but if we determine the existing tools are inadequate
then that seems like a reasonable option.  How would a six month
suspension be insufficient?  Do we really need an unlimited suspension
to get work done?

Finally, if we somehow all convince ourselves that asking chairs to
revisit suspending Jefsey every six months is unacceptable then what
about creating way to suspend Jefsey from langtags related issues but
not other IETF lists?  

Sure, Jefsey is annoying on the ietf list, but is he really so much
worse than me ranting about fairness and openness, Keith ranting about
architecture or Dave Crocker ranting about timely standards
development that we cannot have a place for him?  Speaking as an
individual, if I had to pick conversations to have un-had on the IETF
list, there are ones higher on my list than Jefsey.

Thanks for your consideration,

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 20:48:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzlNh-0006F8-Hs; Thu, 19 Jan 2006 20:48:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlNg-0006F3-0h
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 20:48:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20709
	for ; Thu, 19 Jan 2006 20:46:31 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzlWF-0006rS-Ci
	for ietf@ietf.org; Thu, 19 Jan 2006 20:56:54 -0500
Received: from [10.10.10.11] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001572435.msg
	for ; Fri, 20 Jan 2006 02:49:53 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Fri, 20 Jan 2006 02:47:34 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
Thread-Index: AcYdY3ukulKp7IlWEdqdUAANky3PwA==
In-Reply-To: <43CFE866.8030405@shockey.us>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060120:ietf@ietf.org::eYk6YwECoYEL6v6d:000006vC
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-2.4 required=4.8 tests=BAYES_00,BIZ_TLD,
	TO_ADDRESS_EQ_REAL autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Fri, 20 Jan 2006 02:49:53 +0100
X-MDAV-Processed: consulintel.es, Fri, 20 Jan 2006 02:49:55 +0100
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a
Content-Transfer-Encoding: 7bit
Subject: Re: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Richard,

Thanks for your comments.

See my response below, in-line.

Regards,
Jordi




> De: Richard Shockey 
> Responder a: 
> Fecha: Thu, 19 Jan 2006 14:28:38 -0500
> Para: IETF list 
> Asunto: Re: FW: I-D
> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> 
> JORDI PALET MARTINEZ wrote:
>> Hi,
>> 
>> Here is the original announcement and the IETF URL.
>> 
>> Comments please !
>> 
> 
> 
> 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.

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.

The point here is simple: We really need a criteria. I've proposed several
venues since 2001, specially Madrid (but also Barcelona and others in Latin
America and Caribbean), and it was successfully evaluated by a secretariat
on-site visit. However, afterwards there was no "formal" rejection of the
venue and just a comment that "isn't located downtown". However, less than
one year after that, we had a meeting in San Diego, not in down town, and I
can ensure you with much much much much worst conditions that the Madrid
venue :-( (more distance to downtown, no public transport, more expensive,
etc., etc.).

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.

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".

It hasn't been an easy document, I will say even more difficult than a
technical spec, but I'm glad with the result. I think is a fair document,
that demonstrates also that the IETF is evolving, maturing and we are going
to have meetings in new places and be fair with all the contributors, and
that will also facilitate newcomers to actually start and keep contributing.

I'm also very glad because I've received tens of comments, many more than
what I can see, average, in the majority of other drafts.

I tried to accommodate my perception on the consensus of all those that
contributed, and the document evolved significantly from the first release
(11th July 2005), and I hope having achieved it.

I've also put completely aside, during this time, my own target to get a
meeting organized in Madrid or other locations that I've been proposing for
years, and even may be my own proposed venues will not match the criteria
now, but I don't care, that's being fair and objective and that's really a
must for this, if we want to get it working in an objective way.

> 
> 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.

You can read in the document:
"Generally, this document does not present a strict list of "MUST"
   items.  Instead, it lists what needs to be evaluated, various
   alternative solutions, or combinations thereof, that may apply."

> 
> This IMHO should have come directly out of the IAOC as the subject
> matter is directly within their oversight and charter.

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.

You can read in the document:
"In the end, the IAD will make the final decision and will be accountable
   for it, and therefore he is responsible for applying the criteria
   defined in this document according to the hosting/sponsorship
   availability."

> 
> What is the relationship of this document to the IAOC?

The same as for any other document which is related to the IAD, IASA, and/or
secretariat, nothing less, nothing more: The IAOC is responsible of
providing appropriate direction, oversight and approval.

But guess what, they also need some guidelines if we want an objective IAOC,
right ?

> 
> Frankly there is'nt much about this document I like. It's a classic
> example of the current IETF fashion for process over substance.
> 

I don't really agree on that. The document is plenty of "juice" and
"substance". I've organized a few meetings, not so big as IETF, but some
times even for around 800-900 people and I can tell you that writing the
document has been an interesting exercise that also discovered me issues
that we generally aren't considering and need to be written down so the
process is fair, *not* because the process itself.

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.

> 
> 
>> 
>> 
>>  Title  : IETF Meeting Venue Selection Criteria
>>  Author(s) : J. Palet
>>  Filename : draft-palet-ietf-meeting-venue-selection-criteria-04.txt
>>  Pages  : 18
>>  Date  : 2006-1-18
>>  
>> This document provides the IAD with technical and logistic criteria
>>    for selecting venues for IETF meetings.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection
>> -criteria-04.txt
> -- 
> 
> 
>>>>>>>>>>>> 
> 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
>  or
> 
>  ; 
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 20:53:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzlT8-0008Mb-DK; Thu, 19 Jan 2006 20:53:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlT6-0008MJ-Nq
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 20:53:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21300
	for ; Thu, 19 Jan 2006 20:52:09 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezlbi-00078D-94
	for ietf@ietf.org; Thu, 19 Jan 2006 21:02:32 -0500
Received: from [10.10.10.11] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001572440.msg
	for ; Fri, 20 Jan 2006 02:55:38 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Fri, 20 Jan 2006 02:53:17 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
Thread-Index: AcYdZEgWhpkISYlXEdqdUAANky3PwA==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060120:ietf@ietf.org::oWgOGHR35ud8Xw0b:00000v+R
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Fri, 20 Jan 2006 02:55:39 +0100
X-MDAV-Processed: consulintel.es, Fri, 20 Jan 2006 02:55:39 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Subject: Re: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Paul,

I guess we can question ourselves the same way in many other documents ...

The importance of having documents is part of the IETF "working mode". Is
our way to say, here there is a consensus on this specific topic.

I guess is not my final decision if it will become and RFC or not, but it
will not be fair not following the same path for this document as for many
others.

That said, the original idea has been, since I was pointed out for editing
this document, to follow exactly the same process as with many other
documents, technical and administrative.

Regards,
Jordi




> De: Paul Hoffman 
> Responder a: 
> Fecha: Thu, 19 Jan 2006 12:43:42 -0800
> Para: Richard Shockey , IETF list 
> Asunto: Re: FW: I-D
> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> 
> At 2:28 PM -0500 1/19/06, Richard Shockey wrote:
>> It's a classic example of the current IETF fashion for process over
>> substance.
> 
> Fully agree. What is the justification for this becoming an RFC?
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 21:01:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzlaX-0001IZ-0e; Thu, 19 Jan 2006 21:01:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlaU-0001G6-So
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 21:01:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21932
	for ; Thu, 19 Jan 2006 20:59:48 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezlj8-0007MJ-Rj
	for ietf@ietf.org; Thu, 19 Jan 2006 21:10:11 -0500
Received: from [10.10.10.11] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001572450.msg
	for ; Fri, 20 Jan 2006 03:02:39 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Fri, 20 Jan 2006 03:00:19 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
Thread-Index: AcYdZUOeghXPKIlYEdqdUAANky3PwA==
In-Reply-To: <2d2701c61d43$e8f8c670$d0087c0a@china.huawei.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060120:ietf@ietf.org::i5BoIm0YoNZY+n6n:0000814r
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Fri, 20 Jan 2006 03:02:41 +0100
X-MDAV-Processed: consulintel.es, Fri, 20 Jan 2006 03:02:41 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: 7bit
Subject: Re: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Spencer,

I don't expect we have changes on the way we select venues for a few years.
Otherwise, the process for selecting them is not fair neither objective,
because a venue need to be selected (logistic reasons) at least 18-24 months
ahead. That means that lessons that we learn about what may be right or
wrong in the document will take more than 2 years to get debugged. Right now
we have already an experience of 20 years and we haven't changed too much
lots of things.

Moreover, we do changes in our documents, is not an issue if they are an RFC
or not.

And ... Being the document a guideline (may be BCP better than
Informational), is IAD the one that will take decisions about the venue
selection. I guess he will be smart enough to "correctly" apply the document
to the process. I've no doubt on that.

Regards,
Jordi




> De: Spencer Dawkins 
> Responder a: 
> Fecha: Thu, 19 Jan 2006 16:01:32 -0600
> Para: IETF list 
> Asunto: Re: FW: I-D
> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> 
> From: "Paul Hoffman" 
>> At 2:28 PM -0500 1/19/06, Richard Shockey wrote:
>>> It's a classic example of the current IETF fashion for process over
>>> substance.
>> 
>> Fully agree. What is the justification for this becoming an RFC?
> 
> Well, backing up slightly ...
> 
> How much of our process stuff (including existing BCPs) really needs to be
> published as an RFC?
> 
> Some does, I suppose, but "never changes" doesn't seem like the model we
> should search for on venue selection (the venue selection model used for the
> first 10 IETF meetings probably wouldn't have even booked us into
> Minneapolis, much less Adelaide!).
> 
> Having said this, I hope the IAOC does find this document useful input
> (because if they don't, people have sure been wasting zeros and ones on THIS
> list...
> 
> Thanks,
> 
> Spencer 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 21:07:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzlgQ-0005BM-PC; Thu, 19 Jan 2006 21:07:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlgO-00059a-Kl
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 21:07:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22497
	for ; Thu, 19 Jan 2006 21:05:53 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezlp2-0007dk-VN
	for ietf@ietf.org; Thu, 19 Jan 2006 21:16:17 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 8FE5EE0053; Thu, 19 Jan 2006 21:07:09 -0500 (EST)
To: "Hallam-Baker, Phillip" 
References: <198A730C2044DE4A96749D13E167AD3787AB4F@MOU1WNEXMB04.vcorp.ad.vrsn.com>
From: Sam Hartman 
Date: Thu, 19 Jan 2006 21:07:08 -0500
In-Reply-To: <198A730C2044DE4A96749D13E167AD3787AB4F@MOU1WNEXMB04.vcorp.ad.vrsn.com>
	(Phillip
	Hallam-Baker's message of "Wed, 18 Jan 2006 14:25:56 -0800")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4
Cc: Ted Faber , ietf@ietf.org,
	"Steven M. Bellovin" 
Subject: Re: Wireless at IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi.  I'd just like to speak in favor of anonymous Internet.  Yes there
needs to be a balance, but honestly, if there wern't ways to get
anonymous internet I'd consider it a big problem.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 21:11:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezlk1-0006HM-Et; Thu, 19 Jan 2006 21:11:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezljz-0006Gh-R6
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 21:11:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22848
	for ; Thu, 19 Jan 2006 21:09:36 -0500 (EST)
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezlsa-0007lT-Ox
	for ietf@ietf.org; Thu, 19 Jan 2006 21:20:00 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id EA3C2FB297;
	Fri, 20 Jan 2006 02:10:53 +0000 (UTC)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id ED4633C0207;
	Thu, 19 Jan 2006 21:10:52 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: Sam Hartman 
In-Reply-To: (Your message of "Thu, 19 Jan 2006 21:07:08 EST.")
	 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 19 Jan 2006 21:10:52 -0500
Message-Id: <20060120021052.ED4633C0207@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: Ted Faber , ietf@ietf.org
Subject: Re: Wireless at IETF 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In message , Sam Hartman writes:
>Hi.  I'd just like to speak in favor of anonymous Internet.  Yes there
>needs to be a balance, but honestly, if there wern't ways to get
>anonymous internet I'd consider it a big problem.
>
Strong second.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 21:26:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzlzP-0004Zf-4P; Thu, 19 Jan 2006 21:26:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlzN-0004ZZ-8g
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 21:26:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24497
	for ; Thu, 19 Jan 2006 21:25:30 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezm7z-0008JW-Ke
	for ietf@ietf.org; Thu, 19 Jan 2006 21:35:54 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3808192; Thu, 19 Jan 2006 21:23:49 -0500
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Thu, 19 Jan 2006 21:26:52 -0500
To: jordi.palet@consulintel.es
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" 
Subject: Re: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Speaking just for myself :

I think that there is a strong benefit to having an agreed upon set  
of parameters
for new meeting locations.

Having said that, this may not be appropriate for an RFC. Maybe it  
should be a "living document" on a web page
or wiki, as is being done / considered for mailing list anti-SPAM  
suggestions. Maybe a new class of
IETF document publication is needed.

Regards
Marshall Eubanks

On Jan 19, 2006, at 8:53 PM, JORDI PALET MARTINEZ wrote:

> Hi Paul,
>
> I guess we can question ourselves the same way in many other  
> documents ...
>
> The importance of having documents is part of the IETF "working  
> mode". Is
> our way to say, here there is a consensus on this specific topic.
>
> I guess is not my final decision if it will become and RFC or not,  
> but it
> will not be fair not following the same path for this document as  
> for many
> others.
>
> That said, the original idea has been, since I was pointed out for  
> editing
> this document, to follow exactly the same process as with many other
> documents, technical and administrative.
>
> Regards,
> Jordi
>
>
>
>
>> De: Paul Hoffman 
>> Responder a: 
>> Fecha: Thu, 19 Jan 2006 12:43:42 -0800
>> Para: Richard Shockey , IETF list 
>> Asunto: Re: FW: I-D
>> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
>>
>> At 2:28 PM -0500 1/19/06, Richard Shockey wrote:
>>> It's a classic example of the current IETF fashion for process over
>>> substance.
>>
>> Fully agree. What is the justification for this becoming an RFC?
>>
>> --Paul Hoffman, Director
>> --VPN Consortium
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.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@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 22:00:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzmVi-0006vT-Uw; Thu, 19 Jan 2006 22:00:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzmVg-0006uz-Vw
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 22:00:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26589
	for ; Thu, 19 Jan 2006 21:58:53 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzmeK-0000oF-9j
	for ietf@ietf.org; Thu, 19 Jan 2006 22:09:17 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EzmVW-000FKO-Oz; Thu, 19 Jan 2006 22:00:10 -0500
Date: Thu, 19 Jan 2006 22:00:10 -0500
From: John C Klensin 
To: jordi.palet@consulintel.es
Message-ID: 
In-Reply-To: 
References: 
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 22:25:49 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzmuL-0006K8-1D; Thu, 19 Jan 2006 22:25:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzmuI-0006Ip-Ic; Thu, 19 Jan 2006 22:25:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28100;
	Thu, 19 Jan 2006 22:24:19 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ezn2x-0001YF-6c; Thu, 19 Jan 2006 22:34:43 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EzmuG-000FNH-Kt; Thu, 19 Jan 2006 22:25:44 -0500
Date: Thu, 19 Jan 2006 22:25:43 -0500
From: John C Klensin 
To: Scott Hollenbeck 
Message-ID: <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
In-Reply-To: 
References: 
	
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC
 (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--On Thursday, 19 January, 2006 20:03 -0500 Sam Hartman
 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


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 22:31:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezmzh-00080Z-R8; Thu, 19 Jan 2006 22:31:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezmzf-00080Q-4H
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 22:31:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28578
	for ; Thu, 19 Jan 2006 22:29:51 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezn8H-0001iM-KZ
	for ietf@ietf.org; Thu, 19 Jan 2006 22:40:16 -0500
Received: from [10.10.10.11] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001572540.msg
	for ; Fri, 20 Jan 2006 04:33:17 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Fri, 20 Jan 2006 04:30:55 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
Thread-Index: AcYdceu6Khf6MIllEdqdUAANky3PwA==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060120:ietf@ietf.org::2ds+T+ywfFxHqOsm:00006bA0
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Fri, 20 Jan 2006 04:33:20 +0100
X-MDAV-Processed: consulintel.es, Fri, 20 Jan 2006 04:33:20 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: 7bit
Subject: Re: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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 
> Responder a: 
> Fecha: Thu, 19 Jan 2006 22:00:10 -0500
> Para: 
> CC: "ietf@ietf.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@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 22:37:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezn5B-0000xm-DZ; Thu, 19 Jan 2006 22:37:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezn59-0000xb-8i
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 22:36:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29199
	for ; Thu, 19 Jan 2006 22:35:31 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EznDn-0001z4-1J
	for ietf@ietf.org; Thu, 19 Jan 2006 22:45:56 -0500
Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net
	[68.165.240.35]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0K3b3oN032273
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Jan 2006 19:37:04 -0800
Message-ID: <43D05AB5.4090009@shockey.us>
Date: Thu, 19 Jan 2006 22:36:21 -0500
From: Richard Shockey 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: jordi.palet@consulintel.es
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" 
Subject: Re: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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
 or

 ; 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 22:55:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EznNP-00009F-7u; Thu, 19 Jan 2006 22:55:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EznNJ-00008H-Kx
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 22:55:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01093
	for ; Thu, 19 Jan 2006 22:54:17 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EznVv-0002h6-32
	for ietf@ietf.org; Thu, 19 Jan 2006 23:04:42 -0500
Received: from [10.10.10.11] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001572569.msg
	for ; Fri, 20 Jan 2006 04:57:22 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Fri, 20 Jan 2006 04:54:59 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
Thread-Index: AcYddUhrhwOOvYloEdqdUAANky3PwA==
In-Reply-To: <43D05AB5.4090009@shockey.us>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060120:ietf@ietf.org::GAvdn6lfB0ioXVJq:00000CJk
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-2.4 required=4.8 tests=BAYES_00,BIZ_TLD,
	TO_ADDRESS_EQ_REAL autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Fri, 20 Jan 2006 04:57:24 +0100
X-MDAV-Processed: consulintel.es, Fri, 20 Jan 2006 04:57:27 +0100
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c
Content-Transfer-Encoding: 7bit
Subject: Re: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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 
> Responder a: 
> Fecha: Thu, 19 Jan 2006 22:36:21 -0500
> Para: 
> CC: "ietf@ietf.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
>  or
> 
>  ; 
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 19 23:06:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EznY5-0003sm-IM; Thu, 19 Jan 2006 23:06:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EznY3-0003qN-00
	for ietf@megatron.ietf.org; Thu, 19 Jan 2006 23:06:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01949
	for ; Thu, 19 Jan 2006 23:05:23 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezngg-00034s-NY
	for ietf@ietf.org; Thu, 19 Jan 2006 23:15:48 -0500
Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net
	[68.165.240.35]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0K46fll003354
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 19 Jan 2006 20:06:46 -0800
Message-ID: <43D061A8.9090005@shockey.us>
Date: Thu, 19 Jan 2006 23:06:00 -0500
From: Richard Shockey 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: John C Klensin 
References: 
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, jordi.palet@consulintel.es
Subject: Re: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John C Klensin wrote:
> 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.


Thank you John. As usual you have summarized many of my own feelings 
better than I have done.


> 
> 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. 

My point exactly, again many thanks for your clarity.

> 
> 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. 


as Informational only.



-- 


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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
 or

 ; 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 02:05:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzqLA-0004Rb-Ix; Fri, 20 Jan 2006 02:05:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzqL7-0004RL-H5
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 02:05:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13905
	for ; Fri, 20 Jan 2006 02:04:13 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzqTl-00005o-K3
	for ietf@ietf.org; Fri, 20 Jan 2006 02:14:39 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1EzqKq-000FgL-OB; Fri, 20 Jan 2006 02:05:24 -0500
Date: Fri, 20 Jan 2006 02:05:24 -0500
From: John C Klensin 
To: jordi.palet@consulintel.es, ietf@ietf.org
Message-ID: <69260B781BEDBBE92BD855C8@p3.JCK.COM>
In-Reply-To: 
References: 
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On Friday, 20 January, 2006 04:30 +0100 JORDI PALET MARTINEZ
 wrote:

> 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.

Just as long as you understand that it is going to be hard or
impossible to make it binding, or even strongly suggestive, on
the IAD via an IETF process without getting consensus that...

	(1) It is not clear that, with the IASA in place and
	specifically assigned the meeting site selection task,
	the IESG has the authority to ask for and evaluate...
	unless you propose, and succeed, in modifying BCP 101.
	
	(2) It seems unlikely to me that you would get that
	consensus if it were asked for, at least without many
	months of nit-picking.

Let me give one example on-list and then I'm going to drop back
out of the discussion.  At the end of the first paragraph of
section 2.2, you say "The IETF desires to meet in countries with
significant actual or potential participation."  The "potential"
part of that criterion has never been agreed upon.  We have
tended to go for actual participation, rather than trying to
create a presence where there are potential participants in the
hope of luring them in.  I can think of many reasons to not
change that.  You obviously either think we should or you
misunderstand the criteria that have been used for years.  I
suspect we could have a very long, and ultimately inconclusive,
discussion on this subject.  Indeed, I believe that once a few
people started enumerating what they saw as pros and cons, we
would discover that a very large portion of the IETF community
would have an opinion on the subject.  Interesting, but just not
very likely to be productive.  And, while that assertion sort of
leapt out at me, there are many others like it in the document.

I'd personally prefer to delegate this problem and discussion to
the IAOC, as BCP 101 appears to do, and let them sort it out
without an extended and detailed debate on the IETF list.   

Just my opinion, of course.

     john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 02:17:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzqWY-0000N7-8n; Fri, 20 Jan 2006 02:17:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzqWV-0000Md-1A; Fri, 20 Jan 2006 02:17:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14695;
	Fri, 20 Jan 2006 02:16:00 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ezqf9-0000Sm-Mq; Fri, 20 Jan 2006 02:26:26 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 300CE259719;
	Fri, 20 Jan 2006 08:16:09 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 07978-08; Fri, 20 Jan 2006 08:16:03 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id DB8DA259714;
	Fri, 20 Jan 2006 08:16:02 +0100 (CET)
Date: Fri, 20 Jan 2006 08:17:08 +0100
From: Harald Tveit Alvestrand 
To: Sam Hartman , Scott Hollenbeck 
Message-ID: 
In-Reply-To: 
References: 
	
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



--On torsdag, januar 19, 2006 20:03:56 -0500 Sam Hartman 
 wrote:

> I'd first ask why repeated 30-day suspensions are ineffective.  Harald
> seems to be getting fairly efficient at suspending Jefsey on
> ietf-languages.  I believe he's been suspended on LTRU before.  Is
> Jefsey actually doing much damage there with all these suspensions?

At the moment, the pattern on ietf-languages is that:

- Jefsey posts one of his offtopic political harangues
- About five different people complain privately to me
- I suspend Jefsey's posting privilleges for a month
- About five people send thank-you notes, and wonder whether the IESG will 
get off its butt and allow him to be suspended permanently, usually 
accompanied with ruminations about whether it makes any sense to 
participate in an organization that is so completely ineffective in 
handling disruptive persons
- A month passes in which the list is relatively calm
- I remove Jefsey's suspension
- The pattern repeats

This is a waste of time, resources and the goodwill of the people who 
contribute constructively.

> 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.

Permit me to disagree. And to rant for a little while (those who are tired 
of the subject can hit "delete" now)....

The "contributions" that Jefsey has been making in this regard have, to me, 
had a few common properties:

- The kernels of truth in his ramblings have been so blindingly obvious 
that they are not news to anyone who's spent any significant time in the 
political spaces tht he's talking about
- The biases, perceptions and sheer follies that he proclaims have been 
sufficiently far off-mark that I as an European non-native English speaker 
find it incredibly painful to even consider engaging in debates about 
whether he has a point or not.

The result is not that more points get made, and wider perspectives are 
had. The result is that *fewer* people contribute constructively to the 
debate, and the IETF gets *less* information about the perceptions that the 
rest of the world has on the matters about which Jefsey speaks.

For a recent example, see his "agreement" with me on the geopriv location 
registry:

> We fully agree on this. But I see you are fighting here the same
> difficulty I fight against you for languages. They propose words in their
> language context as you propose languages tags in your internationalised
> context. They do the same layer violation as you do. The only solution to
> this is to conceptualise and to universalise the concept. ISO 11179. You
> define a concept, give it a unique ID (building a referent) and as many
> names as you need which name the concept, not its version in a given
> context. However I agree JTC1/SG32/W2 has not yet addressed the
> multilingual and the networked aspects. But IETF have clumsily approached
> it with IDNA and very well with the DNS.

There's a point here - that you need conceptual separation between "the 
identity of the thing you name" and "the name that you give to the thing".
But many people who work with identifiers know that - Mike O'Dell pointed 
me at Tom McArthur's "Worlds of reference" many years ago; recommended 
reading!

But in order to consider that little gem of truth reasonably, I have to 
wade through the swamp of parsing a message that claims:

- There isn't a common concept of "kitchen" between America and France (as 
far as I know completely stupid)
- There are languages that use the same word for blue and green (as far as 
I know false)
- That ISO 11179, a six-part, 200-page standard for "how to run a registry" 
available in English only, is somehow going to make the IETF 
internationalization efforts be much more conceptually correct

Rather than suffering through the aggravation of dealing with these 
inanities, misrepresentations and out-and-out fantasies, I prefer to file 
Jefsey's messages under my "don't look here" folder, and wait for someone 
else to make the point.

The only argument I, personally, have in favour of replying to a Jefsey 
message is that someone with less knowledge of the facts might be deluded 
into thinking that he's speaking truth, that a sentence like

> I do hope you will permit it to be in cooperation with the IGF,. That we
> can proceed fast on a stable, reasonable and acceptable equal opportunity
> but competitive fair basis. As we all agreed in Tunis.

actually means that the Tunis meetings (where ISOC did its usual yeoman's 
job of trying to convey concerns between the "Internet people" and the 
"Government people") actually came to a reasonable conclusion that 
resembles something Jefsey's been arguing in favour of (I think that's TWO 
unwarranted assumptions, btw).

I've come to the conclusion that my time is better spent on other things, 
so I let his blatherings pass uncommented, and largely unread.

But I fail to see the benefit to the IETF, and I find it very easy to see 
the harm.

                         Harald



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 03:46:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezruu-0003ZW-3j; Fri, 20 Jan 2006 03:46:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezrus-0003ZR-Cd
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 03:46:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22345
	for ; Fri, 20 Jan 2006 03:45:15 -0500 (EST)
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezs3Y-0003Uz-Vl
	for ietf@ietf.org; Fri, 20 Jan 2006 03:55:42 -0500
Received: from venus.office (europa.netlab.nec.de [10.1.1.25])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id B0E70AF68
	for ; Fri, 20 Jan 2006 09:46:26 +0100 (CET)
Received: from n-eggert.office ([10.1.1.112]) by venus.office over TLS secured
	channel with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 20 Jan 2006 09:46:26 +0100
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by n-eggert.office (Postfix) with ESMTP id DC4F764B39F
	for ; Fri, 20 Jan 2006 09:46:25 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v746.2)
To: IETF Discussion 
Message-Id: 
From: Lars Eggert 
Date: Fri, 20 Jan 2006 09:46:24 +0100
X-Mailer: Apple Mail (2.746.2)
X-OriginalArrivalTime: 20 Jan 2006 08:46:26.0627 (UTC)
	FILETIME=[FFDB4930:01C61D9D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Subject: hotels for Dallas?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0989142877=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0989142877==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-525794726;
	protocol="application/pkcs7-signature"


--Apple-Mail-8-525794726
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

Hi,

so I'm happy to see that we now have IETF dates blocked until 2010 on  
http://ietf.org/meetings/events.cal.html, but hotel information for  
Dallas would be more useful to me personally. ETA on that?

Thanks,
Lars
--
Lars Eggert                                     NEC Network Laboratories


--Apple-Mail-8-525794726
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw
ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE
EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN
AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv
AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK
xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF
DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ
vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C
AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l
dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS
vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2
usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu
mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT
G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl
ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa
LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud
HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs
Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf
qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa
9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G
CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy
ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT
FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq
hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw
NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx
EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO
ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI
hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT
wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z
9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY
LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD
VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy
ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz
MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0
QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9
3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR
piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB
KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1
aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDYwMTIwMDg0NjI1WjAjBgkqhkiG9w0BCQQxFgQUpykzxxwTNDrMQMlG/Vc/
GZ4cgzswgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu
LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg
THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu
bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq
hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl
bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD
VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw
JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA
BIIBAIgdEIVDBgTnvzeF2LiPUoZkToF6dFQ61AhBtRUAUBGv84LNC8ye7LK4fwS2LscwIbwmzgRr
cmQjtLVDb9XatIlefPsiiXpleGoiqLg7EXhgRsezR1S0ynwOoGDDAOHVS37OF+I8zuYVWLCeFvDB
fQbXEL4oRj4OgmegZ7BeG1zCYXHbRgFTootTk2eicdLzs9dvbV+335kn2buzHZbaAQGGu9bJu8KK
nFBIc3wQYQVxYQGt7dtUceo3EwUjv4ywQx10uyU1b9NPXqRU7lq5Pp1G/l2MuTukComX8mRKxXYa
eFTT6UJFTCJ960P+j8hRC/AMsi2b0O5VExFcj3Hq6EYAAAAAAAA=

--Apple-Mail-8-525794726--


--===============0989142877==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0989142877==--




From ietf-bounces@ietf.org Fri Jan 20 04:03:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzsB9-0008RV-Io; Fri, 20 Jan 2006 04:03:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzsB7-0008Q3-Ce; Fri, 20 Jan 2006 04:03:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23363;
	Fri, 20 Jan 2006 04:02:02 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzsJn-00047S-Uq; Fri, 20 Jan 2006 04:12:29 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 43BC125971B;
	Fri, 20 Jan 2006 10:02:12 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 10688-05; Fri, 20 Jan 2006 10:02:08 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id CB566259716;
	Fri, 20 Jan 2006 10:02:07 +0100 (CET)
Date: Fri, 20 Jan 2006 10:03:13 +0100
From: Harald Tveit Alvestrand 
To: John C Klensin , Scott Hollenbeck 
Message-ID: <41746BD75D66D3A4B9C30BD2@svartdal.hjemme.alvestrand.no>
In-Reply-To: <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
References: 
	 <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, iesg@ietf.org
Subject: In praise of RFC 3683 (Re: IETF Last Call)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

One rather different thread:

Sam said:


> 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.

--On torsdag, januar 19, 2006 22:25:43 -0500 John C Klensin 
 wrote:

> 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.

Actually I'd like to hark back to a simpler time (approximately 2000)....

At that time, there were no central rules for IETF mailing lists. 
Administrators did what they felt they had to do - including making 
individual decisions to suspend disruptive individuals for a time period of 
their choosing, including "permanently", with or without telling anyone 
they had done so (There were some rules in 2418 section 3.2, but they were 
largely ignored).

And things worked fairly well.

Then, based on some incidents, the IESG started making and enforcing rules:

- Lists are open by default (even spam filters need to be careful)
- Suspensions are to be announced publicly, including "why"
- Suspensions are for a limited time
- Suspensions are to be decided by the IESG, not the listadmin
- Suspensions will take note of the rules in 2418, which actually say the 
two last things above.

and so on and so forth. (Blame the then-chair, one Alvestrand...)

The community decided to share in the codification; RFC 3005, RFC 3683 and 
RFC 3934 are some of the results.

Scott Hollenbeck pointed out to me that RFC 3683 is actually more subtle 
than I had remembered; the words in it are:

   o  those identified on the PR-action have their posting rights to
      that IETF mailing list removed; and,

   o  maintainers of any IETF mailing list may, at their discretion,
      also remove posting rights to that IETF mailing list.

There's nothing in there about the IETF list specifically; until Brian or 
the sergeants-at-arms decide otherwise, a PR-action doesn't affect it.

Apart from the list where the complaint originated, this can be seen as a 
*return* to the pre-2000 state: Power in the hand of the listadmin, and no 
involvement of the IESG in the individual decisions.

I think this is not a blunt instrument at all. It's a subtle one.

                    Harald


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 05:40:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzthC-00077Y-IU; Fri, 20 Jan 2006 05:40:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezth9-00074O-82
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 05:40:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29562
	for ; Fri, 20 Jan 2006 05:39:11 -0500 (EST)
Received: from peewit.ecs.soton.ac.uk ([152.78.68.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eztpq-0006zW-Dz
	for ietf@ietf.org; Fri, 20 Jan 2006 05:49:39 -0500
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk
	[IPv6:2001:630:d0:f102:230:48ff:fe23:58df])
	by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k0KAePrF000956
	for ; Fri, 20 Jan 2006 10:40:25 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k0KAeCj09587
	for ietf@ietf.org; Fri, 20 Jan 2006 10:40:12 GMT
Date: Fri, 20 Jan 2006 10:40:12 +0000
From: Tim Chown 
To: ietf@ietf.org
Message-ID: <20060120104012.GE9015@login.ecs.soton.ac.uk>
Mail-Followup-To: ietf@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner: Found to be clean
X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Subject: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi,

Has there been any discussion in the upper echelons of the IETF about the
issue of Friday sessions?

If you look back over past agendas, it's typically a day with around 3-5
meetings in one session to 11.30am, of which half or more are BoFs.

Is this likely to continue, such that if you're from a different
continent to the host, and you choose to travel home on Friday to get
home a day earlier and save a little hotel money, you stand a (slim) 
chance of missing a WG session you'd like to attend?

Personally I would be happy to travel back Saturday if I knew Friday
was a fullish day, but as it is it's neither here nor there really...
thoughts?

-- 
Tim/::1

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 06:30:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzuSw-0006uy-W8; Fri, 20 Jan 2006 06:30:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzuSu-0006uW-5m
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 06:30:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02713
	for ; Fri, 20 Jan 2006 06:28:27 -0500 (EST)
Received: from mtagate2.uk.ibm.com ([195.212.29.135])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzubW-0008OL-Nz
	for ietf@ietf.org; Fri, 20 Jan 2006 06:38:57 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0KBS5oM082144
	for ; Fri, 20 Jan 2006 11:28:11 GMT
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com
	[9.149.37.213])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0KBS45l182206 for ; Fri, 20 Jan 2006 11:28:04 GMT
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0KBS3dA016956 for ; Fri, 20 Jan 2006 11:28:03 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0KBS35j016950; Fri, 20 Jan 2006 11:28:03 GMT
Received: from zurich.ibm.com (sig-9-145-134-195.de.ibm.com [9.145.134.195])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA72638;
	Fri, 20 Jan 2006 12:28:02 +0100
Message-ID: <43D0C93F.5010306@zurich.ibm.com>
Date: Fri, 20 Jan 2006 12:27:59 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Lars Eggert 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion 
Subject: Re: hotels for Dallas?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Lars,

Sorry but the dates for 2008-10 are NOT blocked - those are strawman
dates that should not have been shown in the calendar yet.

Registration for Dallas is in the final test stage, with a new system for
credit card processing, and we want it to be rock solid.
Should be open *really* soon now.

    Brian

Lars Eggert wrote:
> Hi,
> 
> so I'm happy to see that we now have IETF dates blocked until 2010 on  
> http://ietf.org/meetings/events.cal.html, but hotel information for  
> Dallas would be more useful to me personally. ETA on that?
> 
> Thanks,
> Lars
> -- 
> Lars Eggert                                     NEC Network Laboratories
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 06:35:19 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzuY3-0007s4-IF; Fri, 20 Jan 2006 06:35:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzuY1-0007rz-DA
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 06:35:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03118
	for ; Fri, 20 Jan 2006 06:33:49 -0500 (EST)
Received: from peewit.ecs.soton.ac.uk ([152.78.68.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezugi-00007b-OO
	for ietf@ietf.org; Fri, 20 Jan 2006 06:44:18 -0500
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk
	[IPv6:2001:630:d0:f102:230:48ff:fe23:58df])
	by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k0KBZ42W016684
	for ; Fri, 20 Jan 2006 11:35:04 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k0KBYon11687
	for ietf@ietf.org; Fri, 20 Jan 2006 11:34:50 GMT
Date: Fri, 20 Jan 2006 11:34:50 +0000
From: Tim Chown 
To: IETF Discussion 
Message-ID: <20060120113450.GM9015@login.ecs.soton.ac.uk>
Mail-Followup-To: IETF Discussion 
References: 
	<43D0C93F.5010306@zurich.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43D0C93F.5010306@zurich.ibm.com>
User-Agent: Mutt/1.4i
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner: Found to be clean
X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Subject: Re: hotels for Dallas?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Fri, Jan 20, 2006 at 12:27:59PM +0100, Brian E Carpenter wrote:
> 
> Registration for Dallas is in the final test stage, with a new system for
> credit card processing, and we want it to be rock solid.
> Should be open *really* soon now.

And the hotel info?

(And is the meeting ending 11.30am on the Friday?)

Tim

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 06:47:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzujU-00043o-LK; Fri, 20 Jan 2006 06:47:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzujS-00043g-UA; Fri, 20 Jan 2006 06:47:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04041;
	Fri, 20 Jan 2006 06:45:38 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzusB-0000Xr-0O; Fri, 20 Jan 2006 06:56:08 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1EzujH-00085j-Dh; Fri, 20 Jan 2006 03:46:55 -0800
Message-Id: <6.2.3.4.2.20060120112906.0547e7d0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Fri, 20 Jan 2006 11:59:00 +0100
To: ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: 
References: 
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-B8250F9
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: iesg@ietf.org
Subject: Mr. Smith goes to the IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

As far I am concerned, the PR-action engaged against me by Harald 
Alvestrand is per se of no interest. I just have some general 
comments and one question about it, I will address separately.

What is more interesting is how the IETF and the Internet community 
may benefit from the three issues I raise: multilingualism, ethic and 
user QA. The three of them have an architectural impact (the IAB 
should be able to address through the now silent IAB-discuss) and are 
part of a wide "governance" change which question the RFC 3935 IETF 
mission. These three questions (ethic and user QA being related in 
part) are now under final escalation to the IAB.


At the present time, published contributions (Sam Hartman, John 
Klensin, Harald Alvstrand) agree with me: filibustering, however a 
democratic US invention, is a pest. IETF should do everything not to 
need it (much more efficient than to fight it). I think my 
contributions are of interest to consider in this area. I suppose all 
the PESCI member are already on the two copied lists.


1. due to the importance of the "war on culture" 
"internationalization" represents, I was proposed support and funding 
to oppose it. The problem are an architectural layer violation, a 
narrow vision and a lack of information. Not a lack of competence. To 
kill the IETF for that was inadequate (or premature). I am already a 
problem, would we have been two or three of us ... Had we been 200 as 
I was proposed ... I have computed that $ 20.000 are enough to block 
the IETF. This can be discussed, but this is something we should 
urgently consider, when political, commercial and civil rights 
interests make the IETF, and most of all the IANA, a key target (the 
USG says for sale- may be to protect it?).

I refused it.

2. I proposed Brian Carpenter to get "would be filibusters" a special 
status in the consensus process as "user QA rep". With rights and duties.

This was denied.

3. I proposed an evolution in the WG working method. In using 
position links: every contributor expresses his positions on a page 
he can update as the debate goes. I proposed this to the GNSO 
WG-Review which supported it and I use it in some work. This filters 
out "standard" participants' blabla. It permits everyone to stay, 
every concept to be documented and progressively trimmed, and 
external experts to call in. Consensus is when all the positions are 
equivalent or have identified they cannot agree. Consensus review is 
easy and informative.

This was not considered.

4. I have engaged an IESG, and now an IAB appeal, to know if this 
kind of debate is, or not, part of  the IETF. IESG said "no". I want 
a confirmation by the IAB (so no one can claim there is a conflict) 
before engaging into the organisation of a solution. My solution is a 
dedicated TF sharing into the Internet standard process and reviewing 
the Charters and the Drafts during the LC, or upon request. That TF 
would permanently interact with the users. I think it can be engaged 
in ethic (COI and societal impact) and "governance" issues. The 
interest is that there can be several TF until one emerges as a 
stable and productive solution. I would favor it to be eventually 
part of ISOC and to interface (and protect the IETF from) the IGF.

This is under final consideration. Interested people can share in a Draft.


This IETF has to understand that the Internet has become mature. 
Mature for a product - and specially for a communication technology - 
is when the technology is no more the leader but when usage decides. 
This is what they call "governance". This means that the IGF is going 
to deliver scores of Jefseys. Engineers who can code user response as 
per the user' requests (far more complex than what IETF does today). 
The NSF GENI project will not be alone.

I still consider there is a difference between specifying (Charter) 
and documenting (WG work). But most, because they will be from 
Lobbies or Govs, will not bother. This will lead to balkanization and 
to IETF bottle necks. Already, I saw that with the lobby driven 
WG-LTRU: the Charter was not considered. WG Consensus by exhaustion, 
IETF consensus by disinterest and IESG consensus by impossible 
knowledge of everything lead to dispute like the one I have with 
Harald. There will be scores of them soon if we do not find a 
structural solution.

jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 07:04:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezv06-00019q-0I; Fri, 20 Jan 2006 07:04:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezv02-00016B-4N; Fri, 20 Jan 2006 07:04:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05861;
	Fri, 20 Jan 2006 07:02:45 -0500 (EST)
Received: from [204.9.221.21] (helo=thingmagic.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ezv8l-0001JD-3K; Fri, 20 Jan 2006 07:13:15 -0500
Received: from [66.30.121.250] (account margaret HELO ceili)
	by thingmagic.com (CommuniGate Pro SMTP 5.0.1)
	with ESMTPSA id 697249; Fri, 20 Jan 2006 07:03:54 -0500
From: "Margaret Wasserman" 
To: "'Harald Tveit Alvestrand'" ,
	"'Sam Hartman'" ,
	"'Scott Hollenbeck'" 
Date: Fri, 20 Jan 2006 07:03:52 -0500
Message-ID: <010201c61db9$95069670$0402a8c0@instant802.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcYdkd181GYHOCsORrajcDwyJFXNqwAIKDDA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
In-Reply-To: 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, iesg@ietf.org
Subject: RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Hi Harald,

> - About five people send thank-you notes, and wonder whether
> the IESG will get off its butt and allow him to be suspended
> permanently, usually accompanied with ruminations about
> whether it makes any sense to participate in an organization
> that is so completely ineffective in handling disruptive persons

How do you respond to those five people?  Do you tell them that e-mail
filters were created for a reason?  Do you ask them how hard it is to hit
'd' (or equivalent) once a month?  Do you point out the inherent tension
between running an "open" organization and choosing who can participate
based on the quality of their contributions?  Or do you encourage those
people to be upset about the IESG's supposed ineffectiveness in resolving
this issue, which you seem to consider a black-and-white issue while I,
personally, do not?

Personally, I consider this to be a very complex and difficult issue.  We
have an RFC that does allow the IESG to indefinitely suspend the IETF
posting rights of an individual, and it provides some guidance for making
that decision.  However, it is not a very precise document, and it is
clearly open to interpretation regarding both the definition of disruptive
behaviour and whether an individual needs to be _intentionally_ engaging in
disruptive behaviour in order to have has his/her posting privileges
suspended.

Personally, I am just as tired at this point of reading your poorly-founded
and repeated accusations against Jefsey as I am of reading Jefsey's posts on
this subject.

However, I'd like to address a few of the issues that you raised about one
of Jefsey's posts, in your recent message, in the hope of helping you to
understand that you might not be entirely objective about Jefsey's
contributions at this point.

> - There isn't a common concept of "kitchen" between America
> and France (as far as I know completely stupid)

I would be willing to yield to Jefsey on this one, as he has spent much more
time in France than I have.  In fact, I am pretty sure that I have never
been in a kitchen in France...  However, I did take U.S. high school French,
and I was taught that the word for "kitchen" in U.S. English translates to
"cuisine" in French, but that the word "cuisine" in French can translate to
"kitchen", "cook", or "a style of food" in English.  So, I am not quite sure
that there is a direct translation between the English and French words for
"kitchen"...  I'd have to ask a French person to be sure, though.

On the other hand, I am pretty sure that we all have some common Idea (in
the Platonic sense) of a room in which one cooks dinner (although some of us
might call it "supper").

If you are concerned that Jefsey's statement about kitchens  is somehow
damaging misinformation, perhaps you could ask Jefsey to clarify what he
means or provide a reference?  Or you could ask other French natives to
comment?  On the other hand, if you just think that Jefsey may be slightly
mistaken (confusing a lack of clean translation between two words as an
indication that we do not have a shared concept), why not just ignore it,
like you would if anyone else made a similar mistake?

> - There are languages that use the same word for blue and
> green (as far as I know false)

I googled for "language blue green" and the first hit (Wikipedia) says:

"The English language makes a distinction between blue and green, but some
languages, such as Vietnamese or Tarahumara usually do not use separate
words for green and refer to that colour using a word that can also refer to
yellow or to blue. In Vietnamese, blue and green are denoted by xanh; blue
is specifically described as "xanh like the sky" and green as "xanh like the
leaves".

It is sometimes said that Japanese does not distinguish between blue and
green either. Modern Japanese does have words for both green ($BNP(B midori) and
blue ($B@D$$(B aoi adj.; $B@D(B ao n.). However, ancient Japanese did not have this
distinction: the word midori only came into use in the Heian period, and at
that time (and for a long time thereafter) midori was still considered a
shade of ao. Educational materials distinguishing green and blue only came
into use after World War II, during the Occupation: thus, even though most
Japanese consider them to be green, the word ao is still used to describe
certain vegetables, apples and vegetation. However, most other objects - a
green car, a green sweater, and so forth - will generally be called midori.

Welsh has different boundaries than English regarding blue and green. The
word glas is usually translated as 'blue'. It can also refer, variously, to
the colour of the sea, of grass, or of silver. The word gwyrdd is the
standard translation for 'green'. Glas (same spelling) is, comparably, the
translation for "green" in Irish, with specific reference to plant hues of
green; other shades would be referred to as uaine. In Irish, gorm is the
word for "blue" - the first part (gor(m)) pronounced as in the Welsh
gwyr(dd)."

Now, I don't personally care, but it seems that you may have been poorly
informed in this particular case.

> - That ISO 11179, a six-part, 200-page standard for "how to
> run a registry"
> available in English only, is somehow going to make the IETF
> internationalization efforts be much more conceptually correct

I have looked at this document briefly, and it does seem to introduce some
interesting formal concepts and terms related to registry operation.  While
I don't always have a lot of patience for formalism myself, there are
certainly people who believe that the IETF would benefit from more formalism
in many areas.  In particular, people have rather often introduced ISO
terminology and formal concepts in the network management space for concepts
such as operational and administrative state.  While we might argue about
whether this is a good approach, these suggestions are not usually
considered to be out-of-scope or intentionally disruptive.

I do think that Jefsey operates from a misconception about the IETF's role
in DNS and registry management, and that some of his comments and advice
would be better directed at ICANN.  But, being confused about the division
between the IETF and ICANN in this area is not uncommon.  In fact, I'm not
100% sure that I understand that division completely.

I have to admit that, at times, I find Jefsey's posts long and
hard-to-understand.  There are many times when I don't read to the end of
them, but the same can be said for some of John Klensin's posts, and I
certainly don't want to see John removed from any of the lists I am on -- in
fact, I'd be glad to see him participate more!  I have found that people
from some cultures (France, my own Irish heritage, MIT :-)) tend to be more
long-winded than others, and I think that we should try to be patient with
that.

I also have found that Jefsey's posts have a higher signal-to-noise ratio
than many peoples' posts, but I am willing to chalk some of that up to the
fact that he is a non-native English speaker who is trying to make himself
understood, and so I try to be patient with that, too.

What I have not found in Jefsey's posts to the IETF list is any _intent_ to
disrupt the IETF process.  Nor have I found relentless ad hominem attacks
against individuals or enough off-topic information to warrant serious
action against him.

The biggest well-founded offense that Jefsey seems to be perpetrating is his
continued attempt to raise out-of-scope topics (such as IDN) on the
ietf-languages list.  I can understand why you are tired of dealing with
that.  However, I have not decided (as in, I have not yet made up my mind
and would like further input from others on this topic, particularly those
who have been affected by Jefsey's actions) whether that behaviour is
sufficiently disruptive to the IETF to warrant an indefinite suspension of
all of Jefsey's IETF posting rights.

Margaret






_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 07:14:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezv9b-0005EO-GE; Fri, 20 Jan 2006 07:14:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezv9Z-0005EA-Ga
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 07:14:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07101
	for ; Fri, 20 Jan 2006 07:12:32 -0500 (EST)
Received: from mtagate4.uk.ibm.com ([195.212.29.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzvIC-0001p5-Ki
	for ietf@ietf.org; Fri, 20 Jan 2006 07:23:02 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0KCDefw273888
	for ; Fri, 20 Jan 2006 12:13:40 GMT
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com
	[9.149.37.213])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0KCCP5l217806 for ; Fri, 20 Jan 2006 12:12:25 GMT
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0KCCOWC022005 for ; Fri, 20 Jan 2006 12:12:24 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0KCCOep021994; Fri, 20 Jan 2006 12:12:24 GMT
Received: from zurich.ibm.com (sig-9-145-134-195.de.ibm.com [9.145.134.195])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA74058;
	Fri, 20 Jan 2006 13:12:23 +0100
Message-ID: <43D0D3A5.3000908@zurich.ibm.com>
Date: Fri, 20 Jan 2006 13:12:21 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: "ietf@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80
Content-Transfer-Encoding: 7bit
Cc: jordi.palet@consulintel.es
Subject: Re: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi,

Jordi developed this document largely at my request and with
frequent interaction with the IAD. Clearly, it's intended to be
of use to IASA in the selection of future meeting sites, and
equally of use to potential hosts in understanding the
requirements. Self-evidently, it is not intended to be a
binding document - this is quite clear in the text. But
I guarantee that it will be a very useful document; in fact
it's already been of use in discussion with potential hosts.

I appreciate Jordi's volunteer time spent on this document;
he didn't have to do it.

My expectation is that it will exist as a living document for
some time to come; we don't have the running code experience to
consider freezing it as an RFC yet.

So, could people please review it for errors and omissions?

      Brian

JORDI PALET MARTINEZ wrote:
> Hi Richard,
> 
> Thanks for your comments.
> 
> See my response below, in-line.
> 
> Regards,
> Jordi
> 
> 
> 
> 
> 
>>De: Richard Shockey 
>>Responder a: 
>>Fecha: Thu, 19 Jan 2006 14:28:38 -0500
>>Para: IETF list 
>>Asunto: Re: FW: I-D
>>ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
>>
>>JORDI PALET MARTINEZ wrote:
>>
>>>Hi,
>>>
>>>Here is the original announcement and the IETF URL.
>>>
>>>Comments please !
>>>
>>
>>
>>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.
> 
> 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.
> 
> The point here is simple: We really need a criteria. I've proposed several
> venues since 2001, specially Madrid (but also Barcelona and others in Latin
> America and Caribbean), and it was successfully evaluated by a secretariat
> on-site visit. However, afterwards there was no "formal" rejection of the
> venue and just a comment that "isn't located downtown". However, less than
> one year after that, we had a meeting in San Diego, not in down town, and I
> can ensure you with much much much much worst conditions that the Madrid
> venue :-( (more distance to downtown, no public transport, more expensive,
> etc., etc.).
> 
> 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.
> 
> 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".
> 
> It hasn't been an easy document, I will say even more difficult than a
> technical spec, but I'm glad with the result. I think is a fair document,
> that demonstrates also that the IETF is evolving, maturing and we are going
> to have meetings in new places and be fair with all the contributors, and
> that will also facilitate newcomers to actually start and keep contributing.
> 
> I'm also very glad because I've received tens of comments, many more than
> what I can see, average, in the majority of other drafts.
> 
> I tried to accommodate my perception on the consensus of all those that
> contributed, and the document evolved significantly from the first release
> (11th July 2005), and I hope having achieved it.
> 
> I've also put completely aside, during this time, my own target to get a
> meeting organized in Madrid or other locations that I've been proposing for
> years, and even may be my own proposed venues will not match the criteria
> now, but I don't care, that's being fair and objective and that's really a
> must for this, if we want to get it working in an objective way.
> 
> 
>>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.
> 
> You can read in the document:
> "Generally, this document does not present a strict list of "MUST"
>    items.  Instead, it lists what needs to be evaluated, various
>    alternative solutions, or combinations thereof, that may apply."
> 
> 
>>This IMHO should have come directly out of the IAOC as the subject
>>matter is directly within their oversight and charter.
> 
> 
> 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.
> 
> You can read in the document:
> "In the end, the IAD will make the final decision and will be accountable
>    for it, and therefore he is responsible for applying the criteria
>    defined in this document according to the hosting/sponsorship
>    availability."
> 
> 
>>What is the relationship of this document to the IAOC?
> 
> 
> The same as for any other document which is related to the IAD, IASA, and/or
> secretariat, nothing less, nothing more: The IAOC is responsible of
> providing appropriate direction, oversight and approval.
> 
> But guess what, they also need some guidelines if we want an objective IAOC,
> right ?
> 
> 
>>Frankly there is'nt much about this document I like. It's a classic
>>example of the current IETF fashion for process over substance.
>>
> 
> 
> I don't really agree on that. The document is plenty of "juice" and
> "substance". I've organized a few meetings, not so big as IETF, but some
> times even for around 800-900 people and I can tell you that writing the
> document has been an interesting exercise that also discovered me issues
> that we generally aren't considering and need to be written down so the
> process is fair, *not* because the process itself.
> 
> 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.
> 
> 
>>
>>>
>>> Title  : IETF Meeting Venue Selection Criteria
>>> Author(s) : J. Palet
>>> Filename : draft-palet-ietf-meeting-venue-selection-criteria-04.txt
>>> Pages  : 18
>>> Date  : 2006-1-18
>>> 
>>>This document provides the IAD with technical and logistic criteria
>>>   for selecting venues for IETF meetings.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection
>>>-criteria-04.txt
>>
>>-- 
>>
>>
>>
>>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
>> or
>>
>> ; 
>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@ietf.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@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 07:21:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzvH4-0001Qi-9M; Fri, 20 Jan 2006 07:21:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzvH1-0001QV-UY
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 07:21:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07840
	for ; Fri, 20 Jan 2006 07:20:21 -0500 (EST)
Received: from mtagate4.uk.ibm.com ([195.212.29.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzvPk-00029M-7E
	for ietf@ietf.org; Fri, 20 Jan 2006 07:30:49 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0KCKofw144480
	for ; Fri, 20 Jan 2006 12:20:52 GMT
Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com
	[9.149.37.212])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0KCKl5l182630 for ; Fri, 20 Jan 2006 12:20:47 GMT
Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0KCKlOI005759 for ; Fri, 20 Jan 2006 12:20:47 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0KCKkBU005746; Fri, 20 Jan 2006 12:20:46 GMT
Received: from zurich.ibm.com (sig-9-145-134-195.de.ibm.com [9.145.134.195])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA25476;
	Fri, 20 Jan 2006 13:20:45 +0100
Message-ID: <43D0D59A.1010703@zurich.ibm.com>
Date: Fri, 20 Jan 2006 13:20:42 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Tim Chown 
References: <20060120104012.GE9015@login.ecs.soton.ac.uk>
In-Reply-To: <20060120104012.GE9015@login.ecs.soton.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Tim,

The web site says:

"We start Monday morning and run through Friday lunchtime, with late scheduling changes. Newcomer's training and technical 
tutorials takes place the previous Sunday afternoon. Participants should plan their travel accordingly."

Friday morning is part of the IETF. It's true that generally we schedule about
half as many parallel sessions as during the rest of the week, but that means
you only need to be in 4 places at once instead of 8 the rest of the time.

The survey results indicate that we shouldn't extend to a full day on Friday,
but scrapping those ~4 sessions would have serious impact on scehduling
constraints earlier in the week.

    Brian

Tim Chown wrote:
> Hi,
> 
> Has there been any discussion in the upper echelons of the IETF about the
> issue of Friday sessions?
> 
> If you look back over past agendas, it's typically a day with around 3-5
> meetings in one session to 11.30am, of which half or more are BoFs.
> 
> Is this likely to continue, such that if you're from a different
> continent to the host, and you choose to travel home on Friday to get
> home a day earlier and save a little hotel money, you stand a (slim) 
> chance of missing a WG session you'd like to attend?
> 
> Personally I would be happy to travel back Saturday if I knew Friday
> was a fullish day, but as it is it's neither here nor there really...
> thoughts?
> 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 07:41:19 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzvZv-0000ta-28; Fri, 20 Jan 2006 07:41:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzvZt-0000rk-C0; Fri, 20 Jan 2006 07:41:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09473;
	Fri, 20 Jan 2006 07:39:50 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ezvib-0002qI-1K; Fri, 20 Jan 2006 07:50:19 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 159A626C1E5; Fri, 20 Jan 2006 13:41:08 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 0297126C1D9; Fri, 20 Jan 2006 13:41:07 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k0KCf6Ya702939;
	Fri, 20 Jan 2006 13:41:06 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id AB4F716AA06; Fri, 20 Jan 2006 13:41:06 +0100 (CET)
Date: Fri, 20 Jan 2006 13:41:06 +0100
From: Stephane Bortzmeyer 
To: Margaret Wasserman 
Message-ID: <20060120124106.GA12201@nic.fr>
References: 
	<010201c61db9$95069670$0402a8c0@instant802.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <010201c61db9$95069670$0402a8c0@instant802.com>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: 'Harald Tveit Alvestrand' ,
	'Scott Hollenbeck' ,
	'Sam Hartman' , ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Fri, Jan 20, 2006 at 07:03:52AM -0500,
 Margaret Wasserman  wrote 
 a message of 155 lines which said:

> I also have found that Jefsey's posts have a higher signal-to-noise
> ratio than many peoples' posts, but I am willing to chalk some of
> that up to the fact that he is a non-native English speaker who is
> trying to make himself understood, and so I try to be patient with
> that, too.

I can testify that Jefsey Morfin's posts in french are as long, as
off-topic and as undecipherable than in english. 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 08:42:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzwWs-0006Ye-JD; Fri, 20 Jan 2006 08:42:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzwWq-0006YP-4v
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 08:42:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13327
	for ; Fri, 20 Jan 2006 08:40:44 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzwfW-0004bx-NE
	for ietf@ietf.org; Fri, 20 Jan 2006 08:51:14 -0500
Received: (qmail invoked by alias); 20 Jan 2006 13:41:49 -0000
Received: from p54A7EC8F.dip.t-dialin.net (EHLO peter-dambier.de)
	[84.167.236.143]
	by mail.gmx.net (mp017) with SMTP; 20 Jan 2006 14:41:49 +0100
X-Authenticated: #8956597
Message-ID: <43D0E898.1060702@peter-dambier.de>
Date: Fri, 20 Jan 2006 14:41:44 +0100
From: Peter Dambier 
Organization: Peter and Karin Dambier
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: 	<010201c61db9$95069670$0402a8c0@instant802.com>
	<20060120124106.GA12201@nic.fr>
In-Reply-To: <20060120124106.GA12201@nic.fr>
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: peter@peter-dambier.de
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stephane Bortzmeyer wrote:
> On Fri, Jan 20, 2006 at 07:03:52AM -0500,
>  Margaret Wasserman  wrote 
>  a message of 155 lines which said:
> 
> 
>>I also have found that Jefsey's posts have a higher signal-to-noise
>>ratio than many peoples' posts, but I am willing to chalk some of
>>that up to the fact that he is a non-native English speaker who is
>>trying to make himself understood, and so I try to be patient with
>>that, too.
> 
> 
> I can testify that Jefsey Morfin's posts in french are as long, as
> off-topic and as undecipherable than in english. 


Maybe it is a question of time. It is not always obvious on first
sight what Jefsey means. But it is not obvious on first sight why
protocols break from time to time but break they do.

Internet Engineering is done on NANOG. IETF is far too slow and too
esoteric. The real problems do happen in operations and they must be
dealt with immediately.

What did happen does get into IETF slowly. People like Jefsey do
remember "I have seen that before. It is not noise. It will happen
again".

People like Harald dont have the time to think about it. They stick
in operations down to their elbows. Of course those people have
different views of course they have problems communicating. But
that is exactly what Jefsey says.

The internet has changed slowly. It is no longer research. It has
become operations. But at the same time the internet has drifted
away from IETF to NANOG, RIPE and others.

How about the ROOT? You cannot discuss DNS here or at NANOG.

Nameresolution is done adhoc mostly from peer to peer systems.
The most popular operating systems of two companies do what they
feel is correct. The have the power/number of users to do it.

Outside IETF and NANOG we have ORSN, ORSC, unnamed chinese root,
OpenNic, New.Net, Cesidian root, Public-Root, Unified-Root,
United-Root and others. Dont forget the people who take their
laptop out of their box switch it on and run their own network
without even knowing it. Those people dont speak english.
But those people are our costumers.

I dont want to miss either Jefsey or Harald. We need them both.

-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@peter-dambier.de
mail: peter@echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 09:03:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzwrP-0005Ee-4e; Fri, 20 Jan 2006 09:03:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzwrN-0005EL-Rf; Fri, 20 Jan 2006 09:03:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14982;
	Fri, 20 Jan 2006 09:01:58 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ezx07-0005Fg-3M; Fri, 20 Jan 2006 09:12:28 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0KE3IDN019523; 
	Fri, 20 Jan 2006 08:03:18 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id ; Fri, 20 Jan 2006 15:03:17 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550915577E@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" 
To: Stephane Bortzmeyer 
Date: Fri, 20 Jan 2006 15:03:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: ietf@ietf.org, iesg@ietf.org
Subject: RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Glad to hear it is not just me.

Bert

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On Behalf Of
> Stephane Bortzmeyer
> Sent: Friday, January 20, 2006 13:41
> To: Margaret Wasserman
> Cc: 'Harald Tveit Alvestrand'; 'Scott Hollenbeck'; 'Sam Hartman';
> ietf@ietf.org; iesg@ietf.org
> Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey)
> Morfin
> 
> 
> On Fri, Jan 20, 2006 at 07:03:52AM -0500,
>  Margaret Wasserman  wrote 
>  a message of 155 lines which said:
> 
> > I also have found that Jefsey's posts have a higher signal-to-noise
> > ratio than many peoples' posts, but I am willing to chalk some of
> > that up to the fact that he is a non-native English speaker who is
> > trying to make himself understood, and so I try to be patient with
> > that, too.
> 
> I can testify that Jefsey Morfin's posts in french are as long, as
> off-topic and as undecipherable than in english. 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 09:07:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezwvf-0006Sp-Eo; Fri, 20 Jan 2006 09:07:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezwvd-0006Sk-8c
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 09:07:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15363
	for ; Fri, 20 Jan 2006 09:06:22 -0500 (EST)
Received: from mtagate4.uk.ibm.com ([195.212.29.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezx4M-0005Ot-JA
	for ietf@ietf.org; Fri, 20 Jan 2006 09:16:52 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0KE75fw225016
	for ; Fri, 20 Jan 2006 14:07:12 GMT
Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com
	[9.149.165.229])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0KE748Q177468
	for ; Fri, 20 Jan 2006 15:07:04 +0100
Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0KE6xkS003669 for ; Fri, 20 Jan 2006 15:06:59 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0KE6x5C003655; Fri, 20 Jan 2006 15:06:59 +0100
Received: from zurich.ibm.com (sig-9-145-134-195.de.ibm.com [9.145.134.195])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA74174;
	Fri, 20 Jan 2006 15:06:57 +0100
Message-ID: <43D0EE7E.1050409@zurich.ibm.com>
Date: Fri, 20 Jan 2006 15:06:54 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Tim Chown 
References: 	<43D0C93F.5010306@zurich.ibm.com>
	<20060120113450.GM9015@login.ecs.soton.ac.uk>
In-Reply-To: <20060120113450.GM9015@login.ecs.soton.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion 
Subject: Re: hotels for Dallas?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Tim Chown wrote:
> On Fri, Jan 20, 2006 at 12:27:59PM +0100, Brian E Carpenter wrote:
> 
>>Registration for Dallas is in the final test stage, with a new system for
>>credit card processing, and we want it to be rock solid.
>>Should be open *really* soon now.
> 
> 
> And the hotel info?

The hotel blocks won't be affected by the late start to 
registration. Sorry about this but these things are rather bound 
together.

     Brian
> 
> (And is the meeting ending 11.30am on the Friday?)

Yes, as always.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 10:31:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzyEC-0001NI-KO; Fri, 20 Jan 2006 10:31:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyEA-0001LO-T7
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 10:31:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21725
	for ; Fri, 20 Jan 2006 10:29:35 -0500 (EST)
Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyMt-00087S-S3
	for ietf@ietf.org; Fri, 20 Jan 2006 10:40:06 -0500
Received: from darkwing.uoregon.edu (llynch@localhost [127.0.0.1])
	by darkwing.uoregon.edu (8.13.5/8.13.5) with ESMTP id k0KFUl8u005816;
	Fri, 20 Jan 2006 07:30:47 -0800 (PST)
Received: from localhost (llynch@localhost)
	by darkwing.uoregon.edu (8.13.5/8.13.5/Submit) with ESMTP id
	k0KFUlvA005809; Fri, 20 Jan 2006 07:30:47 -0800 (PST)
Date: Fri, 20 Jan 2006 07:30:47 -0800 (PST)
From: "Lucy E. Lynch" 
To: Pekka Savola 
In-Reply-To: 
Message-ID: 
References: 
	<43CFE866.8030405@shockey.us>
	
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: IETF list 
Subject: Re: FW: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Thu, 19 Jan 2006, Pekka Savola wrote:

> On Thu, 19 Jan 2006, Richard Shockey wrote:
> > This IMHO should have come directly out of the IAOC as the subject matter is
> > directly within their oversight and charter.
> >
> > What is the relationship of this document to the IAOC?
>
> I agree that these are valid points.  Spending cycles on this document
> isn't much use unless IAOC et al "buy in" into it.  Could someone from
> the "powers that be" say something on their thoughts on how venue
> selection criteria (etc.) should be developed?

I'm not sure that I constitute a "power" (more likely just another
slave to process) but I've added review of this document to the next
IAOC Agenda and we will get Jordi our comments shortly there after.

- lel

> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 11:16:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzywX-0004GJ-R7; Fri, 20 Jan 2006 11:16:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzywW-0004G9-KK
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 11:16:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26445
	for ; Fri, 20 Jan 2006 11:15:24 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezz5G-0001ab-To
	for ietf@ietf.org; Fri, 20 Jan 2006 11:25:56 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0KGGbnA012714; Fri, 20 Jan 2006 11:16:37 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23490; 
	Fri, 20 Jan 2006 11:16:36 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Fri, 20 Jan 2006 11:16:36 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886348@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Marshall Eubanks'" , jordi.palet@consulintel.es
Date: Fri, 20 Jan 2006 11:16:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Cc: ietf@ietf.org
Subject: RE: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-
	04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Marshall,

	RFCs are living documents as well, though the process for
change is somewhat cumbersome.  There are examples of RFCs that
have been updated many times in the last few years.

--
Eric 

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Marshall Eubanks
--> Sent: Thursday, January 19, 2006 9:27 PM
--> To: jordi.palet@consulintel.es
--> Cc: ietf@ietf.org
--> Subject: Re: I-D 
--> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
--> 
--> Speaking just for myself :
--> 
--> I think that there is a strong benefit to having an agreed 
--> upon set  
--> of parameters
--> for new meeting locations.
--> 
--> Having said that, this may not be appropriate for an RFC. Maybe it  
--> should be a "living document" on a web page
--> or wiki, as is being done / considered for mailing list anti-SPAM  
--> suggestions. Maybe a new class of
--> IETF document publication is needed.
--> 
--> Regards
--> Marshall Eubanks
--> 
--> On Jan 19, 2006, at 8:53 PM, JORDI PALET MARTINEZ wrote:
--> 
--> > Hi Paul,
--> >
--> > I guess we can question ourselves the same way in many other  
--> > documents ...
--> >
--> > The importance of having documents is part of the IETF "working  
--> > mode". Is
--> > our way to say, here there is a consensus on this specific topic.
--> >
--> > I guess is not my final decision if it will become and 
--> RFC or not,  
--> > but it
--> > will not be fair not following the same path for this 
--> document as  
--> > for many
--> > others.
--> >
--> > That said, the original idea has been, since I was 
--> pointed out for  
--> > editing
--> > this document, to follow exactly the same process as with 
--> many other
--> > documents, technical and administrative.
--> >
--> > Regards,
--> > Jordi
--> >
--> >
--> >
--> >
--> >> De: Paul Hoffman 
--> >> Responder a: 
--> >> Fecha: Thu, 19 Jan 2006 12:43:42 -0800
--> >> Para: Richard Shockey , IETF list 
--> 
--> >> Asunto: Re: FW: I-D
--> >> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
--> >>
--> >> At 2:28 PM -0500 1/19/06, Richard Shockey wrote:
--> >>> It's a classic example of the current IETF fashion for 
--> process over
--> >>> substance.
--> >>
--> >> Fully agree. What is the justification for this becoming an RFC?
--> >>
--> >> --Paul Hoffman, Director
--> >> --VPN Consortium
--> >>
--> >> _______________________________________________
--> >> Ietf mailing list
--> >> Ietf@ietf.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@ietf.org
--> > https://www1.ietf.org/mailman/listinfo/ietf
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 11:30:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzzA5-0002LQ-Rf; Fri, 20 Jan 2006 11:30:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzA3-0002LK-NG
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 11:30:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27409
	for ; Fri, 20 Jan 2006 11:29:23 -0500 (EST)
Received: from igw2.watson.ibm.com ([129.34.20.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzzIo-00022A-Fi
	for ietf@ietf.org; Fri, 20 Jan 2006 11:39:55 -0500
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com
	[129.34.20.40])
	by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with
	ESMTP id k0KGUZIN011215; Fri, 20 Jan 2006 11:30:35 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1])
	by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with
	ESMTP id k0KGUZv78188; Fri, 20 Jan 2006 11:30:35 -0500
Received: from [9.2.43.127] (saturn.watson.ibm.com [9.2.43.127])
	by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with
	ESMTP id k0KGUYs78186; Fri, 20 Jan 2006 11:30:34 -0500
Message-ID: <43D1102A.5020507@watson.ibm.com>
Date: Fri, 20 Jan 2006 11:30:34 -0500
From: Barry Leiba 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "ietf@ietf.org" 
References: 
	<43D0D3A5.3000908@zurich.ibm.com>
In-Reply-To: <43D0D3A5.3000908@zurich.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by igw2.watson.ibm.com id
	k0KGUZIN011215
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: quoted-printable
Cc: jordi.palet@consulintel.es
Subject: Re: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "ietf@ietf.org" 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> So, could people please review it for errors and omissions?

My biggest concern is in sections "2.3.  Freedom of Participation"
and "2.5.  Attendance Limitation and Visas", in that I'm not sure
how realistic they are.  Without getting overly into politics (let's
please not), I think they reflect a somewhat na=EFve view of some of
the political realities.  Specifically...

    Meetings should not be held in countries where some attendees could
    be disallowed entry or where freedom of speech is not guaranteed for
    all participants.

The United States certainly cannot be assumed to allow ALL attendees
entry.  It's well known that we have lists of people we won't allow
in, and lest we think that's limited to the sort of nasty folk who
wouldn't be attending the IETF anyway, I'll point out that a plane
carrying Yusuf Islam -- the singer formerly known as Cat Stevens --
was landed in Maine so that the singer could be removed and sent home
before the plane continued to New York.  Individuals do get on these
lists unreasonably, or by mistake.

Ignoring the issue of individuals, whole groups may have difficulty.
The US has a list of "restricted countries", which includes Iran and
North Korea, and a longer list of countries to which exports of software
or technology are controlled (this list includes Russia and China,
for example).  There's certainly no guarantee at any time that attendees
from these countries won't have a difficult time getting visas, or might
not be able to get them at all.

As to freedom of speech:  We could argue about the reality of that
for a while, but even apart from that, our government has made it
clear that it considers those constitutional rights to apply to US
citizens only, and not to foreign nationals who may be visiting.

OK, all that said, I don't think the US is a bad country in which to
have IETF meetings.  Which is, really, my point: I think the text
needs to be changed to better express the intent, which is that we
want to avoid countries that are unduly restrictive, without trying
to limit things to utopian -- and non-existent -- lands of complete
freedom.

--
Barry Leiba  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 11:32:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzzC4-0002fq-M0; Fri, 20 Jan 2006 11:32:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzzC1-0002fY-P2; Fri, 20 Jan 2006 11:32:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27578;
	Fri, 20 Jan 2006 11:31:25 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzzKj-00026E-AX; Fri, 20 Jan 2006 11:41:57 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0KGXAqT029222
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2006 08:33:11 -0800
Message-ID: <43D1109D.3060700@dcrocker.net>
Date: Fri, 20 Jan 2006 08:32:29 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: John C Klensin 
References: 	
	<6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
In-Reply-To: <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: Scott Hollenbeck , ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>> However a PR action is an incredibly huge hammer.  
...
> 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.


1. The hammer is, indeed, huge.  That is why it must be reserved for use on folk 
who cause significant problems, rather than folk who merely demonstrate a bit of 
social gracelessness.  In particular, it is to be used when someone establishes 
a track record of real and significant disruption.

2. Almost everyone can have a moment of utility, just as almost everyone can 
have a moment of disruption.  The question is whether that utility 
counter-balances the damage caused by being disruptive.  I believe the purpose 
of the current procedure is, really, to make exactly that assessment.

3. None of us is essential to the IETF.  No matter how wonderful anyone's 
occasional contributions, the IETF can do just fine without any one of us. First 
and foremost, the IETF is about the social process of developing agreement on 
technical matters.  Anyone who demonstrates a pattern of disruption to that 
process is hurting the core of the IETF. Such folk need to be excluded from 
public IETF discussions.

d/
-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 11:34:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzzDq-0002tA-FH; Fri, 20 Jan 2006 11:34:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzzDo-0002st-7D; Fri, 20 Jan 2006 11:34:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27762;
	Fri, 20 Jan 2006 11:33:16 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzzMY-0002BC-Kr; Fri, 20 Jan 2006 11:43:48 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 0A28BE006A; Fri, 20 Jan 2006 11:34:35 -0500 (EST)
To: Harald Tveit Alvestrand 
References: 
	
	
From: Sam Hartman 
Date: Fri, 20 Jan 2006 11:34:35 -0500
In-Reply-To:  (Harald
	Tveit Alvestrand's message of "Fri, 20 Jan 2006 08:17:08 +0100")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: Scott Hollenbeck , ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Harald" == Harald Tveit Alvestrand  writes:

    Harald> --On torsdag, januar 19, 2006 20:03:56 -0500 Sam Hartman
    Harald>  wrote:

    >> I'd first ask why repeated 30-day suspensions are ineffective.
    >> Harald seems to be getting fairly efficient at suspending
    >> Jefsey on ietf-languages.  I believe he's been suspended on
    >> LTRU before.  Is Jefsey actually doing much damage there with
    >> all these suspensions?

    Harald> At the moment, the pattern on ietf-languages is that:

    Harald> - Jefsey posts one of his offtopic political harangues -
    Harald> About five different people complain privately to me - I
    Harald> suspend Jefsey's posting privilleges for a month - About
    Harald> five people send thank-you notes, and wonder whether the
    Harald> IESG will get off its butt and allow him to be suspended
    Harald> permanently, usually accompanied with ruminations about
    Harald> whether it makes any sense to participate in an
    Harald> organization that is so completely ineffective in handling
    Harald> disruptive persons - A month passes in which the list is
    Harald> relatively calm - I remove Jefsey's suspension - The
    Harald> pattern repeats

    Harald> This is a waste of time, resources and the goodwill of the
    Harald> people who contribute constructively.

OK.

Now I'm sure we all agree that it is worth some frustration for
openness.

I'd appreciate it if you'd help me try and find the appropriate level
of frustration.

Would six month suspensions instead of 30 day suspensions give you
enough time during a suspension to avoid driving people away and to
make it likely that you would not be too frustrated to run the lists?


What about suspending Jefsey from just the ietf-langugages list and
possibly the ltru list?
Would that be a reasonable compromise?  

If not, why not?

I do realize that some have questioned whether the IESG has the
authority to make such a narrowly scoped suspension.

It is very clear that the community could choose to grant the IESG
this authority in the form of a BCP.  I can make some arguments about
why the IESG has the authority today, although I would describe them
as stretches.

--Sam

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 11:55:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzzXr-0004VT-C7; Fri, 20 Jan 2006 11:55:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzXo-0004SV-Ju
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 11:55:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29837
	for ; Fri, 20 Jan 2006 11:53:56 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzzgZ-000312-Ia
	for ietf@ietf.org; Fri, 20 Jan 2006 12:04:28 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0KGtDQx007346
	for ; Fri, 20 Jan 2006 10:55:14 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id ; Fri, 20 Jan 2006 17:55:11 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550922BE6B@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" 
To: ietf@ietf.org
Date: Fri, 20 Jan 2006 17:55:12 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-
	04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Well said Barry!

Bert

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On Behalf =
Of
> Barry Leiba
> Sent: Friday, January 20, 2006 17:31
> To: ietf@ietf.org
> Cc: jordi.palet@consulintel.es
> Subject: Re: I-D
> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
>=20
>=20
> > So, could people please review it for errors and omissions?
>=20
> My biggest concern is in sections "2.3.  Freedom of Participation"
> and "2.5.  Attendance Limitation and Visas", in that I'm not sure
> how realistic they are.  Without getting overly into politics (let's
> please not), I think they reflect a somewhat na=EFve view of some of
> the political realities.  Specifically...
>=20
>     Meetings should not be held in countries where some=20
> attendees could
>     be disallowed entry or where freedom of speech is not=20
> guaranteed for
>     all participants.
>=20
> The United States certainly cannot be assumed to allow ALL attendees
> entry.  It's well known that we have lists of people we won't allow
> in, and lest we think that's limited to the sort of nasty folk who
> wouldn't be attending the IETF anyway, I'll point out that a plane
> carrying Yusuf Islam -- the singer formerly known as Cat Stevens --
> was landed in Maine so that the singer could be removed and sent home
> before the plane continued to New York.  Individuals do get on these
> lists unreasonably, or by mistake.
>=20
> Ignoring the issue of individuals, whole groups may have difficulty.
> The US has a list of "restricted countries", which includes Iran and
> North Korea, and a longer list of countries to which exports=20
> of software
> or technology are controlled (this list includes Russia and China,
> for example).  There's certainly no guarantee at any time=20
> that attendees
> from these countries won't have a difficult time getting=20
> visas, or might
> not be able to get them at all.
>=20
> As to freedom of speech:  We could argue about the reality of that
> for a while, but even apart from that, our government has made it
> clear that it considers those constitutional rights to apply to US
> citizens only, and not to foreign nationals who may be visiting.
>=20
> OK, all that said, I don't think the US is a bad country in which to
> have IETF meetings.  Which is, really, my point: I think the text
> needs to be changed to better express the intent, which is that we
> want to avoid countries that are unduly restrictive, without trying
> to limit things to utopian -- and non-existent -- lands of complete
> freedom.
>=20
> --
> Barry Leiba  (leiba@watson.ibm.com)
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 12:06:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezzi4-00060s-T0; Fri, 20 Jan 2006 12:06:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezg4q-00056e-CN; Thu, 19 Jan 2006 15:08:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22672;
	Thu, 19 Jan 2006 15:06:45 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EzgDO-0003Z7-BR; Thu, 19 Jan 2006 15:17:05 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2006 12:07:17 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.01,201,1136188800"; 
	d="scan'208"; a="20055144:sNHT70709040654"
Received: from [68.50.18.9] (che-vpn-cluster-1-118.cisco.com [10.86.240.118])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id
	k0JK7DJf016682; Thu, 19 Jan 2006 15:07:14 -0500 (EST)
In-Reply-To: <6.2.3.4.2.20060119152629.07a63790@mail.jefsey.com>
References: 
	<961BD45B6214BD0396648D56@svartdal.hjemme.alvestrand.no>
	<9D2F8783-2CCD-453E-AC11-798CCC94B0E1@cs.columbia.edu>
	
	<6.2.3.4.2.20060119152629.07a63790@mail.jefsey.com>
Mime-Version: 1.0 (Apple Message framework v623)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <46116e90edf35c1148bc1e989c389a20@cisco.com>
Content-Transfer-Encoding: 7bit
From: John Schnizlein 
Date: Thu, 19 Jan 2006 15:06:19 -0500
To: "JFC (Jefsey) Morfin" 
X-Mailer: Apple Mail (2.623)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 20 Jan 2006 12:05:55 -0500
Cc: GEOPRIV WG ,
	Harald Tveit Alvestrand , ietf@ietf.org
Subject: Re: [Geopriv] Re: Last Call: 'Location Types Registry' to
	Proposed	Standard 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 19, 2006, at 10:11 AM, JFC (Jefsey) Morfin wrote:
> ...
>
> "multinationalisation" calls for the concept to be equally understood 
> (what does "understand" mean?) the same way between every cultures 
> (every ends are equal). Either because the concept is truly universal. 
> Or because you built all the cross-national in-between extended 
> services to permit a polylogual relation. This means that when an 
> American end says "kitchen", the French end will receive "American 
> style Kitchen" (our kithens are not _built_ the same way and do not 
> include the same set of things).

Interesting.  Do French kitchens not include a coffee-maker, stove, 
oven, sink, refrigerator and counters?  What do they have, besides 
fewer chemicals on/in their food, that American kitchens do not?

> I take a very common example. Many languages have the same term for 
> blue and green and only consider them as different shades.

Blue and green are different hues.  Different shades are the same hue 
but different concentration, for example navy blue compared to royal 
blue.  http://en.wikipedia.org/wiki/Color_theory

Please provide a reference for languages that use the same term for 
blue and green.  I would be surprised because these colors have 
different receptors in the human eye.  
http://en.wikipedia.org/wiki/Cone_cell

> Recent studies shown that people of different languages describe the 
> different variations of blue/green the same way with the right eye 
> (left brain) but differently with the left eye (right brain), 
> depending on the language.

Please provide references for these studies.  The "right eye (left 
brain)" description is revolutionary, since the function of the optic 
chiasm was hypothesized by Newton in 1704 and demonstrated by by Ramon 
y Cajal in 1899.  http://en.wikipedia.org/wiki/Optic_chiasm

John

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 12:06:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezzi6-00061R-MQ; Fri, 20 Jan 2006 12:06:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezv8x-0004kh-Qz
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 07:13:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07079
	for ; Fri, 20 Jan 2006 07:11:58 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzvHe-0001oJ-Nn
	for ietf@ietf.org; Fri, 20 Jan 2006 07:22:29 -0500
Received: by zproxy.gmail.com with SMTP id 8so441439nzo
	for ; Fri, 20 Jan 2006 04:13:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
	b=l7c49V6ndHhNJcZQcIYIYCqIkGd6FQWxQOlTkvsc3mQpb/y3gGU3q7CLmgWBIrVJ4UHi2HIvo7cA7pzwR/QLvv2JirMM/EqF8EbNT111kV/Uc3z8TJBylII1WHkRf909rg21We6Gm9fRggm9cz8OZUQen9gYSzs1p4gBmieNF3E=
Received: by 10.65.147.3 with SMTP id z3mr1080851qbn;
	Fri, 20 Jan 2006 04:13:22 -0800 (PST)
Received: by 10.65.250.3 with HTTP; Fri, 20 Jan 2006 04:13:22 -0800 (PST)
Message-ID: <955ba8bb0601200413v293d3964h46abfb637cda6657@mail.gmail.com>
Date: Fri, 20 Jan 2006 17:43:22 +0530
From: Neil Harwani 
To: ietf@ietf.org
In-Reply-To: <43d06019.665462fc.1110.55beSMTPIN_ADDED@mx.gmail.com>
MIME-Version: 1.0
References: <43d06019.665462fc.1110.55beSMTPIN_ADDED@mx.gmail.com>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 6b835336d254034fcc92a13cb7bf8f2d
X-Mailman-Approved-At: Fri, 20 Jan 2006 12:05:55 -0500
Subject: Re: Ietf Digest, Vol 21, Issue 74
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1257507273=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1257507273==
Content-Type: multipart/alternative; 
	boundary="----=_Part_4862_1599103.1137759202714"

------=_Part_4862_1599103.1137759202714
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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@ietf.org  wrote:
>
> Send Ietf mailing list submissions to
>         ietf@ietf.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@ietf.org
>
> You can reach the person managing the list at
>         ietf-owner@ietf.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 
> Subject: Re: I-D
>         ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> To: jordi.palet@consulintel.es
> Cc: ietf@ietf.org
> Message-ID: 
> Content-Type: text/plain; charset=3Dus-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 
> Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey)
>         Morfin
> To: Scott Hollenbeck 
> Cc: ietf@ietf.org, iesg@ietf.org
> Message-ID: <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
> Content-Type: text/plain; charset=3Dus-ascii
>
> --On Thursday, 19 January, 2006 20:03 -0500 Sam Hartman
>  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 
> Subject: Re: I-D
>         ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> To: "ietf@ietf.org" 
> Message-ID: 
> Content-Type: text/plain;       charset=3D"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 
> > Responder a: 
> > Fecha: Thu, 19 Jan 2006 22:00:10 -0500
> > Para: 
> > CC: "ietf@ietf.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@ietf.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 
> Subject: Re: I-D
>         ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> To: jordi.palet@consulintel.es
> Cc: "ietf@ietf.org" 
> Message-ID: <43D05AB5.4090009@shockey.us>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>
> 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 (no=
t
> > 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. A=
s
> > 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
>  or
> 
>  ; 
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 20 Jan 2006 04:54:59 +0100
> From: JORDI PALET MARTINEZ 
> Subject: Re: I-D
>         ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> To: "ietf@ietf.org" 
> Message-ID: 
> Content-Type: text/plain;       charset=3D"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 correc=
t
> in the reality, and can't be 100% subjective (yes there will be a decisio=
n
> 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 compare=
d
> 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 
> > Responder a: 
> > Fecha: Thu, 19 Jan 2006 22:36:21 -0500
> > Para: 
> > CC: "ietf@ietf.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, bu=
t
> to
> >> how we want to manage the meetings the next years.
> >>
> >>
> >> Clearly, the old document that we have in the IETF site is insufficien=
t
> 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 o=
f
> > IETF Management is to Manage so we can get on with our business which i=
s
> > 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 i=
n
> > 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 an=
d
> > 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 th=
e
> > 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 sid=
e
> on
> >> the document during all the process in any of the previous versions. I=
t
> 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 IET=
F
> > administrative structure is very new and some what fragile and we shoul=
d
> > 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
> >  or
> > 
> >  ; 
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.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@ietf.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

------=_Part_4862_1599103.1137759202714
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Guyz I am very happy and privileged to be among you all. I don't read all m=
essages but try to catch up when free.



Thanks,

Neil Harwani.

On 1/20/06, ietf-request=
@ietf.org <ietf-request=
@ietf.org
> wrote:
Send Ietf mailing list submissions to
     =
;   
ietf@ietf.org

To subscribe or unsubscribe via the World Wide Web=
, visit
        https://www1.ietf.org/mailman/listi=
nfo/ietf
or, via email, send a message with subject or body 'help' t=
o

        ietf-request@ietf.org

You can reach the person=
 managing the list at
        ietf-owner@ietf.org

When re=
plying, please edit your Subject line so it is more specific

than "Re: Contents of Ietf digest..."


Today's Topi=
cs:

   1. Re: I-D
      A=
CTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
 &nb=
sp;    (John C Klensin)
   2. Re: IETF Las=
t Call under RFC 3683 concerning JFC (Jefsey)

      Morfin (John C Klensin)
 &n=
bsp; 3. Re: I-D
      ACTION:draft-palet-i=
etf-meeting-venue-selection-criteria-04.txt
    &nbs=
p; (JORDI PALET MARTINEZ)
   4. Re: I-D
  &n=
bsp;   ACTION:draft-palet-ietf-meeting-venue-selection-crite=
ria-04.txt

      (Richard Shockey)
   5=
. Re: I-D
      ACTION:draft-palet-ietf-me=
eting-venue-selection-criteria-04.txt
     &nbs=
p;(JORDI PALET MARTINEZ)


---------------------------------------=
-------------------------------


Message: 1
Date: Thu, 19 Jan 2006 22:00:10 -0500
From: John C=
 Klensin <john-ietf@jck.com>=

Subject: Re: I-D
        ACT=
ION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt

To: jordi.palet@consulint=
el.es
Cc: ietf@ietf.org
Mess=
age-ID: <D381E272=
2F41534A94B8294F@p3.JCK.COM
>
Content-Type: text/plain; charset=3Dus-ascii

Jordi,
<=
br>Unlike several others and their comments, there are significant
parts=
 of this I find useful, at least in terms of identifying
issues that sho=
uld be examined.  There are several other parts

of it with which I disagree.  And, ultimately, the presentati=
on
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, an=
d consensus among those with significant experience
planning and running=
 IETF meetings would certainly be no less
difficult.

The difficul=
ty, 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
con=
sider anything whose purpose is to tell the IAD, IAOC, or
IESG (or the I=
ETF 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
perio=
dically as needed, but keeping it out there as a
perspective that the IA=
D 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<=
br>below) along with a suggestion that they establish a set of
periodica=
lly-updated IETF operating procedure notes and put this
(or a modified v=
ersion 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 part=
icular topic
areas about which we appear to disagree, but I don't consid=
er a

discussion of those specific topics to be appropriate or useful
on t=
he IETF list unless the IESG decides that this document
should be an IET=
F topic (e.g., via a Last Call for BCP).

    joh=
n

(note: in both the document and some of your comments in the

last 24 hours, I think you've gotten the IAOC (the oversight
committ=
ee/ 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 a=
re supervised by the IAD and/or IAOC directly).)




-------=
-----------------------

Message: 2
Date: Thu, 19 Jan 2006 22:25:4=
3 -0500

From: John C Klensin <john-ietf=
@jck.com>
Subject: Re: IETF Last Call under RFC 3683 concerning J=
FC (Jefsey)
        Morfin
To=
: Scott Hollenbeck <
sah@428cobrajet.net>
Cc: ietf@ie=
tf.org, iesg@ietf.org
Message-I=
D: <6B00F5E2964A4=
A00C0C1323C@p3.JCK.COM
>
Content-Type: text/plain; charset=3Dus-ascii

--On Thursd=
ay, 19 January, 2006 20:03 -0500 Sam Hartman
<hartmans-ietf@mit.edu> wrote:

>...
&g=
t; Even by his own admission Jefsey has been engaging in

> filibustering--a practice that I think we would agree is
> d=
isruptive.  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 agr=
ee that we need to adopt a strategy that
> prevents Jefsey from disru=
pting 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
&g=
t; 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 th=
ey have nothing
> to offer.
>
> That's not true for Jefse=
y.  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
&=
gt; described concerns of global users and how our protocols,

> including IDN, may not meet user requirements.  These co=
ncerns
> are real and parts of them have been worked on by
> lo=
ng-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. &nbs=
p;I
> personally have found Jefsey's formulations of these concerns> enlightening; I think he has significantly helped me
> underst=
and how the IETF might be perceived and what some user

> concerns with our protocol might be.
>...

I have to r=
eluctantly agree with Sam.  I'm reluctant because
there are fa=
r 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, b=
ut that is exactly the point and the problem.

I have many wishes abo=
ut 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 IA=
B 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,<=
br>when he is told to take particular topics elsewhere, I wish he
would =
heed that advice.

That said, when he appears to be deliberately fili=
bustering, or

otherwise repeating the same comments over and over again, I see
tha=
t as more than adequate justification for enforced time-outs
from the re=
levant lists.  But I'm not convinced that any of this
is evide=
nce 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 wha=
tever 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
parti=
cular list, it would seem reasonable to me for the relevant
AD to author=
ize 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,
wi=
th  sufficient repeated disruptive behavior, find themselves
r=
ather effectively banned for the effective duration of a WG.

If the IESG believes that a formal RFC3933 experiment is needed
to d=
o that, then let's write down and run that experiment.
But, until we hav=
e tried the above --and any other plausible
actions we can think of-- le=
t's save the 3683 actions for those

whose behavior is more clearly inappropriate and
non-constructive th=
an Jefsey's.

    john




-------=
-----------------------

Message: 3
Date: Fri, 20 Jan 2006 04:30:5=
5 +0100
From: JORDI PALET MARTINEZ <
jordi.palet@consulintel.es>
Subject: Re: I-D
       &nbs=
p;ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
To: &q=
uot;ietf@ietf.org
" <ietf@ietf.org>
Me=
ssage-ID: <BFF617FF.152738%jordi.palet@consulintel.es>
Content-Type: text/p=
lain;       charset=3D"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, a=
nd 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@jck.com>
> Responder a: &=
lt;
ietf-bounces@ietf.org>
&=
gt; Fecha: Thu, 19 Jan 2006 22:00:10 -0500
> Para: <jordi.palet@consulintel.es>
> =
CC: "
ietf@ietf.org" <ietf@ietf.org>
> Asunto: Re: I-D
> AC=
TION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
>
&g=
t; Jordi,

>
> Unlike several others and their comments, there are signif=
icant
> 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 prese=
ntation
> of a list of suggestions without prioritization lowers its<=
br>> utility considerably.  On the other hand, I doubt that co=
nsensus
> even on the list of suggested principles is possible. =
 Consensus

> about how they should be prioritized would be more difficult
&g=
t; yet, and consensus among those with significant experience
> plann=
ing 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 do=
ne
> with the document operationally.  It is just my opinio=
n, but I

> consider anything whose purpose is to tell the IAD, IAOC, or
&g=
t; IESG (or the IETF or IASA more generally) how to behave
> procedur=
ally or decide on things to be completely inappropriate
> for publica=
tion 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 possibi=
lity is to just leave it as an I-D, updating it
> periodically as nee=
ded, but keeping it out there as a

> perspective that the IAD might consider.  That has certa=
inly
> been done with some IETF and meeting operational documents in<=
br>> the past.  Another would be to pass it to the IAOC (see n=
ote
> 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<=
br>> with which I disagree.

>
> I will try to find time to send you a list of particular t=
opic
> 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).
>
>&=
nbsp;    john
>
> (note: in both the document an=
d some of your comments in the

> last 24 hours, I think you've gotten the IAOC (the oversight
&g=
t; committee/ IASA decision body) and IASA (the whole
> administrativ=
e operation in principle, but, in practice, just
> the conceptual rea=
lization of the IAOC, the IAD (whom they

> supervise), and the set of tasks and those who carry them out
&=
gt; that are supervised by the IAD and/or IAOC directly).)
>
><=
br>> _______________________________________________
> Ietf mailin=
g list

> Ietf@ietf.org
> https://www1.ietf.org/mail=
man/listinfo/ietf




**********************************=
************

The IPv6 Portal: http://www.ipv6tf.or=
g

Barcelona 2005 Global IPv6 Summit
Slides available at:
<=
a href=3D"http://www.ipv6-es.com">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@shockey.us>
Subject: Re: I-D
    &=
nbsp;   ACTION:draft-palet-ietf-meeting-venue-selection-crit=
eria-04.txt
To: jordi.pale=
t@consulintel.es
Cc: "
ietf@ietf.org" <ietf@ietf.org<=
/a>>
Message-ID: <4=
3D05AB5.4090009@shockey.us>
Content-Type: text/plain; charset=3DI=
SO-8859-1; format=3Dflowed


J
>> I'm assuming this is going to be Informational only a=
nd as such not
>> formally binding on the IAOC on the Secretariat.=

>
> My personal view is that this should be an Informational d=
ocument, as a

> guideline of the selection criteria, as I already tried to describ=
e in the
> document.
>
> There should be no difference be=
tween this and any other IETF document, in
> that sense.

But t=
here are differences Informational is just that Informational and

as such not binding on the parties as would be the Charter of the IABIAOC, NOMCOM etc.

>
> My opinion is that the binding is n=
ot related to the document type, but to
> how we want to manage the m=
eetings the next years.

>
>
> Clearly, the old document that we have in the IETF=
 site is insufficient and
> the decision is so *subjective* (not accu=
sing to anyone, just a fact), that
> the situation is not fair neithe=
r acceptable.



My position is this A. if it an'nt broke dont fix it and I do n=
ot see
what is currently broken. B is is irrelevant whether the selectio=
n is
subjective or not. All selections of this type are ultimately

subjective. This class of IETF policy is the IMHO business of those to
w=
hom the NOMCOM has appointed to oversee such activity in this case the
I=
AOC.

If the IAOC wishes to develop a criterion for site selections a=
nd then

seek community support for such criterion then fine , that is the IETF<=
br>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 o=
f Management. The business of

IETF Management is to Manage so we can get on with our business which i=
s
Internet Standards.

>
> I've complained during years, =
and I guess that was the reason Brian
> Carpenter pointed to me sugge=
sting that I should write the document (not

> stating that Madrid should be the right venue), and I decided to t=
ake 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 i=
n
Portugal .. Oporto Lisbon come to mind.  Now I can see some =
objections
to Ibiza. That might be a stretch...but at least once???
<=
br>IMHO Brian Carpenter was seriously wrong in suggesting that an

individual member of the community attempt to create such a policy
d=
ocument especially since we have just gone through a brutal process to
s=
et up a brand new management oversight committee to ultimately preform

such functions, the IAOC.

Please dont get my wrong. You have obvious=
ly put much work into this and
we should all be grateful for such contri=
butions to the community. I
just dont think it was necessary right now a=
nd even if there was a

general consensus that it was necessary this is the proper task of the<=
br>IAOC.

Brian should have known better.


>> In fact=
 that should be made explicit that nothing in this document
>> sho=
uld 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 docum=
ent. As
> said is only a guideline, but it must be followed in an obj=
ective 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. B=
ut they
> need community driven guidelines to be able to follow as mu=
ch 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<=
br>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 sa=
id, I don't recall having heard comments from your side on
> the docu=
ment 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
&g=
t; constructive by commenting what exactly you dislike and even propose
=
> specific text. I'm sure everyone will be happy to consider all the inp=
uts.

>
>

I have commented on the document.

I dont thi=
nk 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 IET=
F
administrative structure is very new and some what fragile and we shou=
ld
not for the time being impose unwanted solutions on them they did not

solicit support for.

--


 >>>>>>>=
>>>>>>>>>>>>>>>>>>>=
;>>>>>>>>>>>>>>>>>>&g=
t;>>>>>>>>

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.46000 Center Oak Plaza  -   Sterling, VA  2=
0166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.comENUM +87810-13313-31331
PSTN Office +1=20
571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mai=
lto:richard(at)shockey.us> or
<mail=
to:richard.shockey(at)neustar.biz>=
;

<http://www.neustar.biz> ;=
 <http://www.enum.org>
<<=
;<<<<<<<<<<<<<<<<<<&l=
t;<<<<<<<<<<<<<<<<<<&=
lt;<<<<<<<<<<<<<




------------------------------

Message: 5
Date: F=
ri, 20 Jan 2006 04:54:59 +0100
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>

Subject: Re: I-D
        ACTION:=
draft-palet-ietf-meeting-venue-selection-criteria-04.txt
To: "ietf@ietf.org" <ietf@ietf.org>
Message-ID: <
BFF61DA3.1527=
5E%jordi.palet@consulintel.es>
Content-Type: text/plain; &nb=
sp;     charset=3D"US-ASCII"

Hi Richar=
d,

Just a short answer to avoid a long discussion on each of your re=
plies ...


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 wil=
l be a decision

at the end, and that imply certain degree of subjectivity, but a criter=
ia
helps to make it as much objective and fair as possible).

Reme=
mber 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 p=
oint
to know if they can actually be a candidate venue or not.

Re=
gards,
Jordi




> De: Richard Shockey <
richard@shockey.us>
> Responder a: <ietf-bounces@ietf.org>
> Fecha: Thu, 19 Jan =
2006 22:36:21 -0500
> Para: <
jordi.palet@consulintel.es>
> CC: "ietf@ietf.org" <iet=
f@ietf.org>
> Asunto: Re: I-D
> ACTION:draft-palet-ietf-=
meeting-venue-selection-criteria-04.txt

>
> J
>>> I'm assuming this is going to be Informa=
tional only and as such not
>>> formally binding on the IAOC on=
 the Secretariat.
>>
>> My personal view is that this sho=
uld be an Informational document, as a

>> guideline of the selection criteria, as I already tried to des=
cribe 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 Infor=
mational and
> as such not binding on the parties as would be the Cha=
rter of the IAB
> IAOC, NOMCOM etc.
>
>>
>> M=
y 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.
>
><=
br>> My position is this A. if it an'nt broke dont fix it and I do not s=
ee
> what is currently broken. B is is irrelevant whether the selecti=
on is

> subjective or not. All selections of this type are ultimately
&=
gt; subjective. This class of IETF policy is the IMHO business of those to<=
br>> whom the NOMCOM has appointed to oversee such activity in this case=
 the

> IAOC.
>
> If the IAOC wishes to develop a criterion fo=
r site selections and then
> seek community support for such criterio=
n then fine , that is the IETF
> way as I have come to understand it.

>
> We appoint leadership for a reason ..to lead and make deci=
sions. 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 appoi=
nt to
> make such decisions.
>
> In shorter words I belie=
ve 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 complaine=
d 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 a=
nywhere in Spain is the right venue for _anything_
> :-) IMHO!!! I pe=
rsonally would not have any objection to having all
> future IETF mee=
tings in Spain. Well maybe alternate the fall meetings in

> Portugal .. Oporto Lisbon come to mind.  Now I can see s=
ome objections
> to Ibiza. That might be a stretch...but at least onc=
e???
>
> 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 proce=
ss to
> set up a brand new management oversight committee to ultimate=
ly preform

> such functions, the IAOC.
>
> Please dont get my wrong=
. You have obviously put much work into this and
> we should all be g=
rateful 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.
><=
br>>
>>> In fact that should be made explicit that nothing i=
n this document

>>> should be considered formally binding on the IAOC or the S=
ecretariat and
>>> that it only represents "useful suggest=
ions".
>>
>> I think that's precisely against the or=
iginal target of the document. As

>> said is only a guideline, but it must be followed in an object=
ive way.
>
> NO on that I do disagree. That is why if this docu=
ment is to become a
> RFC and I believe that it should not, it must b=
e 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 comm=
unity 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 st=
ruggle to get where we are at right now. Again if the

> IAOC wishes to consider such criterion then your draft is better e=
dited
> there then presented to the community.
>
>
>=
;> Now, all that said, I don't recall having heard comments from your si=
de on

>> the document during all the process in any of the previous ver=
sions. It will
>> be very helpful that you provide them now, but p=
lease, try to be
>> constructive by commenting what exactly you di=
slike and even propose

>> specific text. I'm sure everyone will be happy to consider all=
 the inputs.
>>
>>
>
> I have commented on th=
e document.
>
> I dont think it should exist and certainly not =
as a BCP or Standards

> Track RFC.
>
> 1. Venue Selection Criterion is best le=
ft 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, Direc=
tor - Member of Technical Staff

> NeuStar Inc.
> 46000 Center Oak Plaza  - &nbs=
p; Sterling, VA  20166
> sip:rshockey(at)iptel.org &nb=
sp; sip:57141(at)fwd.pulver.com
> ENUM +87810-13313-31331
> PST=
N Office +1 571.434.5651 PSTN Mobile +1=20
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>
> <<&l=
t;<<<<<<<<<<<<<<<<<<&=
lt;<<<<<<<<<<<<<<<<<<=
<<<<<<<<<<<<<

>
> _______________________________________________
> Ie=
tf mailing list
> Ietf@ietf.org<=
br>> https://www=
1.ietf.org/mailman/listinfo/ietf





**********************************************
T=
he 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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


End of Ietf Di=
gest, Vol 21, Issue 74
************************************





-- 
Thanking you,
Neil Harwani,
BE=
 (Civil)
L D College of Engineering, Ahmedabad
MCA
ICFAI School of=
 Information Technology,
Hyderabad

------=_Part_4862_1599103.1137759202714--


--===============1257507273==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1257507273==--




From ietf-bounces@ietf.org Fri Jan 20 12:06:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezzi8-00061u-8s; Fri, 20 Jan 2006 12:06:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezxhp-0006oj-Lh; Fri, 20 Jan 2006 09:57:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19130;
	Fri, 20 Jan 2006 09:56:10 -0500 (EST)
Received: from zen.org ([69.55.232.50] helo=mail.zen.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ezxqa-0006zd-B8; Fri, 20 Jan 2006 10:06:40 -0500
Received: from localhost (zen.org [127.0.0.1])
	by mail.zen.org (Postfix) with ESMTP id 1773826C0E8;
	Fri, 20 Jan 2006 06:57:36 -0800 (PST)
Received: from mail.zen.org ([127.0.0.1])
	by localhost (zen.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 15179-03; Fri, 20 Jan 2006 06:57:31 -0800 (PST)
Received: from [192.168.1.101] (user-162.wfd84b.dsl.pol.co.uk [84.71.144.162])
	by mail.zen.org (Postfix) with ESMTP id E08F126C0E4;
	Fri, 20 Jan 2006 06:57:29 -0800 (PST)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <000e01c61d6b$9f3eb170$0623520a@charger>
References: <000e01c61d6b$9f3eb170$0623520a@charger>
Date: Fri, 20 Jan 2006 14:57:34 +0000
To: ietf@ietf.org, iesg@ietf.org
From: Michael Everson 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at localhost
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
X-Mailman-Approved-At: Fri, 20 Jan 2006 12:05:55 -0500
Cc: Doug Ewell , John Cowan ,
	Harald Alvestrand 
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>From: Sam Hartman [mailto:hartmans-ietf@mit.edu]
>
>This is why I chose to give the necessary time to common sense to prevail,
>in exposing their mistakes in a way they could forced to correct some of
>them. The democratic method for that is work and filibustering.
>Filibustering is not pleasant. But it permitted to obtain what users'
>protection demanded:

Excuse me? I am the IETF Language Tags reviewer, and the list in 
question for discussion of RFC 3066 is there, basically, for *me*. 
People propose tags, there is some discussion, and we process or 
reject the proposals.

This is NOT the United States Senate and House of Representatives. 
You may think that filibustering is normal and appreciated and 
democratic. It is not. Morfin offers us nothing but bollocks, and it 
interferes with me and my work and I have on more than one occasion 
thought about resigning because of Morfin's poisonousness.

Now stop and think. I'm an expert professional with some reputation 
who has earned a certain amount of respect for my expertise. I am 
busy, too busy for bullshit, but happy enough to try to do a good job 
on for instance RFC 3066.

So who do you want to be nice to? Hm? Whom are the rules protecting? 
What is your goal?

>As such, I agree that we need to adopt a strategy that prevents Jefsey from
>disrupting our processes excessively.

Ban him.

>I'd first ask why repeated 30-day suspensions are ineffective.

Because every time the 30 days is up this crap starts all over and I 
have to waste time writing an e-mail to Harald saying "Ban him." I 
am, you will note, wasting time now dealing with Morfin, because I 
have to write to you about it.

>How would a six month suspension be insufficient?  Do we really need 
>an unlimited suspension to get work done?

It would make me happier. You may not care about that.

>Finally, if we somehow all convince ourselves that asking chairs to revisit
>suspending Jefsey every six months is unacceptable then what about creating
>way to suspend Jefsey from langtags related issues but not other IETF lists?

Whatever it takes.
-- 
Michael Everson * http://www.evertype.com

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 12:06:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezzi9-00062L-FK; Fri, 20 Jan 2006 12:06:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyCK-0000kU-QK
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 10:29:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21581
	for ; Fri, 20 Jan 2006 10:27:41 -0500 (EST)
Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyL2-00082a-KI
	for ietf@ietf.org; Fri, 20 Jan 2006 10:38:12 -0500
Received: from karoshi.com (localhost.localdomain [127.0.0.1])
	by karoshi.com (8.12.8/8.12.8) with ESMTP id k0KFSbIV002203;
	Fri, 20 Jan 2006 15:28:37 GMT
Received: (from bmanning@localhost)
	by karoshi.com (8.12.8/8.12.8/Submit) id k0KFSaDc002202;
	Fri, 20 Jan 2006 15:28:36 GMT
Date: Fri, 20 Jan 2006 15:28:36 +0000
From: bmanning@vacation.karoshi.com
To: JORDI PALET MARTINEZ 
Message-ID: <20060120152836.GA2173@vacation.karoshi.com.>
References: <43D05AB5.4090009@shockey.us>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
X-Mailman-Approved-At: Fri, 20 Jan 2006 12:05:55 -0500
Cc: "ietf@ietf.org" 
Subject: Re: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> 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).
> 
> Regards,
> Jordi
> 

	having hosted an IETF, i'll make the comment that i -really- wanted a
document like this as a "handbook" of things to expect.  But that was back in the
day...  I wrote up some notes and passed them on to the next local host.  a few 
mtgs later, Mark Prior ran into some of the same concerns when he hosted an IETF.
and so a few of us who -had- hosted IETF mtgs got together and wrote up an ID on
hosting requirements.  That draft went 'round the IESG a couple times and then died
a quiet death.   And rightly so.  Such a document is not w/in the IETF remit of defining
Internet Protocols.   So i really understand why you too, would like to see something
like this be in the IETF archives.... but it is NOT in the remit of the IETF as I understand
it.  However, the IETF of today is clearly NOT the IETF i spent time with, so things
could have changed.

--bill

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 12:27:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F003I-0002JF-IG; Fri, 20 Jan 2006 12:27:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F003F-0002Iy-Pt; Fri, 20 Jan 2006 12:27:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03052;
	Fri, 20 Jan 2006 12:26:25 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F00C1-0004Jx-Sd; Fri, 20 Jan 2006 12:36:58 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 0245525973A;
	Fri, 20 Jan 2006 18:26:37 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 23715-01; Fri, 20 Jan 2006 18:26:32 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 57DD2259739;
	Fri, 20 Jan 2006 18:26:32 +0100 (CET)
Date: Fri, 20 Jan 2006 18:27:38 +0100
From: Harald Tveit Alvestrand 
To: Sam Hartman 
Message-ID: 
In-Reply-To: 
References: 
	
	
	
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit
Cc: Scott Hollenbeck , ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam,

let me put it this way:

Changing the rules in the middle of the process is Just Plain Stupid. We've 
done that too many times to count.

We can return to our experience with the process once this round is over, 
and may choose to revisit the set of options we have and see if we can add 
some - but I think it's totally inappropriate to invent new options in the 
middle of a discussion about a specific action.

Nevertheless, I'll respond to some of your specific points....

--On fredag, januar 20, 2006 11:34:35 -0500 Sam Hartman 
 wrote:

>     Harald> This is a waste of time, resources and the goodwill of the
>     Harald> people who contribute constructively.
>
> OK.
>
> Now I'm sure we all agree that it is worth some frustration for
> openness.
>
> I'd appreciate it if you'd help me try and find the appropriate level
> of frustration.

For me personally, that level was passed after reading approximately 300 
Jefsey Morfin postings and finding no way to have a dialogue with him.

My Jefsey collection is now up to 900 posts since the start of 2005.

> Would six month suspensions instead of 30 day suspensions give you
> enough time during a suspension to avoid driving people away and to
> make it likely that you would not be too frustrated to run the lists?

Maybe. But what benefit comes to the IETF from that change?

> What about suspending Jefsey from just the ietf-langugages list and
> possibly the ltru list?
> Would that be a reasonable compromise?

My answer: No.

> If not, why not?

Jefsey has shown no tendency to change his ways. He's posted on 
ietf-languages, ltru, the IETF list, the IDN list, the pesci-discuss list 
and the architecture-discuss list. He claims to have been a low-layer 
network engineer; there's no telling where he'll choose to turn up next.

When he turns up, and behaves as he's always done, we've got two 
possibilities:

- The process has to be followed. Private warning, public warning, short 
suspension, 30-day suspension, appeal for PR-action to the IESG, IESG 
decision-making, suspension. We're talking about 6 months between the time 
*everyone* realizes that he's disruptive and the time he's actually 
suspended for any long period.

- The PR-action is present, global, and can be referred to. The listadmin 
realizes that Jefsey is being disruptive, and suspends him.

Now which of these two processes results in the volunteers who run mailing 
lists and working groups being less frustrated and having more energy to 
give to the IETF's real work?

I realized this a bit after replying to your previous message: The idea 
that a PR-action will result in Jefsey being banned from input to the IETF 
process, and the IETF process missing useful input as a result, had a 
hidden assumption: That listadmins would suspend Jefsey in a situation 
where he had useful input to give.

If Jefsey were to change his ways, and contribute in ways that were useful 
and non-disruptive, I'm pretty sure listadmins would let him go on posting, 
even though the PR-action is in effect. Why turn away useful input?

But I don't see why we should have to go through this painful process for 
every single list that is being affected by the same individual.

> I do realize that some have questioned whether the IESG has the
> authority to make such a narrowly scoped suspension.
>
> It is very clear that the community could choose to grant the IESG
> this authority in the form of a BCP.  I can make some arguments about
> why the IESG has the authority today, although I would describe them
> as stretches.

I would, too.






_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 12:38:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F00DT-0007lg-A4; Fri, 20 Jan 2006 12:38:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F00DR-0007jK-AT; Fri, 20 Jan 2006 12:38:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03953;
	Fri, 20 Jan 2006 12:36:56 -0500 (EST)
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F00M9-0004gX-DZ; Fri, 20 Jan 2006 12:47:29 -0500
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:58477)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1F00DD-0002qw-37 (Exim 4.54)
	(return-path ); Fri, 20 Jan 2006 17:38:11 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1F00DD-0005yO-U0 (Exim 4.53)
	(return-path ); Fri, 20 Jan 2006 17:38:11 +0000
Date: Fri, 20 Jan 2006 17:38:11 +0000
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Sam Hartman 
In-Reply-To: 
Message-ID: 
References: 
	
	
	
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Fri, 20 Jan 2006, Sam Hartman wrote:
>
> What about suspending Jefsey from just the ietf-langugages list and
> possibly the ltru list?

Isn't that what the last call says? It allows other list mangers
to ban him too, but doesn't require it.

Tony.
-- 
f.a.n.finch    http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 12:51:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F00Pc-0004pt-4h; Fri, 20 Jan 2006 12:51:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F00PZ-0004po-1z
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 12:50:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04907
	for ; Fri, 20 Jan 2006 12:49:28 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00YK-00055j-5U
	for ietf@ietf.org; Fri, 20 Jan 2006 13:00:01 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0KHod6t033079
	for ; Fri, 20 Jan 2006 18:50:39 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Fri, 20 Jan 2006 18:50:39 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <249503655.20060120185039@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D1109D.3060700@dcrocker.net>
References: 
	 <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
	<43D1109D.3060700@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574
Content-Transfer-Encoding: 7bit
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Are people on this list still arguing about this?  I thought members
of this list were supposed to be grown-ups (?).


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 13:25:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F00xE-0001IH-KD; Fri, 20 Jan 2006 13:25:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F00xB-0001I0-St; Fri, 20 Jan 2006 13:25:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07972;
	Fri, 20 Jan 2006 13:24:13 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F015x-0006Nm-Nu; Fri, 20 Jan 2006 13:34:47 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 38EDEE0074; Fri, 20 Jan 2006 13:25:35 -0500 (EST)
To: Tony Finch 
References: 
	
	
	
	
From: Sam Hartman 
Date: Fri, 20 Jan 2006 13:25:35 -0500
In-Reply-To:  (Tony
	Finch's message of "Fri, 20 Jan 2006 17:38:11 +0000")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Tony" == Tony Finch  writes:

    Tony> On Fri, 20 Jan 2006, Sam Hartman wrote:
    >>  What about suspending Jefsey from just the ietf-langugages
    >> list and possibly the ltru list?

    Tony> Isn't that what the last call says? It allows other list
    Tony> mangers to ban him too, but doesn't require it.

It does not have any additional checks on the actions of these list
maintainers.  In effect, it places Jefsey in a category where he can
be silenced by the sole discretion of any IETF list manager without
the sort of process review we've had here.

It's my claim that his actions on ietf-languages are unacceptable, but
that his actions on ietf, pesci-discuss and some other lists seem more
desirable than removing him from these lists.

So, I believe that giving managers of those lists the discretion to
ban Jefsey is an inappropriate restriction on the openness of our
process.

As such I believe it is appropriate and necessary to either use
existing processes or to create a new process that would allow us to
make reasonable restrictions.  I believe it is inappropriate for us to
use the tools we have if doing so would create an unfair or closed
process--even if they are the only tools we have.  I will expand more
on this last point in a response to Harald.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 13:26:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F00xv-0001Un-8Y; Fri, 20 Jan 2006 13:26:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F00xt-0001Ua-1n; Fri, 20 Jan 2006 13:26:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07994;
	Fri, 20 Jan 2006 13:24:56 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F016e-0006OM-RS; Fri, 20 Jan 2006 13:35:30 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-3.cisco.com with ESMTP; 20 Jan 2006 10:26:15 -0800
X-IronPort-AV: i="4.01,206,1136188800"; 
	d="scan'208"; a="394292618:sNHT32135400"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0KIQEQi009065;
	Fri, 20 Jan 2006 10:26:14 -0800 (PST)
Received: from [212.254.247.5] (ams-clip-vpn-dhcp4348.cisco.com [10.61.80.251])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0KIUtFL026950;
	Fri, 20 Jan 2006 10:30:56 -0800
Message-ID: <43D12B43.7070509@cisco.com>
Date: Fri, 20 Jan 2006 19:26:11 +0100
From: Eliot Lear 
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Margaret Wasserman 
References: <010201c61db9$95069670$0402a8c0@instant802.com>
In-Reply-To: <010201c61db9$95069670$0402a8c0@instant802.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1;  q=dns; l=599; t=1137781857; x=1138214057;
	c=nowsp; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; 
	d=cisco.com; i=lear@cisco.com; 
	z=Subject:Re=3A=20IETF=20Last=20Call=20under=20RFC=203683=20concerning=20JFC=20(Je
	fsey)=20Morfin| From:Eliot=20Lear=20|
	Date:Fri,=2020=20Jan=202006=2019=3A26=3A11=20+0100|
	Content-Type:text/plain=3B=20charset=3DISO-2022-JP|
	Content-Transfer-Encoding:7bit;
	b=hQdYLdvrBFqjNTsYJQ+1gB0Oa7dWqr9x/ZTNkQkFYGDU+RtSkdvG0+hB9mgCvtcobwc6pl3e
	jAz021pmb0X1XSMrUum3ubZDHBRHonF1jtQs9nHi3cjEM26Fvf/NWfcGVoOxyYvhZQp5TtuFf6n
	/J+/RTCy46T9Bx5WcOANsdS4=
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com;
	dkim=pass ( message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: 'Harald Tveit Alvestrand' ,
	'Scott Hollenbeck' ,
	'Sam Hartman' , ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Margaret,

RFC 3683 gives you broad discretion on the basis to make a decision, and
gives WG chairs broad discretion on what actions they should take. As
you had a hand in it, perhaps you can refresh my memory, but as I recall
that's all by design. This is not a really freedom of speech exercise,
but a discussion about utility to the standards development process
itself. I hope you would make your decision based on that. I have no
beef with JFC, but that's the equation I would recommend. I'd be less
cavalier were the consequences for JFC greater. It's not like if he
really wanted to try again he couldn't reach the decision makers and try
to make nice. I think the going rate for a Google or Y! account is still 0.

Regards,

Eliot

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 13:34:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0166-0003fa-Iu; Fri, 20 Jan 2006 13:34:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0165-0003es-2W
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 13:34:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08703
	for ; Fri, 20 Jan 2006 13:33:26 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F01Es-0006hc-2H
	for ietf@ietf.org; Fri, 20 Jan 2006 13:43:58 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 43E49E0074; Fri, 20 Jan 2006 13:34:47 -0500 (EST)
To: ietf@ietf.org
References: 
	 <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
	<43D1109D.3060700@dcrocker.net>
	<249503655.20060120185039@atkielski.com>
From: Sam Hartman 
Date: Fri, 20 Jan 2006 13:34:47 -0500
In-Reply-To: <249503655.20060120185039@atkielski.com> (Anthony G.
	Atkielski's message of "Fri, 20 Jan 2006 18:50:39 +0100")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Anthony" == Anthony G Atkielski  writes:

    Anthony> Are people on this list still arguing about this?  I
    Anthony> thought members of this list were supposed to be
    Anthony> grown-ups (?).

actually, we've just started arguing about it.

All the previous arguments were This is the last call.  There was a
lot of previous discussion about this issue, but I would not assume
that the IESG members will go wade through all of that.  I doubt I
will and I'm probably one of the more willing to spend a lot of time
digging through long mailing list discussions.

So, if you commented on this issue before the last call started, I'd
recommend sending a summary of your position possibly with pointers to
the last call thread.  I suspect only comments entered during the last
call will be considered.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 13:49:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F01Kc-0001uq-40; Fri, 20 Jan 2006 13:49:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F01KZ-0001uO-II; Fri, 20 Jan 2006 13:49:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09799;
	Fri, 20 Jan 2006 13:48:24 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F01TM-0007Co-I8; Fri, 20 Jan 2006 13:58:56 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 3E86DE0074; Fri, 20 Jan 2006 13:49:49 -0500 (EST)
To: John C Klensin 
References: 
	 <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
From: Sam Hartman 
Date: Fri, 20 Jan 2006 13:49:49 -0500
In-Reply-To: <6B00F5E2964A4A00C0C1323C@p3.JCK.COM> (John C. Klensin's
	message of "Thu, 19 Jan 2006 22:25:43 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: Scott Hollenbeck , ietf@ietf.org, iesg@ietf.org
Subject: Does the IESG have the authority to do less than 3683?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "John" == John C Klensin  writes:

    John> For whatever it is worth, I want to remind the IESG that,
    John> before there was RFC 3683, there was a notion, not only of
    John> 30 day suspensions, but of exponential (or other rapidly
    John> increasing series) back-off.  If someone is being severely
    John> disruptive on a particular list, it would seem reasonable to
    John> me for the relevant AD to authorize a 60 day suspension if a
    John> 30 day one is ineffective, a 120 day suspension if that is
    John> ineffective, and so on.  The nature of that arithmetic is
    John> such that someone could, with sufficient repeated disruptive
    John> behavior, find themselves rather effectively banned for the
    John> effective duration of a WG.  If the IESG believes that a
    John> formal RFC3933 experiment is needed to do that, then let's
    John> write down and run that experiment.  But, until we have
    John> tried the above --and any other plausible actions we can
    John> think of-- let's save the 3683 actions for those whose
    John> behavior is more clearly inappropriate and non-constructive
    John> than Jefsey's.


Hi, John.  The prevailing view on the IESG seems to be that the
combination of RFC 3683 and 3934 actually took away our ability to
approve suspensions greater than 30 days but short of a PR action.
Others seem to believe that while we might want to fix that, we should
deal with this matter first.

can you see a reading of 2418 as amended, 3934 and 3683 together that
give the IESG the power to approve a longer suspension?

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 14:05:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F01ZQ-0007qX-Ov; Fri, 20 Jan 2006 14:05:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F01ZO-0007qQ-AT
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 14:05:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10926
	for ; Fri, 20 Jan 2006 14:03:43 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F01i6-0007hE-OA
	for ietf@ietf.org; Fri, 20 Jan 2006 14:14:15 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F01Z1-0002nM-6p
	for ietf@ietf.org; Fri, 20 Jan 2006 20:04:47 +0100
Received: from 1cust96.tnt6.hbg2.deu.da.uu.net ([149.225.18.96])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Fri, 20 Jan 2006 20:04:47 +0100
Received: from nobody by 1cust96.tnt6.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Fri, 20 Jan 2006 20:04:47 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Fri, 20 Jan 2006 20:03:55 +0100
Organization: 
Lines: 20
Message-ID: <43D1341B.784B@xyzzy.claranet.de>
References: <000e01c61d6b$9f3eb170$0623520a@charger>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust96.tnt6.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Michael Everson wrote:
 
>> From: Sam Hartman [mailto:hartmans-ietf@mit.edu]

>> This is why I chose to give the necessary time to common
>> sense to prevail,
[...]

JFTR, that was in Sam's article where he _quoted_ Jefsey...
 
> Excuse me?

...I guess you missed the quoting, the source is published
in   

Unrelated, I'm not sure why it was published _there_ , the
IAB has its own directory for appeals.

                          Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 14:09:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F01dW-0000nt-PJ; Fri, 20 Jan 2006 14:09:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F01dV-0000nc-AK; Fri, 20 Jan 2006 14:09:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11282;
	Fri, 20 Jan 2006 14:07:58 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F01mG-0007qu-87; Fri, 20 Jan 2006 14:18:30 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0KJ97nA017432; Fri, 20 Jan 2006 14:09:07 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16540; 
	Fri, 20 Jan 2006 14:08:22 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Fri, 20 Jan 2006 14:08:21 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88634E@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Scott Hollenbeck'" , iesg@ietf.org
Date: Fri, 20 Jan 2006 14:08:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc: ietf@ietf.org, ietf-announce@ietf.org
Subject: RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In my opinion, this action is not appropriate in this case.

--
Eric 

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Scott Hollenbeck
--> Sent: Wednesday, January 18, 2006 7:35 AM
--> To: ietf@ietf.org; ietf-announce@ietf.org
--> Cc: iesg@ietf.org
--> Subject: IETF Last Call under RFC 3683 concerning JFC 
--> (Jefsey) Morfin
--> 
--> The IESG has received a request from Harald Alvestrand to 
--> approve an RFC
--> 3683 PR-action  ("posting rights" action) for JFC (Jefsey) 
--> Morfin as a
--> result of a pattern of prior warning and posting rights 
--> suspensions for
--> off-topic postings to the LTRU working group and 
--> ietf-languages mailing
--> lists that have not produced a change in behavior.  This 
--> behavior has been
--> characterized as a "denial-of-service" attack to disrupt the
--> consensus-driven process as described in Section 1 of RFC 
--> 3683.  A timeline
--> of warnings and posting rights suspensions related to this 
--> request is
--> included below.
--> 
--> The IESG will consider this request.  If approved, the 
--> PR-action described
--> in Section 2 of RFC 3683 includes provisions to allow list 
--> administrators to
--> suspend Mr. Morfin's posting rights to the LTRU working group and
--> ietf-languages mailing list for at least one year.  
--> Maintainers of other
--> IETF mailing lists may also remove posting rights to their 
--> mailing lists at
--> their discretion.
--> 
--> The IESG plans to make a decision in the next few weeks, 
--> and solicits final
--> comments on this action.  Please send any comments to the 
--> iesg@ietf.org or
--> ietf@ietf.org mailing lists by 17 February 2006.
--> 
--> For the IESG,
--> Scott Hollenbeck
--> Applications Area Director
--> --------------------------
--> 
--> Private warnings sent for LTRU working group mailing list postings:
--> 7 July 2005
--> 16 July 2005
--> 23 September 2005
--> 26 October 2005
--> 
--> Public warnings and suspensions for LTRU working group and 
--> ietf-languages
--> mailing list postings:
--> 
--> 17 March 2005 (ietf-languages warning)
--> http://www.alvestrand.no/pipermail/ietf-languages/2005-March
--> /003236.html
--> 
--> 5 April 2005 (LTRU warning)
--> http://www1.ietf.org/mail-archive/web/ltru/current/msg00564.html
--> 
--> 12 May 2005 (LTRU suspension)
--> http://www1.ietf.org/mail-archive/web/ltru/current/msg01737.html
--> 
--> 26 May 2005 (LTRU warning)
--> http://www1.ietf.org/mail-archive/web/ltru/current/msg01897.html
--> (Used as basis for 4 July suspension.)
--> 
--> 15 June 2005 (ietf-languages suspension)
--> http://www.alvestrand.no/pipermail/ietf-languages/2005-June/
--> 003474.html
--> 
--> 4 July 2005 (LTRU suspension)
--> http://www1.ietf.org/mail-archive/web/ltru/current/msg02532.html
--> (Appealed to AD, appeal upheld, new warning given.)
--> 
--> 5 July 2005 (LTRU warning)
--> http://www1.ietf.org/mail-archive/web/ltru/current/msg02548.html
--> 
--> 15 September 2005 (ietf-languages suspension)
--> http://www.alvestrand.no/pipermail/ietf-languages/2005-Septe
--> mber/003585.html
--> 
--> 26 September 2005 (LTRU warning)
--> http://www1.ietf.org/mail-archive/web/ltru/current/msg03755.html
--> 
--> 7 October 2005
--> PR-Action request sent to IESG
--> http://www1.ietf.org/mail-archive/web/ietf/current/msg38183.html
--> 
--> 15 October 2005 (LTRU warning)
--> http://www1.ietf.org/mail-archive/web/ltru/current/msg03941.html
--> 
--> 8 November 2005 (LTRU suspension)
--> http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html
--> (Appealed to AD, appeal denied by AD.)
--> 
--> 20 November 2005 (ietf-languages suspension)
--> http://www.alvestrand.no/pipermail/ietf-languages/2005-Novem
--> ber/003811.html
--> (Appealed to AD/IESG, appeal denied by IESG, appealed to the IAB.)
--> 
--> 13 January 2006 (ietf-languages suspension)
--> http://www.alvestrand.no/pipermail/ietf-languages/2006-Janua
--> ry/003854.html
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 14:41:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F028t-00042N-Ub; Fri, 20 Jan 2006 14:41:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F028r-000414-32
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 14:41:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13796
	for ; Fri, 20 Jan 2006 14:40:22 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02Hd-0000Rv-EL
	for ietf@ietf.org; Fri, 20 Jan 2006 14:50:54 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F028B-0003bB-8P
	for ietf@ietf.org; Fri, 20 Jan 2006 20:41:07 +0100
Received: from 1cust17.tnt7.hbg2.deu.da.uu.net ([149.225.100.17])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Fri, 20 Jan 2006 20:41:07 +0100
Received: from nobody by 1cust17.tnt7.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Fri, 20 Jan 2006 20:41:07 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Fri, 20 Jan 2006 20:39:42 +0100
Organization: 
Lines: 16
Message-ID: <43D13C7D.223F@xyzzy.claranet.de>
References: 
	 <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
	<43D1109D.3060700@dcrocker.net>
	<249503655.20060120185039@atkielski.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust17.tnt7.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Subject: Re: IETF Last Call under RFC 3683 [...]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam Hartman wrote:

> I'd recommend sending a summary of your position possibly
> with pointers to the last call thread.  I suspect only
> comments entered during the last call will be considered.

One older pointer wrt RfC 3683 is


This proposal was to update 3934, maybe obsolete 3683.  The
hypothetical 3934bis should be for all "official" IETF lists
incl. the review lists, maybe also for IRTF lists or anybody
else who wants to adopt this procedure.
 
                             Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 15:52:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F03FU-00043O-DJ; Fri, 20 Jan 2006 15:52:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F03FS-00043J-DV
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 15:52:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18290
	for ; Fri, 20 Jan 2006 15:51:15 -0500 (EST)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F03OF-0002aX-88
	for ietf@ietf.org; Fri, 20 Jan 2006 16:01:48 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170])
	by minbar.fac.cs.cmu.edu id aa24572; 20 Jan 2006 15:51 EST
Date: Fri, 20 Jan 2006 15:51:58 -0500
From: Jeffrey Hutzelman 
To: Brian E Carpenter , Tim Chown 
Message-ID: 
In-Reply-To: <43D0EE7E.1050409@zurich.ibm.com>
References: 
	<43D0C93F.5010306@zurich.ibm.com>
	<20060120113450.GM9015@login.ecs.soton.ac.uk>
	<43D0EE7E.1050409@zurich.ibm.com>
Originator-Info: login-token=Mulberry:01yJ5oozIG3RcU6eAk+xyYEl8Qn85P0uE1E5YI/h4=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion 
Subject: Re: hotels for Dallas?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Friday, January 20, 2006 03:06:54 PM +0100 Brian E Carpenter 
 wrote:

> Tim Chown wrote:
>> On Fri, Jan 20, 2006 at 12:27:59PM +0100, Brian E Carpenter wrote:
>>
>>> Registration for Dallas is in the final test stage, with a new system
>>> for credit card processing, and we want it to be rock solid.
>>> Should be open *really* soon now.
>>
>>
>> And the hotel info?
>
> The hotel blocks won't be affected by the late start to registration.
> Sorry about this but these things are rather bound together.

I'm afraid I don't follow this.

We understand that the new registration system is taking time to get 
working, and I doubt that's a big problem for many people.  But as of this 
writing, there is no information on the IETF web site about the meeting 
venue or hotels.  Any idea when that will change?

-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 16:04:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F03Ql-0006vz-NM; Fri, 20 Jan 2006 16:04:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F03Qj-0006vF-PU; Fri, 20 Jan 2006 16:04:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20533;
	Fri, 20 Jan 2006 16:02:53 -0500 (EST)
Received: from [204.9.221.21] (helo=thingmagic.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F03ZQ-0003Pu-NH; Fri, 20 Jan 2006 16:13:27 -0500
Received: from [66.30.121.250] (account margaret HELO ceili)
	by thingmagic.com (CommuniGate Pro SMTP 5.0.1)
	with ESMTPSA id 698274; Fri, 20 Jan 2006 16:04:04 -0500
From: "Margaret Wasserman" 
To: "'Eliot Lear'" 
Date: Fri, 20 Jan 2006 16:04:03 -0500
Message-ID: <023e01c61e05$0be032b0$0402a8c0@instant802.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcYd78XTXmhv74a5RQiklE91yl4zmwAE4ofw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
In-Reply-To: <43D12B43.7070509@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: 'Harald Tveit Alvestrand' ,
	'Scott Hollenbeck' , ietf@ietf.org, iesg@ietf.org
Subject: RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

 
Hi Eliot,

> RFC 3683 gives you broad discretion on the basis to make a 
> decision, and gives WG chairs broad discretion on what 
> actions they should take. As you had a hand in it, perhaps 
> you can refresh my memory,

Just for the record...  I was not involved in the publication of RFC 3683.  

I wrote RFC 3934/BCP 94.  That's the one that allows WG chairs to suspend
posting priveleges on WG mailing lists for up to 30 days.  Prior to that
RFC, only the full IESG could suspend anyone's posting priveleges, even
temporarily.

Margaret



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 16:14:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F03aP-0002Au-IQ; Fri, 20 Jan 2006 16:14:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F03aM-0002AN-BT
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 16:14:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23091
	for ; Fri, 20 Jan 2006 16:12:50 -0500 (EST)
Received: from stratton-two-twenty-three.mit.edu ([18.187.5.223]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F03j9-0004Ol-JS
	for ietf@ietf.org; Fri, 20 Jan 2006 16:23:24 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id AD2D9E0074; Fri, 20 Jan 2006 16:14:10 -0500 (EST)
To: Frank Ellermann 
References: <000e01c61d6b$9f3eb170$0623520a@charger>
	
	<43D1341B.784B@xyzzy.claranet.de>
From: Sam Hartman 
Date: Fri, 20 Jan 2006 16:14:10 -0500
In-Reply-To: <43D1341B.784B@xyzzy.claranet.de> (Frank Ellermann's message of
	"Fri, 20 Jan 2006 20:03:55 +0100")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: ietf@ietf.org
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Frank" == Frank Ellermann  writes:

    Frank> Unrelated, I'm not sure why it was published _there_ , the
    Frank> IAB has its own directory for appeals.

It's an appeal to the IESG.

Jefsey's been a bit active in the appeal front lately:

1) He appealed a typo correction in RFC 3066bis to the area director.  

2) He appealed the rejection in 1 above to the IESG.

3) He appealed his posting suspension from ietf-languages to the area
    director, but the area director believed the IESG as a whole
    needed to rule so we did.

4) He appealed 3 above to the IAB.

5)He appealed the approval of RFC3066bis to the IESG. That appeal is ongoing.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 16:11:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F03Xu-0000pv-LQ; Fri, 20 Jan 2006 16:11:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F03Xs-0000pi-8h
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 16:11:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22168
	for ; Fri, 20 Jan 2006 16:10:16 -0500 (EST)
Received: from monster.hopcount.ca ([199.212.90.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F03gf-00041z-F9
	for ietf@ietf.org; Fri, 20 Jan 2006 16:20:50 -0500
Received: from octopus.hopcount.ca ([199.212.90.5])
	by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.60 (FreeBSD)) (envelope-from )
	id 1F03XM-00006D-PL; Fri, 20 Jan 2006 21:11:13 +0000
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550922BE6B@nl0006exch001u.nl.lucent.com>
References: <7D5D48D2CAA3D84C813F5B154F43B1550922BE6B@nl0006exch001u.nl.lucent.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: quoted-printable
From: Joe Abley 
Date: Fri, 20 Jan 2006 16:11:11 -0500
To: "Wijnen, Bert (Bert)" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: Re: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-
	04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On 20-Jan-2006, at 11:55, Wijnen, Bert (Bert) wrote:

> Well said Barry!
>
>> From: Barry Leiba
>>
>> My biggest concern is in sections "2.3.  Freedom of Participation"
>> and "2.5.  Attendance Limitation and Visas", in that I'm not sure
>> how realistic they are.  Without getting overly into politics (let's
>> please not), I think they reflect a somewhat na=EFve view of some of
>> the political realities.  Specifically...
>>
>>     Meetings should not be held in countries where some
>> attendees could
>>     be disallowed entry or where freedom of speech is not
>> guaranteed for
>>     all participants.

Indeed. Applied with vigour, this restriction implies that no country =20=

is suitable to meet in. That leaves us with parts of Antarctica, a =20
floating venue located in international waters, or zero-g bar BOFs in =20=

outer space. I favour the latter.

A slightly more realistic approach might be to hold meetings =20
regularly in different countries with (ideally) divergent security/=20
immigration policies, in the hope that successive meetings might at =20
least exclude different sets of people.


Joe


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 16:11:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F03XJ-0000fq-H9; Fri, 20 Jan 2006 16:11:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F03XG-0000fW-QW; Fri, 20 Jan 2006 16:11:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22111;
	Fri, 20 Jan 2006 16:09:39 -0500 (EST)
Received: from stratton-two-twenty-three.mit.edu ([18.187.5.223]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F03g4-00041b-0X; Fri, 20 Jan 2006 16:20:13 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id E58F2E0074; Fri, 20 Jan 2006 16:10:51 -0500 (EST)
To: "JFC (Jefsey) Morfin" 
References: 
	
	<6.2.3.4.2.20060120112906.0547e7d0@mail.jefsey.com>
From: Sam Hartman 
Date: Fri, 20 Jan 2006 16:10:51 -0500
In-Reply-To: <6.2.3.4.2.20060120112906.0547e7d0@mail.jefsey.com> (JFC
	Morfin's message of "Fri, 20 Jan 2006 11:59:00 +0100")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: ietf@ietf.org, iesg@ietf.org
Subject: WG links to positions
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "JFC" == JFC (Jefsey) Morfin  writes:

    JFC> 3. I proposed an evolution in the WG working method. In using
    JFC> position links: every contributor expresses his positions on
    JFC> a page he can update as the debate goes. I proposed this to
    JFC> the GNSO WG-Review which supported it and I use it in some
    JFC> work. This filters out "standard" participants' blabla. It
    JFC> permits everyone to stay, every concept to be documented and
    JFC> progressively trimmed, and external experts to call
    JFC> in. Consensus is when all the positions are equivalent or
    JFC> have identified they cannot agree. Consensus review is easy
    JFC> and informative.

    JFC> This was not considered.

Actually I think this is one of the better ideas you've come up with.

I think it needs a lot of work, but I do hope that as we look at WG
tools we have ways to track issues raised by individuals etc.

I'm not sure that the details of where the web pages matter.
I think the important abilities are to be able to answer questions like:

* Is Sam still upset?

* How many people just don't care about this?

* How many people want some solution but don't care about what it is.

    JFC> 4. I have engaged an IESG, and now an IAB appeal, to know if
    JFC> this kind of debate is, or not, part of the IETF. IESG said
    JFC> "no". 

Actually, that isn't really what we said although I do agree that you
probably read our response that way.


We said that the type of debate you're looking for should not take
place on the ietf-languages list.


We did not answer your question of where the debate should take place.

I had intended to write you an individual message giving some
suggestions for where the debate should take place.


Personally I think that your questions about the scope of the IETF,
the scope of ietf language tags and the general approach to
internationalization and multi-lingual issues currently belong on the
ietf@ietf.org list, not on the ietf-languages lists.

However, while I think it is reasonable for you to try and build a
consensus to support your decision you need to stop sending messages
if it becomes clear that you are not convincing people that you are
right.  Our process needs to give you an opportunity to try and
convince people that you are right.  However if you fail to do so, we
cannot allow you to bring things to a grinding halt.

So, bring up any new issue you like on the ietf@ietf.org list; please
be as constructive as you can be.  Let the discussion die out if it is
clear you aren't convincing people.  Respect any warning you see from
the sargents at arms or Brian.  If you fail to respect susch warnings
don't be surprised if your ietf@ietf.org posting rights are suspended.
Again, you may engage us in debate, but you should not be allowed to
stop our work.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 16:35:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F03v8-0005fk-0Q; Fri, 20 Jan 2006 16:35:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F03v0-0005cF-Nc
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 16:35:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00746
	for ; Fri, 20 Jan 2006 16:34:11 -0500 (EST)
Received: from smtp116.iad.emailsrvr.com ([207.97.245.116]
	helo=smtp136.iad.emailsrvr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F043m-0007DV-3q
	for ietf@ietf.org; Fri, 20 Jan 2006 16:44:45 -0500
Received: from [192.168.2.5] (69-170-29-227.chvlva.adelphia.net
	[69.170.29.227]) (Authenticated sender: rpelletier@isoc.org)
	by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id 8FBD444C00D; 
	Fri, 20 Jan 2006 16:35:23 -0500 (EST)
Message-ID: <43D15848.6020408@isoc.org>
Date: Fri, 20 Jan 2006 16:38:16 -0500
From: Ray Pelletier 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeffrey Hutzelman 
References: 	<43D0C93F.5010306@zurich.ibm.com>	<20060120113450.GM9015@login.ecs.soton.ac.uk>	<43D0EE7E.1050409@zurich.ibm.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: OK
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: Tim Chown , IETF Discussion 
Subject: Re: hotels for Dallas?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



Jeffrey Hutzelman wrote:

>
>
> On Friday, January 20, 2006 03:06:54 PM +0100 Brian E Carpenter 
>  wrote:
>
>> Tim Chown wrote:
>>
>>> On Fri, Jan 20, 2006 at 12:27:59PM +0100, Brian E Carpenter wrote:
>>>
>>>> Registration for Dallas is in the final test stage, with a new system
>>>> for credit card processing, and we want it to be rock solid.
>>>> Should be open *really* soon now.
>>>
>>>
>>>
>>> And the hotel info?
>>
>>
>> The hotel blocks won't be affected by the late start to registration.
>> Sorry about this but these things are rather bound together.
>
>
> I'm afraid I don't follow this.
>
> We understand that the new registration system is taking time to get 
> working, and I doubt that's a big problem for many people.  But as of 
> this writing, there is no information on the IETF web site about the 
> meeting venue or hotels.  Any idea when that will change?
>
> -- Jeff

I expect it to change Monday 23 January.
Ray Pelletier
IETF Administrative Director

>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 17:09:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F04Rl-00019d-1g; Fri, 20 Jan 2006 17:09:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F04Ri-00019Y-Rz
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 17:09:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05528
	for ; Fri, 20 Jan 2006 17:07:58 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F04aW-0000lF-Ph
	for ietf@ietf.org; Fri, 20 Jan 2006 17:18:33 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F04RI-0004lV-7e
	for ietf@ietf.org; Fri, 20 Jan 2006 23:09:00 +0100
Received: from 1cust17.tnt7.hbg2.deu.da.uu.net ([149.225.100.17])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Fri, 20 Jan 2006 23:09:00 +0100
Received: from nobody by 1cust17.tnt7.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Fri, 20 Jan 2006 23:09:00 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Fri, 20 Jan 2006 23:07:53 +0100
Organization: 
Lines: 14
Message-ID: <43D15F39.7DAB@xyzzy.claranet.de>
References: <000e01c61d6b$9f3eb170$0623520a@charger>
	
	<43D1341B.784B@xyzzy.claranet.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust17.tnt7.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam Hartman wrote:
 
> 1) He appealed a typo correction in RFC 3066bis to the area
>    director.
> 2) He appealed the rejection in 1 above to the IESG.

Yes, so far I was on track, but I lost it at...
 
> 5) He appealed the approval of RFC3066bis to the IESG. That
>    appeal is ongoing.

...thinking that 5 is the IAB level related to 1+2.  But it's
the "real" appeal against the approval at the IESG level.  Bye



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 17:20:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F04cC-0004Ye-RV; Fri, 20 Jan 2006 17:20:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F04cA-0004YN-I8
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 17:20:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06142
	for ; Fri, 20 Jan 2006 17:18:46 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F04ky-00012z-A5
	for ietf@ietf.org; Fri, 20 Jan 2006 17:29:21 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0KMK4nA023164; Fri, 20 Jan 2006 17:20:04 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA14534; 
	Fri, 20 Jan 2006 17:20:03 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Fri, 20 Jan 2006 17:20:03 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886356@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Sam Hartman'" 
Date: Fri, 20 Jan 2006 17:20:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: ietf@ietf.org
Subject: RE: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Mor
	fin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam,

	Clearly we should be thinking about some way to "charge" 
participants for potentially abusing the IETF appeals process
in general.  There is some minimal processing time associated
with any appeal for everyone who has anything to do with it.

	I don't think posting rights is the way to do this.  For
one thing, it is obvious that this too can be appealed.

	Perhaps the appeal process should require that a token 
cash amount must be deposited with some ISOC general fund - 
with the provision that the deposit would be reimbursed if 
the appeal is found to have merit?

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Sam Hartman
--> Sent: Friday, January 20, 2006 4:14 PM
--> To: Frank Ellermann
--> Cc: ietf@ietf.org
--> Subject: Re: FW: IETF Last Call under RFC 3683 concerning 
--> JFC (Jefsey) Morfin
--> 
--> >>>>> "Frank" == Frank Ellermann  writes:
--> 
-->     Frank> Unrelated, I'm not sure why it was published 
--> _there_ , the
-->     Frank> IAB has its own directory for appeals.
--> 
--> It's an appeal to the IESG.
--> 
--> Jefsey's been a bit active in the appeal front lately:
--> 
--> 1) He appealed a typo correction in RFC 3066bis to the area 
--> director.  
--> 
--> 2) He appealed the rejection in 1 above to the IESG.
--> 
--> 3) He appealed his posting suspension from ietf-languages 
--> to the area
-->     director, but the area director believed the IESG as a whole
-->     needed to rule so we did.
--> 
--> 4) He appealed 3 above to the IAB.
--> 
--> 5)He appealed the approval of RFC3066bis to the IESG. That 
--> appeal is ongoing.
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 17:47:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F052c-00008L-7A; Fri, 20 Jan 2006 17:47:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F052a-000087-KU; Fri, 20 Jan 2006 17:47:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08740;
	Fri, 20 Jan 2006 17:46:04 -0500 (EST)
Received: from stratton-two-twenty-three.mit.edu ([18.187.5.223]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F05BP-00029i-KQ; Fri, 20 Jan 2006 17:56:39 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 5987CE0053; Fri, 20 Jan 2006 17:47:21 -0500 (EST)
To: ietf@ietf.org, iesg@ietf.org
References: 
	 <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
	<43D1109D.3060700@dcrocker.net>
	<249503655.20060120185039@atkielski.com> 
	<43D13C7D.223F@xyzzy.claranet.de>
From: Sam Hartman 
Date: Fri, 20 Jan 2006 17:47:21 -0500
In-Reply-To: <43D13C7D.223F@xyzzy.claranet.de> (Frank Ellermann's message of
	"Fri, 20 Jan 2006 20:39:42 +0100")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: 
Subject: An Experiment in IETF Mailing List Management
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Frank" == Frank Ellermann  writes:

    Frank> One older pointer wrt RfC 3683 is
    Frank> 

    Frank> This proposal was to update 3934, maybe obsolete 3683.  The
    Frank> hypothetical 3934bis should be for all "official" IETF
    Frank> lists incl. the review lists, maybe also for IRTF lists or
    Frank> anybody else who wants to adopt this procedure.


I'm not sure that we can get consensus on this specific direction to
changes in our mailing list procedures.  I hope that we can get
consensus on an experiment for mailing list management.  I've prepared
a draft under RFC 3933 that hopes to accomplish this.  The draft can
be found at
http://www.meepzorp.org/~hartmans/draft-hartmans-mailinglist-experiment.txt
.  I include the meat of the draft below.

If a number of people support this draft I'll submit it and ask Brian
to consider it as an RFC 3933 experiment.

   As discussed in RFC 3683, the IETF  needs to have rules of conduct to
   limit disruptive or abusive behavior while permitting fair and open
   forum for the discussion of Internet standardization.  The IETF has a
   long and complicated history of rules for managing conduct on its
   mailing lists.

   RFC 2418 [RFC2418] permitted individuals to be blocked from posting
   to a mailing list: "As a last resort and after explicit warnings, the
   Area Director, with the approval of the IESG, may request that the
   mailing list maintainer block the ability of the offending individual
   to post to the mailing list."  RFC 2418 also allowed other forms of
   mailing list control to be applied with the approval of the area
   director and IESG.  However RFC 2418 only applies to working group
   mailing lists.

   The IETF discussion list charter [RFC3005] provides guidelines for
   ietf@ietf.org.  These guidelines provide more flexibility than RFC
   2418. "   The IETF Chair, the IETF Executive Director, or a sergeant-
   at-arms appointed by the Chair is empowered to restrict posting by a
   person, or of a thread, when the content is inappropriate and
   represents a pattern of abuse.  They are encouraged to take into
   account the overall nature of the postings by an individual and
   whether particular postings are an aberration or typical.  Complaints
   regarding their decisions should be referred to the IAB. "  In
   particular it appears that these decisions do not follow the normal
   appeals path outlined in RFC 2026 [RFC2026].

   RFC 3683[RFC3683] provides  a procedure for banning named individuals
   from posting to an IETF mailing list for an indefinite period of
   time.  However once such a ban is put in place for one mailing list,
   the individuals responsible for other IETF mailing lists can
   unilaterally remove the posting rights of that individual.

   RFC 3934 [RFC3934] amends RFC 2418 and grants the working group chair
   the ability to suspend a member's posting rights for 30 days.
   However it appears to remove the ability of the AD and IESG to
   approve longer suspensions or alternative procedures: "Other methods
   of mailing list control, including longer suspensions, must be
   carried out in accordance with other IETF-approved procedures."  An
   argument could be made that the amendment was not intended to remove
   the already-approved procedures in RFC 2418 although a perhaps
   stronger argument can be made that the actual textual changes  have
   the effect of removing these procedures.

   While not strictly within the scope of RFC 3934, the IESG and mailing
   list managers have assumed that RFC 3934-like procedures can be


   applied to non-working-group mailing lists.

   The result of these guidelines is that there is a large gap between
   the levels of sanction that can be applied.  An individual can be
   suspended  from a list easily for 30 days.  However the only option
   available to the IESG that permits   a longer suspension for any list
   besides ietf@ietf.org is the ability to suspend an individual for an
   indefinite time period from one list.  This suspension can expand to
   any IETF list without community or IESG involvement.  This memo is an
   RFC 3933[RFC3933] experiment to provide the community with additional
   mechanisms to manage its mailing lists while the community decides
   what mailing list guidelines are appropriate.  IN particular this
   experiment creates a level of sanction between RFC 3934 and RFC 3683.
   The goal of this experiment is to improve the functioning of IETF
   mailing lists while keeping the process open and fair.



3.  The Experiment

   This experiment runs for a period of 18 months.  During the
   experiment period, the IESG MAY approve  other methods of mailing
   list control besides those outlined in RFC 3683 and RFC 3934 to be
   used on a specified set of IETF mailing lists.  Such methods include
   but are not limited to suspending the posting rights of an individual
   beyond  30 days on those lists.  The IESG may also delegate the
   authority to perform longer-term suspensions of specific individuals
   on specific mailing lists.  The procedures of this memo MUST NOT be
   used to suspend the posting rights of an individual beyond the period
   of the experiment.  The procedures of this memo MUST NOT be used to
   limit an individual's ability to read the contents of a mailing list.

   The IESG is encouraged to perform a community-wide last call when it
   is appropriate to do so both when evaluating a specific procedure to
   be applied and when considering the effects of applying that
   procedure to a specific instance of behavior.  The last call is not
   required however.  The reason that the last call is not required is
   that under RFC 2418, no last call is required; there seems to be no
   reason to have a procedure more strict than that proposed in RFC
   2418.

   If the IESG conducts an RFC 3683 last call and finds that sanction is
   too harsh, it is unlikely that an additional last call will be needed
   for applying a lesser sanction.

   Sanctions made under this memo may be appealed using the procedures
   outlined in  [RFC2026].

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 18:14:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F05Sj-00055V-AA; Fri, 20 Jan 2006 18:14:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F05Sh-000558-B4
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 18:14:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10742
	for ; Fri, 20 Jan 2006 18:13:03 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F05bU-00032M-H4
	for ietf@ietf.org; Fri, 20 Jan 2006 18:23:38 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LXZR542AM80036U7@mauve.mrochek.com> for
	ietf@ietf.org; Fri, 20 Jan 2006 15:14:12 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1137798853;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=T0J6Tq0jzwGyaKaRntNgUJc5i
	vvgkj7sQ7tWSK/rhH+TP00ziBWiyjrPQxl31jHu/9yKypLvRY2bozgkAPzVRg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LXZNHA4QWW00009C@mauve.mrochek.com>; Fri,
	20 Jan 2006 15:14:08 -0800 (PST)
To: Gray Eric 
Message-id: <01LXZR524CIG00009C@mauve.mrochek.com>
Date: Fri, 20 Jan 2006 14:31:39 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Fri, 20 Jan 2006 17:20:01 -0500"
	<313680C9A886D511A06000204840E1CF0C886356@whq-msgusr-02.pit.comms.marconi.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <313680C9A886D511A06000204840E1CF0C886356@whq-msgusr-02.pit.comms.marconi.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: 'Sam Hartman' , ietf@ietf.org
Subject: RE: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey)
	Mor	fin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Sam,

> 	Clearly we should be thinking about some way to "charge"
> participants for potentially abusing the IETF appeals process
> in general.  There is some minimal processing time associated
> with any appeal for everyone who has anything to do with it.

> 	I don't think posting rights is the way to do this.  For
> one thing, it is obvious that this too can be appealed.

> 	Perhaps the appeal process should require that a token
> cash amount must be deposited with some ISOC general fund -
> with the provision that the deposit would be reimbursed if
> the appeal is found to have merit?

I've been trying to stay out of this discussion, but I simply cannot let this
one pass.

Incentives of various sorts, including negative incentives like this, are
something economists have studied quite extensively. (*) What they've found is
that in many cases this backfires badly - imposing a fee results in much more
of the behavior you want to discourage, not less.

The problem seems to be that by assigning a price you're in effect saying "this
is how much an appeal costs, if you feel like spending this amount you should
feel free to appeal." It changes what should be an extraordinary and
exceptional event into an ordinary and normal one. And this will apply
regardless of the spin you put on the matter - money talks ... well, you know
the rest.

I'm pretty confident that we have enough people with sufficient disposable
income and strongly held feelings about something or other that this approach
would cause a lot of trouble. And no, I don't have an alternative to suggest,
other than to note that appeals are still pretty rare and I believe Mr. Morfin
is unique in having filed more than one, let alone five. In other words, I'm
not sure that aside from Mr. Morfin there's a real problem to be solved here.

				Ned

(*) I'm at work and don't have any books handy to cite, so I'm afraid I cannot
give any good references for work done in this area. Perhaps someone else can
oblige... However, the popular book "Freakonomics" discusses this issue, albeit
not in sufficient depth for my taste.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 18:56:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F067B-0004ki-QH; Fri, 20 Jan 2006 18:56:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0679-0004kI-WF; Fri, 20 Jan 2006 18:56:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13376;
	Fri, 20 Jan 2006 18:54:51 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F06Fw-0004DV-Sc; Fri, 20 Jan 2006 19:05:27 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F0673-0003qB-Er; Fri, 20 Jan 2006 15:56:14 -0800
Message-Id: <6.2.3.4.2.20060120231018.0481bdd0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Sat, 21 Jan 2006 00:55:50 +0100
To: Sam Hartman 
From: "JFC (Jefsey) Morfin" 
In-Reply-To: 
References: 
	
	<6.2.3.4.2.20060120112906.0547e7d0@mail.jefsey.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-3D732B1D
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: WG links to positions
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear Sam,
I go through your comment.

At 22:10 20/01/2006, Sam Hartman wrote:
> >>>>> "JFC" == JFC (Jefsey) Morfin  writes:
>
>     JFC> 3. I proposed an evolution in the WG working method. In using
>     JFC> position links: every contributor expresses his positions on
>     JFC> a page he can update as the debate goes. I proposed this to
>     JFC> the GNSO WG-Review which supported it and I use it in some
>     JFC> work. This filters out "standard" participants' blabla. It
>     JFC> permits everyone to stay, every concept to be documented and
>     JFC> progressively trimmed, and external experts to call
>     JFC> in. Consensus is when all the positions are equivalent or
>     JFC> have identified they cannot agree. Consensus review is easy
>     JFC> and informative.
>
>     JFC> This was not considered.
>
>Actually I think this is one of the better ideas you've come up with.
>I think it needs a lot of work, but I do hope that as we look at WG
>tools we have ways to track issues raised by individuals etc.

Not much actually as everyone knows to use a page. It can be a 
private WIKI, it can be a form (like the WGIG), etc. The only real 
thing is that people accept to be polite to speed up the process. 
This means that when they quote their page of a Draft they include 
the link, and that there is a WG menu page with the links of the 
people who want a link (only a few want one: everyone see if they are 
competent or a fool).

Then quickly there are positions on the matter at hand. The game is 
to cooperate to reach the same wording. Hence a consensus. You then 
understand that a consensus is not something you discuss, but you 
uncover in common. It had to be here before. You just discuss of the 
"if" to achieve before one can all agree. Nothing common with a 
compromise. Nor with a dominance.

>I'm not sure that the details of where the web pages matter.
>I think the important abilities are to be able to answer questions like:
>* Is Sam still upset?
>* How many people just don't care about this?
>* How many people want some solution but don't care about what it is.
>
>     JFC> 4. I have engaged an IESG, and now an IAB appeal, to know if
>     JFC> this kind of debate is, or not, part of the IETF. IESG said
>     JFC> "no".
>
>Actually, that isn't really what we said although I do agree that you
>probably read our response that way.
>We said that the type of debate you're looking for should not take
>place on the ietf-languages list.

This is why I asked the IAB.

>We did not answer your question of where the debate should take place.
>I had intended to write you an individual message giving some
>suggestions for where the debate should take place.
>
>Personally I think that your questions about the scope of the IETF,
>the scope of ietf language tags and the general approach to
>internationalization and multi-lingual issues currently belong on the
>ietf@ietf.org list, not on the ietf-languages lists.

This is why I asked the IESG. The IESG having not answered I asked the IAB.

>However, while I think it is reasonable for you to try and build a
>consensus to support your decision you need to stop sending messages
>if it becomes clear that you are not convincing people that you are
>right.  Our process needs to give you an opportunity to try and
>convince people that you are right.  However if you fail to do so, we
>cannot allow you to bring things to a grinding halt.

Here is where we misunderstand. I want to convince no one. I raise a 
question. I only want to know where these issues should be addressed 
in the opinion of the IETF consensus.

>So, bring up any new issue you like on the ietf@ietf.org list; please
>be as constructive as you can be.  Let the discussion die out if it is
>clear you aren't convincing people.  Respect any warning you see from
>the sargents at arms or Brian.  If you fail to respect susch warnings
>don't be surprised if your ietf@ietf.org posting rights are suspended.

I am not interested in bringing new issues to the IETF. I have 
shopping list for consensual recipes on the way to communicate 
through the digital ecosystem. And I make my own user QA.

There are existing entities. If some proposes a good recipe (in toto 
or in parte) and it is good quality, I am glad with it. There are two 
problems: when one is de facto exclusive and no good, or when there 
is none. Before building my own solution I want to check there is no 
other way.

>Again, you may engage us in debate, but you should not be allowed to 
>stop our work.

dear! I think you really missed what happened!!! You (IETF) stopped 
my work in wanting to get a technically absurd and messy exclusive in 
my area (multilingual registry systems R&D).

I never stopped your work! I carried it!  Against an affinity group 
only interested in pushing me and all the ohers out of the market 
through technical constraint. Do you _really_ think the Draft IESG 
refused in January (partly because of me) is the same as the one you 
approved in November?

When the WG started, I proposed we would wrapp the Draft quickly in 
working on the Draft together (I was the main opponent). We would 
have had a serious open IETF Draft in days. But the affinity group 
thought the WG-LTRU was only an administrative obligation to get 
their text approved! Harald has documented the number of posts I had 
to send to obtain the current ABNF and some wording, they are now so 
proud of. Read the debates and look at the changes I painstakingly 
obtained to prevent ABNF leaks and confusion. This is not perfect, 
hence the appeal. The need was not so much the Draft to go one way or 
another, but not to be confuse. I made them to clarify it against me.

This was dangerous for me and non-US industries. But Tunis has 
limited most of that danger, because the world consensus should 
consider RFC 3066 Bis as local to the Internationalised US Internet 
application. The need now is to keep its users compatible with us. We 
need interoperability and security. The ABNF does not include but now 
permits "language code interoperability" (by adding an RFC 4151 users 
space for example). The security considerations make the Draft 
dangerous. Hence the appeal. Hence the appeal agree or we will 
document it in real life.


The problem is that the IETF works by consensus but thinks by 
hummings. Working by consensus means that I MAY be right against 
_everyone_  (here an external affinity group in a new area). But the 
community has no mechanism to address that case. What to do if I am 
really right? To come with my supporters: this will start a war and 
will convince no one. I have the hummings but no consensus. Totally 
disruptive.

The only way I found is filibustering. Because this means only one 
expandable person, which will have to demonstrate his results. May be 
there is another one? Tell me.


IMHO In this case, the faulty party is the IESG. The IETF may need 
and create the ietf-languages@iana.org mailing list. But it has no 
capacity to run it, all the more as a private trick. Michael Everson 
cannot be an IETF person because we have no one else of similar level 
to check if he is right (look at his comment today). The "kitchen 
syndrome" with Harald, Mark Crispin etc. (this is all the year long) 
shows we have no reliable experts. The IETF is an engineering 
community, not a linguistic society.

ietf-languages@iana.org is to be made operational, controlled by the 
IANA, documented on the IANA site, experts from every languages would 
share in it, sponsored by their country, their academy, their 
community, the UNESCO, etc. They will probably elect Michael Everson 
as Chair. At the IANA. Not at the IETF nor Unicode. Please remember 
that they have now to document all the networked languages of the 
world and registered 72 exceptions in 10 years.

jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 19:01:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F06CR-0006Mo-PL; Fri, 20 Jan 2006 19:01:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F06CQ-0006Mj-0A
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 19:01:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13705
	for ; Fri, 20 Jan 2006 19:00:17 -0500 (EST)
From: Emmanuel.Desmet@alcatel.be
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F06LE-0004LS-8u
	for ietf@ietf.org; Fri, 20 Jan 2006 19:10:53 -0500
Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr
	[155.132.251.32])
	by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id
	k0L01VmX015408 for ; Sat, 21 Jan 2006 01:01:31 +0100
To: "ietf@ietf.org" 
Message-ID: 
Date: Sat, 21 Jan 2006 01:01:30 +0100
X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 01/21/2006 01:01:31
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Subject: Emmanuel DESMET/BE/ALCATEL is out of the office
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I will be out of the office starting  12/23/2005 and will not return until
02/01/2006.

@+ manu



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 19:01:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F06Ca-0006O1-Av; Fri, 20 Jan 2006 19:01:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F06CZ-0006Nw-3W
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 19:01:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13733
	for ; Fri, 20 Jan 2006 19:00:26 -0500 (EST)
From: Emmanuel.Desmet@alcatel.be
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F06LL-0004Lh-DK
	for ietf@ietf.org; Fri, 20 Jan 2006 19:10:59 -0500
Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr
	[155.132.251.32])
	by smail.alcatel.fr (8.13.4/8.13.4/Debian-3) with ESMTP id
	k0L01fDW015476 for ; Sat, 21 Jan 2006 01:01:41 +0100
To: ietf@ietf.org
Message-ID: 
Date: Sat, 21 Jan 2006 01:01:40 +0100
X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 01/21/2006 01:01:41
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Subject: Emmanuel DESMET/BE/ALCATEL is out of the office
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I will be out of the office starting  12/23/2005 and will not return until
02/01/2006.

@+ manu



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 19:06:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F06HS-000890-VL; Fri, 20 Jan 2006 19:06:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F06HQ-00088M-E2
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 19:06:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14146
	for ; Fri, 20 Jan 2006 19:05:27 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F06QF-0004Y3-Hu
	for ietf@ietf.org; Fri, 20 Jan 2006 19:16:04 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F06HC-00042o-Fo
	for ietf@ietf.org; Sat, 21 Jan 2006 01:06:42 +0100
Received: from 1cust17.tnt7.hbg2.deu.da.uu.net ([149.225.100.17])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Sat, 21 Jan 2006 01:06:42 +0100
Received: from nobody by 1cust17.tnt7.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Sat, 21 Jan 2006 01:06:42 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Sat, 21 Jan 2006 01:05:47 +0100
Organization: 
Lines: 28
Message-ID: <43D17ADB.2EBD@xyzzy.claranet.de>
References: 
	 <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
	<43D1109D.3060700@dcrocker.net>
	<249503655.20060120185039@atkielski.com> 
	<43D13C7D.223F@xyzzy.claranet.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust17.tnt7.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Subject: Re: An Experiment in IETF Mailing List Management
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam Hartman wrote:

> I've prepared a draft under RFC 3933 that hopes to accomplish
> this.  The draft can be found at

> http://www.meepzorp.org/~hartmans/draft-hartmans-mailinglist-experiment.txt

Sounds okay, maybe two nits:

 [quoting 3005]
> Complaints regarding their decisions should be referred to
> the IAB. "
 {unquote]
> In particular it appears that these decisions do not follow
> the normal appeals path outlined in RFC 2026 [RFC2026].

That might be a feature, can't have the Chair juggle with his
or her hats, getting in fights and conflicts of interest.  The
general area with its general list is a special case.

> This experiment runs for a period of 18 months.

Is that long enough ?  Maybe it won't be used in that time...
...checking, oh, 3933 says 12 months, so that's already longer.
Maybe it would be okay to repeat the experiment if the number
of observed usage cases is zero.
                                 Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 19:12:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F06N5-0004Jm-BE; Fri, 20 Jan 2006 19:12:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F06N3-0004Iy-8y; Fri, 20 Jan 2006 19:12:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14493;
	Fri, 20 Jan 2006 19:11:16 -0500 (EST)
Received: from stratton-two-twenty-three.mit.edu ([18.187.5.223]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F06Vq-0004hX-7V; Fri, 20 Jan 2006 19:21:53 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 896ECE0053; Fri, 20 Jan 2006 19:12:34 -0500 (EST)
To: "JFC (Jefsey) Morfin" 
References: 
	
	<6.2.3.4.2.20060120112906.0547e7d0@mail.jefsey.com>
	
	<6.2.3.4.2.20060120231018.0481bdd0@mail.jefsey.com>
From: Sam Hartman 
Date: Fri, 20 Jan 2006 19:12:34 -0500
In-Reply-To: <6.2.3.4.2.20060120231018.0481bdd0@mail.jefsey.com> (JFC
	Morfin's message of "Sat, 21 Jan 2006 00:55:50 +0100")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "JFC" == JFC (Jefsey) Morfin  writes:

    JFC> Dear Sam, I go through     JFC> The problem is that the IETF works by consensus but thinks by
    JFC> hummings. Working by consensus means that I MAY be right
    JFC> against _everyone_ (here an external affinity group in a new
    JFC> area). But the community has no mechanism to address that
    JFC> case. What to do if I am really right? 

The IETF actually works by rough consensus not consensus.  If you are
the only one who holds an opinion then by the decision making process
we as a community have chosen we will decide against you.

You have an opportunity to try and convince us you are right and we
are wrong.  But if you fail to do that we will move on without you.

If you attempt to stop us from moving on once we have listened to you
and determined the rough consensus is against you, then you will be
excluded.  I think we have decided as a community that filibustering
is not something we will tolerate.
So you should expect to be excluded from any forum where you filibuster.

--Sam

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 22:40:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F09cM-0003cb-Jd; Fri, 20 Jan 2006 22:40:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F09cK-0003bR-3K
	for ietf@megatron.ietf.org; Fri, 20 Jan 2006 22:40:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26262
	for ; Fri, 20 Jan 2006 22:39:16 -0500 (EST)
Received: from mercury.lcs.mit.edu ([18.26.0.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F09l8-0001Qz-IN
	for ietf@ietf.org; Fri, 20 Jan 2006 22:49:53 -0500
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178)
	id 46B4C872C6; Fri, 20 Jan 2006 22:40:31 -0500 (EST)
To: ietf@ietf.org
Message-Id: <20060121034031.46B4C872C6@mercury.lcs.mit.edu>
Date: Fri, 20 Jan 2006 22:40:31 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: jnc@mercury.lcs.mit.edu
Subject: RE: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Mor
	fin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

    > From: "Gray, Eric" 

    > Clearly we should be thinking about some way to "charge" participants
    > for potentially abusing the IETF appeals process in general. There is
    > some minimal processing time associated with any appeal for everyone
    > who has anything to do with it.

The legal system in several countries has the concept of a "vexatious
litigator" label, which, when applied to someone, means they are not allowed
to file a lawsuit without the approval of a some third party, generally a
judge.

I suggest the IESG/whomever take immediate steps to amend the appeals process
so that there is a suitable process by which someone who abuses the appeals
process by repeatedly filing pointless, unworthy appeals can be labelled a
"vexatious appellant", whereby they are barred from filing appeals unless
any such appeals are approved by some appropriate third party.

	Noel

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 20 23:30:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0AO9-0006DI-T5; Fri, 20 Jan 2006 23:30:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0AO8-0006D9-8c; Fri, 20 Jan 2006 23:30:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29174;
	Fri, 20 Jan 2006 23:28:40 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0AX0-0002k6-2Z; Fri, 20 Jan 2006 23:39:18 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F0ANq-0002kP-Lm; Fri, 20 Jan 2006 20:29:51 -0800
Message-Id: <6.2.3.4.2.20060121014207.04d45200@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Sat, 21 Jan 2006 01:50:58 +0100
To: Sam Hartman 
From: "JFC (Jefsey) Morfin" 
In-Reply-To: 
References: 
	
	<6.2.3.4.2.20060120112906.0547e7d0@mail.jefsey.com>
	
	<6.2.3.4.2.20060120231018.0481bdd0@mail.jefsey.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-24347F54
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.7 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: Consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear Sam,
I reviewed the meaning of "filibustering" in different dictionaries 
and wikipedia. I have to apologize to everyone. I took the word [from 
its origin - filibustero, flibustier, freebooter] in a totally 
confusing way. Actually, I see now that a "filibuster" is what Harald 
has now engaged the IETF/IESG into, to confuse the RFC 3066 bis 
appeal and the IAB appeal.

Stupid of mine. Now, I have a problem because I have no simple word 
to name my kind of action and describe my relentless diversified and 
pertinent ways to get delivered what I need, user's QA included, in 
the multilingualisation area, as described by the Tunis documents.

At 01:12 21/01/2006, Sam Hartman wrote:
> >>>>> "JFC" == JFC (Jefsey) Morfin  writes:
>
>     JFC> Dear Sam, I go through     JFC> The problem is that the 
> IETF works by consensus but thinks by
>     JFC> hummings. Working by consensus means that I MAY be right
>     JFC> against _everyone_ (here an external affinity group in a new
>     JFC> area). But the community has no mechanism to address that
>     JFC> case. What to do if I am really right?
>
>The IETF actually works by rough consensus not consensus.  If you are
>the only one who holds an opinion then by the decision making process
>we as a community have chosen we will decide against you.

Confusion is the problem. It makes difficult:
- sometime to understand the position of the community
- if a rough consensus has been really found.

WG consensus by exhaustion, IETF consensus by disinterest, IESG 
consensus by impossibility to know everything are not rough 
consensus. This is why appeals may be necessary for important issues.

BTW, you say "if you are the only one". How many should we be?

>You have an opportunity to try and convince us you are right and we
>are wrong.  But if you fail to do that we will move on without you.

Only God, true geeks and fools should try and convince.
I am interested in being convinced, possibly in informing.
And in obtaining the corresponding deliverables.
See below.

>If you attempt to stop us from moving on once we have listened to you
>and determined the rough consensus is against you, then you will be
>excluded.

I am a user: there cannot be a rough consensus against me. But there 
may be a rough consensus not to deliver what I need. Then I am just 
no more interested. We will only oppose if the IETF disloyaly 
interferes with others' deliverables (or mine's). What I thought impossible.

>I think we have decided as a community that filibustering
>is not something we will tolerate.

Agreed. Now, I understand. A PR-action is a good filibuster ... .

>So you should expect to be excluded from any forum where you filibuster.

Correct. But I never did. Except unwillingly when misunderstanding 
the filibustering concept. This may have confused some and made them 
and you waste time. I hate that. I apologize again.

But I would be pleased if someone could help with a proper better 
word. Since this community seems so much interested in reviving an 
issue I though closed.
jfc












_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 01:35:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0CLg-0002L9-GE; Sat, 21 Jan 2006 01:35:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0CLa-0002Ht-Bn; Sat, 21 Jan 2006 01:35:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05208;
	Sat, 21 Jan 2006 01:34:08 -0500 (EST)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0CQM-0005iU-2i; Sat, 21 Jan 2006 01:40:38 -0500
Received: from fe-amer-05.sun.com ([192.18.108.179])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k0L6VCuf001933; 
	Fri, 20 Jan 2006 23:31:13 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
	(Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
	id <0ITF00801J6VLI00@mail-amer.sun.com>
	(original mail from tbray@textuality.com); Fri,
	20 Jan 2006 23:31:11 -0700 (MST)
Received: from [192.168.1.41] ([216.113.201.196])
	by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built
	Sep 9
	2005)) with ESMTPSA id <0ITF000AFJFZ32W0@mail-amer.sun.com>; Fri,
	20 Jan 2006 23:31:11 -0700 (MST)
Date: Fri, 20 Jan 2006 22:31:11 -0800
From: Tim Bray 
In-reply-to: 
To: Scott Hollenbeck 
Message-id: <6AC50D28-E316-4FF1-89C1-BAAE4A7715D8@textuality.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.746.2)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7BIT
Cc: ietf@ietf.org, ietf-announce@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jan 18, 2006, at 4:34 AM, Scott Hollenbeck wrote:

> The IESG plans to make a decision in the next few weeks, and  
> solicits final
> comments on this action.  Please send any comments to the  
> iesg@ietf.org or
> ietf@ietf.org mailing lists by 17 February 2006.

Ban him.  Openness and inclusiveness are virtues, but not absolutes.  
This ban seems to me an expression of respect for the time and energy  
of many dedicated and talented participants here, which are currently  
being wasted by JFC; such respect is also a virtue and on balance in  
this case, a substantially greater one. -Tim



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 04:51:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0FPF-00066N-Iu; Sat, 21 Jan 2006 04:51:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0FPD-00066D-8F
	for ietf@megatron.ietf.org; Sat, 21 Jan 2006 04:51:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18929
	for ; Sat, 21 Jan 2006 04:50:07 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0FY6-0003GQ-Vz
	for ietf@ietf.org; Sat, 21 Jan 2006 05:00:48 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0L9pFap040162
	for ; Sat, 21 Jan 2006 10:51:15 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Sat, 21 Jan 2006 10:51:15 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <38575864.20060121105115@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <6AC50D28-E316-4FF1-89C1-BAAE4A7715D8@textuality.com>
References: 
	<6AC50D28-E316-4FF1-89C1-BAAE4A7715D8@textuality.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Tim Bray writes:

> Ban him.  Openness and inclusiveness are virtues, but not absolutes.

They are only virtues when they are absolute.

> This ban seems to me an expression of respect for the time and energy
> of many dedicated and talented participants here, which are currently
> being wasted by JFC; such respect is also a virtue and on balance in
> this case, a substantially greater one. -Tim

This entire fiasco tells me that the people nominally participating
in it have a lot of time on their hands and very little to do, and
they choose to waste it bickering like preschoolers on a playground
rather than spend it trying to do the actual work of the IETF.  And of
course they will argue with this, because they don't want to recognize
their own failings.

Instead of seeing a stream of posts from this target of opportunity, I
see multiple streams of posts from people complaining about him.
Sorry, but the "cure" is a lot worse than the "disease."


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 06:33:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0H0C-00070I-69; Sat, 21 Jan 2006 06:33:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0H0A-0006ye-12
	for ietf@megatron.ietf.org; Sat, 21 Jan 2006 06:33:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24038
	for ; Sat, 21 Jan 2006 06:32:21 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0H93-0005rR-Af
	for ietf@ietf.org; Sat, 21 Jan 2006 06:43:03 -0500
Received: (qmail invoked by alias); 21 Jan 2006 11:33:29 -0000
Received: from p54A7F2E6.dip.t-dialin.net (EHLO peter-dambier.de)
	[84.167.242.230]
	by mail.gmx.net (mp018) with SMTP; 21 Jan 2006 12:33:29 +0100
X-Authenticated: #8956597
Message-ID: <43D21C03.1000808@peter-dambier.de>
Date: Sat, 21 Jan 2006 12:33:23 +0100
From: Peter Dambier 
Organization: Peter and Karin Dambier
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: 	<6AC50D28-E316-4FF1-89C1-BAAE4A7715D8@textuality.com>
	<38575864.20060121105115@atkielski.com>
In-Reply-To: <38575864.20060121105115@atkielski.com>
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: peter@peter-dambier.de
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Anthony G. Atkielski wrote:
> 
> This entire fiasco tells me that the people nominally participating
> in it have a lot of time on their hands and very little to do, and
> they choose to waste it bickering like preschoolers on a playground
> rather than spend it trying to do the actual work of the IETF.  And of
> course they will argue with this, because they don't want to recognize
> their own failings.
> 
> Instead of seeing a stream of posts from this target of opportunity, I
> see multiple streams of posts from people complaining about him.
> Sorry, but the "cure" is a lot worse than the "disease."

I never complained. I respect Jefsey. Without him it does not make
sense to stay on this list. Without Jefsey you can read everything
in books. No need to reiterate it by bureaucrats.

On the other hand, if I had written this book I could understand
everybody trying to suppress new ideas to prevent anybody from writing
a new book that might replayece the old one :)

-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@peter-dambier.de
mail: peter@echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 07:08:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0HXG-0000tO-Dh; Sat, 21 Jan 2006 07:08:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0HXE-0000t1-Jb; Sat, 21 Jan 2006 07:08:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25726;
	Sat, 21 Jan 2006 07:06:31 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0Hg8-0006dl-Nw; Sat, 21 Jan 2006 07:17:15 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F0HX2-000238-Dy; Sat, 21 Jan 2006 04:07:48 -0800
Message-Id: <6.2.3.4.2.20060121110110.04b605a0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Sat, 21 Jan 2006 12:25:07 +0100
To: iesg@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <6.2.3.4.2.20060120112906.0547e7d0@mail.jefsey.com>
References: 
	
	<6.2.3.4.2.20060120112906.0547e7d0@mail.jefsey.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-551B6BD0
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: ietf@ietf.org
Subject: "Mr. Smith was in the IETF"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Yesterday I proposed to take advantage from my experience for the 
good of the IETF. I used "filibustering" as what I had been engaged 
into. This was a big Franglish confusion. I explained it and 
apologised for the inconvenience in a mail to Sam Hartmann. I asked 
help to find a correct term. I received a few supportive comments 
(and one BS but funny). I thank the formers, all the more than they 
were unexpected!

- thank you for confirming I am not "filibustering", but that Harald 
is (thanks for the examples). As someone put it "Mr. Smith was in the IETF".

- May be "smart activism" as someone else suggested is a good 
description? I do not like "e-guerillero", but sometimes .. "active 
influence" is also interesting?

- I am NOT engaged in any feud against Harald and will support NONE. 
I like this "Mr. Smith was in the IETF" quote, because Jefferson 
Smith was a dedicated person who tried, as I am sure Harald does. I 
do not oppose his analysis, but his lack of _deeper_ analysis and 
generalisation leading to layer violation and scaling inability. I 
also oppose a strategy of influence to force everyone into it. But, 
(a) his doctrine seems to root in RFC 2130 - recently confirmed by 
another IAB workshop on IDNs; (b) he was clear on his intents and got 
supported by the IESG (RFC 3935). There is NO ad hominem (at least on 
my side) but a fundamental architectural difference between 
unilaterally centralised and multilaterally distributed visions of 
the network interintelligibility. I note that in a comment Harald 
shown IMHO that we could totally agree. I accept I tease him: is that 
not the best answer to defamation and name-calling? Better than suing 
him! (The IESG/ISOC would be the one to sue for its drum justice).

- as an IETF _user_ my interest is in the quality and in the 
adequation of the IETF deliverables in my areas of interest and 
competence. I am ready to do and to accept much for good deliverables 
and for their source. I was removing myself from the IETF, now I am 
reasonably protected in my work from the RFC 3066 Bis initial 
confusion and the world is not bound to the IDNA error anymore. 
Unless an unexpected IAB positive response to my appeal, Harald's 
action is the only reason why I am still here. Those who dislike me 
can thank him!

As a general comment: from the mails I receive I am surprised that 
some IETF (often high level) participants do not dare to speak-up and 
_fear_ the IETF immanent "ruling powers" and the "community correct". 
Two want me as their "lighting rod" (first request of that kind was 
at the beginning of the RFC 3066 Bis saga), several others as a 
"fuse", even one as his "Robin Hood"! I do not think this is good. A 
PESCI priority? What is puzzling is when someone aggressively posts 
against me and then sends me a "targeted" long mail of support for 
everything and more .... or when another one mails me a broadside 
against what he wrote on the public list! The most concerning are the 
mails from low-grade-English foreign lurkers, who wishes I represent 
them ... and the quality of their online resumes. I am honored, but 
perplex at the correct solution to bring them. The ethic/user TF I 
plan will certainly be multilingual.

jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 12:26:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0MV2-0003bP-Mm; Sat, 21 Jan 2006 12:26:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0MUz-0003b5-Mm; Sat, 21 Jan 2006 12:26:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14513;
	Sat, 21 Jan 2006 12:24:33 -0500 (EST)
Received: from laweleka.osafoundation.org ([204.152.186.98])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0Mdt-0006zZ-K4; Sat, 21 Jan 2006 12:35:18 -0500
Received: from [192.168.1.100] (unknown [198.144.201.116])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id 4E80114226C;
	Sat, 21 Jan 2006 09:25:32 -0800 (PST)
In-Reply-To: 
References: <000e01c61d6b$9f3eb170$0623520a@charger>
	
Mime-Version: 1.0 (Apple Message framework v728)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <20C3D08D-C758-42C0-A867-1DB67056912C@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault 
Date: Sat, 21 Jan 2006 09:25:15 -0800
To: Michael Everson 
X-Mailer: Apple Mail (2.728)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: 7bit
Cc: Doug Ewell , John Cowan ,
	Harald Alvestrand , ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I second what Michael said.

It may be easy for somebody not involved to hit the delete key, and  
it's reasonable to ask "How hard is it to hit the delete key".  But  
for people doing the work, who have to worry about  whether to  
respond or not, whether keeping silent will give everybody else the  
wrong impression, whether this will derail the work again, and  
whether to just give up... it's quite hard to just hit the delete  
key.  Our passion for our work is a strength in some ways but the  
flip side is the risk of serious demoralization in this kind of  
situation.

I approve of this escalation and think we should not set the bar so  
high that no WG  or DL can ever successfully send the message that a  
PR-action sends.

Lisa Dusseault

On Jan 20, 2006, at 6:57 AM, Michael Everson wrote:

>> From: Sam Hartman [mailto:hartmans-ietf@mit.edu]
>>
>> This is why I chose to give the necessary time to common sense to  
>> prevail,
>> in exposing their mistakes in a way they could forced to correct  
>> some of
>> them. The democratic method for that is work and filibustering.
>> Filibustering is not pleasant. But it permitted to obtain what users'
>> protection demanded:
>>
>
> Excuse me? I am the IETF Language Tags reviewer, and the list in  
> question for discussion of RFC 3066 is there, basically, for *me*.  
> People propose tags, there is some discussion, and we process or  
> reject the proposals.
>
> This is NOT the United States Senate and House of Representatives.  
> You may think that filibustering is normal and appreciated and  
> democratic. It is not. Morfin offers us nothing but bollocks, and  
> it interferes with me and my work and I have on more than one  
> occasion thought about resigning because of Morfin's poisonousness.
>
> Now stop and think. I'm an expert professional with some reputation  
> who has earned a certain amount of respect for my expertise. I am  
> busy, too busy for bullshit, but happy enough to try to do a good  
> job on for instance RFC 3066.
>
> So who do you want to be nice to? Hm? Whom are the rules  
> protecting? What is your goal?
>
>
>> As such, I agree that we need to adopt a strategy that prevents  
>> Jefsey from
>> disrupting our processes excessively.
>>
>
> Ban him.
>
>
>> I'd first ask why repeated 30-day suspensions are ineffective.
>>
>
> Because every time the 30 days is up this crap starts all over and  
> I have to waste time writing an e-mail to Harald saying "Ban him."  
> I am, you will note, wasting time now dealing with Morfin, because  
> I have to write to you about it.
>
>
>> How would a six month suspension be insufficient?  Do we really  
>> need an unlimited suspension to get work done?
>>
>
> It would make me happier. You may not care about that.
>
>
>> Finally, if we somehow all convince ourselves that asking chairs  
>> to revisit
>> suspending Jefsey every six months is unacceptable then what about  
>> creating
>> way to suspend Jefsey from langtags related issues but not other  
>> IETF lists?
>>
>
> Whatever it takes.
> -- 
> Michael Everson * http://www.evertype.com
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 15:15:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0P8l-0005B2-Mn; Sat, 21 Jan 2006 15:15:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0P8j-00058k-PS
	for ietf@megatron.ietf.org; Sat, 21 Jan 2006 15:15:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22907
	for ; Sat, 21 Jan 2006 15:13:43 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0PHg-0002gU-R5
	for ietf@ietf.org; Sat, 21 Jan 2006 15:24:29 -0500
Received: (qmail 11320 invoked from network); 21 Jan 2006 20:14:55 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 21 Jan 2006 20:14:55 -0000
Date: 21 Jan 2006 20:14:59 -0000
Message-ID: <20060121201459.20625.qmail@simone.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: 
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: everson@evertype.com
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>This is NOT the United States Senate and House of Representatives.
>You may think that filibustering is normal and appreciated and
>democratic. It is not.

This is the core of the issue.  The point of this forum is to get work
done.  The rules for participation are not hard to figure out, and are
not hard to abide by.  You can be quite passionate and even fairly
obnoxious and not come anywhere close to the point where anyone would
suggest banning you.  This isn't an issue of free speech.  There are a
million places on the Net open to anyone who wants to say anything.
The issue is maintaining an environment where the vast majority of
members who want to get work done can do so.

I cannot tell you how many lists I've been on that have been in
exactly our situation, paralyzed by one or two people who skate along
the edge of being kicked off, choking the list with clouds of
irrelevant smoke.  There's always the same arguments, if we were
disciplined enough to ignore the noise, it wouldn't matter, everyone
has a right to say something, it's about personalities rather than
substance, etc., etc. You all know them as well as I do.

When this happens, I've only ever seen two possible outcomes.  Either
the smoke generators are ejected, or the productive members leave.

R's,
John

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 16:06:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0PwO-0003VO-Ks; Sat, 21 Jan 2006 16:06:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0PwM-0003Uh-Gy; Sat, 21 Jan 2006 16:06:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25320;
	Sat, 21 Jan 2006 16:05:02 -0500 (EST)
Received: from lizzard.sbs.de ([194.138.37.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0Q5M-00041e-6W; Sat, 21 Jan 2006 16:15:49 -0500
Received: from mail1.sbs.de (localhost [127.0.0.1])
	by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0LL6JLp027821;
	Sat, 21 Jan 2006 22:06:19 +0100
Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net
	[157.163.133.222])
	by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k0LL6JrJ029397;
	Sat, 21 Jan 2006 22:06:19 +0100
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by
	fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 21 Jan 2006 22:06:19 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 21 Jan 2006 22:03:11 +0100
Message-ID: 
Thread-Topic: Location Types Registry
Thread-Index: AcYezhZLupUGRcs8RrGQbpUCCNAQZQ==
From: "Tschofenig, Hannes" 
To: , , 
X-OriginalArrivalTime: 21 Jan 2006 21:06:19.0267 (UTC)
	FILETIME=[86585530:01C61ECE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: Location Types Registry
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi all,=20

The purpose of the document is to creates a registry for location types.
These values are used in  and
. The document can be used for RPID
 but this is not done today. As noted in
the review the xml schema in RPID as currently defined needs to be
modified to use the values in the registry. This is subject to a
discussion in the simple mailing list regarding the work on RPID.=20

I would like to address a few review comments:

- We don't need to describe the usage of location type values in the
"Location Types Registry" document. Other documents provide this
information already. As such, we do not need to consider the usage of
location type values in the "Location Types Registry" document with
respect to possible security considerations. The meaning of multiple
values or a sequence of values is not a topic for the registry.=20

- The values listed in the "Location Types Registry" document are not
displayed to the user. As such, we don't cover internationalization
support. =20

- The definition of the values and the selected location types is chosen
to the best of our knowledge. If there are better definitions please let
us know.=20

- Registration policy: We thought that FCFS would be an acceptable
policy. Some people had a different view about it. Fine. I have no
problems changing it to expert review.=20

- I am not sure it is a good idea to create a separate registry in the
dhcp-civic, in the radius-geopriv and the RPID draft in order to
associate the usage of the values defined in the registry with the
specific usage document.=20

I also saw some good comments about the IANA consideration section. We
will reflect these comments in the draft update.=20

Ciao
Hannes

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 16:09:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0Pzd-0003vb-56; Sat, 21 Jan 2006 16:09:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0Pza-0003uv-7G; Sat, 21 Jan 2006 16:09:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25552;
	Sat, 21 Jan 2006 16:08:22 -0500 (EST)
Received: from gecko.sbs.de ([194.138.37.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0Q8a-00047v-Qe; Sat, 21 Jan 2006 16:19:09 -0500
Received: from mail2.sbs.de (localhost [127.0.0.1])
	by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0LL6LHG012454;
	Sat, 21 Jan 2006 22:06:21 +0100
Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net
	[157.163.133.222])
	by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0LL6KEI011140;
	Sat, 21 Jan 2006 22:06:20 +0100
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by
	fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 21 Jan 2006 22:06:20 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 21 Jan 2006 22:06:19 +0100
Message-ID: 
Thread-Topic: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed
	Standard
Thread-Index: AcYdT8ZxT1h3B3ErRPWnQfwiVNVntwBe+gmA
From: "Tschofenig, Hannes" 
To: "Sam Hartman" ,
	"Henning Schulzrinne" 
X-OriginalArrivalTime: 21 Jan 2006 21:06:20.0251 (UTC)
	FILETIME=[86EE7AB0:01C61ECE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Content-Transfer-Encoding: quoted-printable
Cc: geopriv@ietf.org, Harald Tveit Alvestrand ,
	iesg@ietf.org, ietf@ietf.org
Subject: AW: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed
	Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Sam,=20

please find some feedback below:=20

> >>>>> "Henning" =3D=3D Henning Schulzrinne  =
writes:
>=20
>     >>  2) Inadequate context for use:
>     >>=20
>     >> The document does not make reference to RPID, except in
>     >> "acknowledgement". Thus, it has to be interpreted as
>     >> stand-alone, and must contain its own guidance. RPID states:
>     >>=20
>     >>=20
>     >>=20
>     >> These things guide the usage of place-types in RPID, but cannot
>     >> be found from the registry document.
>     >>=20
>=20
>     Henning> Since usage will strongly depend on the context and since
>     Henning> this registry is not limited to RPID, I think this would
>     Henning> belong into RPID (or other documents), not the registry.
>=20
>     >> This document SHOULD give guidance for usage, saying at least:
>     >>=20
>     >> - whether it's intended that several of these values can be
>     >> used together
>=20
>     Henning> I'd assume yes, in general, but defining that seems to be
>     Henning> the role of the protocol using these elements, not a
>     Henning> registry.
>=20
>     Henning> I think of the registry like a dictionary. A dictionary
>     Henning> does not define which words you can use together.
>=20
>=20
> Here I think is the crux of the problem.  The IETF and IANA should not
> be in the business of creating dictionaries.

There are documents that use a location type. We can give an initial
list of values but we cannot be exhaustive.=20
Do you have a better suggestion for extending these values?=20

>=20
> The document under discussion creates a named set of place
> descriptions.
>=20
> There is no guidance given on how this information should be used,

This information is provided in other documents (RADIUS-Geopriv and
DHCP-CIVIC). We can add references to these documents.=20


> why
> you would want this registry=20

To provide a mechanism for extending the currently defined list of
values.=20

> or what constraints should be placed on
> it.

We have received some feedback about these constraints and we will put
them into the IANA consideration section (as suggested). Documents that
use the values in the registry provide additional constraints.=20


>=20
> That's a big problem.  First, there are likely to be concerns that
> matter to almost all uses of the registry.  It's desirable to require
> using applications to consider these concerns and probably even to
> describe how they handle the concerns.
>=20
>=20
> Another reason not giving guidance is problematic has to do with
> different assumptions about how the registry is used.  Some
> applications may assume that there will be a small number of entries
> in the registry.  That's fine until someone comes along and say
> registers all the different major food chains with presence in more
> than one country.

With the suggested change to expert review for enhancing or updating the
values in the registry this aspect seems to be covered.=20

>=20
> One application may assume that location is single valued; another may
> have multi-valued location.  These applications will expect different
> things from the registry.

There is no problem about this aspect.=20

>=20
> Even when we've tried to have guidance for registries we've run into
> problems.  Witness the recent debate about whether RTP and MIME should
> use the same media type registry.
>=20
> As such, with my AD hat off, I do not support publication of an RFC
> that establishes a dictionary for place names I would probably support
> publication of an RFC that established a well-coped place name
> registry for some purpose.  I'd want to limit the size of the registry
> for localization reasons.

I would like to make sure that I properly understand you.
It would be OK for you if we copy-and-paste the document into RPID,
RADIUS-Geopriv, DHCP-CIVIC (instead of referencing it) and create a
separate registry for each of these documents.

Ciao
Hannes

>=20
> --Sam
>=20
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 16:48:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0QbS-0008Tz-TO; Sat, 21 Jan 2006 16:48:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0QbQ-0008Sk-5o
	for ietf@megatron.ietf.org; Sat, 21 Jan 2006 16:48:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27710
	for ; Sat, 21 Jan 2006 16:47:27 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0QkP-0005Ar-Cr
	for ietf@ietf.org; Sat, 21 Jan 2006 16:58:15 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id EA49BE0053; Sat, 21 Jan 2006 16:48:47 -0500 (EST)
To: jnc@mercury.lcs.mit.edu (Noel Chiappa)
References: <20060121034031.46B4C872C6@mercury.lcs.mit.edu>
From: Sam Hartman 
Date: Sat, 21 Jan 2006 16:48:47 -0500
In-Reply-To: <20060121034031.46B4C872C6@mercury.lcs.mit.edu> (Noel Chiappa's
	message of "Fri, 20 Jan 2006 22:40:31 -0500 (EST)")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: ietf@ietf.org
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Mor
 fin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Noel" == Noel Chiappa  writes:

    >> From: "Gray, Eric"  Clearly we should be
    >> thinking about some way to "charge" participants for
    >> potentially abusing the IETF appeals process in general. There
    >> is some minimal processing time associated with any appeal for
    >> everyone who has anything to do with it.

    Noel> The legal system in several countries has the concept of a
    Noel> "vexatious litigator" label, which, when applied to someone,
    Noel> means they are not allowed to file a lawsuit without the
    Noel> approval of a some third party, generally a judge.

    Noel> I suggest the IESG/whomever take immediate steps to amend
    Noel> the appeals process so that there is a suitable process by
    Noel> which someone who abuses the appeals process by repeatedly
    Noel> filing pointless, unworthy appeals can be labelled a
    Noel> "vexatious appellant", whereby they are barred from filing
    Noel> appeals unless any such appeals are approved by some
    Noel> appropriate third party.

Hi.  I'm not sure it is necessary to go that far.

I'm actually trying to discuss this issue with the rest of the IESG
and see if we can come to agreement on how we'd like to handle making
sure that appeals don't become a DOS.  Clearly we'll need to let the
community know what we decide.  Also, if it involves modifying a BCP
and not just establishing internal IESG procedure, we'll need a formal
last call.
Clearly we should take any community comments we receive into account.

However I don't think this particular issue requires the entire ietf
list to design a solution.  I suspect we'll be able to come up with a
first cut on our own without taking up the time of the entire
community.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 19:18:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0Svx-00085W-IQ; Sat, 21 Jan 2006 19:18:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0Svv-00085P-4Q
	for ietf@megatron.ietf.org; Sat, 21 Jan 2006 19:18:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04608
	for ; Sat, 21 Jan 2006 19:16:45 -0500 (EST)
Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0T4w-0000Aw-Lq
	for ietf@ietf.org; Sat, 21 Jan 2006 19:27:35 -0500
Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43)
	id 1F0SvR-00076T-QH; Sun, 22 Jan 2006 00:17:46 +0000
Message-ID: <43D2CFA7.8080003@dial.pipex.com>
Date: Sun, 22 Jan 2006 00:19:51 +0000
From: Elwyn Davies 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Marshall Eubanks 
References: <20060116154032.GSGZ12737.eastrmmtai02.cox.net@EastRMIMPI02>	<003101c61ad6$3e53f150$01061f0a@Home1>
	<764D3B99-9E59-4E22-958E-14EA4050D28A@multicasttech.com>
In-Reply-To: <764D3B99-9E59-4E22-958E-14EA4050D28A@multicasttech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505
Content-Transfer-Encoding: 7bit
Cc: Patrice Lyons , ietf@ietf.org
Subject: Re: Ietf Digest, Vol 21, Issue 63
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

There are some of the early Internet Monthly reports online at 
http://ftp.us.xemacs.org/ftp/pub/internet-monthly-reports/ (incomplete 
before mid-1986)

The April 1986 edition (imr8604.txt) has the following...

   INTERNET ARCHITECTURE .Grab=5;
 
      .IOvr=3;1. A third draft of a document on gateway requirements was
      circulated for advice and comment in INENG, INARC and the Workshop
      on IS-IS Routing held at NBS. Strictly speaking, this is an NSF
      document and is being reviewed both as a service to NBS and as
      possible guidance for the DoD community.
 
      2. An agenda and marching orders are in place for the first
      meeting of INARC to be held at BBN on 8-9 May. Dave Clark has
      agreed to attend, as well as Lyman Chapin, who chairs the ANSI
      committee charged with routing issues. Marianne Gardner and
      possibly others from BBN will summarize their work on advanced
      routing issues.
 
      3. Discussion continues over a proposed RFC on ISO addressing
      co-authored by Hans-Werner Braun and Ross Callon. This is a legacy
      of the now defunct GADS, but may serve as an opening wedge for
      more general Dod-ISO convergence issues. .IOvr=0;
 
      Dave Mills
 
   INTERNET ENGINEERING .Grab=5;
 
      .IOvr=3;1) The initial meeting of this Task Force convened during
      an open afternoon of the final GADS on January 16, 1986.  A
      tentative Task Force agenda of short, mid and long term goals was
      set.
 
      2) The first full meeting was held on April 8-9, 1986 where the
      agenda focused on: .IOvr=0;
 
         - Recent Internet performance degradation
         - EGP Modifications
         - IP refinements in hosts and gateways for improved routing and
           congestion control
 
      3) A summary of recent Internet performance was given: .Grab=8;
 
                                       Dec 85     Jan 85
      Traffic Sent by Mail Bridges     ~27        ~35   (Mpackets/week)
      Traffic Sent by Mail Bridges     ~90        ~105  (Mpackets/week)
 
      Traffic Dropped by Mail Bridges  ~3%        ~6%
      Traffic Dropped by Mail Bridges  ~2%        ~4%
 
      .IOvr=3;4) BBN discussed two possible sources for these sharp
      changes: 1) a bug in the LSI gateway routing software, which was
      recently discovered and corrected and 2) resource shortage in the
      Mail Bridge PSNs, due to be alleviated by end of April).
 
      6) EGP modifications of two types were discussed: 1) areas in
      which the specification needed to be tightened and 2) areas in
      which the specification can profitable be `re-interpreted'.
      Examples of the second type include fragmented updates and
      interpreting the metric (eg, RFC975 - Autonomous Confederations).
 
      7) Several new ICMP messages were proposed to facilitate fault
      isolation and routing (eg, initial gateway discovery, discovery of
      preferred address for multi-homed hosts).  A co-operative
      congestion control scheme was proposed. Discussion of this scheme
      will continue in the Internet Architecture Task Force. .IOvr=0;
 
      8) Actions in progress:
 
         - continued tracking of Internet traffic for expected
           improvements,
         - produce RFC of EGP modifications,
         - produce RFC specifying host attachment and IP/ICMP
           modifications.
 
      .IOvr=3;9) Detailed meeting notes are available upon request to
      corrigan@DDN1.ARPA, with cc to gross@MITRE.ARPA.  Those requesting
      the notes will be added to the Task Force interest list. .IOvr=0;
 
      Phill Gross
 
I haven't been able to find a complete set of these reports from 
BTW, I came across this mail message from the ancient history of the tcp_ip mailing list (archived at UCL http://www-mice.cs.ucl.ac.uk/multimedia/misc/)
I liked the last paragraph...

Received: from braden.isi.edu by SRI-NIC.ARPA with TCP; Fri 31 Oct 86 10:07:11-PST
Date: Fri, 31 Oct 86 10:04:19 PST
From: Bob Braden 
Posted-Date: Fri, 31 Oct 86 10:04:19 PST
Message-Id: <8610311804.AA00167@braden.isi.edu>
Received: by braden.isi.edu (5.54/5.51)
	id AA00167; Fri, 31 Oct 86 10:04:19 PST
To: rick@seismo.css.gov
Subject: Re:  Poor performance related to egp?
Cc: braden@isi.edu, egp-people@ccv.bbn.com, tcp-ip@sri-nic.arpa

The examples you cite of "horrible" EGP routing are probably due to the
extra-hop problem in the core.  Apparently we have not done an adequate
job of information-spreading, if you are not aware of this problem.  I
seem to recall a blaze of messages on this very subject within the past 6
months, probably on the tcp-ip list.  It began with a complaint almost
identical to yours, and ended with a scholarly explanation of the
extra-hop problem by Dave Mills.

The extra-hop problem can at worst double the core traffic, and it is
scheduled to go away when the Butterflies take over the core.  I forget
the exact predicted date from BBN, but rescue is in sight.

As for performance, in some funny sense EGP is (deliberately) designed for
poor performance, in the sense that it is intended to server as a firewall
against misbehaviour by routing domains outside the core.  It is true, as
Mike StJohns says, that EGP is not a routing protocol; it is also true that
this fact has led to serious restrictions in topology and therefore a
crash effort is being mounted to replace EGP with a routing protocol, under
the direction of the INENG and INARCH task forces. 
 
However, maybe we are asking too much of EGP.  Perhaps we are trying to
make it a technical fix for administrative problems.  To avoid bad things
like oscillations and routing loops in the face of the "diversity" (to
use a nice word) of the Internet as a whole, EGP or whatever replaces it
will always have to use long time constants and provide some sub-optimal
routes.  At the present time, the Internet is growing largely by
accretion of new Autonomous Systems, and this must lead to some 
degradation as you cross boundaries.  If we want better overall
performance, we need to persuade these systems to aggregate into bigger
systems, each run by centralized and professional Internet management,
and each using a carefully-optimized IGP.

I go into all this polemic, because lately I have been exposed to an 
awful lot of technological optimism (ask NASA about that!) about 
Internetting.  I wish we could convince some of the new players in the
Internet game that it takes great technical sophistication and wisdom
to make this stuff work well.  The Anarchy Model of Internetting,
while theoretically feasible due to EGP, is not really a very wise way
to go.

Bob Braden

=========================

regards,
Elwyn Davies




Marshall Eubanks wrote:

> While we are on the subject, in the archives of the IETF there are  
> proceedings of one Internet Architecture Task Force meeting, in May,  
> 1986.
>
> Can anyone fill me in on this entity and what happened to it ?
>
> Regards
> Marshall Eubanks
>
> On Jan 16, 2006, at 2:51 PM, Patrice Lyons wrote:
>
>> Bob,
>>
>> They are talking about the first IETF meeting as taking place on  
>> Jan. 16, 1986.  What about the IETF meeting as one of the several  
>> task forces that Barry Leiner put together while you were still at  
>> DARPA?  There was also the working group series that preceded the  
>> IETF.  I recall that Jon Postel had kept the records of this work  on 
>> the early Internet.  Also, do you plan to go to Dallas?  The  last 
>> message to Harold mentions some agreement reached at Tunis  with 
>> respect to IETF work with the to be formed Internet Governance  Forum 
>> (at least I think that is what it is going to be called) (see  early 
>> work on it at http://www.intgovforum.org/.
>>
>> Patrice
>> ----- Original Message ----- From: 
>> To: 
>> Sent: Monday, January 16, 2006 10:40 AM
>> Subject: Ietf Digest, Vol 21, Issue 63
>>
>>
>>> ------------------------------
>>>
>>> Message: 6
>>> Date: Mon, 16 Jan 2006 11:14:48 +0100
>>> From: Brian E Carpenter 
>>> Subject: An important day for the IETF
>>> To: IETF discussion list 
>>> Message-ID: <43CB7218.1020008@zurich.ibm.com>
>>> Content-Type: text/plain; charset=us-ascii; format=flowed
>>>
>>> Greetings,
>>>
>>> The first IETF meeting took place 20 years ago today,
>>> on January 16th, 1986, in San Diego, California. There were
>>> 21 attendees and Mike Corrigan was in the chair.
>>>
>>> The IETF has come a long way since then. We'll celebrate
>>> this in fine style during the 65th IETF meeting in
>>> Dallas, Texas from March 19 to 24, 2006.
>>>
>>>    Brian Carpenter
>>>    IETF Chair No. 6
>>>
>>> ------------------------------
>>>
>>> Message: 7
>>> Date: Mon, 16 Jan 2006 12:30:13 +0100
>>> From: Harald Tveit Alvestrand 
>>> Subject: Re: An important day for the IETF
>>> To: Brian E Carpenter , IETF discussion list
>>> 
>>> Message-ID: 
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Happy birthday, IETF!
>>>
>>> And remember to raise an extra toast to Mike St. Johns, who should be
>>> coming to his 63rd or so IETF meeting in Dallas..... for some of  
>>> us, this
>>> has gotten to be a habit!
>>>
>>> Wonder how many of the original 21 are still around????
>>>
>>>             Harald, attendee since #22 (but missed #29)
>>>
>>> --On 16. januar 2006 11:14 +0100 Brian E Carpenter  
>>> 
>>> wrote:
>>>
>>>> Greetings,
>>>>
>>>> The first IETF meeting took place 20 years ago today,
>>>> on January 16th, 1986, in San Diego, California. There were
>>>> 21 attendees and Mike Corrigan was in the chair.
>>>>
>>>> The IETF has come a long way since then. We'll celebrate
>>>> this in fine style during the 65th IETF meeting in
>>>> Dallas, Texas from March 19 to 24, 2006.
>>>>
>>>>     Brian Carpenter
>>>>     IETF Chair No. 6
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ietf mailing list
>>>> Ietf@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ietf
>>>>
>>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 9
>>> Date: Mon, 16 Jan 2006 16:00:12 +0100
>>> From: Harald Tveit Alvestrand 
>>> Subject: Re: An important day for the IETF
>>> To: Noel Chiappa , ietf@ietf.org
>>> Message-ID: <64C91C00D46DC52AA27AF3EB@svartdal.hjemme.alvestrand.no>
>>> Content-Type: text/plain; charset=us-ascii; format=flowed
>>>
>>>
>>>
>>> --On mandag, januar 16, 2006 09:39:36 -0500 Noel Chiappa
>>>  wrote:
>>>
>>>>     > From: Harald Tveit Alvestrand 
>>>>
>>>>     > Wonder how many of the original 21 are still around????
>>>>
>>>> You rang? :-)
>>>
>>>
>>> That's one :-)
>>>
>>> The minutes of the first meeting are now online (scanned PDF)(!),  
>>> and there
>>> the attendees are listed as:
>>>
>>> Braun, Hans-Werner
>>> Bresica, Mike
>>> Callon, Ross
>>> Chiappa, Noel
>>> Eldridge, Charles
>>> Gross, Phill
>>> Hinden, Robert
>>> Mathis, James
>>> Mills, David
>>> Nagle, John
>>> Natalie, Ronald
>>> Rokitansky, Carl
>>> Shacham, Nachum
>>> Su, Zaw-Sing
>>> Topolcic, Claudio
>>> Zhang, Lixia
>>>
>>> Clark, David
>>> Corrigan, Mike
>>> Deering, Steve
>>> Means, Robert
>>> St. Johns, Mike
>>>
>>> The only email address that *might* still work is Hans-Werner  
>>> Braun's....
>>> none of the others have FQDNs.....
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 10
>>> Date: Mon, 16 Jan 2006 16:30:13 +0100
>>> From: "JFC (Jefsey) Morfin" 
>>> Subject: Re: An important day for the IETF
>>> To: Harald Tveit Alvestrand , Brian E Carpenter
>>> , IETF discussion list 
>>> Message-ID: <6.2.3.4.2.20060116151422.0395e2b0@mail.jefsey.com>
>>> Content-Type: text/plain; charset="us-ascii"; format=flowed
>>>
>>> At 12:30 16/01/2006, Harald Tveit Alvestrand wrote:
>>>
>>>> Happy birthday, IETF!
>>>
>>>
>>> Dear Harald,
>>> you are right, happy birthday! An impressive continuity we should
>>> strive to protect. In avoiding the status quo that some stakeholders
>>> may favor, and areas outside of network engineering (such as
>>> linguistic and country political definition :-)).
>>>
>>>> Wonder how many of the original 21 are still around????
>>>> Harald, attendee since #22 (but missed #29)
>>>
>>>
>>> Impressive. My own agenda that sad fortnight might help better
>>> understand the past, present and future of the network.
>>>
>>> - on 12-15 January 1986 I attended the eight Telecommunications
>>> Council Eighth Annual Conference at he Hawaiian Regent Hotel in
>>> Honolulu. The theme was  "Evolution of the Digital Pacific". Audience
>>> was probably 200 to 300 people. I had a lunch there with two lady
>>> training consultant for the US Army TV network, to discuss how to
>>> support their program on packet switch network, with Compression  
>>> Lab tools.
>>> - on the 16 I had a diner at the Bonaventure (LA) with Father Bourret
>>> (http://www.kuangchi.com/english/history.htm). On the agenda: packet
>>> switching in TW and a Vatican State International Packet Switch  
>>> Gateway
>>> - then I brought international data services experience in meetings
>>> with an LA based Bank and for a complete turn-key online banking
>>> service to a group NY banks. Multi-currency accounts, ATM
>>> connections. I explained our experience with air-line reservation
>>> services for most of the major airlines, hotels chains and
>>> rent-a-cars, and how it worked at regular Travel Agents using a
>>> service you would call a smart OPES today.
>>> - met with Mobil Oil international communications manager (NY) and
>>> routine meetings with the International Carriers. I was in Washington
>>> on the 28th.
>>>
>>> We used to refer to ARPANET as the "grand father" :-). Minitel users
>>> were probably already 3 millions in France, plus Prestel in UK, plus
>>> Germany, etc.. Over these 20 years since these Tymnet times, OSI,
>>> then the Internet made us to step from 7+ to 70+ to 700+ millions of
>>> active users worldwide.
>>>
>>> But you may understand why I feel the architectural evolution is
>>> sometimes dismaying and why constraints and rigidity cannot bring
>>> innovation and expansion. We need now another technology leap frog
>>> towards the 7+ billions users.
>>>
>>> Only a multilingual, multinational, multilateral, multitechnology,
>>> multiservice continuity architecture can deliver now.
>>> Good luck to everyone for the next decade which will be decisive.
>>>
>>> I do hope you will permit it to be in cooperation with the IGF,. That
>>> we can proceed fast on a stable, reasonable and acceptable equal
>>> opportunity but competitive fair basis. As we all agreed in Tunis.
>>> jfc
>>>
>>
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 21 20:01:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0Tbp-0004ea-KU; Sat, 21 Jan 2006 20:01:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0Tbn-0004ae-Fe
	for ietf@megatron.ietf.org; Sat, 21 Jan 2006 20:01:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06968
	for ; Sat, 21 Jan 2006 20:00:02 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc11.comcast.net ([204.127.202.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0Tko-0001FD-31
	for ietf@ietf.org; Sat, 21 Jan 2006 20:10:52 -0500
Received: from smailcenter59.comcast.net ([204.127.205.159])
	by comcast.net (sccrmhc11) with SMTP
	id <2006012201011601100qkmc0e>; Sun, 22 Jan 2006 01:01:16 +0000
Received: from [66.229.53.140] by smailcenter59.comcast.net;
	Sun, 22 Jan 2006 01:00:57 +0000
Cc: ietf@ietf.org
Date: Sun, 22 Jan 2006 01:00:57 +0000
Message-Id: <012220060100.6341.43D2D94900095766000018C5220700320100000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Mor
	fin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1439868899=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============1439868899==
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_6341_1137891657_0"


--NextPart_Webmail_9m3u9jl4l_6341_1137891657_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

haha@!!  I take a look at the IETF email after four months and it's still the same discussion as when I left!  Helloooo - talk about the ends not justifying the means (oh yes I know this is very very important to the fate of all productivity, I'm sure the yeild will be tremendous).
How 'bout this - if a PR-Action or any "rough concensus" style ban can't be decided in one week then quite obviusly the person is not making a sufficient nuiscance of themselves and the matter should be dropped.  On technical matters heated debate and convincing arguments are valuable but in a PR matter it's not.  What, are you going to convince someone that indeed they really were bothered by someones posts?  "Gee thanks Bob, I didn't know just how much that guy was upsetting me and hindering my productivity."
This isn't regression therapy and no one should be convincing people of their opinions or perceptions.  Make the motion, hear concensus, no cross-talk allowed, make the decision, move on.  Oh and don't let the interior decorators influence the architects - if the policies and penalties aren't clear at the time of the motion then the motion is governed by whatever is clear and you can amend the policies seperately for the next time.  You can't however dynamically change them and have them go into effect retroactively (or dynamically clarify them or however you'd describe this merger of congress and the courtroom).
Nick
--NextPart_Webmail_9m3u9jl4l_6341_1137891657_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit



haha@!!  I take a look at the IETF email after four months and it's still the same discussion as when I left!  Helloooo - talk about the ends not justifying the means (oh yes I know this is very very important to the fate of all productivity, I'm sure the yeild will be tremendous).


How 'bout this - if a PR-Action or any "rough concensus" style ban can't be decided in one week then quite obviusly the person is not making a sufficient nuiscance of themselves and the matter should be dropped.  On technical matters heated debate and convincing arguments are valuable but in a PR matter it's not.  What, are you going to convince someone that indeed they really were bothered by someones posts?  "Gee thanks Bob, I didn't know just how much that guy was upsetting me and hindering my productivity."


This isn't regression therapy and no one should be convincing people of their opinions or perceptions.  Make the motion, hear concensus, no cross-talk allowed, make the decision, move on.  Oh and don't let the interior decorators influence the architects - if the policies and penalties aren't clear at the time of the motion then the motion is governed by whatever is clear and you can amend the policies seperately for the next time.  You can't however dynamically change them and have them go into effect retroactively (or dynamically clarify them or however you'd describe this merger of congress and the courtroom).


Nick


--NextPart_Webmail_9m3u9jl4l_6341_1137891657_0--


--===============1439868899==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1439868899==--




From ietf-bounces@ietf.org Sat Jan 21 20:01:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0Tc1-0004fB-1j; Sat, 21 Jan 2006 20:01:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0Tby-0004f5-Vp
	for ietf@megatron.ietf.org; Sat, 21 Jan 2006 20:01:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06974
	for ; Sat, 21 Jan 2006 20:00:13 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc12.comcast.net ([63.240.77.82])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0Tl0-0001Fb-IQ
	for ietf@ietf.org; Sat, 21 Jan 2006 20:11:03 -0500
Received: from smailcenter59.comcast.net ([204.127.205.159])
	by comcast.net (sccrmhc12) with SMTP
	id <200601220101290120061t7pe>; Sun, 22 Jan 2006 01:01:29 +0000
Received: from [66.229.53.140] by smailcenter59.comcast.net;
	Sun, 22 Jan 2006 01:00:27 +0000
Cc: ietf@ietf.org
Date: Sun, 22 Jan 2006 01:00:27 +0000
Message-Id: <012220060100.6041.43D2D92B0006B25200001799220700320100000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Mor
	fin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0564081058=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0564081058==
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_6041_1137891627_0"


--NextPart_Webmail_9m3u9jl4l_6041_1137891627_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

haha@!!  I take a look at the IETF email after four months and it's still the same discussion as when I left!  Helloooo - talk about the ends not justifying the means (oh yes I know this is very very important to the fate of all productivity, I'm sure the yeild will be tremendous).
How 'bout this - if a PR-Action or any "rough concensus" style ban can't be decided in one week then quite obviusly the person is not making a sufficient nuiscance of themselves and the matter should be dropped.  On technical matters heated debate and convincing arguments are valuable but in a PR matter it's not.  What, are you going to convince someone that indeed they really were bothered by someones posts?  "Gee thanks Bob, I didn't know just how much that guy was upsetting me and hindering my productivity."
This isn't regression therapy and no one should be convincing people of their opinions or perceptions.  Make the motion, hear concensus, no cross-talk allowed, make the decision, move on.  Oh and don't let the interior decorators influence the architects - if the policies and penalties aren't clear at the time of the motion then the motion is governed by whatever is clear and you can amend the policies seperately for the next time.  You can't however dynamically change them and have them go into effect retroactively (or dynamically clarify them or however you'd describe this merger of congress and the courtroom).
Nick
--NextPart_Webmail_9m3u9jl4l_6041_1137891627_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit



haha@!!  I take a look at the IETF email after four months and it's still the same discussion as when I left!  Helloooo - talk about the ends not justifying the means (oh yes I know this is very very important to the fate of all productivity, I'm sure the yeild will be tremendous).


How 'bout this - if a PR-Action or any "rough concensus" style ban can't be decided in one week then quite obviusly the person is not making a sufficient nuiscance of themselves and the matter should be dropped.  On technical matters heated debate and convincing arguments are valuable but in a PR matter it's not.  What, are you going to convince someone that indeed they really were bothered by someones posts?  "Gee thanks Bob, I didn't know just how much that guy was upsetting me and hindering my productivity."


This isn't regression therapy and no one should be convincing people of their opinions or perceptions.  Make the motion, hear concensus, no cross-talk allowed, make the decision, move on.  Oh and don't let the interior decorators influence the architects - if the policies and penalties aren't clear at the time of the motion then the motion is governed by whatever is clear and you can amend the policies seperately for the next time.  You can't however dynamically change them and have them go into effect retroactively (or dynamically clarify them or however you'd describe this merger of congress and the courtroom).


Nick


--NextPart_Webmail_9m3u9jl4l_6041_1137891627_0--


--===============0564081058==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0564081058==--




From ietf-bounces@ietf.org Sun Jan 22 02:04:13 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0ZGn-0001sk-Sc; Sun, 22 Jan 2006 02:04:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ZGm-0001sf-6I
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 02:04:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26995
	for ; Sun, 22 Jan 2006 02:02:42 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0ZPn-0001l1-KA
	for ietf@ietf.org; Sun, 22 Jan 2006 02:13:36 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F0ZGU-0004vm-TG
	for ietf@ietf.org; Sun, 22 Jan 2006 08:03:54 +0100
Received: from pd9fba9a7.dip0.t-ipconnect.de ([217.251.169.167])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Sun, 22 Jan 2006 08:03:54 +0100
Received: from nobody by pd9fba9a7.dip0.t-ipconnect.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for ; Sun, 22 Jan 2006 08:03:54 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Sun, 22 Jan 2006 08:02:46 +0100
Organization: 
Lines: 31
Message-ID: <43D32E16.4B6B@xyzzy.claranet.de>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fba9a7.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: geopriv@mail.apps.ietf.org
Subject: Re: Location Types Registry
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Tschofenig, Hannes wrote:

> The values listed in the "Location Types Registry" document
> are not displayed to the user. As such, we don't cover
> internationalization support.

That wasn't clear from the draft under discussion.  It should
get some "I18N considerations" explaining why that's no issue.

> If there are better definitions please let us know.

Maybe the WiKi dictionary has a category "location" (?)
 
> We thought that FCFS would be an acceptable policy. Some
> people had a different view about it.

Not limited to registration request DoS attacks on IANA, yes.

> Fine. I have no problems changing it to expert review.

Where do you expect to find volunteers for an expert review
of a location dictionary ?  From two "expert review" lists I
know (langtags and charsets) one works at the moment, I'm
not sure about the other.  

"Expert review" is essentially a filter protecting IANA from
some really bad ideas, but it's also an exercise in TINSTAAFL
- set up mailing list, appoint reviewer, handle appeals, etc.

                               Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 03:46:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0arf-00021j-2M; Sun, 22 Jan 2006 03:46:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ard-00021Q-4R
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 03:46:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02376
	for ; Sun, 22 Jan 2006 03:44:53 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0b0j-0004Dc-2h
	for ietf@ietf.org; Sun, 22 Jan 2006 03:55:46 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 22 Jan 2006 00:46:09 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.01,209,1136188800"; 
	d="scan'208"; a="20205156:sNHT21559472"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0M8k5PM025063; 
	Sun, 22 Jan 2006 03:46:06 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Sun, 22 Jan 2006 03:46:05 -0500
Received: from [127.0.0.1] ([161.44.11.166]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Sun, 22 Jan 2006 03:46:04 -0500
Message-ID: <43D34649.9050000@cisco.com>
Date: Sun, 22 Jan 2006 09:46:01 +0100
From: Scott W Brim 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Elwyn Davies 
References: <20060116154032.GSGZ12737.eastrmmtai02.cox.net@EastRMIMPI02>	<003101c61ad6$3e53f150$01061f0a@Home1>	<764D3B99-9E59-4E22-958E-14EA4050D28A@multicasttech.com>
	<43D2CFA7.8080003@dial.pipex.com>
In-Reply-To: <43D2CFA7.8080003@dial.pipex.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jan 2006 08:46:05.0194 (UTC)
	FILETIME=[47E85EA0:01C61F30]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4
Content-Transfer-Encoding: 7bit
Cc: Patrice Lyons , ietf@ietf.org
Subject: Re: Ietf Digest, Vol 21, Issue 63
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 01/22/2006 01:19 AM, Elwyn Davies allegedly wrote:
>         - EGP Modifications

FGP, the follow-on gateway protocol.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 04:01:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0b6V-0006Jq-4X; Sun, 22 Jan 2006 04:01:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0b6T-0006Jl-8d
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 04:01:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03490
	for ; Sun, 22 Jan 2006 04:00:13 -0500 (EST)
Received: from mtagate2.uk.ibm.com ([195.212.29.135])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0bFZ-0004q3-20
	for ietf@ietf.org; Sun, 22 Jan 2006 04:11:06 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0M91UoM198970
	for ; Sun, 22 Jan 2006 09:01:30 GMT
Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com
	[9.149.37.212])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0M91TYP225820 for ; Sun, 22 Jan 2006 09:01:30 GMT
Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0M91TZH012216 for ; Sun, 22 Jan 2006 09:01:29 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0M91TdJ012207 for ; Sun, 22 Jan 2006 09:01:29 GMT
Received: from zurich.ibm.com (sig-9-145-130-30.de.ibm.com [9.145.130.30])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA49766
	for ; Sun, 22 Jan 2006 10:01:28 +0100
Message-ID: <43D349E7.1060507@zurich.ibm.com>
Date: Sun, 22 Jan 2006 10:01:27 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: ietf@ietf.org
References: <7D5D48D2CAA3D84C813F5B154F43B1550922BE6B@nl0006exch001u.nl.lucent.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.uk.ibm.com id
	k0M91UoM198970
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: quoted-printable
Subject: Re: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Joe Abley wrote:
>=20
> On 20-Jan-2006, at 11:55, Wijnen, Bert (Bert) wrote:
>=20
>> Well said Barry!
>>
>>> From: Barry Leiba
>>>
>>> My biggest concern is in sections "2.3.  Freedom of Participation"
>>> and "2.5.  Attendance Limitation and Visas", in that I'm not sure
>>> how realistic they are.  Without getting overly into politics (let's
>>> please not), I think they reflect a somewhat na=EFve view of some of
>>> the political realities.  Specifically...
>>>
>>>     Meetings should not be held in countries where some
>>> attendees could
>>>     be disallowed entry or where freedom of speech is not
>>> guaranteed for
>>>     all participants.
>=20
>=20
> Indeed. Applied with vigour, this restriction implies that no country =20
> is suitable to meet in. That leaves us with parts of Antarctica, a =20
> floating venue located in international waters, or zero-g bar BOFs in =20
> outer space. I favour the latter.
>=20
> A slightly more realistic approach might be to hold meetings  regularly=
=20
> in different countries with (ideally) divergent security/ immigration=20
> policies, in the hope that successive meetings might at  least exclude=20
> different sets of people.

This is a very important issue as we consider visiting countries we've ne=
ver
visited before and as visa regulations change in countries we have been
to often. It would be very useful to know how more people feel we should
tune these criteria.

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 06:20:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0dGq-0000Ch-4F; Sun, 22 Jan 2006 06:20:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0dGo-0000Ca-Gd
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 06:20:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11241
	for ; Sun, 22 Jan 2006 06:19:01 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0dPw-0004Iu-7e
	for ietf@ietf.org; Sun, 22 Jan 2006 06:29:56 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0MBKFIZ050207
	for ; Sun, 22 Jan 2006 12:20:16 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Sun, 22 Jan 2006 12:20:15 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1842666062.20060122122015@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060121201459.20625.qmail@simone.iecc.com>
References: 
	<20060121201459.20625.qmail@simone.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John Levine writes:

> I cannot tell you how many lists I've been on that have been in
> exactly our situation, paralyzed by one or two people who skate along
> the edge of being kicked off, choking the list with clouds of
> irrelevant smoke.  There's always the same arguments, if we were
> disciplined enough to ignore the noise, it wouldn't matter, everyone
> has a right to say something, it's about personalities rather than
> substance, etc., etc. You all know them as well as I do.

Maybe it's time to heed the arguments instead of just complaining
about them.  I do, and it works well for me; I'm never bothered by
"clouds of irrelevant smoke" on any list, even though most lists
constantly have such clouds drifting about.

Of course, in practice, many people refuse to heed these arguments
because they simply cannot tolerate the thought of anyone being
allowed to say or write anything that they themselves find
objectionable. Filtering the unwanted traffic isn't enough for them;
they want to prevent the whole world from seeing it. They are
irritated not only by the traffic itself, but also by the thought that
anyone else might be able to see that traffic. So they crusade for
constant censorship of every expression of which they don't personally
approve. And eventually they make as much or more noise than the
people whom they find so objectionable, ironically.

Eventually you end up with multiple groups on a list: those who
irritate others, those who want to censor the ones they find
irritating, and--sometimes--a minority of people who are grown-up
enough to stay out of both of these groups and continue their normal
work, cheerfully ignoring the children at play on the list.

> When this happens, I've only ever seen two possible outcomes.  Either
> the smoke generators are ejected, or the productive members leave.

There's a third possible outcome: The productive members are smart,
they ignore the smoke, and they continue to work efficiently.  But the
productive members do have to be _smart_, and unfortunately that's
more the exception than the rule, even on lists where the members like
to believe themselves smart.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 06:23:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0dJo-0000lw-7V; Sun, 22 Jan 2006 06:23:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0dJm-0000lQ-Ea
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 06:23:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11324
	for ; Sun, 22 Jan 2006 06:22:05 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0dSt-0004MP-HZ
	for ietf@ietf.org; Sun, 22 Jan 2006 06:33:01 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0MBNNPB050238
	for ; Sun, 22 Jan 2006 12:23:23 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Sun, 22 Jan 2006 12:23:23 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1205771400.20060122122323@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <012220060100.6041.43D2D92B0006B25200001799220700320100000E9B9CD2050C0702@comcast.net>
References: <012220060100.6041.43D2D92B0006B25200001799220700320100000E9B9CD2050C0702@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Mor
	fin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

nick.staff@comcast.net writes:

> haha@!!  I take a look at the IETF email after four months and
> it's still the same discussion as when I left!

I notice the same thing.  The Harper Valley PTA is still very much at
work, but technical issues seem to be few and far between.

> What, are you going to convince someone that indeed they really were
> bothered by someones posts?

The idea is not to convince them, but to override them, so that what
they think doesn't matter.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 07:02:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0dvM-0002rb-RV; Sun, 22 Jan 2006 07:02:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0dvK-0002rQ-VZ; Sun, 22 Jan 2006 07:02:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13305;
	Sun, 22 Jan 2006 07:00:53 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0e4T-0005FX-Es; Sun, 22 Jan 2006 07:11:49 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3815444; Sun, 22 Jan 2006 06:59:01 -0500
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Sun, 22 Jan 2006 07:02:13 -0500
To: Scott Hollenbeck 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, ietf-announce@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I do not support approval of this PR-action.

Regards
Marshall Eubanks

On Jan 18, 2006, at 7:34 AM, Scott Hollenbeck wrote:

> The IESG has received a request from Harald Alvestrand to approve  
> an RFC
> 3683 PR-action  ("posting rights" action) for JFC (Jefsey) Morfin as a
> result of a pattern of prior warning and posting rights suspensions  
> for
> off-topic postings to the LTRU working group and ietf-languages  
> mailing
> lists that have not produced a change in behavior.  This behavior  
> has been
> characterized as a "denial-of-service" attack to disrupt the
> consensus-driven process as described in Section 1 of RFC 3683.  A  
> timeline
> of warnings and posting rights suspensions related to this request is
> included below.
>
> The IESG will consider this request.  If approved, the PR-action  
> described
> in Section 2 of RFC 3683 includes provisions to allow list  
> administrators to
> suspend Mr. Morfin's posting rights to the LTRU working group and
> ietf-languages mailing list for at least one year.  Maintainers of  
> other
> IETF mailing lists may also remove posting rights to their mailing  
> lists at
> their discretion.
>
> The IESG plans to make a decision in the next few weeks, and  
> solicits final
> comments on this action.  Please send any comments to the  
> iesg@ietf.org or
> ietf@ietf.org mailing lists by 17 February 2006.
>
> For the IESG,
> Scott Hollenbeck
> Applications Area Director
> --------------------------
>
> Private warnings sent for LTRU working group mailing list postings:
> 7 July 2005
> 16 July 2005
> 23 September 2005
> 26 October 2005
>
> Public warnings and suspensions for LTRU working group and ietf- 
> languages
> mailing list postings:
>
> 17 March 2005 (ietf-languages warning)
> http://www.alvestrand.no/pipermail/ietf-languages/2005-March/ 
> 003236.html
>
> 5 April 2005 (LTRU warning)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg00564.html
>
> 12 May 2005 (LTRU suspension)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg01737.html
>
> 26 May 2005 (LTRU warning)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg01897.html
> (Used as basis for 4 July suspension.)
>
> 15 June 2005 (ietf-languages suspension)
> http://www.alvestrand.no/pipermail/ietf-languages/2005-June/ 
> 003474.html
>
> 4 July 2005 (LTRU suspension)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg02532.html
> (Appealed to AD, appeal upheld, new warning given.)
>
> 5 July 2005 (LTRU warning)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg02548.html
>
> 15 September 2005 (ietf-languages suspension)
> http://www.alvestrand.no/pipermail/ietf-languages/2005-September/ 
> 003585.html
>
> 26 September 2005 (LTRU warning)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg03755.html
>
> 7 October 2005
> PR-Action request sent to IESG
> http://www1.ietf.org/mail-archive/web/ietf/current/msg38183.html
>
> 15 October 2005 (LTRU warning)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg03941.html
>
> 8 November 2005 (LTRU suspension)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html
> (Appealed to AD, appeal denied by AD.)
>
> 20 November 2005 (ietf-languages suspension)
> http://www.alvestrand.no/pipermail/ietf-languages/2005-November/ 
> 003811.html
> (Appealed to AD/IESG, appeal denied by IESG, appealed to the IAB.)
>
> 13 January 2006 (ietf-languages suspension)
> http://www.alvestrand.no/pipermail/ietf-languages/2006-January/ 
> 003854.html
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 07:05:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0dyb-0003d6-JW; Sun, 22 Jan 2006 07:05:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0dyY-0003cP-VF; Sun, 22 Jan 2006 07:05:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13610;
	Sun, 22 Jan 2006 07:04:12 -0500 (EST)
Received: from mtagate4.de.ibm.com ([195.212.29.153])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0e7g-0005NS-GM; Sun, 22 Jan 2006 07:15:09 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0MC5Sln266022; 
	Sun, 22 Jan 2006 12:05:28 GMT
Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com
	[9.149.165.212])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0MC5SVv106086; Sun, 22 Jan 2006 13:05:28 +0100
Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0MC5RK4017793; Sun, 22 Jan 2006 13:05:27 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0MC5RBJ017790; Sun, 22 Jan 2006 13:05:27 +0100
Received: from zurich.ibm.com (sig-9-145-252-34.de.ibm.com [9.145.252.34])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA77454;
	Sun, 22 Jan 2006 13:05:25 +0100
Message-ID: <43D35ECF.2090307@zurich.ibm.com>
Date: Sun, 22 Jan 2006 11:30:39 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Sam Hartman 
References: 	
	<6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
	
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: John C Klensin , Scott Hollenbeck ,
	ietf@ietf.org, iesg@ietf.org
Subject: Re: Does the IESG have the authority to do less than 3683?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

fwiw, my feeling is that if we did bend the rules that way,
we'd be at strong risk of an appeal. I think the rules are
in a bit of a mess.

     Brian

Sam Hartman wrote:
>>>>>>"John" == John C Klensin  writes:
> 
> 
>     John> For whatever it is worth, I want to remind the IESG that,
>     John> before there was RFC 3683, there was a notion, not only of
>     John> 30 day suspensions, but of exponential (or other rapidly
>     John> increasing series) back-off.  If someone is being severely
>     John> disruptive on a particular list, it would seem reasonable to
>     John> me for the relevant AD to authorize a 60 day suspension if a
>     John> 30 day one is ineffective, a 120 day suspension if that is
>     John> ineffective, and so on.  The nature of that arithmetic is
>     John> such that someone could, with sufficient repeated disruptive
>     John> behavior, find themselves rather effectively banned for the
>     John> effective duration of a WG.  If the IESG believes that a
>     John> formal RFC3933 experiment is needed to do that, then let's
>     John> write down and run that experiment.  But, until we have
>     John> tried the above --and any other plausible actions we can
>     John> think of-- let's save the 3683 actions for those whose
>     John> behavior is more clearly inappropriate and non-constructive
>     John> than Jefsey's.
> 
> 
> Hi, John.  The prevailing view on the IESG seems to be that the
> combination of RFC 3683 and 3934 actually took away our ability to
> approve suspensions greater than 30 days but short of a PR action.
> Others seem to believe that while we might want to fix that, we should
> deal with this matter first.
> 
> can you see a reading of 2418 as amended, 3934 and 3683 together that
> give the IESG the power to approve a longer suspension?
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 07:25:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0eHM-0000pp-Qi; Sun, 22 Jan 2006 07:25:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0eHJ-0000pk-NX
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 07:25:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14627
	for ; Sun, 22 Jan 2006 07:23:36 -0500 (EST)
Received: from mail.gmx.net ([213.165.64.21])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0eQR-0005s3-4A
	for ietf@ietf.org; Sun, 22 Jan 2006 07:34:32 -0500
Received: (qmail invoked by alias); 22 Jan 2006 12:24:44 -0000
Received: from p54A7D0A6.dip.t-dialin.net (EHLO peter-dambier.de)
	[84.167.208.166]
	by mail.gmx.net (mp038) with SMTP; 22 Jan 2006 13:24:44 +0100
X-Authenticated: #8956597
Message-ID: <43D37987.8040605@peter-dambier.de>
Date: Sun, 22 Jan 2006 13:24:39 +0100
From: Peter Dambier 
Organization: Peter and Karin Dambier
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <012220060100.6041.43D2D92B0006B25200001799220700320100000E9B9CD2050C0702@comcast.net>
	<1205771400.20060122122323@atkielski.com>
In-Reply-To: <1205771400.20060122122323@atkielski.com>
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Mor
 fin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: peter@peter-dambier.de
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

For the no-tv people like Karin and me:

Harper Valley P.T.A

USA / NBC/ 36x30m-e / 1981-82

First Episode: Friday 16 January 1981 / 8.00pm
  Last Episode: Saturday 14 August 1982 / 8.30pm
  Theme Music: Harper Valley P.T.A. by Tom T. Hall

Sitcom starring Barbara Eden as Stella Johnson a widow with a 13 year old
daughter, Dee. The pair lived in Harper Valley, Ohio, a Stepford Wives kind
of a place, sweet on the surface but with a sleazy undercurrent.
Stella was a very pro-active member of the school P.T.A. board a fact which
obviously gave the show it's title. The rest of the board thought Stella was far
too radical for them and were determined to be rid of her.
Leader of the PTA was the highly snooty Flora Simpson Reilly who hated Stella
with a passion. Reilly and her family played a big part in the series.
For season two there several changes (most notably the shortening of the title
to simply Harper Valley) with the PTA side of things taking a back seat and the
setting becoming more a traditional suburban one. Stella's inventor Uncle Buster
moved in with her and Dee for this season.
The show was actually based on the hit record of 1968 Harper Valley PTA by
Jeannie C. Riley which in turn led to the 1978 film of the same name which also
starred Barbara Eden as Stella.

Sorry for the long, long quote but yes that is exactly Harper Valley P.T.A

Thankyou King Harald from Norway for playing the most important role.

Thankyou Jefsey for playing the litning rod or
Thors Hammer Mjoelnir might have hit me.

We enjoyed the show but enuf is enuf.

Cheers from Peter and Karin


Anthony G. Atkielski wrote:
> nick.staff@comcast.net writes:
> 
> 
>>haha@!!  I take a look at the IETF email after four months and
>>it's still the same discussion as when I left!
> 
> 
> I notice the same thing.  The Harper Valley PTA is still very much at
> work, but technical issues seem to be few and far between.
> 
> 
>>What, are you going to convince someone that indeed they really were
>>bothered by someones posts?
> 
> 
> The idea is not to convince them, but to override them, so that what
> they think doesn't matter.


-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@echnaton.serveftp.com
mail: peter@peter-dambier.de
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 07:25:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0eHa-0000qW-Oq; Sun, 22 Jan 2006 07:25:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0eHa-0000qL-1c; Sun, 22 Jan 2006 07:25:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14633;
	Sun, 22 Jan 2006 07:23:52 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0eQh-0005sU-UY; Sun, 22 Jan 2006 07:34:49 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-3.cisco.com with ESMTP; 22 Jan 2006 04:25:09 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0MCP9KT016404;
	Sun, 22 Jan 2006 04:25:09 -0800 (PST)
Received: from [212.254.247.5] (ams-clip-vpn-dhcp182.cisco.com [10.61.64.182])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0MCTiW9007892;
	Sun, 22 Jan 2006 04:29:44 -0800
Message-ID: <43D379A3.5010200@cisco.com>
Date: Sun, 22 Jan 2006 13:25:07 +0100
From: Eliot Lear 
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Marshall Eubanks 
References: 
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=77; t=1137932986; x=1138365186;
	c=relaxed/simple; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20
	|Subject:Re=3A=20IETF=20Last=20Call=20under=20RFC=203683=20concerning=20JFC=20(Je
	fsey)=20Morfin
	|To:Marshall=20Eubanks=20;
	X=v=3Dmtcc.com=3B=20h=3Db9CRWP8PLQTyhadNjv48P4D20gM=3D;
	b=gShjrkou7LCMYL5/Tg7AYq8PEHVS13t4t9IzA5zLShLIdorKMwoK/iw7MR9hYM+9Yi5SDDlH
	5F9cPOnSfakz/Uyy/JAakVmeleUE2L6i77lSPN7NEGogmQ87VlGFYWjFbxaZuy5oN8feSA9ff5e
	r1JMF7GbwKaTUU1G3QriTQgA=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com;
	dkim=pass ( message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d62ab47271805379d7172ee693a45db
Content-Transfer-Encoding: 7bit
Cc: Scott Hollenbeck , ietf@ietf.org,
	ietf-announce@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Marshall,
> I do not support approval of this PR-action.

Because.....??


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 07:48:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0edu-0006qp-A8; Sun, 22 Jan 2006 07:48:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0eds-0006qW-4Y; Sun, 22 Jan 2006 07:48:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15843;
	Sun, 22 Jan 2006 07:46:54 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0en0-0006Qs-AC; Sun, 22 Jan 2006 07:57:51 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3815529; Sun, 22 Jan 2006 07:45:07 -0500
In-Reply-To: <43D379A3.5010200@cisco.com>
References: 
	
	<43D379A3.5010200@cisco.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Sun, 22 Jan 2006 07:48:17 -0500
To: Eliot Lear 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: Scott Hollenbeck , ietf@ietf.org,
	ietf-announce@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Because I do not feel that the punishment is merited.

On Jan 22, 2006, at 7:25 AM, Eliot Lear wrote:

> Marshall,
>> I do not support approval of this PR-action.
>
> Because.....??
>

I posted my thoughts earlier, my understanding is that in the last  
call process it is appropriate to restate one's
opinion.

If you conclude that I think that there has been too much verbiage on  
this matter, you are correct. I am trying to add to it as little as  
possible.

Regards
Marshall

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 08:17:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0f6O-00083y-MV; Sun, 22 Jan 2006 08:17:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0f6M-00083k-UD; Sun, 22 Jan 2006 08:17:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18295;
	Sun, 22 Jan 2006 08:16:21 -0500 (EST)
Received: from relay2.mail.uk.clara.net ([80.168.70.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0fFT-0007Ya-VZ; Sun, 22 Jan 2006 08:27:18 -0500
Received: from 81-178-93-18.dsl.pipex.com ([81.178.93.18] helo=Puppy)
	by relay2.mail.uk.clara.net with esmtpa (Exim 4.50)
	id 1F0f6A-000GF1-8L; Sun, 22 Jan 2006 13:17:38 +0000
Message-ID: <006d01c61f56$c08d44d0$0701a8c0@Puppy>
From: "Adrian Farrel" 
To: 
References: 	<6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
	<43D35ECF.2090307@zurich.ibm.com>
Date: Sun, 22 Jan 2006 13:21:23 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Clara-Relay: Message sent using Claranet Relay Service using auth code:
	olddog
X-Spam-Score: 1.2 (+)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I do not support the action against Jefsey Morfin, because the outcome
would facilitate a ban on all IETF lists without specific cause and
without recourse. I am not in a position to judge the correctness of a ban
on the lists explicitly cited but I do not believe that we have witnessed
behavior that is targeted against the IETF per se, and so a blanket ban is
inappropriate.

In my view a full 3683 action would be too harsh.

I am not sympathetic to the argument that says we only have a large hammer
so we MUST use it because we can't do nothing.

If those who would exclude Jefsey from certain lists feel that repeated 30
day bans are too much work, I suggest they draft a new process that would
allow them to create longer bans on specific lists.

Adrian
----- Original Message ----- 
From: "Brian E Carpenter" 
To: "Sam Hartman" 
Cc: "John C Klensin" ; "Scott Hollenbeck"
; ; 
Sent: Sunday, January 22, 2006 10:30 AM
Subject: Re: Does the IESG have the authority to do less than 3683?


> fwiw, my feeling is that if we did bend the rules that way,
> we'd be at strong risk of an appeal. I think the rules are
> in a bit of a mess.
>
>      Brian
>
> Sam Hartman wrote:
> >>>>>>"John" == John C Klensin  writes:
> >
> >
> >     John> For whatever it is worth, I want to remind the IESG that,
> >     John> before there was RFC 3683, there was a notion, not only of
> >     John> 30 day suspensions, but of exponential (or other rapidly
> >     John> increasing series) back-off.  If someone is being severely
> >     John> disruptive on a particular list, it would seem reasonable to
> >     John> me for the relevant AD to authorize a 60 day suspension if a
> >     John> 30 day one is ineffective, a 120 day suspension if that is
> >     John> ineffective, and so on.  The nature of that arithmetic is
> >     John> such that someone could, with sufficient repeated disruptive
> >     John> behavior, find themselves rather effectively banned for the
> >     John> effective duration of a WG.  If the IESG believes that a
> >     John> formal RFC3933 experiment is needed to do that, then let's
> >     John> write down and run that experiment.  But, until we have
> >     John> tried the above --and any other plausible actions we can
> >     John> think of-- let's save the 3683 actions for those whose
> >     John> behavior is more clearly inappropriate and non-constructive
> >     John> than Jefsey's.
> >
> >
> > Hi, John.  The prevailing view on the IESG seems to be that the
> > combination of RFC 3683 and 3934 actually took away our ability to
> > approve suspensions greater than 30 days but short of a PR action.
> > Others seem to believe that while we might want to fix that, we should
> > deal with this matter first.
> >
> > can you see a reading of 2418 as amended, 3934 and 3683 together that
> > give the IESG the power to approve a longer suspension?
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> >
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 08:37:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0fPg-0005LC-K7; Sun, 22 Jan 2006 08:37:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0fPc-0005L6-OK
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 08:37:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19960
	for ; Sun, 22 Jan 2006 08:36:14 -0500 (EST)
Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0fYl-0008FK-83
	for ietf@ietf.org; Sun, 22 Jan 2006 08:47:12 -0500
Received: from [71.254.17.114] (HELO JMHLap3.stevecrocker.com)
	by execdsl.com (CommuniGate Pro SMTP 4.2.7)
	with ESMTP id 12928197; Sun, 22 Jan 2006 06:34:21 -0700
Message-Id: <6.2.1.2.0.20060122083512.030d8708@mail.stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Sun, 22 Jan 2006 08:37:32 -0500
To: Brian E Carpenter , ietf@ietf.org
From: "Joel M. Halpern" 
In-Reply-To: <43D349E7.1060507@zurich.ibm.com>
References: <7D5D48D2CAA3D84C813F5B154F43B1550922BE6B@nl0006exch001u.nl.lucent.com>
	
	<43D349E7.1060507@zurich.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: 
Subject: Re: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

While I applaud the sentiment, I believe as written this is an unfortunate 
and undesirable constraint.
Something along the lines of:
     The IETF should endevour to choose venues where all participants who 
choose to can attend the meeting
would seem to capture the goal as a goal.

Yours,
Joel M. Halpern

At 04:01 AM 1/22/2006, Brian E Carpenter wrote:
> >  Meetings should not be held in countries where some
> >  attendees could
> >   be disallowed entry or where freedom of speech is not
> >  guaranteed for all participants.
>
>
>This is a very important issue as we consider visiting countries we've never
>visited before and as visa regulations change in countries we have been
>to often. It would be very useful to know how more people feel we should
>tune these criteria.
>
>    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 09:14:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0fyi-0006qG-33; Sun, 22 Jan 2006 09:14:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0fyf-0006oU-S4
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 09:13:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21829
	for ; Sun, 22 Jan 2006 09:12:29 -0500 (EST)
Received: from mail.gmx.net ([213.165.64.21])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0g7p-0000h1-2x
	for ietf@ietf.org; Sun, 22 Jan 2006 09:23:25 -0500
Received: (qmail invoked by alias); 22 Jan 2006 14:13:46 -0000
Received: from p54A7D0A6.dip.t-dialin.net (EHLO peter-dambier.de)
	[84.167.208.166]
	by mail.gmx.net (mp028) with SMTP; 22 Jan 2006 15:13:46 +0100
X-Authenticated: #8956597
Message-ID: <43D3931C.9090209@peter-dambier.de>
Date: Sun, 22 Jan 2006 15:13:48 +0100
From: Peter Dambier 
Organization: Peter and Karin Dambier
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott Hollenbeck 
References: 
In-Reply-To: 
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: peter@peter-dambier.de
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I am against this action.

Harald Tveit Alvestrand 

is notorious for swinging for Thors Hammer Mjoelnir just see his postings

Date: Tue, 21 Jun 2005 16:34:48 +0200
From: Harald Tveit Alvestrand 
To: Spencer Dawkins , ietf@ietf.org
Message-ID: <03901A727082675EC7C670D5@B50854F0A9192E8EC6CDA126>
In-Reply-To: <000901c57595$20b33700$0500a8c0@DFNJGL21>

Let me offer a simplistic metric.....

if a WG chair has posted nothing to the WG mailing list for a week, and
that WG chair has not told the WG he's on holiday, that WG chair is
probably not doing his/her job.

If NOBODY's posted to the WG mailing list for a week, it's time to close
the WG.


Date: Sun, 26 Jun 2005 21:02:19 +0200
From: Harald Tveit Alvestrand 
To: ietf@ietf.org
Message-ID: <6B7F58BA899750A5281E0259@B50854F0A9192E8EC6CDA126>

Since I'm no longer responsible for anything that Dean Anderson has a
legitimate role in, and Dean Anderson has proved that he irritates me, I
can stop listening to Dean Anderson.

Goodbye, mr. Anderson.


Date: Fri, 22 Jul 2005 14:08:46 +0200
From: Harald Tveit Alvestrand 
To: Francois Menard , ietf@ietf.org
Message-ID: <5A0CA0F795BD2E094483310B@gloppen.hjemme.alvestrand.no>
In-Reply-To: 
References: 

You have of course read RFC 2826, "IAB Technical Comment on the Unique DNS
Root"?

Of course, this is specifically about the DNS, and doesn't answer your
question as it pertains to non-DNS systems....


Date: Sat, 06 Aug 2005 20:43:13 +0200
From: Harald Tveit Alvestrand 
To: shogunx 
Message-ID: <6E80859BE4257E3164EF20CE@gloppen.hjemme.alvestrand.no>
In-Reply-To: 
References: 

Thanks for confirming that you have totally missed what the IASA process
was all about.

This community has a number of people who wish to say how things need to be
done - whether it is meeting location, IPv6 or cookies during the breaks -
while absolutely refusing to spend any thought cycles whatsoever trying to
find out how this organization is actually put together, who will have to
make the decisions to implement their wishes, and who those people are
accountable to.

You have thoroughly confirmed that you are among that group.


Date: Sat, 06 Aug 2005 19:25:50 +0200
From: Harald Tveit Alvestrand 
To: Iljitsch van Beijnum ,	IETF General Discussion Mailing List 
Message-ID: <6BAC48C363AB77486B6D704C@gloppen.hjemme.alvestrand.no>
In-Reply-To: <90A9AE46-BEB2-4A08-BEA0-65964256574B@muada.com>
References: <90A9AE46-BEB2-4A08-BEA0-65964256574B@muada.com>

I think IPv6 can wait until we have the formalities straight.


Date: Sun, 07 Aug 2005 00:13:22 +0200
From: Harald Tveit Alvestrand 
To: shogunx 
Message-ID: 
In-Reply-To: 
References: 

It seems that you missed the publication of BCP 101, RFC 4071, which
explains exactly what the IASA is.

Once you say something that indicates that you have done anything at all to
understand the organization you claim to be working in, I might find a
reason to engage in debate with you again.

...

There are a lot more.

But please understand I dont want to open a case against Harald here.

The quotes are taken out of context. I enjoy Haralds direct language.
I am shure he did not mean it insultive.

But please understand people who speak a different language might
feel insulted and bite back.

Speaking in an international and multicultural society need respecting
eachother - not shooting on first sight.

Regards,
Peter and Karin Dambier


Scott Hollenbeck wrote:
> The IESG has received a request from Harald Alvestrand to approve an RFC
> 3683 PR-action  ("posting rights" action) for JFC (Jefsey) Morfin as a
> result of a pattern of prior warning and posting rights suspensions for
> off-topic postings to the LTRU working group and ietf-languages mailing
> lists that have not produced a change in behavior.  This behavior has been
> characterized as a "denial-of-service" attack to disrupt the
> consensus-driven process as described in Section 1 of RFC 3683.  A timeline
> of warnings and posting rights suspensions related to this request is
> included below.
> 
> The IESG will consider this request.  If approved, the PR-action described
> in Section 2 of RFC 3683 includes provisions to allow list administrators to
> suspend Mr. Morfin's posting rights to the LTRU working group and
> ietf-languages mailing list for at least one year.  Maintainers of other
> IETF mailing lists may also remove posting rights to their mailing lists at
> their discretion.
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action.  Please send any comments to the iesg@ietf.org or
> ietf@ietf.org mailing lists by 17 February 2006.
> 
> For the IESG,
> Scott Hollenbeck
> Applications Area Director
> --------------------------
> 
> Private warnings sent for LTRU working group mailing list postings:
> 7 July 2005
> 16 July 2005
> 23 September 2005
> 26 October 2005
> 
> Public warnings and suspensions for LTRU working group and ietf-languages
> mailing list postings:
> 
> 17 March 2005 (ietf-languages warning)
> http://www.alvestrand.no/pipermail/ietf-languages/2005-March/003236.html
> 
> 5 April 2005 (LTRU warning)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg00564.html
> 
> 12 May 2005 (LTRU suspension)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg01737.html
> 
> 26 May 2005 (LTRU warning)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg01897.html
> (Used as basis for 4 July suspension.)
> 
> 15 June 2005 (ietf-languages suspension)
> http://www.alvestrand.no/pipermail/ietf-languages/2005-June/003474.html
> 
> 4 July 2005 (LTRU suspension)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg02532.html
> (Appealed to AD, appeal upheld, new warning given.)
> 
> 5 July 2005 (LTRU warning)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg02548.html
> 
> 15 September 2005 (ietf-languages suspension)
> http://www.alvestrand.no/pipermail/ietf-languages/2005-September/003585.html
> 
> 26 September 2005 (LTRU warning)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg03755.html
> 
> 7 October 2005
> PR-Action request sent to IESG
> http://www1.ietf.org/mail-archive/web/ietf/current/msg38183.html
> 
> 15 October 2005 (LTRU warning)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg03941.html
> 
> 8 November 2005 (LTRU suspension)
> http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html
> (Appealed to AD, appeal denied by AD.)
> 
> 20 November 2005 (ietf-languages suspension)
> http://www.alvestrand.no/pipermail/ietf-languages/2005-November/003811.html
> (Appealed to AD/IESG, appeal denied by IESG, appealed to the IAB.)
> 
> 13 January 2006 (ietf-languages suspension)
> http://www.alvestrand.no/pipermail/ietf-languages/2006-January/003854.html
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 


-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@peter-dambier.de
mail: peter@echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 09:30:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0gEZ-0003BK-1A; Sun, 22 Jan 2006 09:30:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0gEX-0003BF-LD
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 09:30:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22748
	for ; Sun, 22 Jan 2006 09:28:53 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0gNg-00019g-GV
	for ietf@ietf.org; Sun, 22 Jan 2006 09:39:49 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0MEU6QI051427
	for ; Sun, 22 Jan 2006 15:30:06 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Sun, 22 Jan 2006 15:30:06 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <455266647.20060122153006@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <006d01c61f56$c08d44d0$0701a8c0@Puppy>
References: 
	<6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
	<43D35ECF.2090307@zurich.ibm.com>
	<006d01c61f56$c08d44d0$0701a8c0@Puppy>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Adrian Farrel writes:

> If those who would exclude Jefsey from certain lists feel that repeated 30
> day bans are too much work, I suggest they draft a new process that would
> allow them to create longer bans on specific lists.

An alternative would be for them to find new jobs that don't include
this tremendous burden.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 09:52:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0gZg-00019X-Pv; Sun, 22 Jan 2006 09:52:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0gZf-00019P-AM; Sun, 22 Jan 2006 09:52:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24133;
	Sun, 22 Jan 2006 09:50:42 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0gio-0001nG-Qo; Sun, 22 Jan 2006 10:01:39 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k0MEq3Fj028138; 
	Sun, 22 Jan 2006 08:52:04 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id ; Sun, 22 Jan 2006 15:52:02 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550922C0A5@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" 
To: Adrian Farrel , iesg@ietf.org
Date: Sun, 22 Jan 2006 15:52:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc: ietf@ietf.org
Subject: RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I appreciate that Adrian and others do care about not being an
elephant in a chinashop. But I see a very serious risk of going the
otherway where we crawl around as a mouse in-between concrete monuments
and are worried that we (as a mouse) would tilt a 1000 kilo monument.

First of all, the PR action is not a blanket ban from all mailing lists.
I agree it does allow all IETF related mailing list maintainers to ban JFC,
but I trust our mailing list maintainers to not do that without good 
reason. The only help they get by this PR action is that they do not have
to go through a admin process to in fact take action. They get the benefit
of the doubt that as soon as JFC starts to send questionale postings (for
the list admin to evaluate), that they can then block such postings.

If anyone finds that a mailing list maintainer were to ban JFC (or anyone
hit by a PR action) for no good reason at all (say even before JFC has made
any postings), then I feel we should challenge such a list maitainer. But
in case of doubt on appropriate behaviour or misconduct on a list,
the list maintainer gets the benefit of the doubt to ban. That is all that
this bigger hammer is about. This to prevent a DoS on continuous elaborate
discussion if a specific person can or cannot be blocked from a list.

I also am VERY MUCH against yet designing a 3rd hammer for sanctions.
We are the Internet Engineering TF to engineer the Internet and its protocols.
We are not an organisation that wants to be the perfect process-organisation
and where we have more mercy/pitty with anyone than even mother Teresa had.
So in my view we do NOT want to engineer/have sanctions at a fine granularity 
of 3, 20, 100, 1000 (where does it stop) different levels. 

Instead, let us do TECHNICAL WORK .... PLEASE!

Or so is my view.

Thanks, Bert

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On Behalf Of
> Adrian Farrel
> Sent: Sunday, January 22, 2006 14:21
> To: iesg@ietf.org
> Cc: ietf@ietf.org
> Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey)
> Morfin
> 
> 
> I do not support the action against Jefsey Morfin, because the outcome
> would facilitate a ban on all IETF lists without specific cause and
> without recourse. I am not in a position to judge the 
> correctness of a ban
> on the lists explicitly cited but I do not believe that we 
> have witnessed
> behavior that is targeted against the IETF per se, and so a 
> blanket ban is
> inappropriate.
> 
> In my view a full 3683 action would be too harsh.
> 
> I am not sympathetic to the argument that says we only have a 
> large hammer
> so we MUST use it because we can't do nothing.
> 
> If those who would exclude Jefsey from certain lists feel 
> that repeated 30
> day bans are too much work, I suggest they draft a new 
> process that would
> allow them to create longer bans on specific lists.
> 
> Adrian
> ----- Original Message ----- 
> From: "Brian E Carpenter" 
> To: "Sam Hartman" 
> Cc: "John C Klensin" ; "Scott Hollenbeck"
> ; ; 
> Sent: Sunday, January 22, 2006 10:30 AM
> Subject: Re: Does the IESG have the authority to do less than 3683?
> 
> 
> > fwiw, my feeling is that if we did bend the rules that way,
> > we'd be at strong risk of an appeal. I think the rules are
> > in a bit of a mess.
> >
> >      Brian
> >
> > Sam Hartman wrote:
> > >>>>>>"John" == John C Klensin  writes:
> > >
> > >
> > >     John> For whatever it is worth, I want to remind the 
> IESG that,
> > >     John> before there was RFC 3683, there was a notion, 
> not only of
> > >     John> 30 day suspensions, but of exponential (or other rapidly
> > >     John> increasing series) back-off.  If someone is 
> being severely
> > >     John> disruptive on a particular list, it would seem 
> reasonable to
> > >     John> me for the relevant AD to authorize a 60 day 
> suspension if a
> > >     John> 30 day one is ineffective, a 120 day suspension 
> if that is
> > >     John> ineffective, and so on.  The nature of that 
> arithmetic is
> > >     John> such that someone could, with sufficient 
> repeated disruptive
> > >     John> behavior, find themselves rather effectively 
> banned for the
> > >     John> effective duration of a WG.  If the IESG believes that a
> > >     John> formal RFC3933 experiment is needed to do that, 
> then let's
> > >     John> write down and run that experiment.  But, until we have
> > >     John> tried the above --and any other plausible actions we can
> > >     John> think of-- let's save the 3683 actions for those whose
> > >     John> behavior is more clearly inappropriate and 
> non-constructive
> > >     John> than Jefsey's.
> > >
> > >
> > > Hi, John.  The prevailing view on the IESG seems to be that the
> > > combination of RFC 3683 and 3934 actually took away our ability to
> > > approve suspensions greater than 30 days but short of a PR action.
> > > Others seem to believe that while we might want to fix 
> that, we should
> > > deal with this matter first.
> > >
> > > can you see a reading of 2418 as amended, 3934 and 3683 
> together that
> > > give the IESG the power to approve a longer suspension?
> > >
> > > _______________________________________________
> > > Ietf mailing list
> > > Ietf@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ietf
> > >
> >
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> >
> >
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 10:23:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0h4J-0001Be-Fa; Sun, 22 Jan 2006 10:23:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0h4F-0001BT-I5; Sun, 22 Jan 2006 10:23:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25639;
	Sun, 22 Jan 2006 10:22:19 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0hDP-0002Ym-BQ; Sun, 22 Jan 2006 10:33:16 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1F0h3x-000Kv0-56; Sun, 22 Jan 2006 10:23:29 -0500
Date: Sun, 22 Jan 2006 10:23:27 -0500
From: John C Klensin 
To: Brian E Carpenter , Sam Hartman 
Message-ID: <39A121894B380434DAC9BB4E@p3.JCK.COM>
In-Reply-To: <43D35ECF.2090307@zurich.ibm.com>
References: 
	 <6B00F5E2964A4A00C0C1323C@p3.JCK.COM>
	 <43D35ECF.2090307@zurich.ibm.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 995b2e24d23b953c94bac5288c432399
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: Does the IESG have the authority to do less than
 3683?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--On Sunday, 22 January, 2006 11:30 +0100 Brian E Carpenter
 wrote:

> fwiw, my feeling is that if we did bend the rules that way,
> we'd be at strong risk of an appeal. I think the rules are
> in a bit of a mess.

Brian,

I'm disturbed by several aspects of this, most of which have
little or nothing to do with Jefsey, his behavior, and what
should be done about it...

() While it is not an excuse or precedent for this case, the
IESG has a long history, some of it fairly recent, for far more
creative interpretations of assorted rules and statements in
written documents than this would call for.  I assume it is not
what you meant by the above, but, if our real criteria for what
the IESG (or IAOC, or IAB, or particular individuals) can or
cannot do are levels of "risk of appeal" or "risk of recall",
then we are in a much bigger mess than our rules.

(2) We seem to be having a pattern of problems with all of our
procedures.   It appears to me that we are patching things
without regard to the systems in which those things are embedded
or the side-effects of the patches.  We have seen it, IMO, with
our apparent inability to get IPR policies right without a new
iteration starting as soon as the latest version is published,
with  the exclusion of IAB and IESG members from those who can
initiate recalls, and with, apparently, replacing a series of
graduated moves with the huge gap between 30 day suspensions and
the rather sweeping and nominally permanent 3683 action.  

In at least the latter two cases, I believe the outcome is
accidental.  Certainly there was no evidence during Last Call on
the relevant documents that the community was aware enough of
the consequences and tradeoffs involved to discuss them.
Speaking personally, I know I read the drafts that became 3683
on the assumption that it added one more tool to the collection
(and hence was harmless at worst) rather than that it excluded
any pre-existing options.  I assume others did too.

Perhaps this demonstrates where, as a community, we are skilled
and where we are not.  Perhaps we need to do as good a job of
looking at potential consequences and side effects of procedural
changes as 
we try to do for protocols.  Whatever is needed, it is becoming
fairly clear that the focus on the next narrowly-defined problem
or the next patch in {ipr, newtrk, pesci, techspec} is a good
recipe for making more mistakes of this type.

(3) One of the consequences of several of the situations in
which we have found ourselves is that we seem to be replacing
assumptions of good sense and the exercise of discretion with an
increasing array of rules.  I consider that undesirable in its
own right.  Worse, the rule-making process seems to always have
us fighting the previous war.  However, operating on the basis
of giving flexibility and discretionary authority to, e.g., the
IESG, IAOC, or other "leadership", requires that those people be
exceptionally sensitive to the views and temper of the
community.  If that sensitivity does not appear to be present;
if, instead, the community sees signs of "we can ignore some
rules but interpret others narrowly as it suits our convenience"
or the arrogance of decision-making based on "if we don't like
that idea or find it threatening, it doesn't have a chance" or
"if they don't like it, they can recall us",  or "let's divide
this up into enough separate discussions to prevent anyone from
getting a complete picture so we can claim support for whatever
we feel like doing", then more rules, many of them probably
proposed or applied as hasty patches, are almost inevitable.
And thus we spiral downhill.   

(Disclaimer: I do not have any particular person's behavior or
any particular event in mind in the paragraph above, only what
appear to me to be patterns over the last several years.)

(4) As for the present issue, I observe, as have others, that we
have now spent more energy, and created more disruption,
debating the appropriateness and severity of Jefsey's behavior,
and whether a particular response is appropriate, than the
behavior itself has spent or caused.  In a way, the comments and
postings have been helpful: we have had much of the conversation
about the appropriate application of 3683, and the lack of
in-between measures, that, in retrospect, should have occurred
when we started to make changes.

So, let me make a few suggestions for getting us unstuck and
back to useful work.

(i) If Jefsey's recent behavior justifies it, generate more 30
day suspensions.

(ii) Let's establish a convention (not a rule -- we would just
screw it up or get tangled in it) that, if a suspension action
is taken against someone whose native language is not English,
we attempt to deliver the suspension notice/ complaint in that
person's language as well as English if reasonably feasible.  We
should not, if possible, have people suspended for reasons they
don't understand or can later claim they don't understand.  On
the other hand, we have accepted (even if Jefsey has not) that
the ability to communicate in English is a practical necessity
for participation in IETF and should not paralyze ourselves by
trying to apply this particular courtesy.

(iii) Again, as a convention, let's agree that, if someone is
suspended more than once for the same basic pattern of behavior,
that the suspensions should explicitly note the history of one
or more prior ones and warn that the community will not tolerate
behavior that results in serial suspensions indefinitely.
Multiple suspensions and such a warning should not become
requirements for taking a 3683 action (or any intermediate
action), but represent a reasonable courtesy and attempt to get
the behavior adjusted, which we should certainly prefer to
ever-more-drastic sanctions.  We should not get ourselves into
the position of spelling out what penalties will be imposed of
the behavior recurs: as others have pointed out, the purpose of
all of these procedures is not to punish offenders, or to permit
offenders to measure the advantages of the behavior against the
potential punishment, but to permit and facilitate the
community's getting work done.

While I am sympathetic to Bert's position that more types of
sanctions would actually hurt us, I'd prefer to have some
intermediate levels of options for another reason.  3683 is not,
as I read it, intended to become a legal proceeding, with the
entire IETF acting as jury and discussing, not only the action
but the character of the presumed offender.  My personal
perspective is that I'd like to see 3683 actions under only two
circumstances.  (i) some sequence of actions have been taken
which are so egregious and so obviously motivated by malice
toward individuals or the community that the community recoils
in collective outrage (or should do so) or (ii) there has been a
repeated pattern of suspensions for similar behavior from
different mailing lists and by different people, that the claim
can be made and supportive that the individual involved is
consistently disruptive and an IETF-wide response is in order.
Frankly, in the latter case, I'm not convinced that the
individual involved has any "right" to disrupt the IETF list
with his or her defense.  This business of letting someone who
has been disruptive try to turn the issue into a personality
matter started by the person who finally develops the energy to
come forward and request a strong action is not healthy for any
of us.

(iv) Let us, quickly, follow up on some of the suggestions that
have been made recently to create intermediate steps by
generating a draft, under the RFC 3933 model, to permit some
intermediate measures.  I'm particularly fond of reinstating the
authority of a WG Chair, with AD approval and subject to appeals
that do not suspend the action while they are being
investigated, to apply exponential back-off, if only because 
   suspend for 30 days
   have new incidents on days 31 and 32.
   spend two weeks going through the warn-review-and-suspend
proces again
   suspend for 30 days
   loop
model is intolerably inefficient if work is really being
disrupted. 

If we care, we should be able to have such procedures in place
under the 3933 model within 30 days.  If people are worried that
we also need a mechanism for pushing back on repetitive appeals,
someone should start working on an experimental draft there too.

Note that, if we get such a procedure in place 25 days from now,
and then find a need to apply them 32 days from now based on
prior suspensions, nothing is being done retroactively.

And then, sometime, we need to figure out why we keep doing
these things to ourselves procedurally and try to cure it.

     john


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 10:45:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0hP9-0007Xs-Kh; Sun, 22 Jan 2006 10:45:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0hP5-0007Wv-6i
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 10:45:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26838
	for ; Sun, 22 Jan 2006 10:43:50 -0500 (EST)
Received: from gecko.sbs.de ([194.138.37.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0hYE-00036x-Lm
	for ietf@ietf.org; Sun, 22 Jan 2006 10:54:48 -0500
Received: from mail2.sbs.de (localhost [127.0.0.1])
	by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k0MFj8JS004088;
	Sun, 22 Jan 2006 16:45:08 +0100
Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net
	[157.163.133.201])
	by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0MFj8PZ025502;
	Sun, 22 Jan 2006 16:45:08 +0100
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by
	fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 22 Jan 2006 16:45:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 22 Jan 2006 16:45:07 +0100
Message-ID: 
Thread-Topic: Location Types Registry
Thread-Index: AcYfIolmsb6sqBKBQsijq0N/WHdKpwANRV8g
From: "Tschofenig, Hannes" 
To: "Frank Ellermann" , 
X-OriginalArrivalTime: 22 Jan 2006 15:45:07.0961 (UTC)
	FILETIME=[D22A2690:01C61F6A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: quoted-printable
Cc: geopriv@mail.apps.ietf.org
Subject: AW: Location Types Registry
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

hi frank,=20

> Tschofenig, Hannes wrote:
>=20
> > The values listed in the "Location Types Registry" document
> > are not displayed to the user. As such, we don't cover
> > internationalization support.
>=20
> That wasn't clear from the draft under discussion.  It should
> get some "I18N considerations" explaining why that's no issue.

we will reflect this aspect.

>=20
> > If there are better definitions please let us know.
>=20
> Maybe the WiKi dictionary has a category "location" (?)

i search for a while and found interesting pages but unfortuately not
related to this topic.=20

i got the impression that some folks had very specific suggestions
already in mind in order to provide constructive feedback.=20

> =20
> > We thought that FCFS would be an acceptable policy. Some
> > people had a different view about it.
>=20
> Not limited to registration request DoS attacks on IANA, yes.
>=20
> > Fine. I have no problems changing it to expert review.
>=20
> Where do you expect to find volunteers for an expert review
> of a location dictionary ?  From two "expert review" lists I
> know (langtags and charsets) one works at the moment, I'm
> not sure about the other. =20
>=20
> "Expert review" is essentially a filter protecting IANA from
> some really bad ideas, but it's also an exercise in TINSTAAFL
> - set up mailing list, appoint reviewer, handle appeals, etc.
do you think expert review is ok? (just to understand you right)

i thought about the Geopriv working group or its designated successor.

ciao
hannes

>=20
>                                Bye, Frank
>=20
>=20
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 11:08:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0hlA-0005h1-4W; Sun, 22 Jan 2006 11:08:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0hl7-0005gf-Jd; Sun, 22 Jan 2006 11:08:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28481;
	Sun, 22 Jan 2006 11:06:36 -0500 (EST)
Received: from [204.9.221.21] (helo=thingmagic.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0huF-0003pU-Uj; Sun, 22 Jan 2006 11:17:34 -0500
Received: from [66.30.121.250] (account margaret HELO ceili)
	by thingmagic.com (CommuniGate Pro SMTP 5.0.1)
	with ESMTPSA id 699201; Sun, 22 Jan 2006 11:07:44 -0500
From: "Margaret Wasserman" 
To: "'JFC \(Jefsey\) Morfin'" , 
Date: Sun, 22 Jan 2006 11:07:43 -0500
Message-ID: <030301c61f6d$fa9e1c00$0402a8c0@instant802.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <6.2.3.4.2.20060120112906.0547e7d0@mail.jefsey.com>
Thread-Index: AcYdt3VAo8Q9YGXNQW2por3mTOnrYABtW+Qw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org
Subject: RE: Mr. Smith goes to the IETF
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Hi Jefsey,

In this post and in at least one other recent post you talk about
filibustering on various mailing lists.  I would like to make sure that I
understand what you are talking about, because this is very important to my
assessment of the proposed PR-Action. Prior to these posts, I did not
understand why you were making so many clearly off-topic posts on these
lists, but I did not assume that you were intentionally attempting to
disrupt the work of the IETF.

In the U.S. filibustering is a tactic used in the U.S. Senate that abuses a
loophole in the Senate rules to _intentionally_ block the work of the senate
for some period of time.  Filibustering is not a democratic right, and it is
not a tactic that, IMO, should be used, encouraged or allowed on IETF
mailing lists. 

I have read this post and other recent posts of yours as admissions that you
are _intentionally_ disrupting the work of the ietf-languages@iana.org list
and the LTRU WG mailing list via a tactic similar to filibustering.  Is that
a correct interpretation of your messages?  

Margaret


> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On 
> Behalf Of JFC (Jefsey) Morfin
> Sent: Friday, January 20, 2006 5:59 AM
> To: ietf@ietf.org
> Cc: iesg@ietf.org
> Subject: Mr. Smith goes to the IETF
> 
> As far I am concerned, the PR-action engaged against me by 
> Harald Alvestrand is per se of no interest. I just have some 
> general comments and one question about it, I will address separately.
> 
> What is more interesting is how the IETF and the Internet 
> community may benefit from the three issues I raise: 
> multilingualism, ethic and user QA. The three of them have an 
> architectural impact (the IAB should be able to address 
> through the now silent IAB-discuss) and are part of a wide 
> "governance" change which question the RFC 3935 IETF mission. 
> These three questions (ethic and user QA being related in
> part) are now under final escalation to the IAB.
> 
> 
> At the present time, published contributions (Sam Hartman, 
> John Klensin, Harald Alvstrand) agree with me: filibustering, 
> however a democratic US invention, is a pest. IETF should do 
> everything not to need it (much more efficient than to fight 
> it). I think my contributions are of interest to consider in 
> this area. I suppose all the PESCI member are already on the 
> two copied lists.
> 
> 
> 1. due to the importance of the "war on culture" 
> "internationalization" represents, I was proposed support and 
> funding to oppose it. The problem are an architectural layer 
> violation, a narrow vision and a lack of information. Not a 
> lack of competence. To kill the IETF for that was inadequate 
> (or premature). I am already a problem, would we have been 
> two or three of us ... Had we been 200 as I was proposed ... 
> I have computed that $ 20.000 are enough to block the IETF. 
> This can be discussed, but this is something we should 
> urgently consider, when political, commercial and civil 
> rights interests make the IETF, and most of all the IANA, a 
> key target (the USG says for sale- may be to protect it?).
> 
> I refused it.
> 
> 2. I proposed Brian Carpenter to get "would be filibusters" a 
> special status in the consensus process as "user QA rep". 
> With rights and duties.
> 
> This was denied.
> 
> 3. I proposed an evolution in the WG working method. In using 
> position links: every contributor expresses his positions on 
> a page he can update as the debate goes. I proposed this to 
> the GNSO WG-Review which supported it and I use it in some 
> work. This filters out "standard" participants' blabla. It 
> permits everyone to stay, every concept to be documented and 
> progressively trimmed, and external experts to call in. 
> Consensus is when all the positions are equivalent or have 
> identified they cannot agree. Consensus review is easy and 
> informative.
> 
> This was not considered.
> 
> 4. I have engaged an IESG, and now an IAB appeal, to know if 
> this kind of debate is, or not, part of  the IETF. IESG said 
> "no". I want a confirmation by the IAB (so no one can claim 
> there is a conflict) before engaging into the organisation of 
> a solution. My solution is a dedicated TF sharing into the 
> Internet standard process and reviewing the Charters and the 
> Drafts during the LC, or upon request. That TF would 
> permanently interact with the users. I think it can be 
> engaged in ethic (COI and societal impact) and "governance" 
> issues. The interest is that there can be several TF until 
> one emerges as a stable and productive solution. I would 
> favor it to be eventually part of ISOC and to interface (and 
> protect the IETF from) the IGF.
> 
> This is under final consideration. Interested people can 
> share in a Draft.
> 
> 
> This IETF has to understand that the Internet has become mature. 
> Mature for a product - and specially for a communication 
> technology - is when the technology is no more the leader but 
> when usage decides. 
> This is what they call "governance". This means that the IGF 
> is going to deliver scores of Jefseys. Engineers who can code 
> user response as per the user' requests (far more complex 
> than what IETF does today). 
> The NSF GENI project will not be alone.
> 
> I still consider there is a difference between specifying 
> (Charter) and documenting (WG work). But most, because they 
> will be from Lobbies or Govs, will not bother. This will lead 
> to balkanization and to IETF bottle necks. Already, I saw 
> that with the lobby driven
> WG-LTRU: the Charter was not considered. WG Consensus by 
> exhaustion, IETF consensus by disinterest and IESG consensus 
> by impossible knowledge of everything lead to dispute like 
> the one I have with Harald. There will be scores of them soon 
> if we do not find a structural solution.
> 
> jfc
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 11:50:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0iQ1-0001lX-5U; Sun, 22 Jan 2006 11:50:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0iPy-0001lS-0X
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 11:50:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01199
	for ; Sun, 22 Jan 2006 11:48:48 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0iZ8-00052H-Lf
	for ietf@ietf.org; Sun, 22 Jan 2006 11:59:47 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F0iPn-0007Vb-TI
	for ietf@ietf.org; Sun, 22 Jan 2006 17:50:08 +0100
Received: from 212.82.251.156 ([212.82.251.156])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Sun, 22 Jan 2006 17:50:07 +0100
Received: from nobody by 212.82.251.156 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Sun, 22 Jan 2006 17:50:07 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Sun, 22 Jan 2006 17:47:58 +0100
Organization: 
Lines: 34
Message-ID: <43D3B73E.2E0B@xyzzy.claranet.de>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 212.82.251.156
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: geopriv@mail.apps.ietf.org
Subject: Re: Location Types Registry
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Tschofenig, Hannes wrote:

> i got the impression that some folks had very specific
> suggestions already in mind in order to provide constructive
> feedback.

One potentially constructive idea I had was to enumerate the
locations.  If the location registry has say 256 slots it's
obvious that it's a resource not designed to get thousands of
entries in various languages.

>> "Expert review" is essentially a filter protecting IANA from
>> some really bad ideas, but it's also an exercise in TINSTAAFL
>> - set up mailing list, appoint reviewer, handle appeals, etc.

> do you think expert review is ok? (just to understand you right

Not sure.  You'd need rules to update entries e.g. for a better
explantion, maybe ways to remove or at least deprecate entries,
and a justification why the registration request "wyoming" for
a fictional location - if I recall that example correctly - is
bogus.

> i thought about the Geopriv working group or its designated
> successor.

Okay, so you have the volunteers for expert review, one problem
solved.  Makes me still wonder why "an entity" - I assume that
could be something I carry with me - should be so indiscreet as
telling that it's now in the "cafe" of a "jail" in an "airport"
or other obscure locations.  That's nobody's business but mine.

                             Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 12:03:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0icG-0004p2-HE; Sun, 22 Jan 2006 12:03:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0icD-0004ou-UE
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 12:02:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01751
	for ; Sun, 22 Jan 2006 12:01:28 -0500 (EST)
Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0ilP-0005Kf-4T
	for ietf@ietf.org; Sun, 22 Jan 2006 12:12:27 -0500
Received: from [192.168.0.41] (pool-141-153-211-136.mad.east.verizon.net
	[141.153.211.136]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id
	k0MH2tMD028434
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Sun, 22 Jan 2006 12:02:56 -0500 (EST)
In-Reply-To: <43D3B73E.2E0B@xyzzy.claranet.de>
References: 
	<43D3B73E.2E0B@xyzzy.claranet.de>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <281F3FC5-F300-435E-A084-8924E93487F8@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
From: Henning Schulzrinne 
Date: Sun, 22 Jan 2006 12:02:53 -0500
To: Frank Ellermann 
X-Mailer: Apple Mail (2.746.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, geopriv@mail.apps.ietf.org
Subject: Re: Location Types Registry
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>
>> i thought about the Geopriv working group or its designated
>> successor.
>
> Okay, so you have the volunteers for expert review, one problem
> solved.  Makes me still wonder why "an entity" - I assume that
> could be something I carry with me - should be so indiscreet as
> telling that it's now in the "cafe" of a "jail" in an "airport"
> or other obscure locations.  That's nobody's business but mine.

In many of the applications, the idea is that the location tells  
*you* where you are (or rather, your mobile device). That way, your  
smart mobile device can decide that a jail cafe is not a good place  
for a private audio conversation, for example, and redirect calls to  
some other locations.





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 12:24:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0ixG-0004RO-VD; Sun, 22 Jan 2006 12:24:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ixE-0004RI-Kf
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 12:24:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03499
	for ; Sun, 22 Jan 2006 12:23:11 -0500 (EST)
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0j6P-00064G-0h
	for ietf@ietf.org; Sun, 22 Jan 2006 12:34:10 -0500
Received: from [192.168.0.102] (ppp-70-244-171-13.dsl.rcsntx.swbell.net
	[70.244.171.13]) (authenticated bits=0)
	by nostrum.com (8.13.4/8.13.4) with ESMTP id k0MHOT5A061792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 22 Jan 2006 11:24:31 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <43D3BFC8.8070909@nostrum.com>
Date: Sun, 22 Jan 2006 11:24:24 -0600
From: Adam Roach 
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Frank Ellermann 
References: 
	<43D3B73E.2E0B@xyzzy.claranet.de>
In-Reply-To: <43D3B73E.2E0B@xyzzy.claranet.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 70.244.171.13 is authenticated by a
	trusted mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, geopriv@mail.apps.ietf.org
Subject: Re: Location Types Registry
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Frank Ellermann wrote:

>Makes me still wonder why "an entity" - I assume that
>could be something I carry with me - should be so indiscreet as
>telling that it's now in the "cafe" of a "jail" in an "airport"
>or other obscure locations.  That's nobody's business but mine.
>

Nobody's business but yours and the people with whom you choose to share 
it. You'll note that this work is coming out of GEOPRIV -- where the 
"PRIV" part of that name stands for "privacy." GEOPRIV has done lots of 
work in making sure that this kind of information ends up only in the 
hands of people you want to have it, and nowhere else (see, e.g., 
draft-ietf-geopriv-common-policy-06).

There are many good use cases in real-time communications that detail 
*why* conveying this kind of information is potentially useful. Going 
into a tutorial on these basic topics seems a bit inappropriate on the 
general list. If you're interested, though, I can point you to a number 
of working group mailing lists where these subjects have been discussed 
thoroughly.

/a

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 13:03:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0jYv-0008Cu-ET; Sun, 22 Jan 2006 13:03:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0jYs-0008A7-PL; Sun, 22 Jan 2006 13:03:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05769;
	Sun, 22 Jan 2006 13:02:04 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0ji3-00073V-Om; Sun, 22 Jan 2006 13:13:04 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0MI3v05021598
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 22 Jan 2006 10:03:58 -0800
Message-ID: <43D3C8E5.8090702@dcrocker.net>
Date: Sun, 22 Jan 2006 10:03:17 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: John C Klensin 
References: 	
	<6B00F5E2964A4A00C0C1323C@p3.JCK.COM>	
	<43D35ECF.2090307@zurich.ibm.com>
	<39A121894B380434DAC9BB4E@p3.JCK.COM>
In-Reply-To: <39A121894B380434DAC9BB4E@p3.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: Does the IESG have the authority to do less than 3683?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> So, let me make a few suggestions for getting us unstuck and
> back to useful work.
> 
> (ii) Let's establish a convention (not a rule -- we would just
> screw it up or get tangled in it) that, if a suspension action
> is taken against someone whose native language is not English,
> we attempt to deliver the suspension notice/ complaint in that
> person's language as well as English if reasonably feasible.  We

This is a well-intentioned suggestion.

However I believe it winds up implying that we have an obligation to translate 
formal IETF language into another language.  At the least, the presence of two 
versions of the notice offer an opportunity for more confusion, not less.  I 
suggest, instead, that the notice / complaint language contain well-reviewed 
boilerplate and that the boilerplate reviews include ease of understanding among 
readers for whom English is a second language.


> (iii) Again, as a convention, let's agree that, if someone is
> suspended more than once for the same basic pattern of behavior,
> that the suspensions should explicitly note the history of one
> or more prior ones and warn that the community will not tolerate
> behavior that results in serial suspensions indefinitely.
> Multiple suspensions and such a warning should not become
> requirements for taking a 3683 action (or any intermediate
> action), but represent a reasonable courtesy and attempt to get
> the behavior adjusted, which we should certainly prefer to

This sounds eminently reasonable.  It leaves us with two mechanisms.

In general, the IETF community can probably juggle two mechanisms that pertain 
to a participation problem.  I'm not so sure it can juggle more.

One mechanism is a 30-day suspension and the other is permanent ban.

The first can be applied repeatedly, unless and until there is a reasonable 
degree of frustration with the offender. Some offenses create that reasonable 
degree in one occurrence.  Others might never trigger it, even with multiple 
suspension.  Community rough consensus will nicely determine that threshold.


>   My personal
> perspective is that I'd like to see 3683 actions under only two
> circumstances.  (i) some sequence of actions have been taken
> which are so egregious and so obviously motivated by malice
> toward individuals or the community that the community recoils
> in collective outrage (or should do so) or (ii) there has been a
> repeated pattern of suspensions for similar behavior from
> different mailing lists and by different people, that the claim
> can be made and supportive that the individual involved is
> consistently disruptive and an IETF-wide response is in order.

Nicely said.  I agree entirely and suggest this language be used for community 
guidance.


> (iv) Let us, quickly, follow up on some of the suggestions that
> have been made recently to create intermediate steps by
> generating a draft, under the RFC 3933 model, to permit some
> intermediate measures.  I'm particularly fond of reinstating the
> authority of a WG Chair, with AD approval and subject to appeals
> that do not suspend the action while they are being
> investigated, to apply exponential back-off, if only because 
>    suspend for 30 days
>    have new incidents on days 31 and 32.
>    spend two weeks going through the warn-review-and-suspend
> proces again
>    suspend for 30 days
>    loop
> model is intolerably inefficient if work is really being
> disrupted. 

Clearly the concern here is valid.  It occurs to me, however, that there is 
another way to view it:

    If someone is going to keep being a repeated problem, quickly after being 
re-instated, then the community will also quickly decide that the person 
warrants permanent removal.  For such people, it is better to get the hassle 
over with sooner, rather than to draw things out.

Exponential backoff merely makes this inevitable outcome take longer.

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 13:39:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0k7K-0000LZ-2l; Sun, 22 Jan 2006 13:39:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0k7H-0000L3-Mb; Sun, 22 Jan 2006 13:39:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07811;
	Sun, 22 Jan 2006 13:37:38 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc11.comcast.net ([63.240.77.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0kGR-00081V-Me; Sun, 22 Jan 2006 13:48:38 -0500
Received: from smailcenter57.comcast.net ([204.127.205.157])
	by comcast.net (sccrmhc11) with SMTP
	id <2006012218384001100qobnje>; Sun, 22 Jan 2006 18:38:55 +0000
Received: from [66.229.53.140] by smailcenter57.comcast.net;
	Sun, 22 Jan 2006 18:38:38 +0000
To: Eliot Lear , Marshall Eubanks 
Date: Sun, 22 Jan 2006 18:38:38 +0000
Message-Id: <012220061838.14198.43D3D12E0009C39600003776220588601400000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
X-Spam-Score: 1.3 (+)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Scott Hollenbeck , ietf@ietf.org,
	ietf-announce@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1994821234=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============1994821234==
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_14198_1137955118_0"


--NextPart_Webmail_9m3u9jl4l_14198_1137955118_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

-------------- Original message -------------- 
From: Eliot Lear  

> Marshall, 
> > I do not support approval of this PR-action. 
> 
> Because.....?? 
> 
Eliot-
I don't mean any offense by this but the "Because" is the whole problem of these PR-Actions.  Somehow "rough concensus" has turned into "the IESG is the jury and the IETF members have to make convincing arguments one way or the other".  The IESG need not be convinved of anything and the "because" is not anyone's bussiness but yours (and is quite frankly off topic unless you start a WG called "why I don't think so-and-so should play here anymore").
I mean really, has anyone ever had their opinion changed because of something someone said during these PR-Actions?  Because if you have you certainly didn't share that with the rest of us (making your change of heart null unless you mailed it to the IESG).
Motion.  Vote.  NO CROSS TALK.  Decide.  Move on.
Or just admit merely controlling who gets to speak isn't satisfying enough, you must also convince everyone you are right   For that's the only reason for these absurdities as I'm sure you already know.
--NextPart_Webmail_9m3u9jl4l_14198_1137955118_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit



-------------- Original message -------------- 
From: Eliot Lear <lear@cisco.com> 

> Marshall, 
> > I do not support approval of this PR-action. 
> 
> Because.....?? 
> 
Eliot-


I don't mean any offense by this but the "Because" is the whole problem of these PR-Actions.  Somehow "rough concensus" has turned into "the IESG is the jury and the IETF members have to make convincing arguments one way or the other".  The IESG need not be convinved of anything and the "because" is not anyone's bussiness but yours (and is quite frankly off topic unless you start a WG called "why I don't think so-and-so should play here anymore").


I mean really, has anyone ever had their opinion changed because of something someone said during these PR-Actions?  Because if you have you certainly didn't share that with the rest of us (making your change of heart null unless you mailed it to the IESG).


Motion.  Vote.  NO CROSS TALK.  Decide.  Move on.


Or just admit merely controlling who gets to speak isn't satisfying enough, you must also convince everyone you are right   For that's the only reason for these absurdities as I'm sure you already know.


--NextPart_Webmail_9m3u9jl4l_14198_1137955118_0--


--===============1994821234==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1994821234==--




From ietf-bounces@ietf.org Sun Jan 22 13:44:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0kCs-00030Z-Ep; Sun, 22 Jan 2006 13:44:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0kCp-00030U-KI
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 13:44:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08282
	for ; Sun, 22 Jan 2006 13:43:21 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0kM1-0008EF-Bx
	for ietf@ietf.org; Sun, 22 Jan 2006 13:54:21 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F0kCY-0004Mc-55
	for ietf@ietf.org; Sun, 22 Jan 2006 19:44:34 +0100
Received: from 212.82.251.156 ([212.82.251.156])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Sun, 22 Jan 2006 19:44:34 +0100
Received: from nobody by 212.82.251.156 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Sun, 22 Jan 2006 19:44:34 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Sun, 22 Jan 2006 19:42:36 +0100
Organization: 
Lines: 36
Message-ID: <43D3D21B.2CE5@xyzzy.claranet.de>
References: 
	<43D3B73E.2E0B@xyzzy.claranet.de> <43D3BFC8.8070909@nostrum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 212.82.251.156
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: geopriv@mail.apps.ietf.org
Subject: Re: Location Types Registry
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Adam Roach wrote:

> You'll note that this work is coming out of GEOPRIV -- where
> the "PRIV" part of that name stands for "privacy."

That's not more obvious in the "registry" draft.  Joe Abley
posted a pointer to draft-ietf-simple-rpid-08 for the missing
context, and there I found lists of locations and moods.  The
latter appears to be a list of smileys (without the smileys),
and it's clear that the user picks what his or her mood is -
a device can't know this, and it better doesn't try to guess
the mood of its user.

For the locations it's not so clear.  Why should a device tell
me that I'm in the "cafe" of a "jail" in an "airport", I would
know this.  And why would I tell my device where it is, all it
needs to know is "be quiet" or "make as much noise as you can",
different ways to attract my attention depending on where I am.

> There are many good use cases in real-time communications
> that detail *why* conveying this kind of information is
> potentially useful. Going into a tutorial on these basic
> topics seems a bit inappropriate on the general list.

Maybe the "registry" draft could be integrated into a draft
where that's immediately clear, or bound to a list of special
purposes where devices need to know why "cycle" and "water"
are different - at first glance both could fall into a category
"now isn't an optimal time to talk, but it's not impossible".

Without context a "location dictionary" as Internet standard
appears to be an odd idea.  And a list of smileys without the
smileys removes the fun - if the moods get their own registry.

                          Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 14:14:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0kfG-00036a-1S; Sun, 22 Jan 2006 14:14:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0kfC-00036V-Uh
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 14:14:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10501
	for ; Sun, 22 Jan 2006 14:12:41 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0koM-0000ef-J0
	for ietf@ietf.org; Sun, 22 Jan 2006 14:23:41 -0500
Received: from raven.songbird.com ([67.114.146.60])
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0MJERgR006095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sun, 22 Jan 2006 11:14:27 -0800
Received: from localhost (localhost [127.0.0.1])
	by raven.songbird.com (8.13.4/8.13.4) with ESMTP id k0MJDgD7026831
	for ; Sun, 22 Jan 2006 11:13:42 -0800
Date: Sun, 22 Jan 2006 11:13:42 -0800
From: kent crispin 
To: ietf@ietf.org
Message-ID: <20060122191342.GA26688@raven.songbird.com>
Mail-Followup-To: ietf@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: kent@raven.songbird.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Sun, Jan 22, 2006 at 12:20:15PM +0100, Anthony G. Atkielski wrote:
> 
> Eventually you end up with multiple groups on a list: those who
> irritate others, those who want to censor the ones they find
> irritating, and--sometimes--a minority of people who are grown-up
> enough to stay out of both of these groups and continue their normal
> work, cheerfully ignoring the children at play on the list.
>
> > When this happens, I've only ever seen two possible outcomes.  Either
> > the smoke generators are ejected, or the productive members leave.
> 
> There's a third possible outcome: The productive members are smart,
> they ignore the smoke, and they continue to work efficiently. 

A fundamental aspect of group decision making is defining the group making
the decision.  Uncoordinated individual procmail rulesets don't cut it if
there is any kind of accountability requirement. 

IETF lists are frequently required to make group decisions, and those
decisions do have an accountability requirement.  Decisions have to stand on the
public record, not the filtered view of some hypothetical elite.  When an IESG
member examines the archive of a list to review some decision, that review
won't tell the IESG member who is filtering who.  

I've been on lists where I thought there was limited and mostly intelligent
traffic, until I looked at the archive. 

> But the
> productive members do have to be _smart_, and unfortunately that's
> more the exception than the rule, even on lists where the members like
> to believe themselves smart.

Would that things were so simple.

-- 
Kent Crispin 
kent@icann.org    p: +1 310 823 9358  f: +1 310 823 8649
kent@songbird.com SIP: 81202@fwd.pulver.com


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 14:21:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0kmE-00054Q-57; Sun, 22 Jan 2006 14:21:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0kmB-00054L-GN
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 14:21:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10978
	for ; Sun, 22 Jan 2006 14:19:53 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.194])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0kvN-0000tB-QP
	for ietf@ietf.org; Sun, 22 Jan 2006 14:30:54 -0500
Received: by zproxy.gmail.com with SMTP id i11so781656nzh
	for ; Sun, 22 Jan 2006 11:21:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=eOk26cF7v20vMBVbrdOVx6+T+hjTq1CMzgiJWaYO1YnAZebd8JWePPSZWlYpAbqrlsRf8jmB0asrpdZyw3dMT/zGI0r4ljf09XUA62HCpEExXpGREcq2BoPMCLOOizpC2njUlE8UtzJQsgCjY0yR6zvTTbwOEYi7MDO7RwaIF1c=
Received: by 10.65.249.11 with SMTP id b11mr124962qbs;
	Sun, 22 Jan 2006 11:14:11 -0800 (PST)
Received: by 10.65.250.3 with HTTP; Sun, 22 Jan 2006 11:14:11 -0800 (PST)
Message-ID: <955ba8bb0601221114h685054e6l7576d46de3b6ec46@mail.gmail.com>
Date: Mon, 23 Jan 2006 00:44:11 +0530
From: Neil Harwani 
To: ietf@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Subject: suggestion on distributed systems
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1775504111=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1775504111==
Content-Type: multipart/alternative; 
	boundary="----=_Part_6358_20442026.1137957251152"

------=_Part_6358_20442026.1137957251152
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I am not sure whether this idea that I am about to write has been
implemented before or not but it has crossed my mind so I am writing it to
you all. Grid / distributed computing is being done these days via availing
of services or giving some services as an application in operating systems.
What I want to propose is what if every operating system which for example
has a networking stack implemented in it, in the same way support for grid
computing / distributed computing is built into it and a separate internet
layer manages data transfer to be processed to OSes which are free.

My suggesionts:
1. Have a variable system built into all OSes which have internet interface
which can allocate space and resources as per what amount of space and
resources are free on the OS.
2. Let a separate new internet layer decide from where to pull data and
where to be put on which system where there is space. This could be
auotmatically encrypted and sent over the net and whereever there is free
space it can put up to be processed or delivered as a service from a
webserver. This same layer based on priorities of the data to be processed
or delivered on net as per required could also decide on criticality and
send it to free systems on internet. I would like to differentiate between
caching and this concept of mine. In caching we are keeping a server to
cache regularly used data but here we have a built in container / system on
every OS on net. Here even the container can study its network and get
trends and fetch the data from required servers and locally keep copies.
Another advantage over caching would be same container could be used for
procesing which is not the function of a cache server.

Example : Suppose a server of paypal has to process millions of records
every month. If a high percentage of this processing is encrypted and sent
to container on various systems running on internet, the same work can be
done with less powerfull paypal servers.

Advantages:
Large saving of bandwidth internationally
Lessening on loads of major servers.
Cheaper and less powerful servers could be put up on net

Kindly pardon me if this has been implemented already. I am a computer
science student about to complete his studies in a few months so I am not
aware of all developments that have taken place. I would be happy to have
your suggestions and feedback.

--
Thanking you,
Neil Harwani,
BE (Civil)
L D College of Engineering, Ahmedabad
MCA
ICFAI School of Information Technology,
Hyderabad

------=_Part_6358_20442026.1137957251152
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


I am not sure whether this idea that I am about to write has been impl=
emented before or not but it has crossed my mind so I am writing it to you =
all. Grid / distributed computing is being done these days via availing of =
services or giving some services as an application in operating systems. Wh=
at I want to propose is what if every operating system which for example ha=
s a networking stack implemented in it, in the same way support for gr=
id computing / distributed computing is built into it and a separate intern=
et layer manages data transfer to be processed to OSes which are free.



 


My suggesionts:


1. Have a variable system built into all OSes which have internet inte=
rface which can allocate space and resources as per what amount of space an=
d resources are free on the OS.


2. Let a separate new internet layer decide from where to pull data an=
d where to be put on which system where there is space. This could be auotm=
atically encrypted and sent over the net and whereever there is free space =
it can put up to be processed or delivered as a service from a webserver. T=
his same layer based on priorities of the data to be processed or delivered=
 on net as per required could also decide on criticality and send it to fre=
e systems on internet. I would like to differentiate between caching a=
nd this concept of mine. In caching we are keeping a server to cache regula=
rly used data but here we have a built in container / system on every OS on=
 net. Here even the container can study its network and get trends and fetc=
h the data from required servers and locally keep copies. Another advantage=
 over caching would be same container could be used for procesing whic=
h is not the function of a cache server. 



 


Example : Suppose a server of paypal has to process millions of record=
s every month. If a high percentage of this processing is encrypted and sen=
t to container on various systems running on internet, the same work can be=
 done with less powerfull paypal servers.



 


Advantages:


Large saving of bandwidth internationally


Lessening on loads of major servers.


Cheaper and less powerful servers could be put up on net


 


Kindly pardon me if this has been implemented already. I am a computer=
 science student about to complete his studies in a few months so I am not =
aware of all developments that have taken place. I would be happy to h=
ave your suggestions and feedback.


-- 
Thanking you,
Neil Harwani,
BE (Civil)L D College of Engineering, Ahmedabad
MCA
ICFAI School of Informati=
on Technology,
Hyderabad 


------=_Part_6358_20442026.1137957251152--


--===============1775504111==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1775504111==--




From ietf-bounces@ietf.org Sun Jan 22 14:41:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0l5j-0002Gd-5V; Sun, 22 Jan 2006 14:41:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0l5h-0002GY-Kx
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 14:41:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12422
	for ; Sun, 22 Jan 2006 14:40:02 -0500 (EST)
Received: from lizzard.sbs.de ([194.138.37.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0lEs-0001TQ-Lj
	for ietf@ietf.org; Sun, 22 Jan 2006 14:51:03 -0500
Received: from mail2.sbs.de (localhost [127.0.0.1])
	by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k0MJfMkf001116;
	Sun, 22 Jan 2006 20:41:22 +0100
Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net
	[157.163.133.201])
	by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k0MJfMiQ026944;
	Sun, 22 Jan 2006 20:41:22 +0100
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by
	fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 22 Jan 2006 20:41:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 22 Jan 2006 20:39:22 +0100
Message-ID: 
Thread-Topic: Location Types Registry
Thread-Index: AcYfhDnc9FuqC7VeTOaVZi8zn4juqQABTJsQ
From: "Tschofenig, Hannes" 
To: "Frank Ellermann" , 
X-OriginalArrivalTime: 22 Jan 2006 19:41:21.0822 (UTC)
	FILETIME=[D271B3E0:01C61F8B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: quoted-printable
Cc: geopriv@mail.apps.ietf.org
Subject: AW: Location Types Registry
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

hi frank,=20

please find a few comments below:=20

> Adam Roach wrote:
>=20
> > You'll note that this work is coming out of GEOPRIV -- where
> > the "PRIV" part of that name stands for "privacy."
>=20
> That's not more obvious in the "registry" draft.  Joe Abley
> posted a pointer to draft-ietf-simple-rpid-08 for the missing
> context, and there I found lists of locations and moods.  The
> latter appears to be a list of smileys (without the smileys),
> and it's clear that the user picks what his or her mood is -
> a device can't know this, and it better doesn't try to guess
> the mood of its user.
>=20
> For the locations it's not so clear.  Why should a device tell
> me that I'm in the "cafe" of a "jail" in an "airport", I would
> know this.  And why would I tell my device where it is, all it
> needs to know is "be quiet" or "make as much noise as you can",
> different ways to attract my attention depending on where I am.

the end host might obtain this information using dhcp-civic.=20

there are, however, many proprietary ways if you take a look at the
context aware networking literature.

note: these aspects are all not part of a document that creates a
registry.=20
there are other documents that discuss these aspects since multiple
protocols/extensions need to work together in order to provide this
functionality.=20

>=20
> > There are many good use cases in real-time communications
> > that detail *why* conveying this kind of information is
> > potentially useful. Going into a tutorial on these basic
> > topics seems a bit inappropriate on the general list.
>=20
> Maybe the "registry" draft could be integrated into a draft
> where that's immediately clear, or bound to a list of special
> purposes where devices need to know why "cycle" and "water"
> are different - at first glance both could fall into a category
> "now isn't an optimal time to talk, but it's not impossible".
>=20
> Without context a "location dictionary" as Internet standard
> appears to be an odd idea.  And a list of smileys without the
> smileys removes the fun - if the moods get their own registry.

have you read, for example, the dhcp-civic draft? do you think it is
difficult to understand what the document does and how the values in the
location type registry are used? it is not uncommon to split one draft
into multiple documents.=20

ciao
hannes

>=20
>                           Bye, Frank
>=20
>=20
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 14:46:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0lAc-0002a2-JA; Sun, 22 Jan 2006 14:46:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0lAa-0002Zv-Ib
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 14:46:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12581
	for ; Sun, 22 Jan 2006 14:45:06 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0lJl-0001Ya-Vg
	for ietf@ietf.org; Sun, 22 Jan 2006 14:56:07 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0MJl32k014530
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Sun, 22 Jan 2006 11:47:04 -0800
Message-ID: <43D3E10E.5020904@dcrocker.net>
Date: Sun, 22 Jan 2006 11:46:22 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: ietf@ietf.org
References: <20060122191342.GA26688@raven.songbird.com>
In-Reply-To: <20060122191342.GA26688@raven.songbird.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 1.0 (+)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Subject: Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

kent crispin wrote:
> On Sun, Jan 22, 2006 at 12:20:15PM +0100, Anthony G. Atkielski wrote:
>> Eventually you end up with multiple groups on a list: those who
>> irritate others, those who want to censor the ones they find
>> irritating, and--sometimes--a minority of people who are grown-up
>> enough to stay out of both of these groups and continue their normal
>> work, cheerfully ignoring the children at play on the list.
 >
> A fundamental aspect of group decision making is defining the group making
> the decision.  Uncoordinated individual procmail rulesets don't cut it if
> there is any kind of accountability requirement. 


The view that individual rulesets provide sufficient controls against 
distracting or disruptive participants ignores some fundamentals of group 
dynamics.  In effect, it holds that there is no cost in having each participant 
decide who is to be filtered.  In fact, the cost is quite high. When a 
participant must spend significant time filtering noise from content on a list, 
it becomes easier to leave the list.

IETF lists are supposed to follow work agendas.  Like any work group, they need 
to be given the management oversight that is typical for performing that work. 
This means asserting current topics, ensuring the topics are the focus of 
discussion, and bringing unruly or distracting participants under control.

More typically, IETF groups have little or none of this oversight, so it is no 
surprise that we find ourselves frequently debating irrelevancies.

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 15:32:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0ltI-0006r2-Kz; Sun, 22 Jan 2006 15:32:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0ltH-0006qu-7F; Sun, 22 Jan 2006 15:32:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14860;
	Sun, 22 Jan 2006 15:31:18 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0m2T-0002fw-RU; Sun, 22 Jan 2006 15:42:18 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3816400; Sun, 22 Jan 2006 15:29:24 -0500
In-Reply-To: 
References: 
	
	<43D379A3.5010200@cisco.com>
	
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: quoted-printable
From: Marshall Eubanks 
Date: Sun, 22 Jan 2006 15:32:39 -0500
To: Marshall Eubanks 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82
Content-Transfer-Encoding: quoted-printable
Cc: Scott Hollenbeck ,
	"ietf@ietf.org Mailing List" ,
	Eliot Lear , IESG 
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hello;

I received some private comments, so I will respond in greater depth. =20=

Please be careful what you ask for.

In doing so, I reread IETF list traffic on this from last September / =20=

October last year, and also the complaint.

So, here goes. First, I am aware of how disrupting posters can be. I =20
remember one individual who posted incessantly on IPv8 on a WG list, =20
another who hacked one of my organization's DNS servers just because =20
I dared to question the validity of alternative roots in a post. And, =20=

I came out in favor of the 3683'ing of Dean Anderson. So, I am not an =20=

automatic no vote.

However, I feel in a case such as this, things are a little different =20=

from technical standards setting. You are entitled to your own =20
opinions, you are not entitled to your own facts. While technical =20
standards are largely based on facts, in a case such as this opinions =20=

come into play. If I say that the protocol "foo" should be rejected =20
because it has a serious technical problem, you are entitled to ask =20
what this problem is. My opinion, by itself, is not enough. On the =20
other hand, if I say that I don't feel that poster "Ydobon" is =20
disruptive, that is, in a sense, not arguable. It is like saying that =20=

I dislike the cookies served at the break at an IETF meeting. You may =20=

like them, others may like them, but giving me lists of these people =20
or of reasons why I should like them is not going to change my mind.

Note the difference here, and the reason why I feel that a simple =20
statement of agreement or disagreement is sufficient :

If there is a fatal technical problem with a proposal, taking a vote =20
of who likes that proposal is irrelevant.

If we want to decide if people like the snacks at the break, =20
providing lists of reasons why they should like them
is irrelevant.

Of course, in very close or tough cases, or particularly egregious =20
ones, other things may come into play. For example, if the cookies =20
are poisoned, people shouldn't eat them, even if everyone raves about =20=

them.

I feel that banishment is a severe punishment, severe enough that I =20
think the conduct should be extremely bad
to warrant it. That is my feeling; others may differ, but there it =20
is. Under the category of extremely bad behavior, RFC 3683 says

    Although not exhaustive,
    examples of abusive or otherwise inappropriate postings to IETF
    mailing lists include:

    o  unsolicited bulk e-mail;

    o  discussion of subjects unrelated to IETF policy, meetings,
       activities, or technical concerns;

    o  unprofessional commentary, regardless of the general subject; =20
and,

    o  announcements of conferences, events, or activities that are not
       sponsored or endorsed by the Internet Society or IETF.

To these, I would add, threats, insults, and the like.

Note that these are (again, in my opinion) not of equal weight. If =20
Mr. Ydobon
sends to the list once a message beginning

RE:TRANSFER OF USD 168,559,000.00 MILLION TO YOUR ACCOUNT.

(actually received by me yesterday), I would say he's gone. If he =20
threatens death to those who disagree,
ditto. But, for "discussion of subjects unrelated to IETF policy, =20
meetings, activities, or technical concerns", I have very =20
occasionally posted jokes to this list, as have others, and I would =20
hope not to be banned for one occasion.

Now, to the case at hand. I read this list, and I do not feel that =20
Mr. Morfin has been disrupting it, nor have I seen any egregious =20
attacks, insults, etc. That's just my opinion, but there it is, and =20
that is the basis of my previous statements.

However, maybe he has been doing bad stuff on other lists; that, =20
after all, is part of the complaint. So, not being paid to do this, I =20=

looked at the complaints and singled out two of the six :

[5]

Personal attack, IETF-languages list:

http://eikenes.alvestrand.no/pipermail/ietf-languages/2005-June/=20
003369.html

Personal attack and threats, LTRU list:
http://www1.ietf.org/mail-archive/web/ltru/current/msg03788.html

I regard personal attacks as really egregious, and threats as worse; =20
even one might certainly be enough to warrant banning.

So, what do I see ?

In http://eikenes.alvestrand.no/pipermail/ietf-languages/2005-June/=20
003369.html
I see a first paragraph that I cannot parse at all, and a lot of =20
other verbiage that I am not qualified to
judge on technical grounds, but nothing I see as an attack.

Ok, in the second, http://www1.ietf.org/mail-archive/web/ltru/current/=20=

msg03788.html
I am going to quote all of JFC's postings, with
tme> being a comment from me.

-----
 > Cannot it be the result of a DISCUSS?
 > I may be wrong, but from the debate it seems we have a lack of
 > clarity concerning the "private use" possibilities between mentors of
 > this WG=FD (I agree with the "qsi" comment given by Harald).=FD

IMO, the pros and cons of using private use code or metadata elements =20=

are reasonably understood generally but must be considered =20
specifically in the context of a given application context. All we =20
are doing is providing tags and a spec for certain ways to compare =20
tags; we are not telling people tags must be used in some derivate =20
protocol or application. Section 4.5 does give general guidance about =20=

the limitations of private-use tags, including the caveats that =20
Harald mentioned:


Private use subtags have no meaning outside the private agreement =20
between the parties that intend to use or exchange language tags that =20=

employ them. The same subtags MAY be used with a different meaning =20
under a separate private agreement. They SHOULD NOT be used where =20
alternatives exist and SHOULD NOT be used in content or protocols =20
intended for general use.


That is the kind of thing that's appropriate to put in *that* =20
document. If the MPAA or MPEG groups need to discuss specific =20
implications of using "qsi" in their protocols and advice =20
implementers of the potential concerns of exposing that to other =20
systems, that's *their* problem, not ours.

Dear Peter,
This response is the response to the question below.

- who is the "ours" you quote? This is IETF not Unicode: it is not =20
meant to deliberately ignore MPAA, MPEG, etc. like requests, nore the =20=

generic ISO 11179 compliant needs, all them represented by AFRAC =20
whose job is to interface them all. Our (as IETF) is to support =20
"*their*" problem (which incidently is mine).

- the failure of the document is that if it partly permits to support =20=

private agreements such as MPAA or MPEG or AFRAC, but it makes that =20
capacity useless in providing no way to document which private =20
agreement is being used. This leads to the conflicts described by =20
Harald and denies the need of the Common Reference Centers like AFRAC =20=

to support them all. This is an organised DoS. And you just =20
documented it. Thank you.

tme>It is not clear to me who he is saying is doing a DOS, but I do =20
not regard that as an actionable insult.
tme>I don't see any others.

 > Dont you think it is better to accept a simple half additional line
 > and permit to address all these tricky cases one shot (in just
 > permitting to indicate the private space of exchange where the added
 > information applies) rather than in re-chartering, wasting months,
 > etc. to universally address a limited number of local cases. Will
 > this will never end? Or is there a major reason I do not understand
 > demanding it.

That's what we're all wondering: will this ever end?

Frankly? I do not know. Some with serious annoyance capacity for your =20=

employer talk of three to five years and of the justice obligation to =20=

support "0-". This is beyond me anyway. Your decision: they wanted to =20=

kill the project, but they are slow. We shown them we could manage in =20=

"0-" with ":" and "." and undetermined length.

There's not another half line of text needed in RFC3066bis to discuss =20=

this. What's really needed is already there.

This is a sales pitch for the unique solution you want to impose (to =20
favor the Charter quoted Unicode CLDR proposition?)
Impeaching private solutions and competition? No well accepted. After =20=

all, this is your problem to pay lawyers.

tme> Hard to read, but I cannot conclude he is threatening legal action.

We've all had opportunity to review it, comment on it and suggest =20
changes to it, and the time for that has passed.

Not this with me, please. People are reading!

This process must and will end; the rest of us are pushing for closure

The IETF mechanic calls for a few months more. Should some at the =20
IESG do not realise how much your proposition is detrimental to their =20=

own corporation (as an example of the way it is detrimental to =20
everyone) there will be appeals - I may or not be involved (I start =20
being bored and my work is building your competition). Then there =20
will be political and legal actions.

tme> Again, hard to read, but I cannot conclude HE is threatening =20
legal action, he is predicting it, a
tme> very different matter.

You really misjudged my opposition. I was here only to help with QA =20
for consumer protection. I proposed you to cooperate several times. =20
Now I can only wish you personal good luck if the RFC is eventually =20
approved by the IAB.

But you seem to want to drag it out longer for the sake of a half =20
line that will supposedly address in one shot all kinds of tricky =20
problems that supposed are not yet addressed -- except AFAICT they =20
are addressed.

Repeating this does not make you any good, nor to your employer: =20
people are reading.

When all this is finished ten years from now, I will have you for =20
lunch. I will explain you what you did wrong for

tme> Is this the threat ? I don't think he is threatening =20
cannibalism. It sounds like a friendly
tme> invitation to me.

your employer.
jfc

-----
So, in my sample picked for "Personal attack and threats", I see no =20
threats, and really no attacks either.
It is hard to read, and may not be worth reading, but is not =20
actionable IMHO.

So, after all of this waste of my time and yours, I am now STRONGLY =20
against approval of this PR-action.

Regards
Marshall

P.S. IETF-announce removed from this thread.

On Jan 22, 2006, at 7:48 AM, Marshall Eubanks wrote:

> Because I do not feel that the punishment is merited.
>
> On Jan 22, 2006, at 7:25 AM, Eliot Lear wrote:
>
>> Marshall,
>>> I do not support approval of this PR-action.
>>
>> Because.....??
>>
>
> I posted my thoughts earlier, my understanding is that in the last =20
> call process it is appropriate to restate one's
> opinion.
>
> If you conclude that I think that there has been too much verbiage =20
> on this matter, you are correct. I am trying to add to it as little =20=

> as possible.
>
> Regards
> Marshall
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 16:02:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0mMH-0006pp-04; Sun, 22 Jan 2006 16:02:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0mMF-0006pX-7d
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 16:02:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16737
	for ; Sun, 22 Jan 2006 16:01:14 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0mVP-0003cM-6Q
	for ietf@ietf.org; Sun, 22 Jan 2006 16:12:13 -0500
Received: from [10.0.0.121] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001577172.msg
	for ; Sun, 22 Jan 2006 22:04:13 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Sun, 22 Jan 2006 15:42:30 -0400
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
Thread-Index: AcYfi/sUOWJneot/EdqHlQANky3PwA==
In-Reply-To: <43D1102A.5020507@watson.ibm.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060122:ietf@ietf.org::GpzBslVGnpWGf+WC:00005FiZ
X-MDRemoteIP: 10.0.0.121
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Sun, 22 Jan 2006 22:04:23 +0100
X-MDAV-Processed: consulintel.es, Sun, 22 Jan 2006 22:04:24 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Content-Transfer-Encoding: quoted-printable
Subject: Re: I-D
 ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Barry,

Thanks a lot for your inputs.

I think this point is extremely important and we really need a clear
multi-national position on that, not just from a lot of participants of a
few countries, unless we want to restrict the participation of only
nationals from those countries.

See my reply, below-in line.

Regards,
Jordi




> De: Barry Leiba 
> Responder a: "ietf@ietf.org" 
> Fecha: Fri, 20 Jan 2006 11:30:34 -0500
> Para: "ietf@ietf.org" 
> CC: 
> Asunto: Re: I-D=20
> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
>=20
>> So, could people please review it for errors and omissions?
>=20
> My biggest concern is in sections "2.3.  Freedom of Participation"
> and "2.5.  Attendance Limitation and Visas", in that I'm not sure
> how realistic they are.  Without getting overly into politics (let's
> please not), I think they reflect a somewhat na=EFve view of some of
> the political realities.  Specifically...
>=20
>     Meetings should not be held in countries where some attendees could
>     be disallowed entry or where freedom of speech is not guaranteed for
>     all participants.
>=20
> The United States certainly cannot be assumed to allow ALL attendees
> entry.  It's well known that we have lists of people we won't allow
> in, and lest we think that's limited to the sort of nasty folk who
> wouldn't be attending the IETF anyway, I'll point out that a plane
> carrying Yusuf Islam -- the singer formerly known as Cat Stevens --
> was landed in Maine so that the singer could be removed and sent home
> before the plane continued to New York.  Individuals do get on these
> lists unreasonably, or by mistake.

It think is fine, of course, don't having as mandatory for a country to
allow to come for an IETF meeting somebody that did something which is
against the law (being a criminal, terrorist or whatever), but not just
because he/she has this or that way of thinking or is national for this or
that country (not to name political, religious, sexual or any kind
opinions).

IETF is an open institution, which don't care about good or bad political
decisions of countries or institutions; we just care about the way we want
the world to do technology to be interoperable for all.

Consequently, if a country don't allow some of us, some contributors or
people willing to contribute, to attend our meetings, that country is
against our goals, and is not good for IETF and is then not good for hosting
an IETF meeting.

I also understand, and that's the complete feeling behind the document, that
we may have no other alternative that hosting the meeting in such country,
but that may be the consequence of not having a better venue, or having
venues which are even more restrictive for a bigger group of contributors or
possible contributors.

The consequence for the IAD from the reading of this document in this
regards, should be like making sure that if better opportunities are
available, are actually used. If the result is that less meetings are being
hosted in certain countries, that's perfectly fair, because the overall
participation will be wider.

If some contributors don't wish to go to other countries, that's a personal
decision and could show a political view from their side, instead of a real
non-political interest in contributing to the work. And as such that is
against IETF goals of a wider participation; such type of "pressure" for the
IAD to move back to certain countries must never be accepted.

>=20
> Ignoring the issue of individuals, whole groups may have difficulty.
> The US has a list of "restricted countries", which includes Iran and
> North Korea, and a longer list of countries to which exports of software
> or technology are controlled (this list includes Russia and China,
> for example).  There's certainly no guarantee at any time that attendees
> from these countries won't have a difficult time getting visas, or might
> not be able to get them at all.

I'm not saying either that the meetings should be held on those countries
either, if they don't respect in a reciprocal way, that anyone can attend
the meeting.

There are lot's of other options, and if that means including a dozen of
countries in the world, even if they are big countries, what is the problem
?

As said, anyway, this is only in case we have no other better choices.

I think the difference is that I'm not saying "MUST not be held". I'm using
a should.

>=20
> As to freedom of speech:  We could argue about the reality of that
> for a while, but even apart from that, our government has made it
> clear that it considers those constitutional rights to apply to US
> citizens only, and not to foreign nationals who may be visiting.

Well, I didn't knew that, and I'm very sorry and sad to heard it, clearly is
a terrible statement coming for a government, and that's very negative, in
my *very personal* opinion, for the government and the citizens that accept
that, and becomes then evident for me that this country is not a good one
for IETF. May be this is something also happening in my own country and I
didn't knew it, but if that's the case (I doubt it), I don't care and I will
also have the same opinion from my *own* country, is not good and is
unacceptable.

If it was my personal decision, I will even make MUST for that specific
case, such as "Meetings MUST NOT be held in countries which don't respect
the freedom of speech for foreigners". :-(

>=20
> OK, all that said, I don't think the US is a bad country in which to
> have IETF meetings.  Which is, really, my point: I think the text
> needs to be changed to better express the intent, which is that we
> want to avoid countries that are unduly restrictive, without trying
> to limit things to utopian -- and non-existent -- lands of complete
> freedom.

As said, I'm not using a MUST, but a SHOULD.

As a consequence if there is a better choice for our meetings, we should opt
for that one. If it means having less meetings in certain countries, that's
perfectly fine and must be that way.

>=20
> --
> Barry Leiba  (leiba@watson.ibm.com)
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 16:02:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0mMI-0006qF-2J; Sun, 22 Jan 2006 16:02:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0mMF-0006pY-CX
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 16:02:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16733
	for ; Sun, 22 Jan 2006 16:01:13 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0mVP-0003c0-60
	for ietf@ietf.org; Sun, 22 Jan 2006 16:12:13 -0500
Received: from [10.0.0.121] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001577169.msg
	for ; Sun, 22 Jan 2006 22:04:06 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Sun, 22 Jan 2006 12:23:58 -0400
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: I-D
	ACTION:draft-palet-ietf-meeting-venue-selection-criteria- 04.txt
Thread-Index: AcYfcD75fXMa/ItjEdqHlQANky3PwA==
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886348@whq-msgusr-02.pit.comms.marconi.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060122:ietf@ietf.org::PqTiI0KoQrfpR5Os:00003vqt
X-MDRemoteIP: 10.0.0.121
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Sun, 22 Jan 2006 22:04:11 +0100
X-MDAV-Processed: consulintel.es, Sun, 22 Jan 2006 22:04:13 +0100
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-
 04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Agree, this is my view.

What I think is *against* the regular IETF process is to have exceptions to
anything being published as RFC.

I see a lot of admin documents (and as such this can be considered somehow),
which are RFCs, so as said there should be no difference.

Regards,
Jordi




> De: "Gray, Eric" 
> Responder a: 
> Fecha: Fri, 20 Jan 2006 11:16:34 -0500
> Para: 'Marshall Eubanks' , 
> CC: "ietf@ietf.org" 
> Asunto: RE: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-
> 04.txt
> 
> Marshall,
> 
> RFCs are living documents as well, though the process for
> change is somewhat cumbersome.  There are examples of RFCs that
> have been updated many times in the last few years.
> 
> --
> Eric 
> 
> --> -----Original Message-----
> --> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]
> --> On Behalf Of Marshall Eubanks
> --> Sent: Thursday, January 19, 2006 9:27 PM
> --> To: jordi.palet@consulintel.es
> --> Cc: ietf@ietf.org
> --> Subject: Re: I-D
> --> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> --> 
> --> Speaking just for myself :
> --> 
> --> I think that there is a strong benefit to having an agreed
> --> upon set  
> --> of parameters
> --> for new meeting locations.
> --> 
> --> Having said that, this may not be appropriate for an RFC. Maybe it
> --> should be a "living document" on a web page
> --> or wiki, as is being done / considered for mailing list anti-SPAM
> --> suggestions. Maybe a new class of
> --> IETF document publication is needed.
> --> 
> --> Regards
> --> Marshall Eubanks
> --> 
> --> On Jan 19, 2006, at 8:53 PM, JORDI PALET MARTINEZ wrote:
> --> 
> --> > Hi Paul,
> --> >
> --> > I guess we can question ourselves the same way in many other
> --> > documents ...
> --> >
> --> > The importance of having documents is part of the IETF "working
> --> > mode". Is
> --> > our way to say, here there is a consensus on this specific topic.
> --> >
> --> > I guess is not my final decision if it will become and
> --> RFC or not,  
> --> > but it
> --> > will not be fair not following the same path for this
> --> document as  
> --> > for many
> --> > others.
> --> >
> --> > That said, the original idea has been, since I was
> --> pointed out for
> --> > editing
> --> > this document, to follow exactly the same process as with
> --> many other
> --> > documents, technical and administrative.
> --> >
> --> > Regards,
> --> > Jordi
> --> >
> --> >
> --> >
> --> >
> --> >> De: Paul Hoffman 
> --> >> Responder a: 
> --> >> Fecha: Thu, 19 Jan 2006 12:43:42 -0800
> --> >> Para: Richard Shockey , IETF list
> --> 
> --> >> Asunto: Re: FW: I-D
> --> >> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
> --> >>
> --> >> At 2:28 PM -0500 1/19/06, Richard Shockey wrote:
> --> >>> It's a classic example of the current IETF fashion for
> --> process over
> --> >>> substance.
> --> >>
> --> >> Fully agree. What is the justification for this becoming an RFC?
> --> >>
> --> >> --Paul Hoffman, Director
> --> >> --VPN Consortium
> --> >>
> --> >> _______________________________________________
> --> >> Ietf mailing list
> --> >> Ietf@ietf.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@ietf.org
> --> > https://www1.ietf.org/mailman/listinfo/ietf
> --> 
> --> 
> --> _______________________________________________
> --> Ietf mailing list
> --> Ietf@ietf.org
> --> https://www1.ietf.org/mailman/listinfo/ietf
> --> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 16:27:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0mkS-0005Ja-Nl; Sun, 22 Jan 2006 16:27:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0mkR-0005JB-58
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 16:27:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18434
	for ; Sun, 22 Jan 2006 16:26:13 -0500 (EST)
Received: from fep02-0.kolumbus.fi ([193.229.0.44] helo=fep02-app.kolumbus.fi)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0mtc-0004OA-N5
	for ietf@ietf.org; Sun, 22 Jan 2006 16:37:14 -0500
Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep02-app.kolumbus.fi
	with ESMTP
	id <20060122212732.LXWM29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
	for ; Sun, 22 Jan 2006 23:27:32 +0200
X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912)
X-Originating-IP: [192.100.124.219]
From: John Loughney 
To: 
Date: Sun, 22 Jan 2006 23:27:32 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=____1137965252072_THO2lnJKL4"
Message-Id: <20060122212732.LXWM29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Subject: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

------=____1137965252072_THO2lnJKL4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I am growing tired of this meta-discussion, but I just needed to add my 2 cents, then I'll be quiet.

As someone who really wants to get work done, I find it very hard to get the work done when someone posts seemingly random comments, or at least is using argumentation that doesn't seem to have any other support in the working group.  I cannot say if this is what Jefsey is doing, as I am not active in any of the WGs in question.

What I do know, is that from time to time, on most working groups, someone pops in and derails forward progress. In my mind, we do need a mechanism to prevent this from happening.  Perfection is the enemy of the good in many, many cases.  We are the Internet 'Engineering' Task Force, we don't promise that we are always right - that's why we have three levels of standards.

People who suggest ignoring or hitting delete don't seem to really get it - as a working chair, I need to continually try to maintain forward motion on technical issues, sometimes someone shows up with what seems like an axe to grind or is trolling for attention.  I think we need mechanisms to be able to divert people who continuously disrespect rough consensus from continuing to disrupt the on-going work. 

The IETF doesn't have a strangle-hold on the Internet - there are other standardization bodies out there, and noone is preventing people from going out and designing their own solutions, outside of the IETF.  Look at various peer-to-peer protocols as a good examples of things that people use everyday, but wouldn't stand a chance of getting an RFC.

John

------=____1137965252072_THO2lnJKL4
Content-Type: text/plain; charset="us-ascii";
	name="replyAll"
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


------=____1137965252072_THO2lnJKL4
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

------=____1137965252072_THO2lnJKL4--





From ietf-bounces@ietf.org Sun Jan 22 17:08:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0nNe-0007OP-5D; Sun, 22 Jan 2006 17:08:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0nNc-0007OJ-51
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 17:08:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21169
	for ; Sun, 22 Jan 2006 17:06:43 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0nWp-0005b9-3L
	for ietf@ietf.org; Sun, 22 Jan 2006 17:17:44 -0500
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 22 Jan 2006 17:08:02 -0500
X-IronPort-AV: i="4.01,210,1136178000"; 
	d="scan'208"; a="80743520:sNHT29380884"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0MM7v6J025586; 
	Sun, 22 Jan 2006 17:08:00 -0500 (EST)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Sun, 22 Jan 2006 17:07:58 -0500
Received: from [127.0.0.1] ([161.44.11.166]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Sun, 22 Jan 2006 17:07:58 -0500
Message-ID: <43D4023C.3090306@cisco.com>
Date: Sun, 22 Jan 2006 23:07:56 +0100
From: Scott W Brim 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: John Loughney 
References: <20060122212732.LXWM29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
In-Reply-To: <20060122212732.LXWM29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jan 2006 22:07:58.0230 (UTC)
	FILETIME=[4D830B60:01C61FA0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 01/22/2006 22:27 PM, John Loughney allegedly wrote:
> Look at various peer-to-peer protocols as a good
> examples of things that people use everyday, but wouldn't stand a
> chance of getting an RFC.

Why not?

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 17:26:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0nfI-0003AK-Fy; Sun, 22 Jan 2006 17:26:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0nfG-00039j-Pv
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 17:26:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22141
	for ; Sun, 22 Jan 2006 17:24:57 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc13.comcast.net ([63.240.77.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0noT-00062l-NS
	for ietf@ietf.org; Sun, 22 Jan 2006 17:35:59 -0500
Received: from smailcenter72.comcast.net ([204.127.205.172])
	by comcast.net (sccrmhc13) with SMTP
	id <2006012222261501300gldkle>; Sun, 22 Jan 2006 22:26:16 +0000
Received: from [66.229.53.140] by smailcenter72.comcast.net;
	Sun, 22 Jan 2006 22:26:15 +0000
To: John Loughney , 
Date: Sun, 22 Jan 2006 22:26:15 +0000
Message-Id: <012220062226.13536.43D4068700038E41000034E0220075043800000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="NextPart_Webmail_9m3u9jl4l_13536_1137968775_0"
X-Spam-Score: 1.3 (+)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: 
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--NextPart_Webmail_9m3u9jl4l_13536_1137968775_0
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_13536_1137968775_1"


--NextPart_Webmail_9m3u9jl4l_13536_1137968775_1
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

-------------- Original message -------------- 
From: John Loughney  

> I am growing tired of this meta-discussion, but I just needed to add my 2 cents, 
> then I'll be quiet....
>I cannot say if this is what Jefsey is doing, as I am not active in any of the 
>WGs in question.

John-
Can you imagine if during every murder trial they had a debate on the humanity of capitol punishment?  This in my opinion becomes a meta-discussion because people who have nothing to say about Jefsey post their general feelings on pr-actions.  While I respect everyone's comments and agree each time we go through the process we learn how to better it, this is not the time or the place to discuss it.  Please, if you don't have an opinion specifically related to Jefsey then stay out of the Jefsey discussion.  
--NextPart_Webmail_9m3u9jl4l_13536_1137968775_1
Content-Type: text/html
Content-Transfer-Encoding: 8bit



-------------- Original message -------------- 
From: John Loughney <john.loughney@kolumbus.fi> 

> I am growing tired of this meta-discussion, but I just needed to add my 2 cents, 
> then I'll be quiet....


>I cannot say if this is what Jefsey is doing, as I am not active in any of the 
>WGs in question.

John-


Can you imagine if during every murder trial they had a debate on the humanity of capitol punishment?  This in my opinion becomes a meta-discussion because people who have nothing to say about Jefsey post their general feelings on pr-actions.  While I respect everyone's comments and agree each time we go through the process we learn how to better it, this is not the time or the place to discuss it.  Please, if you don't have an opinion specifically related to Jefsey then stay out of the Jefsey discussion.  


--NextPart_Webmail_9m3u9jl4l_13536_1137968775_1--


--NextPart_Webmail_9m3u9jl4l_13536_1137968775_0
Content-Type: message/rfc822

From: John Loughney 
To: 
Subject: how to declare consensus when someone ignores consensus
Date: Sun, 22 Jan 2006 21:33:34 +0000
Content-Type: Multipart/mixed;
	boundary="NextPart_Webmail_9m3u9jl4l_13536_1137968775_2"
MIME-Version: 1.0

--NextPart_Webmail_9m3u9jl4l_13536_1137968775_2
Content-Type: text/plain; charset="us-ascii";
	name="replyAll"
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


--NextPart_Webmail_9m3u9jl4l_13536_1137968775_2
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--NextPart_Webmail_9m3u9jl4l_13536_1137968775_2--

--NextPart_Webmail_9m3u9jl4l_13536_1137968775_0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--NextPart_Webmail_9m3u9jl4l_13536_1137968775_0--




From ietf-bounces@ietf.org Sun Jan 22 18:07:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0oIX-0005Qp-QH; Sun, 22 Jan 2006 18:07:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0oIW-0005Qk-Go
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 18:07:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25046
	for ; Sun, 22 Jan 2006 18:05:31 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0oRj-0007Im-Uq
	for ietf@ietf.org; Sun, 22 Jan 2006 18:16:33 -0500
Received: by zproxy.gmail.com with SMTP id 8so817379nzo
	for ; Sun, 22 Jan 2006 15:06:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=rLiheZ53+5RRZ0zhfhikwuDgiTbezYZHEifvBVvabWszKulOMhDc1AbtAQmQ/3hDEgebZGdEkE1t8puG4RwhIEf4cKkPiArYXbelQzHK0Ymp+w9ZNEJmQDQ1TLNwNMq2MrQ7mvEQTY3MKUwMpio7SVuqV0LQbfjRJxtQksVEYok=
Received: by 10.36.250.64 with SMTP id x64mr3431812nzh;
	Sun, 22 Jan 2006 15:06:58 -0800 (PST)
Received: by 10.37.12.71 with HTTP; Sun, 22 Jan 2006 15:06:58 -0800 (PST)
Message-ID: <68fba5c50601221506n37a25dbfk79bfac5484a0e9f0@mail.gmail.com>
Date: Sun, 22 Jan 2006 18:06:58 -0500
From: Robert Sayre 
To: Scott W Brim 
In-Reply-To: <43D4023C.3090306@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <20060122212732.LXWM29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
	<43D4023C.3090306@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org, John Loughney 
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 1/22/06, nick.staff@comcast.net  wrote:
>
> Please, if you don't have
> an opinion specifically related to Jefsey then stay out of the Jefsey
> discussion.

On 1/22/06, Scott W Brim  wrote:
> On 01/22/2006 22:27 PM, John Loughney allegedly wrote:
> > Look at various peer-to-peer protocols as a good
> > examples of things that people use everyday, but wouldn't stand a
> > chance of getting an RFC.
>
> Why not?

Peer-to-peer protocols are a great example. The IETF is a miserable
place to work on them because the organization tolerates all
pseudo-technical discussion, and thus fails to hold the attention of
implementers, despite the fact that the process is designed to route
around that exact problem.

I suspect the IESG will find that the folks actually trying to get
work done in the presence of JFC's emails all feel the same way. Most
of the objections seem to be coming from people concerned with
designing the perfect bureaucratic process. In any WG, there are
implementers whose support is valuable. The rest of the participants
are valuable when they fix bugs. JFC doesn't seem to fix many bugs,
and drives implementers away in droves, from what I can see.

It has been suggested that I be placed under RFC 3683 sanctions in the
past, though I suppose the offending messages have always been in
response to misconduct (not a justification). I don't think the IETF
is in any danger of developing a trigger finger here.

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 21:55:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0rrE-0001ws-TE; Sun, 22 Jan 2006 21:55:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0rrC-0001vy-Qs; Sun, 22 Jan 2006 21:55:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07977;
	Sun, 22 Jan 2006 21:53:34 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0s0S-0004h8-Rn; Sun, 22 Jan 2006 22:04:37 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F0rr0-0008Eq-8b; Sun, 22 Jan 2006 18:54:50 -0800
Message-Id: <6.2.3.4.2.20060122174233.048377a0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Sun, 22 Jan 2006 21:02:25 +0100
To: "Margaret Wasserman" , 
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <030301c61f6d$fa9e1c00$0402a8c0@instant802.com>
References: <6.2.3.4.2.20060120112906.0547e7d0@mail.jefsey.com>
	<030301c61f6d$fa9e1c00$0402a8c0@instant802.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-19962D93
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb
Cc: iesg@ietf.org
Subject: Mr. Smith was at the IETF (was RE: Mr. Smith goes to the IETF)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 17:07 22/01/2006, Margaret Wasserman wrote:
>Hi Jefsey,
>In this post and in at least one other recent post you talk about
>filibustering on various mailing lists.  I would like to make sure that I
>understand what you are talking about, because this is very important to my
>assessment of the proposed PR-Action. Prior to these posts, I did not
>understand why you were making so many clearly off-topic posts on these
>lists, but I did not assume that you were intentionally attempting to
>disrupt the work of the IETF.
>
>In the U.S. filibustering is a tactic used in the U.S. Senate that abuses a
>loophole in the Senate rules to _intentionally_ block the work of the senate
>for some period of time.  Filibustering is not a democratic right, and it is
>not a tactic that, IMO, should be used, encouraged or allowed on IETF
>mailing lists.
>
>I have read this post and other recent posts of yours as admissions that you
>are _intentionally_ disrupting the work of the ietf-languages@iana.org list
>and the LTRU WG mailing list via a tactic similar to filibustering.  Is that
>a correct interpretation of your messages?

Dear Margaret,
I apologized for the confusion I unwillingly created. I wrongly used 
the word "filibustering". "Mr. Smith goes to Washington" and "Davy 
Crockett" pictures give a different and noble idea of 
"filibustering". I took it for what a lonesome democratic, dedicated 
and imaginative "freebooter" (flibustier in French) would do, to 
force positive results, against a powerful lobby defending private 
interests' status-quo.

I was explained by lawyers I was mistaken. They explained me what 
Harald engaged was a filibuster to interfere with my current IAB and 
IETF appeals. One said "Mr. Smith was at the IETF". They called my 
action to restlessly force quality, ethic and adequacy "smart activism", etc.

As a user, shopping for quality solutions for my digital global 
ecosystem, I want (and obtained) simple things:

(1) the RFC 3066 bis pollution to be cleaned. Because it hurt my job 
and the whole world (with no real advantage for its proponents). I 
obtained this through that "smart activism" (the most efficient and 
less disruptive way I found) at the IETF, the WSIS, etc.. My mails 
and attitude (looking a boring fool) forced the WG to clean its 
document, without starting a conflict where my supporters would have 
joined. I made a large number of contributions (read them and tell me 
if they are off-topic): the WG usually adopted/confirmed the 
opposite. This is not always in the text, but the responses are in 
the records. For further user's FAQ. I did not want to convince (I 
oppose a well established  Unicode Globalization US-centric 
doctrine). I just carried QA. Now, other generalised language naming 
(endorsed by the Tunis documents) and documentation propositions can 
now interoperate with it.

(2) however such interoperation still calls for:

   (a) an interface and a minimum level of security RFC 3066 bis does 
not provide. Hence the IESG appeal. If you and IAB deny my 
propositions in that area everyone will know (security) and we will 
patch the interface.

   (b) the IANA registry cooperation: no problem when the 
ietf-languages IANA list is operated, published and controlled by the 
IANA, and respect the Tunis global agreement for multilingualisation. 
This will be a loss of control for its current owners. Hence their 
anti-EU trap and my "5th" ban: should I really waste more time and 
bore everyone appealing against this new vaporware? I can appeal if 
you really want it...

(3) the demonstration the IETF wants to deliver the ethical, 
pertinent and multilingual innovation we need. This explains most of 
my ietf@ietf.org mails. Look at them: I suggest, prod, etc. without 
initiating debates on issues where there no real thinking yet. I 
understand conservative minds do not like it, but it is quite 
efficient in establishing relations with open minded smart people, 
and in obtaining results. I was going away without noise. Now may be 
Harald will make a few more to get interested in the architecture TF 
some of these people plan with me?

Take care.
jfc


> > -----Original Message-----
> > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On
> > Behalf Of JFC (Jefsey) Morfin
> > Sent: Friday, January 20, 2006 5:59 AM
> > To: ietf@ietf.org
> > Cc: iesg@ietf.org
> > Subject: Mr. Smith goes to the IETF
> >
> > As far I am concerned, the PR-action engaged against me by
> > Harald Alvestrand is per se of no interest. I just have some
> > general comments and one question about it, I will address separately.
> >
> > What is more interesting is how the IETF and the Internet
> > community may benefit from the three issues I raise:
> > multilingualism, ethic and user QA. The three of them have an
> > architectural impact (the IAB should be able to address
> > through the now silent IAB-discuss) and are part of a wide
> > "governance" change which question the RFC 3935 IETF mission.
> > These three questions (ethic and user QA being related in
> > part) are now under final escalation to the IAB.
> >
> >
> > At the present time, published contributions (Sam Hartman,
> > John Klensin, Harald Alvstrand) agree with me: filibustering,
> > however a democratic US invention, is a pest. IETF should do
> > everything not to need it (much more efficient than to fight
> > it). I think my contributions are of interest to consider in
> > this area. I suppose all the PESCI member are already on the
> > two copied lists.
> >
> >
> > 1. due to the importance of the "war on culture"
> > "internationalization" represents, I was proposed support and
> > funding to oppose it. The problem are an architectural layer
> > violation, a narrow vision and a lack of information. Not a
> > lack of competence. To kill the IETF for that was inadequate
> > (or premature). I am already a problem, would we have been
> > two or three of us ... Had we been 200 as I was proposed ...
> > I have computed that $ 20.000 are enough to block the IETF.
> > This can be discussed, but this is something we should
> > urgently consider, when political, commercial and civil
> > rights interests make the IETF, and most of all the IANA, a
> > key target (the USG says for sale- may be to protect it?).
> >
> > I refused it.
> >
> > 2. I proposed Brian Carpenter to get "would be filibusters" a
> > special status in the consensus process as "user QA rep".
> > With rights and duties.
> >
> > This was denied.
> >
> > 3. I proposed an evolution in the WG working method. In using
> > position links: every contributor expresses his positions on
> > a page he can update as the debate goes. I proposed this to
> > the GNSO WG-Review which supported it and I use it in some
> > work. This filters out "standard" participants' blabla. It
> > permits everyone to stay, every concept to be documented and
> > progressively trimmed, and external experts to call in.
> > Consensus is when all the positions are equivalent or have
> > identified they cannot agree. Consensus review is easy and
> > informative.
> >
> > This was not considered.
> >
> > 4. I have engaged an IESG, and now an IAB appeal, to know if
> > this kind of debate is, or not, part of  the IETF. IESG said
> > "no". I want a confirmation by the IAB (so no one can claim
> > there is a conflict) before engaging into the organisation of
> > a solution. My solution is a dedicated TF sharing into the
> > Internet standard process and reviewing the Charters and the
> > Drafts during the LC, or upon request. That TF would
> > permanently interact with the users. I think it can be
> > engaged in ethic (COI and societal impact) and "governance"
> > issues. The interest is that there can be several TF until
> > one emerges as a stable and productive solution. I would
> > favor it to be eventually part of ISOC and to interface (and
> > protect the IETF from) the IGF.
> >
> > This is under final consideration. Interested people can
> > share in a Draft.
> >
> >
> > This IETF has to understand that the Internet has become mature.
> > Mature for a product - and specially for a communication
> > technology - is when the technology is no more the leader but
> > when usage decides.
> > This is what they call "governance". This means that the IGF
> > is going to deliver scores of Jefseys. Engineers who can code
> > user response as per the user' requests (far more complex
> > than what IETF does today).
> > The NSF GENI project will not be alone.
> >
> > I still consider there is a difference between specifying
> > (Charter) and documenting (WG work). But most, because they
> > will be from Lobbies or Govs, will not bother. This will lead
> > to balkanization and to IETF bottle necks. Already, I saw
> > that with the lobby driven
> > WG-LTRU: the Charter was not considered. WG Consensus by
> > exhaustion, IETF consensus by disinterest and IESG consensus
> > by impossible knowledge of everything lead to dispute like
> > the one I have with Harald. There will be scores of them soon
> > if we do not find a structural solution.
> >
> > jfc
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> >


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 21:55:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0rrG-0001xP-C6; Sun, 22 Jan 2006 21:55:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0rrD-0001wS-Lw; Sun, 22 Jan 2006 21:55:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07983;
	Sun, 22 Jan 2006 21:53:35 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0s0S-0004hT-Rs; Sun, 22 Jan 2006 22:04:38 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F0rr2-0008Eq-3u; Sun, 22 Jan 2006 18:54:52 -0800
Message-Id: <6.2.3.4.2.20060123000128.06873eb0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Mon, 23 Jan 2006 02:56:11 +0100
To: Marshall Eubanks ,
	Marshall Eubanks 
From: "JFC (Jefsey) Morfin" 
In-Reply-To: 
References: 
	
	<43D379A3.5010200@cisco.com>
	
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-19962D93
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: Scott Hollenbeck ,
	"ietf@ietf.org Mailing List" ,
	Eliot Lear , IESG 
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey)
  Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 21:32 22/01/2006, Marshall Eubanks wrote:
>So, in my sample picked for "Personal attack and threats", I see no 
>threats, and really no attacks either.
>It is hard to read, and may not be worth reading, but is not actionable IMHO.

Dear Marshall,
Thank you for spending the time to check and for speaking the truth.
Actually I am the threat, I am the "attack".

The Internet and the computer environments are US ASCII English. This 
lead to the idea to support languages through a globalization 
architecture internationalizing the network and localizing the 
computers (RFC 2277, 3066). RFC 3066 Bis (technically and 
practically) exclusively commits the Internet to this architecture 
embodied by Unicode. Its current main achievement is IDNA.

This makes the Internet incompatible with multilingualisation needs, 
demands, and architectural R&D like mine. Hence I am the threat. 
Multilingualisation is a retro and cross-internationalisation 
considering the 20.000 language entities equal. A linguistic "peer to peer".

In addition the whole world (14,500 people in Tunis, with the sole 
absence of the IETF) decided for multilingualisation (I accept I am 
active in that area). I also forced  RFC 3066 bis to be so clean that 
one can now easily circumvent its interoperability and security 
problems if they were not addressed by my current appeal. I also 
asked an IAB guidance to know if they want to stick to 
internationalization or want to work on multilingualisation. These 
two appeals are the "attack" they try to protect the IETF from.

jfc

PS. "hard to read" comes from my Franglish (should hardly be a 
problem for language experts?) and from the lack of time. The waste 
of time against a score of opponents reluctant to clarify their Draft 
was huge. I think it was OK to waste a year to permit my work of the 
10 coming years.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 22 23:26:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0tHX-0008Um-MX; Sun, 22 Jan 2006 23:26:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0tHV-0008Uh-Lt
	for ietf@megatron.ietf.org; Sun, 22 Jan 2006 23:26:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13382
	for ; Sun, 22 Jan 2006 23:24:48 -0500 (EST)
Received: from fep01-0.kolumbus.fi ([193.229.0.41] helo=fep01-app.kolumbus.fi)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0tQl-000748-F9
	for ietf@ietf.org; Sun, 22 Jan 2006 23:35:52 -0500
Received: from smtp.kolumbus.fi ([193.229.55.124]) by fep01-app.kolumbus.fi
	with ESMTP
	id <20060123042607.GPAL15577.fep01-app.kolumbus.fi@smtp.kolumbus.fi>;
	Mon, 23 Jan 2006 06:26:07 +0200
X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912)
X-Originating-IP: [84.231.143.173]
From: John Loughney 
To: Scott W Brim 
Date: Mon, 23 Jan 2006 6:26:07 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <20060123042607.GPAL15577.fep01-app.kolumbus.fi@smtp.kolumbus.fi>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> On 01/22/2006 22:27 PM, John Loughney allegedly wrote:
> > Look at various peer-to-peer protocols as a good
> > examples of things that people use everyday, but wouldn't stand a
> > chance of getting an RFC.
> 
> Why not?

Now we're close to side veering off into process issues, but rather than going into that rat-hole, I'll just pose a question: do you think p2p protocol authors would have any motiviation to create a Security Considerations section that would pass IESG review?

John


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 03:22:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0wy4-00065T-E9; Mon, 23 Jan 2006 03:22:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0wy2-00064U-H5
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 03:22:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27420
	for ; Mon, 23 Jan 2006 03:20:56 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0x7K-00053q-RW
	for ietf@ietf.org; Mon, 23 Jan 2006 03:32:04 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0N8MnnZ027636
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2006 00:22:49 -0800
Message-ID: <43D49230.1000207@dcrocker.net>
Date: Mon, 23 Jan 2006 00:22:08 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: John Loughney 
References: <20060123042607.GPAL15577.fep01-app.kolumbus.fi@smtp.kolumbus.fi>
In-Reply-To: <20060123042607.GPAL15577.fep01-app.kolumbus.fi@smtp.kolumbus.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" 
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Now we're close to side veering off into process issues, but rather than 
> going into that rat-hole, I'll just pose a question: do you think p2p 
> protocol authors would have any motiviation to create a Security
> Considerations section that would pass IESG review?


a security considerations section would be a breeze, compared to the 
pre-chartering hoops we regularly impose on new areas of work, especially any 
with a real security component, independent of prior work.

d/



-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 04:03:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0xbO-00058w-C8; Mon, 23 Jan 2006 04:03:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0xbI-000589-N4; Mon, 23 Jan 2006 04:03:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29619;
	Mon, 23 Jan 2006 04:01:32 -0500 (EST)
Received: from mtagate4.uk.ibm.com ([195.212.29.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F0xkb-0006EM-8E; Mon, 23 Jan 2006 04:12:38 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0N92nfw154618; 
	Mon, 23 Jan 2006 09:02:49 GMT
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com
	[9.149.37.213])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0N92nUP207454; Mon, 23 Jan 2006 09:02:49 GMT
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0N92nAb007483; Mon, 23 Jan 2006 09:02:49 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0N92mhS007475; Mon, 23 Jan 2006 09:02:48 GMT
Received: from zurich.ibm.com (sig-9-146-217-94.de.ibm.com [9.146.217.94])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA23966;
	Mon, 23 Jan 2006 10:02:47 +0100
Message-ID: <43D49BAD.7070902@zurich.ibm.com>
Date: Mon, 23 Jan 2006 10:02:37 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: nick.staff@comcast.net
References: <012220061838.14198.43D3D12E0009C39600003776220588601400000E9B9CD2050C0702@comcast.net>
In-Reply-To: <012220061838.14198.43D3D12E0009C39600003776220588601400000E9B9CD2050C0702@comcast.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Cc: Scott Hollenbeck , ietf@ietf.org,
	Eliot Lear , ietf-announce@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

nick.staff@comcast.net wrote:
...
> I mean really, has anyone ever had their opinion changed because of something someone said during these PR-Actions? 

This is in fact only the second last call ever on a PR-action.

I can assure you that the IESG reads the opinions expressed
carefully and does not take such decisions lightly, one way
or the other.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 04:23:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F0xuw-0001Pl-1N; Mon, 23 Jan 2006 04:23:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F0xut-0001Pg-9v
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 04:23:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01256
	for ; Mon, 23 Jan 2006 04:21:46 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0y4A-0006xh-BW
	for ietf@ietf.org; Mon, 23 Jan 2006 04:32:53 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id 17D8B26C0E8; Mon, 23 Jan 2006 10:22:46 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 1C26C26C081; Mon, 23 Jan 2006 10:22:40 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k0N9MdYa651204;
	Mon, 23 Jan 2006 10:22:40 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id CB65A16AA06; Mon, 23 Jan 2006 10:22:39 +0100 (CET)
Date: Mon, 23 Jan 2006 10:22:39 +0100
From: Stephane Bortzmeyer 
To: Neil Harwani 
Message-ID: <20060123092239.GA20214@nic.fr>
References: <955ba8bb0601221114h685054e6l7576d46de3b6ec46@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <955ba8bb0601221114h685054e6l7576d46de3b6ec46@mail.gmail.com>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: ietf@ietf.org
Subject: Re: suggestion on distributed systems
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, Jan 23, 2006 at 12:44:11AM +0530,
 Neil Harwani  wrote 
 a message of 128 lines which said:

> I am not sure whether this idea that I am about to write has been
> implemented before

The idea is interesting but it is clearly underspecified. Before a
serious discussion can take place, you really have to specify it more
completely. If you want the discussion to occur at the IETF, an
Internet-Draft is the proper form:

http://www.ietf.org/ietf/1id-guidelines.html

Technically, I would suggest to think seriously about the Security
Considerations of your Internet-Draft...

> 1. Have a variable system built into all OSes which have internet
> interface which can allocate space and resources as per what amount
> of space and resources are free on the OS.

The big problem is to create a jail strong enough so that the hosted
programs do not compromise or DoS the machine. This is *not* a trivial
problem.

> Example : Suppose a server of paypal has to process millions of
> records every month. If a high percentage of this processing is
> encrypted and sent to container on various systems running on
> internet, the same work can be done with less powerfull paypal
> servers.

Very bad example: first, all Paypal requests require access to the
central database. And, second, Paypal would certainly not trust random
Internet machines for its processing.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 07:54:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F11DI-0006Mf-Dh; Mon, 23 Jan 2006 07:54:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F11DF-0006Lv-T4; Mon, 23 Jan 2006 07:54:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14523;
	Mon, 23 Jan 2006 07:52:55 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc13.comcast.net ([204.127.202.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F11MW-0004Ry-29; Mon, 23 Jan 2006 08:04:05 -0500
Received: from smailcenter42.comcast.net ([204.127.205.142])
	by comcast.net (sccrmhc13) with SMTP
	id <2006012312535301300gi0lie>; Mon, 23 Jan 2006 12:54:08 +0000
Received: from [66.229.53.140] by smailcenter42.comcast.net;
	Mon, 23 Jan 2006 12:53:52 +0000
To: Brian E Carpenter 
Date: Mon, 23 Jan 2006 12:53:52 +0000
Message-Id: <012320061253.3104.43D4D1E00008843200000C20220074818400000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
X-Spam-Score: 1.3 (+)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Scott Hollenbeck , ietf@ietf.org,
	Eliot Lear , ietf-announce@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1730825498=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============1730825498==
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_3104_1138020832_0"


--NextPart_Webmail_9m3u9jl4l_3104_1138020832_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

-------------- Original message -------------- 
From: Brian E Carpenter  
 
> I can assure you that the IESG reads the opinions expressed 
> carefully and does not take such decisions lightly, one way 
> or the other. 
> 
> Brian 
Brian, 
I was not questioning the IESG's decisions nor did I mean my question to imply a long history of PR-Actions.  I was not tring to say that the IESG already has their mind made up and ignores what we have to say - rather I was saying IETF members already have their minds made up.  My point was was not a jab at anyone - no one is doing anything bad, but I think it needs to be stressed that these PR discussions are not changing peoples opinions anymore than as Marshall said, one could be convinced to like a cookie they didn't like.
Since this is a rough consensus decision and since nobody's being convinced to like something they don't, providing the "why's" of ones opinion only serves to incite and drag on that which could be closed with a showing of agree/disagree.
I am not explaining myself well as it's too early in the morning and I have too much to say.  Talk to Marshall he does a much better job than I.
nick
--NextPart_Webmail_9m3u9jl4l_3104_1138020832_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit



-------------- Original message -------------- 
From: Brian E Carpenter <brc@zurich.ibm.com> 
 
> I can assure you that the IESG reads the opinions expressed 
> carefully and does not take such decisions lightly, one way 
> or the other. 
> 
> Brian 
Brian, 


I was not questioning the IESG's decisions nor did I mean my question to imply a long history of PR-Actions.  I was not tring to say that the IESG already has their mind made up and ignores what we have to say - rather I was saying IETF members already have their minds made up.  My point was was not a jab at anyone - no one is doing anything bad, but I think it needs to be stressed that these PR discussions are not changing peoples opinions anymore than as Marshall said, one could be convinced to like a cookie they didn't like.


Since this is a rough consensus decision and since nobody's being convinced to like something they don't, providing the "why's" of ones opinion only serves to incite and drag on that which could be closed with a showing of agree/disagree.


I am not explaining myself well as it's too early in the morning and I have too much to say.  Talk to Marshall he does a much better job than I.


nick


 


--NextPart_Webmail_9m3u9jl4l_3104_1138020832_0--


--===============1730825498==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1730825498==--




From ietf-bounces@ietf.org Mon Jan 23 08:57:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F12CZ-00031N-JR; Mon, 23 Jan 2006 08:57:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F12CY-00031F-3G
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 08:57:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19630
	for ; Mon, 23 Jan 2006 08:56:15 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12Ls-0006WA-0z
	for ietf@ietf.org; Mon, 23 Jan 2006 09:07:26 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NDvRB3062298
	for ; Mon, 23 Jan 2006 14:57:27 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 14:57:27 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1812218673.20060123145727@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060122212732.LXWM29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
References: <20060122212732.LXWM29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John Loughney writes:

> People who suggest ignoring or hitting delete don't seem to
> really get it ...

People who insist that this doesn't work don't seem to really get it.
It has worked for me for decades.

The reality is that some people are irritated by the need to do
anything they don't want to do, including something as simple as
ignoring a post that irritates them or hitting a delete button.  As a
result, they exaggerate the "effort" required to do these things by
many orders of magnitude, in an attempt to give the impression that
there is an objective reason for not doing them--which they feel will
be much more persuasive than admitting that they simply don't like it.

It's not hard to delete or ignore messages (the latter, in particular,
often requires no effort at all).  And moderating discussion groups
tends to be only as hard as one makes it.  A moderator with a
powerfully anal-retentive personality will constantly fuss and stress
over a group, perpetually deleting, editing, banning, and lecturing.
A moderator with a clue, on the other hand, will let just about
everything slide that won't get him into legal trouble and doesn't
technically compromise the system.

The real trolls know this.  They know that a technical denial of
service isn't nearly as effective as appealing to the emotions of a
moderator and the participants in a group, and then watching them fume
and flail uselessly for days, weeks, or months.  While they are busy
banning, deleting, and lecturing, they aren't getting anything else
done--the service level is zero.  And no technical magic is required;
it's all psychology.

Of course, most people who upset a moderator or the other members of a
list aren't trolls ... they've just made the mistake of expressing
unpopular opinions, and the natural intolerance that afflicts most
people takes over from there.

> - as a working chair, I need to continually try to
> maintain forward motion on technical issues, sometimes someone shows
> up with what seems like an axe to grind or is trolling for
> attention.  I think we need mechanisms to be able to divert people
> who continuously disrespect rough consensus from continuing to
> disrupt the on-going work.

The best mechanism is the silent treatment.  Unfortunately, that
requires a wise moderator and wise participants, and these are scarce.
But "diverting" people who are unpopular only adds fuel to the fire
and wastes resources.

> The IETF doesn't have a strangle-hold on the Internet - there are
> other standardization bodies out there, and noone is preventing
> people from going out and designing their own solutions, outside of
> the IETF.

They are all populated by the same species of intolerant and immature
participants that afflict the IETF.  It's very, very difficult to
assemble a group of people who are able to stay cool even when
confronted with things they don't want to hear.  The tiny minority of
people who do fit in this category tend to be excellent moderators
(and indeed excellent leaders in general).


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 08:59:11 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F12Dv-0003G9-CT; Mon, 23 Jan 2006 08:59:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F12Dt-0003DP-I6
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 08:59:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19713
	for ; Mon, 23 Jan 2006 08:57:39 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12NF-0006ZL-GI
	for ietf@ietf.org; Mon, 23 Jan 2006 09:08:49 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NDwxM6062305
	for ; Mon, 23 Jan 2006 14:58:59 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 14:58:59 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1569012409.20060123145859@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <012220062226.13536.43D4068700038E41000034E0220075043800000E9B9CD2050C0702@comcast.net>
References: <012220062226.13536.43D4068700038E41000034E0220075043800000E9B9CD2050C0702@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

nick.staff@comcast.net writes:

> Can you imagine if during every murder trial they had a debate on
> the humanity of capitol punishment?

Can you imagine if, in every business meeting, people who disagreed
decided to sue each other?

> Please, if you don't have an opinion specifically related to
> Jefsey then stay out of the Jefsey discussion.

Please, if you don't have a discussion specifically related to the
work of the IETF, then don't bring it up here.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 09:02:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F12HV-00043H-Gm; Mon, 23 Jan 2006 09:02:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F12HI-000428-9w
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 09:02:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20140
	for ; Mon, 23 Jan 2006 09:01:09 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12Qd-0006jZ-72
	for ietf@ietf.org; Mon, 23 Jan 2006 09:12:20 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NE2SJT062355
	for ; Mon, 23 Jan 2006 15:02:28 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 15:02:28 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <543775398.20060123150228@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <68fba5c50601221506n37a25dbfk79bfac5484a0e9f0@mail.gmail.com>
References: <20060122212732.LXWM29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
	<43D4023C.3090306@cisco.com>
	<68fba5c50601221506n37a25dbfk79bfac5484a0e9f0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Robert Sayre writes:

> I suspect the IESG will find that the folks actually trying to get
> work done in the presence of JFC's emails all feel the same way. Most
> of the objections seem to be coming from people concerned with
> designing the perfect bureaucratic process. In any WG, there are
> implementers whose support is valuable. The rest of the participants
> are valuable when they fix bugs. JFC doesn't seem to fix many bugs,
> and drives implementers away in droves, from what I can see.

Which implementers are those?

Implementers don't spend their time jabbering on discussion groups;
they are too busy implementing.  Analyze, specific, code, test,
release.  No need for chewing the fat on a mailing list in that
process.  And there are only so many hours in a day, so one can spend
them doing things or spend them talking about doing things, but it's
hard to manage both.

> It has been suggested that I be placed under RFC 3683 sanctions in the
> past, though I suppose the offending messages have always been in
> response to misconduct (not a justification). I don't think the IETF
> is in any danger of developing a trigger finger here.

If all the time spent discussing this most useless of RFCs were
dedicated to actually addressing real problems, what might be
accomplished?


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 09:05:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F12Jh-0004in-Hz; Mon, 23 Jan 2006 09:05:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F12Jf-0004hc-F8
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 09:05:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20534
	for ; Mon, 23 Jan 2006 09:03:36 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12T0-0006tZ-V6
	for ietf@ietf.org; Mon, 23 Jan 2006 09:14:47 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NE4u7q062373
	for ; Mon, 23 Jan 2006 15:04:56 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 15:04:56 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1145450497.20060123150456@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060123042607.GPAL15577.fep01-app.kolumbus.fi@smtp.kolumbus.fi>
References: <20060123042607.GPAL15577.fep01-app.kolumbus.fi@smtp.kolumbus.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John Loughney writes:

> Now we're close to side veering off into process issues, but
> rather than going into that rat-hole, I'll just pose a question: do
> you think p2p protocol authors would have any motiviation to create
> a Security Considerations section that would pass IESG review?

Do you think that protocol authors would have any good reason to
submit anything for anyone's review, when the same time could be spent
writing software products?


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 09:32:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F12k8-0004Jr-Gw; Mon, 23 Jan 2006 09:32:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F01Nm-0002di-D0; Fri, 20 Jan 2006 13:53:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10036;
	Fri, 20 Jan 2006 13:51:43 -0500 (EST)
Received: from mercury.ccil.org ([192.190.237.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F01WW-0007Jk-8E; Fri, 20 Jan 2006 14:02:15 -0500
Received: from cowan by mercury.ccil.org with local (Exim 4.34)
	id 1F01Nd-0006F4-Ue; Fri, 20 Jan 2006 13:53:01 -0500
Date: Fri, 20 Jan 2006 13:52:57 -0500
To: iesg@ietf.org, ietf@ietf.org
Message-ID: <20060120185257.GE18960@ccil.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
From: John Cowan 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
X-Mailman-Approved-At: Mon, 23 Jan 2006 09:32:23 -0500
Cc: 
Subject: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I wish to state my strong support for the proposed RFC 3638 PR-action
against Jefsey Morfin.

Jefsey has made life nearly intolerable for those of us on the
ltru@ietf.org and language-tags@iana.org lists.  Banning him on a monthly
basis is insufficient; as soon as the ban is lifted, he returns to his
old habits of posting endless streams of irrelevant noise, vague threats,
and other forms of mailing list abuse.  He must then be warned and then
banned again in a purposeless monthly ritual.

Filtering him out individually, as I do, is insufficient: one still must
read the polite or exasperated responses of others.  I am almost at the
point where I will filter any posting that so much as *mentions* him.

In addition, I have been the direct victim of Jefsey's spleen: he
stepped outside the IETF context to send a request to my then employer
to have me disciplined by that employer for "unprofessional conduct".
As a result, my employer ordered me not to respond to him any more,
but since I have now left that employer, I will take this one action.
I will not stoop to taking revenge in kind, as I want nothing more than
never to hear from him or of him again.

-- 
Don't be so humble.  You're not that great.             John Cowan
        --Golda Meir                                    cowan@ccil.org

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 09:32:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F12k9-0004KR-Sx; Mon, 23 Jan 2006 09:32:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F10D8-00034u-Gv
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 06:50:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10418
	for ; Mon, 23 Jan 2006 06:48:44 -0500 (EST)
Received: from mr1.mastrocinque.net ([212.97.45.53] helo=mx3.memor.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F10MQ-0002Vk-U3
	for ietf@ietf.org; Mon, 23 Jan 2006 06:59:53 -0500
Received: from  [84.167.242.60] by mx3.memor.net
	(ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.8));
	Mon, 23 Jan 2006 12:50:22 +0100
Message-ID: <43D4C2C1.9020604@echnaton.serveftp.com>
Date: Mon, 23 Jan 2006 12:49:21 +0100
From: Peter Dambier 
Organization: Public-Root
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <955ba8bb0601221114h685054e6l7576d46de3b6ec46@mail.gmail.com>
	<20060123092239.GA20214@nic.fr>
In-Reply-To: <20060123092239.GA20214@nic.fr>
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ArGoMail-Authenticated: peter@publicroot.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 23 Jan 2006 09:32:23 -0500
Subject: Re: suggestion on distributed systems
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: peter@echnaton.serveftp.com
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stephane Bortzmeyer wrote:
> On Mon, Jan 23, 2006 at 12:44:11AM +0530,
>  Neil Harwani  wrote 
>  a message of 128 lines which said:
> 
> 
>>I am not sure whether this idea that I am about to write has been
>>implemented before
> 

"Operating Systems, Design and Implementation" by
Andrew S. Tannanbaum and Albert S. Woodhull,
ISBN 0-13-638677-6 Prentice Hall

Not only do the discuss every aspect of an operating system but
they include as an example and for homework practice the complete
Minix operating system plus source.

Tannenbaum has already written a distributed operating system and
you can find many of his ideas in this book.

Minix is also the origin of the linux operating system.

Minix is really modular. You can easyly take it apart and play
with the peaces. In particalur the devide between memory manager
and filesystem suggests to run the pieces distributed over
many computers.

Minix is designed as an academic exercise. I guess it might
give you ideas if not more.
> 
> The idea is interesting but it is clearly underspecified. Before a
> serious discussion can take place, you really have to specify it more
> completely. If you want the discussion to occur at the IETF, an
> Internet-Draft is the proper form:
> 
> http://www.ietf.org/ietf/1id-guidelines.html
> 
> Technically, I would suggest to think seriously about the Security
> Considerations of your Internet-Draft...
> 
> 
>>1. Have a variable system built into all OSes which have internet
>>interface which can allocate space and resources as per what amount
>>of space and resources are free on the OS.
> 
> 
> The big problem is to create a jail strong enough so that the hosted
> programs do not compromise or DoS the machine. This is *not* a trivial
> problem.
> 

Dr. Bernstein has written an intersting stack of modules

daemontools-0.76

is a stack for building demons. It provides a mechanism that
unifies the world of different unixes, linuxes and bsds broviding
a common interface and getting rid of any special treatment for
demons that differenciates them from "normal" programmes.

ucspi-tcp-0.88

provides a different tcp/ip stack that gets rid of most security
holes in common tcp/ip and socket libraries.

djbdns-1.05

finally gets rid of the "Buggy Internet Name Deamon" bind. Bind
before the version 9 did show several problems. Bernstein shows
an alternative for bind and resolver libraries.

http://lifewithdjbdns.org/

> 
>>Example : Suppose a server of paypal has to process millions of
>>records every month. If a high percentage of this processing is
>>encrypted and sent to container on various systems running on
>>internet, the same work can be done with less powerfull paypal
>>servers.
> 
> 
> Very bad example: first, all Paypal requests require access to the
> central database. And, second, Paypal would certainly not trust random
> Internet machines for its processing.

The example is good. It is management that is bad :)


Cheers
Peter and Karin Dambier


-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@echnaton.serveftp.com
mail: peter@peter-dambier.de
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 09:38:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F12pk-00057F-RK; Mon, 23 Jan 2006 09:38:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F12pi-00054M-29
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 09:38:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23616
	for ; Mon, 23 Jan 2006 09:36:40 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F12z1-0008WQ-Fh
	for ietf@ietf.org; Mon, 23 Jan 2006 09:47:51 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 8EDE82596EC;
	Mon, 23 Jan 2006 15:36:53 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 13634-04; Mon, 23 Jan 2006 15:36:48 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 774352596EB;
	Mon, 23 Jan 2006 15:36:47 +0100 (CET)
Date: Mon, 23 Jan 2006 06:37:54 -0800
From: Harald Tveit Alvestrand 
To: John Loughney , Scott W Brim 
Message-ID: <8F069763B60ED81B76567EBF@[10.21.114.126]>
In-Reply-To: <20060123042607.GPAL15577.fep01-app.kolumbus.fi@smtp.kolumbus.fi>
References: <20060123042607.GPAL15577.fep01-app.kolumbus.fi@smtp.kolumbus.fi >
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: ietf@ietf.org
Subject: P2P protocols (Re: Re: how to declare consensus when someone
 ignores consensus)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2051527975=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============2051527975==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========62E53C9F49D1BF4DFE5B=========="

--==========62E53C9F49D1BF4DFE5B==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable



--On 23. januar 2006 06:26 +0200 John Loughney =20
wrote:

>> On 01/22/2006 22:27 PM, John Loughney allegedly wrote:
>> > Look at various peer-to-peer protocols as a good
>> > examples of things that people use everyday, but wouldn't stand a
>> > chance of getting an RFC.
>>
>> Why not?
>
> Now we're close to side veering off into process issues, but rather than
> going into that rat-hole, I'll just pose a question: do you think p2p
> protocol authors would have any motiviation to create a Security
> Considerations section that would pass IESG review?

let's veer off... this is much more fun than other current discussions :-)

Since a major problem for "illegal" P2P networks at the moment is dealing=20
with content that is inserted maliciously (the file named "Britney Spears'=20
latest hit" that says "THOU SHALT NOT STEAL" in a thunderous voice), I=20
think they have a large motivation for workable security models...... and I =

suspect that the Security ADs would LOVE to see documented a security model =

that has been proved to work in that environment.

so I think this particular point is a red herring. Cost of participation=20
and patience with process may be bigger obstacles.

                  Harald




--==========62E53C9F49D1BF4DFE5B==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFD1OpCOMj+2+WY0F4RAp4hAJ0RxWbaSvSrdgKBYBKiMFFVOPF00ACgvhDj
0wu/JLYpF4mAQ24sDAF1LAQ=
=UI3S
-----END PGP SIGNATURE-----

--==========62E53C9F49D1BF4DFE5B==========--



--===============2051527975==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============2051527975==--





From ietf-bounces@ietf.org Mon Jan 23 09:43:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F12uR-0006B7-Nq; Mon, 23 Jan 2006 09:43:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F12uP-0006As-7T
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 09:43:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24021
	for ; Mon, 23 Jan 2006 09:41:34 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F133l-0000IR-L2
	for ietf@ietf.org; Mon, 23 Jan 2006 09:52:46 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id B633F2596EC;
	Mon, 23 Jan 2006 15:41:47 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 13803-02; Mon, 23 Jan 2006 15:41:42 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 95DB92596EB;
	Mon, 23 Jan 2006 15:41:41 +0100 (CET)
Date: Mon, 23 Jan 2006 06:42:48 -0800
From: Harald Tveit Alvestrand 
To: Neil Harwani , ietf@ietf.org
Message-ID: <9E9098A3DBC1C5663690DF0C@[10.21.114.126]>
In-Reply-To: <955ba8bb0601221114h685054e6l7576d46de3b6ec46@mail.gmail.com>
References: <955ba8bb0601221114h685054e6l7576d46de3b6ec46@mail.gmail.com>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: 
Subject: Re: suggestion on distributed systems
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0337082826=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============0337082826==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========3A39B5C7E6057E63494D=========="

--==========3A39B5C7E6057E63494D==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable



--On 23. januar 2006 00:44 +0530 Neil Harwani =20
wrote:

> My suggesionts:
> 1. Have a variable system built into all OSes which have internet
> interface which can allocate space and resources as per what amount of
> space and resources are free on the OS.
> 2. Let a separate new internet layer decide from where to pull data and
> where to be put on which system where there is space. This could be
> auotmatically encrypted and sent over the net and whereever there is free
> space it can put up to be processed or delivered as a service from a
> webserver. This same layer based on priorities of the data to be
> processed or delivered on net as per required could also decide on
> criticality and send it to free systems on internet.

It would be interesting to see whether such a system could be made to work=20
- the system I've seen that most resembles what you speak of is BOINC, the=20
Berkeley Open Infrastructure for Network Computing - see=20
 for details.

A separate, but also interesting, question is what parts of the system can=20
be usefully standardized.

                    Harald


--==========3A39B5C7E6057E63494D==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFD1OtoOMj+2+WY0F4RAiMbAJ9eZ1lShRatOWmNNAsM9y6bcNgSNwCcC9wR
+QJRlbBGlZDO6Q7QfQsqJMU=
=WwEP
-----END PGP SIGNATURE-----

--==========3A39B5C7E6057E63494D==========--



--===============0337082826==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0337082826==--





From ietf-bounces@ietf.org Mon Jan 23 09:58:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F138x-00045r-ST; Mon, 23 Jan 2006 09:58:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F138q-00044V-NA
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 09:58:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25271
	for ; Mon, 23 Jan 2006 09:56:30 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13IC-0000tg-If
	for ietf@ietf.org; Mon, 23 Jan 2006 10:07:41 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP
	id CDCA526C06D; Mon, 23 Jan 2006 15:57:52 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP
	id 901C426C0A6; Mon, 23 Jan 2006 15:57:51 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k0NEvpYa729208;
	Mon, 23 Jan 2006 15:57:51 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id 4F8B116AA06; Mon, 23 Jan 2006 15:57:51 +0100 (CET)
Date: Mon, 23 Jan 2006 15:57:51 +0100
From: Stephane Bortzmeyer 
To: Peter Dambier 
Message-ID: <20060123145751.GA22941@nic.fr>
References: <955ba8bb0601221114h685054e6l7576d46de3b6ec46@mail.gmail.com>
	<20060123092239.GA20214@nic.fr>
	<43D4C2C1.9020604@echnaton.serveftp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43D4C2C1.9020604@echnaton.serveftp.com>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: ietf@ietf.org
Subject: Re: suggestion on distributed systems
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, Jan 23, 2006 at 12:49:21PM +0100,
 Peter Dambier  wrote 
 a message of 112 lines which said:

> ucspi-tcp-0.88
> 
> provides a different tcp/ip stack

No, it is not a TCP/IP stack (just a framework and library to develop
network applications). Sometimes, I really wonder if you know what you
are talking about.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 10:00:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F13Ao-0004SF-VV; Mon, 23 Jan 2006 10:00:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F13Am-0004Re-Up
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 10:00:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25310
	for ; Mon, 23 Jan 2006 09:58:30 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13K7-0000vW-LP
	for ietf@ietf.org; Mon, 23 Jan 2006 10:09:42 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LY3GR3D6SW003KQR@mauve.mrochek.com> for
	ietf@ietf.org; Mon, 23 Jan 2006 06:59:44 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1138028383;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=lKJD48SYBPyqeg+8miQ0Y35LY
	Vuj4fnijJhg/L+J33HL7ErpfdXky2CkOOpPaPiVDGjnPvMc/XVV3RC0ZLg+/A==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LY2MHWCS7K00009A@mauve.mrochek.com>; Mon,
	23 Jan 2006 06:59:42 -0800 (PST)
To: Anthony G Atkielski 
Message-id: <01LY3GR2FJQA00009A@mauve.mrochek.com>
Date: Mon, 23 Jan 2006 06:40:32 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 23 Jan 2006 15:02:28 +0100"
	<543775398.20060123150228@atkielski.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20060122212732.LXWM29001.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
	<43D4023C.3090306@cisco.com>
	<68fba5c50601221506n37a25dbfk79bfac5484a0e9f0@mail.gmail.com>
	<543775398.20060123150228@atkielski.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: ietf@ietf.org
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Robert Sayre writes:

> > I suspect the IESG will find that the folks actually trying to get
> > work done in the presence of JFC's emails all feel the same way. Most
> > of the objections seem to be coming from people concerned with
> > designing the perfect bureaucratic process. In any WG, there are
> > implementers whose support is valuable. The rest of the participants
> > are valuable when they fix bugs. JFC doesn't seem to fix many bugs,
> > and drives implementers away in droves, from what I can see.

> Which implementers are those?

> Implementers don't spend their time jabbering on discussion groups;
> they are too busy implementing.

Gee, it's nice to know I don't exist - that will save me tons of time...

As it happens I'm actively involved in the implementation of almost all of the
protocol specifications I work on. I typically write the code myself for SMTP
and sieve  stuff, IMAP stuff is usually done by other people on my team. And
this code usually ends up in commercial products used at lots of sites to
support many millions of users - it is hardly an academic exercise.

I know lots of other IETF participants who are involved in specification
implementation. Quite a few of them write the code themselves. Some work on
open source, others on propietary implementations, and there are even some that
appear to do it just to make sure things really are implementable. In fact
there are entire WGs (e.g., sieve) where almost all of the active participants
appear to be implementors.

> Analyze, specific, code, test,
> release.  No need for chewing the fat on a mailing list in that
> process.

How very wrong you are. This sort of interaction is HUGELY valuable to
implementors.

> And there are only so many hours in a day, so one can spend
> them doing things or spend them talking about doing things, but it's
> hard to manage both.

This, at least, is true. But "hard to manage" != "imposssible to manage".

> > It has been suggested that I be placed under RFC 3683 sanctions in the
> > past, though I suppose the offending messages have always been in
> > response to misconduct (not a justification). I don't think the IETF
> > is in any danger of developing a trigger finger here.

> If all the time spent discussing this most useless of RFCs were
> dedicated to actually addressing real problems, what might be
> accomplished?

Aside from providing comic relief, exactly what does your your ridiculous
assertion that implmentors don't particulate in the IETF accomplish? 

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 10:33:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F13gn-00058c-8b; Mon, 23 Jan 2006 10:33:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F13gl-00058R-Aw
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 10:33:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27521
	for ; Mon, 23 Jan 2006 10:31:34 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13q3-00025s-UR
	for ietf@ietf.org; Mon, 23 Jan 2006 10:42:41 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NFWjBp063148
	for ; Mon, 23 Jan 2006 16:32:45 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 16:32:45 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <848652508.20060123163245@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D4C2C1.9020604@echnaton.serveftp.com>
References: <955ba8bb0601221114h685054e6l7576d46de3b6ec46@mail.gmail.com>
	<20060123092239.GA20214@nic.fr>
	<43D4C2C1.9020604@echnaton.serveftp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Subject: Re: suggestion on distributed systems
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Peter Dambier writes:

> "Operating Systems, Design and Implementation" by
> Andrew S. Tannanbaum and Albert S. Woodhull,
> ISBN 0-13-638677-6 Prentice Hall
>
> Not only do the discuss every aspect of an operating system but
> they include as an example and for homework practice the complete
> Minix operating system plus source.

It hardly discusses _every_ aspect of an operating system; a lot is
left out (presumably the stuff with which Tannebaum was unfamiliar).
It's still a good book.  It's a little bit too oriented towards UNIX,
though, IIRC--I guess that's the author's favorite OS.




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 10:36:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F13k0-0005tv-AG; Mon, 23 Jan 2006 10:36:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F13jy-0005ti-Ai
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 10:36:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27759
	for ; Mon, 23 Jan 2006 10:34:53 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13tK-0002F5-9X
	for ietf@ietf.org; Mon, 23 Jan 2006 10:46:03 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NFaBQ6063177
	for ; Mon, 23 Jan 2006 16:36:11 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 16:36:11 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1797258665.20060123163611@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060120185257.GE18960@ccil.org>
References: <20060120185257.GE18960@ccil.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John Cowan writes:

> Filtering him out individually, as I do, is insufficient: one still must
> read the polite or exasperated responses of others.  I am almost at the
> point where I will filter any posting that so much as *mentions* him.

Why don't you do that, then, so that he need not be banned just for
your convenience?

> In addition, I have been the direct victim of Jefsey's spleen: he
> stepped outside the IETF context to send a request to my then employer
> to have me disciplined by that employer for "unprofessional conduct".
> As a result, my employer ordered me not to respond to him any more,
> but since I have now left that employer, I will take this one action.
> I will not stoop to taking revenge in kind, as I want nothing more than
> never to hear from him or of him again.

But you still mention irrelevant matters external to this mailing list
in your post. Any personal problem you may have with someone outside
the list (or vice versa) is completely unrelated to IETF work or
mailing lists, and the inconvenience you suffer from having to press
the delete key is also only very tenuously linked to this list.

Maybe your employer's advice wasn't so bad.



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 10:44:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F13rk-00088V-Ti; Mon, 23 Jan 2006 10:44:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F13ri-00088Q-CU
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 10:44:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28598
	for ; Mon, 23 Jan 2006 10:42:53 -0500 (EST)
Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1414-0002a5-EO
	for ietf@ietf.org; Mon, 23 Jan 2006 10:54:03 -0500
Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43)
	id 1F13rQ-0001NZ-7m; Mon, 23 Jan 2006 15:44:04 +0000
Message-ID: <43D4FA42.5060202@dial.pipex.com>
Date: Mon, 23 Jan 2006 15:46:10 +0000
From: Elwyn Davies 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: nick.staff@comcast.net
References: <012220062226.13536.43D4068700038E41000034E0220075043800000E9B9CD2050C0702@comcast.net>
In-Reply-To: <012220062226.13536.43D4068700038E41000034E0220075043800000E9B9CD2050C0702@comcast.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


nick.staff@comcast.net wrote:

>
> Can you imagine if during every murder trial they had a debate on the 
> humanity of capitol punishment?
>
As a non-US citizen, I am a little hazy about some details of the US 
legal system.  Do I assume that this punishment requires the malefactor 
to sit through a set period of congressional filibusters?

I look forwards to a Supreme Court ruling outlawing it as a cruel and 
unusual punishment. 

Regards,
Elwyn

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 11:23:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F14TN-0000jq-Sa; Mon, 23 Jan 2006 11:23:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F14TK-0000jZ-RG
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 11:23:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00465
	for ; Mon, 23 Jan 2006 11:21:45 -0500 (EST)
Received: from mx2.nic.fr ([192.134.4.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14cf-0003gZ-DK
	for ietf@ietf.org; Mon, 23 Jan 2006 11:32:56 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx2.nic.fr (Postfix) with ESMTP id 6092526C0EC
	for ; Mon, 23 Jan 2006 17:23:10 +0100 (CET)
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151])
	by mx2.nic.fr (Postfix) with ESMTP id 0263C26C0A6
	for ; Mon, 23 Jan 2006 17:23:09 +0100 (CET)
Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69])
	by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id k0NGN8Ya861271
	for ; Mon, 23 Jan 2006 17:23:08 +0100 (CET)
Received: by batilda.nic.fr (Postfix, from userid 1000)
	id DE47016AA06; Mon, 23 Jan 2006 17:23:08 +0100 (CET)
Date: Mon, 23 Jan 2006 17:23:08 +0100
From: Stephane Bortzmeyer 
To: ietf@ietf.org
Message-ID: <20060123162308.GA29373@nic.fr>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1797258665.20060123163611@atkielski.com>
X-Operating-System: Debian GNU/Linux 3.1
X-Kernel: Linux 2.6.8-2-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new at mx2.nic.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, Jan 23, 2006 at 04:36:11PM +0100,
 Anthony G. Atkielski  wrote 
 a message of 31 lines which said:

> and the inconvenience you suffer from having to press the delete key

It is not just a matter of personal inconvenience: if the filtering is
done at the edges and not in the IETF mailing list engine, it also
means that public email archives (which are a very important tool for
the IETF) are polluted by the useless messages sent by people like
Jefsey Morfin.

RFC 3028 is not a sufficient solution for dealing with these people.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 11:33:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F14cr-0002tr-LN; Mon, 23 Jan 2006 11:33:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F14cq-0002rv-Cb
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 11:33:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01111
	for ; Mon, 23 Jan 2006 11:31:35 -0500 (EST)
Received: from purgatory.unfix.org ([213.136.24.43])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14mC-0003zm-N2
	for ietf@ietf.org; Mon, 23 Jan 2006 11:42:46 -0500
Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org
	[IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP id 2170F7F4B
	for ; Mon, 23 Jan 2006 17:32:35 +0100 (CET)
Message-ID: <43D50505.7050907@unfix.org>
Date: Mon, 23 Jan 2006 17:32:05 +0100
From: Jeroen Massar 
Organization: Unfix
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: ietf@ietf.org
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
In-Reply-To: <1797258665.20060123163611@atkielski.com>
X-Enigmail-Version: 0.94.0.0
OpenPGP: id=333E7C23;
	url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0692345211=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0692345211==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigF6E213CC300D4B3FCC96D95A"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF6E213CC300D4B3FCC96D95A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Anthony G. Atkielski wrote:
> John Cowan writes:
>=20
>> Filtering him out individually, as I do, is insufficient: one still mu=
st
>> read the polite or exasperated responses of others.  I am almost at th=
e
>> point where I will filter any posting that so much as *mentions* him.
>=20
> Why don't you do that, then, so that he need not be banned just for
> your convenience?

And then suddenly somebody makes a seriously good contribution and your
filter accidentally filters out that message which does have a lot of
value and thus importance for the working group. The signal to noise
ratio has risen way too much by all this talk about one person and
simply takes away a lot of time from a lot of people who can do a lot
more technically interesting work when that ratio is brought back to
signal instead of just being noise. Being able to completely shutdown a
person after having repeatedly warned that person about his behavior is
the only real solution here.

Another aspect is that the mailing lists also contains those
non-technical,non-wg-relevant discussions which effectively are on the
level of Usenet-alike flame war going back and forth in the mailing list
archives. Anybody wanting to join the wg will only find those messages,
possibly missing out on the things that really matter. That doesn't help
in progressing the task of the working group at all. Discussions should
be based on technical aspects relevant to that working group, not to a
myriad of other arguments which are far from the topic of the WG's task.

Yes, it is excluding somebody from giving his viewpoints, but it is not
without arguments that this will be done and the person who this is
bestowed upon has had many chances of bettering his way of posting and
drifting off topic all the time.

Note also that the PR only allows the complete banishment from the list
if that WG decides that that is deemed necessary. Other WG's which do
not have a problem with the postings of a PR'd person can freely choose
to accept them, but of course then have a choice to ban the person too.

[..]
> But you still mention irrelevant matters external to this mailing list
> in your post. Any personal problem you may have with someone outside
> the list (or vice versa) is completely unrelated to IETF work or
> mailing lists, and the inconvenience you suffer from having to press
> the delete key is also only very tenuously linked to this list.

Thus in your opinion you tolerate the behavior where people contact your
boss for actions you take personally (IETF is on personal basis not on
business basis, at least in theory) on a public forum!?

Another way to look at your point of view is to say that mailinglists
should accept spam. As the enduser who receives the list should simply
filter them out.

If somebody has a problem with you in the way you are behaving in such a
forum one contacts the list administrator or working group chair. It's a
list issue when it originates on the list, not a business issue, thus
your boss has absolutely no relevance in this area. It more sounds like
such a method can only be meant as a backstabbing 'teach a lesson'
method to a person than anything else. What good does that bring?
Or do you also call up the wife of the WG chair when you don't like his
decision to complain to him that she should give him food that evening
as you don't have any arguments left any more and simply start doing ad
hominem attacks?

> Maybe your employer's advice wasn't so bad.

That is is true of course, looking at the situation, taking a bit of a
stand-off point of view, reiterating things before doing etc are a good
thing, but sometimes the SnR ratio simply becomes way to high...

Greets,
 Jeroen


--------------enigF6E213CC300D4B3FCC96D95A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQFD1QUFKaooUjM+fCMRAkkaAJ44t3QBDQbzPaJ+bZFfgK+MtcXEegCeI93q
7+Xpg30T/QgQEqURQuhTc/w=
=KAkD
-----END PGP SIGNATURE-----

--------------enigF6E213CC300D4B3FCC96D95A--


--===============0692345211==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0692345211==--




From ietf-bounces@ietf.org Mon Jan 23 11:39:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F14ie-00054i-Aq; Mon, 23 Jan 2006 11:39:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F14id-00053Z-1y
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 11:39:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01467
	for ; Mon, 23 Jan 2006 11:37:33 -0500 (EST)
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14rz-0004Cf-Pm
	for ietf@ietf.org; Mon, 23 Jan 2006 11:48:45 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 0B9B3FB29D;
	Mon, 23 Jan 2006 11:38:54 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id BA8F13BFDA5;
	Mon, 23 Jan 2006 11:38:52 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: Harald Tveit Alvestrand 
In-Reply-To: (Your message of "Mon, 23 Jan 2006 06:37:54 PST.")
	<8F069763B60ED81B76567EBF@[10.21.114.126]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 23 Jan 2006 11:38:52 -0500
Message-Id: <20060123163852.BA8F13BFDA5@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: Scott W Brim , John Loughney ,
	ietf@ietf.org
Subject: Re: P2P protocols (Re: Re: how to declare consensus when someone
	ignores consensus) 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In message <8F069763B60ED81B76567EBF@[10.21.114.126]>, Harald Tveit Alvestrand 
writes:

>
>let's veer off... this is much more fun than other current discussions :-)
>Since a major problem for "illegal" P2P networks at the moment is dealing
>with content that is inserted maliciously (the file named "Britney Spears'
>latest hit" that says "THOU SHALT NOT STEAL" in a thunderous voice), I
>think they have a large motivation for workable security models...... and I
>suspect that the Security ADs would LOVE to see documented a security model
>that has been proved to work in that environment.
>

As a former Security AD, I can tell you that I have a research project 
going on some aspects of this.  Believe it or not, I think the issue is 
linked to BGP security.

The real problem in the Security Considerations, though, is the defense 
against subpoena attacks.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 11:45:19 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F14og-0006tP-Tz; Mon, 23 Jan 2006 11:45:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F14oe-0006tJ-Jl
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 11:45:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01734
	for ; Mon, 23 Jan 2006 11:43:47 -0500 (EST)
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14y1-0004No-DF
	for ietf@ietf.org; Mon, 23 Jan 2006 11:54:58 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 5828CFB2A1
	for ; Mon, 23 Jan 2006 11:45:14 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id 185303BFDA5
	for ; Mon, 23 Jan 2006 11:45:13 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: ietf@ietf.org
In-Reply-To: (Your message of "Mon, 23 Jan 2006 16:32:45 +0100.")
	<848652508.20060123163245@atkielski.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 23 Jan 2006 11:45:13 -0500
Message-Id: <20060123164513.185303BFDA5@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Subject: Re: suggestion on distributed systems 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


>> "Operating Systems, Design and Implementation" by
>> Andrew S. Tannanbaum and Albert S. Woodhull,
>> ISBN 0-13-638677-6 Prentice Hall
>>
>> Not only do the discuss every aspect of an operating system but
>> they include as an example and for homework practice the complete
>> Minix operating system plus source.
>
>It hardly discusses _every_ aspect of an operating system; a lot is
>left out (presumably the stuff with which Tannebaum was unfamiliar).

Nonsense.  Tanenbaum has forgotten more about operating systems than 
most of us will ever know.  But when you teach a subject, especially at 
the introductory level -- I'm teaching operating systems right now, 
using Tanenbaum's text -- you have to abstract out certain details and 
omit some others entirely.  

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 13:01:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F160W-0002hY-Kq; Mon, 23 Jan 2006 13:01:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F160R-0002hQ-7K
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 13:01:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06447
	for ; Mon, 23 Jan 2006 13:00:01 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F169n-0006sa-CD
	for ietf@ietf.org; Mon, 23 Jan 2006 13:11:13 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0NI1JnA019358; Mon, 23 Jan 2006 13:01:19 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18835; 
	Mon, 23 Jan 2006 13:01:18 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Mon, 23 Jan 2006 13:01:17 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886358@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Brian E Carpenter'" , ietf@ietf.org
Date: Mon, 23 Jan 2006 13:01:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: RE: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-
	04.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian,

	This seems to me to be somewhere on the continuum from "no
brainer" to "rocket science" - with a high likelihood of not being
too near the "rocket science" end.

	It would be good to caution the IETF Secretariat and meeting=20
sponsors to consider the potential for difficulty in getting into=20
and out of a specific meeting venue.  It is also a good idea for=20
would-be IETF meeting attendees to take time in advance of meetings=20
to discover for themselves whether there has been in the past - or=20
is likely to be in the future - any difficulty in getting into or=20
leaving some specific meeting location.  This applies to a lot of=20
different considerations, including political, medical and physical=20
issues with entry into and exit from any location.

	Many companies (and other organizations) maintain travel=20
advisory status on a number of places.  And sponsor organizations=20
are most likely aware of the potential for embarrassment if the
meeting location they sponsor causes a lot of grief for many of
the wanna-be attendees (roughly equivalent to not having thought
to offer T-shirts).

	There are plenty of reasons why people who might wish to
- or even need to - attend a meeting are unable to do so, and we
have been able to deal with it in the past.  That's one reason
why there is redundancy in the AD and WG Chair positions.

	About the only thing that really ought to be done is to
add a "caution" to the web page under each IETF meeting, that
would be where people could look to find out about any known=20
issues relating to the meeting venue.  Worst case scenarios
are the ones where someone gets to a venue and finds out about
serious problems that require them to immediately leave, or is
turned around en-route because of - for example - border entry=20
issues.=20

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]=20
--> On Behalf Of Brian E Carpenter
--> Sent: Sunday, January 22, 2006 4:01 AM
--> To: ietf@ietf.org
--> Subject: Re: I-D=20
--> ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
-->=20
--> Joe Abley wrote:
--> >=20
--> > On 20-Jan-2006, at 11:55, Wijnen, Bert (Bert) wrote:
--> >=20
--> >> Well said Barry!
--> >>
--> >>> From: Barry Leiba
--> >>>
--> >>> My biggest concern is in sections "2.3.  Freedom of=20
--> Participation"
--> >>> and "2.5.  Attendance Limitation and Visas", in that=20
--> I'm not sure
--> >>> how realistic they are.  Without getting overly into=20
--> politics (let's
--> >>> please not), I think they reflect a somewhat na=EFve view=20
--> of some of
--> >>> the political realities.  Specifically...
--> >>>
--> >>>     Meetings should not be held in countries where some
--> >>> attendees could
--> >>>     be disallowed entry or where freedom of speech is not
--> >>> guaranteed for
--> >>>     all participants.
--> >=20
--> >=20
--> > Indeed. Applied with vigour, this restriction implies=20
--> that no country =20
--> > is suitable to meet in. That leaves us with parts of=20
--> Antarctica, a =20
--> > floating venue located in international waters, or zero-g=20
--> bar BOFs in =20
--> > outer space. I favour the latter.
--> >=20
--> > A slightly more realistic approach might be to hold=20
--> meetings  regularly=20
--> > in different countries with (ideally) divergent security/=20
--> immigration=20
--> > policies, in the hope that successive meetings might at =20
--> least exclude=20
--> > different sets of people.
-->=20
--> This is a very important issue as we consider visiting=20
--> countries we've never
--> visited before and as visa regulations change in countries=20
--> we have been
--> to often. It would be very useful to know how more people=20
--> feel we should
--> tune these criteria.
-->=20
-->     Brian
-->=20
-->=20
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 13:08:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1679-0004Nc-2e; Mon, 23 Jan 2006 13:08:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1676-0004NR-Vw; Mon, 23 Jan 2006 13:08:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06768;
	Mon, 23 Jan 2006 13:06:55 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F16GU-00075K-Cz; Mon, 23 Jan 2006 13:18:07 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0NI7nnA019531; Mon, 23 Jan 2006 13:07:49 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19611; 
	Mon, 23 Jan 2006 13:07:49 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Mon, 23 Jan 2006 13:07:48 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886359@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Eliot Lear'" , Marshall Eubanks 
Date: Mon, 23 Jan 2006 13:07:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: Scott Hollenbeck , ietf@ietf.org,
	ietf-announce@ietf.org, iesg@ietf.org
Subject: RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Eliot,

	Plenty of time to ask why, once it becomes clear what the
prevalent opinion is.

	I personally find the question a bit on the obnoxious side
prior to that.  When seeking consensus, it is usually necessary 
only to determine what the issues are in the minority opinion,
and largely "nosy-ness" and distraction to ask the basis of the 
opinion among majority opinion holders.

	Consequently, people should first determine what direction
the group is leaning before hosing the discussion with a bunch
of questions about the why's and wherefore's of opinions.

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Eliot Lear
--> Sent: Sunday, January 22, 2006 7:25 AM
--> To: Marshall Eubanks
--> Cc: Scott Hollenbeck; ietf@ietf.org; 
--> ietf-announce@ietf.org; iesg@ietf.org
--> Subject: Re: IETF Last Call under RFC 3683 concerning JFC 
--> (Jefsey) Morfin
--> 
--> Marshall,
--> > I do not support approval of this PR-action.
--> 
--> Because.....??
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 13:12:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F16Aw-00057I-6m; Mon, 23 Jan 2006 13:12:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F16Ar-00056F-Iq
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 13:12:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06919
	for ; Mon, 23 Jan 2006 13:10:47 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F16KF-0007CS-Cz
	for ietf@ietf.org; Mon, 23 Jan 2006 13:22:00 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F16A7-0004IR-VA
	for ietf@ietf.org; Mon, 23 Jan 2006 19:11:32 +0100
Received: from 1cust154.tnt7.hbg2.deu.da.uu.net ([149.225.100.154])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Mon, 23 Jan 2006 19:11:31 +0100
Received: from nobody by 1cust154.tnt7.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Mon, 23 Jan 2006 19:11:31 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Mon, 23 Jan 2006 19:04:49 +0100
Organization: 
Lines: 7
Message-ID: <43D51AC1.702F@xyzzy.claranet.de>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust154.tnt7.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit
Subject: OT: The case of sysop twit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Anthony G. Atkielski wrote:

> banned just for your convenience?

Are you sure that you have read and understood
 ?



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 13:23:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F16LH-00008H-Oz; Mon, 23 Jan 2006 13:23:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F16LF-00006o-Ob; Mon, 23 Jan 2006 13:23:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07632;
	Mon, 23 Jan 2006 13:21:31 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F16Ud-0007WE-CU; Mon, 23 Jan 2006 13:32:44 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-2.cisco.com with ESMTP; 23 Jan 2006 10:22:51 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0NIMoKT016821;
	Mon, 23 Jan 2006 10:22:50 -0800 (PST)
Received: from [212.254.247.5] (ams-clip-vpn-dhcp628.cisco.com [10.61.66.116])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0NIRKL2014228;
	Mon, 23 Jan 2006 10:27:21 -0800
Message-ID: <43D51EF9.7040804@cisco.com>
Date: Mon, 23 Jan 2006 19:22:49 +0100
From: Eliot Lear 
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Gray, Eric" 
References: <313680C9A886D511A06000204840E1CF0C886359@whq-msgusr-02.pit.comms.marconi.com>
In-Reply-To: <313680C9A886D511A06000204840E1CF0C886359@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=317; t=1138040843; x=1138473043;
	c=relaxed/simple; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20
	|Subject:Re=3A=20IETF=20Last=20Call=20under=20RFC=203683=20concerning=20JFC=20(Je
	fsey)=20Morfin
	|To:=22Gray,=20Eric=22=20;
	X=v=3Dmtcc.com=3B=20h=3DJFDUaigzRLJOkNXuY+lNRenAFzc=3D;
	b=pqLeBz9m2mizkZ2ZJ6i9QktLzUtvXablPxdE/OBm6NFnMrQVo9AaY8aYJ02ZiIiYIXT4rn9k
	eCxQXRt0H+aX/Wc5P6HRFQEE/BILybiLyCHsXw96buL9TQuXUwQT/tBv3Tq1lUf6jWs0gKCJcUr
	4T8lNfe9Gf4HRYQluHJz83Ss=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com;
	dkim=pass ( message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Content-Transfer-Encoding: 7bit
Cc: Scott Hollenbeck , ietf@ietf.org,
	ietf-announce@ietf.org, iesg@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Marshall's not just some person with a random opinion, but the ombudsman
for the IETF list.  And so he speaks with some authority.  Also, he
doesn't come to rash conclusions, and so I for one value his considered
opinion.  And that's why I prodded him for more.  And I'm more
enlightened because of it.

Eliot

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 13:55:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F16qu-0000BS-A9; Mon, 23 Jan 2006 13:55:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F16qr-0000BI-My
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 13:55:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09514
	for ; Mon, 23 Jan 2006 13:54:11 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F170G-0008Vk-BK
	for ietf@ietf.org; Mon, 23 Jan 2006 14:05:24 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0NItJnA020858; Mon, 23 Jan 2006 13:55:19 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26384; 
	Mon, 23 Jan 2006 13:55:18 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Mon, 23 Jan 2006 13:55:17 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88635C@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Ned Freed'" , Anthony G Atkielski
	
Date: Mon, 23 Jan 2006 13:55:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Cc: ietf@ietf.org
Subject: RE: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ned,

	It is certainly fair to say that implementors do participate
in mailing list discussions, and that their participation is very
valuable.  However, many times the number of participants that are
"active" (read - vocal) are those that "lurk" and it is my opinion
- supported by observation of, and discussion with, implementors at 
a number of different companies - that the proportion of lurkers 
that are implementors is somewhat higher than the proportion of 
active participants that are also implementors.  I am also of the
opinion that for each participant (either lurker or active), there
are many implementors that participate "vicariously" through those
others in their organization who are more disposed to participate.

	The number of implementors that do not - therefore - actively
particpate in IETF working groups is many times the number that do
- and this would clearly look to many people (especially to an out-
sider) as if implementors are too busy implementing to participate 
in mailing list discussions.

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Ned Freed
--> Sent: Monday, January 23, 2006 9:41 AM
--> To: Anthony G Atkielski
--> Cc: ietf@ietf.org
--> Subject: Re: how to declare consensus when someone ignores consensus
--> 
--> > Robert Sayre writes:
--> 
--> > > I suspect the IESG will find that the folks actually 
--> trying to get
--> > > work done in the presence of JFC's emails all feel the 
--> same way. Most
--> > > of the objections seem to be coming from people concerned with
--> > > designing the perfect bureaucratic process. In any WG, there are
--> > > implementers whose support is valuable. The rest of the 
--> participants
--> > > are valuable when they fix bugs. JFC doesn't seem to 
--> fix many bugs,
--> > > and drives implementers away in droves, from what I can see.
--> 
--> > Which implementers are those?
--> 
--> > Implementers don't spend their time jabbering on 
--> discussion groups;
--> > they are too busy implementing.
--> 
--> Gee, it's nice to know I don't exist - that will save me 
--> tons of time...
--> 
--> As it happens I'm actively involved in the implementation 
--> of almost all of the
--> protocol specifications I work on. I typically write the 
--> code myself for SMTP
--> and sieve  stuff, IMAP stuff is usually done by other 
--> people on my team. And
--> this code usually ends up in commercial products used at 
--> lots of sites to
--> support many millions of users - it is hardly an academic exercise.
--> 
--> I know lots of other IETF participants who are involved in 
--> specification
--> implementation. Quite a few of them write the code 
--> themselves. Some work on
--> open source, others on propietary implementations, and 
--> there are even some that
--> appear to do it just to make sure things really are 
--> implementable. In fact
--> there are entire WGs (e.g., sieve) where almost all of the 
--> active participants
--> appear to be implementors.
--> 
--> > Analyze, specific, code, test,
--> > release.  No need for chewing the fat on a mailing list in that
--> > process.
--> 
--> How very wrong you are. This sort of interaction is HUGELY 
--> valuable to
--> implementors.
--> 
--> > And there are only so many hours in a day, so one can spend
--> > them doing things or spend them talking about doing 
--> things, but it's
--> > hard to manage both.
--> 
--> This, at least, is true. But "hard to manage" != 
--> "imposssible to manage".
--> 
--> > > It has been suggested that I be placed under RFC 3683 
--> sanctions in the
--> > > past, though I suppose the offending messages have 
--> always been in
--> > > response to misconduct (not a justification). I don't 
--> think the IETF
--> > > is in any danger of developing a trigger finger here.
--> 
--> > If all the time spent discussing this most useless of RFCs were
--> > dedicated to actually addressing real problems, what might be
--> > accomplished?
--> 
--> Aside from providing comic relief, exactly what does your 
--> your ridiculous
--> assertion that implmentors don't particulate in the IETF 
--> accomplish? 
--> 
--> 				Ned
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 14:26:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F17Kt-00079Z-Kg; Mon, 23 Jan 2006 14:26:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F17Kp-00077y-WA
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 14:26:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11377
	for ; Mon, 23 Jan 2006 14:25:09 -0500 (EST)
Received: from secure00.secure-transact.net ([63.247.65.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F17UE-00011a-BO
	for ietf@ietf.org; Mon, 23 Jan 2006 14:36:23 -0500
Received: from pcp08942197pcs.trentn01.nj.comcast.net ([69.141.172.43]
	helo=[192.168.0.100])
	by secure00.secure-transact.net with esmtp (Exim 4.52)
	id 1F17KT-0007Ed-4j
	for ietf@ietf.org; Mon, 23 Jan 2006 14:26:17 -0500
Mime-Version: 1.0 (Apple Message framework v746.2)
To: ietf@ietf.org
Message-Id: <25289E30-A03C-4B9B-9E98-278A54F6EB89@cookreport.com>
From: Gordon Cook 
Date: Mon, 23 Jan 2006 14:26:14 -0500
X-Mailer: Apple Mail (2.746.2)
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - secure00.secure-transact.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - cookreport.com
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Subject: what happened to America's internet Future? - a pointer to an essay
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1844323885=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============1844323885==
Content-Type: multipart/alternative; boundary=Apple-Mail-13-823384134


--Apple-Mail-13-823384134
Content-Type: text/plain;
	charset=WINDOWS-1252;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: quoted-printable

that I hope you will enjoy



Here with the first two paragraphs  -



Capitalism in the United States in the 21st century has not moved =20
forward with the rest of the world. We are still embedded in the post =20=

World War II mindset of America as the great economic power at the =20
peak of the industrial age. While many of our giant corporations are =20
shrinking in size, in 2005 in American telecom there were two major =20
exceptions to a trend in the technology area of downsizing driven by =20
increasing commoditization as companies try to become more nimble in =20
order to compete in a globalized economy.

The two largest local phone companies swallowed the two largest =20
American carriers. SBC merged with ATT and became the =93new=94 ATT and =20=

Verizon took over MCI.  Motivated they claimed by the goal of =20
economies of scale, CEOs Whittacre and Seidenberg asserted that they =20
could eliminate duplicative infrastructure and save money. What they =20
did not explain was the cost of adding more debt to their core =20
business and the expense of merging two huge and complex =20
organizations with complex billing systems. They also ignored =20
increasing enterprise customer anxiety as sources of redundant =20
network infrastructure vanished. Some observers speculated that the =20
real reasons for the mergers were the acquisition MCI and ATTs global =20=

IP backbone=92s free traffic interconnection with the other major =20
global players. In an increasingly all IP world, these resources had =20
the potential to enable more cost-effective competition in the =20
efforts of what some began to call Bell East and Bell West=92s efforts =20=

to provide television over their IP networks  efforts to compete with =20=

the MSO's cable modem service that will very likely fail.

you mat read the entire essay at

http://www.cookreport.com/14.11.shtml




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The COOK Report on Internet Protocol, 431 Greenway Ave, Ewing, NJ =20
08618 USA
609 882-2572 (PSTN) 415 651-4147 (Lingo) cook@cookreport.com =20
Subscription
info: http://cookreport.com/subscriptions.shtml How to Stop America's =20=

Broadband
decline and end LEC Mercantilism  at: http://cookreport.com/14.11.shtml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D





--Apple-Mail-13-823384134
Content-Type: text/html;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable


that I =
hope you will enjoy

Here =
with the first two paragraphs=A0 -

Capitalism in the United States in the 21st century has =
not moved forward with the rest of the world. We are still embedded in =
the post World War II mindset of America as the great economic power at =
the peak of the industrial age. While many of our giant corporations are =
shrinking in size, in 2005 in American telecom there were two major =
exceptions to a trend in the technology area of downsizing driven by =
increasing commoditization as companies try to become more nimble in =
order to compete in a globalized economy.
The two largest local phone companies swallowed the two =
largest American carriers. SBC merged with ATT and became the =93new=94 =
ATT and Verizon took over MCI. =AD Motivated they claimed by the goal of =
economies of scale, CEOs Whittacre and Seidenberg asserted that they =
could eliminate duplicative infrastructure and save money. What they did =
not explain was the cost of adding more debt to their core business and =
the expense of merging two huge and complex organizations with complex =
billing systems. They also ignored increasing enterprise customer =
anxiety as sources of redundant network infrastructure vanished. Some =
observers speculated that the real reasons for the mergers were the =
acquisition MCI and ATTs global IP backbone=92s free traffic =
interconnection with the other major global players. In an increasingly =
all IP world, these resources had the potential to enable more =
cost-effective competition in the efforts of what some began to call =
Bell East and Bell West=92s efforts to provide television over their IP =
networks =AD efforts to compete with the MSO's cable modem service that =
will very likely fail.
you mat read the entire essay at
http://www.cookreport.com/1=
4.11.shtml


 cook@cookreport.com =
Subscription
info: http://cookreport.com/s=
ubscriptions.shtml How to Stop America's =
Broadband=A0
decline=A0and end=A0LEC Mercantilism=A0=A0at: http://cookreport.com/14.11.sht=
ml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



 =

=

--Apple-Mail-13-823384134--


--===============1844323885==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1844323885==--




From ietf-bounces@ietf.org Mon Jan 23 14:41:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F17Yj-0001tw-Ai; Mon, 23 Jan 2006 14:41:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F17Yg-0001to-Ga; Mon, 23 Jan 2006 14:40:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12223;
	Mon, 23 Jan 2006 14:39:28 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F17i4-0001WW-NO; Mon, 23 Jan 2006 14:50:42 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0NJelnA022050; Mon, 23 Jan 2006 14:40:47 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA02068; 
	Mon, 23 Jan 2006 14:40:47 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Mon, 23 Jan 2006 14:40:46 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88635E@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Eliot Lear'" 
Date: Mon, 23 Jan 2006 14:40:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 3.0 (+++)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: "'ietf@ietf.org'" , "'iesg@ietf.org'" 
Subject: RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Eliot,

	Ideally, nobody is "just some person with a random opinion" 
and the implication associated with asserting that someone stands 
out because of this is disingenuous - to say the least.

	If we do in fact learn anything from the reply you elicited,
it is that there is more than one reason why the question is not
appropriate - for this kind of question and at this point in the
discussion.

	I do not doubt that you asked the question out of a sincere 
desire to find out what the answer is.  However, there are plenty
of people - here in the IETF as well as everywhere else in the
world - who ask "why" for no other reason than to put the person
expressing their opinion on the defensive.

	Consequently, I believe it is innappropriate to publicly
question - or otherwise challenge - the opinions being sought in
a discussion like this.  As the announcement said, the IESG will
be making a decision, it was the IESG that solicited comment and 
it should be up to the IESG to determine what level of detail is
required with those comments and when additional information is
needed.  I suspect that the IESG will solicit additional input if
they feel that there is a large minority opinion that they feel 
should be analyzed in detail.

	If people genuinely want to know what the basis for any
individuals comments are - or wants to know more than a person 
was willing to say initially, then they should ask privately.
If the individual in question receives enough private questions,
perhaps they will - as in this case - choose to give a public
answer.

	Or perhaps not.

--
Eric


--> -----Original Message-----
--> From: Eliot Lear [mailto:lear@cisco.com] 
--> Sent: Monday, January 23, 2006 1:23 PM
--> To: Gray, Eric
--> Cc: Marshall Eubanks; Scott Hollenbeck; ietf@ietf.org; 
--> ietf-announce@ietf.org; iesg@ietf.org
--> Subject: Re: IETF Last Call under RFC 3683 concerning JFC 
--> (Jefsey) Morfin
--> 
--> Marshall's not just some person with a random opinion, but 
--> the ombudsman
--> for the IETF list.  And so he speaks with some authority.  Also, he
--> doesn't come to rash conclusions, and so I for one value 
--> his considered
--> opinion.  And that's why I prodded him for more.  And I'm more
--> enlightened because of it.
--> 
--> Eliot
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 15:25:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F18FZ-0004Rz-3p; Mon, 23 Jan 2006 15:25:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F18FX-0004Ru-0M
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 15:25:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15207
	for ; Mon, 23 Jan 2006 15:23:44 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F18Ov-00032Z-73
	for ietf@ietf.org; Mon, 23 Jan 2006 15:34:59 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NKOvcp065758
	for ; Mon, 23 Jan 2006 21:24:57 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 21:24:57 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <629193965.20060123212457@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D50505.7050907@unfix.org>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com> <43D50505.7050907@unfix.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jeroen Massar writes:

> And then suddenly somebody makes a seriously good contribution and your
> filter accidentally filters out that message which does have a lot of
> value and thus importance for the working group.

Banning someone has the same effect, if that person has ever made any
useful contributions at all (and that applies to just about everyone).

Besides, you can filter without loss--by actually looking at messages.

> The signal to noise ratio has risen way too much by all this talk
> about one person and simply takes away a lot of time from a lot of
> people who can do a lot more technically interesting work when that
> ratio is brought back to signal instead of just being noise. Being
> able to completely shutdown a person after having repeatedly warned
> that person about his behavior is the only real solution here.

Most of the noise and disturbance I see isn't coming from a single
person, but from a lynch mob so obsessed with silencing someone they
don't like that they can't even do their jobs.

Why aren't you working on something productive, instead of joining in
this discussion, which precisely matches your apparent definition of
useless noise?  Why is it bad when someone else does it, but okay if
you do it?

> Yes, it is excluding somebody from giving his viewpoints, but it is not
> without arguments that this will be done and the person who this is
> bestowed upon has had many chances of bettering his way of posting and
> drifting off topic all the time.

What about excluding everyone else who whines about that person?
Wouldn't that make sense, too?

Then again, would there be anyone left if the same rules applied to
everyone?

> Thus in your opinion you tolerate the behavior where people contact your
> boss for actions you take personally (IETF is on personal basis not on
> business basis, at least in theory) on a public forum!?

No, I don't ... but I don't discuss them on the public forum.  I
discuss them with my lawyer, and all corrective action is taken
offline.  When someone libels you to your employer, complaining about
it on a mailing list is not the answer.

> Another way to look at your point of view is to say that mailinglists
> should accept spam. As the enduser who receives the list should simply
> filter them out.

Yes.  There's no way to reliably eliminate spam in an automated way,
so either you let it through and tolerate a lot of mail that isn't
important, or you block it and lose legitimate messages that you need
to see.  I need to see legitimate messages a lot more than I need to
block messages I find inconvenient, so I don't filter anything.  That
means I have to spend a few seconds deleting hundreds of spam messages
or more each day, but it vastly diminishes the possibility of me
losing legitimate e-mail.

> That is is true of course, looking at the situation, taking a bit of a
> stand-off point of view, reiterating things before doing etc are a good
> thing, but sometimes the SnR ratio simply becomes way to high...

No, sometimes the ability to stay cool is way too low.  But that's the
problem of the person who flies off the handle, not anyone else.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 15:26:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F18Gb-0004hO-0P; Mon, 23 Jan 2006 15:26:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F18GZ-0004h6-CP
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 15:26:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15309
	for ; Mon, 23 Jan 2006 15:24:48 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F18Px-00034p-2i
	for ietf@ietf.org; Mon, 23 Jan 2006 15:36:02 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NKQ7xZ065767
	for ; Mon, 23 Jan 2006 21:26:07 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 21:26:07 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1519021751.20060123212607@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060123162308.GA29373@nic.fr>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	<20060123162308.GA29373@nic.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Stephane Bortzmeyer writes:

> It is not just a matter of personal inconvenience: if the filtering is
> done at the edges and not in the IETF mailing list engine, it also
> means that public email archives (which are a very important tool for
> the IETF) are polluted by the useless messages sent by people like
> Jefsey Morfin.

Since public archives are usually a violation of copyright, anyway,
the entities that maintain them are poorly placed to complain.

And archives can be purged after the fact, without impairing the flow
of messages to the list in real time.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 15:27:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F18HT-0004o8-81; Mon, 23 Jan 2006 15:27:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F18HS-0004nu-4y
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 15:27:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15375
	for ; Mon, 23 Jan 2006 15:25:43 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F18Qq-00037f-BZ
	for ietf@ietf.org; Mon, 23 Jan 2006 15:36:58 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NKR2Q2065777
	for ; Mon, 23 Jan 2006 21:27:02 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 21:27:02 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <105616555.20060123212702@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060123164513.185303BFDA5@berkshire.machshav.com>
References: (Your message of "Mon, 23 Jan 2006 16:32:45 +0100.")
	<848652508.20060123163245@atkielski.com>
	<20060123164513.185303BFDA5@berkshire.machshav.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
Subject: Re: suggestion on distributed systems
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Steven M. Bellovin writes:

> Nonsense.  Tanenbaum has forgotten more about operating systems than
> most of us will ever know.

He has apparently forgotten a lot of things that I remember, or, more
likely, he just has never been exposed to them.  In his book he writes
about the things he knows, which is only logical, but he doesn't know
everything.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 15:29:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F18Jt-0005iN-Nq; Mon, 23 Jan 2006 15:29:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F18Js-0005iD-6W
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 15:29:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15732
	for ; Mon, 23 Jan 2006 15:28:13 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F18TG-0003GH-8n
	for ietf@ietf.org; Mon, 23 Jan 2006 15:39:27 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NKTW8B065804
	for ; Mon, 23 Jan 2006 21:29:32 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 21:29:32 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1152122513.20060123212932@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D51AC1.702F@xyzzy.claranet.de>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	<43D51AC1.702F@xyzzy.claranet.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit
Subject: Re: OT: The case of sysop twit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Frank Ellermann writes:

> Are you sure that you have read and understood
>  ?

I'm sure that I'm not interested in it.  It has nothing to do with the
IETF.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 16:14:13 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F190v-0001ly-Ef; Mon, 23 Jan 2006 16:14:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F190r-0001lY-5v
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 16:14:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19866
	for ; Mon, 23 Jan 2006 16:12:38 -0500 (EST)
Received: from osaka.law.miami.edu ([129.171.187.81])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F19AC-0005IR-QT
	for ietf@ietf.org; Mon, 23 Jan 2006 16:23:53 -0500
Received: (qmail 9501 invoked by uid 500); 23 Jan 2006 21:13:48 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
	by localhost with SMTP; 23 Jan 2006 21:13:48 -0000
Date: Mon, 23 Jan 2006 16:13:48 -0500 (EST)
From: "Michael Froomkin - U.Miami School of Law" 
To: ietf@ietf.org
In-Reply-To: <1519021751.20060123212607@atkielski.com>
Message-ID: 
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	<20060123162308.GA29373@nic.fr>
	<1519021751.20060123212607@atkielski.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Subject: List archives and copyright [WAS Re: John Cowan supports 3683
 PR-action against Jefsey Morfin]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: froomkin@law.tm
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



If you post to a list with a publicly announced public archive -- and even 
more so if you are informed about the archive at the time you join the 
list (hint: you usually are) -- then I think it's pretty clear under US 
law (and, I'd imagine but don't actually know, also the law of most 
civilized countries) that you are impliedly granting a license to archive 
by posting to the list.  Hence the archive is not a copyright violation.

Interesting academic questions might, or might not, arise if in a given 
post one attempted to assert that the implied license is being revoked for 
that post (including the issue of whether given the automation 
involved such an assertion could be legally effective), but they have low 
operational relevance to date.



On Mon, 23 Jan 2006, Anthony G. Atkielski wrote:

> Since public archives are usually a violation of copyright, anyway,
> the entities that maintain them are poorly placed to complain.
>
> And archives can be purged after the fact, without impairing the flow
> of messages to the list in real time.
>

-- 
http://www.icannwatch.org   Personal Blog: http://www.discourse.net
A. Michael Froomkin   |    Professor of Law    |   froomkin@law.tm
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's warm here.<--

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 16:41:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F19RR-0002mw-73; Mon, 23 Jan 2006 16:41:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F19RM-0002mX-Hc
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 16:41:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23380
	for ; Mon, 23 Jan 2006 16:40:03 -0500 (EST)
Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66]
	helo=episteme-software.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F19al-0006on-SZ
	for ietf@ietf.org; Mon, 23 Jan 2006 16:51:17 -0500
Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with
	ESMTP (EIMS X 3.3d15); Mon, 23 Jan 2006 15:41:14 -0600
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com (Unverified)
Message-Id: 
In-Reply-To: <43D0D59A.1010703@zurich.ibm.com>
References: <20060120104012.GE9015@login.ecs.soton.ac.uk>
	<43D0D59A.1010703@zurich.ibm.com>
X-Mailer: Eudora [Macintosh version 7.0a12]
Date: Mon, 23 Jan 2006 15:41:12 -0600
To: Brian E Carpenter 
From: Pete Resnick 
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: Tim Chown , ietf@ietf.org
Subject: Re: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 1/20/06 at 1:20 PM +0100, Brian E Carpenter wrote:

>Tim Chown wrote:
>
>>If you look back over past agendas, it's typically a day with 
>>around 3-5 meetings in one session to 11.30am, of which half or 
>>more are BoFs.
>
>Friday morning is part of the IETF. It's true that generally we 
>schedule about half as many parallel sessions as during the rest of 
>the week, but that means you only need to be in 4 places at once 
>instead of 8 the rest of the time.
>
>The survey results indicate that we shouldn't extend to a full day 
>on Friday, but scrapping those ~4 sessions would have serious impact 
>on scehduling constraints earlier in the week.

However, one of Tim's points is well-taken: We MUST stop scheduling 
BOFs when the likelihood of people attending drops. And saying 
"Friday is a real day" does no good if you put mostly BOFs on Friday. 
If you want people to stick around on Friday, put only the most 
important meetings then. (And no, I don't mind if my meetings are 
then. I'll be there anyway.) To the extent possible, BOFs should be 
early in the week so that they can be chewed on during the week.

pr
-- 
Pete Resnick 
QUALCOMM Incorporated

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 17:07:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F19qa-0002ur-D7; Mon, 23 Jan 2006 17:07:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F19qY-0002uc-6E
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 17:07:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26102
	for ; Mon, 23 Jan 2006 17:06:04 -0500 (EST)
Message-Id: <200601232206.RAA26102@ietf.org>
Received: from psg.com ([147.28.0.62] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F19zx-00086y-Ni
	for ietf@ietf.org; Mon, 23 Jan 2006 17:17:19 -0500
Received: from localhost ([127.0.0.1] helo=psg.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from ) id 1F19qV-0002rU-C8
	for ietf@ietf.org; Mon, 23 Jan 2006 22:07:31 +0000
To: ietf@ietf.org
Date: Mon, 23 Jan 2006 14:07:31 -0800
From: Allison Mankin 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: Re: IETFs... the final Friday? 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Three comments on Friday scheduling:

1.
In my scheduling struggle as AD, I've always needed Fridays pretty
desperately, though I'm hopeful that with the RAI/TSV split, things
will be better.

2.
Some of us wondered if Friday would be more attractive if the net
didn't come down at noon, so that if you commit to staying for the WG
meeting on Friday morning, and you have a late flight, or fly out the
next morning, you can get some work or email done during the rest of
the day.

Anyone else find resonance with that?

3.
Finally, I noticed the IAD included a question about Friday meeting or
not in the survey we were invited to on 9 January.  Getting a sense of
peoples' views quantitatively is good, though that was a
self-selected group, rather than a random sample that could be
assigned a statistical mapping to the IETF population.

Allison


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 17:11:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F19u1-0003PK-Bq; Mon, 23 Jan 2006 17:11:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F19tz-0003PA-74
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 17:11:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26320
	for ; Mon, 23 Jan 2006 17:09:37 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1A3M-0008Cm-5o
	for ietf@ietf.org; Mon, 23 Jan 2006 17:20:51 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0NMAmtV066509
	for ; Mon, 23 Jan 2006 23:10:48 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Mon, 23 Jan 2006 23:10:48 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <788033752.20060123231048@atkielski.com>
To: ietf@ietf.org
In-Reply-To: 
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	<20060123162308.GA29373@nic.fr>
	<1519021751.20060123212607@atkielski.com>
	
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Subject: Re: List archives and copyright [WAS Re: John Cowan supports 3683
	PR-action against Jefsey Morfin]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Michael Froomkin - U.Miami School of Law writes:

> If you post to a list with a publicly announced public archive -- and even
> more so if you are informed about the archive at the time you join the
> list (hint: you usually are) -- then I think it's pretty clear under US
> law (and, I'd imagine but don't actually know, also the law of most 
> civilized countries) that you are impliedly granting a license to archive
> by posting to the list.  Hence the archive is not a copyright violation.

The key phrase here is "you are informed."  You have to be informed
and agree to it.  Forcing someone to click on a button that
acknowledges reading about the archive is a way to do this (commonly
used for software and various Web sites).  Just assuming that someone
has read fine print somewhere on some Web page associated with the
list is not sufficient, however.

> Interesting academic questions might, or might not, arise if in a given
> post one attempted to assert that the implied license is being revoked for
> that post (including the issue of whether given the automation 
> involved such an assertion could be legally effective), but they have low
> operational relevance to date.

Well, that would depend on the agreement, wouldn't it?  Which is all
the more reason to compel a participant to read about archiving
permission and agree to it explicitly in some way.

There are more egregious infringements on the Net, such as Turn It In.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 17:14:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F19xR-00049T-Et; Mon, 23 Jan 2006 17:14:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F19xP-00049G-KP
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 17:14:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26577
	for ; Mon, 23 Jan 2006 17:13:10 -0500 (EST)
Received: from purgatory.unfix.org ([213.136.24.43])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1A6o-0008Ky-36
	for ietf@ietf.org; Mon, 23 Jan 2006 17:24:24 -0500
Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org
	[IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP id C5AA07F69;
	Mon, 23 Jan 2006 23:14:13 +0100 (CET)
Message-ID: <43D55517.4010803@unfix.org>
Date: Mon, 23 Jan 2006 23:13:43 +0100
From: Jeroen Massar 
Organization: Unfix
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: froomkin@law.tm
References: <20060120185257.GE18960@ccil.org>	<1797258665.20060123163611@atkielski.com>	<20060123162308.GA29373@nic.fr>	<1519021751.20060123212607@atkielski.com>
	
In-Reply-To: 
X-Enigmail-Version: 0.94.0.0
OpenPGP: id=333E7C23;
	url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: ietf@ietf.org
Subject: Re: List archives and copyright [WAS Re: John Cowan supports 3683
 PR-action against Jefsey Morfin]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1082184859=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1082184859==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig1DEA80F855A278F204FB80E7"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1DEA80F855A278F204FB80E7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Michael Froomkin - U.Miami School of Law wrote:
> 
>=20
> If you post to a list with a publicly announced public archive -- and
> even more so if you are informed about the archive at the time you join=

> the list (hint: you usually are) -- then I think it's pretty clear unde=
r
> US law [..]

IANAL but one really doesn't have to bother with US law, that really
doesn't apply to many folks (fortunately :) There is a much better thing
than US law, it's called IETF, and the fact that there is:
http://www.ietf.org/maillist-new.html which contains:
8<--------------
All IETF Contributions are subject to the rules of RFC 3978 and RFC 3979.=

-------------->8
Mailinglist traffic also are subject to that.
One gets a copy of this when signing up for the various lists.

On Mon, 23 Jan 2006, Anthony G. Atkielski wrote:

> Since public archives are usually a violation of copyright, anyway,
> the entities that maintain them are poorly placed to complain.

According to you Google and every other website indexing service is a
violation of copyright, better get sue'ing then, you might get rich.

> And archives can be purged after the fact, without impairing the flow
> of messages to the list in real time.

Archives are meant to store things, which is what they are doing, if you
don't want to contribute then simply don't.

Greets,
 Jeroen

(Who wonders that now I've quoted mr Atkielski if I am in violation of
his copyright...)



--------------enig1DEA80F855A278F204FB80E7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQFD1VUXKaooUjM+fCMRAnkrAKDArcbSEnrl6Kmj81Rhk5+ugRlJuACaA6Kt
7ndvIZ3vCOFv9zxFAWWOzMk=
=nqfh
-----END PGP SIGNATURE-----

--------------enig1DEA80F855A278F204FB80E7--


--===============1082184859==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1082184859==--




From ietf-bounces@ietf.org Mon Jan 23 17:16:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F19zY-0004OR-JX; Mon, 23 Jan 2006 17:16:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F19SO-0002xk-52
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 16:42:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23435
	for ; Mon, 23 Jan 2006 16:41:06 -0500 (EST)
Received: from motgate2.mot.com ([144.189.100.101])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F19bm-0006rb-Lx
	for ietf@ietf.org; Mon, 23 Jan 2006 16:52:20 -0500
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231])
	by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k0NM0dSE003296
	for ; Mon, 23 Jan 2006 15:00:39 -0700 (MST)
Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5])
	by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k0NLxfwD019203
	for ; Mon, 23 Jan 2006 15:59:41 -0600 (CST)
Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72)
	id ; Mon, 23 Jan 2006 16:42:22 -0500
Message-ID: <62173B970AE0A044AED8723C3BCF23810C679FEF@ma19exm01.e6.bcs.mot.com>
From: Grossman Dan-LDG004 
To: ietf@ietf.org
Date: Mon, 23 Jan 2006 16:42:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 2.3 (++)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
X-Mailman-Approved-At: Mon, 23 Jan 2006 17:16:50 -0500
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1356402232=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1356402232==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C62065.E42B1132"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C62065.E42B1132
Content-Type: text/plain

Let me preface this by saying that I have no direct interest in ietf-languages or LTRU, nor do I have technical expertise in this area.  I have also been on a temporary hiatus from active participation in IETF.
 
That said, I overcome my usual reluctance to engage in IETF list discussions to oppose this action.
 
Unlike the previous matter of an individual who clearly engaged in threats and ad-homenem attacks, this appears perilously close to being an attempt to suppress a minority viewpoint.   Minority viewpoints need to be heard, regardless of whether the minority is a minority of one, and regardless of how persistent and how (in)articulate the minority may be.  This does not mean that the chair cannot find consensus against the minority view.  However, it strikes me as an abuse of process to revoke posting rights because the majority is tired of hearing the minority opinion.
 
 Mr. Morfin has been accused of straying into "off-topic" postings.  I cannot judge from the examples presented whether this is the case. However, I observe that setting WG scope can serve a constructive purpose in allowing the group to maintain focus by avoiding peripheral issues, or it can be a way of biasing the agenda toward a particular result, of ignoring important issues or of suppressing dissent.
 
Having been both in majorities and in minorities over the past 20 years or so, I know that process protection for minority rights is frustrating to the majority.  I also recognize that the minority is sometimes right.  Patient negotiation, no matter how difficult or time consuming, is the best remedy.
 
I urge the IESG to give Mr. Morfin the benefit of the doubt.  

------_=_NextPart_001_01C62065.E42B1132
Content-Type: text/html
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA2LjAwLjI4MDAuMTUyOCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW
PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTU0NTE2MTMyMS0yMzAxMjAwNj5M
ZXQgbWUgcHJlZmFjZSB0aGlzIA0KYnkgc2F5aW5nIHRoYXQgSSBoYXZlIG5vIGRpcmVjdCBpbnRl
cmVzdCBpbiBpZXRmLWxhbmd1YWdlcyBvciBMVFJVLCBub3IgZG8gSSANCmhhdmUgdGVjaG5pY2Fs
IGV4cGVydGlzZSBpbiB0aGlzIGFyZWEuJm5ic3A7IEkgaGF2ZSBhbHNvIGJlZW4gb24gYSANCnRl
bXBvcmFyeSZuYnNwO2hpYXR1cyBmcm9tIGFjdGl2ZSBwYXJ0aWNpcGF0aW9uIGluIElFVEYuPC9T
UEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpj
bGFzcz01NDUxNjEzMjEtMjMwMTIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+
PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NTQ1MTYxMzIxLTIzMDEyMDA2PlRo
YXQgc2FpZCwgSSANCm92ZXJjb21lIG15IHVzdWFsIHJlbHVjdGFuY2UgdG8gZW5nYWdlIGluIElF
VEYgbGlzdCBkaXNjdXNzaW9ucyB0byBvcHBvc2UgdGhpcyANCmFjdGlvbi48L1NQQU4+PC9GT05U
PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTU0NTE2
MTMyMS0yMzAxMjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl
PUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz01NDUxNjEzMjEtMjMwMTIwMDY+VW5saWtlIHRoZSBw
cmV2aW91cyANCm1hdHRlciBvZiBhbiBpbmRpdmlkdWFsJm5ic3A7d2hvJm5ic3A7Y2xlYXJseSBl
bmdhZ2VkJm5ic3A7aW4gdGhyZWF0cyBhbmQgDQphZC1ob21lbmVtIGF0dGFja3MsIHRoaXMgYXBw
ZWFycyBwZXJpbG91c2x5IGNsb3NlIHRvIGJlaW5nIGFuIGF0dGVtcHQgdG8gDQpzdXBwcmVzcyBh
IG1pbm9yaXR5IHZpZXdwb2ludC4mbmJzcDsmbmJzcDsgTWlub3JpdHkgdmlld3BvaW50cyBuZWVk
IHRvIGJlIGhlYXJkLCANCnJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgbWlub3JpdHkgaXMgYSBt
aW5vcml0eSBvZiBvbmUsIGFuZCByZWdhcmRsZXNzIG9mIGhvdyANCnBlcnNpc3RlbnQgYW5kIGhv
dyAoaW4pYXJ0aWN1bGF0ZSB0aGUgbWlub3JpdHkgbWF5IGJlLiZuYnNwOyBUaGlzIGRvZXMgbm90
IG1lYW4gDQp0aGF0IHRoZSBjaGFpciBjYW5ub3QgZmluZCBjb25zZW5zdXMgYWdhaW5zdCB0aGUg
bWlub3JpdHkgdmlldy4mbmJzcDsgSG93ZXZlciwgDQppdCBzdHJpa2VzIG1lIGFzIGFuIGFidXNl
IG9mIHByb2Nlc3MgdG8gcmV2b2tlIHBvc3RpbmcgcmlnaHRzIGJlY2F1c2UgdGhlIA0KbWFqb3Jp
dHkgaXMgdGlyZWQgb2YgaGVhcmluZyB0aGUgbWlub3JpdHkgb3Bpbmlvbi48L1NQQU4+PC9GT05U
PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTU0NTE2
MTMyMS0yMzAxMjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl
PUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz01NDUxNjEzMjEtMjMwMTIwMDY+Jm5ic3A7TXIuIE1v
cmZpbiBoYXMgDQpiZWVuIGFjY3VzZWQgb2YmbmJzcDtzdHJheWluZyBpbnRvICJvZmYtdG9waWMi
IHBvc3RpbmdzLiZuYnNwOyBJIGNhbm5vdCBqdWRnZSANCmZyb20gdGhlIGV4YW1wbGVzIHByZXNl
bnRlZCB3aGV0aGVyIHRoaXMgaXMgdGhlIGNhc2UuIEhvd2V2ZXIsIEkgb2JzZXJ2ZSB0aGF0IA0K
c2V0dGluZyBXRyBzY29wZSBjYW4gc2VydmUgYSBjb25zdHJ1Y3RpdmUgcHVycG9zZSBpbiBhbGxv
d2luZyB0aGUgZ3JvdXAgdG8gDQptYWludGFpbiBmb2N1cyBieSBhdm9pZGluZyBwZXJpcGhlcmFs
IGlzc3Vlcywgb3IgaXQgY2FuIGJlIGEgd2F5IG9mIGJpYXNpbmcgdGhlIA0KYWdlbmRhIHRvd2Fy
ZCBhIHBhcnRpY3VsYXIgcmVzdWx0LCBvZiBpZ25vcmluZyBpbXBvcnRhbnQgaXNzdWVzIG9yIG9m
IA0Kc3VwcHJlc3NpbmcgZGlzc2VudC48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm
YWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTU0NTE2MTMyMS0yMzAxMjAwNj48L1NQQU4+
PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBj
bGFzcz01NDUxNjEzMjEtMjMwMTIwMDY+SGF2aW5nIGJlZW4gYm90aCBpbiANCm1ham9yaXRpZXMg
YW5kIGluIG1pbm9yaXRpZXMgb3ZlciB0aGUgcGFzdCAyMCB5ZWFycyBvciBzbywgSSBrbm93IHRo
YXQgcHJvY2VzcyANCnByb3RlY3Rpb24gZm9yIG1pbm9yaXR5IHJpZ2h0cyBpcyBmcnVzdHJhdGlu
ZyB0byB0aGUgbWFqb3JpdHkuJm5ic3A7IEkgYWxzbyANCnJlY29nbml6ZSB0aGF0IHRoZSBtaW5v
cml0eSBpcyBzb21ldGltZXMgcmlnaHQuJm5ic3A7IFBhdGllbnQgbmVnb3RpYXRpb24sIG5vIA0K
bWF0dGVyIGhvdyBkaWZmaWN1bHQgb3IgdGltZSBjb25zdW1pbmcsIGlzIHRoZSBiZXN0IHJlbWVk
eS48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BB
TiANCmNsYXNzPTU0NTE2MTMyMS0yMzAxMjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0K
PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz01NDUxNjEzMjEtMjMwMTIw
MDY+SSB1cmdlIHRoZSBJRVNHIHRvIA0KZ2l2ZSBNci4gTW9yZmluIHRoZSBiZW5lZml0IG9mIHRo
ZSBkb3VidC4mbmJzcDsgDQo8L1NQQU4+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo=

------_=_NextPart_001_01C62065.E42B1132--


--===============1356402232==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1356402232==--




From ietf-bounces@ietf.org Mon Jan 23 17:16:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F19za-0004PQ-75; Mon, 23 Jan 2006 17:16:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F19n4-0001c4-Ql
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 17:03:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25928
	for ; Mon, 23 Jan 2006 17:02:29 -0500 (EST)
Received: from web52807.mail.yahoo.com ([206.190.48.250])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F19wR-00080M-Ta
	for ietf@ietf.org; Mon, 23 Jan 2006 17:13:43 -0500
Received: (qmail 42426 invoked by uid 60001); 23 Jan 2006 22:03:36 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=U89cdRTwoV9joNinZlTCjmVOI6GjdZvMewu5Re1f+UdqMUaKLc6HkumOmvm5FqywpljAZZiBJrT8Q4iGX508dkBkaF/lcZGzOP3GT1HeysPRvK45a1u939HdoBqnsMvGo3LROqAeSeZa8gEctWDqOuQSET8ALDf1154Qi87L8QM=
	; 
Message-ID: <20060123220336.42424.qmail@web52807.mail.yahoo.com>
Received: from [206.15.92.7] by web52807.mail.yahoo.com via HTTP;
	Mon, 23 Jan 2006 14:03:34 PST
Date: Mon, 23 Jan 2006 14:03:34 -0800 (PST)
From: Sean Dorman 
To: nick.staff@comcast.net
In-Reply-To: <012220061838.14198.43D3D12E0009C39600003776220588601400000E9B9CD2050C0702@comcast.net>
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
X-Mailman-Approved-At: Mon, 23 Jan 2006 17:16:50 -0500
Cc: 
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1469548450=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1469548450==
Content-Type: multipart/alternative; boundary="0-1183586555-1138053814=:39034"
Content-Transfer-Encoding: 8bit

--0-1183586555-1138053814=:39034
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

I vote in favor of keeping Mr.Morfin as a member of IETF. The greater number of intelligent contributors, the better...
   
  This has been enough of a waste of time that we need to shift gears and focus on important issues.
   
  Regardless of whether or not a differing viewpoint is respected, consensus or no, it still gives me the opportunity to rethink aspects of important issues.
   
  Sincerely,
  Sean M. Dorman
  IT Manager, Network admin
  Sonitrol Security of Fresno

nick.staff@comcast.net wrote:
    -------------- Original message -------------- 
From: Eliot Lear  

> Marshall, 
> > I do not support approval of this PR-action. 
> 
> Because.....?? 
> 
Eliot-
  I don't mean any offense by this but the "Because" is the whole problem of these PR-Actions.  Somehow "rough concensus" has turned into "the IESG is the jury and the IETF members have to make convincing arguments one way or the other".  The IESG need not be convinved of anything and the "because" is not anyone's bussiness but yours (and is quite frankly off topic unless you start a WG called "why I don't think so-and-so should play here anymore").
  I mean really, has anyone ever had their opinion changed because of something someone said during these PR-Actions?  Because if you have you certainly didn't share that with the rest of us (making your change of heart null unless you mailed it to the IESG).
  Motion.  Vote.  NO CROSS TALK.  Decide.  Move on.
  Or just admit merely controlling who gets to speak isn't satisfying enough, you must also convince everyone you are right   For that's the only reason for these absurdities as I'm sure you already know.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
  


		
---------------------------------
Yahoo! Photos
 Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.
--0-1183586555-1138053814=:39034
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


I vote in favor of keeping Mr.Morfin as a member of IETF. The greater number of intelligent contributors, the better...
  
 
  
This has been enough of a waste of time that we need to shift gears and focus on important issues.
  
 
  
Regardless of whether or not a differing viewpoint is respected, consensus or no, it still gives me the opportunity to rethink aspects of important issues.
  
 
  
Sincerely,
  
Sean M. Dorman
  
IT Manager, Network admin
  
Sonitrol Security of Fresno

nick.staff@comcast.net wrote:
  
  
-------------- Original message -------------- 
From: Eliot Lear <lear@cisco.com> 

> Marshall, 
> > I do not support approval of this PR-action. 
> 
> Because.....?? 
> 
Eliot- 
 
I don't mean any offense by this but the "Because" is the whole problem of these PR-Actions.  Somehow "rough concensus" has turned into "the IESG is the jury and the IETF members have to make convincing arguments one way or the other".  The IESG need not be convinved of anything and the "because" is not anyone's bussiness but yours (and is quite frankly off topic unless you start a WG called "why I don't think so-and-so should play here anymore").
  
I mean really, has anyone ever had their opinion changed because of something someone said during these PR-Actions?  Because if you have you certainly didn't share that with the rest of us (making your change of heart null unless you mailed it to the IESG).
  
Motion.  Vote.  NO CROSS TALK.  Decide.  Move on.
  
Or just admit merely controlling who gets to speak isn't satisfying enough, you must also convince everyone you are right   For that's th!
 e only
 reason for these absurdities as I'm sure you already know.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
  


		
Yahoo! Photos
 
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.
--0-1183586555-1138053814=:39034--


--===============1469548450==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1469548450==--




From ietf-bounces@ietf.org Mon Jan 23 17:22:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1A4u-0006Jo-5M; Mon, 23 Jan 2006 17:22:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1A4s-0006Jj-CC
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 17:22:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27367
	for ; Mon, 23 Jan 2006 17:20:53 -0500 (EST)
Received: from biscayne-one-station.mit.edu ([18.7.7.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1AEI-0000En-35
	for ietf@ietf.org; Mon, 23 Jan 2006 17:32:07 -0500
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id
	k0NMMIo3023608; Mon, 23 Jan 2006 17:22:18 -0500 (EST)
Received: from [18.188.3.208] (ken-wireless.dyn.mit.edu [18.188.3.208])
	(authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0NMM6tI005511
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Mon, 23 Jan 2006 17:22:07 -0500 (EST)
In-Reply-To: <200601232206.RAA26102@ietf.org>
References: <200601232206.RAA26102@ietf.org>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <990E19C4-E511-485D-962D-27F7C05A1573@mit.edu>
From: Ken Raeburn 
Date: Mon, 23 Jan 2006 17:22:03 -0500
To: IETF General Discussion Mailing List 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Subject: Re: IETFs... the final Friday? 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jan 23, 2006, at 17:07, Allison Mankin wrote:
> 2.
> Some of us wondered if Friday would be more attractive if the net
> didn't come down at noon, so that if you commit to staying for the WG
> meeting on Friday morning, and you have a late flight, or fly out the
> next morning, you can get some work or email done during the rest of
> the day.
>
> Anyone else find resonance with that?

Definitely.  Tearing it down at noon definitely gives the feeling of  
"you're done, you should be gone now".

> 3.
> Finally, I noticed the IAD included a question about Friday meeting or
> not in the survey we were invited to on 9 January.  Getting a sense of
> peoples' views quantitatively is good, though that was a
> self-selected group, rather than a random sample that could be
> assigned a statistical mapping to the IETF population.

How about a questionnaire at the next IETF or two?  (With collection  
going through Friday noon at least, of course.)  Still somewhat self- 
selected, but it's reaching out specifically to those who attend  
regularly.

Ken

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 17:24:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1A6c-0006l0-Ci; Mon, 23 Jan 2006 17:24:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1A6b-0006kv-4a
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 17:24:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27755
	for ; Mon, 23 Jan 2006 17:22:39 -0500 (EST)
Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1AG0-0000Lw-9H
	for ietf@ietf.org; Mon, 23 Jan 2006 17:33:54 -0500
Received: from [127.0.0.1] (www.caia.swin.edu.au [136.186.229.16])
	by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id JAA750834;
	Tue, 24 Jan 2006 09:23:52 +1100 (EST)
Message-ID: <43D55775.1020509@swin.edu.au>
Date: Tue, 24 Jan 2006 09:23:49 +1100
From: grenville armitage 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <20060120185257.GE18960@ccil.org>	<1797258665.20060123163611@atkielski.com>	<20060123162308.GA29373@nic.fr>	<1519021751.20060123212607@atkielski.com>	
	<43D55517.4010803@unfix.org>
In-Reply-To: <43D55517.4010803@unfix.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
Subject: Re: List archives and copyright [WAS Re: John Cowan supports 3683
 PR-action against Jefsey Morfin]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jeroen Massar wrote:
	[..]
> (Who wonders that now I've quoted mr Atkielski if I am in violation of
> his copyright...)

Well, you certainly caused some his blather to make it past my
receiver-side filters.... ironic, given the context of the thread.

cheers,
gja

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 17:25:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1A7u-0007LV-VG; Mon, 23 Jan 2006 17:25:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1A7t-0007LQ-8D
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 17:25:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28294
	for ; Mon, 23 Jan 2006 17:23:59 -0500 (EST)
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1AHI-0000UW-JA
	for ietf@ietf.org; Mon, 23 Jan 2006 17:35:14 -0500
Received: from lars.local (p54AD3189.dip0.t-ipconnect.de [84.173.49.137])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 9EF1A1BAC9E;
	Mon, 23 Jan 2006 23:25:15 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by lars.local (Postfix) with ESMTP id 4FFAB67CC6E;
	Mon, 23 Jan 2006 23:25:14 +0100 (CET)
In-Reply-To: <200601232206.RAA26102@ietf.org>
References: <200601232206.RAA26102@ietf.org>
Mime-Version: 1.0 (Apple Message framework v746.2)
Message-Id: 
From: Lars Eggert 
Date: Mon, 23 Jan 2006 23:25:11 +0100
To: Allison Mankin 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: ietf@ietf.org
Subject: Re: IETFs... the final Friday? 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0634022063=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0634022063==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-27-834121726;
	protocol="application/pkcs7-signature"


--Apple-Mail-27-834121726
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

On Jan 23, 2006, at 23:07, Allison Mankin wrote:
> Some of us wondered if Friday would be more attractive if the net
> didn't come down at noon, so that if you commit to staying for the WG
> meeting on Friday morning, and you have a late flight, or fly out the
> next morning, you can get some work or email done during the rest of
> the day.
>
> Anyone else find resonance with that?

Yes! Since HIPRG meets Friday afternoon and there are often no  
flights back to Europe after it ends, we typically have to stay until  
Saturday. (Then again, free wireless is pretty easy to find in most  
cities these days.)

Lars
--
Lars Eggert                                     NEC Network Laboratories


--Apple-Mail-27-834121726
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw
ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE
EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN
AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv
AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK
xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF
DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ
vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C
AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l
dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS
vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2
usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu
mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT
G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl
ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa
LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud
HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs
Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf
qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa
9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G
CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy
ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT
FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq
hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw
NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx
EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO
ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI
hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT
wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z
9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY
LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD
VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy
ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz
MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0
QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9
3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR
piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB
KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1
aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDYwMTIzMjIyNTEyWjAjBgkqhkiG9w0BCQQxFgQUH7VrWKNZMIid0/2qhP8A
gGGZpAkwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu
LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg
THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu
bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq
hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl
bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD
VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw
JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA
BIIBAIJfZyropn1GTjQB9RvCTvI5ontpxrrmTPgu//PpWaHk5YcXrAH0vaDTyieCKdzC4SvBXoJH
FBSf37tFAZ9q0ZPJ4Cj9go8ECqpVtckV7V6lDf6H9anFAY3GMLw3NFU6gtmLoOi6SMSP6DtakIQY
ledgaFk4Ka5oxPiuLmSqrq51gXQPUcai/ZJJ/AaNIb9jg23IhdM1TEsJcWQ7Z7W0jUGDxZBba8e/
u8GBNXI/M0CSX94rBihMKCIyTFa59ZzRlFWDgmuFgan4OJIz3yYWz2bQWMCFFyya1lExtfCxGi0c
j3i858BdFKoVZt1CAbXk08XhekxXblzwiklyFVm7mDgAAAAAAAA=

--Apple-Mail-27-834121726--


--===============0634022063==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0634022063==--




From ietf-bounces@ietf.org Mon Jan 23 17:26:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1A97-0007Xd-7a; Mon, 23 Jan 2006 17:26:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1A94-0007WU-Vj
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 17:26:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28541
	for ; Mon, 23 Jan 2006 17:25:13 -0500 (EST)
Received: from raman.networkresonance.com ([198.144.196.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1AIU-0000Xv-3w
	for ietf@ietf.org; Mon, 23 Jan 2006 17:36:27 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001)
	id ABA8C1E8C1B; Mon, 23 Jan 2006 14:26:31 -0800 (PST)
To: Ken Raeburn 
References: <200601232206.RAA26102@ietf.org>
	<990E19C4-E511-485D-962D-27F7C05A1573@mit.edu>
From: Eric Rescorla 
Date: Mon, 23 Jan 2006 14:26:31 -0800
In-Reply-To: <990E19C4-E511-485D-962D-27F7C05A1573@mit.edu> (Ken Raeburn's
	message of "Mon, 23 Jan 2006 17:22:03 -0500")
Message-ID: <86zmlmk2co.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: IETF General Discussion Mailing List 
Subject: Re: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ken Raeburn  writes:

> On Jan 23, 2006, at 17:07, Allison Mankin wrote:
>> 2.
>> Some of us wondered if Friday would be more attractive if the net
>> didn't come down at noon, so that if you commit to staying for the WG
>> meeting on Friday morning, and you have a late flight, or fly out the
>> next morning, you can get some work or email done during the rest of
>> the day.
>>
>> Anyone else find resonance with that?
>
> Definitely.  Tearing it down at noon definitely gives the feeling of
> "you're done, you should be gone now".

Totally agree.

-Ekr

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 17:42:49 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1AOf-00051J-8x; Mon, 23 Jan 2006 17:42:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1AOd-00051E-5O
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 17:42:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00779
	for ; Mon, 23 Jan 2006 17:41:17 -0500 (EST)
Received: from sccrmhc12.comcast.net ([204.127.202.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1AY3-0001Jw-1p
	for ietf@ietf.org; Mon, 23 Jan 2006 17:52:32 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (sccrmhc12) with SMTP
	id <2006012322423601200me670e>; Mon, 23 Jan 2006 22:42:36 +0000
Message-ID: <037f01c6206e$24234360$a9087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: <200601232206.RAA26102@ietf.org>
Date: Mon, 23 Jan 2006 16:41:24 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Subject: Re: IETFs... the final Friday? 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> 2.
> Some of us wondered if Friday would be more attractive if the net
> didn't come down at noon, so that if you commit to staying for the WG
> meeting on Friday morning, and you have a late flight, or fly out the
> next morning, you can get some work or email done during the rest of
> the day.
>
> Anyone else find resonance with that?

Oh, yeah. In addition to the people who mentioned RGs and ad hocs meeting on 
Friday afternoon, there really are a bunch of IETF people staying over 
Friday night for Saturday flights, but you can't find them, because the bars 
went offline after lunch, so they're all in their rooms :-)

I've stayed for drafting sessions on Friday afternoons - we were the last 
people unplugged (thanks to the secretariat), but we were unplugged at about 
2:30 PM, and we were a lot more productive when we were plugged in.

There are IETF meeting sites where I've found reasonable non-IETF wireless 
on Friday afternoons and evenings, but it's not consistently "there" yet.

I've also seen hotels offering "Internet access", which turned out to be one 
computer that you couldn't unplug, in major cities within the last six 
months. Not at the hotels we have deals with, but not everyone can afford to 
stay at the "official" hotels...

Thanks for asking, Allison,

Spencer 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 17:45:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1AR8-0005Jx-UH; Mon, 23 Jan 2006 17:45:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1AR6-0005Jn-70
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 17:45:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00944
	for ; Mon, 23 Jan 2006 17:43:50 -0500 (EST)
From: rpelletier@isoc.org
Received: from smtp116.iad.emailsrvr.com ([207.97.245.116]
	helo=smtp136.iad.emailsrvr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1AaU-0001PI-3g
	for ietf@ietf.org; Mon, 23 Jan 2006 17:55:05 -0500
Received: from secure.webmail.us (webmail3.r1.iad.emailsrvr.com [10.238.10.11])
	by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id 8877844C275
	for ; Mon, 23 Jan 2006 17:45:07 -0500 (EST)
Received: from 128.9.168.71 (Webmail authenticated user rpelletier@isoc.org,
	rpelletier@isoc.org); by secure.webmail.us with HTTP;
	Mon, 23 Jan 2006 17:45:07 -0500 (EST)
Message-ID: <2304.128.9.168.71.1138056307.webmail@128.9.168.71>
Date: Mon, 23 Jan 2006 17:45:07 -0500 (EST)
To: ietf@ietf.org
X-Mailer: Webmail v3
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: OK
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: quoted-printable
Subject: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rpelletier@isoc.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

All;

More than 300 responded to the Meeting Survey conducted following IETF 64
in Vancouver.

See survey results link below.

Among the results are:
1.  Slightly more than 25% say their laptop is compatible with 802.11a.
[Note the IETF 65 NOC for Dallas recommends 802.11a]

2.  Nearly 60% (with an additional 23% undecided) prefer dinner following
all sessions of the day.

3.  Only 23% prefer a full day schedule for Fridays.

4.  Cookies are not the only craving for breaks -- 74% want more healthy
choices.

5.  Only 1/3 of the respondents expressed satisfaction with the wireless
connectivity.

And given the opportunity to say what they liked and didn't - 130 told us
how they felt.

Read it for yourselves: http://www.surveymonkey.com/Report.asp?U=3D165657=
447306

I and NeuStar Secretariat Services will review these results and make
adjustments as possible for IETF 65 Dallas, March 19 - 24.  And we look
forward to seeing you there.

Thanks for your participation.

Ray Pelletier
IETF Administrative Director.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 18:10:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1ApJ-00045h-MZ; Mon, 23 Jan 2006 18:10:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ApH-00045Z-5q
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 18:10:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02762
	for ; Mon, 23 Jan 2006 18:08:49 -0500 (EST)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1Ayh-0002LD-4K
	for ietf@ietf.org; Mon, 23 Jan 2006 18:20:04 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170])
	by minbar.fac.cs.cmu.edu id aa15684; 23 Jan 2006 18:10 EST
Date: Mon, 23 Jan 2006 18:10:04 -0500
From: Jeffrey Hutzelman 
To: EKR , Ken Raeburn 
Message-ID: <89C6E50B5BBFB767B68066FF@sirius.fac.cs.cmu.edu>
In-Reply-To: <86zmlmk2co.fsf@raman.networkresonance.com>
References: <200601232206.RAA26102@ietf.org>
	<990E19C4-E511-485D-962D-27F7C05A1573@mit.edu>
	<86zmlmk2co.fsf@raman.networkresonance.com>
Originator-Info: login-token=Mulberry:017vi9tlhgMio6QzU3IXbtJYVq9OF1LDZbbesbJHg=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: IETF General Discussion Mailing List 
Subject: Re: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Monday, January 23, 2006 02:26:31 PM -0800 Eric Rescorla 
 wrote:

> Ken Raeburn  writes:
>
>> On Jan 23, 2006, at 17:07, Allison Mankin wrote:
>>> 2.
>>> Some of us wondered if Friday would be more attractive if the net
>>> didn't come down at noon, so that if you commit to staying for the WG
>>> meeting on Friday morning, and you have a late flight, or fly out the
>>> next morning, you can get some work or email done during the rest of
>>> the day.
>>>
>>> Anyone else find resonance with that?
>>
>> Definitely.  Tearing it down at noon definitely gives the feeling of
>> "you're done, you should be gone now".
>
> Totally agree.

As do I.  Of course, agreeing that the net should stay up the rest of 
Friday is the easy part.  The hard part is getting the volunteers who do 
the work to commit to staying around that long...

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 20:03:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Can-00025t-JL; Mon, 23 Jan 2006 20:03:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Cal-000225-7Z
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 20:03:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20324
	for ; Mon, 23 Jan 2006 20:01:56 -0500 (EST)
Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1CkC-0001I9-9V
	for ietf@ietf.org; Mon, 23 Jan 2006 20:13:13 -0500
Received: from root (helo=think.thunk.org)
	by thunker.thunk.org with local-esmtps 
	(tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32)  (Exim 4.50 #1 (Debian))
	id 1F1Cac-0001fR-0m; Mon, 23 Jan 2006 20:03:18 -0500
Received: from tytso by think.thunk.org with local (Exim 4.50)
	id 1F191D-0006iy-DC; Mon, 23 Jan 2006 16:14:31 -0500
Date: Mon, 23 Jan 2006 16:14:31 -0500
From: "Theodore Ts'o" 
To: ietf@ietf.org
Message-ID: <20060123211430.GA14409@thunk.org>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1797258665.20060123163611@atkielski.com>
User-Agent: Mutt/1.5.11
X-SA-Exim-Connect-IP: 
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, Jan 23, 2006 at 04:36:11PM +0100, Anthony G. Atkielski wrote:
> > Filtering him out individually, as I do, is insufficient: one still must
> > read the polite or exasperated responses of others.  I am almost at the
> > point where I will filter any posting that so much as *mentions* him.
> 
> Why don't you do that, then, so that he need not be banned just for
> your convenience?

The problem with the "just filter" approach is that if you then fail
to respond to something of substance that got inadvertently filtered
out, it is trivially easy to claim rough consensus.  So if everyone
followed your advice (except for the poor wg chair, who has to judge
consensus, so he/she would be forced to read through all of the
dreck), it would be trivially easy for a group to get something past
the wg; just have 2 or 3 people suggest something that would normally
be controversial, insert the keyword " somewhere in the text,
and then when no one responds because they have all filtered out any
text containing the word "Jefsey", the 2 or 3 people can claim rough
consensus and the change goes in.  :-)

						- Ted

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 20:18:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1CpT-0006rN-8P; Mon, 23 Jan 2006 20:18:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1CpM-0006qC-4W
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 20:18:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21673
	for ; Mon, 23 Jan 2006 20:17:01 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Cyj-0001tl-7g
	for ietf@ietf.org; Mon, 23 Jan 2006 20:28:17 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0O1IbDf009462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2006 17:18:38 -0800
Message-ID: <43D58045.4030405@dcrocker.net>
Date: Mon, 23 Jan 2006 17:17:57 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Brian E Carpenter 
References: <20060120104012.GE9015@login.ecs.soton.ac.uk>	<43D0D59A.1010703@zurich.ibm.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


>  To the extent possible, BOFs should be early in the week so 
> that they can be chewed on during the week.

This strikes me as a singularly useful point:

    Some meetings, such as BOFs, can be expected to generate (and warrant) 
follow-on hallway discussion.

    We should try to schedule those meetings to leave days for that.

d/


-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 20:32:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1D2l-0002wt-P6; Mon, 23 Jan 2006 20:32:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1D2k-0002wb-0u; Mon, 23 Jan 2006 20:32:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22519;
	Mon, 23 Jan 2006 20:30:51 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F1DC9-0002Kd-FF; Mon, 23 Jan 2006 20:42:08 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F1D2V-0006lD-KA; Mon, 23 Jan 2006 17:32:08 -0800
Message-Id: <6.2.3.4.2.20060123185209.0531feb0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Mon, 23 Jan 2006 23:24:07 +0100
To: Jeroen Massar , ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <43D50505.7050907@unfix.org>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	<43D50505.7050907@unfix.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-493A2340
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: IESG 
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 17:32 23/01/2006, Jeroen Massar wrote:
>Thus in your opinion you tolerate the behavior where people contact 
>your boss for actions you take personally (IETF is on personal basis 
>not on business basis, at least in theory) on a public forum!?

I do not want to add to the triggered DoS. I only suggest you do as 
Marhall did: read the archives and speak the truth. I obviously 
forgive John Cowan. But when you use your corporate mail to harass 
someone, his clients find it in Google. He can lose some, as we did 
or they can call your corporation. And you need help, what I 
provided; and he needs it to stop, what I obtained. I am surprised no 
one realises that a PR action is a license to publicly defame a 
person, terminate projects and kill small businesses or non-profits. 
That has consequences on him and on the people and R&D he subsidises 
(I am my own boss for 20 years). People may also get ashamed or feel 
stupid further on.

Should RFC 3066 be applied and the IANA manage, publish and control 
the ietf-languages@alvestrand.no mailing list, appealing on competent 
local experts from everywhere, on an equal no harassment lingual 
opportunity basis, you would have never heard of me - except through 
my currently delayed projects.  But RFC 3066 Bis cleaning, Tunis 
covenant, officially floated possible IANA sale start bettering the 
things. I won. Bickering and bittering will not change that on the 
long range. It should be time for everyone to accept the open use implications.

jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 20:35:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1D6D-0003ak-SE; Mon, 23 Jan 2006 20:35:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1D6C-0003aQ-3F
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 20:35:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22733
	for ; Mon, 23 Jan 2006 20:34:25 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1DFd-0002Rg-Cu
	for ietf@ietf.org; Mon, 23 Jan 2006 20:45:42 -0500
Received: from [192.168.0.2] (adsl-71-131-32-235.dsl.sntc01.pacbell.net
	[71.131.32.235]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0O1aL8W016257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2006 17:36:21 -0800
Message-ID: <43D5846C.7030209@dcrocker.net>
Date: Mon, 23 Jan 2006 17:35:40 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Grossman Dan-LDG004 
References: <62173B970AE0A044AED8723C3BCF23810C679FEF@ma19exm01.e6.bcs.mot.com>
In-Reply-To: <62173B970AE0A044AED8723C3BCF23810C679FEF@ma19exm01.e6.bcs.mot.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


> Unlike the previous matter of an individual who clearly engaged in 
> threats and ad-homenem attacks, this appears perilously close to being 
> an attempt to suppress a minority viewpoint.   


There is a basic difference between preventing the expression of an opinion, 
idea or the like, versus preventing what is effectively a denial of service 
attack on the conduct of group business.

This difference is massive.

An organization like the IETF absolutely MUST encourage the former.  But it 
cannot survive any sustained amount of the latter.

Yes, one can no doubt construct all sorts of scenarios that are in a gray area 
between the two.  Therefore any group that is concerned about permitting -- and 
even encouraging -- the former, needs to make any rules against the latter 
involve scaling a significant hurdle.  In other words, the excesses that 
constitute a "violation" need to be huge.

It is difficult to imagine any reasonable person looking at the particulars of 
the current case and having even the slightest doubt that things are far, far 
beyond any possible gray area.

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 20:36:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1D6w-0003nJ-Mx; Mon, 23 Jan 2006 20:36:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1D6v-0003nA-KL
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 20:36:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22804
	for ; Mon, 23 Jan 2006 20:35:11 -0500 (EST)
Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1DGM-0002U6-Vj
	for ietf@ietf.org; Mon, 23 Jan 2006 20:46:28 -0500
Received: from root (helo=think.thunk.org)
	by thunker.thunk.org with local-esmtps 
	(tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32)  (Exim 4.50 #1 (Debian))
	id 1F1D6q-0001nh-HG; Mon, 23 Jan 2006 20:36:37 -0500
Received: from tytso by think.thunk.org with local (Exim 4.50)
	id 1F1D6j-0002cc-5e; Mon, 23 Jan 2006 20:36:29 -0500
Date: Mon, 23 Jan 2006 20:36:29 -0500
From: "Theodore Ts'o" 
To: Jeffrey Hutzelman 
Message-ID: <20060124013629.GA27182@thunk.org>
References: <200601232206.RAA26102@ietf.org>
	<990E19C4-E511-485D-962D-27F7C05A1573@mit.edu>
	<86zmlmk2co.fsf@raman.networkresonance.com>
	<89C6E50B5BBFB767B68066FF@sirius.fac.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <89C6E50B5BBFB767B68066FF@sirius.fac.cs.cmu.edu>
User-Agent: Mutt/1.5.11
X-SA-Exim-Connect-IP: 
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: Ken Raeburn ,
	IETF General Discussion Mailing List 
Subject: Re: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, Jan 23, 2006 at 06:10:04PM -0500, Jeffrey Hutzelman wrote:
> As do I.  Of course, agreeing that the net should stay up the rest of 
> Friday is the easy part.  The hard part is getting the volunteers who do 
> the work to commit to staying around that long...

... not to mention the cost of keeping the hotel rooms for the extra
day or so.  (Presumably if some or all of the wireless infrastructure
is left running until Friday night, it means that at least some of the
rooms can't get released back to the hotel until mid-day Saturday, and
the volunteers will have to do some of the final teardown Saturday
morning.)

						- Ted

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 20:45:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1DFV-0007A0-CL; Mon, 23 Jan 2006 20:45:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1DFS-00077p-Ui
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 20:45:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23533
	for ; Mon, 23 Jan 2006 20:44:00 -0500 (EST)
Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1DOt-0002pE-WF
	for ietf@ietf.org; Mon, 23 Jan 2006 20:55:17 -0500
Received: from [127.0.0.1] (www.caia.swin.edu.au [136.186.229.16])
	by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id MAA798068;
	Tue, 24 Jan 2006 12:45:18 +1100 (EST)
Message-ID: <43D586A9.8090304@swin.edu.au>
Date: Tue, 24 Jan 2006 12:45:13 +1100
From: grenville armitage 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF list 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Subject: posting privileges vs receiver-side filtering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


It seems we regularly miss some simple points:

Receiver-side filtering:

	- protects the sanity of an individual mailinglist recipient
	 (for their own personal definition of sanity).

Revocation of posting privileges:

	- protects agains dilution of a WG's historical record
	  (archives that soak up all posts to the WG's mailing list)

	- improves the 'signal to distraction' ratio of traffic on the
	  list (particularly important for list residents charged with
	  keeping things on charter and evaluating rough consensus)

Yes, revocation of posting privileges and receiver-side filtering both
cause a drop in traffic reaching one's inbox. But that doesn't 
make the actions equivalent.

cheers,
gja


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 20:48:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1DIR-00082N-9a; Mon, 23 Jan 2006 20:48:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1DIP-00081e-4C; Mon, 23 Jan 2006 20:48:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23812;
	Mon, 23 Jan 2006 20:47:02 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F1DRq-0002ww-JA; Mon, 23 Jan 2006 20:58:19 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3820207; Mon, 23 Jan 2006 20:45:09 -0500
In-Reply-To: <313680C9A886D511A06000204840E1CF0C88635E@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF0C88635E@whq-msgusr-02.pit.comms.marconi.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Mon, 23 Jan 2006 20:48:30 -0500
To: "Gray, Eric" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit
Cc: "'ietf@ietf.org'" , 'Eliot Lear' ,
	"'iesg@ietf.org'" 
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hello;

Receiving multiple queries as to why I made a decision makes me wonder
if I made it properly and articulated it properly. Thus, in the  
course of a sleepless
night fueled by jet-lag, I looked into the matter further with the  
results as you have seen.

I still think that a simple support / do not support response is more  
appropriate in this matter
and regret that it seemed necessary to expend list bandwidth on my  
reasoning.

Regards
Marshall

P.S. I was not appointed "ombudsman for the IETF list" and would not  
claim that honor.

On Jan 23, 2006, at 2:40 PM, Gray, Eric wrote:

> Eliot,
>
> 	Ideally, nobody is "just some person with a random opinion"
> and the implication associated with asserting that someone stands
> out because of this is disingenuous - to say the least.
>
> 	If we do in fact learn anything from the reply you elicited,
> it is that there is more than one reason why the question is not
> appropriate - for this kind of question and at this point in the
> discussion.
>
> 	I do not doubt that you asked the question out of a sincere
> desire to find out what the answer is.  However, there are plenty
> of people - here in the IETF as well as everywhere else in the
> world - who ask "why" for no other reason than to put the person
> expressing their opinion on the defensive.
>
> 	Consequently, I believe it is innappropriate to publicly
> question - or otherwise challenge - the opinions being sought in
> a discussion like this.  As the announcement said, the IESG will
> be making a decision, it was the IESG that solicited comment and
> it should be up to the IESG to determine what level of detail is
> required with those comments and when additional information is
> needed.  I suspect that the IESG will solicit additional input if
> they feel that there is a large minority opinion that they feel
> should be analyzed in detail.
>
> 	If people genuinely want to know what the basis for any
> individuals comments are - or wants to know more than a person
> was willing to say initially, then they should ask privately.
> If the individual in question receives enough private questions,
> perhaps they will - as in this case - choose to give a public
> answer.
>
> 	Or perhaps not.
>
> --
> Eric
>
>
> --> -----Original Message-----
> --> From: Eliot Lear [mailto:lear@cisco.com]
> --> Sent: Monday, January 23, 2006 1:23 PM
> --> To: Gray, Eric
> --> Cc: Marshall Eubanks; Scott Hollenbeck; ietf@ietf.org;
> --> ietf-announce@ietf.org; iesg@ietf.org
> --> Subject: Re: IETF Last Call under RFC 3683 concerning JFC
> --> (Jefsey) Morfin
> -->
> --> Marshall's not just some person with a random opinion, but
> --> the ombudsman
> --> for the IETF list.  And so he speaks with some authority.   
> Also, he
> --> doesn't come to rash conclusions, and so I for one value
> --> his considered
> --> opinion.  And that's why I prodded him for more.  And I'm more
> --> enlightened because of it.
> -->
> --> Eliot
> -->
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 21:16:20 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1DjI-0007mr-5f; Mon, 23 Jan 2006 21:16:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1DjG-0007mm-6B
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 21:16:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25488
	for ; Mon, 23 Jan 2006 21:14:47 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Dsf-0003ow-Jf
	for ietf@ietf.org; Mon, 23 Jan 2006 21:26:04 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3820284; Mon, 23 Jan 2006 21:12:52 -0500
In-Reply-To: <200601232206.RAA26102@ietf.org>
References: <200601232206.RAA26102@ietf.org>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <61B97801-28F2-4B6A-A23E-D720733BC06E@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Mon, 23 Jan 2006 21:16:14 -0500
To: Allison Mankin 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETFs... the final Friday? 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 23, 2006, at 5:07 PM, Allison Mankin wrote:

> Three comments on Friday scheduling:
>
> 1.
> In my scheduling struggle as AD, I've always needed Fridays pretty
> desperately, though I'm hopeful that with the RAI/TSV split, things
> will be better.
>
> 2.
> Some of us wondered if Friday would be more attractive if the net
> didn't come down at noon, so that if you commit to staying for the WG
> meeting on Friday morning, and you have a late flight, or fly out the
> next morning, you can get some work or email done during the rest of
> the day.
>
> Anyone else find resonance with that?

Yes, strongly.

An afternoon social would not be out of place, either, I suspect. Maybe
a beer and gear could be arranged with sponsors.

Of course, the volunteers probably want to get out of town ASAP, so
it's a balancing act.

Regards
Marshall Eubanks

>
> 3.
> Finally, I noticed the IAD included a question about Friday meeting or
> not in the survey we were invited to on 9 January.  Getting a sense of
> peoples' views quantitatively is good, though that was a
> self-selected group, rather than a random sample that could be
> assigned a statistical mapping to the IETF population.
>
> Allison
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 21:17:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Dkp-00084j-BG; Mon, 23 Jan 2006 21:17:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Dkm-00084b-VA; Mon, 23 Jan 2006 21:17:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25582;
	Mon, 23 Jan 2006 21:16:20 -0500 (EST)
Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F1DuC-0003qd-Jj; Mon, 23 Jan 2006 21:27:37 -0500
Received: from [71.254.17.114] (HELO JMHLap3.stevecrocker.com)
	by execdsl.com (CommuniGate Pro SMTP 4.2.7)
	with ESMTP id 12933254; Mon, 23 Jan 2006 19:14:15 -0700
Message-Id: <6.2.1.2.0.20060123211329.0313aea8@mail.stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Mon, 23 Jan 2006 21:17:23 -0500
To: "JFC (Jefsey) Morfin" , ietf@ietf.org
From: "Joel M. Halpern" 
In-Reply-To: <6.2.3.4.2.20060123185209.0531feb0@mail.jefsey.com>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	<43D50505.7050907@unfix.org>
	<6.2.3.4.2.20060123185209.0531feb0@mail.jefsey.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: IESG 
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Assuming I have properly understood Mr. Morfin's email, the best argument I 
have seen for permitting all IETF email list adminsitrators to ban him as 
they deem necessary is his own description of his behavior.

Mr. Morfin appears to have stated that if he feels an opinion is important 
he will push for it (as he should.)  He has also indicated that he will 
keep pushing for it on any and all mailing lists even after the working 
group chair has determined that a rough consensus exists.

If I have understood his postings in this discussion correctly, Mr. Morfin 
has specifically indicated that he intends to behave in ways that are not 
in accord with the rules.  It seems to me that the sensible response to a 
notice of intended misbehavior is to be prepared to respond immediately and 
directly to such behavior.

The proposed action specifically gives the list managers / chairs that 
necessary authority in the light of Mr. Morfin's exhibited and asserted 
behavior.

Yours,
Joel M. Halpern


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 21:23:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1DqC-0000fb-ON; Mon, 23 Jan 2006 21:23:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1DqA-0000f6-KE
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 21:23:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26092
	for ; Mon, 23 Jan 2006 21:21:55 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc13.comcast.net ([63.240.77.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Dzd-00046X-7X
	for ietf@ietf.org; Mon, 23 Jan 2006 21:33:13 -0500
Received: from smailcenter70.comcast.net ([204.127.205.170])
	by comcast.net (sccrmhc13) with SMTP
	id <20060124022315013000vfsre>; Tue, 24 Jan 2006 02:23:16 +0000
Received: from [66.229.53.140] by smailcenter70.comcast.net;
	Tue, 24 Jan 2006 02:23:14 +0000
To: Elwyn Davies 
Date: Tue, 24 Jan 2006 02:23:14 +0000
Message-Id: <012420060223.1211.43D58F920000FCCC000004BB220073436400000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
X-Spam-Score: 1.3 (+)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: ietf@ietf.org
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0576638008=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0576638008==
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_1211_1138069394_0"


--NextPart_Webmail_9m3u9jl4l_1211_1138069394_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

-------------- Original message -------------- 
From: Elwyn Davies  

> 
> nick.staff@comcast.net wrote: 
> 
> > 
> > Can you imagine if during every murder trial they had a debate on the 
> > humanity of capitol punishment? 
> > 
> As a non-US citizen, I am a little hazy about some details of the US 
> legal system. Do I assume that this punishment requires the malefactor 
> to sit through a set period of congressional filibusters? 
> 
> I look forwards to a Supreme Court ruling outlawing it as a cruel and 
> unusual punishment. 
> 
yeah I couldnt agree more.  Capitol punishment is barbaric and cruel and the action of vindictive people.  Odd though that you assumed I was saying that the use of capitol punishment needed to be defended instead of that the prevention of it needed to be ensured.  Either way capitol punishment was an analogy and whatever country you hail from I'm sure my point applies the same.  My point, if you are interested, was that if the penalty for a crime had to be redecided during every trial then trials would take forever and choke an already bottlenecked system.  If you can see the parralel to our current situation where once again we debate the breadth and extent of PR-Action policy while we're in the middle of trying to apply it.  It's half-assed and juvenile and disorderly to the point of embarrasment.  The mature voices are few and far between so we're left with a childish melee that would lose us the respect of any grown-up professional who saw it.  It's become a romper room !
 and it's an embarrasment.
--NextPart_Webmail_9m3u9jl4l_1211_1138069394_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit



-------------- Original message -------------- 
From: Elwyn Davies <elwynd@dial.pipex.com> 

> 
> nick.staff@comcast.net wrote: 
> 
> > 
> > Can you imagine if during every murder trial they had a debate on the 
> > humanity of capitol punishment? 
> > 
> As a non-US citizen, I am a little hazy about some details of the US 
> legal system. Do I assume that this punishment requires the malefactor 
> to sit through a set period of congressional filibusters? 
> 
> I look forwards to a Supreme Court ruling outlawing it as a cruel and 
> unusual punishment. 
> 
yeah I couldnt agree more.  Capitol punishment is barbaric and cruel and the action of vindictive people.  Odd though that you assumed I was saying that the use of capitol punishment needed to be defended instead of that the prevention of it needed to be ensured.  Either way capitol punishment wa!
 s an analogy and whatever country you hail from I'm sure my point applies the same.  My point, if you are interested, was that if the penalty for a crime had to be redecided during every trial then trials would take forever and choke an already bottlenecked system.  If you can see the parralel to our current situation where once again we debate the breadth and extent of PR-Action policy while we're in the middle of trying to apply it.  It's half-assed and juvenile and disorderly to the point of embarrasment.  The mature voices are few and far between so we're left with a childish melee that would lose us the respect of any grown-up professional who saw it.  It's become a romper room and it's an embarrasment.


--NextPart_Webmail_9m3u9jl4l_1211_1138069394_0--


--===============0576638008==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0576638008==--




From ietf-bounces@ietf.org Mon Jan 23 21:31:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1DxY-0003Xm-CX; Mon, 23 Jan 2006 21:31:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1DxW-0003Xd-Or
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 21:31:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26720
	for ; Mon, 23 Jan 2006 21:29:31 -0500 (EST)
Message-Id: <200601240229.VAA26720@ietf.org>
Received: from psg.com ([147.28.0.62] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1E6y-0004P0-KW
	for ietf@ietf.org; Mon, 23 Jan 2006 21:40:49 -0500
Received: from localhost ([127.0.0.1] helo=psg.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1F1DxR-000F9P-SO; Tue, 24 Jan 2006 02:30:57 +0000
To: Marshall Eubanks 
Date: Mon, 23 Jan 2006 18:30:57 -0800
From: Allison Mankin 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: ietf@ietf.org
Subject: Re: IETFs... the final Friday? 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> An afternoon social would not be out of place, either, I suspect. Maybe
> a beer and gear could be arranged with sponsors.
> 

What a fine idea!  Maybe since it would be after the working IETF
time, we could get away with the gear part; to my knowledge
(not perfect) we've historically not agreed to showcases etc in
proximity to the meetings.

> Of course, the volunteers probably want to get out of town ASAP, so
> it's a balancing act.

Indeed.  After a hard week.  So this would have to be thought through
and triaged.

Allison

Allison

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 21:37:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1E3w-0005j9-Vg; Mon, 23 Jan 2006 21:37:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1E3u-0005ha-QD
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 21:37:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27140
	for ; Mon, 23 Jan 2006 21:36:07 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1EDM-0004br-OF
	for ietf@ietf.org; Mon, 23 Jan 2006 21:47:25 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3820340; Mon, 23 Jan 2006 21:34:15 -0500
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3BE5E206-2ACA-4B19-B1B1-5DD691A2E99F@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Mon, 23 Jan 2006 21:37:37 -0500
To: Allison Mankin 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETFs... the final Friday? 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 23, 2006, at 9:30 PM, Allison Mankin wrote:

>> An afternoon social would not be out of place, either, I suspect.  
>> Maybe
>> a beer and gear could be arranged with sponsors.
>>
>
> What a fine idea!  Maybe since it would be after the working IETF
> time, we could get away with the gear part; to my knowledge
> (not perfect) we've historically not agreed to showcases etc in
> proximity to the meetings.

Exactly.

Marshall

>
>> Of course, the volunteers probably want to get out of town ASAP, so
>> it's a balancing act.
>
> Indeed.  After a hard week.  So this would have to be thought through
> and triaged.
>
> Allison
>
> Allison


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 22:19:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Eif-0008VH-B2; Mon, 23 Jan 2006 22:19:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Eic-0008U5-I0
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 22:19:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29240
	for ; Mon, 23 Jan 2006 22:18:11 -0500 (EST)
Received: from mercury.lcs.mit.edu ([18.26.0.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Es4-0005pi-TL
	for ietf@ietf.org; Mon, 23 Jan 2006 22:29:30 -0500
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178)
	id 4313F872DA; Mon, 23 Jan 2006 22:19:31 -0500 (EST)
To: ietf@ietf.org
Message-Id: <20060124031931.4313F872DA@mercury.lcs.mit.edu>
Date: Mon, 23 Jan 2006 22:19:31 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

    > From: nick.staff@comcast.net

    >> From: Elwyn Davies 

    >>> a debate on the humanity of capitol punishment?

    >> Do I assume that this punishment requires the malefactor to sit
    >> through a set period of congressional filibusters?

    > Capitol punishment is barbaric and cruel and the action of vindictive
    > people.

Ah, I suspect that Elwyn was gently pulling your leg about your inability to
spell "capital" (i.e. the death penalty) - "capitol" means "location of the
government" (and similar meanings, including the name of the building which
houses the US federal legislature, which is called "the Capitol") - and that
you've therefore missed the joke...

	Noel

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 22:46:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1F8u-0006Ny-HU; Mon, 23 Jan 2006 22:46:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1F8s-0006NO-3H
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 22:46:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00722
	for ; Mon, 23 Jan 2006 22:45:20 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1FIC-0006cx-Ea
	for ietf@ietf.org; Mon, 23 Jan 2006 22:56:37 -0500
Received: from [150.189.240.97] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001580201.msg
	for ; Tue, 24 Jan 2006 04:48:35 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Mon, 23 Jan 2006 22:57:09 -0400
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: Meeting Survey Results
Thread-Index: AcYgkd3KHHowtIyFEdqY4gANky3PwA==
In-Reply-To: <2304.128.9.168.71.1138056307.webmail@128.9.168.71>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060124:ietf@ietf.org::5tABUnms3X5NLKRV:00005gF1
X-MDRemoteIP: 150.189.240.97
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Tue, 24 Jan 2006 04:48:45 +0100
X-MDAV-Processed: consulintel.es, Tue, 24 Jan 2006 04:48:48 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Ray,

I'm not sure if we need some clarification on this:

> 1.  Slightly more than 25% say their laptop is compatible with 802.11a.
> [Note the IETF 65 NOC for Dallas recommends 802.11a]

According to the survey, only 25.5% of the participants have 802.11a, which
in my opinion means that 11b/g MUST be reliable for 75% of the participants
in the next meeting.

Remember that if we don't have an 802.11a interface in our laptops is
because *THEY DONT'T HAVE IT*.

In my own case, having a Mac is not easy to get built-in 802.11a. I can of
course buy an external card, but is not reasonable (more power consumption,
more things to carry, etc.). There is one more reason, is that in most of
the world is not (today) widely used, so buying it almost only for IETF
meetings, don't make too much sense.

Even do, if it is just me, I will consider buying it, but I don't really
agree to get this asked for 75% of the participants. It is not a choice !

So the clarification is ... what we actually will get at IETF65, and if
something must be changed now for getting good 802.11b/g support, please,
make sure about that now !

Regards,
Jordi




> De: 
> Responder a: 
> Fecha: Mon, 23 Jan 2006 17:45:07 -0500 (EST)
> Para: "ietf@ietf.org" 
> Asunto: Meeting Survey Results
> 
> All;
> 
> More than 300 responded to the Meeting Survey conducted following IETF 64
> in Vancouver.
> 
> See survey results link below.
> 
> Among the results are:
> 1.  Slightly more than 25% say their laptop is compatible with 802.11a.
> [Note the IETF 65 NOC for Dallas recommends 802.11a]
> 
> 2.  Nearly 60% (with an additional 23% undecided) prefer dinner following
> all sessions of the day.
> 
> 3.  Only 23% prefer a full day schedule for Fridays.
> 
> 4.  Cookies are not the only craving for breaks -- 74% want more healthy
> choices.
> 
> 5.  Only 1/3 of the respondents expressed satisfaction with the wireless
> connectivity.
> 
> And given the opportunity to say what they liked and didn't - 130 told us
> how they felt.
> 
> Read it for yourselves: http://www.surveymonkey.com/Report.asp?U=165657447306
> 
> I and NeuStar Secretariat Services will review these results and make
> adjustments as possible for IETF 65 Dallas, March 19 - 24.  And we look
> forward to seeing you there.
> 
> Thanks for your participation.
> 
> Ray Pelletier
> IETF Administrative Director.
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 23:00:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1FLx-00022V-6B; Mon, 23 Jan 2006 23:00:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1FLu-00022B-Vf; Mon, 23 Jan 2006 23:00:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01801;
	Mon, 23 Jan 2006 22:58:49 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F1FVO-00079D-5g; Mon, 23 Jan 2006 23:10:06 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F1FLk-0000Yo-Ar; Mon, 23 Jan 2006 20:00:08 -0800
Message-Id: <6.2.3.4.2.20060124034809.04b97470@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Tue, 24 Jan 2006 04:39:47 +0100
To: "Joel M. Halpern" , ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <6.2.1.2.0.20060123211329.0313aea8@mail.stevecrocker.com>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	<43D50505.7050907@unfix.org>
	<6.2.3.4.2.20060123185209.0531feb0@mail.jefsey.com>
	<6.2.1.2.0.20060123211329.0313aea8@mail.stevecrocker.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-493A2340
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: IESG 
Subject: Should we ban people who say they will appeal a WG Chair decision
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear Joel,
I am afraid you rebuild the rules while I respect them. A WG Chair is 
not God the Father. In its wisdom the IETF has devised an appeal 
mechanism. I oppose positions of a WG-Chair and of a Mailing List 
Owner. So, I use and respect that mechanism. I always respected its 
decisions. All my action is precisely to force these decisions when 
they are missing, so we can respect them. Do you deny me that right?

The current action against me seems to have been launched to 
interferes with a peaceful consideration of two long time annouced 
appeals, one now with the IESG over RFC 3066 Bis; and one with the 
IAB, over the ethic and usage impact and the documentation of the 
Multilingual Internet. Amusingly removing or limiting my rights of 
appeal was one of the first propositions. The IETF would lose every 
technical credibility. It would become the publisher of the bigger.

As you say, I said the involved questions are important enough to 
call for a decision by the IAB in the technical areas, and of the 
other appropriate appeal entities in the areas of applications. Do 
you object that too? The IAB Chair has indicated the IAB will 
respond. The IESG works on the other very seriously as far as I know, 
from the questions they ask. These appeals and my responses not only 
fully state that I will respect the final IAB (IESG) decisions, but 
explain how.

I suggest that you do as Marshall. Consult the archives and read the 
appeals. Then speak the thruth. I am supposed to be out off-topic in 
an engineering group? Show me off-topic! My positions are documented 
by two technical documents on the IAB and the IESG sites and are 
seriously considered. Yet I have not heard a ***_single_ *** 
technical objection. Should not the first question, even before my 
liberty of speach, be if I am right?

http://iab.org/appeals/2006-01-04-jefsey-appeal.pdf
http://ietf.org/IESG/APPEALS/jefsey-morfin-appeal.txt

We are not here to waste time in childish disputes. Should I appeal 
the IESG against my last ietf-languages@alvestrand.no last ban? 
SHould I question the COI of some IESG Members? We are to document 
the best solutions for the Internet designers, users and managers. I 
do not feel that this thread remembers that.

All the best
jfc





At 03:17 24/01/2006, Joel M. Halpern wrote:

>Assuming I have properly understood Mr. Morfin's email, the best 
>argument I have seen for permitting all IETF email list 
>adminsitrators to ban him as they deem necessary is his own 
>description of his behavior.
>
>Mr. Morfin appears to have stated that if he feels an opinion is 
>important he will push for it (as he should.)  He has also indicated 
>that he will keep pushing for it on any and all mailing lists even 
>after the working group chair has determined that a rough consensus exists.
>
>If I have understood his postings in this discussion correctly, Mr. 
>Morfin has specifically indicated that he intends to behave in ways 
>that are not in accord with the rules.  It seems to me that the 
>sensible response to a notice of intended misbehavior is to be 
>prepared to respond immediately and directly to such behavior.
>
>The proposed action specifically gives the list managers / chairs 
>that necessary authority in the light of Mr. Morfin's exhibited and 
>asserted behavior.
>
>Yours,
>Joel M. Halpern
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 23:00:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1FLz-00023t-5v; Mon, 23 Jan 2006 23:00:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1FLv-00022P-Hm
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 23:00:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01803
	for ; Mon, 23 Jan 2006 22:58:49 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1FVN-000796-SV
	for ietf@ietf.org; Mon, 23 Jan 2006 23:10:06 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F1FLh-0000Yo-Lh; Mon, 23 Jan 2006 20:00:07 -0800
Message-Id: <6.2.3.4.2.20060124022956.0664f6b0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Tue, 24 Jan 2006 04:59:56 +0100
To: Grossman Dan-LDG004 , ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <62173B970AE0A044AED8723C3BCF23810C679FEF@ma19exm01.e6.bcs.
	mot.com>
References: <62173B970AE0A044AED8723C3BCF23810C679FEF@ma19exm01.e6.bcs.mot.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; x-avg-checked=avg-ok-493A2340;
	boundary="=======AVGMAIL-43D5A63D5230======="
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8
Cc: 
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--=======AVGMAIL-43D5A63D5230=======
Content-Type: multipart/alternative;
	boundary="=====================_16294840==.ALT";
	x-avg-checked=avg-ok-493A2340

--=====================_16294840==.ALT
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-493A2340

At 22:42 23/01/2006, Grossman Dan-LDG004 wrote:
>Unlike the previous matter of an individual who clearly engaged in 
>threats and ad-homenem attacks, this appears perilously close to 
>being an attempt to suppress a minority viewpoint.   Minority 
>viewpoints need to be heard, regardless of whether the minority is a 
>minority of one, and regardless of how persistent and how 
>(in)articulate the minority may be.  This does not mean that the 
>chair cannot find consensus against the minority view.  However, it 
>strikes me as an abuse of process to revoke posting rights because 
>the majority is tired of hearing the minority opinion.
>
>  Mr. Morfin has been accused of straying into "off-topic" 
> postings.  I cannot judge from the examples presented whether this 
> is the case. However, I observe that setting WG scope can serve a 
> constructive purpose in allowing the group to maintain focus by 
> avoiding peripheral issues, or it can be a way of biasing the 
> agenda toward a particular result, of ignoring important issues or 
> of suppressing dissent.

Dear Dan,
you are perfectly correct. But in this case I faced a "second level" 
case where an active minority made itself a majority, boring everyone 
out but m,e because I needed for my own business survival to impeach 
the market exclusive they were at building.

So, I faced a Unicode affinity group which managed to appear as the 
majority in presenting in the first WG-Chair's mail a complete Draft, 
ready for IESG LC (it just failed as an individual Draft - they 
thought that putting a WG stamp on it would be enough). Because of 
that, most of the possibly interested experts did not contribute, or 
did not join. I had been the most active in making the text fail the 
last call. I therefore proposed to co-write the Draft (it would have 
been done in two days with non-business biased people). The minority 
leader (WG-Chair) refused. We then saw a long "consensus by 
exhaustion" because I did not exhaust.

I balanced between starting a war with 10, 100 or 200 supporters. 
This would have killed the IETF (look at the PR today, if we had tens 
of them ....) and convinced no one of the interest of the IETF. And 
crusading to obtaining the text to be cleaned from most of its 
confusion, to make it less dangerous. I explained that I will appeal 
the IESG, the IAB, the IANA, the UNESCO, the ITU etc. etc. against 
the text until it matched its Charter. The Charter has been written 
by the minority/majority group to fool the IESG. It is not perfect 
but considering it, would have shown many inconsistencies we start 
seeing now. My main opposition was "consider the Charter" (in the 
IETF the IESG does not consider the Charter anymore to accept a Draft).

I obtained everything I wanted:

- the text is now cleaner. It was adopted after the Tunis agreement.
- in parallel the WSIS confirmed my position about multilingualism 
(IAB does not want to consider) calling for work on language codes
- via an appeal the IESG must review the security aspects which make 
the text quite unusable (privacy violation)
- via an appeal the IAB must say if they want the IETF to consider 
the usage/ethic impact of its decisions and the building of the 
Multilingual Internet, or if these issues must be discussed elsewhere.

This builds a situation where the "majority" loses its control on the 
IETF or its control on the real Language Registry (not any more the 
IANA). The choice is difficult. The PR action is a Denial of Thinking 
to try the IESG and the IAB cannot set their mind. But this does not 
bother me, because they will have "failed to respond". This is why 
the need is to unconsiderate me.

Either the IETF maintains the Tunis Internet (the native proposition) 
controlled by the USA and supported by the IANA. Or the IETF engages 
into a new architecture based upon a distributed registry system 
(DRS). This implies a user-centric usage architecture (which calls 
for a convergence of the digital continuity). A technology and 
economical shift of importance, the US industry and the IETF are not 
prepared to. This is why the PR was prepared by an anti-EU set-up, 
opposing the WSIS positions - to involvedthe IESG. At the end of the 
day if the IETF opposes everyone it will have to go with Unicode ... 
look at the list of the Members and of the Executives.

They have been very candid. Before attacking me seriously (physical 
allusions, anonymous calls, etc.[this is the IETF :-) and PR action) 
I was once asked "do you realise how much you cost to the industry?". 
I asked back "which industry?". The control of the text industry is 
far bigger than music, pictures and games.... What they do not 
understand is that its value comes from its diversity and Liberty.

If you are familiar with the French Minitel and Telematic, I use to 
say that we (France) built the Minitel I, that the web is the Minitel 
II and that we have now (mobiles, coreboxes, new appliances, network 
continuity) to support the Minitel III phase. I happen to have 
experimented in real life that architecture and to be in charge of 
its analysis and international deployment (Tymnet). What I sold for $ 
250.000 to State monopolies 20 years ago, is what you should soon be 
able to giveaway in a mobile to 3 billion people.

>Having been both in majorities and in minorities over the past 20 
>years or so, I know that process protection for minority rights is 
>frustrating to the majority.  I also recognize that the minority is 
>sometimes right.  Patient negotiation, no matter how difficult or 
>time consuming, is the best remedy.

I spend my time pleading for consensus. The technical solution is 
easy enough using RFC 4151 space. The problem is that they need an 
exclusive (like ICANN vs. open roots). Negotiation would be like 
ICANN accepting open roots.This is true that this is what ICANN does: 
with  NeuStar and GSMA, with China, etc.

>I urge the IESG to give Mr. Morfin the benefit of the doubt.

Thank you, but I am expandable. The IETF should not be. At least right now.
Take care.

jfc

--=====================_16294840==.ALT
Content-Type: text/html; charset=us-ascii; x-avg-checked=avg-ok-493A2340



At 22:42 23/01/2006, Grossman Dan-LDG004 wrote:


Unlike the previous
matter of an individual who clearly engaged in threats and ad-homenem
attacks, this appears perilously close to being an attempt to suppress a
minority viewpoint.   Minority viewpoints need to be heard,
regardless of whether the minority is a minority of one, and regardless
of how persistent and how (in)articulate the minority may be.  This
does not mean that the chair cannot find consensus against the minority
view.  However, it strikes me as an abuse of process to revoke
posting rights because the majority is tired of hearing the minority
opinion.

 

 Mr. Morfin has been accused of straying into
"off-topic" postings.  I cannot judge from the examples
presented whether this is the case. However, I observe that setting WG
scope can serve a constructive purpose in allowing the group to maintain
focus by avoiding peripheral issues, or it can be a way of biasing the
agenda toward a particular result, of ignoring important issues or of
suppressing dissent.


Dear Dan,

you are perfectly correct. But in this case I faced a "second
level" case where an active minority made itself a majority, boring
everyone out but m,e because I needed for my own business survival to
impeach the market exclusive they were at building. 


So, I faced a Unicode affinity group which managed to appear as the
majority in presenting in the first WG-Chair's mail a complete Draft,
ready for IESG LC (it just failed as an individual Draft - they thought
that putting a WG stamp on it would be enough). Because of that, most of
the possibly interested experts did not contribute, or did not join. I
had been the most active in making the text fail the last call. I
therefore proposed to co-write the Draft (it would have been done in two
days with non-business biased people). The minority leader (WG-Chair)
refused. We then saw a long "consensus by exhaustion" because I
did not exhaust.


I balanced between starting a war with 10, 100 or 200 supporters. This
would have killed the IETF (look at the PR today, if we had tens of them
....) and convinced no one of the interest of the IETF. And crusading to
obtaining the text to be cleaned from most of its confusion, to make it
less dangerous. I explained that I will appeal the IESG, the IAB, the
IANA, the UNESCO, the ITU etc. etc. against the text until it matched its
Charter. The Charter has been written by the minority/majority group to
fool the IESG. It is not perfect but considering it, would have shown
many inconsistencies we start seeing now. My main opposition was
"consider the Charter" (in the IETF the IESG does not consider
the Charter anymore to accept a Draft).


I obtained everything I wanted:


- the text is now cleaner. It was adopted after the Tunis agreement.

- in parallel the WSIS confirmed my position about multilingualism (IAB
does not want to consider) calling for work on language codes

- via an appeal the IESG must review the security aspects which make the
text quite unusable (privacy violation)

- via an appeal the IAB must say if they want the IETF to consider the
usage/ethic impact of its decisions and the building of the Multilingual
Internet, or if these issues must be discussed elsewhere. 


This builds a situation where the "majority" loses its control
on the IETF or its control on the real Language Registry (not any more
the IANA). The choice is difficult. The PR action is a Denial of Thinking
to try the IESG and the IAB cannot set their mind. But this does not
bother me, because they will have "failed to respond". This is
why the need is to unconsiderate me.


Either the IETF maintains the Tunis Internet (the native proposition)
controlled by the USA and supported by the IANA. Or the IETF engages into
a new architecture based upon a distributed registry system (DRS). This
implies a user-centric usage architecture (which calls for a convergence
of the digital continuity). A technology and economical shift of
importance, the US industry and the IETF are not prepared to. This is why
the PR was prepared by an anti-EU set-up, opposing the WSIS positions -
to involvedthe IESG. At the end of the day if the IETF opposes everyone
it will have to go with Unicode ... look at the list of the Members and
of the Executives. 


They have been very candid. Before attacking me seriously (physical
allusions, anonymous calls, etc.[this is the IETF :-) and PR action) I
was once asked "do you realise how much you cost to the
industry?". I asked back "which industry?". The control of
the text industry is far bigger than music, pictures and games.... What
they do not understand is that its value comes from its diversity and
Liberty. 


If you are familiar with the French Minitel and Telematic, I use to say
that we (France) built the Minitel I, that the web is the Minitel II and
that we have now (mobiles, coreboxes, new appliances, network continuity)
to support the Minitel III phase. I happen to have experimented in real
life that architecture and to be in charge of its analysis and
international deployment (Tymnet). What I sold for $ 250.000 to State
monopolies 20 years ago, is what you should soon be able to giveaway in a
mobile to 3 billion people.



Having been both in
majorities and in minorities over the past 20 years or so, I know that
process protection for minority rights is frustrating to the
majority.  I also recognize that the minority is sometimes
right.  Patient negotiation, no matter how difficult or time
consuming, is the best remedy.


I spend my time pleading for consensus. The technical solution is easy
enough using RFC 4151 space. The problem is that they need an exclusive
(like ICANN vs. open roots). Negotiation would be like ICANN accepting
open roots.This is true that this is what ICANN does: with  NeuStar
and GSMA, with China, etc.



I urge the IESG to
give Mr. Morfin the benefit of the doubt. 


Thank you, but I am expandable. The IETF should not be. At least right
now.

Take care.


jfc




--=====================_16294840==.ALT--
--=======AVGMAIL-43D5A63D5230=======
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--=======AVGMAIL-43D5A63D5230=======--





From ietf-bounces@ietf.org Mon Jan 23 23:09:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1FUj-0004sA-9Y; Mon, 23 Jan 2006 23:09:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1FUg-0004s1-Jk
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 23:09:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02442
	for ; Mon, 23 Jan 2006 23:07:52 -0500 (EST)
Received: from twin.uoregon.edu ([128.223.214.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Fe9-0007Sv-52
	for ietf@ietf.org; Mon, 23 Jan 2006 23:19:09 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by twin.uoregon.edu (8.13.4/8.13.4) with ESMTP id k0O48wEq026608;
	Mon, 23 Jan 2006 20:08:58 -0800
Date: Mon, 23 Jan 2006 20:08:58 -0800 (PST)
From: Joel Jaeggli 
X-X-Sender: joelja@twin.uoregon.edu
To: JORDI PALET MARTINEZ 
In-Reply-To: 
Message-ID: 
References: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: "ietf@ietf.org" 
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 23 Jan 2006, JORDI PALET MARTINEZ wrote:

> Hi Ray,

> In my own case, having a Mac is not easy to get built-in 802.11a. I can of
> course buy an external card, but is not reasonable (more power consumption,
> more things to carry, etc.). There is one more reason, is that in most of
> the world is not (today) widely used, so buying it almost only for IETF
> meetings, don't make too much sense.

By that standard configuring your laptop to support ipv6 doesn't make 
much sense either...

> Even do, if it is just me, I will consider buying it, but I don't really
> agree to get this asked for 75% of the participants. It is not a choice !
>
> So the clarification is ... what we actually will get at IETF65, and if
> something must be changed now for getting good 802.11b/g support, please,
> make sure about that now !
>
> Regards,
> Jordi
>
>
>
>
>> De: 
>> Responder a: 
>> Fecha: Mon, 23 Jan 2006 17:45:07 -0500 (EST)
>> Para: "ietf@ietf.org" 
>> Asunto: Meeting Survey Results
>>
>> All;
>>
>> More than 300 responded to the Meeting Survey conducted following IETF 64
>> in Vancouver.
>>
>> See survey results link below.
>>
>> Among the results are:
>> 1.  Slightly more than 25% say their laptop is compatible with 802.11a.
>> [Note the IETF 65 NOC for Dallas recommends 802.11a]
>>
>> 2.  Nearly 60% (with an additional 23% undecided) prefer dinner following
>> all sessions of the day.
>>
>> 3.  Only 23% prefer a full day schedule for Fridays.
>>
>> 4.  Cookies are not the only craving for breaks -- 74% want more healthy
>> choices.
>>
>> 5.  Only 1/3 of the respondents expressed satisfaction with the wireless
>> connectivity.
>>
>> And given the opportunity to say what they liked and didn't - 130 told us
>> how they felt.
>>
>> Read it for yourselves: http://www.surveymonkey.com/Report.asp?U=165657447306
>>
>> I and NeuStar Secretariat Services will review these results and make
>> adjustments as possible for IETF 65 Dallas, March 19 - 24.  And we look
>> forward to seeing you there.
>>
>> Thanks for your participation.
>>
>> Ray Pelletier
>> IETF Administrative Director.
>>
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.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@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli  	       Unix Consulting 	       joelja@darkwing.uoregon.edu
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 23:21:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Fg6-00008f-T5; Mon, 23 Jan 2006 23:21:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Fg4-0008UC-1O
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 23:21:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03031
	for ; Mon, 23 Jan 2006 23:19:38 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1FpW-0007oG-9K
	for ietf@ietf.org; Mon, 23 Jan 2006 23:30:56 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0O4KpdH069894
	for ; Tue, 24 Jan 2006 05:20:51 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Tue, 24 Jan 2006 05:20:51 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <782751960.20060124052051@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D55517.4010803@unfix.org>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	<20060123162308.GA29373@nic.fr>
	<1519021751.20060123212607@atkielski.com>
	
	<43D55517.4010803@unfix.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit
Subject: Re: List archives and copyright [WAS Re: John Cowan supports 3683
	PR-action against Jefsey Morfin]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jeroen Massar writes:

> IANAL but one really doesn't have to bother with US law, that really
> doesn't apply to many folks (fortunately :)

The laws of other developed countries are frequently even more
restrictive when it comes to copyright.

> There is a much better thing
> than US law, it's called IETF, and the fact that there is:
> http://www.ietf.org/maillist-new.html which contains:
> 8<--------------
> All IETF Contributions are subject to the rules of RFC 3978 and RFC 3979.
-------------->>8
> Mailinglist traffic also are subject to that.
> One gets a copy of this when signing up for the various lists.

That's not good enough.  Prospective list members must be presented
with the actual texts themselves and must agree to abide by them
_before_ they sign up.  And in some jurisdictions, even this may not
be enough (see "moral rights" and copyright).

> According to you Google and every other website indexing service is a
> violation of copyright, better get sue'ing then, you might get rich.

Be careful what you wish for.

At one time, copyright lasted for only a few years.  And at one time,
patents could only be applied to machines.

> Archives are meant to store things, which is what they are doing, if you
> don't want to contribute then simply don't.

If I contribute to a mailing list that is archived, then my posts may
be archived against my will.

> (Who wonders that now I've quoted mr Atkielski if I am in violation of
> his copyright...)

People who haven't yet been sued tend to be very flippant about
intellectual property rights.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 23:24:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Fjl-0001EG-ND; Mon, 23 Jan 2006 23:24:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Fjj-0001E1-RK
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 23:24:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03311
	for ; Mon, 23 Jan 2006 23:23:26 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1FtC-0007vb-HE
	for ietf@ietf.org; Mon, 23 Jan 2006 23:34:44 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0O4OjX3069930
	for ; Tue, 24 Jan 2006 05:24:45 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Tue, 24 Jan 2006 05:24:45 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <39697985.20060124052445@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060123211430.GA14409@thunk.org>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	<20060123211430.GA14409@thunk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Theodore Ts'o writes:

> The problem with the "just filter" approach is that if you then fail
> to respond to something of substance that got inadvertently filtered
> out, it is trivially easy to claim rough consensus.

The problem with prior restraint, such as a ban, is that nobody ever
gets to respond to anything that doesn't toe the party line.  That's a
general problem with all censorship.

With filters, the intolerance of one person doesn't influence that of
others.  If he misses something and fails to respond to it because of
his filters, that's his own problem and his own fault.  The fact that
he might be careless in filtering or might choose to filter things
that other people don't is not a justification for forcing the whole
world to observe the same restrictions.

> So if everyone followed your advice (except for the poor wg chair,
> who has to judge consensus, so he/she would be forced to read
> through all of the dreck), it would be trivially easy for a group to
> get something past the wg; just have 2 or 3 people suggest something
> that would normally be controversial, insert the keyword "
> somewhere in the text, and then when no one responds because they
> have all filtered out any text containing the word "Jefsey", the 2
> or 3 people can claim rough consensus and the change goes in.

See above. Laziness and intolerance are (or should be) problems of the
individual, not the group.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 23:32:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Fr0-0003Fe-Hd; Mon, 23 Jan 2006 23:32:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Fqy-0003FZ-5r
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 23:32:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03765
	for ; Mon, 23 Jan 2006 23:30:54 -0500 (EST)
Received: from biscayne-one-station.mit.edu ([18.7.7.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1G0Q-0008Aw-42
	for ietf@ietf.org; Mon, 23 Jan 2006 23:42:12 -0500
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id
	k0O4WGL3017259; Mon, 23 Jan 2006 23:32:16 -0500 (EST)
Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160])
	(authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0O4WEb6008821
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Mon, 23 Jan 2006 23:32:14 -0500 (EST)
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <41F3E06C-B157-4B0B-AB75-03CBA7777EB8@mit.edu>
From: Ken Raeburn 
Date: Mon, 23 Jan 2006 23:32:13 -0500
To: jordi.palet@consulintel.es
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" 
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jan 23, 2006, at 21:57, JORDI PALET MARTINEZ wrote:
> In my own case, having a Mac is not easy to get built-in 802.11a. I  
> can of
> course buy an external card,

Are there cards with Mac OS X drivers nowadays?  If I knew where to  
get one, I'd consider it, given the condition of the 802.11b/g  
network too much of the time.  (Or are you running Linux kernels on  
your hardware?)

Ken

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 23:33:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Frg-0003Tx-0b; Mon, 23 Jan 2006 23:33:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Frd-0003Tn-6P
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 23:33:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03831
	for ; Mon, 23 Jan 2006 23:31:35 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1G15-0008DQ-U3
	for ietf@ietf.org; Mon, 23 Jan 2006 23:42:53 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0O4Wsao069991
	for ; Tue, 24 Jan 2006 05:32:54 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Tue, 24 Jan 2006 05:32:54 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <162112559.20060124053254@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D5846C.7030209@dcrocker.net>
References: <62173B970AE0A044AED8723C3BCF23810C679FEF@ma19exm01.e6.bcs.mot.com>
	<43D5846C.7030209@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dave Crocker writes:

> There is a basic difference between preventing the expression of an opinion,
> idea or the like, versus preventing what is effectively a denial of service
> attack on the conduct of group business.

Yes.  A denial of service attack is a technical attack on a server or
network that effectively halts or dramatically interferes with normal
traffic or transactions.  An expression of an opinion or idea never
does this.

> An organization like the IETF absolutely MUST encourage the former.  But it
> cannot survive any sustained amount of the latter.

Well, when the mailing list receives 200 messages a second from the
same source, certainly it can take action.  There are laws against
that sort of DoS in most jurisdictions.

> Yes, one can no doubt construct all sorts of scenarios that are in a gray area
> between the two.

No, there's no gray area between the two.  It's pretty easy to see
when a network is down or a server is stalled because of a DoS attack,
and it has nothing in common with an expression of opinion or ideas.

> In other words, the excesses that constitute a "violation" need to
> be huge.

No, they just need to be true DoS attacks, not expressions of
unpopular opinions that are being falsely characterized as DoS attacks
in order to rationalize censorship.

> It is difficult to imagine any reasonable person looking at the
> particulars of the current case and having even the slightest doubt
> that things are far, far beyond any possible gray area.

I don't see any DoS.  I don't think anyone expressing an opinion can
type fast enough to create one.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 23:34:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1FtH-0003zf-UT; Mon, 23 Jan 2006 23:34:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1FtF-0003z7-Qb
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 23:34:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03986
	for ; Mon, 23 Jan 2006 23:33:15 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1G2h-0008HP-HD
	for ietf@ietf.org; Mon, 23 Jan 2006 23:44:33 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0O4YYtY070021
	for ; Tue, 24 Jan 2006 05:34:34 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Tue, 24 Jan 2006 05:34:34 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <192584976.20060124053434@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D586A9.8090304@swin.edu.au>
References: <43D586A9.8090304@swin.edu.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Subject: Re: posting privileges vs receiver-side filtering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

grenville armitage writes:

> - protects agains dilution of a WG's historical record (archives
> that soak up all posts to the WG's mailing list)

Stop blindly archiving every message, and this ceases to be a problem.

> - improves the 'signal to distraction' ratio of traffic on the list
> (particularly important for list residents charged with keeping
> things on charter and evaluating rough consensus)

Distraction is in the eye of the beholder.  Ignoring something
requires no action; paying attention to it requires action.  Thus,
distraction is always an explicit action on the part of the receiver;
it is never forced by the sender.

> Yes, revocation of posting privileges and receiver-side filtering both
> cause a drop in traffic reaching one's inbox. But that doesn't 
> make the actions equivalent.

Yes.  The former is censorship, the latter is not.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 23 23:36:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Fux-0004OH-OF; Mon, 23 Jan 2006 23:36:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Fuv-0004LT-9R
	for ietf@megatron.ietf.org; Mon, 23 Jan 2006 23:36:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04116
	for ; Mon, 23 Jan 2006 23:34:59 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1G4O-0008Lg-4e
	for ietf@ietf.org; Mon, 23 Jan 2006 23:46:17 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0O4aIOh070033
	for ; Tue, 24 Jan 2006 05:36:18 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Tue, 24 Jan 2006 05:36:18 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1901529503.20060124053618@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <6.2.1.2.0.20060123211329.0313aea8@mail.stevecrocker.com>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com> <43D50505.7050907@unfix.org>
	<6.2.3.4.2.20060123185209.0531feb0@mail.jefsey.com>
	<6.2.1.2.0.20060123211329.0313aea8@mail.stevecrocker.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Joel M. Halpern writes:

> Assuming I have properly understood Mr. Morfin's email, the best argument I
> have seen for permitting all IETF email list adminsitrators to ban him as
> they deem necessary is his own description of his behavior.
>
> Mr. Morfin appears to have stated that if he feels an opinion is important
> he will push for it (as he should.)  He has also indicated that he will
> keep pushing for it on any and all mailing lists even after the working
> group chair has determined that a rough consensus exists.
>
> If I have understood his postings in this discussion correctly, Mr. Morfin
> has specifically indicated that he intends to behave in ways that are not
> in accord with the rules.  It seems to me that the sensible response to a
> notice of intended misbehavior is to be prepared to respond immediately and
> directly to such behavior.
>
> The proposed action specifically gives the list managers / chairs that
> necessary authority in the light of Mr. Morfin's exhibited and asserted
> behavior.

Replace "Mr. Morfin" with "Dr. King" and see how it sounds.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 00:00:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1GHw-0004Y7-9m; Tue, 24 Jan 2006 00:00:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1GHu-0004XM-6w
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 00:00:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05740
	for ; Mon, 23 Jan 2006 23:58:44 -0500 (EST)
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1GRM-0000q2-Qm
	for ietf@ietf.org; Tue, 24 Jan 2006 00:10:02 -0500
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k0O4UQB0015204; Tue, 24 Jan 2006 06:30:26 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 24 Jan 2006 06:35:14 +0200
Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 24 Jan 2006 06:35:14 +0200
Received: from 172.19.68.87 ([172.19.68.87]) by esebe100.NOE.Nokia.com
	([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Tue, 24 Jan 2006 04:35:13 +0000
Received: from essrv103nok155120.ntc.nokia.com by esebe100.noe.nokia.com;
	24 Jan 2006 06:35:13 +0200
From: "Soininen Jonne (Nokia-NET/Espoo)" 
To: jordi.palet@consulintel.es
In-Reply-To: 
References: 
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: NET/ST/IED
Date: Tue, 24 Jan 2006 06:35:13 +0200
Message-Id: <1138077313.21483.8.camel@essrv103nok155120.ntc.nokia.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-22) 
X-OriginalArrivalTime: 24 Jan 2006 04:35:14.0369 (UTC)
	FILETIME=[91BE3B10:01C6209F]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" 
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Jordi,

the preference for .11a was stated because we want to make sure that
everybody who has the possibility for it would use it. It makes the
network much more reliable. Of course b and g are provided as well.

It is a recommendation not a MUST, like the mail says.

Cheers,

Jonne.

On Mon, 2006-01-23 at 22:57 -0400, ext JORDI PALET MARTINEZ wrote:
> Hi Ray,
> 
> I'm not sure if we need some clarification on this:
> 
> > 1.  Slightly more than 25% say their laptop is compatible with 802.11a.
> > [Note the IETF 65 NOC for Dallas recommends 802.11a]
> 
> According to the survey, only 25.5% of the participants have 802.11a, which
> in my opinion means that 11b/g MUST be reliable for 75% of the participants
> in the next meeting.
> 
> Remember that if we don't have an 802.11a interface in our laptops is
> because *THEY DONT'T HAVE IT*.
> 
> In my own case, having a Mac is not easy to get built-in 802.11a. I can of
> course buy an external card, but is not reasonable (more power consumption,
> more things to carry, etc.). There is one more reason, is that in most of
> the world is not (today) widely used, so buying it almost only for IETF
> meetings, don't make too much sense.
> 
> Even do, if it is just me, I will consider buying it, but I don't really
> agree to get this asked for 75% of the participants. It is not a choice !
> 
> So the clarification is ... what we actually will get at IETF65, and if
> something must be changed now for getting good 802.11b/g support, please,
> make sure about that now !
> 
> Regards,
> Jordi
> 
> 
> 
> 
> > De: 
> > Responder a: 
> > Fecha: Mon, 23 Jan 2006 17:45:07 -0500 (EST)
> > Para: "ietf@ietf.org" 
> > Asunto: Meeting Survey Results
> > 
> > All;
> > 
> > More than 300 responded to the Meeting Survey conducted following IETF 64
> > in Vancouver.
> > 
> > See survey results link below.
> > 
> > Among the results are:
> > 1.  Slightly more than 25% say their laptop is compatible with 802.11a.
> > [Note the IETF 65 NOC for Dallas recommends 802.11a]
> > 
> > 2.  Nearly 60% (with an additional 23% undecided) prefer dinner following
> > all sessions of the day.
> > 
> > 3.  Only 23% prefer a full day schedule for Fridays.
> > 
> > 4.  Cookies are not the only craving for breaks -- 74% want more healthy
> > choices.
> > 
> > 5.  Only 1/3 of the respondents expressed satisfaction with the wireless
> > connectivity.
> > 
> > And given the opportunity to say what they liked and didn't - 130 told us
> > how they felt.
> > 
> > Read it for yourselves: http://www.surveymonkey.com/Report.asp?U=165657447306
> > 
> > I and NeuStar Secretariat Services will review these results and make
> > adjustments as possible for IETF 65 Dallas, March 19 - 24.  And we look
> > forward to seeing you there.
> > 
> > Thanks for your participation.
> > 
> > Ray Pelletier
> > IETF Administrative Director.
> > 
> > 
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.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@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 00:11:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1GT6-0000VA-2c; Tue, 24 Jan 2006 00:11:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1GT3-0000Un-Gu
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 00:11:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06527
	for ; Tue, 24 Jan 2006 00:10:15 -0500 (EST)
Received: from firestar.cisco.com ([171.68.227.75] helo=av-tac-sj.cisco.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1GcU-0001En-KW
	for ietf@ietf.org; Tue, 24 Jan 2006 00:21:33 -0500
X-TACSUNS: Virus Scanned
Received: from rtp-cse-133.cisco.com (localhost [127.0.0.1])
	by av-tac-sj.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k0O5BWp07873;
	Mon, 23 Jan 2006 21:11:32 -0800 (PST)
Received: from localhost (chelliot@localhost)
	by rtp-cse-133.cisco.com (8.11.7p1+Sun/8.11.6) with ESMTP id
	k0O5BQW19055; Tue, 24 Jan 2006 00:11:26 -0500 (EST)
Date: Tue, 24 Jan 2006 00:11:26 -0500 (EST)
From: Chris Elliott 
To: Ken Raeburn 
In-Reply-To: <41F3E06C-B157-4B0B-AB75-03CBA7777EB8@mit.edu>
Message-ID: 
References: 
	<41F3E06C-B157-4B0B-AB75-03CBA7777EB8@mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: "ietf@ietf.org" , jordi.palet@consulintel.es
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 23 Jan 2006, Ken Raeburn wrote:

> On Jan 23, 2006, at 21:57, JORDI PALET MARTINEZ wrote:
>> In my own case, having a Mac is not easy to get built-in 802.11a. I can of
>> course buy an external card,
>
> Are there cards with Mac OS X drivers nowadays?  If I knew where to get one, 
> I'd consider it, given the condition of the 802.11b/g network too much of the 
> time.  (Or are you running Linux kernels on your hardware?)

Yes, several.

Specifically, I gave 17 of the old Cisco .11a-only cards away in 
Vancouver, mostly to Mac folks.

Chris.

>
> Ken
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

Chris Elliott  CCIE# 2013       |         |
Customer Diagnostic Engineer   |||       |||
RTP, NC, USA                  |||||     |||||
919-392-2146              .:|||||||||:|||||||||:.
chelliot@cisco.com        c i s c o S y s t e m s

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

From owner-ietf-krb-wg-outgoing@anl.gov Tue Jan 24 00:14:18 2006
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1GVU-0000w2-0j
	for krb-wg-archive@megatron.ietf.org; Tue, 24 Jan 2006 00:14:18 -0500
Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06746
	for ; Tue, 24 Jan 2006 00:12:44 -0500 (EST)
Received: by mailhost.anl.gov (Postfix)
	id 68EEE2D6; Mon, 23 Jan 2006 23:13:41 -0600 (CST)
Delivered-To: ietf-krb-wg-outgoing@anl.gov
Received: from mailhost.anl.gov (localhost [127.0.0.1])
	by localhost.ctd.anl.gov (Postfix) with ESMTP id 22C022A6
	for ; Mon, 23 Jan 2006 23:13:41 -0600 (CST)
Received: by mailhost.anl.gov (Postfix, from userid 10733)
	id 074EC2D6; Mon, 23 Jan 2006 23:13:40 -0600 (CST)
X-Original-To: ietf-krb-wg@anl.gov
Delivered-To: ietf-krb-wg@anl.gov
Received: from mailhost.anl.gov (localhost [127.0.0.1])
	by localhost.ctd.anl.gov (Postfix) with ESMTP id 429862D2
	for ; Mon, 23 Jan 2006 23:13:40 -0600 (CST)
Received: from mailrelay.anl.gov (mailrelay.anl.gov [130.202.101.22])
	by mailhost.anl.gov (Postfix) with ESMTP id 2451F2A6
	for ; Mon, 23 Jan 2006 23:13:40 -0600 (CST)
Received: from mailrelay.anl.gov (localhost [127.0.0.1])
	by localhost.ctd.anl.gov (Postfix) with ESMTP id 055EB5F0C1D;
	Mon, 23 Jan 2006 23:13:40 -0600 (CST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by mailrelay.anl.gov (Postfix) with ESMTP id 7E56F5F0C4F
	for ; Mon, 23 Jan 2006 23:13:38 -0600 (CST)
Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499);
	 Mon, 23 Jan 2006 21:13:37 -0800
Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 23 Jan 2006 21:13:27 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 23 Jan 2006 18:16:53 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 23 Jan 2006 18:16:53 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C6208C.3E155F3F"
Subject: PKINIT-33 and diffs with -32
Date: Mon, 23 Jan 2006 18:16:53 -0800
Message-ID: 
X-MS-Has-Attach: yes
Thread-Topic: PKINIT-33 and diffs with -32
thread-index: AcYgjD2+qjmaaY67RVOQxVyEsorPdA==
From: "Liqiang(Larry) Zhu" 
To: 
X-OriginalArrivalTime: 24 Jan 2006 02:16:53.0809 (UTC) FILETIME=[3E394A10:01C6208C]
Sender: owner-ietf-krb-wg@mailhost.anl.gov
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6208C.3E155F3F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



205,212c205,212
<    [RFC3280] is popular for facilitating non-repudiation and perfect
<    secrecy.  An established Public Key Infrastructure (PKI) provides
key
<    management and key distribution mechanisms that can be used to
<    establish authentication and secure communication.  Adding
public-key
<    cryptography to Kerberos provides a nice congruence to public-key
<    protocols, obviates the human users' burden to manage strong
<    passwords, and allows Kerberized applications to take advantage of
<    existing key services and identity management.
---
>    [RFC3280] is popular for facilitating data origin authentication
and
>    perfect secrecy.  An established Public Key Infrastructure (PKI)
>    provides key management and key distribution mechanisms that can be
>    used to establish authentication and secure communication.  Adding
>    public-key cryptography to Kerberos provides a nice congruence to
>    public-key protocols, obviates the human users' burden to manage
>    strong passwords, and allows Kerberized applications to take
>    advantage of existing key services and identity management.


322,326c322,326
<    In addition, implementations of this specification MUST be capable
of
<    processing the Extended Key Usage (EKU) extension and the
id-pkinit-
<    san (as defined in Section 3.2.2) otherName of the Subject
<    Alternative Name (SAN) extension in X.509 certificates [RFC3280],
if
<    present.
---
>    o  Algorithms identified in the contentEncryptionAlgorithm field of
>       the type EncryptedContentInfo [RFC3852] for encrypting the
>       temporary key in the encryptedKey field of the type
>       KeyTransRecipientInfo [RFC3852] with a public key, as described
in
>       Section 3.2.3.2: rsaEncryption [RFC3447] [RFC3279].


328c328,331
< 3.1.2.  Defined Message and Encryption Types
---
>    o  Algorithms identified in the contentEncryptionAlgorithm field of
>       the type EncryptedContentInfo [RFC3852] for encrypting the AS
>       reply key with the temporary key contained in the encryptedKey
>       field of the type KeyTransRecipientInfo [RFC3852], as described
in
330d332
<    PKINIT makes use of the following new pre-authentication types:




339a340,351
>       Section 3.2.3.2: des-ede3-cbc (three-key 3DES, CBC mode)
>       [RFC3370].
>=20
>    In addition, implementations of this specification MUST be capable
of
>    processing the Extended Key Usage (EKU) extension and the
id-pkinit-
>    san (as defined in Section 3.2.2) otherName of the Subject
>    Alternative Name (SAN) extension in X.509 certificates [RFC3280].
>=20
> 3.1.2.  Defined Message and Encryption Types
>=20
>    PKINIT makes use of the following new pre-authentication types:
>=20
376d387
<    corresponding specifications.
378,382d388
<    Interoperability note: Some implementations may not be able to
decode
<    wrapped CMS objects encoded with BER; specifically, they may not be
<    able to decode indefinite length encodings.  To maximize
<    interoperability, implementers SHOULD encode CMS objects used in
<    PKINIT with DER.
384d389
< 3.1.3.  Algorithm Identifiers
386,391c391
<    PKINIT does not define, but does make use of, the following
algorithm
<    identifiers.
<=20
<=20
<=20



396,397c396
<    PKINIT uses the following algorithm identifier(s) for Modular
<    Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
---
>    corresponding specifications.
399c398,402
<        dhpublicnumber (as described in [RFC3279])
---
>    Interoperability note: Some implementations may not be able to
decode
>    wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects
encoded
>    with BER; specifically, they may not be able to decode indefinite
>    length encodings.  To maximize interoperability, implementers
SHOULD
>    encode CMS objects used in PKINIT with DER.
401,402c404
<    PKINIT uses the following signature algorithm identifiers as
defined
<    in [RFC3279]:
---
> 3.1.3.  Kerberos Encryption Types for CMS Algorithm Identifiers
404,406c406,411
<        sha-1WithRSAEncryption (RSA with SHA1)
<        md5WithRSAEncryption   (RSA with MD5)
<        id-dsa-with-sha1       (DSA with SHA1)
---
>    For historical reasons, PKINIT defines the following Kerberos
>    encryption types [RFC4120], for use in the etype field of the
AS-REQ
>    [RFC4120] message to indicate acceptance of the corresponding
>    algorithms (including public encryption algorithms, bulk encryption
>    agorithms, and signature algorithms) that can used by Cryptographic
>    Message Syntax (CMS) [RFC3852] messages in the reply:
408,425d412
<    PKINIT uses the following encryption algorithm identifiers as
defined
<    in [RFC3447] for encrypting the temporary key with a public key:
<=20
<        rsaEncryption
<        id-RSAES-OAEP
<=20
<    PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
<    for encrypting the AS reply key with the temporary key:
<=20
<        des-ede3-cbc (three-key 3DES, CBC mode, as defined in
[RFC3370])
<        rc2-cbc       (RC2, CBC mode, as defined in [RFC3370])
<        id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
<=20
<    PKINIT defines the following encryption types, for use in the etype
<    field of the AS-REQ [RFC4120] message to indicate acceptance of the
<    corresponding algorithms that can used by Cryptographic Message
<    Syntax (CMS) [RFC3852] messages in the reply:
<=20
427c414,415
<           -- Indicates that the client supports id-dsa-with-sha1.
---
>           -- Indicates that the client supports id-dsa-with-sha1
>           -- [RFC3279].
429c417,418
<           -- Indicates that the client supports md5WithRSAEncryption.
---
>           -- Indicates that the client supports md5WithRSAEncryption
>           -- [RFC3279].
431c420,421
<           -- Indicates that the client supports
sha-1WithRSAEncryption.
---
>           -- Indicates that the client supports sha-1WithRSAEncryption
>           -- [RFC3279].
433c423
<           -- Indicates that the client supports rc2-cbc.
---
>           -- Indicates that the client supports rc2-cbc [RFC3370].
435c425,426
<           -- Indicates that the client supports rsaEncryption.
---
>           -- Indicates that the client supports rsaEncryption
>           -- [RFC3447] [RFC3279].
437c428,429
<           -- Indicates that the client supports id-RSAES-OAEP.
---
>           -- Indicates that the client supports id-RSAES-OAEP
>           -- [RFC3447] [RFC3279].
439c431
<           -- Indicates that the client supports des-ede3-cbc.
---
>           -- Indicates that the client supports des-ede3-cbc
[RFC3370].
440a433,437
>    Per [RFC4120], these encryption types are sent in the decreasing
>    preference order of the client, and there is no significance in the
>    relative order between any two of different types of algorithms:
>    public key encryption algorithms, bulk encryption algorithms, and
>    signature algorithms.
441a439,442
>    In the etype field of the AS-REQ, the client SHOULD send the
kerberos
>    encryption type corresponding to the CMS algorithm idenitifer if
that
>    algorithm identifier is assigned with a kerberos encryption type in
>    the encryption type list above.



548,549c548,550
<                    -- List of CMS encryption types supported by the
<                    -- client in order of (decreasing) preference.
---
>                    -- List of CMS encryption, bulk encryption,
>                    -- or signature algorithm identifiers supported by
>                    -- the client in order of (decreasing) preference.
555d555
<        }
559c559
563a564,565
>        }
>=20
610,611d611
<        encryption types supported by the client in order of
(decreasing)
<        preference.  The clientDHNonce field is described later in this
615c615

620c620,632
<        section.
---
>        algorithm identifiers (for encryption algorithms, bulk
encryption
>        algorithms and signature algorithms) that are supported by the
>        client in order of (decreasing) preference, and can be used to
>        identify a signature agorithm or a public key encryption
>        algorithm in the keyEncryptionAlgorithm field of the type
>        KeyTransRecipientInfo or a bulk encryption algorithm in the
>        contentEncryptionAlgorithm field of the type
EncryptedContentInfo
>        [RFC3852] when encrypting the AS reply key as described in
>        Section 3.2.3.2.  However, there is no significance in the
>        relative order between any two of different types of
algorithms:
>        public key encryption algorithms, bulk encryption algorithms
and
>        signature algorithms.  The clientDHNonce field is described
later
>        in this section.

978a993,997
>    Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
>    data does permit empty SEQUENCEs to be encoded.  Such empty
sequences
>    may only be used if the KDC itself vouches for the user's
>    certificate.
>=20
1382,1386d1424
<    Implementation note: CAs issuing KDC certificates SHOULD place all
<    "short" and "fully-qualified" Kerberos realm names of the KDC (one
<    per GeneralName [RFC3280]) into the KDC certificate to allow
maximum
<    flexibility.
<=20

1443a1482,1493
>    The security of cryptographic algorithms is dependent on generating
>    secret quantities [RFC4086].  The number of truly random bits is
>    extremely important to determining the attack resistance strength
of
>    the cryptosystem, for example, the secret Diffie-Hellman exponents
>    must be chosen based on n truly random bits (where n is the system
>    security requirement).  The security of the overall system is
>    significantly weakened by using insufficient random inputs: a
>    sophisticated attacker may find it easier to reproduce the
>    environment that produced the secret quantities and to search the
>    resulting small set of possibilities than to locate the quantities
in
>    the whole of the potential number space.
>=20
1504,1506c1553,1556
<    policies may allow the use of relatively weak public keys.  Using
<    such keys to wrap data encrypted under stronger conventional
<    cryptosystems may be inappropriate.
---
>    policies may allow the use of relatively weak public keys.  When
>    using such weak asymmetric keys to protect/exchange stronger
>    symmetric Keys, the attack resistant strength of the overall system
>    is no better than that of these weak keys [RFC3766].
1507a1558,1560
>    PKINIT requires keys for symmetric cryptosystems to be generated.
>    Some such systems contain "weak" keys.  For recommendations
regarding
>    these weak keys, see [RFC4120].
1508a1562,1563
>    PKINIT allows the use of the same RSA key pair for encryption and
>    signing when doing RSA encryption based key delivery.  This is not
1511c1566,1567
< Zhu & Tung                Expires July 15, 2006                [Page
27]
---
>=20
> Zhu & Tung                Expires July 27, 2006                [Page
28]
1516,1521d1571
<    PKINIT requires keys for symmetric cryptosystems to be generated.
<    Some such systems contain "weak" keys.  For recommendations
regarding
<    these weak keys, see [RFC4120].
<=20
<    PKINIT allows the use of the same RSA key pair for encryption and
<    signing when doing RSA encryption based key delivery.  This is not
1542,1545d1591
<    The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
<    permit empty SEQUENCEs to be encoded.  Such empty sequences may
only
<    be used if the KDC itself vouches for the user's certificate.
<=20
11699a1736,1742
>               April 1999.
>=20
>    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
>               Version 5 Generic Security Service Application Program
>               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
>               July 2005.
>=20
1728a1772,1775
>        id-pkinit-authData      OBJECT IDENTIFIER  ::=3D { id-pkinit 1 =
}
>        id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::=3D { id-pkinit 2 =
}
>        id-pkinit-rkeyData      OBJECT IDENTIFIER  ::=3D { id-pkinit 3 =
}
>        id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::=3D { id-pkinit 4 =
}
1731c1778,1779
< Zhu & Tung                Expires July 15, 2006                [Page
31]
---
>=20
> Zhu & Tung                Expires July 27, 2006                [Page
32]
1736,1739d1783
<        id-pkinit-authData      OBJECT IDENTIFIER  ::=3D { id-pkinit 1 =
}
<        id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::=3D { id-pkinit 2 =
}
<        id-pkinit-rkeyData      OBJECT IDENTIFIER  ::=3D { id-pkinit 3 =
}
<        id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::=3D { id-pkinit 4 =
}
1783a1828
>        }
1784a1830
>        DHNonce ::=3D OCTET STRING
1787c1833,1835
<=20
<        DHNonce ::=3D OCTET STRING
<=20
1839c1883,1887
<                    -- List of CMS encryption types supported by the
---
>                    -- List of CMS encryption, bulk encryption,
>                    -- or signature algorithm identifiers supported by
>                    -- the client in order of (decreasing) preference.
>           clientDHNonce           [3] DHNonce OPTIONAL,


------_=_NextPart_001_01C6208C.3E155F3F
Content-Type: text/plain;
	name="draft-ietf-cat-kerberos-pk-init-33.txt"
Content-Description: draft-ietf-cat-kerberos-pk-init-33.txt
Content-Disposition: attachment;
	filename="draft-ietf-cat-kerberos-pk-init-33.txt"
Content-Transfer-Encoding: base64

DQoNCg0KTkVUV09SSyBXT1JLSU5HIEdST1VQICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgTC4gWmh1DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBNaWNyb3NvZnQgQ29ycG9yYXRpb24NCkV4cGlyZXM6IEp1bHkgMjcs
IDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQi4gVHVuZw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBVU0MgSW5mb3JtYXRpb24gU2Np
ZW5jZXMgSW5zdGl0dXRlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEphbnVhcnkgMjMsIDIwMDYNCg0KDQogICAgIFB1YmxpYyBLZXkgQ3J5
cHRvZ3JhcGh5IGZvciBJbml0aWFsIEF1dGhlbnRpY2F0aW9uIGluIEtlcmJlcm9zDQogICAgICAg
ICAgICAgICAgICAgZHJhZnQtaWV0Zi1jYXQta2VyYmVyb3MtcGstaW5pdC0zMw0KDQpTdGF0dXMg
b2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFj
aCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3Ro
ZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUgYmVlbiBv
ciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcw0K
ICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYg
b2YgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9m
IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVh
cywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1h
eSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFm
dHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh
IG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwg
b3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBp
bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRl
cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoN
CiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBh
dA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBU
aGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vz
c2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIElu
dGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEp1bHkgMjcsIDIwMDYuDQoNCkNvcHlyaWdodCBO
b3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuDQoN
CkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHByb3RvY29sIGV4dGVuc2lv
bnMgKGhlcmVhZnRlciBjYWxsZWQgUEtJTklUKQ0KICAgdG8gdGhlIEtlcmJlcm9zIHByb3RvY29s
IHNwZWNpZmljYXRpb24uICBUaGVzZSBleHRlbnNpb25zIHByb3ZpZGUgYQ0KICAgbWV0aG9kIGZv
ciBpbnRlZ3JhdGluZyBwdWJsaWMga2V5IGNyeXB0b2dyYXBoeSBpbnRvIHRoZSBpbml0aWFsDQog
ICBhdXRoZW50aWNhdGlvbiBleGNoYW5nZSwgYnkgdXNpbmcgYXN5bW1ldHJpYy1rZXkgc2lnbmF0
dXJlIGFuZC9vcg0KICAgZW5jcnlwdGlvbiBhbGdvcml0aG1zIGluIHByZS1hdXRoZW50aWNhdGlv
biBkYXRhIGZpZWxkcy4NCg0KDQoNCg0KDQpaaHUgJiBUdW5nICAgICAgICAgICAgICAgIEV4cGly
ZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURy
YWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkg
MjAwNg0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIENv
bnZlbnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuICA1DQogICAzLiAgRXh0ZW5zaW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgMy4xLiAgRGVmaW5pdGlvbnMsIFJlcXVpcmVt
ZW50cywgYW5kIENvbnN0YW50cyAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgICAgIDMuMS4xLiAg
UmVxdWlyZWQgQWxnb3JpdGhtcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2
DQogICAgICAgMy4xLjIuICBEZWZpbmVkIE1lc3NhZ2UgYW5kIEVuY3J5cHRpb24gVHlwZXMgLiAu
IC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgICAzLjEuMy4gIEtlcmJlcm9zIEVuY3J5cHRpb24gVHlw
ZXMgZm9yIENNUyBBbGdvcml0aG0NCiAgICAgICAgICAgICAgIElkZW50aWZpZXJzICAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAzLjIuICBQS0lOSVQg
UHJlLWF1dGhlbnRpY2F0aW9uIFN5bnRheCBhbmQgVXNlIC4gLiAuIC4gLiAuIC4gLiAuICA5DQog
ICAgICAgMy4yLjEuICBHZW5lcmF0aW9uIG9mIENsaWVudCBSZXF1ZXN0IC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gIDkNCiAgICAgICAzLjIuMi4gIFJlY2VpcHQgb2YgQ2xpZW50IFJlcXVlc3Qg
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgICAgIDMuMi4zLiAgR2VuZXJhdGlv
biBvZiBLREMgUmVwbHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICAgICAg
My4yLjQuICBSZWNlaXB0IG9mIEtEQyBSZXBseSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gMjUNCiAgICAgMy4zLiAgSW50ZXJvcGVyYWJpbGl0eSBSZXF1aXJlbWVudHMgIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNg0KICAgICAzLjQuICBLREMgSW5kaWNhdGlvbiBvZiBQ
S0lOSVQgU3VwcG9ydCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQogICA0LiAgU2VjdXJp
dHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
MjcNCiAgIDUuICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAyOQ0KICAgNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMwDQogICA3LiAgUmVmZXJlbmNlcyAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzANCiAg
ICAgNy4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAzMA0KICAgICA3LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyDQogICBBcHBlbmRpeCBBLiAgUEtJTklUIEFT
Ti4xIE1vZHVsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzINCiAgIEFwcGVu
ZGl4IEIuICBUZXN0IFZlY3RvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAzNw0KICAgQXBwZW5kaXggQy4gIE1pc2NlbGxhbmVvdXMgSW5mb3JtYXRpb24gYWJvdXQg
TWljcm9zb2Z0IFdpbmRvd3MNCiAgICAgICAgICAgICAgICBQS0lOSVQgSW1wbGVtZW50YXRpb25z
ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOQ0KICAgQXV0aG9ycycgQWRkcmVzc2Vz
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQxDQogICBJ
bnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAu
IC4gLiAuIC4gNDINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
Wmh1ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjcsIDIwMDYgICAgICAgICAg
ICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBQS0lO
SVQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDYNCg0KDQoxLiAgSW50cm9kdWN0aW9u
DQoNCiAgIFRoZSBLZXJiZXJvcyBWNSBwcm90b2NvbCBbUkZDNDEyMF0gaW52b2x2ZXMgdXNlIG9m
IGEgdHJ1c3RlZCB0aGlyZA0KICAgcGFydHkga25vd24gYXMgdGhlIEtleSBEaXN0cmlidXRpb24g
Q2VudGVyIChLREMpIHRvIG5lZ290aWF0ZSBzaGFyZWQNCiAgIHNlc3Npb24ga2V5cyBiZXR3ZWVu
IGNsaWVudHMgYW5kIHNlcnZpY2VzIGFuZCBwcm92aWRlIG11dHVhbA0KICAgYXV0aGVudGljYXRp
b24gYmV0d2VlbiB0aGVtLg0KDQogICBUaGUgY29ybmVyLXN0b25lIG9mIEtlcmJlcm9zIFY1IGlz
IHRoZSBUaWNrZXQgYW5kIHRoZSBBdXRoZW50aWNhdG9yLg0KICAgQSBUaWNrZXQgZW5jYXBzdWxh
dGVzIGEgc3ltbWV0cmljIGtleSAodGhlIHRpY2tldCBzZXNzaW9uIGtleSkgaW4gYW4NCiAgIGVu
dmVsb3BlIChhIHB1YmxpYyBtZXNzYWdlKSBpbnRlbmRlZCBmb3IgYSBzcGVjaWZpYyBzZXJ2aWNl
LiAgVGhlDQogICBjb250ZW50cyBvZiB0aGUgVGlja2V0IGFyZSBlbmNyeXB0ZWQgd2l0aCBhIHN5
bW1ldHJpYyBrZXkgc2hhcmVkDQogICBiZXR3ZWVuIHRoZSBzZXJ2aWNlIHByaW5jaXBhbCBhbmQg
dGhlIGlzc3VpbmcgS0RDLiAgVGhlIGVuY3J5cHRlZA0KICAgcGFydCBvZiB0aGUgVGlja2V0IGNv
bnRhaW5zIHRoZSBjbGllbnQgcHJpbmNpcGFsIG5hbWUsIGFtb25nc3Qgb3RoZXINCiAgIGl0ZW1z
LiAgQW4gQXV0aGVudGljYXRvciBpcyBhIHJlY29yZCB0aGF0IGNhbiBiZSBzaG93biB0byBoYXZl
IGJlZW4NCiAgIHJlY2VudGx5IGdlbmVyYXRlZCB1c2luZyB0aGUgdGlja2V0IHNlc3Npb24ga2V5
IGluIHRoZSBhc3NvY2lhdGVkDQogICBUaWNrZXQuICBUaGUgdGlja2V0IHNlc3Npb24ga2V5IGlz
IGtub3duIGJ5IHRoZSBjbGllbnQgd2hvIHJlcXVlc3RlZA0KICAgdGhlIHRpY2tldC4gIFRoZSBj
b250ZW50cyBvZiB0aGUgQXV0aGVudGljYXRvciBhcmUgZW5jcnlwdGVkIHdpdGggdGhlDQogICBh
c3NvY2lhdGVkIHRpY2tldCBzZXNzaW9uIGtleS4gIFRoZSBlbmNyeXB0ZWQgcGFydCBvZiBhbg0K
ICAgQXV0aGVudGljYXRvciBjb250YWlucyBhIHRpbWVzdGFtcCBhbmQgdGhlIGNsaWVudCBwcmlu
Y2lwYWwgbmFtZSwNCiAgIGFtb25nc3Qgb3RoZXIgaXRlbXMuDQoNCiAgIEFzIHNob3duIGluIEZp
Z3VyZSAxIGJlbG93LCB0aGUgS2VyYmVyb3MgVjUgcHJvdG9jb2wgY29uc2lzdHMgb2YgdGhlDQog
ICBmb2xsb3dpbmcgbWVzc2FnZSBleGNoYW5nZXMgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUg
S0RDLCBhbmQgdGhlDQogICBjbGllbnQgYW5kIHRoZSBhcHBsaWNhdGlvbiBzZXJ2aWNlOg0KDQog
ICAgLSBUaGUgQXV0aGVudGljYXRpb24gU2VydmljZSAoQVMpIEV4Y2hhbmdlDQoNCiAgICAgIFRo
ZSBjbGllbnQgb2J0YWlucyBhbiAiaW5pdGlhbCIgdGlja2V0IGZyb20gdGhlIEtlcmJlcm9zDQog
ICAgICBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgKEFTKSwgdHlwaWNhbGx5IGEgVGlja2V0IEdyYW50
aW5nIFRpY2tldA0KICAgICAgKFRHVCkuICBUaGUgQVMtUkVRIG1lc3NhZ2UgYW5kIHRoZSBBUy1S
RVAgbWVzc2FnZSBhcmUgdGhlIHJlcXVlc3QNCiAgICAgIGFuZCB0aGUgcmVwbHkgbWVzc2FnZSBy
ZXNwZWN0aXZlbHkgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgQVMuDQoNCiAgICAtIFRoZSBU
aWNrZXQgR3JhbnRpbmcgU2VydmljZSAoVEdTKSBFeGNoYW5nZQ0KDQogICAgICBUaGUgY2xpZW50
IHN1YnNlcXVlbnRseSB1c2VzIHRoZSBUR1QgdG8gYXV0aGVudGljYXRlIGFuZCByZXF1ZXN0IGEN
CiAgICAgIHNlcnZpY2UgdGlja2V0IGZvciBhIHBhcnRpY3VsYXIgc2VydmljZSwgZnJvbSB0aGUg
S2VyYmVyb3MgdGlja2V0LQ0KICAgICAgZ3JhbnRpbmcgc2VydmVyIChUR1MpLiAgVGhlIFRHUy1S
RVEgbWVzc2FnZSBhbmQgdGhlIFRHUy1SRVANCiAgICAgIG1lc3NhZ2UgYXJlIHRoZSByZXF1ZXN0
IGFuZCB0aGUgcmVwbHkgbWVzc2FnZSByZXNwZWN0aXZlbHkgYmV0d2Vlbg0KICAgICAgdGhlIGNs
aWVudCBhbmQgdGhlIFRHUy4NCg0KICAgIC0gVGhlIENsaWVudC9TZXJ2ZXIgQXV0aGVudGljYXRp
b24gUHJvdG9jb2wgKEFQKSBFeGNoYW5nZQ0KDQogICAgICBUaGUgY2xpZW50IHRoZW4gbWFrZXMg
YSByZXF1ZXN0IHdpdGggYW4gQVAtUkVRIG1lc3NhZ2UsIGNvbnNpc3RpbmcNCiAgICAgIG9mIGEg
c2VydmljZSB0aWNrZXQgYW5kIGFuIGF1dGhlbnRpY2F0b3IgdGhhdCBjZXJ0aWZpZXMgdGhlDQog
ICAgICBjbGllbnQncyBwb3NzZXNzaW9uIG9mIHRoZSB0aWNrZXQgc2Vzc2lvbiBrZXkuICBUaGUg
c2VydmVyIG1heQ0KICAgICAgb3B0aW9uYWxseSByZXBseSB3aXRoIGFuIEFQLVJFUCBtZXNzYWdl
LiAgQVAgZXhjaGFuZ2VzIHR5cGljYWxseQ0KICAgICAgbmVnb3RpYXRlIHNlc3Npb24gc3BlY2lm
aWMgc3ltbWV0cmljIGtleXMuDQoNCg0KDQoNClpodSAmIFR1bmcgICAgICAgICAgICAgICAgRXhw
aXJlcyBKdWx5IDI3LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQt
RHJhZnQgICAgICAgICAgICAgICAgICAgUEtJTklUICAgICAgICAgICAgICAgICAgICAgSmFudWFy
eSAyMDA2DQoNCg0KICAgVXN1YWxseSwgdGhlIEFTIGFuZCBUR1MgYXJlIGludGVncmF0ZWQgaW4g
YSBzaW5nbGUgZGV2aWNlIGFsc28ga25vd24NCiAgIGFzIHRoZSBLREMuDQoNCiAgICAgIEZpZ3Vy
ZSAxOiAgVGhlIE1lc3NhZ2UgRXhjaGFuZ2VzIGluIHRoZSBLZXJiZXJvcyBWNSBQcm90b2NvbA0K
DQogICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAg
ICAgICstLS0tLS0tLS0+fCAgS0RDICAgICAgICAgfA0KICAgICAgIEFTLVJFUSAvICAgKy0tLS0t
LS18ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgLyAgIC8gICAgICAgICstLS0tLS0tLS0t
LS0tLSsNCiAgICAgICAgICAgIC8gICAvICAgICAgICAgIF4gICAgICAgICAgIHwNCiAgICAgICAg
ICAgLyAgICB8QVMtUkVQICAgLyAgICAgICAgICAgIHwNCiAgICAgICAgICB8ICAgICB8ICAgICAg
ICAvIFRHUy1SRVEgICAgICsgVEdTLVJFUA0KICAgICAgICAgIHwgICAgIHwgICAgICAgLyAgICAg
ICAgICAgICAvDQogICAgICAgICAgfCAgICAgfCAgICAgIC8gICAgICAgICAgICAgLw0KICAgICAg
ICAgIHwgICAgIHwgICAgIC8gICArLS0tLS0tLS0tKw0KICAgICAgICAgIHwgICAgIHwgICAgLyAg
IC8NCiAgICAgICAgICB8ICAgICB8ICAgLyAgIC8NCiAgICAgICAgICB8ICAgICB8ICAvICAgLw0K
ICAgICAgICAgIHwgICAgIHYgLyAgIHYNCiAgICAgICAgICsrLS0tLS0tLSstLS0tLS0rICAgICAg
ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgIHwgIENsaWVudCAgICAgICArLS0t
LS0tLS0tLS0tPnwgIEFwcGxpY2F0aW9uICAgIHwNCiAgICAgICAgIHwgICAgICAgICAgICAgICB8
ICAgIEFQLVJFUSAgIHwgIFNlcnZlciAgICAgICAgIHwNCiAgICAgICAgIHwgICAgICAgICAgICAg
ICB8LS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgKy0tLS0tLS0tLS0t
LS0tLSsgICAgQVAtUkVQICAgKy0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICBJbiB0aGUgQVMgZXhj
aGFuZ2UsIHRoZSBLREMgcmVwbHkgY29udGFpbnMgdGhlIHRpY2tldCBzZXNzaW9uIGtleSwNCiAg
IGFtb25nc3Qgb3RoZXIgaXRlbXMsIHRoYXQgaXMgZW5jcnlwdGVkIHVzaW5nIGEga2V5ICh0aGUg
QVMgcmVwbHkga2V5KQ0KICAgc2hhcmVkIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIEtEQy4g
IFRoZSBBUyByZXBseSBrZXkgaXMgdHlwaWNhbGx5DQogICBkZXJpdmVkIGZyb20gdGhlIGNsaWVu
dCdzIHBhc3N3b3JkIGZvciBodW1hbiB1c2Vycy4gIFRoZXJlZm9yZSBmb3INCiAgIGh1bWFuIHVz
ZXJzIHRoZSBhdHRhY2sgcmVzaXN0YW5jZSBzdHJlbmd0aCBvZiB0aGUgS2VyYmVyb3MgcHJvdG9j
b2wNCiAgIGlzIG5vIHN0cm9uZ2VyIHRoYW4gdGhlIHN0cmVuZ3RoIG9mIHRoZWlyIHBhc3N3b3Jk
cy4NCg0KICAgVGhlIHVzZSBvZiBhc3ltbWV0cmljIGNyeXB0b2dyYXBoeSBpbiB0aGUgZm9ybSBv
ZiBYLjUwOSBjZXJ0aWZpY2F0ZXMNCiAgIFtSRkMzMjgwXSBpcyBwb3B1bGFyIGZvciBmYWNpbGl0
YXRpbmcgZGF0YSBvcmlnaW4gYXV0aGVudGljYXRpb24gYW5kDQogICBwZXJmZWN0IHNlY3JlY3ku
ICBBbiBlc3RhYmxpc2hlZCBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpDQogICBwcm92
aWRlcyBrZXkgbWFuYWdlbWVudCBhbmQga2V5IGRpc3RyaWJ1dGlvbiBtZWNoYW5pc21zIHRoYXQg
Y2FuIGJlDQogICB1c2VkIHRvIGVzdGFibGlzaCBhdXRoZW50aWNhdGlvbiBhbmQgc2VjdXJlIGNv
bW11bmljYXRpb24uICBBZGRpbmcNCiAgIHB1YmxpYy1rZXkgY3J5cHRvZ3JhcGh5IHRvIEtlcmJl
cm9zIHByb3ZpZGVzIGEgbmljZSBjb25ncnVlbmNlIHRvDQogICBwdWJsaWMta2V5IHByb3RvY29s
cywgb2J2aWF0ZXMgdGhlIGh1bWFuIHVzZXJzJyBidXJkZW4gdG8gbWFuYWdlDQogICBzdHJvbmcg
cGFzc3dvcmRzLCBhbmQgYWxsb3dzIEtlcmJlcml6ZWQgYXBwbGljYXRpb25zIHRvIHRha2UNCiAg
IGFkdmFudGFnZSBvZiBleGlzdGluZyBrZXkgc2VydmljZXMgYW5kIGlkZW50aXR5IG1hbmFnZW1l
bnQuDQoNCiAgIFRoZSBhZHZhbnRhZ2UgYWZmb3JkZWQgYnkgdGhlIEtlcmJlcm9zIFRHVCBpcyB0
aGF0IHRoZSBjbGllbnQgZXhwb3Nlcw0KICAgaGlzIGxvbmctdGVybSBzZWNyZXRzIG9ubHkgb25j
ZS4gIFRoZSBUR1QgYW5kIGl0cyBhc3NvY2lhdGVkIHNlc3Npb24NCiAgIGtleSBjYW4gdGhlbiBi
ZSB1c2VkIGZvciBhbnkgc3Vic2VxdWVudCBzZXJ2aWNlIHRpY2tldCByZXF1ZXN0cy4gIE9uZQ0K
ICAgcmVzdWx0IG9mIHRoaXMgaXMgdGhhdCBhbGwgZnVydGhlciBhdXRoZW50aWNhdGlvbiBpcyBp
bmRlcGVuZGVudCBvZg0KICAgdGhlIG1ldGhvZCBieSB3aGljaCB0aGUgaW5pdGlhbCBhdXRoZW50
aWNhdGlvbiB3YXMgcGVyZm9ybWVkLg0KICAgQ29uc2VxdWVudGx5LCBpbml0aWFsIGF1dGhlbnRp
Y2F0aW9uIHByb3ZpZGVzIGEgY29udmVuaWVudCBwbGFjZSB0bw0KDQoNCg0KWmh1ICYgVHVuZyAg
ICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjcsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdl
IDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBQS0lOSVQgICAgICAgICAg
ICAgICAgICAgICBKYW51YXJ5IDIwMDYNCg0KDQogICBpbnRlZ3JhdGUgcHVibGljLWtleSBjcnlw
dG9ncmFwaHkgaW50byBLZXJiZXJvcyBhdXRoZW50aWNhdGlvbi4gIEluDQogICBhZGRpdGlvbiwg
dGhlIHVzZSBvZiBzeW1tZXRyaWMgY3J5cHRvZ3JhcGh5IGFmdGVyIHRoZSBpbml0aWFsDQogICBl
eGNoYW5nZSBpcyBwcmVmZXJyZWQgZm9yIHBlcmZvcm1hbmNlLg0KDQogICBUaGlzIGRvY3VtZW50
IGRlc2NyaWJlcyB0aGUgbWV0aG9kcyBhbmQgZGF0YSBmb3JtYXRzIHVzaW5nIHdoaWNoIHRoZQ0K
ICAgY2xpZW50IGFuZCB0aGUgS0RDIGNhbiB1c2UgcHVibGljIGFuZCBwcml2YXRlIGtleSBwYWly
cyB0byBtdXR1YWxseQ0KICAgYXV0aGVudGljYXRlIGluIHRoZSBBUyBleGNoYW5nZSBhbmQgbmVn
b3RpYXRlIHRoZSBBUyByZXBseSBrZXksIGtub3duDQogICBvbmx5IGJ5IHRoZSBjbGllbnQgYW5k
IHRoZSBLREMsIHRvIGVuY3J5cHQgdGhlIEFTLVJFUCBzZW50IGJ5IHRoZQ0KICAgS0RDLg0KDQoN
CjIuICBDb252ZW50aW9ucyBVc2VkIGluIFRoaXMgRG9jdW1lbnQNCg0KICAgVGhlIGtleSB3b3Jk
cyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0K
ICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BU
SU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNj
cmliZWQgaW4gW1JGQzIxMTldLg0KDQogICBJbiB0aGlzIHByb3RvY29sLCBib3RoIHRoZSBjbGll
bnQgYW5kIHRoZSBLREMgaGF2ZSBhIHB1YmxpYy1wcml2YXRlDQogICBrZXkgcGFpciBpbiBvcmRl
ciB0byBwcm92ZSB0aGVpciBpZGVudGl0aWVzIHRvIGVhY2ggb3RoZXIgb3ZlciB0aGUNCiAgIG9w
ZW4gbmV0d29yay4gIFRoZSB0ZXJtICJzaWduYXR1cmUga2V5IiBpcyB1c2VkIHRvIHJlZmVyIHRv
IHRoZQ0KICAgcHJpdmF0ZSBrZXkgb2YgdGhlIGtleSBwYWlyIGJlaW5nIHVzZWQuDQoNCiAgIFRo
ZSBlbmNyeXB0aW9uIGtleSB1c2VkIHRvIGVuY3J5cHQgdGhlIGVuYy1wYXJ0IGZpZWxkIG9mIHRo
ZSBLREMtUkVQDQogICBpbiB0aGUgQVMtUkVQIFtSRkM0MTIwXSBpcyByZWZlcnJlZCB0byBhcyB0
aGUgQVMgcmVwbHkga2V5Lg0KDQogICBBbiBlbXB0eSBzZXF1ZW5jZSBpbiBhbiBvcHRpb25hbCBm
aWVsZCBjYW4gYmUgZWl0aGVyIGluY2x1ZGVkIG9yDQogICBvbWl0dGVkOiBib3RoIGVuY29kaW5n
cyBhcmUgcGVybWl0dGVkIGFuZCBjb25zaWRlcmVkIGVxdWl2YWxlbnQuDQoNCiAgIFRoZSB0ZXJt
ICJNb2R1bGFyIEV4cG9uZW50aWFsIERpZmZpZS1IZWxsbWFuIiBpcyB1c2VkIHRvIHJlZmVyIHRv
IHRoZQ0KICAgRGlmZmllLUhlbGxtYW4ga2V5IGV4Y2hhbmdlIGFzIGRlc2NyaWJlZCBpbiBbUkZD
MjYzMV0sIGluIG9yZGVyIHRvDQogICBkaWZmZXJlbnRpYXRlIGl0IGZyb20gb3RoZXIgZXF1aXZh
bGVudCByZXByZXNlbnRhdGlvbnMgb2YgdGhlIHNhbWUNCiAgIGtleSBhZ3JlZW1lbnQgYWxnb3Jp
dGhtLg0KDQoNCjMuICBFeHRlbnNpb25zDQoNCiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgZXh0
ZW5zaW9ucyB0byBbUkZDNDEyMF0gZm9yIHN1cHBvcnRpbmcgdGhlIHVzZQ0KICAgb2YgcHVibGlj
LWtleSBjcnlwdG9ncmFwaHkgaW4gdGhlIGluaXRpYWwgcmVxdWVzdCBmb3IgYSB0aWNrZXQuDQoN
CiAgIEJyaWVmbHksIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgZm9sbG93aW5nIGV4dGVuc2lv
bnMgdG8gW1JGQzQxMjBdOg0KDQogICAxLiBUaGUgY2xpZW50IGluZGljYXRlcyB0aGUgdXNlIG9m
IHB1YmxpYy1rZXkgYXV0aGVudGljYXRpb24gYnkNCiAgICAgIGluY2x1ZGluZyBhIHNwZWNpYWwg
cHJlYXV0aGVudGljYXRvciBpbiB0aGUgaW5pdGlhbCByZXF1ZXN0LiAgVGhpcw0KICAgICAgcHJl
YXV0aGVudGljYXRvciBjb250YWlucyB0aGUgY2xpZW50J3MgcHVibGljLWtleSBkYXRhIGFuZCBh
DQogICAgICBzaWduYXR1cmUuDQoNCg0KDQoNCg0KDQpaaHUgJiBUdW5nICAgICAgICAgICAgICAg
IEV4cGlyZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVy
bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAgICAgICAgICAgICAgICAgICAgIEph
bnVhcnkgMjAwNg0KDQoNCiAgIDIuIFRoZSBLREMgdGVzdHMgdGhlIGNsaWVudCdzIHJlcXVlc3Qg
YWdhaW5zdCBpdHMgYXV0aGVudGljYXRpb24NCiAgICAgIHBvbGljeSBhbmQgdHJ1c3RlZCBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0aWVzIChDQXMpLg0KDQogICAzLiBJZiB0aGUgcmVxdWVzdCBwYXNz
ZXMgdGhlIHZlcmlmaWNhdGlvbiB0ZXN0cywgdGhlIEtEQyByZXBsaWVzIGFzDQogICAgICB1c3Vh
bCwgYnV0IHRoZSByZXBseSBpcyBlbmNyeXB0ZWQgdXNpbmcgZWl0aGVyOg0KDQogICAgICBhLiBh
IGtleSBnZW5lcmF0ZWQgdGhyb3VnaCBhIERpZmZpZS1IZWxsbWFuIChESCkga2V5IGV4Y2hhbmdl
DQogICAgICAgICBbUkZDMjYzMV0gW0lFRUUxMzYzXSB3aXRoIHRoZSBjbGllbnQsIHNpZ25lZCB1
c2luZyB0aGUgS0RDJ3MNCiAgICAgICAgIHNpZ25hdHVyZSBrZXk7IG9yDQoNCiAgICAgIGIuIGEg
c3ltbWV0cmljIGVuY3J5cHRpb24ga2V5LCBzaWduZWQgdXNpbmcgdGhlIEtEQydzIHNpZ25hdHVy
ZQ0KICAgICAgICAga2V5IGFuZCBlbmNyeXB0ZWQgdXNpbmcgdGhlIGNsaWVudCdzIHB1YmxpYyBr
ZXkuDQoNCiAgICAgIEFueSBrZXlpbmcgbWF0ZXJpYWwgcmVxdWlyZWQgYnkgdGhlIGNsaWVudCB0
byBvYnRhaW4gdGhlDQogICAgICBlbmNyeXB0aW9uIGtleSBmb3IgZGVjcnlwdGluZyB0aGUgS0RD
IHJlcGx5IGlzIHJldHVybmVkIGluIGEgcHJlLQ0KICAgICAgYXV0aGVudGljYXRpb24gZmllbGQg
YWNjb21wYW55aW5nIHRoZSB1c3VhbCByZXBseS4NCg0KICAgNC4gVGhlIGNsaWVudCB2YWxpZGF0
ZXMgdGhlIEtEQydzIHNpZ25hdHVyZSwgb2J0YWlucyB0aGUgZW5jcnlwdGlvbg0KICAgICAga2V5
LCBkZWNyeXB0cyB0aGUgcmVwbHksIGFuZCB0aGVuIHByb2NlZWRzIGFzIHVzdWFsLg0KDQogICBT
ZWN0aW9uIDMuMSBvZiB0aGlzIGRvY3VtZW50IGVudW1lcmF0ZXMgdGhlIHJlcXVpcmVkIGFsZ29y
aXRobXMgYW5kDQogICBuZWNlc3NhcnkgZXh0ZW5zaW9uIG1lc3NhZ2UgdHlwZXMuICBTZWN0aW9u
IDMuMiBkZXNjcmliZXMgdGhlDQogICBleHRlbnNpb24gbWVzc2FnZXMgaW4gZ3JlYXRlciBkZXRh
aWwuDQoNCjMuMS4gIERlZmluaXRpb25zLCBSZXF1aXJlbWVudHMsIGFuZCBDb25zdGFudHMNCg0K
My4xLjEuICBSZXF1aXJlZCBBbGdvcml0aG1zDQoNCiAgIEFsbCBQS0lOSVQgaW1wbGVtZW50YXRp
b25zIE1VU1Qgc3VwcG9ydCB0aGUgZm9sbG93aW5nIGFsZ29yaXRobXM6DQoNCiAgIG8gIEFTIHJl
cGx5IGtleSBlbmN0eXBlOiBhZXMxMjgtY3RzLWhtYWMtc2hhMS05NiBhbmQgYWVzMjU2LWN0cy1o
bWFjLQ0KICAgICAgc2hhMS05NiBbUkZDMzk2Ml0uDQoNCiAgIG8gIFNpZ25hdHVyZSBhbGdvcml0
aG06IHNoYS0xV2l0aFJTQUVuY3J5cHRpb24gW1JGQzMyNzldLg0KDQogICBvICBBUyByZXBseSBr
ZXkgZGVsaXZlcnkgbWV0aG9kOiBEaWZmaWUtSGVsbG1hbiBrZXkgZXhjaGFuZ2UNCiAgICAgIFtS
RkMyNjMxXS4NCg0KICAgbyAgQWxnb3JpdGhtcyBpZGVudGlmaWVkIGluIHRoZSBjb250ZW50RW5j
cnlwdGlvbkFsZ29yaXRobSBmaWVsZCBvZg0KICAgICAgdGhlIHR5cGUgRW5jcnlwdGVkQ29udGVu
dEluZm8gW1JGQzM4NTJdIGZvciBlbmNyeXB0aW5nIHRoZQ0KICAgICAgdGVtcG9yYXJ5IGtleSBp
biB0aGUgZW5jcnlwdGVkS2V5IGZpZWxkIG9mIHRoZSB0eXBlDQogICAgICBLZXlUcmFuc1JlY2lw
aWVudEluZm8gW1JGQzM4NTJdIHdpdGggYSBwdWJsaWMga2V5LCBhcyBkZXNjcmliZWQgaW4NCiAg
ICAgIFNlY3Rpb24gMy4yLjMuMjogcnNhRW5jcnlwdGlvbiBbUkZDMzQ0N10gW1JGQzMyNzldLg0K
DQogICBvICBBbGdvcml0aG1zIGlkZW50aWZpZWQgaW4gdGhlIGNvbnRlbnRFbmNyeXB0aW9uQWxn
b3JpdGhtIGZpZWxkIG9mDQogICAgICB0aGUgdHlwZSBFbmNyeXB0ZWRDb250ZW50SW5mbyBbUkZD
Mzg1Ml0gZm9yIGVuY3J5cHRpbmcgdGhlIEFTDQogICAgICByZXBseSBrZXkgd2l0aCB0aGUgdGVt
cG9yYXJ5IGtleSBjb250YWluZWQgaW4gdGhlIGVuY3J5cHRlZEtleQ0KICAgICAgZmllbGQgb2Yg
dGhlIHR5cGUgS2V5VHJhbnNSZWNpcGllbnRJbmZvIFtSRkMzODUyXSwgYXMgZGVzY3JpYmVkIGlu
DQoNCg0KDQpaaHUgJiBUdW5nICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyNywgMjAwNiAg
ICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg
ICAgIFBLSU5JVCAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgICAgIFNl
Y3Rpb24gMy4yLjMuMjogZGVzLWVkZTMtY2JjICh0aHJlZS1rZXkgM0RFUywgQ0JDIG1vZGUpDQog
ICAgICBbUkZDMzM3MF0uDQoNCiAgIEluIGFkZGl0aW9uLCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhp
cyBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgY2FwYWJsZSBvZg0KICAgcHJvY2Vzc2luZyB0aGUgRXh0
ZW5kZWQgS2V5IFVzYWdlIChFS1UpIGV4dGVuc2lvbiBhbmQgdGhlIGlkLXBraW5pdC0NCiAgIHNh
biAoYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMi4yKSBvdGhlck5hbWUgb2YgdGhlIFN1YmplY3QN
CiAgIEFsdGVybmF0aXZlIE5hbWUgKFNBTikgZXh0ZW5zaW9uIGluIFguNTA5IGNlcnRpZmljYXRl
cyBbUkZDMzI4MF0uDQoNCjMuMS4yLiAgRGVmaW5lZCBNZXNzYWdlIGFuZCBFbmNyeXB0aW9uIFR5
cGVzDQoNCiAgIFBLSU5JVCBtYWtlcyB1c2Ugb2YgdGhlIGZvbGxvd2luZyBuZXcgcHJlLWF1dGhl
bnRpY2F0aW9uIHR5cGVzOg0KDQogICAgICAgUEFfUEtfQVNfUkVRICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgMTYNCiAgICAgICBQQV9QS19BU19SRVAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAxNw0KDQogICBQS0lOSVQgYWxzbyBtYWtlcyB1c2Ugb2YgdGhlIGZvbGxv
d2luZyBuZXcgYXV0aG9yaXphdGlvbiBkYXRhIHR5cGU6DQoNCiAgICAgICBBRF9JTklUSUFMX1ZF
UklGSUVEX0NBUyAgICAgICAgICAgICAgICAgICAgICAgOQ0KDQogICBQS0lOSVQgaW50cm9kdWNl
cyB0aGUgZm9sbG93aW5nIG5ldyBlcnJvciBjb2RlczoNCg0KICAgICAgIEtEQ19FUlJfQ0xJRU5U
X05PVF9UUlVTVEVEICAgICAgICAgICAgICAgICAgIDYyDQogICAgICAgS0RDX0VSUl9JTlZBTElE
X1NJRyAgICAgICAgICAgICAgICAgICAgICAgICAgNjQNCiAgICAgICBLRENfRVJSX0RIX0tFWV9Q
QVJBTUVURVJTX05PVF9BQ0NFUFRFRCAgICAgICA2NQ0KICAgICAgIEtEQ19FUlJfQ0FOVF9WRVJJ
RllfQ0VSVElGSUNBVEUgICAgICAgICAgICAgIDcwDQogICAgICAgS0RDX0VSUl9JTlZBTElEX0NF
UlRJRklDQVRFICAgICAgICAgICAgICAgICAgNzENCiAgICAgICBLRENfRVJSX1JFVk9LRURfQ0VS
VElGSUNBVEUgICAgICAgICAgICAgICAgICA3Mg0KICAgICAgIEtEQ19FUlJfUkVWT0NBVElPTl9T
VEFUVVNfVU5LTk9XTiAgICAgICAgICAgIDczDQogICAgICAgS0RDX0VSUl9DTElFTlRfTkFNRV9N
SVNNQVRDSCAgICAgICAgICAgICAgICAgNzUNCiAgICAgICBLRENfRVJSX0lOQ09OU0lTVEVOVF9L
RVlfUFVSUE9TRSAgICAgICAgICAgICA3Nw0KICAgICAgIEtEQ19FUlJfRElHRVNUX0lOX0NFUlRf
Tk9UX0FDQ0VQVEVEICAgICAgICAgIDc4DQogICAgICAgS0RDX0VSUl9QQV9DSEVDS1NVTV9NVVNU
X0JFX0lOQ0xVREVEICAgICAgICAgNzkNCiAgICAgICBLRENfRVJSX0RJR0VTVF9JTl9TSUdORURf
REFUQV9OT1RfQUNDRVBURUQgICA4MA0KDQogICBQS0lOSVQgdXNlcyB0aGUgZm9sbG93aW5nIHR5
cGVkIGRhdGEgdHlwZXMgZm9yIGVycm9yczoNCg0KICAgICAgIFREX1RSVVNURURfQ0VSVElGSUVS
UyAgICAgICAgICAgICAgICAgICAgICAgMTA0DQogICAgICAgVERfSU5WQUxJRF9DRVJUSUZJQ0FU
RVMgICAgICAgICAgICAgICAgICAgICAxMDUNCiAgICAgICBURF9ESF9QQVJBTUVURVJTICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDEwOQ0KDQogICBUaGUgQVNOLjEgbW9kdWxlIGZvciBhbGwg
c3RydWN0dXJlcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgKHBsdXMNCiAgIElNUE9SVCBzdGF0
ZW1lbnRzIGZvciBhbGwgaW1wb3J0ZWQgc3RydWN0dXJlcykgaXMgZ2l2ZW4gaW4NCiAgIEFwcGVu
ZGl4IEEuDQoNCiAgIEFsbCBzdHJ1Y3R1cmVzIGRlZmluZWQgaW4gb3IgaW1wb3J0ZWQgaW50byB0
aGlzIGRvY3VtZW50IE1VU1QgYmUNCiAgIGVuY29kZWQgdXNpbmcgRGlzdGluZ3Vpc2hlZCBFbmNv
ZGluZyBSdWxlcyAoREVSKSBbWDY4MF0gW1g2OTBdDQogICAodW5sZXNzIG90aGVyd2lzZSBub3Rl
ZCkuICBBbGwgZGF0YSBzdHJ1Y3R1cmVzIGNhcnJpZWQgaW4gT0NURVQNCiAgIFNUUklOR3MgbXVz
dCBiZSBlbmNvZGVkIGFjY29yZGluZyB0byB0aGUgcnVsZXMgc3BlY2lmaWVkIGluDQoNCg0KDQpa
aHUgJiBUdW5nICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAg
ICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5J
VCAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgIGNvcnJlc3BvbmRpbmcg
c3BlY2lmaWNhdGlvbnMuDQoNCiAgIEludGVyb3BlcmFiaWxpdHkgbm90ZTogU29tZSBpbXBsZW1l
bnRhdGlvbnMgbWF5IG5vdCBiZSBhYmxlIHRvIGRlY29kZQ0KICAgd3JhcHBlZCBDcnlwdG9ncmFw
aGljIE1lc3NhZ2UgU3ludGF4IChDTVMpIFtSRkMzODUyXSBvYmplY3RzIGVuY29kZWQNCiAgIHdp
dGggQkVSOyBzcGVjaWZpY2FsbHksIHRoZXkgbWF5IG5vdCBiZSBhYmxlIHRvIGRlY29kZSBpbmRl
ZmluaXRlDQogICBsZW5ndGggZW5jb2RpbmdzLiAgVG8gbWF4aW1pemUgaW50ZXJvcGVyYWJpbGl0
eSwgaW1wbGVtZW50ZXJzIFNIT1VMRA0KICAgZW5jb2RlIENNUyBvYmplY3RzIHVzZWQgaW4gUEtJ
TklUIHdpdGggREVSLg0KDQozLjEuMy4gIEtlcmJlcm9zIEVuY3J5cHRpb24gVHlwZXMgZm9yIENN
UyBBbGdvcml0aG0gSWRlbnRpZmllcnMNCg0KICAgRm9yIGhpc3RvcmljYWwgcmVhc29ucywgUEtJ
TklUIGRlZmluZXMgdGhlIGZvbGxvd2luZyBLZXJiZXJvcw0KICAgZW5jcnlwdGlvbiB0eXBlcyBb
UkZDNDEyMF0sIGZvciB1c2UgaW4gdGhlIGV0eXBlIGZpZWxkIG9mIHRoZSBBUy1SRVENCiAgIFtS
RkM0MTIwXSBtZXNzYWdlIHRvIGluZGljYXRlIGFjY2VwdGFuY2Ugb2YgdGhlIGNvcnJlc3BvbmRp
bmcNCiAgIGFsZ29yaXRobXMgKGluY2x1ZGluZyBwdWJsaWMgZW5jcnlwdGlvbiBhbGdvcml0aG1z
LCBidWxrIGVuY3J5cHRpb24NCiAgIGFnb3JpdGhtcywgYW5kIHNpZ25hdHVyZSBhbGdvcml0aG1z
KSB0aGF0IGNhbiB1c2VkIGJ5IENyeXB0b2dyYXBoaWMNCiAgIE1lc3NhZ2UgU3ludGF4IChDTVMp
IFtSRkMzODUyXSBtZXNzYWdlcyBpbiB0aGUgcmVwbHk6DQoNCiAgICAgICBpZC1kc2Etd2l0aC1z
aGExLUNtc09JRCAgICAgICAgICAgICAgICAgICAgICAgOQ0KICAgICAgICAgIC0tIEluZGljYXRl
cyB0aGF0IHRoZSBjbGllbnQgc3VwcG9ydHMgaWQtZHNhLXdpdGgtc2hhMQ0KICAgICAgICAgIC0t
IFtSRkMzMjc5XS4NCiAgICAgICBtZDVXaXRoUlNBRW5jcnlwdGlvbi1DbXNPSUQgICAgICAgICAg
ICAgICAgICAxMA0KICAgICAgICAgIC0tIEluZGljYXRlcyB0aGF0IHRoZSBjbGllbnQgc3VwcG9y
dHMgbWQ1V2l0aFJTQUVuY3J5cHRpb24NCiAgICAgICAgICAtLSBbUkZDMzI3OV0uDQogICAgICAg
c2hhLTFXaXRoUlNBRW5jcnlwdGlvbi1DbXNPSUQgICAgICAgICAgICAgICAgMTENCiAgICAgICAg
ICAtLSBJbmRpY2F0ZXMgdGhhdCB0aGUgY2xpZW50IHN1cHBvcnRzIHNoYS0xV2l0aFJTQUVuY3J5
cHRpb24NCiAgICAgICAgICAtLSBbUkZDMzI3OV0uDQogICAgICAgcmMyLWNiYy1FbnZPSUQgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgMTINCiAgICAgICAgICAtLSBJbmRpY2F0ZXMgdGhh
dCB0aGUgY2xpZW50IHN1cHBvcnRzIHJjMi1jYmMgW1JGQzMzNzBdLg0KICAgICAgIHJzYUVuY3J5
cHRpb24tRW52T0lEICAgICAgICAgICAgICAgICAgICAgICAgIDEzDQogICAgICAgICAgLS0gSW5k
aWNhdGVzIHRoYXQgdGhlIGNsaWVudCBzdXBwb3J0cyByc2FFbmNyeXB0aW9uDQogICAgICAgICAg
LS0gW1JGQzM0NDddIFtSRkMzMjc5XS4NCiAgICAgICBpZC1SU0FFUy1PQUVQLUVudk9JRCAgICAg
ICAgICAgICAgICAgICAgICAgICAxNA0KICAgICAgICAgIC0tIEluZGljYXRlcyB0aGF0IHRoZSBj
bGllbnQgc3VwcG9ydHMgaWQtUlNBRVMtT0FFUA0KICAgICAgICAgIC0tIFtSRkMzNDQ3XSBbUkZD
MzI3OV0uDQogICAgICAgZGVzLWVkZTMtY2JjLUVudk9JRCAgICAgICAgICAgICAgICAgICAgICAg
ICAgMTUNCiAgICAgICAgICAtLSBJbmRpY2F0ZXMgdGhhdCB0aGUgY2xpZW50IHN1cHBvcnRzIGRl
cy1lZGUzLWNiYyBbUkZDMzM3MF0uDQoNCiAgIFBlciBbUkZDNDEyMF0sIHRoZXNlIGVuY3J5cHRp
b24gdHlwZXMgYXJlIHNlbnQgaW4gdGhlIGRlY3JlYXNpbmcNCiAgIHByZWZlcmVuY2Ugb3JkZXIg
b2YgdGhlIGNsaWVudCwgYW5kIHRoZXJlIGlzIG5vIHNpZ25pZmljYW5jZSBpbiB0aGUNCiAgIHJl
bGF0aXZlIG9yZGVyIGJldHdlZW4gYW55IHR3byBvZiBkaWZmZXJlbnQgdHlwZXMgb2YgYWxnb3Jp
dGhtczoNCiAgIHB1YmxpYyBrZXkgZW5jcnlwdGlvbiBhbGdvcml0aG1zLCBidWxrIGVuY3J5cHRp
b24gYWxnb3JpdGhtcywgYW5kDQogICBzaWduYXR1cmUgYWxnb3JpdGhtcy4NCg0KICAgSW4gdGhl
IGV0eXBlIGZpZWxkIG9mIHRoZSBBUy1SRVEsIHRoZSBjbGllbnQgU0hPVUxEIHNlbmQgdGhlIGtl
cmJlcm9zDQogICBlbmNyeXB0aW9uIHR5cGUgY29ycmVzcG9uZGluZyB0byB0aGUgQ01TIGFsZ29y
aXRobSBpZGVuaXRpZmVyIGlmIHRoYXQNCiAgIGFsZ29yaXRobSBpZGVudGlmaWVyIGlzIGFzc2ln
bmVkIHdpdGggYSBrZXJiZXJvcyBlbmNyeXB0aW9uIHR5cGUgaW4NCiAgIHRoZSBlbmNyeXB0aW9u
IHR5cGUgbGlzdCBhYm92ZS4NCg0KDQoNCg0KWmh1ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBp
cmVzIEp1bHkgMjcsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1E
cmFmdCAgICAgICAgICAgICAgICAgICBQS0lOSVQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5
IDIwMDYNCg0KDQozLjIuICBQS0lOSVQgUHJlLWF1dGhlbnRpY2F0aW9uIFN5bnRheCBhbmQgVXNl
DQoNCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBzeW50YXggYW5kIHVzZSBvZiB0aGUgdmFy
aW91cyBwcmUtDQogICBhdXRoZW50aWNhdGlvbiBmaWVsZHMgZW1wbG95ZWQgYnkgUEtJTklULg0K
DQozLjIuMS4gIEdlbmVyYXRpb24gb2YgQ2xpZW50IFJlcXVlc3QNCg0KICAgVGhlIGluaXRpYWwg
YXV0aGVudGljYXRpb24gcmVxdWVzdCAoQVMtUkVRKSBpcyBzZW50IGFzIHBlciBbUkZDNDEyMF07
DQogICBpbiBhZGRpdGlvbiwgYSBwcmUtYXV0aGVudGljYXRpb24gZGF0YSBlbGVtZW50LCB3aG9z
ZSBwYWRhdGEtdHlwZSBpcw0KICAgUEFfUEtfQVNfUkVRIGFuZCB3aG9zZSBwYWRhdGEtdmFsdWUg
Y29udGFpbnMgdGhlIERFUiBlbmNvZGluZyBvZiB0aGUNCiAgIHR5cGUgUEEtUEstQVMtUkVRLCBp
cyBpbmNsdWRlZC4NCg0KICAgICAgIFBBLVBLLUFTLVJFUSA6Oj0gU0VRVUVOQ0Ugew0KICAgICAg
ICAgIHNpZ25lZEF1dGhQYWNrICAgICAgICAgIFswXSBJTVBMSUNJVCBPQ1RFVCBTVFJJTkcsDQog
ICAgICAgICAgICAgICAgICAgLS0gQ29udGFpbnMgYSBDTVMgdHlwZSBDb250ZW50SW5mbyBlbmNv
ZGVkDQogICAgICAgICAgICAgICAgICAgLS0gYWNjb3JkaW5nIHRvIFtSRkMzODUyXS4NCiAgICAg
ICAgICAgICAgICAgICAtLSBUaGUgY29udGVudFR5cGUgZmllbGQgb2YgdGhlIHR5cGUgQ29udGVu
dEluZm8NCiAgICAgICAgICAgICAgICAgICAtLSBpcyBpZC1zaWduZWREYXRhICgxLjIuODQwLjEx
MzU0OS4xLjcuMiksDQogICAgICAgICAgICAgICAgICAgLS0gYW5kIHRoZSBjb250ZW50IGZpZWxk
IGlzIGEgU2lnbmVkRGF0YS4NCiAgICAgICAgICAgICAgICAgICAtLSBUaGUgZUNvbnRlbnRUeXBl
IGZpZWxkIGZvciB0aGUgdHlwZSBTaWduZWREYXRhIGlzDQogICAgICAgICAgICAgICAgICAgLS0g
aWQtcGtpbml0LWF1dGhEYXRhICgxLjMuNi4xLjUuMi4zLjEpLCBhbmQgdGhlDQogICAgICAgICAg
ICAgICAgICAgLS0gZUNvbnRlbnQgZmllbGQgY29udGFpbnMgdGhlIERFUiBlbmNvZGluZyBvZiB0
aGUNCiAgICAgICAgICAgICAgICAgICAtLSB0eXBlIEF1dGhQYWNrLg0KICAgICAgICAgICAgICAg
ICAgIC0tIEF1dGhQYWNrIGlzIGRlZmluZWQgYmVsb3cuDQogICAgICAgICAgdHJ1c3RlZENlcnRp
ZmllcnMgICAgICAgWzFdIFNFUVVFTkNFIE9GDQogICAgICAgICAgICAgICAgICAgICAgRXh0ZXJu
YWxQcmluY2lwYWxJZGVudGlmaWVyIE9QVElPTkFMLA0KICAgICAgICAgICAgICAgICAgIC0tIENv
bnRhaW5zIGEgbGlzdCBvZiBDQXMsIHRydXN0ZWQgYnkgdGhlIGNsaWVudCwNCiAgICAgICAgICAg
ICAgICAgICAtLSB0aGF0IGNhbiBiZSB1c2VkIHRvIGNlcnRpZnkgdGhlIEtEQy4NCiAgICAgICAg
ICAgICAgICAgICAtLSBFYWNoIEV4dGVybmFsUHJpbmNpcGFsSWRlbnRpZmllciBpZGVudGlmaWVz
IGEgQ0ENCiAgICAgICAgICAgICAgICAgICAtLSBvciBhIENBIGNlcnRpZmljYXRlICh0aGVyZWJ5
IGl0cyBwdWJsaWMga2V5KS4NCiAgICAgICAgICAgICAgICAgICAtLSBUaGUgaW5mb3JtYXRpb24g
Y29udGFpbmVkIGluIHRoZQ0KICAgICAgICAgICAgICAgICAgIC0tIHRydXN0ZWRDZXJ0aWZpZXJz
IFNIT1VMRCBiZSB1c2VkIGJ5IHRoZSBLREMgYXMNCiAgICAgICAgICAgICAgICAgICAtLSBoaW50
cyB0byBndWlkZSBpdHMgc2VsZWN0aW9uIG9mIGFuIGFwcHJvcHJpYXRlDQogICAgICAgICAgICAg
ICAgICAgLS0gY2VydGlmaWNhdGUgY2hhaW4gdG8gcmV0dXJuIHRvIHRoZSBjbGllbnQuDQogICAg
ICAgICAga2RjUGtJZCAgICAgICAgICAgICAgICAgWzJdIElNUExJQ0lUIE9DVEVUIFNUUklORw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPUFRJT05BTCwNCiAgICAgICAg
ICAgICAgICAgICAtLSBDb250YWlucyBhIENNUyB0eXBlIFNpZ25lcklkZW50aWZpZXIgZW5jb2Rl
ZA0KICAgICAgICAgICAgICAgICAgIC0tIGFjY29yZGluZyB0byBbUkZDMzg1Ml0uDQogICAgICAg
ICAgICAgICAgICAgLS0gSWRlbnRpZmllcywgaWYgcHJlc2VudCwgYSBwYXJ0aWN1bGFyIEtEQw0K
ICAgICAgICAgICAgICAgICAgIC0tIHB1YmxpYyBrZXkgdGhhdCB0aGUgY2xpZW50IGFscmVhZHkg
aGFzLg0KICAgICAgICAgIC4uLg0KICAgICAgIH0NCg0KICAgICAgIERITm9uY2UgOjo9IE9DVEVU
IFNUUklORw0KDQogICAgICAgRXh0ZXJuYWxQcmluY2lwYWxJZGVudGlmaWVyIDo6PSBTRVFVRU5D
RSB7DQogICAgICAgICAgc3ViamVjdE5hbWUgICAgICAgICAgICBbMF0gSU1QTElDSVQgT0NURVQg
U1RSSU5HIE9QVElPTkFMLA0KICAgICAgICAgICAgICAgICAgIC0tIENvbnRhaW5zIGEgUEtJWCB0
eXBlIE5hbWUgZW5jb2RlZCBhY2NvcmRpbmcgdG8NCg0KDQoNClpodSAmIFR1bmcgICAgICAgICAg
ICAgICAgRXhwaXJlcyBKdWx5IDI3LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0K
SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgUEtJTklUICAgICAgICAgICAgICAgICAg
ICAgSmFudWFyeSAyMDA2DQoNCg0KICAgICAgICAgICAgICAgICAgIC0tIFtSRkMzMjgwXS4NCiAg
ICAgICAgICAgICAgICAgICAtLSBJZGVudGlmaWVzIHRoZSBjZXJ0aWZpY2F0ZSBzdWJqZWN0IGJ5
IHRoZQ0KICAgICAgICAgICAgICAgICAgIC0tIGRpc3Rpbmd1aXNoZWQgc3ViamVjdCBuYW1lLg0K
ICAgICAgICAgICAgICAgICAgIC0tIFJFUVVJUkVEIHdoZW4gdGhlcmUgaXMgYSBkaXN0aW5ndWlz
aGVkIHN1YmplY3QNCiAgICAgICAgICAgICAgICAgICAtLSBuYW1lIHByZXNlbnQgaW4gdGhlIGNl
cnRpZmljYXRlLg0KICAgICAgICAgaXNzdWVyQW5kU2VyaWFsTnVtYmVyICAgWzFdIElNUExJQ0lU
IE9DVEVUIFNUUklORyBPUFRJT05BTCwNCiAgICAgICAgICAgICAgICAgICAtLSBDb250YWlucyBh
IENNUyB0eXBlIElzc3VlckFuZFNlcmlhbE51bWJlciBlbmNvZGVkDQogICAgICAgICAgICAgICAg
ICAgLS0gYWNjb3JkaW5nIHRvIFtSRkMzODUyXS4NCiAgICAgICAgICAgICAgICAgICAtLSBJZGVu
dGlmaWVzIGEgY2VydGlmaWNhdGUgb2YgdGhlIHN1YmplY3QuDQogICAgICAgICAgICAgICAgICAg
LS0gUkVRVUlSRUQgZm9yIFRELUlOVkFMSUQtQ0VSVElGSUNBVEVTIGFuZA0KICAgICAgICAgICAg
ICAgICAgIC0tIFRELVRSVVNURUQtQ0VSVElGSUVSUy4NCiAgICAgICAgIHN1YmplY3RLZXlJZGVu
dGlmaWVyICAgIFsyXSBJTVBMSUNJVCBPQ1RFVCBTVFJJTkcgT1BUSU9OQUwsDQogICAgICAgICAg
ICAgICAgICAgLS0gSWRlbnRpZmllcyB0aGUgc3ViamVjdCdzIHB1YmxpYyBrZXkgYnkgYSBrZXkN
CiAgICAgICAgICAgICAgICAgICAtLSBpZGVudGlmaWVyLiAgV2hlbiBhbiBYLjUwOSBjZXJ0aWZp
Y2F0ZSBpcw0KICAgICAgICAgICAgICAgICAgIC0tIHJlZmVyZW5jZWQsIHRoaXMga2V5IGlkZW50
aWZpZXIgbWF0Y2hlcyB0aGUgWC41MDkNCiAgICAgICAgICAgICAgICAgICAtLSBzdWJqZWN0S2V5
SWRlbnRpZmllciBleHRlbnNpb24gdmFsdWUuICBXaGVuIG90aGVyDQogICAgICAgICAgICAgICAg
ICAgLS0gY2VydGlmaWNhdGUgZm9ybWF0cyBhcmUgcmVmZXJlbmNlZCwgdGhlIGRvY3VtZW50cw0K
ICAgICAgICAgICAgICAgICAgIC0tIHRoYXQgc3BlY2lmeSB0aGUgY2VydGlmaWNhdGUgZm9ybWF0
IGFuZCB0aGVpciB1c2UNCiAgICAgICAgICAgICAgICAgICAtLSB3aXRoIHRoZSBDTVMgbXVzdCBp
bmNsdWRlIGRldGFpbHMgb24gbWF0Y2hpbmcgdGhlDQogICAgICAgICAgICAgICAgICAgLS0ga2V5
IGlkZW50aWZpZXIgdG8gdGhlIGFwcHJvcHJpYXRlIGNlcnRpZmljYXRlDQogICAgICAgICAgICAg
ICAgICAgLS0gZmllbGQuDQogICAgICAgICAgICAgICAgICAgLS0gUkVDT01NRU5ERUQgZm9yIFRE
LVRSVVNURUQtQ0VSVElGSUVSUy4NCiAgICAgICAgICAuLi4NCiAgICAgICB9DQoNCiAgICAgICBB
dXRoUGFjayA6Oj0gU0VRVUVOQ0Ugew0KICAgICAgICAgIHBrQXV0aGVudGljYXRvciAgICAgICAg
IFswXSBQS0F1dGhlbnRpY2F0b3IsDQogICAgICAgICAgY2xpZW50UHVibGljVmFsdWUgICAgICAg
WzFdIFN1YmplY3RQdWJsaWNLZXlJbmZvIE9QVElPTkFMLA0KICAgICAgICAgICAgICAgICAgIC0t
IFR5cGUgU3ViamVjdFB1YmxpY0tleUluZm8gaXMgZGVmaW5lZCBpbg0KICAgICAgICAgICAgICAg
ICAgIC0tIFtSRkMzMjgwXS4NCiAgICAgICAgICAgICAgICAgICAtLSBTcGVjaWZpZXMgRGlmZmll
LUhlbGxtYW4gZG9tYWluIHBhcmFtZXRlcnMNCiAgICAgICAgICAgICAgICAgICAtLSBhbmQgdGhl
IGNsaWVudCdzIHB1YmxpYyBrZXkgdmFsdWUgW0lFRUUxMzYzXS4NCiAgICAgICAgICAgICAgICAg
ICAtLSBUaGUgREggcHVibGljIGtleSB2YWx1ZSBpcyBlbmNvZGVkIGFzIGEgQklUDQogICAgICAg
ICAgICAgICAgICAgLS0gU1RSSU5HIGFjY29yZGluZyB0byBbUkZDMzI3OV0uDQogICAgICAgICAg
ICAgICAgICAgLS0gVGhpcyBmaWVsZCBpcyBwcmVzZW50IG9ubHkgaWYgdGhlIGNsaWVudCB3aXNo
ZXMNCiAgICAgICAgICAgICAgICAgICAtLSB0byB1c2UgdGhlIERpZmZpZS1IZWxsbWFuIGtleSBh
Z3JlZW1lbnQgbWV0aG9kLg0KICAgICAgICAgIHN1cHBvcnRlZENNU1R5cGVzICAgICAgIFsyXSBT
RVFVRU5DRSBPRiBBbGdvcml0aG1JZGVudGlmaWVyDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIE9QVElPTkFMLA0KICAgICAgICAgICAgICAgICAgIC0tIFR5cGUgQWxnb3Jp
dGhtSWRlbnRpZmllciBpcyBkZWZpbmVkIGluDQogICAgICAgICAgICAgICAgICAgLS0gW1JGQzMy
ODBdLg0KICAgICAgICAgICAgICAgICAgIC0tIExpc3Qgb2YgQ01TIGVuY3J5cHRpb24sIGJ1bGsg
ZW5jcnlwdGlvbiwNCiAgICAgICAgICAgICAgICAgICAtLSBvciBzaWduYXR1cmUgYWxnb3JpdGht
IGlkZW50aWZpZXJzIHN1cHBvcnRlZCBieQ0KICAgICAgICAgICAgICAgICAgIC0tIHRoZSBjbGll
bnQgaW4gb3JkZXIgb2YgKGRlY3JlYXNpbmcpIHByZWZlcmVuY2UuDQogICAgICAgICAgY2xpZW50
REhOb25jZSAgICAgICAgICAgWzNdIERITm9uY2UgT1BUSU9OQUwsDQogICAgICAgICAgICAgICAg
ICAgLS0gUHJlc2VudCBvbmx5IGlmIHRoZSBjbGllbnQgaW5kaWNhdGVzIHRoYXQgaXQNCiAgICAg
ICAgICAgICAgICAgICAtLSB3aXNoZXMgdG8gcmV1c2UgREgga2V5cyBvciB0byBhbGxvdyB0aGUg
S0RDIHRvDQogICAgICAgICAgICAgICAgICAgLS0gZG8gc28gKHNlZSBTZWN0aW9uIDMuMi4zLjEp
Lg0KICAgICAgICAgIC4uLg0KDQoNCg0KWmh1ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBpcmVz
IEp1bHkgMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFm
dCAgICAgICAgICAgICAgICAgICBQS0lOSVQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIw
MDYNCg0KDQogICAgICAgfQ0KDQogICAgICAgUEtBdXRoZW50aWNhdG9yIDo6PSBTRVFVRU5DRSB7
DQogICAgICAgICAgY3VzZWMgICAgICAgICAgICAgICAgICAgWzBdIElOVEVHRVIgKDAuLjk5OTk5
OSksDQogICAgICAgICAgY3RpbWUgICAgICAgICAgICAgICAgICAgWzFdIEtlcmJlcm9zVGltZSwN
CiAgICAgICAgICAgICAgICAgICAtLSBjdXNlYyBhbmQgY3RpbWUgYXJlIHVzZWQgYXMgaW4gW1JG
QzQxMjBdLCBmb3INCiAgICAgICAgICAgICAgICAgICAtLSByZXBsYXkgcHJldmVudGlvbi4NCiAg
ICAgICAgICBub25jZSAgICAgICAgICAgICAgICAgICBbMl0gSU5URUdFUiAoMC4uNDI5NDk2NzI5
NSksDQogICAgICAgICAgICAgICAgICAgLS0gQ2hvc2VuIHJhbmRvbWx5OyAgVGhpcyBub25jZSBk
b2VzIG5vdCBuZWVkIHRvDQogICAgICAgICAgICAgICAgICAgLS0gbWF0Y2ggd2l0aCB0aGUgbm9u
Y2UgaW4gdGhlIEtEQy1SRVEtQk9EWS4NCiAgICAgICAgICBwYUNoZWNrc3VtICAgICAgICAgICAg
ICBbM10gT0NURVQgU1RSSU5HIE9QVElPTkFMLA0KICAgICAgICAgICAgICAgICAgIC0tIE1VU1Qg
YmUgcHJlc2VudC4NCiAgICAgICAgICAgICAgICAgICAtLSBDb250YWlucyB0aGUgU0hBMSBjaGVj
a3N1bSwgcGVyZm9ybWVkIG92ZXINCiAgICAgICAgICAgICAgICAgICAtLSBLREMtUkVRLUJPRFku
DQogICAgICAgICAgLi4uDQogICAgICAgfQ0KDQogICBUaGUgQ29udGVudEluZm8gW1JGQzM4NTJd
IHN0cnVjdHVyZSBjb250YWluZWQgaW4gdGhlIHNpZ25lZEF1dGhQYWNrDQogICBmaWVsZCBvZiB0
aGUgdHlwZSBQQS1QSy1BUy1SRVEgaXMgZW5jb2RlZCBhY2NvcmRpbmcgdG8gW1JGQzM4NTJdIGFu
ZA0KICAgaXMgZmlsbGVkIG91dCBhcyBmb2xsb3dzOg0KDQogICAxLiAgVGhlIGNvbnRlbnRUeXBl
IGZpZWxkIG9mIHRoZSB0eXBlIENvbnRlbnRJbmZvIGlzIGlkLXNpZ25lZERhdGENCiAgICAgICAo
YXMgZGVmaW5lZCBpbiBbUkZDMzg1Ml0pLCBhbmQgdGhlIGNvbnRlbnQgZmllbGQgaXMgYSBTaWdu
ZWREYXRhDQogICAgICAgKGFzIGRlZmluZWQgaW4gW1JGQzM4NTJdKS4NCg0KICAgMi4gIFRoZSBl
Q29udGVudFR5cGUgZmllbGQgZm9yIHRoZSB0eXBlIFNpZ25lZERhdGEgaXMgaWQtcGtpbml0LQ0K
ICAgICAgIGF1dGhEYXRhOiB7IGlzbygxKSBvcmcoMykgZG9kKDYpIGludGVybmV0KDEpIHNlY3Vy
aXR5KDUpDQogICAgICAga2VyYmVyb3N2NSgyKSBwa2luaXQoMykgYXV0aERhdGEoMSkgfS4gIE5v
dGVzIHRvIENNUw0KICAgICAgIGltcGxlbWVudGVyczogdGhlIHNpZ25lZCBhdHRyaWJ1dGUgY29u
dGVudC10eXBlIE1VU1QgYmUgcHJlc2VudA0KICAgICAgIGluIHRoaXMgU2lnbmVkRGF0YSBpbnN0
YW5jZSBhbmQgaXRzIHZhbHVlIGlzIGlkLXBraW5pdC1hdXRoRGF0YQ0KICAgICAgIGFjY29yZGlu
ZyB0byBbUkZDMzg1Ml0uDQoNCiAgIDMuICBUaGUgZUNvbnRlbnQgZmllbGQgZm9yIHRoZSB0eXBl
IFNpZ25lZERhdGEgY29udGFpbnMgdGhlIERFUg0KICAgICAgIGVuY29kaW5nIG9mIHRoZSB0eXBl
IEF1dGhQYWNrLg0KDQogICA0LiAgVGhlIHNpZ25lckluZm9zIGZpZWxkIG9mIHRoZSB0eXBlIFNp
Z25lZERhdGEgY29udGFpbnMgYSBzaW5nbGUNCiAgICAgICBzaWduZXJJbmZvLCB3aGljaCBjb250
YWlucyB0aGUgc2lnbmF0dXJlIG92ZXIgdGhlIHR5cGUgQXV0aFBhY2suDQoNCiAgIDUuICBUaGUg
QXV0aFBhY2sgc3RydWN0dXJlIGNvbnRhaW5zIGEgUEtBdXRoZW50aWNhdG9yLCB0aGUgY2xpZW50
DQogICAgICAgcHVibGljIGtleSBpbmZvcm1hdGlvbiwgdGhlIENNUyBlbmNyeXB0aW9uIHR5cGVz
IHN1cHBvcnRlZCBieSB0aGUNCiAgICAgICBjbGllbnQgYW5kIGEgREhOb25jZS4gIFRoZSBwa0F1
dGhlbnRpY2F0b3IgZmllbGQgY2VydGlmaWVzIHRvIHRoZQ0KICAgICAgIEtEQyB0aGF0IHRoZSBj
bGllbnQgaGFzIHJlY2VudCBrbm93bGVkZ2Ugb2YgdGhlIHNpZ25pbmcga2V5IHRoYXQNCiAgICAg
ICBhdXRoZW50aWNhdGVzIHRoZSBjbGllbnQuICBUaGUgY2xpZW50UHVibGljVmFsdWUgZmllbGQg
c3BlY2lmaWVzDQogICAgICAgRGlmZmllLUhlbGxtYW4gZG9tYWluIHBhcmFtZXRlcnMgYW5kIHRo
ZSBjbGllbnQncyBwdWJsaWMga2V5DQogICAgICAgdmFsdWUuICBUaGUgREggcHVibGljIGtleSB2
YWx1ZSBpcyBlbmNvZGVkIGFzIGEgQklUIFNUUklORw0KICAgICAgIGFjY29yZGluZyB0byBbUkZD
MzI3OV0uICBUaGUgY2xpZW50UHVibGljVmFsdWUgZmllbGQgaXMgcHJlc2VudA0KICAgICAgIG9u
bHkgaWYgdGhlIGNsaWVudCB3aXNoZXMgdG8gdXNlIHRoZSBEaWZmaWUtSGVsbG1hbiBrZXkgYWdy
ZWVtZW50DQogICAgICAgbWV0aG9kLiAgVGhlIHN1cHBvcnRlZENNU1R5cGVzIGZpZWxkIHNwZWNp
ZmllcyB0aGUgbGlzdCBvZiBDTVMNCg0KDQoNClpodSAmIFR1bmcgICAgICAgICAgICAgICAgRXhw
aXJlcyBKdWx5IDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQt
RHJhZnQgICAgICAgICAgICAgICAgICAgUEtJTklUICAgICAgICAgICAgICAgICAgICAgSmFudWFy
eSAyMDA2DQoNCg0KICAgICAgIGFsZ29yaXRobSBpZGVudGlmaWVycyAoZm9yIGVuY3J5cHRpb24g
YWxnb3JpdGhtcywgYnVsayBlbmNyeXB0aW9uDQogICAgICAgYWxnb3JpdGhtcyBhbmQgc2lnbmF0
dXJlIGFsZ29yaXRobXMpIHRoYXQgYXJlIHN1cHBvcnRlZCBieSB0aGUNCiAgICAgICBjbGllbnQg
aW4gb3JkZXIgb2YgKGRlY3JlYXNpbmcpIHByZWZlcmVuY2UsIGFuZCBjYW4gYmUgdXNlZCB0bw0K
ICAgICAgIGlkZW50aWZ5IGEgc2lnbmF0dXJlIGFnb3JpdGhtIG9yIGEgcHVibGljIGtleSBlbmNy
eXB0aW9uDQogICAgICAgYWxnb3JpdGhtIGluIHRoZSBrZXlFbmNyeXB0aW9uQWxnb3JpdGhtIGZp
ZWxkIG9mIHRoZSB0eXBlDQogICAgICAgS2V5VHJhbnNSZWNpcGllbnRJbmZvIG9yIGEgYnVsayBl
bmNyeXB0aW9uIGFsZ29yaXRobSBpbiB0aGUNCiAgICAgICBjb250ZW50RW5jcnlwdGlvbkFsZ29y
aXRobSBmaWVsZCBvZiB0aGUgdHlwZSBFbmNyeXB0ZWRDb250ZW50SW5mbw0KICAgICAgIFtSRkMz
ODUyXSB3aGVuIGVuY3J5cHRpbmcgdGhlIEFTIHJlcGx5IGtleSBhcyBkZXNjcmliZWQgaW4NCiAg
ICAgICBTZWN0aW9uIDMuMi4zLjIuICBIb3dldmVyLCB0aGVyZSBpcyBubyBzaWduaWZpY2FuY2Ug
aW4gdGhlDQogICAgICAgcmVsYXRpdmUgb3JkZXIgYmV0d2VlbiBhbnkgdHdvIG9mIGRpZmZlcmVu
dCB0eXBlcyBvZiBhbGdvcml0aG1zOg0KICAgICAgIHB1YmxpYyBrZXkgZW5jcnlwdGlvbiBhbGdv
cml0aG1zLCBidWxrIGVuY3J5cHRpb24gYWxnb3JpdGhtcyBhbmQNCiAgICAgICBzaWduYXR1cmUg
YWxnb3JpdGhtcy4gIFRoZSBjbGllbnRESE5vbmNlIGZpZWxkIGlzIGRlc2NyaWJlZCBsYXRlcg0K
ICAgICAgIGluIHRoaXMgc2VjdGlvbi4NCg0KICAgNi4gIFRoZSBjdGltZSBmaWVsZCBpbiB0aGUg
UEtBdXRoZW50aWNhdG9yIHN0cnVjdHVyZSBjb250YWlucyB0aGUNCiAgICAgICBjdXJyZW50IHRp
bWUgb24gdGhlIGNsaWVudCdzIGhvc3QsIGFuZCB0aGUgY3VzZWMgZmllbGQgY29udGFpbnMNCiAg
ICAgICB0aGUgbWljcm9zZWNvbmQgcGFydCBvZiB0aGUgY2xpZW50J3MgdGltZXN0YW1wLiAgVGhl
IGN0aW1lIGFuZA0KICAgICAgIGN1c2VjIGZpZWxkcyBhcmUgdXNlZCB0b2dldGhlciB0byBzcGVj
aWZ5IGEgcmVhc29uYWJseSBhY2N1cmF0ZQ0KICAgICAgIHRpbWVzdGFtcCBbUkZDNDEyMF0uICBU
aGUgbm9uY2UgZmllbGQgaXMgY2hvc2VuIHJhbmRvbWx5LiAgVGhlDQogICAgICAgcGFDaGVja3N1
bSBmaWVsZCBNVVNUIGJlIHByZXNlbnQgYW5kIGl0IGNvbnRhaW5zIGEgU0hBMSBjaGVja3N1bQ0K
ICAgICAgIHRoYXQgaXMgcGVyZm9ybWVkIG92ZXIgdGhlIEtEQy1SRVEtQk9EWSBbUkZDNDEyMF0u
ICBJbiBvcmRlciB0bw0KICAgICAgIGVhc2UgZnV0dXJlIG1pZ3JhdGlvbiBmcm9tIHRoZSB1c2Ug
b2YgU0hBMSwgdGhlIHBhQ2hlY2tzdW0gZmllbGQNCiAgICAgICBpcyBtYWRlIG9wdGlvbmFsIHN5
bnRhY3RpY2FsbHk6IHdoZW4gdGhlIHJlcXVlc3QgaXMgZXh0ZW5kZWQgdG8NCiAgICAgICBuZWdv
dGlhdGUgaGFzaCBhbGdvcml0aG1zLCB0aGUgbmV3IGNsaWVudCB3aXNoaW5nIG5vdCB0byB1c2Ug
U0hBMQ0KICAgICAgIHdpbGwgc2VuZCB0aGUgcmVxdWVzdCBpbiB0aGUgZXh0ZW5kZWQgbWVzc2Fn
ZSBzeW50YXggd2l0aG91dCB0aGUNCiAgICAgICBwYUNoZWNrc3VtIGZpZWxkLiAgVGhlIEtEQyBj
b25mb3JtaW5nIHRvIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUDQogICAgICAgcmV0dXJuIGEgS1JC
LUVSUk9SIFtSRkM0MTIwXSBtZXNzYWdlIHdpdGggdGhlIGNvZGUNCiAgICAgICBLRENfRVJSX1BB
X0NIRUNLU1VNX01VU1RfQkVfSU5DTFVERUQgKHNlZSBTZWN0aW9uIDMuMi4zKS4gIFRoYXQNCiAg
ICAgICB3aWxsIGFsbG93IGEgbmV3IGNsaWVudCB0byByZXRyeSB3aXRoIFNIQTEgaWYgYWxsb3dl
ZCBieSB0aGUNCiAgICAgICBsb2NhbCBwb2xpY3kuDQoNCiAgIDcuICBUaGUgY2VydGlmaWNhdGVz
IGZpZWxkIG9mIHRoZSB0eXBlIFNpZ25lZERhdGEgY29udGFpbnMNCiAgICAgICBjZXJ0aWZpY2F0
ZXMgaW50ZW5kZWQgdG8gZmFjaWxpdGF0ZSBjZXJ0aWZpY2F0aW9uIHBhdGgNCiAgICAgICBjb25z
dHJ1Y3Rpb24sIHNvIHRoYXQgdGhlIEtEQyBjYW4gdmVyaWZ5IHRoZSBzaWduYXR1cmUgb3ZlciB0
aGUNCiAgICAgICB0eXBlIEF1dGhQYWNrLiAgRm9yIHBhdGggdmFsaWRhdGlvbiwgdGhlc2UgY2Vy
dGlmaWNhdGVzIFNIT1VMRCBiZQ0KICAgICAgIHN1ZmZpY2llbnQgdG8gY29uc3RydWN0IGF0IGxl
YXN0IG9uZSBjZXJ0aWZpY2F0aW9uIHBhdGggZnJvbSB0aGUNCiAgICAgICBjbGllbnQgY2VydGlm
aWNhdGUgdG8gb25lIHRydXN0IGFuY2hvciBhY2NlcHRhYmxlIGJ5IHRoZSBLREMNCiAgICAgICBb
UkZDNDE1OF0uICBUaGUgY2xpZW50IE1VU1QgYmUgY2FwYWJsZSBvZiBpbmNsdWRpbmcgc3VjaCBh
IHNldCBvZg0KICAgICAgIGNlcnRpZmljYXRlcyBpZiBjb25maWd1cmVkIHRvIGRvIHNvLiAgVGhl
IGNlcnRpZmljYXRlcyBmaWVsZCBNVVNUDQogICAgICAgTk9UIGNvbnRhaW4gInJvb3QiIENBIGNl
cnRpZmljYXRlcy4NCg0KICAgOC4gIFRoZSBjbGllbnQncyBEaWZmaWUtSGVsbG1hbiBwdWJsaWMg
dmFsdWUgKGNsaWVudFB1YmxpY1ZhbHVlKSBpcw0KICAgICAgIGluY2x1ZGVkIGlmIGFuZCBvbmx5
IGlmIHRoZSBjbGllbnQgd2lzaGVzIHRvIHVzZSB0aGUgRGlmZmllLQ0KICAgICAgIEhlbGxtYW4g
a2V5IGFncmVlbWVudCBtZXRob2QuICBUaGUgRGlmZmllLUhlbGxtYW4gZG9tYWluDQogICAgICAg
cGFyYW1ldGVycyBbSUVFRTEzNjNdIGZvciB0aGUgY2xpZW50J3MgcHVibGljIGtleSBhcmUgc3Bl
Y2lmaWVkDQogICAgICAgaW4gdGhlIGFsZ29yaXRobSBmaWVsZCBvZiB0aGUgdHlwZSBTdWJqZWN0
UHVibGljS2V5SW5mbyBbUkZDMzI3OV0NCiAgICAgICBhbmQgdGhlIGNsaWVudCdzIERpZmZpZS1I
ZWxsbWFuIHB1YmxpYyBrZXkgdmFsdWUgaXMgbWFwcGVkIHRvIGENCiAgICAgICBzdWJqZWN0UHVi
bGljS2V5IChhIEJJVCBTVFJJTkcpIGFjY29yZGluZyB0byBbUkZDMzI3OV0uICBXaGVuDQoNCg0K
DQpaaHUgJiBUdW5nICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyNywgMjAwNiAgICAgICAg
ICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFBL
SU5JVCAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgICAgICB1c2luZyB0
aGUgRGlmZmllLUhlbGxtYW4ga2V5IGFncmVlbWVudCBtZXRob2QsIGltcGxlbWVudGF0aW9ucw0K
ICAgICAgIE1VU1Qgc3VwcG9ydCBPYWtsZXkgMTAyNC1iaXQgTW9kdWxhciBFeHBvbmVudGlhbCAo
TU9EUCkgd2VsbC0NCiAgICAgICBrbm93biBncm91cCAyIFtSRkMyNDEyXSBhbmQgT2FrbGV5IDIw
NDgtYml0IE1PRFAgd2VsbC1rbm93biBncm91cA0KICAgICAgIDE0IFtSRkMzNTI2XSwgYW5kIFNI
T1VMRCBzdXBwb3J0IE9ha2xleSA0MDk2LWJpdCBNT0RQIHdlbGwta25vd24NCiAgICAgICBncm91
cCAxNiBbUkZDMzUyNl0uDQoNCiAgICAgICBUaGUgRGlmZmllLUhlbGxtYW4gZmllbGQgc2l6ZSBz
aG91bGQgYmUgY2hvc2VuIHNvIGFzIHRvIHByb3ZpZGUNCiAgICAgICBzdWZmaWNpZW50IGNyeXB0
b2dyYXBoaWMgc2VjdXJpdHkgW1JGQzM3NjZdLg0KDQogICAgICAgV2hlbiBNT0RQIERpZmZpZS1I
ZWxsbWFuIGlzIHVzZWQsIHRoZSBleHBvbmVudHMgc2hvdWxkIGhhdmUgYXQNCiAgICAgICBsZWFz
dCB0d2ljZSBhcyBtYW55IGJpdHMgYXMgdGhlIHN5bW1ldHJpYyBrZXlzIHRoYXQgd2lsbCBiZQ0K
ICAgICAgIGRlcml2ZWQgZnJvbSB0aGVtIFtPREw5OV0uDQoNCiAgIDkuICBUaGUgY2xpZW50IG1h
eSB3aXNoIHRvIHJldXNlIERIIGtleXMgb3IgdG8gYWxsb3cgdGhlIEtEQyB0byBkbyBzbw0KICAg
ICAgIChzZWUgU2VjdGlvbiAzLjIuMy4xKS4gIElmIHNvLCB0aGVuIHRoZSBjbGllbnQgaW5jbHVk
ZXMgdGhlDQogICAgICAgY2xpZW50REhOb25jZSBmaWVsZC4gIFRoaXMgbm9uY2Ugc3RyaW5nIE1V
U1QgYmUgYXMgbG9uZyBhcyB0aGUNCiAgICAgICBsb25nZXN0IGtleSBsZW5ndGggb2YgdGhlIHN5
bW1ldHJpYyBrZXkgdHlwZXMgdGhhdCB0aGUgY2xpZW50DQogICAgICAgc3VwcG9ydHMuICBUaGlz
IG5vbmNlIE1VU1QgYmUgY2hvc2VuIHJhbmRvbWx5Lg0KDQogICBUaGUgRXh0ZXJuYWxQcmluY2lw
YWxJZGVudGlmaWVyIHN0cnVjdHVyZSBpcyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgdG8NCiAgIGlk
ZW50aWZ5IHRoZSBzdWJqZWN0J3MgcHVibGljIGtleSB0aGVyZWJ5IHRoZSBzdWJqZWN0IHByaW5j
aXBhbC4NCiAgIFRoaXMgc3RydWN0dXJlIGlzIGZpbGxlZCBvdXQgYXMgZm9sbG93czoNCg0KICAg
MS4gIFRoZSBzdWJqZWN0TmFtZSBmaWVsZCBjb250YWlucyBhIFBLSVggdHlwZSBOYW1lIGVuY29k
ZWQgYWNjb3JkaW5nDQogICAgICAgdG8gW1JGQzMyODBdLiAgVGhpcyBmaWVsZCBpZGVudGlmaWVz
IHRoZSBjZXJ0aWZpY2F0ZSBzdWJqZWN0IGJ5DQogICAgICAgdGhlIGRpc3Rpbmd1aXNoZWQgc3Vi
amVjdCBuYW1lLiAgVGhpcyBmaWVsZCBpcyBSRVFVSVJFRCB3aGVuDQogICAgICAgdGhlcmUgaXMg
YSBkaXN0aW5ndWlzaGVkIHN1YmplY3QgbmFtZSBwcmVzZW50IGluIHRoZSBjZXJ0aWZpY2F0ZQ0K
ICAgICAgIGJlaW5nIHVzZWQuDQoNCiAgIDIuICBUaGUgaXNzdWVyQW5kU2VyaWFsTnVtYmVyIGZp
ZWxkIGNvbnRhaW5zIGEgQ01TIHR5cGUNCiAgICAgICBJc3N1ZXJBbmRTZXJpYWxOdW1iZXIgZW5j
b2RlZCBhY2NvcmRpbmcgdG8gW1JGQzM4NTJdLiAgVGhpcyBmaWVsZA0KICAgICAgIGlkZW50aWZp
ZXMgYSBjZXJ0aWZpY2F0ZSBvZiB0aGUgc3ViamVjdC4gIFRoaXMgZmllbGQgaXMgUkVRVUlSRUQN
CiAgICAgICBmb3IgVEQtSU5WQUxJRC1DRVJUSUZJQ0FURVMgYW5kIFRELVRSVVNURUQtQ0VSVElG
SUVSUyAoYm90aA0KICAgICAgIHN0cnVjdHVyZXMgYXJlIGRlZmluZWQgaW4gU2VjdGlvbiAzLjIu
MikuDQoNCiAgIDMuICBUaGUgc3ViamVjdEtleUlkZW50aWZpZXIgW1JGQzM4NTJdIGZpZWxkIGlk
ZW50aWZpZXMgdGhlIHN1YmplY3Qncw0KICAgICAgIHB1YmxpYyBrZXkgYnkgYSBrZXkgaWRlbnRp
Zmllci4gIFdoZW4gYW4gWC41MDkgY2VydGlmaWNhdGUgaXMNCiAgICAgICByZWZlcmVuY2VkLCB0
aGlzIGtleSBpZGVudGlmaWVyIG1hdGNoZXMgdGhlIFguNTA5DQogICAgICAgc3ViamVjdEtleUlk
ZW50aWZpZXIgZXh0ZW5zaW9uIHZhbHVlLiAgV2hlbiBvdGhlciBjZXJ0aWZpY2F0ZQ0KICAgICAg
IGZvcm1hdHMgYXJlIHJlZmVyZW5jZWQsIHRoZSBkb2N1bWVudHMgdGhhdCBzcGVjaWZ5IHRoZQ0K
ICAgICAgIGNlcnRpZmljYXRlIGZvcm1hdCBhbmQgdGhlaXIgdXNlIHdpdGggdGhlIENNUyBtdXN0
IGluY2x1ZGUNCiAgICAgICBkZXRhaWxzIG9uIG1hdGNoaW5nIHRoZSBrZXkgaWRlbnRpZmllciB0
byB0aGUgYXBwcm9wcmlhdGUNCiAgICAgICBjZXJ0aWZpY2F0ZSBmaWVsZC4gIFRoaXMgZmllbGQg
aXMgUkVDT01NRU5ERUQgZm9yIFRELVRSVVNURUQtDQogICAgICAgQ0VSVElGSUVSUyAoYXMgZGVm
aW5lZCBpbiBTZWN0aW9uIDMuMi4yKS4NCg0KICAgVGhlIHRydXN0ZWRDZXJ0aWZpZXJzIGZpZWxk
IG9mIHRoZSB0eXBlIFBBLVBLLUFTLVJFUSBjb250YWlucyBhIGxpc3QNCiAgIG9mIENBcywgdHJ1
c3RlZCBieSB0aGUgY2xpZW50LCB0aGF0IGNhbiBiZSB1c2VkIHRvIGNlcnRpZnkgdGhlIEtEQy4N
CiAgIEVhY2ggRXh0ZXJuYWxQcmluY2lwYWxJZGVudGlmaWVyIGlkZW50aWZpZXMgYSBDQSBvciBh
IENBIGNlcnRpZmljYXRlDQoNCg0KDQpaaHUgJiBUdW5nICAgICAgICAgICAgICAgIEV4cGlyZXMg
SnVseSAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0
ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAw
Ng0KDQoNCiAgICh0aGVyZWJ5IGl0cyBwdWJsaWMga2V5KS4NCg0KICAgVGhlIGtkY1BrSWQgZmll
bGQgb2YgdGhlIHR5cGUgUEEtUEstQVMtUkVRIGNvbnRhaW5zIGEgQ01TIHR5cGUNCiAgIFNpZ25l
cklkZW50aWZpZXIgZW5jb2RlZCBhY2NvcmRpbmcgdG8gW1JGQzM4NTJdLiAgVGhpcyBmaWVsZA0K
ICAgaWRlbnRpZmllcywgaWYgcHJlc2VudCwgYSBwYXJ0aWN1bGFyIEtEQyBwdWJsaWMga2V5IHRo
YXQgdGhlIGNsaWVudA0KICAgYWxyZWFkeSBoYXMuDQoNCjMuMi4yLiAgUmVjZWlwdCBvZiBDbGll
bnQgUmVxdWVzdA0KDQogICBVcG9uIHJlY2VpdmluZyB0aGUgY2xpZW50J3MgcmVxdWVzdCwgdGhl
IEtEQyB2YWxpZGF0ZXMgaXQuICBUaGlzDQogICBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgc3RlcHMg
dGhhdCB0aGUgS0RDIE1VU1QgKHVubGVzcyBvdGhlcndpc2UNCiAgIG5vdGVkKSB0YWtlIGluIHZh
bGlkYXRpbmcgdGhlIHJlcXVlc3QuDQoNCiAgIFRoZSBLREMgdmVyaWZpZXMgdGhlIGNsaWVudCdz
IHNpZ25hdHVyZSBpbiB0aGUgc2lnbmVkQXV0aFBhY2sgZmllbGQNCiAgIGFjY29yZGluZyB0byBb
UkZDMzg1Ml0uDQoNCiAgIElmLCB3aGlsZSB2YWxpZGF0aW5nIHRoZSBjbGllbnQncyBYLjUwOSBj
ZXJ0aWZpY2F0ZSBbUkZDMzI4MF0sIHRoZQ0KICAgS0RDIGNhbm5vdCBidWlsZCBhIGNlcnRpZmlj
YXRpb24gcGF0aCB0byB2YWxpZGF0ZSB0aGUgY2xpZW50J3MNCiAgIGNlcnRpZmljYXRlLCBpdCBz
ZW5kcyBiYWNrIGEgS1JCLUVSUk9SIFtSRkM0MTIwXSBtZXNzYWdlIHdpdGggdGhlDQogICBjb2Rl
IEtEQ19FUlJfQ0FOVF9WRVJJRllfQ0VSVElGSUNBVEUuICBUaGUgYWNjb21wYW55aW5nIGUtZGF0
YSBmb3INCiAgIHRoaXMgZXJyb3IgbWVzc2FnZSBpcyBhIFRZUEVELURBVEEgKGFzIGRlZmluZWQg
aW4gW1JGQzQxMjBdKSB0aGF0DQogICBjb250YWlucyBhbiBlbGVtZW50IHdob3NlIGRhdGEtdHlw
ZSBpcyBURF9UUlVTVEVEX0NFUlRJRklFUlMsIGFuZA0KICAgd2hvc2UgZGF0YS12YWx1ZSBjb250
YWlucyB0aGUgREVSIGVuY29kaW5nIG9mIHRoZSB0eXBlIFRELVRSVVNURUQtDQogICBDRVJUSUZJ
RVJTOg0KDQogICAgICAgVEQtVFJVU1RFRC1DRVJUSUZJRVJTIDo6PSBTRVFVRU5DRSBPRg0KICAg
ICAgICAgICAgICAgICAgICAgIEV4dGVybmFsUHJpbmNpcGFsSWRlbnRpZmllcg0KICAgICAgICAg
ICAgICAgICAgIC0tIElkZW50aWZpZXMgYSBsaXN0IG9mIENBcyB0cnVzdGVkIGJ5IHRoZSBLREMu
DQogICAgICAgICAgICAgICAgICAgLS0gRWFjaCBFeHRlcm5hbFByaW5jaXBhbElkZW50aWZpZXIg
aWRlbnRpZmllcyBhIENBDQogICAgICAgICAgICAgICAgICAgLS0gb3IgYSBDQSBjZXJ0aWZpY2F0
ZSAodGhlcmVieSBpdHMgcHVibGljIGtleSkuDQoNCiAgIEVhY2ggRXh0ZXJuYWxQcmluY2lwYWxJ
ZGVudGlmaWVyIChhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4yLjEpIGluIHRoZQ0KICAgVEQtVFJV
U1RFRC1DRVJUSUZJRVJTIHN0cnVjdHVyZSBpZGVudGlmaWVzIGEgQ0Egb3IgYSBDQSBjZXJ0aWZp
Y2F0ZQ0KICAgKHRoZXJlYnkgaXRzIHB1YmxpYyBrZXkpIHRydXN0ZWQgYnkgdGhlIEtEQy4NCg0K
ICAgVXBvbiByZWNlaXZpbmcgdGhpcyBlcnJvciBtZXNzYWdlLCB0aGUgY2xpZW50IFNIT1VMRCBy
ZXRyeSBvbmx5IGlmIGl0DQogICBoYXMgYSBkaWZmZXJlbnQgc2V0IG9mIGNlcnRpZmljYXRlcyAo
ZnJvbSB0aG9zZSBvZiB0aGUgcHJldmlvdXMNCiAgIHJlcXVlc3RzKSB0aGF0IGZvcm0gYSBjZXJ0
aWZpY2F0aW9uIHBhdGggKG9yIGEgcGFydGlhbCBwYXRoKSBmcm9tIG9uZQ0KICAgb2YgdGhlIHRy
dXN0IGFuY2hvcnMgYWNjZXB0YWJsZSBieSB0aGUgS0RDIHRvIGl0cyBvd24gY2VydGlmaWNhdGUu
DQoNCiAgIElmLCB3aGlsZSBwcm9jZXNzaW5nIHRoZSBjZXJ0aWZpY2F0aW9uIHBhdGgsIHRoZSBL
REMgZGV0ZXJtaW5lcyB0aGF0DQogICB0aGUgc2lnbmF0dXJlIG9uIG9uZSBvZiB0aGUgY2VydGlm
aWNhdGVzIGluIHRoZSBzaWduZWRBdXRoUGFjayBmaWVsZA0KICAgaXMgaW52YWxpZCwgaXQgcmV0
dXJucyBhIEtSQi1FUlJPUiBbUkZDNDEyMF0gbWVzc2FnZSB3aXRoIHRoZSBjb2RlDQogICBLRENf
RVJSX0lOVkFMSURfQ0VSVElGSUNBVEUuICBUaGUgYWNjb21wYW55aW5nIGUtZGF0YSBmb3IgdGhp
cyBlcnJvcg0KICAgbWVzc2FnZSBpcyBhIFRZUEVELURBVEEgdGhhdCBjb250YWlucyBhbiBlbGVt
ZW50IHdob3NlIGRhdGEtdHlwZSBpcw0KICAgVERfSU5WQUxJRF9DRVJUSUZJQ0FURVMsIGFuZCB3
aG9zZSBkYXRhLXZhbHVlIGNvbnRhaW5zIHRoZSBERVINCiAgIGVuY29kaW5nIG9mIHRoZSB0eXBl
IFRELUlOVkFMSUQtQ0VSVElGSUNBVEVTOg0KDQoNCg0KDQpaaHUgJiBUdW5nICAgICAgICAgICAg
ICAgIEV4cGlyZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCklu
dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAgICAgICAgICAgICAgICAgICAg
IEphbnVhcnkgMjAwNg0KDQoNCiAgICAgICBURC1JTlZBTElELUNFUlRJRklDQVRFUyA6Oj0gU0VR
VUVOQ0UgT0YNCiAgICAgICAgICAgICAgICAgICAgICBFeHRlcm5hbFByaW5jaXBhbElkZW50aWZp
ZXINCiAgICAgICAgICAgICAgICAgICAtLSBFYWNoIEV4dGVybmFsUHJpbmNpcGFsSWRlbnRpZmll
ciBpZGVudGlmaWVzIGENCiAgICAgICAgICAgICAgICAgICAtLSBjZXJ0aWZpY2F0ZSAoc2VudCBi
eSB0aGUgY2xpZW50KSB3aXRoIGFuIGludmFsaWQNCiAgICAgICAgICAgICAgICAgICAtLSBzaWdu
YXR1cmUuDQoNCiAgIEVhY2ggRXh0ZXJuYWxQcmluY2lwYWxJZGVudGlmaWVyIChhcyBkZWZpbmVk
IGluIFNlY3Rpb24gMy4yLjEpIGluIHRoZQ0KICAgVEQtSU5WQUxJRC1DRVJUSUZJQ0FURVMgc3Ry
dWN0dXJlIGlkZW50aWZpZXMgYSBjZXJ0aWZpY2F0ZSAodGhhdCB3YXMNCiAgIHNlbnQgYnkgdGhl
IGNsaWVudCkgd2l0aCBhbiBpbnZhbGlkIHNpZ25hdHVyZS4NCg0KICAgSWYgbW9yZSB0aGFuIG9u
ZSBYLjUwOSBjZXJ0aWZpY2F0ZSBzaWduYXR1cmUgaXMgaW52YWxpZCwgdGhlIEtEQyBNQVkNCiAg
IGluY2x1ZGUgb25lIElzc3VlckFuZFNlcmlhbE51bWJlciBwZXIgaW52YWxpZCBzaWduYXR1cmUg
d2l0aGluIHRoZQ0KICAgVEQtSU5WQUxJRC1DRVJUSUZJQ0FURVMuDQoNCiAgIFRoZSBjbGllbnQn
cyBYLjUwOSBjZXJ0aWZpY2F0ZSBpcyB2YWxpZGF0ZWQgYWNjb3JkaW5nIHRvIFtSRkMzMjgwXS4N
Cg0KICAgQmFzZWQgb24gbG9jYWwgcG9saWN5LCB0aGUgS0RDIG1heSBhbHNvIGNoZWNrIHdoZXRo
ZXIgYW55IFguNTA5DQogICBjZXJ0aWZpY2F0ZXMgaW4gdGhlIGNlcnRpZmljYXRpb24gcGF0aCB2
YWxpZGF0aW5nIHRoZSBjbGllbnQncw0KICAgY2VydGlmaWNhdGUgaGF2ZSBiZWVuIHJldm9rZWQu
ICBJZiBhbnkgb2YgdGhlbSBoYXZlIGJlZW4gcmV2b2tlZCwgdGhlDQogICBLREMgTVVTVCByZXR1
cm4gYW4gZXJyb3IgbWVzc2FnZSB3aXRoIHRoZSBjb2RlDQogICBLRENfRVJSX1JFVk9LRURfQ0VS
VElGSUNBVEU7IGlmIHRoZSBLREMgYXR0ZW1wdHMgdG8gZGV0ZXJtaW5lIHRoZQ0KICAgcmV2b2Nh
dGlvbiBzdGF0dXMgYnV0IGlzIHVuYWJsZSB0byBkbyBzbywgaXQgU0hPVUxEIHJldHVybiBhbiBl
cnJvcg0KICAgbWVzc2FnZSB3aXRoIHRoZSBjb2RlIEtEQ19FUlJfUkVWT0NBVElPTl9TVEFUVVNf
VU5LTk9XTi4gIFRoZQ0KICAgY2VydGlmaWNhdGUgb3IgY2VydGlmaWNhdGVzIGFmZmVjdGVkIGFy
ZSBpZGVudGlmaWVkIGV4YWN0bHkgYXMgZm9yDQogICB0aGUgZXJyb3IgY29kZSBLRENfRVJSX0lO
VkFMSURfQ0VSVElGSUNBVEUgKHNlZSBhYm92ZSkuDQoNCiAgIE5vdGUgdGhhdCB0aGUgVERfSU5W
QUxJRF9DRVJUSUZJQ0FURVMgZXJyb3IgZGF0YSBpcyBvbmx5IHVzZWQgdG8NCiAgIGlkZW50aWZ5
IGludmFsaWQgY2VydGlmaWNhdGVzIHNlbnQgYnkgdGhlIGNsaWVudCBpbiB0aGUgcmVxdWVzdC4N
Cg0KICAgVGhlIGNsaWVudCdzIHB1YmxpYyBrZXkgaXMgdGhlbiB1c2VkIHRvIHZlcmlmeSB0aGUg
c2lnbmF0dXJlLiAgSWYgdGhlDQogICBzaWduYXR1cmUgZmFpbHMgdG8gdmVyaWZ5LCB0aGUgS0RD
IE1VU1QgcmV0dXJuIGFuIGVycm9yIG1lc3NhZ2Ugd2l0aA0KICAgdGhlIGNvZGUgS0RDX0VSUl9J
TlZBTElEX1NJRy4gIFRoZXJlIGlzIG5vIGFjY29tcGFueWluZyBlLWRhdGEgZm9yDQogICB0aGlz
IGVycm9yIG1lc3NhZ2UuDQoNCiAgIEluIGFkZGl0aW9uIHRvIHZhbGlkYXRpbmcgdGhlIGNsaWVu
dCdzIHNpZ25hdHVyZSwgdGhlIEtEQyBNVVNUIGFsc28NCiAgIGNoZWNrIHRoYXQgdGhlIGNsaWVu
dCdzIHB1YmxpYyBrZXkgdXNlZCB0byB2ZXJpZnkgdGhlIGNsaWVudCdzDQogICBzaWduYXR1cmUg
aXMgYm91bmQgdG8gdGhlIGNsaWVudCdzIHByaW5jaXBhbCBuYW1lIGFzIHNwZWNpZmllZCBpbiB0
aGUNCiAgIEFTLVJFUSBhcyBmb2xsb3dzOg0KDQogICAxLiBJZiB0aGUgS0RDIGhhcyBpdHMgb3du
IGJpbmRpbmcgYmV0d2VlbiBlaXRoZXIgdGhlIGNsaWVudCdzDQogICAgICBzaWduYXR1cmUtdmVy
aWZpY2F0aW9uIHB1YmxpYyBrZXkgb3IgdGhlIGNsaWVudCdzIGNlcnRpZmljYXRlIGFuZA0KICAg
ICAgdGhlIGNsaWVudCdzIEtlcmJlcm9zIHByaW5jaXBhbCBuYW1lLCBpdCB1c2VzIHRoYXQgYmlu
ZGluZy4NCg0KICAgMi4gT3RoZXJ3aXNlLCBpZiB0aGUgY2xpZW50J3MgWC41MDkgY2VydGlmaWNh
dGUgY29udGFpbnMgYSBTdWJqZWN0DQogICAgICBBbHRlcm5hdGl2ZSBOYW1lIChTQU4pIGV4dGVu
c2lvbiBjYXJyeWluZyBhIEtSQjVQcmluY2lwYWxOYW1lDQogICAgICAoZGVmaW5lZCBiZWxvdykg
aW4gdGhlIG90aGVyTmFtZSBmaWVsZCBvZiB0aGUgdHlwZSBHZW5lcmFsTmFtZQ0KICAgICAgW1JG
QzMyODBdLCBpdCBiaW5kcyB0aGUgY2xpZW50J3MgWC41MDkgY2VydGlmaWNhdGUgdG8gdGhhdCBu
YW1lLg0KDQoNCg0KDQpaaHUgJiBUdW5nICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyNywg
MjAwNiAgICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg
ICAgICAgICAgIFBLSU5JVCAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAg
ICAgIFRoZSB0eXBlIG9mIHRoZSBvdGhlck5hbWUgZmllbGQgaXMgQW5vdGhlck5hbWUuICBUaGUg
dHlwZS1pZCBmaWVsZA0KICAgICAgb2YgdGhlIHR5cGUgQW5vdGhlck5hbWUgaXMgaWQtcGtpbml0
LXNhbjoNCg0KICAgICAgIGlkLXBraW5pdC1zYW4gT0JKRUNUIElERU5USUZJRVIgOjo9DQogICAg
ICAgICB7IGlzbygxKSBvcmcoMykgZG9kKDYpIGludGVybmV0KDEpIHNlY3VyaXR5KDUpIGtlcmJl
cm9zdjUoMikNCiAgICAgICAgICAgeDUwOVNhbkFOICgyKSB9DQoNCiAgICAgIEFuZCB0aGUgdmFs
dWUgZmllbGQgb2YgdGhlIHR5cGUgQW5vdGhlck5hbWUgaXMgYQ0KICAgICAgS1JCNVByaW5jaXBh
bE5hbWUuDQoNCiAgICAgICBLUkI1UHJpbmNpcGFsTmFtZSA6Oj0gU0VRVUVOQ0Ugew0KICAgICAg
ICAgICByZWFsbSAgICAgICAgICAgICAgICAgICBbMF0gUmVhbG0sDQogICAgICAgICAgIHByaW5j
aXBhbE5hbWUgICAgICAgICAgIFsxXSBQcmluY2lwYWxOYW1lDQogICAgICAgfQ0KDQogICBJZiB0
aGUgS2VyYmVyb3MgY2xpZW50IG5hbWUgaW4gdGhlIEFTLVJFUSBkb2VzIG5vdCBtYXRjaCBhIG5h
bWUgYm91bmQNCiAgIGJ5IHRoZSBLREMgKHRoZSBiaW5kaW5nIGNhbiBiZSBpbiB0aGUgY2VydGlm
aWNhdGUsIGZvciBleGFtcGxlIGFzDQogICBkZXNjcmliZWQgYWJvdmUpLCBvciBpZiB0aGVyZSBp
cyBubyBiaW5kaW5nIGZvdW5kIGJ5IHRoZSBLREMsIHRoZSBLREMNCiAgIE1VU1QgcmV0dXJuIGFu
IGVycm9yIG1lc3NhZ2Ugd2l0aCB0aGUgY29kZQ0KICAgS0RDX0VSUl9DTElFTlRfTkFNRV9NSVNN
QVRDSC4gIFRoZXJlIGlzIG5vIGFjY29tcGFueWluZyBlLWRhdGEgZm9yDQogICB0aGlzIGVycm9y
IG1lc3NhZ2UuDQoNCiAgIEV2ZW4gaWYgdGhlIGNlcnRpZmljYXRpb24gcGF0aCBpcyB2YWxpZGF0
ZWQgYW5kIHRoZSBjZXJ0aWZpY2F0ZSBpcw0KICAgbWFwcGVkIHRvIHRoZSBjbGllbnQncyBwcmlu
Y2lwYWwgbmFtZSwgdGhlIEtEQyBtYXkgZGVjaWRlIG5vdCB0bw0KICAgYWNjZXB0IHRoZSBjbGll
bnQncyBjZXJ0aWZpY2F0ZSwgZGVwZW5kaW5nIG9uIGxvY2FsIHBvbGljeS4NCg0KICAgVGhlIEtE
QyBNQVkgcmVxdWlyZSB0aGUgcHJlc2VuY2Ugb2YgYW4gRXh0ZW5kZWQgS2V5IFVzYWdlIChFS1Up
DQogICBLZXlQdXJwb3NlSWQgW1JGQzMyODBdIGlkLXBraW5pdC1LUENsaWVudEF1dGggaW4gdGhl
IGV4dGVuc2lvbnMgZmllbGQNCiAgIG9mIHRoZSBjbGllbnQncyBYLjUwOSBjZXJ0aWZpY2F0ZToN
Cg0KICAgICAgIGlkLXBraW5pdC1LUENsaWVudEF1dGggT0JKRUNUIElERU5USUZJRVIgOjo9DQog
ICAgICAgICB7IGlzbygxKSBvcmcoMykgZG9kKDYpIGludGVybmV0KDEpIHNlY3VyaXR5KDUpIGtl
cmJlcm9zdjUoMikNCiAgICAgICAgICAgcGtpbml0KDMpIGtleVB1cnBvc2VDbGllbnRBdXRoKDQp
IH0NCiAgICAgICAgICAgICAgLS0gUEtJTklUIGNsaWVudCBhdXRoZW50aWNhdGlvbi4NCiAgICAg
ICAgICAgICAgLS0gS2V5IHVzYWdlIGJpdHMgdGhhdCBNVVNUIGJlIGNvbnNpc3RlbnQ6DQogICAg
ICAgICAgICAgIC0tIGRpZ2l0YWxTaWduYXR1cmUuDQoNCiAgIFRoZSBkaWdpdGFsU2lnbmF0dXJl
IGtleSB1c2FnZSBiaXQgW1JGQzMyODBdIE1VU1QgYmUgYXNzZXJ0ZWQgd2hlbg0KICAgdGhlIGlu
dGVuZGVkIHB1cnBvc2Ugb2YgdGhlIGNsaWVudCdzIFguNTA5IGNlcnRpZmljYXRlIGlzIHJlc3Ry
aWN0ZWQNCiAgIHdpdGggdGhlIGlkLXBraW5pdC1LUENsaWVudEF1dGggRUtVLg0KDQogICBJZiB0
aGlzIEVLVSBLZXlQdXJwb3NlSWQgaXMgcmVxdWlyZWQgYnV0IGl0IGlzIG5vdCBwcmVzZW50IG9y
IGlmIHRoZQ0KICAgY2xpZW50IGNlcnRpZmljYXRlIGlzIHJlc3RyaWN0ZWQgbm90IHRvIGJlIHVz
ZWQgZm9yIFBLSU5JVCBjbGllbnQNCiAgIGF1dGhlbnRpY2F0aW9uIHBlciBTZWN0aW9uIDQuMi4x
LjEzIG9mIFtSRkMzMjgwXSwgdGhlIEtEQyBNVVNUIHJldHVybg0KICAgYW4gZXJyb3IgbWVzc2Fn
ZSBvZiB0aGUgY29kZSBLRENfRVJSX0lOQ09OU0lTVEVOVF9LRVlfUFVSUE9TRS4gIFRoZXJlDQog
ICBpcyBubyBhY2NvbXBhbnlpbmcgZS1kYXRhIGZvciB0aGlzIGVycm9yIG1lc3NhZ2UuICBLRENz
IGltcGxlbWVudGluZw0KICAgdGhpcyByZXF1aXJlbWVudCBTSE9VTEQgYWxzbyBhY2NlcHQgdGhl
IEVLVSBLZXlQdXJwb3NlSWQgaWQtbXMta3Atc2MtDQogICBsb2dvbiAoMS4zLjYuMS40LjEuMzEx
LjIwLjIuMikgYXMgbWVldGluZyB0aGUgcmVxdWlyZW1lbnQsIGFzIHRoZXJlDQoNCg0KDQpaaHUg
JiBUdW5nICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAgICAg
ICBbUGFnZSAxNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAg
ICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgIGFyZSBhIGxhcmdlIG51bWJl
ciBvZiBYLjUwOSBjbGllbnQgY2VydGlmaWNhdGVzIGRlcGxveWVkIGZvciB1c2Ugd2l0aA0KICAg
UEtJTklUIHdoaWNoIGhhdmUgdGhpcyBFS1UuDQoNCiAgIEFzIGEgbWF0dGVyIG9mIGxvY2FsIHBv
bGljeSwgdGhlIEtEQyBNQVkgZGVjaWRlIHRvIHJlamVjdCByZXF1ZXN0cyBvbg0KICAgdGhlIGJh
c2lzIG9mIHRoZSBhYnNlbmNlIG9yIHByZXNlbmNlIG9mIG90aGVyIHNwZWNpZmljIEVLVSBPSUQn
cy4NCg0KICAgSWYgdGhlIGRpZ2VzdCBhbGdvcml0aG0gdXNlZCBpbiBnZW5lcmF0aW5nIHRoZSBD
QSBzaWduYXR1cmUgZm9yIHRoZQ0KICAgcHVibGljIGtleSBpbiBhbnkgY2VydGlmaWNhdGUgb2Yg
dGhlIHJlcXVlc3QgaXMgbm90IGFjY2VwdGFibGUgYnkgdGhlDQogICBLREMsIHRoZSBLREMgTVVT
VCByZXR1cm4gYSBLUkItRVJST1IgW1JGQzQxMjBdIG1lc3NhZ2Ugd2l0aCB0aGUgY29kZQ0KICAg
S0RDX0VSUl9ESUdFU1RfSU5fQ0VSVF9OT1RfQUNDRVBURUQuICBUaGUgYWNjb21wYW55aW5nIGUt
ZGF0YSBNVVNUIGJlDQogICBlbmNvZGVkIGluIFRZUEVELURBVEEgYWx0aG91Z2ggbm9uZSBpcyBk
ZWZpbmVkIGF0IHRoaXMgcG9pbnQuDQoNCiAgIElmIHRoZSBjbGllbnQncyBwdWJsaWMga2V5IGlz
IG5vdCBhY2NlcHRlZCB3aXRoIHJlYXNvbnMgb3RoZXIgdGhhbg0KICAgd2hhdCB3ZXJlIHNwZWNp
ZmllZCBhYm92ZSwgdGhlIEtEQyByZXR1cm5zIGEgS1JCLUVSUk9SIFtSRkM0MTIwXQ0KICAgbWVz
c2FnZSB3aXRoIHRoZSBjb2RlIEtEQ19FUlJfQ0xJRU5UX05PVF9UUlVTVEVELiAgVGhlcmUgaXMg
bm8NCiAgIGFjY29tcGFueWluZyBlLWRhdGEgY3VycmVudGx5IGRlZmluZWQgZm9yIHRoaXMgZXJy
b3IgbWVzc2FnZS4NCg0KICAgVGhlIEtEQyBNVVNUIGNoZWNrIHRoZSB0aW1lc3RhbXAgdG8gZW5z
dXJlIHRoYXQgdGhlIHJlcXVlc3QgaXMgbm90IGENCiAgIHJlcGxheSwgYW5kIHRoYXQgdGhlIHRp
bWUgc2tldyBmYWxscyB3aXRoaW4gYWNjZXB0YWJsZSBsaW1pdHMuICBUaGUNCiAgIHJlY29tbWVu
ZGF0aW9ucyBmb3IgY2xvY2sgc2tldyB0aW1lcyBpbiBbUkZDNDEyMF0gYXBwbHkgaGVyZS4gIElm
IHRoZQ0KICAgY2hlY2sgZmFpbHMsIHRoZSBLREMgTVVTVCByZXR1cm4gZXJyb3IgY29kZSBLUkJf
QVBfRVJSX1JFUEVBVCBvcg0KICAgS1JCX0FQX0VSUl9TS0VXLCByZXNwZWN0aXZlbHkuDQoNCiAg
IElmIHRoZSBjbGllbnRQdWJsaWNWYWx1ZSBpcyBmaWxsZWQgaW4sIGluZGljYXRpbmcgdGhhdCB0
aGUgY2xpZW50DQogICB3aXNoZXMgdG8gdXNlIHRoZSBEaWZmaWUtSGVsbG1hbiBrZXkgYWdyZWVt
ZW50IG1ldGhvZCwgdGhlIEtEQyBTSE9VTEQNCiAgIGNoZWNrIHRvIHNlZSBpZiB0aGUga2V5IHBh
cmFtZXRlcnMgc2F0aXNmeSBpdHMgcG9saWN5LiAgSWYgdGhleSBkbw0KICAgbm90LCBpdCBNVVNU
IHJldHVybiBhbiBlcnJvciBtZXNzYWdlIHdpdGggdGhlIGNvZGUNCiAgIEtEQ19FUlJfREhfS0VZ
X1BBUkFNRVRFUlNfTk9UX0FDQ0VQVEVELiAgVGhlIGFjY29tcGFueWluZyBlLWRhdGEgaXMgYQ0K
ICAgVFlQRUQtREFUQSB0aGF0IGNvbnRhaW5zIGFuIGVsZW1lbnQgd2hvc2UgZGF0YS10eXBlIGlz
DQogICBURF9ESF9QQVJBTUVURVJTLCBhbmQgd2hvc2UgZGF0YS12YWx1ZSBjb250YWlucyB0aGUg
REVSIGVuY29kaW5nIG9mDQogICB0aGUgdHlwZSBURC1ESC1QQVJBTUVURVJTOg0KDQogICAgICAg
VEQtREgtUEFSQU1FVEVSUyA6Oj0gU0VRVUVOQ0UgT0YgQWxnb3JpdGhtSWRlbnRpZmllcg0KICAg
ICAgICAgICAgICAgICAgIC0tIEVhY2ggQWxnb3JpdGhtSWRlbnRpZmllciBzcGVjaWZpZXMgYSBz
ZXQgb2YNCiAgICAgICAgICAgICAgICAgICAtLSBEaWZmaWUtSGVsbG1hbiBkb21haW4gcGFyYW1l
dGVycyBbSUVFRTEzNjNdLg0KICAgICAgICAgICAgICAgICAgIC0tIFRoaXMgbGlzdCBpcyBpbiBk
ZWNyZWFzaW5nIHByZWZlcmVuY2Ugb3JkZXIuDQoNCiAgIFRELURILVBBUkFNRVRFUlMgY29udGFp
bnMgYSBsaXN0IG9mIERpZmZpZS1IZWxsbWFuIGRvbWFpbiBwYXJhbWV0ZXJzDQogICB0aGF0IHRo
ZSBLREMgc3VwcG9ydHMgaW4gZGVjcmVhc2luZyBwcmVmZXJlbmNlIG9yZGVyLCBmcm9tIHdoaWNo
IHRoZQ0KICAgY2xpZW50IFNIT1VMRCBwaWNrIG9uZSB0byByZXRyeSB0aGUgcmVxdWVzdC4NCg0K
ICAgVGhlIEFsZ29yaXRobUlkZW50aWZpZXIgc3RydWN0dXJlIGlzIGRlZmluZWQgaW4gW1JGQzMy
ODBdIGFuZCBpcw0KICAgZmlsbGVkIGluIGFjY29yZGluZyB0byBbUkZDMzI3OV0uICBNb3JlIHNw
ZWNpZmljYWxseSBTZWN0aW9uIDIuMy4zIG9mDQogICBbUkZDMzI3OV0gZGVzY3JpYmVzIGhvdyB0
byBmaWxsIGluIHRoZSBBbGdvcml0aG1JZGVudGlmaWVyIHN0cnVjdHVyZQ0KICAgaW4gdGhlIGNh
c2Ugd2hlcmUgTU9EUCBEaWZmaWUtSGVsbG1hbiBrZXkgZXhjaGFuZ2UgaXMgdXNlZC4NCg0KICAg
SWYgdGhlIGNsaWVudCBpbmNsdWRlZCBhIGtkY1BrSWQgZmllbGQgaW4gdGhlIFBBLVBLLUFTLVJF
USBhbmQgdGhlDQogICBLREMgZG9lcyBub3QgcG9zc2VzcyB0aGUgY29ycmVzcG9uZGluZyBrZXks
IHRoZSBLREMgTVVTVCBpZ25vcmUgdGhlDQoNCg0KDQpaaHUgJiBUdW5nICAgICAgICAgICAgICAg
IEV4cGlyZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVy
bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAgICAgICAgICAgICAgICAgICAgIEph
bnVhcnkgMjAwNg0KDQoNCiAgIGtkY1BrSWQgZmllbGQgYXMgaWYgdGhlIGNsaWVudCBkaWQgbm90
IGluY2x1ZGUgb25lLg0KDQogICBJZiB0aGUgZGlnZXN0IGFsZ29yaXRobSB1c2VkIGJ5IHRoZSBp
ZC1wa2luaXQtYXV0aERhdGEgaXMgbm90DQogICBhY2NlcHRhYmxlIGJ5IHRoZSBLREMsIHRoZSBL
REMgTVVTVCByZXR1cm4gYSBLUkItRVJST1IgW1JGQzQxMjBdDQogICBtZXNzYWdlIHdpdGggdGhl
IGNvZGUgS0RDX0VSUl9ESUdFU1RfSU5fU0lHTkVEX0RBVEFfTk9UX0FDQ0VQVEVELg0KICAgVGhl
IGFjY29tcGFueWluZyBlLWRhdGEgTVVTVCBiZSBlbmNvZGVkIGluIFRZUEVELURBVEEgYWx0aG91
Z2ggbm9uZQ0KICAgaXMgZGVmaW5lZCBhdCB0aGlzIHBvaW50Lg0KDQozLjIuMy4gIEdlbmVyYXRp
b24gb2YgS0RDIFJlcGx5DQoNCiAgIElmIHRoZSBwYUNoZWNrc3VtIGZpbGVkIGluIHRoZSByZXF1
ZXN0IGlzIG5vdCBwcmVzZW50LCB0aGUgS0RDDQogICBjb25mb3JtaW5nIHRvIHRoaXMgc3BlY2lm
aWNhdGlvbiBNVVNUIHJldHVybiBhIEtSQi1FUlJPUiBbUkZDNDEyMF0NCiAgIG1lc3NhZ2Ugd2l0
aCB0aGUgY29kZSBLRENfRVJSX1BBX0NIRUNLU1VNX01VU1RfQkVfSU5DTFVERUQuICBUaGUNCiAg
IGFjY29tcGFueWluZyBlLWRhdGEgTVVTVCBiZSBlbmNvZGVkIGluIFRZUEVELURBVEEgKG5vIGVy
cm9yIGRhdGEgaXMNCiAgIGRlZmluZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uKS4NCg0KICAgQXNz
dW1pbmcgdGhhdCB0aGUgY2xpZW50J3MgcmVxdWVzdCBoYXMgYmVlbiBwcm9wZXJseSB2YWxpZGF0
ZWQsIHRoZQ0KICAgS0RDIHByb2NlZWRzIGFzIHBlciBbUkZDNDEyMF0sIGV4Y2VwdCBhcyBmb2xs
b3dzLg0KDQogICBUaGUgS0RDIE1VU1Qgc2V0IHRoZSBpbml0aWFsIGZsYWcgYW5kIGluY2x1ZGUg
YW4gYXV0aG9yaXphdGlvbiBkYXRhDQogICBlbGVtZW50IG9mIGFkLXR5cGUgW1JGQzQxMjBdIEFE
X0lOSVRJQUxfVkVSSUZJRURfQ0FTIGluIHRoZSBpc3N1ZWQNCiAgIHRpY2tldC4gIFRoZSBhZC1k
YXRhIFtSRkM0MTIwXSBmaWVsZCBjb250YWlucyB0aGUgREVSIGVuY29kaW5nIG9mIHRoZQ0KICAg
dHlwZSBBRC1JTklUSUFMLVZFUklGSUVELUNBUzoNCg0KICAgICAgIEFELUlOSVRJQUwtVkVSSUZJ
RUQtQ0FTIDo6PSBTRVFVRU5DRSBPRg0KICAgICAgICAgICAgICAgICAgICAgIEV4dGVybmFsUHJp
bmNpcGFsSWRlbnRpZmllcg0KICAgICAgICAgICAgICAgICAgIC0tIElkZW50aWZpZXMgdGhlIGNl
cnRpZmljYXRpb24gcGF0aCBiYXNlZCBvbiB3aGljaA0KICAgICAgICAgICAgICAgICAgIC0tIHRo
ZSBjbGllbnQgY2VydGlmaWNhdGUgd2FzIHZhbGlkYXRlZC4NCiAgICAgICAgICAgICAgICAgICAt
LSBFYWNoIEV4dGVybmFsUHJpbmNpcGFsSWRlbnRpZmllciBpZGVudGlmaWVzIGEgQ0ENCiAgICAg
ICAgICAgICAgICAgICAtLSBvciBhIENBIGNlcnRpZmljYXRlICh0aGVyZWJ5IGl0cyBwdWJsaWMg
a2V5KS4NCg0KICAgVGhlIEFELUlOSVRJQUwtVkVSSUZJRUQtQ0FTIHN0cnVjdHVyZSBpZGVudGlm
aWVzIHRoZSBjZXJ0aWZpY2F0aW9uDQogICBwYXRoIGJhc2VkIG9uIHdoaWNoIHRoZSBjbGllbnQg
Y2VydGlmaWNhdGUgd2FzIHZhbGlkYXRlZC4gIEVhY2gNCiAgIEV4dGVybmFsUHJpbmNpcGFsSWRl
bnRpZmllciAoYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMi4xKSBpbiB0aGUgQUQtDQogICBJTklU
SUFMLVZFUklGSUVELUNBUyBzdHJ1Y3R1cmUgaWRlbnRpZmllcyBhIENBIG9yIGEgQ0EgY2VydGlm
aWNhdGUNCiAgICh0aGVyZWJ5IGl0cyBwdWJsaWMga2V5KS4NCg0KICAgTm90ZSB0aGF0IHRoZSBz
eW50YXggZm9yIHRoZSBBRC1JTklUSUFMLVZFUklGSUVELUNBUyBhdXRob3JpemF0aW9uDQogICBk
YXRhIGRvZXMgcGVybWl0IGVtcHR5IFNFUVVFTkNFcyB0byBiZSBlbmNvZGVkLiAgU3VjaCBlbXB0
eSBzZXF1ZW5jZXMNCiAgIG1heSBvbmx5IGJlIHVzZWQgaWYgdGhlIEtEQyBpdHNlbGYgdm91Y2hl
cyBmb3IgdGhlIHVzZXIncw0KICAgY2VydGlmaWNhdGUuDQoNCiAgIFRoZSBBUyB3cmFwcyBhbnkg
QUQtSU5JVElBTC1WRVJJRklFRC1DQVMgZGF0YSBpbiBBRC1JRi1SRUxFVkFOVA0KICAgY29udGFp
bmVycyBpZiB0aGUgbGlzdCBvZiBDQXMgc2F0aXNmaWVzIHRoZSBBUycgcmVhbG0ncyBsb2NhbCBw
b2xpY3kNCiAgICh0aGlzIGNvcnJlc3BvbmRzIHRvIHRoZSBUUkFOU0lURUQtUE9MSUNZLUNIRUNL
RUQgdGlja2V0IGZsYWcNCiAgIFtSRkM0MTIwXSkuICBGdXJ0aGVybW9yZSwgYW55IFRHUyBNVVNU
IGNvcHkgc3VjaCBhdXRob3JpemF0aW9uIGRhdGENCiAgIGZyb20gdGlja2V0cyB1c2VkIHdpdGhp
biBhIFBBLVRHUy1SRVEgb2YgdGhlIFRHUy1SRVEgaW50byB0aGUNCiAgIHJlc3VsdGluZyB0aWNr
ZXQuICBJZiB0aGUgbGlzdCBvZiBDQXMgc2F0aXNmaWVzIHRoZSBsb2NhbCBLREMncw0KDQoNCg0K
Wmh1ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjcsIDIwMDYgICAgICAgICAg
ICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBQS0lO
SVQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDYNCg0KDQogICByZWFsbSdzIHBvbGlj
eSwgdGhlIFRHUyBNQVkgd3JhcCB0aGUgZGF0YSBpbnRvIHRoZSBBRC1JRi1SRUxFVkFOVA0KICAg
Y29udGFpbmVyLCBvdGhlcndpc2UgaXQgTUFZIHVud3JhcCB0aGUgYXV0aG9yaXphdGlvbiBkYXRh
IG91dCBvZiB0aGUNCiAgIEFELUlGLVJFTEVWQU5UIGNvbnRhaW5lci4NCg0KICAgQXBwbGljYXRp
b24gc2VydmVycyB0aGF0IHVuZGVyc3RhbmQgdGhpcyBhdXRob3JpemF0aW9uIGRhdGEgdHlwZQ0K
ICAgU0hPVUxEIGFwcGx5IGxvY2FsIHBvbGljeSB0byBkZXRlcm1pbmUgd2hldGhlciBhIGdpdmVu
IHRpY2tldCBiZWFyaW5nDQogICBzdWNoIGEgdHlwZSAqbm90KiBjb250YWluZWQgd2l0aGluIGFu
IEFELUlGLVJFTEVWQU5UIGNvbnRhaW5lciBpcw0KICAgYWNjZXB0YWJsZS4gIChUaGlzIGNvcnJl
c3BvbmRzIHRvIHRoZSBBUCBzZXJ2ZXIgY2hlY2tpbmcgdGhlDQogICB0cmFuc2l0ZWQgZmllbGQg
d2hlbiB0aGUgVFJBTlNJVEVELVBPTElDWS1DSEVDS0VEIGZsYWcgaGFzIG5vdCBiZWVuDQogICBz
ZXQgW1JGQzQxMjBdLikgIElmIHN1Y2ggYSBkYXRhIHR5cGUgaXMgY29udGFpbmVkIHdpdGhpbiBh
biBBRC1JRi0NCiAgIFJFTEVWQU5UIGNvbnRhaW5lciwgQVAgc2VydmVycyBNQVkgYXBwbHkgbG9j
YWwgcG9saWN5IHRvIGRldGVybWluZQ0KICAgd2hldGhlciB0aGUgYXV0aG9yaXphdGlvbiBkYXRh
IGlzIGFjY2VwdGFibGUuDQoNCiAgIEEgcHJlLWF1dGhlbnRpY2F0aW9uIGRhdGEgZWxlbWVudCwg
d2hvc2UgcGFkYXRhLXR5cGUgaXMgUEFfUEtfQVNfUkVQDQogICBhbmQgd2hvc2UgcGFkYXRhLXZh
bHVlIGNvbnRhaW5zIHRoZSBERVIgZW5jb2Rpbmcgb2YgdGhlIHR5cGUgUEEtUEstDQogICBBUy1S
RVAgKGRlZmluZWQgYmVsb3cpLCBpcyBpbmNsdWRlZCBpbiB0aGUgQVMtUkVQIFtSRkM0MTIwXS4N
Cg0KICAgICAgIFBBLVBLLUFTLVJFUCA6Oj0gQ0hPSUNFIHsNCiAgICAgICAgICBkaEluZm8gICAg
ICAgICAgICAgICAgICBbMF0gREhSZXBJbmZvLA0KICAgICAgICAgICAgICAgICAgIC0tIFNlbGVj
dGVkIHdoZW4gRGlmZmllLUhlbGxtYW4ga2V5IGV4Y2hhbmdlIGlzDQogICAgICAgICAgICAgICAg
ICAgLS0gdXNlZC4NCiAgICAgICAgICBlbmNLZXlQYWNrICAgICAgICAgICAgICBbMV0gSU1QTElD
SVQgT0NURVQgU1RSSU5HLA0KICAgICAgICAgICAgICAgICAgIC0tIFNlbGVjdGVkIHdoZW4gcHVi
bGljIGtleSBlbmNyeXB0aW9uIGlzIHVzZWQuDQogICAgICAgICAgICAgICAgICAgLS0gQ29udGFp
bnMgYSBDTVMgdHlwZSBDb250ZW50SW5mbyBlbmNvZGVkDQogICAgICAgICAgICAgICAgICAgLS0g
YWNjb3JkaW5nIHRvIFtSRkMzODUyXS4NCiAgICAgICAgICAgICAgICAgICAtLSBUaGUgY29udGVu
dFR5cGUgZmllbGQgb2YgdGhlIHR5cGUgQ29udGVudEluZm8gaXMNCiAgICAgICAgICAgICAgICAg
ICAtLSBpZC1lbnZlbG9wZWREYXRhICgxLjIuODQwLjExMzU0OS4xLjcuMykuDQogICAgICAgICAg
ICAgICAgICAgLS0gVGhlIGNvbnRlbnQgZmllbGQgaXMgYW4gRW52ZWxvcGVkRGF0YS4NCiAgICAg
ICAgICAgICAgICAgICAtLSBUaGUgY29udGVudFR5cGUgZmllbGQgZm9yIHRoZSB0eXBlIEVudmVs
b3BlZERhdGENCiAgICAgICAgICAgICAgICAgICAtLSBpcyBpZC1zaWduZWREYXRhICgxLjIuODQw
LjExMzU0OS4xLjcuMikuDQogICAgICAgICAgICAgICAgICAgLS0gVGhlIGVDb250ZW50VHlwZSBm
aWVsZCBmb3IgdGhlIGlubmVyIHR5cGUNCiAgICAgICAgICAgICAgICAgICAtLSBTaWduZWREYXRh
ICh3aGVuIHVuZW5jcnlwdGVkKSBpcw0KICAgICAgICAgICAgICAgICAgIC0tIGlkLXBraW5pdC1y
a2V5RGF0YSAoMS4zLjYuMS41LjIuMy4zKSBhbmQgdGhlDQogICAgICAgICAgICAgICAgICAgLS0g
ZUNvbnRlbnQgZmllbGQgY29udGFpbnMgdGhlIERFUiBlbmNvZGluZyBvZiB0aGUNCiAgICAgICAg
ICAgICAgICAgICAtLSB0eXBlIFJlcGx5S2V5UGFjay4NCiAgICAgICAgICAgICAgICAgICAtLSBS
ZXBseUtleVBhY2sgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMi4zLjIuDQogICAgICAgICAgLi4u
DQogICAgICAgfQ0KDQogICAgICAgREhSZXBJbmZvIDo6PSBTRVFVRU5DRSB7DQogICAgICAgICAg
ZGhTaWduZWREYXRhICAgICAgICAgICAgWzBdIElNUExJQ0lUIE9DVEVUIFNUUklORywNCiAgICAg
ICAgICAgICAgICAgICAtLSBDb250YWlucyBhIENNUyB0eXBlIENvbnRlbnRJbmZvIGVuY29kZWQg
YWNjb3JkaW5nDQogICAgICAgICAgICAgICAgICAgLS0gdG8gW1JGQzM4NTJdLg0KICAgICAgICAg
ICAgICAgICAgIC0tIFRoZSBjb250ZW50VHlwZSBmaWVsZCBvZiB0aGUgdHlwZSBDb250ZW50SW5m
byBpcw0KICAgICAgICAgICAgICAgICAgIC0tIGlkLXNpZ25lZERhdGEgKDEuMi44NDAuMTEzNTQ5
LjEuNy4yKSwgYW5kIHRoZQ0KICAgICAgICAgICAgICAgICAgIC0tIGNvbnRlbnQgZmllbGQgaXMg
YSBTaWduZWREYXRhLg0KICAgICAgICAgICAgICAgICAgIC0tIFRoZSBlQ29udGVudFR5cGUgZmll
bGQgZm9yIHRoZSB0eXBlIFNpZ25lZERhdGEgaXMNCiAgICAgICAgICAgICAgICAgICAtLSBpZC1w
a2luaXQtREhLZXlEYXRhICgxLjMuNi4xLjUuMi4zLjIpLCBhbmQgdGhlDQoNCg0KDQpaaHUgJiBU
dW5nICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAgICAgICBb
UGFnZSAxOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAgICAg
ICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgICAgICAgICAgICAgICAgICAtLSBl
Q29udGVudCBmaWVsZCBjb250YWlucyB0aGUgREVSIGVuY29kaW5nIG9mIHRoZQ0KICAgICAgICAg
ICAgICAgICAgIC0tIHR5cGUgS0RDREhLZXlJbmZvLg0KICAgICAgICAgICAgICAgICAgIC0tIEtE
Q0RIS2V5SW5mbyBpcyBkZWZpbmVkIGJlbG93Lg0KICAgICAgICAgIHNlcnZlckRITm9uY2UgICAg
ICAgICAgIFsxXSBESE5vbmNlIE9QVElPTkFMLA0KICAgICAgICAgICAgICAgICAgIC0tIFByZXNl
bnQgaWYgYW5kIG9ubHkgaWYgZGhLZXlFeHBpcmF0aW9uIGlzDQogICAgICAgICAgICAgICAgICAg
LS0gcHJlc2VudCBpbiB0aGUgS0RDREhLZXlJbmZvLg0KICAgICAgICAgIC4uLg0KICAgICAgIH0N
Cg0KICAgICAgIEtEQ0RIS2V5SW5mbyA6Oj0gU0VRVUVOQ0Ugew0KICAgICAgICAgIHN1YmplY3RQ
dWJsaWNLZXkgICAgICAgIFswXSBCSVQgU1RSSU5HLA0KICAgICAgICAgICAgICAgICAgIC0tIFRo
ZSBLREMncyBESCBwdWJsaWMga2V5Lg0KICAgICAgICAgICAgICAgICAgIC0tIFRoZSBESCBwdWJs
aWMga2V5IHZhbHVlIGlzIGVuY29kZWQgYXMgYSBCSVQNCiAgICAgICAgICAgICAgICAgICAtLSBT
VFJJTkcgYWNjb3JkaW5nIHRvIFtSRkMzMjc5XS4NCiAgICAgICAgICBub25jZSAgICAgICAgICAg
ICAgICAgICBbMV0gSU5URUdFUiAoMC4uNDI5NDk2NzI5NSksDQogICAgICAgICAgICAgICAgICAg
LS0gQ29udGFpbnMgdGhlIG5vbmNlIGluIHRoZSBwa0F1dGhlbnRpY2F0b3IgZmllbGQNCiAgICAg
ICAgICAgICAgICAgICAtLSBpbiB0aGUgcmVxdWVzdCBpZiB0aGUgREgga2V5cyBhcmUgTk9UIHJl
dXNlZCwNCiAgICAgICAgICAgICAgICAgICAtLSAwIG90aGVyd2lzZS4NCiAgICAgICAgICBkaEtl
eUV4cGlyYXRpb24gICAgICAgICBbMl0gS2VyYmVyb3NUaW1lIE9QVElPTkFMLA0KICAgICAgICAg
ICAgICAgICAgIC0tIEV4cGlyYXRpb24gdGltZSBmb3IgS0RDJ3Mga2V5IHBhaXIsDQogICAgICAg
ICAgICAgICAgICAgLS0gcHJlc2VudCBpZiBhbmQgb25seSBpZiB0aGUgREgga2V5cyBhcmUgcmV1
c2VkLg0KICAgICAgICAgICAgICAgICAgIC0tIElmIHByZXNlbnQsIHRoZSBLREMncyBESCBwdWJs
aWMga2V5IE1VU1Qgbm90IGJlDQogICAgICAgICAgICAgICAgICAgLS0gdXNlZCBwYXN0IHRoZSBw
b2ludCBvZiB0aGlzIGV4cGlyYXRpb24gdGltZS4NCiAgICAgICAgICAgICAgICAgICAtLSBJZiB0
aGlzIGZpZWxkIGlzIG9taXR0ZWQgdGhlbiB0aGUgc2VydmVyREhOb25jZQ0KICAgICAgICAgICAg
ICAgICAgIC0tIGZpZWxkIE1VU1QgYWxzbyBiZSBvbWl0dGVkLg0KICAgICAgICAgIC4uLg0KICAg
ICAgIH0NCg0KICAgVGhlIGNvbnRlbnQgb2YgdGhlIEFTLVJFUCBpcyBvdGhlcndpc2UgdW5jaGFu
Z2VkIGZyb20gW1JGQzQxMjBdLiAgVGhlDQogICBLREMgZW5jcnlwdHMgdGhlIHJlcGx5IGFzIHVz
dWFsLCBidXQgbm90IHdpdGggdGhlIGNsaWVudCdzIGxvbmctdGVybQ0KICAga2V5LiAgSW5zdGVh
ZCwgaXQgZW5jcnlwdHMgaXQgd2l0aCBlaXRoZXIgYSBzaGFyZWQga2V5IGRlcml2ZWQgZnJvbSBh
DQogICBEaWZmaWUtSGVsbG1hbiBleGNoYW5nZSwgb3IgYSBnZW5lcmF0ZWQgZW5jcnlwdGlvbiBr
ZXkuICBUaGUgY29udGVudHMNCiAgIG9mIHRoZSBQQS1QSy1BUy1SRVAgaW5kaWNhdGUgd2hpY2gg
a2V5IGRlbGl2ZXJ5IG1ldGhvZCBpcyB1c2VkLg0KDQogICBJbiBhZGRpdGlvbiwgdGhlIGxpZmV0
aW1lIG9mIHRoZSB0aWNrZXQgcmV0dXJuZWQgYnkgdGhlIEtEQyBNVVNUIE5PVA0KICAgZXhjZWVk
IHRoYXQgb2YgdGhlIGNsaWVudCdzIHB1YmxpYy1wcml2YXRlIGtleSBwYWlyLiAgVGhlIHRpY2tl
dA0KICAgbGlmZXRpbWUsIGhvd2V2ZXIsIGNhbiBiZSBzaG9ydGVyIHRoYW4gdGhhdCBvZiB0aGUg
Y2xpZW50J3MgcHVibGljLQ0KICAgcHJpdmF0ZSBrZXkgcGFpci4gIEZvciB0aGUgaW1wbGVtZW50
YXRpb25zIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhlDQogICBsaWZldGltZSBvZiB0aGUgY2xp
ZW50J3MgcHVibGljLXByaXZhdGUga2V5IHBhaXIgaXMgdGhlIHZhbGlkaXR5DQogICBwZXJpb2Qg
aW4gWC41MDkgY2VydGlmaWNhdGVzIFtSRkMzMjgwXSwgdW5sZXNzIGNvbmZpZ3VyZWQgb3RoZXJ3
aXNlLg0KDQozLjIuMy4xLiAgVXNpbmcgRGlmZmllLUhlbGxtYW4gS2V5IEV4Y2hhbmdlDQoNCiAg
IEluIHRoaXMgY2FzZSwgdGhlIFBBLVBLLUFTLVJFUCBjb250YWlucyBhIERIUmVwSW5mbyBzdHJ1
Y3R1cmUuDQoNCiAgIFRoZSBDb250ZW50SW5mbyBbUkZDMzg1Ml0gc3RydWN0dXJlIGZvciB0aGUg
ZGhTaWduZWREYXRhIGZpZWxkIGlzDQogICBmaWxsZWQgaW4gYXMgZm9sbG93czoNCg0KDQoNCg0K
Wmh1ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjcsIDIwMDYgICAgICAgICAg
ICAgICAgW1BhZ2UgMjBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBQS0lO
SVQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDYNCg0KDQogICAxLiAgVGhlIGNvbnRl
bnRUeXBlIGZpZWxkIG9mIHRoZSB0eXBlIENvbnRlbnRJbmZvIGlzIGlkLXNpZ25lZERhdGENCiAg
ICAgICAoYXMgZGVmaW5lZCBpbiBbUkZDMzg1Ml0pLCBhbmQgdGhlIGNvbnRlbnQgZmllbGQgaXMg
YSBTaWduZWREYXRhDQogICAgICAgKGFzIGRlZmluZWQgaW4gW1JGQzM4NTJdKS4NCg0KICAgMi4g
IFRoZSBlQ29udGVudFR5cGUgZmllbGQgZm9yIHRoZSB0eXBlIFNpZ25lZERhdGEgaXMgdGhlIE9J
RCB2YWx1ZQ0KICAgICAgIGZvciBpZC1wa2luaXQtREhLZXlEYXRhOiB7IGlzbygxKSBvcmcoMykg
ZG9kKDYpIGludGVybmV0KDEpDQogICAgICAgc2VjdXJpdHkoNSkga2VyYmVyb3N2NSgyKSBwa2lu
aXQoMykgREhLZXlEYXRhKDIpIH0uICBOb3RlcyB0byBDTVMNCiAgICAgICBpbXBsZW1lbnRlcnM6
IHRoZSBzaWduZWQgYXR0cmlidXRlIGNvbnRlbnQtdHlwZSBNVVNUIGJlIHByZXNlbnQNCiAgICAg
ICBpbiB0aGlzIFNpZ25lZERhdGEgaW5zdGFuY2UgYW5kIGl0cyB2YWx1ZSBpcyBpZC1wa2luaXQt
REhLZXlEYXRhDQogICAgICAgYWNjb3JkaW5nIHRvIFtSRkMzODUyXS4NCg0KICAgMy4gIFRoZSBl
Q29udGVudCBmaWVsZCBmb3IgdGhlIHR5cGUgU2lnbmVkRGF0YSBjb250YWlucyB0aGUgREVSDQog
ICAgICAgZW5jb2Rpbmcgb2YgdGhlIHR5cGUgS0RDREhLZXlJbmZvLg0KDQogICA0LiAgVGhlIEtE
Q0RIS2V5SW5mbyBzdHJ1Y3R1cmUgY29udGFpbnMgdGhlIEtEQydzIHB1YmxpYyBrZXksIGEgbm9u
Y2UNCiAgICAgICBhbmQgb3B0aW9uYWxseSB0aGUgZXhwaXJhdGlvbiB0aW1lIG9mIHRoZSBLREMn
cyBESCBrZXkgYmVpbmcNCiAgICAgICByZXVzZWQuICBUaGUgc3ViamVjdFB1YmxpY0tleSBmaWVs
ZCBvZiB0aGUgdHlwZSBLRENESEtleUluZm8NCiAgICAgICBmaWVsZCBpZGVudGlmaWVzIEtEQydz
IERIIHB1YmxpYyBrZXkuICBUaGlzIERIIHB1YmxpYyBrZXkgdmFsdWUNCiAgICAgICBpcyBlbmNv
ZGVkIGFzIGEgQklUIFNUUklORyBhY2NvcmRpbmcgdG8gW1JGQzMyNzldLiAgVGhlIG5vbmNlDQog
ICAgICAgZmllbGQgY29udGFpbnMgdGhlIG5vbmNlIGluIHRoZSBwa0F1dGhlbnRpY2F0b3IgZmll
bGQgaW4gdGhlDQogICAgICAgcmVxdWVzdCBpZiB0aGUgREgga2V5cyBhcmUgTk9UIHJldXNlZC4g
IFRoZSB2YWx1ZSBvZiB0aGlzIG5vbmNlDQogICAgICAgZmllbGQgaXMgMCBpZiB0aGUgREgga2V5
cyBhcmUgcmV1c2VkLiAgVGhlIGRoS2V5RXhwaXJhdGlvbiBmaWVsZA0KICAgICAgIGlzIHByZXNl
bnQgaWYgYW5kIG9ubHkgaWYgdGhlIERIIGtleXMgYXJlIHJldXNlZC4gIElmIHRoZQ0KICAgICAg
IGRoS2V5RXhwaXJhdGlvbiBmaWVsZCBpcyBwcmVzZW50LCB0aGUgS0RDJ3MgcHVibGljIGtleSBp
biB0aGlzDQogICAgICAgS0RDREhLZXlJbmZvIHN0cnVjdHVyZSBNVVNUIE5PVCBiZSB1c2VkIHBh
c3QgdGhlIHBvaW50IG9mIHRoaXMNCiAgICAgICBleHBpcmF0aW9uIHRpbWUuICBJZiB0aGlzIGZp
ZWxkIGlzIG9taXR0ZWQgdGhlbiB0aGUgc2VydmVyREhOb25jZQ0KICAgICAgIGZpZWxkIE1VU1Qg
YWxzbyBiZSBvbWl0dGVkLg0KDQogICA1LiAgVGhlIHNpZ25lckluZm9zIGZpZWxkIG9mIHRoZSB0
eXBlIFNpZ25lZERhdGEgY29udGFpbnMgYSBzaW5nbGUNCiAgICAgICBzaWduZXJJbmZvLCB3aGlj
aCBjb250YWlucyB0aGUgc2lnbmF0dXJlIG92ZXIgdGhlIHR5cGUNCiAgICAgICBLRENESEtleUlu
Zm8uDQoNCiAgIDYuICBUaGUgY2VydGlmaWNhdGVzIGZpZWxkIG9mIHRoZSB0eXBlIFNpZ25lZERh
dGEgY29udGFpbnMNCiAgICAgICBjZXJ0aWZpY2F0ZXMgaW50ZW5kZWQgdG8gZmFjaWxpdGF0ZSBj
ZXJ0aWZpY2F0aW9uIHBhdGgNCiAgICAgICBjb25zdHJ1Y3Rpb24sIHNvIHRoYXQgdGhlIGNsaWVu
dCBjYW4gdmVyaWZ5IHRoZSBLREMncyBzaWduYXR1cmUNCiAgICAgICBvdmVyIHRoZSB0eXBlIEtE
Q0RIS2V5SW5mby4gIFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhlDQogICAgICAgdHJ1
c3RlZENlcnRpZmllcnMgaW4gdGhlIHJlcXVlc3QgU0hPVUxEIGJlIHVzZWQgYnkgdGhlIEtEQyBh
cw0KICAgICAgIGhpbnRzIHRvIGd1aWRlIGl0cyBzZWxlY3Rpb24gb2YgYW4gYXBwcm9wcmlhdGUg
Y2VydGlmaWNhdGUgY2hhaW4NCiAgICAgICB0byByZXR1cm4gdG8gdGhlIGNsaWVudC4gIFRoaXMg
ZmllbGQgbWF5IGJlIGxlZnQgZW1wdHkgaWYgdGhlIEtEQw0KICAgICAgIHB1YmxpYyBrZXkgc3Bl
Y2lmaWVkIGJ5IHRoZSBrZGNQa0lkIGZpZWxkIGluIHRoZSBQQS1QSy1BUy1SRVEgd2FzDQogICAg
ICAgdXNlZCBmb3Igc2lnbmluZy4gIE90aGVyd2lzZSwgZm9yIHBhdGggdmFsaWRhdGlvbiwgdGhl
c2UNCiAgICAgICBjZXJ0aWZpY2F0ZXMgU0hPVUxEIGJlIHN1ZmZpY2llbnQgdG8gY29uc3RydWN0
IGF0IGxlYXN0IG9uZQ0KICAgICAgIGNlcnRpZmljYXRpb24gcGF0aCBmcm9tIHRoZSBLREMgY2Vy
dGlmaWNhdGUgdG8gb25lIHRydXN0IGFuY2hvcg0KICAgICAgIGFjY2VwdGFibGUgYnkgdGhlIGNs
aWVudCBbUkZDNDE1OF0uICBUaGUgS0RDIE1VU1QgYmUgY2FwYWJsZSBvZg0KICAgICAgIGluY2x1
ZGluZyBzdWNoIGEgc2V0IG9mIGNlcnRpZmljYXRlcyBpZiBjb25maWd1cmVkIHRvIGRvIHNvLiAg
VGhlDQogICAgICAgY2VydGlmaWNhdGVzIGZpZWxkIE1VU1QgTk9UIGNvbnRhaW4gInJvb3QiIENB
IGNlcnRpZmljYXRlcy4NCg0KDQoNCg0KDQpaaHUgJiBUdW5nICAgICAgICAgICAgICAgIEV4cGly
ZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAyMV0NCgwNCkludGVybmV0LURy
YWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkg
MjAwNg0KDQoNCiAgIDcuICBJZiB0aGUgY2xpZW50IGluY2x1ZGVkIHRoZSBjbGllbnRESE5vbmNl
IGZpZWxkLCB0aGVuIHRoZSBLREMgbWF5DQogICAgICAgY2hvb3NlIHRvIHJldXNlIGl0cyBESCBr
ZXlzLiAgSWYgdGhlIHNlcnZlciByZXVzZXMgREgga2V5cyB0aGVuDQogICAgICAgaXQgTVVTVCBp
bmNsdWRlIGFuIGV4cGlyYXRpb24gdGltZSBpbiB0aGUgZGhLZXlFeHBpcmF0aW9uIGZpZWxkLg0K
ICAgICAgIFBhc3QgdGhlIHBvaW50IG9mIHRoZSBleHBpcmF0aW9uIHRpbWUsIHRoZSBzaWduYXR1
cmUgb3ZlciB0aGUNCiAgICAgICB0eXBlIERIUmVwSW5mbyBpcyBjb25zaWRlcmVkIGV4cGlyZWQv
aW52YWxpZC4gIFdoZW4gdGhlIHNlcnZlcg0KICAgICAgIHJldXNlcyBESCBrZXlzIHRoZW4gaXQg
TVVTVCBpbmNsdWRlIGEgc2VydmVyREhOb25jZSBhdCBsZWFzdCBhcw0KICAgICAgIGxvbmcgYXMg
dGhlIGxlbmd0aCBvZiBrZXlzIGZvciB0aGUgc3ltbWV0cmljIGVuY3J5cHRpb24gc3lzdGVtDQog
ICAgICAgdXNlZCB0byBlbmNyeXB0IHRoZSBBUyByZXBseS4gIE5vdGUgdGhhdCBpbmNsdWRpbmcg
dGhlDQogICAgICAgc2VydmVyREhOb25jZSBjaGFuZ2VzIGhvdyB0aGUgY2xpZW50IGFuZCBzZXJ2
ZXIgY2FsY3VsYXRlIHRoZSBrZXkNCiAgICAgICB0byB1c2UgdG8gZW5jcnlwdCB0aGUgcmVwbHk7
IHNlZSBiZWxvdyBmb3IgZGV0YWlscy4gIFRoZSBLREMNCiAgICAgICBTSE9VTEQgTk9UIHJldXNl
IERIIGtleXMgdW5sZXNzIHRoZSBjbGllbnRESE5vbmNlIGZpZWxkIGlzDQogICAgICAgcHJlc2Vu
dCBpbiB0aGUgcmVxdWVzdC4NCg0KICAgVGhlIEFTIHJlcGx5IGtleSBpcyBkZXJpdmVkIGFzIGZv
bGxvd3M6DQoNCiAgIDEuIEJvdGggdGhlIEtEQyBhbmQgdGhlIGNsaWVudCBjYWxjdWxhdGUgdGhl
IHNoYXJlZCBzZWNyZXQgdmFsdWUgYXMNCiAgICAgIGZvbGxvd3M6DQoNCiAgICAgIGEpIFdoZW4g
TU9EUCBEaWZmaWUtSGVsbG1hbiBpcyB1c2VkLCBsZXQgREhTaGFyZWRTZWNyZXQgYmUgdGhlDQog
ICAgICAgICBzaGFyZWQgc2VjcmV0IHZhbHVlLiAgREhTaGFyZWRTZWNyZXQgaXMgdGhlIHZhbHVl
IFpaIGFzDQogICAgICAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEuMSBvZiBbUkZDMjYzMV0u
DQoNCiAgICAgIERIU2hhcmVkU2VjcmV0IGlzIGZpcnN0IHBhZGRlZCB3aXRoIGxlYWRpbmcgemVy
b3Mgc3VjaCB0aGF0IHRoZQ0KICAgICAgc2l6ZSBvZiBESFNoYXJlZFNlY3JldCBpbiBvY3RldHMg
aXMgdGhlIHNhbWUgYXMgdGhhdCBvZiB0aGUNCiAgICAgIG1vZHVsdXMsIHRoZW4gcmVwcmVzZW50
ZWQgYXMgYSBzdHJpbmcgb2Ygb2N0ZXRzIGluIGJpZy1lbmRpYW4NCiAgICAgIG9yZGVyLg0KDQog
ICAgICBJbXBsZW1lbnRhdGlvbiBub3RlOiBCb3RoIHRoZSBjbGllbnQgYW5kIHRoZSBLREMgY2Fu
IGNhY2hlIHRoZQ0KICAgICAgdHJpcGxlICh5YSwgeWIsIERIU2hhcmVkU2VjcmV0KSwgd2hlcmUg
eWEgaXMgdGhlIGNsaWVudCdzIHB1YmxpYw0KICAgICAga2V5IGFuZCB5YiBpcyB0aGUgS0RDJ3Mg
cHVibGljIGtleS4gIElmIGJvdGggeWEgYW5kIHliIGFyZSB0aGUNCiAgICAgIHNhbWUgaW4gYSBs
YXRlciBleGNoYW5nZSwgdGhlIGNhY2hlZCBESFNoYXJlZFNlY3JldCBjYW4gYmUgdXNlZC4NCg0K
ICAgMi4gTGV0IEsgYmUgdGhlIGtleS1nZW5lcmF0aW9uIHNlZWQgbGVuZ3RoIFtSRkMzOTYxXSBv
ZiB0aGUgQVMgcmVwbHkNCiAgICAgIGtleSB3aG9zZSBlbmN0eXBlIGlzIHNlbGVjdGVkIGFjY29y
ZGluZyB0byBbUkZDNDEyMF0uDQoNCiAgIDMuIERlZmluZSB0aGUgZnVuY3Rpb24gb2N0ZXRzdHJp
bmcya2V5KCkgYXMgZm9sbG93czoNCg0KICAgICAgICAgICBvY3RldHN0cmluZzJrZXkoeCkgPT0g
cmFuZG9tLXRvLWtleShLLXRydW5jYXRlKA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgU0hBMSgweDAwIHwgeCkgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgU0hBMSgweDAxIHwgeCkgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
U0hBMSgweDAyIHwgeCkgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4u
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICApKQ0KDQoNCg0KDQoNCg0KDQoN
ClpodSAmIFR1bmcgICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI3LCAyMDA2ICAgICAgICAg
ICAgICAgIFtQYWdlIDIyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgUEtJ
TklUICAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA2DQoNCg0KICAgICAgd2hlcmUgeCBp
cyBhbiBvY3RldCBzdHJpbmc7IHwgaXMgdGhlIGNvbmNhdGVuYXRpb24gb3BlcmF0b3I7IDB4MDAs
DQogICAgICAweDAxLCAweDAyLCBldGMuLCBhcmUgZWFjaCByZXByZXNlbnRlZCBhcyBhIHNpbmds
ZSBvY3RldDsgcmFuZG9tLQ0KICAgICAgdG8ta2V5KCkgaXMgYW4gb3BlcmF0aW9uIHRoYXQgZ2Vu
ZXJhdGVzIGEgcHJvdG9jb2wga2V5IGZyb20gYQ0KICAgICAgYml0c3RyaW5nIG9mIGxlbmd0aCBL
OyBhbmQgSy10cnVuY2F0ZSB0cnVuY2F0ZXMgaXRzIGlucHV0IHRvIHRoZQ0KICAgICAgZmlyc3Qg
SyBiaXRzLiAgQm90aCBLIGFuZCByYW5kb20tdG8ta2V5KCkgYXJlIGFzIGRlZmluZWQgaW4gdGhl
DQogICAgICBrY3J5cHRvIHByb2ZpbGUgW1JGQzM5NjFdIGZvciB0aGUgZW5jdHlwZSBvZiB0aGUg
QVMgcmVwbHkga2V5Lg0KDQogICA0LiBXaGVuIERIIGtleXMgYXJlIHJldXNlZCwgbGV0IG5fYyBi
ZSB0aGUgY2xpZW50REhOb25jZSwgYW5kIG5fayBiZQ0KICAgICAgdGhlIHNlcnZlckRITm9uY2U7
IG90aGVyd2lzZSwgbGV0IGJvdGggbl9jIGFuZCBuX2sgYmUgZW1wdHkgb2N0ZXQNCiAgICAgIHN0
cmluZ3MuDQoNCiAgIDUuIFRoZSBBUyByZXBseSBrZXkgayBpczoNCg0KICAgICAgICAgICBrID0g
b2N0ZXRzdHJpbmcya2V5KERIU2hhcmVkU2VjcmV0IHwgbl9jIHwgbl9rKQ0KDQozLjIuMy4yLiAg
VXNpbmcgUHVibGljIEtleSBFbmNyeXB0aW9uDQoNCiAgIEluIHRoaXMgY2FzZSwgdGhlIFBBLVBL
LUFTLVJFUCBjb250YWlucyB0aGUgZW5jS2V5UGFjayBmaWVsZCB3aGVyZQ0KICAgdGhlIEFTIHJl
cGx5IGtleSBpcyBlbmNyeXB0ZWQuDQoNCiAgIFRoZSBDb250ZW50SW5mbyBbUkZDMzg1Ml0gc3Ry
dWN0dXJlIGZvciB0aGUgZW5jS2V5UGFjayBmaWVsZCBpcw0KICAgZmlsbGVkIGluIGFzIGZvbGxv
d3M6DQoNCiAgIDEuICBUaGUgY29udGVudFR5cGUgZmllbGQgb2YgdGhlIHR5cGUgQ29udGVudElu
Zm8gaXMgaWQtZW52ZWxvcGVkRGF0YQ0KICAgICAgIChhcyBkZWZpbmVkIGluIFtSRkMzODUyXSks
IGFuZCB0aGUgY29udGVudCBmaWVsZCBpcyBhbg0KICAgICAgIEVudmVsb3BlZERhdGEgKGFzIGRl
ZmluZWQgaW4gW1JGQzM4NTJdKS4NCg0KICAgMi4gIFRoZSBjb250ZW50VHlwZSBmaWVsZCBmb3Ig
dGhlIHR5cGUgRW52ZWxvcGVkRGF0YSBpcyBpZC0NCiAgICAgICBzaWduZWREYXRhOiB7IGlzbyAo
MSkgbWVtYmVyLWJvZHkgKDIpIHVzICg4NDApIHJzYWRzaSAoMTEzNTQ5KQ0KICAgICAgIHBrY3Mg
KDEpIHBrY3M3ICg3KSBzaWduZWREYXRhICgyKSB9Lg0KDQogICAzLiAgVGhlIGVDb250ZW50VHlw
ZSBmaWVsZCBmb3IgdGhlIGlubmVyIHR5cGUgU2lnbmVkRGF0YSAod2hlbg0KICAgICAgIGRlY3J5
cHRlZCBmcm9tIHRoZSBlbmNyeXB0ZWRDb250ZW50IGZpZWxkIGZvciB0aGUgdHlwZQ0KICAgICAg
IEVudmVsb3BlZERhdGEpIGlzIGlkLXBraW5pdC1ya2V5RGF0YTogeyBpc28oMSkgb3JnKDMpIGRv
ZCg2KQ0KICAgICAgIGludGVybmV0KDEpIHNlY3VyaXR5KDUpIGtlcmJlcm9zdjUoMikgcGtpbml0
KDMpIHJrZXlEYXRhKDMpIH0uDQogICAgICAgTm90ZXMgdG8gQ01TIGltcGxlbWVudGVyczogdGhl
IHNpZ25lZCBhdHRyaWJ1dGUgY29udGVudC10eXBlIE1VU1QNCiAgICAgICBiZSBwcmVzZW50IGlu
IHRoaXMgU2lnbmVkRGF0YSBpbnN0YW5jZSBhbmQgaXRzIHZhbHVlIGlzIGlkLQ0KICAgICAgIHBr
aW5pdC1ya2V5RGF0YSBhY2NvcmRpbmcgdG8gW1JGQzM4NTJdLg0KDQogICA0LiAgVGhlIGVDb250
ZW50IGZpZWxkIGZvciB0aGUgaW5uZXIgdHlwZSBTaWduZWREYXRhIGNvbnRhaW5zIHRoZSBERVIN
CiAgICAgICBlbmNvZGluZyBvZiB0aGUgdHlwZSBSZXBseUtleVBhY2sgKGFzIGRlc2NyaWJlZCBi
ZWxvdykuDQoNCiAgIDUuICBUaGUgc2lnbmVySW5mb3MgZmllbGQgb2YgdGhlIGlubmVyIHR5cGUg
U2lnbmVkRGF0YSBjb250YWlucyBhDQogICAgICAgc2luZ2xlIHNpZ25lckluZm8sIHdoaWNoIGNv
bnRhaW5zIHRoZSBzaWduYXR1cmUgZm9yIHRoZSB0eXBlDQogICAgICAgUmVwbHlLZXlQYWNrLg0K
DQoNCg0KDQoNCg0KWmh1ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjcsIDIw
MDYgICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg
ICAgICAgICBQS0lOSVQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDYNCg0KDQogICA2
LiAgVGhlIGNlcnRpZmljYXRlcyBmaWVsZCBvZiB0aGUgaW5uZXIgdHlwZSBTaWduZWREYXRhIGNv
bnRhaW5zDQogICAgICAgY2VydGlmaWNhdGVzIGludGVuZGVkIHRvIGZhY2lsaXRhdGUgY2VydGlm
aWNhdGlvbiBwYXRoDQogICAgICAgY29uc3RydWN0aW9uLCBzbyB0aGF0IHRoZSBjbGllbnQgY2Fu
IHZlcmlmeSB0aGUgS0RDJ3Mgc2lnbmF0dXJlDQogICAgICAgZm9yIHRoZSB0eXBlIFJlcGx5S2V5
UGFjay4gIFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhlDQogICAgICAgdHJ1c3RlZENl
cnRpZmllcnMgaW4gdGhlIHJlcXVlc3QgU0hPVUxEIGJlIHVzZWQgYnkgdGhlIEtEQyBhcw0KICAg
ICAgIGhpbnRzIHRvIGd1aWRlIGl0cyBzZWxlY3Rpb24gb2YgYW4gYXBwcm9wcmlhdGUgY2VydGlm
aWNhdGUgY2hhaW4NCiAgICAgICB0byByZXR1cm4gdG8gdGhlIGNsaWVudC4gIFRoaXMgZmllbGQg
bWF5IGJlIGxlZnQgZW1wdHkgaWYgdGhlIEtEQw0KICAgICAgIHB1YmxpYyBrZXkgc3BlY2lmaWVk
IGJ5IHRoZSBrZGNQa0lkIGZpZWxkIGluIHRoZSBQQS1QSy1BUy1SRVEgd2FzDQogICAgICAgdXNl
ZCBmb3Igc2lnbmluZy4gIE90aGVyd2lzZSwgZm9yIHBhdGggdmFsaWRhdGlvbiwgdGhlc2UNCiAg
ICAgICBjZXJ0aWZpY2F0ZXMgU0hPVUxEIGJlIHN1ZmZpY2llbnQgdG8gY29uc3RydWN0IGF0IGxl
YXN0IG9uZQ0KICAgICAgIGNlcnRpZmljYXRpb24gcGF0aCBmcm9tIHRoZSBLREMgY2VydGlmaWNh
dGUgdG8gb25lIHRydXN0IGFuY2hvcg0KICAgICAgIGFjY2VwdGFibGUgYnkgdGhlIGNsaWVudCBb
UkZDNDE1OF0uICBUaGUgS0RDIE1VU1QgYmUgY2FwYWJsZSBvZg0KICAgICAgIGluY2x1ZGluZyBz
dWNoIGEgc2V0IG9mIGNlcnRpZmljYXRlcyBpZiBjb25maWd1cmVkIHRvIGRvIHNvLiAgVGhlDQog
ICAgICAgY2VydGlmaWNhdGVzIGZpZWxkIE1VU1QgTk9UIGNvbnRhaW4gInJvb3QiIENBIGNlcnRp
ZmljYXRlcy4NCg0KICAgNy4gIFRoZSByZWNpcGllbnRJbmZvcyBmaWVsZCBvZiB0aGUgdHlwZSBF
bnZlbG9wZWREYXRhIGlzIGEgU0VUIHdoaWNoDQogICAgICAgTVVTVCBjb250YWluIGV4YWN0bHkg
b25lIG1lbWJlciBvZiB0eXBlIEtleVRyYW5zUmVjaXBpZW50SW5mby4NCiAgICAgICBUaGUgZW5j
cnlwdGVkS2V5IG9mIHRoaXMgbWVtYmVyIGNvbnRhaW5zIHRoZSB0ZW1wb3Jhcnkga2V5IHdoaWNo
DQogICAgICAgaXMgZW5jcnlwdGVkIHVzaW5nIHRoZSBjbGllbnQncyBwdWJsaWMga2V5Lg0KDQog
ICA4LiAgVGhlIHVucHJvdGVjdGVkQXR0cnMgb3Igb3JpZ2luYXRvckluZm8gZmllbGRzIG9mIHRo
ZSB0eXBlDQogICAgICAgRW52ZWxvcGVkRGF0YSBNQVkgYmUgcHJlc2VudC4NCg0KICAgSWYgdGhl
cmUgaXMgYSBzdXBwb3J0ZWRDTVNUeXBlcyBmaWVsZCBpbiB0aGUgQXV0aFBhY2ssIHRoZSBLREMg
bXVzdA0KICAgY2hlY2sgdG8gc2VlIGlmIGl0IHN1cHBvcnRzIGFueSBvZiB0aGUgbGlzdGVkIHR5
cGVzLiAgSWYgaXQgc3VwcG9ydHMNCiAgIG1vcmUgdGhhbiBvbmUgb2YgdGhlIHR5cGVzLCB0aGUg
S0RDIFNIT1VMRCB1c2UgdGhlIG9uZSBsaXN0ZWQgZmlyc3QuDQogICBJZiBpdCBkb2VzIG5vdCBz
dXBwb3J0IGFueSBvZiB0aGVtLCBpdCBNVVNUIHJldHVybiBhbiBlcnJvciBtZXNzYWdlDQogICB3
aXRoIHRoZSBjb2RlIEtEQ19FUlJfRVRZUEVfTk9TVVBQIFtSRkM0MTIwXS4NCg0KICAgRnVydGhl
cm1vcmUgdGhlIEtEQyBjb21wdXRlcyB0aGUgY2hlY2tzdW0gb2YgdGhlIEFTLVJFUSBpbiB0aGUg
Y2xpZW50DQogICByZXF1ZXN0LiAgVGhpcyBjaGVja3N1bSBpcyBwZXJmb3JtZWQgb3ZlciB0aGUg
dHlwZSBBUy1SRVEgYW5kIHRoZQ0KICAgcHJvdG9jb2wga2V5IFtSRkMzOTYxXSBvZiB0aGUgY2hl
Y2tzdW0gb3BlcmF0aW9uIGlzIHRoZSByZXBseUtleSBhbmQNCiAgIHRoZSBrZXkgdXNhZ2UgbnVt
YmVyIGlzIDYuICBJZiB0aGUgcmVwbHlLZXkncyBlbmN0eXBlIGlzICJuZXdlciINCiAgIFtSRkM0
MTIwXSBbUkZDNDEyMV0sIHRoZSBjaGVja3N1bSBvcGVyYXRpb24gaXMgdGhlIHJlcXVpcmVkIGNo
ZWNrc3VtDQogICBvcGVyYXRpb24gW1JGQzM5NjFdIG9mIHRoYXQgZW5jdHlwZS4NCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KWmh1ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBpcmVz
IEp1bHkgMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMjRdDQoMDQpJbnRlcm5ldC1EcmFm
dCAgICAgICAgICAgICAgICAgICBQS0lOSVQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIw
MDYNCg0KDQogICAgICAgUmVwbHlLZXlQYWNrIDo6PSBTRVFVRU5DRSB7DQogICAgICAgICAgcmVw
bHlLZXkgICAgICAgICAgICAgICAgWzBdIEVuY3J5cHRpb25LZXksDQogICAgICAgICAgICAgICAg
ICAgLS0gQ29udGFpbnMgdGhlIHNlc3Npb24ga2V5IHVzZWQgdG8gZW5jcnlwdCB0aGUNCiAgICAg
ICAgICAgICAgICAgICAtLSBlbmMtcGFydCBmaWVsZCBpbiB0aGUgQVMtUkVQLCBpLmUuIHRoZQ0K
ICAgICAgICAgICAgICAgICAgIC0tIEFTIHJlcGx5IGtleS4NCiAgICAgICAgICBhc0NoZWNrc3Vt
ICAgICAgICAgICAgICBbMV0gQ2hlY2tzdW0sDQogICAgICAgICAgICAgICAgICAtLSBDb250YWlu
cyB0aGUgY2hlY2tzdW0gb2YgdGhlIEFTLVJFUQ0KICAgICAgICAgICAgICAgICAgLS0gY29ycmVz
cG9uZGluZyB0byB0aGUgY29udGFpbmluZyBBUy1SRVAuDQogICAgICAgICAgICAgICAgICAtLSBU
aGUgY2hlY2tzdW0gaXMgcGVyZm9ybWVkIG92ZXIgdGhlIHR5cGUgQVMtUkVRLg0KICAgICAgICAg
ICAgICAgICAgLS0gVGhlIHByb3RvY29sIGtleSBbUkZDMzk2MV0gb2YgdGhlIGNoZWNrc3VtIGlz
IHRoZQ0KICAgICAgICAgICAgICAgICAgLS0gcmVwbHlLZXkgYW5kIHRoZSBrZXkgdXNhZ2UgbnVt
YmVyIGlzIDYuDQogICAgICAgICAgICAgICAgICAtLSBJZiB0aGUgcmVwbHlLZXkncyBlbmN0eXBl
IGlzICJuZXdlciIgW1JGQzQxMjBdDQogICAgICAgICAgICAgICAgICAtLSBbUkZDNDEyMV0sIHRo
ZSBjaGVja3N1bSBpcyB0aGUgcmVxdWlyZWQNCiAgICAgICAgICAgICAgICAgIC0tIGNoZWNrc3Vt
IG9wZXJhdGlvbiBbUkZDMzk2MV0gZm9yIHRoYXQgZW5jdHlwZS4NCiAgICAgICAgICAgICAgICAg
IC0tIFRoZSBjbGllbnQgTVVTVCB2ZXJpZnkgdGhpcyBjaGVja3N1bSB1cG9uIHJlY2VpcHQNCiAg
ICAgICAgICAgICAgICAgIC0tIG9mIHRoZSBBUy1SRVAuDQogICAgICAgICAgLi4uDQogICAgICAg
fQ0KDQogICBJbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBSU0EgZW5jcnlwdGlvbiBrZXkgZGVsaXZl
cnkgbWV0aG9kIGFyZQ0KICAgUkVDT01NRU5ERUQgdG8gc3VwcG9ydCBSU0Ega2V5cyBhdCBsZWFz
dCAyMDQ4IGJpdHMgaW4gc2l6ZS4NCg0KMy4yLjQuICBSZWNlaXB0IG9mIEtEQyBSZXBseQ0KDQog
ICBVcG9uIHJlY2VpcHQgb2YgdGhlIEtEQydzIHJlcGx5LCB0aGUgY2xpZW50IHByb2NlZWRzIGFz
IGZvbGxvd3MuICBJZg0KICAgdGhlIFBBLVBLLUFTLVJFUCBjb250YWlucyB0aGUgZGhTaWduZWRE
YXRhIGZpZWxkLCB0aGUgY2xpZW50IGRlcml2ZXMNCiAgIHRoZSBBUyByZXBseSBrZXkgdXNpbmcg
dGhlIHNhbWUgcHJvY2VkdXJlIHVzZWQgYnkgdGhlIEtEQyBhcyBkZWZpbmVkDQogICBpbiBTZWN0
aW9uIDMuMi4zLjEuICBPdGhlcndpc2UsIHRoZSBtZXNzYWdlIGNvbnRhaW5zIHRoZSBlbmNLZXlQ
YWNrDQogICBmaWVsZCwgYW5kIHRoZSBjbGllbnQgZGVjcnlwdHMgYW5kIGV4dHJhY3RzIHRoZSB0
ZW1wb3Jhcnkga2V5IGluIHRoZQ0KICAgZW5jcnlwdGVkS2V5IGZpZWxkIG9mIHRoZSBtZW1iZXIg
S2V5VHJhbnNSZWNpcGllbnRJbmZvLCBhbmQgdGhlbiB1c2VzDQogICB0aGF0IGFzIHRoZSBBUyBy
ZXBseSBrZXkuDQoNCiAgIElmIHRoZSBwdWJsaWMga2V5IGVuY3J5cHRpb24gbWV0aG9kIGlzIHVz
ZWQsIHRoZSBjbGllbnQgTVVTVCB2ZXJpZnkNCiAgIHRoZSBhc0NoZWNrc3VtIGNvbnRhaW5lZCBp
biB0aGUgUmVwbHlLZXlQYWNrLg0KDQogICBJbiBlaXRoZXIgY2FzZSwgdGhlIGNsaWVudCBNVVNU
IHZlcmlmeSB0aGUgc2lnbmF0dXJlIGluIHRoZQ0KICAgU2lnbmVkRGF0YSBhY2NvcmRpbmcgdG8g
W1JGQzM4NTJdLiAgVGhlIEtEQydzIFguNTA5IGNlcnRpZmljYXRlIE1VU1QNCiAgIGJlIHZhbGlk
YXRlZCBhY2NvcmRpbmcgdG8gW1JGQzMyODBdLiAgSW4gYWRkaXRpb24sIHVubGVzcyB0aGUgY2xp
ZW50DQogICBjYW4gb3RoZXJ3aXNlIHZlcmlmeSB0aGF0IHRoZSBwdWJsaWMga2V5IHVzZWQgdG8g
dmVyaWZ5IHRoZSBLREMncw0KICAgc2lnbmF0dXJlIGlzIGJvdW5kIHRvIHRoZSBLREMgb2YgdGhl
IHRhcmdldCByZWFsbSwgdGhlIEtEQydzIFguNTA5DQogICBjZXJ0aWZpY2F0ZSBNVVNUIGNvbnRh
aW4gYSBTdWJqZWN0IEFsdGVybmF0aXZlIE5hbWUgZXh0ZW5zaW9uDQogICBbUkZDMzI4MF0gY2Fy
cnlpbmcgYW4gQW5vdGhlck5hbWUgd2hvc2UgdHlwZS1pZCBpcyBpZC1wa2luaXQtc2FuIChhcw0K
ICAgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMi4yKSBhbmQgd2hvc2UgdmFsdWUgaXMgYSBLUkI1UHJp
bmNpcGFsTmFtZSB0aGF0DQogICBtYXRjaGVzIHRoZSBuYW1lIG9mIHRoZSBUR1Mgb2YgdGhlIHRh
cmdldCByZWFsbSAoYXMgZGVmaW5lZCBpbg0KICAgU2VjdGlvbiA3LjMgb2YgW1JGQzQxMjBdKS4N
Cg0KICAgVW5sZXNzIHRoZSBjbGllbnQga25vd3MgYnkgc29tZSBvdGhlciBtZWFucyB0aGF0IHRo
ZSBLREMgY2VydGlmaWNhdGUNCiAgIGlzIGludGVuZGVkIGZvciBhIEtlcmJlcm9zIEtEQywgdGhl
IGNsaWVudCBNVVNUIHJlcXVpcmUgdGhhdCB0aGUgS0RDDQoNCg0KDQpaaHUgJiBUdW5nICAgICAg
ICAgICAgICAgIEV4cGlyZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAyNV0N
CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAgICAgICAgICAgICAg
ICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgIGNlcnRpZmljYXRlIGNvbnRhaW5zIHRoZSBFS1Ug
S2V5UHVycG9zZUlkIFtSRkMzMjgwXSBpZC1wa2luaXQtS1BLZGM6DQoNCiAgICAgICBpZC1wa2lu
aXQtS1BLZGMgT0JKRUNUIElERU5USUZJRVIgOjo9DQogICAgICAgICB7IGlzbygxKSBvcmcoMykg
ZG9kKDYpIGludGVybmV0KDEpIHNlY3VyaXR5KDUpIGtlcmJlcm9zdjUoMikNCiAgICAgICAgICAg
cGtpbml0KDMpIGtleVB1cnBvc2VLZGMoNSkgfQ0KICAgICAgICAgICAgICAtLSBTaWduaW5nIEtE
QyByZXNwb25zZXMuDQogICAgICAgICAgICAgIC0tIEtleSB1c2FnZSBiaXRzIHRoYXQgTVVTVCBi
ZSBjb25zaXN0ZW50Og0KICAgICAgICAgICAgICAtLSBkaWdpdGFsU2lnbmF0dXJlLg0KDQogICBU
aGUgZGlnaXRhbFNpZ25hdHVyZSBrZXkgdXNhZ2UgYml0IFtSRkMzMjgwXSBNVVNUIGJlIGFzc2Vy
dGVkIHdoZW4NCiAgIHRoZSBpbnRlbmRlZCBwdXJwb3NlIG9mIHRoZSBLREMncyBYLjUwOSBjZXJ0
aWZpY2F0ZSBpcyByZXN0cmljdGVkDQogICB3aXRoIHRoZSBpZC1wa2luaXQtS1BLZGMgRUtVLg0K
DQogICBJZiB0aGUgS0RDIGNlcnRpZmljYXRlIGNvbnRhaW5zIHRoZSBLZXJiZXJvcyBUR1MgbmFt
ZSBlbmNvZGVkIGFzIGFuDQogICBpZC1wa2luaXQtc2FuIFNBTiwgdGhpcyBjZXJ0aWZpY2F0ZSBp
cyBjZXJ0aWZpZWQgYnkgdGhlIGlzc3VpbmcgQ0EgYXMNCiAgIGEgS0RDIGNlcnRpZmljYXRlLCB0
aGVyZWZvcmUgdGhlIGlkLXBraW5pdC1LUEtkYyBFS1UgaXMgbm90IHJlcXVpcmVkLg0KDQogICBJ
ZiBhbGwgYXBwbGljYWJsZSBjaGVja3MgYXJlIHNhdGlzZmllZCwgdGhlIGNsaWVudCB0aGVuIGRl
Y3J5cHRzIHRoZQ0KICAgZW5jLXBhcnQgZmllbGQgb2YgdGhlIEtEQy1SRVAgaW4gdGhlIEFTLVJF
UCB1c2luZyB0aGUgQVMgcmVwbHkga2V5LA0KICAgYW5kIHRoZW4gcHJvY2VlZHMgYXMgZGVzY3Jp
YmVkIGluIFtSRkM0MTIwXS4NCg0KMy4zLiAgSW50ZXJvcGVyYWJpbGl0eSBSZXF1aXJlbWVudHMN
Cg0KICAgVGhlIGNsaWVudCBNVVNUIGJlIGNhcGFibGUgb2Ygc2VuZGluZyBhIHNldCBvZiBjZXJ0
aWZpY2F0ZXMNCiAgIHN1ZmZpY2llbnQgdG8gYWxsb3cgdGhlIEtEQyB0byBjb25zdHJ1Y3QgYSBj
ZXJ0aWZpY2F0aW9uIHBhdGggZm9yIHRoZQ0KICAgY2xpZW50J3MgY2VydGlmaWNhdGUsIGlmIHRo
ZSBjb3JyZWN0IHNldCBvZiBjZXJ0aWZpY2F0ZXMgaXMgcHJvdmlkZWQNCiAgIHRocm91Z2ggY29u
ZmlndXJhdGlvbiBvciBwb2xpY3kuDQoNCiAgIElmIHRoZSBjbGllbnQgc2VuZHMgYWxsIHRoZSBY
LjUwOSBjZXJ0aWZpY2F0ZXMgb24gYSBjZXJ0aWZpY2F0aW9uDQogICBwYXRoIHRvIGEgdHJ1c3Qg
YW5jaG9yIGFjY2VwdGFibGUgYnkgdGhlIEtEQywgYW5kIHRoZSBLREMgY2FuIG5vdA0KICAgdmVy
aWZ5IHRoZSBjbGllbnQncyBwdWJsaWMga2V5IG90aGVyd2lzZSwgdGhlIEtEQyBNVVNUIGJlIGFi
bGUgdG8NCiAgIHByb2Nlc3MgcGF0aCB2YWxpZGF0aW9uIGZvciB0aGUgY2xpZW50J3MgY2VydGlm
aWNhdGUgYmFzZWQgb24gdGhlDQogICBjZXJ0aWZpY2F0ZXMgaW4gdGhlIHJlcXVlc3QuDQoNCiAg
IFRoZSBLREMgTVVTVCBiZSBjYXBhYmxlIG9mIHNlbmRpbmcgYSBzZXQgb2YgY2VydGlmaWNhdGVz
IHN1ZmZpY2llbnQNCiAgIHRvIGFsbG93IHRoZSBjbGllbnQgdG8gY29uc3RydWN0IGEgY2VydGlm
aWNhdGlvbiBwYXRoIGZvciB0aGUgS0RDJ3MNCiAgIGNlcnRpZmljYXRlLCBpZiB0aGUgY29ycmVj
dCBzZXQgb2YgY2VydGlmaWNhdGVzIGlzIHByb3ZpZGVkIHRocm91Z2gNCiAgIGNvbmZpZ3VyYXRp
b24gb3IgcG9saWN5Lg0KDQogICBJZiB0aGUgS0RDIHNlbmRzIGFsbCB0aGUgWC41MDkgY2VydGlm
aWNhdGVzIG9uIGEgY2VydGlmaWNhdGlvbiBwYXRoDQogICB0byBhIHRydXN0IGFuY2hvciBhY2Nl
cHRhYmxlIGJ5IHRoZSBjbGllbnQsIGFuZCB0aGUgY2xpZW50IGNhbiBub3QNCiAgIHZlcmlmeSB0
aGUgS0RDJ3MgcHVibGljIGtleSBvdGhlcndpc2UsIHRoZSBjbGllbnQgTVVTVCBiZSBhYmxlIHRv
DQogICBwcm9jZXNzIHBhdGggdmFsaWRhdGlvbiBmb3IgdGhlIEtEQydzIGNlcnRpZmljYXRlIGJh
c2VkIG9uIHRoZQ0KICAgY2VydGlmaWNhdGVzIGluIHRoZSByZXBseS4NCg0KMy40LiAgS0RDIElu
ZGljYXRpb24gb2YgUEtJTklUIFN1cHBvcnQNCg0KICAgSWYgcHJlLWF1dGhlbnRpY2F0aW9uIGlz
IHJlcXVpcmVkLCBidXQgd2FzIG5vdCBwcmVzZW50IGluIHRoZQ0KDQoNCg0KWmh1ICYgVHVuZyAg
ICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2Ug
MjZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBQS0lOSVQgICAgICAgICAg
ICAgICAgICAgICBKYW51YXJ5IDIwMDYNCg0KDQogICByZXF1ZXN0LCBwZXIgW1JGQzQxMjBdIGFu
IGVycm9yIG1lc3NhZ2Ugd2l0aCB0aGUgY29kZQ0KICAgS0RDX0VSUl9QUkVBVVRIX0ZBSUxFRCBp
cyByZXR1cm5lZCBhbmQgYSBNRVRIT0QtREFUQSBvYmplY3Qgd2lsbCBiZQ0KICAgc3RvcmVkIGlu
IHRoZSBlLWRhdGEgZmllbGQgb2YgdGhlIEtSQi1FUlJPUiBtZXNzYWdlIHRvIHNwZWNpZnkgd2hp
Y2gNCiAgIHByZS1hdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIGFyZSBhY2NlcHRhYmxlLiAgVGhl
IEtEQyBjYW4gdGhlbg0KICAgaW5kaWNhdGUgdGhlIHN1cHBvcnQgb2YgUEtJTklUIGJ5IGluY2x1
ZGluZyBhbiBlbXB0eSBlbGVtZW50IHdob3NlDQogICBwYWRhdGEtdHlwZSBpcyBQQV9QS19BU19S
RVEgaW4gdGhhdCBNRVRIT0QtREFUQSBvYmplY3QuDQoNCiAgIE90aGVyd2lzZSBpZiBpdCBpcyBy
ZXF1aXJlZCBieSB0aGUgS0RDJ3MgbG9jYWwgcG9saWN5IHRoYXQgdGhlIGNsaWVudA0KICAgbXVz
dCBiZSBwcmUtYXV0aGVudGljYXRlZCB1c2luZyB0aGUgcHJlLWF1dGhlbnRpY2F0aW9uIG1lY2hh
bmlzbQ0KICAgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQsIGJ1dCBubyBQS0lOSVQgcHJlLWF1
dGhlbnRpY2F0aW9uIHdhcw0KICAgcHJlc2VudCBpbiB0aGUgcmVxdWVzdCwgYW4gZXJyb3IgbWVz
c2FnZSB3aXRoIHRoZSBjb2RlDQogICBLRENfRVJSX1BSRUFVVEhfRkFJTEVEIFNIT1VMRCBiZSBy
ZXR1cm5lZC4NCg0KICAgS0RDcyBNVVNUIGxlYXZlIHRoZSBwYWRhdGEtdmFsdWUgZmllbGQgb2Yg
dGhlIFBBX1BLX0FTX1JFUSBlbGVtZW50IGluDQogICB0aGUgS1JCLUVSUk9SJ3MgTUVUSE9ELURB
VEEgZW1wdHkgKGkuZS4sIHNlbmQgYSB6ZXJvLWxlbmd0aCBPQ1RFVA0KICAgU1RSSU5HKSwgYW5k
IGNsaWVudHMgTVVTVCBpZ25vcmUgdGhpcyBhbmQgYW55IG90aGVyIHZhbHVlLiAgRnV0dXJlDQog
ICBleHRlbnNpb25zIHRvIHRoaXMgcHJvdG9jb2wgbWF5IHNwZWNpZnkgb3RoZXIgZGF0YSB0byBz
ZW5kIGluc3RlYWQgb2YNCiAgIGFuIGVtcHR5IE9DVEVUIFNUUklORy4NCg0KDQo0LiAgU2VjdXJp
dHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhlIHNlY3VyaXR5IG9mIGNyeXB0b2dyYXBoaWMgYWxn
b3JpdGhtcyBpcyBkZXBlbmRlbnQgb24gZ2VuZXJhdGluZw0KICAgc2VjcmV0IHF1YW50aXRpZXMg
W1JGQzQwODZdLiAgVGhlIG51bWJlciBvZiB0cnVseSByYW5kb20gYml0cyBpcw0KICAgZXh0cmVt
ZWx5IGltcG9ydGFudCB0byBkZXRlcm1pbmluZyB0aGUgYXR0YWNrIHJlc2lzdGFuY2Ugc3RyZW5n
dGggb2YNCiAgIHRoZSBjcnlwdG9zeXN0ZW0sIGZvciBleGFtcGxlLCB0aGUgc2VjcmV0IERpZmZp
ZS1IZWxsbWFuIGV4cG9uZW50cw0KICAgbXVzdCBiZSBjaG9zZW4gYmFzZWQgb24gbiB0cnVseSBy
YW5kb20gYml0cyAod2hlcmUgbiBpcyB0aGUgc3lzdGVtDQogICBzZWN1cml0eSByZXF1aXJlbWVu
dCkuICBUaGUgc2VjdXJpdHkgb2YgdGhlIG92ZXJhbGwgc3lzdGVtIGlzDQogICBzaWduaWZpY2Fu
dGx5IHdlYWtlbmVkIGJ5IHVzaW5nIGluc3VmZmljaWVudCByYW5kb20gaW5wdXRzOiBhDQogICBz
b3BoaXN0aWNhdGVkIGF0dGFja2VyIG1heSBmaW5kIGl0IGVhc2llciB0byByZXByb2R1Y2UgdGhl
DQogICBlbnZpcm9ubWVudCB0aGF0IHByb2R1Y2VkIHRoZSBzZWNyZXQgcXVhbnRpdGllcyBhbmQg
dG8gc2VhcmNoIHRoZQ0KICAgcmVzdWx0aW5nIHNtYWxsIHNldCBvZiBwb3NzaWJpbGl0aWVzIHRo
YW4gdG8gbG9jYXRlIHRoZSBxdWFudGl0aWVzIGluDQogICB0aGUgd2hvbGUgb2YgdGhlIHBvdGVu
dGlhbCBudW1iZXIgc3BhY2UuDQoNCiAgIEtlcmJlcm9zIGVycm9yIG1lc3NhZ2VzIGFyZSBub3Qg
aW50ZWdyaXR5IHByb3RlY3RlZCwgYXMgYSByZXN1bHQsIHRoZQ0KICAgZG9tYWluIHBhcmFtZXRl
cnMgc2VudCBieSB0aGUgS0RDIGFzIFRELURILVBBUkFNRVRFUlMgY2FuIGJlIHRhbXBlcmVkDQog
ICB3aXRoIGJ5IGFuIGF0dGFja2VyIHNvIHRoYXQgdGhlIHNldCBvZiBkb21haW4gcGFyYW1ldGVy
cyBzZWxlY3RlZA0KICAgY291bGQgYmUgZWl0aGVyIHdlYWtlciBvciBub3QgbXV0dWFsbHkgcHJl
ZmVycmVkLiAgTG9jYWwgcG9saWN5IGNhbg0KICAgY29uZmlndXJlIHNldHMgb2YgZG9tYWluIHBh
cmFtZXRlcnMgYWNjZXB0YWJsZSBsb2NhbGx5LCBvciBkaXNhbGxvdw0KICAgdGhlIG5lZ290aWF0
aW9uIG9mIERIIGRvbWFpbiBwYXJhbWV0ZXJzLg0KDQogICBUaGUgc3ltbWV0cmljIHJlcGx5IGtl
eSBzaXplIGFuZCBEaWZmaWUtSGVsbG1hbiBmaWVsZCBzaXplIG9yIFJTQQ0KICAgbW9kdWx1cyBz
aXplIHNob3VsZCBiZSBjaG9zZW4gc28gYXMgdG8gcHJvdmlkZSBzdWZmaWNpZW50DQogICBjcnlw
dG9ncmFwaGljIHNlY3VyaXR5IFtSRkMzNzY2XS4NCg0KICAgV2hlbiBNT0RQIERpZmZpZS1IZWxs
bWFuIGlzIHVzZWQsIHRoZSBleHBvbmVudHMgc2hvdWxkIGhhdmUgYXQgbGVhc3QNCiAgIHR3aWNl
IGFzIG1hbnkgYml0cyBhcyB0aGUgc3ltbWV0cmljIGtleXMgdGhhdCB3aWxsIGJlIGRlcml2ZWQg
ZnJvbQ0KICAgdGhlbSBbT0RMOTldLg0KDQoNCg0KWmh1ICYgVHVuZyAgICAgICAgICAgICAgICBF
eHBpcmVzIEp1bHkgMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMjddDQoMDQpJbnRlcm5l
dC1EcmFmdCAgICAgICAgICAgICAgICAgICBQS0lOSVQgICAgICAgICAgICAgICAgICAgICBKYW51
YXJ5IDIwMDYNCg0KDQogICBQS0lOSVQgcmFpc2VzIGNlcnRhaW4gc2VjdXJpdHkgY29uc2lkZXJh
dGlvbnMgYmV5b25kIHRob3NlIHRoYXQgY2FuDQogICBiZSByZWd1bGF0ZWQgc3RyaWN0bHkgaW4g
cHJvdG9jb2wgZGVmaW5pdGlvbnMuICBXZSB3aWxsIGFkZHJlc3MgdGhlbQ0KICAgaW4gdGhpcyBz
ZWN0aW9uLg0KDQogICBQS0lOSVQgZXh0ZW5kcyB0aGUgY3Jvc3MtcmVhbG0gbW9kZWwgdG8gdGhl
IHB1YmxpYy1rZXkNCiAgIGluZnJhc3RydWN0dXJlLiAgVXNlcnMgb2YgUEtJTklUIG11c3QgdW5k
ZXJzdGFuZCBzZWN1cml0eSBwb2xpY2llcw0KICAgYW5kIHByb2NlZHVyZXMgYXBwcm9wcmlhdGUg
dG8gdGhlIHVzZSBvZiBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlcw0KICAgW1JGQzMyODBdLg0K
DQogICBJbiBvcmRlciB0byB0cnVzdCBhIEtEQyBjZXJ0aWZpY2F0ZSB0aGF0IGlzIGNlcnRpZmll
ZCBieSBhIENBIGFzIGENCiAgIEtEQyBjZXJ0aWZpY2F0ZSBmb3IgYSB0YXJnZXQgcmVhbG0gKGZv
ciBleGFtcGxlLCBieSBhc3NlcnRpbmcgdGhlIFRHUw0KICAgbmFtZSBvZiB0aGF0IEtlcmJlcm9z
IHJlYWxtIGFzIGFuIGlkLXBraW5pdC1zYW4gU0FOIGFuZC9vcg0KICAgcmVzdHJpY3RpbmcgdGhl
IGNlcnRpZmljYXRlIHVzYWdlIGJ5IHVzaW5nIHRoZSBpZC1wa2luaXQtS1BLZGMgRUtVLA0KICAg
YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4yLjQpLCB0aGUgY2xpZW50IE1VU1QgdmVyaWZ5IHRo
YXQgdGhlIEtEQw0KICAgY2VydGlmaWNhdGUncyBpc3N1aW5nIENBIGlzIGF1dGhvcml6ZWQgdG8g
aXNzdWUgS0RDIGNlcnRpZmljYXRlcyBmb3INCiAgIHRoYXQgdGFyZ2V0IHJlYWxtLiAgT3RoZXJ3
aXNlLCB0aGUgYmluZGluZyBiZXR3ZWVuIHRoZSBLREMNCiAgIGNlcnRpZmljYXRlIGFuZCB0aGUg
S0RDIG9mIHRoZSB0YXJnZXQgcmVhbG0gaXMgbm90IGVzdGFibGlzaGVkLg0KDQogICBIb3cgdG8g
dmFsaWRhdGUgdGhpcyBhdXRob3JpemF0aW9uIGlzIGEgbWF0dGVyIG9mIGxvY2FsIHBvbGljeS4g
IEENCiAgIHdheSB0byBhY2hpZXZlIHRoaXMgaXMgdGhlIGNvbmZpZ3VyYXRpb24gb2Ygc3BlY2lm
aWMgc2V0cyBvZg0KICAgaW50ZXJtZWRpYXJ5IENBcyBhbmQgdHJ1c3QgYW5jaG9ycywgb25lIG9m
IHdoaWNoIG11c3QgYmUgb24gdGhlIEtEQw0KICAgY2VydGlmaWNhdGUncyBjZXJ0aWZpY2F0aW9u
IHBhdGggW1JGQzMyODBdOyBhbmQgZm9yIGVhY2ggQ0Egb3IgdHJ1c3QNCiAgIGFuY2hvciB0aGUg
cmVhbG1zIGZvciB3aGljaCBpdCBpcyBhbGxvd2VkIHRvIGlzc3VlIGNlcnRpZmljYXRlcy4NCg0K
ICAgSW4gYWRkaXRpb24sIGlmIGFueSBDQSBpcyB0cnVzdGVkIHRvIGlzc3VlIEtEQyBjZXJ0aWZp
Y2F0ZXMgY2FuIGFsc28NCiAgIGlzc3VlIG90aGVyIGtpbmRzIG9mIGNlcnRpZmljYXRlcywgdGhl
biBsb2NhbCBwb2xpY3kgbXVzdCBiZSBhYmxlIHRvDQogICBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRo
ZW06IGZvciBleGFtcGxlLCBpdCBjb3VsZCByZXF1aXJlIHRoYXQgS0RDDQogICBjZXJ0aWZpY2F0
ZXMgY29udGFpbiB0aGUgaWQtcGtpbml0LUtQS2RjIEVLVSBvciB0aGF0IHRoZSByZWFsbSBiZQ0K
ICAgc3BlY2lmaWVkIHdpdGggdGhlIGlkLXBraW5pdC1zYW4gU0FOLg0KDQogICBJdCBpcyB0aGUg
cmVzcG9uc2liaWxpdHkgb2YgdGhlIFBLSSBhZG1pbmlzdHJhdG9ycyBmb3IgYW4NCiAgIG9yZ2Fu
aXphdGlvbiB0byBlbnN1cmUgdGhhdCBLREMgY2VydGlmaWNhdGVzIGFyZSBvbmx5IGlzc3VlZCB0
byBLRENzLA0KICAgYW5kIHRoYXQgY2xpZW50cyBjYW4gYXNjZXJ0YWluIHRoaXMgdXNpbmcgdGhl
aXIgbG9jYWwgcG9saWN5Lg0KDQogICBTdGFuZGFyZCBLZXJiZXJvcyBhbGxvd3MgdGhlIHBvc3Np
YmlsaXR5IG9mIGludGVyYWN0aW9ucyBiZXR3ZWVuDQogICBjcnlwdG9zeXN0ZW1zIG9mIHZhcnlp
bmcgc3RyZW5ndGhzOyB0aGlzIGRvY3VtZW50IGFkZHMgaW50ZXJhY3Rpb25zDQogICB3aXRoIHB1
YmxpYy1rZXkgY3J5cHRvc3lzdGVtcyB0byBLZXJiZXJvcy4gIFNvbWUgYWRtaW5pc3RyYXRpdmUN
CiAgIHBvbGljaWVzIG1heSBhbGxvdyB0aGUgdXNlIG9mIHJlbGF0aXZlbHkgd2VhayBwdWJsaWMg
a2V5cy4gIFdoZW4NCiAgIHVzaW5nIHN1Y2ggd2VhayBhc3ltbWV0cmljIGtleXMgdG8gcHJvdGVj
dC9leGNoYW5nZSBzdHJvbmdlcg0KICAgc3ltbWV0cmljIEtleXMsIHRoZSBhdHRhY2sgcmVzaXN0
YW50IHN0cmVuZ3RoIG9mIHRoZSBvdmVyYWxsIHN5c3RlbQ0KICAgaXMgbm8gYmV0dGVyIHRoYW4g
dGhhdCBvZiB0aGVzZSB3ZWFrIGtleXMgW1JGQzM3NjZdLg0KDQogICBQS0lOSVQgcmVxdWlyZXMg
a2V5cyBmb3Igc3ltbWV0cmljIGNyeXB0b3N5c3RlbXMgdG8gYmUgZ2VuZXJhdGVkLg0KICAgU29t
ZSBzdWNoIHN5c3RlbXMgY29udGFpbiAid2VhayIga2V5cy4gIEZvciByZWNvbW1lbmRhdGlvbnMg
cmVnYXJkaW5nDQogICB0aGVzZSB3ZWFrIGtleXMsIHNlZSBbUkZDNDEyMF0uDQoNCiAgIFBLSU5J
VCBhbGxvd3MgdGhlIHVzZSBvZiB0aGUgc2FtZSBSU0Ega2V5IHBhaXIgZm9yIGVuY3J5cHRpb24g
YW5kDQogICBzaWduaW5nIHdoZW4gZG9pbmcgUlNBIGVuY3J5cHRpb24gYmFzZWQga2V5IGRlbGl2
ZXJ5LiAgVGhpcyBpcyBub3QNCg0KDQoNClpodSAmIFR1bmcgICAgICAgICAgICAgICAgRXhwaXJl
cyBKdWx5IDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDA0KSW50ZXJuZXQtRHJh
ZnQgICAgICAgICAgICAgICAgICAgUEtJTklUICAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAy
MDA2DQoNCg0KICAgcmVjb21tZW5kZWQgdXNhZ2Ugb2YgUlNBIGtleXMgW1JGQzM0NDddLCBieSB1
c2luZyBESCBiYXNlZCBrZXkNCiAgIGRlbGl2ZXJ5IHRoaXMgaXMgYXZvaWRlZC4NCg0KICAgQ2Fy
ZSBzaG91bGQgYmUgdGFrZW4gaW4gaG93IGNlcnRpZmljYXRlcyBhcmUgY2hvc2VuIGZvciB0aGUg
cHVycG9zZXMNCiAgIG9mIGF1dGhlbnRpY2F0aW9uIHVzaW5nIFBLSU5JVC4gIFNvbWUgbG9jYWwg
cG9saWNpZXMgbWF5IHJlcXVpcmUgdGhhdA0KICAga2V5IGVzY3JvdyBiZSB1c2VkIGZvciBjZXJ0
YWluIGNlcnRpZmljYXRlIHR5cGVzLiAgRGVwbG95ZXJzIG9mDQogICBQS0lOSVQgc2hvdWxkIGJl
IGF3YXJlIG9mIHRoZSBpbXBsaWNhdGlvbnMgb2YgdXNpbmcgY2VydGlmaWNhdGVzIHRoYXQNCiAg
IGhhdmUgZXNjcm93ZWQga2V5cyBmb3IgdGhlIHB1cnBvc2VzIG9mIGF1dGhlbnRpY2F0aW9uLiAg
QmVjYXVzZQ0KICAgc2lnbmluZyBvbmx5IGNlcnRpZmljYXRlcyBhcmUgbm9ybWFsbHkgbm90IGVz
Y3Jvd2VkLCBieSB1c2luZyBESA0KICAgYmFzZWQga2V5IGRlbGl2ZXJ5IHRoaXMgaXMgYXZvaWRl
ZC4NCg0KICAgUEtJTklUIGRvZXMgbm90IHByb3ZpZGUgZm9yIGEgInJldHVybiByb3V0YWJpbGl0
eSIgdGVzdCB0byBwcmV2ZW50DQogICBhdHRhY2tlcnMgZnJvbSBtb3VudGluZyBhIGRlbmlhbC1v
Zi1zZXJ2aWNlIGF0dGFjayBvbiB0aGUgS0RDIGJ5DQogICBjYXVzaW5nIGl0IHRvIHBlcmZvcm0g
dW5uZWNlc3NhcnkgYW5kIGV4cGVuc2l2ZSBwdWJsaWMta2V5DQogICBvcGVyYXRpb25zLiAgU3Ry
aWN0bHkgc3BlYWtpbmcsIHRoaXMgaXMgYWxzbyB0cnVlIG9mIHN0YW5kYXJkDQogICBLZXJiZXJv
cywgYWx0aG91Z2ggdGhlIHBvdGVudGlhbCBjb3N0IGlzIG5vdCBhcyBncmVhdCwgYmVjYXVzZQ0K
ICAgc3RhbmRhcmQgS2VyYmVyb3MgZG9lcyBub3QgbWFrZSB1c2Ugb2YgcHVibGljLWtleSBjcnlw
dG9ncmFwaHkuICBCeQ0KICAgdXNpbmcgREggYmFzZWQga2V5IGRlbGl2ZXJ5IGFuZCByZXVzaW5n
IERIIGtleXMsIHRoZSBuZWNlc3NhcnkgY3J5cHRvDQogICBwcm9jZXNzaW5nIGNvc3QgcGVyIHJl
cXVlc3QgY2FuIGJlIG1pbmltaXplZC4NCg0KICAgV2hlbiB0aGUgRGlmZmllLUhlbGxtYW4ga2V5
IGV4Y2hhbmdlIG1ldGhvZCBpcyB1c2VkLCBhZGRpdGlvbmFsIHByZS0NCiAgIGF1dGhlbnRpY2F0
aW9uIGRhdGEgW1JGQzQxMjBdIChpbiBhZGRpdGlvbiB0byB0aGUgUEFfUEtfQVNfUkVRIGFzDQog
ICBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbikgaXMgbm90IGJvdW5kIHRvIHRoZSBBU19S
RVEgYnkgdGhlDQogICBtZWNoYW5pc21zIGRpc2N1c3NlZCBpbiB0aGlzIHNwZWNpZmljYXRpb24g
KG1lYW5pbmcgaXQgbWF5IGJlIGRyb3BwZWQNCiAgIG9yIGFkZGVkIGJ5IGF0dGFja2VycyB3aXRo
b3V0IGJlaW5nIGRldGVjdGVkIGJ5IGVpdGhlciB0aGUgY2xpZW50IG9yDQogICB0aGUgS0RDKS4g
IERlc2lnbmVycyBvZiBhZGRpdGlvbmFsIHByZS1hdXRoZW50aWNhdGlvbiBkYXRhIHNob3VsZA0K
ICAgdGFrZSB0aGF0IGludG8gY29uc2lkZXJhdGlvbiBpZiBzdWNoIGFkZGl0aW9uYWwgcHJlLWF1
dGhlbnRpY2F0aW9uDQogICBkYXRhIGNhbiBiZSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggdGhl
IFBBX1BLX0FTX1JFUS4gIFRoZSBmdXR1cmUNCiAgIHdvcmsgb2YgdGhlIEtlcmJlcm9zIHdvcmtp
bmcgZ3JvdXAgaXMgZXhwZWN0ZWQgdG8gdXBkYXRlIHRoZSBoYXNoDQogICBhbGdvcml0aG1zIHNw
ZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGFuZCBwcm92aWRlIGEgZ2VuZXJpYyBtZWNoYW5pc20N
CiAgIHRvIGJpbmQgYWRkaXRpb25hbCBwcmUtYXV0aGVudGljYXRpb24gZGF0YSB3aXRoIHRoZSBh
Y2NvbXBhbnlpbmcNCiAgIEFTX1JFUS4NCg0KDQo1LiAgQWNrbm93bGVkZ2VtZW50cw0KDQogICBU
aGUgZm9sbG93aW5nIHBlb3BsZSBoYXZlIG1hZGUgc2lnbmlmaWNhbnQgY29udHJpYnV0aW9ucyB0
byB0aGlzDQogICBkcmFmdDogUGF1bCBMZWFjaCwgU3RlZmFuIFNhbnRlc3NvbiwgU2FtIEhhcnRt
YW4sIExvdmUgSG9ybnF1aXN0DQogICBBc3RyYW5kLCBLZW4gUmFlYnVybiwgTmljb2xhcyBXaWxs
aWFtcywgSm9obiBXcmF5LCBUb20gWXUsIEplZmZyZXkNCiAgIEh1dHplbG1hbiwgRGF2aWQgQ3Jv
c3MsIERhbiBTaW1vbiwgS2FydGhpayBKYWdhbmF0aGFuLCBDaGFza2llbCBNDQogICBHcnVuZG1h
biBhbmQgSmVmZnJleSBBbHRtYW4uDQoNCiAgIEFuZHJlIFNjZWRyb3YsIEFhcm9uIEQuIEphZ2dh
cmQsIElsaWFubyBDZXJ2ZXNhdG8sIEpvZS1LYWkgVHNheSBhbmQNCiAgIENocmlzIFdhbHN0YWQg
ZGlzY292ZXJlZCBhIGJpbmRpbmcgaXNzdWUgYmV0d2VlbiB0aGUgQVMtUkVRIGFuZCBBUy0NCiAg
IFJFUCBpbiBkcmFmdCAtMjYsIHRoZSBhc0NoZWNrc3VtIGZpZWxkIHdhcyBhZGRlZCBhcyB0aGUg
cmVzdWx0Lg0KDQogICBTcGVjaWFsIHRoYW5rcyB0byBDbGlmZm9yZCBOZXVtYW4sIE1hdHRoZXcg
SHVyLCBTYXNoYSBNZWR2aW5za3kgYW5kDQogICBKb25hdGhhbiBUcm9zdGxlIHdobyB3cm90ZSBl
YXJsaWVyIHZlcnNpb25zIG9mIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQpaaHUgJiBUdW5nICAgICAg
ICAgICAgICAgIEV4cGlyZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAyOV0N
CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAgICAgICAgICAgICAg
ICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgIFRoZSBhdXRob3JzIGFyZSBpbmRlYnRlZCB0byB0
aGUgS2VyYmVyb3Mgd29ya2luZyBncm91cCBjaGFpciBKZWZmcmV5DQogICBIdXR6ZWxtYW4gd2hv
IGtlcHQgdHJhY2sgb2YgdmFyaW91cyBpc3N1ZXMgYW5kIHdhcyBlbm9ybW91c2x5IGhlbHBmdWwN
CiAgIGR1cmluZyB0aGUgY3JlYXRpb24gb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgU29tZSBvZiB0
aGUgaWRlYXMgb24gd2hpY2ggdGhpcyBkb2N1bWVudCBpcyBiYXNlZCBhcm9zZSBkdXJpbmcNCiAg
IGRpc2N1c3Npb25zIG92ZXIgc2V2ZXJhbCB5ZWFycyBiZXR3ZWVuIG1lbWJlcnMgb2YgdGhlIFNB
QUcsIHRoZSBJRVRGDQogICBDQVQgd29ya2luZyBncm91cCwgYW5kIHRoZSBQU1JHLCByZWdhcmRp
bmcgaW50ZWdyYXRpb24gb2YgS2VyYmVyb3MNCiAgIGFuZCBTUFguICBTb21lIGlkZWFzIGhhdmUg
YWxzbyBiZWVuIGRyYXduIGZyb20gdGhlIERBU1Mgc3lzdGVtLg0KICAgVGhlc2UgY2hhbmdlcyBh
cmUgYnkgbm8gbWVhbnMgZW5kb3JzZWQgYnkgdGhlc2UgZ3JvdXBzLiAgVGhpcyBpcyBhbg0KICAg
YXR0ZW1wdCB0byByZXZpdmUgc29tZSBvZiB0aGUgZ29hbHMgb2YgdGhvc2UgZ3JvdXBzLCBhbmQg
dGhpcw0KICAgZG9jdW1lbnQgYXBwcm9hY2hlcyB0aG9zZSBnb2FscyBwcmltYXJpbHkgZnJvbSB0
aGUgS2VyYmVyb3MNCiAgIHBlcnNwZWN0aXZlLg0KDQogICBMYXN0bHksIGNvbW1lbnRzIGZyb20g
Z3JvdXBzIHdvcmtpbmcgb24gc2ltaWxhciBpZGVhcyBpbiBEQ0UgaGF2ZQ0KICAgYmVlbiBpbnZh
bHVhYmxlLg0KDQoNCjYuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQg
aGFzIG5vIGFjdGlvbnMgZm9yIElBTkEuDQoNCg0KNy4gIFJlZmVyZW5jZXMNCg0KNy4xLiAgTm9y
bWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW0lFRUUxMzYzXQ0KICAgICAgICAgICAgICBJRUVFLCAi
U3RhbmRhcmQgU3BlY2lmaWNhdGlvbnMgZm9yIFB1YmxpYyBLZXkgDQogICAgICAgICAgICAgIENy
eXB0b2dyYXBoeSIsIElFRUUgMTM2MywgMjAwMC4NCg0KICAgW1JGQzIxMTldICBCcmFkbmVyLCBT
LiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAgICAgICAgICAg
UmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KICAg
W1JGQzI0MTJdICBPcm1hbiwgSC4sICJUaGUgT0FLTEVZIEtleSBEZXRlcm1pbmF0aW9uIFByb3Rv
Y29sIiwNCiAgICAgICAgICAgICAgUkZDIDI0MTIsIE5vdmVtYmVyIDE5OTguDQoNCiAgIFtSRkMy
NjMxXSAgUmVzY29ybGEsIEUuLCAiRGlmZmllLUhlbGxtYW4gS2V5IEFncmVlbWVudCBNZXRob2Qi
LA0KICAgICAgICAgICAgICBSRkMgMjYzMSwgSnVuZSAxOTk5Lg0KDQogICBbUkZDMzI3OV0gIEJh
c3NoYW0sIEwuLCBQb2xrLCBXLiwgYW5kIFIuIEhvdXNsZXksICJBbGdvcml0aG1zIGFuZA0KICAg
ICAgICAgICAgICBJZGVudGlmaWVycyBmb3IgdGhlIEludGVybmV0IFguNTA5IFB1YmxpYyBLZXkN
CiAgICAgICAgICAgICAgSW5mcmFzdHJ1Y3R1cmUgQ2VydGlmaWNhdGUgYW5kIENlcnRpZmljYXRl
IFJldm9jYXRpb24gTGlzdA0KICAgICAgICAgICAgICAoQ1JMKSBQcm9maWxlIiwgUkZDIDMyNzks
IEFwcmlsIDIwMDIuDQoNCiAgIFtSRkMzMjgwXSAgSG91c2xleSwgUi4sIFBvbGssIFcuLCBGb3Jk
LCBXLiwgYW5kIEQuIFNvbG8sICJJbnRlcm5ldA0KICAgICAgICAgICAgICBYLjUwOSBQdWJsaWMg
S2V5IEluZnJhc3RydWN0dXJlIENlcnRpZmljYXRlIGFuZA0KICAgICAgICAgICAgICBDZXJ0aWZp
Y2F0ZSBSZXZvY2F0aW9uIExpc3QgKENSTCkgUHJvZmlsZSIsIFJGQyAzMjgwLA0KICAgICAgICAg
ICAgICBBcHJpbCAyMDAyLg0KDQoNCg0KWmh1ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBpcmVz
IEp1bHkgMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMzBdDQoMDQpJbnRlcm5ldC1EcmFm
dCAgICAgICAgICAgICAgICAgICBQS0lOSVQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIw
MDYNCg0KDQogICBbUkZDMzM3MF0gIEhvdXNsZXksIFIuLCAiQ3J5cHRvZ3JhcGhpYyBNZXNzYWdl
IFN5bnRheCAoQ01TKQ0KICAgICAgICAgICAgICBBbGdvcml0aG1zIiwgUkZDIDMzNzAsIEF1Z3Vz
dCAyMDAyLg0KDQogICBbUkZDMzQ0N10gIEpvbnNzb24sIEouIGFuZCBCLiBLYWxpc2tpLCAiUHVi
bGljLUtleSBDcnlwdG9ncmFwaHkNCiAgICAgICAgICAgICAgU3RhbmRhcmRzIChQS0NTKSAjMTog
UlNBIENyeXB0b2dyYXBoeSBTcGVjaWZpY2F0aW9ucw0KICAgICAgICAgICAgICBWZXJzaW9uIDIu
MSIsIFJGQyAzNDQ3LCBGZWJydWFyeSAyMDAzLg0KDQogICBbUkZDMzUyNl0gIEtpdmluZW4sIFQu
IGFuZCBNLiBLb2pvLCAiTW9yZSBNb2R1bGFyIEV4cG9uZW50aWFsIChNT0RQKQ0KICAgICAgICAg
ICAgICBEaWZmaWUtSGVsbG1hbiBncm91cHMgZm9yIEludGVybmV0IEtleSBFeGNoYW5nZSAoSUtF
KSIsDQogICAgICAgICAgICAgIFJGQyAzNTI2LCBNYXkgMjAwMy4NCg0KICAgW1JGQzM1NjVdICBT
Y2hhYWQsIEouLCAiVXNlIG9mIHRoZSBBZHZhbmNlZCBFbmNyeXB0aW9uIFN0YW5kYXJkIChBRVMp
DQogICAgICAgICAgICAgIEVuY3J5cHRpb24gQWxnb3JpdGhtIGluIENyeXB0b2dyYXBoaWMgTWVz
c2FnZSBTeW50YXgNCiAgICAgICAgICAgICAgKENNUykiLCBSRkMgMzU2NSwgSnVseSAyMDAzLg0K
DQogICBbUkZDMzc2Nl0gIE9ybWFuLCBILiBhbmQgUC4gSG9mZm1hbiwgIkRldGVybWluaW5nIFN0
cmVuZ3RocyBGb3INCiAgICAgICAgICAgICAgUHVibGljIEtleXMgVXNlZCBGb3IgRXhjaGFuZ2lu
ZyBTeW1tZXRyaWMgS2V5cyIsIEJDUCA4NiwNCiAgICAgICAgICAgICAgUkZDIDM3NjYsIEFwcmls
IDIwMDQuDQoNCiAgIFtSRkMzODUyXSAgSG91c2xleSwgUi4sICJDcnlwdG9ncmFwaGljIE1lc3Nh
Z2UgU3ludGF4IChDTVMpIiwNCiAgICAgICAgICAgICAgUkZDIDM4NTIsIEp1bHkgMjAwNC4NCg0K
ICAgW1JGQzM5NjFdICBSYWVidXJuLCBLLiwgIkVuY3J5cHRpb24gYW5kIENoZWNrc3VtIFNwZWNp
ZmljYXRpb25zIGZvcg0KICAgICAgICAgICAgICBLZXJiZXJvcyA1IiwgUkZDIDM5NjEsIEZlYnJ1
YXJ5IDIwMDUuDQoNCiAgIFtSRkMzOTYyXSAgUmFlYnVybiwgSy4sICJBZHZhbmNlZCBFbmNyeXB0
aW9uIFN0YW5kYXJkIChBRVMpDQogICAgICAgICAgICAgIEVuY3J5cHRpb24gZm9yIEtlcmJlcm9z
IDUiLCBSRkMgMzk2MiwgRmVicnVhcnkgMjAwNS4NCg0KICAgW1JGQzQwODZdICBFYXN0bGFrZSwg
RC4sIFNjaGlsbGVyLCBKLiwgYW5kIFMuIENyb2NrZXIsICJSYW5kb21uZXNzDQogICAgICAgICAg
ICAgIFJlcXVpcmVtZW50cyBmb3IgU2VjdXJpdHkiLCBCQ1AgMTA2LCBSRkMgNDA4NiwgSnVuZSAy
MDA1Lg0KDQogICBbUkZDNDEyMF0gIE5ldW1hbiwgQy4sIFl1LCBULiwgSGFydG1hbiwgUy4sIGFu
ZCBLLiBSYWVidXJuLCAiVGhlDQogICAgICAgICAgICAgIEtlcmJlcm9zIE5ldHdvcmsgQXV0aGVu
dGljYXRpb24gU2VydmljZSAoVjUpIiwgUkZDIDQxMjAsDQogICAgICAgICAgICAgIEp1bHkgMjAw
NS4NCg0KICAgW1g2ODBdICAgICBJVFUtVCBSZWNvbW1lbmRhdGlvbiBYLjY4MCAoMjAwMikgfCBJ
U08vSUVDIDg4MjQtMToyMDAyLCANCiAgICAgICAgICAgICAgSW5mb3JtYXRpb24gdGVjaG5vbG9n
eSAtIEFic3RyYWN0IFN5bnRheCBOb3RhdGlvbiBPbmUgDQogICAgICAgICAgICAgIChBU04uMSk6
IFNwZWNpZmljYXRpb24gb2YgYmFzaWMgbm90YXRpb24uDQoNCiAgIFtYNjkwXSAgICAgSVRVLVQg
UmVjb21tZW5kYXRpb24gWC42OTAgKDIwMDIpIHwgSVNPL0lFQyA4ODI1LTE6MjAwMiwgDQogICAg
ICAgICAgICAgIEluZm9ybWF0aW9uIHRlY2hub2xvZ3kgLSBBU04uMSBlbmNvZGluZyBSdWxlczog
U3BlY2lmaWNhdGlvbiANCiAgICAgICAgICAgICAgb2YgQmFzaWMgRW5jb2RpbmcgUnVsZXMgKEJF
UiksIENhbm9uaWNhbCBFbmNvZGluZyBSdWxlcyANCiAgICAgICAgICAgICAgKENFUikgYW5kIERp
c3Rpbmd1aXNoZWQgRW5jb2RpbmcgUnVsZXMgKERFUikuDQoNCjcuMi4gIEluZm9ybWF0aXZlIFJl
ZmVyZW5jZXMNCg0KICAgW0xFTlNUUkFdICBMZW5zdHJhLCBBLiBhbmQgRS4gVmVyaGV1bCwgIlNl
bGVjdGluZyBDcnlwdG9ncmFwaGljIEtleSANCiAgICAgICAgICAgICAgU2l6ZXMiLCBKb3VybmFs
IG9mIENyeXB0b2xvZ3kgMTQgKDIwMDEpIDI1NS0yOTMuDQogICANCiAgIFtPREw5OV0gICAgT2Rs
eXprbywgQS4sICJEaXNjcmV0ZSBsb2dhcml0aG1zOiBUaGUgcGFzdCBhbmQgdGhlDQogICAgICAg
ICAgICAgIGZ1dHVyZSwgRGVzaWducywgQ29kZXMsIGFuZCBDcnlwdG9ncmFwaHkgKDE5OTkpIi4N
Cg0KICAgICAgICAgICAgICBBcHJpbCAxOTk5Lg0KDQogICBbUkZDNDEyMV0gIFpodSwgTC4sIEph
Z2FuYXRoYW4sIEsuLCBhbmQgUy4gSGFydG1hbiwgIlRoZSBLZXJiZXJvcw0KICAgICAgICAgICAg
ICBWZXJzaW9uIDUgR2VuZXJpYyBTZWN1cml0eSBTZXJ2aWNlIEFwcGxpY2F0aW9uIFByb2dyYW0N
CiAgICAgICAgICAgICAgSW50ZXJmYWNlIChHU1MtQVBJKSBNZWNoYW5pc206IFZlcnNpb24gMiIs
IFJGQyA0MTIxLA0KICAgICAgICAgICAgICBKdWx5IDIwMDUuDQoNCiAgIFtSRkM0MTU4XSAgQ29v
cGVyLCBNLiwgRHphbWJhc293LCBZLiwgSGVzc2UsIFAuLCBKb3NlcGgsIFMuLCBhbmQgUi4NCiAg
ICAgICAgICAgICAgTmljaG9sYXMsICJJbnRlcm5ldCBYLjUwOSBQdWJsaWMgS2V5IEluZnJhc3Ry
dWN0dXJlOg0KICAgICAgICAgICAgICBDZXJ0aWZpY2F0aW9uIFBhdGggQnVpbGRpbmciLCBSRkMg
NDE1OCwgU2VwdGVtYmVyIDIwMDUuDQoNCg0KQXBwZW5kaXggQS4gIFBLSU5JVCBBU04uMSBNb2R1
bGUNCg0KICAgICAgIEtlcmJlcm9zVjUtUEstSU5JVC1TUEVDIHsNCiAgICAgICAgICAgICAgIGlz
bygxKSBpZGVudGlmaWVkLW9yZ2FuaXphdGlvbigzKSBkb2QoNikgaW50ZXJuZXQoMSkNCiAgICAg
ICAgICAgICAgIHNlY3VyaXR5KDUpIGtlcmJlcm9zVjUoMikgbW9kdWxlcyg0KSBwa2luaXQoNSkN
CiAgICAgICB9IERFRklOSVRJT05TIEVYUExJQ0lUIFRBR1MgOjo9IEJFR0lODQoNCiAgICAgICBJ
TVBPUlRTDQogICAgICAgICAgIFN1YmplY3RQdWJsaWNLZXlJbmZvLCBBbGdvcml0aG1JZGVudGlm
aWVyDQogICAgICAgICAgICAgICBGUk9NIFBLSVgxRXhwbGljaXQ4OCB7IGlzbyAoMSkNCiAgICAg
ICAgICAgICAgICAgaWRlbnRpZmllZC1vcmdhbml6YXRpb24gKDMpIGRvZCAoNikgaW50ZXJuZXQg
KDEpDQogICAgICAgICAgICAgICAgIHNlY3VyaXR5ICg1KSBtZWNoYW5pc21zICg1KSBwa2l4ICg3
KSBpZC1tb2QgKDApDQogICAgICAgICAgICAgICAgIGlkLXBraXgxLWV4cGxpY2l0ICgxOCkgfQ0K
ICAgICAgICAgICAgICAgICAtLSBBcyBkZWZpbmVkIGluIFJGQyAzMjgwLg0KDQogICAgICAgICAg
IEtlcmJlcm9zVGltZSwgUHJpbmNpcGFsTmFtZSwgUmVhbG0sIEVuY3J5cHRpb25LZXkNCiAgICAg
ICAgICAgICAgIEZST00gS2VyYmVyb3NWNVNwZWMyIHsgaXNvKDEpIGlkZW50aWZpZWQtb3JnYW5p
emF0aW9uKDMpDQogICAgICAgICAgICAgICAgIGRvZCg2KSBpbnRlcm5ldCgxKSBzZWN1cml0eSg1
KSBrZXJiZXJvc1Y1KDIpDQogICAgICAgICAgICAgICAgIG1vZHVsZXMoNCkga3JiNXNwZWMyKDIp
IH0gOw0KDQogICAgICAgaWQtcGtpbml0IE9CSkVDVCBJREVOVElGSUVSIDo6PQ0KICAgICAgICAg
eyBpc28gKDEpIG9yZyAoMykgZG9kICg2KSBpbnRlcm5ldCAoMSkgc2VjdXJpdHkgKDUpDQogICAg
ICAgICAgIGtlcmJlcm9zdjUgKDIpIHBraW5pdCAoMykgfQ0KDQogICAgICAgaWQtcGtpbml0LWF1
dGhEYXRhICAgICAgT0JKRUNUIElERU5USUZJRVIgIDo6PSB7IGlkLXBraW5pdCAxIH0NCiAgICAg
ICBpZC1wa2luaXQtREhLZXlEYXRhICAgICBPQkpFQ1QgSURFTlRJRklFUiAgOjo9IHsgaWQtcGtp
bml0IDIgfQ0KICAgICAgIGlkLXBraW5pdC1ya2V5RGF0YSAgICAgIE9CSkVDVCBJREVOVElGSUVS
ICA6Oj0geyBpZC1wa2luaXQgMyB9DQogICAgICAgaWQtcGtpbml0LUtQQ2xpZW50QXV0aCAgT0JK
RUNUIElERU5USUZJRVIgIDo6PSB7IGlkLXBraW5pdCA0IH0NCg0KDQoNClpodSAmIFR1bmcgICAg
ICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDMy
XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgUEtJTklUICAgICAgICAgICAg
ICAgICAgICAgSmFudWFyeSAyMDA2DQoNCg0KICAgICAgIGlkLXBraW5pdC1LUEtkYyAgICAgICAg
IE9CSkVDVCBJREVOVElGSUVSICA6Oj0geyBpZC1wa2luaXQgNSB9DQoNCiAgICAgICBpZC1wa2lu
aXQtc2FuIE9CSkVDVCBJREVOVElGSUVSIDo6PQ0KICAgICAgICAgeyBpc28oMSkgb3JnKDMpIGRv
ZCg2KSBpbnRlcm5ldCgxKSBzZWN1cml0eSg1KSBrZXJiZXJvc3Y1KDIpDQogICAgICAgICAgIHg1
MDlTYW5BTiAoMikgfQ0KDQogICAgICAgcGEtcGstYXMtcmVxIElOVEVHRVIgOjo9ICAgICAgICAg
ICAgICAgICAgMTYNCiAgICAgICBwYS1way1hcy1yZXAgSU5URUdFUiA6Oj0gICAgICAgICAgICAg
ICAgICAxNw0KDQogICAgICAgYWQtaW5pdGlhbC12ZXJpZmllZC1jYXMgSU5URUdFUiA6Oj0gICAg
ICAgIDkNCg0KICAgICAgIHRkLXRydXN0ZWQtY2VydGlmaWVycyBJTlRFR0VSIDo6PSAgICAgICAg
MTA0DQogICAgICAgdGQtaW52YWxpZC1jZXJ0aWZpY2F0ZXMgSU5URUdFUiA6Oj0gICAgICAxMDUN
CiAgICAgICB0ZC1kaC1wYXJhbWV0ZXJzIElOVEVHRVIgOjo9ICAgICAgICAgICAgIDEwOQ0KDQog
ICAgICAgUEEtUEstQVMtUkVRIDo6PSBTRVFVRU5DRSB7DQogICAgICAgICAgc2lnbmVkQXV0aFBh
Y2sgICAgICAgICAgWzBdIElNUExJQ0lUIE9DVEVUIFNUUklORywNCiAgICAgICAgICAgICAgICAg
ICAtLSBDb250YWlucyBhIENNUyB0eXBlIENvbnRlbnRJbmZvIGVuY29kZWQNCiAgICAgICAgICAg
ICAgICAgICAtLSBhY2NvcmRpbmcgdG8gW1JGQzM4NTJdLg0KICAgICAgICAgICAgICAgICAgIC0t
IFRoZSBjb250ZW50VHlwZSBmaWVsZCBvZiB0aGUgdHlwZSBDb250ZW50SW5mbw0KICAgICAgICAg
ICAgICAgICAgIC0tIGlzIGlkLXNpZ25lZERhdGEgKDEuMi44NDAuMTEzNTQ5LjEuNy4yKSwNCiAg
ICAgICAgICAgICAgICAgICAtLSBhbmQgdGhlIGNvbnRlbnQgZmllbGQgaXMgYSBTaWduZWREYXRh
Lg0KICAgICAgICAgICAgICAgICAgIC0tIFRoZSBlQ29udGVudFR5cGUgZmllbGQgZm9yIHRoZSB0
eXBlIFNpZ25lZERhdGEgaXMNCiAgICAgICAgICAgICAgICAgICAtLSBpZC1wa2luaXQtYXV0aERh
dGEgKDEuMy42LjEuNS4yLjMuMSksIGFuZCB0aGUNCiAgICAgICAgICAgICAgICAgICAtLSBlQ29u
dGVudCBmaWVsZCBjb250YWlucyB0aGUgREVSIGVuY29kaW5nIG9mIHRoZQ0KICAgICAgICAgICAg
ICAgICAgIC0tIHR5cGUgQXV0aFBhY2suDQogICAgICAgICAgICAgICAgICAgLS0gQXV0aFBhY2sg
aXMgZGVmaW5lZCBiZWxvdy4NCiAgICAgICAgICB0cnVzdGVkQ2VydGlmaWVycyAgICAgICBbMV0g
U0VRVUVOQ0UgT0YNCiAgICAgICAgICAgICAgICAgICAgICBFeHRlcm5hbFByaW5jaXBhbElkZW50
aWZpZXIgT1BUSU9OQUwsDQogICAgICAgICAgICAgICAgICAgLS0gQ29udGFpbnMgYSBsaXN0IG9m
IENBcywgdHJ1c3RlZCBieSB0aGUgY2xpZW50LA0KICAgICAgICAgICAgICAgICAgIC0tIHRoYXQg
Y2FuIGJlIHVzZWQgdG8gY2VydGlmeSB0aGUgS0RDLg0KICAgICAgICAgICAgICAgICAgIC0tIEVh
Y2ggRXh0ZXJuYWxQcmluY2lwYWxJZGVudGlmaWVyIGlkZW50aWZpZXMgYSBDQQ0KICAgICAgICAg
ICAgICAgICAgIC0tIG9yIGEgQ0EgY2VydGlmaWNhdGUgKHRoZXJlYnkgaXRzIHB1YmxpYyBrZXkp
Lg0KICAgICAgICAgICAgICAgICAgIC0tIFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhl
DQogICAgICAgICAgICAgICAgICAgLS0gdHJ1c3RlZENlcnRpZmllcnMgU0hPVUxEIGJlIHVzZWQg
YnkgdGhlIEtEQyBhcw0KICAgICAgICAgICAgICAgICAgIC0tIGhpbnRzIHRvIGd1aWRlIGl0cyBz
ZWxlY3Rpb24gb2YgYW4gYXBwcm9wcmlhdGUNCiAgICAgICAgICAgICAgICAgICAtLSBjZXJ0aWZp
Y2F0ZSBjaGFpbiB0byByZXR1cm4gdG8gdGhlIGNsaWVudC4NCiAgICAgICAgICBrZGNQa0lkICAg
ICAgICAgICAgICAgICBbMl0gSU1QTElDSVQgT0NURVQgU1RSSU5HDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIE9QVElPTkFMLA0KICAgICAgICAgICAgICAgICAgIC0tIENv
bnRhaW5zIGEgQ01TIHR5cGUgU2lnbmVySWRlbnRpZmllciBlbmNvZGVkDQogICAgICAgICAgICAg
ICAgICAgLS0gYWNjb3JkaW5nIHRvIFtSRkMzODUyXS4NCiAgICAgICAgICAgICAgICAgICAtLSBJ
ZGVudGlmaWVzLCBpZiBwcmVzZW50LCBhIHBhcnRpY3VsYXIgS0RDDQogICAgICAgICAgICAgICAg
ICAgLS0gcHVibGljIGtleSB0aGF0IHRoZSBjbGllbnQgYWxyZWFkeSBoYXMuDQogICAgICAgICAg
Li4uDQogICAgICAgfQ0KDQogICAgICAgREhOb25jZSA6Oj0gT0NURVQgU1RSSU5HDQoNCg0KDQoN
ClpodSAmIFR1bmcgICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI3LCAyMDA2ICAgICAgICAg
ICAgICAgIFtQYWdlIDMzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgUEtJ
TklUICAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA2DQoNCg0KICAgICAgIEV4dGVybmFs
UHJpbmNpcGFsSWRlbnRpZmllciA6Oj0gU0VRVUVOQ0Ugew0KICAgICAgICAgIHN1YmplY3ROYW1l
ICAgICAgICAgICAgWzBdIElNUExJQ0lUIE9DVEVUIFNUUklORyBPUFRJT05BTCwNCiAgICAgICAg
ICAgICAgICAgICAtLSBDb250YWlucyBhIFBLSVggdHlwZSBOYW1lIGVuY29kZWQgYWNjb3JkaW5n
IHRvDQogICAgICAgICAgICAgICAgICAgLS0gW1JGQzMyODBdLg0KICAgICAgICAgICAgICAgICAg
IC0tIElkZW50aWZpZXMgdGhlIGNlcnRpZmljYXRlIHN1YmplY3QgYnkgdGhlDQogICAgICAgICAg
ICAgICAgICAgLS0gZGlzdGluZ3Vpc2hlZCBzdWJqZWN0IG5hbWUuDQogICAgICAgICAgICAgICAg
ICAgLS0gUkVRVUlSRUQgd2hlbiB0aGVyZSBpcyBhIGRpc3Rpbmd1aXNoZWQgc3ViamVjdA0KICAg
ICAgICAgICAgICAgICAgIC0tIG5hbWUgcHJlc2VudCBpbiB0aGUgY2VydGlmaWNhdGUuDQogICAg
ICAgICBpc3N1ZXJBbmRTZXJpYWxOdW1iZXIgICBbMV0gSU1QTElDSVQgT0NURVQgU1RSSU5HIE9Q
VElPTkFMLA0KICAgICAgICAgICAgICAgICAgIC0tIENvbnRhaW5zIGEgQ01TIHR5cGUgSXNzdWVy
QW5kU2VyaWFsTnVtYmVyIGVuY29kZWQNCiAgICAgICAgICAgICAgICAgICAtLSBhY2NvcmRpbmcg
dG8gW1JGQzM4NTJdLg0KICAgICAgICAgICAgICAgICAgIC0tIElkZW50aWZpZXMgYSBjZXJ0aWZp
Y2F0ZSBvZiB0aGUgc3ViamVjdC4NCiAgICAgICAgICAgICAgICAgICAtLSBSRVFVSVJFRCBmb3Ig
VEQtSU5WQUxJRC1DRVJUSUZJQ0FURVMgYW5kDQogICAgICAgICAgICAgICAgICAgLS0gVEQtVFJV
U1RFRC1DRVJUSUZJRVJTLg0KICAgICAgICAgc3ViamVjdEtleUlkZW50aWZpZXIgICAgWzJdIElN
UExJQ0lUIE9DVEVUIFNUUklORyBPUFRJT05BTCwNCiAgICAgICAgICAgICAgICAgICAtLSBJZGVu
dGlmaWVzIHRoZSBzdWJqZWN0J3MgcHVibGljIGtleSBieSBhIGtleQ0KICAgICAgICAgICAgICAg
ICAgIC0tIGlkZW50aWZpZXIuICBXaGVuIGFuIFguNTA5IGNlcnRpZmljYXRlIGlzDQogICAgICAg
ICAgICAgICAgICAgLS0gcmVmZXJlbmNlZCwgdGhpcyBrZXkgaWRlbnRpZmllciBtYXRjaGVzIHRo
ZSBYLjUwOQ0KICAgICAgICAgICAgICAgICAgIC0tIHN1YmplY3RLZXlJZGVudGlmaWVyIGV4dGVu
c2lvbiB2YWx1ZS4gIFdoZW4gb3RoZXINCiAgICAgICAgICAgICAgICAgICAtLSBjZXJ0aWZpY2F0
ZSBmb3JtYXRzIGFyZSByZWZlcmVuY2VkLCB0aGUgZG9jdW1lbnRzDQogICAgICAgICAgICAgICAg
ICAgLS0gdGhhdCBzcGVjaWZ5IHRoZSBjZXJ0aWZpY2F0ZSBmb3JtYXQgYW5kIHRoZWlyIHVzZQ0K
ICAgICAgICAgICAgICAgICAgIC0tIHdpdGggdGhlIENNUyBtdXN0IGluY2x1ZGUgZGV0YWlscyBv
biBtYXRjaGluZyB0aGUNCiAgICAgICAgICAgICAgICAgICAtLSBrZXkgaWRlbnRpZmllciB0byB0
aGUgYXBwcm9wcmlhdGUgY2VydGlmaWNhdGUNCiAgICAgICAgICAgICAgICAgICAtLSBmaWVsZC4N
CiAgICAgICAgICAgICAgICAgICAtLSBSRUNPTU1FTkRFRCBmb3IgVEQtVFJVU1RFRC1DRVJUSUZJ
RVJTLg0KICAgICAgICAgIC4uLg0KICAgICAgIH0NCg0KICAgICAgIEF1dGhQYWNrIDo6PSBTRVFV
RU5DRSB7DQogICAgICAgICAgcGtBdXRoZW50aWNhdG9yICAgICAgICAgWzBdIFBLQXV0aGVudGlj
YXRvciwNCiAgICAgICAgICBjbGllbnRQdWJsaWNWYWx1ZSAgICAgICBbMV0gU3ViamVjdFB1Ymxp
Y0tleUluZm8gT1BUSU9OQUwsDQogICAgICAgICAgICAgICAgICAgLS0gVHlwZSBTdWJqZWN0UHVi
bGljS2V5SW5mbyBpcyBkZWZpbmVkIGluDQogICAgICAgICAgICAgICAgICAgLS0gW1JGQzMyODBd
Lg0KICAgICAgICAgICAgICAgICAgIC0tIFNwZWNpZmllcyBEaWZmaWUtSGVsbG1hbiBkb21haW4g
cGFyYW1ldGVycw0KICAgICAgICAgICAgICAgICAgIC0tIGFuZCB0aGUgY2xpZW50J3MgcHVibGlj
IGtleSB2YWx1ZSBbSUVFRTEzNjNdLg0KICAgICAgICAgICAgICAgICAgIC0tIFRoZSBESCBwdWJs
aWMga2V5IHZhbHVlIGlzIGVuY29kZWQgYXMgYSBCSVQNCiAgICAgICAgICAgICAgICAgICAtLSBT
VFJJTkcgYWNjb3JkaW5nIHRvIFtSRkMzMjc5XS4NCiAgICAgICAgICAgICAgICAgICAtLSBUaGlz
IGZpZWxkIGlzIHByZXNlbnQgb25seSBpZiB0aGUgY2xpZW50IHdpc2hlcw0KICAgICAgICAgICAg
ICAgICAgIC0tIHRvIHVzZSB0aGUgRGlmZmllLUhlbGxtYW4ga2V5IGFncmVlbWVudCBtZXRob2Qu
DQogICAgICAgICAgc3VwcG9ydGVkQ01TVHlwZXMgICAgICAgWzJdIFNFUVVFTkNFIE9GIEFsZ29y
aXRobUlkZW50aWZpZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT1BU
SU9OQUwsDQogICAgICAgICAgICAgICAgICAgLS0gVHlwZSBBbGdvcml0aG1JZGVudGlmaWVyIGlz
IGRlZmluZWQgaW4NCiAgICAgICAgICAgICAgICAgICAtLSBbUkZDMzI4MF0uDQogICAgICAgICAg
ICAgICAgICAgLS0gTGlzdCBvZiBDTVMgZW5jcnlwdGlvbiwgYnVsayBlbmNyeXB0aW9uLA0KICAg
ICAgICAgICAgICAgICAgIC0tIG9yIHNpZ25hdHVyZSBhbGdvcml0aG0gaWRlbnRpZmllcnMgc3Vw
cG9ydGVkIGJ5DQogICAgICAgICAgICAgICAgICAgLS0gdGhlIGNsaWVudCBpbiBvcmRlciBvZiAo
ZGVjcmVhc2luZykgcHJlZmVyZW5jZS4NCiAgICAgICAgICBjbGllbnRESE5vbmNlICAgICAgICAg
ICBbM10gREhOb25jZSBPUFRJT05BTCwNCiAgICAgICAgICAgICAgICAgICAtLSBQcmVzZW50IG9u
bHkgaWYgdGhlIGNsaWVudCBpbmRpY2F0ZXMgdGhhdCBpdA0KDQoNCg0KWmh1ICYgVHVuZyAgICAg
ICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMzRd
DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBQS0lOSVQgICAgICAgICAgICAg
ICAgICAgICBKYW51YXJ5IDIwMDYNCg0KDQogICAgICAgICAgICAgICAgICAgLS0gd2lzaGVzIHRv
IHJldXNlIERIIGtleXMgb3IgdG8gYWxsb3cgdGhlIEtEQyB0bw0KICAgICAgICAgICAgICAgICAg
IC0tIGRvIHNvLg0KICAgICAgICAgIC4uLg0KICAgICAgIH0NCg0KICAgICAgIFBLQXV0aGVudGlj
YXRvciA6Oj0gU0VRVUVOQ0Ugew0KICAgICAgICAgIGN1c2VjICAgICAgICAgICAgICAgICAgIFsw
XSBJTlRFR0VSICgwLi45OTk5OTkpLA0KICAgICAgICAgIGN0aW1lICAgICAgICAgICAgICAgICAg
IFsxXSBLZXJiZXJvc1RpbWUsDQogICAgICAgICAgICAgICAgICAgLS0gY3VzZWMgYW5kIGN0aW1l
IGFyZSB1c2VkIGFzIGluIFtSRkM0MTIwXSwgZm9yDQogICAgICAgICAgICAgICAgICAgLS0gcmVw
bGF5IHByZXZlbnRpb24uDQogICAgICAgICAgbm9uY2UgICAgICAgICAgICAgICAgICAgWzJdIElO
VEVHRVIgKDAuLjQyOTQ5NjcyOTUpLA0KICAgICAgICAgICAgICAgICAgIC0tIENob3NlbiByYW5k
b21seTsgIFRoaXMgbm9uY2UgZG9lcyBub3QgbmVlZCB0bw0KICAgICAgICAgICAgICAgICAgIC0t
IG1hdGNoIHdpdGggdGhlIG5vbmNlIGluIHRoZSBLREMtUkVRLUJPRFkuDQogICAgICAgICAgcGFD
aGVja3N1bSAgICAgICAgICAgICAgWzNdIE9DVEVUIFNUUklORyBPUFRJT05BTCwNCiAgICAgICAg
ICAgICAgICAgICAtLSBNVVNUIGJlIHByZXNlbnQuDQogICAgICAgICAgICAgICAgICAgLS0gQ29u
dGFpbnMgdGhlIFNIQTEgY2hlY2tzdW0sIHBlcmZvcm1lZCBvdmVyDQogICAgICAgICAgICAgICAg
ICAgLS0gS0RDLVJFUS1CT0RZLg0KICAgICAgICAgIC4uLg0KICAgICAgIH0NCg0KICAgICAgIFRE
LVRSVVNURUQtQ0VSVElGSUVSUyA6Oj0gU0VRVUVOQ0UgT0YNCiAgICAgICAgICAgICAgICAgICAg
ICBFeHRlcm5hbFByaW5jaXBhbElkZW50aWZpZXINCiAgICAgICAgICAgICAgICAgICAtLSBJZGVu
dGlmaWVzIGEgbGlzdCBvZiBDQXMgdHJ1c3RlZCBieSB0aGUgS0RDLg0KICAgICAgICAgICAgICAg
ICAgIC0tIEVhY2ggRXh0ZXJuYWxQcmluY2lwYWxJZGVudGlmaWVyIGlkZW50aWZpZXMgYSBDQQ0K
ICAgICAgICAgICAgICAgICAgIC0tIG9yIGEgQ0EgY2VydGlmaWNhdGUgKHRoZXJlYnkgaXRzIHB1
YmxpYyBrZXkpLg0KDQogICAgICAgVEQtSU5WQUxJRC1DRVJUSUZJQ0FURVMgOjo9IFNFUVVFTkNF
IE9GDQogICAgICAgICAgICAgICAgICAgICAgRXh0ZXJuYWxQcmluY2lwYWxJZGVudGlmaWVyDQog
ICAgICAgICAgICAgICAgICAgLS0gRWFjaCBFeHRlcm5hbFByaW5jaXBhbElkZW50aWZpZXIgaWRl
bnRpZmllcyBhDQogICAgICAgICAgICAgICAgICAgLS0gY2VydGlmaWNhdGUgKHNlbnQgYnkgdGhl
IGNsaWVudCkgd2l0aCBhbiBpbnZhbGlkDQogICAgICAgICAgICAgICAgICAgLS0gc2lnbmF0dXJl
Lg0KDQogICAgICAgS1JCNVByaW5jaXBhbE5hbWUgOjo9IFNFUVVFTkNFIHsNCiAgICAgICAgICAg
cmVhbG0gICAgICAgICAgICAgICAgICAgWzBdIFJlYWxtLA0KICAgICAgICAgICBwcmluY2lwYWxO
YW1lICAgICAgICAgICBbMV0gUHJpbmNpcGFsTmFtZQ0KICAgICAgIH0NCg0KICAgICAgIEFELUlO
SVRJQUwtVkVSSUZJRUQtQ0FTIDo6PSBTRVFVRU5DRSBPRg0KICAgICAgICAgICAgICAgICAgICAg
IEV4dGVybmFsUHJpbmNpcGFsSWRlbnRpZmllcg0KICAgICAgICAgICAgICAgICAgIC0tIElkZW50
aWZpZXMgdGhlIGNlcnRpZmljYXRpb24gcGF0aCBiYXNlZCBvbiB3aGljaA0KICAgICAgICAgICAg
ICAgICAgIC0tIHRoZSBjbGllbnQgY2VydGlmaWNhdGUgd2FzIHZhbGlkYXRlZC4NCiAgICAgICAg
ICAgICAgICAgICAtLSBFYWNoIEV4dGVybmFsUHJpbmNpcGFsSWRlbnRpZmllciBpZGVudGlmaWVz
IGEgQ0ENCiAgICAgICAgICAgICAgICAgICAtLSBvciBhIENBIGNlcnRpZmljYXRlICh0aGVyZWJ5
IGl0cyBwdWJsaWMga2V5KS4NCg0KICAgICAgIFBBLVBLLUFTLVJFUCA6Oj0gQ0hPSUNFIHsNCiAg
ICAgICAgICBkaEluZm8gICAgICAgICAgICAgICAgICBbMF0gREhSZXBJbmZvLA0KICAgICAgICAg
ICAgICAgICAgIC0tIFNlbGVjdGVkIHdoZW4gRGlmZmllLUhlbGxtYW4ga2V5IGV4Y2hhbmdlIGlz
DQogICAgICAgICAgICAgICAgICAgLS0gdXNlZC4NCg0KDQoNClpodSAmIFR1bmcgICAgICAgICAg
ICAgICAgRXhwaXJlcyBKdWx5IDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDM1XQ0KDA0K
SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgUEtJTklUICAgICAgICAgICAgICAgICAg
ICAgSmFudWFyeSAyMDA2DQoNCg0KICAgICAgICAgIGVuY0tleVBhY2sgICAgICAgICAgICAgIFsx
XSBJTVBMSUNJVCBPQ1RFVCBTVFJJTkcsDQogICAgICAgICAgICAgICAgICAgLS0gU2VsZWN0ZWQg
d2hlbiBwdWJsaWMga2V5IGVuY3J5cHRpb24gaXMgdXNlZC4NCiAgICAgICAgICAgICAgICAgICAt
LSBDb250YWlucyBhIENNUyB0eXBlIENvbnRlbnRJbmZvIGVuY29kZWQNCiAgICAgICAgICAgICAg
ICAgICAtLSBhY2NvcmRpbmcgdG8gW1JGQzM4NTJdLg0KICAgICAgICAgICAgICAgICAgIC0tIFRo
ZSBjb250ZW50VHlwZSBmaWVsZCBvZiB0aGUgdHlwZSBDb250ZW50SW5mbyBpcw0KICAgICAgICAg
ICAgICAgICAgIC0tIGlkLWVudmVsb3BlZERhdGEgKDEuMi44NDAuMTEzNTQ5LjEuNy4zKS4NCiAg
ICAgICAgICAgICAgICAgICAtLSBUaGUgY29udGVudCBmaWVsZCBpcyBhbiBFbnZlbG9wZWREYXRh
Lg0KICAgICAgICAgICAgICAgICAgIC0tIFRoZSBjb250ZW50VHlwZSBmaWVsZCBmb3IgdGhlIHR5
cGUgRW52ZWxvcGVkRGF0YQ0KICAgICAgICAgICAgICAgICAgIC0tIGlzIGlkLXNpZ25lZERhdGEg
KDEuMi44NDAuMTEzNTQ5LjEuNy4yKS4NCiAgICAgICAgICAgICAgICAgICAtLSBUaGUgZUNvbnRl
bnRUeXBlIGZpZWxkIGZvciB0aGUgaW5uZXIgdHlwZQ0KICAgICAgICAgICAgICAgICAgIC0tIFNp
Z25lZERhdGEgKHdoZW4gdW5lbmNyeXB0ZWQpIGlzDQogICAgICAgICAgICAgICAgICAgLS0gaWQt
cGtpbml0LXJrZXlEYXRhICgxLjMuNi4xLjUuMi4zLjMpIGFuZCB0aGUNCiAgICAgICAgICAgICAg
ICAgICAtLSBlQ29udGVudCBmaWVsZCBjb250YWlucyB0aGUgREVSIGVuY29kaW5nIG9mIHRoZQ0K
ICAgICAgICAgICAgICAgICAgIC0tIHR5cGUgUmVwbHlLZXlQYWNrLg0KICAgICAgICAgICAgICAg
ICAgIC0tIFJlcGx5S2V5UGFjayBpcyBkZWZpbmVkIGJlbG93Lg0KICAgICAgICAgIC4uLg0KICAg
ICAgIH0NCg0KICAgICAgIERIUmVwSW5mbyA6Oj0gU0VRVUVOQ0Ugew0KICAgICAgICAgIGRoU2ln
bmVkRGF0YSAgICAgICAgICAgIFswXSBJTVBMSUNJVCBPQ1RFVCBTVFJJTkcsDQogICAgICAgICAg
ICAgICAgICAgLS0gQ29udGFpbnMgYSBDTVMgdHlwZSBDb250ZW50SW5mbyBlbmNvZGVkIGFjY29y
ZGluZw0KICAgICAgICAgICAgICAgICAgIC0tIHRvIFtSRkMzODUyXS4NCiAgICAgICAgICAgICAg
ICAgICAtLSBUaGUgY29udGVudFR5cGUgZmllbGQgb2YgdGhlIHR5cGUgQ29udGVudEluZm8gaXMN
CiAgICAgICAgICAgICAgICAgICAtLSBpZC1zaWduZWREYXRhICgxLjIuODQwLjExMzU0OS4xLjcu
MiksIGFuZCB0aGUNCiAgICAgICAgICAgICAgICAgICAtLSBjb250ZW50IGZpZWxkIGlzIGEgU2ln
bmVkRGF0YS4NCiAgICAgICAgICAgICAgICAgICAtLSBUaGUgZUNvbnRlbnRUeXBlIGZpZWxkIGZv
ciB0aGUgdHlwZSBTaWduZWREYXRhIGlzDQogICAgICAgICAgICAgICAgICAgLS0gaWQtcGtpbml0
LURIS2V5RGF0YSAoMS4zLjYuMS41LjIuMy4yKSwgYW5kIHRoZQ0KICAgICAgICAgICAgICAgICAg
IC0tIGVDb250ZW50IGZpZWxkIGNvbnRhaW5zIHRoZSBERVIgZW5jb2Rpbmcgb2YgdGhlDQogICAg
ICAgICAgICAgICAgICAgLS0gdHlwZSBLRENESEtleUluZm8uDQogICAgICAgICAgICAgICAgICAg
LS0gS0RDREhLZXlJbmZvIGlzIGRlZmluZWQgYmVsb3cuDQogICAgICAgICAgc2VydmVyREhOb25j
ZSAgICAgICAgICAgWzFdIERITm9uY2UgT1BUSU9OQUwsDQogICAgICAgICAgICAgICAgICAgLS0g
UHJlc2VudCBpZiBhbmQgb25seSBpZiBkaEtleUV4cGlyYXRpb24gaXMNCiAgICAgICAgICAgICAg
ICAgICAtLSBwcmVzZW50Lg0KICAgICAgICAgIC4uLg0KICAgICAgIH0NCg0KICAgICAgIEtEQ0RI
S2V5SW5mbyA6Oj0gU0VRVUVOQ0Ugew0KICAgICAgICAgIHN1YmplY3RQdWJsaWNLZXkgICAgICAg
IFswXSBCSVQgU1RSSU5HLA0KICAgICAgICAgICAgICAgICAgIC0tIFRoZSBLREMncyBESCBwdWJs
aWMga2V5Lg0KICAgICAgICAgICAgICAgICAgIC0tIFRoZSBESCBwdWJsaWMga2V5IHZhbHVlIGlz
IGVuY29kZWQgYXMgYSBCSVQNCiAgICAgICAgICAgICAgICAgICAtLSBTVFJJTkcgYWNjb3JkaW5n
IHRvIFtSRkMzMjc5XS4NCiAgICAgICAgICBub25jZSAgICAgICAgICAgICAgICAgICBbMV0gSU5U
RUdFUiAoMC4uNDI5NDk2NzI5NSksDQogICAgICAgICAgICAgICAgICAgLS0gQ29udGFpbnMgdGhl
IG5vbmNlIGluIHRoZSBwa0F1dGhlbnRpY2F0b3IgZmllbGQNCiAgICAgICAgICAgICAgICAgICAt
LSBpbiB0aGUgcmVxdWVzdCBpZiB0aGUgREgga2V5cyBhcmUgTk9UIHJldXNlZCwNCiAgICAgICAg
ICAgICAgICAgICAtLSAwIG90aGVyd2lzZS4NCiAgICAgICAgICBkaEtleUV4cGlyYXRpb24gICAg
ICAgICBbMl0gS2VyYmVyb3NUaW1lIE9QVElPTkFMLA0KICAgICAgICAgICAgICAgICAgIC0tIEV4
cGlyYXRpb24gdGltZSBmb3IgS0RDJ3Mga2V5IHBhaXIsDQogICAgICAgICAgICAgICAgICAgLS0g
cHJlc2VudCBpZiBhbmQgb25seSBpZiB0aGUgREgga2V5cyBhcmUgcmV1c2VkLg0KDQoNCg0KWmh1
ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjcsIDIwMDYgICAgICAgICAgICAg
ICAgW1BhZ2UgMzZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBQS0lOSVQg
ICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDYNCg0KDQogICAgICAgICAgICAgICAgICAg
LS0gSWYgcHJlc2VudCwgdGhlIEtEQydzIERIIHB1YmxpYyBrZXkgTVVTVCBub3QgYmUNCiAgICAg
ICAgICAgICAgICAgICAtLSB1c2VkIHBhc3QgdGhlIHBvaW50IG9mIHRoaXMgZXhwaXJhdGlvbiB0
aW1lLg0KICAgICAgICAgICAgICAgICAgIC0tIElmIHRoaXMgZmllbGQgaXMgb21pdHRlZCB0aGVu
IHRoZSBzZXJ2ZXJESE5vbmNlDQogICAgICAgICAgICAgICAgICAgLS0gZmllbGQgTVVTVCBhbHNv
IGJlIG9taXR0ZWQuDQogICAgICAgICAgLi4uDQogICAgICAgfQ0KDQogICAgICAgUmVwbHlLZXlQ
YWNrIDo6PSBTRVFVRU5DRSB7DQogICAgICAgICAgcmVwbHlLZXkgICAgICAgICAgICAgICAgWzBd
IEVuY3J5cHRpb25LZXksDQogICAgICAgICAgICAgICAgICAgLS0gQ29udGFpbnMgdGhlIHNlc3Np
b24ga2V5IHVzZWQgdG8gZW5jcnlwdCB0aGUNCiAgICAgICAgICAgICAgICAgICAtLSBlbmMtcGFy
dCBmaWVsZCBpbiB0aGUgQVMtUkVQLCBpLmUuIHRoZQ0KICAgICAgICAgICAgICAgICAgIC0tIEFT
IHJlcGx5IGtleS4NCiAgICAgICAgICBhc0NoZWNrc3VtICAgICAgICAgICAgICBbMV0gQ2hlY2tz
dW0sDQogICAgICAgICAgICAgICAgICAtLSBDb250YWlucyB0aGUgY2hlY2tzdW0gb2YgdGhlIEFT
LVJFUQ0KICAgICAgICAgICAgICAgICAgLS0gY29ycmVzcG9uZGluZyB0byB0aGUgY29udGFpbmlu
ZyBBUy1SRVAuDQogICAgICAgICAgICAgICAgICAtLSBUaGUgY2hlY2tzdW0gaXMgcGVyZm9ybWVk
IG92ZXIgdGhlIHR5cGUgQVMtUkVRLg0KICAgICAgICAgICAgICAgICAgLS0gVGhlIHByb3RvY29s
IGtleSBbUkZDMzk2MV0gb2YgdGhlIGNoZWNrc3VtIGlzIHRoZQ0KICAgICAgICAgICAgICAgICAg
LS0gcmVwbHlLZXkgYW5kIHRoZSBrZXkgdXNhZ2UgbnVtYmVyIGlzIDYuDQogICAgICAgICAgICAg
ICAgICAtLSBJZiB0aGUgcmVwbHlLZXkncyBlbmN0eXBlIGlzICJuZXdlciIgW1JGQzQxMjBdDQog
ICAgICAgICAgICAgICAgICAtLSBbUkZDNDEyMV0sIHRoZSBjaGVja3N1bSBpcyB0aGUgcmVxdWly
ZWQNCiAgICAgICAgICAgICAgICAgIC0tIGNoZWNrc3VtIG9wZXJhdGlvbiBbUkZDMzk2MV0gZm9y
IHRoYXQgZW5jdHlwZS4NCiAgICAgICAgICAgICAgICAgIC0tIFRoZSBjbGllbnQgTVVTVCB2ZXJp
ZnkgdGhpcyBjaGVja3N1bSB1cG9uIHJlY2VpcHQNCiAgICAgICAgICAgICAgICAgIC0tIG9mIHRo
ZSBBUy1SRVAuDQogICAgICAgICAgLi4uDQogICAgICAgfQ0KDQogICAgICAgVEQtREgtUEFSQU1F
VEVSUyA6Oj0gU0VRVUVOQ0UgT0YgQWxnb3JpdGhtSWRlbnRpZmllcg0KICAgICAgICAgICAgICAg
ICAgIC0tIEVhY2ggQWxnb3JpdGhtSWRlbnRpZmllciBzcGVjaWZpZXMgYSBzZXQgb2YNCiAgICAg
ICAgICAgICAgICAgICAtLSBEaWZmaWUtSGVsbG1hbiBkb21haW4gcGFyYW1ldGVycyBbSUVFRTEz
NjNdLg0KICAgICAgICAgICAgICAgICAgIC0tIFRoaXMgbGlzdCBpcyBpbiBkZWNyZWFzaW5nIHBy
ZWZlcmVuY2Ugb3JkZXIuDQogICAgICAgRU5EDQoNCg0KQXBwZW5kaXggQi4gIFRlc3QgVmVjdG9y
cw0KDQogICBGdW5jdGlvbiBvY3RldHN0cmluZzJrZXkoKSBpcyBkZWZpbmVkIGluIFNlY3Rpb24g
My4yLjMuMS4gIFRoaXMNCiAgIHNlY3Rpb24gZGVzY3JpYmVzIGEgZmV3IHNldHMgb2YgdGVzdCB2
ZWN0b3JzIHRoYXQgd291bGQgYmUgdXNlZnVsIGZvcg0KICAgaW1wbGVtZW50ZXJzIG9mIG9jdGV0
c3RyaW5nMmtleSgpLg0KDQoNCiAgIFNldCAxDQogICA9PT09PQ0KICAgSW5wdXQgb2N0ZXQgc3Ry
aW5nIHggaXM6DQoNCiAgICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDAgMDANCiAgICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgMDANCiAgICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDANCiAgICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAN
Cg0KDQoNClpodSAmIFR1bmcgICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDI3LCAyMDA2ICAg
ICAgICAgICAgICAgIFtQYWdlIDM3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg
ICAgUEtJTklUICAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA2DQoNCg0KICAgICAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMA0KICAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMA0KDQogICBPdXRwdXQgb2YgSy10cnVuY2F0ZSgpIHdoZW4gdGhlIGtleSBzaXpl
IGlzIDMyIG9jdGV0czoNCg0KICAgICA1ZSBlNSAwZCA2NyA1YyA4MCA5ZiBlNSA5ZSA0YSA3NyA2
MiBjNSA0YiA2NSA4Mw0KICAgICA3NSA0NyBlYSBmYiAxNSA5YiBkOCBjZCBjNyA1ZiBmYyBhNSA5
MSAxZSA0YyA0MQ0KDQoNCiAgIFNldCAyOg0KICAgPT09PT0NCiAgIElucHV0IG9jdGV0IHN0cmlu
ZyB4IGlzOg0KDQogICAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IDAwIDAwDQogICAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IDAwDQogICAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
DQogICAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwDQog
ICAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwDQogICAg
IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwDQogICAgIDAw
IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwDQogICAgIDAwIDAw
IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwDQoNCiAgIE91dHB1dCBv
ZiBLLXRydW5jYXRlKCkgd2hlbiB0aGUga2V5IHNpemUgaXMgMzIgb2N0ZXRzOg0KDQogICAgIGFj
IGY3IDcwIDdjIDA4IDk3IDNkIGRmIGRiIDI3IGNkIDM2IDE0IDQyIGNjIGZiDQogICAgIGEzIDU1
IGM4IDg4IDRjIGI0IDcyIGYzIDdkIGE2IDM2IGQwIDdkIDU2IDc4IDdlDQoNCg0KICAgU2V0IDM6
DQogICA9PT09PT0NCiAgIElucHV0IG9jdGV0IHN0cmluZyB4IGlzOg0KDQogICAgIDAwIDAxIDAy
IDAzIDA0IDA1IDA2IDA3IDA4IDA5IDBhIDBiIDBjIDBkIDBlIDBmDQogICAgIDEwIDAwIDAxIDAy
IDAzIDA0IDA1IDA2IDA3IDA4IDA5IDBhIDBiIDBjIDBkIDBlDQogICAgIDBmIDEwIDAwIDAxIDAy
IDAzIDA0IDA1IDA2IDA3IDA4IDA5IDBhIDBiIDBjIDBkDQogICAgIDBlIDBmIDEwIDAwIDAxIDAy
IDAzIDA0IDA1IDA2IDA3IDA4IDA5IDBhIDBiIDBjDQogICAgIDBkIDBlIDBmIDEwIDAwIDAxIDAy
IDAzIDA0IDA1IDA2IDA3IDA4IDA5IDBhIDBiDQogICAgIDBjIDBkIDBlIDBmIDEwIDAwIDAxIDAy
IDAzIDA0IDA1IDA2IDA3IDA4IDA5IDBhDQoNCg0KDQpaaHUgJiBUdW5nICAgICAgICAgICAgICAg
IEV4cGlyZXMgSnVseSAyNywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAzOF0NCgwNCkludGVy
bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFBLSU5JVCAgICAgICAgICAgICAgICAgICAgIEph
bnVhcnkgMjAwNg0KDQoNCiAgICAgMGIgMGMgMGQgMGUgMGYgMTAgMDAgMDEgMDIgMDMgMDQgMDUg
MDYgMDcgMDggMDkNCiAgICAgMGEgMGIgMGMgMGQgMGUgMGYgMTAgMDAgMDEgMDIgMDMgMDQgMDUg
MDYgMDcgMDgNCg0KICAgT3V0cHV0IG9mIEstdHJ1bmNhdGUoKSB3aGVuIHRoZSBrZXkgc2l6ZSBp
cyAzMiBvY3RldHM6DQoNCiAgICAgYzQgNDIgZGEgNTggNWYgY2IgODAgZTQgM2IgNDcgOTQgNmYg
MjUgNDAgOTMgZTMNCiAgICAgNzMgMjkgZDkgOTAgMDEgMzggMGQgYjcgODMgNzEgZGIgM2EgY2Yg
NWMgNzkgN2UNCg0KDQogICBTZXQgNDoNCiAgID09PT09DQogICBJbnB1dCBvY3RldCBzdHJpbmcg
eCBpczoNCg0KICAgICAwMCAwMSAwMiAwMyAwNCAwNSAwNiAwNyAwOCAwOSAwYSAwYiAwYyAwZCAw
ZSAwZg0KICAgICAxMCAwMCAwMSAwMiAwMyAwNCAwNSAwNiAwNyAwOCAwOSAwYSAwYiAwYyAwZCAw
ZQ0KICAgICAwZiAxMCAwMCAwMSAwMiAwMyAwNCAwNSAwNiAwNyAwOCAwOSAwYSAwYiAwYyAwZA0K
ICAgICAwZSAwZiAxMCAwMCAwMSAwMiAwMyAwNCAwNSAwNiAwNyAwOCAwOSAwYSAwYiAwYw0KICAg
ICAwZCAwZSAwZiAxMCAwMCAwMSAwMiAwMyAwNCAwNSAwNiAwNyAwOA0KDQogICBPdXRwdXQgb2Yg
Sy10cnVuY2F0ZSgpIHdoZW4gdGhlIGtleSBzaXplIGlzIDMyIG9jdGV0czoNCg0KICAgICAwMCA1
MyA5NSAzYiA4NCBjOCA5NiBmNCBlYiAzOCA1YyAzZiAyZSA3NSAxYyA0YQ0KICAgICA1OSAwZSBk
NiBmZiBhZCBjYSA2ZiBmNiA0ZiA0NyBlYiBlYiA4ZCA3OCAwZiBmYw0KDQoNCkFwcGVuZGl4IEMu
ICBNaXNjZWxsYW5lb3VzIEluZm9ybWF0aW9uIGFib3V0IE1pY3Jvc29mdCBXaW5kb3dzIFBLSU5J
VA0KICAgICAgICAgICAgIEltcGxlbWVudGF0aW9ucw0KDQogICBFYXJsaWVyIHJldmlzaW9ucyBv
ZiB0aGUgUEtJTklUIEktRCB3ZXJlIGltcGxlbWVudGVkIGluIHZhcmlvdXMNCiAgIHJlbGVhc2Vz
IG9mIE1pY3Jvc29mdCBXaW5kb3dzIGFuZCBkZXBsb3llZCBpbiBmYWlybHkgbGFyZ2UgbnVtYmVy
cy4NCiAgIFRvIGVuYWJsZSB0aGUgY29tbXVuaXR5IHRvIGJldHRlciBpbnRlcm9wZXJhdGUgd2l0
aCBzeXN0ZW1zIHJ1bm5pbmcNCiAgIHRob3NlIHJlbGVhc2VzLCB0aGUgZm9sbG93aW5nIGluZm9y
bWF0aW9uIG1heSBiZSB1c2VmdWwuDQoNCiAgIEtEQyBjZXJ0aWZpY2F0ZXMgaXNzdWVkIGJ5IFdp
bmRvd3MgMjAwMCBFbnRlcnByaXNlIENBcyBjb250YWluIGENCiAgIGROU05hbWUgU0FOIHdpdGgg
dGhlIEROUyBuYW1lIG9mIHRoZSBob3N0IHJ1bm5pbmcgdGhlIEtEQywgYW5kIHRoZQ0KICAgaWQt
a3Atc2VydmVyQXV0aCBFS1UgW1JGQzMyODBdLg0KDQogICBLREMgY2VydGlmaWNhdGVzIGlzc3Vl
ZCBieSBXaW5kb3dzIDIwMDMgRW50ZXJwcmlzZSBDQXMgY29udGFpbiBhDQogICBkTlNOYW1lIFNB
TiB3aXRoIHRoZSBETlMgbmFtZSBvZiB0aGUgaG9zdCBydW5uaW5nIHRoZSBLREMsIHRoZSBpZC1r
cC0NCiAgIHNlcnZlckF1dGggRUtVIGFuZCB0aGUgaWQtbXMta3Atc2MtbG9nb24gRUtVLg0KDQog
ICBJdCBpcyBhbnRpY2lwYXRlZCB0aGF0IHRoZSBuZXh0IHJlbGVhc2Ugb2YgV2luZG93cyBpcyBh
bHJlYWR5IHRvbyBmYXINCiAgIGFsb25nIHRvIGFsbG93IGl0IHRvIHN1cHBvcnQgdGhlIGlzc3Vp
bmcgS0RDIGNlcnRpZmljYXRlcyB3aXRoIGlkLQ0KICAgcGtpbml0LXNhbiBTQU4gYXMgc3BlY2lm
aWVkIGluIHRoaXMgUkZDLiAgSW5zdGVhZCwgdGhleSB3aWxsIGhhdmUgYQ0KICAgZE5TTmFtZSBT
QU4gY29udGFpbmluZyB0aGUgZG9tYWluIG5hbWUgb2YgdGhlIEtEQyBhbmQgdGhlIGludGVuZGVk
DQogICBwdXJwb3NlIG9mIHRoZXNlIEtEQyBjZXJ0aWZpY2F0ZXMgYmUgcmVzdHJpY3RlZCBieSB0
aGUgcHJlc2VuY2Ugb2YNCiAgIHRoZSBpZC1wa2luaXQtS1BLZGMgRUtVIGFuZCBpZC1rcC1zZXJ2
ZXJBdXRoIEVLVS4NCg0KDQoNCg0KWmh1ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1
bHkgMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMzldDQoMDQpJbnRlcm5ldC1EcmFmdCAg
ICAgICAgICAgICAgICAgICBQS0lOSVQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDYN
Cg0KDQogICBJbiBhZGRpdGlvbiB0byBjaGVja2luZyB0aGF0IHRoZSBhYm92ZSBhcmUgcHJlc2Vu
dCBpbiBhIEtEQw0KICAgY2VydGlmaWNhdGUsIFdpbmRvd3MgY2xpZW50cyB2ZXJpZnkgdGhhdCB0
aGUgaXNzdWVyIG9mIHRoZSBLREMNCiAgIGNlcnRpZmljYXRlIGlzIG9uZSBvZiBhIHNldCBvZiBh
bGxvd2VkIGlzc3VlcnMgb2Ygc3VjaCBjZXJ0aWZpY2F0ZXMsDQogICBzbyB0aG9zZSB3aXNoaW5n
IHRvIGlzc3VlIEtEQyBjZXJ0aWZpY2F0ZXMgbmVlZCB0byBjb25maWd1cmUgdGhlaXINCiAgIFdp
bmRvd3MgY2xpZW50cyBhcHByb3ByaWF0ZWx5Lg0KDQogICBDbGllbnQgY2VydGlmaWNhdGVzIGFj
Y2VwdGVkIGJ5IFdpbmRvd3MgMjAwMCBhbmQgV2luZG93cyAyMDAzIFNlcnZlcg0KICAgS0RDcyBt
dXN0IGNvbnRhaW4gYW4gaWQtbXMtc2FuLXNjLWxvZ29uLXVwbiAoMS4zLjYuMS40LjEuMzExLjIw
LjIuMykNCiAgIFNBTiBhbmQgdGhlIGlkLW1zLWtwLXNjLWxvZ29uIEVLVS4gIFRoZSBpZC1tcy1z
YW4tc2MtbG9nb24tdXBuIFNBTg0KICAgY29udGFpbnMgYSBVVEY4IGVuY29kZWQgc3RyaW5nIHdo
b3NlIHZhbHVlIGlzIHRoYXQgb2YgdGhlIERpcmVjdG9yeQ0KICAgU2VydmljZSBhdHRyaWJ1dGUg
VXNlclByaW5jaXBhbE5hbWUgb2YgdGhlIGNsaWVudCBhY2NvdW50IG9iamVjdCwgYW5kDQogICB0
aGUgcHVycG9zZSBvZiBpbmNsdWRpbmcgdGhlIGlkLW1zLXNhbi1zYy1sb2dvbi11cG4gU0FOIGlu
IHRoZSBjbGllbnQNCiAgIGNlcnRpZmljYXRlIGlzIHRvIHZhbGlkYXRlIHRoZSBjbGllbnQgbWFw
cGluZyAoaW4gb3RoZXIgd29yZHMsIHRoZQ0KICAgY2xpZW50J3MgcHVibGljIGtleSBpcyBib3Vu
ZCB0byB0aGUgYWNjb3VudCB0aGF0IGhhcyB0aGlzDQogICBVc2VyUHJpbmNpcGFsTmFtZSB2YWx1
ZSkuDQoNCiAgIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGFsbCBNaWNyb3NvZnQgS2VyYmVyb3Mg
cmVhbG0gbmFtZXMgYXJlIGRvbWFpbg0KICAgc3R5bGUgcmVhbG0gbmFtZXMgYW5kIHN0cmljdGx5
IGluIHVwcGVyIGNhc2UuICBJbiBhZGRpdGlvbiwgdGhlDQogICBVc2VyUHJpbmNpcGFsTmFtZSBh
dHRyaWJ1dGUgaXMgZ2xvYmFsbHkgdW5pcXVlIGluIFdpbmRvd3MgMjAwMCBhbmQNCiAgIFdpbmRv
d3MgMjAwMy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KWmh1ICYgVHVuZyAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjcs
IDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNDBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg
ICAgICAgICAgICBQS0lOSVQgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDYNCg0KDQpB
dXRob3JzJyBBZGRyZXNzZXMNCg0KICAgTGFycnkgWmh1DQogICBNaWNyb3NvZnQgQ29ycG9yYXRp
b24NCiAgIE9uZSBNaWNyb3NvZnQgV2F5DQogICBSZWRtb25kLCBXQSAgOTgwNTINCiAgIFVTDQoN
CiAgIEVtYWlsOiBsemh1QG1pY3Jvc29mdC5jb20NCg0KDQogICBCcmlhbiBUdW5nDQogICBVU0Mg
SW5mb3JtYXRpb24gU2NpZW5jZXMgSW5zdGl0dXRlDQogICA0Njc2IEFkbWlyYWx0eSBXYXkgU3Vp
dGUgMTAwMQ0KICAgTWFyaW5hIGRlbCBSZXksIENBICA5MDI5Mg0KICAgVVMNCg0KICAgRW1haWw6
IGJyaWFuQGlzaS5lZHUNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClpodSAmIFR1bmcgICAgICAgICAgICAgICAgRXhwaXJl
cyBKdWx5IDI3LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDQxXQ0KDA0KSW50ZXJuZXQtRHJh
ZnQgICAgICAgICAgICAgICAgICAgUEtJTklUICAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAy
MDA2DQoNCg0KSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0
YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0K
ICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdo
dCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ug
b2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBl
eHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9y
IG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhh
cw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJp
Z2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8g
cmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJD
UCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNl
Y3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBh
dmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4g
YSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBw
cm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNw
ZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVw
b3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGlu
dml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkN
CiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIg
cHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5
IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRy
ZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcu
DQoNCg0KRGlzY2xhaW1lciBvZiBWYWxpZGl0eQ0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUg
aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJ
UyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQ
UkVTRU5UUw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09D
SUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlN
IEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5P
VCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1B
VElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0K
ICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNV
TEFSIFBVUlBPU0UuDQoNCg0KQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMp
IFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdA0K
ICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4g
QkNQIDc4LCBhbmQNCiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMg
cmV0YWluIGFsbCB0aGVpciByaWdodHMuDQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGlu
ZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRo
ZQ0KICAgSW50ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KWmh1ICYgVHVuZyAgICAgICAgICAgICAg
ICBFeHBpcmVzIEp1bHkgMjcsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNDJdDQoMDQoNCg==

------_=_NextPart_001_01C6208C.3E155F3F--





From ietf-bounces@ietf.org Tue Jan 24 00:18:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1GZT-0002Kw-Bc; Tue, 24 Jan 2006 00:18:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1GZR-0002Jj-PD
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 00:18:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07555
	for ; Tue, 24 Jan 2006 00:16:51 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1Giv-0001aa-LT
	for ietf@ietf.org; Tue, 24 Jan 2006 00:28:10 -0500
Received: (qmail 29402 invoked from network); 24 Jan 2006 05:18:10 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 24 Jan 2006 05:18:10 -0000
Date: 24 Jan 2006 05:18:11 -0000
Message-ID: <20060124051811.77775.qmail@simone.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <788033752.20060123231048@atkielski.com>
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Subject: Re: junior lawyers, was List archives and copyright 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>The key phrase here is "you are informed."  You have to be informed
>and agree to it. ...

Can I politely encourage people who are not lawyers to refrain from
expressing legal opinions here, or even worse stating legal opinions
as though they were facts?

I know just enough about copyright law to know that it is complex and
subtle, it is hard to say exactly what is a license and what is fair
use, and should a situation like this end up in court, the result will
depend on the detailed facts of the case including arguments about
what's the customary usage of messages sent to mailing lists and
whether people are aware of the physical locations of archives so they
know what law applies and so forth.  I have my opinions about what's
legitimate and what's not, but I am not under any illusions that a
judge would necessarily agree with me.

Besides, we already got the opinion of an actual lawyer for free.
What a deal.

R's,
John


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 00:18:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1GZu-0002RN-Hc; Tue, 24 Jan 2006 00:18:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1GZs-0002RA-5G
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 00:18:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07601
	for ; Tue, 24 Jan 2006 00:17:18 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1GjL-0001bz-FP
	for ietf@ietf.org; Tue, 24 Jan 2006 00:28:36 -0500
Received: (qmail 205 invoked from network); 24 Jan 2006 05:18:45 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 24 Jan 2006 05:18:45 -0000
Date: 24 Jan 2006 05:18:45 -0000
Message-ID: <20060124051845.77931.qmail@simone.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <1901529503.20060124053618@atkielski.com>
Cc: ietf@ietf.org
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Content-Transfer-Encoding: 7bit
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>Replace "Mr. Morfin" with "Dr. King" and see how it sounds.

Have we just discovered a new corollary to Godwin's Law?

R's,
John

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 00:18:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1GZv-0002Rn-JQ; Tue, 24 Jan 2006 00:18:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1GZs-0002RF-IQ
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 00:18:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07602
	for ; Tue, 24 Jan 2006 00:17:18 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1GjL-0001by-FP
	for ietf@ietf.org; Tue, 24 Jan 2006 00:28:36 -0500
Received: (qmail 205 invoked from network); 24 Jan 2006 05:18:45 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 24 Jan 2006 05:18:45 -0000
Date: 24 Jan 2006 05:18:45 -0000
Message-ID: <20060124051845.77931.qmail@simone.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <1901529503.20060124053618@atkielski.com>
Cc: ietf@ietf.org
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Content-Transfer-Encoding: 7bit
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>Replace "Mr. Morfin" with "Dr. King" and see how it sounds.

Have we just discovered a new corollary to Godwin's Law?

R's,
John

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 00:53:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1H7D-0006BR-Iy; Tue, 24 Jan 2006 00:53:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1H7A-00068X-Sp
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 00:53:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09649
	for ; Tue, 24 Jan 2006 00:51:42 -0500 (EST)
Received: from xenotime.net ([66.160.160.81])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1HGc-0002g2-VY
	for ietf@ietf.org; Tue, 24 Jan 2006 01:03:01 -0500
Received: from midway.site ([71.111.157.99]) by xenotime.net for
	; Mon, 23 Jan 2006 21:53:07 -0800
Date: Mon, 23 Jan 2006 21:53:19 -0800
From: "Randy.Dunlap" 
To: John Levine 
Message-Id: <20060123215319.24987c7d.rdunlap@xenotime.net>
In-Reply-To: <20060124051845.77931.qmail@simone.iecc.com>
References: <1901529503.20060124053618@atkielski.com>
	<20060124051845.77931.qmail@simone.iecc.com>
Organization: YPO4
X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.3; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 24 Jan 2006 05:18:45 -0000 John Levine wrote:

> >Replace "Mr. Morfin" with "Dr. King" and see how it sounds.
> 
> Have we just discovered a new corollary to Godwin's Law?

or
http://en.wikipedia.org/wiki/Senator,_you_are_no_Jack_Kennedy


but all of this is so way off-topic, it's pitiful to see
this in/on/at IETF.

---
~Randy

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 01:07:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1HKc-0001ao-Eu; Tue, 24 Jan 2006 01:07:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1HKZ-0001ai-BT
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 01:07:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10467
	for ; Tue, 24 Jan 2006 01:05:33 -0500 (EST)
Received: from netcore.fi ([193.94.160.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1HU2-00037M-Um
	for ietf@ietf.org; Tue, 24 Jan 2006 01:16:52 -0500
Received: from netcore.fi (localhost [127.0.0.1])
	by netcore.fi (8.12.8/8.12.8) with ESMTP id k0O66jHa005822
	for ; Tue, 24 Jan 2006 08:06:45 +0200
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0O66jSu005819
	for ; Tue, 24 Jan 2006 08:06:45 +0200
Date: Tue, 24 Jan 2006 08:06:45 +0200 (EET)
From: Pekka Savola 
To: ietf@ietf.org
In-Reply-To: <1797258665.20060123163611@atkielski.com>
Message-ID: 
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: ClamAV version 0.88,
	clamav-milter version 0.87 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed 
	version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 23 Jan 2006, Anthony G. Atkielski wrote:
> John Cowan writes:
>> Filtering him out individually, as I do, is insufficient: one still must
>> read the polite or exasperated responses of others.  I am almost at the
>> point where I will filter any posting that so much as *mentions* him.
>
> Why don't you do that, then, so that he need not be banned just for
> your convenience?

Why must each and every WG member be required to filter a person's 
postings?  Much more convenient to do so in one place.

Maybe you should try participating in a WG trying to be constructive 
sometime.  As far as I can see from quick googling and browsing 
various I-D/RFC data, you've never made any contribution to any IETF 
WG at all, just more or less heated and/or trollish messages at 
ietf@ietf.org.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 01:08:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1HM0-0001tB-2T; Tue, 24 Jan 2006 01:08:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1HLy-0001r1-8A; Tue, 24 Jan 2006 01:08:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10517;
	Tue, 24 Jan 2006 01:07:00 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F1HVS-00039Q-3b; Tue, 24 Jan 2006 01:18:19 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-3.cisco.com with ESMTP; 23 Jan 2006 22:08:19 -0800
X-IronPort-AV: i="4.01,214,1136188800"; 
	d="scan'208"; a="395469401:sNHT30155036"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0O68IKT026480;
	Mon, 23 Jan 2006 22:08:18 -0800 (PST)
Received: from [212.254.247.4] (ams-clip-vpn-dhcp4256.cisco.com [10.61.80.159])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0O6ClRt019330;
	Mon, 23 Jan 2006 22:12:48 -0800
Message-ID: <43D5C44F.6000708@cisco.com>
Date: Tue, 24 Jan 2006 07:08:15 +0100
From: Eliot Lear 
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Marshall Eubanks 
References: <313680C9A886D511A06000204840E1CF0C88635E@whq-msgusr-02.pit.comms.marconi.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=192; t=1138083169; x=1138515369;
	c=relaxed/simple; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20
	|Subject:Re=3A=20IETF=20Last=20Call=20under=20RFC=203683=20concerning=20JFC=20(Je
	fsey)=20Morfin
	|To:Marshall=20Eubanks=20;
	X=v=3Dmtcc.com=3B=20h=3DW/Q75B5u32J11Ldu4hUa76Qzo9Q=3D;
	b=mEUZdWXxkMBVmB6Z1hEjxvWgtYYFETjqzcTiAj3Ur2N6RucH6e61tBucS6sR+GfUMqTOPSws
	vI1kjoJDgRZUvio82YvV1Vi3lF7giEEYaLbWaDgL62MWRqnmATPbC0mAkP74Qf+aQM5lmRBdIQ4
	50F5L9s+O+N/KWsQmywejgo0=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com;
	dkim=pass ( message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Content-Transfer-Encoding: 7bit
Cc: "'ietf@ietf.org'" , "'iesg@ietf.org'" 
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Marshall Eubanks wrote:
>
> P.S. I was not appointed "ombudsman for the IETF list" and would not
> claim that honor.
Sorry- wrong word.  Sargeant at Arms (my own sleeplessness).

Eliot

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 03:03:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1J9Y-0001YI-3w; Tue, 24 Jan 2006 03:03:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1J9U-0001Y0-HD
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 03:03:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17055
	for ; Tue, 24 Jan 2006 03:02:13 -0500 (EST)
Received: from mtagate4.de.ibm.com ([195.212.29.153])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1JJ0-0006kT-5d
	for ietf@ietf.org; Tue, 24 Jan 2006 03:13:34 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0O82xln067572
	for ; Tue, 24 Jan 2006 08:03:00 GMT
Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com
	[9.149.165.213])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0O82TrA063288
	for ; Tue, 24 Jan 2006 09:02:29 +0100
Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0O82TcG027606 for ; Tue, 24 Jan 2006 09:02:29 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0O82SWT027590; Tue, 24 Jan 2006 09:02:29 +0100
Received: from zurich.ibm.com (sig-9-145-250-158.de.ibm.com [9.145.250.158])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA74504;
	Tue, 24 Jan 2006 09:02:27 +0100
Message-ID: <43D5DF14.4080705@zurich.ibm.com>
Date: Tue, 24 Jan 2006 09:02:28 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Ken Raeburn 
References: <200601232206.RAA26102@ietf.org>
	<990E19C4-E511-485D-962D-27F7C05A1573@mit.edu>
In-Reply-To: <990E19C4-E511-485D-962D-27F7C05A1573@mit.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: IETF General Discussion Mailing List 
Subject: Questionnaire [Re: IETFs... the final Friday?]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Ken Raeburn wrote:
...
>> Finally, I noticed the IAD included a question about Friday meeting or
>> not in the survey we were invited to on 9 January.  Getting a sense of
>> peoples' views quantitatively is good, though that was a
>> self-selected group, rather than a random sample that could be
>> assigned a statistical mapping to the IETF population.
> 
> 
> How about a questionnaire at the next IETF or two?  (With collection  
> going through Friday noon at least, of course.)  Still somewhat self- 
> selected, but it's reaching out specifically to those who attend  
> regularly.

I think we'll stick to an on-line survey; having people do their own
data entry and having a computer add up the numbers saves a lot of
clerical expense. We can discriminate in the survey between attendees
and non-attendees. As for the self-selection bias that Allison notes,
I'm afraid that is very hard to avoid without much more work.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 03:24:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1JTv-0001Cz-Ue; Tue, 24 Jan 2006 03:24:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1JTt-0001CJ-TV
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 03:24:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18587
	for ; Tue, 24 Jan 2006 03:23:18 -0500 (EST)
Received: from mtagate3.uk.ibm.com ([195.212.29.136])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1JdO-0007UN-AQ
	for ietf@ietf.org; Tue, 24 Jan 2006 03:34:39 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0O8OROC075826
	for ; Tue, 24 Jan 2006 08:24:29 GMT
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com
	[9.149.37.216])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0O8N0aS021106 for ; Tue, 24 Jan 2006 08:23:00 GMT
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0O8MxMg013328 for ; Tue, 24 Jan 2006 08:22:59 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0O8MxtE013319 for ; Tue, 24 Jan 2006 08:22:59 GMT
Received: from zurich.ibm.com (sig-9-145-250-158.de.ibm.com [9.145.250.158])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA50372
	for ; Tue, 24 Jan 2006 09:22:58 +0100
Message-ID: <43D5E3E3.4070809@zurich.ibm.com>
Date: Tue, 24 Jan 2006 09:22:59 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: ietf@ietf.org
References: <43D586A9.8090304@swin.edu.au>
	<192584976.20060124053434@atkielski.com>
In-Reply-To: <192584976.20060124053434@atkielski.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Subject: Re: posting privileges vs receiver-side filtering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Anthony G. Atkielski wrote:
> grenville armitage writes:
> 
> 
>>- protects agains dilution of a WG's historical record (archives
>>that soak up all posts to the WG's mailing list)
> 
> 
> Stop blindly archiving every message, and this ceases to be a problem.

The IETF standards process requires us to archive WG mailing lists.
For good reasons: open process requires a public record, and prior art
claims can be checked.

> 
> 
>>- improves the 'signal to distraction' ratio of traffic on the list
>>(particularly important for list residents charged with keeping
>>things on charter and evaluating rough consensus)
> 
> 
> Distraction is in the eye of the beholder.  Ignoring something
> requires no action;

Not true. When one receives a few hundred emails per day, the act of
ignoring, say, 75% of them takes a significant amount of time. Even
the act of maintaining one's personal filters takes a significant
amount of time.

...
> 
>>Yes, revocation of posting privileges and receiver-side filtering both
>>cause a drop in traffic reaching one's inbox. But that doesn't 
>>make the actions equivalent.
> 
> 
> Yes.  The former is censorship, the latter is not.

It isn't censorship. It isn't infringing anybody's free speech.
It's very specifically restricting misuse of mailing lists that
have been set up for a given purpose. That is well within bounds
for a community such as ours.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 05:00:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1KyO-0001IU-Ir; Tue, 24 Jan 2006 05:00:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1KyM-0001IP-AJ
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 05:00:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24642
	for ; Tue, 24 Jan 2006 04:58:52 -0500 (EST)
From: Julien.Maisonneuve@alcatel.com
Received: from smail3.alcatel.fr ([62.23.212.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1L7q-0002UV-M9
	for ietf@ietf.org; Tue, 24 Jan 2006 05:10:13 -0500
Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr
	[155.132.182.163])
	by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k0O9xvT5008568;
	Tue, 24 Jan 2006 11:00:02 +0100
Received: from [155.132.126.127] ([155.132.126.127])
	by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a)
	with ESMTP id 2006012410595775:2703 ;
	Tue, 24 Jan 2006 10:59:57 +0100 
Message-ID: <43D5FA9D.8090200@alcatel.com>
Date: Tue, 24 Jan 2006 10:59:57 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.11) Gecko/20050728
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Theodore Ts'o" 
References: <200601232206.RAA26102@ietf.org>	<990E19C4-E511-485D-962D-27F7C05A1573@mit.edu>	<86zmlmk2co.fsf@raman.networkresonance.com>	<89C6E50B5BBFB767B68066FF@sirius.fac.cs.cmu.edu>
	<20060124013629.GA27182@thunk.org>
In-Reply-To: <20060124013629.GA27182@thunk.org>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a
	|January 7, 2002) at 01/24/2006 10:59:57,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7,
	2002) at 01/24/2006 11:00:02,
	Serialize complete at 01/24/2006 11:00:02
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Alcanet-MTA-scanned-and-authorized: yes
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: Ken Raeburn ,
	IETF General Discussion Mailing List 
Subject: Re: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Theodore Ts'o wrote:

>... not to mention the cost of keeping the hotel rooms for the extra
>day or so.  (Presumably if some or all of the wireless infrastructure
>is left running until Friday night, it means that at least some of the
>rooms can't get released back to the hotel until mid-day Saturday, and
>the volunteers will have to do some of the final teardown Saturday
>morning.)
>
Teardown doesn't take so much time (from my last participation to it)  
that you couldn't postpone the final moment and still be able to remove 
it the same day. In addition, we're not necessarily talking about 
leaving it all up. It would be enough to leave a few Wifi spots and a 
couple of wired switches in/close to the terminal room, leaving a lot of 
space for teardown work (meeting rooms, most of the APs, cables, 
terminal room tables/switches/power/printers, backup links,...). Routers 
and other equipment would go last, but most of the work would already be 
done by then.
So it doesn't have to be exactly noon, there is some wiggle room there.
Regards,
Julien.

-- 
Julien Maisonneuve                      


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 07:37:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1NQK-00062m-Do; Tue, 24 Jan 2006 07:37:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1NQI-00062a-OY
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 07:37:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07688
	for ; Tue, 24 Jan 2006 07:35:52 -0500 (EST)
Received: from sccrmhc11.comcast.net ([63.240.77.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1NZq-0008Qe-2l
	for ietf@ietf.org; Tue, 24 Jan 2006 07:47:15 -0500
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165])
	by comcast.net (sccrmhc11) with SMTP
	id <200601241236590110099q99e>; Tue, 24 Jan 2006 12:36:59 +0000
Message-ID: <065501c620e2$b2890620$a9087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: 
Date: Tue, 24 Jan 2006 06:35:44 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Subject: Putting ideas into practice
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

We're generating quite a bit of e-mail under two or three separate threads 
that may not be changing anyone's mind, and we're seeing suggestions for 
actions that probably require BCP changes in order to implement them.

While I would not dream of asking people to refrain from sharing their 
opinions on this list at whatever typing speed their fleshware will support, 
It Might Be More Effective to write internet drafts that capture these 
excellent ideas and propose RFC 3933 process experiments that would actually 
cause the ideas to be implemented.

... unless you think the IETF bases process changes off e-mail postings, in 
which case, please feel free to keep typing at line rate.

Thanks,

Spencer 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 08:48:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1OXN-00032k-IN; Tue, 24 Jan 2006 08:48:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1OXL-00032f-6J
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 08:48:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12940
	for ; Tue, 24 Jan 2006 08:47:12 -0500 (EST)
Received: from mtagate2.de.ibm.com ([195.212.29.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Ogs-0002hO-P4
	for ietf@ietf.org; Tue, 24 Jan 2006 08:58:36 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0ODLVS1217884
	for ; Tue, 24 Jan 2006 13:48:21 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com
	[9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0OD6NrA232804
	for ; Tue, 24 Jan 2006 14:06:23 +0100
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0OD6NDp002404 for ; Tue, 24 Jan 2006 14:06:23 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0OD6MJS002377; Tue, 24 Jan 2006 14:06:22 +0100
Received: from zurich.ibm.com (sig-9-145-250-158.de.ibm.com [9.145.250.158])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA59810;
	Tue, 24 Jan 2006 14:06:21 +0100
Message-ID: <43D6264C.8040707@zurich.ibm.com>
Date: Tue, 24 Jan 2006 14:06:20 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: IETF General Discussion Mailing List 
References: <200601232206.RAA26102@ietf.org>	<990E19C4-E511-485D-962D-27F7C05A1573@mit.edu>	<86zmlmk2co.fsf@raman.networkresonance.com>	<89C6E50B5BBFB767B68066FF@sirius.fac.cs.cmu.edu>	<20060124013629.GA27182@thunk.org>
	<43D5FA9D.8090200@alcatel.com>
In-Reply-To: <43D5FA9D.8090200@alcatel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Let's not sweat the details on this list.

We've got two points from this conversation:

1. it is good to have BOFs earlier in the week if possible,
subject to scheduling constraints.

2. it would be much appreciated, subject to financial limits,
to have some wireless connectivity through Friday afternoon.

I'm sure the IAD will note these points for future
planning.

    Brian

Julien.Maisonneuve@alcatel.com wrote:
> Theodore Ts'o wrote:
> 
>> ... not to mention the cost of keeping the hotel rooms for the extra
>> day or so.  (Presumably if some or all of the wireless infrastructure
>> is left running until Friday night, it means that at least some of the
>> rooms can't get released back to the hotel until mid-day Saturday, and
>> the volunteers will have to do some of the final teardown Saturday
>> morning.)
>>
> Teardown doesn't take so much time (from my last participation to it)  
> that you couldn't postpone the final moment and still be able to remove 
> it the same day. In addition, we're not necessarily talking about 
> leaving it all up. It would be enough to leave a few Wifi spots and a 
> couple of wired switches in/close to the terminal room, leaving a lot of 
> space for teardown work (meeting rooms, most of the APs, cables, 
> terminal room tables/switches/power/printers, backup links,...). Routers 
> and other equipment would go last, but most of the work would already be 
> done by then.
> So it doesn't have to be exactly noon, there is some wiggle room there.
> Regards,
> Julien.
> 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 08:58:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1OgO-0005ol-RD; Tue, 24 Jan 2006 08:58:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1OgM-0005hJ-HG
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 08:58:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13551
	for ; Tue, 24 Jan 2006 08:56:31 -0500 (EST)
Received: from sccrmhc14.comcast.net ([204.127.202.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Opu-00032M-I7
	for ietf@ietf.org; Tue, 24 Jan 2006 09:07:55 -0500
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165])
	by comcast.net (sccrmhc14) with SMTP
	id <2006012413574901400eeleee>; Tue, 24 Jan 2006 13:57:49 +0000
Message-ID: <078201c620ed$fd138250$a9087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: "IETF General Discussion Mailing List" 
References: <200601232206.RAA26102@ietf.org>	<990E19C4-E511-485D-962D-27F7C05A1573@mit.edu>	<86zmlmk2co.fsf@raman.networkresonance.com>	<89C6E50B5BBFB767B68066FF@sirius.fac.cs.cmu.edu>	<20060124013629.GA27182@thunk.org><43D5FA9D.8090200@alcatel.com>
	<43D6264C.8040707@zurich.ibm.com>
Date: Tue, 24 Jan 2006 07:56:34 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Subject: Re: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ack.

> Let's not sweat the details on this list.
> 
> We've got two points from this conversation:
> 
> 1. it is good to have BOFs earlier in the week if possible,
> subject to scheduling constraints.
> 
> 2. it would be much appreciated, subject to financial limits,
> to have some wireless connectivity through Friday afternoon.
> 
> I'm sure the IAD will note these points for future
> planning.
> 
>    Brian

And thanks!

Spencer


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 09:43:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1POi-0001Bp-46; Tue, 24 Jan 2006 09:43:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1POg-0001BV-8h
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 09:43:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16363
	for ; Tue, 24 Jan 2006 09:42:19 -0500 (EST)
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1PYE-0004ZN-BW
	for ietf@ietf.org; Tue, 24 Jan 2006 09:53:43 -0500
Received: from [192.168.0.102] (ppp-70-244-171-13.dsl.rcsntx.swbell.net
	[70.244.171.13]) (authenticated bits=0)
	by nostrum.com (8.13.4/8.13.4) with ESMTP id k0OEhYXu043891
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Jan 2006 08:43:35 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <43D63D11.1080404@nostrum.com>
Date: Tue, 24 Jan 2006 08:43:29 -0600
From: Adam Roach 
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ken Raeburn 
References: 
	<41F3E06C-B157-4B0B-AB75-03CBA7777EB8@mit.edu>
In-Reply-To: <41F3E06C-B157-4B0B-AB75-03CBA7777EB8@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 70.244.171.13 is authenticated by a
	trusted mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" , jordi.palet@consulintel.es
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ken Raeburn wrote:

> Are there [802.11a] cards with Mac OS X drivers nowadays?

This device has a lot of geek appeal; in addition to A/G/B support, it 
acts as a stand-alone handheld 802.11 network detection device:

http://www.zyxel.com/product/model.php?indexcate=1131440677

The spec sheet doesn't make it obvious, but they do have an OS X driver 
available:

ftp://ftp.us.zyxel.com/AG-225H/MacOSDriver/AG-225H_MacOSdriver_v1.10.zip

/a



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 10:30:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Q8B-00054I-3R; Tue, 24 Jan 2006 10:30:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Q88-000524-NA
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 10:30:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21483
	for ; Tue, 24 Jan 2006 10:29:16 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1QHe-0006rG-JA
	for ietf@ietf.org; Tue, 24 Jan 2006 10:40:42 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0OFUUof074893
	for ; Tue, 24 Jan 2006 16:30:30 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Tue, 24 Jan 2006 16:30:30 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <792569437.20060124163030@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060124051811.77775.qmail@simone.iecc.com>
References: <788033752.20060123231048@atkielski.com>
	<20060124051811.77775.qmail@simone.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Subject: Re: junior lawyers, was List archives and copyright
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John Levine writes:

> Can I politely encourage people who are not lawyers to refrain from
> expressing legal opinions here, or even worse stating legal opinions
> as though they were facts?

Why?  IP litigation is usually a roll of the dice, anyway.

> I know just enough about copyright law to know that it is complex and
> subtle, it is hard to say exactly what is a license and what is fair
> use, and should a situation like this end up in court, the result will
> depend on the detailed facts of the case including arguments about
> what's the customary usage of messages sent to mailing lists and
> whether people are aware of the physical locations of archives so they
> know what law applies and so forth.  I have my opinions about what's
> legitimate and what's not, but I am not under any illusions that a
> judge would necessarily agree with me.
>
> Besides, we already got the opinion of an actual lawyer for free.
> What a deal.

See above.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 10:33:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1QAp-0006oA-Jf; Tue, 24 Jan 2006 10:33:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1QAn-0006nD-8r
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 10:33:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21982
	for ; Tue, 24 Jan 2006 10:32:01 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1QKL-00075F-DB
	for ietf@ietf.org; Tue, 24 Jan 2006 10:43:27 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0OFXLFJ074938
	for ; Tue, 24 Jan 2006 16:33:21 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Tue, 24 Jan 2006 16:33:21 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <0728557.20060124163321@atkielski.com>
To: ietf@ietf.org
In-Reply-To: 
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Subject: Re: John Cowan supports 3683 PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Pekka Savola writes:

> Why must each and every WG member be required to filter a person's
> postings?  Much more convenient to do so in one place.

Because each and every WG member is an individual, with his own ideas
of what he does or doesn't want to read, and imposing the same rules
upon everyone prevents members from making their own decisions.  It
also imposes the decisions of a small minority upon the majority.

> Maybe you should try participating in a WG trying to be constructive
> sometime.

Maybe.  Do they involve as much puerile bickering as this list?

> As far as I can see from quick googling and browsing
> various I-D/RFC data, you've never made any contribution to any IETF
> WG at all, just more or less heated and/or trollish messages at 
> ietf@ietf.org.

As far as I know, you're a complete stranger who resorts to personal
attacks from his very first post.  Maybe this list is just the place
for you, from what I've seen.



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 10:36:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1QDR-0007j3-4j; Tue, 24 Jan 2006 10:36:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1QDQ-0007hi-35
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 10:36:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22244
	for ; Tue, 24 Jan 2006 10:34:44 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1QMy-0007DE-M3
	for ietf@ietf.org; Tue, 24 Jan 2006 10:46:10 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0OFa5SJ074962
	for ; Tue, 24 Jan 2006 16:36:05 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Tue, 24 Jan 2006 16:36:05 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <194198333.20060124163605@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D5E3E3.4070809@zurich.ibm.com>
References: <43D586A9.8090304@swin.edu.au>
	<192584976.20060124053434@atkielski.com>
	<43D5E3E3.4070809@zurich.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Subject: Re: posting privileges vs receiver-side filtering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian E Carpenter writes:

> The IETF standards process requires us to archive WG mailing lists.
> For good reasons: open process requires a public record, and prior art
> claims can be checked.

How much of an open process can there be if some input is censored?

> Not true. When one receives a few hundred emails per day, the act of
> ignoring, say, 75% of them takes a significant amount of time.

No, it does not.  I do it.  I know people like to give that impression
so that they can justify censorship, but it just doesn't take that
much time.

> Even the act of maintaining one's personal filters takes a
> significant amount of time.

See above.

> It isn't censorship.

Whenever a third party decides to prevent one party from communicating
with another, it's censorship.

> It's very specifically restricting misuse of mailing lists that
> have been set up for a given purpose. That is well within bounds
> for a community such as ours.

Unfortunately, there is no objective defintion of misuse, so it
resolves to highly subjective censorship, and often the grounds for
censorship are practically unrelated to real utility or a lack
thereof.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 10:45:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1QMX-0003me-SE; Tue, 24 Jan 2006 10:45:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1QMV-0003mX-R0
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 10:45:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22956
	for ; Tue, 24 Jan 2006 10:44:08 -0500 (EST)
Received: from sccrmhc14.comcast.net ([63.240.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1QW4-0007Xj-P4
	for ietf@ietf.org; Tue, 24 Jan 2006 10:55:34 -0500
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165])
	by comcast.net (sccrmhc14) with SMTP
	id <2006012415452701400ek7qqe>; Tue, 24 Jan 2006 15:45:27 +0000
Message-ID: <07f401c620fd$060b33d0$a9087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: <43D586A9.8090304@swin.edu.au><192584976.20060124053434@atkielski.com><43D5E3E3.4070809@zurich.ibm.com>
	<194198333.20060124163605@atkielski.com>
Date: Tue, 24 Jan 2006 09:44:12 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Subject: Re: posting privileges vs receiver-side filtering
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Now that we are reaching the stage of "is not"/"is too" discourse, could the 
people who need so desperately to convince each other try private e-mail?

Please feel free to google my own posting history on this list. At one 
point, I thought posting to this list was an effective way to accomplish 
change at the IETF. It's not. If you care, write a draft. If you don't care 
...

Thanks,

Spencer

From: "Anthony G. Atkielski" 
> Brian E Carpenter writes:
>> Not true. When one receives a few hundred emails per day, the act of
>> ignoring, say, 75% of them takes a significant amount of time.
>
> No, it does not.  I do it.  I know people like to give that impression
> so that they can justify censorship, but it just doesn't take that
> much time. 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 10:52:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1QT1-0005Ez-T5; Tue, 24 Jan 2006 10:52:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1QSy-0005Ek-KY
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 10:52:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23481
	for ; Tue, 24 Jan 2006 10:50:49 -0500 (EST)
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1QcY-0007nB-Jn
	for ietf@ietf.org; Tue, 24 Jan 2006 11:02:14 -0500
Received: from [172.17.2.251] (dsl001-129-069.dfw1.dsl.speakeasy.net
	[72.1.129.69]) (authenticated bits=0)
	by nostrum.com (8.13.4/8.13.4) with ESMTP id k0OFq6EB044793
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Jan 2006 09:52:06 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <43D64D23.3010709@nostrum.com>
Date: Tue, 24 Jan 2006 09:52:03 -0600
From: Adam Roach 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ray Pelletier 
References: 	<43D0C93F.5010306@zurich.ibm.com>	<20060120113450.GM9015@login.ecs.soton.ac.uk>	<43D0EE7E.1050409@zurich.ibm.com>	
	<43D15848.6020408@isoc.org>
In-Reply-To: <43D15848.6020408@isoc.org>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 72.1.129.69 is authenticated by a
	trusted mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: Tim Chown , IETF Discussion 
Subject: Re: hotels for Dallas?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ray Pelletier wrote:

>
> Jeffrey Hutzelman wrote:
>
>>
>> We understand that the new registration system is taking time to get 
>> working, and I doubt that's a big problem for many people.  But as of 
>> this writing, there is no information on the IETF web site about the 
>> meeting venue or hotels.  Any idea when that will change?
>>
>> -- Jeff
>
>
> I expect it to change Monday 23 January.
> Ray Pelletier
> IETF Administrative Director


Do we have a new ETA?

/a

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 10:55:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1QW3-0005mz-Hs; Tue, 24 Jan 2006 10:55:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1QW2-0005mu-1n
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 10:55:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23897
	for ; Tue, 24 Jan 2006 10:53:58 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc11.comcast.net ([204.127.202.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1QfX-0007wr-QO
	for ietf@ietf.org; Tue, 24 Jan 2006 11:05:24 -0500
Received: from smailcenter45.comcast.net ([204.127.205.145])
	by comcast.net (sccrmhc11) with SMTP
	id <20060124155516011009bjude>; Tue, 24 Jan 2006 15:55:16 +0000
Received: from [66.229.53.140] by smailcenter45.comcast.net;
	Tue, 24 Jan 2006 15:55:14 +0000
To: jnc@mercury.lcs.mit.edu (Noel Chiappa), ietf@ietf.org
Date: Tue, 24 Jan 2006 15:55:14 +0000
Message-Id: <012420061555.6491.43D64DE200080E890000195B220076230200000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: how to declare consensus when someone ignores consensus
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0789072668=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0789072668==
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_6491_1138118114_0"


--NextPart_Webmail_9m3u9jl4l_6491_1138118114_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

-------------- Original message -------------- 
From: jnc@mercury.lcs.mit.edu (Noel Chiappa) 
> Ah, I suspect that Elwyn was gently pulling your leg about your inability to 
> spell "capital" (i.e. the death penalty) - "capitol" means "location of the 
> government" 
Ahh haaa....damn word...it'll pay for that...;)
Now imagine if you looked up the word Capital in the dictionary and it read like this:

Capital - Although not exhaustive, examples of the meaning of the word Capital include:  Wealth in the form of money or property; Human resources considered in terms of their contributions to an economy; a city that is the center of a specific activity or industry;  etc.

Maybe some of our inaction comes from having policies that are a little too open-ended.  I don't like being locked into rules but maybe there are cases where we can't be so open ended  (RISC vs. CISC?).  Maybe if we made our operational policies specific and all-inclusive we wouldn't have to reinterpret them every time we went to use them.  Then again maybe we want reinterpretation.

Nick
--NextPart_Webmail_9m3u9jl4l_6491_1138118114_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit





-------------- Original message -------------- 
From: jnc@mercury.lcs.mit.edu (Noel Chiappa) 


> Ah, I suspect that Elwyn was gently pulling your leg about your inability to 
> spell "capital" (i.e. the death penalty) - "capitol" means "location of the 
> government" 


Ahh haaa....damn word...it'll pay for that...;)


Now imagine if you looked up the word Capital in the dictionary and it read like this:


 


Capital - Although not exhaustive, examples of the meaning of the word Capital include:  Wealth in the form of money or property; Human resources considered in terms of their contributions to an economy; a city that is the center of a specific activity or industry;  etc.


 


Maybe some of our inaction comes from having policies that are a little too open-ended.  I don't like being locked into rules but maybe there are cases where we can't be so open ended  (RISC vs. CISC?).  Maybe if we made our operational policies specific and all-inclusive we wouldn't have to reinterpret them every time we went to use them.  Then again maybe we want reinterpretation.


 


Nick


--NextPart_Webmail_9m3u9jl4l_6491_1138118114_0--


--===============0789072668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0789072668==--




From ietf-bounces@ietf.org Tue Jan 24 11:22:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1QwL-0006rg-43; Tue, 24 Jan 2006 11:22:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1QwI-0006qs-RA
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 11:22:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26817
	for ; Tue, 24 Jan 2006 11:21:09 -0500 (EST)
Received: from mx1.magmacom.com ([206.191.0.217])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1R5s-0000sJ-0o
	for ietf@ietf.org; Tue, 24 Jan 2006 11:32:33 -0500
Received: from mail4.magma.ca (mail4.magma.ca [206.191.0.222])
	by mx1.magmacom.com (8.13.0/8.13.0) with ESMTP id k0OGMZJe026135
	for ; Tue, 24 Jan 2006 11:22:36 -0500
Received: from [192.168.1.175] (209-87-232-162.storm.ca [209.87.232.162])
	(authenticated bits=0)
	by mail4.magma.ca (8.13.0/8.13.0) with ESMTP id k0OGMXGt030585
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for ; Tue, 24 Jan 2006 11:22:35 -0500
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Transfer-Encoding: 7bit
Message-Id: 
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: ietf@ietf.org
From: Philip Matthews 
Date: Tue, 24 Jan 2006 11:23:08 -0500
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Subject: P2P-SIP effort
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In light of the recent discussion of P2P protocols, I would like to  
call people's attention
to the proposal to form a working group to develop methods of using  
SIP in a fully distributed
P2P network. There is an active mailing list, there are some internet- 
drafts, there is a draft charter proposal,
and a BOF slot has been requested for the Dallas meeting.

For more information, check out:
       www.p2psip.org
(which contains information about the effort) AND
       https://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
which is the mailing list.

- Philip



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 11:31:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1R4o-0001k7-0j; Tue, 24 Jan 2006 11:31:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1R4l-0001jv-GD
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 11:31:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27541
	for ; Tue, 24 Jan 2006 11:29:53 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1REK-0001Cs-84
	for ietf@ietf.org; Tue, 24 Jan 2006 11:41:17 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 0873E2596E2
	for ; Tue, 24 Jan 2006 17:29:59 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP id 24097-05 for ;
	Tue, 24 Jan 2006 17:29:54 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 333EB2596E6
	for ; Tue, 24 Jan 2006 17:29:50 +0100 (CET)
Date: Tue, 24 Jan 2006 07:52:57 -0800
From: Harald Tveit Alvestrand 
To: ietf@ietf.org
Message-ID: <09B04E0BD2C340393F2CE025@B50854F0A9192E8EC6CDA126>
In-Reply-To: <39697985.20060124052445@atkielski.com>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>	<20060123211430.GA14409@thunk.org>
	<39697985.20060124052445@atkielski.com>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Subject: Preventing posting vs preventing the airing of opinion
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1243262524=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1243262524==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========1375DB24E08BD1CEAC0C=========="

--==========1375DB24E08BD1CEAC0C==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Distracting from the topic yet again....

--On 24. januar 2006 05:24 +0100 "Anthony G. Atkielski"=20
 wrote:

> Theodore Ts'o writes:
>
>> The problem with the "just filter" approach is that if you then fail
>> to respond to something of substance that got inadvertently filtered
>> out, it is trivially easy to claim rough consensus.
>
> The problem with prior restraint, such as a ban, is that nobody ever
> gets to respond to anything that doesn't toe the party line.  That's a
> general problem with all censorship.

I've seen this claim several times, and it still makes my head hurt to try=20
to relate it to the real world.

If what is important is having an opinion stated, there is no barrier to=20
having a friend (that is, a real person, not an alternate email account)=20
say "I hear from X, and he says...." on your behalf.

Of course there are two cases where this is a problem:

- When, among the participants with posting rights on the list, there isn't =

a single person who is willing to pass on your opinion
- When you are so sure that your words are the perfect expression of what=20
you are trying to say that you refuse to let anyone else touch them before=20
posting

Since this is in the context of the concept of "censorship", there is a=20
third category:

- where the act of passing on your opinion puts the other person in=20
immediate danger of being refused posting rights

I haven't seen that as a realistic fear in the IETF.

                    Harald



--==========1375DB24E08BD1CEAC0C==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFD1k1ZOMj+2+WY0F4RAjHjAJwNi9Yebhq6sU5tCTeuai+z/j4Z9gCgydvb
JrS7pyXhVE44LRo37+wv2nw=
=YPZ4
-----END PGP SIGNATURE-----

--==========1375DB24E08BD1CEAC0C==========--



--===============1243262524==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1243262524==--





From ietf-bounces@ietf.org Tue Jan 24 11:51:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1ROA-0006lG-G8; Tue, 24 Jan 2006 11:51:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1RO8-0006kC-JL
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 11:51:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28993
	for ; Tue, 24 Jan 2006 11:49:54 -0500 (EST)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1RXh-0001xs-VF
	for ietf@ietf.org; Tue, 24 Jan 2006 12:01:19 -0500
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01LY4YXOD7SW0043F0@mauve.mrochek.com> for
	ietf@ietf.org; Tue, 24 Jan 2006 08:51:14 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1138121473;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=ZZVpzvZXkdFLPZGYlcJ9SJz5T
	VJ7I3FOqugBHuZ+/ikc6BPsA7DDZnf5CE5rZeeo6hiHUecfKKfTNOL3OTSlBQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LY4UH2V14W00009C@mauve.mrochek.com>; Tue,
	24 Jan 2006 08:51:12 -0800 (PST)
To: Ken Raeburn 
Message-id: <01LY4YXNERSQ00009C@mauve.mrochek.com>
Date: Tue, 24 Jan 2006 08:45:51 -0800 (PST)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 23 Jan 2006 23:32:13 -0500"
	<41F3E06C-B157-4B0B-AB75-03CBA7777EB8@mit.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; delsp=yes; format=flowed
References: 
	<41F3E06C-B157-4B0B-AB75-03CBA7777EB8@mit.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: ietfietforg , jordi.palet@consulintel.es
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> On Jan 23, 2006, at 21:57, JORDI PALET MARTINEZ wrote:
> > In my own case, having a Mac is not easy to get built-in 802.11a. I
> > can of course buy an external card,

> Are there cards with Mac OS X drivers nowadays?

Yes there are. Here's the one I use:

   http://www.orangeware.com/endusers/wirelessformac.html

There's a fairly long list of supported cards, some of which support 802.11a.
I'm currently using a 3COM 3CRWE154A72 card, FWIW.

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 11:51:49 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1ROX-00070l-SF; Tue, 24 Jan 2006 11:51:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ROV-00070e-97
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 11:51:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29061
	for ; Tue, 24 Jan 2006 11:50:17 -0500 (EST)
From: rpelletier@isoc.org
Received: from smtp116.iad.emailsrvr.com ([207.97.245.116]
	helo=smtp136.iad.emailsrvr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1RY4-0001yy-QK
	for ietf@ietf.org; Tue, 24 Jan 2006 12:01:42 -0500
Received: from secure.webmail.us (webmail1.r1.iad.emailsrvr.com [10.238.10.9])
	by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id
	B463D44C434; Tue, 24 Jan 2006 11:51:32 -0500 (EST)
Received: from 128.9.168.71 (Webmail authenticated user rpelletier@isoc.org,
	rpelletier@isoc.org); by secure.webmail.us with HTTP;
	Tue, 24 Jan 2006 11:51:32 -0500 (EST)
Message-ID: <3373.128.9.168.71.1138121492.webmail@128.9.168.71>
In-Reply-To: <43D64D23.3010709@nostrum.com>
References: 	<43D0C93F.5010306@zurich.ibm.com>	<20060120113450.GM9015@login.ecs.soton.ac.uk>	<43D0EE7E.1050409@zurich.ibm.com>	
	<43D15848.6020408@isoc.org> <43D64D23.3010709@nostrum.com>
Date: Tue, 24 Jan 2006 11:51:32 -0500 (EST)
To: "Adam Roach" 
X-Mailer: Webmail v3
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: OK
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.3 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: quoted-printable
Cc: Tim Chown , IETF Discussion 
Subject: Re: hotels for Dallas?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rpelletier@isoc.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Today.
Of course, the sun never sets on the Internet.
Really today 24 Jan 2006.
Ray




-----Original Message-----
From: "Adam Roach" 
Sent: Tuesday, January 24, 2006 10:52 am
To: "Ray Pelletier" 
Cc: "Jeffrey Hutzelman" 
0"Tim Chown" 
0"IETF Discussion" 
Subject: Re: hotels for Dallas?

Ray Pelletier wrote:

>
> Jeffrey Hutzelman wrote:
>
>>
>> We understand that the new registration system is taking time to get
>> working, and I doubt that's a big problem for many people.  But as of
>> this writing, there is no information on the IETF web site about the
>> meeting venue or hotels.  Any idea when that will change?
>>
>> -- Jeff
>
>
> I expect it to change Monday 23 January.
> Ray Pelletier
> IETF Administrative Director


Do we have a new ETA?

/a



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 13:44:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1T9v-0000Mm-Qt; Tue, 24 Jan 2006 13:44:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1T9t-0000Mh-DH
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 13:44:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08491
	for ; Tue, 24 Jan 2006 13:43:18 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1TJS-0006Uu-1M
	for ietf@ietf.org; Tue, 24 Jan 2006 13:54:44 -0500
Received: from [192.168.0.16] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001582632.msg
	for ; Tue, 24 Jan 2006 19:46:44 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Tue, 24 Jan 2006 14:44:15 -0400
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: Meeting Survey Results
Thread-Index: AcYhFiy5azLM8Y0JEdqeyAANky3PwA==
In-Reply-To: <1138077313.21483.8.camel@essrv103nok155120.ntc.nokia.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060124:ietf@ietf.org::K7kwOvaaCz2Z9qNS:00005v0e
X-MDRemoteIP: 150.189.240.59
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Tue, 24 Jan 2006 19:46:47 +0100
X-MDAV-Processed: consulintel.es, Tue, 24 Jan 2006 19:46:50 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Content-Transfer-Encoding: quoted-printable
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Jonne,

I'm not sure if I got it. My MUST was on the other way around: We really
need to warrantee good coverage for b/g to 75% of the participants.

Regards,
Jordi




> De: "Soininen Jonne (Nokia-NET/Espoo)" 
> Organizaci=F3n: NET/ST/IED
> Responder a: 
> Fecha: Tue, 24 Jan 2006 06:35:13 +0200
> Para: 
> CC: "ietf@ietf.org" 
> Asunto: Re: Meeting Survey Results
>=20
> Hi Jordi,
>=20
> the preference for .11a was stated because we want to make sure that
> everybody who has the possibility for it would use it. It makes the
> network much more reliable. Of course b and g are provided as well.
>=20
> It is a recommendation not a MUST, like the mail says.
>=20
> Cheers,
>=20
> Jonne.
>=20
> On Mon, 2006-01-23 at 22:57 -0400, ext JORDI PALET MARTINEZ wrote:
>> Hi Ray,
>>=20
>> I'm not sure if we need some clarification on this:
>>=20
>>> 1.  Slightly more than 25% say their laptop is compatible with 802.11a.
>>> [Note the IETF 65 NOC for Dallas recommends 802.11a]
>>=20
>> According to the survey, only 25.5% of the participants have 802.11a, which
>> in my opinion means that 11b/g MUST be reliable for 75% of the participants
>> in the next meeting.
>>=20
>> Remember that if we don't have an 802.11a interface in our laptops is
>> because *THEY DONT'T HAVE IT*.
>>=20
>> In my own case, having a Mac is not easy to get built-in 802.11a. I can of
>> course buy an external card, but is not reasonable (more power consumption,
>> more things to carry, etc.). There is one more reason, is that in most of
>> the world is not (today) widely used, so buying it almost only for IETF
>> meetings, don't make too much sense.
>>=20
>> Even do, if it is just me, I will consider buying it, but I don't really
>> agree to get this asked for 75% of the participants. It is not a choice !
>>=20
>> So the clarification is ... what we actually will get at IETF65, and if
>> something must be changed now for getting good 802.11b/g support, please,
>> make sure about that now !
>>=20
>> Regards,
>> Jordi
>>=20
>>=20
>>=20
>>=20
>>> De: 
>>> Responder a: 
>>> Fecha: Mon, 23 Jan 2006 17:45:07 -0500 (EST)
>>> Para: "ietf@ietf.org" 
>>> Asunto: Meeting Survey Results
>>>=20
>>> All;
>>>=20
>>> More than 300 responded to the Meeting Survey conducted following IETF 64
>>> in Vancouver.
>>>=20
>>> See survey results link below.
>>>=20
>>> Among the results are:
>>> 1.  Slightly more than 25% say their laptop is compatible with 802.11a.
>>> [Note the IETF 65 NOC for Dallas recommends 802.11a]
>>>=20
>>> 2.  Nearly 60% (with an additional 23% undecided) prefer dinner following
>>> all sessions of the day.
>>>=20
>>> 3.  Only 23% prefer a full day schedule for Fridays.
>>>=20
>>> 4.  Cookies are not the only craving for breaks -- 74% want more healthy
>>> choices.
>>>=20
>>> 5.  Only 1/3 of the respondents expressed satisfaction with the wireless
>>> connectivity.
>>>=20
>>> And given the opportunity to say what they liked and didn't - 130 told us
>>> how they felt.
>>>=20
>>> Read it for yourselves:
>>> http://www.surveymonkey.com/Report.asp?U=3D165657447306
>>>=20
>>> I and NeuStar Secretariat Services will review these results and make
>>> adjustments as possible for IETF 65 Dallas, March 19 - 24.  And we look
>>> forward to seeing you there.
>>>=20
>>> Thanks for your participation.
>>>=20
>>> Ray Pelletier
>>> IETF Administrative Director.
>>>=20
>>>=20
>>> _______________________________________________
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ietf
>>=20
>>=20
>>=20
>>=20
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>>=20
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>>=20
>> 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.
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 14:37:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Tyv-00072e-2p; Tue, 24 Jan 2006 14:37:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Tys-00072P-Cp
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 14:37:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12039
	for ; Tue, 24 Jan 2006 14:35:59 -0500 (EST)
Received: from lonsmimeo.rit.reuters.com ([192.165.213.23]
	helo=lonsmime04.rit.reuters.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1U8T-0008MW-2R
	for ietf@ietf.org; Tue, 24 Jan 2006 14:47:26 -0500
Received: from uknsprd1 (unverified [129.1.30.40]) by 
	lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with 
	ESMTP id  for 
	; Tue, 24 Jan 2006 19:37:09 +0000
Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by 
	eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id 
	<0ITM00LWN3TWA2@eupig2.dtc.lon.ime.reuters.com> for ietf@ietf.org; Tue, 
	24 Jan 2006 19:37:08 +0000 (GMT)
Received: from LONSMSXM06.emea.ime.reuters.com ([10.14.113.22]) by 
	lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0);
	Tue, 24 Jan 2006 19:37:08 +0000
Date: Tue, 24 Jan 2006 19:37:37 +0000
From: Misha Wolf 
To: ietf@ietf.org
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: quoted-printable
Thread-Topic: Misha Wolf supports PR-action against Jefsey Morfin
Thread-Index: AcYgKqnUro5dxi58TeurDGHzQ65o2wA8oPFw
Content-class: urn:content-classes:message
X-OriginalArrivalTime: 24 Jan 2006 19:37:08.0770 (UTC) 
	FILETIME=[90708820:01C6211D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: quoted-printable
Subject: Misha Wolf supports PR-action against Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I strongly support the proposed RFC 3683 PR-action against Jefsey
Morfin.

Misha


To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, exc=
ept where the sender specifically states them to be the views of Reuters Lt=
d.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 14:47:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1U87-0001Pe-Vg; Tue, 24 Jan 2006 14:47:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1U85-0001PZ-R6
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 14:47:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12778
	for ; Tue, 24 Jan 2006 14:45:30 -0500 (EST)
Received: from purgatory.unfix.org ([213.136.24.43])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1UHf-0000Gm-Gf
	for ietf@ietf.org; Tue, 24 Jan 2006 14:56:56 -0500
Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org
	[IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP id 9CDB67F45;
	Tue, 24 Jan 2006 20:46:35 +0100 (CET)
Message-ID: <43D683FA.8050502@unfix.org>
Date: Tue, 24 Jan 2006 20:46:02 +0100
From: Jeroen Massar 
Organization: Unfix
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Anthony G. Atkielski" , ietf@ietf.org
References: <20060120185257.GE18960@ccil.org>	<1797258665.20060123163611@atkielski.com>	
	<0728557.20060124163321@atkielski.com>
In-Reply-To: <0728557.20060124163321@atkielski.com>
X-Enigmail-Version: 0.94.0.0
OpenPGP: id=333E7C23;
	url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: 
Subject: Proposal for keeping "free speech" but limitting the nuisance to
 the working group (Was: John Cowan supports 3683 PR-action against Jefsey
 Morfin)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0804239392=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0804239392==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigD9BB13008E555A2E39F7CE06"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD9BB13008E555A2E39F7CE06
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Anthony G. Atkielski wrote:
> Pekka Savola writes:
>=20
>> Why must each and every WG member be required to filter a person's
>> postings?  Much more convenient to do so in one place.
>=20
> Because each and every WG member is an individual, with his own ideas
> of what he does or doesn't want to read, and imposing the same rules
> upon everyone prevents members from making their own decisions.  It
> also imposes the decisions of a small minority upon the majority.

Here goes for a try... flame me off list if required.

As it is indeed quite controversial to 'block' people, maybe there can
be a solution that, though it will have overhead for listadmins, it will
help the process that the workinggroup is actually for in the first place=
=2E

In the several messages there have been brought up a number of solutions
 to the problem where one or multiple entities are (deliberately)
flooding/overloading the mailinglists of workinggroups and other places
with off-topic messages.

There seem to be a couple of solutions, amongst which:
 - Filtering based on source address at the receiver
 - Filtering based on keywords, which has really bad side-effects.
 - Blocking the sender at the mailinglist level.
 - 3683 PR for complete full blockage of posting rights.

The first is reasonably fine, as you don't see the message of the entity
that one finds not useful, but you might see responses of others thus
this is still intrusive and you still get those messages which you
wanted to filter out. The second option might filter out messages which
you did want to read. Both still will get these messages in the
mailinglist archive, even though there was a consensus that those
messages are unwanted.

The third and fourth option are pretty definitive, no more messages from
that entity, but this might be seen as silencing this persons freedom of
speech.

My proposal to solve this issue but keeping everybody happy:

Two mailinglists: @ietf.org + full.@ietf.org

full.@ is completely open, anybody can post anything they want
though hopefully on topic on the subject of the workinggroup and of
course based on the source address having a subscription *1
full.@ is subscribed to @ thus full.wg gets everything
preserving, at least parts, of the freedom of speech that is wanted and
for the people who want to read a lot of mail everyday.

Initially everybody who signs up to the @ list can post to it.
When the consensus on the list is that a member is not participating
correctly, ignoring warnings etc, like currently this member can be
banned from the list for a temporary amount of time. The member can
still voice his opinions on the @ list. This thus allows him to
voice his concerns to the members that do want to read them. Like the
current 3683 PR the ban can become effectively indefinitely for the main
list, while the poster is still and always allowed on full.@.


The big concern here is of course that one could say that if you get
booted out of the group that your voice won't be heard as they are not
reading the other list. This is of course true, but one can raise their
concerns on the full list, for instance Google won't differentiate
between them and there will always be folks who will listen to it and
forward these concerns when they have valid argumentation. By posting
'good' messages to the full.@ list a member can also demonstrate
that he is really willing to contribute instead of disrupt. One of the
nicest controversies is of course what to determine good and bad,
starwars as an example, how bad are the jedi and how good are the sith,
it completely depends on the side you are on, nothing else. That all
boils down to trust and other factors, any mailinglist admin could abuse
his position to set the sender of an address to silently discard, SMTP
can have a CC: in the header and mailman will not forward the message to
that person and various other nice tricks.

I hope the above might give a better point to discuss all this over
instead of seeing replies like "that is not good" "see above" and other
comments without effective constructive arguments.

Greets,
 Jeroen

*1 =3D to avoid the large amount of spam flowing to the various lists
which nicely get blocked because of subscription regulation.



--------------enigD9BB13008E555A2E39F7CE06
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQFD1oP6KaooUjM+fCMRAqymAJ4zOE/aJQNXEkLRFESbeuaoNkofGQCdG8vh
xyDOuccNahA3lH1HQKcQvFs=
=ziMf
-----END PGP SIGNATURE-----

--------------enigD9BB13008E555A2E39F7CE06--


--===============0804239392==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0804239392==--




From ietf-bounces@ietf.org Tue Jan 24 15:01:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1UMN-0005Cl-KJ; Tue, 24 Jan 2006 15:01:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1UML-0005CS-G9
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 15:01:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13711
	for ; Tue, 24 Jan 2006 15:00:14 -0500 (EST)
Received: from sokol.elan.net ([216.151.192.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1UVu-0000nS-7N
	for ietf@ietf.org; Tue, 24 Jan 2006 15:11:41 -0500
Received: from sokol.elan.net (sokol [127.0.0.1])
	by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k0OK1Srk015253
	for ; Tue, 24 Jan 2006 12:01:28 -0800
Received: from localhost (william@localhost)
	by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k0OK1ReU015250
	for ; Tue, 24 Jan 2006 12:01:28 -0800
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Tue, 24 Jan 2006 12:01:27 -0800 (PST)
From: "william(at)elan.net" 
To: ietf@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Subject: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


I'm against the PR action. From links included with PR action, I do
not see that Jefsey's actions include anything that maybe deemed as 
personal attacks or similar actions clearly prohibited by IETF and
his posts seem to be an advocacy and representing his views and IETF
as organization is based on free participation and representation of 
everyone's views to arrive at consensus. Free speech is at the core
of discussions at IETF and those representing minority positions
should not be prevented from expressing it and most definitely it
should not cause such global IETF-wide ban as PR action represents.

-- 
William Leibzon
Elan Networks
william@elan.net

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 15:23:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1UhJ-00055y-Nr; Tue, 24 Jan 2006 15:23:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1UhH-00055r-Gd
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 15:23:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15664
	for ; Tue, 24 Jan 2006 15:21:52 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Uqs-0001hi-BM
	for ietf@ietf.org; Tue, 24 Jan 2006 15:33:19 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 8DA8D2596DA;
	Tue, 24 Jan 2006 21:22:03 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 29858-07; Tue, 24 Jan 2006 21:21:58 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id B2A122596D1;
	Tue, 24 Jan 2006 21:21:57 +0100 (CET)
Date: Tue, 24 Jan 2006 12:09:52 -0800
From: Harald Tveit Alvestrand 
To: Jeroen Massar , ietf@ietf.org
Message-ID: 
In-Reply-To: <43D683FA.8050502@unfix.org>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	
	<0728557.20060124163321@atkielski.com> <43D683FA.8050502@unfix.org>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: 
Subject: Re: Proposal for keeping "free speech" but limitting the nuisance
 to the working group (Was: John Cowan supports 3683 PR-action against Jefsey
 Morfin)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2047495861=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============2047495861==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========4B870FC113D963AA8DBF=========="

--==========4B870FC113D963AA8DBF==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable



--On 24. januar 2006 20:46 +0100 Jeroen Massar  wrote:

> My proposal to solve this issue but keeping everybody happy:
>
> Two mailinglists: @ietf.org + full.@ietf.org
>
> full.@ is completely open, anybody can post anything they want
> though hopefully on topic on the subject of the workinggroup and of
> course based on the source address having a subscription *1
> full.@ is subscribed to @ thus full.wg gets everything
> preserving, at least parts, of the freedom of speech that is wanted and
> for the people who want to read a lot of mail everyday.

In fact this has been implemented at least once that I know of - on the=20
DNSO GA mailing list. The "full" version had relatively few subscribers.

You can find the archives of that experiment at=20
 - it's probably difficult to=20
guess from the archives whether it was successful; better ask someone who=20
was there at a time whether they think it worked.

Another variant is the ietf-censored version of the IETF list that I ran=20
for a while, but left to others when becoming IETF chair - google claims=20
that  is a=20
current page for it. Some people liked it; I don't know what filters are=20
currently in place for it, but it doesn't seem to be working - archives=20
have spam in them, but no IETF list traffic, so I guess it's not working.

                    Harald








--==========4B870FC113D963AA8DBF==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFD1omQOMj+2+WY0F4RAigrAKCiAcp0ppYd0vKx5JvswB3QHp2obgCdFdYf
P37JaeNPHdi8zlrkI/8nzHQ=
=2rQ3
-----END PGP SIGNATURE-----

--==========4B870FC113D963AA8DBF==========--



--===============2047495861==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============2047495861==--





From ietf-bounces@ietf.org Tue Jan 24 15:43:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1V0U-0002M1-G9; Tue, 24 Jan 2006 15:43:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1V0R-0002LV-T3; Tue, 24 Jan 2006 15:43:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16889;
	Tue, 24 Jan 2006 15:41:40 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F1VA2-0002M9-K2; Tue, 24 Jan 2006 15:53:07 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3822737; Tue, 24 Jan 2006 15:39:40 -0500
In-Reply-To: <43D5C44F.6000708@cisco.com>
References: <313680C9A886D511A06000204840E1CF0C88635E@whq-msgusr-02.pit.comms.marconi.com>
	
	<43D5C44F.6000708@cisco.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <81BC6A2F-4DE2-4D06-9C8B-6024D77933E7@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Tue, 24 Jan 2006 15:43:04 -0500
To: Eliot Lear 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: "'ietf@ietf.org'" , "'iesg@ietf.org'" 
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hello;

On Jan 24, 2006, at 1:08 AM, Eliot Lear wrote:

> Marshall Eubanks wrote:
>>
>> P.S. I was not appointed "ombudsman for the IETF list" and would not
>> claim that honor.
> Sorry- wrong word.  Sargeant at Arms (my own sleeplessness).
>
> Eliot

Nope, that that either.

Please note that I claim neither special knowledge nor special  
position in this matter.

Regards
Marshall 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 15:48:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1V5U-0003Ox-EZ; Tue, 24 Jan 2006 15:48:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1V5R-0003O8-1V
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 15:48:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17537
	for ; Tue, 24 Jan 2006 15:46:48 -0500 (EST)
Message-Id: <200601242046.PAA17537@ietf.org>
Received: from venus3.veridas.net ([202.52.32.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1VF0-0002ce-OZ
	for ietf@ietf.org; Tue, 24 Jan 2006 15:58:16 -0500
Received: (qmail 6312 invoked from network); 25 Jan 2006 06:47:58 +1000
Received: from dassa@dhs.org by venus3 by uid 1001 with qmail-scanner-1.15 
	( Clear:. Processed in 1.828916 secs); 24 Jan 2006 20:47:58 -0000
Received: from dsl-125-209-164-118.nsw.veridas.net (HELO dhs) (125.209.164.118)
	by 202.52.49.177 with SMTP; 25 Jan 2006 06:47:56 +1000
Received: (qmail 28440 invoked by uid 453); 24 Jan 2006 16:26:06 -0000
Received: from dassa.dhs (HELO dassa) (192.168.0.2)
	by dhs (qpsmtpd/0.31-dev) with ESMTP; Wed, 25 Jan 2006 03:26:05 +1100
From: "Dassa" 
To: "'Harald Tveit Alvestrand'" ,
	"'Jeroen Massar'" , 
Date: Wed, 25 Jan 2006 07:47:53 +1100
Organization: DHS International Pty Ltd Australia
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Thread-Index: AcYhJQxFPJf4Q9aeTLSaxJeudQHwfwAAN9+Q
X-Qmail-Scanner-Message-ID: <11381356765026268@venus3>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: 
Subject: RE: Proposal for keeping "free speech" but limitting the nuisance
	to the working group (Was: John Cowan supports 3683 PR-action
	against Jefsey Morfin)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dassa@dhs.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

|> -----Original Message-----
|> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
|> On Behalf Of Harald Tveit Alvestrand
|> Sent: Wednesday, January 25, 2006 7:10 AM
|> To: Jeroen Massar; ietf@ietf.org
|> Subject: Re: Proposal for keeping "free speech" but 
|> limitting the nuisance to the working group (Was: John Cowan 
|> supports 3683 PR-action against Jefsey Morfin)
|> 
|> 
|> 
|> --On 24. januar 2006 20:46 +0100 Jeroen Massar 
|>  wrote:
|> 
|> > My proposal to solve this issue but keeping everybody happy:
|> >
|> > Two mailinglists: @ietf.org + full.@ietf.org
|> >
|> > full.@ is completely open, anybody can post anything they want 
|> > though hopefully on topic on the subject of the 
|> workinggroup and of 
|> > course based on the source address having a subscription 
|> *1 full.@ 
|> > is subscribed to @ thus full.wg gets everything preserving, at 
|> > least parts, of the freedom of speech that is wanted and for the 
|> > people who want to read a lot of mail everyday.
|> 
|> In fact this has been implemented at least once that I know 
|> of - on the DNSO GA mailing list. The "full" version had 
|> relatively few subscribers.
|> 
|> You can find the archives of that experiment at 
|>  - it's probably 
|> difficult to guess from the archives whether it was 
|> successful; better ask someone who was there at a time 
|> whether they think it worked.


I was a subscriber to both of the DNSO GA mailing lists and I do think the
experiment worked for the most part.  I've seen this a few times and it does
take a load of the main list but there are dangers in the "full" list becoming
a dumping ground for garbage.  Both lists need dedicated people to keep them
functioning correctly. It all boils down to how much traffic and noise
individuals can handle.  It appears there are large numbers of participants
who need to be sheltered a little more than others to retain their
participation, not a bad thing, just a fact.  Anything that can be done to
improve participation is a good thing.

Darryl (Dassa) Lynch 

PS...I've known Jefsey online since those early DNSO and IDNO days and whilst
I don't always agree with him I respect his right to opinions.  I haven't
followed his postings to other lists but haven't seen anything here I object
to with regard to posting rights.  I wouldn't like to see a blanket ban placed
on his postings so a "full" list experiment would be a preference for me.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 16:19:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1VZm-0002O6-S6; Tue, 24 Jan 2006 16:19:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1VZk-0002Mk-E2
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 16:19:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28050
	for ; Tue, 24 Jan 2006 16:18:08 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1VjL-0006oG-FF
	for ietf@ietf.org; Tue, 24 Jan 2006 16:29:37 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-4.cisco.com with ESMTP; 24 Jan 2006 13:19:30 -0800
X-IronPort-AV: i="4.01,214,1136188800"; 
	d="scan'208"; a="1769666296:sNHT30112738"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0OLJSWF020522
	for ; Tue, 24 Jan 2006 13:19:28 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 24 Jan 2006 13:19:28 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.88.117]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 24 Jan 2006 13:19:27 -0800
Message-Id: <4.3.2.7.2.20060124151411.0334bd20@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Jan 2006 15:19:27 -0600
To: Mark Townsley , ietf@ietf.org
From: "James M. Polk" 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 24 Jan 2006 21:19:28.0139 (UTC)
	FILETIME=[DBC9E5B0:01C6212B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: 
Subject: Re: Softwires Interim Meeting 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Mark

I'm not an interested party here, and I don't mean to throw a monkey wrench 
into your plans, but I'm observing that this seems to be within the 30 days 
of moratorium of when we cannot have an interim, where (loosely) 'interims 
shall not be within 30 days of the next IETF meeting'.

The Dallas IETF starts on March 19th, so I would think the cutoff would be 
Feb 19th for the last of an interim.  What am I missing?

At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote:
>The meeting will be Feb 23-24 in Hong Kong. Participants should plan to
>arrive Feb 22 for an early start on Feb 23. We will finish by 2pm on Feb
>24. Accomodation information coming shortly (watch the
>softwires@ietf.org mailing list).
>
>Thank you,
>
>- Mark
>
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 16:52:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1W5d-0005Rf-VF; Tue, 24 Jan 2006 16:52:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1W5c-0005RJ-FH
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 16:52:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06056
	for ; Tue, 24 Jan 2006 16:51:04 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1WFC-0001bh-Fs
	for ietf@ietf.org; Tue, 24 Jan 2006 17:02:33 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3822900; Tue, 24 Jan 2006 16:49:07 -0500
In-Reply-To: <4.3.2.7.2.20060124151411.0334bd20@email.cisco.com>
References: <4.3.2.7.2.20060124151411.0334bd20@email.cisco.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Tue, 24 Jan 2006 16:52:31 -0500
To: "James M. Polk" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: Mark Townsley , ietf@ietf.org
Subject: Re: Softwires Interim Meeting 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

March 19 - 30 days = Feb 17th.

On Jan 24, 2006, at 4:19 PM, James M. Polk wrote:

> Mark
>
> I'm not an interested party here, and I don't mean to throw a  
> monkey wrench into your plans, but I'm observing that this seems to  
> be within the 30 days of moratorium of when we cannot have an  
> interim, where (loosely) 'interims shall not be within 30 days of  
> the next IETF meeting'.
>
> The Dallas IETF starts on March 19th, so I would think the cutoff  
> would be Feb 19th for the last of an interim.  What am I missing?
>
> At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote:
>> The meeting will be Feb 23-24 in Hong Kong. Participants should  
>> plan to
>> arrive Feb 22 for an early start on Feb 23. We will finish by 2pm  
>> on Feb
>> 24. Accomodation information coming shortly (watch the
>> softwires@ietf.org mailing list).
>>
>> Thank you,
>>
>> - Mark
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 17:04:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1WH2-0002D9-5Z; Tue, 24 Jan 2006 17:04:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1WH0-0002CZ-2N
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 17:04:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07102
	for ; Tue, 24 Jan 2006 17:02:50 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1WQa-00025L-72
	for ietf@ietf.org; Tue, 24 Jan 2006 17:14:19 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-4.cisco.com with ESMTP; 24 Jan 2006 14:04:10 -0800
X-IronPort-AV: i="4.01,214,1136188800"; 
	d="scan'208"; a="1769685826:sNHT143723590"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0OM49QR009551;
	Tue, 24 Jan 2006 14:04:09 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 24 Jan 2006 14:04:00 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.88.117]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 24 Jan 2006 14:04:00 -0800
Message-Id: <4.3.2.7.2.20060124160333.0329d9a8@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Jan 2006 16:03:59 -0600
To: Marshall Eubanks 
From: "James M. Polk" 
In-Reply-To: 
References: <4.3.2.7.2.20060124151411.0334bd20@email.cisco.com>
	<4.3.2.7.2.20060124151411.0334bd20@email.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 24 Jan 2006 22:04:00.0207 (UTC)
	FILETIME=[14771DF0:01C62132]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: Mark Townsley , ietf@ietf.org
Subject: Re: Softwires Interim Meeting 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 04:52 PM 1/24/2006 -0500, Marshall Eubanks wrote:
>March 19 - 30 days = Feb 17th.

oops


>On Jan 24, 2006, at 4:19 PM, James M. Polk wrote:
>
>>Mark
>>
>>I'm not an interested party here, and I don't mean to throw a
>>monkey wrench into your plans, but I'm observing that this seems to
>>be within the 30 days of moratorium of when we cannot have an
>>interim, where (loosely) 'interims shall not be within 30 days of
>>the next IETF meeting'.
>>
>>The Dallas IETF starts on March 19th, so I would think the cutoff
>>would be Feb 19th for the last of an interim.  What am I missing?
>>
>>At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote:
>>>The meeting will be Feb 23-24 in Hong Kong. Participants should
>>>plan to
>>>arrive Feb 22 for an early start on Feb 23. We will finish by 2pm
>>>on Feb
>>>24. Accomodation information coming shortly (watch the
>>>softwires@ietf.org mailing list).
>>>
>>>Thank you,
>>>
>>>- Mark
>>>
>>>_______________________________________________
>>>IETF-Announce mailing list
>>>IETF-Announce@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/ietf-announce
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 17:08:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1WLR-0005UG-S9; Tue, 24 Jan 2006 17:08:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1WLP-0005SZ-8F
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 17:08:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07519
	for ; Tue, 24 Jan 2006 17:07:23 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1WV1-0002G8-7f
	for ietf@ietf.org; Tue, 24 Jan 2006 17:18:52 -0500
Received: from [192.168.0.4] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001582904.msg
	for ; Tue, 24 Jan 2006 23:10:42 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Tue, 24 Jan 2006 18:08:16 -0400
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: Softwires Interim Meeting
Thread-Index: AcYhMqzu6zX2w40lEdqeyAANky3PwA==
In-Reply-To: <4.3.2.7.2.20060124151411.0334bd20@email.cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060124:ietf@ietf.org::f/F8XjD3G3DOQe3a:000012gG
X-MDRemoteIP: 150.189.240.59
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Tue, 24 Jan 2006 23:10:43 +0100
X-MDAV-Processed: consulintel.es, Tue, 24 Jan 2006 23:10:43 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit
Subject: Re: Softwires Interim Meeting
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi James,

This was already discussed in the WG, and I guess the AD has taken measures
to avoid this being a real problem.

Right now it will be a real problem canceling the meeting, as some people
has already got non-refundable and very expensive flights after so many
weeks of lack of adequate planning.

I've insisted in Vancouver, when the plan for this meeting was drafted, to
fix it at that time, unfortunately was repeatedly ignored, with the
consequence of the meeting being first fixed at the end of January in San
Jose with a non-clear consensus from the participants, and now in dates
which are also unfortunate for some of us, but as said is too late now to
start changing it again.

In order to avoid this happening again, I'm working in some more clear
suggestions for rules on how to adequately plan Interim meetings. I will
circulate them ASAP.

Regards,
Jordi




> De: "James M. Polk" 
> Responder a: 
> Fecha: Tue, 24 Jan 2006 15:19:27 -0600
> Para: Mark Townsley , "ietf@ietf.org" 
> Asunto: Re: Softwires Interim Meeting
> 
> Mark
> 
> I'm not an interested party here, and I don't mean to throw a monkey wrench
> into your plans, but I'm observing that this seems to be within the 30 days
> of moratorium of when we cannot have an interim, where (loosely) 'interims
> shall not be within 30 days of the next IETF meeting'.
> 
> The Dallas IETF starts on March 19th, so I would think the cutoff would be
> Feb 19th for the last of an interim.  What am I missing?
> 
> At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote:
>> The meeting will be Feb 23-24 in Hong Kong. Participants should plan to
>> arrive Feb 22 for an early start on Feb 23. We will finish by 2pm on Feb
>> 24. Accomodation information coming shortly (watch the
>> softwires@ietf.org mailing list).
>> 
>> Thank you,
>> 
>> - Mark
>> 
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf-announce
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 17:34:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1WkW-000172-7r; Tue, 24 Jan 2006 17:34:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1WkT-00016x-K4
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 17:34:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10747
	for ; Tue, 24 Jan 2006 17:33:15 -0500 (EST)
Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Wu0-0003gt-MR
	for ietf@ietf.org; Tue, 24 Jan 2006 17:44:43 -0500
Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil
	via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP;
	Tue, 24 Jan 2006 22:34:38 +0000
Received: (private information removed)
Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil
	via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP;
	Tue, 24 Jan 2006 22:34:37 +0000
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 Jan 2006 16:34:36 -0600
Message-ID: <1929B8C5B318524495727D8A241DAFB2034C9D01@NAEAMILLEX03VA.nadsusea.nads.navy.mil>
Thread-Topic: Meeting Survey Results
Thread-Index: AcYhFiy5azLM8Y0JEdqeyAANky3PwAAAjkyA
From: "Odonoghue, Karen F CIV B35-Branch" 
To: 
X-OriginalArrivalTime: 24 Jan 2006 22:34:36.0641 (UTC)
	FILETIME=[5B10B510:01C62136]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jordi,

With the RF characteristics of 802.11b/g (including the fact that
there are only three non-overlapping channels (in the US) and they all
exist in the already overcrowded 2.4 GHz freq range) and the density
of users in the meeting rooms at the IETF, you cannot "warrantee"=20
a level of performance. I attend both IEEE 802 and IETF meetings and=20
both struggle with wireless coverage at those densities for this=20
very basic physical reason. The more transmitters you have=20
transmitting on the same frequencies in the same space, the more noise=20
you will have. The more noise you have the more performance issues
you will experience. Technology and product evolution will improve
the situation, but we have to work with what we have.=20

While 802.11a hasn't overtaken 802.11b/g in general, it is much=20
better suited for our environment. There are more non-overlapping=20
channels, it operates in the less crowded 5 GHz range, and the=20
range is shorter. Thus you can deploy more APs in the same space=20
without contributing to the overall noise issue. =20

We are suggesting that users that are willing and able should
consider investing in 802.11a cards for a happier IETF network
experience.  Anything we can do to reduce the level of noise at
will make the experience better for the remaining users.=20

Past and current NOC teams plan to deploy the best network they=20
can with the resources available. Donations of equipment and
expertise are always welcome.=20

Karen

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On Behalf Of
> JORDI PALET MARTINEZ
> Sent: Tuesday, January 24, 2006 13:44
> To: ietf@ietf.org
> Subject: Re: Meeting Survey Results
>=20
>=20
> Hi Jonne,
>=20
> I'm not sure if I got it. My MUST was on the other way=20
> around: We really
> need to warrantee good coverage for b/g to 75% of the participants.
>=20
> Regards,
> Jordi
>=20
>=20
>=20
>=20
> > De: "Soininen Jonne (Nokia-NET/Espoo)" 
> > Organizaci=F3n: NET/ST/IED
> > Responder a: 
> > Fecha: Tue, 24 Jan 2006 06:35:13 +0200
> > Para: 
> > CC: "ietf@ietf.org" 
> > Asunto: Re: Meeting Survey Results
> >=20
> > Hi Jordi,
> >=20
> > the preference for .11a was stated because we want to make sure that
> > everybody who has the possibility for it would use it. It makes the
> > network much more reliable. Of course b and g are provided as well.
> >=20
> > It is a recommendation not a MUST, like the mail says.
> >=20
> > Cheers,
> >=20
> > Jonne.
> >=20
> > On Mon, 2006-01-23 at 22:57 -0400, ext JORDI PALET MARTINEZ wrote:
> >> Hi Ray,
> >>=20
> >> I'm not sure if we need some clarification on this:
> >>=20
> >>> 1.  Slightly more than 25% say their laptop is compatible=20
> with 802.11a.
> >>> [Note the IETF 65 NOC for Dallas recommends 802.11a]
> >>=20
> >> According to the survey, only 25.5% of the participants=20
> have 802.11a, which
> >> in my opinion means that 11b/g MUST be reliable for 75% of=20
> the participants
> >> in the next meeting.
> >>=20
> >> Remember that if we don't have an 802.11a interface in our=20
> laptops is
> >> because *THEY DONT'T HAVE IT*.
> >>=20
> >> In my own case, having a Mac is not easy to get built-in=20
> 802.11a. I can of
> >> course buy an external card, but is not reasonable (more=20
> power consumption,
> >> more things to carry, etc.). There is one more reason, is=20
> that in most of
> >> the world is not (today) widely used, so buying it almost=20
> only for IETF
> >> meetings, don't make too much sense.
> >>=20
> >> Even do, if it is just me, I will consider buying it, but=20
> I don't really
> >> agree to get this asked for 75% of the participants. It is=20
> not a choice !
> >>=20
> >> So the clarification is ... what we actually will get at=20
> IETF65, and if
> >> something must be changed now for getting good 802.11b/g=20
> support, please,
> >> make sure about that now !
> >>=20
> >> Regards,
> >> Jordi
> >>=20
> >>=20
> >>=20
> >>=20
> >>> De: 
> >>> Responder a: 
> >>> Fecha: Mon, 23 Jan 2006 17:45:07 -0500 (EST)
> >>> Para: "ietf@ietf.org" 
> >>> Asunto: Meeting Survey Results
> >>>=20
> >>> All;
> >>>=20
> >>> More than 300 responded to the Meeting Survey conducted=20
> following IETF 64
> >>> in Vancouver.
> >>>=20
> >>> See survey results link below.
> >>>=20
> >>> Among the results are:
> >>> 1.  Slightly more than 25% say their laptop is compatible=20
> with 802.11a.
> >>> [Note the IETF 65 NOC for Dallas recommends 802.11a]
> >>>=20
> >>> 2.  Nearly 60% (with an additional 23% undecided) prefer=20
> dinner following
> >>> all sessions of the day.
> >>>=20
> >>> 3.  Only 23% prefer a full day schedule for Fridays.
> >>>=20
> >>> 4.  Cookies are not the only craving for breaks -- 74%=20
> want more healthy
> >>> choices.
> >>>=20
> >>> 5.  Only 1/3 of the respondents expressed satisfaction=20
> with the wireless
> >>> connectivity.
> >>>=20
> >>> And given the opportunity to say what they liked and=20
> didn't - 130 told us
> >>> how they felt.
> >>>=20
> >>> Read it for yourselves:
> >>> http://www.surveymonkey.com/Report.asp?U=3D165657447306
> >>>=20
> >>> I and NeuStar Secretariat Services will review these=20
> results and make
> >>> adjustments as possible for IETF 65 Dallas, March 19 -=20
> 24.  And we look
> >>> forward to seeing you there.
> >>>=20
> >>> Thanks for your participation.
> >>>=20
> >>> Ray Pelletier
> >>> IETF Administrative Director.
> >>>=20
> >>>=20
> >>> _______________________________________________
> >>> Ietf mailing list
> >>> Ietf@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/ietf
> >>=20
> >>=20
> >>=20
> >>=20
> >> **********************************************
> >> The IPv6 Portal: http://www.ipv6tf.org
> >>=20
> >> Barcelona 2005 Global IPv6 Summit
> >> Slides available at:
> >> http://www.ipv6-es.com
> >>=20
> >> This electronic message contains information which may be=20
> privileged or
> >> confidential. The information is intended to be for the use of the
> >> individual(s) named above. If you are not the intended=20
> recipient be aware
> >> that any disclosure, copying, distribution or use of the=20
> contents of this
> >> information, including attached files, is prohibited.
> >>=20
> >>=20
> >>=20
> >>=20
> >> _______________________________________________
> >> Ietf mailing list
> >> Ietf@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ietf
> >=20
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
>=20
>=20
>=20
>=20
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
>=20
> Barcelona 2005 Global IPv6 Summit
> Slides available at:
> http://www.ipv6-es.com
>=20
> This electronic message contains information which may be=20
> privileged or confidential. The information is intended to be=20
> for the use of the individual(s) named above. If you are not=20
> the intended recipient be aware that any disclosure, copying,=20
> distribution or use of the contents of this information,=20
> including attached files, is prohibited.
>=20
>=20
>=20
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 17:39:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1WpT-0005uM-88; Tue, 24 Jan 2006 17:39:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1WpP-0005u4-JQ
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 17:39:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11270
	for ; Tue, 24 Jan 2006 17:38:25 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Wz0-0003vd-JH
	for ietf@ietf.org; Tue, 24 Jan 2006 17:49:53 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3823010; Tue, 24 Jan 2006 17:36:26 -0500
In-Reply-To: <1929B8C5B318524495727D8A241DAFB2034C9D01@NAEAMILLEX03VA.nadsusea.nads.navy.mil>
References: <1929B8C5B318524495727D8A241DAFB2034C9D01@NAEAMILLEX03VA.nadsusea.nads.navy.mil>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <6800EEA8-6D11-47CF-9008-60C8A020B461@multicasttech.com>
Content-Transfer-Encoding: quoted-printable
From: Marshall Eubanks 
Date: Tue, 24 Jan 2006 17:39:45 -0500
To: "Odonoghue, Karen F CIV B35-Branch" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org, jordi.palet@consulintel.es
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Just consider it a big experiment in 802.11a robustness.

Regards
Marshall

On Jan 24, 2006, at 5:34 PM, Odonoghue, Karen F CIV B35-Branch wrote:

> Jordi,
>
> With the RF characteristics of 802.11b/g (including the fact that
> there are only three non-overlapping channels (in the US) and they all
> exist in the already overcrowded 2.4 GHz freq range) and the density
> of users in the meeting rooms at the IETF, you cannot "warrantee"
> a level of performance. I attend both IEEE 802 and IETF meetings and
> both struggle with wireless coverage at those densities for this
> very basic physical reason. The more transmitters you have
> transmitting on the same frequencies in the same space, the more noise
> you will have. The more noise you have the more performance issues
> you will experience. Technology and product evolution will improve
> the situation, but we have to work with what we have.
>
> While 802.11a hasn't overtaken 802.11b/g in general, it is much
> better suited for our environment. There are more non-overlapping
> channels, it operates in the less crowded 5 GHz range, and the
> range is shorter. Thus you can deploy more APs in the same space
> without contributing to the overall noise issue.
>
> We are suggesting that users that are willing and able should
> consider investing in 802.11a cards for a happier IETF network
> experience.  Anything we can do to reduce the level of noise at
> will make the experience better for the remaining users.
>
> Past and current NOC teams plan to deploy the best network they
> can with the resources available. Donations of equipment and
> expertise are always welcome.
>
> Karen
>
>> -----Original Message-----
>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On =20
>> Behalf Of
>> JORDI PALET MARTINEZ
>> Sent: Tuesday, January 24, 2006 13:44
>> To: ietf@ietf.org
>> Subject: Re: Meeting Survey Results
>>
>>
>> Hi Jonne,
>>
>> I'm not sure if I got it. My MUST was on the other way
>> around: We really
>> need to warrantee good coverage for b/g to 75% of the participants.
>>
>> Regards,
>> Jordi
>>
>>
>>
>>
>>> De: "Soininen Jonne (Nokia-NET/Espoo)" 
>>> Organizaci=F3n: NET/ST/IED
>>> Responder a: 
>>> Fecha: Tue, 24 Jan 2006 06:35:13 +0200
>>> Para: 
>>> CC: "ietf@ietf.org" 
>>> Asunto: Re: Meeting Survey Results
>>>
>>> Hi Jordi,
>>>
>>> the preference for .11a was stated because we want to make sure that
>>> everybody who has the possibility for it would use it. It makes the
>>> network much more reliable. Of course b and g are provided as well.
>>>
>>> It is a recommendation not a MUST, like the mail says.
>>>
>>> Cheers,
>>>
>>> Jonne.
>>>
>>> On Mon, 2006-01-23 at 22:57 -0400, ext JORDI PALET MARTINEZ wrote:
>>>> Hi Ray,
>>>>
>>>> I'm not sure if we need some clarification on this:
>>>>
>>>>> 1.  Slightly more than 25% say their laptop is compatible
>> with 802.11a.
>>>>> [Note the IETF 65 NOC for Dallas recommends 802.11a]
>>>>
>>>> According to the survey, only 25.5% of the participants
>> have 802.11a, which
>>>> in my opinion means that 11b/g MUST be reliable for 75% of
>> the participants
>>>> in the next meeting.
>>>>
>>>> Remember that if we don't have an 802.11a interface in our
>> laptops is
>>>> because *THEY DONT'T HAVE IT*.
>>>>
>>>> In my own case, having a Mac is not easy to get built-in
>> 802.11a. I can of
>>>> course buy an external card, but is not reasonable (more
>> power consumption,
>>>> more things to carry, etc.). There is one more reason, is
>> that in most of
>>>> the world is not (today) widely used, so buying it almost
>> only for IETF
>>>> meetings, don't make too much sense.
>>>>
>>>> Even do, if it is just me, I will consider buying it, but
>> I don't really
>>>> agree to get this asked for 75% of the participants. It is
>> not a choice !
>>>>
>>>> So the clarification is ... what we actually will get at
>> IETF65, and if
>>>> something must be changed now for getting good 802.11b/g
>> support, please,
>>>> make sure about that now !
>>>>
>>>> Regards,
>>>> Jordi
>>>>
>>>>
>>>>
>>>>
>>>>> De: 
>>>>> Responder a: 
>>>>> Fecha: Mon, 23 Jan 2006 17:45:07 -0500 (EST)
>>>>> Para: "ietf@ietf.org" 
>>>>> Asunto: Meeting Survey Results
>>>>>
>>>>> All;
>>>>>
>>>>> More than 300 responded to the Meeting Survey conducted
>> following IETF 64
>>>>> in Vancouver.
>>>>>
>>>>> See survey results link below.
>>>>>
>>>>> Among the results are:
>>>>> 1.  Slightly more than 25% say their laptop is compatible
>> with 802.11a.
>>>>> [Note the IETF 65 NOC for Dallas recommends 802.11a]
>>>>>
>>>>> 2.  Nearly 60% (with an additional 23% undecided) prefer
>> dinner following
>>>>> all sessions of the day.
>>>>>
>>>>> 3.  Only 23% prefer a full day schedule for Fridays.
>>>>>
>>>>> 4.  Cookies are not the only craving for breaks -- 74%
>> want more healthy
>>>>> choices.
>>>>>
>>>>> 5.  Only 1/3 of the respondents expressed satisfaction
>> with the wireless
>>>>> connectivity.
>>>>>
>>>>> And given the opportunity to say what they liked and
>> didn't - 130 told us
>>>>> how they felt.
>>>>>
>>>>> Read it for yourselves:
>>>>> http://www.surveymonkey.com/Report.asp?U=3D165657447306
>>>>>
>>>>> I and NeuStar Secretariat Services will review these
>> results and make
>>>>> adjustments as possible for IETF 65 Dallas, March 19 -
>> 24.  And we look
>>>>> forward to seeing you there.
>>>>>
>>>>> Thanks for your participation.
>>>>>
>>>>> Ray Pelletier
>>>>> IETF Administrative Director.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ietf mailing list
>>>>> Ietf@ietf.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@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ietf
>>>
>>> _______________________________________________
>>> Ietf mailing list
>>> Ietf@ietf.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@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 18:16:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1XOo-0004dK-4y; Tue, 24 Jan 2006 18:16:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1XOm-0004aP-CO
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 18:16:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14207
	for ; Tue, 24 Jan 2006 18:14:58 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1XYP-0005M2-1c
	for ietf@ietf.org; Tue, 24 Jan 2006 18:26:26 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 44ECF2596D2;
	Wed, 25 Jan 2006 00:15:05 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 01880-10; Wed, 25 Jan 2006 00:15:01 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 9B27C2596BB;
	Wed, 25 Jan 2006 00:15:00 +0100 (CET)
Date: Tue, 24 Jan 2006 15:15:04 -0800
From: Harald Tveit Alvestrand 
To: jordi.palet@consulintel.es, ietf@ietf.org
Message-ID: <12012B00949A38FBE4B2794F@B50854F0A9192E8EC6CDA126>
In-Reply-To: 
References: 
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: 
Subject: Re: Softwires Interim Meeting
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0853848311=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============0853848311==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========A7E82262667AB72BBE2A=========="

--==========A7E82262667AB72BBE2A==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable



--On 24. januar 2006 18:08 -0400 JORDI PALET MARTINEZ=20
 wrote:

> In order to avoid this happening again, I'm working in some more clear
> suggestions for rules on how to adequately plan Interim meetings. I will
> circulate them ASAP.

I wonder if that's the right approach.....

the original impetus for the "30 day rule" was a situation where we had a=20
non-US IETF (I think it was Adelaide), and suddenly were hit by a flurry of =

requests for "interim" meetings a week or two before or afte the IETF=20
meeting - all of them intending to be in the US.

The interpretation of some was that this looked like an attempt by US=20
participants to avoid the expense of going overseas, leading to a=20
perception that they thought it was fair that overseas participants always=20
paid the cost of participating in US meetings, but not vice versa.

In this case, the IETF meeting is in the US, and the interim meeting is not =

- so the foot may be in the other mouth, as the saying goes.

If making rules, I'd say "30 days is the norm. It's a rule unless the AD=20
says otherwise; the AD's decision has to be published" (so that we can see=20
who to blame if the community thinks it's not OK.

But be careful what's a rule and what's advice, and don't mix too many=20
topics into one document..... it destroys the ability to get finished.

               Harald






--==========A7E82262667AB72BBE2A==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFD1rT4OMj+2+WY0F4RAmIRAJwL3JEJARRfy4Rlo3xkyFyBi3/K/ACg23LT
EnxsEQpIYu6TOQYXmvNEJEc=
=3E5Q
-----END PGP SIGNATURE-----

--==========A7E82262667AB72BBE2A==========--



--===============0853848311==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0853848311==--





From ietf-bounces@ietf.org Tue Jan 24 18:18:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1XQM-0005s2-IQ; Tue, 24 Jan 2006 18:18:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1XQK-0005ph-1g
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 18:18:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14304
	for ; Tue, 24 Jan 2006 18:16:33 -0500 (EST)
Received: from mercury.lcs.mit.edu ([18.26.0.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1XZw-0005QV-Ln
	for ietf@ietf.org; Tue, 24 Jan 2006 18:28:01 -0500
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178)
	id 7BAF686AE5; Tue, 24 Jan 2006 18:17:53 -0500 (EST)
To: ietf@ietf.org
Message-Id: <20060124231753.7BAF686AE5@mercury.lcs.mit.edu>
Date: Tue, 24 Jan 2006 18:17:53 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

    > From: "william(at)elan.net" 

    > Free speech is at the core of discussions at IETF and those
    > representing minority positions should not be prevented from
    > expressing it 

OK, I'll bite. How do you reconcile this principle with defending someone who
has tried to get people penalized for saying what they think? It seems to me
that there's a logical contradiction there: Jefsey gets to say whatever he
wants, but others can't?

I refer you to the most interesting:

  http://article.gmane.org/gmane.ietf.ltru/1033

especially where it says things like "Reuters, my employer, received the
following message today" and "'We will contact tomorrow the Reuters legal
department in Paris we will then copy and ask an acknowledgment from.'" (And
anyone who thinks that message to Reuters was not an attempt to create trouble
for someone with their employer is being deliberately obtuse.)

	Noel

PS: The IETF is *not* here to provide free speech. It's here to write
protocols. Speech is subsidiary to that goal.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 18:27:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1XZ8-0002Tl-9A; Tue, 24 Jan 2006 18:27:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1XZ6-0002Td-Bj
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 18:27:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15048
	for ; Tue, 24 Jan 2006 18:25:37 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F1Xii-0005mK-Rn
	for ietf@ietf.org; Tue, 24 Jan 2006 18:37:06 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-2.cisco.com with ESMTP; 24 Jan 2006 15:26:58 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0ONQvWF011648;
	Tue, 24 Jan 2006 15:26:57 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 24 Jan 2006 15:26:57 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.88.117]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 24 Jan 2006 15:26:57 -0800
Message-Id: <4.3.2.7.2.20060124172523.034d8eb8@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Jan 2006 17:26:56 -0600
To: jordi.palet@consulintel.es, "ietf@ietf.org" 
From: "James M. Polk" 
In-Reply-To: 
References: <4.3.2.7.2.20060124151411.0334bd20@email.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 24 Jan 2006 23:26:57.0129 (UTC)
	FILETIME=[AAF12590:01C6213D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: 
Subject: Re: Softwires Interim Meeting
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jordi

Please don't misunderstand me, I have no pension for making trouble here, I 
was just observing something that seemed a little out of place is all.  I 
have no interest in forcing any changes to your plans.

At 06:08 PM 1/24/2006 -0400, JORDI PALET MARTINEZ wrote:
>Hi James,
>
>This was already discussed in the WG, and I guess the AD has taken measures
>to avoid this being a real problem.
>
>Right now it will be a real problem canceling the meeting, as some people
>has already got non-refundable and very expensive flights after so many
>weeks of lack of adequate planning.
>
>I've insisted in Vancouver, when the plan for this meeting was drafted, to
>fix it at that time, unfortunately was repeatedly ignored, with the
>consequence of the meeting being first fixed at the end of January in San
>Jose with a non-clear consensus from the participants, and now in dates
>which are also unfortunate for some of us, but as said is too late now to
>start changing it again.
>
>In order to avoid this happening again, I'm working in some more clear
>suggestions for rules on how to adequately plan Interim meetings. I will
>circulate them ASAP.
>
>Regards,
>Jordi
>
>
>
>
> > De: "James M. Polk" 
> > Responder a: 
> > Fecha: Tue, 24 Jan 2006 15:19:27 -0600
> > Para: Mark Townsley , "ietf@ietf.org" 
> > Asunto: Re: Softwires Interim Meeting
> >
> > Mark
> >
> > I'm not an interested party here, and I don't mean to throw a monkey wrench
> > into your plans, but I'm observing that this seems to be within the 30 days
> > of moratorium of when we cannot have an interim, where (loosely) 'interims
> > shall not be within 30 days of the next IETF meeting'.
> >
> > The Dallas IETF starts on March 19th, so I would think the cutoff would be
> > Feb 19th for the last of an interim.  What am I missing?
> >
> > At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote:
> >> The meeting will be Feb 23-24 in Hong Kong. Participants should plan to
> >> arrive Feb 22 for an early start on Feb 23. We will finish by 2pm on Feb
> >> 24. Accomodation information coming shortly (watch the
> >> softwires@ietf.org mailing list).
> >>
> >> Thank you,
> >>
> >> - Mark
> >>
> >> _______________________________________________
> >> IETF-Announce mailing list
> >> IETF-Announce@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ietf-announce
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.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@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 18:39:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Xkw-00078t-8C; Tue, 24 Jan 2006 18:39:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Xku-00078k-4l
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 18:39:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15832
	for ; Tue, 24 Jan 2006 18:37:49 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1XuU-0006Cv-PJ
	for ietf@ietf.org; Tue, 24 Jan 2006 18:49:18 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0ONd2xl079514
	for ; Wed, 25 Jan 2006 00:39:02 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Wed, 25 Jan 2006 00:39:02 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <921295818.20060125003902@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060124231753.7BAF686AE5@mercury.lcs.mit.edu>
References: <20060124231753.7BAF686AE5@mercury.lcs.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: quoted-printable
Subject: Re: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Noel Chiappa writes:

> OK, I'll bite. How do you reconcile this principle with defending someone=
 who
> has tried to get people penalized for saying what they think? It seems to=
 me
> that there's a logical contradiction there: Jefsey gets to say whatever he
> wants, but others can't?
>
> I refer you to the most interesting:
>
>   http://article.gmane.org/gmane.ietf.ltru/1033
>
> especially where it says things like "Reuters, my employer, received the
> following message today" and "'We will contact tomorrow the Reuters legal
> department in Paris we will then copy and ask an acknowledgment from.'"

You're confusing messages sent to this list with messages sent
out-of-band to a different destination.  The question here concerns
only traffic to this list, not other activities carried out by members
of the list in other venues.

> And anyone who thinks that message to Reuters was not an attempt to
> create trouble for someone with their employer is being deliberately
> obtuse.

Poison-pen messages to employers are very risky, and they are usually
defamatory, and if anything bad happens as a result of the messages
thus sent, the sender can find himself in considerable trouble.

At the same time, an employer who acts upon a mere poison-pen e-mail
or letter in an inappropriate way can find himself in trouble, too.

And finally, someone who sends messages under the cover of a corporate
e-mail address, domain, etc., runs the risk of implicitly dragging his
employer's name into purely personal disputes, which is why many
employers require that their employees not use corporate e-mail
addresses or other identifiable resources when expressing their own
opinions online.

> PS: The IETF is *not* here to provide free speech. It's here to write
> protocols. Speech is subsidiary to that goal.

From=20what I've seen lately, it's here to argue about who should be
censored, and to chat about which hotel should be equipped with what
equipment, and other matters that seem utterly foreign to anything
like "Internet engineering."  It sounds eerily like a typical,
ineffectual bureaucratic agency.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 18:39:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1XlF-0007JH-Ut; Tue, 24 Jan 2006 18:39:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1XlE-0007Gy-Ke
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 18:39:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15861
	for ; Tue, 24 Jan 2006 18:38:10 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F1Xur-0006Dl-Fw
	for ietf@ietf.org; Tue, 24 Jan 2006 18:49:38 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-2.cisco.com with ESMTP; 24 Jan 2006 15:39:30 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0ONdUWF018185;
	Tue, 24 Jan 2006 15:39:30 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 24 Jan 2006 15:39:29 -0800
Received: from [171.69.52.163] ([171.69.52.163]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 24 Jan 2006 15:39:29 -0800
Message-ID: <43D6BAAF.4060302@cisco.com>
Date: Tue, 24 Jan 2006 15:39:27 -0800
From: Mark Townsley 
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Marshall Eubanks 
References: <4.3.2.7.2.20060124151411.0334bd20@email.cisco.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Jan 2006 23:39:29.0332 (UTC)
	FILETIME=[6B4A3740:01C6213F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Softwires Interim Meeting
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Marshall Eubanks wrote:

> March 19 - 30 days = Feb 17th.

This date was chosen, understanding that it bends the rules a bit, to 
increase the greater goal of global participation by coinciding with the 
APRICOT conference the following week (so at least some of the 
non-asiapac members will be on the correct side of the globe).

- Mark

>
> On Jan 24, 2006, at 4:19 PM, James M. Polk wrote:
>
>> Mark
>>
>> I'm not an interested party here, and I don't mean to throw a  monkey 
>> wrench into your plans, but I'm observing that this seems to  be 
>> within the 30 days of moratorium of when we cannot have an  interim, 
>> where (loosely) 'interims shall not be within 30 days of  the next 
>> IETF meeting'.
>>
>> The Dallas IETF starts on March 19th, so I would think the cutoff  
>> would be Feb 19th for the last of an interim.  What am I missing?
>>
>> At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote:
>>
>>> The meeting will be Feb 23-24 in Hong Kong. Participants should  
>>> plan to
>>> arrive Feb 22 for an early start on Feb 23. We will finish by 2pm  
>>> on Feb
>>> 24. Accomodation information coming shortly (watch the
>>> softwires@ietf.org mailing list).
>>>
>>> Thank you,
>>>
>>> - Mark
>>>
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> IETF-Announce@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ietf-announce
>>
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>
>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 18:45:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1XqU-0000Kd-0A; Tue, 24 Jan 2006 18:45:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1XqS-0000KQ-53
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 18:45:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16315
	for ; Tue, 24 Jan 2006 18:43:33 -0500 (EST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Y02-0006Qs-VR
	for ietf@ietf.org; Tue, 24 Jan 2006 18:55:02 -0500
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k0ONis4u011178; 
	Tue, 24 Jan 2006 15:44:54 -0800 (PST)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with
	ESMTP id k0ONirWa029068; Tue, 24 Jan 2006 18:44:53 -0500 (EST)
Received: from 127.0.0.1 (localhost [127.0.0.1])
	by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k0ONiqba019488; 
	Tue, 24 Jan 2006 18:44:53 -0500 (EST)
From: Bill Sommerfeld 
To: rpelletier@isoc.org
In-Reply-To: <2304.128.9.168.71.1138056307.webmail@128.9.168.71>
References: <2304.128.9.168.71.1138056307.webmail@128.9.168.71>
Content-Type: text/plain; charset=iso-8859-1
Message-Id: <1138146292.17240.252.camel@thunk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6.330 
Date: Tue, 24 Jan 2006 18:44:52 -0500
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 2006-01-23 at 17:45, rpelletier@isoc.org wrote:
> Among the results are:
> 1.  Slightly more than 25% say their laptop is compatible with 802.11a.
> [Note the IETF 65 NOC for Dallas recommends 802.11a]
> 
> 5.  Only 1/3 of the respondents expressed satisfaction with the wireless
> connectivity.

Is there any correlation in the survey results between "satisfied with
wireless" and "has 802.11a"?

					- Bill



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 18:46:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Xru-0001AU-D7; Tue, 24 Jan 2006 18:46:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Xrr-0001AF-WA
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 18:46:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16519
	for ; Tue, 24 Jan 2006 18:45:01 -0500 (EST)
Received: from sokol.elan.net ([216.151.192.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Y1S-0006UP-Fq
	for ietf@ietf.org; Tue, 24 Jan 2006 18:56:30 -0500
Received: from sokol.elan.net (sokol [127.0.0.1])
	by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k0ONkMBi012595;
	Tue, 24 Jan 2006 15:46:22 -0800
Received: from localhost (william@localhost)
	by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k0ONkLT6012592; 
	Tue, 24 Jan 2006 15:46:22 -0800
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Tue, 24 Jan 2006 15:46:21 -0800 (PST)
From: "william(at)elan.net" 
To: Noel Chiappa 
In-Reply-To: <20060124231753.7BAF686AE5@mercury.lcs.mit.edu>
Message-ID: 
References: <20060124231753.7BAF686AE5@mercury.lcs.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: ietf@ietf.org
Subject: Re: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Tue, 24 Jan 2006, Noel Chiappa wrote:

>    > From: "william(at)elan.net" 
>
>    > Free speech is at the core of discussions at IETF and those
>    > representing minority positions should not be prevented from
>    > expressing it
>
> OK, I'll bite. How do you reconcile this principle with defending someone who
> has tried to get people penalized for saying what they think? It seems to me
> that there's a logical contradiction there: Jefsey gets to say whatever he
> wants, but others can't?

Jut to explain, my original draft text was larger and I removed some
(most) of its text before posting to ietf list; it may have helped if
I did not do it ... (although I think it was too verbose). The reason
why I left last sentence was actually because I strongly disagree
with idea of baning somebody from entire ietf because of how he's
been advocating his position on one (or two) mail list - that was
the core of that sentence (rather then free speech issue).

In regards to free speech, I understand that certain limitations must
be made in the way we post, so it does not disturb entire process
(i.e. I do have right to free speech, but its bad idea to exercise
that right in the middle of the highway). If I did not remove some
of the other text, it would have been clear that what I was more
concerned with is how these limitations are being put in place and
that precedents offered by PR actions allow what could be described
as "IETF elite" to have even bigger way to control the activities
and to get rid of anyone they do not like and this could lead to
other people not being entirely open for the fear of being banned
(which is what I meant by such actions being against free speech).
I think this is bad idea and PR action should be used very very very 
reluctantly and I do not see it as being the right case here.

-- 
William Leibzon
Elan Networks
william@elan.net

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 18:51:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1XwC-0002VR-Ip; Tue, 24 Jan 2006 18:51:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Xw9-0002UD-Oz
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 18:50:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16894
	for ; Tue, 24 Jan 2006 18:49:27 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Y5m-0006i8-K0
	for ietf@ietf.org; Tue, 24 Jan 2006 19:00:56 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 62C392596D7
	for ; Wed, 25 Jan 2006 00:49:38 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP id 02492-09 for ;
	Wed, 25 Jan 2006 00:49:33 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 5F0812596D2
	for ; Wed, 25 Jan 2006 00:49:31 +0100 (CET)
Date: Tue, 24 Jan 2006 15:50:27 -0800
From: Harald Tveit Alvestrand 
To: ietf@ietf.org
Message-ID: <8247DE093C399FBC0065C883@B50854F0A9192E8EC6CDA126>
In-Reply-To: <921295818.20060125003902@atkielski.com>
References: <20060124231753.7BAF686AE5@mercury.lcs.mit.edu>
	<921295818.20060125003902@atkielski.com>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Subject: Re: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0153290207=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============0153290207==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========9B5926C9245803B2A87C=========="

--==========9B5926C9245803B2A87C==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable



--On 25. januar 2006 00:39 +0100 "Anthony G. Atkielski"=20
 wrote:

>> I refer you to the most interesting:
>>
>>   http://article.gmane.org/gmane.ietf.ltru/1033
>>
>> especially where it says things like "Reuters, my employer, received the
>> following message today" and "'We will contact tomorrow the Reuters =
legal
>> department in Paris we will then copy and ask an acknowledgment from.'"
>
> You're confusing messages sent to this list with messages sent
> out-of-band to a different destination.  The question here concerns
> only traffic to this list, not other activities carried out by members
> of the list in other venues.

thanks for informing us that you're discussing that.... the IETF Last Call=20
that started this debate was concerned with behaviour on the ietf-languages =

and ltru lists, not the IETF list. Read the Last Call:



It does not refer to the IETF list at all, except that it refers to "other=20
IETF mailing lists".

Does this mean that you have no opinion on the actual content of the Last=20
Call?

                  Harald




--==========9B5926C9245803B2A87C==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFD1r1DOMj+2+WY0F4RAsbsAJ9xkMdksMTpRqg6mNstc/gLuL6DygCgme43
cLixn3DcOTzcLw2EEa9THCo=
=Z6oI
-----END PGP SIGNATURE-----

--==========9B5926C9245803B2A87C==========--



--===============0153290207==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0153290207==--





From ietf-bounces@ietf.org Tue Jan 24 18:58:40 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1Y3b-0000Gc-VQ; Tue, 24 Jan 2006 18:58:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Y3Y-0000EQ-RD
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 18:58:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18527
	for ; Tue, 24 Jan 2006 18:57:05 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1YDC-0007OA-8S
	for ietf@ietf.org; Tue, 24 Jan 2006 19:08:34 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0ONwQgx027943; Tue, 24 Jan 2006 18:58:26 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA04896; 
	Tue, 24 Jan 2006 18:58:26 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Tue, 24 Jan 2006 18:58:25 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C886381@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'jnc@mercury.lcs.mit.edu'" 
Date: Tue, 24 Jan 2006 18:58:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: ietf@ietf.org
Subject: RE: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Noel,

	I think you may have bitten into a bear-trap.  :-)

	First, the site you cite speculates that  is
the "author" of this note.  That may be the case, but there 
is no evidence - contained at that site - to support that 
speculative assertion.  It certainly is possible, maybe even 
very likely, that the letter originated at that 's 
direct request or complaint.  It may even have been the case 
that the same  had a direct hand in the phrasing the
words used in the "letter" - but all of that is speculative.  
We need more direct evidence that this  actually did
"author" the "letter" in question, before we should act as if
we are convinced.

	Second, the "letter" complains not about something that
 said, but something that  was 
doing.  Specifically, it appears to me, that  is 
accused of trying to effectively silence the original .

	I believe that responding to a specific action of this 
sort is absolutely consistent with a belief in the right to
be heard.

	Which is a good segue into one of your other points: I
absolutely agree that the IETF is not here to provide free
speech.  However, the IETF MUST be an open forum in which
people from different cultural and corporate backgrounds can
be heard (as long as they can make even a weak case for the
relevance of what they are saying) - when it comes to how we
write protocols and how this process and effort is going to
impact on them.

	We can't just create a cluster of "good guys" and go 
off into hall-way meetings to make decisions that affect 
many millions of people and many billions of dollars in the
businesses and economies of the whole world.  The "bad guys"
also have a right to be heard - at least to the extent that
they only want to be heard.

	I think the problem is that a lot of people want to 
send a message to a specific individual that they have 
"heard" him enough.  And the only hammer lying near-by that
is big enough to send that message is RFC 3683.  In this
case, this is definitely not the right thing to do.  

	Use the tool that was intended for this purpose.  If
it doesn't work, then fix it.  Don't just pick up the next
bigger hammer without regard for the message that everyone
else is going to get.

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of jnc@mercury.lcs.mit.edu
--> Sent: Tuesday, January 24, 2006 6:18 PM
--> To: ietf@ietf.org
--> Cc: jnc@mercury.lcs.mit.edu
--> Subject: Re: Against "PR-action against Jefsey Morfin"
--> 
-->     > From: "william(at)elan.net" 
--> 
-->     > Free speech is at the core of discussions at IETF and those
-->     > representing minority positions should not be prevented from
-->     > expressing it 
--> 
--> OK, I'll bite. How do you reconcile this principle with 
--> defending someone who
--> has tried to get people penalized for saying what they 
--> think? It seems to me
--> that there's a logical contradiction there: Jefsey gets to 
--> say whatever he
--> wants, but others can't?
--> 
--> I refer you to the most interesting:
--> 
-->   http://article.gmane.org/gmane.ietf.ltru/1033
--> 
--> especially where it says things like "Reuters, my employer, 
--> received the
--> following message today" and "'We will contact tomorrow the 
--> Reuters legal
--> department in Paris we will then copy and ask an 
--> acknowledgment from.'" (And
--> anyone who thinks that message to Reuters was not an 
--> attempt to create trouble
--> for someone with their employer is being deliberately obtuse.)
--> 
--> 	Noel
--> 
--> PS: The IETF is *not* here to provide free speech. It's 
--> here to write
--> protocols. Speech is subsidiary to that goal.
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 19:19:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1YNv-0003oY-Bf; Tue, 24 Jan 2006 19:19:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1YNq-0003lF-No
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 19:19:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20155
	for ; Tue, 24 Jan 2006 19:18:03 -0500 (EST)
From: rpelletier@isoc.org
Received: from smtp116.iad.emailsrvr.com ([207.97.245.116]
	helo=smtp136.iad.emailsrvr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1YXT-00089a-LO
	for ietf@ietf.org; Tue, 24 Jan 2006 19:29:32 -0500
Received: from secure.webmail.us (webmail1.r1.iad.emailsrvr.com [10.238.10.9])
	by relay1.r1.iad.emailsrvr.com (SMTP Server) with ESMTP id
	E2BCE44C01C; Tue, 24 Jan 2006 19:19:23 -0500 (EST)
Received: from 128.9.168.71 (Webmail authenticated user rpelletier@isoc.org,
	rpelletier@isoc.org); by secure.webmail.us with HTTP;
	Tue, 24 Jan 2006 19:19:23 -0500 (EST)
Message-ID: <4650.128.9.168.71.1138148363.webmail@128.9.168.71>
In-Reply-To: <1138146292.17240.252.camel@thunk>
References: <2304.128.9.168.71.1138056307.webmail@128.9.168.71>
	<1138146292.17240.252.camel@thunk>
Date: Tue, 24 Jan 2006 19:19:23 -0500 (EST)
To: "Bill Sommerfeld" 
X-Mailer: Webmail v3
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: OK
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.3 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rpelletier@isoc.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org






-----Original Message-----
From: "Bill Sommerfeld" 
Sent: Tuesday, January 24, 2006 6:44 pm
To: rpelletier@isoc.org
Cc: ietf@ietf.org
Subject: Re: Meeting Survey Results

On Mon, 2006-01-23 at 17:45, rpelletier@isoc.org wrote:
> Among the results are:
> 1.  Slightly more than 25% say their laptop is compatible with 802.11a.
> [Note the IETF 65 NOC for Dallas recommends 802.11a]
>
> 5.  Only 1/3 of the respondents expressed satisfaction with the wireles=
s
> connectivity.

Is there any correlation in the survey results between "satisfied with
wireless" and "has 802.11a"?

Nearly 55% of those who said they had 802.11a said wireless was adequate
or better.
Ray

					- Bill





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 19:45:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1YnH-00062j-OM; Tue, 24 Jan 2006 19:45:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1YnF-00062a-EY
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 19:45:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21662
	for ; Tue, 24 Jan 2006 19:44:18 -0500 (EST)
Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Yws-0000XD-4E
	for ietf@ietf.org; Tue, 24 Jan 2006 19:55:47 -0500
Received: from [127.0.0.1] (www.caia.swin.edu.au [136.186.229.16])
	by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id LAA1022611;
	Wed, 25 Jan 2006 11:45:32 +1100 (EST)
Message-ID: <43D6CA28.1000402@swin.edu.au>
Date: Wed, 25 Jan 2006 11:45:28 +1100
From: grenville armitage 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Subject: Free speech? Re: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

william(at)elan.net wrote:
	[..]
> Free speech is at the core
> of discussions at IETF [...]

Must admit I always thought it was constructive speech (in the sense
of attempting to engineer solutions, new architectures, protocols or
clarity of understanding) that was at the core of discussions at IETF.

How things change.

cheers,
gja

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 20:35:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1ZYr-0002MB-Uv; Tue, 24 Jan 2006 20:35:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ZYp-0002LK-Sx
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 20:35:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24936
	for ; Tue, 24 Jan 2006 20:33:28 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1ZiT-0002Dt-Mb
	for ietf@ietf.org; Tue, 24 Jan 2006 20:44:59 -0500
Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net
	[68.165.240.35]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0P1Z5aO017533
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Tue, 24 Jan 2006 17:35:08 -0800
Message-ID: <43D6D5A0.8030008@shockey.us>
Date: Tue, 24 Jan 2006 20:34:24 -0500
From: Richard Shockey 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
CC: ietf@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Subject: Richard Shockey supports IETF "renditioning" the Jefsey Morfin
 problem to the CIA
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



Now can we get back to our regularly scheduled rants on the pro's an
con's of ASCII in RFC's?


-- 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 21:52:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1alw-00005c-56; Tue, 24 Jan 2006 21:52:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1alu-00005U-0e
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 21:52:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00063
	for ; Tue, 24 Jan 2006 21:51:02 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1avW-0004mw-65
	for ietf@ietf.org; Tue, 24 Jan 2006 22:02:33 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0P2qFdG081245
	for ; Wed, 25 Jan 2006 03:52:16 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Wed, 25 Jan 2006 03:52:15 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <102944513.20060125035215@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <8247DE093C399FBC0065C883@B50854F0A9192E8EC6CDA126>
References: <20060124231753.7BAF686AE5@mercury.lcs.mit.edu>
	<921295818.20060125003902@atkielski.com>
	<8247DE093C399FBC0065C883@B50854F0A9192E8EC6CDA126>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Subject: Re: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Harald Tveit Alvestrand writes:

> thanks for informing us that you're discussing that.... the IETF Last Call
> that started this debate was concerned with behaviour on the ietf-languages
> and ltru lists, not the IETF list. Read the Last Call:
>
> 
>
> It does not refer to the IETF list at all, except that it refers to "other
> IETF mailing lists".
>
> Does this mean that you have no opinion on the actual content of the Last
> Call?

Out of band means not sent to e-mail lists at all, so my comments
apply to all mailing lists, and not just this particular list.

My opinions are general and don't apply to any specific censorship
attempt.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 21:55:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1aoO-00019U-Ei; Tue, 24 Jan 2006 21:55:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1aoM-00019L-1H
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 21:55:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00217
	for ; Tue, 24 Jan 2006 21:53:34 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1ay1-0004rb-FQ
	for ietf@ietf.org; Tue, 24 Jan 2006 22:05:06 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0P2sues081267
	for ; Wed, 25 Jan 2006 03:54:56 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Wed, 25 Jan 2006 03:54:56 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1832787170.20060125035456@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D6CA28.1000402@swin.edu.au>
References: 
	<43D6CA28.1000402@swin.edu.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Subject: Re: Free speech? Re: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

grenville armitage writes:

> Must admit I always thought it was constructive speech (in the sense
> of attempting to engineer solutions, new architectures, protocols or
> clarity of understanding) that was at the core of discussions at IETF.

Then I suppose that threads such as "Meeting Survey Results," which
have nothing to do with these goals, are out of order?

Decisions as to what counts as "constructive" are subjective, unfortunately.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 24 22:57:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1bms-0000i1-6N; Tue, 24 Jan 2006 22:57:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1bmp-0000fZ-VY
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 22:57:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03944
	for ; Tue, 24 Jan 2006 22:56:04 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc12.comcast.net ([204.127.202.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1bwS-0006hA-S4
	for ietf@ietf.org; Tue, 24 Jan 2006 23:07:36 -0500
Received: from smailcenter68.comcast.net ([204.127.205.168])
	by comcast.net (sccrmhc12) with SMTP
	id <2006012503571701200n8a7oe>; Wed, 25 Jan 2006 03:57:17 +0000
Received: from [66.229.53.140] by smailcenter68.comcast.net;
	Wed, 25 Jan 2006 03:57:17 +0000
To: ietf@ietf.org
Date: Wed, 25 Jan 2006 03:57:17 +0000
Message-Id: <012520060357.16353.43D6F71C000D778600003FE1220702065300000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Subject: Questions for those in favor of PR-Actions in general
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0750344646=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0750344646==
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_16353_1138161437_0"


--NextPart_Webmail_9m3u9jl4l_16353_1138161437_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

There are a couple of arguments consistently used as by the pro-ban/anti-filter camp  that kind of confuse me and maybe someone could explain:
Claim:  The claim that all the good people will leave if the noise level is too great and if stubborn people with limited technical ability aren't banned.
Question:  Since the first PR-Action was only a few months ago are you saying that all the good people have been gone for a long time and everyone still here are the people the good engineers left because of?
Claim:  Filtering by sender doesn't help because you see all the repsonses to their mail.
Question a:  If the responses are part of the problem then aren't the people who sent them part of the problem as well?  They are equally (probably more disruptive), so why not ban them?  Are they incapable of controlling their responses?  Are they lemmings? 
Question b:  If so many people whose email you don't want to filter are replying to the person that you do, then maybe you  are in the minority in thinking their comments aren't worthy of discussion?
Question c:  If so many people whose email you don't want to filter are replying the person that you do then maybe you're the only one who's filtering them?
Question:  If there was rough consensus on banning someone then if that same rough consensus individually filtered all mail to or from that individual wouldn't the same effect be acheived? Roughly?
Question:  Has no one made a dynamic filter that logs the subject of all email sent from an address and then filters all future email with the same subject, regardless of sender or recipient?
Question  How many responses will not be able to refrain from making fun of the Clain/Question format I used?
nick
--NextPart_Webmail_9m3u9jl4l_16353_1138161437_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit



There are a couple of arguments consistently used as by the pro-ban/anti-filter camp  that kind of confuse me and maybe someone could explain:


Claim:  The claim that all the good people will leave if the noise level is too great and if stubborn people with limited technical ability aren't banned.


Question:  Since the first PR-Action was only a few months ago are you saying that all the good people have been gone for a long time and everyone still here are the people the good engineers left because of?


Claim:  Filtering by sender doesn't help because you see all the repsonses to their mail.


Question a:  If the responses are part of the problem then aren't the people who sent them part of the problem as well?  They are equally (probably more disruptive), so why not ban them?  Are they incapable of controlling their responses?  Are they lemmings? 


Question b:  If so many people whose email you don't want to filter are replying to the person that you do, then maybe you  are in the minority in thinking their comments aren't worthy of discussion?


Question c:  If so many people whose email you don't want to filter are replying the person that you do then maybe you're the only one who's filtering them?


Question:  If there was rough consensus on banning someone then if that same rough consensus individually filtered all mail to or from that individual wouldn't the same effect be acheived? Roughly?


Question:  Has no one made a dynamic filter that logs the subject of all email sent from an address and then filters all future email with the same subject, regardless of sender or recipient?


Question  How many responses will not be able to refrain from making fun of the Clain/Question format I used?


nick


--NextPart_Webmail_9m3u9jl4l_16353_1138161437_0--


--===============0750344646==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0750344646==--




From ietf-bounces@ietf.org Tue Jan 24 23:39:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1cRJ-0000lk-Dr; Tue, 24 Jan 2006 23:39:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1cRH-0000lc-AF
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 23:39:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06935
	for ; Tue, 24 Jan 2006 23:37:53 -0500 (EST)
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1caw-0008C4-Dw
	for ietf@ietf.org; Tue, 24 Jan 2006 23:49:24 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k0P4Y36x022819; Wed, 25 Jan 2006 06:34:10 +0200
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Jan 2006 06:38:55 +0200
Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by
	esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 25 Jan 2006 06:38:53 +0200
Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain
	[127.0.0.1])
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id
	k0P4cqK3019320; Tue, 24 Jan 2006 20:38:52 -0800
Received: (from kessens@localhost)
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id
	k0P4cp67019318; Tue, 24 Jan 2006 20:38:51 -0800
Date: Tue, 24 Jan 2006 20:38:51 -0800
From: David Kessens 
To: JORDI PALET MARTINEZ 
Message-ID: <20060125043851.GE16303@nokia.com>
References: <1138077313.21483.8.camel@essrv103nok155120.ntc.nokia.com>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.1i
X-OriginalArrivalTime: 25 Jan 2006 04:38:54.0225 (UTC)
	FILETIME=[3F335810:01C62169]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: "ietf@ietf.org" 
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Jordi,

On Tue, Jan 24, 2006 at 02:44:15PM -0400, JORDI PALET MARTINEZ wrote:
> 
> I'm not sure if I got it. My MUST was on the other way around: We really
> need to warrantee good coverage for b/g to 75% of the participants.

We hope to offer good connectivity to the other 25% of the participants as well.

You can help us by bringing a configured 802.11a card.

David Kessens
---

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 02:00:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1eeB-0000br-SK; Wed, 25 Jan 2006 02:00:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ee9-0000a1-Lp
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 02:00:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15648
	for ; Wed, 25 Jan 2006 01:59:18 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.193])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1enn-0004J3-Vu
	for ietf@ietf.org; Wed, 25 Jan 2006 02:10:51 -0500
Received: by zproxy.gmail.com with SMTP id 8so39670nzo
	for ; Tue, 24 Jan 2006 23:00:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=mvtlQ5T1K8twhPfq6eT5Tg/XbYt1Ka1B6JR5T3B993hU/wfgV8Ffa7HfoZdDV+5PtYgOM4tcRzFMG6Fus//0u27iqKs2JQasmRA0cOKoaKuQ2BktgOHEB1JTTIykC3MpYguN+rVBkg1ZDwKXmXkJHNKCaHcQH4/69E8btMUM4Ps=
Received: by 10.65.97.8 with SMTP id z8mr56977qbl;
	Tue, 24 Jan 2006 23:00:42 -0800 (PST)
Received: by 10.65.182.13 with HTTP; Tue, 24 Jan 2006 23:00:42 -0800 (PST)
Message-ID: <2d106eb50601242300w33551a83q3261d7b3c5706796@mail.gmail.com>
Date: Wed, 25 Jan 2006 02:00:42 -0500
From: Martin Hannigan 
To: ietf@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.5 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Subject: FOR the PR re: JFC
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1446383814=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1446383814==
Content-Type: multipart/alternative; 
	boundary="----=_Part_22110_31887669.1138172442611"

------=_Part_22110_31887669.1138172442611
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

See the subject.

-M<

------=_Part_22110_31887669.1138172442611
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable



See the subject. 

-M<




------=_Part_22110_31887669.1138172442611--


--===============1446383814==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1446383814==--




From ietf-bounces@ietf.org Wed Jan 25 02:45:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1fLA-0007XI-RH; Wed, 25 Jan 2006 02:45:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1fL9-0007VT-4o
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 02:45:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17853
	for ; Wed, 25 Jan 2006 02:43:44 -0500 (EST)
Received: from mtagate2.de.ibm.com ([195.212.29.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1fUp-0005Wz-UO
	for ietf@ietf.org; Wed, 25 Jan 2006 02:55:17 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0P7j3I5235314
	for ; Wed, 25 Jan 2006 07:45:03 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com
	[9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0P7j3oi160246
	for ; Wed, 25 Jan 2006 08:45:03 +0100
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0P7j3Ob027164 for ; Wed, 25 Jan 2006 08:45:03 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0P7j2t3026889 for ; Wed, 25 Jan 2006 08:45:03 +0100
Received: from zurich.ibm.com (dyn-9-159-130-49.ge.ch.ibm.com [9.159.130.49])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA31904
	for ; Wed, 25 Jan 2006 08:44:57 +0100
Message-ID: <43D72C7B.9050004@zurich.ibm.com>
Date: Wed, 25 Jan 2006 08:44:59 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: ietf@ietf.org
References: 	<43D6CA28.1000402@swin.edu.au>
	<1832787170.20060125035456@atkielski.com>
In-Reply-To: <1832787170.20060125035456@atkielski.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Subject: Re: Free speech? Re: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Anthony G. Atkielski wrote:
> grenville armitage writes:
> 
> 
>>Must admit I always thought it was constructive speech (in the sense
>>of attempting to engineer solutions, new architectures, protocols or
>>clarity of understanding) that was at the core of discussions at IETF.
> 
> 
> Then I suppose that threads such as "Meeting Survey Results," which
> have nothing to do with these goals, are out of order?

On *this* list, my attitude is to be more tolerant about scope; the test
is RFC 3005, and that is deliberately liberal.

On WG lists, and specialist lists of other kinds, the test is relevance
to the charter or purpose, and that is much narrower.

Of course, it goes without saying that insults and unprofessional
language of any kind are to be avoided on all lists; and sarcasm and
irony can easily be misunderstood.

> Decisions as to what counts as "constructive" are subjective, unfortunately.

They are, but one thing that is clearly not constructive is endless
debate over issues where the responsible chair or moderator has already
declared a rough consensus. As others have pointed out, rough consensus
is different from unanimity. Once we have established rough consensus
in the IETF, we accept it and move on. That means some people accepting
things they don't agree with.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 04:02:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1gXl-0006bK-Hl; Wed, 25 Jan 2006 04:02:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1gXc-0006Za-Fu
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 04:02:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21937
	for ; Wed, 25 Jan 2006 04:00:40 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1ghI-0007za-Dj
	for ietf@ietf.org; Wed, 25 Jan 2006 04:12:14 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F1gXR-0000MI-J4
	for ietf@ietf.org; Wed, 25 Jan 2006 10:02:01 +0100
Received: from pd9fba9b7.dip0.t-ipconnect.de ([217.251.169.183])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Wed, 25 Jan 2006 10:02:01 +0100
Received: from nobody by pd9fba9b7.dip0.t-ipconnect.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for ; Wed, 25 Jan 2006 10:02:01 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Wed, 25 Jan 2006 10:00:05 +0100
Organization: 
Lines: 36
Message-ID: <43D73E15.6EC8@xyzzy.claranet.de>
References: <012520060357.16353.43D6F71C000D778600003FE1220702065300000E9B9CD2050C0702@comcast.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fba9b7.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Subject: Re: Questions for those in favor of PR-Actions in general
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

nick.staff@comcast.net wrote:

> There are a couple of arguments consistently used as by the
> pro-ban/anti-filter camp that kind of confuse me

Yes, RfC 3683 can obviously have a very high "troll"-factor.
 
> Since the first PR-Action was only a few months ago

The "last call" ended in December.  IMO both 3934 and 3683 are
mainly of interest for folks with "hats", editors, Chairs, ADs,
because they can't simply filter contributors, at least not as
simply as others without "hats".  Besides I fear their private
inbound is flooded by complaints in the case of conflicts.  So
it's mainly for them that they can ban contributors, and it's
for "us" (TINU) that they can't simply decree whatever pleases
them, but follow some procedures like 3005, 3934, and 3683.

IMHO Sam's / John's / Margaret's proposals are generally better
than RfC 3683.  Hard to judge after only two last calls, but I
know this "excommunication" business from other communities.

IIRC there never was a public 3934 warning on _this_ list, and
if somebody isn't allowed to post on another list for some time
(s)he can simply post here.  As long as it's not excessive this
list is rather harmless, nobody expects that e.g. Brian "must"
read all mails here.

For other lists the folks with "hats" need some way to defend
themselves from side-effects of flamewars hitting their private
inbound, and "we" (TINW) want them to do some more interesting 
things like figure out a way to get "rough consensus" for the
technical issues, or help to find bugs and nits in drafts under
discussion.
                                  Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 06:57:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1jHd-0003do-JL; Wed, 25 Jan 2006 06:57:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1jHb-0003bc-6Y
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 06:57:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04248
	for ; Wed, 25 Jan 2006 06:56:20 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc14.comcast.net ([204.127.202.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1jRK-0005at-Eh
	for ietf@ietf.org; Wed, 25 Jan 2006 07:07:55 -0500
Received: from smailcenter58.comcast.net ([204.127.205.158])
	by comcast.net (sccrmhc14) with SMTP
	id <2006012511574001400egs7je>; Wed, 25 Jan 2006 11:57:40 +0000
Received: from [66.229.53.140] by smailcenter58.comcast.net;
	Wed, 25 Jan 2006 11:57:39 +0000
To: Frank Ellermann , ietf@ietf.org
Date: Wed, 25 Jan 2006 11:57:39 +0000
Message-Id: <012520061157.15686.43D767B3000412D800003D46220588636000000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: 
Subject: Questions for those in favor of PR-Actions in general
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1311329350=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============1311329350==
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_15686_1138190259_0"


--NextPart_Webmail_9m3u9jl4l_15686_1138190259_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

I'm sorry Frank, your response didn't address any of my questions so maybe there was some missed direction.  Whatever the case I'll restate it in case you want another go at it:
There are a couple of arguments consistently used by the pro-ban/anti-filter camp  that kind of confuse me and maybe someone could explain:
Claim:  The claim that all the good people will leave if the noise level is too great and if stubborn people with limited technical ability aren't banned.
Question:  If that claim is accurate, then since there were no PR-Actions for the first 20 years of the IETF one would have to assume that all the good people left long ago (years and years) and the ones left here now are the ones that drove the good engineers away?
Claim:  Filtering by sender doesn't help because you see all the repsonses to their mail.
Question a:  If the responses are part of the problem then aren't the people who sent them part of the problem as well?  They are equally (probably more disruptive), so why not ban them?  Are they incapable of controlling their responses?  Are they lemmings? 
Question b:  If so many people whose email you don't want to filter are replying to the person that you do, then maybe you are in the minority in thinking their comments aren't worthy of discussion?
Question c:  If so many people whose email you don't want to filter are replying to the person that you do then maybe you're the only one who's filtering them?
Question:  If there was rough consensus on banning someone then if that same rough consensus individually filtered all mail to or from that individual wouldn't the same effect be acheived? Roughly?
Question:  Has no one made a dynamic filter that logs the subject of all email sent from an address and then filters all future email with the same subject, regardless of sender or recipient?
Question  How many responses will not be able to refrain from making fun of the Clain/Question format I used?
nick
--NextPart_Webmail_9m3u9jl4l_15686_1138190259_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit



I'm sorry Frank, your response didn't address any of my questions so maybe there was some missed direction.  Whatever the case I'll restate it in case you want another go at it:


There are a couple of arguments consistently used by the pro-ban/anti-filter camp  that kind of confuse me and maybe someone could explain:


Claim:  The claim that all the good people will leave if the noise level is too great and if stubborn people with limited technical ability aren't banned.


Question:  If that claim is accurate, then since there were no PR-Actions for the first 20 years of the IETF one would have to assume that all the good people left long ago (years and years) and the ones left here now are the ones that drove the good engineers away?


Claim:  Filtering by sender doesn't help because you see all the repsonses to their mail.


Question a:  If the responses are part of the problem then aren't the people who sent them part of the problem as well?  They are equally (probably more disruptive), so why not ban them?  Are they incapable of controlling their responses?  Are they lemmings? 


Question b:  If so many people whose email you don't want to filter are replying to the person that you do, then maybe you are in the minority in thinking their comments aren't worthy of discussion?


Question c:  If so many people whose email you don't want to filter are replying to the person that you do then maybe you're the only one who's filtering them?


Question:  If there was rough consensus on banning someone then if that same rough consensus individually filtered all mail to or from that individual wouldn't the same effect be acheived? Roughly?


Question:  Has no one made a dynamic filter that logs the subject of all email sent from an address and then filters all future email with the same subject, regardless of sender or recipient?


Question  How many responses will not be able to refrain from making fun of the Clain/Question format I used?


nick


--NextPart_Webmail_9m3u9jl4l_15686_1138190259_0--


--===============1311329350==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1311329350==--




From ietf-bounces@ietf.org Wed Jan 25 07:40:44 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1jx6-00018I-15; Wed, 25 Jan 2006 07:40:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1jx3-00017m-Bp
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 07:40:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07318
	for ; Wed, 25 Jan 2006 07:39:10 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1k6k-00073F-Ca
	for ietf@ietf.org; Wed, 25 Jan 2006 07:50:45 -0500
Received: from [150.189.240.96] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001584438.msg
	for ; Wed, 25 Jan 2006 13:42:43 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Wed, 25 Jan 2006 08:40:13 -0400
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: Meeting Survey Results
Thread-Index: AcYhrHxKuwS9HI2fEdqeyAANky3PwA==
In-Reply-To: <20060125043851.GE16303@nokia.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060125:ietf@ietf.org::ltZmI1Z5525GmwGK:00001jn1
X-MDRemoteIP: 150.189.240.96
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Wed, 25 Jan 2006 13:42:45 +0100
X-MDAV-Processed: consulintel.es, Wed, 25 Jan 2006 13:42:46 +0100
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi David,

Don't want to start a new useless thread here, my point was basically to
show that b/g has a wider adoption and 75% of the laptops don't have
built-in a, so it makes sense to make additional effort to get it working.

I also learn from a previous email the reasons why b/g are not so good in
our meeting, and may be thru our liaison with IEEE we need to make some
noise over there, so the market use a better technology.

I also got some folks confirming that a cards where available also in
previous meetings, but probably that was not properly advertised, may be ?

Regards,
Jordi




> De: David Kessens 
> Responder a: 
> Fecha: Tue, 24 Jan 2006 20:38:51 -0800
> Para: JORDI PALET MARTINEZ 
> CC: "ietf@ietf.org" 
> Asunto: Re: Meeting Survey Results
> 
> 
> Jordi,
> 
> On Tue, Jan 24, 2006 at 02:44:15PM -0400, JORDI PALET MARTINEZ wrote:
>> 
>> I'm not sure if I got it. My MUST was on the other way around: We really
>> need to warrantee good coverage for b/g to 75% of the participants.
> 
> We hope to offer good connectivity to the other 25% of the participants as
> well.
> 
> You can help us by bringing a configured 802.11a card.
> 
> David Kessens
> ---
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 08:02:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1kIb-0008Lg-RO; Wed, 25 Jan 2006 08:02:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1kIY-0008KT-Mp
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 08:02:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10053
	for ; Wed, 25 Jan 2006 08:01:22 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1kSF-0008GC-OV
	for ietf@ietf.org; Wed, 25 Jan 2006 08:12:57 -0500
Received: (qmail invoked by alias); 25 Jan 2006 13:02:30 -0000
Received: from p54A7CE9F.dip.t-dialin.net (EHLO peter-dambier.de)
	[84.167.206.159]
	by mail.gmx.net (mp029) with SMTP; 25 Jan 2006 14:02:30 +0100
X-Authenticated: #8956597
Message-ID: <43D776E0.3060900@peter-dambier.de>
Date: Wed, 25 Jan 2006 14:02:24 +0100
From: Peter Dambier 
Organization: Peter and Karin Dambier
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: ietf@ietf.org
References: <012520060357.16353.43D6F71C000D778600003FE1220702065300000E9B9CD2050C0702@comcast.net>
In-Reply-To: <012520060357.16353.43D6F71C000D778600003FE1220702065300000E9B9CD2050C0702@comcast.net>
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Subject: Re: Questions for those in favor of CoS in general
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: peter@peter-dambier.de
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

To make a long debate short.

When you no longer know what is real and what is imagination,
that is a clear sign that the Church of Scientology might
be involved.

When you have facts in front of your eyes but people keep
telling you different.

When new facts start aperaring but you have no clue of their
origin.

Would it not be easier to ask about cult membership and
then to decide whom to exclude and whom not?

By the way, Scientology is a history of censoring.

I am sorry if I am terrybly off topic now,
but all threads around Jefseys posting rights are.

regards,
Peter and Karin Dambier


-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@peter-dambier.de
mail: peter@echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 08:53:13 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1l5F-0001ya-Ry; Wed, 25 Jan 2006 08:53:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1UKK-0004zd-1G
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 14:59:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13616
	for ; Tue, 24 Jan 2006 14:58:08 -0500 (EST)
Received: from intellical.net ([217.160.241.227] helo=pjag.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1UTu-0000kN-DD
	for ietf@ietf.org; Tue, 24 Jan 2006 15:09:35 -0500
Received: (qmail 30996 invoked from network); 24 Jan 2006 14:59:29 -0500
Received: from localhost (HELO ?192.168.168.10?) (127.0.0.1)
	by localhost with (DHE-RSA-AES256-SHA encrypted) SMTP;
	24 Jan 2006 14:59:29 -0500
Message-ID: <43D6871B.8040601@IntelliCal.net>
Date: Tue, 24 Jan 2006 12:59:23 -0700
From: Doug Royer 
Organization: IntelliCal LLC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <20060120185257.GE18960@ccil.org>	<1797258665.20060123163611@atkielski.com>		<0728557.20060124163321@atkielski.com>
	<43D683FA.8050502@unfix.org>
In-Reply-To: <43D683FA.8050502@unfix.org>
Content-Type: multipart/mixed; boundary="------------070706030303010707000205"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
X-Mailman-Approved-At: Wed, 25 Jan 2006 08:53:10 -0500
Subject: Re: Proposal for keeping "free speech" but limitting the nuisance
 to the working group (Was: John Cowan supports 3683 PR-action against Jefsey
 Morfin)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.
--------------070706030303010707000205
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Are you going to write mailing list software an provide it
free of charge to implement all of this?



Jeroen Massar wrote:
> Anthony G. Atkielski wrote:
> 
>>Pekka Savola writes:
>>
>>
>>>Why must each and every WG member be required to filter a person's
>>>postings?  Much more convenient to do so in one place.
>>
>>Because each and every WG member is an individual, with his own ideas
>>of what he does or doesn't want to read, and imposing the same rules
>>upon everyone prevents members from making their own decisions.  It
>>also imposes the decisions of a small minority upon the majority.
> 
> 
> Here goes for a try... flame me off list if required.
> 
> As it is indeed quite controversial to 'block' people, maybe there can
> be a solution that, though it will have overhead for listadmins, it will
> help the process that the workinggroup is actually for in the first place.
> 
> In the several messages there have been brought up a number of solutions
>  to the problem where one or multiple entities are (deliberately)
> flooding/overloading the mailinglists of workinggroups and other places
> with off-topic messages.
> 
> There seem to be a couple of solutions, amongst which:
>  - Filtering based on source address at the receiver
>  - Filtering based on keywords, which has really bad side-effects.
>  - Blocking the sender at the mailinglist level.
>  - 3683 PR for complete full blockage of posting rights.
> 
> The first is reasonably fine, as you don't see the message of the entity
> that one finds not useful, but you might see responses of others thus
> this is still intrusive and you still get those messages which you
> wanted to filter out. The second option might filter out messages which
> you did want to read. Both still will get these messages in the
> mailinglist archive, even though there was a consensus that those
> messages are unwanted.
> 
> The third and fourth option are pretty definitive, no more messages from
> that entity, but this might be seen as silencing this persons freedom of
> speech.
> 
> My proposal to solve this issue but keeping everybody happy:
> 
> Two mailinglists: @ietf.org + full.@ietf.org
> 
> full.@ is completely open, anybody can post anything they want
> though hopefully on topic on the subject of the workinggroup and of
> course based on the source address having a subscription *1
> full.@ is subscribed to @ thus full.wg gets everything
> preserving, at least parts, of the freedom of speech that is wanted and
> for the people who want to read a lot of mail everyday.
> 
> Initially everybody who signs up to the @ list can post to it.
> When the consensus on the list is that a member is not participating
> correctly, ignoring warnings etc, like currently this member can be
> banned from the list for a temporary amount of time. The member can
> still voice his opinions on the @ list. This thus allows him to
> voice his concerns to the members that do want to read them. Like the
> current 3683 PR the ban can become effectively indefinitely for the main
> list, while the poster is still and always allowed on full.@.
> 
> 
> The big concern here is of course that one could say that if you get
> booted out of the group that your voice won't be heard as they are not
> reading the other list. This is of course true, but one can raise their
> concerns on the full list, for instance Google won't differentiate
> between them and there will always be folks who will listen to it and
> forward these concerns when they have valid argumentation. By posting
> 'good' messages to the full.@ list a member can also demonstrate
> that he is really willing to contribute instead of disrupt. One of the
> nicest controversies is of course what to determine good and bad,
> starwars as an example, how bad are the jedi and how good are the sith,
> it completely depends on the side you are on, nothing else. That all
> boils down to trust and other factors, any mailinglist admin could abuse
> his position to set the sender of an address to silently discard, SMTP
> can have a CC: in the header and mailman will not forward the message to
> that person and various other nice tricks.
> 
> I hope the above might give a better point to discuss all this over
> instead of seeing replies like "that is not good" "see above" and other
> comments without effective constructive arguments.
> 
> Greets,
>  Jeroen
> 
> *1 = to avoid the large amount of spam flowing to the various lists
> which nicely get blocked because of subscription regulation.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

-- 

Doug Royer                     | http://IntelliCal.com
-------------------------------|-----------------------------
               Intelligent Calendars


--------------070706030303010707000205
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Disposition: attachment;
 filename="Doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:IntelliCal LLC
adr:;;267 Kentlands Blvd, #3041;Gaithersburg;MD;20878;USA
email;internet:Doug@IntelliCal.net
title:CTO
x-mozilla-html:FALSE
url:http://IntelliCal.com
version:2.1
end:vcard


--------------070706030303010707000205
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--------------070706030303010707000205--




From ietf-bounces@ietf.org Wed Jan 25 08:53:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1l5H-0001z0-63; Wed, 25 Jan 2006 08:53:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1akQ-0008Ey-Qq
	for ietf@megatron.ietf.org; Tue, 24 Jan 2006 21:51:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00027
	for ; Tue, 24 Jan 2006 21:49:31 -0500 (EST)
Received: from out4.smtp.messagingengine.com ([66.111.4.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1atx-0004ll-E7
	for ietf@ietf.org; Tue, 24 Jan 2006 22:01:02 -0500
Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149])
	by frontend1.messagingengine.com (Postfix) with ESMTP id 7A7DFD2FEB1
	for ; Tue, 24 Jan 2006 21:50:49 -0500 (EST)
Received: from frontend2.messagingengine.com ([10.202.2.151])
	by frontend1.internal (MEProxy); Tue, 24 Jan 2006 21:50:49 -0500
X-Sasl-enc: ZnFzhUp5FVsSxNQ7Vm/CatFCmC97W9sC7PMYVA9eNsUt 1138157447
Received: from [10.0.1.2] (unknown [66.90.11.67])
	by www.fastmail.fm (Postfix) with ESMTP id 6A7EF57146F
	for ; Tue, 24 Jan 2006 21:50:47 -0500 (EST)
Date: Tue, 24 Jan 2006 21:50:50 -0500
From: Cyrus Daboo 
To: ETF General Discussion Mailing List 
Message-ID: <1DD8BE36A56F85B035E41DAC@ninevah.local>
In-Reply-To: <43D6264C.8040707@zurich.ibm.com>
References: <200601232206.RAA26102@ietf.org>
	<990E19C4-E511-485D-962D-27F7C05A1573@mit.edu>
	<86zmlmk2co.fsf@raman.networkresonance.com>
	<89C6E50B5BBFB767B68066FF@sirius.fac.cs.cmu.edu>
	<20060124013629.GA27182@thunk.org>	<43D5FA9D.8090200@alcatel.com>
	<43D6264C.8040707@zurich.ibm.com>
X-Mailer: Mulberry/4.0.4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 25 Jan 2006 08:53:10 -0500
Subject: Re: IETFs... the final Friday?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Brian,

--On January 24, 2006 2:06:20 PM +0100 Brian E Carpenter 
 wrote:

> 2. it would be much appreciated, subject to financial limits,
> to have some wireless connectivity through Friday afternoon.

It may be enough just to keep the terminal room open as long as possible 
(with both wired and wireless access only in that area) but allow wireless 
in the meeting rooms to be dismantled after all meetings are done.

-- 
Cyrus Daboo


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 11:54:39 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1nup-00071A-EC; Wed, 25 Jan 2006 11:54:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1nun-00070u-Bw
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 11:54:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29908
	for ; Wed, 25 Jan 2006 11:53:01 -0500 (EST)
Received: from peewit.ecs.soton.ac.uk ([152.78.68.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1o4T-0008KO-If
	for ietf@ietf.org; Wed, 25 Jan 2006 12:04:41 -0500
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk
	[IPv6:2001:630:d0:f102:230:48ff:fe23:58df])
	by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k0PGsWf6020354
	for ; Wed, 25 Jan 2006 16:54:32 GMT
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id k0PGrq915223
	for ietf@ietf.org; Wed, 25 Jan 2006 16:53:52 GMT
Date: Wed, 25 Jan 2006 16:53:52 +0000
From: Tim Chown 
To: ietfietforg 
Message-ID: <20060125165351.GI24549@login.ecs.soton.ac.uk>
Mail-Followup-To: ietfietforg 
References: 
	<41F3E06C-B157-4B0B-AB75-03CBA7777EB8@mit.edu>
	<01LY4YXNERSQ00009C@mauve.mrochek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01LY4YXNERSQ00009C@mauve.mrochek.com>
User-Agent: Mutt/1.4i
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner: Found to be clean
X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Tue, Jan 24, 2006 at 08:45:51AM -0800, Ned Freed wrote:
> >Are there cards with Mac OS X drivers nowadays?
> 
> Yes there are. Here's the one I use:
> 
>   http://www.orangeware.com/endusers/wirelessformac.html
> 
> There's a fairly long list of supported cards, some of which support 
> 802.11a.
> I'm currently using a 3COM 3CRWE154A72 card, FWIW.

Away from the technobabble...

A key finding is that only 7% have to pay their own way to the IETF,
some of whom may have their own companies.

And only 7% say that the $50US fee hike might stop them attending again.

With so many people unhappy with wireless, these stats add up to charging
more for better wireless....

The weird stat was 7% for whom $50US extra means they have to file
paperwork to get the money (just eat less? :)

-- 
Tim/::1



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 12:04:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1o4Y-0000Xo-2Q; Wed, 25 Jan 2006 12:04:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1o4V-0000XL-B1
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 12:04:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01218
	for ; Wed, 25 Jan 2006 12:03:08 -0500 (EST)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]
	helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F1oEE-0000Jz-Rs
	for ietf@ietf.org; Wed, 25 Jan 2006 12:14:46 -0500
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com
	[47.129.230.99])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k0PH49x05878; Wed, 25 Jan 2006 12:04:09 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Jan 2006 12:03:36 -0500
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5051A8581@zcarhxm2.corp.nortel.com>
Thread-Topic: Meeting Survey Results
Thread-Index: AcYhrHxKuwS9HI2fEdqeyAANky3PwAAI8CvQ
From: "Ed Juskevicius" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> I also learn from a previous email the reasons why b/g are not=20
> so good in our meeting, and may be thru our liaison with IEEE
> we need to make some noise over there, so the market use a
> better technology.

>From the perspective of RF attenuation (and signals not going through
air walls in hotels), 802.11a is actually a better technology.  The
spectrum used is at a higher frequency, and the standard includes more
channels which can be used to deploy a WLAN in tight quarters (like an
IETF meeting).

If making noise would help, I think petitioning Apple to include 802.11a
in their machines would be more effective in the market than asking
IEEE802 to develop yet another WLAN standard (imho).  However, I agree
with your observation that using 802.11a may not be a choice for a lot
of people in Dallas, at IETF 65.=20

Regards,

Ed J.

-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
JORDI PALET MARTINEZ
Sent: Wednesday, January 25, 2006 7:40 AM
To: ietf@ietf.org
Subject: Re: Meeting Survey Results


Hi David,

Don't want to start a new useless thread here, my point was basically to
show that b/g has a wider adoption and 75% of the laptops don't have
built-in a, so it makes sense to make additional effort to get it
working.

I also learn from a previous email the reasons why b/g are not so good
in our meeting, and may be thru our liaison with IEEE we need to make
some noise over there, so the market use a better technology.

I also got some folks confirming that a cards where available also in
previous meetings, but probably that was not properly advertised, may be
?

Regards,
Jordi




> De: David Kessens 
> Responder a: 
> Fecha: Tue, 24 Jan 2006 20:38:51 -0800
> Para: JORDI PALET MARTINEZ 
> CC: "ietf@ietf.org" 
> Asunto: Re: Meeting Survey Results
>=20
>=20
> Jordi,
>=20
> On Tue, Jan 24, 2006 at 02:44:15PM -0400, JORDI PALET MARTINEZ wrote:
>>=20
>> I'm not sure if I got it. My MUST was on the other way around: We=20
>> really need to warrantee good coverage for b/g to 75% of the=20
>> participants.
>=20
> We hope to offer good connectivity to the other 25% of the=20
> participants as well.
>=20
> You can help us by bringing a configured 802.11a card.
>=20
> David Kessens
> ---
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 12:45:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1oi1-0003Of-A9; Wed, 25 Jan 2006 12:45:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ohz-0003Oa-TF
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 12:45:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04816
	for ; Wed, 25 Jan 2006 12:43:56 -0500 (EST)
Received: from tom.iecc.com ([208.31.42.38])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1orj-0001u8-PR
	for ietf@ietf.org; Wed, 25 Jan 2006 12:55:35 -0500
Received: (qmail 813 invoked from network); 25 Jan 2006 17:45:10 -0000
Received: (ofmipd 208.31.42.47); 25 Jan 2006 17:44:48 -0000
Date: 25 Jan 2006 12:45:11 -0500
Message-ID: <20060125124316.C92532@simone.iecc.com>
From: "John L" 
To: ietf@ietf.org
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Subject: help help, I'm trapped on the bofchairs list
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

which has been discovered by spammers and has no apparent filtering.

To whom should I appeal to ask that it have the usual members-only posting 
rules or something else to keep out the junk?

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

PS: I realize that if I were a truly virtuous person I would just delete 
the noise, but I am not.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 12:59:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1ovC-0000U0-0J; Wed, 25 Jan 2006 12:59:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ov9-0000Ts-Gb
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 12:59:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06117
	for ; Wed, 25 Jan 2006 12:57:32 -0500 (EST)
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1p4t-0002SR-Dw
	for ietf@ietf.org; Wed, 25 Jan 2006 13:09:10 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 84472FB27D;
	Wed, 25 Jan 2006 12:58:41 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id A487B3BFDE2;
	Wed, 25 Jan 2006 12:58:40 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: David Kessens 
In-Reply-To: (Your message of "Tue, 24 Jan 2006 20:38:51 PST.")
	<20060125043851.GE16303@nokia.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 25 Jan 2006 12:58:40 -0500
Message-Id: <20060125175840.A487B3BFDE2@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: "ietf@ietf.org" ,
	JORDI PALET MARTINEZ 
Subject: Re: Meeting Survey Results 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In message <20060125043851.GE16303@nokia.com>, David Kessens writes:
>
>Jordi,
>
>On Tue, Jan 24, 2006 at 02:44:15PM -0400, JORDI PALET MARTINEZ wrote:
>> 
>> I'm not sure if I got it. My MUST was on the other way around: We really
>> need to warrantee good coverage for b/g to 75% of the participants.
>
>We hope to offer good connectivity to the other 25% of the participants as well.
>
>You can help us by bringing a configured 802.11a card.
>

How much of the benefit of 801.11a is because so few people are using 
it?  Would it hold up if everyone switched to it?

Yes, there are more frequencies and less congestion.  Is that enough?

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 13:20:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1pGB-0003W0-E0; Wed, 25 Jan 2006 13:20:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1pG9-0003VV-2l
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 13:20:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09760
	for ; Wed, 25 Jan 2006 13:19:12 -0500 (EST)
Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1pPt-0003xR-Fw
	for ietf@ietf.org; Wed, 25 Jan 2006 13:30:51 -0500
Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil
	via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP;
	Wed, 25 Jan 2006 18:20:38 +0000
Received: (private information removed)
Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil
	via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP;
	Wed, 25 Jan 2006 18:20:36 +0000
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Jan 2006 12:20:23 -0600
Message-ID: <1929B8C5B318524495727D8A241DAFB2034C9D61@NAEAMILLEX03VA.nadsusea.nads.navy.mil>
Thread-Topic: Meeting Survey Results 
Thread-Index: AcYh2lo0+Lu9SRo1QHi3wJkNIRmDUgAARXcA
From: "Odonoghue, Karen F CIV B35-Branch" 
To: "Steven M. Bellovin" ,
	"David Kessens" 
X-OriginalArrivalTime: 25 Jan 2006 18:20:27.0301 (UTC)
	FILETIME=[0429D550:01C621DC]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org, JORDI PALET MARTINEZ 
Subject: RE: Meeting Survey Results 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Well, in theory, 802.11a should scale better because of the
shorter range and the additional non-overlapping channels.
Now, I'm not guaranteeing that there won't be other issues we
haven't identified. We haven't had the density on 11a yet to
find the problems we don't know about.  What we do know is that
thus far folks using 11a on IETF networks have been happier than
folks using 11b.

Karen

> How much of the benefit of 801.11a is because so few people are using=20
> it?  Would it hold up if everyone switched to it?
>=20
> Yes, there are more frequencies and less congestion.  Is that enough?
>=20
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>=20
>=20
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 13:30:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1pPl-000705-Vm; Wed, 25 Jan 2006 13:30:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1pPj-0006zx-OO
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 13:30:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10586
	for ; Wed, 25 Jan 2006 13:29:08 -0500 (EST)
Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1pZW-0004Kj-59
	for ietf@ietf.org; Wed, 25 Jan 2006 13:40:47 -0500
Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil
	via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP;
	Wed, 25 Jan 2006 18:30:37 +0000
Received: (private information removed)
Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil
	via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP;
	Wed, 25 Jan 2006 18:30:35 +0000
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Jan 2006 12:30:32 -0600
Message-ID: <1929B8C5B318524495727D8A241DAFB2034C9D64@NAEAMILLEX03VA.nadsusea.nads.navy.mil>
Thread-Topic: Meeting Survey Results
Thread-Index: AcYhrHxKuwS9HI2fEdqeyAANky3PwAAG3LLg
From: "Odonoghue, Karen F CIV B35-Branch" 
To: , 
X-OriginalArrivalTime: 25 Jan 2006 18:30:33.0117 (UTC)
	FILETIME=[6D4204D0:01C621DD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: RE: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jordi,

> Don't want to start a new useless thread here, my point was=20
> basically to
> show that b/g has a wider adoption and 75% of the laptops don't have
> built-in a, so it makes sense to make additional effort to=20
> get it working.

My basic problem with this and previous comments on this topic=20
from you is the implication that with better planning and/or=20
additional effort the problems would be solved. If you believe=20
this to be so, then please share that technical knowledge. I have=20
been involved in most of the IETF wireless networks for the last=20
three years. We don't plan in advance to deploy wireless networks=20
with issues. Some of what I consider the best in the business have
worked on this over the years, and we still run into issues.=20
Concrete technical suggestions for improvements and contributions=20
of resources (equipment and people) are welcome. Just telling us
to put forth "additional effort to get it working" doesn't get=20
the job done.

Karen


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 13:38:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1pX2-00015f-FT; Wed, 25 Jan 2006 13:38:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1pWz-00012m-Oe
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 13:38:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11462
	for ; Wed, 25 Jan 2006 13:36:38 -0500 (EST)
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1pgk-0004iy-DP
	for ietf@ietf.org; Wed, 25 Jan 2006 13:48:17 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id D627EFB289;
	Wed, 25 Jan 2006 13:38:04 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by berkshire.machshav.com (Postfix) with ESMTP id EB8953BFDE2;
	Wed, 25 Jan 2006 13:38:03 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" 
To: "Odonoghue, Karen F CIV B35-Branch" 
In-Reply-To: (Your message of "Wed, 25 Jan 2006 12:20:23 CST.")
	<1929B8C5B318524495727D8A241DAFB2034C9D61@NAEAMILLEX03VA.nadsusea.nads.navy.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 25 Jan 2006 13:38:03 -0500
Message-Id: <20060125183803.EB8953BFDE2@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: David Kessens , ietf@ietf.org,
	JORDI PALET MARTINEZ 
Subject: Re: Meeting Survey Results 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In message <1929B8C5B318524495727D8A241DAFB2034C9D61@NAEAMILLEX03VA.nadsusea.na
ds.navy.mil>, "Odonoghue, Karen F CIV B35-Branch" writes:
>Well, in theory, 802.11a should scale better because of the
>shorter range and the additional non-overlapping channels.
>Now, I'm not guaranteeing that there won't be other issues we
>haven't identified. We haven't had the density on 11a yet to
>find the problems we don't know about.  What we do know is that
>thus far folks using 11a on IETF networks have been happier than
>folks using 11b.
>

Yup.  And the difference between theory and practice is that in theory, 
there is no difference, but in practice there is...

I agree with your observation -- 802.11a users are more satisfied with 
the network.  I made sure that I got an 802.11a-capable interface when 
I bought a new laptop.  But I'm reluctant to tell everyone to do that 
without more assurance that it will solve the problem.  We've heard 
lots of hypotheses over the years on what to do about 802.11b/g, 
including lower-power access points, more attention to channel 
assignment, and getting people to turn off ad hoc mode.  None of those 
have solved the problem.  Will switching to 802.11a?  Is there other 
prior art we need to look at?

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 13:53:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1pli-0007nF-U5; Wed, 25 Jan 2006 13:53:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1plg-0007mD-Oe
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 13:53:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12801
	for ; Wed, 25 Jan 2006 13:51:40 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1pvH-0005K6-Vy
	for ietf@ietf.org; Wed, 25 Jan 2006 14:03:19 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 13C272596C4;
	Wed, 25 Jan 2006 19:51:44 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 02507-02; Wed, 25 Jan 2006 19:51:40 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id C92EC2596AF;
	Wed, 25 Jan 2006 19:51:38 +0100 (CET)
Date: Wed, 25 Jan 2006 10:52:46 -0800
From: Harald Tveit Alvestrand 
To: "Odonoghue, Karen F CIV B35-Branch" ,
	"Steven M. Bellovin" ,
	David Kessens 
Message-ID: <4D23968A3008F9A354A8B0B2@207.47.24.220.rev.nextweb.net>
In-Reply-To: <1929B8C5B318524495727D8A241DAFB2034C9D61@NAEAMILLEX03VA.nadsusea.nads.navy.mil>
References: <1929B8C5B318524495727D8A241DAFB2034C9D61@NAEAMILLEX03VA.nadsuse
	a.nads.navy.mil>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: ietf@ietf.org, JORDI PALET MARTINEZ 
Subject: 802.11a (RE: Meeting Survey Results)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0061969875=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============0061969875==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========9428E29C0D7A9C79E4CA=========="

--==========9428E29C0D7A9C79E4CA==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[the dreaded subject-changer strikes again]

--On 25. januar 2006 12:20 -0600 "Odonoghue, Karen F CIV B35-Branch"=20
 wrote:

> Well, in theory, 802.11a should scale better because of the
> shorter range and the additional non-overlapping channels.
> Now, I'm not guaranteeing that there won't be other issues we
> haven't identified. We haven't had the density on 11a yet to
> find the problems we don't know about.  What we do know is that
> thus far folks using 11a on IETF networks have been happier than
> folks using 11b.

One thing I learned at the IEEE meeting the week following the IETF (where=20
the week started with EXACTLY the same problems as at the IETF) was that=20
the 802.11a specifications left out the "ad hoc mode".

So we're *guaranteed* that no conformant 802.11a card will go into "ad hoc=20
mode", because there ain't no such thing.

Yours for the removal of features....

                  Harald




--==========9428E29C0D7A9C79E4CA==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFD18j+OMj+2+WY0F4RAvFOAJ92qPB09h8xDi/wiGJQpLLnIYp2ggCdGX9w
70SNDbe/AgQoIhQbsGwaCJw=
=M1Zk
-----END PGP SIGNATURE-----

--==========9428E29C0D7A9C79E4CA==========--



--===============0061969875==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0061969875==--





From ietf-bounces@ietf.org Wed Jan 25 14:02:11 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1puF-0003qX-OW; Wed, 25 Jan 2006 14:02:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1puD-0003o7-QE
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 14:02:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13758
	for ; Wed, 25 Jan 2006 14:00:38 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1q40-0005id-Jx
	for ietf@ietf.org; Wed, 25 Jan 2006 14:12:18 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0PJ1rgx018959
	for ; Wed, 25 Jan 2006 14:01:53 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28424
	for ; Wed, 25 Jan 2006 14:01:52 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Wed, 25 Jan 2006 14:01:51 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C88638B@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'ietf@ietf.org'" 
Date: Wed, 25 Jan 2006 14:01:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Subject: RE: Free speech? Re: Against "PR-action against Jefsey Morfin"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Anthony,

	I actually feel that meeting summaries and - occasionally
surveys - can be a critical constructive part of the process.

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Anthony G. Atkielski
--> Sent: Tuesday, January 24, 2006 9:55 PM
--> To: ietf@ietf.org
--> Subject: Re: Free speech? Re: Against "PR-action against 
--> Jefsey Morfin"
--> 
--> grenville armitage writes:
--> 
--> > Must admit I always thought it was constructive speech 
--> (in the sense
--> > of attempting to engineer solutions, new architectures, 
--> protocols or
--> > clarity of understanding) that was at the core of 
--> discussions at IETF.
--> 
--> Then I suppose that threads such as "Meeting Survey Results," which
--> have nothing to do with these goals, are out of order?
--> 
--> Decisions as to what counts as "constructive" are 
--> subjective, unfortunately.
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 14:28:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1qJM-0006RC-Ld; Wed, 25 Jan 2006 14:28:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1qJI-0006Pr-92
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 14:28:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15753
	for ; Wed, 25 Jan 2006 14:26:32 -0500 (EST)
Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1qT5-0006dJ-Cm
	for ietf@ietf.org; Wed, 25 Jan 2006 14:38:12 -0500
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr
	[192.44.77.29])
	by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with
	ESMTP id k0PJRbl03059; Wed, 25 Jan 2006 20:27:37 +0100
Received: from givry.rennes.enst-bretagne.fr
	(localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id
	k0PJRbZY006537; Wed, 25 Jan 2006 20:27:38 +0100 (CET)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200601251927.k0PJRbZY006537@givry.rennes.enst-bretagne.fr>
From: Francis Dupont 
To: Tim Chown 
In-reply-to: Your message of Wed, 25 Jan 2006 16:53:52 GMT.
	<20060125165351.GI24549@login.ecs.soton.ac.uk> 
Date: Wed, 25 Jan 2006 20:27:37 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: ietfietforg 
Subject: Re: Meeting Survey Results 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

 In your previous mail you wrote:

   > There's a fairly long list of supported cards, some of which support 
   > 802.11a.

=> as I've currently a 12" PowerBook I'd like to find a "wordwide usable"
.11a USB dongle because:
 - the only time I used an .11a card it was great!
 - if enough persons are switching to .11a perhaps the .11b/g is
   becoming again usable.
   
Francis.Dupont@point6.net

PS: I need a local (Dallas) place to buy it too.
PPS: it seems the ZyXEL AG-225H is supported (there is a driver on
us.zyel.com for MacOS). Of course, it is not possible to get one in France.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 14:47:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1qcV-0006YE-1G; Wed, 25 Jan 2006 14:47:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1qcT-0006Xx-Fb
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 14:47:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18038
	for ; Wed, 25 Jan 2006 14:46:21 -0500 (EST)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1qmF-0007Z4-I9
	for ietf@ietf.org; Wed, 25 Jan 2006 14:58:02 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k0PJj0kx016461; Wed, 25 Jan 2006 21:45:03 +0200
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Jan 2006 21:46:37 +0200
Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by
	esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 25 Jan 2006 21:46:36 +0200
Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain
	[127.0.0.1])
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id
	k0PJkPK3024100; Wed, 25 Jan 2006 11:46:30 -0800
Received: (from kessens@localhost)
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id
	k0PJkOIR024098; Wed, 25 Jan 2006 11:46:24 -0800
Date: Wed, 25 Jan 2006 11:46:24 -0800
From: David Kessens 
To: "Steven M. Bellovin" 
Message-ID: <20060125194624.GA23879@nokia.com>
References: <1929B8C5B318524495727D8A241DAFB2034C9D61@NAEAMILLEX03VA.nadsusea.nads.navy.mil>
	<20060125183803.EB8953BFDE2@berkshire.machshav.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060125183803.EB8953BFDE2@berkshire.machshav.com>
User-Agent: Mutt/1.4.1i
X-OriginalArrivalTime: 25 Jan 2006 19:46:37.0050 (UTC)
	FILETIME=[0D92EDA0:01C621E8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: ietf@ietf.org
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Steve,

On Wed, Jan 25, 2006 at 01:38:03PM -0500, Steven M. Bellovin wrote:
> 
> I agree with your observation -- 802.11a users are more satisfied with 
> the network.  I made sure that I got an 802.11a-capable interface when 
> I bought a new laptop.  But I'm reluctant to tell everyone to do that 
> without more assurance that it will solve the problem.  We've heard 
> lots of hypotheses over the years on what to do about 802.11b/g, 
> including lower-power access points, more attention to channel 
> assignment, and getting people to turn off ad hoc mode.  None of those 
> have solved the problem.  Will switching to 802.11a?  Is there other 
> prior art we need to look at?

Theory and practical experience both indicate that 802.11a can give
you better performance in IETF settings.

And for the record, we are not talking about switching to 802.11a
(check out: http://www.ietf.org/meetings/notes_noc65.html). We are
advising people to bring a card/dongle that is capable of 802.11a to
take advantage of this better performing technology. At current prices
(it is not hard to find prices well below US$50), this seems a rather
small investment to make.

David Kessens
---

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 14:56:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1qks-0001e3-Ej; Wed, 25 Jan 2006 14:56:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1qkq-0001Yl-0A
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 14:56:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18818
	for ; Wed, 25 Jan 2006 14:55:00 -0500 (EST)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1qud-0007vH-ER
	for ietf@ietf.org; Wed, 25 Jan 2006 15:06:40 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k0PJuMqN011641; Wed, 25 Jan 2006 21:56:23 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 25 Jan 2006 21:55:37 +0200
Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by
	esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 25 Jan 2006 21:55:38 +0200
Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain
	[127.0.0.1])
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id
	k0PJtZK3024167; Wed, 25 Jan 2006 11:55:35 -0800
Received: (from kessens@localhost)
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id
	k0PJtZXY024165; Wed, 25 Jan 2006 11:55:35 -0800
Date: Wed, 25 Jan 2006 11:55:34 -0800
From: David Kessens 
To: Francis Dupont 
Message-ID: <20060125195534.GB23879@nokia.com>
References: <20060125165351.GI24549@login.ecs.soton.ac.uk>
	<200601251927.k0PJRbZY006537@givry.rennes.enst-bretagne.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200601251927.k0PJRbZY006537@givry.rennes.enst-bretagne.fr>
User-Agent: Mutt/1.4.1i
X-OriginalArrivalTime: 25 Jan 2006 19:55:38.0952 (UTC)
	FILETIME=[50929C80:01C621E9]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: Tim Chown , ietfietforg 
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Francis,

On Wed, Jan 25, 2006 at 08:27:37PM +0100, Francis Dupont wrote:
> 
> PS: I need a local (Dallas) place to buy it too.

www.frys.com
Fry's Electronics
12710 Executive Drive
Dallas, TX
(214) 342-5900

about 14 miles from the hotel. 

We will see whether we can post this information to the webpage and we
will check if there are more nearby stores.

Of course, Fry's tends to be well worth the drive even if there are
stores that are more nearby.

David Kessens
---

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 15:26:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1rDc-0005fe-51; Wed, 25 Jan 2006 15:26:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1rDa-0005fZ-1j
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 15:26:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20709
	for ; Wed, 25 Jan 2006 15:24:42 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1rNL-0000OH-RC
	for ietf@ietf.org; Wed, 25 Jan 2006 15:36:23 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-5.cisco.com with ESMTP; 25 Jan 2006 12:26:01 -0800
X-IronPort-AV: i="4.01,218,1136188800"; 
	d="scan'208"; a="251347764:sNHT32302868"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0PKQ0KT009597
	for ; Wed, 25 Jan 2006 12:26:00 -0800 (PST)
Received: from [171.71.193.105] (dhcp-171-71-193-105.cisco.com
	[171.71.193.105])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0PKUOw6002222
	for ; Wed, 25 Jan 2006 12:30:24 -0800
Message-ID: <43D7DEDE.3050803@cisco.com>
Date: Wed, 25 Jan 2006 12:26:06 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
	rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF Discussion 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=883; t=1138221024; x=1138653224;
	c=relaxed/simple; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20
	|Subject:=22too=20many=20notes=22=20--=20a=20modest=20proposal
	|To:IETF=20Discussion=20;
	X=v=3Dmtcc.com=3B=20h=3DAuPXJAV74SszR1Uf4KVdDDpCTt0=3D;
	b=BYKp335iugpxsErRErjmItvzhHk4OtzLLlUU8Mqr3IMNPz3d2HLyu0AAvf1UZV9Fgo1Qaq4E
	3yIrQ+iokuUshrggArDY9qfeyWOTekaKI8e+scyI6tiQLWmpA7GydStlUHEjKK5h1ZN8+e7zw5E
	iNIlpI8fcvHMX6+NkGP4niSk=;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Subject: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

It seems to me that a lot of what causes working group lists to
melt down is simply the volume of traffic -- usually with plenty
of off-topic banter, or exchanges of dubious value, with the resulting
conjestive collapse of our wetware buffering. On good days, the
drop algorithm may be more sophisticated than tail drops; on
bad days...

Perhaps we should take a lesson from TCP and set a receive window
on IETF mailing lists in the face of conjestion. The sender is thus
obligated to keep the transmission within the window, and as a side
effect to consider the quality of the, um, quantity. Just this simple
step would greatly limit (purposeful) DOS attacks and other death 
spirals. It also mitigates the "free speech" attacks by not throttling
based on content (which is inherently contentious), but based on
wg mailing list "bandwidth".

		in all modesty, Mike

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 16:11:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1rv3-0004u1-HC; Wed, 25 Jan 2006 16:11:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1rv1-0004ts-Up
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 16:11:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23747
	for ; Wed, 25 Jan 2006 16:09:35 -0500 (EST)
Received: from seahorse.shentel.net ([204.111.11.44])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1s4p-0001sS-UT
	for ietf@ietf.org; Wed, 25 Jan 2006 16:21:17 -0500
Received: from Steve ([204.111.101.203])
	by seahorse.shentel.net (8.12.11/8.12.11) with SMTP id k0PLAih1020178; 
	Wed, 25 Jan 2006 16:10:45 -0500
From: "Steve Silverman" 
To: "Michael Thomas" , "IETF Discussion" 
Date: Wed, 25 Jan 2006 16:12:06 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <43D7DEDE.3050803@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: 
Subject: RE: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

It seems to me that limiting users to 3 messages / day (perhaps with a
maximum number of bytes) would be a
minimal impact on free speech but would limit the damage done by
overly productive transmitters. This could be limited to users  who
are nominated to a "limit" list by many users.  How difficult this
would be to implement on the message exploders is another question.

Steve Silverman

> -----Original Message-----
> From: ietf-bounces@ietf.org
> [mailto:ietf-bounces@ietf.org]On Behalf Of
> Michael Thomas
> Sent: Wednesday, January 25, 2006 3:26 PM
> To: IETF Discussion
> Subject: "too many notes" -- a modest proposal
>
>
> It seems to me that a lot of what causes working group lists to
> melt down is simply the volume of traffic -- usually with plenty
> of off-topic banter, or exchanges of dubious value, with
> the resulting
> conjestive collapse of our wetware buffering. On good days, the
> drop algorithm may be more sophisticated than tail drops; on
> bad days...
>
> Perhaps we should take a lesson from TCP and set a receive window
> on IETF mailing lists in the face of conjestion. The sender is thus
> obligated to keep the transmission within the window, and as a side
> effect to consider the quality of the, um, quantity. Just
> this simple
> step would greatly limit (purposeful) DOS attacks and other death
> spirals. It also mitigates the "free speech" attacks by not
> throttling
> based on content (which is inherently contentious), but based on
> wg mailing list "bandwidth".
>
> 		in all modesty, Mike
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 16:32:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1sFe-0005YB-9D; Wed, 25 Jan 2006 16:32:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1sFb-0005Xy-Ma
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 16:32:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25071
	for ; Wed, 25 Jan 2006 16:30:51 -0500 (EST)
Received: from [69.30.42.70] (helo=smtp.elevennetworks.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1sPL-0002Vr-AE
	for ietf@ietf.org; Wed, 25 Jan 2006 16:42:33 -0500
Received: from [216.4.147.131] (helo=STJOHNS-LAPTOP2.mindspring.com)
	by smtp.elevennetworks.com with esmtp (Exim 4.44)
	id 1F1sF4-0003op-Os; Wed, 25 Jan 2006 13:31:52 -0800
Message-Id: <7.0.0.10.2.20060125122439.03a1c528@mindspring.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta)
Date: Wed, 25 Jan 2006 12:47:01 -0500
To: nick.staff@comcast.net, Frank Ellermann ,
	ietf@ietf.org
From: Michael StJohns 
In-Reply-To: <012520061157.15686.43D767B3000412D800003D46220588636000000
	E9B9CD2050C0702@comcast.net>
References: <012520061157.15686.43D767B3000412D800003D46220588636000000E9B9CD2050C0702@comcast.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.7 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: 
Subject: Re: Questions for those in favor of PR-Actions in general
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 06:57 AM 1/25/2006, nick.staff@comcast.net wrote:

>Claim:  The claim that all the good people will leave if the noise 
>level is too great and if stubborn people with limited technical 
>ability aren't banned.
>
>Question:  If that claim is accurate, then since there were no 
>PR-Actions for the first 20 years of the IETF one would have to 
>assume that all the good people left long ago (years and years) and 
>the ones left here now are the ones that drove the good engineers away?

Not exactly correct.   The first person was threatened with removal 
from the IETF list around 1990.  There have been other actions that 
didn't result in removals over the years - usually the threat was 
enough to resolve the issue.  In this case the consensus was to 
continue the particular discussion (amusingly enough the chair wanted 
to move certain discussions off the list unilaterally and I 
objected).  See the IETF archives around the middle of april 
1990.  Subject "mailing list policy" or "inanity".

Now the IETF environment of 1990 is quite different than the one 
today.  I'm fairly sure the discussion points I made then would 
change now because of that change in environment and even more 
because of the sheer amount of traffic on all the mailing lists to 
which I subscribe.






_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 16:47:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1sTw-0003Dj-Pp; Wed, 25 Jan 2006 16:47:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1sTu-0003Ck-Eo
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 16:47:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25994
	for ; Wed, 25 Jan 2006 16:45:38 -0500 (EST)
Received: from omr5.networksolutionsemail.com ([205.178.146.55]
	helo=mail.networksolutionsemail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1sdi-0002wf-8G
	for ietf@ietf.org; Wed, 25 Jan 2006 16:57:20 -0500
Received: (qmail 1293 invoked from network); 25 Jan 2006 21:46:45 -0000
Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237)
	by omr5.mgt.bos.netsol.com with SMTP; 25 Jan 2006 21:46:45 -0000
Message-ID: <43D7F1C5.9080602@andybierman.com>
Date: Wed, 25 Jan 2006 13:46:45 -0800
From: Andy Bierman 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Silverman 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: 7bit
Cc: Michael Thomas , IETF Discussion 
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Steve Silverman wrote:

>It seems to me that limiting users to 3 messages / day (perhaps with a
>maximum number of bytes) would be a
>minimal impact on free speech but would limit the damage done by
>overly productive transmitters. This could be limited to users  who
>are nominated to a "limit" list by many users.  How difficult this
>would be to implement on the message exploders is another question.
>
>  
>

I do not share your regulatory zeal.
As a WG Chair and WG participant, I have enough rules to follow already.
The last thing I want to do is count messages and bytes, and enforce
draconian rules like this.


>Steve Silverman
>  
>

Andy

>  
>
>>-----Original Message-----
>>From: ietf-bounces@ietf.org
>>[mailto:ietf-bounces@ietf.org]On Behalf Of
>>Michael Thomas
>>Sent: Wednesday, January 25, 2006 3:26 PM
>>To: IETF Discussion
>>Subject: "too many notes" -- a modest proposal
>>
>>
>>It seems to me that a lot of what causes working group lists to
>>melt down is simply the volume of traffic -- usually with plenty
>>of off-topic banter, or exchanges of dubious value, with
>>the resulting
>>conjestive collapse of our wetware buffering. On good days, the
>>drop algorithm may be more sophisticated than tail drops; on
>>bad days...
>>
>>Perhaps we should take a lesson from TCP and set a receive window
>>on IETF mailing lists in the face of conjestion. The sender is thus
>>obligated to keep the transmission within the window, and as a side
>>effect to consider the quality of the, um, quantity. Just
>>this simple
>>step would greatly limit (purposeful) DOS attacks and other death
>>spirals. It also mitigates the "free speech" attacks by not
>>throttling
>>based on content (which is inherently contentious), but based on
>>wg mailing list "bandwidth".
>>
>>		in all modesty, Mike
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf
>>
>>    
>>
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>
>
>  
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 16:53:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1sZn-0004R2-CI; Wed, 25 Jan 2006 16:53:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1sZl-0004Qx-Oo
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 16:53:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26315
	for ; Wed, 25 Jan 2006 16:51:41 -0500 (EST)
Received: from relay00.pair.com ([209.68.5.9])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1sja-00038B-A3
	for ietf@ietf.org; Wed, 25 Jan 2006 17:03:23 -0500
Received: (qmail 74955 invoked by uid 0); 25 Jan 2006 21:52:56 -0000
Received: from unknown (HELO l-w865gbf-ws) (unknown)
	by unknown with SMTP; 25 Jan 2006 21:52:56 -0000
X-pair-Authenticated: 64.32.194.73
From: Scott Kitterman 
To: ietf@ietf.org
Date: Wed, 25 Jan 2006 16:52:55 -0500
User-Agent: KMail/1.7
References: 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200601251652.55805.scott@kitterman.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 01/25/2006 16:12, Steve Silverman wrote:
> It seems to me that limiting users to 3 messages / day (perhaps with a
> maximum number of bytes) would be a
> minimal impact on free speech but would limit the damage done by
> overly productive transmitters. This could be limited to users  who
> are nominated to a "limit" list by many users.  How difficult this
> would be to implement on the message exploders is another question.
>
> Steve Silverman
>
This rule was in place during MARID, although there were no technical 
restrictions, just reminders from the chairs.

It seemed to me at the time that the rule had the least effect on those that 
needed it most (myself included at times).

Scott Kitterman

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 16:58:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1seY-00078M-6t; Wed, 25 Jan 2006 16:58:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1seU-00077s-RV
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 16:58:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26762
	for ; Wed, 25 Jan 2006 16:56:34 -0500 (EST)
Received: from purgatory.unfix.org ([213.136.24.43])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1soH-0003Jl-QQ
	for ietf@ietf.org; Wed, 25 Jan 2006 17:08:16 -0500
Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org
	[IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP id 3AF6D7F45;
	Wed, 25 Jan 2006 22:57:33 +0100 (CET)
Message-ID: <43D7F42C.7070001@unfix.org>
Date: Wed, 25 Jan 2006 22:57:00 +0100
From: Jeroen Massar 
Organization: Unfix
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: ietf@ietf.org, Rob Austein 
References: <20060120185257.GE18960@ccil.org>	<1797258665.20060123163611@atkielski.com>		<0728557.20060124163321@atkielski.com>	<43D683FA.8050502@unfix.org>
	<43D6871B.8040601@IntelliCal.net>
In-Reply-To: <43D6871B.8040601@IntelliCal.net>
X-Enigmail-Version: 0.94.0.0
OpenPGP: id=333E7C23;
	url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Cc: Harald Tveit Alvestrand ,
	"Darryl \(Dassa\) Lynch" , Doug Royer 
Subject: Re: "too many notes" -- a modest proposal & Re: Proposal for keeping
 "free speech" but limitting the nuisance to the working group (Was: John
 Cowan supports 3683 PR-action against Jefsey Morfin)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0219391326=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0219391326==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigADD16B3DD902FD575952DA94"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigADD16B3DD902FD575952DA94
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

[aggregated message, the from's are in the cc, Rob see first reply]

Top-PS: Did folks see and read the following:
http://www.ietf.org/internet-drafts/draft-hartman-mailinglist-experiment-=
00.txt


Michael Thomas wrote:
[..]
> Perhaps we should take a lesson from TCP and set a receive window
> on IETF mailing lists in the face of conjestion. The sender is thus
> obligated to keep the transmission within the window, and as a side
> effect to consider the quality of the, um, quantity. Just this simple
> step would greatly limit (purposeful) DOS attacks and other death
> spirals. It also mitigates the "free speech" attacks by not throttling
> based on content (which is inherently contentious), but based on
> wg mailing list "bandwidth".

A couple of mailinglists already have a form of this, eg for the ipv6
working group mailinglist, see:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg06123.html

This started somewhere around 18 Aug 2003 on request of the chairs.
ftp://playground.sun.com/pub/ipng/ipng-mail-archive/ipng.200308
Note that the list was then still hosted at SUN.

Afaik, since this was introduced, people did start posting with higher
content quality and lower quantity. Maybe Rob Austein can provide the
numbers in a nice graph or some other details?

Steve Silverman wrote:
> It seems to me that limiting users to 3 messages / day (perhaps with a
> maximum number of bytes) would be a
> minimal impact on free speech but would limit the damage done by
> overly productive transmitters. This could be limited to users  who
> are nominated to a "limit" list by many users.

Limiting to less than 3 per day would be the same as suspending for X
hours. Next to that it might also inhibit one from fixing a statement,
though of course one should re-read their post before posting.

> How difficult this
> would be to implement on the message exploders is another question.

Mailman is python and it should not be to difficult to add per-poster
counters, but this would also require that the secretariat applies those
patches and then hope that these changes are really working perfectly
well. A lot of testing would be required. Many people depend on the list
software, breaking it is not something that will be taken lightly ;)
Also avoiding such counters can be done easily by using multiple
subscriptions, but indeed that would be obvious.

Doug Royer wrote:
>=20
> Are you going to write mailing list software an provide it
> free of charge to implement all of this?

That already exists, it is called Mailman, which is what at least
@ietf.org uses and several of the lists not hosted here also.
Note the "X-Mailman-Version: 2.1.5" header in every post.

The existing lists are already there, just add an extra 'full' list,
subscribe the mainlist to the full list, which is quite normal with
umbrella lists, and presto. Now when somebody gets suspended from the
mainlist, the WG Chair can then ask the listadmin to move the
subscription of the to be suspended person from the mainlist to the
alternate list. Thus add on full, remove from main.

The technical part is the very easy part here. It is politics and maybe
more over ethnics and some other factors which are the hard parts.


Harald Tveit Alvestrand wrote:
[..full/main list..]
> In fact this has been implemented at least once that I know of - on
> the DNSO GA mailing list. The "full" version had relatively few
> subscribers.

Only suspended folks or "suspended-lovers" (AmaViS style) would indeed
be interested in following it. To avoid this we could, at first setup
the full list to contain all the members of

The DNSO list also has a long 'rules of order' file:
http://www.dnso.org/dnso/notes/2000.GA-ga-rules-v0.4.html

> Another variant is the ietf-censored version of the IETF list that I
> ran for a while, but left to others when becoming IETF chair - google
> claims that
> 
> is a current page for it.

I guess the main problem with this list is that the WG Chair doesn't
have (much) influence on it. It is neither an official list. Also it is
not clear who has been censored or not, which indeed means censoring,
while IMHO we still want to allow people to voice their opinions and not
simply discard them. The naming 'censored' is thus quite correct for
this list but I that is also something that the IETF should steer clear
from with a wide angle.

Darryl (Dassa) Lynch wrote:
> 
>
> I was a subscriber to both of the DNSO GA mailing lists and I do think
> the experiment worked for the most part.

As the list isn't active any more it might be useful to get input from
the members of the list that where then participating. Of course from
both the "I want to be on the main" and "on the full" lists. Off-list
replies for 'counting' are welcome.

> I've seen this a few times [..] Anything that can be done to improve
> participation is a good thing.

Exactly my opinion.

> PS...I've known Jefsey online since those early DNSO and IDNO days
> and whilst I don't always agree with him I respect his right to
> opinions.  I haven't followed his postings to other lists but haven't
> seen anything here I object to with regard to posting rights.
> I wouldn't like to see a blanket ban placed on his postings so a
> "full" list experiment would be a preference for me.

I didn't follow the lists where the real trouble was caused, but from
the comments I read and the reasoning behind them though I would, with a
main/full construct, move him to the full list so that he can still
voice his opinions but without undermining the rest of the process as I
do have a big problem with the fact that my mailbox, even though nicely
sorted, is getting flooded by a lot of policy mails and repeated
arguments instead of technical items.

Greets,
 Jeroen


--------------enigADD16B3DD902FD575952DA94
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQFD1/QsKaooUjM+fCMRApREAKChUpLBF9de78p6RXDOMlptOloPlQCgt3S3
E4JIQAI3m95mSZjQ3QiyDqg=
=icqD
-----END PGP SIGNATURE-----

--------------enigADD16B3DD902FD575952DA94--


--===============0219391326==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0219391326==--




From ietf-bounces@ietf.org Wed Jan 25 17:15:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1svW-0006r4-Vn; Wed, 25 Jan 2006 17:15:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1svU-0006qq-3S
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 17:15:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28534
	for ; Wed, 25 Jan 2006 17:14:07 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1t5E-00043F-Qa
	for ietf@ietf.org; Wed, 25 Jan 2006 17:25:50 -0500
Received: from [150.189.240.96] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001585946.msg
	for ; Wed, 25 Jan 2006 23:17:34 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Wed, 25 Jan 2006 17:47:17 -0400
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: Meeting Survey Results
Thread-Index: AcYhrHxKuwS9HI2fEdqeyAANky3PwAAG3LLgAAw+drU=
In-Reply-To: <1929B8C5B318524495727D8A241DAFB2034C9D64@NAEAMILLEX03VA.nadsusea.nads.navy.mil>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060125:ietf@ietf.org::sUny0EVPv9ByPWl/:00002LyW
X-MDRemoteIP: 150.189.240.96
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Wed, 25 Jan 2006 23:17:38 +0100
X-MDAV-Processed: consulintel.es, Wed, 25 Jan 2006 23:17:39 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: quoted-printable
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Karen,

I understand your point, which somehow has been replied by some other
comments in the list such as:

- Is not so clear that this technology (a) will still work if all use it.
- We are asking to change to 75% of the attendees.
- 50USD may be a lot for some people.

Moreover, my comment comes basically from the perspective of understanding
that is a lack of information what it matters here. It may have been my own
ignorance regarding the theoretical advantages of a versus b/g, which make
me assume that it was just a question of more APs or something similar,
because my previous experience in b/g only networks, has always been good
except in IETF meetings. Of course, the number of people using it was not so
big.

Some times it may be better to have a more detailed explanation from the NOC
about why this decision is taken, instead of just providing the decision and
full stop. That probably could have avoided the complete thread (which was
very informative in any case, but may be not so much in other similar
situations).

Regards,
Jordi




> De: "Odonoghue, Karen F CIV B35-Branch" 
> Responder a: 
> Fecha: Wed, 25 Jan 2006 12:30:32 -0600
> Para: , 
> Conversaci=F3n: Meeting Survey Results
> Asunto: RE: Meeting Survey Results
>=20
> Jordi,
>=20
>> Don't want to start a new useless thread here, my point was
>> basically to
>> show that b/g has a wider adoption and 75% of the laptops don't have
>> built-in a, so it makes sense to make additional effort to
>> get it working.
>=20
> My basic problem with this and previous comments on this topic
> from you is the implication that with better planning and/or
> additional effort the problems would be solved. If you believe
> this to be so, then please share that technical knowledge. I have
> been involved in most of the IETF wireless networks for the last
> three years. We don't plan in advance to deploy wireless networks
> with issues. Some of what I consider the best in the business have
> worked on this over the years, and we still run into issues.
> Concrete technical suggestions for improvements and contributions
> of resources (equipment and people) are welcome. Just telling us
> to put forth "additional effort to get it working" doesn't get
> the job done.
>=20
> Karen
>=20
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 17:23:40 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1t3E-00015g-20; Wed, 25 Jan 2006 17:23:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1t3B-00015O-KQ
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 17:23:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29099
	for ; Wed, 25 Jan 2006 17:22:05 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1tD0-0004Jr-BS
	for ietf@ietf.org; Wed, 25 Jan 2006 17:33:47 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 5ADB62596C0;
	Wed, 25 Jan 2006 23:22:17 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 07479-09; Wed, 25 Jan 2006 23:22:12 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id ED59D2596BB;
	Wed, 25 Jan 2006 23:22:10 +0100 (CET)
Date: Wed, 25 Jan 2006 14:08:40 -0800
From: Harald Tveit Alvestrand 
To: Michael Thomas , IETF Discussion 
Message-ID: <64EA6FCA33E6A3F95FF4D4EF@B50854F0A9192E8EC6CDA126>
In-Reply-To: <43D7DEDE.3050803@cisco.com>
References: <43D7DEDE.3050803@cisco.com>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: 
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1188155692=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1188155692==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========DFEBE79E91D53C85A909=========="

--==========DFEBE79E91D53C85A909==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

We had a discussion on this back in May 2003, and I created a mailing list=20
for it called "ietf-moderation" - you can subscribe to the list by=20
http://eikenes.alvestrand.no/mailman/listinfo/ietf-moderation, or the usual =

-request spiel.

Total traffic seems to have been 3 messages in May and 9 messages in=20
December, so it would be a quick job to review.

The list's still available to continue the discussion.....

--On 25. januar 2006 12:26 -0800 Michael Thomas  wrote:

> It seems to me that a lot of what causes working group lists to
> melt down is simply the volume of traffic -- usually with plenty
> of off-topic banter, or exchanges of dubious value, with the resulting
> conjestive collapse of our wetware buffering. On good days, the
> drop algorithm may be more sophisticated than tail drops; on
> bad days...
>
> Perhaps we should take a lesson from TCP and set a receive window
> on IETF mailing lists in the face of conjestion. The sender is thus
> obligated to keep the transmission within the window, and as a side
> effect to consider the quality of the, um, quantity. Just this simple
> step would greatly limit (purposeful) DOS attacks and other death
> spirals. It also mitigates the "free speech" attacks by not throttling
> based on content (which is inherently contentious), but based on
> wg mailing list "bandwidth".
>
> 		in all modesty, Mike
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
>




--==========DFEBE79E91D53C85A909==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFD1/boOMj+2+WY0F4RAk09AKCK4n/wRDUWeRvcmkmHYl4BiaeWAwCgihk7
eTPQuGOpA6+7adx3CGPVt84=
=tHFb
-----END PGP SIGNATURE-----

--==========DFEBE79E91D53C85A909==========--



--===============1188155692==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1188155692==--





From ietf-bounces@ietf.org Wed Jan 25 18:15:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1trq-000837-CI; Wed, 25 Jan 2006 18:15:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1tro-00080h-1V
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 18:15:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02778
	for ; Wed, 25 Jan 2006 18:14:23 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1u1d-0005r6-4G
	for ietf@ietf.org; Wed, 25 Jan 2006 18:26:06 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [127.0.0.1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3826049; Wed, 25 Jan 2006 18:12:18 -0500
In-Reply-To: <20060125175840.A487B3BFDE2@berkshire.machshav.com>
References: <20060125175840.A487B3BFDE2@berkshire.machshav.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <666DDC6A-4B27-44FC-BD7C-04858670DEAC@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Wed, 25 Jan 2006 18:15:30 -0500
To: "Steven M. Bellovin" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: David Kessens , "ietf@ietf.org" ,
	JORDI PALET MARTINEZ 
Subject: Re: Meeting Survey Results 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 25, 2006, at 12:58 PM, Steven M. Bellovin wrote:

> In message <20060125043851.GE16303@nokia.com>, David Kessens writes:
>>
>> Jordi,
>>
>> On Tue, Jan 24, 2006 at 02:44:15PM -0400, JORDI PALET MARTINEZ wrote:
>>>
>>> I'm not sure if I got it. My MUST was on the other way around: We  
>>> really
>>> need to warrantee good coverage for b/g to 75% of the participants.
>>
>> We hope to offer good connectivity to the other 25% of the  
>> participants as well.
>>
>> You can help us by bringing a configured 802.11a card.
>>
>
> How much of the benefit of 801.11a is because so few people are using
> it?  Would it hold up if everyone switched to it?
>
> Yes, there are more frequencies and less congestion.  Is that enough?


I imagine we are about to find out.

Regards
Marshall

>
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 21:19:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1wjA-0005NG-Ni; Wed, 25 Jan 2006 21:19:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1wj1-0005K7-1N
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 21:19:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28014
	for ; Wed, 25 Jan 2006 21:17:31 -0500 (EST)
Received: from a.mail.sonic.net ([64.142.16.245])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1wsp-0007jM-8G
	for ietf@ietf.org; Wed, 25 Jan 2006 21:29:14 -0500
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG
	[168.61.10.151]) (authenticated bits=0)
	by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0Q2IjlD002624
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 25 Jan 2006 18:18:46 -0800
In-Reply-To: <64EA6FCA33E6A3F95FF4D4EF@B50854F0A9192E8EC6CDA126>
References: <43D7DEDE.3050803@cisco.com>
	<64EA6FCA33E6A3F95FF4D4EF@B50854F0A9192E8EC6CDA126>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Douglas Otis 
Date: Wed, 25 Jan 2006 18:18:55 -0800
To: Harald Tveit Alvestrand 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: Michael Thomas , IETF Discussion 
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Jan 25, 2006, at 2:08 PM, Harald Tveit Alvestrand wrote:

> We had a discussion on this back in May 2003, and I created a  
> mailing list for it called "ietf-moderation" - you can subscribe to  
> the list by http://eikenes.alvestrand.no/mailman/listinfo/ietf- 
> moderation, or the usual -request spiel.
>
> Total traffic seems to have been 3 messages in May and 9 messages  
> in December, so it would be a quick job to review.
>
> The list's still available to continue the discussion.....
>

I suspect that at the moment, I am the guilty party in consuming  
bandwidth on the DKIM list.  With the aggressive schedule, the  
immediate desire was to get issues listed, corrected, and in a form  
found acceptable.  I initially attempted to bundle these issues and  
was requested to make separate posts.  Each of these posts then  
resulted in an exchange of two or three subsequent exchanges offering  
corrections and guidance, with follow-on.  I don't expect this to  
continue, and my apologies if this has created any difficulty.  I  
will make an effort to slow down.

-Doug

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 22:03:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1xQP-0001Ws-M5; Wed, 25 Jan 2006 22:03:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1xQL-0001Va-Ij
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 22:03:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01463
	for ; Wed, 25 Jan 2006 22:02:17 -0500 (EST)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1xaC-0000s0-K0
	for ietf@ietf.org; Wed, 25 Jan 2006 22:14:02 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k0Q33d98016655; Thu, 26 Jan 2006 05:03:43 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Jan 2006 05:03:05 +0200
Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by
	esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 26 Jan 2006 05:03:03 +0200
Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain
	[127.0.0.1])
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id
	k0Q332K3026449; Wed, 25 Jan 2006 19:03:02 -0800
Received: (from kessens@localhost)
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id
	k0Q331bF026447; Wed, 25 Jan 2006 19:03:01 -0800
Date: Wed, 25 Jan 2006 19:03:01 -0800
From: David Kessens 
To: JORDI PALET MARTINEZ 
Message-ID: <20060126030301.GA26268@nokia.com>
References: <1929B8C5B318524495727D8A241DAFB2034C9D64@NAEAMILLEX03VA.nadsusea.nads.navy.mil>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.1i
X-OriginalArrivalTime: 26 Jan 2006 03:03:04.0320 (UTC)
	FILETIME=[06673800:01C62225]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: "ietf@ietf.org" 
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Jordi,

On Wed, Jan 25, 2006 at 05:47:17PM -0400, JORDI PALET MARTINEZ wrote:
> 
> I understand your point, which somehow has been replied by some other
> comments in the list such as:
> 
> - Is not so clear that this technology (a) will still work if all use it.
> - We are asking to change to 75% of the attendees.

I don't understand why you keep harping on this issue that only exists
because you have misread our announcement.

We have been very forthcoming and clear why we like people to bring
802.11a cards.

We are not forcing anybody to use 802.11a and there is absolutely no
talk of not providing 802.11b wireless access. We *RECOMMEND* that
people bring and use 802.11a gear because we believe that *EVERYBODY*,
including people who only have 802.11b cards, will have a better
network experience.

The only thing that we should have mentioned, but that we overlooked
as most cards/dongles on the market now do 802.11a,b&g, is that we
don't recommend to leave your 802.11b equipment at home. The hotel is
very large and there will be areas in the fringes that will have
better 802.11b coverage or that are only covered by the hotels own
802.11b service.

> - 50USD may be a lot for some people.

You can easily get cards *LESS* than US$50. It is your judgement call
whether you believe that this investment is worth it. Don't buy a
802.11a card/dongle if you think it is too much. Nobody forces you to
buy one.

David Kessens
---

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 23:02:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1yKm-0000v2-1s; Wed, 25 Jan 2006 23:02:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1yKj-0000sb-UJ
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 23:02:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05829
	for ; Wed, 25 Jan 2006 23:00:33 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1yUZ-0002rb-Br
	for ietf@ietf.org; Wed, 25 Jan 2006 23:12:18 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0Q41ko8093585
	for ; Thu, 26 Jan 2006 05:01:46 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 05:01:46 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1409670234.20060126050146@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D7DEDE.3050803@cisco.com>
References: <43D7DEDE.3050803@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Michael Thomas writes:

> Perhaps we should take a lesson from TCP and set a receive window
> on IETF mailing lists in the face of conjestion. The sender is thus
> obligated to keep the transmission within the window, and as a side
> effect to consider the quality of the, um, quantity. Just this simple
> step would greatly limit (purposeful) DOS attacks and other death 
> spirals. It also mitigates the "free speech" attacks by not throttling
> based on content (which is inherently contentious), but based on
> wg mailing list "bandwidth".

Sounds fine to me ... but I know it would never fly.  Some people
consider themselves "more equal than others" and would object as soon
as their "important" posts were rejected, no matter how much traffic
they were generating.  And they'd point to the occasional posters and
insist that their infrequent posts were far less worthy of inclusion
on the list.  And so on.  In other words, it would be fair, but
fairness is not what most people want.  They want total freedom for
themselves, but heavy restrictions for everyone else.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 23:05:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1yNh-0002wz-UZ; Wed, 25 Jan 2006 23:05:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1yMq-0002ZO-RY
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 23:04:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05957
	for ; Wed, 25 Jan 2006 23:02:44 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1yWg-0002vz-Vj
	for ietf@ietf.org; Wed, 25 Jan 2006 23:14:29 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0Q443mq093597
	for ; Thu, 26 Jan 2006 05:04:03 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 05:04:03 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <139696328.20060126050403@atkielski.com>
To: ietf@ietf.org
In-Reply-To: 
References: <43D7DEDE.3050803@cisco.com>
	
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Steve Silverman writes:

> It seems to me that limiting users to 3 messages / day (perhaps with
> a maximum number of bytes) would be a minimal impact on free speech
> but would limit the damage done by overly productive transmitters.
> This could be limited to users who are nominated to a "limit" list
> by many users.

Bzzzt!  No, that ruins the whole idea.  It's just censorship by
another name.

If three messages is enough for responsible contributions by one
person, it's enough for responsible contributions from anyone.  If
it's not, then the limit must be higher.  But the limit has to be the
same for everyone.

As I've already said, this idea is too fair to work.  Nobody wants
fairness; most people want total freedom for themselves and severe
restrictions on everyone else--censorship, in other words.  A limit
that everyone would be forced to respect would be rejected by the very
same people who cry out for limits.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 23:05:11 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1yNj-0002zy-OP; Wed, 25 Jan 2006 23:05:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1yNT-0002m8-65
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 23:04:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06017
	for ; Wed, 25 Jan 2006 23:03:22 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1yXK-0002xp-Ak
	for ietf@ietf.org; Wed, 25 Jan 2006 23:15:07 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0Q44iuC093605
	for ; Thu, 26 Jan 2006 05:04:44 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 05:04:44 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1965741720.20060126050444@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <7.0.0.10.2.20060125122439.03a1c528@mindspring.com>
References: <012520061157.15686.43D767B3000412D800003D46220588636000000E9B9CD2050C0702@comcast.net>
	<7.0.0.10.2.20060125122439.03a1c528@mindspring.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Content-Transfer-Encoding: 7bit
Subject: Re: Questions for those in favor of PR-Actions in general
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Michael StJohns writes:

> Now the IETF environment of 1990 is quite different than the one
> today.

How?  And why?


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 23:06:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1yOv-0003KG-DW; Wed, 25 Jan 2006 23:06:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1yOs-0003JY-IA
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 23:06:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06139
	for ; Wed, 25 Jan 2006 23:04:50 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1yYl-00031Q-1W
	for ietf@ietf.org; Wed, 25 Jan 2006 23:16:35 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0Q46BOs093615
	for ; Thu, 26 Jan 2006 05:06:11 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 05:06:11 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1182823182.20060126050611@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D7F1C5.9080602@andybierman.com>
References: 
	<43D7F1C5.9080602@andybierman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Andy Bierman writes:

> I do not share your regulatory zeal.
> As a WG Chair and WG participant, I have enough rules to follow already.
> The last thing I want to do is count messages and bytes, and enforce
> draconian rules like this.

But counting messages and bytes happens to be something that can be
easily automated, and it can be applied with absolute consistency to
everyone, without prejudice.  Of course, those are exactly the reasons
why many people would reject the idea--they want to keep other people
from posting, but they also fear being prevented from posting
themselves.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 23:10:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1ySq-00052D-NM; Wed, 25 Jan 2006 23:10:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ySn-00051O-De
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 23:10:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06457
	for ; Wed, 25 Jan 2006 23:08:53 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1ycd-0003Aq-2h
	for ietf@ietf.org; Wed, 25 Jan 2006 23:20:38 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0Q4ACMX093647
	for ; Thu, 26 Jan 2006 05:10:12 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 05:10:12 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <374441416.20060126051012@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D7F42C.7070001@unfix.org>
References: <20060120185257.GE18960@ccil.org>
	<1797258665.20060123163611@atkielski.com>
	
	<0728557.20060124163321@atkielski.com> <43D683FA.8050502@unfix.org>
	<43D6871B.8040601@IntelliCal.net> <43D7F42C.7070001@unfix.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal & Re: Proposal for
	keeping "free speech" but limitting the nuisance to the
	working group (Was: John Cowan supports 3683 PR-action
	against Jefsey Morfin)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jeroen Massar writes:

> Limiting to less than 3 per day would be the same as suspending for X
> hours.

They would both be the same only if they were carried out in the same
way.

If either method is applied to specific users, it's still just
arbitrary censorship.  If it is applied equally to everyone by a
robot, then it's fair.

> Next to that it might also inhibit one from fixing a statement,
> though of course one should re-read their post before posting.

Life is tough.  As long as the same restrictions apply to _everyone_,
no problem.

> Mailman is python and it should not be to difficult to add per-poster
> counters, but this would also require that the secretariat applies those
> patches and then hope that these changes are really working perfectly
> well. A lot of testing would be required. Many people depend on the list
> software, breaking it is not something that will be taken lightly ;)
> Also avoiding such counters can be done easily by using multiple
> subscriptions, but indeed that would be obvious.

Excuses, excuses.  The urge to manually and subjectively _censor_ is
irresistibly strong, is it not?


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Wed Jan 25 23:53:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1z87-0007QN-0k; Wed, 25 Jan 2006 23:53:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1z84-0007Q2-1u
	for ietf@megatron.ietf.org; Wed, 25 Jan 2006 23:53:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09182
	for ; Wed, 25 Jan 2006 23:51:31 -0500 (EST)
Received: from omr6.networksolutionsemail.com ([205.178.146.56]
	helo=mail.networksolutionsemail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F1zHw-0004Xk-3N
	for ietf@ietf.org; Thu, 26 Jan 2006 00:03:17 -0500
Received: (qmail 7744 invoked from network); 26 Jan 2006 04:52:53 -0000
Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237)
	by omr6.mgt.bos.netsol.com with SMTP; 26 Jan 2006 04:52:53 -0000
Message-ID: <43D855A4.7080007@andybierman.com>
Date: Wed, 25 Jan 2006 20:52:52 -0800
From: Andy Bierman 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: 	<43D7F1C5.9080602@andybierman.com>
	<1182823182.20060126050611@atkielski.com>
In-Reply-To: <1182823182.20060126050611@atkielski.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Anthony G. Atkielski wrote:

>Andy Bierman writes:
>
>  
>
>>I do not share your regulatory zeal.
>>As a WG Chair and WG participant, I have enough rules to follow already.
>>The last thing I want to do is count messages and bytes, and enforce
>>draconian rules like this.
>>    
>>
>
>But counting messages and bytes happens to be something that can be
>easily automated, and it can be applied with absolute consistency to
>everyone, without prejudice.  Of course, those are exactly the reasons
>why many people would reject the idea--they want to keep other people
>from posting, but they also fear being prevented from posting
>themselves.
>  
>

I think you missed my point.
I should have said "enforce or abide by draconian rules".
Automating the process is even worse.
Then stupid scripts disrupt WG activity on a regular basis.
Inappropriate mailing list use should be dealt with by the
WG Chair(s) in a more diplomatic manner. 


Andy

>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>
>
>  
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 00:22:40 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1zah-0003VQ-Vx; Thu, 26 Jan 2006 00:22:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1zaf-0003Tb-QU
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 00:22:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11191
	for ; Thu, 26 Jan 2006 00:21:04 -0500 (EST)
Received: from pop04.mail.atl.earthlink.net ([207.69.200.28])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1zkZ-0005VH-3h
	for ietf@ietf.org; Thu, 26 Jan 2006 00:32:51 -0500
Received: from mswamui-bichon.atl.sa.earthlink.net ([209.86.224.26])
	by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10)
	id 1F1zaa-0004Yf-00
	for ietf@ietf.org; Thu, 26 Jan 2006 00:22:32 -0500
Message-ID: <5559308.1138252952014.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
Date: Thu, 26 Jan 2006 12:22:32 +0700 (GMT+07:00)
From: Randy Presuhn 
To: ietf@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Subject: Re: Questions for those in favor of PR-Actions in general
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Randy Presuhn 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi -

>From: nick.staff@comcast.net
>Sent: Jan 25, 2006 6:57 PM
>To: Frank Ellermann , ietf@ietf.org
>Subject: Questions for those in favor of PR-Actions in general
...
>Claim:  The claim that all the good people will leave if the noise
>level is too great and if stubborn people with limited technical ability aren't banned.

A more accurate restatement is that some good people have
already left because participation in the IETF was sufficiently
unpleasant for them, and that other productive people are on the
verge of leaving for the same reason.

How much snake oil and vitriol one is willing to tolerate varies
with the individual and how much they're rewarded (in one
way or another) for spending time in this snake pit.

>Question:  If that claim is accurate, then since there were no PR-Actions
>for the first 20 years of the IETF one would have to assume that all
>the good people left long ago (years and years) and the ones left
>here now are the ones that drove the good engineers away?

I know first-hand of several very good engineers who have stopped
participating here, and have cited the level of nastiness as a key
motivating factor.   The question is of finding a balance between the
human need for civility, and our willingness to extract work from
the uncivil.

Randy

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 02:16:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F21Mj-0005bX-5M; Thu, 26 Jan 2006 02:16:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F21Mf-0005bP-Ga
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 02:16:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17906
	for ; Thu, 26 Jan 2006 02:14:46 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F21WZ-00008G-3h
	for ietf@ietf.org; Thu, 26 Jan 2006 02:26:32 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-4.cisco.com with ESMTP; 25 Jan 2006 23:16:06 -0800
X-IronPort-AV: i="4.01,220,1136188800"; 
	d="scan'208"; a="1770296759:sNHT30224084"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0Q7G4jt000667;
	Wed, 25 Jan 2006 23:16:04 -0800 (PST)
Received: from [212.254.247.4] (ams-clip-vpn-dhcp4254.cisco.com [10.61.80.157])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0Q7KP4p006019;
	Wed, 25 Jan 2006 23:20:26 -0800
Message-ID: <43D87732.2000205@cisco.com>
Date: Thu, 26 Jan 2006 08:16:02 +0100
From: Eliot Lear 
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Douglas Otis 
References: <43D7DEDE.3050803@cisco.com>	<64EA6FCA33E6A3F95FF4D4EF@B50854F0A9192E8EC6CDA126>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=365; t=1138260027; x=1138692227;
	c=relaxed/simple; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20
	|Subject:Re=3A=20=22too=20many=20notes=22=20--=20a=20modest=20proposal
	|To:Douglas=20Otis=20;
	X=v=3Dmtcc.com=3B=20h=3DXt2Nygp6FuTK+RlPz/GAMEexAP4=3D;
	b=Jk1z8ouzQbbDpMufylm6HWCLQXcDLSpI20Hy4/qrs0CAs0/TuC4z9D8ksIz4A/XWbSZkZtki
	y60AK9DlrI1q7srCj7/nV/FUJgHD8QiX4c1+94FFhkN2Qkm1GxuNzji4u3PKUIM93/lL7NbivcK
	iCMJGHkNqOG5EFW0MAkFYinE=;
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com;
	dkim=pass ( message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand ,
	Michael Thomas , IETF Discussion 
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Douglas Otis wrote:
> I suspect that at the moment, I am the guilty party in consuming
> bandwidth on the DKIM list.  With the aggressive schedule, the
> immediate desire was to get issues listed, corrected, and in a form
> found acceptable.  
Without going into all the reasons why here, I asked Doug to separate
out issues into separate messages.

Eliot

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 02:42:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F21lo-0006we-Mf; Thu, 26 Jan 2006 02:42:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F21lm-0006wO-8i; Thu, 26 Jan 2006 02:42:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19710;
	Thu, 26 Jan 2006 02:40:42 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F21vg-0000vr-2h; Thu, 26 Jan 2006 02:52:29 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F21la-0008Cr-Mo; Wed, 25 Jan 2006 23:42:03 -0800
Message-Id: <6.2.3.4.2.20060126071601.068e8af0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Thu, 26 Jan 2006 08:41:52 +0100
To: Randy Presuhn 
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <5559308.1138252952014.JavaMail.root@mswamui-bichon.atl.sa.
	earthlink.net>
References: <5559308.1138252952014.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-5E9D5BE1
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: ietf@ietf.org, IESG 
Subject: Re: Questions for those in favor of PR-Actions in general
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 06:22 26/01/2006, Randy Presuhn said:
>I know first-hand of several very good engineers who have stopped
>participating here, and have cited the level of nastiness as a key
>motivating factor.   The question is of finding a balance between the
>human need for civility, and our willingness to extract work from
>the uncivil.

Dear Randy,
good question. We all know many cases (I get mails from unknowns due 
to the PR-action). I think there is a structural response and two cases.

The structural response is that people are who they are. Internet 
Engineers are humanly no different from others. Those who cannot work 
with average others will probably not produce a good work in such a 
community. If you do not have the guts to affront the whole IETF, who 
will take your proposition for innovation seriously? It a sort of 
community quality control PR self-action. The only problem is when 
the one ready to face the wolfpack is technically loony, or out of 
phase with the IETF objectives. IAB appeal should address that issue, 
long before any PR action. I accept it is never nice for a seasoned 
expert to be barked at by a young puppy, or a stupid opponent. But, a 
good seasoned expert is a good seasoned expert because he learned to 
take benefit from everything. Also, it permits everyone to know if a 
debate is biased or personal, if the raised technical issues are 
discussed or not.

The two different cases depends on the real motivation and impact (of 
a person or of debate). Does it belongs to the IETF scope or not. 
This is still to the IAB to decide. In the case of the WG-ltru you 
have been embarked in one of the seldom IETF cases (IP addresses 
numbering plan, DNS root are the only two comparable, and less 
important, issues I can think of) where the world is concerned. All 
the more than in the two other cases, they concern Internet issues 
(IP and DNS). Here the matter concerns the humanity core (languages 
are its most important common property). You dealt with a major 
source of power and money: the control of the IANA registry of the 
text industries. Still more important to the mankind and economy than 
music, films and games. I think you should have initially asked the 
IAN guidance I have eventually asked.

In my case, one of thre reasons of this threat, the controlling group 
used it standard protection first: initial uncivility. This does not 
work with me. Also, a private control of the IANA language tag 
registry would kill my job. So, I survived them. What is most 
interesting is that people who had been nastily ejected asked me to 
represent them, or helped me. Also, that people who felt unsecure 
asked me to be their lighting rod. I reported I observed the same 
effect with the PR-action.

This being said, I agree that some working tools and procedures, a 
jury of honor, etc. would probably help the IETF. But this seem 
beyond reach due to its communitu hysteresis, and it might affect its 
time proven capacities.
jfc



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 03:02:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F224u-0005Uc-0l; Thu, 26 Jan 2006 03:02:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F224s-0005UU-9V; Thu, 26 Jan 2006 03:01:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20722;
	Thu, 26 Jan 2006 03:00:26 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F22Em-0001Ro-Bf; Thu, 26 Jan 2006 03:12:13 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F224p-0004SO-E8; Thu, 26 Jan 2006 00:01:55 -0800
Message-Id: <6.2.3.4.2.20060126085959.068e34a0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Thu, 26 Jan 2006 09:01:52 +0100
To: Randy Presuhn 
From: "JFC (Jefsey) Morfin" 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-5E9D5BE1
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: ietf@ietf.org, IESG 
Subject: typo of mine: Re: Questions for those in favor of PR-Actions
 in general
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Please obviously read:
"In my case, one of thre reasons of this thread", instead of "In my 
case, one of thre reasons of this threat".
Sorry.
jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 05:42:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F24a0-0001YH-Su; Thu, 26 Jan 2006 05:42:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F24Zy-0001Y7-C3
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 05:42:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02514
	for ; Thu, 26 Jan 2006 05:40:41 -0500 (EST)
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F24jt-0006ph-JL
	for ietf@ietf.org; Thu, 26 Jan 2006 05:52:31 -0500
Received: from venus.office (europa.netlab.nec.de [10.1.1.25])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 19B2723634;
	Thu, 26 Jan 2006 11:41:54 +0100 (CET)
Received: from n-eggert.office ([10.1.1.112]) by venus.office over TLS secured
	channel with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Jan 2006 11:41:53 +0100
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by n-eggert.office (Postfix) with ESMTP id 05F4667EF85;
	Thu, 26 Jan 2006 11:41:53 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v746.2)
To: IETF Discussion 
Message-Id: 
From: Lars Eggert 
Date: Thu, 26 Jan 2006 11:41:51 +0100
X-Mailer: Apple Mail (2.746.2)
X-OriginalArrivalTime: 26 Jan 2006 10:41:54.0018 (UTC)
	FILETIME=[1F61C420:01C62265]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: Martin Stiemerling 
Subject: getting the IETF rate at the Hilton
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0506433052=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0506433052==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-1051121928;
	protocol="application/pkcs7-signature"


--Apple-Mail-14-1051121928
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

Hi,

the Hilton reservation system doesn't offer the IETF rate when  
checking out on March 25 (or later) and instead charges $189 for all  
days. Can someone ask them to fix that?

(The Hilton site shows "65TH IETF MEETING GROUP DATES:  
03/16/06-03/25/06", so I assume the rate should be available until  
the 25th.)

Lars
--
Lars Eggert                                     NEC Network Laboratories


--Apple-Mail-14-1051121928
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw
ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE
EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN
AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv
AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK
xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF
DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ
vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C
AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l
dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS
vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2
usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu
mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT
G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl
ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa
LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud
HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs
Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf
qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa
9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G
CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy
ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT
FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq
hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw
NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx
EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO
ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI
hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT
wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z
9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY
LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD
VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy
ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz
MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0
QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9
3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR
piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB
KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1
aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDYwMTI2MTA0MTUyWjAjBgkqhkiG9w0BCQQxFgQU4ls/6G4dmAIIbjq72rOu
1GH1ZDwwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu
LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg
THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu
bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq
hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl
bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD
VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw
JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA
BIIBAJRQ7ZI7Ff6EP/goz09NFsI7CG87sEvbgXFVbgdJVv9QbC90vC0N22/bngpH1RUFWv1l7QU/
ZvzpmiV2hnhMu5SKLNSL1EtoWn+mALtx5YiS5ANWBGJDYB4AmNLT/XkKhzVAzG+JlKnTKyHuXUrr
PUcsjOV/mNW00l8Igp6RYJQsIndug6RPsgV6uZedFNLtUKaCJTMVavdF9OG3juognL7edpYq1c+q
HP9DTfrrqNCl0vhL1Z1B2Jfe9mDej9dHMoft4F08KJym+siisDOLfHP7SHnugtR6GTGaJGNUtmjI
3fGfRgMwMFhMAwc84avBMSRTPZJxyDF44EPYFD0PF+QAAAAAAAA=

--Apple-Mail-14-1051121928--


--===============0506433052==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0506433052==--




From ietf-bounces@ietf.org Thu Jan 26 07:05:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F25st-00038o-Pj; Thu, 26 Jan 2006 07:05:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F25sr-00038g-L2
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 07:05:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07598
	for ; Thu, 26 Jan 2006 07:04:16 -0500 (EST)
Received: from mtagate1.de.ibm.com ([195.212.29.150])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F262m-0000m4-78
	for ietf@ietf.org; Thu, 26 Jan 2006 07:16:04 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0QC5OOl188194
	for ; Thu, 26 Jan 2006 12:05:24 GMT
Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com
	[9.149.165.229])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0QC5NgV157004
	for ; Thu, 26 Jan 2006 13:05:23 +0100
Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0QC5Nvl024392 for ; Thu, 26 Jan 2006 13:05:23 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0QC5Me4024387; Thu, 26 Jan 2006 13:05:23 +0100
Received: from zurich.ibm.com (sig-9-146-218-145.de.ibm.com [9.146.218.145])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA70930;
	Thu, 26 Jan 2006 13:05:21 +0100
Message-ID: <43D8BB00.1090202@zurich.ibm.com>
Date: Thu, 26 Jan 2006 13:05:20 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Jeroen Massar 
References: <20060120185257.GE18960@ccil.org>	<1797258665.20060123163611@atkielski.com>		<0728557.20060124163321@atkielski.com>
	<43D683FA.8050502@unfix.org>
In-Reply-To: <43D683FA.8050502@unfix.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Proposal for keeping "free speech" but limitting the nuisance
 to the working group (Was: John Cowan supports 3683 PR-action against Jefsey
 Morfin)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jeroen,

A practice I used when I was diffserv chair and we had quite a lot
of off-topic postings was to create a second list, diffserv-interest
(which still exists BTW). The rule for diffserv@ietf.org was "must
be relevant to a chartered work item" and the rule for diffserv-interest
was "must be relevant to diffserv technology."

This worked well, with active intervention by the chair to divert
off-topic threads to the -interest list.  It doesn't raise any
issues for the standards process, which states that all consensus
points are settled on the WG mailing list. People only interested
in the standards work simply ignored the -interest list.

This is easy; any WG chair can do it today.

    Brian


Jeroen Massar wrote:
> Anthony G. Atkielski wrote:
> 
>>Pekka Savola writes:
>>
>>
>>>Why must each and every WG member be required to filter a person's
>>>postings?  Much more convenient to do so in one place.
>>
>>Because each and every WG member is an individual, with his own ideas
>>of what he does or doesn't want to read, and imposing the same rules
>>upon everyone prevents members from making their own decisions.  It
>>also imposes the decisions of a small minority upon the majority.
> 
> 
> Here goes for a try... flame me off list if required.
> 
> As it is indeed quite controversial to 'block' people, maybe there can
> be a solution that, though it will have overhead for listadmins, it will
> help the process that the workinggroup is actually for in the first place.
> 
> In the several messages there have been brought up a number of solutions
>  to the problem where one or multiple entities are (deliberately)
> flooding/overloading the mailinglists of workinggroups and other places
> with off-topic messages.
> 
> There seem to be a couple of solutions, amongst which:
>  - Filtering based on source address at the receiver
>  - Filtering based on keywords, which has really bad side-effects.
>  - Blocking the sender at the mailinglist level.
>  - 3683 PR for complete full blockage of posting rights.
> 
> The first is reasonably fine, as you don't see the message of the entity
> that one finds not useful, but you might see responses of others thus
> this is still intrusive and you still get those messages which you
> wanted to filter out. The second option might filter out messages which
> you did want to read. Both still will get these messages in the
> mailinglist archive, even though there was a consensus that those
> messages are unwanted.
> 
> The third and fourth option are pretty definitive, no more messages from
> that entity, but this might be seen as silencing this persons freedom of
> speech.
> 
> My proposal to solve this issue but keeping everybody happy:
> 
> Two mailinglists: @ietf.org + full.@ietf.org
> 
> full.@ is completely open, anybody can post anything they want
> though hopefully on topic on the subject of the workinggroup and of
> course based on the source address having a subscription *1
> full.@ is subscribed to @ thus full.wg gets everything
> preserving, at least parts, of the freedom of speech that is wanted and
> for the people who want to read a lot of mail everyday.
> 
> Initially everybody who signs up to the @ list can post to it.
> When the consensus on the list is that a member is not participating
> correctly, ignoring warnings etc, like currently this member can be
> banned from the list for a temporary amount of time. The member can
> still voice his opinions on the @ list. This thus allows him to
> voice his concerns to the members that do want to read them. Like the
> current 3683 PR the ban can become effectively indefinitely for the main
> list, while the poster is still and always allowed on full.@.
> 
> 
> The big concern here is of course that one could say that if you get
> booted out of the group that your voice won't be heard as they are not
> reading the other list. This is of course true, but one can raise their
> concerns on the full list, for instance Google won't differentiate
> between them and there will always be folks who will listen to it and
> forward these concerns when they have valid argumentation. By posting
> 'good' messages to the full.@ list a member can also demonstrate
> that he is really willing to contribute instead of disrupt. One of the
> nicest controversies is of course what to determine good and bad,
> starwars as an example, how bad are the jedi and how good are the sith,
> it completely depends on the side you are on, nothing else. That all
> boils down to trust and other factors, any mailinglist admin could abuse
> his position to set the sender of an address to silently discard, SMTP
> can have a CC: in the header and mailman will not forward the message to
> that person and various other nice tricks.
> 
> I hope the above might give a better point to discuss all this over
> instead of seeing replies like "that is not good" "see above" and other
> comments without effective constructive arguments.
> 
> Greets,
>  Jeroen
> 
> *1 = to avoid the large amount of spam flowing to the various lists
> which nicely get blocked because of subscription regulation.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 07:14:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F261h-0006az-WC; Thu, 26 Jan 2006 07:14:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F261e-0006at-Ku
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 07:14:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08369
	for ; Thu, 26 Jan 2006 07:13:21 -0500 (EST)
Received: from mtagate2.de.ibm.com ([195.212.29.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F26BY-00018T-4w
	for ietf@ietf.org; Thu, 26 Jan 2006 07:25:09 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0QCEFI5244894
	for ; Thu, 26 Jan 2006 12:14:16 GMT
Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com
	[9.149.165.213])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0QCDsgV211776
	for ; Thu, 26 Jan 2006 13:13:54 +0100
Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0QCDrBf026810 for ; Thu, 26 Jan 2006 13:13:54 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0QCDraO026804 for ; Thu, 26 Jan 2006 13:13:53 +0100
Received: from zurich.ibm.com (sig-9-146-218-145.de.ibm.com [9.146.218.145])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA59816
	for ; Thu, 26 Jan 2006 13:13:52 +0100
Message-ID: <43D8BCF9.3070108@zurich.ibm.com>
Date: Thu, 26 Jan 2006 13:13:45 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: IETF Discussion 
References: <43D7DEDE.3050803@cisco.com>	<64EA6FCA33E6A3F95FF4D4EF@B50854F0A9192E8EC6CDA126>	
	<43D87732.2000205@cisco.com>
In-Reply-To: <43D87732.2000205@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Eliot Lear wrote:
> Douglas Otis wrote:
> 
>>I suspect that at the moment, I am the guilty party in consuming
>>bandwidth on the DKIM list.  With the aggressive schedule, the
>>immediate desire was to get issues listed, corrected, and in a form
>>found acceptable.  
> 
> Without going into all the reasons why here, I asked Doug to separate
> out issues into separate messages.

Exactly. If a WG group is discussing a dozen separate issues in parallel,
an active participant can easily send several dozen *constructive*
messages in a day. Our problem with disruptive messages can't be solved
by counting bytes.

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 07:21:11 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F267j-0001Bo-BK; Thu, 26 Jan 2006 07:21:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F267h-0001Ba-5d
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 07:21:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09005
	for ; Thu, 26 Jan 2006 07:19:37 -0500 (EST)
Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F26Hd-0001PW-1z
	for ietf@ietf.org; Thu, 26 Jan 2006 07:31:26 -0500
Received: (qmail 72346 invoked from network); 26 Jan 2006 13:10:04 -0000
Received: from softbank219001188003.bbtec.net (HELO
	necom830.hpcl.titech.ac.jp) (219.1.188.3)
	by necom830.hpcl.titech.ac.jp with SMTP; 26 Jan 2006 13:10:04 -0000
Message-ID: <43D8BECF.1040904@necom830.hpcl.titech.ac.jp>
Date: Thu, 26 Jan 2006 21:21:35 +0900
From: Masataka Ohta 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: Brian E Carpenter 
References: <20060120185257.GE18960@ccil.org>	<1797258665.20060123163611@atkielski.com>		<0728557.20060124163321@atkielski.com>	<43D683FA.8050502@unfix.org>
	<43D8BB00.1090202@zurich.ibm.com>
In-Reply-To: <43D8BB00.1090202@zurich.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Proposal for keeping "free speech" but limitting the nuisance
 to the working group (Was: John Cowan supports 3683 PR-action against Jefsey
 Morfin)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian E Carpenter wrote:
 
> A practice I used when I was diffserv chair and we had quite a lot
> of off-topic postings was to create a second list, diffserv-interest
> (which still exists BTW). The rule for diffserv@ietf.org was "must
> be relevant to a chartered work item" and the rule for diffserv-interest
> was "must be relevant to diffserv technology."

Though I never participated in diffserv WG activities, which was
chartered wrongly from the beginning, your chairing strategy
explains why the result of the WG is technically meaningless.

> People only interested
> in the standards work simply ignored the -interest list.

They ignored the -interest list and the technology.

							Masataka Ohta



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 07:48:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F26Yb-0003Uh-UQ; Thu, 26 Jan 2006 07:48:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F26YZ-0003UV-9h
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 07:48:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10375
	for ; Thu, 26 Jan 2006 07:47:21 -0500 (EST)
Received: from mtagate1.de.ibm.com ([195.212.29.150])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F26iU-00027D-69
	for ietf@ietf.org; Thu, 26 Jan 2006 07:59:10 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0QCm0Ol243884
	for ; Thu, 26 Jan 2006 12:48:02 GMT
Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com
	[9.149.165.212])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0QClxgV221886
	for ; Thu, 26 Jan 2006 13:47:59 +0100
Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0QClxro030156 for ; Thu, 26 Jan 2006 13:47:59 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0QClxEc030135; Thu, 26 Jan 2006 13:47:59 +0100
Received: from zurich.ibm.com (sig-9-146-218-145.de.ibm.com [9.146.218.145])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA54486;
	Thu, 26 Jan 2006 13:47:58 +0100
Message-ID: <43D8C4FD.1060302@zurich.ibm.com>
Date: Thu, 26 Jan 2006 13:47:57 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Masataka Ohta 
References: <20060120185257.GE18960@ccil.org>	<1797258665.20060123163611@atkielski.com>		<0728557.20060124163321@atkielski.com>	<43D683FA.8050502@unfix.org>
	<43D8BB00.1090202@zurich.ibm.com>
	<43D8BECF.1040904@necom830.hpcl.titech.ac.jp>
In-Reply-To: <43D8BECF.1040904@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Proposal for keeping "free speech" but limitting the nuisance
 to the working group (Was: John Cowan supports 3683 PR-action against Jefsey
 Morfin)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Masataka Ohta wrote:
> Brian E Carpenter wrote:
>  
> 
>>A practice I used when I was diffserv chair and we had quite a lot
>>of off-topic postings was to create a second list, diffserv-interest
>>(which still exists BTW). The rule for diffserv@ietf.org was "must
>>be relevant to a chartered work item" and the rule for diffserv-interest
>>was "must be relevant to diffserv technology."
> 
> 
> Though I never participated in diffserv WG activities, which was
> chartered wrongly from the beginning,

As a matter of fact, I believe that the insistence of the ADs
involved on a very tightly drawn charter was the main reason that
the WG succeeded.

> your chairing strategy

You mean the care we took to consider dissenting opinions before
reaching rough consensus? Or something else?

> explains why the result of the WG is technically meaningless.

That is a strange statement given the actual facts of implementation
and deployment.

>>People only interested
>>in the standards work simply ignored the -interest list.
> 
> 
> They ignored the -interest list and the technology.

Are you referring to the many vendors that implemented
it, or the many enterprises that have deployed it?

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 08:09:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F26sp-0002mr-5n; Thu, 26 Jan 2006 08:09:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F26sm-0002mh-Ai
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 08:09:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12205
	for ; Thu, 26 Jan 2006 08:08:16 -0500 (EST)
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F272i-0002zg-On
	for ietf@ietf.org; Thu, 26 Jan 2006 08:20:06 -0500
Received: from venus.office (europa.netlab.nec.de [10.1.1.25])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 5C60723627;
	Thu, 26 Jan 2006 14:09:37 +0100 (CET)
Received: from n-eggert.office ([10.1.1.112]) by venus.office over TLS secured
	channel with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Jan 2006 14:09:37 +0100
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by n-eggert.office (Postfix) with ESMTP id 3EC2B67EFEC;
	Thu, 26 Jan 2006 14:09:35 +0100 (CET)
In-Reply-To: <43D8C7D2.5000005@zurich.ibm.com>
References: 
	<43D8C7D2.5000005@zurich.ibm.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Message-Id: <39907EC9-CF30-4FDB-A766-502241292A41@netlab.nec.de>
From: Lars Eggert 
Date: Thu, 26 Jan 2006 14:09:33 +0100
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.746.2)
X-OriginalArrivalTime: 26 Jan 2006 13:09:37.0288 (UTC)
	FILETIME=[C24D7080:01C62279]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: Martin Stiemerling ,
	IETF Discussion 
Subject: Re: getting the IETF rate at the Hilton
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0390154147=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0390154147==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-16-1059983614;
	protocol="application/pkcs7-signature"


--Apple-Mail-16-1059983614
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

Hi,

On Jan 26, 2006, at 14:00, Brian E Carpenter wrote:
> I would suggest that instead of sending such issues to a very large
> list addressed to "somebody", people should send them where they
> may reach the right people:  ietf-registrar@ietf.org
> and if that doesn't solve it, iad@ietf.org.

thanks. I have re-sent the message to the registrar.

However, your email is the first time I've seen either of these two  
addresses mentioned. I also can't find them on ietf.org. It's hard to  
send email to an address one doesn't know about.

Sending this to the general list also made other attendees aware of  
the problem, which IMO is one of its purposes, no?

Lars
--
Lars Eggert                                     NEC Network Laboratories


--Apple-Mail-16-1059983614
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw
ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE
EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN
AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv
AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK
xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF
DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ
vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C
AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l
dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS
vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2
usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu
mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT
G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl
ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa
LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud
HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs
Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf
qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa
9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G
CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy
ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT
FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq
hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw
NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx
EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO
ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI
hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT
wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z
9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY
LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD
VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy
ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz
MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0
QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9
3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR
piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB
KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1
aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDYwMTI2MTMwOTMzWjAjBgkqhkiG9w0BCQQxFgQUkBojYE6qv49/LvRs7Q5S
kOgWArUwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu
LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg
THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu
bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq
hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl
bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD
VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw
JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA
BIIBAIufpTlJ2SUXK3qWwlVb211H2lK4HRB3IewHHy+MewUB5O/z9lTBeE7vyiT7jU4ym7uSp6Qe
rKGqNLRRIXdzJgU4sExmOUmctwIgt02xmLqpduBKe/kGDv67/p8sre0JxrCwUZ46TIkS3oKO9oZ7
JCn/bk0rLJyUhbIb4gjUwAc57XSUb63YurPmnbFdOmJzUM0XMwcf6WAhtSf22EUroxjg1VYsYrTl
QiylcVT4sM8idmrZw05WJfMxf7FHeI9m2bHCu5VFmuVkPlX/DKKubJTZ0lPFIcSgGGeCewAgrWik
OT4rpapanOk61CUX7N89SMkohFufEArnJ3ztnxFB0FIAAAAAAAA=

--Apple-Mail-16-1059983614--


--===============0390154147==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0390154147==--




From ietf-bounces@ietf.org Thu Jan 26 08:12:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F26vV-0003xK-6Z; Thu, 26 Jan 2006 08:12:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F26vT-0003xF-O0
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 08:12:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12422
	for ; Thu, 26 Jan 2006 08:11:04 -0500 (EST)
Received: from mtagate3.uk.ibm.com ([195.212.29.136])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F275Q-000362-6o
	for ietf@ietf.org; Thu, 26 Jan 2006 08:22:53 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0QD6ISg083974
	for ; Thu, 26 Jan 2006 13:12:24 GMT
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com
	[9.149.37.213])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0QD043E025550 for ; Thu, 26 Jan 2006 13:00:04 GMT
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0QD04H3014482 for ; Thu, 26 Jan 2006 13:00:04 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0QD03cQ014463; Thu, 26 Jan 2006 13:00:04 GMT
Received: from zurich.ibm.com (sig-9-146-218-145.de.ibm.com [9.146.218.145])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA25524;
	Thu, 26 Jan 2006 14:00:02 +0100
Message-ID: <43D8C7D2.5000005@zurich.ibm.com>
Date: Thu, 26 Jan 2006 14:00:02 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Lars Eggert 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Cc: Martin Stiemerling ,
	IETF Discussion 
Subject: Re: getting the IETF rate at the Hilton
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I would suggest that instead of sending such issues to a very large
list addressed to "somebody", people should send them where they
may reach the right people:  ietf-registrar@ietf.org
and if that doesn't solve it, iad@ietf.org.

     Brian

Lars Eggert wrote:
> Hi,
> 
> the Hilton reservation system doesn't offer the IETF rate when  checking 
> out on March 25 (or later) and instead charges $189 for all  days. Can 
> someone ask them to fix that?
> 
> (The Hilton site shows "65TH IETF MEETING GROUP DATES:  
> 03/16/06-03/25/06", so I assume the rate should be available until  the 
> 25th.)
> 
> Lars
> -- 
> Lars Eggert                                     NEC Network Laboratories
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 08:40:20 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F27MK-0005uO-Gm; Thu, 26 Jan 2006 08:40:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F27MI-0005uJ-Vg
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 08:40:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14720
	for ; Thu, 26 Jan 2006 08:38:47 -0500 (EST)
Received: from sccrmhc11.comcast.net ([63.240.77.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F27WH-00047P-0G
	for ietf@ietf.org; Thu, 26 Jan 2006 08:50:37 -0500
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165])
	by comcast.net (sccrmhc11) with SMTP
	id <20060126134002011009c189e>; Thu, 26 Jan 2006 13:40:03 +0000
Message-ID: <05bd01c6227d$d5192890$a9087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: <43D7F1C5.9080602@andybierman.com>
	<1182823182.20060126050611@atkielski.com>
Date: Thu, 26 Jan 2006 07:38:46 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Subject: Taking a deep breath (was Re: "too many notes" -- a modest proposal)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Just for the participants who are enjoying the current discussion on this 
list (for some value of "enjoying") -

One of the things that I find most helpful is when people who could be 
replying posting-by-posting within a thread stop, take a deep breath, and 
ask themselves, "rather than making my point in response to a number of 
different posts, what am I really trying to say?"

The same number of bytes, in one coherent message, with some thought given 
to organization, is a lot more helpful.

John Klensin is especially good at this, but he is not the only one (thank 
goodness).

And, just for another hint, John has been able to extract almost verbatim 
from his postings into Internet Drafts, which also say what he is trying to 
say in a coherent and organized way. Submitting Internet Drafts is The Only 
Way our BCPs are going to change, unless we actually enjoy the IESG "making 
it up as we go along" as the IETF process.

At least one IESG member is receptive enough to the idea of RFC 3933 process 
experiments that he is writing up proposals himself. If you actually care 
whether anything changes, that's what you can do, to make a difference.

Thanks,

Spencer (co-author of RFC 3933, which started out as a John Klensin e-mail, 
and is now a BCP) 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 09:46:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F28OJ-0005IG-5s; Thu, 26 Jan 2006 09:46:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F28OH-0005I8-Bp
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 09:46:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21670
	for ; Thu, 26 Jan 2006 09:44:53 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc13.comcast.net ([63.240.77.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F28YD-0006zB-PZ
	for ietf@ietf.org; Thu, 26 Jan 2006 09:56:44 -0500
Received: from smailcenter71.comcast.net ([204.127.205.171])
	by comcast.net (sccrmhc13) with SMTP
	id <200601261446000130011a3le>; Thu, 26 Jan 2006 14:46:00 +0000
Received: from [66.229.53.140] by smailcenter71.comcast.net;
	Thu, 26 Jan 2006 14:46:00 +0000
To: ietf@ietf.org, hartmans-ietf@mit.edu
Date: Thu, 26 Jan 2006 14:46:00 +0000
Message-Id: <012620061446.4337.43D8E0A800060234000010F1220076369200000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
X-Spam-Score: 1.5 (+)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: 
Subject: draft-hartmans-mailinglist-experiment
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0128983351=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0128983351==
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_4337_1138286760_0"


--NextPart_Webmail_9m3u9jl4l_4337_1138286760_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

I think Sams proposed experiment is a very good idea.  I do have some thoughts, but my support doesn't hinge on their incorporation and I'm in favor of the draft either way.
In my opinion these should be experiments of process rather than penalty.  I feel like since the severity of a ban legnth is subjective and since different cases will warrant different legnths we might do better (i.e. have less things to disagree on) if all experiments assumed the same ban legnth.  I was also thnking that if everyone agreed this was a process experiment then I'd like to suggest that all experiments be mock in the sense that the decisions are not actually carried out.  I think doing it that way would give us greater freedom to experiment.  Also I figure anyone banned by an experimental process is going to make a lot of noise in the appeals process and we might start to annoy our counterparts who have to hear them?
These are just my thoughts and I'm not tied to any of them so you risk no argument by disagreeing.
nick
--NextPart_Webmail_9m3u9jl4l_4337_1138286760_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit





I think Sams proposed experiment is a very good idea.  I do have some thoughts, but my support doesn't hinge on their incorporation and I'm in favor of the draft either way.


In my opinion these should be experiments of process rather than penalty.  I feel like since the severity of a ban legnth is subjective and since different cases will warrant different legnths we might do better (i.e. have less things to disagree on) if all experiments assumed the same ban legnth.  I was also thnking that if everyone agreed this was a process experiment then I'd like to suggest that all experiments be mock in the sense that the decisions are not actually carried out.  I think doing it that way would give us greater freedom to experiment.  Also I figure anyone banned by an experimental process is going to make a lot of noise in the appeals process and we might start to annoy our counterparts who have to hear them?


These are just my thoughts and I'm not tied to any of them so you risk no argument by disagreeing.


nick


--NextPart_Webmail_9m3u9jl4l_4337_1138286760_0--


--===============0128983351==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0128983351==--




From ietf-bounces@ietf.org Thu Jan 26 09:56:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F28Xf-00082E-HU; Thu, 26 Jan 2006 09:56:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F28Xd-00080s-H5
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 09:56:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22451
	for ; Thu, 26 Jan 2006 09:54:33 -0500 (EST)
Received: from sccrmhc13.comcast.net ([63.240.77.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F28ha-0007N9-U9
	for ietf@ietf.org; Thu, 26 Jan 2006 10:06:24 -0500
Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165])
	by comcast.net (sccrmhc13) with SMTP
	id <200601261455500130012gife>; Thu, 26 Jan 2006 14:55:50 +0000
Message-ID: <06d301c62288$6b3b1a90$a9087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: <012620061446.4337.43D8E0A800060234000010F1220076369200000E9B9CD2050C0702@comcast.net>
Date: Thu, 26 Jan 2006 08:54:33 -0600
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
Subject: Re: draft-hartmans-mailinglist-experiment
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1197397491=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1197397491==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_06D0_01C62256.204989E0"

This is a multi-part message in MIME format.

------=_NextPart_000_06D0_01C62256.204989E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A pointer to "Sam's proposed experiment" is =
http://www.ietf.org/internet-drafts/draft-hartman-mailinglist-experiment-=
00.txt, announced on Tuesday of this week.

Thanks,

Spencer
  ----- Original Message -----=20
  From: nick.staff@comcast.net=20
  To: ietf@ietf.org ; hartmans-ietf@mit.edu=20
  Sent: Thursday, January 26, 2006 8:46 AM
  Subject: draft-hartmans-mailinglist-experiment


  I think Sams proposed experiment is a very good idea.  I do have some =
thoughts, but my support doesn't hinge on their incorporation and I'm in =
favor of the draft either way.

  In my opinion these should be experiments of process rather than =
penalty.  I feel like since the severity of a ban legnth is subjective =
and since different cases will warrant different legnths we might do =
better (i.e. have less things to disagree on) if all experiments assumed =
the same ban legnth.  I was also thnking that if everyone agreed this =
was a process experiment then I'd like to suggest that all experiments =
be mock in the sense that the decisions are not actually carried out.  I =
think doing it that way would give us greater freedom to experiment.  =
Also I figure anyone banned by an experimental process is going to make =
a lot of noise in the appeals process and we might start to annoy our =
counterparts who have to hear them?

  These are just my thoughts and I'm not tied to any of them so you risk =
no argument by disagreeing.

  nick



-------------------------------------------------------------------------=
-----


  _______________________________________________
  Ietf mailing list
  Ietf@ietf.org
  https://www1.ietf.org/mailman/listinfo/ietf

------=_NextPart_000_06D0_01C62256.204989E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









A pointer to "Sam's proposed =
experiment" is http://www.ietf.org/internet-drafts/draft-hartman-mailinglist-ex=
periment-00.txt,=20
announced on Tuesday of this week.


 


Thanks,


 


Spencer


  
----- Original Message ----- 

  From:=20
  nick.staff@comcast.net =

  
  
Sent: Thursday, January 26, =
2006 8:46=20
  AM

  
Subject:=20
  draft-hartmans-mailinglist-experiment

  


  

  
I think Sams proposed experiment is a very good idea.  I =
do have=20
  some thoughts, but my support doesn't hinge on =
their incorporation=20
  and I'm in favor of the draft either way.

  
In my opinion these should be experiments of process rather =
than=20
  penalty.  I feel like since the severity of a ban legnth is =
subjective=20
  and since different cases will warrant different legnths we might do =
better=20
  (i.e. have less things to disagree on) if all experiments=20
  assumed the same ban legnth.  I was also thnking =
that if=20
  everyone agreed this was a process experiment then I'd like to suggest =
that=20
  all experiments be mock in the sense that the decisions are not =
actually=20
  carried out.  I think doing it that way would give us =
greater=20
  freedom to experiment.  Also I figure anyone banned by an=20
  experimental process is going to make a lot of noise in the appeals =
process=20
  and we might start to annoy our counterparts who have to hear =
them?

  
These are just my thoughts and I'm not tied to any of them so you =
risk no=20
  argument by disagreeing.

  
nick

  

  


  
_______________________________________________
Ietf mailing =

  =
list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
<=
/BLOCKQUOTE>

------=_NextPart_000_06D0_01C62256.204989E0--




--===============1197397491==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1197397491==--






From ietf-bounces@ietf.org Thu Jan 26 10:14:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F28pm-00009B-JF; Thu, 26 Jan 2006 10:14:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F28pk-00008U-Cu
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 10:14:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24434
	for ; Thu, 26 Jan 2006 10:13:15 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F28ze-0008Ca-5E
	for ietf@ietf.org; Thu, 26 Jan 2006 10:25:06 -0500
Received: from [192.168.0.2] (adsl-71-131-94-71.dsl.sntc01.pacbell.net
	[71.131.94.71]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0QFF2ww006500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Jan 2006 07:15:03 -0800
Message-ID: <43D8E74E.4000402@dcrocker.net>
Date: Thu, 26 Jan 2006 07:14:22 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Lars Eggert 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion 
Subject: Re: getting the IETF rate at the Hilton
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


> the Hilton reservation system doesn't offer the IETF rate when checking 
> out on March 25 (or later) and instead charges $189 for all days. Can 
> someone ask them to fix that?


While waiting for Hilton to fix the problem, an obvious work-around is to make 2 
reservations, one for the period that gets the lower rate and the second for the 
additional night(s).

d/


-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 10:16:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F28rb-0000oZ-DC; Thu, 26 Jan 2006 10:16:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F28rY-0000nU-0M
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 10:16:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24591
	for ; Thu, 26 Jan 2006 10:15:05 -0500 (EST)
Received: from mtagate3.de.ibm.com ([195.212.29.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F291S-0008H2-34
	for ietf@ietf.org; Thu, 26 Jan 2006 10:26:56 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0QE6Prq079120
	for ; Thu, 26 Jan 2006 15:16:20 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com
	[9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0QDglgV248250
	for ; Thu, 26 Jan 2006 14:42:47 +0100
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0QDgkc4022733 for ; Thu, 26 Jan 2006 14:42:46 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0QDgkCt022708; Thu, 26 Jan 2006 14:42:46 +0100
Received: from zurich.ibm.com (sig-9-146-218-145.de.ibm.com [9.146.218.145])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA82908;
	Thu, 26 Jan 2006 14:42:44 +0100
Message-ID: <43D8D1D4.9010304@zurich.ibm.com>
Date: Thu, 26 Jan 2006 14:42:44 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Lars Eggert 
References: 
	<43D8C7D2.5000005@zurich.ibm.com>
	<39907EC9-CF30-4FDB-A766-502241292A41@netlab.nec.de>
In-Reply-To: <39907EC9-CF30-4FDB-A766-502241292A41@netlab.nec.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: Martin Stiemerling ,
	IETF Discussion 
Subject: Secretariat and IASA contacts [Re: getting the IETF rate at the
	Hilton]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Lars,

Secretariat contact points are actually listed at
http://www.ietf.org/secretariat.html which is linked
right off the IETF home page.

You can find the IAD's address on the IASA page linked
from the bottom of the home page, but I agree it's
not obvious and I will suggest it be improved.

     Brian

Lars Eggert wrote:
> Hi,
> 
> On Jan 26, 2006, at 14:00, Brian E Carpenter wrote:
> 
>> I would suggest that instead of sending such issues to a very large
>> list addressed to "somebody", people should send them where they
>> may reach the right people:  ietf-registrar@ietf.org
>> and if that doesn't solve it, iad@ietf.org.
> 
> 
> thanks. I have re-sent the message to the registrar.
> 
> However, your email is the first time I've seen either of these two  
> addresses mentioned. I also can't find them on ietf.org. It's hard to  
> send email to an address one doesn't know about.
> 
> Sending this to the general list also made other attendees aware of  the 
> problem, which IMO is one of its purposes, no?
> 
> Lars
> -- 
> Lars Eggert                                     NEC Network Laboratories
> 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 10:34:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2994-0007en-At; Thu, 26 Jan 2006 10:34:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2991-0007eA-Sy
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 10:34:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27131
	for ; Thu, 26 Jan 2006 10:33:09 -0500 (EST)
Received: from smtp0.netlab.nec.de ([195.37.70.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F29Iv-0000vB-CE
	for ietf@ietf.org; Thu, 26 Jan 2006 10:45:00 -0500
Received: from venus.office (europa.netlab.nec.de [10.1.1.25])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id B5CD923614;
	Thu, 26 Jan 2006 16:34:28 +0100 (CET)
Received: from n-eggert.office ([10.1.1.112]) by venus.office over TLS secured
	channel with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 26 Jan 2006 16:34:28 +0100
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by n-eggert.office (Postfix) with ESMTP id F07F867F0AE;
	Thu, 26 Jan 2006 16:34:27 +0100 (CET)
In-Reply-To: <43D8E74E.4000402@dcrocker.net>
References: 
	<43D8E74E.4000402@dcrocker.net>
Mime-Version: 1.0 (Apple Message framework v746.2)
Message-Id: <884EA2FF-2A25-4A26-A7DB-5A2C260338E0@netlab.nec.de>
From: Lars Eggert 
Date: Thu, 26 Jan 2006 16:34:23 +0100
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.746.2)
X-OriginalArrivalTime: 26 Jan 2006 15:34:28.0438 (UTC)
	FILETIME=[FEA1AF60:01C6228D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: IETF Discussion 
Subject: Re: getting the IETF rate at the Hilton
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1629613923=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============1629613923==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-25-1068673943;
	protocol="application/pkcs7-signature"


--Apple-Mail-25-1068673943
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

On Jan 26, 2006, at 16:14, Dave Crocker wrote:
> While waiting for Hilton to fix the problem, an obvious work-around  
> is to make 2 reservations, one for the period that gets the lower  
> rate and the second for the additional night(s).

FWIW, calling the hotel directly has also worked.

Lars
--
Lars Eggert                                     NEC Network Laboratories


--Apple-Mail-25-1068673943
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw
ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE
EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN
AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv
AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK
xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF
DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ
vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C
AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l
dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS
vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2
usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu
mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT
G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl
ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa
LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud
HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs
Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf
qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa
9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G
CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy
ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT
FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq
hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw
NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx
EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO
ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI
hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT
wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z
9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY
LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD
VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy
ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz
MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0
QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9
3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR
piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB
KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1
aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDYwMTI2MTUzNDI0WjAjBgkqhkiG9w0BCQQxFgQUTqzWZ+tci9pJoqn1DrMQ
mqs+N28wgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu
LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg
THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu
bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq
hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl
bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD
VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw
JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA
BIIBAIKLFQL+PYtur2zqJlltC8Rqnwr2neMqWWkx64RRyqrxJfGAprpd84+MBB0DXUs/RWpJig+A
kXnm6AeTSr/5qxBAOpHJ+bovdNboND/Vn+kPgxzVw213b6ie3UHpOwZQU3goprWybCLyElt223mc
1HQLrfr2F6sJml3i8xOvfVDfTQNx5G4qJqigzAkOYQ8dwt4QzKvP/pZfj07+tu6jPsKspyhjHwpV
Y1EdLCPGphZCZWgtE2RtqoE7Zmn4jjnIRuKo9Dj+8XMdLjrjcPI+bWtLEfuAgheK1xR0Yj/lKrTJ
60rigvzmqtodgG31ERo5FQ6l+9ZITSLSUoCSkBBm5M4AAAAAAAA=

--Apple-Mail-25-1068673943--


--===============1629613923==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1629613923==--




From ietf-bounces@ietf.org Thu Jan 26 10:43:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F29Ht-0001pH-Ph; Thu, 26 Jan 2006 10:43:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F29Hr-0001p9-Fh
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 10:43:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28431
	for ; Thu, 26 Jan 2006 10:42:19 -0500 (EST)
Received: from [63.240.77.84] (helo=sccrmhc14.comcast.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F29Ra-0001Pg-78
	for ietf@ietf.org; Thu, 26 Jan 2006 10:54:10 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (sccrmhc14) with SMTP
	id <2006012615425401400ds0bae>; Thu, 26 Jan 2006 15:42:54 +0000
Message-ID: <071601c6228f$0169daa0$a9087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: "IETF Discussion" 
References: <43D8C7D2.5000005@zurich.ibm.com><39907EC9-CF30-4FDB-A766-502241292A41@netlab.nec.de>
	<43D8D1D4.9010304@zurich.ibm.com>
Date: Thu, 26 Jan 2006 09:41:41 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Subject: Re: Secretariat and IASA contacts [Re: getting the IETF rate at
	theHilton]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

From: "Brian E Carpenter" 


> Lars,
>
> Secretariat contact points are actually listed at
> http://www.ietf.org/secretariat.html which is linked
> right off the IETF home page.
>
> You can find the IAD's address on the IASA page linked
> from the bottom of the home page, but I agree it's
> not obvious and I will suggest it be improved.

Hi, Brian,

I actually knew about http://www.ietf.org/secretariat.html (it replaced an 
entire page of e-mail addresses and websites in the IETF Overview 
presentation, a couple of IETFs back, and is very helpful), but didn't 
understand that ietf-registrar also included hotel reservation issues.

(I did know about Ray's e-mail address and punted to him with the related 
issue that the reservation system didn't allow for Friday or Saturday 
check-in, either - so the problems at both ends of the week have been 
reported now).

Thanks,

Spencer 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 11:09:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F29ge-0005yi-LL; Thu, 26 Jan 2006 11:09:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F29gc-0005xt-Mv
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 11:09:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00405
	for ; Thu, 26 Jan 2006 11:07:53 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F29qY-0002LQ-7k
	for ietf@ietf.org; Thu, 26 Jan 2006 11:19:45 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0QG96j6098945
	for ; Thu, 26 Jan 2006 17:09:06 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 17:09:06 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <11410503317.20060126170906@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D855A4.7080007@andybierman.com>
References: 
	<43D7F1C5.9080602@andybierman.com>
	<1182823182.20060126050611@atkielski.com>
	<43D855A4.7080007@andybierman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Andy Bierman writes:

> I think you missed my point.
> I should have said "enforce or abide by draconian rules".
> Automating the process is even worse.
> Then stupid scripts disrupt WG activity on a regular basis.
> Inappropriate mailing list use should be dealt with by the
> WG Chair(s) in a more diplomatic manner.

Well, one option is to stop trying to restrict access to lists to
begin with.  The problem with having a human being make the decision
is that human beings are notoriously biased.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 11:12:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F29jl-0006Yw-6D; Thu, 26 Jan 2006 11:12:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F29ji-0006Yi-6T
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 11:12:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00596
	for ; Thu, 26 Jan 2006 11:11:05 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F29tg-0002RH-94
	for ietf@ietf.org; Thu, 26 Jan 2006 11:22:57 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0QGCRdv098993
	for ; Thu, 26 Jan 2006 17:12:27 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 17:12:27 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <665179144.20060126171227@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <5559308.1138252952014.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
References: <5559308.1138252952014.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Subject: Re: Questions for those in favor of PR-Actions in general
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Randy Presuhn writes:

> A more accurate restatement is that some good people have
> already left because participation in the IETF was sufficiently
> unpleasant for them, and that other productive people are on the
> verge of leaving for the same reason.

Well, if they can't stand the heat in the kitchen, maybe they should
leave.

There isn't any venue in which real discussions with real and
different points of view can take place without some sort of conflict
that might ruffle the feathers of particularly delicate individuals.
If it's that stressful for them, they probably shouldn't be involved
in such discussions.  Trying to remove all the substance of the
discussions just to avoid offending the hypersensitive makes no
logical sense.

> How much snake oil and vitriol one is willing to tolerate varies
> with the individual and how much they're rewarded (in one
> way or another) for spending time in this snake pit.

You think these lists are snake pits?  They seem awfully tame to me.
And I've seen much more snake-infested venues produce useful results,
so the serpents are not necessarily obstacles.

> I know first-hand of several very good engineers who have stopped
> participating here, and have cited the level of nastiness as a key
> motivating factor.

Well, there will always be more good engineers.




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 11:13:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F29l1-0006k0-Il; Thu, 26 Jan 2006 11:13:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F29ky-0006jv-Um
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 11:13:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00661
	for ; Thu, 26 Jan 2006 11:12:22 -0500 (EST)
Received: from e4.ny.us.ibm.com ([32.97.182.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F29uu-0002Su-PO
	for ietf@ietf.org; Thu, 26 Jan 2006 11:24:14 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k0QGCROM030484
	for ; Thu, 26 Jan 2006 11:13:43 -0500
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com
	[9.149.37.216])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0QAvP3E158612 for ; Thu, 26 Jan 2006 10:57:25 GMT
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0QAvP0U010853 for ; Thu, 26 Jan 2006 10:57:25 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0QAvOgr010839; Thu, 26 Jan 2006 10:57:24 GMT
Received: from zurich.ibm.com (sig-9-146-218-145.de.ibm.com [9.146.218.145])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA68336;
	Thu, 26 Jan 2006 11:57:23 +0100
Message-ID: <43D8AB13.6020202@zurich.ibm.com>
Date: Thu, 26 Jan 2006 11:57:23 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Mark Townsley 
References: <4.3.2.7.2.20060124151411.0334bd20@email.cisco.com>	
	<43D6BAAF.4060302@cisco.com>
In-Reply-To: <43D6BAAF.4060302@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Softwires Interim Meeting
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

And BTW it isn't a rule, it's strongly worded guideline.

     Brian

Mark Townsley wrote:
> Marshall Eubanks wrote:
> 
>> March 19 - 30 days = Feb 17th.
> 
> 
> This date was chosen, understanding that it bends the rules a bit, to 
> increase the greater goal of global participation by coinciding with the 
> APRICOT conference the following week (so at least some of the 
> non-asiapac members will be on the correct side of the globe).
> 
> - Mark
> 
>>
>> On Jan 24, 2006, at 4:19 PM, James M. Polk wrote:
>>
>>> Mark
>>>
>>> I'm not an interested party here, and I don't mean to throw a  monkey 
>>> wrench into your plans, but I'm observing that this seems to  be 
>>> within the 30 days of moratorium of when we cannot have an  interim, 
>>> where (loosely) 'interims shall not be within 30 days of  the next 
>>> IETF meeting'.
>>>
>>> The Dallas IETF starts on March 19th, so I would think the cutoff  
>>> would be Feb 19th for the last of an interim.  What am I missing?
>>>
>>> At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote:
>>>
>>>> The meeting will be Feb 23-24 in Hong Kong. Participants should  
>>>> plan to
>>>> arrive Feb 22 for an early start on Feb 23. We will finish by 2pm  
>>>> on Feb
>>>> 24. Accomodation information coming shortly (watch the
>>>> softwires@ietf.org mailing list).
>>>>
>>>> Thank you,
>>>>
>>>> - Mark
>>>>
>>>> _______________________________________________
>>>> IETF-Announce mailing list
>>>> IETF-Announce@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ietf-announce
>>>
>>>
>>>
>>> _______________________________________________
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ietf
>>
>>
>>
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 11:17:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F29o8-0007VZ-5i; Thu, 26 Jan 2006 11:17:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F29o6-0007VF-5P
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 11:17:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01013
	for ; Thu, 26 Jan 2006 11:15:37 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F29y4-0002bv-16
	for ietf@ietf.org; Thu, 26 Jan 2006 11:27:29 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0QGGx7Y099026
	for ; Thu, 26 Jan 2006 17:16:59 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 17:16:59 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1635686984.20060126171659@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D8BCF9.3070108@zurich.ibm.com>
References: <43D7DEDE.3050803@cisco.com>
	<64EA6FCA33E6A3F95FF4D4EF@B50854F0A9192E8EC6CDA126>
	
	<43D87732.2000205@cisco.com> <43D8BCF9.3070108@zurich.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian E Carpenter writes:

> Exactly. If a WG group is discussing a dozen separate issues in parallel,
> an active participant can easily send several dozen *constructive*
> messages in a day. Our problem with disruptive messages can't be solved
> by counting bytes.

Set a rolling monthly quota, then.  Nobody constantly sends a long
stream of consistently productive messages.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 11:36:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2A7A-0008Sm-9R; Thu, 26 Jan 2006 11:36:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2A78-0008Sh-IQ
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 11:36:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02414
	for ; Thu, 26 Jan 2006 11:35:17 -0500 (EST)
Received: from omr1.networksolutionsemail.com ([205.178.146.51]
	helo=mail.networksolutionsemail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2AH6-0003IX-Th
	for ietf@ietf.org; Thu, 26 Jan 2006 11:47:10 -0500
Received: (qmail 11632 invoked from network); 26 Jan 2006 16:36:38 -0000
Received: from unknown (HELO ?192.168.0.11?) (24.24.133.237)
	by omr1.mgt.bos.netsol.com with SMTP; 26 Jan 2006 16:36:38 -0000
Message-ID: <43D8FA96.3070907@andybierman.com>
Date: Thu, 26 Jan 2006 08:36:38 -0800
From: Andy Bierman 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: 	<43D7F1C5.9080602@andybierman.com>	<1182823182.20060126050611@atkielski.com>	<43D855A4.7080007@andybierman.com>
	<11410503317.20060126170906@atkielski.com>
In-Reply-To: <11410503317.20060126170906@atkielski.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Anthony G. Atkielski wrote:

>Andy Bierman writes:
>
>  
>
>>I think you missed my point.
>>I should have said "enforce or abide by draconian rules".
>>Automating the process is even worse.
>>Then stupid scripts disrupt WG activity on a regular basis.
>>Inappropriate mailing list use should be dealt with by the
>>WG Chair(s) in a more diplomatic manner.
>>    
>>
>
>Well, one option is to stop trying to restrict access to lists to
>begin with.  The problem with having a human being make the decision
>is that human beings are notoriously biased.
>  
>

If we did this, our mailing lists would be bombarded with SPAM
from non-subscribers. 

There is an appeals process (of that we are too painfully aware)
that can be used for people who are told by a WG Chair that
they are using the mailing list in an inappropriate manner, and still
insist on continuing their behavior.

I have found that only the worst managers deal with
bad apples by burdening the entire group with oppressive rules.

Andy


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 11:38:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2A8f-0000Np-Jh; Thu, 26 Jan 2006 11:38:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2A8c-0000Nb-Ln
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 11:38:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02533
	for ; Thu, 26 Jan 2006 11:36:50 -0500 (EST)
Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2AIb-0003LF-3x
	for ietf@ietf.org; Thu, 26 Jan 2006 11:48:42 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 8801AE0053; Thu, 26 Jan 2006 11:38:10 -0500 (EST)
To: nick.staff@comcast.net
References: <012620061446.4337.43D8E0A800060234000010F1220076369200000E9B9CD2050C0702@comcast.net>
From: Sam Hartman 
Date: Thu, 26 Jan 2006 11:38:10 -0500
In-Reply-To: <012620061446.4337.43D8E0A800060234000010F1220076369200000E9B9CD2050C0702@comcast.net>
	(nick staff's message of "Thu, 26 Jan 2006 14:46:00 +0000")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: ietf@ietf.org
Subject: Re: draft-hartmans-mailinglist-experiment
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


So, if we don't actually carry out the ban, how do we see whether the
ban is successful in meeting the experimental goal of improving
productivity?



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 11:43:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2ADC-0001CE-RB; Thu, 26 Jan 2006 11:43:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ADB-0001C9-HT
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 11:43:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03041
	for ; Thu, 26 Jan 2006 11:41:32 -0500 (EST)
Received: from biscayne-one-station.mit.edu ([18.7.7.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2AN8-0003WK-QW
	for ietf@ietf.org; Thu, 26 Jan 2006 11:53:25 -0500
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id
	k0QGgve1000630; Thu, 26 Jan 2006 11:42:57 -0500 (EST)
Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160])
	(authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0QGgoWp010513
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Thu, 26 Jan 2006 11:42:51 -0500 (EST)
In-Reply-To: <012620061446.4337.43D8E0A800060234000010F1220076369200000E9B9CD2050C0702@comcast.net>
References: <012620061446.4337.43D8E0A800060234000010F1220076369200000E9B9CD2050C0702@comcast.net>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0D0BB9C1-4EED-4080-A524-4CAB18C1A35C@mit.edu>
From: Ken Raeburn 
Date: Thu, 26 Jan 2006 11:42:47 -0500
To: nick.staff@comcast.net
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org Mailing List" 
Subject: Re: draft-hartmans-mailinglist-experiment
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jan 26, 2006, at 9:46, nick.staff@comcast.net wrote:
>   Also I figure anyone banned by an experimental process is going  
> to make a lot of noise in the appeals process and we might start to  
> annoy our counterparts who have to hear them?

Isn't the (seemingly) requisite appeal following any action of this  
sort just part of the experiment?  And if we just use mock bans as  
you suggest, then of course they should be followed up with mock  
appeals, which the IESG or IAB pretend to listen to and make  
decisions about.  We could even pretend to have endless discussions  
without conclusions on various mailing lists.

> These are just my thoughts and I'm not tied to any of them so you  
> risk no argument by disagreeing.

These aren't even my thoughts. :-)

Ken

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 12:42:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2B91-0003Zf-R0; Thu, 26 Jan 2006 12:42:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2B8z-0003Yy-W0
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 12:42:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07794
	for ; Thu, 26 Jan 2006 12:41:14 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2BFJ-0006Vf-IB
	for ietf@ietf.org; Thu, 26 Jan 2006 12:49:22 -0500
Received: (qmail 19027 invoked from network); 26 Jan 2006 17:38:50 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 26 Jan 2006 17:38:50 -0000
Date: 26 Jan 2006 17:38:50 -0000
Message-ID: <20060126173850.55046.qmail@simone.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <1635686984.20060126171659@atkielski.com>
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>Set a rolling monthly quota, then.  Nobody constantly sends a long
>stream of consistently productive messages.

We've certainly been made aware of that.

R's,
John

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 12:43:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2B9D-0003dM-18; Thu, 26 Jan 2006 12:43:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2B97-0003bm-G9
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 12:42:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07864
	for ; Thu, 26 Jan 2006 12:41:22 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2BDQ-0006El-7I
	for ietf@ietf.org; Thu, 26 Jan 2006 12:47:28 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F2B29-0004z2-RV
	for ietf@ietf.org; Thu, 26 Jan 2006 18:35:45 +0100
Received: from 1cust143.tnt8.hbg2.deu.da.uu.net ([149.225.138.143])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Thu, 26 Jan 2006 18:35:45 +0100
Received: from nobody by 1cust143.tnt8.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Thu, 26 Jan 2006 18:35:45 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Thu, 26 Jan 2006 18:31:04 +0100
Organization: 
Lines: 71
Message-ID: <43D90758.7229@xyzzy.claranet.de>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust143.tnt8.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit
Subject: Re: Protocol Action: 'LDAP: Internationalized String Preparation'
 to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

The IESG wrote:

>  as a Proposed Standard

Mostly editorial nits:

| presented and stored values are first prepared for comparison
| and so that a character-by-character comparison yields the
| "correct" result.

s/and// (?)

| The following six-step process SHALL be applied to each
| presented and attribute value in preparation for character
| string matching rule evaluation.

s/and// (?)

| The input string is be normalized to Unicode Form KC
| (compatibility composed) as described in [UAX15].

s/is be/is/  Maybe s/KC/NFKC/ as used in 3454.
Or better s/Form KC/NFKC/g (more than one occurence).

| Characters which, per Section 5.8 of [Stringprep], change
| display properties or are deprecated are prohibited.

s/[Stringprep]/[RFC3454]/g

Something with the indentation in appendices A and B is odd.

| Otherwise, if the string being prepared is an initial, any,
| or final substring, then the output string is exactly one
| SPACE character, else the output string is exactly two
| SPACEs.

Apparently 'initial substring', 'any substring', and
'final substring' are terms here, and not simply the same as
any substring, also used later in appendix B:

| That is, if a prepared any substring matches a partition of
| the attribute value, then an assertion constructed by
| subdividing that substring into multiple substrings should
| also match.

How about quoting these terms:  '"initial", "any", or "final
substring"' in the first case, 'if a prepared "any substring"
matches' in the second case (?)  For an xml2rfc source that
could be done with any substring.

Actually only the unquoted "any" confused me, normally "any"
should include initial and final.

| All spaces are regarded as insignificant and are to be
| removed.

s/are to be// (?)  More than one occurence.

For the "Security Considerations" a note about mixing tables
for different Unicode versions might help:  RFC 3454 is 3.2,
using an Unicode 5 table to figure out say "unassigned" might
be a bad idea.

| However, only leading and trailing (as well as multiple
| consecutive spaces) of the string (as a whole) are
| insignificant.

s/consecutive spaces)/consecutive) spaces/

                      Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 12:43:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2B9S-0003j1-9W; Thu, 26 Jan 2006 12:43:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2B9O-0003hx-Iw
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 12:43:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08035
	for ; Thu, 26 Jan 2006 12:41:38 -0500 (EST)
Received: from mercury.lcs.mit.edu ([18.26.0.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2BAp-0005xL-4g
	for ietf@ietf.org; Thu, 26 Jan 2006 12:44:44 -0500
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178)
	id DA6C686AEA; Thu, 26 Jan 2006 12:34:11 -0500 (EST)
To: ietf@ietf.org
Message-Id: <20060126173411.DA6C686AEA@mercury.lcs.mit.edu>
Date: Thu, 26 Jan 2006 12:34:11 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

    > From: "Anthony G. Atkielski" 

    > Nobody constantly sends a long stream of consistently productive
    > messages.

The irony in you, of all people, making this statement is a little stunning -
to the point that one really does start to wonder exactly what could be
behind your posting behaviour. Several possibilities come to mind, of
course...

    > Well, there will always be more good engineers.

In that case, there's no harm in the rest of us deciding we don't need the
dubious "assistance" of few of the most troublesome, and least productive, is
there?

	Noel

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 15:15:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2DWM-0006nu-RA; Thu, 26 Jan 2006 15:15:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2DWK-0006nD-79
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 15:15:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21503
	for ; Thu, 26 Jan 2006 15:13:30 -0500 (EST)
Received: from e34.co.us.ibm.com ([32.97.110.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2DgG-0004MT-Pd
	for ietf@ietf.org; Thu, 26 Jan 2006 15:25:23 -0500
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com
	[9.17.195.106])
	by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k0QKEdB9012845
	for ; Thu, 26 Jan 2006 15:14:39 -0500
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167])
	by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id
	k0QKGtUO061976 for ; Thu, 26 Jan 2006 13:16:56 -0700
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1])
	by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0QKEc3t028322 for ; Thu, 26 Jan 2006 13:14:39 -0700
Received: from cichlid.raleigh.ibm.com (sig-9-65-193-60.mts.ibm.com
	[9.65.193.60])
	by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0QKEbSZ028279 for ; Thu, 26 Jan 2006 13:14:38 -0700
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k0QKE2nU012126
	for ; Thu, 26 Jan 2006 15:14:07 -0500
Message-Id: <200601262014.k0QKE2nU012126@cichlid.raleigh.ibm.com>
To: ietf@ietf.org
Date: Thu, 26 Jan 2006 15:14:02 -0500
From: Thomas Narten 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Subject: Weekly posting summary for ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

[note: I find this type of summary to be a useful tool for
highlighting certain aspects of list traffic. With Brian Carpenter's
blessing, I plan on making this a regular feature for the ietf list.]

Total of 312 messages in the last 7 days ending midnight January 25.

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 11.22% |   35 |  7.24% |   119726 | anthony@atkielski.com
  5.45% |   17 |  5.21% |    86239 | brc@zurich.ibm.com
  0.32% |    1 |  9.29% |   153603 | lzhu@windows.microsoft.com
  3.85% |   12 |  5.11% |    84559 | jordi.palet@consulintel.es
  3.53% |   11 |  4.78% |    79123 | jefsey@jefsey.com
  3.85% |   12 |  3.82% |    63209 | harald@alvestrand.no
  3.53% |   11 |  3.56% |    58870 | tme@multicasttech.com
  3.85% |   12 |  3.11% |    51425 | hartmans-ietf@mit.edu
  3.21% |   10 |  3.49% |    57674 | nick.staff@comcast.net
  2.88% |    9 |  2.94% |    48651 | eric.gray@marconi.com
  3.21% |   10 |  2.24% |    37115 | nobody@xyzzy.claranet.de
  0.64% |    2 |  4.55% |    75287 | neil.harwani@gmail.com
  2.56% |    8 |  1.83% |    30220 | spencer@mcsr-labs.org
  1.60% |    5 |  2.61% |    43189 | lars.eggert@netlab.nec.de
  2.24% |    7 |  1.66% |    27438 | dhc2@dcrocker.net
  1.60% |    5 |  1.67% |    27638 | peter@peter-dambier.de
  1.28% |    4 |  1.82% |    30133 | jeroen@unfix.org
  1.92% |    6 |  0.92% |    15245 | johnl@iecc.com
  1.60% |    5 |  1.14% |    18790 | lear@cisco.com
  1.28% |    4 |  1.27% |    21052 | hannes.tschofenig@siemens.com
  1.60% |    5 |  0.95% |    15699 | smb@cs.columbia.edu
  0.96% |    3 |  1.32% |    21839 | john-ietf@jck.com
  0.96% |    3 |  1.29% |    21303 | margaret@thingmagic.com
  1.28% |    4 |  0.94% |    15517 | david.kessens@nokia.com
  1.28% |    4 |  0.84% |    13954 | bortzmeyer@nic.fr
  1.28% |    4 |  0.84% |    13907 | rpelletier@isoc.org
  0.96% |    3 |  1.05% |    17384 | karen.odonoghue@navy.mil
  0.96% |    3 |  0.99% |    16330 | bwijnen@lucent.com
  1.28% |    4 |  0.64% |    10650 | jnc@mercury.lcs.mit.edu
  0.64% |    2 |  1.24% |    20453 | elwynd@dial.pipex.com
  0.96% |    3 |  0.91% |    15058 | richard@shockey.us
  0.96% |    3 |  0.83% |    13736 | jmpolk@cisco.com
  0.96% |    3 |  0.78% |    12960 | ned.freed@mrochek.com
  0.96% |    3 |  0.73% |    12106 | jhutz@cmu.edu
  0.96% |    3 |  0.68% |    11294 | ietf@andybierman.com
  0.96% |    3 |  0.62% |    10172 | raeburn@mit.edu
  0.96% |    3 |  0.59% |     9827 | adam@nostrum.com
  0.96% |    3 |  0.56% |     9199 | tjc@ecs.soton.ac.uk
  0.96% |    3 |  0.49% |     8154 | garmitage@swin.edu.au
  0.64% |    2 |  0.52% |     8648 | hgs@cs.columbia.edu
  0.64% |    2 |  0.43% |     7061 | john.loughney@kolumbus.fi
  0.64% |    2 |  0.43% |     7054 | william@elan.net
  0.64% |    2 |  0.41% |     6820 | tytso@mit.edu
  0.64% |    2 |  0.41% |     6706 | pekkas@netcore.fi
  0.64% |    2 |  0.39% |     6368 | sbrim@cisco.com
  0.64% |    2 |  0.38% |     6364 | joel@stevecrocker.com
  0.32% |    1 |  0.64% |    10657 | cook@cookreport.com
  0.64% |    2 |  0.31% |     5130 | mankin@psg.com
  0.64% |    2 |  0.27% |     4506 | emmanuel.desmet@alcatel.be
  0.32% |    1 |  0.54% |     8918 | dan.grossman@motorola.com
  0.32% |    1 |  0.50% |     8290 | doug@intellical.net
  0.32% |    1 |  0.46% |     7575 | sean_dorman@yahoo.com
  0.32% |    1 |  0.40% |     6653 | jonne.soininen@nokia.com
  0.32% |    1 |  0.35% |     5801 | peter@echnaton.serveftp.com
  0.32% |    1 |  0.35% |     5734 | adrian@olddog.co.uk
  0.32% |    1 |  0.34% |     5685 | lisa@osafoundation.org
  0.32% |    1 |  0.33% |     5431 | edj@nortel.com
  0.32% |    1 |  0.33% |     5409 | dassa@dhs.org
  0.32% |    1 |  0.32% |     5348 | joelja@darkwing.uoregon.edu
  0.32% |    1 |  0.31% |     5075 | leiba@watson.ibm.com
  0.32% |    1 |  0.28% |     4703 | everson@evertype.com
  0.32% |    1 |  0.28% |     4674 | jschnizl@cisco.com
  0.32% |    1 |  0.27% |     4418 | john@jck.com
  0.32% |    1 |  0.27% |     4385 | townsley@cisco.com
  0.32% |    1 |  0.26% |     4353 | sayrer@gmail.com
  0.32% |    1 |  0.25% |     4145 | mat@cisco.com
  0.32% |    1 |  0.25% |     4097 | kent@songbird.com
  0.32% |    1 |  0.25% |     4066 | julien.maisonneuve@alcatel.com
  0.32% |    1 |  0.24% |     3923 | steves@shentel.net
  0.32% |    1 |  0.22% |     3692 | froomkin@law.miami.edu
  0.32% |    1 |  0.22% |     3643 | bmanning@vacation.karoshi.com
  0.32% |    1 |  0.22% |     3594 | mstjohns@mindspring.com
  0.32% |    1 |  0.21% |     3511 | dotis@mail-abuse.org
  0.32% |    1 |  0.21% |     3504 | jabley@isc.org
  0.32% |    1 |  0.21% |     3488 | llynch@darkwing.uoregon.edu
  0.32% |    1 |  0.21% |     3484 | randy_presuhn@mindspring.com
  0.32% |    1 |  0.21% |     3426 | presnick@qualcomm.com
  0.32% |    1 |  0.20% |     3351 | hartmans-ietf-ietf@mit.edu
  0.32% |    1 |  0.20% |     3337 | mohta@necom830.hpcl.titech.ac.jp
  0.32% |    1 |  0.20% |     3327 | cyrus@daboo.name
  0.32% |    1 |  0.20% |     3317 | chelliot@cisco.com
  0.32% |    1 |  0.20% |     3279 | tbray@textuality.com
  0.32% |    1 |  0.20% |     3225 | cowan@ccil.org
  0.32% |    1 |  0.19% |     3169 | misha.wolf@reuters.com
  0.32% |    1 |  0.19% |     3104 | hannigan@gmail.com
  0.32% |    1 |  0.18% |     3007 | francis.dupont@point6.net
  0.32% |    1 |  0.18% |     2988 | dot@dotat.at
  0.32% |    1 |  0.18% |     2930 | sommerfeld@sun.com
  0.32% |    1 |  0.18% |     2899 | philip_matthews@magma.ca
  0.32% |    1 |  0.17% |     2890 | scott@kitterman.com
  0.32% |    1 |  0.17% |     2835 | ekr@networkresonance.com
  0.32% |    1 |  0.15% |     2546 | rdunlap@xenotime.net
  0.32% |    1 |  0.15% |     2469 | paul.hoffman@vpnc.org
  0.32% |    1 |  0.00% |        0 | tmp
--------+------+--------+----------+------------------------
100.00% |  312 |100.00% |  1653740 | Total

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 15:23:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2Der-0002Gq-Ej; Thu, 26 Jan 2006 15:23:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Deo-0002EF-91
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 15:23:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22152
	for ; Thu, 26 Jan 2006 15:22:18 -0500 (EST)
Received: from boole.openldap.org ([204.152.186.50] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Don-0004en-Kg
	for ietf@ietf.org; Thu, 26 Jan 2006 15:34:12 -0500
Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com
	[24.205.218.53] (may be forged)) (authenticated bits=0)
	by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k0QKNc5e081714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Jan 2006 20:23:39 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <7.0.0.16.0.20060126122025.0370a860@OpenLDAP.org>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 26 Jan 2006 12:23:14 -0800
To: Frank Ellermann 
From: "Kurt D. Zeilenga" 
In-Reply-To: <43D90758.7229@xyzzy.claranet.de>
References: 
	<43D90758.7229@xyzzy.claranet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: ietf@ietf.org
Subject: Re: Protocol Action: 'LDAP: Internationalized String
 Preparation' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 09:31 AM 1/26/2006, Frank Ellermann wrote:
>The IESG wrote:
>>  as a Proposed Standard
>Mostly editorial nits:

I will work with the RFC-Editor to address the editorial
issues during AUTH48.  As far as any non-Editorial issue,
I suggest you bring it up with the responsible AD as any
non-Editorial change at this stage would normally require
his approval to make.

Kurt 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 16:00:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2EEi-00070b-A1; Thu, 26 Jan 2006 16:00:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2EEg-00070L-2e
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 16:00:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25914
	for ; Thu, 26 Jan 2006 15:59:21 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2EOf-0006PS-3O
	for ietf@ietf.org; Thu, 26 Jan 2006 16:11:16 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0QL0cgx023760
	for ; Thu, 26 Jan 2006 16:00:38 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA24838
	for ; Thu, 26 Jan 2006 16:00:38 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Thu, 26 Jan 2006 16:00:37 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C8863AD@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'ietf@ietf.org'" 
Date: Thu, 26 Jan 2006 16:00:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: RE: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Anthony,

...
--> 
--> Set a rolling monthly quota, then.  Nobody constantly sends a long
--> stream of consistently productive messages.
--> 
--> 

This is simply not true.  All one needs to do is publish a
crucial document relevant to the working groups charter, 
and important to understanding the rest of the work, and
one will be inundated with questions.

The most productive way to deal with questions in a working
group is to answer them publicly on the list.  To avoid the
trip wire, however, most people woul simply answer specific
questions off-line.  That would be BAD.

Debate on work in progress is critical, must be in public
at least much of the time and will usually involve a small 
number of people - authors in particular - who simply must 
participate.  On several occasions, I have seen productive 
debate on critical drafts take more than a month in some
working groups.

--
Eric

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 16:11:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2EOu-0002ab-Bi; Thu, 26 Jan 2006 16:11:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2EOq-0002ZK-FH; Thu, 26 Jan 2006 16:11:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28671;
	Thu, 26 Jan 2006 16:09:51 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F2EYq-0007T2-Eu; Thu, 26 Jan 2006 16:21:45 -0500
Received: from [10.0.0.127] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001588677.msg; Thu, 26 Jan 2006 22:13:25 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Thu, 26 Jan 2006 10:02:18 -0400
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" , 
Message-ID: 
Thread-Topic: Interim meetings planning [was Softwires Interim Meeting]
Thread-Index: AcYigR47XRCkKI50Edq9tAANky3PwA==
In-Reply-To: <12012B00949A38FBE4B2794F@B50854F0A9192E8EC6CDA126>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060126:iesg@ietf.org::ZkrwYURjNYkzEyOQ:00001IO7
X-Return-Path: jordi.palet@consulintel.es
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00 autolearn=ham 
	version=3.0.4
X-Spam-Processed: consulintel.es, Thu, 26 Jan 2006 22:13:26 +0100
X-MDAV-Processed: consulintel.es, Thu, 26 Jan 2006 22:13:28 +0100
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Interim meetings planning [was Softwires Interim Meeting]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi Harald,

In my opinion the 30 days rule is a good one, it may be possible to make it
a bit flexible, just indicating 3-4 weeks before a meeting instead of 30
days. My comment, based on very recent experience, is that the rest of the
Interim meeting planning procedure must be described more explicitly.

The idea is not to have this in a new draft, or if actually we want it, make
it in specific one, not mixed with anything else.

The actual rules on this are at
http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt

"The area directors will evaluate proposed interim meetings and conference
calls to be sure that that the location, timing, etc.  do not unfairly favor
some subset of the potential attendees and that the proposed meeting or call
will not unfairly bias the working group discussions."


This is my proposal:

"Interim meetings must be planned ahead, in order to facilitate a broader
participation, reduce clashes with other meetings or events, and bring the
cost down for the attendees.

The need for them is typically recognized during a main IETF meeting. In
order to allow a fair participation, they need to be announced in the
relevant WG mail exploder 60 days in advance of the expected meeting date
with a request for candidate hosts and dates. Typically this means
announcing it already during the running main IETF meeting which recognized
the need for that. This will also facilitate the planning for some of the
participants.

Once the intention to hold the meeting has been announced, in one week time,
the "hosting" offers should be confirmed to the relevant WG mail exploder.
The co-chair and ADs will provide a summary at the end of that week,
excluding possible identified clashes and the WG will have one more week for
the a vote on that.

All the process must be made openly in the mail exploder in order to allow
certain interaction for possible small variations during the 1 week proposal
time.

The final decision should be taken at least 6 weeks in advance to the
meeting.

The ADs will base its decision in the mailing list vote, prioritizing the
participation of those which have work related to the meeting target and
indicate their interest in attending. In any case the target is to not
unfairly favor some subset of other potential attendees in such way that the
proposed meeting will not unfairly bias the working group discussions.

The ADs should consider not holding the meeting if there is an impossibility
for key contributors with existing work to attend.

Is expected that the meeting is organized 3-4 weeks ahead of a full IETF
meeting, unless the AD says otherwise."

This could be represented as:

   60(+) days - Announcement of Intention to hold it          3-4 weeks
/------------------------------------------------------\/----------------\

IETF                           Int. m. announced      Int. m.           IETF
|-----------|-------------|------------|----------------|-----------------|
            |   1 week    |   1 week         6(+) weeks
            |             |
            |             +------> start of voting 1 week period
            +--------------------> start of proposals 1 week period


How do you feel about this ?

Regards,
Jordi

PS: May be we need something similar for conference calls, but the timing
should be different


> De: Harald Tveit Alvestrand 
> Responder a: 
> Fecha: Tue, 24 Jan 2006 15:15:04 -0800
> Para: , "ietf@ietf.org" 
> Asunto: Re: Softwires Interim Meeting
> 
> 
> 
> --On 24. januar 2006 18:08 -0400 JORDI PALET MARTINEZ
>  wrote:
> 
>> In order to avoid this happening again, I'm working in some more clear
>> suggestions for rules on how to adequately plan Interim meetings. I will
>> circulate them ASAP.
> 
> I wonder if that's the right approach.....
> 
> the original impetus for the "30 day rule" was a situation where we had a
> non-US IETF (I think it was Adelaide), and suddenly were hit by a flurry of
> requests for "interim" meetings a week or two before or afte the IETF
> meeting - all of them intending to be in the US.
> 
> The interpretation of some was that this looked like an attempt by US
> participants to avoid the expense of going overseas, leading to a
> perception that they thought it was fair that overseas participants always
> paid the cost of participating in US meetings, but not vice versa.
> 
> In this case, the IETF meeting is in the US, and the interim meeting is not
> - so the foot may be in the other mouth, as the saying goes.
> 
> If making rules, I'd say "30 days is the norm. It's a rule unless the AD
> says otherwise; the AD's decision has to be published" (so that we can see
> who to blame if the community thinks it's not OK.
> 
> But be careful what's a rule and what's advice, and don't mix too many
> topics into one document..... it destroys the ability to get finished.
> 
>                Harald
> 
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 16:36:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2En6-0007kV-Vn; Thu, 26 Jan 2006 16:36:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2En2-0007j6-Kp
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 16:36:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07462
	for ; Thu, 26 Jan 2006 16:34:51 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Ewz-0002N7-R2
	for ietf@ietf.org; Thu, 26 Jan 2006 16:46:45 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F2Emh-0002VP-9v
	for ietf@ietf.org; Thu, 26 Jan 2006 22:36:03 +0100
Received: from pd9fba981.dip0.t-ipconnect.de ([217.251.169.129])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Thu, 26 Jan 2006 22:36:03 +0100
Received: from nobody by pd9fba981.dip0.t-ipconnect.de with local (Gmexim 0.1
	(Debian)) id 1AlnuQ-0007hv-00
	for ; Thu, 26 Jan 2006 22:36:03 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Thu, 26 Jan 2006 22:35:10 +0100
Organization: 
Lines: 14
Message-ID: <43D9408E.747C@xyzzy.claranet.de>
References: 
	<43D90758.7229@xyzzy.claranet.de>
	<7.0.0.16.0.20060126122025.0370a860@OpenLDAP.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fba981.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Subject: Re: Protocol Action: 'LDAP: Internationalized String
	Preparation' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Kurt D. Zeilenga wrote:

> As far as any non-Editorial issue, I suggest you bring it
> up with the responsible AD as any non-Editorial change at
> this stage would normally require his approval to make.

Actually I was scanning through several dozens of articles
and confused "protocol action" with a "last call", sorry.

Please ignore my security proposal, "3.2 is not 4 or 5" is
probably a well-known stringprep feature.
              
                      Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 16:47:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2Exr-0004m8-Jv; Thu, 26 Jan 2006 16:47:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Exm-0004eq-UN
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 16:47:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10199
	for ; Thu, 26 Jan 2006 16:45:58 -0500 (EST)
Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2F7l-0003Ql-2i
	for ietf@ietf.org; Thu, 26 Jan 2006 16:57:52 -0500
Received: (qmail 89992 invoked from network); 26 Jan 2006 22:36:34 -0000
Received: from softbank219001188003.bbtec.net (HELO
	necom830.hpcl.titech.ac.jp) (219.1.188.3)
	by necom830.hpcl.titech.ac.jp with SMTP; 26 Jan 2006 22:36:34 -0000
Message-ID: <43D9438E.2030705@necom830.hpcl.titech.ac.jp>
Date: Fri, 27 Jan 2006 06:47:58 +0900
From: Masataka Ohta 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: Brian E Carpenter 
References: <20060120185257.GE18960@ccil.org>	<1797258665.20060123163611@atkielski.com>		<0728557.20060124163321@atkielski.com>	<43D683FA.8050502@unfix.org>
	<43D8BB00.1090202@zurich.ibm.com>
	<43D8BECF.1040904@necom830.hpcl.titech.ac.jp>
	<43D8C4FD.1060302@zurich.ibm.com>
In-Reply-To: <43D8C4FD.1060302@zurich.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Proposal for keeping "free speech" but limitting the nuisance
 to the working group (Was: John Cowan supports 3683 PR-action against Jefsey
 Morfin)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian E Carpenter wrote:

>>> A practice I used when I was diffserv chair and we had quite a lot
>>> of off-topic postings was to create a second list, diffserv-interest
>>> (which still exists BTW). The rule for diffserv@ietf.org was "must
>>> be relevant to a chartered work item" and the rule for diffserv-interest
>>> was "must be relevant to diffserv technology."

>> Though I never participated in diffserv WG activities, which was
>> chartered wrongly from the beginning,

> As a matter of fact, I believe that the insistence of the ADs
> involved on a very tightly drawn charter was the main reason that
> the WG succeeded.

As your measure of success is not in technology but in progressing
standardization process, you say the WG succeeded.

>>> People only interested
>>> in the standards work simply ignored the -interest list.

>> They ignored the -interest list and the technology.

> Are you referring to the many vendors that implemented
> it, or the many enterprises that have deployed it?

I'm referring to relatively small number of enterprises that
have depoyed it.

						Masataka Ohta


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 16:54:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2F4B-0003Eo-3P; Thu, 26 Jan 2006 16:54:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2F48-0003CB-JG
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 16:54:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11013
	for ; Thu, 26 Jan 2006 16:52:31 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2FE7-0003mC-BN
	for ietf@ietf.org; Thu, 26 Jan 2006 17:04:26 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1F2F3w-0004hf-4r; Thu, 26 Jan 2006 16:53:52 -0500
Date: Thu, 26 Jan 2006 16:53:51 -0500
From: John C Klensin 
To: jordi.palet@consulintel.es
Message-ID: 
In-Reply-To: 
References: 
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Interim meetings planning [was Softwires Interim
 Meeting]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Jordi,

Let me make a very general observation, based on my experience
with the IETF.

Where administrative procedures are concerned, the IETF
functions well when the IESG is given general guidance by the
community but then applies good judgment and discretion to the
situations that arise.  If the community observes that the
IESG's judgment is not good enough, we readjust the general
guidance -- by complaints to individual ADs, by notes to the
IESG, by discussion on the IETF list, or even via appeals if
that is needed.  If one or more specific ADs regularly abuse
that discretionary authority, they get abused in return on
mailing lists, in plenaries, in discussions with nomcoms, and,
if necessary, by recalls or at least serious discussions of
recalls.  

By contrast, when we try to write down the specific rules that
should be applied, or the list of rules or steps they should use
in making decisions, and try to reach consensus on them, two
things happen, and happen over and over again:

	(1) We spend (I would say "waste", but you may
	reasonably disagree) a huge amount of time discussing
	both the details of the proposals and whether or not the
	proposals are appropriate.  In my personal opinion, the
	IETF would be a better and more effective place to get
	work done if a higher percentage of the community's
	energy went into technical work than into discussions of
	procedural details.
	
	(2) We get the details wrong, resulting in more time
	being spent correcting the details of the rules that,
	IMO, we might have been better off not having in the
	first place.

In addition, if we get the details seriously wrong, the IESG has
historically responded by applying a meta-rule.  That meta-rule
is that their first obligation is to keep the IETF functioning.
And, on that basis, once they conclude that whatever has been
written down and established by consensus makes no sense, they
simply ignore ignore it.   That action creates a very unhappy
and unhealthy environment, whether it is appealed or not, but
often may still be better than the alternative.

So, for a case like this, I suggest that you might want to have
a conversation, with any AD you think is likely to listen, about
whether the present guidance is sufficient and whether
additional guidance or discussion would help.  ADs persuading
other ADs about IESG matters and customs can be far more
effective than any of us writing I-Ds to pin down details.  If
there are no ADs with whom you feel that you can have such a
conversation, then I think you need to chat with the Nomcom but
I, at least, have generally found ADs to be receptive on these
sorts of issues... even ADs with whom I generally don't get
along well (not that there are any of those on the current IESG).

Let's try to avoid yet another round of stretched-out
discussions on, e.g., how many days constitutes adequate notice,
how to measure the accessibility of a location, what conditions
are sufficient to justify an exception, and whatever other
questions start to arise as soon as one tries to lock down
specific rules.  If an interim meeting is announced that is
likely to cause specific harm (as distinct from being an issue
of principles about dates and locations), complain to the
relevant AD and, if necessary, appeal the decision to approve
the meeting.   But most of us, yourself certainly included, have
more productive things to do with our time than starting another
one of these procedural debate threads.

Just my opinion, of course.
     john


--On Thursday, 26 January, 2006 10:02 -0400 JORDI PALET MARTINEZ
 wrote:

> Hi Harald,
> 
> In my opinion the 30 days rule is a good one, it may be
> possible to make it a bit flexible, just indicating 3-4 weeks
> before a meeting instead of 30 days. My comment, based on very
> recent experience, is that the rest of the Interim meeting
> planning procedure must be described more explicitly.
>
> The idea is not to have this in a new draft, or if actually we
> want it, make it in specific one, not mixed with anything else.
> 
> The actual rules on this are at
> http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt
> 
> "The area directors will evaluate proposed interim meetings
> and conference calls to be sure that that the location,
> timing, etc.  do not unfairly favor some subset of the
>...


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 17:33:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2FgN-0008AZ-Am; Thu, 26 Jan 2006 17:33:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2FgL-000891-4d
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 17:33:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13392
	for ; Thu, 26 Jan 2006 17:31:59 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2FqL-0004sD-UE
	for ietf@ietf.org; Thu, 26 Jan 2006 17:43:55 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0QMXHuD002568
	for ; Thu, 26 Jan 2006 23:33:17 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 23:33:17 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1799364776.20060126233317@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <43D8FA96.3070907@andybierman.com>
References: 
	<43D7F1C5.9080602@andybierman.com>
	<1182823182.20060126050611@atkielski.com>
	<43D855A4.7080007@andybierman.com>
	<11410503317.20060126170906@atkielski.com>
	<43D8FA96.3070907@andybierman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Andy Bierman writes:

> If we did this, our mailing lists would be bombarded with SPAM
> from non-subscribers.

Then accept e-mail only from subscribers.

> There is an appeals process (of that we are too painfully aware)
> that can be used for people who are told by a WG Chair that
> they are using the mailing list in an inappropriate manner, and still
> insist on continuing their behavior.

It's still subject to human bias.

> I have found that only the worst managers deal with
> bad apples by burdening the entire group with oppressive rules.

I agree.  But managers who apply oppressive rules selectively are just
as bad.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 17:37:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2Fjg-0000m3-OZ; Thu, 26 Jan 2006 17:37:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Fje-0000lT-N5
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 17:36:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13651
	for ; Thu, 26 Jan 2006 17:35:25 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Ftf-0004ys-ES
	for ietf@ietf.org; Thu, 26 Jan 2006 17:47:21 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0QMaW1g002712
	for ; Thu, 26 Jan 2006 23:36:32 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 23:36:32 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1279169698.20060126233632@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060126173411.DA6C686AEA@mercury.lcs.mit.edu>
References: <20060126173411.DA6C686AEA@mercury.lcs.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Noel Chiappa writes:

> In that case, there's no harm in the rest of us deciding we don't need the
> dubious "assistance" of few of the most troublesome, and least productive, is
> there?

Actually there is, because there's very little correlation between
being "troublesome" on a mailing list and being a bad engineer.  This
is particularly true when any failure to agree with the majority is
interpreted as "trouble."  People who disagree are usually the motors
of change, and therefore of problem resolution.  Restricting
discussion to those who wish only to maintain conformity and consensus
in a happy little community makes for very little "trouble," but also
eliminates any real purpose for the discussion forum.

Maybe anyone who engages in personal attacks should be banned.  What
do you think?


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 17:38:49 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2FlR-00012C-5Y; Thu, 26 Jan 2006 17:38:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2FlO-000124-TY
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 17:38:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13809
	for ; Thu, 26 Jan 2006 17:37:14 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2FvQ-00053R-E1
	for ietf@ietf.org; Thu, 26 Jan 2006 17:49:09 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0QMca0u002722
	for ; Thu, 26 Jan 2006 23:38:36 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 23:38:36 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <103556383.20060126233836@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <200601262014.k0QKE2nU012126@cichlid.raleigh.ibm.com>
References: <200601262014.k0QKE2nU012126@cichlid.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Subject: Re: Weekly posting summary for ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Thomas Narten writes:

> [note: I find this type of summary to be a useful tool for
> highlighting certain aspects of list traffic. With Brian Carpenter's
> blessing, I plan on making this a regular feature for the ietf list.]
>
> Total of 312 messages in the last 7 days ending midnight January 25.

Cool.  Can you do it for the last two years, just to provide a more
realistic perspective?  Just to see if alleged "troublemakers" are
also generating high volumes of message traffic.

It would also be nice to see if all those "good engineers" are silent,
or nearly so.  If so, that would partly support the hypothesis that
good engineers post infrequently, but at the same time it would render
the list without any real purpose.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 17:41:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2Fnq-0001Ea-05; Thu, 26 Jan 2006 17:41:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Fno-0001EO-3U
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 17:41:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13983
	for ; Thu, 26 Jan 2006 17:39:43 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Fxq-00057S-K5
	for ietf@ietf.org; Thu, 26 Jan 2006 17:51:39 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0QMf6LX002752
	for ; Thu, 26 Jan 2006 23:41:06 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Thu, 26 Jan 2006 23:41:06 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <274931316.20060126234106@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <313680C9A886D511A06000204840E1CF0C8863AD@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF0C8863AD@whq-msgusr-02.pit.comms.marconi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by freebie.atkielski.com
	id k0QMf6LX002752
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: quoted-printable
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Gray, Eric writes:

> This is simply not true.  All one needs to do is publish a
> crucial document relevant to the working groups charter,=20
> and important to understanding the rest of the work, and
> one will be inundated with questions.

Then maybe message traffic is not a reliable indicator of
"disturbance"; in which case those here who attempt to associate the
two are either na=EFve or disingenuous.

> Debate on work in progress is critical, must be in public
> at least much of the time and will usually involve a small=20
> number of people - authors in particular - who simply must=20
> participate.

So why is it bad when a small number of people consistently disagree
and post many messages in consequence?  How can you have critical
public debate without lots of message traffic and disagreement?


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 17:51:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2Fy0-0007gl-5b; Thu, 26 Jan 2006 17:51:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Fxx-0007gM-4L
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 17:51:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14743
	for ; Thu, 26 Jan 2006 17:50:12 -0500 (EST)
Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2G7z-0005V7-76
	for ietf@ietf.org; Thu, 26 Jan 2006 18:02:08 -0500
Received: from [71.254.17.114] (HELO JMHLap3.stevecrocker.com)
	by execdsl.com (CommuniGate Pro SMTP 4.2.7)
	with ESMTP id 12944072 for ietf@ietf.org;
	Thu, 26 Jan 2006 15:47:59 -0700
Message-Id: <6.2.1.2.0.20060126174556.03287808@mail.stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 26 Jan 2006 17:51:08 -0500
To: IETF Discussion 
From: "Joel M. Halpern" 
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Subject: Re: I-D ACTION:draft-hartman-mailinglist-experiment-00.txt 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This experiment is a good idea.

Joel M. Halpern

At 06:50 PM 1/24/2006, you wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Experimental Procedure for  LongTerm 
> Suspensions from Mailing Lists
>         Author(s)       : S. Hartman
>         Filename        : draft-hartman-mailinglist-experiment-00.txt
>         Pages           : 8
>         Date            : 2006-1-24
>
>    Discussion in the community has begun to question whether RFC 3683
>    and RFC 3934 provide the appropriate flexibility for managing IETF
>    mailing lists.  This document is an RFC 3933  experiment designed to
>    allow the community to experiment with a broader set of tools for
>    mailing list management while trying to determine what the long-term
>    guidelines should be.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hartman-mailinglist-experiment-00.txt


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 18:42:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2Gko-0003L1-TY; Thu, 26 Jan 2006 18:42:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Gkn-0003Kt-J9
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 18:42:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17427
	for ; Thu, 26 Jan 2006 18:40:40 -0500 (EST)
Received: from rzcomm22.rz.tu-bs.de ([134.169.9.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Gup-0006rT-AF
	for ietf@ietf.org; Thu, 26 Jan 2006 18:52:36 -0500
Received: from rzis5.rz.tu-bs.de (rzis5.rz.tu-bs.de [134.169.9.193])
	by rzcomm22.rz.tu-bs.de (8.13.4/8.13.4) with ESMTP id k0QNgA5C015027
	for ; Fri, 27 Jan 2006 00:42:10 +0100
	(envelope-from n.zrelli@tu-bs.de)
Received: (from apache@localhost)
	by rzis5.rz.tu-bs.de (8.11.6/8.11.6) id k0QNg9729857
	for ietf@ietf.org; Fri, 27 Jan 2006 00:42:09 +0100
X-Authentication-Warning: rzis5.rz.tu-bs.de: apache set sender to
	n.zrelli@tu-bs.de using -f
Received: from 134.169.9.189 ( [134.169.9.189])
Message-ID: <1138318929.43d95e5107fa8@webmail.tu-bs.de>
Date: Fri, 27 Jan 2006 00:42:09 +0100
From: Nejd Zrelli 
To: ietf 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.1
X-Originating-IP: 134.169.9.189
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 8bit
Subject: Scheduling in WLAN
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Hallo!

I am sorry if I am not supposed to send this message in this list.
I have problems in the choose of a real time scheduling algorithm for packets 
in a wireless LAN (802.11b).
My project is the transmission of MPEG4 over WLAN and I'm trying to use a PEP 
(Performance Enhancing Proxy) to do that.

thanks,

Nejd

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 18:45:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2GnU-0003pW-IK; Thu, 26 Jan 2006 18:45:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2GnR-0003oT-MA
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 18:44:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17549
	for ; Thu, 26 Jan 2006 18:43:24 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2GxU-0006ut-PF
	for ietf@ietf.org; Thu, 26 Jan 2006 18:55:21 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F2GnF-0002kZ-E9; Thu, 26 Jan 2006 15:44:46 -0800
Message-Id: <6.2.3.4.2.20060127001804.05f2a7b0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Fri, 27 Jan 2006 00:25:38 +0100
To: Thomas Narten , ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <200601262014.k0QKE2nU012126@cichlid.raleigh.ibm.com>
References: <200601262014.k0QKE2nU012126@cichlid.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-25B74EED
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc: 
Subject: Re: Weekly posting summary for ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Thomas,
this kind of filtering is interesting. From previous experience on 
DoT (denial of thinking) work,

- you should differentiate the genuine text and the replied text. 
This is a technique to keep a maximum text. To make the reading 
longer. You will note that people cutting off the old text do not 
carry negative filibustering.
- I suggest you keep that data for you and IESG. This kind of data 
are important to organise DoT. For example, should I want to increase 
the filibustering I would send a mail to Anthony  or to Sam Hartman 
(different possible responses, but possible same wheight).

BTW do you use a specialised tool or did you develop it? There are 
servers carrying the job and helping mailing list disrupting. May be 
one or two private agency specialised in the job.
jfc


At 21:14 26/01/2006, Thomas Narten wrote:

>[note: I find this type of summary to be a useful tool for
>highlighting certain aspects of list traffic. With Brian Carpenter's
>blessing, I plan on making this a regular feature for the ietf list.]
>
>Total of 312 messages in the last 7 days ending midnight January 25.
>
>     Messages   |      Bytes        | Who
>--------+------+--------+----------+------------------------
>  11.22% |   35 |  7.24% |   119726 | anthony@atkielski.com
>   5.45% |   17 |  5.21% |    86239 | brc@zurich.ibm.com
>   0.32% |    1 |  9.29% |   153603 | lzhu@windows.microsoft.com
>   3.85% |   12 |  5.11% |    84559 | jordi.palet@consulintel.es
>   3.53% |   11 |  4.78% |    79123 | jefsey@jefsey.com
>   3.85% |   12 |  3.82% |    63209 | harald@alvestrand.no
>   3.53% |   11 |  3.56% |    58870 | tme@multicasttech.com
>   3.85% |   12 |  3.11% |    51425 | hartmans-ietf@mit.edu
>   3.21% |   10 |  3.49% |    57674 | nick.staff@comcast.net
>   2.88% |    9 |  2.94% |    48651 | eric.gray@marconi.com
>   3.21% |   10 |  2.24% |    37115 | nobody@xyzzy.claranet.de
>   0.64% |    2 |  4.55% |    75287 | neil.harwani@gmail.com
>   2.56% |    8 |  1.83% |    30220 | spencer@mcsr-labs.org
>   1.60% |    5 |  2.61% |    43189 | lars.eggert@netlab.nec.de
>   2.24% |    7 |  1.66% |    27438 | dhc2@dcrocker.net
>   1.60% |    5 |  1.67% |    27638 | peter@peter-dambier.de
>   1.28% |    4 |  1.82% |    30133 | jeroen@unfix.org
>   1.92% |    6 |  0.92% |    15245 | johnl@iecc.com
>   1.60% |    5 |  1.14% |    18790 | lear@cisco.com
>   1.28% |    4 |  1.27% |    21052 | hannes.tschofenig@siemens.com
>   1.60% |    5 |  0.95% |    15699 | smb@cs.columbia.edu
>   0.96% |    3 |  1.32% |    21839 | john-ietf@jck.com
>   0.96% |    3 |  1.29% |    21303 | margaret@thingmagic.com
>   1.28% |    4 |  0.94% |    15517 | david.kessens@nokia.com
>   1.28% |    4 |  0.84% |    13954 | bortzmeyer@nic.fr
>   1.28% |    4 |  0.84% |    13907 | rpelletier@isoc.org
>   0.96% |    3 |  1.05% |    17384 | karen.odonoghue@navy.mil
>   0.96% |    3 |  0.99% |    16330 | bwijnen@lucent.com
>   1.28% |    4 |  0.64% |    10650 | jnc@mercury.lcs.mit.edu
>   0.64% |    2 |  1.24% |    20453 | elwynd@dial.pipex.com
>   0.96% |    3 |  0.91% |    15058 | richard@shockey.us
>   0.96% |    3 |  0.83% |    13736 | jmpolk@cisco.com
>   0.96% |    3 |  0.78% |    12960 | ned.freed@mrochek.com
>   0.96% |    3 |  0.73% |    12106 | jhutz@cmu.edu
>   0.96% |    3 |  0.68% |    11294 | ietf@andybierman.com
>   0.96% |    3 |  0.62% |    10172 | raeburn@mit.edu
>   0.96% |    3 |  0.59% |     9827 | adam@nostrum.com
>   0.96% |    3 |  0.56% |     9199 | tjc@ecs.soton.ac.uk
>   0.96% |    3 |  0.49% |     8154 | garmitage@swin.edu.au
>   0.64% |    2 |  0.52% |     8648 | hgs@cs.columbia.edu
>   0.64% |    2 |  0.43% |     7061 | john.loughney@kolumbus.fi
>   0.64% |    2 |  0.43% |     7054 | william@elan.net
>   0.64% |    2 |  0.41% |     6820 | tytso@mit.edu
>   0.64% |    2 |  0.41% |     6706 | pekkas@netcore.fi
>   0.64% |    2 |  0.39% |     6368 | sbrim@cisco.com
>   0.64% |    2 |  0.38% |     6364 | joel@stevecrocker.com
>   0.32% |    1 |  0.64% |    10657 | cook@cookreport.com
>   0.64% |    2 |  0.31% |     5130 | mankin@psg.com
>   0.64% |    2 |  0.27% |     4506 | emmanuel.desmet@alcatel.be
>   0.32% |    1 |  0.54% |     8918 | dan.grossman@motorola.com
>   0.32% |    1 |  0.50% |     8290 | doug@intellical.net
>   0.32% |    1 |  0.46% |     7575 | sean_dorman@yahoo.com
>   0.32% |    1 |  0.40% |     6653 | jonne.soininen@nokia.com
>   0.32% |    1 |  0.35% |     5801 | peter@echnaton.serveftp.com
>   0.32% |    1 |  0.35% |     5734 | adrian@olddog.co.uk
>   0.32% |    1 |  0.34% |     5685 | lisa@osafoundation.org
>   0.32% |    1 |  0.33% |     5431 | edj@nortel.com
>   0.32% |    1 |  0.33% |     5409 | dassa@dhs.org
>   0.32% |    1 |  0.32% |     5348 | joelja@darkwing.uoregon.edu
>   0.32% |    1 |  0.31% |     5075 | leiba@watson.ibm.com
>   0.32% |    1 |  0.28% |     4703 | everson@evertype.com
>   0.32% |    1 |  0.28% |     4674 | jschnizl@cisco.com
>   0.32% |    1 |  0.27% |     4418 | john@jck.com
>   0.32% |    1 |  0.27% |     4385 | townsley@cisco.com
>   0.32% |    1 |  0.26% |     4353 | sayrer@gmail.com
>   0.32% |    1 |  0.25% |     4145 | mat@cisco.com
>   0.32% |    1 |  0.25% |     4097 | kent@songbird.com
>   0.32% |    1 |  0.25% |     4066 | julien.maisonneuve@alcatel.com
>   0.32% |    1 |  0.24% |     3923 | steves@shentel.net
>   0.32% |    1 |  0.22% |     3692 | froomkin@law.miami.edu
>   0.32% |    1 |  0.22% |     3643 | bmanning@vacation.karoshi.com
>   0.32% |    1 |  0.22% |     3594 | mstjohns@mindspring.com
>   0.32% |    1 |  0.21% |     3511 | dotis@mail-abuse.org
>   0.32% |    1 |  0.21% |     3504 | jabley@isc.org
>   0.32% |    1 |  0.21% |     3488 | llynch@darkwing.uoregon.edu
>   0.32% |    1 |  0.21% |     3484 | randy_presuhn@mindspring.com
>   0.32% |    1 |  0.21% |     3426 | presnick@qualcomm.com
>   0.32% |    1 |  0.20% |     3351 | hartmans-ietf-ietf@mit.edu
>   0.32% |    1 |  0.20% |     3337 | mohta@necom830.hpcl.titech.ac.jp
>   0.32% |    1 |  0.20% |     3327 | cyrus@daboo.name
>   0.32% |    1 |  0.20% |     3317 | chelliot@cisco.com
>   0.32% |    1 |  0.20% |     3279 | tbray@textuality.com
>   0.32% |    1 |  0.20% |     3225 | cowan@ccil.org
>   0.32% |    1 |  0.19% |     3169 | misha.wolf@reuters.com
>   0.32% |    1 |  0.19% |     3104 | hannigan@gmail.com
>   0.32% |    1 |  0.18% |     3007 | francis.dupont@point6.net
>   0.32% |    1 |  0.18% |     2988 | dot@dotat.at
>   0.32% |    1 |  0.18% |     2930 | sommerfeld@sun.com
>   0.32% |    1 |  0.18% |     2899 | philip_matthews@magma.ca
>   0.32% |    1 |  0.17% |     2890 | scott@kitterman.com
>   0.32% |    1 |  0.17% |     2835 | ekr@networkresonance.com
>   0.32% |    1 |  0.15% |     2546 | rdunlap@xenotime.net
>   0.32% |    1 |  0.15% |     2469 | paul.hoffman@vpnc.org
>   0.32% |    1 |  0.00% |        0 | tmp
>--------+------+--------+----------+------------------------
>100.00% |  312 |100.00% |  1653740 | Total
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 19:05:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2H7N-0005P2-Tn; Thu, 26 Jan 2006 19:05:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2H7K-0005M0-Ri
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 19:05:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19403
	for ; Thu, 26 Jan 2006 19:03:57 -0500 (EST)
Received: from sccrmhc14.comcast.net ([63.240.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2HHM-0007kD-TB
	for ietf@ietf.org; Thu, 26 Jan 2006 19:15:54 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (sccrmhc14) with SMTP
	id <2006012700050201400dq2aue>; Fri, 27 Jan 2006 00:05:02 +0000
Message-ID: <023601c622d5$27078320$a9087c0a@china.huawei.com>
From: "Spencer Dawkins" 
To: "IETF Discussion" 
References: 
	<6.2.1.2.0.20060126174556.03287808@mail.stevecrocker.com>
Date: Thu, 26 Jan 2006 18:03:48 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION:draft-hartman-mailinglist-experiment-00.txt 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I agree. One question...

As best I can see, the proposed experiment is silent on whether suspension 
from one list has any effect on suspension from other lists, so I'm assuming 
this aspect of RFC 3683 still applies?

(Text is something like "maintainers of any IETF mailing list may, at their 
discretion, also remove posting rights to that IETF mailing list" for a 
period of time not to exceed the remaining period of the suspension from any 
other IETF list?)

Thanks,

Spencer


> This experiment is a good idea.
>
> Joel M. Halpern 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 21:10:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2J4b-00037c-Tw; Thu, 26 Jan 2006 21:10:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2J4a-00037S-J0
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 21:10:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26695
	for ; Thu, 26 Jan 2006 21:09:16 -0500 (EST)
Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2JEd-0002n0-Ul
	for ietf@ietf.org; Thu, 26 Jan 2006 21:21:13 -0500
Received: from [71.254.17.114] (HELO JMHLap3.stevecrocker.com)
	by execdsl.com (CommuniGate Pro SMTP 4.2.7)
	with ESMTP id 12944523 for ietf@ietf.org;
	Thu, 26 Jan 2006 19:07:19 -0700
Message-Id: <6.2.1.2.0.20060126210932.032c0cf8@mail.stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 26 Jan 2006 21:10:31 -0500
To: "IETF Discussion" 
From: "Joel M. Halpern" 
In-Reply-To: <023601c622d5$27078320$a9087c0a@china.huawei.com>
References: 
	<6.2.1.2.0.20060126174556.03287808@mail.stevecrocker.com>
	<023601c622d5$27078320$a9087c0a@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Subject: Re: I-D ACTION:draft-hartman-mailinglist-experiment-00.txt 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

As I read the description of the experiment, when the IESG decides on the 
appropriate response to a specific case, they can decide whether that 
response is a single-list response or a multi-list response.

Yours,
Joel

At 07:03 PM 1/26/2006, Spencer Dawkins wrote:
>I agree. One question...
>
>As best I can see, the proposed experiment is silent on whether suspension 
>from one list has any effect on suspension from other lists, so I'm 
>assuming this aspect of RFC 3683 still applies?
>
>(Text is something like "maintainers of any IETF mailing list may, at 
>their discretion, also remove posting rights to that IETF mailing list" 
>for a period of time not to exceed the remaining period of the suspension 
>from any other IETF list?)
>
>Thanks,
>
>Spencer
>
>
>>This experiment is a good idea.
>>
>>Joel M. Halpern
>
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Thu Jan 26 22:30:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2KJa-00080Y-20; Thu, 26 Jan 2006 22:30:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2KJX-00080R-Th
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 22:30:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01347
	for ; Thu, 26 Jan 2006 22:28:47 -0500 (EST)
From: nick.staff@comcast.net
Received: from sccrmhc13.comcast.net ([204.127.202.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2KTc-0004yG-1X
	for ietf@ietf.org; Thu, 26 Jan 2006 22:40:45 -0500
Received: from smailcenter61.comcast.net ([204.127.205.161])
	by comcast.net (sccrmhc13) with SMTP
	id <20060127033006013001447je>; Fri, 27 Jan 2006 03:30:06 +0000
Received: from [66.229.53.140] by smailcenter61.comcast.net;
	Fri, 27 Jan 2006 03:30:06 +0000
To: Sam Hartman 
Date: Fri, 27 Jan 2006 03:30:06 +0000
Message-Id: <012720060330.1128.43D993BE00028AE300000468220588448400000E9B9CD2050C0702@comcast.net>
X-Mailer: AT&T Message Center Version 1 (Aug  4 2005)
X-Authenticated-Sender: bmljay5zdGFmZkBjb21jYXN0Lm5ldA==
MIME-Version: 1.0
X-Spam-Score: 1.5 (+)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: ietf@ietf.org
Subject: Re: draft-hartmans-mailinglist-experiment
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0174598559=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--===============0174598559==
Content-Type: multipart/alternative;
	boundary="NextPart_Webmail_9m3u9jl4l_1128_1138332606_0"


--NextPart_Webmail_9m3u9jl4l_1128_1138332606_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

I guess to me I feel like all experiments will lead to banned and the effectiveness of the solution is going to be how smoothly it gets there and how much it disrupts the normal course of things.  I could be misunderstanding the whole thing but I feel like productivity will be affected most by the process?
-------------- Original message -------------- 
From: Sam Hartman  

> 
> So, if we don't actually carry out the ban, how do we see whether the 
> ban is successful in meeting the experimental goal of improving 
> productivity? 
> 
> 
--NextPart_Webmail_9m3u9jl4l_1128_1138332606_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit



I guess to me I feel like all experiments will lead to banned and the effectiveness of the solution is going to be how smoothly it gets there and how much it disrupts the normal course of things.  I could be misunderstanding the whole thing but I feel like productivity will be affected most by the process?


-------------- Original message -------------- 
From: Sam Hartman <hartmans-ietf@mit.edu> 

> 
> So, if we don't actually carry out the ban, how do we see whether the 
> ban is successful in meeting the experimental goal of improving 
> productivity? 
> 
> 


--NextPart_Webmail_9m3u9jl4l_1128_1138332606_0--


--===============0174598559==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0174598559==--




From ietf-bounces@ietf.org Fri Jan 27 01:02:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2MgN-0006pL-84; Fri, 27 Jan 2006 01:02:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2MgK-0006pA-LX
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 01:02:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10620
	for ; Fri, 27 Jan 2006 01:00:27 -0500 (EST)
Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2MqP-0001G5-39
	for ietf@ietf.org; Fri, 27 Jan 2006 01:12:27 -0500
Received: from root (helo=think.thunk.org)
	by thunker.thunk.org with local-esmtps 
	(tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32)  (Exim 4.50 #1 (Debian))
	id 1F2MgG-00009Z-PD; Fri, 27 Jan 2006 01:01:57 -0500
Received: from tytso by think.thunk.org with local (Exim 4.50)
	id 1F2MgC-00066a-9m; Fri, 27 Jan 2006 01:01:52 -0500
Date: Fri, 27 Jan 2006 01:01:52 -0500
From: "Theodore Ts'o" 
To: "Anthony G. Atkielski" 
Message-ID: <20060127060152.GA14450@thunk.org>
References: <43D7DEDE.3050803@cisco.com>
	<64EA6FCA33E6A3F95FF4D4EF@B50854F0A9192E8EC6CDA126>
	
	<43D87732.2000205@cisco.com> <43D8BCF9.3070108@zurich.ibm.com>
	<1635686984.20060126171659@atkielski.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1635686984.20060126171659@atkielski.com>
User-Agent: Mutt/1.5.11
X-SA-Exim-Connect-IP: 
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: ietf@ietf.org
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Thu, Jan 26, 2006 at 05:16:59PM +0100, Anthony G. Atkielski wrote:
> Brian E Carpenter writes:
> 
> > Exactly. If a WG group is discussing a dozen separate issues in parallel,
> > an active participant can easily send several dozen *constructive*
> > messages in a day. Our problem with disruptive messages can't be solved
> > by counting bytes.
> 
> Set a rolling monthly quota, then.  Nobody constantly sends a long
> stream of consistently productive messages.

Anthony,

	As a gentle suggestion from one of the Sargeant-At-Arms.  If
you were to keep track of how many messages you have been posting
compared to others, I think you would find that you are one of the
more prolific posters on this thread.  And if you were to stop, take a
breath, and post a single message comprising your thoughts on all of
the messages that you have been reading, and were to self-impose your
own quota on the number of messages you have posted, it would very
likely make the IETF list a more pleasant place to converse.

	This is a discpline that I would recommend to all who are
posting to the IETF list... .but given that you are one of the more
prolific as of late and you seem to have suggested the quota idea
without any idea of the potential irony of that statement, I would
like to commend to you your own suggestion.

	As others have suggested, if you were take as your model the
posting frequency and the thoughtfulness of John Klensin's posts, it
would be hard for you to go wrong.

	Regards,

						- Ted

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 01:37:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2NEe-0004Sr-Fq; Fri, 27 Jan 2006 01:37:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2NEb-0004SY-0S
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 01:37:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12438
	for ; Fri, 27 Jan 2006 01:35:53 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2NOg-0002Dy-C6
	for ietf@ietf.org; Fri, 27 Jan 2006 01:47:51 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k0R6b9fw006473
	for ; Fri, 27 Jan 2006 07:37:09 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Fri, 27 Jan 2006 07:37:09 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <194526399.20060127073709@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060127060152.GA14450@thunk.org>
References: <43D7DEDE.3050803@cisco.com>
	<64EA6FCA33E6A3F95FF4D4EF@B50854F0A9192E8EC6CDA126>
	
	<43D87732.2000205@cisco.com> <43D8BCF9.3070108@zurich.ibm.com>
	<1635686984.20060126171659@atkielski.com>
	<20060127060152.GA14450@thunk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Theodore Ts'o writes:

> As a gentle suggestion from one of the Sargeant-At-Arms.  If
> you were to keep track of how many messages you have been posting
> compared to others, I think you would find that you are one of the
> more prolific posters on this thread.

And if you were to look at the total number of posts over the past
three years, I think you would find that I hardly ever post to this
list at all.

However, I receive thousands of messages from the list, most of which
are of no interest to me, and many of which don't even seem to be
related to the nominal purpose of the list ... and I do not complain,
nor do I suggest that others limit their posting for my convenience.
I understand the value of forums in which freedom of expression is
permitted, and I do not apply double standards.

> And if you were to stop, take a breath, and post a single message
> comprising your thoughts on all of the messages that you have been
> reading, and were to self-impose your own quota on the number of
> messages you have posted, it would very likely make the IETF list a
> more pleasant place to converse.

I don't impose a quota. Quotas are suggestions that others have made,
not me. I only suggested that quotas might be the least of several
evils, for people who cannot resist the temptation to attempt to
silence others with whom they disagree.

If you were to stop and reflect before posting personal attacks on
other people, you, too, could make the list a more pleasant place to
converse.  However, unlike you, I shall not attempt to tell you what
to post or not post.

> This is a discpline that I would recommend to all who are
> posting to the IETF list ...

But not one that you are willing to put into practice, apparently.

> ... but given that you are one of the more
> prolific as of late and you seem to have suggested the quota idea
> without any idea of the potential irony of that statement, I would
> like to commend to you your own suggestion.

I didn't suggest any form of censorship.  I only try to make
suggestions that limit the damages of censorship, since I know that
some people can't live without it.

> As others have suggested, if you were take as your model the
> posting frequency and the thoughtfulness of John Klensin's posts, it
> would be hard for you to go wrong.

If you were to take as your model my total abstinence from ad hominem,
you wouldn't have written your post at all.



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 09:17:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2UPa-0008CF-8N; Fri, 27 Jan 2006 09:17:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2UPY-0008CA-53
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 09:17:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11729
	for ; Fri, 27 Jan 2006 09:15:39 -0500 (EST)
Received: from netcore.fi ([193.94.160.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2UZe-0008My-NS
	for ietf@ietf.org; Fri, 27 Jan 2006 09:27:40 -0500
Received: from netcore.fi (localhost [127.0.0.1])
	by netcore.fi (8.12.8/8.12.8) with ESMTP id k0REGoHa031486
	for ; Fri, 27 Jan 2006 16:16:50 +0200
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0REGoia031483
	for ; Fri, 27 Jan 2006 16:16:50 +0200
Date: Fri, 27 Jan 2006 16:16:50 +0200 (EET)
From: Pekka Savola 
To: ietf@ietf.org
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: ClamAV 0.88/1252/Thu Jan 26 13:03:25 2006 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed 
	version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi,

Looking at the restaurant map, it seems that the IETF65 hotel/venue is 
basically "in the middle of nowhere".  Restaurants are typically 2+ 
miles away, and my guess is that public transportation or walking 
aren't options.

Maybe folks more experienced in the area can shed some light on this. 
Is it expected that folks rent a car in order not to starve, or..? 
Drive 500 taxis back and forth?

It'd be useful to clarify this for planning and preparation purposes.

This statement, "The Wyndham is less than a ten minute walk from the 
Hilton Anatole." is a bit odd -- at least Maporama prints out the 
distance as 22.7 kilometers, 16 mins with a car.  Did I do something 
wrong?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 10:05:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2VAF-00032b-Ha; Fri, 27 Jan 2006 10:05:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VAD-0002zW-Qk
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 10:05:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17302
	for ; Fri, 27 Jan 2006 10:03:53 -0500 (EST)
Received: from mtagate3.de.ibm.com ([195.212.29.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VKN-0002EX-Mb
	for ietf@ietf.org; Fri, 27 Jan 2006 10:15:57 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0RF54Ws158340
	for ; Fri, 27 Jan 2006 15:05:05 GMT
Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com
	[9.149.165.213])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0RF4Ds4055662
	for ; Fri, 27 Jan 2006 16:04:15 +0100
Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0RF4B2b015905 for ; Fri, 27 Jan 2006 16:04:11 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0RF4BbQ015882; Fri, 27 Jan 2006 16:04:11 +0100
Received: from zurich.ibm.com (sig-9-146-219-102.de.ibm.com [9.146.219.102])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA53422;
	Fri, 27 Jan 2006 16:04:07 +0100
Message-ID: <43DA3668.5060200@zurich.ibm.com>
Date: Fri, 27 Jan 2006 16:04:08 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Pekka Savola 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Pekka,

> Maybe folks more experienced in the area can shed some light on this. Is 
> it expected that folks rent a car in order not to starve, or..? Drive 
> 500 taxis back and forth?

There is food on site of course, but taxis (shared!) seem to be needed
for wider choice of restaurants.

> This statement, "The Wyndham is less than a ten minute walk from the 
> Hilton Anatole." is a bit odd -- at least Maporama prints out the 
> distance as 22.7 kilometers, 16 mins with a car.  Did I do something wrong?

You must have. Mapquest says 0.3 miles.

     Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 10:31:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2VZ5-0003B3-Or; Fri, 27 Jan 2006 10:31:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VZ4-0003At-9A
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 10:31:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19193
	for ; Fri, 27 Jan 2006 10:29:33 -0500 (EST)
Received: from netcore.fi ([193.94.160.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2VjD-00039m-01
	for ietf@ietf.org; Fri, 27 Jan 2006 10:41:37 -0500
Received: from netcore.fi (localhost [127.0.0.1])
	by netcore.fi (8.12.8/8.12.8) with ESMTP id k0RFUpHa000801;
	Fri, 27 Jan 2006 17:30:52 +0200
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0RFUphX000798;
	Fri, 27 Jan 2006 17:30:51 +0200
Date: Fri, 27 Jan 2006 17:30:51 +0200 (EET)
From: Pekka Savola 
To: Brian E Carpenter 
In-Reply-To: <43DA3668.5060200@zurich.ibm.com>
Message-ID: 
References: 
	<43DA3668.5060200@zurich.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: ClamAV 0.88/1252/Thu Jan 26 13:03:25 2006 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 
	autolearn=ham version=3.1.0
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Fri, 27 Jan 2006, Brian E Carpenter wrote:
>> This statement, "The Wyndham is less than a ten minute walk from the Hilton 
>> Anatole." is a bit odd -- at least Maporama prints out the distance as 22.7 
>> kilometers, 16 mins with a car.  Did I do something wrong?
>
> You must have. Mapquest says 0.3 miles.

FWIW: there appear to be two locations "2201 Stemmons Freeway, 
Dallas".  Maporama used zip code 75006 for me, while the correct 
appears to be 75207.  I guess this explains the situation.

Based on what I hear on dialogue which happened on wgchairs list on 
this, it's still not clear if you can be expected to be able to walk 
from Wyndham to the venue...

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 10:53:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2VuH-0000DH-Qi; Fri, 27 Jan 2006 10:53:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2VuB-00007r-6E
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 10:52:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21043
	for ; Fri, 27 Jan 2006 10:51:22 -0500 (EST)
Received: from twin.uoregon.edu ([128.223.214.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2W4L-000411-5V
	for ietf@ietf.org; Fri, 27 Jan 2006 11:03:26 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by twin.uoregon.edu (8.13.4/8.13.4) with ESMTP id k0RFqY2w024613;
	Fri, 27 Jan 2006 07:52:34 -0800
Date: Fri, 27 Jan 2006 07:52:34 -0800 (PST)
From: Joel Jaeggli 
X-X-Sender: joelja@twin.uoregon.edu
To: Pekka Savola 
In-Reply-To: 
Message-ID: 
References: 
	<43DA3668.5060200@zurich.ibm.com>
	
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Fri, 27 Jan 2006, Pekka Savola wrote:

> On Fri, 27 Jan 2006, Brian E Carpenter wrote:
>>> This statement, "The Wyndham is less than a ten minute walk from the 
>>> Hilton Anatole." is a bit odd -- at least Maporama prints out the distance 
>>> as 22.7 kilometers, 16 mins with a car.  Did I do something wrong?
>> 
>> You must have. Mapquest says 0.3 miles.
>
> FWIW: there appear to be two locations "2201 Stemmons Freeway, Dallas". 
> Maporama used zip code 75006 for me, while the correct appears to be 75207. 
> I guess this explains the situation.
>
> Based on what I hear on dialogue which happened on wgchairs list on this, 
> it's still not clear if you can be expected to be able to walk from Wyndham 
> to the venue...

There is essentially another hotel and a parking lot between the two 
hotels.

google local is pretty accurate:

http://maps.google.com/maps?f=q&hl=en&q=2015+Market+Center+Boulevard+Dallas,+Texas+75207&btnG=Search&ll=32.797232,-96.824827&spn=0.018759,0.059094

it's about 300 meters, maybe less.

>

-- 
--------------------------------------------------------------------------
Joel Jaeggli  	       Unix Consulting 	       joelja@darkwing.uoregon.edu
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 10:57:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2Vyp-0002iQ-3D; Fri, 27 Jan 2006 10:57:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Vyn-0002h7-64
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 10:57:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21472
	for ; Fri, 27 Jan 2006 10:56:08 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2W8y-0004BP-3v
	for ietf@ietf.org; Fri, 27 Jan 2006 11:08:12 -0500
Received: from [192.168.0.3] (adsl-71-131-93-12.dsl.sntc01.pacbell.net
	[71.131.93.12]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0RFvmwh028406
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2006 07:57:49 -0800
Message-ID: <43DA42D4.4040005@dcrocker.net>
Date: Fri, 27 Jan 2006 07:57:08 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Pekka Savola 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Looking at the restaurant map, it seems that the IETF65 hotel/venue is 
> basically "in the middle of nowhere".  Restaurants are typically 2+ 
> miles away, and my guess is that public transportation or walking aren't 
> options.


Periodically, the IETF venue is quite isolated.

This makes it inconvenient not only for getting to restaurants but also for 
attendees wanting to stay at cheaper hotels.

Frequently it even makes it difficult to just walk around.

d/
-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 11:36:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2Wap-0004YU-SX; Fri, 27 Jan 2006 11:36:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Wam-0004Y9-TX
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 11:36:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24630
	for ; Fri, 27 Jan 2006 11:35:23 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2Wkx-0005Xc-29
	for ietf@ietf.org; Fri, 27 Jan 2006 11:47:28 -0500
Received: (qmail 2191 invoked from network); 27 Jan 2006 16:36:48 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 27 Jan 2006 16:36:48 -0000
Date: 27 Jan 2006 16:36:49 -0000
Message-ID: <20060127163649.84859.qmail@simone.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: 
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: pekkas@netcore.fi
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>This statement, "The Wyndham is less than a ten minute walk from the 
>Hilton Anatole." is a bit odd -- at least Maporama prints out the 
>distance as 22.7 kilometers, 16 mins with a car.  Did I do something 
>wrong?

Whassa matter, 23 km is too far to walk?  Wimp.

Visiting Dallas without a car is like visiting Nome without a parka.
It just isn't done.  I've heard reports of police stopping people for
suspicious behavior, with the behavior being that they were walking.

Rental cars are cheap.  I found one for $17/day at the airport.  Since
a taxi from the airport to the hotel is about $35 each way, a car is
basically the same price and it gives you the option of leaving the
hotel.

Google Maps has an excellent view of the area around the hotel, on
which you can zoom way in and see the individual cars in the parking
lot.  You won't need a parka, but if you plan to do much walking, you
may need a gas mask.

http://maps.google.com/maps?f=q&hl=en&q=2201+N+Stemmons+Freeway,+Dallas,+TX&btnG=Search&t=h&ll=32.801182,-96.827209&spn=0.012193,0.021393&t=h

There are a lot of hotels in the area other than the two on the IETF
web site, easily found through services like Orbitz and Expedia, or by
looking at the satellite map and observing all the swimmming pools,
each of which belongs to a hotel or motel, then clicking Find
Businesses, and tell it you want hotels:

http://maps.google.com/maps?f=l&hl=en&q=hotel&near=2201+N+Stemmons+Freeway,+Dallas,+TX&btnG=Search&ll=32.801182,-96.827209&spn=0.012193,0.014398&t=h

I'm staying at the Marriott Fairfield Inn down the street, for
$99/night which is supposed to include breakfast and WiFi.  Orbitz
wanted me to prepay but I got the same price non-prepay at
marriott.com.  The Wyndam is actually about two blocks south of the
Anatole, inside the bend of the creek.  Google says it's 33 seconds
away by car.

There doesn't appear to be anywhere to eat nearby other than the hotel
restaurants, so you're right, if you don't want to starve, you need a
taxi, a car, or a friend with one.

R's,
John


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 12:35:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2XVJ-0004As-Me; Fri, 27 Jan 2006 12:35:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2JJw-0000wK-6v
	for ietf@megatron.ietf.org; Thu, 26 Jan 2006 21:26:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27642
	for ; Thu, 26 Jan 2006 21:25:07 -0500 (EST)
Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2JU0-0003ES-Kk
	for ietf@ietf.org; Thu, 26 Jan 2006 21:37:04 -0500
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0ITQ00FCNBGYZ0@usaga01-in.huawei.com> for
	ietf@ietf.org; Thu, 26 Jan 2006 18:12:34 -0800 (PST)
Received: from huawei.com (usams01-in [172.18.4.10])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0ITQ00AS5BGXW4@usaga01-in.huawei.com> for
	ietf@ietf.org; Thu, 26 Jan 2006 18:12:34 -0800 (PST)
Received: from [172.24.1.6] (Forwarded-For: [219.234.180.253])
	by usams01-in.huawei.com (mshttpd); Thu, 26 Jan 2006 21:17:06 -0500
Date: Thu, 26 Jan 2006 21:17:06 -0500
From: HarringtonDavid 73653 
To: ietf@ietf.org
Message-id: 
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7BIT
X-Mailman-Approved-At: Fri, 27 Jan 2006 12:35:19 -0500
Subject: Weekly posting summary for ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi,

I strongly encourage the collection of data for understanding mailing list behaviors. However, I have concerns that this information could be interpreted to support specific positions about the benefit or lack thereof associated with mailing list behaviors. There has been no work to develop a reasonable model of mailing list behaviors and the benefits of certain patterns, so making unwarranted assumtions based on these statistics could easily lead to abuse.

I suggest designing an experiment, ala RFC3933, to collect statistical mailing list information for purposes of better understanding how certain patterns positively or negatively impact effectiveness. This collection should be done across a wide variety of mailing lists, e.g., all IETF mailing lists, to ensure an adequately diverse sample universe. Once collected, the data should be correlated to other statistics that are related to WG effectiveness, and be corrrelated to subjective analysis of the effectiveness of a WG. 

This data could then be used to design a better process for identifying and handling mailing list behaviors that might be considered abusive. I do not like adding lots of process; I would rather see us focus on developing technology, but if we need to have process, then let's at least design processes based on the best objective data we can gather.

Some of the analysisI think should be done:
1) is there a correlation between the posting patterns and the timely completion of milestones in a WG?
2) is there a correlation between posting patterns and the time between first publication of an I-D and its subsequent adoption by the WG? 
3) is there a correlation between posting patterns and the time between adoption of an I-D by the WG and the publication as a Proposed Standard?
4) Are there specific points in the provess when the posting pattern behaviors change? (such as after PS apporoval but before RFC publication, or during WGLC, or immediately after and updated I-D is posted?, etc.
5) in the subjective view of the chairs **of many WGs, not just ones that had problem posters**, did posting behaviors help or hurt the forward progress of the WG?
6) maybe a survey should be done for all WG participants to get their subjective view of whether posting behaviors helped or hurt WG process

I would be willing to help design and document a data collection experiment to contribute to a better understanding of the factors that impact the effectiveness of IETF processes.

David Harrington
dharrington@huawei.com



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 12:37:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2XXK-0005EE-PZ; Fri, 27 Jan 2006 12:37:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2XXJ-0005DY-1g
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 12:37:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29254
	for ; Fri, 27 Jan 2006 12:35:51 -0500 (EST)
Received: from colibri.verisign.com ([65.205.251.74])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2XhV-0007XN-Hd
	for ietf@ietf.org; Fri, 27 Jan 2006 12:47:57 -0500
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com
	[65.205.251.35])
	by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0RHbEK8022194;
	Fri, 27 Jan 2006 09:37:14 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by
	MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 27 Jan 2006 09:37:14 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 27 Jan 2006 09:37:15 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD378CE19D@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Thread-Topic: IETF65 hotel location
Thread-Index: AcYjWlT4VDhjSFzfQ429xHbq/5raCgADcpzw
From: "Hallam-Baker, Phillip" 
To: "Joel Jaeggli" ,
	"Pekka Savola" 
X-OriginalArrivalTime: 27 Jan 2006 17:37:14.0209 (UTC)
	FILETIME=[4F62E510:01C62368]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Cue ten further emails describing various Google Earth mashups that
correlate restaurants with capacity, wait time and geek acceptability=20

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20
> Behalf Of Joel Jaeggli
> Sent: Friday, January 27, 2006 7:53 AM
> To: Pekka Savola
> Cc: ietf@ietf.org
> Subject: Re: IETF65 hotel location
>=20
> On Fri, 27 Jan 2006, Pekka Savola wrote:
>=20
> > On Fri, 27 Jan 2006, Brian E Carpenter wrote:
> >>> This statement, "The Wyndham is less than a ten minute=20
> walk from the=20
> >>> Hilton Anatole." is a bit odd -- at least Maporama prints out the=20
> >>> distance as 22.7 kilometers, 16 mins with a car.  Did I=20
> do something wrong?
> >>=20
> >> You must have. Mapquest says 0.3 miles.
> >
> > FWIW: there appear to be two locations "2201 Stemmons=20
> Freeway, Dallas".=20
> > Maporama used zip code 75006 for me, while the correct=20
> appears to be 75207.=20
> > I guess this explains the situation.
> >
> > Based on what I hear on dialogue which happened on wgchairs list on=20
> > this, it's still not clear if you can be expected to be=20
> able to walk=20
> > from Wyndham to the venue...
>=20
> There is essentially another hotel and a parking lot between=20
> the two hotels.
>=20
> google local is pretty accurate:
>=20
> http://maps.google.com/maps?f=3Dq&hl=3Den&q=3D2015+Market+Center+Bou
levard+Dallas,+Texas+75207&btnG=3DSearch&ll=3D32.797232,-96.824827>
&spn=3D0.018759,0.059094
>=20
> it's about 300 meters, maybe less.
>=20
> >
>=20
> --
> --------------------------------------------------------------
> ------------
> Joel Jaeggli  	       Unix Consulting 	      =20
joelja@darkwing.uoregon.edu
> GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000=20
> 35AB B67F 56B2
>=20
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>=20
>=20

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 14:40:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2ZSr-0002e4-W4; Fri, 27 Jan 2006 14:40:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ZSp-0002dq-5T
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 14:40:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08211
	for ; Fri, 27 Jan 2006 14:39:22 -0500 (EST)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Zd1-0002vm-Ek
	for ietf@ietf.org; Fri, 27 Jan 2006 14:51:28 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	k0RJbwxT024931; Fri, 27 Jan 2006 21:38:06 +0200
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 27 Jan 2006 21:40:45 +0200
Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by
	esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); 
	Fri, 27 Jan 2006 21:40:09 +0200
Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain
	[127.0.0.1])
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id
	k0RJe8K3005449; Fri, 27 Jan 2006 11:40:08 -0800
Received: (from kessens@localhost)
	by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id
	k0RJe7bo005447; Fri, 27 Jan 2006 11:40:07 -0800
Date: Fri, 27 Jan 2006 11:40:07 -0800
From: David Kessens 
To: dcrocker@bbiw.net
Message-ID: <20060127194007.GA5219@nokia.com>
References: 
	<43DA42D4.4040005@dcrocker.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43DA42D4.4040005@dcrocker.net>
User-Agent: Mutt/1.4.1i
X-OriginalArrivalTime: 27 Jan 2006 19:40:10.0111 (UTC)
	FILETIME=[7BC438F0:01C62379]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: Pekka Savola , ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Dave,

On Fri, Jan 27, 2006 at 07:57:08AM -0800, Dave Crocker wrote:
> 
> This makes it inconvenient not only for getting to restaurants but
> also for attendees wanting to stay at cheaper hotels.

There is a wide selection of cheaper hotels available around the
meeting hotel that are all walking distance.

Restaurants at walking distance are indeed problematic. However, the
hotel has quite a few choices of it's own and there are quite a few
very good restaurants a short cab ride away.

We realize that this is not ideal. Site selection is a compromise.

To give a bit of background: unfortunately, the hotel selection
process started very late which limited the amount of available venues
such that we didn't had the luxury to select a hotel that could
satisfy all criteria as much as we would have liked. We as Nokia
offered to host the meeting when we heard at a fairly late stage that
IETF was still in need for a host and that Dallas was being considered
by the secretariat (Our US headquarters are in Dallas).

My personal hope is that the selection process will happen more in
advance future now that we have Ray in place as our IAD.

> Frequently it even makes it difficult to just walk around.

As everything in Dallas, this hotel is quite large. Just a walk around
the premises will be quite a bit. 

David Kessens
---

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 14:45:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2ZXM-0003ZE-J4; Fri, 27 Jan 2006 14:45:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ZXK-0003Xw-1g
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 14:45:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08508
	for ; Fri, 27 Jan 2006 14:44:01 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2ZhW-00033k-Co
	for ietf@ietf.org; Fri, 27 Jan 2006 14:56:07 -0500
Received: from [192.168.0.3] (adsl-71-131-93-12.dsl.sntc01.pacbell.net
	[71.131.93.12]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0RJjsev005309
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2006 11:45:54 -0800
Message-ID: <43DA784A.8050108@bbiw.net>
Date: Fri, 27 Jan 2006 11:45:14 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: David Kessens 
References: 
	<43DA42D4.4040005@dcrocker.net> <20060127194007.GA5219@nokia.com>
In-Reply-To: <20060127194007.GA5219@nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dcrocker@bbiw.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org




> There is a wide selection of cheaper hotels available around the
> meeting hotel that are all walking distance.

The mapping page that the anatole provides seemed to show the closest 
alternative as about .8 miles, and seemed to require walking down a problematic 
street.  Google seems to show it more like .2 and straightforward.

sorry for the confusion.

d/

-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 15:03:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2ZoK-0003CQ-SH; Fri, 27 Jan 2006 15:03:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Zo6-0003B3-QI
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 15:02:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10031
	for ; Fri, 27 Jan 2006 15:01:22 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2ZyI-0003h1-8a
	for ietf@ietf.org; Fri, 27 Jan 2006 15:13:28 -0500
Received: (qmail 12192 invoked from network); 27 Jan 2006 20:02:46 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 27 Jan 2006 20:02:46 -0000
Date: 27 Jan 2006 20:02:47 -0000
Message-ID: <20060127200247.34217.qmail@simone.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <198A730C2044DE4A96749D13E167AD378CE19D@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>Cue ten further emails describing various Google Earth mashups that
>correlate restaurants with capacity, wait time and geek acceptability 

If we could morph it into a signup system that distributed people
according to restauant capacity and avoided the problem that someone
says "I hear there's a burrito place on X street" and a herd of 300
IETFers shows up there, since they don't know any other places to go,
then you'd really have something.

R's,
John




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 15:12:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2ZxO-0006V3-6W; Fri, 27 Jan 2006 15:12:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ZxM-0006Sw-1A
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 15:12:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10600
	for ; Fri, 27 Jan 2006 15:10:55 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F2a7Y-0003xg-Vy
	for ietf@ietf.org; Fri, 27 Jan 2006 15:23:02 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-3.cisco.com with ESMTP; 27 Jan 2006 12:12:07 -0800
X-IronPort-AV: i="4.01,227,1136188800"; 
	d="scan'208"; a="397393319:sNHT2193928640"
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0RKC6WF026951;
	Fri, 27 Jan 2006 12:12:06 -0800 (PST)
Received: from [216.102.208.11] (rtp-vpn3-351.cisco.com [10.82.217.97])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0RKGM7I020633;
	Fri, 27 Jan 2006 12:16:23 -0800
Message-ID: <43DA7E9D.2060904@cisco.com>
Date: Fri, 27 Jan 2006 12:12:13 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
	rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Levine 
References: <20060127200247.34217.qmail@simone.iecc.com>
In-Reply-To: <20060127200247.34217.qmail@simone.iecc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=607; t=1138392983; x=1138825183;
	c=relaxed/simple; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20
	|Subject:Re=3A=20IETF65=20hotel=20location
	|To:John=20Levine=20;
	X=v=3Dmtcc.com=3B=20h=3DTQP/VZcgw0w5aTDGNeZk3y95YMY=3D;
	b=kfF3NrH4CjscDrT8L6+AXutES+IYa7IEZBgtzGiIbTR1WpLd+nSyTvbOv8hGFq9hpjGaXUFB
	eslfYLP9l2vZWH6KkEl4Ekc45h+R0ZGKyD7/vu9oYvRRWX7FgVUlnzkH7rjVZwM7azSDR3rLG+s
	DxPVwLuVxLNzKIrlBObMgGXI=;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John Levine wrote:
>>Cue ten further emails describing various Google Earth mashups that
>>correlate restaurants with capacity, wait time and geek acceptability 
> 
> 
> If we could morph it into a signup system that distributed people
> according to restauant capacity and avoided the problem that someone
> says "I hear there's a burrito place on X street" and a herd of 300
> IETFers shows up there, since they don't know any other places to go,
> then you'd really have something.

I'm afraid it's beyond IETF's expertise to come up with
distributed burrito processing protocols.

		Mike

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 15:28:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2aCO-0003Oi-SJ; Fri, 27 Jan 2006 15:28:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aCM-0003OF-Li
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 15:27:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11508
	for ; Fri, 27 Jan 2006 15:26:26 -0500 (EST)
Received: from rwcrmhc14.comcast.net ([204.127.192.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2aMZ-0004Np-Pw
	for ietf@ietf.org; Fri, 27 Jan 2006 15:38:33 -0500
Received: from s73602 (unknown[65.104.224.98])
	by comcast.net (rwcrmhc14) with SMTP
	id <20060127202741m14001938je>; Fri, 27 Jan 2006 20:27:41 +0000
Message-ID: <01cd01c6237f$f39ba380$6501a8c0@china.huawei.com>
From: "Spencer Dawkins" 
To: 
References: <20060127200247.34217.qmail@simone.iecc.com>
	<43DA7E9D.2060904@cisco.com>
Date: Fri, 27 Jan 2006 14:26:26 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi, Mike,

>> If we could morph it into a signup system that distributed people
>> according to restauant capacity and avoided the problem that someone
>> says "I hear there's a burrito place on X street" and a herd of 300
>> IETFers shows up there, since they don't know any other places to go,
>> then you'd really have something.
>
> I'm afraid it's beyond IETF's expertise to come up with
> distributed burrito processing protocols.
>
> Mike

If you think about this for a minute, you would realize that (1) we not only 
have protocols for this, but we have running code, and (2) "too much focus 
on distributed burrito processing" might explain a lot about where we are 
and how we got here! :-)

Thanks,

Spencer, who is wondering what a "dining protocol designers" multitasking 
algorithm might look like, with a burrito between every pair of protocol 
designers (with apologies to the dining philosophers) 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 16:22:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2b3G-0000QN-AX; Fri, 27 Jan 2006 16:22:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2b3D-0000Pi-Vq
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 16:22:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17550
	for ; Fri, 27 Jan 2006 16:21:02 -0500 (EST)
Received: from hale160.ifa.hawaii.edu ([128.171.160.5]
	helo=hale.ifa.hawaii.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F2bDP-00073R-QG
	for ietf@ietf.org; Fri, 27 Jan 2006 16:33:09 -0500
Received: from XeonAL (xeonal [128.171.163.193])
	by hale.ifa.hawaii.edu (8.13.4/8.12.10) with ESMTP id k0RLMM5H018823;
	Fri, 27 Jan 2006 11:22:22 -1000 (HST)
From: "Robin Uyeshiro" 
To: "'David Kessens'" , 
Date: Fri, 27 Jan 2006 11:22:17 -1000
Message-ID: <002601c62387$c3373490$c1a3ab80@XeonAL>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <20060127194007.GA5219@nokia.com>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: 'Pekka Savola' , ietf@ietf.org
Subject: RE: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Try this:

http://maps.a9.com/?ypLoc=2015%20Market%20Center%20Blvd%2C%20Dallas%2C%2
0TX

You can "walk" down the street and see things.


-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
David Kessens
Sent: Friday, January 27, 2006 9:40 AM
To: dcrocker@bbiw.net
Cc: Pekka Savola; ietf@ietf.org
Subject: Re: IETF65 hotel location


Dave,

On Fri, Jan 27, 2006 at 07:57:08AM -0800, Dave Crocker wrote:
> 
> This makes it inconvenient not only for getting to restaurants but
> also for attendees wanting to stay at cheaper hotels.

There is a wide selection of cheaper hotels available around the
meeting hotel that are all walking distance.

Restaurants at walking distance are indeed problematic. However, the
hotel has quite a few choices of it's own and there are quite a few
very good restaurants a short cab ride away.

We realize that this is not ideal. Site selection is a compromise.

To give a bit of background: unfortunately, the hotel selection
process started very late which limited the amount of available venues
such that we didn't had the luxury to select a hotel that could
satisfy all criteria as much as we would have liked. We as Nokia
offered to host the meeting when we heard at a fairly late stage that
IETF was still in need for a host and that Dallas was being considered
by the secretariat (Our US headquarters are in Dallas).

My personal hope is that the selection process will happen more in
advance future now that we have Ray in place as our IAD.

> Frequently it even makes it difficult to just walk around.

As everything in Dallas, this hotel is quite large. Just a walk around
the premises will be quite a bit. 

David Kessens
---

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 16:53:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2bWv-0002bk-Hp; Fri, 27 Jan 2006 16:53:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2bWs-0002bI-Ow
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 16:53:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19919
	for ; Fri, 27 Jan 2006 16:51:41 -0500 (EST)
Received: from currant.srv.cs.cmu.edu ([128.2.194.193])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2bh6-0000f2-E3
	for ietf@ietf.org; Fri, 27 Jan 2006 17:03:49 -0500
Received: from CHOKECHERRY.SRV.CS.CMU.EDU ([128.2.185.41])
	by currant.srv.cs.cmu.edu id aa11526; 27 Jan 2006 16:53 EST
Received: from bistromath-home.pc.cs.cmu.edu
	(c-67-186-56-211.hsd1.pa.comcast.net [67.186.56.211])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id
	k0RLquYk020442
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 27 Jan 2006 16:52:57 -0500 (EST)
Date: Fri, 27 Jan 2006 16:52:56 -0500
From: Jeffrey Hutzelman 
To: Spencer Dawkins , ietf@ietf.org
Message-ID: <4CD2672290309C57FA3CA218@bistromath.pc.cs.cmu.edu>
In-Reply-To: <01cd01c6237f$f39ba380$6501a8c0@china.huawei.com>
References: <20060127200247.34217.qmail@simone.iecc.com>
	<43DA7E9D.2060904@cisco.com>
	<01cd01c6237f$f39ba380$6501a8c0@china.huawei.com>
Originator-Info: login-token=Mulberry:01Camkm3MRGQ9V9BwcPCfUCqAb28aQ3R12HtIAPyk=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2,
	Antispam-Data: 2006.01.27.130609
X-Spam-OK: 7%
X-Spam-Score: 1.2 (+)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Friday, January 27, 2006 02:26:26 PM -0600 Spencer Dawkins 
 wrote:

> Hi, Mike,
>
>>> If we could morph it into a signup system that distributed people
>>> according to restauant capacity and avoided the problem that someone
>>> says "I hear there's a burrito place on X street" and a herd of 300
>>> IETFers shows up there, since they don't know any other places to go,
>>> then you'd really have something.
>>
>> I'm afraid it's beyond IETF's expertise to come up with
>> distributed burrito processing protocols.
>>
>> Mike
>
> If you think about this for a minute, you would realize that (1) we not
> only have protocols for this, but we have running code, and (2) "too much
> focus on distributed burrito processing" might explain a lot about where
> we are and how we got here! :-)
>
> Thanks,
>
> Spencer, who is wondering what a "dining protocol designers" multitasking
> algorithm might look like, with a burrito between every pair of protocol
> designers (with apologies to the dining philosophers)

Ah, but this is not that big a problem, because unlike forks, burritos are 
dual-ported.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Fri Jan 27 18:49:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2dL9-0003lI-L4; Fri, 27 Jan 2006 18:49:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2dL7-0003l2-FD
	for ietf@megatron.ietf.org; Fri, 27 Jan 2006 18:49:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26967
	for ; Fri, 27 Jan 2006 18:47:39 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2dVN-0003sY-5M
	for ietf@ietf.org; Fri, 27 Jan 2006 18:59:49 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F2dKs-0004zY-Tu; Fri, 27 Jan 2006 15:48:59 -0800
Message-Id: <6.2.3.4.2.20060127222317.04560170@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Sat, 28 Jan 2006 00:12:32 +0100
To: HarringtonDavid 73653 , ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-51317F2
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: 
Subject: Re: Weekly posting summary for ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear David,
This could be done in extracting archives and in building a statistic 
program. Then it could be given to some good mathematician to find 
correlations. The utilisation of as much IETF mailing lists as 
possible over the last 10 years could permit to discover some 
personal behavioral pattern. The real issue is that a mailing list is 
polylogue and is something we have to learn about. For example we all 
know that one single mail may trigger hundredth of posts. The problem 
is not to impeach the fight, but the match use to start it.
jfc

At 03:17 27/01/2006, HarringtonDavid 73653 wrote:
>Some of the analysisI think should be done:
>1) is there a correlation between the posting patterns and the 
>timely completion of milestones in a WG?

if the Charter is considered by the WG or not.
if the final report to the IESG states that the Charter was fulfilled.
if the authors of the I-D are or not preselected before the creation of the WG?

>2) is there a correlation between posting patterns and the time 
>between first publication of an I-D and its subsequent adoption by the WG?

the delay between the start of a WG and the publication of the I-D.
The number of proposed changes to the I-D. Ratio of considered, 
denied, adopted changes. Number of mails per results  (global, per individual).
Number of never answered relevant questions.

>3) is there a correlation between posting patterns and the time 
>between adoption of an I-D by the WG and the publication as a 
>Proposed Standard?

This is a certain number of periods which should be detailed.

>4) Are there specific points in the provess when the posting pattern 
>behaviors change? (such as after PS apporoval but before RFC 
>publication, or during WGLC, or immediately after and updated I-D is 
>posted?, etc.

I am not sure all that correspond to a real debate? Also it does not 
take into consideration external aspects, appeals, etc.

>5) in the subjective view of the chairs **of many WGs, not just ones 
>that had problem posters**, did posting behaviors help or hurt the 
>forward progress of the WG?

Yes. But the problem is to assess if help/hurt. I would propose a 
simpler criteria - for each I-D Change, the delay since the 
proposition started. The last change. The pattern after the last 
change. The last change date vs. transmission to IESG.

>6) maybe a survey should be done for all WG participants to get 
>their subjective view of whether posting behaviors helped or hurt WG process

This is subjective. The best criteria is the difference between the 
first and last I-D and the way the changes came in (as a proposition 
or to block a proposition. Was that proposition to eventually get the 
resulting change).

The real issue I think is the consensus by exhaustion. This should be 
traced through the participation pattern and the number of mails to 
approve/disapprove a point the Chair deem consensual and the number 
of average participants at that time.

Another important point is the number of participants, silent or 
active during the life of the WG.

>I would be willing to help design and document a data collection 
>experiment to contribute to a better understanding of the factors 
>that impact the effectiveness of IETF processes.

I would suggest a simple thing: to take a few typical mailing lists 
the Chairs would release the number of registered participants (at 
which date), to download them as a file, and to build a tool to 
extact statistics. From previous work in that area for @large list, 
the size of the mails vs. the size of someone input in the mail is an 
important factor, as well as the mail being trimed or not.

I am interested too in working on that.
jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 28 06:12:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2o0F-0001i8-Eo; Sat, 28 Jan 2006 06:12:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2nzh-0001EP-JV
	for ietf@megatron.ietf.org; Sat, 28 Jan 2006 06:11:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13360
	for ; Sat, 28 Jan 2006 06:10:15 -0500 (EST)
Received: from zproxy.gmail.com ([64.233.162.205])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2oA1-0007ws-DA
	for ietf@ietf.org; Sat, 28 Jan 2006 06:22:31 -0500
Received: by zproxy.gmail.com with SMTP id 9so805732nzo
	for ; Sat, 28 Jan 2006 03:11:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=BX0WFtMiOXeOuiOQL8J25VzKVZg/CNbVE/vV7bTo4tHP8qQzFXzlf13QwWexcUXrvH5e6GC5CG98qWiz6NPMOeZUilPyrRzoAaC/0lH2j68JkPorNLzP/zG17286lv3zw0jERRuRr9VhUe6QaiFPFUgTrjJD2jNWHhAmRBdOsss=
Received: by 10.36.38.7 with SMTP id l7mr3179410nzl;
	Sat, 28 Jan 2006 03:11:44 -0800 (PST)
Received: by 10.36.88.19 with HTTP; Sat, 28 Jan 2006 03:11:44 -0800 (PST)
Message-ID: <8ee2e61f0601280311q270e0bfbp@mail.gmail.com>
Date: Sat, 28 Jan 2006 12:11:44 +0100
From: Eduardo Mendez 
To: ietf@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.6 (/)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d
Subject: "JFC 3683"?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1276349031=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1276349031==
Content-Type: multipart/alternative; 
	boundary="----=_Part_3297_1474146.1138446704280"

------=_Part_3297_1474146.1138446704280
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Jefsey says it is a faked case.
He calls it "JFC 3683".
He says it is commercial competition.
He says ad hominems answer his technical points.
He says he won.
He says it is to the IESG and IAB to say how.
The matter is important.
I wanted to know and I spent time.

I checked reading WG-ltru, Languages, IETF archives.
I am not an engineer, but I know to read a case.
I also have a poor english. But I have assistants.
And all this is not engineering.

I saw that Jefsey repeats himself.
He says "let consider the charter".
The Chair says: "later"... and never does.

Jefsey explains the importance to the world.
I agree. It is obvious for any non-US-American.
Only for USA internationalization is multilingualisation.

Why users will not accept.
Why it will be balkanization.
Main thing is: he proposes good changes.
For technical reasons.
He obtains many changes.

If he wants something.
He proposes the opposite.
And obtains what he wants.
Very fun.
I understand they are not happy.

The way he repeats things is funny.
I-D says something.
This creates many problems.
He talk of each problem one by one.
They cannot solve. Just block.
This is what he wants.
The scope is smaller, smaller.

Best is when Harald apologises.
Because he technically agrees with Jefsey!

Another good one is ISO 11179.
IETF experts show their ignorance.
Just reading the TOC show Jefsey right.

I saw ietf-languages is ignorant at EU.
They were insulting EU and EU people.
Jefsey faked a funny ignorance at USA.
He gave the good technical answer.
And he explained reality.
He was fired.
The Chair explains it is just to fool IESG.
The IETF Chair says politely it is not good.
IESG starts the PR action.

I read Harald request for a PR action.
Most of the reasons are not documented.
Some are external to IETF.
ISO one would be easy to check?

Now I made a folder with the "JFC 3683" IETF mails.
I already found 268!
There are some technical issues raised by Jefsey.
None are commented.

This looks like a Parliament.
Not like a Science Academy.
I know Parliaments: Jefsey won.

Many will not like.
They can check as I did.

Eduardo Mendez

------=_Part_3297_1474146.1138446704280
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Jefsey says it is a faked case.

He calls it "JFC 3683".

He says it is commercial competition.

He says ad hominems answer his technical points.

He says he won.

He says it is to the IESG and IAB to say how.

The matter is important.

I wanted to know and I spent time.



I checked reading WG-ltru, Languages, IETF archives.

I am not an engineer, but I know to read a case.

I also have a poor english. But I have assistants.

And all this is not engineering.



I saw that Jefsey repeats himself.

He says "let consider the charter".

The Chair says: "later"... and never does.



Jefsey explains the importance to the world.

I agree. It is obvious for any non-US-American.

Only for USA internationalization is multilingualisation.



Why users will not accept.

Why it will be balkanization.

Main thing is: he proposes good changes.

For technical reasons.

He obtains many changes. 



If he wants something.

He proposes the opposite. 

And obtains what he wants.

Very fun. 

I understand they are not happy.



The way he repeats things is funny.

I-D says something. 

This creates many problems.

He talk of each problem one by one.

They cannot solve. Just block.

This is what he wants.

The scope is smaller, smaller.



Best is when Harald apologises.

Because he technically agrees with Jefsey!



Another good one is ISO 11179.

IETF experts show their ignorance.

Just reading the TOC show Jefsey right.



I saw ietf-languages is ignorant at EU.

They were insulting EU and EU people.

Jefsey faked a funny ignorance at USA.

He gave the good technical answer.

And he explained reality.

He was fired.

The Chair explains it is just to fool IESG.

The IETF Chair says politely it is not good.

IESG starts the PR action.



I read Harald request for a PR action.

Most of the reasons are not documented.

Some are external to IETF.

ISO one would be easy to check?



Now I made a folder with the "JFC 3683" IETF mails.

I already found 268! 

There are some technical issues raised by Jefsey.

None are commented.



This looks like a Parliament.

Not like a Science Academy.

I know Parliaments: Jefsey won.



Many will not like.

They can check as I did.



Eduardo Mendez












------=_Part_3297_1474146.1138446704280--


--===============1276349031==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1276349031==--




From ietf-bounces@ietf.org Sat Jan 28 13:02:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2uPP-0005Ze-Fy; Sat, 28 Jan 2006 13:02:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2uPM-0005U1-T4
	for ietf@megatron.ietf.org; Sat, 28 Jan 2006 13:02:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02844
	for ; Sat, 28 Jan 2006 13:01:10 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2uZl-00013G-9e
	for ietf@ietf.org; Sat, 28 Jan 2006 13:13:30 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3834013; Sat, 28 Jan 2006 12:58:55 -0500
In-Reply-To: <43DA42D4.4040005@dcrocker.net>
References: 
	<43DA42D4.4040005@dcrocker.net>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <824559A0-1D1D-4DB3-B445-0F646F99C344@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Sat, 28 Jan 2006 13:02:41 -0500
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: Pekka Savola , ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

This can be argued both ways. (The most productive meeting I think  
that I ever went to
was a physics standardization meeting in a castle in the South of  
England with nothing of note within 20 miles, and not even a pub  
within 10 miles. All we could do is work, meet and bond. And raid the  
wine cellar.)

However, to be constructive, I would like to suggest adding two yes  
or no questions to the next meeting
questionnaire :

A.) Do you feel that the venue chosen for the meeting was too remote,  
in terms of accessibility
of restaurants, bars, your or other hotels, etc. ?

B.) (If "A" is answered yes.) Would having another IETF meeting in a  
site that is similarly remote make it
less likely that you would attend ?

BTW, the last time I was in Dallas my wife and I walked all over  
downtown, including over to Dealy Plaza.
It was hot, we were the only pedestrians except for some street  
people (except at the Plaza itself),
and we never saw a cab (except at a hotel we went by). My advice is,  
if you really want to get around, rent a car.

Regards
Marshall

On Jan 27, 2006, at 10:57 AM, Dave Crocker wrote:

>> Looking at the restaurant map, it seems that the IETF65 hotel/ 
>> venue is basically "in the middle of nowhere".  Restaurants are  
>> typically 2+ miles away, and my guess is that public  
>> transportation or walking aren't options.
>
>
> Periodically, the IETF venue is quite isolated.
>
> This makes it inconvenient not only for getting to restaurants but  
> also for attendees wanting to stay at cheaper hotels.
>
> Frequently it even makes it difficult to just walk around.
>
> d/
> -- 
>
> Dave Crocker
> Brandenburg InternetWorking
> 
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 28 13:13:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2uZe-0007uK-KR; Sat, 28 Jan 2006 13:13:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2uZS-0007qj-CN
	for ietf@megatron.ietf.org; Sat, 28 Jan 2006 13:13:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03380
	for ; Sat, 28 Jan 2006 13:11:02 -0500 (EST)
Received: from sccrmhc11.comcast.net ([63.240.77.81])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2ujJ-0001IQ-SH
	for ietf@ietf.org; Sat, 28 Jan 2006 13:23:22 -0500
Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149])
	by comcast.net (sccrmhc11) with SMTP
	id <2006012818114301100hsmh5e>; Sat, 28 Jan 2006 18:11:43 +0000
From: "David B Harrington" 
To: "'Spencer Dawkins'" , 
Date: Sat, 28 Jan 2006 13:11:38 -0500
Message-ID: <002701c62436$48f7ef80$0400a8c0@DJYXPY41>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcYjgKZU7f8488qkQUGDHUp9g+jlCgAtTO/g
In-Reply-To: <01cd01c6237f$f39ba380$6501a8c0@china.huawei.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: 
Subject: RE: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietfdbh@comcast.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi,

This conversation of the IETF65 location started with an issue of
security.

I'd like to get this discussion back on track.
What are the security requirements for a distributed burrito
processing protocol?
If you are traveling from the conference hotel to a restaurant and are
mugged, is that considered a man-in-the-middle attack?

dbh

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On 
> Behalf Of Spencer Dawkins
> Sent: Friday, January 27, 2006 3:26 PM
> To: ietf@ietf.org
> Subject: Re: IETF65 hotel location
> 
> Hi, Mike,
> 
> >> If we could morph it into a signup system that distributed people
> >> according to restauant capacity and avoided the problem 
> that someone
> >> says "I hear there's a burrito place on X street" and a herd of
300
> >> IETFers shows up there, since they don't know any other 
> places to go,
> >> then you'd really have something.
> >
> > I'm afraid it's beyond IETF's expertise to come up with
> > distributed burrito processing protocols.
> >
> > Mike
> 
> If you think about this for a minute, you would realize that 
> (1) we not only 
> have protocols for this, but we have running code, and (2) 
> "too much focus 
> on distributed burrito processing" might explain a lot about 
> where we are 
> and how we got here! :-)
> 
> Thanks,
> 
> Spencer, who is wondering what a "dining protocol designers" 
> multitasking 
> algorithm might look like, with a burrito between every pair 
> of protocol 
> designers (with apologies to the dining philosophers) 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sat Jan 28 17:13:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2yKT-0005u9-Bx; Sat, 28 Jan 2006 17:13:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F2yKJ-0005rg-Cq
	for ietf@megatron.ietf.org; Sat, 28 Jan 2006 17:13:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14494
	for ; Sat, 28 Jan 2006 17:12:01 -0500 (EST)
Received: from currant.srv.cs.cmu.edu ([128.2.194.193])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2yUX-0006u2-RI
	for ietf@ietf.org; Sat, 28 Jan 2006 17:24:23 -0500
Received: from CHOKECHERRY.SRV.CS.CMU.EDU ([128.2.185.41])
	by currant.srv.cs.cmu.edu id aa21907; 28 Jan 2006 17:13 EST
Received: from bistromath-home.pc.cs.cmu.edu
	(c-67-186-56-211.hsd1.pa.comcast.net [67.186.56.211])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.5/8.13.5) with ESMTP id
	k0SMCumM020762
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Sat, 28 Jan 2006 17:12:58 -0500 (EST)
Date: Sat, 28 Jan 2006 17:12:56 -0500
From: Jeffrey Hutzelman 
To: ietfdbh@comcast.net, "'Spencer Dawkins'" ,
	ietf@ietf.org
Message-ID: 
In-Reply-To: <002701c62436$48f7ef80$0400a8c0@DJYXPY41>
References: <002701c62436$48f7ef80$0400a8c0@DJYXPY41>
Originator-Info: login-token=Mulberry:01GAU4W4Jtrc9kULDcS4Noyq93b4afObGFembAToU=;
	token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2,
	Antispam-Data: 2006.01.28.130611
X-Spam-OK: 7%
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: 
Subject: RE: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



On Saturday, January 28, 2006 01:11:38 PM -0500 David B Harrington 
 wrote:

> This conversation of the IETF65 location started with an issue of
> security.
>
> I'd like to get this discussion back on track.
> What are the security requirements for a distributed burrito
> processing protocol?
> If you are traveling from the conference hotel to a restaurant and are
> mugged, is that considered a man-in-the-middle attack?

That would, of course, depend on the gender of the mugger.  However, the 
important thing to note is that such attacks can be prevented by the use of 
strong end-to-end security, such as an armored car, or perhaps a tank.  Of 
course, there is always a tradeoff to be made in these situations.  For 
example, I'm given to understand that tanks tend to be a bit trickier to 
drive than cars...



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 29 07:29:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3Bgf-00045t-EQ; Sun, 29 Jan 2006 07:29:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3BgW-00040Z-4s
	for ietf@megatron.ietf.org; Sun, 29 Jan 2006 07:29:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24895
	for ; Sun, 29 Jan 2006 07:28:00 -0500 (EST)
Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10]
	helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1F3Bqy-0006Hj-2q
	for ietf@ietf.org; Sun, 29 Jan 2006 07:40:30 -0500
Received: (qmail 15977 invoked from network); 29 Jan 2006 12:28:58 -0000
X-NetworkBox-HamSign: 0101;OUT;hitachihk1;c5c3743224d52119bc2a2cac0da95321;
Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by
	ip-11-194-65-202.rev.dyxnet.com with SMTP; 29 Jan 2006 12:28:58 -0000
Received: (qmail 8462 invoked from network); 29 Jan 2006 12:29:00 -0000
X-NetworkBox-HamSign: 0101;OUT;hitachihk5;82349defaafb43a93cbdc2d0f7a93c95;
Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn)
	(170.95.82.6)by 172.16.10.9 with SMTP; 29 Jan 2006 12:29:00 -0000
Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with
	Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jan 2006 20:28:59 +0800
content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Sun, 29 Jan 2006 20:28:58 +0800
Message-ID: <834B54D356AA8F46B9B233DD88BEAA38BC6AA9@hcbjdc2>
Thread-Topic: One IETF related Workshop informaiton,
Thread-Index: AcYkz5M+s6WWFkP8QCORp9rwOWciLw==
From: "DENG, HUI -HCHBJ" 
To: "DENG, HUI -HCHBJ" , 
X-OriginalArrivalTime: 29 Jan 2006 12:28:59.0847 (UTC)
	FILETIME=[94B6B570:01C624CF]
X-Scanned-By-hitachihk5: Virus scan performed by network-box
X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1138537740.41-8459-000
X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned
	in 0.02/0.06 secs)
X-Scanned-By-hitachihk5: Spam-Check-Result: No,
	hits=0 required=7 tests= autolearn=no version=2.0
X-Spam-Status: No
X-Scanned-By-hitachihk1: Virus scan performed by network-box
X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1138537738.763-15963-000
X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned
	in 0.02/0.01 secs)
X-Scanned-By-hitachihk1: Spam-Check-Result: No,
	hits=0 required=7 tests= autolearn=no version=2.0
X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via
	Network Box hitachihk5)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: mip6@ietf.org, sip@ietf.org, wuhq@catt.ac.cn, mip4@ietf.org,
	softwires@ietf.org, jianping@cernet.edu.cn, netlmm@ngnet.it
Subject: One IETF related Workshop informaiton,
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1294435564=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1294435564==
content-class: urn:content-classes:message
Content-Type: text/plain;charset="utf-8"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

RGVhciBBbGwNCiANClRvZGF5IGlzIENoaW5hJ3MgbHVuYXIgbmV3IHllYXIgZGF5LCBhbmQgdGhp
cyB5ZWFyIHNheXMgIkRvZyIgeWVhci4gQnkgdGFraW5nIHRoaXMgb3Bwb3J0dW5pdHksDQpXZSdk
IGxpa2UgdG8gYW5ub3VuY2Ugb25lIHdvcmtzaG9wIGluZm9ybWF0aW9uIHdoaWNoIGlzIHJlbGF0
ZWQgdG8gSUVURiBtYWlubHkuDQogDQpBcm91bmQgRmViLiAyNy0yOHRoLCAyMDA2LCBCZWlqaW5n
LCBDaGluYSwgQ05HSSBFeHBlcnQgQ29tbWlzc2lvbiB3aWxsIGhvc3QgYSAgc3BlY2lhbCANCndv
cmtzaG9wIG9uIE5ldyBUcmVuZCBvZiBOZXh0IEdlbmVyYXRpb24gSW50ZXJuZXQuIFdlIHdlbGNv
bWUgYW5kIGludml0ZSAgcmVzZWFyY2hlcnMgDQp3aG8gaXMgaW52b2x2ZWQgaW4gSUVURiwgM0dQ
UDIsIElFRUUgcmVsYXRlZCB0byBNSVAsIElQdjYsIFNJUCwgYW5kIEZNQyBldCBhbC4gDQp0byBh
dHRlbmQgdGhpcyB3b3Jrc2hvcCBmb3IgZnJlZS4gSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIGF0
dGVuZGluZyB0aGlzIHdvcmtzaG9wLA0KcGxlYXNlIGRvbnQnIGhlc2l0YXRlIHRvIGxldCB1cyBr
bm93IGl0Lg0KIA0KVGhlIGZvbGxvd2luZyBsaW5rIGlzIGxhc3QgeWVhciB3b3Jrc2hvcCBpbmZv
cm1hdGlvbjoNCmh0dHA6Ly93d3cxLmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWlwNi9jdXJy
ZW50L21zZzAyMzUzLmh0bWwNCiANCldlIGFyZSBhbHNvIGV4cGVjdGluZyB0aGF0IElFVEYgbWVl
dGluZyBjb3VsZCBiZSBoZWxkIGluIENoaW5hIHNvbWVkYXkuDQogDQpIYXBweSBEb2dnaWUsIERv
ZywgRG9uZ2xlIFllYXIgdG8gcGVvcGxlIHdobyBpcyBpbnRlcmVzdGVkIGluIENoaW5hJ3MgY3Vs
dHVyZS4NCk1hbnkgdGhhbmtzLA0KIA0KUHJvZi4gSGVxdWFuIFd1DQpDaGllZiBTY2llbnRpc3Qs
IENoaW5hIE5leHQtR2VuZXJhdGlvbiBJbnRlcm5ldCBFeHBlcnRzIENvbW1pc3Npb24gDQpWaWNl
IFByZXNpZGVudCwgQ2hpbmVzZSBBY2FkZW15IG9mIEVuZ2luZWVyaW5nDQogDQpIdWkgRGVuZw0K
Q2hhaXIgb2YgT3JnYW5pemluZyBDb21taXR0ZWUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
IC0tLS0tLS0tLS0tLS0tLS0tLSANCldvcmtzaG9wIG9uIE5ldyBUcmVuZCBvZiBOZXh0IEdlbmVy
YXRpb24gSW50ZXJuZXQNCg0KKDEpIE9yZ2FuaXplcnM6ICBDaGluYSBOZXh0LUdlbmVyYXRpb24g
SW50ZXJuZXQgRXhwZXJ0cyBDb21taXNzaW9uDQogICAgICBIb3N0OiAgICAgICAgICBDRVJORVQg
Q2VudGVyOiBDaGluYSBFZHVjYXRpb24gYW5kIFJlc2VhcmNoIE5ldHdvcmsgQ2VudGVyDQogICAg
ICBTcG9uc29yOiAgICAgSGl0YWNoaSAoQ2hpbmEpIFImRCBDb3Jwb3JhdGlvbi4NCigyKSBEYXRl
L1RpbWU6ICAgRmViLiAyN3RoLTI4dGguIE1vbmRheS9UdWVzZGF5LCAyMDA2DQooMykgUGxhY2U6
ICAgICAgICAgIFRzaW5naHVhIFVuaXYuIEZJVCBCdWlsZGluZw0KDQpDb250YWN0IFBlb3BsZToN
CiANCiBGYW5nIEx2DQogVGVsOiAoODYpIDEw77yNNjI3OTU4MTjvvI02MzIyDQogRS1tYWlsOiBm
YW5nbEBjZXJuZXQuZWR1LmNuDQogDQogWWFvaHVpIEFuDQogVGVsOiAoODYpIDEwLTY4NTIyNjY5
DQogRmF4OiAoODYpIDEwLTY4NTIyNjY5DQogRS1tYWlsOiBheWhAY2FlLmNuDQogDQogSHVpIERF
TkcNCiBNb2I6ICg4NikgMTM5MTA3NTAyMDENCiBGYXg6ICg4NikgMTAtNjU5MC04MTc5DQogRS1t
YWlsOiBoZGVuZ0BoaXRhY2hpLmNuDQoNCldvcmtzaG9wIFRvcGljczoNCi0gSUVURiBNb2JpbGUg
SVAgcmVsYXRlZCAoTUlQdjQsIE1JUDYsIE5FTU8sIE1vYm9wdHMsIE5FVExNTSkuDQotIElFVEYg
U0lQIHJlbGF0ZWQgKDNHUFAyIHJlbGF0ZWQpLg0KLSAzR1BQMiBJUCByZWxhdGVkIHRlY2hub2xv
Z3kgKE1JUCBhbmQgSU1TKS4NCi0gSUVFRSA4MDIuMTYsMjEgSUVURiByZWxhdGVkDQotIDEwMCBi
eSAxMDAgcHJvamVjdCByZWxhdGVkDQotIEdFTkkgcHJvamVjdCByZWxhdGVkDQotIENoaW5hIE1v
YmlsZSBPcGVyYXRvcnMgc3RyYXRlZ3kgYW5kIHNvbWUgc29sdXRpb24uIChDaGluYSBNb2JpbGUg
YW5kIENoaW5hICBVbmljb20pDQotIENoaW5hIEZpeGVkIE9wZXJhdG9ycyBzdHJhdGVneSBhbmQg
c29tZSBzb2x1dGlvbi4gKENoaW5hIFRlbGVjb20gYW5kIENoaW5hICBOZXRjb20pDQotIEZvcmVp
Z24gTW9iaWxlIENhcnJpZXIncyBzdHJhdGVneSBmb3IgbmV4dCBnZW5lcmF0aW9uIEludGVybmV0
Lg0KLSBDaGluYSBSZXNlYXJjaCBOZXR3b3JrIFN0cmF0ZWd5IGZvciBuZXh0IGdlbmVyYXRpb24g
SW50ZXJuZXQuIChDRVJORVQpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQpEcmFmdCBBZ2VuZGEgYnV0IG5vdCB5ZXQgZmluYWxpemVkOg0KIA0K
RmViLiAyN3RoDQrvvJxNb3JuaW5nIFNlc3Npb27vvJ7jgIDjgIDjgIDjgIBDaGFpcjogUHJvZi4g
SGVxdWFuIFd1IChDaGllZiBTY2llbnRpc3Qgb2YgQ05HSSBFeHBlcnRzIENvbW1pc3Npb24pDQo5
OjAwLTk6MzAgICAgT3BlbmluZyBBZGRyZXNzDQogICAgICAgICAgICAgRHIuIEhlcXVhbiBXdSAg
KENoaWVmIFNjaWVudGlzdCBvZiBDTkdJIEV4cGVydHMgQ29tbWlzc2lvbikNCjk6MzAtMTA6MDAg
ICBNb2JpbGl0eSBpbiBJUHY0OiBUZWNobm9sb2d5IGFuZCBEZXBsb3ltZW50LCBhbmQgb3RoZXIg
bmV3IHRyZW5kcyBvZiBuZXR3b3JrLg0KICAgICAgICAgICAgIE1yLiBIZW5yaWsgTGV2a293ZXR6
IChDaGFpciBvZiBNSVA0IFdHIGluIElFVEYpDQoxMDowMC0xMDozMCAgSW52aXRlZCBzcGVha2Vy
IGZvcm0gTlNGIG9mIFVTQQ0KICAgICAgICAgICAgIE1yLiAoSW52aXRlZCBieSBDRVJORVQpDQox
MDozMC0xMDo0MCAgIO+8nCAgQ29mZmVlIEJyZWFrIO+8ng0KMTA6NDAtMTE6MTAgIE5ldyBUcmVu
ZCBvZiBOZXh0IEdlbmVyYXRpb24gSW50ZXJuZXQgb2YgQ2hpbmEgVW5pY29tLg0KICAgICAgICAg
ICAgIERyLiBZdW5qaWUgTGl1IChQcmUtQ1RPIG9mIENoaW5hIFVuaWNvbSkNCjExOjEwLTExOjQw
ICBEb2NvbW8gTmV4dCBHZW5lcmF0aW9uIEFsbCBJUCBuZXR3b3JrDQogICAgICAgICAgICAgTXIu
IE1hc2FtaSBZYWJ1c2FraSAoRGlyZWN0b3Igb2YgQWxsLUlQIG5ldHdvcmsgZGV2ZWxvcG1lbnQg
YW5kIHN0YW5kYXJkaXphdGlvbiwgRG9Db01vKQ0KICAgICAgICANCu+8nCBMdW5jaCDvvJ4NCjEy
OjIwLTE0OjAwICANCu+8nEFmdGVybm9vbiBTZXNzaW9u77yeICAgICAgIENoYWlyOiBHb3BhbCBE
b21tZXR5IChWaWNlIENoYWlybWFuIG9mIE1JUDYgV0cpDQoxNDowMC0xNDozMCAgQ0VSTkVUMg0K
ICAgICAgICAgICAgIE1yLiAgICggQ0VSTkVUKQ0KMTQ6MzAtMTU6MDAgIC4uIFdHIGluIElFVEYN
CiAgICAgICAgICAgICBNci4gIChJRVRGKSANCjE1OjAwLTE1OjIwICAg77ycICBDb2ZmZWUgQnJl
YWsg77yeDQoxNToyMC0xNTo1MCAgTmV3IFRyZW5kIG9mIE5leHQgR2VuZXJhdGlvbiBJbnRlcm5l
dCBvZiBDaGluYSBUZWxlY29tLg0KICAgICAgICAgICAgIE1yLiAoQ2hpbmEgVGVsZWNvbSkNCjE1
OjUwLTE2OjIwICBGaXhlZCBhbmQgTW9iaWxlIGNvbnZlcmdlbmNlDQogICAgICAgICAgICAgRHIu
ICAoSGl0YWNoaSkNCjE2OjIwLTE2OjUwICBJVFUgYW5kIElFVEYgcmVsYXRpb25zaGlwDQogICAg
ICAgICAgICAgTXMuICAoSVRVKSAoTGluZ3RhbywgSmlhbmcpDQoxNjo1MC0xNzoyMCAgTmV0d29y
ayBUcmVuZA0KICAgICAgICAgICAgIE1zLiAoSW52aXRlZCBieSBDRVJORVQpDQoxNzoyMC0xODow
MCAgM0dQUDIgSU1TDQogICAgICAgICAgICAgTXMuIFlhbiBMaSAoUXVhbGNvbW0pDQo8QmFucXVl
dD4gICAgMTg6MjAtMjA6MDANCkZlYi4gMjh0aA0K77ycTW9ybmluZyBTZXNzaW9u77ye44CA44CA
44CA44CAQ2hhaXI6IFByb2YuWmlxaWFuZyBIb3UgKENoaWVmIEFkdmlzb3Igb2YgQ2hpbmEgTmV0
Y29tKQ0KOTowMC05OjMwICAgIElFRUUgODAyLjE2IGFuZCBIdWF3ZWkNCiAgICAgICAgICAgIE1y
LiBQaGlsbGlwIEJhcmJlciAgKENoYWlyIG9mIE5FVE1BTiwgSUVFRSA4MDIuMTYpDQo5OjMwLTEw
OjAwICAgTW9iaWxlIElQdjYgaW4gSUVURg0KICAgICAgICAgICAgRHIuIEdvcGFsIERvbW1ldHkg
KENvLUNoYWlyIG9mIE1JUDYgV0cgaW4gSUVURiwgQ2lzY28pIA0KMTA6MDAtMTA6MzAgIEludml0
ZWQgc3BlYWtlciBmb3JtIENoaW5hIEFjYWRlbXkgb2YgU2NpZW5jZQ0KICAgICAgICAgICAgIE1y
Lg0KMTA6MzAtMTA6NDAgICDvvJwgIENvZmZlZSBCcmVhayDvvJ4NCjEwOjQwLTExOjEwICBOZXcg
VHJlbmQgb2YgTmV4dCBHZW5lcmF0aW9uIEludGVybmV0IG9mIENoaW5hIE1vYmlsZS4NCiAgICAg
ICAgICAgICBNcy4gKENoaW5hIE1vYmlsZSkNCjExOjEwLTExOjQwICBJRUVFIDgwMi4yMSBXRw0K
ICAgICAgICAgICAgIERyLiBBamF5IFJhamt1bWFyIChMdWNlbnQpDQoxMDozMC0xMTowMCAgTmV3
IFRyZW5kIG9mIE5leHQgR2VuZXJhdGlvbiBJbnRlcm5ldCBvZiBDaGluYSBOZXRjb20uDQogICAg
ICAgICAgICAgTXMuIChDaGluYSBOZXRjb20pDQoNCu+8nEFmdGVybm9vbiBTZXNzaW9u77yeICBE
aXJlY3RvciBvZiBDRVJORVQsIERyLiBKaWFucGluZyBXdQ0KIEZvcnVtIGFuZCBWaXNpdCBDRVJO
RVQyDQogIEFsbCBJbnZpdGVkIFNwZWFrZXJzOg0KICBUb3BpY3M6IE5ldyBUcmVuZCBvZiBOZXh0
IEdlbmVyYXRpb24gSW50ZXJuZXQNCkNsb3NpbmcgQWRkcmVzcw0KIA0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQpQbGVhc2UgYWxsb3cgdXMg
dG8gaW50cm9kdWNlIENOR0kgaGVyZSwNCiANClRoZSBDTkdJIChDaGluYSBOZXh0IEdlbmVyYXRp
b24gSW50ZXJuZXQgUHJvamVjdCkgd2FzIHN0YXJ0ZWQgaW4gMjAwMy4gSXQgd2lsbCAgY29uc3Ry
dWN0IGEgYmlnIElQdjYgbmV0d29yayBieSB0aGUgZW5kIG9mIDIwMDUgdGhhdCB3aWxsIGNvdmVy
IHdob2xlIGNvdW50cnksIDIwKyAgY2l0aWVzLCAzOSBjb3JlIG5vZGVzLCBhbmQgMzAwKyBhY2Nl
c3Mgbm9kZXMuIFRoZW4gQ2hpbmEgbWF5IGJlY29tZSBhIGNvdW50cnkgdGhhdCAgaGFzIHRoZSBs
YXJnZXN0IElQdjYgbmV0d29yay4gVGhlIENOR0kgcHJvamVjdCBpcyBsZWFkZWQgYnkgc3RhdGUg
YWRtaW5pc3RyYXRpb25zLiAgVGhleSBhcmUgTmF0aW9uYWwgRGV2ZWxvcG1lbnQgYW5kIFJlZm9y
bSBDb21taXNzaW9uIChORFJDKSx0aGUgTWluaXN0cnkgb2YgU2NpZW5jZSAgYW5kIFRlY2hub2xv
Z3kgKE1PU1QpLCB0aGUgTWluaXN0cnkgb2YgRWR1Y2F0aW9uIChNT0UpLCB0aGUgTWluaXN0cnkg
b2YgSW5mb3JtYXRpb24gIEluZHVzdHJ5IChNSUkpLCB0aGUgU3RhdGUgQ291bmNpbCBJbmZvcm1h
dGl6YXRpb24gT2ZmaWNlLCB0aGUgQ2hpbmVzZSBBY2FkZW15IG9mICBTY2llbmNlcyAoQ0FTKSwg
dGhlIENoaW5lc2UgQWNhZGVteSBvZiBFbmdpbmVlcmluZyAoQ0FFKSBhbmQgdGhlIE5hdGlvbmFs
IE5hdHVyYWwgIFNjaWVuY2UgRm91bmRhdGlvbiBvZiBDaGluYSAoTlNGQykuIA0KIA0KVG8gYmUg
dGhlIHBhcnQgb2YgQ05HSSBwcm9qZWN0LCB0aGUgdGVsZWNvbSBvcGVyYXRvcnMsIHdobyBpbmNs
dWRlIENoaW5hIFRlbGVjb20sICBDaGluYSBVbmljb20sIENoaW5hIE5ldGNvbSwgQ2hpbmEgTW9i
aWxlIGFuZCBDaGluYSBSYWlsY29tLCBhbG9uZyB3aXRoIHRoZSBhY2FkZW1pYyAgbmV0d29yayBD
RVJORVQgYW5kIENTVE5FVCwgYXJlIHJlc3BvbnNpYmxlIGZvciBjb25zdHJ1Y3RpbmcgdGhlaXIg
b3duIElQdjYgY29yZSAgbmV0d29ya3MuIFRoZSBDTkdJIG5ldHdvcmsgc3dpdGNoIGNlbnRlcnMg
bG9jYXRlZCBpbiBCZWlqaW5nIGFuZCBTaGFuZ2hhaSB3aWxsICBjb25uZWN0IGFib3ZlIElQdjYg
Y29yZSBuZXR3b3JrcyBhbmQgaW50ZXItd29ya2luZyB3aXRoIGludGVybmF0aW9uYWwgSVB2NiB0
cmFpbCAgbmV0d29ya3MuIC4gDQogDQpUaGUgQ05HSSBFeHBlcnQgQ29tbWlzc2lvbiB3YXMgZXN0
YWJsaXNoZWQgdG8gbWFuYWdlIHRoZSBwcm9qZWN0LCBhbmQgdGVsZWNvbSAgb3BlcmF0b3JzLCBt
YW51ZmFjdHVyZXMgYW5kIHJlc2VhcmNoIGluc3RpdHV0ZXMgaGF2ZSBqb2luZWQgdGhlIGVmZm9y
dC4gQ05HSSBFeHBlcnQgIENvbW1pc3Npb24gaGFzIHRocmVlIHN1YiB3b3JraW5nIGdyb3Vwczog
dGhlIENOR0kgTmV0d29yayBDb25zdHJ1Y3Rpb24gV29ya2luZyAgR3JvdXAsIHRoZSBOZXR3b3Jr
IEFwcGxpY2F0aW9uIGFuZCBTZXJ2aWNlIFdvcmtpbmcgR3JvdXAgYW5kIHRoZSBOZXR3b3JrIFIm
RCBhbmQgIEluZHVzdHJpYWxpemF0aW9uIFdvcmtpbmcgR3JvdXAuIA0KIA0KQ0VSTkVUMiAoTmV4
dCBHZW5lcmF0aW9uIEVkdWNhdGlvbiBhbmQgUmVzZWFyY2ggTmV0d29yayBpbiBDaGluYSkgaXMg
dGhlIGJpZ2dlc3QgIE5hdGl2ZSBJUHY2IG5ldHdvcmsgYXJvdW5kIHRoZSB3b3JsZCB3aGljaCBj
b25uZWN0IDEwMCsgVW5pdmVyc2l0aWVzIGFuZCAxMDArICBSZXNlYXJjaCBJbnN0aXR1dGVzIGF0
IDFHYnBzKyANCkNoaW5hIE1vYmlsZTogICAgTW9iaWxlIE9wZXJhdG9yIHdpdGggbGFyZ2VzdCBj
YXBhY2l0eSBpbiB0aGUgd29ybGQNCkNoaW5hIFRlbGVjb206ICBNb3N0IHNvdXRoIHBhcnQgb2Yg
Q2hpbmEgZml4ZWQgb3BlcmF0b3IgYW5kIG5ldHdvcmsgYWNjZXNzIHByb3ZpZGVyDQpDaGluYSBV
bmljb206ICAgTm8uIDMgTW9iaWxlIE9wZXJhdG9yIGFuZCBOby4gMiBDRE1BIG9wZXJhdG9yIHJh
bmtlZCBpbiBudW1iZXIgb2YgIHN1YnNjcmliZXIgaW4gdGhlIHdvcmxkDQpDaGluYSBOZXRjb206
ICAgTW9zdCBub3J0aCBwYXJ0IG9mIENoaW5hIGZpeGVkIG9wZXJhdG9yIGFuZCBuZXR3b3JrIGFj
Y2VzcyBwcm92aWRlcg0KQ1NUTkVUICAgICAgICAgIChDaGluYSBTY2llbmNlIGFuZCBUZWNobm9s
b2d5IE5ldHdvcmspDQpDaGluYSBSYWlsY29tOiAgTmV3IHRlbGVjb20gb3BlcmF0b3IuDQoNCg==
Disclaimer:
The contents of this e-mail, and its attachments, if any, are confidential and may be protected
by law against any unauthorized use.  If you have received this e-mail by mistake or have
reason to believe that you are not the intended recipient, please notify the sender by reply
e-mail as soon as possible and delete it from your computer system immediately thereafter.
If you are not the intended recipient, you must not copy this e-mail or attachment or disclose
the contents to any other person.  While we have made every effort to keep our network virus free,
we take no responsibility for any computer virus which might be transferred by way of this e-mail.


--===============1294435564==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1294435564==--



From ietf-bounces@ietf.org Sun Jan 29 13:29:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3HIw-0005hx-J8; Sun, 29 Jan 2006 13:29:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3HIv-0005fy-GM
	for ietf@megatron.ietf.org; Sun, 29 Jan 2006 13:29:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16625
	for ; Sun, 29 Jan 2006 13:27:48 -0500 (EST)
Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123]
	helo=norman.insensate.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3HTJ-0007Z2-4e
	for ietf@ietf.org; Sun, 29 Jan 2006 13:40:21 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by norman.insensate.co.uk (Postfix) with ESMTP
	id 7C5747A742; Sun, 29 Jan 2006 18:28:44 +0000 (GMT)
In-Reply-To: <824559A0-1D1D-4DB3-B445-0F646F99C344@multicasttech.com>
References: 
	<43DA42D4.4040005@dcrocker.net>
	<824559A0-1D1D-4DB3-B445-0F646F99C344@multicasttech.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: lconroy 
Date: Sun, 29 Jan 2006 18:28:43 +0000
To: Marshall Eubanks 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Marshall,
   How the heck did you manage to find *anywhere* in the South of  
England
where the nearest pub was over 10 miles away? As a Southerner, I'm  
amazed.

Seriously, folks, I try to avoid driving on the wrong side of the  
road, so is
there a problem in walking about in this area of Dallas at this time  
of year?

Also, will the Agenda give longer breaks for Lunch?
- it would seem that it will take some time to get to an external food
   joint, eat, and get back.

BTW - Answer to voodoo poll = B/yes. I sure hope that there is good time
to decide on venues in the future, and that decisions on venue (e.g.  
away
from Las Vegas) are not delayed.

Finally, my congratulations and sympathies to the hosts who "stepped  
up to
the plate" on short notice.

all the best,
   Lawrence

On 28 Jan 2006, at 18:02, Marshall Eubanks wrote:
> This can be argued both ways. (The most productive meeting I think  
> that I ever went to
> was a physics standardization meeting in a castle in the South of  
> England with nothing of note within 20 miles, and not even a pub  
> within 10 miles. All we could do is work, meet and bond. And raid  
> the wine cellar.)
>
> However, to be constructive, I would like to suggest adding two yes  
> or no questions to the next meeting
> questionnaire :
>
> A.) Do you feel that the venue chosen for the meeting was too  
> remote, in terms of accessibility
> of restaurants, bars, your or other hotels, etc. ?
>
> B.) (If "A" is answered yes.) Would having another IETF meeting in  
> a site that is similarly remote make it
> less likely that you would attend ?
>
> BTW, the last time I was in Dallas my wife and I walked all over  
> downtown, including over to Dealy Plaza.
> It was hot, we were the only pedestrians except for some street  
> people (except at the Plaza itself),
> and we never saw a cab (except at a hotel we went by). My advice  
> is, if you really want to get around, rent a car.
>
> Regards
> Marshall
>
> On Jan 27, 2006, at 10:57 AM, Dave Crocker wrote:
>
>>> Looking at the restaurant map, it seems that the IETF65 hotel/ 
>>> venue is basically "in the middle of nowhere".  Restaurants are  
>>> typically 2+ miles away, and my guess is that public  
>>> transportation or walking aren't options.
>>
>>
>> Periodically, the IETF venue is quite isolated.
>>
>> This makes it inconvenient not only for getting to restaurants but  
>> also for attendees wanting to stay at cheaper hotels.
>>
>> Frequently it even makes it difficult to just walk around.
>>
>> d/
>> -- 
>>
>> Dave Crocker
>> Brandenburg InternetWorking
>> 
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 29 18:44:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3MDQ-0006kX-1o; Sun, 29 Jan 2006 18:44:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3MDO-0006k8-2m
	for ietf@megatron.ietf.org; Sun, 29 Jan 2006 18:44:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08997
	for ; Sun, 29 Jan 2006 18:42:31 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F3MNu-00087k-2y
	for ietf@ietf.org; Sun, 29 Jan 2006 18:55:07 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-3.cisco.com with ESMTP; 29 Jan 2006 15:43:55 -0800
X-IronPort-AV: i="4.01,231,1136188800"; 
	d="scan'208"; a="398063969:sNHT27584764"
Received: from chappe.cisco.com (chappe.cisco.com [171.71.182.172])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0TNhtWF027283;
	Sun, 29 Jan 2006 15:43:55 -0800 (PST)
Received: from chappe.cisco.com (chappe.cisco.com [171.71.182.172])
	by chappe.cisco.com (8.13.4/8.13.4) with ESMTP id k0TNhsvQ032724;
	Sun, 29 Jan 2006 15:43:54 -0800
Date: Sun, 29 Jan 2006 15:43:54 -0800 (PST)
From: Ole Jacobsen 
To: lconroy 
In-Reply-To: 
Message-ID: 
References: 
	<43DA42D4.4040005@dcrocker.net>
	<824559A0-1D1D-4DB3-B445-0F646F99C344@multicasttech.com>
	
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Ole Jacobsen 
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Just be sure to stop at the gun rental place at the airport on the way in, 
this is Texas :-)



Ole J. Jacobsen 
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   GSM: +1 415-370-4628
E-mail: ole@cisco.com  URL: http://www.cisco.com/ipj



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 29 20:03:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3NSY-0001Ee-DT; Sun, 29 Jan 2006 20:03:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3NSW-0001Dt-Mh
	for ietf@megatron.ietf.org; Sun, 29 Jan 2006 20:03:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13439
	for ; Sun, 29 Jan 2006 20:02:03 -0500 (EST)
Received: from mtagate2.uk.ibm.com ([195.212.29.135])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3Nct-0001ZL-7v
	for ietf@ietf.org; Sun, 29 Jan 2006 20:14:40 -0500
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0U13RKS268014
	for ; Mon, 30 Jan 2006 01:03:27 GMT
Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com
	[9.149.37.213])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP
	id k0U13R7x200700 for ; Mon, 30 Jan 2006 01:03:27 GMT
Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k0U13R96008351 for ; Mon, 30 Jan 2006 01:03:27 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k0U13RxS008348; Mon, 30 Jan 2006 01:03:27 GMT
Received: from zurich.ibm.com (sig-9-145-252-142.de.ibm.com [9.145.252.142])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id CAA49356;
	Mon, 30 Jan 2006 02:03:25 +0100
Message-ID: <43DD65DC.4010307@zurich.ibm.com>
Date: Mon, 30 Jan 2006 02:03:24 +0100
From: Brian E Carpenter 
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: lconroy 
References: 	<43DA42D4.4040005@dcrocker.net>	<824559A0-1D1D-4DB3-B445-0F646F99C344@multicasttech.com>
	
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

...

> so is
> there a problem in walking about in this area of Dallas at this time  of 
> year?

Possibly being arrested for not burning enough petroleum?

Seriously, taxis may be necessary once in a while.


> 
> Also, will the Agenda give longer breaks for Lunch?
> - it would seem that it will take some time to get to an external food
>   joint, eat, and get back.

There are supposed to be multiple lunch options close by. So no, we
won't be extending the break.

    Brian


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Sun Jan 29 21:26:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3OkP-0006kP-Uh; Sun, 29 Jan 2006 21:26:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3OkI-0006kC-Cd
	for ietf@megatron.ietf.org; Sun, 29 Jan 2006 21:26:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18447
	for ; Sun, 29 Jan 2006 21:24:38 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3Oum-0003bO-6v
	for ietf@ietf.org; Sun, 29 Jan 2006 21:37:16 -0500
Received: from [192.168.0.3] (adsl-71-131-62-129.dsl.sntc01.pacbell.net
	[71.131.62.129]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0U2QVYZ015834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 29 Jan 2006 18:26:31 -0800
Message-ID: <43DD792F.6090506@dcrocker.net>
Date: Sun, 29 Jan 2006 18:25:51 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Marshall Eubanks 
References: 
	<43DA42D4.4040005@dcrocker.net>
	<824559A0-1D1D-4DB3-B445-0F646F99C344@multicasttech.com>
In-Reply-To: <824559A0-1D1D-4DB3-B445-0F646F99C344@multicasttech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



> However, to be constructive, I would like to suggest adding two yes or 
> no questions to the next meeting questionnaire :
> 
> A.) Do you feel that the venue chosen for the meeting was too remote, in 
> terms of accessibility of restaurants, bars, your or other hotels, etc. ? >
> B.) (If "A" is answered yes.) Would having another IETF meeting in a site
> that is similarly remote make it less likely that you would attend ? >


Asking questions like this could be quite useful.

The challenge is in making sure that the right people get asked.

If the questions are asked of people who already attended the meeting, then the 
sampling is of people with the resources to accommodate the current style of 
meeting arrangement.

While some might grouse about one characteristic or another of the current 
choices, the questionnaire will not serve to understand the needs of people who 
are *unable to attend* IETF meetings because of current costs, due to 
remoteness, hotel fees, or the like.

(By the way, the "what will make it less likely you will attend" type of 
question is often interesting to ask, but is usually not a good predictor of 
actual behavior.)

d/
-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 06:33:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3XHq-0005Qj-Ub; Mon, 30 Jan 2006 06:33:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3XHp-0005Od-0t; Mon, 30 Jan 2006 06:33:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15440;
	Mon, 30 Jan 2006 06:31:49 -0500 (EST)
Received: from b.painless.aaisp.net.uk ([81.187.81.52] helo=smtp.aaisp.net.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F3XSP-0000LA-00; Mon, 30 Jan 2006 06:44:31 -0500
Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43)
	id 1F3XHJ-0003sH-Ky; Mon, 30 Jan 2006 11:33:01 +0000
Message-ID: <43DDF9EF.40405@dial.pipex.com>
Date: Mon, 30 Jan 2006 11:35:11 +0000
From: Elwyn Davies 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tools Team Discussion 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: xml2rfc mailing list ,
	IETF Discussion 
Subject: Finding issue trackers for drafts
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi.

One additional piece of information relating to drafts that ism't 
included in the drafts database is the location of the issue tracker (if 
any).  They aren't all in one place at the moment which makes life more 
difficult than necessary for the casual inspector... for example...

- I was just faced with an email relating to a l2vpn document which I 
reviewed for the gen-art team which stated that 'there were some issues 
in the issue tracker' but no note of where I could locate the tracker.  
Now clearly I can bug the authors but I am sure they have better things 
to do.

- I know where to find some of the nsis issue trackers but I also know 
they aren't obvious to a casual observer.

So two thoughts:
- Could this information be collated on the info pages (subject to a 
good way of finding it out)?
- Would it be a good idea to incorporate the location of the issue 
tracker into drafts as a matter of course (might even encourage their use)?

xml2rfc might be able to provide some sort of support perhaps but that 
isn't essential.

Regards,
Elwyn

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 09:00:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3ZZZ-0005QT-RR; Mon, 30 Jan 2006 09:00:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3ZZU-0005O4-L0
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 08:59:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24546
	for ; Mon, 30 Jan 2006 08:58:02 -0500 (EST)
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3Zjx-0004UY-SI
	for ietf@ietf.org; Mon, 30 Jan 2006 09:10:47 -0500
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com
	[47.129.230.99])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	k0UDtNW13213; Mon, 30 Jan 2006 08:55:23 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 30 Jan 2006 08:59:12 -0500
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D5051A85D9@zcarhxm2.corp.nortel.com>
Thread-Topic: IETF65 hotel location
Thread-Index: AcYlRZHx3BLEzf8hRQKFp6G+6LD9zQAX3Qhw
From: "Ed Juskevicius" 
To: , "Marshall Eubanks" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
Subject: RE: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dave Crocker write:
> the questionnaire will not serve to understand the needs
> of people who are *unable to attend*

Perhaps we should ask a more open-ended question (i.e. "B" below):

A) Did you attend IETF-65?
B) If not, why not?

Regards,

Ed=20

-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
Dave Crocker
Sent: Sunday, January 29, 2006 9:26 PM
To: Marshall Eubanks
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location




> However, to be constructive, I would like to suggest adding two yes or
> no questions to the next meeting questionnaire :
>=20
> A.) Do you feel that the venue chosen for the meeting was too remote,=20
> in
> terms of accessibility of restaurants, bars, your or other hotels,
etc. ? >
> B.) (If "A" is answered yes.) Would having another IETF meeting in a
site
> that is similarly remote make it less likely that you would attend ? >


Asking questions like this could be quite useful.

The challenge is in making sure that the right people get asked.

If the questions are asked of people who already attended the meeting,
then the=20
sampling is of people with the resources to accommodate the current
style of=20
meeting arrangement.

While some might grouse about one characteristic or another of the
current=20
choices, the questionnaire will not serve to understand the needs of
people who=20
are *unable to attend* IETF meetings because of current costs, due to=20
remoteness, hotel fees, or the like.

(By the way, the "what will make it less likely you will attend" type of

question is often interesting to ask, but is usually not a good
predictor of=20
actual behavior.)

d/
--=20

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 10:59:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3bRJ-0001br-B1; Mon, 30 Jan 2006 10:59:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3bRH-0001bJ-9P
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 10:59:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02970
	for ; Mon, 30 Jan 2006 10:57:52 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3bbv-0008Me-Oo
	for ietf@ietf.org; Mon, 30 Jan 2006 11:10:37 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3840268; Mon, 30 Jan 2006 10:55:29 -0500
In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D5051A85D9@zcarhxm2.corp.nortel.com>
References: <0BDFFF51DC89434FA33F8B37FCE363D5051A85D9@zcarhxm2.corp.nortel.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <47F6C2C1-E0A0-4356-A4A1-D4B64881C52D@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks 
Date: Mon, 30 Jan 2006 10:59:20 -0500
To: "Ed Juskevicius" 
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: 7bit
Cc: dcrocker@bbiw.net, ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear Ed;

This might also be a useful question to ask; it might be better to  
make it multiple choice along the lines of
(B. If not, because of
- general expense
- registration fees
- difficulty in arranging visa's or other travel preparations
- interference from other meetings or work schedule
- location of the meeting city
- location of the meeting venue )

However, that wasn't quite what I was suggesting. I have heard this  
issue of nearby access to
"stuff" come up before, and I know some people consider it quite  
important, so much
so that certain locations might be ruled out just for only having  
venues that are too isolated in their urban context.

So, in the context of a location that may be considered isolated, I  
think it might be
useful to consider this an experiment, and judge the reaction of the  
community after
the meeting towards this variable. Note that this would require  
polling those who attended, rather than those
who did not.

Regards
Marshall


On Jan 30, 2006, at 8:59 AM, Ed Juskevicius wrote:

> Dave Crocker write:
>> the questionnaire will not serve to understand the needs
>> of people who are *unable to attend*
>
> Perhaps we should ask a more open-ended question (i.e. "B" below):
>
> A) Did you attend IETF-65?
> B) If not, why not?
>
> Regards,
>
> Ed
>
> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On  
> Behalf Of
> Dave Crocker
> Sent: Sunday, January 29, 2006 9:26 PM
> To: Marshall Eubanks
> Cc: ietf@ietf.org
> Subject: Re: IETF65 hotel location
>
>
>
>
>> However, to be constructive, I would like to suggest adding two  
>> yes or
>> no questions to the next meeting questionnaire :
>>
>> A.) Do you feel that the venue chosen for the meeting was too remote,
>> in
>> terms of accessibility of restaurants, bars, your or other hotels,
> etc. ? >
>> B.) (If "A" is answered yes.) Would having another IETF meeting in a
> site
>> that is similarly remote make it less likely that you would  
>> attend ? >
>
>
> Asking questions like this could be quite useful.
>
> The challenge is in making sure that the right people get asked.
>
> If the questions are asked of people who already attended the meeting,
> then the
> sampling is of people with the resources to accommodate the current
> style of
> meeting arrangement.
>
> While some might grouse about one characteristic or another of the
> current
> choices, the questionnaire will not serve to understand the needs of
> people who
> are *unable to attend* IETF meetings because of current costs, due to
> remoteness, hotel fees, or the like.
>
> (By the way, the "what will make it less likely you will attend"  
> type of
>
> question is often interesting to ask, but is usually not a good
> predictor of
> actual behavior.)
>
> d/
> -- 
>
> Dave Crocker
> Brandenburg InternetWorking
> 
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 11:49:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3cDr-00020r-Bh; Mon, 30 Jan 2006 11:49:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3cDn-0001xd-7K
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 11:49:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06592
	for ; Mon, 30 Jan 2006 11:48:00 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3cOS-0001b4-Fx
	for ietf@ietf.org; Mon, 30 Jan 2006 12:00:45 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0UGnNgx001648; Mon, 30 Jan 2006 11:49:23 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04636; 
	Mon, 30 Jan 2006 11:49:23 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Mon, 30 Jan 2006 11:49:22 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C8863C6@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'ietfdbh@comcast.net'" , ietf@ietf.org
Date: Mon, 30 Jan 2006 11:49:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: 
Subject: RE: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

David,

	As I understand it, it would be a man-in-the-middle
attack if you sat at a table and ordered a Burrito from a
person you thought was a waiter.  That person then goes to
the counter, orders two burritos and a large coffee, to go.
They then deliver one Burrito to you, along with the bill,
and takes the other Burrito and the coffee with them. 

	What you describe is more like "high-jacking" the 
transport mechanism...

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of David B Harrington
--> Sent: Saturday, January 28, 2006 1:12 PM
--> To: 'Spencer Dawkins'; ietf@ietf.org
--> Subject: RE: IETF65 hotel location
--> 
--> Hi,
--> 
--> This conversation of the IETF65 location started with an issue of
--> security.
--> 
--> I'd like to get this discussion back on track.
--> What are the security requirements for a distributed burrito
--> processing protocol?
--> If you are traveling from the conference hotel to a 
--> restaurant and are
--> mugged, is that considered a man-in-the-middle attack?
--> 
--> dbh
--> 
--> > -----Original Message-----
--> > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On 
--> > Behalf Of Spencer Dawkins
--> > Sent: Friday, January 27, 2006 3:26 PM
--> > To: ietf@ietf.org
--> > Subject: Re: IETF65 hotel location
--> > 
--> > Hi, Mike,
--> > 
--> > >> If we could morph it into a signup system that 
--> distributed people
--> > >> according to restauant capacity and avoided the problem 
--> > that someone
--> > >> says "I hear there's a burrito place on X street" and a herd of
--> 300
--> > >> IETFers shows up there, since they don't know any other 
--> > places to go,
--> > >> then you'd really have something.
--> > >
--> > > I'm afraid it's beyond IETF's expertise to come up with
--> > > distributed burrito processing protocols.
--> > >
--> > > Mike
--> > 
--> > If you think about this for a minute, you would realize that 
--> > (1) we not only 
--> > have protocols for this, but we have running code, and (2) 
--> > "too much focus 
--> > on distributed burrito processing" might explain a lot about 
--> > where we are 
--> > and how we got here! :-)
--> > 
--> > Thanks,
--> > 
--> > Spencer, who is wondering what a "dining protocol designers" 
--> > multitasking 
--> > algorithm might look like, with a burrito between every pair 
--> > of protocol 
--> > designers (with apologies to the dining philosophers) 
--> > 
--> > 
--> > 
--> > _______________________________________________
--> > Ietf mailing list
--> > Ietf@ietf.org
--> > https://www1.ietf.org/mailman/listinfo/ietf
--> > 
--> 
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 11:57:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3cLR-0004dg-3O; Mon, 30 Jan 2006 11:57:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3cLO-0004ZZ-CN
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 11:57:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07967
	for ; Mon, 30 Jan 2006 11:55:59 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3cWB-00024V-3Q
	for ietf@ietf.org; Mon, 30 Jan 2006 12:08:44 -0500
Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001594847.msg
	for ; Mon, 30 Jan 2006 17:59:44 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Mon, 30 Jan 2006 17:57:11 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: Meeting Survey Results
Thread-Index: AcYlvjYzdK9QCJGxEdqvOQANky3PwA==
In-Reply-To: <20060126030301.GA26268@nokia.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060130:ietf@ietf.org::G2Am6s3NMa8mtxBJ:00001CAW
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Mon, 30 Jan 2006 17:59:46 +0100
X-MDAV-Processed: consulintel.es, Mon, 30 Jan 2006 17:59:48 +0100
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Content-Transfer-Encoding: 7bit
Subject: Re: Meeting Survey Results
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi David,

I'm not really sure if we are able to completely understand each other, may
be my fault with my poor English.

I'm not saying anyone is enforcing one or the other protocol, I just say
that it may be wrong to assume, even if we believe that "a" is better, that
it will work if almost everyone move to "a". And then we will have
recommended everyone to invest in something that was not so useful ...

I'm not enforcing the NOC to make a b/g network, especially once has been
explained why "a" seems to be better. On the other way around, I'm sure that
they are doing the best that can be done, absolutely no doubt on that.

Once more, some times providing "details" could be more helpful than just
decisions w/o explanations about why.

Let's close this here, please.

Regards,
Jordi




> De: David Kessens 
> Responder a: 
> Fecha: Wed, 25 Jan 2006 19:03:01 -0800
> Para: JORDI PALET MARTINEZ 
> CC: "ietf@ietf.org" 
> Asunto: Re: Meeting Survey Results
> 
> 
> Jordi,
> 
> On Wed, Jan 25, 2006 at 05:47:17PM -0400, JORDI PALET MARTINEZ wrote:
>> 
>> I understand your point, which somehow has been replied by some other
>> comments in the list such as:
>> 
>> - Is not so clear that this technology (a) will still work if all use it.
>> - We are asking to change to 75% of the attendees.
> 
> I don't understand why you keep harping on this issue that only exists
> because you have misread our announcement.
> 
> We have been very forthcoming and clear why we like people to bring
> 802.11a cards.
> 
> We are not forcing anybody to use 802.11a and there is absolutely no
> talk of not providing 802.11b wireless access. We *RECOMMEND* that
> people bring and use 802.11a gear because we believe that *EVERYBODY*,
> including people who only have 802.11b cards, will have a better
> network experience.
> 
> The only thing that we should have mentioned, but that we overlooked
> as most cards/dongles on the market now do 802.11a,b&g, is that we
> don't recommend to leave your 802.11b equipment at home. The hotel is
> very large and there will be areas in the fringes that will have
> better 802.11b coverage or that are only covered by the hotels own
> 802.11b service.
> 
>> - 50USD may be a lot for some people.
> 
> You can easily get cards *LESS* than US$50. It is your judgement call
> whether you believe that this investment is worth it. Don't buy a
> 802.11a card/dongle if you think it is too much. Nobody forces you to
> buy one.
> 
> David Kessens
> ---
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 12:16:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3cdn-0008ET-Ok; Mon, 30 Jan 2006 12:16:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3cdl-0007zS-5S
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 12:16:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09737
	for ; Mon, 30 Jan 2006 12:14:44 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3coK-0002os-L3
	for ietf@ietf.org; Mon, 30 Jan 2006 12:27:29 -0500
Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001594890.msg
	for ; Mon, 30 Jan 2006 18:18:31 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Mon, 30 Jan 2006 18:15:57 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: Interim meetings planning [was Softwires Interim Meeting]
Thread-Index: AcYlwNVZE/vOFJG0EdqvOQANky3PwA==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060130:ietf@ietf.org::kt8UfUMZQS3B8sfw:00002HLw
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Mon, 30 Jan 2006 18:18:33 +0100
X-MDAV-Processed: consulintel.es, Mon, 30 Jan 2006 18:18:37 +0100
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
Content-Transfer-Encoding: 7bit
Subject: Re: Interim meetings planning [was Softwires Interim Meeting]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi John,

Thanks for your input. See below, in-line.

Regards,
Jordi




> De: John C Klensin 
> Responder a: 
> Fecha: Thu, 26 Jan 2006 16:53:51 -0500
> Para: 
> CC: "ietf@ietf.org" 
> Asunto: Re: Interim meetings planning [was Softwires Interim Meeting]
> 
> Jordi,
> 
> Let me make a very general observation, based on my experience
> with the IETF.
> 
> Where administrative procedures are concerned, the IETF
> functions well when the IESG is given general guidance by the
> community but then applies good judgment and discretion to the
> situations that arise.  If the community observes that the
> IESG's judgment is not good enough, we readjust the general
> guidance -- by complaints to individual ADs, by notes to the
> IESG, by discussion on the IETF list, or even via appeals if
> that is needed.  If one or more specific ADs regularly abuse
> that discretionary authority, they get abused in return on
> mailing lists, in plenaries, in discussions with nomcoms, and,
> if necessary, by recalls or at least serious discussions of
> recalls.  

Agree, but I feel that there is a lack of administrative procedure here,
which already caused some troubles. I'm trying to avoid repeating mistakes,
improving the guidance and making sure the process is more open and fair.

I fear that in this kind of situation (an Interim meeting unfairly setup),
an appeal will not sort out the problem.

> 
> By contrast, when we try to write down the specific rules that
> should be applied, or the list of rules or steps they should use
> in making decisions, and try to reach consensus on them, two
> things happen, and happen over and over again:
> 
> (1) We spend (I would say "waste", but you may
> reasonably disagree) a huge amount of time discussing
> both the details of the proposals and whether or not the
> proposals are appropriate.  In my personal opinion, the
> IETF would be a better and more effective place to get
> work done if a higher percentage of the community's
> energy went into technical work than into discussions of
> procedural details.

Agree in that we need more people, and working more in technical documents,
but we like it or not, procedures are needed to make sure that the technical
work can be followed up. Otherwise, we may break our main rule: consensus,
not sure if say here also fairness.

> 
> (2) We get the details wrong, resulting in more time
> being spent correcting the details of the rules that,
> IMO, we might have been better off not having in the
> first place.

I really much prefer to avoid problems when they may be too late to get
recovered. Details need to be put in place for that.

> 
> In addition, if we get the details seriously wrong, the IESG has
> historically responded by applying a meta-rule.  That meta-rule
> is that their first obligation is to keep the IETF functioning.
> And, on that basis, once they conclude that whatever has been
> written down and established by consensus makes no sense, they
> simply ignore ignore it.   That action creates a very unhappy
> and unhealthy environment, whether it is appealed or not, but
> often may still be better than the alternative.

Not really sure if I've seen a case like the one that you describe, but
really doubt it may be the case for what I'm proposing.

> 
> So, for a case like this, I suggest that you might want to have
> a conversation, with any AD you think is likely to listen, about
> whether the present guidance is sufficient and whether
> additional guidance or discussion would help.  ADs persuading
> other ADs about IESG matters and customs can be far more
> effective than any of us writing I-Ds to pin down details.  If
> there are no ADs with whom you feel that you can have such a
> conversation, then I think you need to chat with the Nomcom but
> I, at least, have generally found ADs to be receptive on these
> sorts of issues... even ADs with whom I generally don't get
> along well (not that there are any of those on the current IESG).

Agree, and indeed my proposal was the outcome of a few email exchange with
an AD ;-) He actually suggested to include this in the
venue-selection-criteria document, which for me, and also talking to others,
was not the best choice ...

> 
> Let's try to avoid yet another round of stretched-out
> discussions on, e.g., how many days constitutes adequate notice,
> how to measure the accessibility of a location, what conditions
> are sufficient to justify an exception, and whatever other
> questions start to arise as soon as one tries to lock down
> specific rules.  If an interim meeting is announced that is
> likely to cause specific harm (as distinct from being an issue
> of principles about dates and locations), complain to the
> relevant AD and, if necessary, appeal the decision to approve
> the meeting.   But most of us, yourself certainly included, have
> more productive things to do with our time than starting another
> one of these procedural debate threads.
> 
> Just my opinion, of course.

And thanks a lot for it !

>      john
> 
> 
> --On Thursday, 26 January, 2006 10:02 -0400 JORDI PALET MARTINEZ
>  wrote:
> 
>> Hi Harald,
>> 
>> In my opinion the 30 days rule is a good one, it may be
>> possible to make it a bit flexible, just indicating 3-4 weeks
>> before a meeting instead of 30 days. My comment, based on very
>> recent experience, is that the rest of the Interim meeting
>> planning procedure must be described more explicitly.
>> 
>> The idea is not to have this in a new draft, or if actually we
>> want it, make it in specific one, not mixed with anything else.
>> 
>> The actual rules on this are at
>> http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt
>> 
>> "The area directors will evaluate proposed interim meetings
>> and conference calls to be sure that that the location,
>> timing, etc.  do not unfairly favor some subset of the
>> ...
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 12:18:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3cfC-0000Y7-3g; Mon, 30 Jan 2006 12:18:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3cfA-0000UP-A7
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 12:18:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09954
	for ; Mon, 30 Jan 2006 12:16:24 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3cpw-0002ts-Np
	for ietf@ietf.org; Mon, 30 Jan 2006 12:29:10 -0500
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0UHGY615252;
	Mon, 30 Jan 2006 09:16:34 -0800 (PST)
From: Bob Braden 
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id JAA16888;
	Mon, 30 Jan 2006 09:16:34 -0800 (PST)
Date: Mon, 30 Jan 2006 09:16:34 -0800 (PST)
Message-Id: <200601301716.JAA16888@gra.isi.edu>
To: ietf@ietf.org
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: braden@ISI.EDU
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


I don't understand why this discussion keeps going on and on, much
less why it started in the first place.

Folks, surely we have more important issues of Internet technology to
talk about, rather than jaw-boning about a task that we have delegated
to a competant organization.  That organization has in general done an
excellent job over the past many years, and I for one am confident they
will continue.  They are sensitive to input, but they get the job
done.  Site selection and contracting requires a difficult balancing
act to perform, between the ideal and the real.  As far as I can see,
they do a much better job of than the IETF could possibly hope for.  I
am thankful for their dedication and expertise.

Let's stop spending our resources micro-managing the Secretariat,
and deal with the problems that we are supposed to be solving.

Bob Braden


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 12:25:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3cmV-0002zV-4h; Mon, 30 Jan 2006 12:25:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3cmS-0002yW-KW
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 12:25:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10457
	for ; Mon, 30 Jan 2006 12:23:56 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3cxF-00038F-Hm
	for ietf@ietf.org; Mon, 30 Jan 2006 12:36:41 -0500
Received: (qmail 6466 invoked from network); 30 Jan 2006 17:25:30 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 30 Jan 2006 17:25:30 -0000
Date: 30 Jan 2006 17:25:30 -0000
Message-ID: <20060130172530.17513.qmail@simone.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <47F6C2C1-E0A0-4356-A4A1-D4B64881C52D@multicasttech.com>
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>So, in the context of a location that may be considered isolated, I
>think it might be useful to consider this an experiment, and judge
>the reaction of the community after the meeting towards this
>variable.

A reasonable question, but it probably needs to be picked out a little
more than that.  For us self-employed weenies, the price of the trip
is an issue, and part of the problem of isolated hotels is that they
tend to have restaurants where the burger costs $23.95 and takes an
hour to arrive.  In this case, there are cheaper hotels nearby, but
unless you want to eat at Denny's, the culinary and options are thin.

R's,
John


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 13:41:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3dy3-0001WI-Ey; Mon, 30 Jan 2006 13:41:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3dy0-0001WD-K8
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 13:41:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15835
	for ; Mon, 30 Jan 2006 13:39:57 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3e8o-0005Rf-ES
	for ietf@ietf.org; Mon, 30 Jan 2006 13:52:43 -0500
Received: from [192.168.0.3] (adsl-71-131-62-129.dsl.sntc01.pacbell.net
	[71.131.62.129]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0UIfmEU032253
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2006 10:41:48 -0800
Message-ID: <43DE5DC4.40503@dcrocker.net>
Date: Mon, 30 Jan 2006 10:41:08 -0800
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Bob Braden 
References: <200601301716.JAA16888@gra.isi.edu>
In-Reply-To: <200601301716.JAA16888@gra.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bob Braden wrote:
> I don't understand why this discussion keeps going on and on, much
> less why it started in the first place.

perhaps the difficulty is that you do not suffer from the problems being 
discussed.  that is fine for you, but it does not make the problems small or 
secondary.

when an issue is raised repeatedly, by many different people, it almost always 
has some degree of inherent legitimacy.  that makes it worth attending to.

some tactical problems have strategic impact. in this case, decisions which well 
might serve to make the ietf less inclusive ought to be taken seriously.

it used to be relatively easy and inexpensive to attend ietf meetings.  this no 
longer holds.  that excludes keeps potentially useful participants.

d/
-- 

Dave Crocker
Brandenburg InternetWorking


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 13:57:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3eDM-0004bo-IE; Mon, 30 Jan 2006 13:57:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3eDK-0004aQ-7L
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 13:57:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16994
	for ; Mon, 30 Jan 2006 13:55:28 -0500 (EST)
Received: from parsley.amaranth.net ([204.10.1.23])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3eNo-0005yP-R6
	for ietf@ietf.org; Mon, 30 Jan 2006 14:08:15 -0500
Received: from ancho.senie.com (c-24-34-19-2.hsd1.ma.comcast.net [24.34.19.2])
	(authenticated bits=0)
	by parsley.amaranth.net (8.12.11/8.12.11) with ESMTP id k0UIujX3032129
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Mon, 30 Jan 2006 13:56:47 -0500
Message-Id: <6.2.5.6.2.20060130134946.07935a98@senie.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 30 Jan 2006 13:53:25 -0500
To: ietf@ietf.org
From: Daniel Senie 
In-Reply-To: <20060130172530.17513.qmail@simone.iecc.com>
References: <47F6C2C1-E0A0-4356-A4A1-D4B64881C52D@multicasttech.com>
	<20060130172530.17513.qmail@simone.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: ClamAV version 0.87.1,
	clamav-milter version 0.87 on parsley.amaranth.net
X-Virus-Status: Clean
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 12:25 PM 1/30/2006, John Levine wrote:
> >So, in the context of a location that may be considered isolated, I
> >think it might be useful to consider this an experiment, and judge
> >the reaction of the community after the meeting towards this
> >variable.
>
>A reasonable question, but it probably needs to be picked out a little
>more than that.  For us self-employed weenies, the price of the trip
>is an issue, and part of the problem of isolated hotels is that they
>tend to have restaurants where the burger costs $23.95 and takes an
>hour to arrive.  In this case, there are cheaper hotels nearby, but
>unless you want to eat at Denny's, the culinary and options are thin.

I'll echo John's sentiments, also being self-employed. My IETF 
participation is spotty at best of late based on the expense.

Also being vegan, some locales can be especially difficult. (Memphis 
was sure a challenge). I still have a hard time thinking of a better 
place than Minneapolis in wintertime. The hotel costs weren't bad, 
and who knew Minneapolis was one of the most vegan and vegetarian 
friendly places in the US? 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 14:06:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3eME-0007KB-1u; Mon, 30 Jan 2006 14:06:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3eMB-0007Iz-9i
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 14:06:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17686
	for ; Mon, 30 Jan 2006 14:04:55 -0500 (EST)
Received: from twin.uoregon.edu ([128.223.214.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3eWz-0006HD-3w
	for ietf@ietf.org; Mon, 30 Jan 2006 14:17:42 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by twin.uoregon.edu (8.13.4/8.13.4) with ESMTP id k0UJ6Aw7016609;
	Mon, 30 Jan 2006 11:06:10 -0800
Date: Mon, 30 Jan 2006 11:06:10 -0800 (PST)
From: Joel Jaeggli 
X-X-Sender: joelja@twin.uoregon.edu
To: dcrocker@bbiw.net
In-Reply-To: <43DE5DC4.40503@dcrocker.net>
Message-ID: 
References: <200601301716.JAA16888@gra.isi.edu> <43DE5DC4.40503@dcrocker.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: Bob Braden , ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 30 Jan 2006, Dave Crocker wrote:

> Bob Braden wrote:
>> I don't understand why this discussion keeps going on and on, much
>> less why it started in the first place.
>
> perhaps the difficulty is that you do not suffer from the problems being 
> discussed.  that is fine for you, but it does not make the problems small or 
> secondary.
>
> when an issue is raised repeatedly, by many different people, it almost 
> always has some degree of inherent legitimacy.  that makes it worth attending 
> to.
>
> some tactical problems have strategic impact. in this case, decisions which 
> well might serve to make the ietf less inclusive ought to be taken seriously.
>
> it used to be relatively easy and inexpensive to attend ietf meetings.  this 
> no longer holds.  that excludes keeps potentially useful participants.

It also used to be easy and inexpensive to host one...

contrast say ietf 20 with ietf63.

> d/
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli  	       Unix Consulting 	       joelja@darkwing.uoregon.edu
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 14:49:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3f1o-0000hd-Je; Mon, 30 Jan 2006 14:49:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3f1m-0000h9-Mp
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 14:49:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22050
	for ; Mon, 30 Jan 2006 14:47:44 -0500 (EST)
Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3fCR-000835-0f
	for ietf@ietf.org; Mon, 30 Jan 2006 15:00:32 -0500
Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v8.0.1.R)
	with ESMTP id md50001595161.msg
	for ; Mon, 30 Jan 2006 20:51:27 +0100
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Mon, 30 Jan 2006 20:48:52 +0100
From: JORDI PALET MARTINEZ 
To: "ietf@ietf.org" 
Message-ID: 
Thread-Topic: IETF65 hotel location
Thread-Index: AcYl1jITcNYc9pHJEdqvOQANky3PwA==
In-Reply-To: <43DE5DC4.40503@dcrocker.net>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:060130:ietf@ietf.org::/AmgwozurQLoU5SN:00002J7N
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es
X-Spam-Status: No, score=-4.7 required=4.8 tests=BAYES_00, TO_ADDRESS_EQ_REAL 
	autolearn=no version=3.0.4
X-Spam-Processed: consulintel.es, Mon, 30 Jan 2006 20:51:30 +0100
X-MDAV-Processed: consulintel.es, Mon, 30 Jan 2006 20:51:31 +0100
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: quoted-printable
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I've abstained myself to comment on this thread until now ... I prefer not
to judge until I actually visit the venue and see the real situation,
because it will be unfair to discover that this venue has been selected
being distant to downtown, when this was the excuse given to me for not
accepting Madrid, which has been proposed since 2001. Then we had San Diego,
which was a much better case, and I though it will never again happen ...
Will see ...

The point here is:
1) I agree with Dave: something that is being commented repeatedly ... Means
is not satisfying people and may be a real problem
2) Those that are expressing opinions on this thread, may be will like to
provide further inputs to a document in the scope of this thread, which has
been developed precisely to cope with this issues:
http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection
-criteria-04.txt

Regards,
Jordi




> De: Dave Crocker 
> Organizaci=F3n: Brandenburg InternetWorking
> Responder a: 
> Fecha: Mon, 30 Jan 2006 10:41:08 -0800
> Para: Bob Braden 
> CC: "ietf@ietf.org" 
> Asunto: Re: IETF65 hotel location
>=20
> Bob Braden wrote:
>> I don't understand why this discussion keeps going on and on, much
>> less why it started in the first place.
>=20
> perhaps the difficulty is that you do not suffer from the problems being
> discussed.  that is fine for you, but it does not make the problems small or
> secondary.
>=20
> when an issue is raised repeatedly, by many different people, it almost always
> has some degree of inherent legitimacy.  that makes it worth attending to.
>=20
> some tactical problems have strategic impact. in this case, decisions which
> well=20
> might serve to make the ietf less inclusive ought to be taken seriously.
>=20
> it used to be relatively easy and inexpensive to attend ietf meetings.  this
> no=20
> longer holds.  that excludes keeps potentially useful participants.
>=20
> d/
> --=20
>=20
> Dave Crocker
> Brandenburg InternetWorking
> 
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Mon Jan 30 19:58:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3jqh-0006HH-1Q; Mon, 30 Jan 2006 19:58:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3jqe-0006Gn-R6
	for ietf@megatron.ietf.org; Mon, 30 Jan 2006 19:58:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28403
	for ; Mon, 30 Jan 2006 19:56:35 -0500 (EST)
Received: from [66.114.247.24] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3k1L-0006MQ-Ok
	for ietf@ietf.org; Mon, 30 Jan 2006 20:09:25 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id DB470E006A; Mon, 30 Jan 2006 19:57:56 -0500 (EST)
To: "Joel M. Halpern" 
References: 
	<6.2.1.2.0.20060126174556.03287808@mail.stevecrocker.com>
	<023601c622d5$27078320$a9087c0a@china.huawei.com>
	<6.2.1.2.0.20060126210932.032c0cf8@mail.stevecrocker.com>
From: Sam Hartman 
Date: Mon, 30 Jan 2006 19:57:56 -0500
In-Reply-To: <6.2.1.2.0.20060126210932.032c0cf8@mail.stevecrocker.com> (Joel
	M. Halpern's message of "Thu, 26 Jan 2006 21:10:31 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: IETF Discussion 
Subject: Re: I-D ACTION:draft-hartman-mailinglist-experiment-00.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Joel" == Joel M Halpern  writes:

    Joel> As I read the description of the experiment, when the IESG
    Joel> decides on the appropriate response to a specific case, they
    Joel> can decide whether that response is a single-list response
    Joel> or a multi-list response.

That was my intent.
Note there are roughly three responses:

1) Ban from list foo

2) Ban from list foo and bar but no others

3) Ban from list foo, and bar; lists in the set baz can also ban without iesg involvement.

I'd be happy to drop 3 as an option for this experiment if there is
community support.  I'd also be happy to keep 3 as an option.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 07:42:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3uqN-0007jJ-0O; Tue, 31 Jan 2006 07:42:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3uqK-0007fR-Dk; Tue, 31 Jan 2006 07:42:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11883;
	Tue, 31 Jan 2006 07:40:58 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F3v17-0001K4-BI; Tue, 31 Jan 2006 07:53:54 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F3upe-0006W3-UA; Tue, 31 Jan 2006 04:42:03 -0800
Message-Id: <6.2.3.4.2.20060131132315.0681a460@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Tue, 31 Jan 2006 13:41:43 +0100
To: ietf@ietf.org, architecture-discuss@ietf.org
From: "JFC (Jefsey) Morfin" 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-3AD468A3
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: 
Subject: learning about real world NGN issues from the Indian questionnaire
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I can only suggest everyone, wanting to get a practical and real 
world summary of the NGN deployment issues, to read this 
document/questionnaire by the Indian Regulatory Authority. 
(http://www.trai.gov.in/cpaper12jan06.pdf) - 89 pages.

The response of the ISOC Member Roland H. Alden who indicated the 
link is also of high interest 
(http://www.ralden.com/C5/TRAI/default.aspx) (no pdf for the time 
being) to understand the interests at stake.

FYI Mr. S. N. Gupta says he will accept comments until Feb. 13th: 
they will all be published, except if requested otherwise.
jfc

At 17:05 30/01/2006, Roland H. Alden wrote:
>(From the preface of the document itself) "...The valuable comments and
>suggestions from various stakeholders are solicited by TRAI to arrive at
>the recommendations regarding the appropriate policy and regulatory
>steps towards NGN migration in the country. Your comments may be sent
>through e-mail at trai09@bol.net.in or through fax at 011-26191998 by
>3rd February 2006. The paper has also been launched on TRAI's website
>(www.trai.gov.in). For any clarification, the stakeholders may contact
>Mr. S. N. Gupta, Advisor (Converged Networks), TRAI at Tele:
>011-26167914."


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 10:50:41 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3xmD-00049f-9U; Tue, 31 Jan 2006 10:50:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xmB-00049G-9v
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 10:50:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28270
	for ; Tue, 31 Jan 2006 10:49:01 -0500 (EST)
Received: from shu.cs.utk.edu ([160.36.56.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3xx9-0008AB-KY
	for ietf@ietf.org; Tue, 31 Jan 2006 11:02:00 -0500
Received: from localhost (shu [127.0.0.1])
	by shu.cs.utk.edu (Postfix) with ESMTP id 9C5DA13B6E;
	Tue, 31 Jan 2006 10:50:33 -0500 (EST)
Received: from shu.cs.utk.edu ([127.0.0.1])
	by localhost (shu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 15151-02; Tue, 31 Jan 2006 10:50:32 -0500 (EST)
Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182])
	by shu.cs.utk.edu (Postfix) with ESMTP id 0CD1613B26;
	Tue, 31 Jan 2006 10:50:31 -0500 (EST)
Message-ID: <43DF874B.9010506@cs.utk.edu>
Date: Tue, 31 Jan 2006 10:50:35 -0500
From: Keith Moore 
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <200601301716.JAA16888@gra.isi.edu> <43DE5DC4.40503@dcrocker.net>
In-Reply-To: <43DE5DC4.40503@dcrocker.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF65 hotel location
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dave Crocker wrote:

> when an issue is raised repeatedly, by many different people, it almost 
> always has some degree of inherent legitimacy.  that makes it worth 
> attending to.
> 
> some tactical problems have strategic impact. in this case, decisions 
> which well might serve to make the ietf less inclusive ought to be taken 
> seriously.
> 
> it used to be relatively easy and inexpensive to attend ietf meetings.  
> this no longer holds.  that excludes keeps potentially useful participants.

this is one of those rare occasions where Dave and I are in agreement.

Keith

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 11:29:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3yO9-0004Kt-Kq; Tue, 31 Jan 2006 11:29:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yO7-0004JV-Km
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 11:29:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04052
	for ; Tue, 31 Jan 2006 11:28:07 -0500 (EST)
Received: from mail124.messagelabs.com ([85.158.136.19])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3yYx-0001ya-0r
	for ietf@ietf.org; Tue, 31 Jan 2006 11:41:05 -0500
X-VirusChecked: Checked
X-Env-Sender: gash@att.com
X-Msg-Ref: server-8.tower-124.messagelabs.com!1138724874!6543872!42
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 22050 invoked from network); 31 Jan 2006 16:29:29 -0000
Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4)
	by server-8.tower-124.messagelabs.com with SMTP;
	31 Jan 2006 16:29:29 -0000
Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by
	attrh3i.attrh.att.com (7.2.052)
	id 43D3BB52001252B8; Tue, 31 Jan 2006 11:29:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 31 Jan 2006 10:29:28 -0600
Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9A1E@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-ash-alt-formats-01.txt 
Thread-Index: AcYmgbEVnaIs3sMdQrWKm6ok/Mz4KAAARGNA
From: "Ash, Gerald R \(Jerry\), ALABS" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \(Jerry\), ALABS" ,
	Stewart Bryant 
Subject: RE: I-D ACTION:draft-ash-alt-formats-01.txt 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi All,

As a follow-up to our recent discussion, please review the draft at
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.txt,
.pdf version available at
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.pdf.

We propose an experiment based on RFC 3933 allowing, in addition to
ASCII text as a normative input/output format, PDF as an additional
normative output format.

We look forward to your comments and suggestions.

Thanks,
Regards,
Jerry, Stewart, Yaakov

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Tuesday, January 31, 2006 10:50 AM
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-ash-alt-formats-01.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Proposed Experiment: Normative Format in
Addition to ASCII Text
	Author(s)	: J. Ash, et al.
	Filename	: draft-ash-alt-formats-01.txt,.pdf
	Pages		: 8
	Date		: 2006-1-31
=09
Following RFC 3933, the authors propose an experiment allowing, in
   addition to ASCII text as a normative input/output format, PDF as an
   additional normative output format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.txt

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 11:30:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3yP0-0004bv-Lg; Tue, 31 Jan 2006 11:30:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3yOy-0004WE-5a; Tue, 31 Jan 2006 11:30:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04149;
	Tue, 31 Jan 2006 11:28:56 -0500 (EST)
Received: from [213.255.237.116] (helo=HO-SRV-XCH.kabholding.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F3yZi-00020h-TP; Tue, 31 Jan 2006 11:41:53 -0500
Date: Tue, 31 Jan 2006 19:31:34 +0300
MIME-Version: 1.0
Message-ID: <9ABF628243825A49B65382CFCA494427030818@HO-SRV-XCH.kabholding.com>
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Thread-Topic: urgent dhcp request 
thread-index: AcYmg3SC6pcsrsLQTv2TIYRQj+azWAAACgtA
From: "Mohammed Tantawi" 
To: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: quoted-printable
Cc: Ietf@ietf.org
Subject: urgent dhcp request 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear All,

I am in My network Have 200 Users & I need to give them this settings on
the=20
IP- Address :-

IP: 192.168.1.8
SM: 255.255.255.0
GW: 90.0.0.1-metric ( Automatic )=20
DNS: 192.168.1.1

But i want to Add 2 IP Address  on the Network Card which will optain
the IP=20
Address from THE DHCP , and i want to add also 2 Gateway, but one
Gateway=20
will be its matric as default & the Other one will be ( metric 2 ) .

so my questions, how can i configure the DHCP to Broad cast 2 IP-Address
& 2=20
Gateway from one scope ?=20

Please some one help me how can i do that ?


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 13:29:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F40FU-00048y-C4; Tue, 31 Jan 2006 13:29:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F40FQ-00046i-CS; Tue, 31 Jan 2006 13:29:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15794;
	Tue, 31 Jan 2006 13:27:24 -0500 (EST)
Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F40QR-00070J-GY; Tue, 31 Jan 2006 13:40:24 -0500
Received: from [66.114.247.49] ([::ffff:128.107.248.220])
	(AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by zeke.ecotroph.net with esmtp; Tue, 31 Jan 2006 13:28:00 -0500
	id 0158807E.43DFAC31.000046D1
Message-ID: <43DFAC4B.1070309@thinkingcat.com>
Date: Tue, 31 Jan 2006 13:28:27 -0500
From: Leslie Daigle 
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "JFC (Jefsey) Morfin" , "Iesg (E-mail)" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
Content-Transfer-Encoding: 7bit
Cc: IAB , ietf@ietf.org
Subject: IAB Response to Appeal from Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On 4 January 2006, the IAB received an appeal from Jefsey Morfin
appealing the IESG decision to uphold the suspension of his
posting rights to the ietf-languages list. According to the
procedures in Section 6.5.2 of RFC 2026, the IAB has reviewed the
situation and issues the following response.

1. The Appeal Question

The IAB interpreted this appeal to be as follows:

The appeal concerns whether the IESG, in upholding the suspension of Mr.
Morfin's posting privileges to the ietf-languages mailing list, made an
incorrect decision.


2. The Scope and Basis of the Appeal

While Mr. Morfin noted several motivations for his appeal and
requests that several questions be answered in response to his
appeal, the IAB did not consider Mr. Morfin's discussion of
internationalization issues. Rather, the IAB reviewed the appeal
as it applies to the administration of IETF mailing lists and
specifically to the removal of posting rights. In particular, the
conclusions described here narrowly apply to the process used by
the IESG in upholding the 20 Nov 2005 suspension of Mr. Morfin's
posting rights on the ietf-languages mailing list. Finally, in
considering the appeal, we observe that the IESG noted that no
existing explicit mailing list policy RFC was applicable in this
case.

3. The Process used by the IAB to Review the Situation

The question raised by the appeal is whether the IESG followed
the Internet Standards Process in the upholding of the suspension
of Mr. Morfin's posting rights to the ietf-languages mailing
list.

The procedure used by the IAB in considering this appeal has
included:

o Review of the documentation of the IETF's standards procedures
     as described in RFC 2026 and RFC 2418,

o Review of IETF Mailing List Administrative Procedures, as
     documented in RFCs 2418, 3005, 3683, and 3934, and

o Review of the context and history of this appeal

4. IAB Considerations

In its response to Mr. Morfin's initial appeal, the IESG notes:
"RFC 3934 does not strictly speaking, apply to non-WG lists but
we have considered it by analogy". The IAB found that RFC 3934 is
specific to working group mailing lists: Not only is RFC 3934
specifically identified as an update to RFC 2418 (which regards
working group procedures), but the clearly stated purpose of RFC
3934 is to give working group chairs similar authority on a
mailing list as they have in face-to-face meetings. In
particular, a working group chair can "refuse to grant the floor
to any individual who is unprepared or otherwise covering
inappropriate material, or who, in the opinion of the chair, is
disrupting the WG process" during a meeting. It is precisely
because of their designation as working group chair that RFC 3934
provides the chair the ability to suspend posting rights without
IESG approval. This calls into question the suspension of mailing
list posting rights under RFC 3934 other than by working group
chairs on working group mailing lists.

The IAB also reviewed other IETF mailing list management RFCs.
RFC 3683 refers to the "temporary suspension of posting rights to
a specific mailing list." However, we were hard-pressed to find
language in RFC 3683 that could have been applied in either the
initial suspension or the IESG response. In particular, RFC 3683
notes that those temporary suspensions are documented in RFC 2418
(which, like RFC 3934, applies to working group chairs) and RFC
3005 (where the IETF chair, the executive director, and a duly
appointed sergeant-at-arms are the ones empowered to refuse
postings to the ietf@ietf.org mailing list), neither of which
covers the case at hand.  As a result, we find there is no
specific mailing list management process RFC that applies.

While we find that neither RFC 3683 nor RFC 3934 directly apply
in this case, the IAB understands that the IETF must be able to
act in the face of ambiguity in "the rules." Indeed, it would be
a terrible outcome if we found the IESG's decision would have
been reasonable if neither RFC 3683 nor RFC 3934 existed, but now
unreasonable since the documents do exist but don't
apply. Moreover, current well-established practice allows for
mailing list maintainers of any IETF mailing list, without
prior approval, to remove or block posts from viruses or other
operationally-disrupting e-mail sources, and we are not offering
a decision that we believe contradicts that. Responsible parties
must be able to take action even if there is ambiguity or lack of
explicit coverage by specific process documents.

Of course, these actions are not arbitrary: RFC 3934 limits working
group chairs to only restrict posting rights in order to support
constructive work on the working group's chartered activity, and
current list maintainer practice is only to block postings from
operationally-disruptive sources. In the spirit of RFC 2026 and
RFC 3935, those actions must be governed by appropriate judgment
and the basis for such judgments should be clear and public.  The
IAB believes this is imperative in order to ensure that the IETF
continues to function in the most open and fair manner possible,
for all participants.

5. IAB Conclusion on the Appeal

The IAB found that the response provided by the IESG in this
action did not provide sufficient justification to sustain the
banning of Mr. Morfin from the ietf-languages mailing list. In
particular, while the IAB agrees with the IESG that no specific
mailing list process RFCs directly apply in this case, its
response is not sufficiently clear why RFC 3934 is considered
applicable "by analogy". Further, it is also unclear from the
IESG's response what the scope of applicability of RFC 3934 might
be, or when other process RFCs  might be applied "by
analogy". Therefore, the IESG's action does not meet the clear
and public requirement outlined above and the IAB annuls the
IESG's decision in this appeal and sends the matter back to the
IESG for resolution.

Since the suspension period has expired, no remedy is
indicated. However, the IAB recommends that the ambiguities that
gave rise to this appeal be clarified, as described in the
following sections.

6. IAB Recommendations

6.1 Clearly Define the Operation of IETF Mailing Lists

If mailing list participation rules are to be based on
contributing constructively to work items, the IETF should
consider making public charters for those lists (however formal
or informal) so that people understand the scope of the work, the
person responsible for shepherding the discussion in accordance
with the charter, and rules governing participation in those
lists. In particular, future RFCs (or revisions of existing RFCs)
governing mailing list administration should clearly indicate who
the responsible parties are as well as the extent of their
authorities.

6.2 Disambiguate Current Mailing List Administration Procedures

The IAB recommends to the IETF that the ambiguity in the current
procedures be cleared up. In particular: RFCs 3005 and 3934 allow
for posting rights revocation for specific mailing lists (the
IETF main list and working group mailing lists) at the discretion
of people directly responsible to and appointed by the IESG;
RFC 3683 allows for posting rights revocation by any IETF mailing
list maintainer, but only on the basis of an IETF-wide  consensus
call (a high hurdle); current practice allows for posting rights
revocation by mailing list maintainers in the case of operational
emergencies; the large gap in between those procedures is not
addressed, either by BCP or by well-established practice.

6.3 Clearly and Publicly Document IESG Decisions on Appeals

When deciding similar cases in the future, the IAB recommends
that the IESG give clear and public support for the basis of
their decision, either by providing clear documentation of the
interpretation of applicability of existing process or by
referencing well-established current practice.



Leslie Daigle,
IAB Chair.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 13:54:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F40du-0002Rh-2D; Tue, 31 Jan 2006 13:54:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F40dX-0002HY-Rt; Tue, 31 Jan 2006 13:53:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18613;
	Tue, 31 Jan 2006 13:52:12 -0500 (EST)
Received: from [66.114.247.47] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F40oQ-0008Bf-DG; Tue, 31 Jan 2006 14:05:11 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id E712CE006A; Tue, 31 Jan 2006 13:53:35 -0500 (EST)
To: Leslie Daigle 
References: <43DFAC4B.1070309@thinkingcat.com>
From: Sam Hartman 
Date: Tue, 31 Jan 2006 13:53:35 -0500
In-Reply-To: <43DFAC4B.1070309@thinkingcat.com> (Leslie Daigle's message of
	"Tue, 31 Jan 2006 13:28:27 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: IAB , "Iesg \(E-mail\)" , ietf@ietf.org
Subject: Re: IAB Response to Appeal from Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



So, a clarification request:

Am I correctly understanding that the clear and public requirement
does not always imply a process RFC?  In particular, John Klensin has
made an argument that there are a wide variety of matters that are
better handled by operational procedures made available for community
comment than by BCP document.

It's my reading that the IAB is interested in making sure that the
processes and rules are clear and public, not that they are all
codified in BCP.


I'm not looking for a formal response from the IAB but would
appreciate comments from its members.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 14:08:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F40rc-0006a5-Mu; Tue, 31 Jan 2006 14:08:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F40rZ-0006Yz-Cd
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 14:08:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20011
	for ; Tue, 31 Jan 2006 14:06:41 -0500 (EST)
Received: from [66.114.247.47] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F412R-0000Ib-Tz
	for ietf@ietf.org; Tue, 31 Jan 2006 14:19:41 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 42362E006A; Tue, 31 Jan 2006 14:08:07 -0500 (EST)
To: "Ash, Gerald R (Jerry), ALABS" 
References: <9473683187ADC049A855ED2DA739ABCA09FA9A1E@KCCLUST06EVS1.ugd.att.com>
From: Sam Hartman 
Date: Tue, 31 Jan 2006 14:08:07 -0500
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9A1E@KCCLUST06EVS1.ugd.att.com>
	(Gerald
	R. ALABS Ash's message of "Tue, 31 Jan 2006 10:29:28 -0600")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: ietf@ietf.org, Stewart Bryant 
Subject: Re: I-D ACTION:draft-ash-alt-formats-01.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

How far along are you in getting representatives of the interesting
stakeholders involved?


Have you found a WG/document/something that would benefit from the
experiment?  Have you found an AD who would be willing to work with
this experiment?  Have you found someone from the rfc-editor who is
interested in participating?


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 14:42:59 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F41P1-0000TE-Iv; Tue, 31 Jan 2006 14:42:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F41Oy-0000PA-Kv; Tue, 31 Jan 2006 14:42:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22183;
	Tue, 31 Jan 2006 14:41:12 -0500 (EST)
Received: from zeke.ecotroph.net ([69.31.8.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F41Zr-0001oa-EV; Tue, 31 Jan 2006 14:54:12 -0500
Received: from [66.114.247.49] ([::ffff:128.107.248.220])
	(AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by zeke.ecotroph.net with esmtp; Tue, 31 Jan 2006 14:41:57 -0500
	id 0158807E.43DFBD85.0000562D
Message-ID: <43DFBDA0.2040406@thinkingcat.com>
Date: Tue, 31 Jan 2006 14:42:24 -0500
From: Leslie Daigle 
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Hartman 
References: <43DFAC4B.1070309@thinkingcat.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: IAB , "Iesg \(E-mail\)" , ietf@ietf.org
Subject: Re: IAB Response to Appeal from Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam,

One IAB member's perspective:  no, the expectation is not
BCP upon BCP upon BCP.

The devil is, of course, in the details.   Even community commented
on published operational procedures should not be at odds with
our general or specific process documents, or else that seems
to suggest the process documents need updating.  And we have
a community-defined process for that (which seems to result
in a BCP).

Again -- that's just one person's perspective.

Leslie.

Sam Hartman wrote:
> 
> So, a clarification request:
> 
> Am I correctly understanding that the clear and public requirement
> does not always imply a process RFC?  In particular, John Klensin has
> made an argument that there are a wide variety of matters that are
> better handled by operational procedures made available for community
> comment than by BCP document.
> 
> It's my reading that the IAB is interested in making sure that the
> processes and rules are clear and public, not that they are all
> codified in BCP.
> 
> 
> I'm not looking for a formal response from the IAB but would
> appreciate comments from its members.
> 
> --Sam
> 
> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 14:47:19 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F41TD-0001zs-3o; Tue, 31 Jan 2006 14:47:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F41TB-0001pk-77; Tue, 31 Jan 2006 14:47:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22461;
	Tue, 31 Jan 2006 14:45:32 -0500 (EST)
Received: from [66.114.247.47] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F41e3-0001xB-J2; Tue, 31 Jan 2006 14:58:32 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id C13DBE006A; Tue, 31 Jan 2006 14:47:01 -0500 (EST)
To: Leslie Daigle 
References: <43DFAC4B.1070309@thinkingcat.com> 
	<43DFBDA0.2040406@thinkingcat.com>
From: Sam Hartman 
Date: Tue, 31 Jan 2006 14:47:01 -0500
In-Reply-To: <43DFBDA0.2040406@thinkingcat.com> (Leslie Daigle's message of
	"Tue, 31 Jan 2006 14:42:24 -0500")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: IAB , "Iesg \(E-mail\)" , ietf@ietf.org
Subject: Re: IAB Response to Appeal from Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Leslie" == Leslie Daigle  writes:

    Leslie> The devil is, of course, in the details.  Even community
    Leslie> commented on published operational procedures should not
    Leslie> be at odds with our general or specific process documents,
    Leslie> or else that seems to suggest the process documents need
    Leslie> updating.  And we have a community-defined process for
    Leslie> that (which seems to result in a BCP).

O, this statement I completely agree with.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 15:21:49 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F41q3-000115-TO; Tue, 31 Jan 2006 15:10:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F41py-0000vC-6U
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 15:10:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23474
	for ; Tue, 31 Jan 2006 15:09:10 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F41vS-0002ht-TT
	for ietf@ietf.org; Tue, 31 Jan 2006 15:16:32 -0500
Received: (qmail 19635 invoked from network); 31 Jan 2006 20:05:04 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 31 Jan 2006 20:05:04 -0000
Date: 31 Jan 2006 20:05:04 -0000
Message-ID: <20060131200504.29161.qmail@simone.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9A1E@KCCLUST06EVS1.ugd.att.com>
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: gash@att.com
Subject: Re: I-D ACTION: draft-ash-alt-formats-01.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>We propose an experiment based on RFC 3933 allowing, in addition to
>ASCII text as a normative input/output format, PDF as an additional
>normative output format.

There are a lot of different formats called PDF.  There are PDF 1.1,
1.2, 1.3, and 1.4.  There's the new PDF/A archival profile along with
a variety of other industry-specific PDF/x profiles .  And there are a
whole lot of files produced by alleged PDF generators that don't
actually conform to any version of the PDF spec.  (Often they depend
on non-standard fonts that happened to be installed on the author's
computer.)

Among valid PDFs, do you include PDFs that are coded to prohibit text
extraction?  How about PDFs that are just bitmap scans of printed
documents, like the PDF versions of some early RFCs from the 1970s?

As we all know, one of the reasons that ASCII text has stood the test
of time is that its definition is stable and well-understood, so it is
at no risk of becoming unreadable due to losing the programs needed to
decode it.  I think that PDF/A may be well enough defined to be an
adequate archival format, but just "PDF" is way too vague.

R's,
John


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 16:24:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F42yy-0006ey-21; Tue, 31 Jan 2006 16:24:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F41qM-0001Kk-OO; Tue, 31 Jan 2006 15:11:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23705;
	Tue, 31 Jan 2006 15:09:35 -0500 (EST)
Received: from bay106-f15.bay106.hotmail.com ([65.54.161.25] helo=hotmail.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F41pb-0002Ns-QM; Tue, 31 Jan 2006 15:10:29 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	Tue, 31 Jan 2006 11:58:53 -0800
Message-ID: 
Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP;
	Tue, 31 Jan 2006 19:58:53 GMT
X-Originating-IP: [12.18.180.167]
X-Originating-Email: [bernard_aboba@hotmail.com]
X-Sender: bernard_aboba@hotmail.com
In-Reply-To: <43DFBDA0.2040406@thinkingcat.com>
From: "Bernard Aboba" 
To: leslie@thinkingcat.com, hartmans-ietf@mit.edu
Date: Tue, 31 Jan 2006 11:58:53 -0800
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 31 Jan 2006 19:58:53.0750 (UTC)
	FILETIME=[C328ED60:01C626A0]
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
X-Mailman-Approved-At: Tue, 31 Jan 2006 16:24:07 -0500
Cc: iab@ietf.org, iesg@ietf.org, ietf@ietf.org
Subject: Re: IAB Response to Appeal from Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

My personal perspective is that on a subject as sensitive as banning, it is 
very important to have clear, well documented procedures dictating the 
process and who is allowed to initiate the ban.  Creation of more documents 
may not be the solution to this problem, particularly since the 
applicability and overlap of the existing documents is already somewhat 
unclear.


>From: Leslie Daigle 
>To: Sam Hartman 
>CC: IAB , "Iesg (E-mail)" , ietf@ietf.org
>Subject: Re: IAB Response to Appeal from Jefsey Morfin
>Date: Tue, 31 Jan 2006 14:42:24 -0500
>
>Sam,
>
>One IAB member's perspective:  no, the expectation is not
>BCP upon BCP upon BCP.
>
>The devil is, of course, in the details.   Even community commented
>on published operational procedures should not be at odds with
>our general or specific process documents, or else that seems
>to suggest the process documents need updating.  And we have
>a community-defined process for that (which seems to result
>in a BCP).
>
>Again -- that's just one person's perspective.
>
>Leslie.
>
>Sam Hartman wrote:
>>
>>So, a clarification request:
>>
>>Am I correctly understanding that the clear and public requirement
>>does not always imply a process RFC?  In particular, John Klensin has
>>made an argument that there are a wide variety of matters that are
>>better handled by operational procedures made available for community
>>comment than by BCP document.
>>
>>It's my reading that the IAB is interested in making sure that the
>>processes and rules are clear and public, not that they are all
>>codified in BCP.
>>
>>
>>I'm not looking for a formal response from the IAB but would
>>appreciate comments from its members.
>>
>>--Sam
>>
>>
>



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 16:38:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F43D1-0003MD-1Z; Tue, 31 Jan 2006 16:38:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F43Cy-0003Kt-H8
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 16:38:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03000
	for ; Tue, 31 Jan 2006 16:37:03 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F43Nw-00076z-Qc
	for ietf@ietf.org; Tue, 31 Jan 2006 16:50:05 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F43CT-0005uf-B5
	for ietf@ietf.org; Tue, 31 Jan 2006 22:38:09 +0100
Received: from 1cust232.tnt6.hbg2.deu.da.uu.net ([149.225.18.232])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Tue, 31 Jan 2006 22:38:09 +0100
Received: from nobody by 1cust232.tnt6.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Tue, 31 Jan 2006 22:38:09 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Tue, 31 Jan 2006 22:32:14 +0100
Organization: 
Lines: 30
Message-ID: <43DFD75E.6A2@xyzzy.claranet.de>
References: <9473683187ADC049A855ED2DA739ABCA09FA9A1E@KCCLUST06EVS1.ugd.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust232.tnt6.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION:draft-ash-alt-formats-01.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ash, Gerald R (Jerry), ALABS wrote:

> .pdf version available at
> http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.pdf.

My AcroReader 3 says "Colorspace "csfi" konnte nicht gefunden
werden" (cannot find colourspace 'csfi' or similar).  Then it
gave me the option to ignore further errors, I confirmed this.

Sure like hell the one thing I don't see are the two important
non-ASCII-art versions of the example figures on (PDF) pages 5
and 7.

Many of those in support of PDF said that the experiment has to
identify a minimal subset of required features.  Whatever this
might be, "colourspace 'csfi'" (or similar) isn't a part of it.

> We look forward to your comments and suggestions.

Maybe use OpenOffice to create the PDF, so far that apparaently
always worked from my POV.  Specify which PDF features you want
to allow.  Make sure that "csfi" (or similar) isn't a part of
this minimal subset.

Consider a maximum size, your text/plain has about 18 KB, the
PDF has 113 (?) KB.  Above 1 MB I'd simply refuse to download
it.  Unless I desperately want it or somebody tells me that it
should work against all odds.
                               Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 16:40:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F43FB-0004CA-3z; Tue, 31 Jan 2006 16:40:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F43F8-0004AE-GJ; Tue, 31 Jan 2006 16:40:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03154;
	Tue, 31 Jan 2006 16:39:09 -0500 (EST)
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F43Q1-0007BM-UL; Tue, 31 Jan 2006 16:52:11 -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
	[169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id
	k0VLeUgx011856; Tue, 31 Jan 2006 16:40:30 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com
	(uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29125; 
	Tue, 31 Jan 2006 16:40:30 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service
	(5.5.2657.72) id ; Tue, 31 Jan 2006 16:40:29 -0500
Message-ID: <313680C9A886D511A06000204840E1CF0C8863DF@whq-msgusr-02.pit.comms.marconi.com>
From: "Gray, Eric" 
To: "'Bernard Aboba'" , leslie@thinkingcat.com,
	hartmans-ietf@mit.edu
Date: Tue, 31 Jan 2006 16:40:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: iab@ietf.org, iesg@ietf.org, ietf@ietf.org
Subject: RE: IAB Response to Appeal from Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Bernard,

	The way I interpret your statement is that you feel that 
replacement of the existing set of documents - possibly with a
single new document - is preferred to writing one or more new
documents with the intent to just "glue" the current set back
together.

	Is that a correct interpretation?

--
Eric

--> -----Original Message-----
--> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 
--> On Behalf Of Bernard Aboba
--> Sent: Tuesday, January 31, 2006 2:59 PM
--> To: leslie@thinkingcat.com; hartmans-ietf@mit.edu
--> Cc: iab@ietf.org; iesg@ietf.org; ietf@ietf.org
--> Subject: Re: IAB Response to Appeal from Jefsey Morfin
--> 
--> My personal perspective is that on a subject as sensitive 
--> as banning, it is 
--> very important to have clear, well documented procedures 
--> dictating the 
--> process and who is allowed to initiate the ban.  Creation 
--> of more documents 
--> may not be the solution to this problem, particularly since the 
--> applicability and overlap of the existing documents is 
--> already somewhat 
--> unclear.
--> 
--> 
--> >From: Leslie Daigle 
--> >To: Sam Hartman 
--> >CC: IAB , "Iesg (E-mail)" , 
--> ietf@ietf.org
--> >Subject: Re: IAB Response to Appeal from Jefsey Morfin
--> >Date: Tue, 31 Jan 2006 14:42:24 -0500
--> >
--> >Sam,
--> >
--> >One IAB member's perspective:  no, the expectation is not
--> >BCP upon BCP upon BCP.
--> >
--> >The devil is, of course, in the details.   Even community commented
--> >on published operational procedures should not be at odds with
--> >our general or specific process documents, or else that seems
--> >to suggest the process documents need updating.  And we have
--> >a community-defined process for that (which seems to result
--> >in a BCP).
--> >
--> >Again -- that's just one person's perspective.
--> >
--> >Leslie.
--> >
--> >Sam Hartman wrote:
--> >>
--> >>So, a clarification request:
--> >>
--> >>Am I correctly understanding that the clear and public requirement
--> >>does not always imply a process RFC?  In particular, John 
--> Klensin has
--> >>made an argument that there are a wide variety of matters that are
--> >>better handled by operational procedures made available 
--> for community
--> >>comment than by BCP document.
--> >>
--> >>It's my reading that the IAB is interested in making sure that the
--> >>processes and rules are clear and public, not that they are all
--> >>codified in BCP.
--> >>
--> >>
--> >>I'm not looking for a formal response from the IAB but would
--> >>appreciate comments from its members.
--> >>
--> >>--Sam
--> >>
--> >>
--> >
--> 
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 17:50:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F44KT-0003Tw-Nd; Tue, 31 Jan 2006 17:50:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F44KR-0003Rt-TY
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 17:50:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07421
	for ; Tue, 31 Jan 2006 17:48:44 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F44VM-00010U-Ec
	for ietf@ietf.org; Tue, 31 Jan 2006 18:01:45 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by sj-iport-2.cisco.com with ESMTP; 31 Jan 2006 14:50:09 -0800
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0VMo9KT006042;
	Tue, 31 Jan 2006 14:50:09 -0800 (PST)
Received: from [171.71.193.105] (dhcp-171-71-193-105.cisco.com
	[171.71.193.105])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0VMs8u9016037;
	Tue, 31 Jan 2006 14:54:10 -0800
Message-ID: <43DFE9AB.2050500@cisco.com>
Date: Tue, 31 Jan 2006 14:50:19 -0800
From: Michael Thomas 
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
	rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian E Carpenter 
References: <43D7DEDE.3050803@cisco.com>	<64EA6FCA33E6A3F95FF4D4EF@B50854F0A9192E8EC6CDA126>		<43D87732.2000205@cisco.com>
	<43D8BCF9.3070108@zurich.ibm.com>
In-Reply-To: <43D8BCF9.3070108@zurich.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=897; t=1138748051; x=1139180251;
	c=relaxed/simple; s=nebraska;
	h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version;
	d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20
	|Subject:Re=3A=20=22too=20many=20notes=22=20--=20a=20modest=20proposal
	|To:Brian=20E=20Carpenter=20;
	X=v=3Dmtcc.com=3B=20h=3Dgypaxnp0PfCvmhxvuptO6/KVHwk=3D;
	b=RLvdq+N1yx0XhBYNH5LvVgcMoU3edtRDUlOpVxOJbCcLplCr8gkCuA+70BY3y+5swDvYIA18
	Y4l+XEcS9yrnY8TTiZRpecd3iE28EvtOekAqtj/fC6WQMzyt+jaJ+/XWbVuKLA9xWOswtatRE8/
	0dOfSM1CBK2MZGRT1hc6jayg=;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion 
Subject: Re: "too many notes" -- a modest proposal
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian E Carpenter wrote:
> 
> Eliot Lear wrote:
> 
>> Douglas Otis wrote:
>>
>>> I suspect that at the moment, I am the guilty party in consuming
>>> bandwidth on the DKIM list.  With the aggressive schedule, the
>>> immediate desire was to get issues listed, corrected, and in a form
>>> found acceptable.  
>>
>>
>> Without going into all the reasons why here, I asked Doug to separate
>> out issues into separate messages.
> 
> 
> Exactly. If a WG group is discussing a dozen separate issues in parallel,
> an active participant can easily send several dozen *constructive*
> messages in a day. Our problem with disruptive messages can't be solved
> by counting bytes.

Is there really a working group that can realistically deal
with a dozen separate issues in parallel? I know that when I
see a dozen or so issues posted to a mailing list, my eyes
glaze...

		Mike

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 18:17:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F44kE-0005k1-RQ; Tue, 31 Jan 2006 18:17:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F44kC-0005V6-DF
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 18:17:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10074
	for ; Tue, 31 Jan 2006 18:15:09 -0500 (EST)
Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F44uu-00023k-8m
	for ietf@ietf.org; Tue, 31 Jan 2006 18:28:11 -0500
Received: from [71.240.232.61] (HELO JMHLap3.stevecrocker.com)
	by execdsl.com (CommuniGate Pro SMTP 4.2.7)
	with ESMTP id 12959490 for ietf@ietf.org;
	Tue, 31 Jan 2006 16:13:07 -0700
Message-Id: <6.2.1.2.0.20060131181010.031c4d18@mail.stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 31 Jan 2006 18:16:27 -0500
To: 
From: "Joel M. Halpern" 
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA9A1E@KCCLUST06EVS1.ugd
	.att.com>
References: <9473683187ADC049A855ED2DA739ABCA09FA9A1E@KCCLUST06EVS1.ugd.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Subject: RE: I-D ACTION:draft-ash-alt-formats-01.txt 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Aside from the issues already raised on the list, I see some other problems.

First and foremost, if the input format is PDF, how will the RFC Editor 
edit the document?  PDF documents are not editable.

Secondarily, as a lesser matter, for the WG / Documents that get selected 
for the experiment, can you indicate what composition tools (editors) are 
likely to be suitable for producing this?  Are we going to be requiring 
that the document editors for those documents have and use word?  (Or Open 
Doc, or ...)  Or are we expecting them to find their own tools to 
participate in the experiment?

Thirdly, it would probably be a good idea to have greater clarity on 
judging success.  If the WG loved it, and the IETF list is divided, and ... 
which condition is most important, and why?  Given that the impact of this 
experiment is quite broad, I think that clarity on the judgement is important.

Yours,
Joel M. Halpern

At 11:29 AM 1/31/2006, Ash, Gerald R \(Jerry\), ALABS wrote:
>Hi All,
>
>As a follow-up to our recent discussion, please review the draft at
>http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.txt,
>.pdf version available at
>http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.pdf.
>
>We propose an experiment based on RFC 3933 allowing, in addition to
>ASCII text as a normative input/output format, PDF as an additional
>normative output format.
>
>We look forward to your comments and suggestions.
>
>Thanks,
>Regards,
>Jerry, Stewart, Yaakov


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 18:51:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F45HX-0006jo-1O; Tue, 31 Jan 2006 18:51:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F45HS-0006he-Ci; Tue, 31 Jan 2006 18:51:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12507;
	Tue, 31 Jan 2006 18:49:40 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F45SL-000389-BY; Tue, 31 Jan 2006 19:02:42 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id B02DC2596BA;
	Wed,  1 Feb 2006 00:49:51 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 19177-02; Wed,  1 Feb 2006 00:49:47 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id F0D182596BE;
	Wed,  1 Feb 2006 00:49:40 +0100 (CET)
Date: Tue, 31 Jan 2006 15:39:33 -0800
From: Harald Tveit Alvestrand 
To: Leslie Daigle , "Iesg (E-mail)" 
Message-ID: <6A7FAFC112645012E09FC142@B50854F0A9192E8EC6CDA126>
In-Reply-To: <43DFAC4B.1070309@thinkingcat.com>
References: <43DFAC4B.1070309@thinkingcat.com>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: IAB , ietf@ietf.org
Subject: Re: IAB Response to Appeal from Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1331907872=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============1331907872==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========AC045962F0459CD1C804=========="

--==========AC045962F0459CD1C804==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

IAB,

Thank you for the processing of this request.

However, this mailing list maintainer is now completely uncertain about=20
what his marching orders are with regards to continuing to administer the=20
ietf-languages list.

The IAB seems to have decided that it's the IESG that has to decide this;=20
there is nothing else in the decision of the IAB that is clear to me.

Until the IESG hands me a new decision, I will continue to administer the=20
ietf-languages list as if RFC 3683 was appropriate guidance for=20
administering it, including upholding the current suspension of posting=20
rights for Jefsey Morfin until February 13, 2006.

The alternatives would be to declare that I'm making up the rules on my=20
own, or to declare that the list has no rules until the IESG decides; the=20
last interpretation is not one I'm willing to run a list under.

(Yes, he's gotten suspended again.)

                    Harald Alvestrand

--On 31. januar 2006 13:28 -0500 Leslie Daigle =20
wrote:

> 5. IAB Conclusion on the Appeal
>
> The IAB found that the response provided by the IESG in this
> action did not provide sufficient justification to sustain the
> banning of Mr. Morfin from the ietf-languages mailing list. In
> particular, while the IAB agrees with the IESG that no specific
> mailing list process RFCs directly apply in this case, its
> response is not sufficiently clear why RFC 3934 is considered
> applicable "by analogy". Further, it is also unclear from the
> IESG's response what the scope of applicability of RFC 3934 might
> be, or when other process RFCs  might be applied "by
> analogy". Therefore, the IESG's action does not meet the clear
> and public requirement outlined above and the IAB annuls the
> IESG's decision in this appeal and sends the matter back to the
> IESG for resolution.
>
> Since the suspension period has expired, no remedy is
> indicated. However, the IAB recommends that the ambiguities that
> gave rise to this appeal be clarified, as described in the
> following sections.




--==========AC045962F0459CD1C804==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFD3/U1OMj+2+WY0F4RAr/1AKCrD1vC9x6nvdR0axfSUceUK8cAWACfb1n5
tL2FrNa1kRMnkqrCi4bOaCw=
=Cpr/
-----END PGP SIGNATURE-----

--==========AC045962F0459CD1C804==========--



--===============1331907872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============1331907872==--





From ietf-bounces@ietf.org Tue Jan 31 20:19:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F46em-0007Z4-Cv; Tue, 31 Jan 2006 20:19:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F46eg-0007W1-7v; Tue, 31 Jan 2006 20:19:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20131;
	Tue, 31 Jan 2006 20:17:43 -0500 (EST)
Received: from [66.114.247.57] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F46pa-0006NN-JR; Tue, 31 Jan 2006 20:30:47 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 90F44E006A; Tue, 31 Jan 2006 20:19:12 -0500 (EST)
To: Harald Tveit Alvestrand 
References: 
	
	
	
	
From: Sam Hartman 
Date: Tue, 31 Jan 2006 20:19:12 -0500
In-Reply-To:  (Harald
	Tveit Alvestrand's message of "Fri, 20 Jan 2006 18:27:38 +0100")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: Scott Hollenbeck , ietf@ietf.org, iesg@ietf.org
Subject: Fairness and changing rules
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Harald" == Harald Tveit Alvestrand  writes:

    Harald> Sam, let me put it this way:

    Harald> Changing the rules in the middle of the process is Just
    Harald> Plain Stupid. We've done that too many times to count.



Hi.  I've been perplexed by this comment.

I'd like to understand why changing the rules in the middle of a
process is a bad idea.

I can think of cases under which changing the rules might be problematic:

1) Many legal and process systems have as a part of fairness the idea
   that actions that people should not be punished by actions that are
   prohibited/illegal unless the actions are prohibited/illegal before
   the action took place.  In my own experience, the US constitution
   has a prohibition against ex post facto laws--laws that make
   something illegal after it happened.  There are some fairly obvious
   reasons why you want this particularly when the goal of punishment
   is to discourage behavior from happening.  Our process is such a
   process so I agree we should not sanction people for actions that
   were not sanctionable when the action took place.

2) It is undesirable to make a sanction significantly harsher than
    initially expected during a process.  If I expect that what I'm
    doing is OK, but I might be wrong and get a warning I'll be very
    surprised and annoyed if I end up getting kicked off the mailing
    list.  It would be unacceptable to change the process to allow
    this to happen in the middle of the process.

3) Our standards process has an idea that we don't want to change the
    bar too much while a standard is in progress and that we want
    consistency.  We don't want to apply one process to one standard
    and a different process to a similar standard.  We phase in new
    requirements over time.  If people believe they have met the
    requirements for publication then it is frustrating to surprise
    them with new requirements they could not have anticipated.  This
    is true even if the new requirements are approved through process
    changes.  Now  clearly there is a balance here.

Note that reason 3 to avoid rules changes during a process does not
directly apply to PR actions.  I don't want to view PR actions in the
same way as a standard.  It should not be the case that if you collect
sufficient evidence you can get someone banned from a mailing list.
You have a right to expect that if you collect sufficient evidence of
an administrative problem like a problematic individual on a mailing
list, this problem will be solved in some way.  You don't have a right
or expectation to demand a particular solution.  If for example the
IESG successfully managed to convince the individual to clean up their
act, you don't have a right to be disappointed that a PR action was
not approved.  (If the IESG claims they have convinced the individual
to clean up their act, you may well be dubious about whether this
claim is valid.)



In particular I'm having a hard time finding an ethical or logical
reason why we would not want to approve a process change that allows a
lesser sanction for behavior that is already prohibited.
Can you help me understand why that specifically would be a bad idea?

Now, there is one case where I can see a concern.  If we are concerned
that the behavior may not be sanctionable today then what we are doing
might be problematic.  We could make an explicit determination that
the behavior was currently prohibited before deciding to apply the
lesser sanction.  Some people might question whether we could isolate
the two calls enough to make that decision.

So I agree that a solution open to less question is to refuse to apply
a sanction, create a process change and wait for prohibited behavior to
happen again.  I'm concerned that in the case of Pr actions that may
be unfair to those trying to get work done.  I could accept a decision
not to apply sanctions and to change the process though if the
community feels that is necessary.

I am concerned though that such a decision may lead to what I consider
to be a major problem.  If we decide that we're going to apply a large
sanction because that is the only tool available to us, I believe we
have done something that violates the spirit of our process and that
does not meet the standard of fairness we hold ourselves to.

The fourth goal of  the standards development process in RFC 2026 is
fairness:

     The goals of the Internet Standards Process are:
        o  technical excellence;
           o  prior implementation and testing;
              o  clear, concise, and easily understood documentation;
                 o  openness and fairness;  and
                    o  timeliness.
                  


In particular, section 6.5.3 provides a path for resolving the
situation where we follow procedures that do not meet the standards of
fairness and openness to which we have obligated ourselves:

     Further recourse is available only in cases in which the procedures
        themselves (i.e., the procedures described in this document) are
           claimed to be inadequate or insufficient to the protection of
        the
           rights of all parties in a fair and open Internet Standards
        Process.
           Claims on this basis may be made to the Internet Society
        Board of
           Trustees.  


I think that if there is general agreement in the community that a
lesser sanction, were it available, would be adequate to solve a
problem, but  we apply a greater sanction because that is the only
tool our process permits, there would be a claim for relief under
section 6.5.3 of RFC 2026.  I hope that ISOC would grant relief in
such a situation.  The IAB's response today gives me confidence that
such a claim might never reach ISOC.


So, if the community decides that we need to avoid a sanction in some
specific case so we can change the process, I can agree with that
decision.  If we choose to apply a sanction we agree is too great
simply because it is the tool we have, I look forward to a successful
appeal of our foolishness.

--Sam


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 20:49:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F477j-0007F3-LJ; Tue, 31 Jan 2006 20:49:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F477h-0007DV-OU
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 20:49:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24720
	for ; Tue, 31 Jan 2006 20:47:43 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F47Ib-00088m-Kx
	for ietf@ietf.org; Tue, 31 Jan 2006 21:00:47 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k111n2CD035330
	for ; Wed, 1 Feb 2006 02:49:02 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Wed, 1 Feb 2006 02:49:02 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1237768540.20060201024902@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060131200504.29161.qmail@simone.iecc.com>
References: <9473683187ADC049A855ED2DA739ABCA09FA9A1E@KCCLUST06EVS1.ugd.att.com>
	<20060131200504.29161.qmail@simone.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION: draft-ash-alt-formats-01.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John Levine writes:

> Among valid PDFs, do you include PDFs that are coded to prohibit text
> extraction?  How about PDFs that are just bitmap scans of printed
> documents, like the PDF versions of some early RFCs from the 1970s?

Use the most conservative (and thus probably the earliest) version of
PDF.  Later versions are designed mostly to make money for Adobe, and
they are scarcely needed for documents that contain only formatted
text and diagrams.  Using an early version of PDF also guarantees that
the document can be opened with (almost?) any version of Acrobat
Reader or other software.

I still use Acrobat 4.x, and I have it set to generate Acrobat 3.x
documents, and I've yet to generate any document that requires a more
recent version of the software.  If you limit yourself to the text and
simple artwork that has sufficed for the printed page for the past few
centuries, you don't need anything more recent, and you shouldn't be
using anything more recent.

Be conservative in what you require, and liberal in what you accept.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 20:52:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F47Ab-0008Ic-Id; Tue, 31 Jan 2006 20:52:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F47AZ-0008HU-OF
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 20:52:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25005
	for ; Tue, 31 Jan 2006 20:50:43 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F47LW-0008GB-SP
	for ietf@ietf.org; Tue, 31 Jan 2006 21:03:47 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k111qAtv035349
	for ; Wed, 1 Feb 2006 02:52:10 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Wed, 1 Feb 2006 02:52:10 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <515300502.20060201025210@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <6A7FAFC112645012E09FC142@B50854F0A9192E8EC6CDA126>
References: <43DFAC4B.1070309@thinkingcat.com>
	<6A7FAFC112645012E09FC142@B50854F0A9192E8EC6CDA126>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Subject: Re: IAB Response to Appeal from Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Harald Tveit Alvestrand writes:

> Thank you for the processing of this request.
>
> However, this mailing list maintainer is now completely uncertain about
> what his marching orders are with regards to continuing to administer the
> ietf-languages list.
>
> The IAB seems to have decided that it's the IESG that has to decide this;
> there is nothing else in the decision of the IAB that is clear to me.
>
> Until the IESG hands me a new decision, I will continue to administer the
> ietf-languages list as if RFC 3683 was appropriate guidance for 
> administering it, including upholding the current suspension of posting
> rights for Jefsey Morfin until February 13, 2006.
>
> The alternatives would be to declare that I'm making up the rules on my
> own, or to declare that the list has no rules until the IESG decides; the
> last interpretation is not one I'm willing to run a list under.
>
> (Yes, he's gotten suspended again.)

It sounds a lot like you're trying to rationalize a personal
preference.  Your instructions are apparently unclear, so you just do
what you want.  It takes you several paragraphs to say it, but that's
what it amounts to.

I like the use of the passive: "He's gotten suspended again," as if a
stray lightning bolt did this and no human being had any role in it.
Apparently you must uphold the suspension actively, but the suspension
itself takes place through some sort of external magical influence.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 20:57:26 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F47FO-0001us-Mw; Tue, 31 Jan 2006 20:57:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F47FM-0001s2-JH
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 20:57:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25481
	for ; Tue, 31 Jan 2006 20:55:48 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F47QR-0008Re-J2
	for ietf@ietf.org; Tue, 31 Jan 2006 21:08:52 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k111vEHJ035398
	for ; Wed, 1 Feb 2006 02:57:14 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Wed, 1 Feb 2006 02:57:14 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <228927895.20060201025714@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <6.2.1.2.0.20060131181010.031c4d18@mail.stevecrocker.com>
References: <9473683187ADC049A855ED2DA739ABCA09FA9A1E@KCCLUST06EVS1.ugd.att.com>
	<6.2.1.2.0.20060131181010.031c4d18@mail.stevecrocker.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION:draft-ash-alt-formats-01.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Joel M. Halpern writes:

> First and foremost, if the input format is PDF, how will the RFC Editor
> edit the document?  PDF documents are not editable.

PDF is designed to be uneditable.  It's for final versions of a
document, and the difficulty involved in trying to edit it is one of
its most useful features.

If the document isn't acceptable as-is, then it should be rejected
until the author makes any required changes.

I'm not saying that PDF is or isn't the right format, but I can say
that PDF seems like the least of several evils when it comes to
encoding line art in a document.  If you have to go beyond ASCII text,
PDF is the next step up.  It's certainly better than RTF, or Word
format.  And it is so thoroughly entrenched these days that it has a
good chance of surviving over the long term, whereas many other
formats do not.

Also, at least early versions of PDF cannot easily carry viruses;
later versions are perhaps best avoided because of this risk.

> Secondarily, as a lesser matter, for the WG / Documents that get selected
> for the experiment, can you indicate what composition tools (editors) are
> likely to be suitable for producing this?  Are we going to be requiring
> that the document editors for those documents have and use word?  (Or Open
> Doc, or ...)  Or are we expecting them to find their own tools to 
> participate in the experiment?

There are lots of ways to generate PDF.  An additional option is to
offer PDF generation from text or other formats.  PDF is a good
archive format for anything that requires line art and not just text.
Of course, if no document will ever require anything more than simple
text, there's no need for PDF.




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 21:08:29 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F47Q5-0004lj-23; Tue, 31 Jan 2006 21:08:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F47Q2-0004kY-Ru
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 21:08:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26282
	for ; Tue, 31 Jan 2006 21:06:42 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F47ay-0000Lo-D8
	for ietf@ietf.org; Tue, 31 Jan 2006 21:19:46 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k11287mA035760
	for ; Wed, 1 Feb 2006 03:08:07 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Wed, 1 Feb 2006 03:08:07 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1838606358.20060201030807@atkielski.com>
To: ietf@ietf.org
In-Reply-To: 
References: 
	
	
	
	
	
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit
Subject: Re: Fairness and changing rules
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam Hartman writes:

> I'd like to understand why changing the rules in the middle of a
> process is a bad idea.

They aren't rules if they can be changed even as they are being
applied.  If you want to make rules, you have to be willing to abide
by them.  Changing the rules even as they are applied is equivalent to
not having rules to begin with (although I realize this is precisely
the unstated goal for some people).

> It should not be the case that if you collect sufficient evidence
> you can get someone banned from a mailing list. You have a right to
> expect that if you collect sufficient evidence of an administrative
> problem like a problematic individual on a mailing list, this
> problem will be solved in some way. You don't have a right or
> expectation to demand a particular solution. If for example the IESG
> successfully managed to convince the individual to clean up their
> act, you don't have a right to be disappointed that a PR action was
> not approved. (If the IESG claims they have convinced the individual
> to clean up their act, you may well be dubious about whether this
> claim is valid.)

An alternative is to do nothing, which in the long run is the least
disruptive and wasteful of resources.  All "problematic individuals"
are nothing more than one person irritating another, and if people
cultivate tolerance instead of wasting their time bickering like
schoolchildren, the overall result is greater productivity and
flexibility for all.

> In particular I'm having a hard time finding an ethical or logical
> reason why we would not want to approve a process change that allows
> a lesser sanction for behavior that is already prohibited. Can you
> help me understand why that specifically would be a bad idea?

Just because it is a change allowing a lesser sanction doesn't mean
that it justifies setting the precedent of changing the rules in
transit.

> Now, there is one case where I can see a concern.  If we are concerned
> that the behavior may not be sanctionable today then what we are doing
> might be problematic.  We could make an explicit determination that
> the behavior was currently prohibited before deciding to apply the
> lesser sanction.  Some people might question whether we could isolate
> the two calls enough to make that decision.

Or we could spend this time working on the real tasks of the group
instead of whining about who should or shouldn't be banned.

Every mailing list I've ever encountered is this way, constantly
degenerating into personal attacks and attempts to censor and ban
anyone who isn't sufficiently popular or well placed.  Don't people
ever grow up?

> So I agree that a solution open to less question is to refuse to apply
> a sanction, create a process change and wait for prohibited behavior to
> happen again.

Why not just drop the whole thing and pretend nothing ever happened?
Then the group can get back to business. I know that business isn't
nearly as much fun as goofing off with bans and censorship and
arguments about bans and censorship and arguments about arguments
about bans and censorship, but it _is_ the nominal purpose of the
group, isn't it?

> I think that if there is general agreement in the community that a
> lesser sanction, were it available, would be adequate to solve a
> problem, but  we apply a greater sanction because that is the only
> tool our process permits, there would be a claim for relief under
> section 6.5.3 of RFC 2026.

Or maybe a temporary estoppel motion for ad hoc pro tempore injunctive
relief under subparagraph (b) of section IIa of codex 4 of Section
4.1.3.15/C (as amended) of RFC 4299182.

You know, just writing ever more complicated policies and procedures
doesn't make them useful or valid.

> So, if the community decides that we need to avoid a sanction in some
> specific case so we can change the process, I can agree with that
> decision.  If we choose to apply a sanction we agree is too great
> simply because it is the tool we have, I look forward to a successful
> appeal of our foolishness.

Perhaps just stepping out of the sandbox and getting back to work
would serve to eliminate the foolishness.  I'm not holding my breath,
though.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 21:15:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F47WY-0006Lm-4P; Tue, 31 Jan 2006 21:15:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F47WW-0006LN-5E; Tue, 31 Jan 2006 21:15:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26674;
	Tue, 31 Jan 2006 21:13:31 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F47ha-0000Y7-FY; Tue, 31 Jan 2006 21:26:35 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 9EF6F25817F;
	Wed,  1 Feb 2006 03:13:44 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 22647-04; Wed,  1 Feb 2006 03:13:40 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id DCBB325806E;
	Wed,  1 Feb 2006 03:13:38 +0100 (CET)
Date: Tue, 31 Jan 2006 18:13:50 -0800
From: Harald Tveit Alvestrand 
To: Sam Hartman 
Message-ID: 
In-Reply-To: 
References: 
	
	
	
	
	
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: Scott Hollenbeck , ietf@ietf.org, iesg@ietf.org
Subject: Re: Fairness and changing rules
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0388254364=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

--===============0388254364==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========A3257E57FA77BC577FFE=========="

--==========A3257E57FA77BC577FFE==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Sam,

trying to avoid pointing at persons, despite the fact that a specific=20
person is at the heart of the current discussion...... your 3 points are=20
very valid reasons for avoiding rule changes, but I think you miss the=20
point I was trying to make.

The IESG was asked to choose between two alternatives:

- Execute a PR-Action against "X"
- Do not execute a PR-Action against "X"

In the ensuing discussion, you have argued that there should be other=20
procedures for mailing list management, which are suited to "lesser=20
offenses".

Doing this at the same time as considering the PR-action against "X" has=20
some interesting consequences:

- The "problem behaviour" that the rule seeks to address is likely to get=20
crafted so that it's clear whether "X"'s behaviour falls within or outside=20
the description. While this makes things clearer in this case, I believe=20
that history shows very low predictive value for whether or not such a rule =

will be clear once a new case comes along.

- The "reaction" that the rule seeks to implement will take the form of=20
whatever the discussion concludes is a reasonable reaction to the behaviour =

exhibited by "X". Again, this is no predictor of whether or not the=20
reaction will be adequate, overreaction, or underreaction for the next case =

that comes along.

- The discussion that has to come before the final crafting of the new=20
rules is likely to take some time - months, if experience is a guide. This=20
offers an excuse for avoiding making a decision in "X"'s specific case -=20
thus prolonging the time of indecision.

I do not want the IETF to craft rules for "X", and then re-craft them for=20
"Y", "Z" and "W" because hastily crafted rules did not fit the next=20
situation to come along. I want the rules to be reasonable, and stable.
And I think making up rules while considering a specific unique case is=20
harmful to such a process.

One point in closing:

A PR-action, or a mailing list suspension, is NOT a punishment. Rules of=20
order exist to protect the IETF's ability to do its work.

I believe that's your central responsibility.

                         Harald

--==========A3257E57FA77BC577FFE==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFD4BleOMj+2+WY0F4RAuXKAKD4N/NyYTXNiOg7mpmMT0VCbyHBGACg0Vxe
kBE0JXrhcBVZcrN+5xSZ7js=
=RIJ2
-----END PGP SIGNATURE-----

--==========A3257E57FA77BC577FFE==========--



--===============0388254364==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

--===============0388254364==--





From ietf-bounces@ietf.org Tue Jan 31 21:24:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F47ff-0000S3-Gt; Tue, 31 Jan 2006 21:24:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F47fc-0000Ql-13; Tue, 31 Jan 2006 21:24:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27360;
	Tue, 31 Jan 2006 21:22:45 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F47qX-0000rR-3N; Tue, 31 Jan 2006 21:35:49 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F47ex-0002Du-3y; Tue, 31 Jan 2006 18:23:51 -0800
Message-Id: <6.2.3.4.2.20060201011759.06605eb0@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Wed, 01 Feb 2006 03:23:25 +0100
To: iab@ietf.org, iesg@ietf.org, ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <43DFAC4B.1070309@thinkingcat.com>
References: <43DFAC4B.1070309@thinkingcat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-3C527EA4
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d9238570526f12788af3d33c67f37625
Cc: 
Subject: Re: IAB Response to Appeal from Jefsey Morfin
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I thank the IAB for the processing of my request. I acknowledge its decision.

The IAB has decided not to discuss the motives of the contention, but 
the use of RFC 3934 to legitimate a ban decision (also used in the 
three other cases). Harald Alvestrand indicated the reasons of this 
use: if the list "didn't behave as if it was subject to RFC 3934, the 
IETF would be justified in asking someone else to take on the job of 
running the list." This is consistent with the consequences he draws 
from the IAB decision: "the alternatives would be to declare that I'm 
making up the [list] rules on my own, or to declare that the list has 
no rules until the IESG decides; the last interpretation is not one 
I'm willing to run a list under."

This means that the IAB, Harald Alvestrand and I root the issue 
[which make us waste so much time for one year] in the unclear 
status, "basically, for *me* " (says Michael Everson, ietf@ietf.org 
at 15:57 20/01/2006), of the RFC 3066 IANA 
ietf-languages@alvestrand.no mailing list. I hope this list will soon 
be a IANA managed mailing list, or that the IESG requires the WG-ltru 
to gives it a more precise status through RFC 3066 bis (a debate I 
proposed and I was denied).

I make a note of the IESG and of the IAB "no comment" concerning my 
propositions in the Multilingual Internet, users requirements and 
ethic areas. I now feel free to proceed along these propositions in 
the respect of the Internet standard process.

I received several "well done" mails. I consider that Harald and I 
are both only trying to do our best to clarify a complex issue to the 
benefit of the users and of the IETF. I genuinely hope the IAB 
decision will help us to openly discuss it, taking the necessary time.

jfc


At 19:28 31/01/2006, Leslie Daigle wrote:


>On 4 January 2006, the IAB received an appeal from Jefsey Morfin
>appealing the IESG decision to uphold the suspension of his
>posting rights to the ietf-languages list. According to the
>procedures in Section 6.5.2 of RFC 2026, the IAB has reviewed the
>situation and issues the following response.
>
>1. The Appeal Question
>
>The IAB interpreted this appeal to be as follows:
>
>The appeal concerns whether the IESG, in upholding the suspension of Mr.
>Morfin's posting privileges to the ietf-languages mailing list, made an
>incorrect decision.
>
>
>2. The Scope and Basis of the Appeal
>
>While Mr. Morfin noted several motivations for his appeal and
>requests that several questions be answered in response to his
>appeal, the IAB did not consider Mr. Morfin's discussion of
>internationalization issues. Rather, the IAB reviewed the appeal
>as it applies to the administration of IETF mailing lists and
>specifically to the removal of posting rights. In particular, the
>conclusions described here narrowly apply to the process used by
>the IESG in upholding the 20 Nov 2005 suspension of Mr. Morfin's
>posting rights on the ietf-languages mailing list. Finally, in
>considering the appeal, we observe that the IESG noted that no
>existing explicit mailing list policy RFC was applicable in this
>case.
>
>3. The Process used by the IAB to Review the Situation
>
>The question raised by the appeal is whether the IESG followed
>the Internet Standards Process in the upholding of the suspension
>of Mr. Morfin's posting rights to the ietf-languages mailing
>list.
>
>The procedure used by the IAB in considering this appeal has
>included:
>
>o Review of the documentation of the IETF's standards procedures
>     as described in RFC 2026 and RFC 2418,
>
>o Review of IETF Mailing List Administrative Procedures, as
>     documented in RFCs 2418, 3005, 3683, and 3934, and
>
>o Review of the context and history of this appeal
>
>4. IAB Considerations
>
>In its response to Mr. Morfin's initial appeal, the IESG notes:
>"RFC 3934 does not strictly speaking, apply to non-WG lists but
>we have considered it by analogy". The IAB found that RFC 3934 is
>specific to working group mailing lists: Not only is RFC 3934
>specifically identified as an update to RFC 2418 (which regards
>working group procedures), but the clearly stated purpose of RFC
>3934 is to give working group chairs similar authority on a
>mailing list as they have in face-to-face meetings. In
>particular, a working group chair can "refuse to grant the floor
>to any individual who is unprepared or otherwise covering
>inappropriate material, or who, in the opinion of the chair, is
>disrupting the WG process" during a meeting. It is precisely
>because of their designation as working group chair that RFC 3934
>provides the chair the ability to suspend posting rights without
>IESG approval. This calls into question the suspension of mailing
>list posting rights under RFC 3934 other than by working group
>chairs on working group mailing lists.
>
>The IAB also reviewed other IETF mailing list management RFCs.
>RFC 3683 refers to the "temporary suspension of posting rights to
>a specific mailing list." However, we were hard-pressed to find
>language in RFC 3683 that could have been applied in either the
>initial suspension or the IESG response. In particular, RFC 3683
>notes that those temporary suspensions are documented in RFC 2418
>(which, like RFC 3934, applies to working group chairs) and RFC
>3005 (where the IETF chair, the executive director, and a duly
>appointed sergeant-at-arms are the ones empowered to refuse
>postings to the ietf@ietf.org mailing list), neither of which
>covers the case at hand.  As a result, we find there is no
>specific mailing list management process RFC that applies.
>
>While we find that neither RFC 3683 nor RFC 3934 directly apply
>in this case, the IAB understands that the IETF must be able to
>act in the face of ambiguity in "the rules." Indeed, it would be
>a terrible outcome if we found the IESG's decision would have
>been reasonable if neither RFC 3683 nor RFC 3934 existed, but now
>unreasonable since the documents do exist but don't
>apply. Moreover, current well-established practice allows for
>mailing list maintainers of any IETF mailing list, without
>prior approval, to remove or block posts from viruses or other
>operationally-disrupting e-mail sources, and we are not offering
>a decision that we believe contradicts that. Responsible parties
>must be able to take action even if there is ambiguity or lack of
>explicit coverage by specific process documents.
>
>Of course, these actions are not arbitrary: RFC 3934 limits working
>group chairs to only restrict posting rights in order to support
>constructive work on the working group's chartered activity, and
>current list maintainer practice is only to block postings from
>operationally-disruptive sources. In the spirit of RFC 2026 and
>RFC 3935, those actions must be governed by appropriate judgment
>and the basis for such judgments should be clear and public.  The
>IAB believes this is imperative in order to ensure that the IETF
>continues to function in the most open and fair manner possible,
>for all participants.
>
>5. IAB Conclusion on the Appeal
>
>The IAB found that the response provided by the IESG in this
>action did not provide sufficient justification to sustain the
>banning of Mr. Morfin from the ietf-languages mailing list. In
>particular, while the IAB agrees with the IESG that no specific
>mailing list process RFCs directly apply in this case, its
>response is not sufficiently clear why RFC 3934 is considered
>applicable "by analogy". Further, it is also unclear from the
>IESG's response what the scope of applicability of RFC 3934 might
>be, or when other process RFCs  might be applied "by
>analogy". Therefore, the IESG's action does not meet the clear
>and public requirement outlined above and the IAB annuls the
>IESG's decision in this appeal and sends the matter back to the
>IESG for resolution.
>
>Since the suspension period has expired, no remedy is
>indicated. However, the IAB recommends that the ambiguities that
>gave rise to this appeal be clarified, as described in the
>following sections.
>
>6. IAB Recommendations
>
>6.1 Clearly Define the Operation of IETF Mailing Lists
>
>If mailing list participation rules are to be based on
>contributing constructively to work items, the IETF should
>consider making public charters for those lists (however formal
>or informal) so that people understand the scope of the work, the
>person responsible for shepherding the discussion in accordance
>with the charter, and rules governing participation in those
>lists. In particular, future RFCs (or revisions of existing RFCs)
>governing mailing list administration should clearly indicate who
>the responsible parties are as well as the extent of their
>authorities.
>
>6.2 Disambiguate Current Mailing List Administration Procedures
>
>The IAB recommends to the IETF that the ambiguity in the current
>procedures be cleared up. In particular: RFCs 3005 and 3934 allow
>for posting rights revocation for specific mailing lists (the
>IETF main list and working group mailing lists) at the discretion
>of people directly responsible to and appointed by the IESG;
>RFC 3683 allows for posting rights revocation by any IETF mailing
>list maintainer, but only on the basis of an IETF-wide  consensus
>call (a high hurdle); current practice allows for posting rights
>revocation by mailing list maintainers in the case of operational
>emergencies; the large gap in between those procedures is not
>addressed, either by BCP or by well-established practice.
>
>6.3 Clearly and Publicly Document IESG Decisions on Appeals
>
>When deciding similar cases in the future, the IAB recommends
>that the IESG give clear and public support for the basis of
>their decision, either by providing clear documentation of the
>interpretation of applicability of existing process or by
>referencing well-established current practice.
>
>
>
>Leslie Daigle,
>IAB Chair.
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 21:31:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F47mK-0002SX-Ga; Tue, 31 Jan 2006 21:31:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F47mI-0002Qv-DU; Tue, 31 Jan 2006 21:31:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27985;
	Tue, 31 Jan 2006 21:29:39 -0500 (EST)
Received: from [66.114.247.57] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F47xC-00017o-Ca; Tue, 31 Jan 2006 21:42:44 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id BB614E0074; Tue, 31 Jan 2006 21:31:08 -0500 (EST)
To: Harald Tveit Alvestrand 
References: 
	
	
	
	
	
	
From: Sam Hartman 
Date: Tue, 31 Jan 2006 21:31:08 -0500
In-Reply-To:  (Harald
	Tveit Alvestrand's message of "Tue, 31 Jan 2006 18:13:50 -0800")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: Scott Hollenbeck , ietf@ietf.org, iesg@ietf.org
Subject: Re: Fairness and changing rules
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>>>>> "Harald" == Harald Tveit Alvestrand  writes:

    Harald> Sam, trying to avoid pointing at persons, despite the fact
    Harald> that a specific person is at the heart of the current
    Harald> discussion...... your 3 points are very valid reasons for
    Harald> avoiding rule changes, but I think you miss the point I
    Harald> was trying to make.

    Harald> The IESG was asked to choose between two alternatives:

    Harald> - Execute a PR-Action against "X" - Do not execute a
    Harald> PR-Action against "X"

OK.  I actually view our responsibility more as use the tools we have
available to allow y to get its work done even given x's behavior.  I
don't believe the central question is whether the PR action should be
executed.

    Harald> In the ensuing discussion, you have argued that there
    Harald> should be other procedures for mailing list management,
    Harald> which are suited to "lesser offenses".

    Harald> Doing this at the same time as considering the PR-action
    Harald> against "X" has some interesting consequences:

    Harald> - The "problem behaviour" that the rule seeks to address
    Harald> is likely to get crafted so that it's clear whether "X"'s
    Harald> behaviour falls within or outside the description. While
    Harald> this makes things clearer in this case, I believe that
    Harald> history shows very low predictive value for whether or not
    Harald> such a rule will be clear once a new case comes along.

I am not proposing a new rule, simply a new sanction to be made
available.

    Harald> - The "reaction" that the rule seeks to implement will
    Harald> take the form of whatever the discussion concludes is a
    Harald> reasonable reaction to the behaviour exhibited by
    Harald> "X". Again, this is no predictor of whether or not the
    Harald> reaction will be adequate, overreaction, or underreaction
    Harald> for the next case that comes along.

Again, I'm not sure I see this applies to create a new possible sanction for the same behavior.

    Harald> - The discussion that has to come before the final
    Harald> crafting of the new rules is likely to take some time -
    Harald> months, if experience is a guide. This offers an excuse
    Harald> for avoiding making a decision in "X"'s specific case -
    Harald> thus prolonging the time of indecision.

I believe this would be unacceptable if it happens.

That's why I I favor an experimental rule.

    Harald> I do not want the IETF to craft rules for "X", and then
    Harald> re-craft them for "Y", "Z" and "W" because hastily crafted
    Harald> rules did not fit the next situation to come along. I want
    Harald> the rules to be reasonable, and stable.  And I think
    Harald> making up rules while considering a specific unique case
    Harald> is harmful to such a process.

Perhaps.  However precident-based case law seems to work well for a
number of process systems.

    Harald> One point in closing:

    Harald> A PR-action, or a mailing list suspension, is NOT a
    Harald> punishment. Rules of order exist to protect the IETF's
    Harald> ability to do its work.

Here we completely agree.

I think I now understand the concerns you have.  I believe perhaps
from a position of hubris that the IESG can manage these risks.


--Sam

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 21:43:49 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F47yH-00077v-09; Tue, 31 Jan 2006 21:43:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F47wx-0006fN-0Q
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 21:42:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28766
	for ; Tue, 31 Jan 2006 21:40:38 -0500 (EST)
Received: from [66.114.247.57] (helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F487p-0001Ur-EN
	for ietf@ietf.org; Tue, 31 Jan 2006 21:53:42 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 570DBE0074; Tue, 31 Jan 2006 21:42:08 -0500 (EST)
To: ietf@ietf.org
From: Sam Hartman 
Message-Id: <20060201024208.570DBE0074@carter-zimmerman.mit.edu>
Date: Tue, 31 Jan 2006 21:42:08 -0500 (EST)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Subject: Call for input: draft-hartman-mailinglist-experiment-00.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org



As many have noticed, I have prepared a draft on an RFC 3933
experiment for mailing list management.

The goal is to give very liberal powers to the IESG equivelent to the
powers originally given to the IESG under RFC 2418 for working group
lists over all IETF lists.


The main reason for an experiment is that I believe that we can get
this published fast and a new BCP will take a while.

I clearly need to make the following changes:

1) Incorporate the IAB appeal response.

2) Make it clear that this applies to non-wg lists and to clarify what
    an IETF list is.  John Klensin has supplied excellent text for
    this.


I'm also asking the IESG to comment on whether they would find the
experiment useful.  I think one of the major requirements for an RFC
3933 experiment is whether the stakeholders would find the experiment
useful.
So I need to see if the IESG even wants this.

I'm interested in feedback on the following issues:

* Is 18 months too long for the experiment.  I don't think so but have
received one comment requesting 12 months.

* Are there limits that need to be placed on the IESG's authority?  My
  preference is to grant the same authority available under RFC 2418 for WG lists to all IETF lists.

* Are there other changes that need to be made?


--Sam

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 22:31:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F48i9-0003wa-CF; Tue, 31 Jan 2006 22:31:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F48i2-0003sW-HX
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 22:31:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01875
	for ; Tue, 31 Jan 2006 22:29:20 -0500 (EST)
Received: from xuxa.iecc.com ([208.31.42.42])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F48sy-0002tP-Nf
	for ietf@ietf.org; Tue, 31 Jan 2006 22:42:26 -0500
Received: (qmail 25486 invoked from network); 1 Feb 2006 03:30:49 -0000
Received: from simone.iecc.com (208.31.42.47)
	by mail2.iecc.com with QMQP; 1 Feb 2006 03:30:49 -0000
Date: 1 Feb 2006 03:30:49 -0000
Message-ID: <20060201033049.37674.qmail@simone.iecc.com>
From: John Levine 
To: ietf@ietf.org
In-Reply-To: <6.2.1.2.0.20060131181010.031c4d18@mail.stevecrocker.com>
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: joel@stevecrocker.com
Subject: Re: I-D ACTION: draft-ash-alt-formats-01.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

>First and foremost, if the input format is PDF, how will the RFC Editor 
>edit the document?  PDF documents are not editable.

Well, this particular proposal only makes PDF an output format, but
the question is still a good one.  Without an editorial process to
create the PDFs, it's not much of an experiment.

I think I understand many of the issues here, and they don't strike me
as being amenable to solution by wiggling the back end.  If the goal
is to allow prettier output while still maintaining the stability and
reusability of plain text, that practically demands an input format
that is plain text underneath (for the stability and reusability) but
structured enough that it can be converted mechanicically to PDF or
whatever.  The obvious candidate is an XML profile with some tools to
render it into output formats.  But now we have to face questions
about which version is authoritative (the XML, presumably) and whether
the PDF version is any more than a convenience for people who don't
like to read XML.  I could easily envision a system that archives the
XML along with renderings into PDF, HTML, or whatever else people like
to read, adding new translators as desired to offer them in whatever
trendy new format (podcast?) is popular next.

None of this is is a technical stretch.  What's hard is making sure
the processes work, for the people who write drafts and RFCs, the
people who do the editorial work, and the people who use the results.
So I have to ask, what part of this problem does an experiment that
just permits PDF output solve?

R's,
John


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 22:36:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F48ms-0005qF-NH; Tue, 31 Jan 2006 22:36:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F48mm-0005iQ-3S
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 22:36:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02122
	for ; Tue, 31 Jan 2006 22:34:17 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F48xm-00030x-9y
	for ietf@ietf.org; Tue, 31 Jan 2006 22:47:22 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F48mP-0003Cg-Be
	for ietf@ietf.org; Wed, 01 Feb 2006 04:35:37 +0100
Received: from 1cust232.tnt6.hbg2.deu.da.uu.net ([149.225.18.232])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Wed, 01 Feb 2006 04:35:37 +0100
Received: from nobody by 1cust232.tnt6.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Wed, 01 Feb 2006 04:35:37 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Wed, 01 Feb 2006 04:33:17 +0100
Organization: 
Lines: 25
Message-ID: <43E02BFD.778E@xyzzy.claranet.de>
References: <43DFAC4B.1070309@thinkingcat.com>
	<6.2.3.4.2.20060201011759.06605eb0@mail.jefsey.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust232.tnt6.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Subject: Re: IAB Response to Appeal from [...]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

JFC (Jefsey) Morfin wrote:

> I hope this list will soon be a IANA managed mailing list,
> or that the IESG requires the WG-ltru to gives it a more
> precise status through RFC 3066 bis (a debate I proposed
> and I was denied).

That's of course not the case, it was debated for quite some
time in "the making of 30066bis":




Just two examples grepping for "3934" in an LTRU archive.
 
> I consider that Harald and I are both only trying to do our
> best to clarify a complex issue to the benefit of the users
> and of the IETF. I genuinely hope the IAB decision will help
> us to openly discuss it, taking the necessary time.

Whatever it takes.  I like a new IAB draft published recently:

-- 
Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 23:31:17 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F49eG-00007E-3l; Tue, 31 Jan 2006 23:31:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F49eE-00006q-HC
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 23:31:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05679
	for ; Tue, 31 Jan 2006 23:29:35 -0500 (EST)
Received: from laubervilliers-151-12-129-223.w193-252.abo.wanadoo.fr
	([193.252.54.223] helo=freebie.atkielski.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F49pH-0004gj-Gl
	for ietf@ietf.org; Tue, 31 Jan 2006 23:42:41 -0500
Received: from pix.atkielski.com (pix.atkielski.com [10.0.0.40])
	by freebie.atkielski.com (8.13.1/8.13.1) with ESMTP id k114Ut6s036910
	for ; Wed, 1 Feb 2006 05:30:55 +0100 (CET)
	(envelope-from anthony@atkielski.com)
Date: Wed, 1 Feb 2006 05:30:55 +0100
From: "Anthony G. Atkielski" 
Organization: Anthony Atkielski
X-Priority: 3 (Normal)
Message-ID: <1487089042.20060201053055@atkielski.com>
To: ietf@ietf.org
In-Reply-To: <20060201024208.570DBE0074@carter-zimmerman.mit.edu>
References: <20060201024208.570DBE0074@carter-zimmerman.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.5 (+++)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Subject: Re: Call for input: draft-hartman-mailinglist-experiment-00.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam Hartman writes:

> I'm interested in feedback on the following issues:
>
> * Is 18 months too long for the experiment.  I don't think so but have
> received one comment requesting 12 months.
>
> * Are there limits that need to be placed on the IESG's authority?  My
>   preference is to grant the same authority available under RFC
> 2418 for WG lists to all IETF lists.
>
> * Are there other changes that need to be made?

You forgot this:

* Are there better ways for list members to spend their time in
service of the IETF than by coming up with new ways to censor and ban
on mailing lists?

Perhaps some simplification is in order; I believe an Act of Congress
might be a good model to follow in looking for something less complex
than the current policy.


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 23:31:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F49eb-0000B0-9U; Tue, 31 Jan 2006 23:31:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F49eU-000095-Hi; Tue, 31 Jan 2006 23:31:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05694;
	Tue, 31 Jan 2006 23:29:43 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F49pQ-0004hV-82; Tue, 31 Jan 2006 23:42:49 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F49dq-0007yE-57; Tue, 31 Jan 2006 20:30:50 -0800
Message-Id: <6.2.3.4.2.20060201045044.0675ee90@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Wed, 01 Feb 2006 04:52:50 +0100
To: Sam Hartman ,
	Harald Tveit Alvestrand 
From: "JFC (Jefsey) Morfin" 
In-Reply-To: 
References: 
	
	
	
	
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-3C527EA4
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: Scott Hollenbeck , ietf@ietf.org, iesg@ietf.org
Subject: Re: Fairness and changing rules
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 02:19 01/02/2006, Sam Hartman wrote:

> >>>>> "Harald" == Harald Tveit Alvestrand  writes:
>
>     Harald> Sam, let me put it this way:
>
>     Harald> Changing the rules in the middle of the process is Just
>     Harald> Plain Stupid. We've done that too many times to count.

I am not sure I read this mail?
Anyway, this means a jurisprudence.
Under "Y" chairmanship.

At 03:13 01/02/2006, Harald Tveit Alvestrand wrote:
>Sam,
>trying to avoid pointing at persons, despite the fact that a 
>specific person is at the heart of the current discussion...... your 
>3 points are very valid reasons for avoiding rule changes, but I 
>think you miss the point I was trying to make.
>
>The IESG was asked to choose between two alternatives:
>- Execute a PR-Action against "X"
>- Do not execute a PR-Action against "X"

You right. This makes the first alternative.

The second alternative I asked for but not engaged yet is:
- Execute a PR-Action against "Y"
- Do not execute a PR-Action against "Y"

It will be based upon the time wasted since Nov 15th, 2005 in order 
to delay the action decided during the Versailles meeting.

>A PR-action, or a mailing list suspension, is NOT a punishment. 
>Rules of order exist to protect the IETF's ability to do its work.
>I believe that's your central responsibility.

I need a clarification here. Do you mean that once you engaged a PR 
defamaction, only Y can talk, and X should shut-up or this is a DoS 
and prevents the IETF to carry its work?

jfc




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 23:37:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F49kB-0001vX-74; Tue, 31 Jan 2006 23:37:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F49k3-0001tk-13
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 23:37:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06054
	for ; Tue, 31 Jan 2006 23:35:27 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F49uw-0004qg-UR
	for ietf@ietf.org; Tue, 31 Jan 2006 23:48:31 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1F49jj-0006MZ-C1
	for ietf@ietf.org; Wed, 01 Feb 2006 05:36:55 +0100
Received: from 1cust232.tnt6.hbg2.deu.da.uu.net ([149.225.18.232])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for ; Wed, 01 Feb 2006 05:36:55 +0100
Received: from nobody by 1cust232.tnt6.hbg2.deu.da.uu.net with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for ; Wed, 01 Feb 2006 05:36:55 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann 
Date: Wed, 01 Feb 2006 05:34:14 +0100
Organization: 
Lines: 23
Message-ID: <43E03A46.4EE9@xyzzy.claranet.de>
References: <20060201024208.570DBE0074@carter-zimmerman.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 1cust232.tnt6.hbg2.deu.da.uu.net
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Subject: Re: Call for input: draft-hartman-mailinglist-experiment-00.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Sam Hartman wrote:

> * Is 18 months too long for the experiment.  I don't think
>   so but have received one comment requesting 12 months.

Is that about what I posted here in
 ?

In that case I wasn't sure if 12 or 18 months are long enough
to catch one application of the experiment, but apparently 12
months is a hard limit in RfC 3933 (?)

> * Are there other changes that need to be made?

Exclude the general list (this list) as special case, it's too
confusing if you experiment also with RfC 3005 and its special
appeal rules.

Unless Brian wants to "opt in" to this list experiment with the
general list.  But one stable point outside of the experiment
might be a good idea.
                              Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



From ietf-bounces@ietf.org Tue Jan 31 23:47:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F49ts-0004Ge-NU; Tue, 31 Jan 2006 23:47:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F49tn-0004FH-PU
	for ietf@megatron.ietf.org; Tue, 31 Jan 2006 23:47:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06534
	for ; Tue, 31 Jan 2006 23:45:36 -0500 (EST)
Received: from montage.altserver.com ([63.247.74.122])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4A4l-00056K-Lp
	for ietf@ietf.org; Tue, 31 Jan 2006 23:58:40 -0500
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24]
	helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52)
	id 1F49tI-0002Q6-VR; Tue, 31 Jan 2006 20:46:49 -0800
Message-Id: <6.2.3.4.2.20060201053803.06713c10@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Wed, 01 Feb 2006 05:46:28 +0100
To: Frank Ellermann , ietf@ietf.org
From: "JFC (Jefsey) Morfin" 
In-Reply-To: <43E02BFD.778E@xyzzy.claranet.de>
References: <43DFAC4B.1070309@thinkingcat.com>
	<6.2.3.4.2.20060201011759.06605eb0@mail.jefsey.com>
	<43E02BFD.778E@xyzzy.claranet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-3C527EA4
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: 
Subject: Re: IAB Response to Appeal from [...]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear Frank,
RFC 3066 bis is now a local low interest issue, under IESG appeal, 
mainly for security considerations.
IRT your so called debate, I do not think that "leaving the things as 
they are" is an innovative solution. Now someone has to do the work.
jfc


At 04:33 01/02/2006, Frank Ellermann wrote:

>JFC (Jefsey) Morfin wrote:
>
> > I hope this list will soon be a IANA managed mailing list,
> > or that the IESG requires the WG-ltru to gives it a more
> > precise status through RFC 3066 bis (a debate I proposed
> > and I was denied).
>
>That's of course not the case, it was debated for quite some
>time in "the making of 30066bis":
>
>
>
>
>Just two examples grepping for "3934" in an LTRU archive.
>
> > I consider that Harald and I are both only trying to do our
> > best to clarify a complex issue to the benefit of the users
> > and of the IETF. I genuinely hope the IAB decision will help
> > us to openly discuss it, taking the necessary time.
>
>Whatever it takes.  I like a new IAB draft published recently:
>
>--
>Frank
>
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf