Subject: [v6ops] Protocol Action: '464XLAT: Combination of Stateful and Stateless Translation' to Best Current Practice (draft-ietf-v6ops-464xlat-09.txt)

From: The IESG <[email-masked]>
Date: Wed, 30 Jan 2013 14:51:29 -0800

The IESG has approved the following document:
- '464XLAT: Combination of Stateful and Stateless Translation'
  (draft-ietf-v6ops-464xlat-09.txt) as Best Current Practice

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Ronald Bonica and Benoit Claise.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/

Technical Summary: 

  This document describes an architecture (464XLAT) for providing 
  limited IPv4 connectivity across an IPv6-only network by combining 
  existing and well-known stateful protocol translation RFC 6146 in the 
  core and stateless protocol translation RFC 6145 at the edge. 464XLAT 
  is a simple and scalable technique to quickly deploy limited IPv4 
  access service to IPv6-only edge networks without encapsulation. 

Working Group Summary: 

  The working group, for the most part, the working group found this 
  uncontroversial; it is a way to deploy an IPv6-only core in a mobile 
  network and use translation to provide access to IPv4 content. The 
  folks working on the software "MAP" technology objected to it as it is 
  a deployment technology simpler than MAP and takes shortcuts that may 
  hobble such deployments in the long term. Remi Despres made 
  suggestions on the list and had some support. However, the suggested 
  approaches were more "different" than "better", and neither built 
  consensus nor demonstrated issues requiring changes to the document. 

Document Quality: 

  The document is a description of how to build a certain service 
  offering. There are ways to build other service offerings, and they 
  may or may not be better. However, the service offering described has 
  been implemented and in fact works. 

Personnel: 
 
  The document shepherd is Fred Baker. The area director is Ron Bonica.

---

From: t.petch <[email-masked]>
Date: Thu, 31 Jan 2013 12:17:50 +0000

Um.

I thought that we were still discussing whether or not the IPR claims
were acceptable, but perhaps not.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: "v6ops mailing list" <[email-masked]>; "v6ops chair"
<[email-masked]>; "RFC Editor" <[email-masked]>
Sent: Wednesday, January 30, 2013 10:51 PM
Subject: [v6ops] Protocol Action: '464XLAT: Combination of Stateful
andStateless Translation' to Best CurrentPractice
(draft-ietf-v6ops-464xlat-09.txt)

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Jan 2013 14:22:24 +0000

Yes, I'd have expected to see a consensus call by the WG chairs before this went ahead.

(Not that I'm upset, since we commonly accept RAND conditions.)

Regards
   Brian

---

From: SM <[email-masked]>
Date: Thu, 31 Jan 2013 14:20:17 -0800

Hi Tom,
>were acceptable, but perhaps not.

That was my understanding too.

Regards,
-sm

---

From: joel jaeggli <[email-masked]>
Date: Thu, 31 Jan 2013 15:26:56 -0800

>> were acceptable, but perhaps not.
The discussion was instigated by Ron after dicussion in the IESG, after 
some time on the list the v6ops chairs and AD have discussed it and the 
AD has cleared it, thus the IESG has no outstanding issues. Draft-09 
addresses the issues raised by IESG during review.

the WG should review the diffs associated with 09

http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-09

Given an intended status of BCP, the next big step is IETF last call, 
which should not be construed as a reason to stop this discussion, quite 
the contrary.

---

From: SM <[email-masked]>
Date: Thu, 31 Jan 2013 16:24:32 -0800

Hi Joel,
At 15:26 31-01-2013, joel jaeggli wrote:
>Given an intended status of BCP, the next big step is IETF last 
>call, which should not be construed as a reason to stop this 
>discussion, quite the contrary.

The message at 
http://www.ietf.org/mail-archive/web/v6ops/current/msg15027.html 
mentions that the draft has been approved for publication by the 
IESG.  According to the above there will be another IETF Last 
Call.  The state in the datatracker may be incorrect.

Regards,
-sm

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Feb 2013 01:47:19 +0000

On Jan 31, 2013, at 6:26 PM, joel jaeggli <[email-masked]> wrote:
> Given an intended status of BCP, the next big step is IETF last call, which should not be construed as a reason to stop this discussion, quite the contrary.

Someone, I can't remember who (sorry!), pointed out that this statement is true of Informational, but perhaps not of BCP.   That is, if the document is merely intended to document the existing practice that some vendor follows, that is a good thing which we should publish; however, it shouldn't be a BCP if the IPR terms are not found to be acceptable.

I haven't looked at it in depth, but a brief skim of the updated IPR report that went by yesterday looked like it was a bit outside of the norm for IETF standards, since it mentions charging royalties.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 31 Jan 2013 21:12:38 -0800

On 1/31/13 5:47 PM, Ted Lemon wrote:
> Someone, I can't remember who (sorry!), pointed out that this statement is true of Informational, but perhaps not of BCP.
I think you mean vice-versa. if I'm wrong about it's current state then 
I missed something. version 9 and 8 still request the status of bcp as 
the wglc validated as well.

  we have hypothetically discussed whether the ipr is more palatable 
with an informational document.
>    That is, if the document is merely intended to document the existing practice that some vendor follows, that is a good thing which we should publish; however, it shouldn't be a BCP if the IPR terms are not found to be acceptable.
>
Definition  of what is RAND is somewhat fungible. It clearly is not in 
the style of non-assert clause which I would have no problems at all with.