RE: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing Draft(06)

["Tom Alexander" <[e-mail]>]

BMWGers,

I've been hearing some off-list rumblings that my previous comments relating
to 802.11 devices constituted some sort of objection to the hash and
stuffing draft. Nothing could be further from the truth.

I'm definitely in favor of the hash and stuffing draft, particularly as I
myself (in a previous life, building Ethernet switch chips) have been
repeatedly burned by the lack of a common understanding as to what
constituted good MAC addresses to use during testing. Putting this issue to
bed, in my mind, is a GOOD THING.

My comments were specifically in terms of the use of uncontrollably random
combinations of MAC/IP addresses in 802.11 testing. The issue here is fairly
small and specialized: to get 802.11 WLAN controllers to work consistently,
avoid different MAC addresses for the same IP address, or different IP
addresses for the same MAC address. Thus some degree of determinism and
control is required when generating the address combinations. If this can be
achieved, the use of pseudorandom address values for 802.11 testing is also,
in my view, a good thing.

I hope this clarifies the underlying intent of my comments.

Best regards,

- Tom A.

-----Original Message-----
From: David Newman [mailto:[e-mail]] 
Sent: Monday, November 13, 2006 1:12 PM
To: [e-mail]
Subject: Re: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing
Draft(06)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/13/06 12:26 PM, Romascanu, Dan (Dan) wrote:
> David,
> 
> So I  understand from your response that you agree that the scope of the
> document is not Ethernet-only.

Yes. Given that section 4.3 already covers MPLS, a L2.5-ish technology,
I'd say we're already well on the way there.

> In this case please confirm whether you
> will be changing as I suggested the name and the text in the first
> paragraph of Section 4.2 so that it is not Ethernet-specific. 

I have a clarification question and a process question about this:

Clarification question: As previously noted no change is needed for the
802.11 example you cited, since 802.3 and 802.11 share a common address
format. Thus I am not altogether clear on what would change in section 4.2.

One possible strategy would be:

a. retitle section 4.2 "Link Layer Addresses"

b. substitute "link layer" for "Ethernet" in most instances in that
section's text except where making Ethernet-specific comments; and

c. add a sentence along the lines of what you originally suggested, such
as "Benchmarking efforts many different link-layer technologies. While
the examples given in this section use 802.3 Ethernet, the same concepts
of pseudo-randomization apply to other link-layer technologies."

OK with you?

Process question: This ID is now out of last call. What's the drill for
modifying documents that have passed out of last call? Specifically,
does the change you've requested mean another cycle of ID numbers and
another last call?

(This document began life as a simple "app note" at IETF 60 in December
2003. I would imagine that many subscribers to this list would be
delighted if their managers allowed them three years to write an app
note...)

dn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFFWN+jyPxGVjntI4IRAoY8AKCQVsin2SK0QvtsehAHOYSYonFecwCfWVaP
NGjl8aL/aMfxWr3gJNc04Cg=
=rzEH
-----END PGP SIGNATURE-----

_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg


_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg