>>>>> On Fri, 29 Mar 2002 13:21:53 -0500,
>>>>> David Lehmann <[EMAIL PROTECTED]> said:
>> This example seems too specific to incorporate the extension into the
>> document at this late stage.
> The lateness of this proposal was pointed out to me by Erik,
> but thought I could give a shot nonetheless.
Yes, anyone can basically raise their own requests at any time, but
whether the requests are accepted or not depends on the timing...IMO,
just saying "this could be useful" cannot be a reason to adopt the
request at this stage, and, honestly, I don't see much benefit of
the idea comparing to the status of the document. (But, of course, I
may be wrong or be biased, so I'll hear from others' opinions for a
while.)
>> Also, I don't get why the next header is
>> so special.
> The reason is that if I am implementing a particular protocol
> (e.g. SCTP), I don't want to be bothered by errors generated
> for every other protocol on the node. I would only want errors
> for my particular protocol.
If you're implementing SCTP itself in the user space, I would point
out that this API is not intended to aid implementing a transport
layer protocol in the user space (at least in my understanding.) If
you want to let an SCTP application accept ICMPv6 error messages, I'd
say it's a so special case (even though this is the "advanced" API).
Secondly, one of the reasons why ICMPv6-type based filtering was
introduced was because we can see many ICMPv6 messages even in normal
operation, because ND and MLD are both using ICMPv6 messages. Error
messages, however, are basically exceptions. Thus, I don't see much
validity for the motivation to filter ICMPv6 error messages.
>> If we added this, then other implementors would want
>> filtering based on inner flowlabel, inner hop limit, inner source or
>> destination addresses, inner extension headers...
> If they are generally useful, so be it. However, I don't know how
> great the dangers are of those additional requests.
My point is that the request of filtering on the next header is as
special as others, at least for me. But, again, I may be wrong, and
will hear from others.
At this moment I sill do not think we can add the feature to the
document.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
