Hello Bill,

There's a big difference between allowing refusal
(which I agree should be possible) and requiring
support in the implementation.

I can make an analogy between your example and
the IPsec mandate.

Your example "works", because there aren't any
communications that last for very many packets.

What if I build a product that ONLY ever supports
insecure applications?  Should I be allowed to claim
IPv6 conformance if my product platform does not
have any IPsec implementation?

Currently, the answer for IPv6 is "no".  But, I
reckon the number of nodes that only ever support
insecure applications would be a lot more than the
number of nodes that only ever support instantaneous,
disconnected application streams.

Plus, one could even devise semi-rational scenarios
where the DNS server needs to support mobility, of course
depending on the applications.  For remote diagnosis,
maybe some (secure!) streaming applications for processed
or graphic data would be highly advantageous, and the
diagnostician might be mobile at the time...
In fact, this doesn't sound at all far fetched to me.

Regards,
Charlie P.




Bill Sommerfeld wrote:
> 
> Here's another reason why RO needs to be optional:
> 
> Consider the traffic patterns surrounding a root name server.
> 
> Properly functioning clients talk to it at most once every two days
> (the current TTL of root server NS records) per TLD used, and do a
> single packet exchange per TLD.
> 
> There would be no point in it ever maintaining a binding cache.
> 
> On the other hand, I don't see much harm in mandating that hosts be
> able to politely refuse a binding update request.
> 
>                                                 - Bill
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to