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

[Suresh Krishnan <[e-mail]>]

Hi Lee,

> On Oct 23, 2018, at 3:50 PM, Lee Howard <[e-mail]> wrote:
> 
> 
> 
> On 10/23/18 2:57 PM, Suresh Krishnan wrote:
>> 
>> RFC1264 (coincidently written by Bob) was the first document in this space requiring implementations before heading to Proposed Standard
>> RFC4794 obsoleted RFC1264 specifically pointing to the following text RFC2026  (which postdated RFC1264)
>> 
>>       Usually, neither implementation nor operational experience is
>>       required for the designation of a specification as a Proposed
>>       Standard.  However, such experience is highly desirable, and will
>>       usually represent a strong argument in favor of a Proposed
>>       Standard designation.
>> 
>>       The IESG may require implementation and/or operational experience
>>       prior to granting Proposed Standard status to a specification that
>>       materially affects the core Internet protocols or that specifies
>>       behavior that may have significant operational impact on the
>>       Internet.
>> 
>> and allows WGs to set their own rules. This is where things stand right now.
>> 
>> The current state of the art BCP is RFC7942 (which obsoleted RFC6982) that allows providing optional info about existing implementations and Section 4 of that document lists some of the benefits of doing so.
>> 
>> Thanks
>> Suresh
> Thanks for this!
> 
> Looking at recent (past two years) 6man documents. . .
> 
> draft-ietf-6man-segment-routing-header
> I think multiple interoperable implementations exist. 
> 
> draft-ietf-6man-icmp-limits
> Specifies ICMPv6 error messages.
> It's -00, but we should look for running code before publication.
> 
> draft-ietf-6man-rfc4941bis-00
> Also -00, but I'd hope to see code before publication.
> 
> 
> RFC 8425 (was draft-ietf-6man-ndpioiana)
> IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags
> No running code applicable.
> 
> RFC 8319 (was draft-ietf-6man-maxra)
> Support for Adjustable Maximum Router Lifetimes per Link
> I think we had seen code; not sure, but I don't recall objections from implementers.
> 
I did implement this just to check if there were no crazy side effects of this.
> 
> RFC 8200 (was draft-ietf-6man-rfc2460bis)
> Internet Protocol, Version 6 (IPv6) Specification Errata        2017-07
> Decades of running code.
> 
> RFC 8201 (was draft-ietf-6man-rfc1981bis)
> Path MTU Discovery for IP version 6
> Decades of running code.
> 
> 
> RFC 8096 (was draft-ietf-6man-ipv6-mibs-obsolete)
> The IPv6-Specific MIB Modules Are Obsolete
> No running code applicable.
> 
> RFC 8106 (was draft-ietf-6man-rdnss-rfc6106bis)
> IPv6 Router Advertisement Options for DNS Configuration
> We had running code.
> RFC 8064 (was draft-ietf-6man-default-iids)
> Recommendation on Stable IPv6 Interface Identifiers
> No running code applicable
> 
> 
> RFC 8021 (was draft-ietf-6man-deprecate-atomfrag-generation)
> Generation of IPv6 Atomic Fragments Considered Harmful
> No running code applicable.
> 
> 
> So, requesting running code for the ipv6only-flag isn't really a change in practice for 6man. We just haven't had to ask before.
> 
Not to take away from your point, but a lot of these are bis documents and I would have expected running code at this time :-).

Thanks
Suresh