From mailman-admin@ietf.org Sat Mar 1 09:09:06 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05311 for ; Sat, 1 Mar 2003 09:09:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21EIcp04817 for ; Sat, 1 Mar 2003 09:18:38 -0500 Date: Sat, 01 Mar 2003 09:18:38 -0500 Message-ID: <20030301141838.26394.24806.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ifmib-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ifmib-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ifmib-archive@ietf.org: List Password // URL ---- -------- ifmib@ietf.org agzm https://www1.ietf.org/mailman/options/ifmib/ifmib-archive%40ietf.org From ifmib-admin@ietf.org Wed Mar 26 12:40:09 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04941; Wed, 26 Mar 2003 12:40:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHwAO16633; Wed, 26 Mar 2003 12:58:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHt1O16464 for ; Wed, 26 Mar 2003 12:55:01 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04743 for ; Wed, 26 Mar 2003 12:33:37 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2QHZuJ15053 for ; Wed, 26 Mar 2003 12:35:56 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 18:35:50 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550137BC4E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ifmib@ietf.org Date: Wed, 26 Mar 2003 18:35:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [ifmib] RPR MIB Quesion Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-BeenThere: ifmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Interfaces MIB working group mailing list. List-Post: List-Help: List-Subscribe: , Any comments from IF-MIB experts? > > -----Original Message----- > > From: Frank Kastenholz [mailto:fkastenholz@juniper.net] > > Sent: vrijdag 21 maart 2003 15:21 > > To: Wijnen, Bert (Bert); Keith McCloghrie (E-mail) > > Cc: Glenn Parsons; 'Thomas Narten'; Dan Romascanu (E-mail); 'Wijnen, > > Bert (Bert)' > > Subject: RE: Another Review of RPR MIB > > > > It's been a _long_ time since I looked at this stuff, but my _guess_ > > (and I must emphasize the word GUESS) is that it depends on how > > you model the interface -- in particular, it would depend on how > > you define the interface stacking. > > > > If you model the 802.17 interface as a single Interface, then I > > would think that the promiscuity would reflect whether the > > higher layers of software (i.e. the clients of 802.17 such as > > IP) see all the packets that "go by" the station or not. > > > > If you model the 802.17 interface as a stack of interfaces, > > some of which might be the lower-level phys (if I have my > > terminology right). Then some of these interfaces are in > > promiscuous mode, others are not, depending on whether > > they pass all packets up to the next higher interface stack > > element or not. > > > > This is my guess. It's worth the paper it's printed on :-) > > > > Frank Kastenholz > > > > Another comment... Glenn says that > > "RPR MAC never accepts unicast addresses other than to > > itself when unicast is on local ring" > > This may be what the standard says to do. However, I have to believe > > that some vendors will develop hardware that has the ability to > > promiscuously sniff every packet on the ring and report that packet > > up to the higher layers -- without stripping the packet off. Think > > of protocol analyzers (or security eavesdroppers) and their needs... > > > > > > > > >-----Original Message----- > > >From: Glenn Parsons [mailto:gparsons@nortelnetworks.com] > > >Sent: donderdag 20 maart 2003 23:21 > > >To: 'Wijnen, Bert (Bert)' > > >Cc: 'Thomas Narten'; Dan Romascanu (E-mail); 'Frank Kastenholz' > > >Subject: Another Review of RPR MIB > > > > > >.. snip .. > > > > > >There is a concern that promiscuous mode as defined in the > > >Interface MIB (as ifPromiscuous) does not strictly apply > > >to RPR. As far a we can tell there are three possible > > >mapping options since we understand that we must support it. > > >Can you suggest which is the most appropriate? > > > > > >There 3 options are: > > > always false - > > > RPR MAC never accepts unicast addresses other than to > > > itself when unicast is on local ring > > > always true - > > > RPR MAC as a function of transit path always deals with > > > every packet regardless if it is delivered to a local > > > client > > > true - > > > bridge relay client attached and the RPR MAC accepts > > > unicast to self, multicast, remote unicast marked > > > with floodbit ; > > > false - otherwise > > > > > >Cheers, > > >Glenn. > > > _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib