Re: [v6ops] Working Group Administrivia

Sheng Jiang <jiangsheng@huawei.com> Mon, 08 December 2014 02:18 UTC

Return-Path: <jiangsheng@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016621A1B49 for <v6ops@ietfa.amsl.com>; Sun, 7 Dec 2014 18:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM5MriWQqs5H for <v6ops@ietfa.amsl.com>; Sun, 7 Dec 2014 18:18:21 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B711A1B40 for <v6ops@ietf.org>; Sun, 7 Dec 2014 18:18:19 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMO61018; Mon, 08 Dec 2014 02:18:18 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 8 Dec 2014 02:18:17 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 8 Dec 2014 10:18:11 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: "t.petch" <ietfc@btconnect.com>, "Fred Baker (fred)" <fred@cisco.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Working Group Administrivia
Thread-Index: AQHQELfApl0OmdTiikqs9ZO27DRlMpyD67olgAEAGMA=
Date: Mon, 08 Dec 2014 02:18:11 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AFDB427@nkgeml512-mbx.china.huawei.com>
References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <010701d01204$b8e18160$4001a8c0@gateway.2wire.net>
In-Reply-To: <010701d01204$b8e18160$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yNOy0TBHF9JBKxjObsgPM47u1IA
Subject: Re: [v6ops] Working Group Administrivia
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Dec 2014 02:18:23 -0000

>As Brian says in his note,
>
>2014-10-27           draft-ietf-v6ops-dhcpv6-slaac-problem
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/
>
>addresses a known problem and I think it would be remiss of the IETF not
>to have this documented

Fully agreed. My read from the latest meeting response is the problem should be document and know by operators and implementors. The controversial part is not this draft, but the follow up of this draft:

1) The solution (protocol level) is not belong to v6ops WG. 

2) The real debate is Whether v6ops should produce an operational guidelines for operators to avoid this issue. Personally, I think it is helpful and belong to this WG, but it seems the WG does not reach consensus on this.

Best regards,

Sheng

>Tom Petch
>
>
>----- Original Message -----
>From: "Fred Baker (fred)" <fred@cisco.com>
>To: <v6ops@ietf.org>
>Sent: Friday, December 05, 2014 6:17 PM
>Subject: [v6ops] Working Group Administrivia
>
>
>Joel, Lee, and I spoke this morning about the status of the working
>group and various drafts in it. I’d like to gauge working group
>consensus on the status of a number of working group drafts that have
>either expired or otherwise should no longer be considered working group
>drafts. Your opinions, pro or con (such as “I’m fine with all that but
>think we should still be considering draft-whatever”), please:
>
>We think that the following can be safely set aside, by having the
>secretariat record (and show in the data tracker) that they are no
>longer working group drafts. They have expired, and are not currently
>being pursued:
>
>2003-01-13                     draft-ietf-v6ops-ipv4survey
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey/
>2003-02-14                 draft-ietf-v6ops-ipv4survey-gen
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey-gen/
>2004-07-20                  draft-ietf-v6ops-v6onbydefault
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6onbydefault/
>2007-02-27             draft-ietf-v6ops-routing-guidelines
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-routing-guidelines/
>2007-03-28              draft-ietf-v6ops-campus-transition
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-campus-transition/
>2008-05-13         draft-ietf-v6ops-nat64-pb-statement-req
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-pb-statement-req/
>2011-07-26             draft-ietf-v6ops-v4v6tran-framework
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/
>2013-08-14                draft-ietf-v6ops-monitor-ds-ipv6
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-monitor-ds-ipv6/
>
>We think that draft-ietf-v6ops-balanced-ipv6-security, in its current
>state, is a deployment report, primarily from Swisscom. While the
>working group expressed interest in guidance on firewall configuration,
>this isn’t it. We think it should no longer be a working group draft,
>and invite the authors to submit it to the independent stream as a
>deployment report (<rfc-ise@rfc-editor.org).
>
>2013-12-06         draft-ietf-v6ops-balanced-ipv6-security
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security/
>
>Although the working group expressed interest in the following and the
>authors have been working hard on them, we think the working group is no
>longer interested in these, and so they should be returned to the
>authors and not recorded or treated as working group drafts.
>
>2014-09-18                 draft-ietf-v6ops-design-choices
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/
>2014-10-27           draft-ietf-v6ops-dhcpv6-slaac-problem
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/
>2014-10-27      draft-ietf-v6ops-ula-usage-recommendations
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendatio
>ns/
>
>Speaking for myself, if I have any question of the above, it is on only
>one of these.
>
>If any draft has its "WG Draft" status revoked, it will still be
>available from the IETF website as far as I know, but subsequent
>revisions should be named as individual submissions to a working group,
>draft-<author>-<wg>-<subject> or individual submissions to the IETF,
>draft-<author>-<subject>. It would be good if the authors would send a
>note to internet-drafts@ietf.org indicating that the old draft name were
>replaced by the new draft name, so that the revision history is tracked
>appropriately.
>
>Opinions?
>
>
>
>
>------------------------------------------------------------------------
>--------
>
>
>>
>>
>
>
>------------------------------------------------------------------------
>--------
>
>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops