Andrew, I am a bit confused (not unusual). Can you get back to basics on my questions below?
On 07-Dec-19 11:23, Andrew Alston wrote: > Ole - so - let me understand something. > > The definition of consensus - among other things - say that all outstanding > objections have been addressed (though not potentially resolved). When you > have multiple people saying - a draft violates RFC8200 and that is a concern > - Are you referring to draft-ietf-spring-srv6-network-programming-05? If not, the subject header of this thread is a bit confusing. If so, why are you asking Ole? The WG last call is in the spring WG, with a courtesy copy to 6MAN. > and if such a thing is required, an update to RFC8200 should be done. Why does that follow? Alternatively, draft-ietf-spring-srv6-network-programming could acknowledge that it deviates from RFC8200. Whether that's acceptable would be a question for the IETF Last Call rather than any single WG. At the moment, the draft only mentions RFC8200 in a context that discusses neither insertion nor removal of extension headers, which is beside the point. Like draft-voyer, if it describes a violation of RFC8200, shouldn't that be explicit in the text? There's a lot of jargon in draft-ietf-spring-srv6-network-programming. I can't tell from the jargon whether "insert" means "insert on the fly" and whether "Pop the SRH" means "delete on the fly". Should those terms be clarified before the draft advances? > Multiple concerns have been raised - a number of which have not been > addressed to the satisfaction of those asking the questions. > > Yet - we now see documents being pushed through to last call Erm, that's what Last Call is for - finding the things that haven't been settled. But for draft-ietf-spring-*, it's the spring WG chairs you should be asking, IMHO. Regards, Brian > without these things being addressed. So I would ask - what exactly do you, > as a working group chair propose we do - swallow our technical concerns and > our objections and because we've said it once, and it's been ignored or swept > under the rug, shrug our shoulders and say - oh well - that’s ok - we tried - > and let something we believe to be technically flawed sail through? > > I stood and very clearly stated multiple times that I believe that work on > this stuff and the drafts which I am co-author on should continue in parallel > - because for one - I believe in some ways - they address different things - > yet - at the same time - that does not mean that I believe that we should > accept things which we have deep technical concerns about. > > The engineering must come first - and it seems very clear to me that both > myself and others - have significant technical and operational concerns - and > I find it rather bizarre that you seem to imply that once these concerns are > stated once - we should swallow it and accept a situation where these are not > addressed and documents are shoved through to last call in the face of > serious technical objection. > > So - please - clarify for me - are you asking us to swallow our objections > and just accept something that violates another rfc for which there is > consensus just because we asked once, and the issue wasn't addressed - so > that makes it somehow disappear? Or what exactly are you expecting of us? > > Andrew > > > On 07/12/2019, 01:02, "Ole Troan" <otr...@employees.org> wrote: > > > > > On 6 Dec 2019, at 22:09, Fernando Gont <fg...@si6networks.com> wrote: > > > > I don't think there is much room for interpretation here, but anyway I > > should ask: are you suggesting that I have attacked or been attacking > > the process? > > I would rather say taking advantage of the process. > > By reiterating the same assertive arguments again and again you > contribute to polarization. Your strategy for consensus building seems to be > one of attrition. > > If you want to help make the process work, I would encourage you to > reconsider that approach. > > Ole > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
