Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

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

Interoperability is a different thing, and this is the way we will actually be able to move RFCs to STDs (demonstrated interoperability and widely implemented).

If we don't allow documents, even before they are implemented (or as Joel said, before they can talk openly about the implementation), to get to RFCs, then we will not be able to move most of the work that vendors are waiting to become an RFC to implement or openly talk about that implementation ...

If something is discovered as broken or incomplete during the implementation, that's fine, we have -bis, or erratas, etc., same as we can deprecate something with demonstrates is useless or completely broken.

"to err is human"

Regards,
Jordi
 
 

-----Mensaje original-----
De: ipv6 <[e-mail]> en nombre de Lee Howard <[e-mail]>
Fecha: miércoles, 24 de octubre de 2018, 18:22
Para: <[e-mail]>
Asunto: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

    
    On 10/24/18 7:08 AM, JORDI PALET MARTINEZ wrote:
    > Then the vendors that have the power to implement everything they want, definitively win,
    
    Yes. The people who write the code that implements the protocols we use 
    on the Internet are the ones who. . . do that.
    
    >   only because they are able to implement it, not necessarily because it is good or bad, and the argument of the implementation will be a tool to reach consensus, even if it takes longer, more versions, etc. This is real life.
    
    If two implementers can't tell from a draft what to do to make sure 
    their implementations can interoperate, the draft should not advance, 
    regardless of how good the idea is. In this case, one OS could say, 
    "That's advisory, I'll ignore it and do everything over IPv4," another 
    could say, "The router has no IPv4 but I'm using IPv4 for service 
    discovery, so I'll keep doing it," and a third could say, "RA says no 
    IPv4, I'm disabling the stack." All comply with the document as written, 
    but those three systems would have a very hard time communicating.
    
    What guidance would you give those implementers? Can we put that 
    guidance into the draft?
    
    >
    > Very good ideas that don't become standards because during the ID development don't get implemented (even if they will become implemented once they become RFCs), lose.
    >
    > I'm sure there have been already many IETF documents that have been in both situations. Market decides at the end. But that's the thing: at the end, most of the time only when there is an RFC.
    >
    > A couple of examples I can remember, IPv6 site local (it was an RFC) and draft-ietf-ipv6-dns-discovery, different process stages, both got implemented by many OS vendors and also Linux. No longer used.
    
    Implementation is not a guarantee of deployment.
    
    Non-implementation is a guarantee of non-deployment.
    
    >
    > I'm sorry but it is discrimination.
    
    Yes. We are trying to discriminate between clear documents and vague 
    documents. From what I can see, developers can write completely 
    compliant implementations that break communications between systems on a 
    network.
    
    We also discriminate between ideas that help and those that hurt, or 
    even those that do no harm but are useless. If we never discriminated, 
    we would publish every draft.
    
    Lee
    
    >
    > Regards,
    > Jordi
    >   
    >   
    >
    > -----Mensaje original-----
    > De: ipv6 <[e-mail]> en nombre de Job Snijders <[e-mail]>
    > Fecha: miércoles, 24 de octubre de 2018, 12:31
    > Para: JORDI PALET MARTINEZ <jordi.palet=[e-mail]>
    > CC: Fernando Gont <[e-mail]>, Suresh Krishnan <[e-mail]>, "[e-mail]" <[e-mail]>
    > Asunto: Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)
    >
    >      On Tue, Oct 23, 2018 at 10:03:35PM +0200, JORDI PALET MARTINEZ wrote:
    >      > Let’s suppose there is a draft and nobody wants to implement it.
    >      
    >      full stop. then the document does not need to be published.
    >      
    >      > Another draft is implemented. May be after some time the one that was
    >      > not implemented get more market success than the other one.
    >      
    >      fantastic, at that point the document can move forward again in the
    >      publication process. 'market success' implies running code came into
    >      existence.
    >      
    >      > This is discriminating both drafts in the IETF process, and we must
    >      > not do that. It may happen even “you have programmers” that are good
    >      > friends, they will do for me and in the other way around. Or I’m a
    >      > vendor, so I’ve the resource to do it.
    >      
    >      This is not discrimination. If authors don't have the capability to
    >      develop running code themselves, and also don't have access to resources
    >      nor are able to convince others to implement a protocol specification...
    >      the IETF's prime directive of interoperability can't be met anyway.
    >      
    >      Some ideas gain traction, some don't - this happens to all of us.
    >      
    >      > This will mean at the end that we balance the IETF work towards those
    >      > that can (somehow), get things implemented, even if is a bad work (I
    >      > understand that still need to follow the consensus, etc.).
    >      
    >      Bias towards getting things implemented is an excellent way to foster a
    >      stream of healthy specifications. Invariably the creation of running
    >      code leads to higher quality specifications as implementers provide
    >      their feedback to the WG. We don't work in the void, we're here to do
    >      tangible things. This is not an academic exercise.
    >      
    >      > At the end, we may have open source implementation of a draft, and not
    >      > being adopted by vendors, or in the other way around. That’s not a
    >      > good way to classify “good” or “bad” IETF work, also because after
    >      > some years, what was “bad” is adopted as good, and viceversa.
    >      
    >      I don't understand your 'open source' vs 'vendors' statement, they are
    >      the same, both are vendors. The publication license and cost are
    >      irrelevant.
    >      
    >      > I understand that when IETF started, it was very few work and it was
    >      > very easy to ask for code for everything, but our industry changed and
    >      > we can’t enforce that, even at WG level.
    >      
    >      I don't think 'our industry changed' means that we can now do without
    >      code. We can absolutely enforce it, also at the WG level. IDR working
    >      group is living proof. The QUIC and TLS13 groups have done excellent
    >      work and only got to the point where they are by investing time &
    >      resources to produce lots of running code.
    >      
    >      Raising the bar is a good thing!
    >      
    >      Kind regards,
    >      
    >      Job
    >      
    >      --------------------------------------------------------------------
    >      IETF IPv6 working group mailing list
    >      [e-mail]
    >      Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    >      --------------------------------------------------------------------
    >      
    >
    >
    >
    > **********************************************
    > 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.
    >
    >
    >
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > [e-mail]
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [e-mail]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



**********************************************
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.