Re: ISPACs

[Brian Carpenter CERN-CN <[e-mail]>]

Paul raises an interesting meta-issue, but wherever it fits,
it isn't the cidrd list... maybe poised. When I have time, I'll
post the IAB's view on this to the poised list, but it's
not at the top of my priority list right now.

  Brian Carpenter

>--------- Text sent by Paul Resnick follows:
> 
> >Curtis Villamizar wrote (in part):
> >Regardless of whether or not it is a good business model,
> >RFCs are not the way to propose business models.
> 
> >Brian Carpenter wrote (in part): 
> >I said in the open IAB that the IAB has advised the IESG that
> >the IETF should not work on specific business models or practices,
> >but may and should work on mechanisms which will support various
> >business models.
> 
> A lot of IAB and IETF people are uncomfortable about the increasing
> discussion of business-related matters. I don't think either of the
> summaries above, however, capture the appropriate role for IETF.
> 
>    Nature of Innovation            Nature of implication
>    --------------------            ---------------------
> 1. Technical                       Technical
> 2. Technical                       Business
> 3. Business                        Technical
> 4. Business                        Business
> 
> Presumably everyone agrees that items of type 1 (technical innovation with
> technical implication) should be discussed at IETF and be written about in
> RFCs. 
> 
> Brian and Curtis imply that items of type 2 are also acceptable for IETF
> discussion.
> 
> I argue that we need also to include type 3, business innovations that have
> technical implications, such as number portability or scalable routing. It's
> my experience that technical people are often better at understanding
> business concepts than the reverse. As a result, we need to discuss,
> understand, and document the technical implications of business practices,
> rather than leaving these matters purely to the business types.
> 
> I agree that we should exclude items of type 4. That is, IETF need not
> discuss the business implications of a business innovation. That means, in
> this case, that we can ignore such questions as whether a business-savvy ISP
> should join an ISPAC. We should, however, point out the level of technical
> interdependence among ISPs in an ISPAC, as Justin Newton has done.
> 
> ------------------------------------------------------------
> Paul Resnick			AT&T Labs
> Public Policy Research		Room 2C-430A
> 908-582-5370 (voice)		600 Mountain Avenue
> 908-582-4113 (fax)		P.O. Box 636
> [e-mail]	Murray Hill, NJ 07974-0636
> http://www.research.att.com/~presnick
> 
>