Re: [v6ops] reclassify 464XLAT as standard instead of info

[JORDI PALET MARTINEZ <[e-mail]>]

Response in-line

Saludos,
Jordi
 

-----Mensaje original-----
De: Lee Howard <[e-mail]>
Responder a: <[e-mail]>
Fecha: viernes, 22 de septiembre de 2017, 20:48
Para: <[e-mail]>, "[e-mail] WG" <[e-mail]>
Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info

    
    
    On 9/22/17, 2:22 PM, "v6ops on behalf of JORDI PALET MARTINEZ"
    <[e-mail] on behalf of [e-mail]> wrote:
    
    >Hi Lee,
    >
    >See below in-line.
    >
    >Regards,
    >Jordi
    > 
    >
    >-----Mensaje original-----
    >De: v6ops <[e-mail]> en nombre de Lee Howard
    ><[e-mail]>
    >Responder a: <[e-mail]>
    >Fecha: viernes, 22 de septiembre de 2017, 14:56
    >Para: Lee Howard <[e-mail]>
    >CC: "[e-mail] WG" <[e-mail]>
    >Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info
    >
    >    As to the original question, I have a couple of questions:
    >    
    >    1. What is gained by promoting rfc6877 "464XLAT: Combination of
    >Stateful
    >    and Stateless Translation”?  Regardless of whether the correct
    >promotion
    >    path is BCP or Proposed Standard, what is the goal?
    >
    >[Jordi] My point is: I understand that when 464XLAT was proposed, it was
    >not considered at the same level as other transition mechanisms, which
    >are, from the start, standards track. Now that this is the most
    >successful (in terms of number of users vs. all the other transition
    >mechanisms), in my opinion there is no reason to discriminate it. So,
    >either we drop to informational all the transition mechanisms that have
    >so much lower degree of success or even to historic or deprecated those
    >that are not used. Is a matter of fairness and recognize the reality.
    
    Well, rfc6877 doesn’t define a new protocol, it describes a way that
    existing technologies could meet a need. I’m trying to read it as a
    Technical Specification as defined by rfc2026, and I don’t see how it fits.
    
    Who is discriminating against the most successful mechanism based on its
    document track?

[Jordi] We (IETF) are discriminating among different transition technologies. I understand that is not a new protocol, but I’m sure we can spend some time in investigating other standards track documents that are not actually “protocols” per se … just ways to do it. Unfortunately, may operators in the market don’t know all those “details” about the distinction in between an informational, a BCP, etc., so having “other” transition technologies as non-info and this one as info, makes a difference and I’ve heard this from several people the last weeks (also previously, but I refer to this period because last weeks, I’ve been in 3 different continents with people from many different countries).

You can read 4.2.2  Informational

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.

Which clearly states “general information, does not represent an Internet community consensus” … which is not true in the sense that 464XLAT required consensus to be accepted and published, right? A reader that didn’t followed the process don't know the details.

    >    
    >    2. rfc2026 “The Internet Standards Process”  says a BCP is the "best
    >    current thinking on a statement of principle or on what is believed
    >to be
    >    the best way to perform some operations.”  What principle or what
    >    operations is 464xlat best for?
    >    
    >[Jordi] Well, I was suggesting standards track, not BCP. So not sure how
    >to read this question myself. Actually, I’ve drafted already (started two
    >months ago, and not related at all to this discussion, but for lack of
    >time availability, haven’t completed it yet, hopefully can have it early
    >next week) a BCP which initially I’ve titled “464XLAT Deployment
    >Guidelines in Operator Networks”. The idea come out after we had the
    >discussion of deploying at the IETF network 464XLAT instead of just
    >NAT64. In this document I’m describing how, according to my experience
    >(and hopefully inputs from others once a first version is published),
    >464XLAT is being deployed in both cellular and non-cellular networks.
    
    Maybe I should have also asked the question, “How does rfc6877 meet the
    standard of an Internet Standard according to rfc2026?”

[Jordi] It seems to me (unless missing something) that we are reading RFC2026 as if only a new “protocol” can be actually a standard (not discussing here what degree of maturity, as that discussion will be only relevant if first we accept that 464XLAT can be reclassified to that), which is not correct “”. To get 464XLAT working you actually need to implement code in both, the devices (UEs, CEs, etc.) and the network.

Reading the definition of TS and AS (section 3.1 and 3.2), it is clear to me that 464XLAT can fit in any of both definitions, so that should not be an issue for this reclassification. “A TS may be completely self-
   contained, or it may incorporate material from other specifications
   by reference to other documents (which might or might not be Internet
   Standards).”
    
    Lee
    
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.