Subject: Re: [dispatch] Revisionofdraft-allen-dispatch-imei-urn-as-instanceid

From: Henry Sinnreich <[email-masked]>
Date: Thu, 10 Mar 2011 11:03:01 -0600

Hi Andrew,

I have generic objections to see the publication of yet another
informational RFC about practices in consortiums of closed networks in the
IETF, for the following reasons:

* Using the RFC process as a publishing venue for organizations that don't
explicitly do that in support of the open e2e Internet.

* The resources of the IETF are not unlimited, meeting time and email time
to discuss is scarce and the IETF registries are just not scalable enough to
support registrations for all the extensions that benefit countless external
organizations and companies that deploy Internet technology.
New business plans and the required extensions pop up in an endless fashion.
Big organizations such as you mention have their own resources to publish
their internal technical documents and white papers if they desire to do so.

Members of outside organizations are certainly doing everybody a good
service by informing via email of new standards/extensions in other
organization, such as you have done below, but such information need not
overload the Internet RFC process nor overload the Internet registries.

* Hard for SIP developers and right out impossible for application
developers.
Though SIP works fine indeed across the world; SIPit and the SIP Forum
take care of unavoidable problems still encountered by operators, arguably
increasing SIP complexity for non-Internet purposes is not a good idea, even
if new SIP extensions are labeled as just "informational". It makes it even
more difficult for new developers entering the field to ever understand, let
alone write code for some or all that has been published already about SIP
for example. Checking right now there are 197 RFCs matching SIP and 78 I-Ds
found by the RFC search engine.

It is time to leave SIP alone and move on to other critical areas for the
Internet, such as for example the future of applications that will be
discussed in the next IETF technical plenary on Monday, March 28.

With this in mind, I would rather not go into discussing your I-D in detail,
though at first glance it seems technically correct and if it were discussed
on the list, may indeed technically qualify as an informational RFC - just
what I am arguing against.

These are all personal opinions. The chairs and ADs may or may not discuss
or agree/disagree with. Your I-D is just a good opportunity to raise these
issues. 

Note that I am not suggesting any voting on your I-D, if it will be
discussed, since for various reasons, the majority of folks attending the
DISPATCH WG are from various outside organizations with business plans that
may or may not fully embrace the open e2e Internet; a perfect legitimate
choice for them, but not  in the IETF (I just can't remember when ever there
was a vote against any new I-D for SIP, since no cost was perceived by those
voting).

Thanks,
Henry 

On 3/9/11 5:45 PM, "Andrew Allen" <[email-masked]> wrote:

> 
> Henry
> 
> Would you care to elaborate and explain your specific concerns?  How is what
> is defined in these drafts potentially incompatible with the open, e2e
> architectural and in any other way technical conflict with the Internet?
> 
> The two drafts do the following things:
> 
> One draft simply defines and registers with IANA a URN namespace according to
> the procedures defined for doing that.
> 
> The other draft simply defines how this URN can be used as an instance ID as
> required by RFC 5626.
> 
> SIP and the mechanisms in RFC 5626 are already being used in networks defined
> by 3GPP and are being deployed by members of the GSMA. 3GPP and GSMA have
> already defined this behavior using their existing device Identifiers for
> instance ID generation in their specifications. These drafts complete the
> process doing things the right way by reserving the namespace and defining the
> usage of it using the IETF defined mechanisms for doing that.
> 
> Andrew
> 
> ----- Original Message -----
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Wednesday, March 09, 2011 03:10 PM
> To: Itsuma TANAKA <[email-masked]>; [email-masked]
> <[email-masked]>
> Subject: Re: [dispatch] Revisionofdraft-allen-dispatch-imei-urn-as-instanceid
> 
> Such work in the IETF would require IMO an explanation about its
> compatibility with the open, e2e architectural and other technical
> principles of the Internet. It actually seems to be the opposite.
> 
> For this reason, such work may be better accomplished in other
> organizations, so as to avoid architectural principle and other technical
> conflicts. Simplicity and scalability comes to mind among other, though this
> is better discussed elsewhere.
> 
> Thanks,
> 
> Henry Sinnreich
> 
> 
> On 3/9/11 8:54 AM, "Itsuma TANAKA" <[email-masked]> wrote:
> 
>> Dear All,
>> 
>> I work for NTT DOCOMO, Inc in Japan. and attend various 3GPP meetings (SA2,
>> CT1, CT4, and CT3) and GSM Association (GSMA) Interworking, Roaming Expert
>> Group (IREG), Roaming in LTE (RILTE) and Packet subgroup meetings.  I serve
>> as a Vice Chair of GSMA IREG RILTE and Packet subgroups.
>> 
>> I would like to express my support of draft-montemurro-gsma-imei-urn and the
>> associated draft-allen-dispatch-imei-urn-as-instanceid.
>> 
>> The reasons are exactly same as what Ricky Kaura (Samsung) expressed.  A
>> various 3GPP specifications (IMS Registration in 3GPP TS24.229, IMS
>> emergency calls in TS23.237 and TS24.237, ICS in TS23.292 and TS24.292), and
>> GSMA document (GSMA PRD IR.92, "IMS Profile for Voice and SMS") are using
>> these drafts.
>> 
>> These internet drafts are very important to support various key features in
>> 3GPP and to enable GSMA Voice over LTE.  Therefore, I kindly would like ask
>> that this work is progressed as quickly as possible in IETF.
>> 
>> 
>> Best regards,
>> 
>> Itsuma Tanaka
>> NTT DOCOMO
>> 
>> 
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this transmission
> by unintended recipients is not authorized and may be unlawful.

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 10 Mar 2011 17:41:12 +0000

Hi Henry,
 um ...
i. Votes in the IETF; did I miss this, or is this another change
   like actively barring entry to meetings for deadbeats?

ii. Information is good.
   I for one have no axe to grind on this, but believe that this is a service to the Internet community.
   Reporting how things work in the real world has been a long-term feature of the informational track (as you know).

iii. The fact that imei format is used and can be tied to URNs and IIDs seems to me to be both
   a valid and reasonable idea.
   *Requiring* that to be done is a different page of the book, but this is NOT a standards track doc.
   How GSMA spectrum members want to run their networks is not an IETF topic (viz CONDOR, ...).
   That war was decided waaaaay back -- you were there for that as well :).

   Your comments on lack of e2e operation (i.e. if this is not in SIP messages they will be
   treated "differently"/with extreme prejudice) is at the very least reasonable, but that
   addresses the general topic of the IETF as an SDO, rather than being tied to this draft.

iv. you say that SIP time should not be taken up with registrations -- that's the iid registration process.
  There's a registration doc that has (if one is fortunate) a "how this is used by xxx".
  So ... this should "go through on the nod". You have said that it appears to be technically valid.

  Q: Are you arguing that the iid registration process should be changed?

all the best,
 Lawrence
--
What comes up must come down.
"Not my department", says Werner Von Braun

---

From: "Andrew Allen" <[email-masked]>
Date: Thu, 10 Mar 2011 16:04:09 -0600

Hi Henry,

I think then that it's a fair summary of your email to say that your
objections are of a political and philosophical nature related to your
view of what constitutes the internet and whether the IETF should be
involved in enhancing IETF protocols for stakeholders that utilize those
IETF protocols for deployments that some in the community might not
consider "the Internet" or "the pure Internet" or the "open e2e
Internet" rather than technical issues with the contents of the drafts.

While I don't want to start a general debate on what is "the Internet"
here I will state that in my view it's very difficult to exclude any
particular stakeholders and their deployments of IETF protocols from
being part of the Internet when those stakeholders are in many cases the
very same established telecommunications companies or ISPs that the vast
majority of the population in most countries use to obtain access to the
Internet. 

My understanding also is that IETF nearly a decade ago agreed to
cooperate with 3GPP (and other standards bodies) in developing and
enhancing internet protocols and that IETF specifically requested (more
like insisted) that any extensions or enhancements to IETF protocols
required by 3GPP be done within IETF according to the procedures defined
by IETF for enhancing IETF protocols and for registering namespaces etc.
These drafts simply comply with that agreed way of working between IETF
and 3GPP. To my knowledge this working agreement is still in effect. I
don't think it is the role of the dispatch WG to determine which
applications or deployments of SIP to support or cooperate with counter
to agreements previously made at IESG level.

Refusing cooperation based on what is considered not to be part of the
"open e2e Internet" is only likely to set up two (or more) competing
versions of the Internet resulting in the 21st century equivalent of the
standard rail gauge vs broad rail gauge communications interoperability
issue from the 19th century - effectively killing the goal of an open
e2e internet! As Dale indicated what is considered a walled garden today
may not be walled in the future (if I remember some very significant
walls came tumbling down during just the last decade of the 20th century
alone).

Different business models will be resolved through the market not by
creating competing incompatible technical solutions. 

In terms of the time used on discussion within dispatch I don't think
there is a need for much more discussion in dispatch. These drafts could
go ahead as AD sponsored without further WG involvement. As I understand
it the IMEI URN definition draft did not as part of the URN registration
process need to even be discussed in dispatch at all (although Dale
Worley's review was invaluable in improving the draft technically) as
the NIDs list was the fora for this discussion and where previous
versions of that draft were discussed.

It should be noted all we are talking about with regard to these drafts
is the registration of a URN namespace and definition of its usage as an
Instance ID as required by RFC 5626. If we can't agree that then what
future extensions can we agree?

Andrew

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Thursday, March 10, 2011 11:03 AM
To: Andrew Allen; [email-masked]; [email-masked]
Subject: Re: [dispatch]
Revisionofdraft-allen-dispatch-imei-urn-as-instanceid

Hi Andrew,

I have generic objections to see the publication of yet another
informational RFC about practices in consortiums of closed networks in
the
IETF, for the following reasons:

* Using the RFC process as a publishing venue for organizations that
don't
explicitly do that in support of the open e2e Internet.

* The resources of the IETF are not unlimited, meeting time and email
time
to discuss is scarce and the IETF registries are just not scalable
enough to
support registrations for all the extensions that benefit countless
external
organizations and companies that deploy Internet technology.
New business plans and the required extensions pop up in an endless
fashion.
Big organizations such as you mention have their own resources to
publish
their internal technical documents and white papers if they desire to do
so.

* Hard for SIP developers and right out impossible for application
developers.
Though SIP works fine indeed across the world; SIPit and the SIP Forum
take care of unavoidable problems still encountered by operators,
arguably
increasing SIP complexity for non-Internet purposes is not a good idea,
even
if new SIP extensions are labeled as just "informational". It makes it
even
more difficult for new developers entering the field to ever understand,
let
alone write code for some or all that has been published already about
SIP
for example. Checking right now there are 197 RFCs matching SIP and 78
I-Ds
found by the RFC search engine.

It is time to leave SIP alone and move on to other critical areas for
the
Internet, such as for example the future of applications that will be
discussed in the next IETF technical plenary on Monday, March 28.

With this in mind, I would rather not go into discussing your I-D in
detail,
though at first glance it seems technically correct and if it were
discussed
on the list, may indeed technically qualify as an informational RFC -
just
what I am arguing against.

These are all personal opinions. The chairs and ADs may or may not
discuss
or agree/disagree with. Your I-D is just a good opportunity to raise
these
issues. 

Note that I am not suggesting any voting on your I-D, if it will be
discussed, since for various reasons, the majority of folks attending
the
DISPATCH WG are from various outside organizations with business plans
that
may or may not fully embrace the open e2e Internet; a perfect legitimate
choice for them, but not  in the IETF (I just can't remember when ever
there
was a vote against any new I-D for SIP, since no cost was perceived by
those
voting).

Thanks,
Henry 

On 3/9/11 5:45 PM, "Andrew Allen" <[email-masked]> wrote:

> Subject: Re: [dispatch]
Revisionofdraft-allen-dispatch-imei-urn-as-instanceid

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Mar 2011 07:57:05 +0100

Hi,

I agree with Andrew.

People have invested, and are investing, lots of resources into SIP based systems. They are not suddently going to throw everything away just because some people in IETF suddently thinks there are more "fun and sexy" stuff to work on than SIP...

Also, regarding the agreement between IETF and 3GPP, if people have issues with that agreement I don't think that people who are working based on that agreement should have to suffer.

Instead, people having issues with the agreement should bring those issues to a more appropriate instance.

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew Allen
> Sent: 11. maaliskuuta 2011 0:04
> To: Henry Sinnreich; [email-masked]; [email-masked]
> Subject: Re: [dispatch] 
> I think then that it's a fair summary of your email to say 
> that your objections are of a political and philosophical 
> nature related to your view of what constitutes the internet 
> and whether the IETF should be involved in enhancing IETF 
> protocols for stakeholders that utilize those IETF protocols 
> for deployments that some in the community might not consider 
> "the Internet" or "the pure Internet" or the "open e2e 
> here I will state that in my view it's very difficult to 
> exclude any particular stakeholders and their deployments of 
> IETF protocols from being part of the Internet when those 
> stakeholders are in many cases the very same established 
> telecommunications companies or ISPs that the vast majority 
> of the population in most countries use to obtain access to 
> the Internet. 
> 
> My understanding also is that IETF nearly a decade ago agreed 
> to cooperate with 3GPP (and other standards bodies) in 
> developing and enhancing internet protocols and that IETF 
> specifically requested (more like insisted) that any 
> extensions or enhancements to IETF protocols required by 3GPP 
> be done within IETF according to the procedures defined by 
> IETF for enhancing IETF protocols and for registering namespaces etc.
> These drafts simply comply with that agreed way of working 
> between IETF and 3GPP. To my knowledge this working agreement 
> is still in effect. I don't think it is the role of the 
> dispatch WG to determine which applications or deployments of 
> SIP to support or cooperate with counter to agreements 
> previously made at IESG level.
> 
> Refusing cooperation based on what is considered not to be 
> part of the "open e2e Internet" is only likely to set up two 
> (or more) competing versions of the Internet resulting in the 
> 21st century equivalent of the standard rail gauge vs broad 
> rail gauge communications interoperability issue from the 
> 19th century - effectively killing the goal of an open e2e 
> internet! As Dale indicated what is considered a walled 
> garden today may not be walled in the future (if I remember 
> some very significant walls came tumbling down during just 
> the last decade of the 20th century alone).
> 
> Different business models will be resolved through the market 
> not by creating competing incompatible technical solutions. 
> 
> In terms of the time used on discussion within dispatch I 
> don't think there is a need for much more discussion in 
> dispatch. These drafts could go ahead as AD sponsored without 
> further WG involvement. As I understand it the IMEI URN 
> definition draft did not as part of the URN registration 
> process need to even be discussed in dispatch at all 
> (although Dale Worley's review was invaluable in improving 
> the draft technically) as the NIDs list was the fora for this 
> discussion and where previous versions of that draft were discussed.
> 
> It should be noted all we are talking about with regard to 
> these drafts is the registration of a URN namespace and 
> definition of its usage as an Instance ID as required by RFC 
> 5626. If we can't agree that then what future extensions can we agree?
> 
> Andrew
> 
> I have generic objections to see the publication of yet 
> another informational RFC about practices in consortiums of 
> closed networks in the IETF, for the following reasons:
> 
> * Using the RFC process as a publishing venue for 
> organizations that don't explicitly do that in support of the 
> open e2e Internet.
> 
> * The resources of the IETF are not unlimited, meeting time 
> and email time to discuss is scarce and the IETF registries 
> are just not scalable enough to support registrations for all 
> the extensions that benefit countless external organizations 
> and companies that deploy Internet technology.
> Big organizations such as you mention have their own 
> resources to publish their internal technical documents and 
> white papers if they desire to do so.
> 
> Members of outside organizations are certainly doing 
> everybody a good service by informing via email of new 
> standards/extensions in other organization, such as you have 
> done below, but such information need not overload the 
> Internet RFC process nor overload the Internet registries.
> 
> * Hard for SIP developers and right out impossible for 
> application developers.
> Though SIP works fine indeed across the world; SIPit and the 
> SIP Forum take care of unavoidable problems still encountered 
> by operators, arguably increasing SIP complexity for 
> non-Internet purposes is not a good idea, even if new SIP 
> extensions are labeled as just "informational". It makes it 
> even more difficult for new developers entering the field to 
> ever understand, let alone write code for some or all that 
> has been published already about SIP for example. Checking 
> right now there are 197 RFCs matching SIP and 78 I-Ds found 
> by the RFC search engine.
> 
> It is time to leave SIP alone and move on to other critical 
> areas for the Internet, such as for example the future of 
> applications that will be discussed in the next IETF 
> technical plenary on Monday, March 28.
> 
> With this in mind, I would rather not go into discussing your 
> I-D in detail, though at first glance it seems technically 
> correct and if it were discussed on the list, may indeed 
> technically qualify as an informational RFC - just what I am 
> arguing against.
> 
> These are all personal opinions. The chairs and ADs may or 
> may not discuss or agree/disagree with. Your I-D is just a 
> good opportunity to raise these issues. 
> 
> Note that I am not suggesting any voting on your I-D, if it 
> will be discussed, since for various reasons, the majority of 
> folks attending the DISPATCH WG are from various outside 
> organizations with business plans that may or may not fully 
> embrace the open e2e Internet; a perfect legitimate choice 
> for them, but not  in the IETF (I just can't remember when 
> ever there was a vote against any new I-D for SIP, since no 
> cost was perceived by those voting).
> 
> Thanks,
> Henry 
> 
> 
> > The other draft simply defines how this URN can be used as 
> an instance
> ID as
> > required by RFC 5626.
> > 
> > SIP and the mechanisms in RFC 5626 are already being used 
> in networks
> defined
> > already defined this behavior using their existing device 
> Identifiers
> for
> > instance ID generation in their specifications. These 
> drafts complete
> the
> >> I work for NTT DOCOMO, Inc in Japan. and attend various 
> 3GPP meetings
> (SA2,
> >> Group (IREG), Roaming in LTE (RILTE) and Packet subgroup 
> meetings.  I
> serve
> >> I would like to express my support of 
> draft-montemurro-gsma-imei-urn
> and the
> >> The reasons are exactly same as what Ricky Kaura (Samsung) 
> expressed.
> A
> This transmission (including any attachments) may contain 
> confidential information, privileged material (including 
> material protected by the solicitor-client or other 
> applicable privileges), or constitute non-public information. 
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender 
> and delete this information from your system. Use, 
> dissemination, distribution, or reproduction of this 
> transmission by unintended recipients is not authorized and 
> may be unlawful.

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 11 Mar 2011 11:28:53 -0600

Hi Andrew, Christer,

>> enhancing internet protocols

3GPP etc. documents are best served by having them online, up-to-date, on
their respective web sites, where they can be searched and studied.
Using IETF RFCs for this seems rather odd, and certainly less effective.

>some people in IETF suddently thinks there are more "fun and sexy" stuff to
>work on than SIP...

As mentioned, after 100's of SIP RFCs and I-Ds over 12+ years, almost all
SIP apps are telephony features, while 100,000s of apps are all using HTML,
some of them to communicate in new ways - quite different from the SIP
telephone call signaling models. RTC-Web may or may not be based on SIP
signaling _alone_ , if at all. Communication models and user habits have
changed very much (and are still changing) since SIP has been defined.

Don't you think we have a problem here?
If yes, wouldn't listening to the IETF technical plenary presentation on the
future of applications be a good start to address the challenge for SIP
applications?

What do you think?

Henry

On 3/11/11 12:57 AM, "Christer Holmberg" <[email-masked]>
wrote:

> 
> Hi,
> 
> I agree with Andrew.
> 
> People have invested, and are investing, lots of resources into SIP based
> systems. They are not suddently going to throw everything away just because
> some people in IETF suddently thinks there are more "fun and sexy" stuff to
> work on than SIP...
> 
> Also, regarding the agreement between IETF and 3GPP, if people have issues
> with that agreement I don't think that people who are working based on that
> agreement should have to suffer.
> 
>> confidential

---

From: Mary Barnes <[email-masked]>
Date: Fri, 11 Mar 2011 13:27:28 -0600

Hi Henry,

I'll make just a few comments on this discussion thread, as I don't think
it's a productive discussion on this mailing list - likely it would be
better on the ietf-discussion list or you might want to approach someone on
the IAB about this topic, since the IAB is the responsible party in
establishing and appointing liaisons.

However, as far as the 3gpp specs that are all online, fairly up-to-date as
best as I can tell:
http://www.3gpp.org/-specifications-

As you puruse the specs, you will find that 3gpp uses a number of the specs
in the exact same manner as do "e2e" implementations.  So, I don't think the
situation is as dire as it might appear.  We can debate this topic ad
naseum, but IMS is what it is and is being deployed and nothing any of us
say or think here will change that.  The reality is that a large number of
contributors to the e2e specs are here because the folks that pay them to
contribute to the IETF make money selling those systems.  I will also note
that folks that aren't interested in IMS can use your document that was
published as a baseline "e2e" SIP implementation:
http://tools.ietf.org/html/rfc5638

There is also a spreadsheet of IETF dependencies that is regularly updated
and it includes references to the specs that depend upon core IETF RFCs:
http://www.3gpp.org/-IETF-Dependencies-and-Priorities-

I will note that summaries of issues and actions related to the RAI area
documents has been posted on the RAI area mailing list in the past:
http://www.ietf.org/mail-archive/web/rai/current/msg00955.html
So, I think there has been a reasonable amount of transparency with regards
to this working relationship. Since this relationship between 3GPP and IETF
has been in place, there have been a number of documents that have been
approved and in general it has been a fruitful relationship on both parts.
 In some cases, core changes were made to SIP that benefited both the e2e
model and the walled garden.

Regards,
Mary.

On Fri, Mar 11, 2011 at 11:28 AM, Henry Sinnreich <[email-masked]

> > Instead, people having issues with the agreement should bring those
> issues to
> > a more appropriate instance.
> >
> > Regards,
> >
> > Christer
> >
> >

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 11 Mar 2011 14:45:17 -0600

Thanks Mary!

The same actually came to my mind as well.

Henry

On 3/11/11 1:27 PM, "Mary Barnes" <[email-masked]> wrote:

> Hi Henry, 
> 
> I'll make just a few comments on this discussion thread, as I don't think it's
> a productive discussion on this mailing list - likely it would be better on
> the ietf-discussion list or you might want to approach someone on the IAB
> about this topic, since the IAB is the responsible party in establis

---

From: "Andrew Allen" <[email-masked]>
Date: Sat, 12 Mar 2011 16:53:25 -0600

Henry

I think Mary has covered this all very well.

I am happy to engage in further philosophical discussions on the future of the Internet in Prague.

Andrew

From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, March 11, 2011 01:27 PM
To: Henry Sinnreich <[email-masked]> 
Cc: Christer Holmberg <[email-masked]>; Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]> 
Subject: Re: [dispatch] Revisionofdraft-allen-dispatch-imei-urn-as-instanceid 

Hi Henry, 

I'll make just a few comments on this discussion thread, as I don't think it's a productive discussion on this mailing list - likely it would be better on the ietf-discussion list or you might want to approach someone on the IAB about this topic, since the IAB is the responsible party in establishing and appointing liaisons. 

However, as far as the 3gpp specs that are all online, fairly up-to-date as best as I can tell:
http://www.3gpp.org/-specifications-

As you puruse the specs, you will find that 3gpp uses a number of the specs in the exact same manner as do "e2e" implementations.  So, I don't think the situation is as dire as it might appear.  We can debate this topic ad naseum, but IMS is what it is and is being deployed and nothing any of us say or think here will change that.  The reality is that a large number of contributors to the e2e specs are here because the folks that pay them to contribute to the IETF make money selling those systems.  I will also note that folks that aren't interested in IMS can use your document that was published as a baseline "e2e" SIP implementation: http://tools.ietf.org/html/rfc5638

There is also a spreadsheet of IETF dependencies that is regularly updated and it includes references to the specs that depend upon core IETF RFCs:
http://www.3gpp.org/-IETF-Dependencies-and-Priorities-

I will note that summaries of issues and actions related to the RAI area documents has been posted on the RAI area mailing list in the past:
http://www.ietf.org/mail-archive/web/rai/current/msg00955.html
So, I think there has been a reasonable amount of transparency with regards to this working relationship. Since this relationship between 3GPP and IETF has been in place, there have been a number of documents that have been approved and in general it has been a fruitful relationship on both parts.  In some cases, core changes were made to SIP that benefited both the e2e model and the walled garden.  

Regards,
Mary. 

On Fri, Mar 11, 2011 at 11:28 AM, Henry Sinnreich <[email-masked]> wrote:

	Hi Andrew, Christer,

	
	
	What do you think?
	
	Henry

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 13 Mar 2011 11:31:51 -0500

Hi Andrew,

Yes, chatting at the IETF would be interesting, though there is nothing
philosophical in the overwhelming hard numbers and trends in the market for
all industry segments driven by applications. And the Web platforms for
these applications.

Henry

On 3/12/11 5:53 PM, "Andrew Allen" <[email-masked]> wrote:

> Cc: Christer Holmberg <[email-masked]>; Andrew Allen;
> [email-masked] <[email-masked]>; [email-masked]
> <[email-masked]>
> about this topic, since the IAB is the responsible party in establishing and
> appointing liaisons. 
> 
> As you puruse the specs, you will find that 3gpp uses a number of the specs in
> the exact same manner as do "e2e" implementations.  So, I don't think the
> situation is as dire as it might appear.  We can debate this topic ad naseum,
> but IMS is what it is and is being deployed and nothing any of us say or think
> here will change that.  The reality is that a large number of contributors to
> the e2e specs are here because the folks that pay them to contribute to the
> IETF make money selling those systems.  I will also note that folks that
> aren't interested in IMS can use your document that was published as a
> baseline "e2e" SIP implementation: http://tools.ietf.org/html/rfc5638
> 
> There is also a spreadsheet of IETF dependencies that is regularly updated and
> it includes references to the specs that depend upon core IETF RFCs:
> So, I think there has been a reasonable amount of transparency with regards to
> this working relationship. Since this relationship between 3GPP and IETF has
> been in place, there have been a number of documents that have been approved
> and in general it has been a fruitful relationship on both parts.  In some
> cases, core changes were made to SIP that benefited both the e2e model and the
> walled garden.  
> 
> Regards,
> Mary. 
> 
>>> > Instead, people having issues with the agreement should bring those issues
>>> to