[Foip] [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt

[Gonzalo Salgueiro]

To all:

One of the ideas that we tossed around in today's meeting was merging the Fax Problem Statement that we have submitted to the IETF with the Problem Statement related to SIP/SDP Negotiation that Kevin has done so much work on.  The aim would be to address Cullen's statement:

> The more important part to publish IMHO is documenting some issues, problems, deficiencies and/or bugs in some IETF specifications that are leading to lack of interoperability in deployments. That type of problem statement would be great information to get written down in a concrete form that allows the appropriate WG to go fix the problems.

Does this group see value in combining these documents into a single one? Will it satisfy Cullen's concerns? Does it make sense for the FoIP TG to have a unified Problem Statement document?
I have added the thread with Cullen's comments below. Please review and provide feedback.

Thanks,

Gonzalo


On Feb 1, 2010, at 2:17 AM, Paul E. Jones wrote:

> Cullen,
> 
>> I'm trying to think about what we want to accomplish by publishing this
>> draft as an RFC. I was very happy to read the draft and think there is
>> some good stuff in it.
> 
> As an informational RFC, the objective would be nothing more than to
> document the issues that have been identified.  It does not try to address a
> problem, but merely raise awareness to issues in a manner similar to many
> other Informational RFCs over the years.
> 
>> The draft contains a mixture of things. Partially it is a liaison to
>> IETF from sipforum about what they are up to with a sipform work group.
> 
> You're right.  I think we should change some of the wording, especially the
> abstract.  The intent it not to be a liaison document, but it is intended to
> report on current state of affairs to the Internet community.
> 
>> This is great to get but I don't think there is much long term need to
>> record that in RFC form. The more important part to publish IMHO is
>> documenting some issues, problems, deficiencies and/or bugs in some
>> IETF specifications that are leading to lack of interoperability in
>> deployments. That type of problem statement would be great information
>> to get written down in a concrete form that allows the appropriate WG
>> to go fix the problems.
> 
> The challenge, I suppose, is that there are no IETF documents that we can
> fault.  There have been Internet Drafts written in the past that provide
> inaccurate information.  Perhaps they didn't at the time, but they have been
> implemented by vendors.
> 
> Having said that, the reason for wanting to publish this in the IETF is that
> there are a number of SIP devices that implement T.38 and problems exist in
> many of those implementations.  It's not a fault of SIP, but it is believed
> that there is value in providing this information to those developers.  It
> would also be of benefit to those deploying equipment.
> 
> Longer-term, it would only serve as a historical record in much the same way
> many Informational RFCs do.
> 
>> I do realize fax works by using protocols from multiple SDOs and that
>> does complicate things. I think it would be beneficial to document
>> specific problems found with IETF protocols. I'm less interested in the
>> IETF publishing problems with some other SDOs protocols.  You've caught
>> me at a particularly sensitive time having just spend 1/2 my time for
>> the last several months dealing with the IETF relationships with other
>> SDOs. And if anyone mentions royalty free fax algorithms my head might
>> explode :-)
> 
> We already have one: it's called PDF over SMTP. ;-)
> 
> I understand your point.  The issue is that, while some problems are
> inherent in T.38, there is a bigger issue and perhaps a "lesson to be
> learned" here: the Internet and gateways into legacy technology do not
> always fit well together.  Some of the problems with T.38 have to do with
> timers expiring due to multiple hops between IP network and PSTN network
> segments, for example.
> 
> While this is not IETF technology, it's not all technology of any SDO.  Fax
> issues have been something of joint interest by folks in both the ITU and
> IETF.  I recall folks actively working on this in both organizations in 1998
> and 1999.  More than a decade later, we see all of these issues with SIP
> networks that are now being deployed.
> 
> One day, this will all be behind us.  It will either be when the last PSTN
> GW is dismantled and buried, or when we all switch to something like the
> above mentioned royalty-free IP-based document transmission system. ;-)
> Until then (or perhaps as a driver for), we need to document the issues.  We
> also need to take steps to try to resolve them and, ideally, some folks in
> the IETF will help bring about change.
> 
>> So what I am getting at is could we move this draft more towards
>> something that documents what is observed in real world deployments and
>> discuss the problems with the existing IETF protocols, then WG Last
>> Call it in the appropriate WG(s) (I'm assuming things like mmusic,
>> fecframe, perhaps avt) and publish it as informational? The goal of
>> publishing it would be to provide a problem statement for future work
>> in theses WG.
> 
> I think we can remove some of the text that makes it sound too much like a
> liaison, but I don't think we can highlight issues with existing IETF texts
> and I don't think it would be appropriate to drive this through a WG to
> produce a standards-track document.
> 
>> Does that make sense to people? Reasonable path forward? I'm open to
>> other ideas but whatever we do, I would want to understand why
>> publishing whatever document we published was going to help make things
>> work better. And on that note, I'd like to express many thanks to SIP
>> Forum and all the people who worked on this effort for helping get fax
>> working better.
> 
> I think I heard crickets chirping.  Perhaps that's a bad sign, but I would
> like to hear more voices.  Folks who have tried to deploy fax equipment,
> either as a manufacturer or the end-user, surely has had some level of
> frustration with fax.  So, how do people feel about this document?
> 
> Paul
> 
>> Cullen
>> 
>> PS - Paul, thanks for trying to make less work and Dean, as punishment
>> for your sins I'm nominating you for AD to the next Nomcom :-)
>> 
>> On Jan 7, 2010, at 11:27 PM, Paul E. Jones wrote:
>> 
>>> Dean said:
>>>>> "AD Sponsored submissions represent a significant workload to the
>>>>> IESG."
>>>>> 
>>>> 
>>>> If the document is well enough drafted that it doesn't create a lot
>> of
>>>> work for the AD, then there isn't that much extra work.
>>>> 
>>>> One can also use an external document shepherd to make sure the doc
>> is
>>>> really "IESG ready" before the AD gets deeply into it. PaulK would
>> be
>>>> good at this ;-).
>>>> 
>>>> Besides, Cullen needs more work to do.
>>> 
>>> So, Paul K. and Cullen should each be made aware that you've given
>> them an
>>> assignment.  They'll thank you at the next meeting. ;-)
>>> 
>>> Paul
>>> 
>>> 
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore at ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>> 
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch at ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch