Re: [spring] Question about SRv6 Insert function

Fernando,

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Fernando Gont
> Sent: Tuesday, September 3, 2019 1:18 PM
> 
> 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.

draft-ietf-spring-srv6-network-programming has a normative reference to [I-D.voyer-6man-extension-header-insertion]
 https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01#section-13.1

As such, from a process standpoint, it would not going to be published before [I-D.voyer-6man-extension-header-insertion] be itself published as RFC. And from its name, the latter is intended to be discussed and within control of the 6MAN WG. So I don't think that we can say that it "just rely on the AD to keep the "DISCUSS" button pressed."

In my mind, this should also be a clear indication that the question of header insertion is (to be) within the control of the 6MAN WG. But you may have a different opinion.

Regards,
--Bruno

> 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?
> 
> 
> -- 
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.