Re: [v6ops] Working Group Administrivia

t.petch <ietfc@btconnect.com> Wed, 10 December 2014 17:58 UTC

Return-Path: <ietfc@btconnect.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 A961A1A00BD for <v6ops@ietfa.amsl.com>; Wed, 10 Dec 2014 09:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] 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 yKj4UsdMdgaH for <v6ops@ietfa.amsl.com>; Wed, 10 Dec 2014 09:58:18 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::722]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8AF1A1B12 for <v6ops@ietf.org>; Wed, 10 Dec 2014 09:58:18 -0800 (PST)
Received: from pc6 (81.151.166.145) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 17:39:42 +0000
Message-ID: <05aa01d014a0$43c5be20$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Sheng Jiang <jiangsheng@huawei.com>, "Fred Baker (fred)" <fred@cisco.com>, v6ops@ietf.org
References: <08DA982D-6605-434B-B815-C69B8A97FA4C@cisco.com> <010701d01204$b8e18160$4001a8c0@gateway.2wire.net> <5D36713D8A4E7348A7E10DF7437A4B923AFDB427@nkgeml512-mbx.china.huawei.com>
Date: Wed, 10 Dec 2014 17:39:29 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.166.145]
X-ClientProxiedBy: DB3PR05CA0052.eurprd05.prod.outlook.com (25.160.41.180) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149)
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055;
X-Forefront-PRVS: 0421BF7135
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377424004)(199003)(377454003)(189002)(40100003)(20776003)(64706001)(47776003)(68736005)(81816999)(120916001)(62236002)(99396003)(44716002)(97736003)(50226001)(4396001)(122386002)(66066001)(31966008)(46102003)(50466002)(1720100001)(50986999)(15975445007)(1456003)(81686999)(84392001)(76176999)(23676002)(77096005)(61296003)(19580405001)(21056001)(14496001)(1556002)(42186005)(19580395003)(87976001)(92566001)(105586002)(62966003)(86362001)(106356001)(107886001)(107046002)(77156002)(89996001)(33646002)(101416001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055;
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Vz4XVj8LrKJkQTByz-eyG7y3Lj4
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: Wed, 10 Dec 2014 17:58:22 -0000

Sheng

If I read the e-mail addresses aright, you are the editor of
draft-ietf-v6ops-dhcpv6-slaac-problem
What do you want (that I might be able to do) bofore this is ready for
WG Last Call?

Tom Petch


----- Original Message -----
From: "Sheng Jiang" <jiangsheng@huawei.com>
To: "t.petch" <ietfc@btconnect.com>; "Fred Baker (fred)"
<fred@cisco.com>; <v6ops@ietf.org>
Sent: Monday, December 08, 2014 2:18 AM
Subject: RE: [v6ops] Working Group Administrivia


> >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-recommendati
o
> >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
>