Re: [v6ops] A way forward for 464XLAT

[李星 <[e-mail]>]

于 2012/3/28 23:22, Wojciech Dec 写道: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.

+1.  xing


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





_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops