If you go through the minutes, you can count the number of statements for and those against, and it was fairly evenly divided, so it is totally fair and indeed accurate to say so. Here's my lists of Pros and cons.
Pros: ===== 1) Provides a single document (rather than vendor, SP or other SDO specific documents) for something that is fairly widely deployed. 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. 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. 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. 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. 5) This puts the burden of inter-working on the vendors that have gone the standards route 6) Successfully implementing inter-working is likely more work than implementing HI (i.e., carriers are wanting vendors to implement a standard that's yet to be clearly defined rather than implementing an existing RFC). 7) Interworking has a negative impact on capacity - i.e., overall it's more work to do the interworking than implement 4244 (although perhaps in this day and age this isn't so much an issue - in the old days, capacity was an important consideration). And, I'm not sure if this is a PRO or a CON, but this is a fine example of the ineffectiveness of RAI in some areas - Those of us that worked on History-Info would honestly have been perfectly happy had Diversion been accepted almost a decade ago, as we could have built upon that. It wasn't, so we orginally went in with a proposal that used a header that was planned to be standardized (remote-party-id). That idea was soundly rejected and the WG consensus was to develop a very general building block. So, the WG spent the usual several long and painful years developing RFC 4244. The most interesting aspect of this is that some of the folks most vehemently opposed to History-Info in the WG because it could be used for all these legacy services, now believe we should progress this document. Certainly, this based on the current business environment, but it's also an example of the philosophical split in the RAI area - some folks are here (as already noted) based on corporate objectives, others might be here to support corporate objectives, but they also believe in the fundamental e2e principles and still others have no corporate affiliation and thus may not need to compromise. So, it seems in the end, we're getting the worst of both worlds and it's exemplified with this document IMHO. That all said, if this document were written from a more general perspective of how to interwork legacy protocol information into History-Info, then I would support the work. But, interworking a proprietary SIP header with a standardized SIP header sets a horrible precendent IMHO. If another SDO wants to do so, then that's fine - I don't have any say in other SDOs and there's seems far more inline what many of them do regularly anyways. Regards, Mary. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, March 13, 2009 4:53 AM To: [email protected]; [email protected] Cc: [email protected] Subject: Re: [BLISS] TR: New Version Notification fordraft-mohali-diversion-history-info-01 Hi all, I can just say that it is true that in Dublin there was not a clear consensus but it is not fair to say "there was as much of an opposition as there was support to work on this." The opposition was on the fact that Diversion was not an IETF draft (as expired) but many people was saying that this argument was not valid because there is still the possibility to edit the draft as historical. Regards Marianne -----Message d'origine----- De : Shida Schubert [mailto:[email protected]] Envoyé : vendredi 13 mars 2009 01:01 À : Hadriel Kaplan Cc : MOHALI Marianne RD-CORE-ISS; Jason Fischl; [email protected] Objet : Re: [BLISS] TR: New Version Notification for draft-mohali-diversion-history-info-01 Hi Hadriel; As far as I know there was no clear consensus on the way forward of this draft, and as you may recall, there was as much of an opposition as there was support to work on this. Only thing I believe we agreed on was that, if we were to discuss the draft, we were to use BLISS mailing list until we know what we are doing. Regards Shida On 13-Mar-09, at 3:48 AM, Hadriel Kaplan wrote: > Hi Marianne and BLISS Chairs, > Why was this submitted as an individual-draft again and not a > Working-Group draft? > > Didn't we have consensus in Dublin to make this a BLISS WG Item? > > If we want to make History-Info the new white meat, we have to provide > a transition mechanism. That transition mechanism can either be done > differently by every system, or be done the same way. > > -hadriel _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
