Re: NHRP v6 - hardware type / address type

[Grenville Armitage <[e-mail]>]

Oh, please. You cant have it both ways.

First you observe, as though to imply that one codepoint per
media type is (a) what we're allowed, yet (b) not enough:

>>Media
>>type to address type is a many to many mapping, so media type does not
>>identify the address type.

and yet, when faced with ATM case of multiple address types you
propose...

>>I don't see this as the only choice.  If there are 3 combinations of
>>address and subaddress for ATM, then how about simply defining 3
>>distinct address types?

If multiple codepoints (regardless of the number space)
are allowed, you've answered your own first implied problem above.
If we find a media that has 3, or 4, or 5 address types then
you define ar$hrd codepoints for each address type of the same
media. (But as a reality check, can you name any current examples,
or good reasons why such a situation would arise in the future that
NHRP would be relevant to?)

>>It would also seem to require the NHRP spec to enumerate all the media
>>types, specifying what these bits mean in each media's context.

Hardly. The IANA lists are quite appropriate, and there's nothing
stopping us from saying "here's the table for NHRP, MARS, etc, where
each ar$hrd value identifies a media and one or two addresses.
The first named address type is represented by flag = 0 in the
<blah blah>, the second address type .... by flag = 1 in the <blah>".

gja