Bruno, On 11-Dec-19 06:17, [email protected] wrote: > Fernando, > >> From: Fernando Gont [mailto:[email protected]] >> Sent: Monday, December 9, 2019 9:54 PM >> >> On 5/9/19 09:46, [email protected] wrote: >> [....] >>>> >>>> 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." >> >> Yes, it is just relying on that. > > Situation has changed since this email: the network programming draft has now > removed text related to SRH insertion. > Please comment on the text if you see text related to SRH insertion.
For example: https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-8.2 Why would draft-voyer-6man-extension-header-insertion exists if the SRH proponents do not intend to perform SRH insertion? Brian > >> A question of you as a chair: does the wg you chair publish documents >> based on current specs (or at the very least based on changes that are >> going to happen in the near term as a result of *existing and proven >> consensus*), or does spring ship documents that implicitly betting on >> changes that have no consensus? > > In general, I don't see the benefit of sending a draft which we expect would > never progress to RFC. So this would not be my preferred path. > However, I guess that as always, there are exceptions and I'm not a priori > aware of a process forbidding this. As of today, I'd rather not spend time on > this hypothetical case. > >> The former is how I expect WGs to operate. The later shows a clear path >> to a huge pile of documents stuck at IESG review, simply because so >> later in the process folks found out that the document turns out to >> violate existing specs. With the risk of an AD pressing "YES", and hence >> IETF has been circumvented. > > While IESG processing is beyond my paycheck (literally ;-) ), I trust the > IESG. And I don't see a reason to doubt a priori. > And even in this case, there may be a possibly to fetch back the document > from the RFC editor queue. > > In short: very hypothetic case and beyond my hat. As of today, I'd propose > that we work on the text of the document. > > Thank you, > --Bruno > >> Thanks, >> -- >> Fernando Gont >> e-mail: [email protected] || [email protected] >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> > > _________________________________________________________________________________________________________________________ > > 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. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
