Subject: [v6ops] Working Group Administrivia

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 5 Dec 2014 18:17:38 +0000

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 (<[email-masked]).

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-recommendations/

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 [email-masked] indicating that the old draft name were replaced by the new draft name, so that the revision history is tracked appropriately.

Opinions?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Dec 2014 08:37:27 +1300

Personal opinion: I agree with most of the assessments, but:

On 06/12/2014 07:17, Fred Baker (fred) wrote:
...
> 2014-09-18                 draft-ietf-v6ops-design-choices      http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/

I think it's a real shame if we can't produce some collective wisdom
in this area. Admittedly, there is an alternative for the authors -
turn it into a book. But it seems like it should be mainstream work
for this WG. If I haven't commented much on it, that's because I think
it is competent work that should go forward. My preferred next step
for this draft would be one more update (see below) and a WG Last Call.

> 2014-10-27           draft-ietf-v6ops-dhcpv6-slaac-problem      http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/

I'm of the party that believes that there is a defect in the IPv6
specifications in this area that needs to be fixed. I don't care whether
this draft becomes an RFC, but I do care about the fix. As long as
there's no sign of somebody fixing the specs, I like having this
draft around.

> 2014-10-27      draft-ietf-v6ops-ula-usage-recommendations      http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations/

I'm surprised by the assertion that the WG isn't interested, given the
amount of email this topic has generated. But now I have a suggestion.
draft-ietf-v6ops-design-choices says "this document serves both to
document the reasoning behind best current practices for IPv6, and to
allow a designer to make an intelligent choice where no such
consensus exists." However, it doesn't have a section on choices for
addressing. It needs that, and the ULA recommendations and considerations
belong there rather than in a separate draft.

   Brian

---

From: t.petch <[email-masked]>
Date: Sun, 7 Dec 2014 10:01:02 +0000

Fred

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

Tom Petch

----- Original Message -----
From: "Fred Baker (fred)" <[email-masked]>
To: <[email-masked]>
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 (<[email-masked]).

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 [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Matthew Petach <[email-masked]>
Date: Sun, 7 Dec 2014 13:29:09 -0800

> addresses a known problem and I think it would be remiss of the IETF not

Completely concur; we can't leave the
current situation as it is, where the
behaviours are decided ad-hoc by
different sets of developers, and
upgrading your OS may suddenly
change how your network behaves.
This needs to be documented, and
hopefully fixed at some point.

Thanks!

Matt

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 8 Dec 2014 02:18:11 +0000

>addresses a known problem and I think it would be remiss of the IETF not

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Dec 2014 11:06:24 +0100

> there's no sign of somebody fixing the specs, I like having this

since we haven't been able to agree on a fix over the last decade, I would not recommend for you to hold your breath waiting for one.

I do think it is useful to have the implementation report that this document is around.

cheers,
Ole

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 9 Dec 2014 15:33:49 +0000

So what I get out of this so far is that folks are OK with the clean-up of the expired drafts, but feel that there is a place for a WG document documenting (but not making recommendations about) the SLAAC/DHCP problem.

Let me ask specifically about the “ULA” and “Design Choices” documents. They have not expired and their authors are still working on them. Brian has commented; others have not. Do we want to keep working on them?

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Dec 2014 17:20:46 +0100

Le 09/12/2014 16:33, Fred Baker (fred) a écrit :
> So what I get out of this so far is that folks are OK with the
> clean-up of the expired drafts, but feel that there is a place for a
> WG document documenting (but not making recommendations about) the
> SLAAC/DHCP problem.
>
> Let me ask specifically about the “ULA” and “Design Choices”
> documents. They have not expired and their authors are still working
> on them. Brian has commented; others have not. Do we want to keep
> working on them?

There is one thing I noticed in other ULA-related discussions (e.g. 
homenet WG) that often new methods of generating ULAs are alluded to. 
It would be better to first refer to the existing methods of generating 
ULAs (the ULA RFC) and maybe select among those.

I am not sure whether the current ULA draft recommends when and how to 
select among the 3 ULA generation methods already in the ULA RFC, but 
otherwise it may be good to.

Alex

>> 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-10-27      draft-ietf-v6ops-ula-usage-recommendations 
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations/
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Tim Chown <[email-masked]>
Date: Tue, 9 Dec 2014 21:49:41 +0000

Hi,

> On 9 Dec 2014, at 15:33, Fred Baker (fred) <[email-masked]> wrote:
> 

I would like to see these that one progressed, as it came out of the 6renum WG as a gap, and it would be very appropriate to close that gap off, as best as we can.

> Let me ask specifically about the “ULA” and “Design Choices” documents. They have not expired and their authors are still working on them. Brian has commented; others have not. Do we want to keep w…

I think both are useful. There were certainly other documents that ‘punted’ guidance on ULA usage to that ULA draft, so it would seem reasonable to complete it, so long as its just Informational and not BCP. And I’ve seen references to the design choices document in various places, so people are clearly using it, and finding it useful to point others at, so again closing it off would seem worthwhile.

The old enterprise IPv6 draft of mine you dug up was of course obsoleted by the enterprise-incremental document, so is certainly dead.

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 9 Dec 2014 21:51:12 +0000

> Let me ask specifically about the “ULA” and “Design Choices” documents. They have not expired and their authors are still working on them. Brian has commented; others have not. Do we want to keep w…

Oh, and I’d also support Brian’s proposal to move the ULA ‘guidance' (rather than ‘recommendations’) to the design choices document, which is an appropriate place to discuss the tradeoffs with their use in different contexts.

Tim

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 10 Dec 2014 01:33:59 +0000

>Let me ask specifically about the “ULA” and “Design Choices” documents.
>They have not expired and their authors are still working on them. Brian has
>commented; others have not. Do we want to keep working on them?

The WG certainly showed interests when these documents were adopted. The topics are useful. Then, maybe long process and wide discussion (some discussion may be relevant, but not essential for the core contents of these documents) have distracted people's interests. Let's get back to the original motivations, focus on the core contents, and complete them as quick as possible.

Best regards,

Sheng

>longer interested in these, and so they should be returned to the authors and
>not recorded or treated as working group drafts.
>>

---

From: <[email-masked]>
Date: Wed, 10 Dec 2014 08:25:23 +0100

+1 
	Olaf

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Sheng Jiang
Sent: Mittwoch, 10. Dezember 2014 02:34
To: Fred Baker (fred); [email-masked] WG
Subject: Re: [v6ops] Working Group Administrivia

>They have not expired and their authors are still working on them. 
>Brian has commented; others have not. Do we want to keep working on them?

Best regards,

Sheng

>> 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 
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendati
>ons
>/

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 10 Dec 2014 16:18:25 +0000

> The WG certainly showed interests when these documents were adopted. The topics are useful. Then, maybe long process and wide discussion (some discussion may be relevant, but not essential for the…

Works for me.

---

From: t.petch <[email-masked]>
Date: Wed, 10 Dec 2014 17:39:29 +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" <[email-masked]>
To: "t.petch" <[email-masked]>; "Fred Baker (fred)"
<[email-masked]>; <[email-masked]>
Sent: Monday, December 08, 2014 2:18 AM
Subject: RE: [v6ops] Working Group Administrivia

> 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:
> 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.
the
> >authors have been working hard on them, we think the working group is
no
>http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendati
o

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 11 Dec 2014 02:24:24 +0000

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

>From: t.petch [mailto:[email-masked]]
>Sent: Thursday, December 11, 2014 1:39 AM
>To: Sheng Jiang; Fred Baker (fred); [email-masked]

---

From: t.petch <[email-masked]>
Date: Fri, 12 Dec 2014 11:08:13 +0000

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" <[email-masked]>
To: "t.petch" <[email-masked]>; "Fred Baker (fred)"
<[email-masked]>; <[email-masked]>
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.
> >> >addresses a known problem and I think it would be remiss of the
IETF
> >not
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-pb-statement-re
q
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-securit
y
> >> >draft-<author>-<subject>. It would be good if the authors would
send
> >a
> >> >note to [email-masked] indicating that the old draft
name
> >were
>>----------------------------------------------------------------------
-
> >-
> >> >--------
> >> >
> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
>
>>----------------------------------------------------------------------
-
> >-

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 12 Dec 2014 16:05:52 +0000

> reflects the state of  M and O :-)

No, it was not a statement of consensus. It was a statement that I’m wondering whether we have a consensus, and whether I’m reading it correctly. My read of the subsequent discussion is that the working group would like the SLAAC document to be a SLAAC problem statement, and wants to work on it, that the ULA draft should continue (with the preferred outcome to be to document use cases known to be deployed), and the “design considerations” document to continue.

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 15 Dec 2014 03:33:18 +0000

>From: Fred Baker (fred) [mailto:[email-masked]]
>Sent: Saturday, December 13, 2014 12:06 AM
>
>the ULA draft should continue (with the preferred outcome
>to be to document use cases known to be deployed)

Hi, Fred & Howard,

We are working towards that direction. We will even change the document title. However, the document name (draft-ietf-v6ops-ula-usage-recommendations) is still misleading. For next version, can we resubmit it as draft-ietf-v6ops-ula-use-cases or something you think proper. Then you can tag is as replacement of draft-ietf-v6ops-ula-usage-recommendations. Does it work for you?

Best regards,

Sheng