Re: AHbis WG LC: need for source address based selectors

[Tero Kivinen <kivinen@ssh.fi>]

Stephen Kent writes:
> >"The SPIs from the reserved range may used different demultiplexing
					 ^ => use
> >algorithms and use source and/or destination address and/or protocols
> >and/or some other information for the actual demultiplexing. A
> >document describing new reserved SPI number MUST also specify the
					       ^ => must
> >demultiplexing algorithm used for that specific SPI."
...
> promote interoperability. What you seem to suggest is a that we not 
> preclude someone from saying that they comply with IPsec, even though 
> they would be following a demuxing policy that is not used in any 
> extant implementations and thus would not be interoperable with any 
> of these implementations.

I have little problems of parsing what you are saying above, but what
I said there does not affect interoperability at all, as it does not
change any current implemenation to conforming or non-conforming.

If the implementation wants to follow the AHbis then it must implement
the demux policy that is MUST in it. This text does not change that.
What that text says (or at least tries to say) is that there is future
work in progress that might use different demuliplexing policies IN
ADDITION to the current ones, and those future documents will define
them later.

What this means to implementator is that if he feels he might be
wanting to comply to those (future) documents later he might want to
write implementation so that new demultiplexing policies can also be
used.

The only MUST (or perhaps it should be "must") in my text was for the
future document writers, not to any implementator. For implementators
we just give hint that "yes, there is work going on, and you might
want to create your architecture so that it can handle those future
demultiplexing algorithms".

> This does not promote interoperability; 
> all it does is allow someone to claim conformance with a standard. 

It will be conforming to the AHbis if and only if it implements the
demultiplexing algorithms specified as MUST in the AHbis. This text
does not change it. It will be conforming to some other future
documents if it implements demultiplexing algorithms specified there.
This text will not change that either.

Only thing I was (trying) to say in the text was that "be prepared,
there is other demultiplexing algorithm(s) coming in the future
documents".

> That does not seem constructive and, as I noted, it only add to 
> complexity.

Adds complexity to where? I do not thing it changes anything in the
implementations unless you plan to implement those future documents,
and it will not change any bits in the wire, nor can you remove any of
the current demultiplexing algorithm currently mandated by AHbis. 

> Am I missing something in your suggestion?

I think so. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/