Re: [magma] Mailing Lists Archive

[Brian Haberman <[e-mail]>]

It appears that the secretariat has had some issues with several mailing 
list archives due to an attempt to clean up spam messages sent directly 
to the archives.  They expect to have all the archives corrected by next 
week.

Regards,
Brian

K.Kawaguchi wrote:
> Hello,
> 
> The archive function of ml has stopped at the end of January.
> 
> http://www.ietf.org/mail-archive/web/magma/current/maillist.html
> 
> 
> Best Regards
> --
> Kiyoaki Kawaguchi
> 
> _______________________________________________
> magma mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/magma


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 697813A698E; Sun,  8 Feb 2009 10:45:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sun,  8 Feb 2009 10:45:01 -0800 (PST)
Cc: [e-mail]
Subject: [magma] I-D Action:draft-ietf-magma-mgmd-mib-13.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 18:45:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multicast & Anycast Group Membership Working Group of the IETF.


	Title           : Multicast Group Membership Discovery MIB
	Author(s)       : B. Haberman
	Filename        : draft-ietf-magma-mgmd-mib-13.txt
	Pages           : 42
	Date            : 2009-02-08

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects used for managing the Internet
Group Management Protocol (IGMP) and the Multicast Listener Discovery
(MLD) protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-magma-mgmd-mib-13.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-magma-mgmd-mib-13.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id C70BD3A68AE; Sun,  8 Feb 2009 11:00:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sun,  8 Feb 2009 11:00:01 -0800 (PST)
Cc: [e-mail]
Subject: [magma] I-D Action:draft-ietf-magma-mgmd-mib-14.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 19:00:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multicast & Anycast Group Membership Working Group of the IETF.


	Title           : Multicast Group Membership Discovery MIB
	Author(s)       : B. Haberman
	Filename        : draft-ietf-magma-mgmd-mib-14.txt
	Pages           : 42
	Date            : 2009-02-08

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects used for managing the Internet
Group Management Protocol (IGMP) and the Multicast Listener Discovery
(MLD) protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-magma-mgmd-mib-14.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-magma-mgmd-mib-14.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161023A67F3 for <[e-mail]>; Sun,  8 Feb 2009 11:30:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcTYFqt6FC4f for <[e-mail]>; Sun,  8 Feb 2009 11:30:11 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id DE97D3A659C for <[e-mail]>; Sun,  8 Feb 2009 11:30:11 -0800 (PST)
Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 53E5DB893 for <[e-mail]>; Sun,  8 Feb 2009 11:30:13 -0800 (PST)
Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iCY0aTQxR00y for <[e-mail]>; Sun,  8 Feb 2009 11:30:12 -0800 (PST)
Received: from clairseach.fuaim.com (unknown [IPv6:2001:470:117:128:20c:29ff:fe3c:1706]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id EEE46B892 for <[e-mail]>; Sun,  8 Feb 2009 11:30:11 -0800 (PST)
Received: from Clemson.local (c-76-100-31-131.hsd1.md.comcast.net [76.100.31.131]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id n18InKJ9026792 for <[e-mail]>; Sun, 8 Feb 2009 10:49:21 -0800
Message-ID: <[e-mail]>
Date: Sun, 08 Feb 2009 14:30:16 -0500
From: Brian Haberman <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [magma] I-D Action:draft-ietf-magma-mgmd-mib-14.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 19:30:13 -0000

All,
      This version of the MGMD MIB was generated to address several
comments raised during the IETF Last Call.  The biggest area of impact
was in the various compliance statements where changes were made to 
eliminate duplicate machine-readable statements.

Regards,
Brian



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 5F16D28C11C; Mon,  9 Feb 2009 05:15:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  9 Feb 2009 05:15:01 -0800 (PST)
Cc: [e-mail]
Subject: [magma] I-D Action:draft-ietf-magma-mgmd-mib-15.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 13:15:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multicast & Anycast Group Membership Working Group of the IETF.


	Title           : Multicast Group Membership Discovery MIB
	Author(s)       : B. Haberman
	Filename        : draft-ietf-magma-mgmd-mib-15.txt
	Pages           : 42
	Date            : 2009-02-09

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects used for managing the Internet
Group Management Protocol (IGMP) and the Multicast Listener Discovery
(MLD) protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-magma-mgmd-mib-15.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-magma-mgmd-mib-15.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 30) id 7DC3C3A6A9E; Mon,  9 Feb 2009 06:49:29 -0800 (PST)
X-idtracker: yes
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon,  9 Feb 2009 06:49:29 -0800 (PST)
Cc: magma chair <[e-mail]>, magma mailing list <[e-mail]>, Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>
Subject: [magma] Protocol Action: 'Multicast Group Membership Discovery MIB' to Proposed Standard
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 14:49:29 -0000

The IESG has approved the following document:

- 'Multicast Group Membership Discovery MIB '
   <draft-ietf-magma-mgmd-mib-15.txt> as a Proposed Standard

This document is the product of the Multicast & Anycast Group Membership 
Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-magma-mgmd-mib-15.txt

Technical Summary

  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet community.
  In particular, it describes objects used for managing the Internet
  Group Management Protocol (IGMP) and the Multicast Listener
  Discovery (MLD) protocol.

Working Group Summary
 
  The document has been reviewed by key WG members and the chairs
  have no concerns with those reviews.

Protocol Quality

  Jari Arkko has reviewed this specification for the IESG,
  and Dave Thaler has reviewed this specification as a part
  of a MIB Doctor review.

  It took from April 2006 to August 2007 for the MIB Doctor
  Review and AD review issues to be addressed.

  This revision addresses all the comments made by David McWalter and 
  Dave Thaler.  Even though the I-D editor posted the draft, the 
  id-nits tool run automatically on tools.ietf.org says there are 
  4 errors with a boilerplate mismatch and long lines being the biggest
  issues. The reference to RFC 2119 in the Introduction still uses 
  [KEYWORDS] which doesn't exist in the Reference section. These
  issues will be corrected in AUTH48, or in the next revision,
  if a need to revise arises in IESG.



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AB53A6B32 for <[e-mail]>; Thu, 12 Feb 2009 02:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.804
X-Spam-Level: 
X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-nD8IQEoXkh for <[e-mail]>; Thu, 12 Feb 2009 02:33:14 -0800 (PST)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 604BC3A6B22 for <[e-mail]>; Thu, 12 Feb 2009 02:33:14 -0800 (PST)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D06C6198714 for <[e-mail]>; Thu, 12 Feb 2009 12:33:18 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 8C8FE1986EF for <[e-mail]>; Thu, 12 Feb 2009 12:33:18 +0200 (EET)
Message-ID: <[e-mail]>
Date: Thu, 12 Feb 2009 12:32:01 +0200
From: Jari Arkko <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: [magma] closing the working group
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2009 10:33:15 -0000

The last document has been approved from this working group, and all 
milestones have been reached. Should we call this the successful 
termination of the project?

After a discussion with the chairs, my plan is to close the WG. The 
mailing list would be kept open, because there are occasional 
discussions about the interpretation of the rules in existing RFCs etc. 
If there are informational or experimental documents, I can AD sponsor 
them without a working group.

Does anyone see a need to keep the WG alive?

Jari



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2863A6ACE for <[e-mail]>; Thu, 12 Feb 2009 07:12:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.287
X-Spam-Level: 
X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT1Ua3nDivE6 for <[e-mail]>; Thu, 12 Feb 2009 07:12:55 -0800 (PST)
Received: from soportemv.com (correo.soportemv.com [80.81.115.248]) by core3.amsl.com (Postfix) with ESMTP id ADFF43A6B86 for <[e-mail]>; Thu, 12 Feb 2009 07:12:53 -0800 (PST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98D24.629B63EA"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 12 Feb 2009 16:12:56 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [magma] closing the working group
Thread-Index: AcmM/VXj6u9N6HSiSUidkZ0QsMouqQAI7oIM
References: <[e-mail]>
From: "Alvaro Fernandez" <[e-mail]>
To: "Jari Arkko" <[e-mail]>, <[e-mail]>
Subject: Re: [magma] closing the working group
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2009 15:12:56 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C98D24.629B63EA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I think IGMPv3 should evolve into IGMPv4, or whatever is necessary.
=20
I see three problems with the current RFC 3376 specification:
=20
1. Latency (Sending a Q(S,G) when a host leaves and waiting the answer)
2. I think mixing include sources and exclude sources is a mistake that =
makes the protocol complex and makes more difficult the integration with =
PIM-SM.
3. New issues related with mobility. Today there are probably more =
mobile host than not mobile hosts and IGMPv3 ignores mobility. (There is =
the MULTIMOB mailing list in the IETF but there is no working group for =
multicast host mobility)
=20
So, from my point of view, there are reassons to continue working on =
IGMP or another groups like 3GPP will do this work with specifications =
like MBMS that designs everything considering the business point of view =
of telecom companies (authentication, charging, ...)
=20
Best regards
=20
Alvaro Fernandez

________________________________

De: [e-mail] en nombre de Jari Arkko
Enviado el: jue 12/02/2009 11:32
Para: [e-mail]
Asunto: [magma] closing the working group



The last document has been approved from this working group, and all
milestones have been reached. Should we call this the successful
termination of the project?

After a discussion with the chairs, my plan is to close the WG. The
mailing list would be kept open, because there are occasional
discussions about the interpretation of the rules in existing RFCs etc.
If there are informational or experimental documents, I can AD sponsor
them without a working group.

Does anyone see a need to keep the WG alive?

Jari

_______________________________________________
magma mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/magma



------_=_NextPart_001_01C98D24.629B63EA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>[magma] closing the working group</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6000.16788" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText76435 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Hi,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I think IGMPv3 should evolve =
into IGMPv4, or whatever is necessary.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I see three problems with the =
current RFC 3376 specification:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>1. Latency (Sending a Q(S,G) =
when a host leaves and waiting the answer)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>2. I think mixing include =
sources and exclude sources is a mistake that makes the protocol complex =
and&nbsp;makes more difficult the integration with PIM-SM.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>3. New issues related with =
mobility. Today there are probably more mobile host than not mobile =
hosts and IGMPv3 ignores mobility. (There is the MULTIMOB mailing list =
in the IETF but there is no working group for multicast host =
mobility)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>So, from my point of view, =
there are reassons to continue working on IGMP or another groups like =
3GPP will do this work with specifications like MBMS that&nbsp;designs =
everything&nbsp;considering the business point of view of telecom =
companies (authentication, charging, ...)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Best regards</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Alvaro =
Fernandez</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>De:</B> [e-mail] en nombre =
de Jari Arkko<BR><B>Enviado el:</B> jue 12/02/2009 11:32<BR><B>Para:</B> =
[e-mail]<BR><B>Asunto:</B> [magma] closing the working =
group<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>The last document has been approved from this working =
group, and all<BR>milestones have been reached. Should we call this the =
successful<BR>termination of the project?<BR><BR>After a discussion with =
the chairs, my plan is to close the WG. The<BR>mailing list would be =
kept open, because there are occasional<BR>discussions about the =
interpretation of the rules in existing RFCs etc.<BR>If there are =
informational or experimental documents, I can AD sponsor<BR>them =
without a working group.<BR><BR>Does anyone see a need to keep the WG =
alive?<BR><BR>Jari<BR><BR>_______________________________________________=
<BR>magma mailing list<BR>[e-mail]<BR><A =
href=3D"https://www.ietf.org/mailman/listinfo/magma">https://www.ietf.org=
/mailman/listinfo/magma</A><BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C98D24.629B63EA--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF4328C279 for <[e-mail]>; Thu, 12 Feb 2009 12:49:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.264
X-Spam-Level: 
X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f52FHSjvLI5 for <[e-mail]>; Thu, 12 Feb 2009 12:49:40 -0800 (PST)
Received: from web111415.mail.gq1.yahoo.com (web111415.mail.gq1.yahoo.com [67.195.15.216]) by core3.amsl.com (Postfix) with SMTP id 8A7B128C1A8 for <[e-mail]>; Thu, 12 Feb 2009 12:49:40 -0800 (PST)
Received: (qmail 71885 invoked by uid 60001); 12 Feb 2009 20:49:46 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1234471786; bh=15o6FxLuLr5JdLycaWkuoy0uaRefpCq5uauTnKcgrC8=; h=Message-ID:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=N5Z8yxry0AB5z7VkrMSumiYZH06pBf6PrEOXsW0XthhH+x79BTPzU3aQ4Rlij9f/numuZbNcBlqHmVoCA5AFP+uAjpraespi+UR0g1jN9IbmMlyTFSu4/KDTXbE7I2D7D39I0uKI9d4QX7pwQdmnqSwcv3rIZqJvEU0CkT2CYzk=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=BfNn3fA5Dta/1XP25Do8bLDj61AoeV28sVC7RNtweAFBJI/dOlxtyL0d20Wp8ZrJIpHbUQVJxj3Yjr3ZWIq1pta6udIA2hTusq2fL+IlsfzsUDI2aoK1QB+Tigd0386IKP1+so5mqj6a5KuZsGqEuNGE+FmExuUH2IPqqtefCTw=;
Message-ID: <[e-mail]>
Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Thu, 12 Feb 2009 12:49:45 PST
X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1
Date: Thu, 12 Feb 2009 12:49:45 -0800 (PST)
From: Behcet Sarikaya <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-9675881-1234471785=:71611"
Cc: Dirk von Hugo <[e-mail]>
Subject: [magma] Multimob
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Behcet Sarikaya <[e-mail]>
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2009 20:49:44 -0000

--0-9675881-1234471785=:71611
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Dear Magma Folks,=0A=A0 Please be informed that we have an activity on Mult=
icast Mobility (multimob)=A0whose scope=A0contains the=A0 group management =
protocols and proxy mobile IP protocols. We expect that group management pr=
otocols will be deployed in the mobile networks and there are several issue=
s there which are being discussed in Multimob.=0A=A0 We welcome all of you =
to subscribe to Multimob mailing list and solicit your contributions to the=
 discussions. Here is the info:=0A=A0=0A=0AMailing Lists:=0AGeneral Discuss=
ion: [e-mail]=0ASubscribe online at: https://www1.ietf.org/mailman=
/listinfo/multimob=0A=0A=0ARegards,=0A=0ABehcet=0A=0A=0A      
--0-9675881-1234471785=:71611
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV>Dear Magma Folks,</DIV>
<DIV>&nbsp; Please be informed that we have an activity on Multicast Mobility (multimob)&nbsp;whose scope&nbsp;contains the&nbsp; group management protocols and proxy mobile IP protocols. We expect that group management protocols will be deployed in the mobile networks and there are several issues there which are being discussed in Multimob.</DIV>
<DIV>&nbsp; We welcome all of you to subscribe to Multimob mailing list and solicit your contributions to the discussions. Here is the info:</DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Mailing Lists:<BR>General Discussion: <A href="mailto:[e-mail]">[e-mail]</A><BR>Subscribe online at: <A href="https://www1.ietf.org/mailman/listinfo/multimob">https://www1.ietf.org/mailman/listinfo/multimob</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Behcet</DIV></div><br>

      </body></html>
--0-9675881-1234471785=:71611--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F773A6985 for <[e-mail]>; Thu, 12 Feb 2009 17:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.956
X-Spam-Level: *
X-Spam-Status: No, score=1.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjFa5cJS1SRn for <[e-mail]>; Thu, 12 Feb 2009 17:59:11 -0800 (PST)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 3EB243A6830 for <[e-mail]>; Thu, 12 Feb 2009 17:59:11 -0800 (PST)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 13 Feb 2009 09:59:06 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 13 Feb 2009 09:59:06 +0800 (CST)
Received: from l47967b ([10.111.12.115]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 13 Feb 2009 09:59:06 +0800 (CST)
Date: Fri, 13 Feb 2009 09:59:05 +0800
From: Liu Hui <[e-mail]>
In-reply-to: <[e-mail]>
To: 'Alvaro Fernandez' <[e-mail]>, 'Jari Arkko' <[e-mail]>, [e-mail]
Message-id: <002a01c98d7e$a6f3c8c0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_i25zTE4kLogaPDPC8rT0vA)"
Thread-index: AcmM/VXj6u9N6HSiSUidkZ0QsMouqQAI7oIMABWXt+A=
Subject: Re: [magma] closing the working group
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2009 01:59:12 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_i25zTE4kLogaPDPC8rT0vA)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Hi,
=20
For the three problem mentioned please see my comments:
=20
1. I suppose this process is usefull on shared network and when the =
explicit
tracking is not used. When the Qurier receives a leave, it should prune =
for
this group only when it is assured that no other host on the same subnet
receiving from the same group, by sending this query.
=20
2 It's true. And the usage of include and exclude mode makes the =
protocol
rather complicated.  But we have a
draft"draft-ietf-mboned-lightweight-igmpv3-mldv2" dealing with this =
issue.
The draft abolishes the usage of the two filter-modes and redesigns
IGMPv3/MLDv2 in a rather simplified manner.  The draft is currently
processed in MBONED WG.
=20
3. The isssue should be further evaluated  what exactly the new =
requirements
are.  If they turn out to be merely tuning of the protocol parameters, =
there
is no need to introduce a new version of the draft.  Otherwise they =
should
be first clarified then decided which group is appropriate for the work.
=20
=20
Best Regards,
Liu Hui


  _____ =20

From: [e-mail] [mailto:[e-mail]] On Behalf =
Of
Alvaro Fernandez
Sent: 2009=C4=EA2=D4=C212=C8=D5 23:13
To: Jari Arkko; [e-mail]
Subject: Re: [magma] closing the working group


Hi,
=20
I think IGMPv3 should evolve into IGMPv4, or whatever is necessary.
=20
I see three problems with the current RFC 3376 specification:
=20
1. Latency (Sending a Q(S,G) when a host leaves and waiting the answer)  =

2. I think mixing include sources and exclude sources is a mistake that
makes the protocol complex and makes more difficult the integration with
PIM-SM.
3. New issues related with mobility. Today there are probably more =
mobile
host than not mobile hosts and IGMPv3 ignores mobility. (There is the
MULTIMOB mailing list in the IETF but there is no working group for
multicast host mobility)
=20
So, from my point of view, there are reassons to continue working on =
IGMP or
another groups like 3GPP will do this work with specifications like MBMS
that designs everything considering the business point of view of =
telecom
companies (authentication, charging, ...)
=20
Best regards
=20
Alvaro Fernandez

  _____ =20

De: [e-mail] en nombre de Jari Arkko
Enviado el: jue 12/02/2009 11:32
Para: [e-mail]
Asunto: [magma] closing the working group



The last document has been approved from this working group, and all
milestones have been reached. Should we call this the successful
termination of the project?

After a discussion with the chairs, my plan is to close the WG. The
mailing list would be kept open, because there are occasional
discussions about the interpretation of the rules in existing RFCs etc.
If there are informational or experimental documents, I can AD sponsor
them without a working group.

Does anyone see a need to keep the WG alive?

Jari

_______________________________________________
magma mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/magma



--Boundary_(ID_i25zTE4kLogaPDPC8rT0vA)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML dir=3Dltr><HEAD><TITLE>[magma] closing the working group</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D600250701-13022009><FONT =
face=3DArial=20
color=3D#0000ff>Hi,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D600250701-13022009><FONT =
face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D600250701-13022009><FONT =
face=3DArial=20
color=3D#0000ff>For the three problem mentioned please see my=20
comments:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D600250701-13022009></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D600250701-13022009><FONT =
face=3DArial=20
color=3D#0000ff>1. I suppose this process is usefull&nbsp;on shared =
network and=20
when the explicit tracking is not used. When the Qurier receives a =
leave, it=20
should prune for this group only when it is assured&nbsp;that no other =
host on=20
the same subnet receiving from the same group, by sending this=20
query.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D600250701-13022009><FONT =
face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D600250701-13022009><FONT =
face=3DArial=20
color=3D#0000ff>2 It's true. And the usage of include and exclude mode =
makes the=20
protocol rather complicated.&nbsp; But we have a=20
draft"draft-ietf-mboned-lightweight-igmpv3-mldv2"&nbsp;dealing with this =

issue.&nbsp; The draft abolishes the usage=20
of&nbsp;the&nbsp;two&nbsp;filter-modes and redesigns IGMPv3/MLDv2 in a =
rather=20
simplified manner.&nbsp; The draft is currently processed in MBONED=20
WG.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D600250701-13022009><FONT =
face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D600250701-13022009>3. The =
isssue should be=20
further&nbsp;evaluated &nbsp;what exactly&nbsp;the new requirements =
are.&nbsp;=20
If&nbsp;they turn out to be&nbsp;merely tuning of the protocol =
parameters,=20
there&nbsp;is no need to introduce a new version of the draft.&nbsp; =
Otherwise=20
they should be first clarified then&nbsp;decided which group is =
appropriate for=20
the work.</SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D600250701-13022009><FONT =
face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D600250701-13022009></SPAN><SPAN=20
class=3D600250701-13022009><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D600250701-13022009><FONT =
face=3DArial=20
color=3D#0000ff>Best Regards,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D600250701-13022009></SPAN><SPAN=20
class=3D600250701-13022009><FONT face=3DArial color=3D#0000ff>Liu=20
Hui</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma><B>From:</B> [e-mail]=20
  [mailto:[e-mail]] <B>On Behalf Of </B>Alvaro=20
  Fernandez<BR><B>Sent:</B> 2009=C4=EA2=D4=C212=C8=D5 =
23:13<BR><B>To:</B> Jari Arkko;=20
  [e-mail]<BR><B>Subject:</B> Re: [magma] closing the working=20
  group<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV id=3DidOWAReplyText76435 dir=3Dltr>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000>Hi,</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial>I think IGMPv3 should evolve into =
IGMPv4, or=20
  whatever is necessary.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial>I see three problems with the =
current RFC 3376=20
  specification:</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial>1. Latency (Sending a Q(S,G) when a =
host leaves=20
  and waiting the answer)</FONT><FONT face=3DArial color=3D#0000ff><SPAN =

  class=3D600250701-13022009>&nbsp;&nbsp;</SPAN></FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial>2. I think mixing include sources =
and exclude=20
  sources is a mistake that makes the protocol complex and&nbsp;makes =
more=20
  difficult the integration with PIM-SM.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial>3. New issues related with mobility. =
Today there=20
  are probably more mobile host than not mobile hosts and IGMPv3 ignores =

  mobility. (There is the MULTIMOB mailing list in the IETF but there is =
no=20
  working group for multicast host mobility)</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial>So, from my point of view, there are =
reassons to=20
  continue working on IGMP or another groups like 3GPP will do this work =
with=20
  specifications like MBMS that&nbsp;designs everything&nbsp;considering =
the=20
  business point of view of telecom companies (authentication, charging, =

  ...)</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial>Best regards</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial>Alvaro Fernandez</FONT></DIV></DIV>
  <DIV dir=3Dltr><BR>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma><B>De:</B> [e-mail] en nombre de =
Jari=20
  Arkko<BR><B>Enviado el:</B> jue 12/02/2009 11:32<BR><B>Para:</B>=20
  [e-mail]<BR><B>Asunto:</B> [magma] closing the working=20
  group<BR></FONT><BR></DIV>
  <DIV>
  <P>The last document has been approved from this working group, and=20
  all<BR>milestones have been reached. Should we call this the=20
  successful<BR>termination of the project?<BR><BR>After a discussion =
with the=20
  chairs, my plan is to close the WG. The<BR>mailing list would be kept =
open,=20
  because there are occasional<BR>discussions about the interpretation =
of the=20
  rules in existing RFCs etc.<BR>If there are informational or =
experimental=20
  documents, I can AD sponsor<BR>them without a working =
group.<BR><BR>Does=20
  anyone see a need to keep the WG=20
  =
alive?<BR><BR>Jari<BR><BR>_______________________________________________=
<BR>magma=20
  mailing list<BR>[e-mail]<BR><A=20
  =
href=3D"https://www.ietf.org/mailman/listinfo/magma">https://www.ietf.org=
/mailman/listinfo/magma</A><BR></P></DIV></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_i25zTE4kLogaPDPC8rT0vA)--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EECA3A6B8C for <[e-mail]>; Thu, 12 Feb 2009 22:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_12=0.6, RELAY_IS_203=0.994, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMbYSbSEqRUP for <[e-mail]>; Thu, 12 Feb 2009 22:57:18 -0800 (PST)
Received: from tkns.tk.ysknet.co.jp (tkmx.tk.ysknet.co.jp [203.180.172.16]) by core3.amsl.com (Postfix) with SMTP id 8A72D3A6B23 for <[e-mail]>; Thu, 12 Feb 2009 22:57:16 -0800 (PST)
Received: (qmail 14490 invoked from network); 13 Feb 2009 15:58:00 +0900
Received: from  (HELO PrecisionM20) (@) by  with SMTP; 13 Feb 2009 15:58:00 +0900
To: [e-mail]
From: "K.Kawaguchi" <[e-mail]>
Message-Id: <[e-mail]>
X-Mailer: Winbiff [Version 2.51 PL2]
X-Accept-Language: ja,en,zh
Date: Fri, 13 Feb 2009 15:57:20 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [magma] [MLDv2] RFC3810 questions
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2009 06:57:19 -0000

Hi all,

It seems that I have been late.
However, I am investigating RFC3810 and there is some questions. These
may be my shortages of an understanding. However, a problem may be
caused in the interconnection between implementation.

In order to solve these questions, please maintain ml or let me know
suitable WG.


========================================================================
2.3.  Building Multicast Address Listener State on Multicast Routers
---
   Besides this "soft leave" mechanism, there is also a "fast leave"
   scheme in MLDv2; it is also based on the use of source timers.  When
   a node in INCLUDE mode expresses its desire to stop listening to a
   specific source, all the multicast routers on the link lower their
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   timers for that source to a given value.  The Querier then sends a
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Multicast Address and Source Specific Query, to verify whether there
   are other listeners for that source on the link, or not.  If a report
   that includes this source is received before the timer expiration,
   all the multicast routers on the link update the source timer.  If
   not, the source is deleted from the Include List.  The handling of
   the Include List, according to the received reports, is detailed in
   Tables 7.4.1 and 7.4.2.
---

I think that it is not exact.  According to the table of 7.4.1 and
7.4.2, a report is received and a timer is not made low. According to
7.6.1, a timer is lowered when sending a query, and receiving a query.


========================================================================
5.1.8.  QRV (Querier's Robustness Variable)
---
   Routers adopt the QRV value from the most recently received Query as
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   their own [Robustness Variable] value, unless that most recently
   received QRV was zero, in which case they use the default [Robustness
   Variable] value specified in section 9.1, or a statically configured
   value.
---

I think that clearness is short.  It should be limited to the time when
the query was received from the "querier" and "new querier" (i.e., the
querier should be memorized). Furthermore, it is restricted when the
destination addresses of a query are all node multicast (FF02::1).

The router immediately after starting except a querier sends a query. RV
of a non-querier is not adopted. When destination addresses are not all
node multicast, all the nodes do not receive QRV.


========================================================================
5.1.9.  QQIC (Querier's Query Interval Code)
---
   Multicast routers that are not the current Querier adopt the QQI
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   value from the most recently received Query as their own [Query
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Interval] value, unless that most recently received QQI was zero, in
   which case the receiving routers use the default [Query Interval]
   value specified in section 9.2.
---

Same as above QRV.


========================================================================
5.1.15.  Destination Addresses for Queries
---
   In MLDv2, General Queries are sent to the link-scope all-nodes
   multicast address (FF02::1).  Multicast Address Specific and
   Multicast Address and Source Specific Queries are sent with an IP
   destination address equal to the multicast address of interest.
   *However*, a node MUST accept and process any Query whose IP
                                                       ^^^^^^^^
   Destination Address field contains *any* of the addresses (unicast or
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   multicast) assigned to the interface on which the Query arrives. This
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   might be useful, e.g., for debugging purposes.
---

This is a question. A query message will be accepted if a destination
address is a unicast address of an interface. When the query message has
something unusual, should an ICMP error message be replied in MLD?


========================================================================
5.2.14.  Destination Addresses for Reports
---
   Version 2 Multicast Listener Reports are sent with an IP destination
   address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast
   routers listen (see section 11 for IANA considerations related to
   this special destination address).  A node that operates in version 1
   compatibility mode (see details in section 8) sends version 1 Reports
   to the multicast address specified in the Multicast Address field of
   the Report.  In addition, a node MUST accept and process any version
                                                                ^^^^^^^
   1 Report whose IP Destination Address field contains *any* of the
   ^^^^^^^^
   IPv6 addresses (unicast or multicast) assigned to the interface on
   which the Report arrives.  This might be useful, e.g., for debugging
   purposes.
---

May "MLDv1" limitation be suitable? (Comparison with 5.1.15)


========================================================================
7.6.1.  Timer Updates
7.6.3.2.  Building and Sending Multicast Address and Source Specific
---
   When a table action "Send Q(MA,X)" is encountered by the Querier in
   the table in section 7.4.2, the following actions must be performed
   for each of the sources in X that send to multicast address MA, with
                                                                   ^^^^
   source timer larger than LLQT:
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
---

When a specific query is received, and a timer is larger than LLQT, it
lowers to LLQT, but when a timer is already below LLQT, it does not
raise. May this understanding be suitable?


========================================================================
7.6.2.  Querier Election
---
   When a router receives a query with a lower IPv6 address than its
                          ^^^^^^^
   own, it sets the Other Querier Present timer to Other Querier Present
   Timeout; if it was previously in Querier state, it switches to Non-
   Querier state and ceases to send queries on the link.  After the
   Other Querier Present timer expires, it should re-enter the Querier
   state and begin sending General Queries.
---

I think that clearness is short.  It should be limited to the time when
the query was received from the "querier" and "new querier" (i.e., the
querier should be memorized). Furthermore, it is restricted when the
destination addresses of a query are all node multicast (FF02::1).

Continuation of periodical general query cannot be guaranteed with a
specific query. When destination addresses are not all node multicast,
all the nodes do not receive query.


========================================================================
7.6.2.  Querier Election
---
   When a router receives a query with a lower IPv6 address than its
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   own, it sets the Other Querier Present timer to Other Querier Present
   ^^^^
   Timeout; if it was previously in Querier state, it switches to Non-
   Querier state and ceases to send queries on the link.  After the
   Other Querier Present timer expires, it should re-enter the Querier
   state and begin sending General Queries.
---

I think that clearness is short. It is necessary to memorize the address
of a querier with Other Querier Present timer. While Other Querier
Present timer is effective, only the general query (destination address
is FF02::1) of "querier" and "new querier" (a priority higher than
"querier") is received.

When the priority of the address of Router A, B, and C is high A > B > C,
By the query of B started newly, C may have the different timer and RV
value from A. It is tentative disarrangement.


========================================================================
7.6.2.  Querier Election
---
   When a router receives a query with a lower IPv6 address than its
   own, it sets the Other Querier Present timer to Other Querier Present
   Timeout; if it was previously in Querier state, it switches to Non-
   Querier state and ceases to send queries on the link.  After the
   Other Querier Present timer expires, it should re-enter the Querier
   state and begin sending General Queries.
                           ^^^^^^^^^^^^^^^
---

Does the value of QRV and QI keep up the value of a previous querier?
Or does it return to an own default value?


========================================================================
8.3.2.  In the Presence of MLDv1 Multicast Address Listeners
---
   The Multicast Address Compatibility Mode of a multicast address
   record is set to MLDv1 whenever an MLDv1 Multicast Listener Report is
   received for that multicast address.  At the same time, the Older
   Version Host Present timer for the multicast address is set to Older
   Version Host Present Timeout seconds.  The timer is re-set whenever a
   new MLDv1 Report is received for that multicast address.  If the
                                                             ^^^^^^
   Older Version Host Present timer expires, the router switches back to
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Multicast Address Compatibility Mode of MLDv2 for that multicast
   address.

   (cut)

   MLDv2 BLOCK messages are ignored, as are source-lists in TO_EX()
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   messages (i.e., any TO_EX() message is treated as TO_EX( {} )).  On
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the other hand, the Querier continues to send MLDv2 queries,
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   regardless of its Multicast Address Compatibility Mode.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
---

I think that description is short. A router receives a Done message, and
after checking that MLDv1 listeners have stopped being, the timer of
Filter mode may expire early from Older Version Host Present timer. You
should also make Older Version Host Present timer expire at this time.

MLDv2 BLOCK messages are ignored. Any TO_EX() message is treated as
TO_EX( {} )).


========================================================================
9.8.  Last Listener Query Interval

This is a check. There is no structure transmitted between routers into
an MLDv2 protocol. Therefore, all the routers need to be set as the same
value by the system administrator.


========================================================================
9.9.  Last Listener Query Count

This is a query. The value of LLQC is also influenced when adopting QRV
of a query message as RV? Or all the routers need to be set as the same
value by the system administrator?


========================================================================
9.3.  Query Response Interval

I think that clearness is short. A non-querier sends general query, when
Other Querier Present Timer expires. The remaining time for state
continuation is;

MALI - Other Querier Present Timeout = Query Response Interval / 2

Therefore, Maximum Response Delay time must be less than "Query Response
Interval / 2".

On the other hand, according to 9.14.3, the maximum response delay time
should be set up from the expected number of reporters. Therefore, you
should set up the value of "Query Response Interval / 2" not limit the
maximum response delay time. That is, QRI is set up be twice the maximum
of the actually required maximum response delay time.


========================================================================
9.12.  Older Version Querier Present Timeout

---
   The Older Version Querier Present Timeout is the time-out for
   transitioning a host back to MLDv2 Host Compatibility Mode.  When an
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   MLDv1 query is received, MLDv2 hosts set their Older Version Querier
   Present Timer to [Older Version Querier Present Timeout].
---

All the listeners need to be set as the same value by the system
administrator in RV, QI, and QRI of MLDv1. Moreover, are RV and QI
adopted from QRV and QQIC of MLDv2 query?


Best Regards
--
Kiyoaki Kawaguchi

Best Regards
--
Kiyoaki Kawaguchi



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4540B3A6846 for <[e-mail]>; Fri, 13 Feb 2009 03:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.904
X-Spam-Level: 
X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrGxjBpJcg5b for <[e-mail]>; Fri, 13 Feb 2009 03:09:29 -0800 (PST)
Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 987D63A6886 for <[e-mail]>; Fri, 13 Feb 2009 03:09:12 -0800 (PST)
Received: from localhost (vis196b.inria.fr [194.254.174.196]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 352E113D06C4; Fri, 13 Feb 2009 19:32:35 +0900 (JST)
Date: Fri, 13 Feb 2009 12:09:12 +0100 (CET)
Message-Id: <[e-mail]>
To: [e-mail]
From: Hitoshi Asaeda <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
Subject: Re: [magma] closing the working group
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2009 11:09:30 -0000

Hi,

I agree with Alvaro.

IGMPv3/MLDv2 have some bugs and are good to update, although I don't
know whether the version number should be changed or not.
The updated version specification can be inherited from LW version
protocol specification, and mobility support may be also considered
(while there may still be the possibility to work on it in multimob).

And if the new versions are proposed, IGMP/MLD security may be able to
be considered.

Regards,
--
Hitoshi Asaeda

Subject: Re: [magma] closing the working group
Date: Thu, 12 Feb 2009 16:12:56 +0100

> Hi,
>  
> I think IGMPv3 should evolve into IGMPv4, or whatever is necessary.
>  
> I see three problems with the current RFC 3376 specification:
>  
> 1. Latency (Sending a Q(S,G) when a host leaves and waiting the answer)
> 2. I think mixing include sources and exclude sources is a mistake that makes the protocol complex and makes more difficult the integration with PIM-SM.
> 3. New issues related with mobility. Today there are probably more mobile host than not mobile hosts and IGMPv3 ignores mobility. (There is the MULTIMOB mailing list in the IETF but there is no working group for multicast host mobility)
>  
> So, from my point of view, there are reassons to continue working on IGMP or another groups like 3GPP will do this work with specifications like MBMS that designs everything considering the business point of view of telecom companies (authentication, charging, ...)
>  
> Best regards
>  
> Alvaro Fernandez
> 
> ________________________________
> 
> De: [e-mail] en nombre de Jari Arkko
> Enviado el: jue 12/02/2009 11:32
> Para: [e-mail]
> Asunto: [magma] closing the working group
> 
> 
> 
> The last document has been approved from this working group, and all
> milestones have been reached. Should we call this the successful
> termination of the project?
> 
> After a discussion with the chairs, my plan is to close the WG. The
> mailing list would be kept open, because there are occasional
> discussions about the interpretation of the rules in existing RFCs etc.
> If there are informational or experimental documents, I can AD sponsor
> them without a working group.
> 
> Does anyone see a need to keep the WG alive?
> 
> Jari
> 
> _______________________________________________
> magma mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/magma
> 
> 


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C525528C1C6 for <[e-mail]>; Fri, 13 Feb 2009 06:36:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level: 
X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn1kpcUbVQLY for <[e-mail]>; Fri, 13 Feb 2009 06:36:22 -0800 (PST)
Received: from WA4EHSOBE006.bigfish.com (wa4ehsobe005.messaging.microsoft.com [216.32.181.15]) by core3.amsl.com (Postfix) with ESMTP id B070B28C16D for <[e-mail]>; Fri, 13 Feb 2009 06:36:22 -0800 (PST)
Received: from mail87-wa4-R.bigfish.com (10.8.14.248) by WA4EHSOBE006.bigfish.com (10.8.40.26) with Microsoft SMTP Server id 8.1.291.1; Fri, 13 Feb 2009 14:36:28 +0000
Received: from mail87-wa4 (localhost.localdomain [127.0.0.1])	by mail87-wa4-R.bigfish.com (Postfix) with ESMTP id 0923D8E82B2	for <[e-mail]>; Fri, 13 Feb 2009 14:36:29 +0000 (UTC)
X-BigFish: VPS-7(zz936fMzzzz22005h186Mz2ei54h6bh43j62h)
X-Spam-TCS-SCL: 1:0
X-FB-SS: 5,5,
Received: by mail87-wa4 (MessageSwitch) id 1234535786880310_27634; Fri, 13 Feb 2009 14:36:26 +0000 (UCT)
Received: from MAEDG1.ets.enterasys.com (unknown [134.141.3.139])	(using TLSv1 with cipher AES128-SHA (128/128 bits))	(No client certificate requested)	by mail87-wa4.bigfish.com (Postfix) with ESMTP id AD4621C20052	for <[e-mail]>; Fri, 13 Feb 2009 14:36:26 +0000 (UTC)
Received: from macas-nlb.ets.enterasys.com (134.141.79.21) by MAEDG1.ets.enterasys.com (134.141.168.76) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 13 Feb 2009 09:34:50 -0500
Received: from MAEXCEVS2.ets.enterasys.com ([fe80::90b0:3940:6b9:a734]) by MACAS1.ets.enterasys.com ([fe80::9cc2:82ec:a40:9ee%10]) with mapi; Fri, 13 Feb 2009 09:33:58 -0500
From: "Schirl, Paul" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Fri, 13 Feb 2009 09:33:56 -0500
Thread-Topic: draft-ietf-magma-mgmd-mib-15.txt
Thread-Index: AcmN6Bm4l/ba+Bm5SGOdEPVgCP9/bg==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_004_24645E4B5357B94D9A19774311903FBE03B19B17A1MAEXCEVS2etse_"; type="multipart/alternative"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 13 Feb 2009 07:59:34 -0800
Cc: "Schirl, Paul" <[e-mail]>
Subject: [magma] draft-ietf-magma-mgmd-mib-15.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2009 14:40:14 -0000

--_004_24645E4B5357B94D9A19774311903FBE03B19B17A1MAEXCEVS2etse_
Content-Type: multipart/alternative;
	boundary="_000_24645E4B5357B94D9A19774311903FBE03B19B17A1MAEXCEVS2etse_"

--_000_24645E4B5357B94D9A19774311903FBE03B19B17A1MAEXCEVS2etse_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,
  All statements like the one below in this MIB text won't compile for me.


SYNTAX     InetAddressType { ipv4(1), ipv6(2) }


>From RFC 4011 (INET-ADDRESS-MIB):

         To support future extensions, the InetAddressType textual
         convention SHOULD NOT be sub-typed in object type definitions.
         It MAY be sub-typed in compliance statements in order to
         require only a subset of these address types for a compliant
         implementation.

Paul Schirl
Senior Firmware Engineer
Enterasys Networks, Inc.

[cid:image001.jpg@01C98DBE.30DF6820]<http://www.enterasys.com/>










--_000_24645E4B5357B94D9A19774311903FBE03B19B17A1MAEXCEVS2etse_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www=
.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoin=
t/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns=
:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xm=
lns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D=
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schem=
as.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.mi=
crosoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsof=
t.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/=
package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats=
.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/off=
ice/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/=
2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpa=
ges" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/typ=
es" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/mess=
ages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibr=
ary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer=
/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"=
&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1096290949;
	mso-list-type:hybrid;
	mso-list-template-ids:-1979912444 67698703 67698713 67698715 67698703 6769=
8713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>All,<o:p></o:p></span></=
p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>&nbsp; All statements li=
ke the
one below in this MIB text won&#8217;t compile for me.<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoListParagraph><span style=3D'font-size:10.0pt;font-family:"Co=
urier New";
color:#1F497D'>SYNTAX&nbsp;&nbsp;&nbsp;&nbsp; InetAddressType { ipv4(1),
ipv6(2) }</span><span style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoListParagraph><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p>=
</span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>From RFC 4011
(INET-ADDRESS-MIB):<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
To support future extensions, the InetAddressType textual<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
convention SHOULD NOT be sub-typed in object type definitions.<o:p></o:p></=
span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
It MAY be sub-typed in compliance statements in order to<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
require only a subset of these address types for a compliant<o:p></o:p></sp=
an></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;
implementation.</span><span style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Paul Schirl<o:p></o:p></=
span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Senior Firmware Engineer=
<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Enterasys Networks, Inc.=
<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:black'><o:p>&nbsp;</o:p></span></=
p>

<p class=3DMsoNormal><a href=3D"http://www.enterasys.com/"><span style=3D'c=
olor:black;
text-decoration:none'><img border=3D0 width=3D173 height=3D32 id=3D"Picture=
_x0020_1"
src=3D"cid:image001.jpg@01C98DBE.30DF6820" alt=3D"enterasys_logo_colorSM"><=
/span></a><span
style=3D'color:black'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoListParagraph><o:p>&nbsp;</o:p></p>

<p class=3DMsoListParagraph><span style=3D'font-size:10.0pt;font-family:"Co=
urier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

--_000_24645E4B5357B94D9A19774311903FBE03B19B17A1MAEXCEVS2etse_--

--_004_24645E4B5357B94D9A19774311903FBE03B19B17A1MAEXCEVS2etse_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=2678;
	creation-date="Fri, 13 Feb 2009 09:33:56 GMT";
	modification-date="Fri, 13 Feb 2009 09:33:56 GMT"
Content-ID: <image001.jpg@01C98DBE.30DF6820>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAgAK0DASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1DX7v
V7az26NYC6uX4DOwCx+5z1+leU+IbHxg2641qO7kj7kNujX8F4FdTq7/ABEvr13s4DZ24Y+XHG6Z
x7k9TW54Tm8UES23iO2UoFzHPlcn/ZIHX60j3aEng6fOuST66+9/XoeNW9zcWsgktp5IXHRo3Kn9
K7vwp8R7qK5jstck86FztW5PDIf9r1HvWX8RNCg0bX1ktUEcF2nmBB0Vs4YD26H8a5Og9x06GOoq
TWj+9H0gCCAQcg9CKwtb8ZaLoM/2e7uGefGTFEu5h9fSoPAGoyaj4StmmYs8JMJY9Tt6fpivN7hb
qz8cXP2q6jsp/tDsJ7mPeoBztOMemOaqKufE14OjUcH0dj1HRPGGja/MYLO4YTgZ8qVdrEe3rVWb
4geHre8mtZrmVJIWZXzC2MjrzXEaRZxXXjK2uIddtrm8E4ZhBbOqtjr0GOneodLtLe++JkkFzEss
TXkpKNyDjJGarlRjzM9A0fx1omtXwsreWVJn+4JU2h/ofWqHjDxwmimbTrWCRrto/lmxhEJ/mR1r
j2it7L4pCKFFihivVIVRgKMA1R1vXIvEvidbi9keOwEgRQi7mWPPYep/rRy6i5nY3vAGp3n9pyz6
lPfzQrEWE00zeTGvdjk4J6AV01x8SvDkExjWaaYA4LxxEr/9euV+Ieot59hokAa1sY4UfYwx14GR
7D+tUPskc1vHoMHiCznR3BWO3s2Ys3+8Bmi19Qu1oeqDXtNbRDrK3KmyVCxkA/THrnjFYh+JXhoR
NILicleieSwLfSuI1vzYYrLwXp0v2h4pMzsnSSZj0+grodW0zQ/A/h6B5NOhv7+RgFeUZ3OOSfYD
0FKyHdm7e+PtCsEj8+WXzpEDeQse50zzhh2PtS6X490LVbgwRzSQyBS+Jk2jA5PPTpXnra5dR2p1
mO70m2u5GISCC2BmBzyST0+tafhLQIjoeo+INXWZopoXRPLXL7T95wP89DTsg5nc6WX4meHY5Siv
cyKDgyJCdtXJ/HWgwafBfG5keCdiitHEWww6g+h5ry+IRWdldvpPiCIwHG+3niKNMO3ykEH866LR
oH8U+BNStxZQRTW8gkikhj2CRwO49ccfjRyoSkztbnxdo9rotvq8s7/Zbk7YyEJYnnjHXsagm8da
DBpsN/JcSCOckRJ5R3vg4JA9M968jiuL3U7ex0RMlVnbyl/2nIzn6c/ma67xzpeiWZ06zkup7S4t
7ZUQ+QXjkUH1HQ5z+dHKg5mdRYfEPw/f3K23nSwSOcL50ZUE/Wh/HNlBI6zWsyhWKqVIOeh9eOor
zqTVbuy1i3E11Y64MIFYx7+M8KDgEGvZEsbQZcWkKs/LfIKTSQ02zz7V7D4hWN66Wd/c3tuW/dyR
lM49wRwauaRofji8gaXUfEMun/3E2LIx+uMYrqNftNWurPOjX4tblMkB1BWT2Oen1ryrxBqHjKPf
b6xLeRRnghRtjb8V4P51B9HhpTxUFGPIn6a/dsV/F1xM+rfZZdafVxbDb5xQKFY9QMde3NYNS29r
cXUgjtoJJnPRY0LH9K7vwp8OLqW5jvdcj8mFDuW2PLOf9r0HtQe3OtSwlJKb29NfkjrPAGnSad4S
tlmUq8xMxU9Ru6fpitHUdP0PVpxb6hDaXE4HCORvA/nWmAAAAMAdAK8yuNA1geMGu7bSZcm+EpaY
q8W3+8HGGH0xT2PkoQji6k5zlbqd/p2i6ZpII0+xht93UovJ/HrTYfD+kQX/ANvisIUuixbzQPmy
eprmfFUfitteU6Y1yLTy18k2+CA+ed4JH68Yq54qTXmlsfsf2w2wRvtAsCok8zHy9f4c0XJjhE+T
31734G03h/SG1D+0G0+E3W7f5pX5s+tRJ4X0KK5FwmlWyyq24ME6H1rM1lvEEOnaNPaJdSyRSqby
KNl3uuOQex/Cqm3xRJ4JI/0qPVGuv7y+Yse/8vu0XFHCppPmWrt/wfQ6XUtE0zV9v9oWMVwU+6XX
kfjRp+h6VpWTYWEFuxGNyLz+fWsDxLZ6/a6VYW+lXF3crG5+0yKQZnHb04z6e1bfh0aguhWw1Rna
72neXADdeM44zjFFzOdBRpqopJ3e3UZBo+hafqSzxWtrDevuKtkB2z1IzU93Y6Xr1qEuYoL2ANkc
hgD7EVy/jLQNV1bxFp9xpyuht7dys4xhXByoP16fjTdK0/xBp/w5ltrSB7fVPMdgnG4Avk47ZxnF
Fzf6rTdKMlNXdtO17nQHwl4e8pYzpFrsTJHyf1rTt4YIbWOC3RFgRdqKv3QBxiuY0C01y48P6lb6
nJdq0oIt/NwJF+XnByTjPrVTTNP1y3+HhtrVby11O3csiOy5bBzhf9kj175ouT9Vim1zrRpff1+R
vzeEPD1xOZpdIti5OchcfoKi17R7+TRorLw5PHpzJKCdvyApg5HA9cVi+H4fGEmuQf2tJNHZgNcP
8wxkjiL8OtF2nis+LCYftfk/al8shl+z/Z8cgjruzRcbwa5nHnjtfcZ4T+H8+j6qNS1K4imkjB8p
I8kBj/ESa668s9M1dWtbuK3uvLPzRthin9RWRNZavd+Myxu7u30uKBHURsAkkgPKnvWFPp3iC18c
XV/b2tz/AGdNcR+b5DKGkULjP0B6ihtip4WEtOdbX/4HqdZY+GND02cT2el28Ug6OFyR9M9K1K4n
xSvig+IoH0kXjWoVPljIVM5+bJz6eorbn8MRTybxqF9Dkcok2Bn/AD/Kgl0IRjGUprXtrb1P/9k=

--_004_24645E4B5357B94D9A19774311903FBE03B19B17A1MAEXCEVS2etse_--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9973A6BD3 for <[e-mail]>; Fri, 13 Feb 2009 13:55:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zK2VKV8SV45 for <[e-mail]>; Fri, 13 Feb 2009 13:55:20 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id E5F583A6B40 for <[e-mail]>; Fri, 13 Feb 2009 13:55:20 -0800 (PST)
Received: from localhost (localhost.fuaim.com [127.0.0.1]) by uillean.fuaim.com (Postfix) with ESMTP id 38DD1B85D; Fri, 13 Feb 2009 13:55:25 -0800 (PST)
Received: from uillean.fuaim.com ([127.0.0.1]) by localhost (uillean.fuaim.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nR310XIZuhuk; Fri, 13 Feb 2009 13:55:23 -0800 (PST)
Received: from clairseach.fuaim.com (unknown [IPv6:2001:470:117:128:20c:29ff:fe3c:1706]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E016AB853; Fri, 13 Feb 2009 13:55:22 -0800 (PST)
Received: from Clemson.local (c-76-100-31-131.hsd1.md.comcast.net [76.100.31.131]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id n1DL7MJ9002108; Fri, 13 Feb 2009 13:07:23 -0800
Message-ID: <[e-mail]>
Date: Fri, 13 Feb 2009 16:55:12 -0500
From: Brian Haberman <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: "Schirl, Paul" <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [magma] draft-ietf-magma-mgmd-mib-15.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2009 21:55:21 -0000

Hi Paul,

Schirl, Paul wrote:
> All,
> 
>   All statements like the one below in this MIB text won’t compile for me.
> 
>  
> 
> SYNTAX     InetAddressType { ipv4(1), ipv6(2) }
> 
>  
> 
>  From RFC 4011 (INET-ADDRESS-MIB):
> 
>  
> 
>          To support future extensions, the InetAddressType textual
> 
>          convention SHOULD NOT be sub-typed in object type definitions.
> 
>          It MAY be sub-typed in compliance statements in order to
> 
>          require only a subset of these address types for a compliant
> 
>          implementation.
> 

The key phrase here is "SHOULD NOT".  In the case of the MGMD MIB, the 
InetAddressType objects need to be limited to specific families based on 
the protocols being supported (IGMP and MLD).  The MIB Doctor performing 
the review encouraged this sub-typing in conjunction with the sub-typing 
of the InetAddress objects.

We have verified that this mib does compile with multiple standards 
compliant MIB compilers.

Regards,
Brian


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C163A677E for <[e-mail]>; Tue, 24 Feb 2009 17:51:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.505
X-Spam-Level: **
X-Spam-Status: No, score=2.505 tagged_above=-999 required=5 tests=[AWL=-1.000,  BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXg02a8uNrqC for <[e-mail]>; Tue, 24 Feb 2009 17:51:51 -0800 (PST)
Received: from tkns.tk.ysknet.co.jp (tkmx.tk.ysknet.co.jp [203.180.172.16]) by core3.amsl.com (Postfix) with SMTP id D50F53A63EC for <[e-mail]>; Tue, 24 Feb 2009 17:51:50 -0800 (PST)
Received: (qmail 21592 invoked from network); 25 Feb 2009 10:52:51 +0900
Received: from  (HELO PrecisionM20) (@) by  with SMTP; 25 Feb 2009 10:52:51 +0900
To: [e-mail]
From: "K.Kawaguchi" <[e-mail]>
Message-Id: <[e-mail]>
X-Mailer: Winbiff [Version 2.51 PL2]
X-Accept-Language: ja,en,zh
Date: Wed, 25 Feb 2009 10:52:06 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [magma] Mailing Lists Archive
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2009 01:51:51 -0000

Hello,

The archive function of ml has stopped at the end of January.

http://www.ietf.org/mail-archive/web/magma/current/maillist.html


Best Regards
--
Kiyoaki Kawaguchi