Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

[Tom Herbert <[e-mail]>]

On Mon, Nov 25, 2019 at 1:01 PM Andrew Alston
<[e-mail]> wrote:
>
> I have to second this – because if this starts to happen on the standards track, what standard holds true?  I’ve seen much debate about not having multiple solutions to the same problem – and WG chairs trying to avoid that, however I would argue that it is far worse if we start publishing standards that contradict other standards – effectively creating standards that directly contradict each other.

Andrew, for an independent submission this contingency is covered by RFC4846:

"Any submission that constitutes an alternative to, or is in conflict
with, an IETF Standard or proposal for Standards-Track adoption must
clearly indicate that relationship."

I believe we've established that the draft is in conflict with
RFC8200, but I do not believe the relationship has been clearly
indicated.

Tom

>
>
>
> I also agree that the independent stream would make a lot of sense in this case – but then again – maybe I’m missing something because I forgot to read an rfc somewhere
>
>
>
> Andrew
>
>
>
>
>
> From: ipv6 <[e-mail]> On Behalf Of Joel M. Halpern
> Sent: Sunday, 24 November 2019 22:17
> To: Brian E Carpenter <[e-mail]>; Sander Steffann <[e-mail]>
> Cc: 6man <[e-mail]>
> Subject: Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt
>
>
>
> There is no reason I know of for the IETF to publish an RFC on the IETF
> stream that describes interesting ways that deployers have violated
> RFCs. If the deployers want an RFC, the Independent Stream can be used
> to publish such things. Particularly if the document actually describes
> meaningful values for there violation.
>
> Yours,
> Joel
>
> On 11/23/2019 6:59 PM, Brian E Carpenter wrote:
> > Hi Sander,
> >
> >> - I object to not updating RFC8200 in any RFC that contradicts its content. If EH insertion should be accepted by this WG despite the objections then implementers reading RFC8200 need to know that a conscious exception has been made.
> >
> > So, it sounds as if you are against publishing true facts. This draft describes an implementation and operational practice. I completely agree that it violates RFC8200, which standardises IPv6 for the Internet. I wouldn't object to adding an explicit statement of this to the draft, because that's also a true fact. But I would be very sad if the IETF is now against publishing factual information about actual practice that we are not willing to standardise, in line with https://tools.ietf.org/html/rfc2026#section-4.2.2 paragraph 2.
> >
> > If we had standardised mechanisms for establishing limited domains, we could do better than that, but we aren't there yet.
> >
> > Regards
> > Brian Carpenter
> >
> > --------------------------------------------------------------------
> > 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
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------