From elwynd@googlemail.com Wed Aug 4 11:32:52 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748523A67DB for ; Wed, 4 Aug 2010 11:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Hqu-ey7JcGl for ; Wed, 4 Aug 2010 11:32:48 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EFD213A680A for ; Wed, 4 Aug 2010 11:32:45 -0700 (PDT)
Received: by wwj40 with SMTP id 40so5475419wwj.13 for ; Wed, 04 Aug 2010 11:33:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=p68AN6FKgIbiHNRA1KGJLGJtv1V1stVgnEUW0QQjp+s=; b=gosnQ8/CDk4M80vn8giNtTLWQ4/wYvEZvWXbqnVQwvgnc1oTucPV2OahdnFPxufgSK g9WQNWC2EwSthHPP48Vcyr8DEJ71Cl6qfFoG6fYj0HtgTN9qRhToC4z9T5VPqdvQmON0 y+TNyEpVCVmFIQqN/Sef36MYUOCkA7k28oubk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=eFXkt5m4eSK91IrAAA6z9U3HEpS4hT48eMeSnXivKID1+m88SPaXE+eitATwXFxEbU uzBykfXHGaxJeGzhYQ5g4v42FiGzGX5syGBLPqQWdcPtWBMfh4Ar7rBN3C0XssQm6Xno xgCD5lueBpRhsT1PpG7IGZaIoQ85YUFVSwV9k=
Received: by 10.227.152.149 with SMTP id g21mr8023098wbw.228.1280946793598; Wed, 04 Aug 2010 11:33:13 -0700 (PDT)
Received: from [81.187.254.247] (247.254.187.81.in-addr.arpa [81.187.254.247]) by mx.google.com with ESMTPS id f30sm7462431wbe.18.2010.08.04.11.33.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 11:33:11 -0700 (PDT)
Message-ID: <4C59B319.3010609@googlemail.com>
Date: Wed, 04 Aug 2010 19:36:09 +0100
From: Elwyn Davies
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Tools Team Discussion
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Tools-discuss] HTML markup of drafts - reference corner case?
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 04 Aug 2010 18:32:52 -0000
Hi.
I was just reading
http://tools.ietf.org/html/draft-ietf-v6ops-isp-scenarios-00 and noticed
that the HTML markup seemed to have missed some of the references.
For example, the last paragraph on page 3:
> [RFC4779] discusses deployment in broadband access networks such as
> CATV, ADSL and wireless. [RFC5181 ], [RFC5121 ] and
> [I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16 ] deal specifically
> with IEEE 802.16 access networks. MPLS-based ISPs may use the 6PE
>
>
>
> Carpenter & Jiang Expires October 17, 2010 [Page 3]
>
>
> Internet-Draft ISP IPv6 Scenarios April 2010
>
>
> [RFC4798] mechanism.
>
Here the RFC references not at the beginning of lines (RFC 5181 ad 5121)
produce links whereas the ones at the beginning of lines don't (RFC 4779
and 4798). I guess this is something in the already heroic pattern
matching that doesn't pick up these examples.
Regards,
Elwyn
From henrik@levkowetz.com Thu Aug 5 04:34:54 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2FB3A686B for ; Thu, 5 Aug 2010 04:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.856
X-Spam-Level:
X-Spam-Status: No, score=-101.856 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZsIa9KHhnDE for ; Thu, 5 Aug 2010 04:34:53 -0700 (PDT)
Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id 996D33A6841 for ; Thu, 5 Aug 2010 04:34:53 -0700 (PDT)
Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:61464 helo=dyn-fg124.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OgyjB-00027q-VO; Thu, 05 Aug 2010 13:35:15 +0200
Message-ID: <4C5AA1F1.30407@levkowetz.com>
Date: Thu, 05 Aug 2010 13:35:13 +0200
From: Henrik Levkowetz
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Elwyn Davies
References: <4C59B319.3010609@googlemail.com>
In-Reply-To: <4C59B319.3010609@googlemail.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e
X-SA-Exim-Rcpt-To: elwynd@googlemail.com, tools-discuss@ietf.org, henrik-sent@levkowetz.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org)
Cc: Tools Team Discussion
Subject: Re: [Tools-discuss] HTML markup of drafts - reference corner case?
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 05 Aug 2010 11:34:54 -0000
Hi Elwyn,
On 2010-08-04 20:36 Elwyn Davies said:
...
> Here the RFC references not at the beginning of lines (RFC 5181 ad 5121)
> produce links whereas the ones at the beginning of lines don't (RFC 4779
> and 4798). I guess this is something in the already heroic pattern
> matching that doesn't pick up these examples.
Yes. Since the conversion is done by pattern matching rather than parsing,
it's hard to differentiate between places in the text where there's a
reference to an entry in the reference section, and the entry itself, if the
in-text reference is placed at the beginning of a line.
I'll see if I can refine things to handle this case, though.
Best,
Henrik
From henrik@levkowetz.com Mon Aug 9 05:18:00 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E257C28C0DC; Mon, 9 Aug 2010 05:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.414
X-Spam-Level:
X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxZTJu-oPyAT; Mon, 9 Aug 2010 05:18:00 -0700 (PDT)
Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id C579F28B56A; Mon, 9 Aug 2010 05:17:59 -0700 (PDT)
Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:50797 helo=dyn-fg117.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OiRJ8-0000A5-7b; Mon, 09 Aug 2010 14:18:23 +0200
Message-ID: <4C5FF20D.1010406@levkowetz.com>
Date: Mon, 09 Aug 2010 14:18:21 +0200
From: Henrik Levkowetz
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: JP Vasseur
References: <2CEC3E28-FB45-4D7E-AEDA-B88F180BD5AE@cisco.com>
In-Reply-To: <2CEC3E28-FB45-4D7E-AEDA-B88F180BD5AE@cisco.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e
X-SA-Exim-Rcpt-To: jpv@cisco.com, tools-development@ietf.org, tools-discuss@ietf.org, Adrian.Farrel@huawei.com, henrik-sent@levkowetz.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org)
Cc: tools-development@ietf.org, tools-discuss@ietf.org, Adrian Farrel
Subject: Re: [Tools-discuss] [TOOLS-DEVELOPMENT] Ticketing System Feed-back
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 09 Aug 2010 12:18:01 -0000
Hi JP,
On 2010-08-03 12:10 JP Vasseur said:
> Dear all,
>
> First of all I'd like to share some very positive feed-back on the use
> of the ticketing system. As with any other tool, it requires a bit of
> time to get used to it and even more importantly use it appropriately.
> Please find attached a short presentation that I used during the
> Routing Area open meeting (copying Adrian who proposed that slot, our
> Routing AD).
>
> Should I have suggestions to improve the tool, is it the appropriate
> mailing list ? Would you be interested ?
tools-discuss@ietf.org is probably the most appropriate list. Yes,
suggestions are welcome :-)
In your slides, you mention:
- Provide stats
This may be possible, but it depends on which
stats it is you would like...
- Automatic reminder
Should be possible. I'll look into this.
- Tickets for item even if there's not yet an ID
I believe this is already possible -- could
you expand on this; what do you feel is missing
to make this possible?
Best,
Henrik
From henrik@levkowetz.com Wed Aug 11 10:11:29 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D293A69AD for ; Wed, 11 Aug 2010 10:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.432
X-Spam-Level:
X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMYa9GOA8psi for ; Wed, 11 Aug 2010 10:11:24 -0700 (PDT)
Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id 8BC533A6A7B for ; Wed, 11 Aug 2010 10:11:21 -0700 (PDT)
Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:63363 helo=dyn-fg117.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OjEq3-0003Ab-KY; Wed, 11 Aug 2010 19:11:41 +0200
Message-ID: <4C62D9CB.9060100@levkowetz.com>
Date: Wed, 11 Aug 2010 19:11:39 +0200
From: Henrik Levkowetz
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: JP Vasseur
References: <2CEC3E28-FB45-4D7E-AEDA-B88F180BD5AE@cisco.com> <4C5FF20D.1010406@levkowetz.com> <3D25CDB7-CD1D-428E-B502-79FCB35C2D1C@cisco.com>
In-Reply-To: <3D25CDB7-CD1D-428E-B502-79FCB35C2D1C@cisco.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e
X-SA-Exim-Rcpt-To: jpv@cisco.com, tools-discuss@ietf.org, Adrian.Farrel@huawei.com, henrik-sent@levkowetz.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org)
Cc: Adrian Farrel , tools-discuss@ietf.org
Subject: Re: [Tools-discuss] [TOOLS-DEVELOPMENT] Ticketing System Feed-back
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 11 Aug 2010 17:11:29 -0000
Hi JP,
On 2010-08-10 19:44 JP Vasseur said:
> Hi Henrik,
>
> On Aug 9, 2010, at 1:18 PM, Henrik Levkowetz wrote:
...
>> - Provide stats
>> This may be possible, but it depends on which
>> stats it is you would like...
>
> Basically, on the monthly basis:
> * number of new opened tickets
> * number of closed tickets
> * number of remaining tickets
>
> If that could be done for all and then also on a per priority basis
> (minor, major), then per document basis, ... that would be excellent
> of course.
I've added a new macro which lets you do all this. Links to full info
about the macro, and an example without selecting any subsets can be
seen here:
https://wiki.tools.ietf.org/wg/roll/trac/wiki/IetfSpecificFeatures
I'm not too happy about it using a flash component, but to do better
I'd have to rewrite it, which is not on the table right now.
>>
>> - Automatic reminder
>> Should be possible. I'll look into this.
>>
I've found one existing module which sends reminders, but it's not
well written and can't be configured the way we'd want it. TODO.
> That'd be great, thanks.
>
>> - Tickets for item even if there's not yet an ID
>> I believe this is already possible -- could
>> you expand on this; what do you feel is missing
>> to make this possible?
>>
>
> Let me check, I might have missed that this was indeed already possible.
Ok, good.
Best,
Henrik
From vaclav.vacek@siemens.com Mon Aug 9 02:20:29 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E50E3A67F7 for ; Mon, 9 Aug 2010 02:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.829
X-Spam-Level:
X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dswYNHKu4xCy for ; Mon, 9 Aug 2010 02:20:27 -0700 (PDT)
Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 2D2D03A67A1 for ; Mon, 9 Aug 2010 02:20:26 -0700 (PDT)
Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id o799KxYA002726 for ; Mon, 9 Aug 2010 11:20:59 +0200
Received: from nets139a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id o799KxqX017545 for ; Mon, 9 Aug 2010 11:20:59 +0200
Received: from prga004a.ww300.siemens.net ([163.242.71.105]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 11:20:59 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB37A4.2D86C9A5"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 9 Aug 2010 11:20:58 +0200
Message-ID: <3E4278088AD82C48B4663DDFE762CEF307FE8F61@prga004a.ww300.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: New IETF Tool Proposal
Thread-Index: Acs3pC0QxcXUVu6VTUiBZV1veChM7Q==
From: "Vacek, Vaclav"
To:
X-OriginalArrivalTime: 09 Aug 2010 09:20:59.0461 (UTC) FILETIME=[2DE92750:01CB37A4]
X-purgate: clean
X-purgate: This mail is considered clean
X-purgate-type: clean
X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net
X-purgate-ID: 149917::100809112059-2413FBA0-371F397D/0-0/0-15
X-purgate-size: 6410/0
X-Mailman-Approved-At: Tue, 17 Aug 2010 09:18:55 -0700
Subject: [Tools-discuss] New IETF Tool Proposal
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 09 Aug 2010 09:22:54 -0000
This is a multi-part message in MIME format.
------_=_NextPart_001_01CB37A4.2D86C9A5
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: base64
SGksDQogIEkgaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyBhZGRpbmcgYSBuZXcgdG9vbCB0byB0
aGUgbGlzdCBhdCB0b29scy5pZXRmLm9yZy4gVGhlcmUgaGFzIGJlZW4gYSBzeW50YXgtdmVyaWZp
Y2F0aW9uIHRvb2wgKGJuZnBhcnNlcsKyIC0gaHR0cDovL2JuZnBhcnNlcjIuc291cmNlZm9yZ2Uu
bmV0LykgZGV2ZWxvcGVkIGFzIGEgam9pbnQgcHJvamVjdCBvZiBBTkYgREFUQSBzcG9sLiBzIHIu
by4gKGh0dHA6Ly93d3cuYW5mZGF0YS5jeikgYW5kIHRoZSBJbnN0aXR1dGUgZm9yIFRoZW9yZXRp
Y2FsIENvbXB1dGVyIFNjaWVuY2UgKElUSSksIEZhY3VsdHkgb2YgSW5mb3JtYXRpY3MsIE1hc2Fy
eWsgVW5pdmVyc2l0eSAoaHR0cDovL2l0aS5maS5tdW5pLmN6LykuDQogDQpCbmZwYXJzZXLCsiBh
bGxvd3MgcnVudGltZSBnZW5lcmF0aW9uIG9mIGEgcGFyc2VyIGZyb20gYSBncmFtbWFyIHdyaXR0
ZW4gaW4gQUJORiBvciBvdGhlciB1c2VyLWRlZmluZWQgc3ludGF4LiBUaGUgcGFyc2VyIGlzIHRo
ZW4gYWJsZSB0byBwYXJzZSBzdHJpbmdzLCBsb2NhdGUgZXJyb3JzIGFuZCBhbHNvIG1hcmsgc3Vi
c3RyaW5ncyBnZW5lcmF0ZWQgZnJvbSB1c2VyLWRlZmluZWQgbm9udGVybWluYWxzLg0KVGhlIHBh
cnNlciBjYW4gaGFuZGxlIGFtYmlndW91cyBncmFtbWFycyBhcyB3ZWxsLg0KIA0KV2Ugd291bGQg
bGlrZSB0byB0byBydW4gYW4gb25saW5lIHNlcnZpY2Ugd2l0aGluIGEgbW9udGg7IHRoZSBjdXJy
ZW50IHZlcnNpb24gcmVmZXJlbmNlZCBmcm9tIHRoZSBibmZwYXJzZXLCsidzIGhvbWVwYWdlIGlz
IG9ic29sZXRlLg0KIA0KRmluYWxseSwgaGVyZSdzIHRoZSBxdWVzdGlvbjoNCldoYXQgc3RlcHMg
bmVlZCB0byBiZSBkb25lIGluIG9yZGVyIHRoYXQgYm5mcGFyc2VywrIgaXMgYWRkZWQgdG8gSUVU
RiB0b29scz8NCiANClRoYW5rIHlvdSBpbiBhZHZhbmNlIQ0KIA0KQmVzdCByZWdhcmRzDQogDQpW
w6FjbGF2IFZhY2VrDQpBTkYgREFUQSBzcG9sLiBzIHIuby4NCiANCk9mZmljZToNCkxvbmTDvW5z
a8OpIG7DoW0uIDQNCjYzOSAwMCwgQnJubw0KxIxlc2vDoSByZXB1Ymxpa2ENCiANClBob25lICAg
KzQyMCA1MzggNzc2IDg4Mg0KdmFjbGF2LnZhY2VrQHNpZW1lbnMuY29tIDxtYWlsdG86dmFjbGF2
LnZhY2VrQHNpZW1lbnMuY29tPiANCmh0dHA6Ly93d3cuYW5mZGF0YS5jeiA8aHR0cDovL3d3dy5h
bmZkYXRhLmN6Lz4gDQo=
------_=_NextPart_001_01CB37A4.2D86C9A5
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: base64
77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u
dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2
LjAwLjI5MDAuNTk2OSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U
IGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NTg0MjEwMDA5LTA5MDgyMDEwPkhpLDwv
U1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNs
YXNzPTU4NDIxMDAwOS0wOTA4MjAxMD4mbmJzcDsgSSBoYXZlIGEgDQpxdWVzdGlvbiByZWdhcmRp
bmcgYWRkaW5nIGEgbmV3IHRvb2wgdG8gdGhlIGxpc3QgYXQgdG9vbHMuaWV0Zi5vcmcuIFRoZXJl
IGhhcyANCmJlZW4gYSBzeW50YXgtdmVyaWZpY2F0aW9uIHRvb2wgKGJuZnBhcnNlcsKyIC0gPEEg
DQpocmVmPSJodHRwOi8vYm5mcGFyc2VyMi5zb3VyY2Vmb3JnZS5uZXQvIj5odHRwOi8vYm5mcGFy
c2VyMi5zb3VyY2Vmb3JnZS5uZXQvPC9BPikgDQpkZXZlbG9wZWQgYXMgYSBqb2ludCBwcm9qZWN0
IG9mJm5ic3A7QU5GIERBVEEgc3BvbC4gcyByLm8uICg8QSANCmhyZWY9Imh0dHA6Ly93d3cuYW5m
ZGF0YS5jeiI+aHR0cDovL3d3dy5hbmZkYXRhLmN6PC9BPikgYW5kIHRoZSZuYnNwO0luc3RpdHV0
ZSANCmZvciBUaGVvcmV0aWNhbCBDb21wdXRlciBTY2llbmNlIChJVEkpLCBGYWN1bHR5IG9mIElu
Zm9ybWF0aWNzLCBNYXNhcnlrIA0KVW5pdmVyc2l0eSAoPEEgDQpocmVmPSJodHRwOi8vaXRpLmZp
Lm11bmkuY3ovIj5odHRwOi8vaXRpLmZpLm11bmkuY3ovPC9BPikuPC9TUEFOPjwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz01ODQyMTAwMDkt
MDkwODIwMTA+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh
bCBzaXplPTI+PFNQQU4gY2xhc3M9NTg0MjEwMDA5LTA5MDgyMDEwPkJuZnBhcnNlcsKyIGFsbG93
cyANCnJ1bnRpbWUgZ2VuZXJhdGlvbiBvZiBhIHBhcnNlciBmcm9tIGEgZ3JhbW1hciB3cml0dGVu
IGluIEFCTkYgb3Igb3RoZXIgDQp1c2VyLWRlZmluZWQgc3ludGF4LiBUaGUgcGFyc2VyIGlzIHRo
ZW4gYWJsZSB0byBwYXJzZSBzdHJpbmdzLCBsb2NhdGUgZXJyb3JzIGFuZCANCmFsc28gbWFyayBz
dWJzdHJpbmdzIGdlbmVyYXRlZCBmcm9tIHVzZXItZGVmaW5lZCANCm5vbnRlcm1pbmFscy48L1NQ
QU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFz
cz01ODQyMTAwMDktMDkwODIwMTA+VGhlIHBhcnNlciBjYW4gDQpoYW5kbGUgYW1iaWd1b3VzIGdy
YW1tYXJzIGFzIHdlbGwuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh
bCBzaXplPTI+PFNQQU4gDQpjbGFzcz01ODQyMTAwMDktMDkwODIwMTA+PC9TUEFOPjwvRk9OVD4m
bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NTg0
MjEwMDA5LTA5MDgyMDEwPldlIHdvdWxkIGxpa2UgdG8gdG8gDQpydW4gYW4gb25saW5lIHNlcnZp
Y2Ugd2l0aGluIGEgbW9udGg7IHRoZSBjdXJyZW50IHZlcnNpb24gcmVmZXJlbmNlZCBmcm9tIHRo
ZSANCmJuZnBhcnNlcsKyJ3MgaG9tZXBhZ2UgaXMgb2Jzb2xldGUuPC9TUEFOPjwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz01ODQyMTAwMDkt
MDkwODIwMTA+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh
bCBzaXplPTI+PFNQQU4gY2xhc3M9NTg0MjEwMDA5LTA5MDgyMDEwPkZpbmFsbHksIGhlcmUncyB0
aGUgDQpxdWVzdGlvbjo8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs
IHNpemU9Mj48U1BBTiBjbGFzcz01ODQyMTAwMDktMDkwODIwMTA+V2hhdCBzdGVwcyBuZWVkIHRv
IA0KYmUgZG9uZSBpbiBvcmRlciB0aGF0IGJuZnBhcnNlcsKyIGlzIGFkZGVkIHRvIElFVEYgdG9v
bHM/PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQ
QU4gDQpjbGFzcz01ODQyMTAwMDktMDkwODIwMTA+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4N
CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NTg0MjEwMDA5LTA5MDgy
MDEwPlRoYW5rIHlvdSBpbiANCmFkdmFuY2UhPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZP
TlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz01ODQyMTAwMDktMDkwODIwMTA+PC9T
UEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NTg0MjEwMDA5LTA5MDgy
MDEwPg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkJlc3QgcmVnYXJk
czwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNw
OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Ww6FjbGF2IFZhY2VrPEJSPkFO
RiBEQVRBIHNwb2wuIHMgci5vLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz
aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5P
ZmZpY2U6PEJSPkxvbmTDvW5za8OpIG7DoW0uIDQ8QlI+NjM5IDAwLCANCkJybm88QlI+xIxlc2vD
oSByZXB1Ymxpa2E8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwv
Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+UGhvbmUmbmJz
cDsmbmJzcDsgKzQyMCA1MzggNzc2IDg4MjxCUj48L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86dmFj
bGF2LnZhY2VrQHNpZW1lbnMuY29tIj48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPnZhY2xhdi52
YWNla0A8U1BBTiANCmNsYXNzPTU4NDIxMDAwOS0wOTA4MjAxMD5zaWVtZW5zPC9TUEFOPi5jb208
L0ZPTlQ+PC9BPjxCUj48QSANCmhyZWY9Imh0dHA6Ly93d3cuYW5mZGF0YS5jei8iPjxGT05UIGZh
Y2U9QXJpYWwgDQpzaXplPTI+aHR0cDovL3d3dy5hbmZkYXRhLmN6PC9GT05UPjwvQT48L0RJVj48
L1NQQU4+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==
------_=_NextPart_001_01CB37A4.2D86C9A5--
From jpv@cisco.com Tue Aug 10 11:25:36 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9ED53A691A for ; Tue, 10 Aug 2010 11:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.468
X-Spam-Level:
X-Spam-Status: No, score=-110.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPTRl09cRczq for ; Tue, 10 Aug 2010 11:25:36 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 03F983A6A83 for ; Tue, 10 Aug 2010 11:25:35 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEABQ3YUyrR7Ht/2dsb2JhbACgLHGhaJtThToEiUCCVQ
X-IronPort-AV: E=Sophos;i="4.55,349,1278288000"; d="scan'208";a="238384331"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 10 Aug 2010 18:26:11 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7AIQ8TF005580; Tue, 10 Aug 2010 18:26:10 GMT
Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 20:26:09 +0200
Received: from [10.98.96.115] ([10.61.96.103]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 20:26:07 +0200
Message-Id: <3D25CDB7-CD1D-428E-B502-79FCB35C2D1C@cisco.com>
From: JP Vasseur
To: Henrik Levkowetz
In-Reply-To: <4C5FF20D.1010406@levkowetz.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 10 Aug 2010 18:44:06 +0100
References: <2CEC3E28-FB45-4D7E-AEDA-B88F180BD5AE@cisco.com> <4C5FF20D.1010406@levkowetz.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 10 Aug 2010 18:26:08.0561 (UTC) FILETIME=[80777A10:01CB38B9]
X-Mailman-Approved-At: Tue, 17 Aug 2010 09:18:55 -0700
Cc: Adrian Farrel , tools-discuss@ietf.org
Subject: Re: [Tools-discuss] [TOOLS-DEVELOPMENT] Ticketing System Feed-back
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 10 Aug 2010 18:25:37 -0000
Hi Henrik,
On Aug 9, 2010, at 1:18 PM, Henrik Levkowetz wrote:
> Hi JP,
>
> On 2010-08-03 12:10 JP Vasseur said:
>> Dear all,
>>
>> First of all I'd like to share some very positive feed-back on the
>> use
>> of the ticketing system. As with any other tool, it requires a bit of
>> time to get used to it and even more importantly use it
>> appropriately.
>> Please find attached a short presentation that I used during the
>> Routing Area open meeting (copying Adrian who proposed that slot, our
>> Routing AD).
>>
>> Should I have suggestions to improve the tool, is it the appropriate
>> mailing list ? Would you be interested ?
>
> tools-discuss@ietf.org is probably the most appropriate list. Yes,
> suggestions are welcome :-)
>
> In your slides, you mention:
>
> - Provide stats
> This may be possible, but it depends on which
> stats it is you would like...
Basically, on the monthly basis:
* number of new opened tickets
* number of closed tickets
* number of remaining tickets
If that could be done for all and then also on a per priority basis
(minor, major), then per document basis, ... that would be excellent
of course.
>
> - Automatic reminder
> Should be possible. I'll look into this.
>
That'd be great, thanks.
> - Tickets for item even if there's not yet an ID
> I believe this is already possible -- could
> you expand on this; what do you feel is missing
> to make this possible?
>
Let me check, I might have missed that this was indeed already possible.
Many Thanks.
JP.
> Best,
>
> Henrik
From ietfdbh@comcast.net Tue Aug 17 14:17:54 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A4B3A684B for ; Tue, 17 Aug 2010 14:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.349
X-Spam-Level:
X-Spam-Status: No, score=-101.349 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_05=-1.11, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHNNe411TZSA for ; Tue, 17 Aug 2010 14:17:53 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 26F473A6869 for ; Tue, 17 Aug 2010 14:17:53 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta04.westchester.pa.mail.comcast.net with comcast id vY0E1e0070vyq2s54ZJVhp; Tue, 17 Aug 2010 21:18:29 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta05.westchester.pa.mail.comcast.net with comcast id vZJU1e0032JQnJT3RZJUF4; Tue, 17 Aug 2010 21:18:28 +0000
From: "David Harrington"
To:
Date: Tue, 17 Aug 2010 17:18:29 -0400
Message-ID: <7DC216F999274DC3A5BBDCA945532F7D@23FX1C1>
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.5931
Thread-Index: Acs5agBp3mhtnVZORdKjt9lALbxGCgARdFzwAClKs+A=
Subject: [Tools-discuss] behave docs, example addresses, and idnits
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 17 Aug 2010 21:17:54 -0000
Hi,
Behave docs draw warnings from idnits because they use addresses that
are
not consistent with the approved example addresses for ipv6. This is
becuase
we are defining new special purpose prefixes, and give examples for
the use
of those prefixes:
draft-ietf-behave-dns64-10.txt(353): Found possible IPv6 address
'64:FF9B::' in
position 46 in the paragraph; this doesn't match RFC 3849's
suggested
2001:DB8::
/32 address range or RFC 4193's Unique Local Address range FC00::/7.
And searching draft-ietf-behave-dns64 quickly reveals the first
occurence of the string 64:FF9B is this text:
The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96
reserved
by [I-D.ietf-behave-address-format] for the purpose of
representing IPv4 addresses in IPv6 address space.
This shows an error that will likely be flagged for multiple reaons.
Idnits should be updated to not flag any IPv6 addresses that embed
IPv4 addresses, as long as:
1) the IPv6 prefix is a "well-known" prefix (e.g. 6to4, Teredo,
64:FF9B, etc.) AND
2) the embedded IPv4 address is in the IPv4 documentation range.
Can we get idnits updated?
David Harrington
Area director
IETF Transport Area
From ietfdbh@comcast.net Wed Aug 18 18:20:13 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B773E3A698D for ; Wed, 18 Aug 2010 18:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.094
X-Spam-Level:
X-Spam-Status: No, score=-102.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIz6ePf-FZqf for ; Wed, 18 Aug 2010 18:20:12 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 968EA3A6765 for ; Wed, 18 Aug 2010 18:20:12 -0700 (PDT)
Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id vmdt1e00527AodY5A1Lojw; Thu, 19 Aug 2010 01:20:48 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta19.westchester.pa.mail.comcast.net with comcast id w1Lo1e0012JQnJT3f1Losh; Thu, 19 Aug 2010 01:20:48 +0000
From: "David Harrington"
To:
Date: Wed, 18 Aug 2010 21:20:10 -0400
Message-ID:
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.5931
Thread-Index: Acs/PKpPuEXS21kYQlmogRROQPqryw==
Cc: iesg@ietf.org
Subject: [Tools-discuss] searching for BCPs.
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 19 Aug 2010 01:20:13 -0000
Hi,
http://datatracker.ietf.org/doc/ gives me no options for searching for
BCPs.
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl did allow this.
Can we add BCP and STD and FYI to the advanced search capabilities?
(I find that I often search for BCPs, when I want to see the
recommended way to do something.
I almost never search for STDs or FYIs)
dbh
From richard.barnes@gmail.com Wed Aug 18 18:28:47 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F7B3A69B8; Wed, 18 Aug 2010 18:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hzRZ8Jpvu4l; Wed, 18 Aug 2010 18:28:46 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B9D923A67F0; Wed, 18 Aug 2010 18:28:45 -0700 (PDT)
Received: by bwz9 with SMTP id 9so1319491bwz.31 for ; Wed, 18 Aug 2010 18:29:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=FZzFVYVntEDL7kMVr5DmBuHuhXn14fEwOcTkv1n0OTw=; b=dE5giBFoxCwKBKHVwiNw1dvlVF4CTrcKUtxz3KE3kxobuAGc4tpi2CTa1TCiuIzym+ ASssagaQyVo6pkx640lO3/6xovm/xQFkoM3//P8O4N4HeXFFH3xVXzEy09xzduXf7ePH gSzku6vTUtsPfGY5ECaIC4BGu74GbuZbgDfeM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NwGok6I3hd/rOTyRZYHH1un8qMtiFuT/l/CejXaN77l+0zxluT21KDiAqVX/fTDwqg 1E32G/syOgoWeq+x9b3ovWZjjUQT0Y0YKjXV89CFaiLeXxKs4SLtwA3dBISWc9ZaxvdX u8qQkfsr0GOHMv428OFPyrfpCpQbLjdZjfzR4=
MIME-Version: 1.0
Received: by 10.204.68.206 with SMTP id w14mr5175752bki.132.1282181360127; Wed, 18 Aug 2010 18:29:20 -0700 (PDT)
Received: by 10.204.13.195 with HTTP; Wed, 18 Aug 2010 18:29:19 -0700 (PDT)
Received: by 10.204.13.195 with HTTP; Wed, 18 Aug 2010 18:29:19 -0700 (PDT)
In-Reply-To:
References:
Date: Wed, 18 Aug 2010 21:29:19 -0400
Message-ID:
From: Richard Barnes
To: David Harrington
Content-Type: multipart/alternative; boundary=001636c5addf820d86048e231c0c
Cc: iesg@ietf.org, tools-discuss@ietf.org
Subject: Re: [Tools-discuss] searching for BCPs.
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 19 Aug 2010 01:28:47 -0000
--001636c5addf820d86048e231c0c
Content-Type: text/plain; charset=ISO-8859-1
At least for BCPs, you can use the tools site,e.g.:
As for STDs, wasn't there consensus at the last IETF to get rid of those
numbers? :)
On Aug 18, 2010 9:20 PM, "David Harrington" wrote:
Hi,
http://datatracker.ietf.org/doc/ gives me no options for searching for
BCPs.
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl did allow this.
Can we add BCP and STD and FYI to the advanced search capabilities?
(I find that I often search for BCPs, when I want to see the
recommended way to do something.
I almost never search for STDs or FYIs)
dbh
_______________________________________________
Tools-discuss mailing list
Tools-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss
--001636c5addf820d86048e231c0c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
At least for BCPs, you can use the tools site,e.g.:
<http://tools.IETF.org/html=
/bcp38>
As for STDs, wasn't there consensus at the last IETF to get rid of t=
hose numbers?=A0 :)
On Aug 18, 2010 9:20 PM, "David Harringto=
n" <ietfdbh@comcast.net&=
gt; wrote:
Hi,
http://datat=
racker.ietf.org/doc/ gives me no options for searching for
BCPs.
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl did allow this.
Can we add BCP and STD and FYI to the advanced search capabilities?
(I find that I often search for BCPs, when I want to see the
recommended way to do something.
I almost never search for STDs or FYIs)
dbh
_______________________________________________
Tools-discuss mailing list
Tools-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss
--001636c5addf820d86048e231c0c--
From henrik@levkowetz.com Thu Aug 19 07:43:42 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51553A688B for ; Thu, 19 Aug 2010 07:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOnELne+p5cn for ; Thu, 19 Aug 2010 07:43:37 -0700 (PDT)
Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id BDF8D3A6829 for ; Thu, 19 Aug 2010 07:43:36 -0700 (PDT)
Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:63460 helo=dyn-fg117.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Om6La-0007aE-Dt; Thu, 19 Aug 2010 16:44:03 +0200
Message-ID: <4C6D4331.8050704@levkowetz.com>
Date: Thu, 19 Aug 2010 16:44:01 +0200
From: Henrik Levkowetz
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: David Harrington
References: <7DC216F999274DC3A5BBDCA945532F7D@23FX1C1>
In-Reply-To: <7DC216F999274DC3A5BBDCA945532F7D@23FX1C1>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e
X-SA-Exim-Rcpt-To: ietfdbh@comcast.net, tools-discuss@ietf.org, henrik-sent@levkowetz.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org)
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] behave docs, example addresses, and idnits
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 19 Aug 2010 14:43:43 -0000
Hi David,
On 2010-08-17 23:18 David Harrington said:
> Hi,
>
> Behave docs draw warnings from idnits because they use addresses
> that are not consistent with the approved example addresses for ipv6.
> This is becuase we are defining new special purpose prefixes, and
> give examples for the use of those prefixes:
>
> draft-ietf-behave-dns64-10.txt(353): Found possible IPv6 address
> '64:FF9B::' in position 46 in the paragraph; this doesn't match RFC
> 3849's suggested 2001:DB8:: /32 address range or RFC 4193's Unique
> Local Address range FC00::/7.
>
>
> And searching draft-ietf-behave-dns64 quickly reveals the first
> occurence of the string 64:FF9B is this text:
>
> The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved by
> [I-D.ietf-behave-address-format] for the purpose of representing IPv4
> addresses in IPv6 address space.
>
> This shows an error that will likely be flagged for multiple reaons.
> Idnits should be updated to not flag any IPv6 addresses that embed
> IPv4 addresses, as long as: 1) the IPv6 prefix is a "well-known"
> prefix (e.g. 6to4, Teredo, 64:FF9B, etc.) AND 2) the embedded IPv4
> address is in the IPv4 documentation range.
>
> Can we get idnits updated?
I'm happy to update idnits to do better flagging, but in order to do
so I need to know what to look for. If you'll provide the set of
IPv6 prefixes which should be acceptable with embedded IPv4 documentation
addresses, I'll put it in.
However, I have some reservations I'd still like to mention:
0) The idnits output for the non-RFC3849 addresses already contains a
reservation: "If these are example addresses, they should be changed."
The intention is of course to get the author to actually look at the
document from the viewpoint of using RFC3849 example addresses where
appropriate; there clearly are cases where new prefixes are in the
process of being defined where this message should pop up, but be
seen as not relevant. Maybe the message should be changed from an
error to a warning?
1) I don't see off-hand that this would have improved the case
substantially for draft-ietf-behave-dns64-10.txt; the '64:FF9B::'
address which is flagged by idnits doesn't contain an embedded IPv4
address in 6 of the 10 flagged cases; so the message would still appear
given that idnits had been updated with an 'embedded-IPv4-example-address'
fix, and would still require inspection of the situation.
2) The '64:FF9B::' prefix is still in the process of being standardised;
should we really update idnits with new prefixes before the defining
documents have become RFCs? (Hmm, looking at the tracker status of
the -address-format draft I see it has actually been approved, so this
should be OK...)
Best,
Henrik
From ietfdbh@comcast.net Thu Aug 19 13:15:51 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0513A6A49 for ; Thu, 19 Aug 2010 13:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.101
X-Spam-Level:
X-Spam-Status: No, score=-102.101 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REUY4vDYuoVo for ; Thu, 19 Aug 2010 13:15:49 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id A91943A6A81 for ; Thu, 19 Aug 2010 13:14:56 -0700 (PDT)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta14.westchester.pa.mail.comcast.net with comcast id wBYh1e0031wpRvQ5ELFYVa; Thu, 19 Aug 2010 20:15:32 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta18.westchester.pa.mail.comcast.net with comcast id wLFY1e0042JQnJT3eLFYl2; Thu, 19 Aug 2010 20:15:32 +0000
From: "David Harrington"
To: "'Richard Barnes'"
References:
Date: Thu, 19 Aug 2010 16:15:01 -0400
Message-ID:
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0268_01CB3FB9.AD8BA1A0"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
In-Reply-To:
Thread-Index: Acs/PfNwtV9HDRa8TkGxVg70Xe7pqwAnTNOw
Cc: iesg@ietf.org, tools-discuss@ietf.org
Subject: Re: [Tools-discuss] searching for BCPs.
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 19 Aug 2010 20:15:51 -0000
This is a multi-part message in MIME format.
------=_NextPart_000_0268_01CB3FB9.AD8BA1A0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi,
There was discussion. I don't know if or when that will happen.
dbh
_____
From: Richard Barnes [mailto:richard.barnes@gmail.com]
Sent: Wednesday, August 18, 2010 9:29 PM
To: David Harrington
Cc: iesg@ietf.org; tools-discuss@ietf.org
Subject: Re: [Tools-discuss] searching for BCPs.
At least for BCPs, you can use the tools site,e.g.:
As for STDs, wasn't there consensus at the last IETF to get rid of
those numbers? :)
On Aug 18, 2010 9:20 PM, "David Harrington"
wrote:
Hi,
http://datatracker.ietf.org/doc/ gives me no options for searching for
BCPs.
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl did allow this.
Can we add BCP and STD and FYI to the advanced search capabilities?
(I find that I often search for BCPs, when I want to see the
recommended way to do something.
I almost never search for STDs or FYIs)
dbh
_______________________________________________
Tools-discuss mailing list
Tools-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss
------=_NextPart_000_0268_01CB3FB9.AD8BA1A0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
There was discussion. I don't know if or when that =
will=20
happen.
dbh
At least for BCPs, you can use the tools site,e.g.:
<http://tools.IETF.org/html/bcp3=
8>
As for STDs, wasn't there consensus at the last IETF to get rid of =
those=20
numbers? :)
On Aug 18, 2010 9:20 PM, "David Harrington" =
<ietfdbh@comcast.net>=20
wrote:
Hi,
http://datatracker.ietf.org/doc/ gives me no =
options for=20
searching for
BCPs.
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl =
did allow=20
this.
Can we add BCP and STD and FYI to the advanced search=20
capabilities?
(I find that I often search for BCPs, when I want =
to see=20
the
recommended way to do something.
I almost never search for =
STDs or=20
=
FYIs)
dbh
_______________________________________________Tools-discuss=20
mailing list
Tools-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss
------=_NextPart_000_0268_01CB3FB9.AD8BA1A0--
From spencer@wonderhamster.org Fri Aug 20 04:42:12 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3FC53A6970; Fri, 20 Aug 2010 04:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.267
X-Spam-Level:
X-Spam-Status: No, score=-100.267 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVMVkhPw6Lt5; Fri, 20 Aug 2010 04:42:11 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 86B6E3A68F1; Fri, 20 Aug 2010 04:42:11 -0700 (PDT)
Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lw2ir-1OwdqF0rD3-017dBl; Fri, 20 Aug 2010 07:42:44 -0400
Message-ID: <6ED66842582A4956A1EB5DF21E65D65F@china.huawei.com>
From: "Spencer Dawkins"
To: "David Harrington" , "'Richard Barnes'"
References:
Date: Fri, 20 Aug 2010 06:42:36 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E4_01CB4032.E008B2C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
X-Provags-ID: V02:K0:N+0OYVZzkd32bg6JEiPlR62N6VeC66uIMe6nUmYSYAa WorPlZJgtYT8h83HMbtlbq9NMrzkhBjXCaN++MMshAdVArYLlN +50kkooPmmyTvQ7ZQSasqGfYvdtqF7MCg520Avbpa3+hfXhinT 6MG35ePMF7nTXmwYLsIVewOwJ74zEGb42OyUl/ntAH3v903N+B Om3bLILjzbCOo+AtQdbOmFaQxNBYG79sOQjptTMmv0=
Cc: iesg@ietf.org, tools-discuss@ietf.org
Subject: Re: [Tools-discuss] searching for BCPs.
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 20 Aug 2010 11:42:12 -0000
This is a multi-part message in MIME format.
------=_NextPart_000_02E4_01CB4032.E008B2C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Not speaking as anything except Russ's note-taker for the Wednesday =
night plenary, but "not at the plenary where *I* was taking notes".
What I was hearing in hallway discussions is that STDs that don't get =
assigned until you're at the third level of the current three-level =
maturity set might be worth getting rid of, but if you assign STD =
numbers at the first level (of any maturity set), that's a lot less =
obvious. If we had more protocols that qualified for STD numbers, we =
might very well use them more. So I didn't think they've been voted off =
the island yet.
I'm assuming that FYIs would come along for free, if you had BCPs and =
STDs already, without looking at the code for this. If that's not true, =
the most recent FYI was published in April 2001, which might account for =
the low usage rate by IETF participants who are not also archeologists =
...
Spencer
----- Original Message -----=20
From: David Harrington=20
To: 'Richard Barnes'=20
Cc: iesg@ietf.org ; tools-discuss@ietf.org=20
Sent: Thursday, August 19, 2010 3:15 PM
Subject: Re: [Tools-discuss] searching for BCPs.
Hi,
There was discussion. I don't know if or when that will happen.
dbh
-------------------------------------------------------------------------=
---
From: Richard Barnes [mailto:richard.barnes@gmail.com]=20
Sent: Wednesday, August 18, 2010 9:29 PM
To: David Harrington
Cc: iesg@ietf.org; tools-discuss@ietf.org
Subject: Re: [Tools-discuss] searching for BCPs.
As for STDs, wasn't there consensus at the last IETF to get rid of =
those numbers? :)
------=_NextPart_000_02E4_01CB4032.E008B2C0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Not speaking as anything except Russ's note-taker =
for the=20
Wednesday night plenary, but "not at the plenary where *I* was taking=20
notes".
What I was hearing in hallway discussions is that =
STDs that=20
don't get assigned until you're at the third level of the current =
three-level=20
maturity set might be worth getting rid of, but if you assign STD =
numbers at the=20
first level (of any maturity set), that's a lot less obvious. If we had =
more=20
protocols that qualified for STD numbers, we might very well use them =
more. So I=20
didn't think they've been voted off the island yet.
I'm assuming that FYIs would come along for free, if =
you had=20
BCPs and STDs already, without looking at the code for this. If that's =
not true,=20
the most recent FYI was published in April 2001, which might account for =
the low=20
usage rate by IETF participants who are not also archeologists =
...
Spencer
----- Original Message -----
Sent: Thursday, August 19, 2010 =
3:15=20
PM
Subject: Re: [Tools-discuss] =
searching=20
for BCPs.
Hi,
There was discussion. I don't know if or when =
that will=20
happen.
dbh
As for STDs, wasn't there consensus at the last IETF to get rid =
of those=20
numbers? :)
------=_NextPart_000_02E4_01CB4032.E008B2C0--
From dwing@cisco.com Fri Aug 20 12:50:59 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1813A697F for ; Fri, 20 Aug 2010 12:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.507
X-Spam-Level:
X-Spam-Status: No, score=-110.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XulhD5fb7ZJM for ; Fri, 20 Aug 2010 12:50:58 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 63FE73A688F for ; Fri, 20 Aug 2010 12:50:58 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAL55bkyrR7H+/2dsb2JhbACUSotzcaBim1yFNwSENDM
X-IronPort-AV: E=Sophos;i="4.56,241,1280707200"; d="scan'208";a="273819414"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2010 19:51:31 +0000
Received: from dwingWS (sjc-vpn3-708.cisco.com [10.21.66.196]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7KJpUWY000760; Fri, 20 Aug 2010 19:51:30 GMT
From: "Dan Wing"
To: "'Henrik Levkowetz'" , "'David Harrington'"
References: <7DC216F999274DC3A5BBDCA945532F7D@23FX1C1> <4C6D4331.8050704@levkowetz.com>
In-Reply-To: <4C6D4331.8050704@levkowetz.com>
Date: Fri, 20 Aug 2010 12:51:30 -0700
Message-ID: <139701cb40a1$15b31000$41193000$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acs/rQ2VO0YRK7VmR7eAinmtraXNXgA7/ISg
Content-Language: en-us
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] behave docs, example addresses, and idnits
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 20 Aug 2010 19:50:59 -0000
> -----Original Message-----
> From: tools-discuss-bounces@ietf.org [mailto:tools-discuss-
> bounces@ietf.org] On Behalf Of Henrik Levkowetz
> Sent: Thursday, August 19, 2010 7:44 AM
> To: David Harrington
> Cc: tools-discuss@ietf.org
> Subject: Re: [Tools-discuss] behave docs, example addresses, and idnits
>
> Hi David,
>
> On 2010-08-17 23:18 David Harrington said:
> > Hi,
> >
> > Behave docs draw warnings from idnits because they use addresses
> > that are not consistent with the approved example addresses for ipv6.
> > This is becuase we are defining new special purpose prefixes, and
> > give examples for the use of those prefixes:
> >
> > draft-ietf-behave-dns64-10.txt(353): Found possible IPv6 address
> > '64:FF9B::' in position 46 in the paragraph; this doesn't match RFC
> > 3849's suggested 2001:DB8:: /32 address range or RFC 4193's Unique
> > Local Address range FC00::/7.
> >
> >
> > And searching draft-ietf-behave-dns64 quickly reveals the first
> > occurence of the string 64:FF9B is this text:
> >
> > The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved by
> > [I-D.ietf-behave-address-format] for the purpose of representing IPv4
> > addresses in IPv6 address space.
> >
> > This shows an error that will likely be flagged for multiple reaons.
> > Idnits should be updated to not flag any IPv6 addresses that embed
> > IPv4 addresses, as long as: 1) the IPv6 prefix is a "well-known"
> > prefix (e.g. 6to4, Teredo, 64:FF9B, etc.) AND 2) the embedded IPv4
> > address is in the IPv4 documentation range.
> >
> > Can we get idnits updated?
>
> I'm happy to update idnits to do better flagging, but in order to do
> so I need to know what to look for. If you'll provide the set of
> IPv6 prefixes which should be acceptable with embedded IPv4
> documentation
> addresses, I'll put it in.
To accommodate the well-known prefix defined in
draft-ietf-behave-address-format, we would want to allow an IPv6 address
starting with 64:FF9B, with anything in the middle, and an RFC3330
documentation address at the end in decimal or hex. So all of these should
pass:
64:ff9b:1::192.0.2.0
64:ff9b:1:2:3::192.0.2.0
64:ff9b:1::0c00:0200 < 192.0.2.0 in hex
64:ff9b:1:2:3::0c00:0200
To accomodate the network-specific prefix defined in
draft-ietf-behave-address-format, the existing support in idnits for the
IPv6 documentation prefix (2001:db8) should be extended to allow an RFC3330
IPv4 dotted decimal address in the last 32 bits, such as:
2001:db8:1::192.0.2.0
We could argue that such an address shouldn't appear in an I-D due to rules
of draft-ietf-6man-text-addr-representation, but the rules of
draft-ietf-6man-text-addr-representation seem to apply to equipment, while
an I-D is trying to explain a technology. This seems worthwhile to discuss
before making a change to idnits. I haven't been closely involved with
draft-ietf-6man-text-addr-representation.
By the way, draft-ietf-6man-text-addr-representation is now an "RFC-to-Be",
so changing idnits to require lowercase IPv6 example addresses might be a
worthy thing to consider at the same time.
> However, I have some reservations I'd still like to mention:
>
> 0) The idnits output for the non-RFC3849 addresses already contains a
> reservation: "If these are example addresses, they should be changed."
> The intention is of course to get the author to actually look at the
> document from the viewpoint of using RFC3849 example addresses where
> appropriate; there clearly are cases where new prefixes are in the
> process of being defined where this message should pop up, but be
> seen as not relevant. Maybe the message should be changed from an
> error to a warning?
During IESG review of our documents, it seems many IESG members
run IDNITS. I don't know why, considering their time is valuable and
considering that PROTO already requires the shepherd run idnits
(1.g of RFC4858).
Many just seemed to see the output of idnits and ask authors and
chairs "has this been checked". This resulted in wasted time
with all parties.
I don't know how to best fix that, but perhaps changing the warning
that says:
** There are 10 instances of lines with non-RFC3849-compliant IPv6
addresses
in the document. If these are example addresses, they should be
changed.
to add "use verbose mode (--verbose) to see these instances" might encourage
further analysis by whoever is running idnits.
> 1) I don't see off-hand that this would have improved the case
> substantially for draft-ietf-behave-dns64-10.txt; the '64:FF9B::'
> address which is flagged by idnits doesn't contain an embedded IPv4
> address in 6 of the 10 flagged cases; so the message would still appear
> given that idnits had been updated with an 'embedded-IPv4-example-
> address'
> fix, and would still require inspection of the situation.
Agreed that this change to idnits would not help that particular
document at all.
> 2) The '64:FF9B::' prefix is still in the process of being
> standardised;
> should we really update idnits with new prefixes before the defining
> documents have become RFCs? (Hmm, looking at the tracker status of
> the -address-format draft I see it has actually been approved, so this
> should be OK...)
Right.
-d
>
>
> Best,
>
> Henrik
> _______________________________________________
> Tools-discuss mailing list
> Tools-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
From ietfdbh@comcast.net Mon Aug 23 16:53:16 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A853A68A0 for ; Mon, 23 Aug 2010 16:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.109
X-Spam-Level:
X-Spam-Status: No, score=-102.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyBYx3fNyvAI for ; Mon, 23 Aug 2010 16:53:15 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 7F0A13A686B for ; Mon, 23 Aug 2010 16:53:15 -0700 (PDT)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA11.westchester.pa.mail.comcast.net with comcast id xyZn1e00317dt5G5BztpFk; Mon, 23 Aug 2010 23:53:49 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta13.westchester.pa.mail.comcast.net with comcast id xztn1e0032JQnJT3ZztnuU; Mon, 23 Aug 2010 23:53:49 +0000
From: "David Harrington"
To: "'Henrik Levkowetz'"
References: <7DC216F999274DC3A5BBDCA945532F7D@23FX1C1> <4C6D4331.8050704@levkowetz.com>
Date: Mon, 23 Aug 2010 19:53:20 -0400
Message-ID:
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.5931
In-Reply-To: <4C6D4331.8050704@levkowetz.com>
Thread-Index: Acs/rP6vquCGEuoATaOE5SwZk4Bg2ADcDYIQ
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] behave docs, example addresses, and idnits
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 23 Aug 2010 23:53:17 -0000
Hi,
The IESG is guilty of ignoring the warning part of the error: "If
these are example addresses, they should be changed."
It MIGHT help to change this to a warning rather than an error, but it
appears IESG education is really what is required. sigh. My job, not
yours ;-)
I don't know that adding the prefixes to the tool would be that
helpful, and your time might be better spent on other features. If
it's convenient for you to chnage idnits to watch for these prefixes,
and check for embedded IPv4 examplke addresses, then it might help
some.
As Dan Wing pointed out in his email providing the known prefixes,
another check might be to flag uppercase hex use in addresses (not
that this really matters in the real world ;-)
dbh
> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> Sent: Thursday, August 19, 2010 10:44 AM
> To: David Harrington
> Cc: tools-discuss@ietf.org
> Subject: Re: [Tools-discuss] behave docs, example addresses,
> and idnits
>
> Hi David,
>
> On 2010-08-17 23:18 David Harrington said:
> > Hi,
> >
> > Behave docs draw warnings from idnits because they use
> addresses that
> > are not consistent with the approved example addresses for ipv6.
> > This is becuase we are defining new special purpose
> prefixes, and give
> > examples for the use of those prefixes:
> >
> > draft-ietf-behave-dns64-10.txt(353): Found possible IPv6 address
> > '64:FF9B::' in position 46 in the paragraph; this doesn't match
RFC
> > 3849's suggested 2001:DB8:: /32 address range or RFC 4193's Unique
> > Local Address range FC00::/7.
> >
> >
> > And searching draft-ietf-behave-dns64 quickly reveals the first
> > occurence of the string 64:FF9B is this text:
> >
> > The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96
> reserved by
> > [I-D.ietf-behave-address-format] for the purpose of
> representing IPv4
> > addresses in IPv6 address space.
> >
> > This shows an error that will likely be flagged for
> multiple reaons.
> > Idnits should be updated to not flag any IPv6 addresses that embed
> > IPv4 addresses, as long as: 1) the IPv6 prefix is a "well-known"
> > prefix (e.g. 6to4, Teredo, 64:FF9B, etc.) AND 2) the embedded IPv4
> > address is in the IPv4 documentation range.
> >
> > Can we get idnits updated?
>
> I'm happy to update idnits to do better flagging, but in
> order to do so I need to know what to look for. If you'll
> provide the set of
> IPv6 prefixes which should be acceptable with embedded IPv4
> documentation addresses, I'll put it in.
>
> However, I have some reservations I'd still like to mention:
>
> 0) The idnits output for the non-RFC3849 addresses already contains
a
> reservation: "If these are example addresses, they should be
changed."
> The intention is of course to get the author to actually look
> at the document from the viewpoint of using RFC3849 example
> addresses where appropriate; there clearly are cases where
> new prefixes are in the process of being defined where this
> message should pop up, but be seen as not relevant. Maybe
> the message should be changed from an error to a warning?
>
> 1) I don't see off-hand that this would have improved the
> case substantially for draft-ietf-behave-dns64-10.txt; the
'64:FF9B::'
> address which is flagged by idnits doesn't contain an
> embedded IPv4 address in 6 of the 10 flagged cases; so the
> message would still appear given that idnits had been updated
> with an 'embedded-IPv4-example-address'
> fix, and would still require inspection of the situation.
>
> 2) The '64:FF9B::' prefix is still in the process of being
> standardised; should we really update idnits with new
> prefixes before the defining documents have become RFCs?
> (Hmm, looking at the tracker status of the -address-format
> draft I see it has actually been approved, so this should be OK...)
>
>
> Best,
>
> Henrik
>
From henrik@levkowetz.com Tue Aug 24 05:01:12 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F1B3A67C0 for ; Tue, 24 Aug 2010 05:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl+GMK0H3-sy for ; Tue, 24 Aug 2010 05:01:11 -0700 (PDT)
Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id 161943A672E for ; Tue, 24 Aug 2010 05:01:11 -0700 (PDT)
Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:55294 helo=dyn-fg117.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1OnsC5-000623-W4; Tue, 24 Aug 2010 14:01:34 +0200
Message-ID: <4C73B49D.3090706@levkowetz.com>
Date: Tue, 24 Aug 2010 14:01:33 +0200
From: Henrik Levkowetz
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: David Harrington
References: <7DC216F999274DC3A5BBDCA945532F7D@23FX1C1> <4C6D4331.8050704@levkowetz.com>
In-Reply-To:
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e
X-SA-Exim-Rcpt-To: ietfdbh@comcast.net, tools-discuss@ietf.org, henrik-sent@levkowetz.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org)
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] behave docs, example addresses, and idnits
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 24 Aug 2010 12:01:12 -0000
Hi David,
Ok, given what you write below, my plan is this:
1) Change idnits to emit a warning instead of an error for this,
and add a note about using --verbose mode to see the instances.
This can be done at once.
2) Add RFC5952 compliance checks for IPv6 addresses. There are a
number of checks to perform, so coding this is no 5-minute fix.
To be done when time permits.
3) Add recognition of IPv6-address-with-embedded-IPv4-example-address
to the example address warning code, to avoid warnings for these.
To be done after 2) if time permits; low priority.
Works?
Best,
Henrik
On 2010-08-24 01:53 David Harrington said:
> Hi,
>
> The IESG is guilty of ignoring the warning part of the error: "If
> these are example addresses, they should be changed."
>
> It MIGHT help to change this to a warning rather than an error, but it
> appears IESG education is really what is required. sigh. My job, not
> yours ;-)
>
> I don't know that adding the prefixes to the tool would be that
> helpful, and your time might be better spent on other features. If
> it's convenient for you to chnage idnits to watch for these prefixes,
> and check for embedded IPv4 examplke addresses, then it might help
> some.
>
> As Dan Wing pointed out in his email providing the known prefixes,
> another check might be to flag uppercase hex use in addresses (not
> that this really matters in the real world ;-)
>
> dbh
>
>> -----Original Message-----
>> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
>> Sent: Thursday, August 19, 2010 10:44 AM
>> To: David Harrington
>> Cc: tools-discuss@ietf.org
>> Subject: Re: [Tools-discuss] behave docs, example addresses,
>> and idnits
>>
>> Hi David,
>>
>> On 2010-08-17 23:18 David Harrington said:
>>> Hi,
>>>
>>> Behave docs draw warnings from idnits because they use
>> addresses that
>>> are not consistent with the approved example addresses for ipv6.
>>> This is becuase we are defining new special purpose
>> prefixes, and give
>>> examples for the use of those prefixes:
>>>
>>> draft-ietf-behave-dns64-10.txt(353): Found possible IPv6 address
>>> '64:FF9B::' in position 46 in the paragraph; this doesn't match
> RFC
>>> 3849's suggested 2001:DB8:: /32 address range or RFC 4193's Unique
>
>>> Local Address range FC00::/7.
>>>
>>>
>>> And searching draft-ietf-behave-dns64 quickly reveals the first
>>> occurence of the string 64:FF9B is this text:
>>>
>>> The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96
>> reserved by
>>> [I-D.ietf-behave-address-format] for the purpose of
>> representing IPv4
>>> addresses in IPv6 address space.
>>>
>>> This shows an error that will likely be flagged for
>> multiple reaons.
>>> Idnits should be updated to not flag any IPv6 addresses that embed
>>> IPv4 addresses, as long as: 1) the IPv6 prefix is a "well-known"
>>> prefix (e.g. 6to4, Teredo, 64:FF9B, etc.) AND 2) the embedded IPv4
>
>>> address is in the IPv4 documentation range.
>>>
>>> Can we get idnits updated?
>>
>> I'm happy to update idnits to do better flagging, but in
>> order to do so I need to know what to look for. If you'll
>> provide the set of
>> IPv6 prefixes which should be acceptable with embedded IPv4
>> documentation addresses, I'll put it in.
>>
>> However, I have some reservations I'd still like to mention:
>>
>> 0) The idnits output for the non-RFC3849 addresses already contains
> a
>> reservation: "If these are example addresses, they should be
> changed."
>> The intention is of course to get the author to actually look
>> at the document from the viewpoint of using RFC3849 example
>> addresses where appropriate; there clearly are cases where
>> new prefixes are in the process of being defined where this
>> message should pop up, but be seen as not relevant. Maybe
>> the message should be changed from an error to a warning?
>>
>> 1) I don't see off-hand that this would have improved the
>> case substantially for draft-ietf-behave-dns64-10.txt; the
> '64:FF9B::'
>> address which is flagged by idnits doesn't contain an
>> embedded IPv4 address in 6 of the 10 flagged cases; so the
>> message would still appear given that idnits had been updated
>> with an 'embedded-IPv4-example-address'
>> fix, and would still require inspection of the situation.
>>
>> 2) The '64:FF9B::' prefix is still in the process of being
>> standardised; should we really update idnits with new
>> prefixes before the defining documents have become RFCs?
>> (Hmm, looking at the tracker status of the -address-format
>> draft I see it has actually been approved, so this should be OK...)
>>
>>
>> Best,
>>
>> Henrik
>>
>
>
From ietfdbh@comcast.net Wed Aug 25 16:05:42 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0033A68E0 for ; Wed, 25 Aug 2010 16:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.151
X-Spam-Level:
X-Spam-Status: No, score=-102.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyKhJ0YR5Vpc for ; Wed, 25 Aug 2010 16:05:41 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 49FD83A689B for ; Wed, 25 Aug 2010 16:05:41 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id ybP71e0020QuhwU5Dn6EpV; Wed, 25 Aug 2010 23:06:14 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta02.westchester.pa.mail.comcast.net with comcast id yn6E1e0042JQnJT3Nn6ErU; Wed, 25 Aug 2010 23:06:14 +0000
From: "David Harrington"
To: "'Henrik Levkowetz'"
References: <7DC216F999274DC3A5BBDCA945532F7D@23FX1C1> <4C6D4331.8050704@levkowetz.com> <4C73B49D.3090706@levkowetz.com>
Date: Wed, 25 Aug 2010 19:05:29 -0400
Message-ID:
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.5931
In-Reply-To: <4C73B49D.3090706@levkowetz.com>
Thread-Index: ActDhCEVslPF6sp6QTaiX7LvxUXwzwBJdwCQ
Cc: tools-discuss@ietf.org
Subject: Re: [Tools-discuss] behave docs, example addresses, and idnits
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 25 Aug 2010 23:05:42 -0000
WFM
dbh
> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> Sent: Tuesday, August 24, 2010 8:02 AM
> To: David Harrington
> Cc: tools-discuss@ietf.org
> Subject: Re: [Tools-discuss] behave docs, example addresses,
> and idnits
>
> Hi David,
>
> Ok, given what you write below, my plan is this:
>
> 1) Change idnits to emit a warning instead of an error for this,
> and add a note about using --verbose mode to see the instances.
> This can be done at once.
>
> 2) Add RFC5952 compliance checks for IPv6 addresses. There are a
> number of checks to perform, so coding this is no 5-minute fix.
> To be done when time permits.
>
> 3) Add recognition of
IPv6-address-with-embedded-IPv4-example-address
> to the example address warning code, to avoid warnings for
these.
> To be done after 2) if time permits; low priority.
>
> Works?
>
>
> Best,
>
> Henrik
>
>
> On 2010-08-24 01:53 David Harrington said:
> > Hi,
> >
> > The IESG is guilty of ignoring the warning part of the error: "If
> > these are example addresses, they should be changed."
> >
> > It MIGHT help to change this to a warning rather than an
> error, but it
> > appears IESG education is really what is required. sigh. My
> job, not
> > yours ;-)
> >
> > I don't know that adding the prefixes to the tool would be that
> > helpful, and your time might be better spent on other features. If
> > it's convenient for you to chnage idnits to watch for these
> prefixes,
> > and check for embedded IPv4 examplke addresses, then it might help
> > some.
> >
> > As Dan Wing pointed out in his email providing the known prefixes,
> > another check might be to flag uppercase hex use in addresses (not
> > that this really matters in the real world ;-)
> >
> > dbh
> >
> >> -----Original Message-----
> >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> >> Sent: Thursday, August 19, 2010 10:44 AM
> >> To: David Harrington
> >> Cc: tools-discuss@ietf.org
> >> Subject: Re: [Tools-discuss] behave docs, example addresses, and
> >> idnits
> >>
> >> Hi David,
> >>
> >> On 2010-08-17 23:18 David Harrington said:
> >>> Hi,
> >>>
> >>> Behave docs draw warnings from idnits because they use
> >> addresses that
> >>> are not consistent with the approved example addresses for ipv6.
> >>> This is becuase we are defining new special purpose
> >> prefixes, and give
> >>> examples for the use of those prefixes:
> >>>
> >>> draft-ietf-behave-dns64-10.txt(353): Found possible IPv6 address
> >>> '64:FF9B::' in position 46 in the paragraph; this doesn't match
> > RFC
> >>> 3849's suggested 2001:DB8:: /32 address range or RFC 4193's
Unique
> >
> >>> Local Address range FC00::/7.
> >>>
> >>>
> >>> And searching draft-ietf-behave-dns64 quickly reveals the first
> >>> occurence of the string 64:FF9B is this text:
> >>>
> >>> The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96
> >> reserved by
> >>> [I-D.ietf-behave-address-format] for the purpose of
> >> representing IPv4
> >>> addresses in IPv6 address space.
> >>>
> >>> This shows an error that will likely be flagged for
> >> multiple reaons.
> >>> Idnits should be updated to not flag any IPv6 addresses that
embed
> >>> IPv4 addresses, as long as: 1) the IPv6 prefix is a "well-known"
> >>> prefix (e.g. 6to4, Teredo, 64:FF9B, etc.) AND 2) the embedded
IPv4
> >
> >>> address is in the IPv4 documentation range.
> >>>
> >>> Can we get idnits updated?
> >>
> >> I'm happy to update idnits to do better flagging, but in
> order to do
> >> so I need to know what to look for. If you'll provide the set of
> >> IPv6 prefixes which should be acceptable with embedded IPv4
> >> documentation addresses, I'll put it in.
> >>
> >> However, I have some reservations I'd still like to mention:
> >>
> >> 0) The idnits output for the non-RFC3849 addresses already
contains
> > a
> >> reservation: "If these are example addresses, they should be
> > changed."
> >> The intention is of course to get the author to actually
> look at the
> >> document from the viewpoint of using RFC3849 example
> addresses where
> >> appropriate; there clearly are cases where new prefixes are in
the
> >> process of being defined where this message should pop up, but be
> >> seen as not relevant. Maybe the message should be changed from
an
> >> error to a warning?
> >>
> >> 1) I don't see off-hand that this would have improved the case
> >> substantially for draft-ietf-behave-dns64-10.txt; the
> > '64:FF9B::'
> >> address which is flagged by idnits doesn't contain an
> embedded IPv4
> >> address in 6 of the 10 flagged cases; so the message would still
> >> appear given that idnits had been updated with an
> >> 'embedded-IPv4-example-address'
> >> fix, and would still require inspection of the situation.
> >>
> >> 2) The '64:FF9B::' prefix is still in the process of being
> >> standardised; should we really update idnits with new
> prefixes before
> >> the defining documents have become RFCs?
> >> (Hmm, looking at the tracker status of the -address-format draft
I
> >> see it has actually been approved, so this should be OK...)
> >>
> >>
> >> Best,
> >>
> >> Henrik
> >>
> >
> >
>
From fred@cisco.com Fri Aug 27 16:19:03 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DADF93A697B for ; Fri, 27 Aug 2010 16:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.083
X-Spam-Level:
X-Spam-Status: No, score=-110.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEG+8Mrlfoiz for ; Fri, 27 Aug 2010 16:19:03 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 292913A68EF for ; Fri, 27 Aug 2010 16:19:03 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAM3kd0yrR7H+/2dsb2JhbACgXnGhKptPhTcEhDuFTg
X-IronPort-AV: E=Sophos;i="4.56,280,1280707200"; d="scan'208";a="579878179"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 27 Aug 2010 23:19:35 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7RNJRnO017188; Fri, 27 Aug 2010 23:19:28 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Fri, 27 Aug 2010 16:19:35 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Fri, 27 Aug 2010 16:19:35 -0700
From: Fred Baker
Date: Fri, 27 Aug 2010 16:19:20 -0700
Message-Id:
To: Henrik Levkowetz
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: IETF TOOLS discussion
Subject: [Tools-discuss] Working Group Drafts
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 27 Aug 2010 23:19:04 -0000
One thing that has me scratching my head. With the older datatracker, =
folks used to get a list of drafts that were either working group drafts =
or individual submissions to working groups sorted by status. Now, they =
get a list of the active drafts, but they are not sorted in any way. Is =
there something I need to do to get the list sorted so that I can =
readily see "these are in state <>"?=
From henrik@levkowetz.com Mon Aug 30 07:46:10 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED1C3A69D3 for ; Mon, 30 Aug 2010 07:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adTG4gGXZMkn for ; Mon, 30 Aug 2010 07:46:09 -0700 (PDT)
Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by core3.amsl.com (Postfix) with ESMTP id 12F483A69CB for ; Mon, 30 Aug 2010 07:46:06 -0700 (PDT)
Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:52760 helo=dyn-fg117.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Oq5cx-0002cG-A8; Mon, 30 Aug 2010 16:46:29 +0200
Message-ID: <4C7BC442.2030007@levkowetz.com>
Date: Mon, 30 Aug 2010 16:46:26 +0200
From: Henrik Levkowetz
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: Fred Baker
References:
In-Reply-To:
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e
X-SA-Exim-Rcpt-To: fred@cisco.com, tools-discuss@ietf.org, henrik-sent@levkowetz.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000)
X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org)
Cc: IETF TOOLS discussion
Subject: Re: [Tools-discuss] Working Group Drafts
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 30 Aug 2010 14:46:10 -0000
Hi Fred,
On 2010-08-28 01:19 Fred Baker said:
> One thing that has me scratching my head. With the older datatracker,
> folks used to get a list of drafts that were either working group
> drafts or individual submissions to working groups sorted by status.
> Now, they get a list of the active drafts, but they are not sorted in
> any way. Is there something I need to do to get the list sorted so
> that I can readily see "these are in state <>"?
I'm not sure which URLs you're referring to here.
Previously, the only pages which had WG drafts and related individual
drafts were the tools status pages, for instance
http://tools.ietf.org/wg/v6ops/
Recently we've added display of WG status and related drafts to the
official datatracker, as in
http://datatracker.ietf.org/wg/v6ops/
If these are the URLs you're thinking of in your message above, the
answer is that the latter (the wg documents page on the official
datatracker) hasn't received as much TLC yet as the tools pages have,
so the grouping / sorting is still missing.
Best,
Henrik
From ahagens@amsl.com Mon Aug 30 09:35:57 2010
Return-Path:
X-Original-To: tools-discuss@core3.amsl.com
Delivered-To: tools-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E73F3A68B3; Mon, 30 Aug 2010 09:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLxP6y1CXOcP; Mon, 30 Aug 2010 09:35:55 -0700 (PDT)
Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id EB88D3A68B8; Mon, 30 Aug 2010 09:35:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 262E9E08AD; Mon, 30 Aug 2010 09:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoVQwP2XZ6+g; Mon, 30 Aug 2010 09:36:26 -0700 (PDT)
Received: from rfc2.home (pool-173-73-54-24.washdc.fios.verizon.net [173.73.54.24]) by c1a.amsl.com (Postfix) with ESMTPSA id 8C94DE0892; Mon, 30 Aug 2010 09:36:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Alice Hagens
In-Reply-To:
Date: Mon, 30 Aug 2010 12:36:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CC8C79D-D844-48C1-BE9C-BCB5BD511275@amsl.com>
References:
To: David Harrington
X-Mailer: Apple Mail (2.1081)
Cc: iesg@ietf.org, Tools Team Discussion , RFC Editor
Subject: Re: [Tools-discuss] searching for BCPs.
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Tools Discussion
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 30 Aug 2010 16:35:57 -0000
David,
You wrote:
> http://www.rfc-editor.org/cgi-bin/rfcsearch.pl did allow this.
The RFC Editor search engine (http://www.rfc-editor.org/rfcsearch.html =
a.k.a. http://www.rfc-editor.org/cgi-bin/rfcsearch.pl) does allow this.=20=
The default is to search all RFCs (including the sub-series STDs, BCPs, =
and FYIs). In addition to searching by document number (e.g., BCP 9), =
you can search by title, keyword, and author name. Also, you can limit =
the search to a sub-series by selecting a button on the right.
Please let us know if a specific search of BCPs on =
http://www.rfc-editor.org/rfcsearch.html wasn't yielding the expected =
results.
Thank you.
RFC Editor/ah
On Aug 18, 2010, at 9:20 PM, David Harrington wrote:
> Hi,
>=20
> http://datatracker.ietf.org/doc/ gives me no options for searching for
> BCPs.
> http://www.rfc-editor.org/cgi-bin/rfcsearch.pl did allow this.
>=20
> Can we add BCP and STD and FYI to the advanced search capabilities?
> (I find that I often search for BCPs, when I want to see the
> recommended way to do something.
> I almost never search for STDs or FYIs)
>=20
> dbh
>=20
> _______________________________________________
> Tools-discuss mailing list
> Tools-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
>=20