Subject: [core] #179: SHOULD NOT for multicast response repression

From: "core issue tracker" <[email-masked]>
Date: Mon, 05 Dec 2011 15:31:45 -0000

#179: SHOULD NOT for multicast response repression

 This ticket is to make multicast response repression a SHOULD NOT, as
 there are cases where some POSIX interfaces do not make multicast source
 address information available.

 From Esko Dijk's WGLC review:

 ** Multicast and filtering:
  "A multicast request with a query string MUST NOT be responded
  to if filtering is not supported or if the filter does not match (to
  avoid a needless response storm)."
 I'm thinking if this could also be a "SHOULD NOT" requirement, but perhaps
 there's a good reason why "MUST NOT" is used here. If anyone on the list
 has further opinions on this, I would be interested.

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  minor                 |  Milestone:
Component:  link-format           |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: <https://svn.tools.ietf.org/wg/core/trac/ticket/179>
core <http://tools.ietf.org/core/>

---

From: Guido Moritz <[email-masked]>
Date: Tue, 6 Dec 2011 12:17:01 +0100

I think the most important issue here is that the server supports filtering only optionally. If the filter does not match there is no response. Quite obvious for me. But what if the server does not support filtering at all?

The first thing that comes into my mind is how I would implement a client. I am not sure, but does a client have a (obvious and straight forward) possibility to find out if the server supports filtering? Otherwise I would not use filtering in my client implementation, because I may miss servers that don't implement it.

Maybe a possible solution would be to separate those two cases (1) filter does not match MUST NOT be responded and (2) filtering is not supported SHOULD NOT be responded. But I am not sure if SHOULD NOT is sufficient. It might still result in client implementations which do not use filtering and this in turn causes a real response storm.

Guido

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> core issue tracker
> Gesendet: Montag, 5. Dezember 2011 16:32
> An: [email-masked]
> Cc: [email-masked]
> Betreff: [core] #179: SHOULD NOT for multicast response repression
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core