Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RE] [REInterestGroup] 802.3 Residental Ethernet PAR: any MSC concerns?



Tom (and Michael),

I sense a few emotions in the discussions, but not many
definitions of terms. Maybe we're not all discussing
the same thing.

From my perspective, service discovery involves gaining
a detailed understanding of potential talker and listener
capabilities. This is a hard problem, technically and
organizationally.

When I worked on the HP-PA architecture, we attempted to
do this by providing processor-executable database access
code, and sometimes simple I/O drivers. Sun attempted to
do a similar thing with what (I believe) was called
Open BIOS, which were APIs to Forth code.

This is a very hard problem, and few organizations have
solved this well. For example, 100's of pages have been
used to describe printer characteristics, and these have
taken years of standards work of folks with printer-specific
knowledge. What is the dot size? Do dots overlap?
What is a cartridge-low indication? How many paper-jam
indications? What languages are supported? What versions
of ASCII are supported? And, the list goes on.

The key point is that its not hard to define some sort
of simple information-transfer protocol; that's the easy
part. Defining the content of what is transferred; that's
the hard part and _clearly_ not within the knowledge base
of 802.

An unfortunate problem is the difficulty of defining a
good information-transfer protocol, independently of the
content specification.

Also, any API has to provide mechanisms for sending
vendor-dependent content, such as diagnostics. Then,
where is the border line drawn between standard/required
and dependent/optional? Another hard problem.

Tom, is that also your definition of service discovery?
Are we talking about the same thing?

Perhaps Tom could provide some insights on what facilities
he envisions and how these could be implemented? Specific
words, even if included within a PAR, could mean quite
different things to different people.

DVJ

David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
      +1.650.856.9801
Cell: +1.650.954.6906
Fax:  +1.360.242.5508
Base: dvj@alum.mit.edu



>> -----Original Message-----
>> From: owner-stds-802-3-re@IEEE.ORG
>> [mailto:owner-stds-802-3-re@IEEE.ORG]On Behalf Of Thomas Dineen
>> Sent: Friday, March 11, 2005 9:32 PM
>> To: STDS-802-3-RE@LISTSERV.IEEE.ORG
>> Subject: Re: [RE] [REInterestGroup] 802.3 Residental Ethernet PAR: any
>> MSC concerns?
>>
>>
>> David And All:
>>
>> Actually your posting dose bring to mind a concern about the Re Par
>>  Many if not most of the members of the RE Study Group, or at least
>> a few loud ones, are against the development of a layer 2 Service
>> Discovery protocol for Re. Favoring instead to use previously developed
>> proprietary protocols. My concern lies in the concept that such
>> proprietary
>> protocols will almost certainly not be available to all
>> implementors under
>> reasonable non discriminatory terms. Leaving the future Re Industry in
>> something of a patent licensing quagmire. Many have suggested the
>> existence of layer 3 standard protocols is sufficient, but I disagree.
>> I believe that we need a clean Layer 2 only architecture to be
>> competitive.
>> So I advocate the inclusion of an objective probably in the 802.1 Re Par
>> to specify a Layer 2 Service Discovery Protocol. Further more I would
>> suggest that both the 802.3 and 802.1 PARs be held, without
>> consideration,
>> until the issue is resolved.
>>
>> Thomas Dineen