Re: [bess] [Technical Errata Reported] RFC4659 (4087) / IPv6 mandatory for an RFC4364 implem ?

Well I agree with Francois & Eric.

To me RFC4659 is an "amendment" to RFC4364 not an "update" or "errata"

I vote to reject.

Cheers,
R.

On Tue, Nov 18, 2014 at 7:10 AM, Francois Le Faucheur (flefauch) <
flefauch@cisco.com> wrote:

> Hi Wes and all,
>
> Based on my (possibly naive or outdated) understanding of “update", I
> don’t see RFC4659 as updating RFC4364.
> From my recollection of the work to produce RFC4659 at the time, there was
> no intention for the WG to influence whether IPv6 was going to be mandatory
> in implementation of RFC4364. It was considered that one may implement
> RFC4364 for IPv4, and if one wanted to support IPv6 support then they’d
> also implement RFC4659.
> If some other document wants to take a stab at defining what IPv6 feature
> is mandatory in what environment, fine by me. But I don’t believe that was
> the intention of the WG or RFC4659.
>
> So unless someone produces a definition for “updates” that change my
> understanding, I vote for rejecting the errata.
>
> Cheers
>
> Francois
>
> > On 14 Nov 2014, at 13:27, George, Wes <wesley.george@twcable.com> wrote:
> >
> > On 11/14/14, 12:36 PM, "Eric C Rosen" <erosen@juniper.net> wrote:
> >
> >
> >> This just isn't the meaning of "Updates".
> >>
> >>> I think that the nuanced inference that you are making as to why
> >>> "updates" is used or not used is going to be lost on all but those
> >>> deeply involved in IETF standards minutiae.
> >>
> >> Agreed.  Of course, the same could be said of all the meta-data,
> >> including the classification as "standards track", "experimental", etc.
> >> Nevertheless, the terms have been given a certain meaning with regard
> >> to IETF process, and we can't just decide that we're going to use them
> >> differently.
> >
> > WG] I am not trying to ad hoc redefine the term. However, searching for
> > "RFC updates" produces a lot of irrelevant results, so quite honestly I
> > have no idea what to feed a search engine to find the right RFC or BCP
> > that normatively defines the term "updates" as far as metadata is
> > concerned and what that means in IETF process terms for the relationship
> > between the documents, so I can't really respond to your assertion
> > intelligently. Citation, please?
> >
> >> The only real impact of accepting this erratum would be to give fuel to
> >> non-productive arguments like:
> >>
> >> - "Hey, your alleged implementation of 4364 isn't compliant to 4364,
> >> because it doesn't implement 4659."
> >>
> >> - "But it was compliant last week!"
> >>
> >> - "No, it hasn't been compliant since BCP177 was published".
> >>
> >> - "Then BCP177 should have updated 4364"
> >>
> >> So I would suggest rejecting this erratum on the grounds that any
> >> positive effect is more than outweighed by the time wasted having
> >> non-productive arguments about it.
> >
> > WG] Well, the same argument could happen with nearly any standard that is
> > updated by subsequent standards on or after the day that the updating
> > draft becomes a standard. This is because "updates" (along with
> > obsolete/historical/replace) is how we evolve our standards, and
> > implementers have to evaluate whether they need to update their
> > implementation to keep up with those changes, usually with feedback from
> > the people who buy their implementations, since they are the ones who
> > determine whether a given implementation is "standards compliant" as
> > shorthand for "meets my needs for features and interoperability". The
> > reason I filed an erratum is that I believe that the lack of the update
> > metadata linkage was an oversight, not that I am trying to retroactively
> > backdoor a change to the standard and consensus. If anyone has the
> history
> > and can show that the WG made a conscious decision around this, I'll
> stand
> > corrected, and will update draft-ietf-mpls-ipv6-only-gap accordingly to
> > reflect the conflict between the two documents (4364 is still in full
> > effect as a standalone standard but explicitly doesn't support IPv6,
> while
> > 4659 does support IPv6 but doesn't actually change 4364 to harmonize the
> > standard and reflect that IPv6 support is possible).
> >
> > Also: When did IETF start optimizing to avoid wasting time on
> > non-productive arguments? ;-)
> >
> > Wes George
> >
> >
> > This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>