Hi Fernando,

> On Sep 3, 2019, at 7:17 AM, Fernando Gont <ferna...@gont.com.ar> wrote:
> 
> Hello, Suresh,
> 
> On 2/9/19 19:07, Suresh Krishnan wrote:
> [....]
>>>> So, we should probably explore the motivation for Option 2). If the
>>>> motivation is not sufficient, we should probably standardize on Option 1.
>>> 
>>> My argument would be:
>>> Folks would do whatever they please with 1). If somehow they feel the
>>> need to do 2), they should *refrain from even suggesting it*, post an
>>> internet draft that proposes to update RFC8200 to allow for the
>>> insertion of EHs, wait for that to be adopted and published, and only
>>> then suggest to do EH insertion.
>> 
>> I have put down my thoughts on the future of header insertion work in a
>> mail to the 6man list in May 2017. The mail can be found below
>> 
>> https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc
> 
> This seems e bit misleading. What I would expect is that before any work
> is published on EH-insertion, the IPv6 standard is updated to allow for
> EH insertion. (plese see bellow)

> 
>>> P.S.: Given the amount of discussion there has been on this topic in the
>>> context of RFC8200, I'd like to hope that there's no draft-ietf document
>>> suggesting EH-insertion or, if there is, the relevant ADs and chairs
>>> make sure that's not the case anymore.
>> 
>> Yes. If a draft violates RFC8200 and it hits the IESG for evaluation, I
>> will certainly hold a DISCUSS position until the violations are fixed.
> 
> Since there have been plenty of attempts to do EH insertion or leave the
> IPv6 standard ambiguous in this respect, and the IETF has had consensus
> that EH insertion is not allowed, I think it would be bad, wastefull,
> tricky, and even dangerous to let a document go through the whole
> publication process, and just rely on the AD to keep the "DISCUSS"
> button pressed.
> 
> Put another way: what'd be the rationale for having a draft-ietf and
> have the corresponding wg ship the document with something that clearly
> goes against IETF consensus, and that the relevant AD has declared that
> wouldn't let pass?

In short, this is not the case. I am *not* the relevant AD for the SRv6 Network 
Programming draft. If this document was in 6man I would have flagged it much 
earlier like I did for the SRH draft.

Thanks
Suresh

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to