Responses below [MB]. -----Original Message----- From: Hadriel Kaplan [mailto:[email protected]] Sent: Friday, March 13, 2009 9:57 AM To: Barnes, Mary (RICH2:AR00); [email protected]; [email protected] Cc: [email protected] Subject: RE: [BLISS] TR: New Version Notification fordraft-mohali-diversion-history-info-01
> -----Original Message----- > From: Mary Barnes [mailto:[email protected]] > Sent: Friday, March 13, 2009 10:19 AM > > Cons: > ====== > 1) In order for the document to be useful and accurate, it effectively > is standarizing the Diversion header. Diversion would need to be > registered, normative "i"s dotted and "t"s crossed, etc. You can't get around that. Of course you can. The Diversion draft can be submitted as historical for information only. I believe there's even precedence for this in the IETF, where proprietary protocols or extensions were documented simply so that people could figure out how to interwork away from them. [MB] I agree that they have indeed published proprietary protocols, but I am not at all aware of a case where they have published a new header for a protocol that provides the same functionality as a standardized header. Why will it not work for another SDO to describe Diversion and then just register the header? This doc could reference the other SDO document (there is a precendent for that). Indeed, even when docs are published by the RFC editor, the expert review requires consideration as to whether the work duplicates existing IETF work. Now, proprietary protocols can be considered okay, but this isn't a protocol we're talking about - it's a header. And, even with independent submissions, the IESG (per BCP 92) still checks for conflicts between the work of the IETF and the documents submitted. And, as far as I understand it (at least per today's process) "Historic" is not appropriate for this header - that's used for things that are obsolete. [/MB] > 2) Re-enforces the idea that what we do in standards isn't translating > to the real world - History-Info was there quite some time ago, but > folks chose not to implement. We need to be honest with ourselves about this. We screwed up. We took a really long time, making a more extensible/flexible/pretty mechanism, in a more general way, instead of solving the specific problem at hand. I think we've all expressed our frustration recently about this type of problem, and hopefully the re-org and new model will improve things. But that doesn't absolve us of responsibility for Diversion's prevalence. We can't go blame 3GPP or OMA or whatever for this - it was *us*. [MB] In this case, I'm not blaming other SDOs. The fault in my opinion is with the vendors that chose not to implement the standards and SPs that don't expect vendors to implement the standards. And, that's fine - if we want to say we messed up, then let's obsolete 4244 and jump back on the Diversion band wagon and extend it to do the other things we want to do. I just cannot see how having two ways to do the same thing enhances interoperability or maintainability in the long run. [/MB] > 3) Leading to my next point, that as Hadriel noted, this sets the > precendent for documenting all sorts of proprietary interworking (and > there's a lot of that). In my mind, this is just reverse engineering > the standards from product implementations, which is more the purview > of groups like SIP Forum or one of the Service Provider focused > organizations to provide guidelines on the Industry standards vs IETF > standards - there's already lots of cross-pollination amongst the > various organizations. If we want to do this (in IETF) we need to > acknowledge this is what we're doing, but it certainly doesn't seem to > be the charter of any of the current RAI WGs. If it were just one vendor that implemented it, I would find it a lot more troublesome in terms of precedence setting. But it wasn't one vendor. Many vendors implemented it. It's effectively a defacto standard. [MB] It was a trickle down thing - if vendor x wanted to I/W with vendor y that only implemented diversion, then vendor X had to implement it as well as did any other vendor that wanted to I/W with vendor Y, who for whatever reason didn't implement History-Info. IMHO, 4 or 5 years ago, this wouldn't have been a problem, but when a specs been out for 4+ years, then I think it's a different issue. I still can't fathom that none of these vendors have made any changes to their products in the past 4+ years, that they couldn't have added History-Info.[/MB] > 4) From a technical perspective, there is the potential for loss of > information when mapping from History-Info -> Diversion -> History-Info. > My suggestion would be to just carry both headers through the network. That won't work, and we discussed why that won't work in Dublin. [MB] The only reason I can see (as I don't recall the Dublin discussion) is that vendor y from my example doesn't want to change a line of code to do anything new. [/MB] > 5) This puts the burden of inter-working on the vendors that have gone > the standards route They already have that burden, because of how long it took us. The incumbent deployed legacy gear almost always has the upper hand in this regard. [MB] I don't agree - History-Info has been out for quite some time and again, I can't fathom that folks haven't made some enhancements to their products. Now, perhaps, no one told them, but then that's not the IETF's fault. [/MB] -hadriel _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
