Re: [v6ops] A way forward for 464XLAT

[Wojciech Dec <[e-mail]>]

Hi Fred,

the proposed way forward makes sense to me. There appears to be a desire to
have an "implementers spec" for a NAT64 client-device, along with some
default settings, and assuming that this is based on existing NAT64
standards and not based on some "hard coded" values, it's fine to progress
as a separate draft.

Regards,
Woj.

On 27 March 2012 04:34, Fred Baker <[e-mail]> wrote:

> I won't say "chair hat off", but "chair hat fashionably tipped to one
> side." I'm trying to figure out the best way forward for the 464XLAT
> specification in view of comments by the authors of
>
>        http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u
>        http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib
>        http://datatracker.ietf.org/doc/draft-fu-softwire-map-mib
>        http://datatracker.ietf.org/doc/draft-jiang-softwire-map-radius
>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment
>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option
>
> http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation
>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation
>
> http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-port
>        http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd
>
> http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast
>
> and notably the comments in the working group meeting Monday morning. Why
> do I comment on the "chair hat"? Well, I'm not "giving instruction", as
> chair; I'm floating an idea. If the idea is acceptable, the idea may become
> instruction; if it needs to be modified, I want to have that conversation.
>
> The objections raised in the working group come down to:
>    - the authors of said other documents would like to have a conversation
> with the 464XLAT folks
>    - What's this about a prefix::/96?
>    - What's this about a proxy service?
>    - What's this about normative language?
>    - How does it fit the the mdt-softwire-map specifications, which
>      appear to have a growing consensus behind them in softwire?
>
> Before you continue reading this note, please stop and read these two
> sections:
>    http://tools.ietf.org/html/rfc2026#section-4.2.2
>    http://tools.ietf.org/html/rfc2026#section-5
>
> From my perspective, and from reading those definitions, an Informational
> Document is a white paper, while a BCP is something that a significant and
> relevant part of the Internet COmmunity agrees to, and
>
> ...since the Internet itself is composed of networks operated by a great
>   variety of organizations, with diverse goals and rules, good user
>   service requires that the operators and administrators of the
>   Internet follow some common guidelines for policies and operations.
>
> In other words, operational service models, while not strictly speaking
> "protocols", can be described in a BCP *standard* as "how to implement a
> certain service". This is in no sense "the best" or "only way to deploy
> RFCs 6145/6146", but it might be "the best way to deploy the CLAT service".
> v6ops is authorized, by charter, to write informational and BCP documents.
>
> And since a BCP describes the set of things that one MUST or SHOULD do in
> deploying such a service, RFC 2119 language regarding that specific service
> may be acceptable in a BCP describing that service.
>
>
> With that preparatory reasoning, it seems to me that we need to separate
> the contentious parts of the specification so that uncontentious parts can
> go forward, and other parts can be discussed - whether in this working
> group or another one.
>
>
> Given the points of contention, it seems that the separation needs to be
> among three documents.
>
> The first is a specification - a BCP - for the CLAT service. It refers to
> RFCs 6052/6144/6145/6146/6147, and describes how translation is used in
> this context using normative language. It does not refer to a prefix::/96;
> it refers to RFC 6052. My understanding is that several people have said
> that this specification is interesting and useful.
>
> The second is a separate specification for the proxy service, which is
> contentious. Being separated, it can be discussed and beaten to death as
> needed. The first specification says that the CLAT service MAY implement
> this proxy service. I'm not sure whether that is BCP or Informational; we
> can discuss that in the context of the rest of the discussion of the proxy
> service.
>
> The third is a report on the trial deployment of the CLAT service by the
> various companies in question. This is an informational document.
>
> Am I making sense? Would this be an acceptable way forward?
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>