Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-00.txt

From: "C. M. Heard" <[email-masked]>
Date: Tue, 28 Mar 2017 19:42:36 -0700

On Wed, 29 Mar 2017 07:28:32 +1300 Brian E Carpenter wrote:
> > Hence, a context-less ban of
> > IPv6 extension header insertion does not make sense.
>
> RFC2460bis isn't contextless. The context is the Internet and therefore
> the requirements for interoperable communication between any two nodes
> on the Internet. I don't see any conflict between that and a additional
> specification for local use of a feature that does not meet those
> requirements.
>
> I think this draft would be much easier to consider without that sort
> of phrasing.

Agreed, and in the same vein, I think that the draft would be more credible
if the first sentence of the abstract were changed along the following lines:

OLD:
   The network operator and vendor community has clearly indicated that
   IPv6 header insertion is useful and required.

NEW:
   Certain segments of the network operator and vendor community have
   clearly indicated that IPv6 header insertion is useful and required
   for their purposes.

//cmh

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 Mar 2017 15:33:24 +0000

Hi,

> On 29 Mar 2017, at 03:42, C. M. Heard <[email-masked]> wrote:
> 

Well, I think if this document is to be adopted, it should start by saying clearly why EH “insertion” by encapsulation as per RFC2460-bis isn’t sufficient in specific scenarios.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 Mar 2017 22:57:54 +0200

>> On Wed, 29 Mar 2017 07:28:32 +1300 Brian E Carpenter wrote:
[....]
> Well, I think if this document is to be adopted, it should start by saying clearly why EH “insertion” by encapsulation as per RFC2460-bis isn’t sufficient in specific scenarios.

As far as I understand, this doc is essentially making an argument
against the decision taken for rfc2460bis.

Since that ship has already sailed, I'm not sure whether it could be
adopted "as is".

Rather, it should probably make a case for updating RFCXXXX (whatever
number rfc2460bis receives).

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 Mar 2017 21:02:27 +0000

> On 29 Mar 2017, at 21:57, Fernando Gont <[email-masked]> wrote:
> 

That was my understanding of what has been previously said.

The draft would need (as Mark also said in another thread) explain why encapsulated isn’t sufficient, and then successfully describe how direct EH insertion can be done safely in specific conditions.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 Mar 2017 23:22:42 +0200

On 03/29/2017 11:02 PM, Tim Chown wrote:
>>> 
>>> Well, I think if this document is to be adopted, it should start
>>> by saying clearly why EH “insertion” by encapsulation as per
>>> RFC2460-bis isn’t sufficient in specific scenarios.
>> 
>> Since that ship has already sailed, I'm not sure whether it could
>> be adopted "as is".
>> 
>> Rather, it should probably make a case for updating RFCXXXX
>> (whatever number rfc2460bis receives).
> 
> The draft would need (as Mark also said in another thread) explain
> why encapsulated isn’t sufficient, and then successfully describe how
> direct EH insertion can be done safely in specific conditions.

Agreed. And the text be phrased as an update to RFCXXXX (rfc2460bis),
rather than about the decision that has already been taken for
rfc2460bis. -- Otherwise, the I-D looks like tryig to reopen discussion,
when the ship has already sailed.

Cheers,