Thomas, [using your reply to continue my response...]
On Mon, Sep 29, 2014 at 02:44:46PM -0400, Thomas Narten wrote: > > It is NOT OK to tell anyone that they should not contribute a draft - > > because > > it may muddy the water > > or for ANY other non-technical reason.? Individual drafts or desire to > > request > > WG adoption do not change > > this.? I do not ever want to see or hear something like this on an IETF > > mailing list. > > Let me defend Acee here a bit and try to chart a course a bit more > down the middle. When a WG has an effort underway that is intended to > lead to a WG document (and that is what I read the current "design > team" effort to be), it is IMO often not helpful to have yet more IDs > submitted on the same topic. Rather than complementing the existing > work towards a concensus result, additional IDs can be a distraction > and require folk to spend time figuring out how the other ID relates > to the WG effort. I.e., it's much more constuctive to say "here is > what is defficient in the current model, and here is what I think we > should do instead". It is much less constructive to have a standalone > ID that (probably) overlaps with the other IDs and doesn't focus on > the *differences* from the other work that already has a head start. I generally agree, but would also offer a counter point: As we go through our standardization efforts in the various routing protocol modules, some of the vendors will have created an internal model of their implementation. Having such a model is highly useful in the sense that it provides an overall view of how a given implementation functions. The challenge that will come is taking our individual models and reconciling them to a common IETF model. Obviously OSPF at least has made some progress toward such an implementation. BFD has recently kicked off its yang modeling work. One of the things I recommended as we start our analysis is that we simply provide the inputs in the github repository that was established for the work (currently in a repository based from my account) all contributions that help establish configuration and operational context. We currently have the BFD MIBs along with a contribution from Huawei. Juniper will be contributing its BFD yang as well and we're expecting others. I'd suggest that it might be good for the other protocol yang work to establish practices for vendor models for comparison purposes. Choose whatever place - github, or the I-D repository - you find handy. :-) > It is the case that the IETF mantra is "submit a draft", but frankly, > I think that is a bit of a sound bite that we would do well to not > spit out as often as we seem to because it too often misses what > really should happen, namely, how best to contribute to reaching > consensus in a WG. We have a huge problem today where there are > overlapping/competing drafts that WGs have to sort through. In speaking with Sue, I don't believe there was any intended affront to existing efforts. I think you'll find her happy to help coordinate that analysis and generate appropriate diffs. And I think we'll also find the benefit of having the I2RS cases considered as part of that work. > In this case (and I personally don't have any skin in the game), it > seems to that both parties are making honest efforts to do the right > thing, but unfortunately, the state of play was not fully known to all. Exactly. I think the feeling of people "getting their toes stepped upon" comes from some over-reactions. Hopefully we'll reset our levels and continue working on good standards. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
