Re: [RE] [REInterestGroup] 802.3 Residental Ethernet PAR: any MSC concerns?
Dear all,
As outsider to this group , I am not expressing an opinion (although I
would be personally in favor of comments like Jim's, for complete discovery
to be made through UPnP/DLNA) here but could someone relates/comments on
simultaneous use by future RE standard for topology discovery using
layer 2 discovery : IEEE 802.1AB currently nearing completion?
(system description TLV would allow bridge/station discrimination for
instance)
Has discussion between the two groups being held?
Philippe Boucachard
> Tom-
>
> You are free to use your one vote to oppose "all ResE PARs" forwhatever reason you choose. Also, as a voting member of 802.3 you areguaranteed reasonable access to the forum to express your views.
>
> However, in my opinion, your rationale for opposition is badly flawed onat least two counts:
> 1) There is no requirement whatsoever in the IEEE P&P to addressIP issues at PAR request time. To the best of my knowledge there has beenno statement of non-availability of IP for essential material for theproposed project. The IEEE requirement is that assurance letters beprovided before submittal to REVCOM (not NESCOM), although "EarlyDisclosure is encouraged".
>
> 2) 802.3 provides layer standards in support of products. It does notdo standards for complete products nor does it pretend to do so. Yourassertion that 802.3 can not generate a standard because (you assert)that it can't standardize a piece of the required product solution piecethat is outside the scope of 802.3 (and arguably outside the scope of802) is nonsensical. Further, I see no evidence that any one party has alock on the required technology that you refer to. Therefore, there is aset of choices to be made and those choices are not appropriate for 802.3work.
>
> I believe that, given these considerations, your only appropriategrounds for objection would be that these problems which are outside 802scope would have a sufficiently large impact on the 5 Criteria to damagethe viability of the project. My own guess is that is unlikely to betrue.
>
> Sincerely,
>
> Geoff Thompson
>
>
> At 08:57 AM 3/12/2005 -0800, Thomas Dineen wrote:
> Michael:
>
> Where there is smoke there is fire!!!!! Your verybehavior on
> this issue has caused me to take it up as a concern!
>
> Your discussion shown below, while interesting, isirrelevant
> in that it details a list of layer 3 and above IETF public domainprotocols,
> some of which by your own admission have patent issues.
>
> My concern is entirely focused on the requirement for apublic
> domain layer 2 solution available under reasonable andnon-discriminatory
> terms. This will allow for low cost and low complexity layer 2 onlysolutions.
> This concept will allow for layer 3 agnostic implementations, or forthat
> matter implementations without layer 3 and its significant overhead.After all
> did that cheap ResE Speaker or cheap ResE Stereo really need an IPAddress????
> Do these low cost implementations really need to support the entire TCP /IP
> Protocol stack?
>
> I plan to oppose all ResE PARs until this issue isresolved.
>
> Thomas Dineen
>
> Michael Johas Teener wrote:
>
> Thomas,
>
> As one of the "loud" ones, I wish you would stop persisting in
> your claim
> that the discovery mechanisms that already exist are
> "proprietary" and
> "almost certainly not available to all implementers under RAND
> (reasonable
> and non-discriminatory) terms". I have noted a number of times in
> your
> presence, with your acknowledgement, there are a number of IETF
> discovery
> systems in place (free, and following IETF rules) including SLP (rfc2608
> and
> its derivatives), DDDS (rfc3958) and multicast-DNS/DNS-SD
> (www.dns-sd.org,
> based on rfc2782). There are *many* others (too many, really).
>
> The industry is moving towards a UPnP-based system which, while based
> on
> various RFCs, is somewhat unique, and is a bit encumbered with IP
> issues.
> This issues, however, have NOTHING to do with RAND (all parties are
> committed to RAND ... and indeed to *free* licensing).
>
> There are NO, repeat NO "proprietary" protocols involved in all
> this. If you
> know of one, please be specific. I'm involved with at least three
> industry
> efforts, and I find myself at a loss to understand your insistence that
> there is a problem.
>
> Finally, why do we need a layer 2 service discovery protocol to be
> "competitive"? With whom? The only kind of discovery a layer 2
> protocol
> needs is one that is required by the protocol itself ... such as a
> common
> synchronization source or "grand master" as it's called in IEEE
> 1588. Beyond
> that, we are getting into some rather major layering issues ...
>
> On 3/11/05 9:31 PM, "Thomas Dineen"
> <tdineen@IX.NETCOM.COM>
> wrote:
>
> 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 leasta few loud ones, are against the development of a layer 2 ServiceDiscovery protocol for Re. Favoring instead to use previously developedproprietary protocols. My concern lies in the concept that such proprietaryprotocols will almost certainly not be available to all implementors underreasonable non discriminatory terms. Leaving the future Re Industry insomething of a patent licensing quagmire. Many have suggested theexistence 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 Parto specify a Layer 2 Service Discovery Protocol. Further more I wouldsuggest that both the 802.3 and 802.1 PARs be held, without consideration,until the issue is resolved.Thomas Di!
neen