Re: [v6ops] Working Group Administrivia

[t.petch <[e-mail]>]

Sheng

I am aware of
"
From: fred at cisco.com
To: v6ops at ietf.org
Date: Sun, 19 Oct 2014 11:00:02 -0700

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.  "

as well as

"From: fred at cisco.com
To: v6ops at ietf.org
Date: Sun, 26 Oct 2014 11:00:03 -0700

The working group last call for this draft announced last week
continues for another week.  Please feel free to comment on it. "

so my last post, while wishing to see this advance, was also slightly
tongue-in-cheek.

I think it unfortunate that a new version then appeared the day after
Fred's post, a
version, which, for me, was a step backwards.  (The WG then went off
into another of its canard, 6to4, IMO).

I think it wrong to try and document all the (common) variations in
behaviour.  Rather, I want something which could be summarised as
1) M and O is a mess
2) It will always be a mess
3) Tough
with the evidence to support this in the form of variant
implementations, enough to show that it is a mess without attempting to
be a comprehensive survey.

I see Fred's message, the one which started this thread as an implicit
statement by the WG Chair that the WGLC resulted in a consensus that the
WG should not proceed with this I-D - a view which I, and a few others,
have stated their disagreement with.  Perhaps the IETF process now
reflects the state of  M and O :-)

Tom Petch


----- Original Message -----
From: "Sheng Jiang" <[e-mail]>
To: "t.petch" <[e-mail]>; "Fred Baker (fred)"
<[e-mail]>; <[e-mail]>
Sent: Thursday, December 11, 2014 2:24 AM

> Hi, Tom,
>
> Thanks for your offer.
>
> Review and comments would be very helpful for us to improve. Following
the latest discussion, there are two actions we are planning: A) focus
on the implementation divergence rather than a protocol definition
problem statement. The most of contents are already in the current
document. It just needs a little bit reorganizing and rewording. B) some
addition investigation or experiments, e.g. both DHCPv6 and ND have DNS
configuration.
>
> If you are interested to contribute, you are certainly welcome.
>
> Best regards,
>
> Sheng
>
> >-----Original Message-----
> >From: t.petch [mailto:[e-mail]]
> >Sent: Thursday, December 11, 2014 1:39 AM
> >To: Sheng Jiang; Fred Baker (fred); [e-mail]
> >Subject: Re: [v6ops] Working Group Administrivia
> >
> >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" <[e-mail]>
> >To: "t.petch" <[e-mail]>; "Fred Baker (fred)"
> ><[e-mail]>; <[e-mail]>
> >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)" <[e-mail]>
> >> >To: <[e-mail]>
> >> >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-re
q
> >/
> >> >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 (<[e-mail]).
> >> >
> >> >2013-12-06         draft-ietf-v6ops-balanced-ipv6-security
> >>
>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-securit
y
> >/
> >> >
> >> >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-recommendat
i
> >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 [e-mail] 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
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/v6ops
> >> >>
> >> >
> >> >_______________________________________________
> >> >v6ops mailing list
> >> >[e-mail]
> >> >https://www.ietf.org/mailman/listinfo/v6ops
> >>
>
>