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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 13 Nov 2006 22:26:20 +0200

David,

So I  understand from your response that you agree that the scope of the
document is not Ethernet-only. 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. 

Dan

> -----Original Message-----
> From: David Newman [mailto:[email-masked]] 
> Sent: Wednesday, November 08, 2006 5:36 PM
> Cc: [email-masked]
> Subject: Re: [bmwg] 3rd WG Last Call on Address Hash and Bit 
> Stuffing Draft(06)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Romascanu, Dan (Dan) wrote:
> > In general I believe that the draft is ready for submission 
> to the IESG.
> > I have a few non-critical comments that I believe should be 
> taken into 
> > consideration in a future revision of the document, but prior to 
> > approval by the IESG.
> > 
> > 1. Terminology and Acronyms - the document could benefit 
> from a short 
> > terminology section. Also, there is broad usage of 
> acronyms, without 
> > acronym explanation in a separate section or expansion at first 
> > occurrence 2. Section 2 refers to Ethernet MAC addresses. Actually 
> > BMWG documents that fall under the scope of this document 
> could cover 
> > a broader range of IEEE 802 technologies out of which 
> Ethernet is just 
> > one, for example IEEE 802.11 wireless LAN. I suggest that 
> the scope of 
> > this section and the text where relevant is changed so that 
> it covers 
> > IEEE 802 rather than just Ethernet.
> 
> We've had other suggestions for this ID to cover more than 802.3:
> 
> - --In response to input from Jerry Perser, we modified 
> section 4.2 to include an example covering 802.11 roaming.
> 
> Given that 802.3 and 802.11 share a common MAC address format 
> (48 bits, OUI in the same place), no 802.11-specific 
> modification is needed for the address pattern recommended here
> 
> - --In response to input from Scott Poretsky, we added 
> section 4.3 on MPLS label contents
> 
> Thanks very much for the positive feedback.
> 
> dn
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> 
> iD8DBQFFUflMyPxGVjntI4IRApXBAKD4W1vrhyb4ByZeKy1OHkb2pl/zRQCghwhP
> M+zHhZm5To/DfYMnNJzwwzY=
> =KHra
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bmwg
> 

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

---

From: David Newman <[email-masked]>
Date: Mon, 13 Nov 2006 13:12:03 -0800

On 11/13/06 12:26 PM, Romascanu, Dan (Dan) wrote:
> 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

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

---

From: Al Morton <[email-masked]>
Date: Mon, 13 Nov 2006 18:32:25 -0500

>does the change you've requested mean another cycle of ID numbers and

IMO, if the changes from this WGLC are purely editorial,
we can move on to "publication request".  If substantive
changes were made, then another very short WGLC is usually in order
(1 week, care now/not) at this stage of maturity.

>delighted if their managers allowed them three years to write an app

Yup.

When a document pops out of the (long) standards process, the ideal
outcome is when the product is "greater than the sum of the parts".

What I mean is this: by sharing our reviews and comments along the
way, one person takes someone else's suggestion and expands on
it in a way that neither originally envisioned. This sort of
interaction would not take place if the reviewers work independently.
In our group, interaction can happen on the list or at meetings, but the
reality that standards work is a sideline for most folks means it
will take time to get attention.  And of course, we must be
vigilant to keep any draft from becoming "a horse, as designed by
Committee".  Pushing-back takes time, too.

Al

---

From: "Tom Alexander" <[email-masked]>
Date: Tue, 14 Nov 2006 08:48:11 -0800

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:[email-masked]] 
Sent: Monday, November 13, 2006 1:12 PM
To: [email-masked]
Subject: Re: [bmwg] 3rd WG Last Call on Address Hash and Bit Stuffing
Draft(06)

OK with you?

dn

---

From: Al Morton <[email-masked]>
Date: Tue, 14 Nov 2006 12:12:49 -0500

>stuffing draft. Nothing could be further from the truth.

Thanks for the clarification, Tom.

I hope anyone who has any further concerns will
air them quickly on the list.  The WGLC ended a
week ago...

Al