Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, V

Fernando,

> > It is a simple logical consequence.
> >
> > Middleboxes do not exist in the IPv6 architecture.
> > There is no interpretation of 2460 that can lead to an implementor inserting 
> > headers other places than at the source.
> > Therefore, there is no interoperability issue in RFC2460 nor any ambiguity 
> > that needs to be resolved in RFC2460.
> lAt the Last 6man meeting there was a bunch of people arguing that
> inserting EHs was "ok" because "it was not explicitly banned" -- the
> "interpretation" :-) at the time being that "'processed' doesn't mean
> 'inserted'"
>
> I asked you whether EH insertion was allowed, and you didn't answer the
> question, even after asking multiple times (it should be in the audio
> recordings).
>
> Now you say the above. When did you change your mind?
Huh?
I'm not saying anything about header insertion outside the context of 2460 
being allowed or not.
I'm saying that in the context of implementing 2460 header insertion cannot 
come up.

> Simple:
>
> 1) It was clear to everyone that EH insertion wasn't allowed.
>
> 2) Some folks came with a funny interpretation, such that EHs could be
> inserted.
>
> 3) Lots of supporters of EH-insertion (mostly from the same company)
> argued that "it wasn't forbidden". And this wasted lots of people's time.
>
> So a clarification is warranted. That's it.
>
> P.S.: And then folks wonder why people "give up"??
>
> Me, I'm not wasting more time on this. It should be pretty clear to the
> IESG what's going on here.
Sorry, you lost me.

Ole

signature.asc
Description: Message signed with OpenPGP