Subject: Re: [magma] Mailing Lists Archive

From: Brian Haberman <[email-masked]>
Date: Fri, 27 Feb 2009 07:40:17 -0500

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/magma

From: [email-masked]
To: [email-masked]
Date: Sun,  8 Feb 2009 10:45:01 -0800 (PST)
Cc: [email-masked]
Subject: [magma] I-D Action:draft-ietf-magma-mgmd-mib-13.txt

--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: <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Date: Sun,  8 Feb 2009 11:00:01 -0800 (PST)
Cc: [email-masked]
Subject: [magma] I-D Action:draft-ietf-magma-mgmd-mib-14.txt

--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: <[email-masked]>

--NextPart--

Date: Sun, 08 Feb 2009 14:30:16 -0500
From: Brian Haberman <[email-masked]>
To: [email-masked]
Subject: Re: [magma] I-D Action:draft-ietf-magma-mgmd-mib-14.txt

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

From: [email-masked]
To: [email-masked]
Date: Mon,  9 Feb 2009 05:15:01 -0800 (PST)
Cc: [email-masked]
Subject: [magma] I-D Action:draft-ietf-magma-mgmd-mib-15.txt

--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: <[email-masked]>

--NextPart--

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Date: Mon,  9 Feb 2009 06:49:29 -0800 (PST)
Cc: magma chair <[email-masked]>, magma mailing list <[email-masked]>, Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>
Subject: [magma] Protocol Action: 'Multicast Group Membership Discovery MIB' to Proposed Standard

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.

Date: Thu, 12 Feb 2009 12:32:01 +0200
From: Jari Arkko <[email-masked]>
To: [email-masked]
Subject: [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

Content-class: urn:content-classes:message
Date: Thu, 12 Feb 2009 16:12:56 +0100
From: "Alvaro Fernandez" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, <[email-masked]>
Subject: Re: [magma] closing the working group

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: [email-masked] en nombre de Jari Arkko
Enviado el: jue 12/02/2009 11:32
Para: [email-masked]
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
[email-masked]
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> [email-masked] en nombre =
de Jari Arkko<BR><B>Enviado el:</B> jue 12/02/2009 11:32<BR><B>Para:</B> =
[email-masked]<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>[email-masked]<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--

Date: Thu, 12 Feb 2009 12:49:45 -0800 (PST)
From: Behcet Sarikaya <[email-masked]>
To: [email-masked]
Cc: Dirk von Hugo <[email-masked]>
Subject: [magma] Multimob
Reply-To: Behcet Sarikaya <[email-masked]>

--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: [email-masked]=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:[email-masked]">[email-masked]</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--

Date: Fri, 13 Feb 2009 09:59:05 +0800
From: Liu Hui <[email-masked]>
To: 'Alvaro Fernandez' <[email-masked]>, 'Jari Arkko' <[email-masked]>, [email-masked]
Subject: Re: [magma] closing the working group

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: [email-masked] [mailto:[email-masked]] On Behalf =
Of
Alvaro Fernandez
Sent: 2009=C4=EA2=D4=C212=C8=D5 23:13
To: Jari Arkko; [email-masked]
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: [email-masked] en nombre de Jari Arkko
Enviado el: jue 12/02/2009 11:32
Para: [email-masked]
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
[email-masked]
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> [email-masked]=20
  [mailto:[email-masked]] <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
  [email-masked]<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> [email-masked] en nombre de =
Jari=20
  Arkko<BR><B>Enviado el:</B> jue 12/02/2009 11:32<BR><B>Para:</B>=20
  [email-masked]<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>[email-masked]<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)--

To: [email-masked]
From: "K.Kawaguchi" <[email-masked]>
Date: Fri, 13 Feb 2009 15:57:20 +0900
Subject: [magma] [MLDv2] RFC3810 questions

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

Date: Fri, 13 Feb 2009 12:09:12 +0100 (CET)
To: [email-masked]
From: Hitoshi Asaeda <[email-masked]>
Cc: [email-masked]
Subject: Re: [magma] closing the working group

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: [email-masked] en nombre de Jari Arkko
> Enviado el: jue 12/02/2009 11:32
> Para: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/magma
> 
> 

From: "Schirl, Paul" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 13 Feb 2009 09:33:56 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Schirl, Paul" <[email-masked]>
Subject: [magma] draft-ietf-magma-mgmd-mib-15.txt

--_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.

<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:[email-masked]" 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: <[email-masked]>
Content-Transfer-Encoding: base64

--_004_24645E4B5357B94D9A19774311903FBE03B19B17A1MAEXCEVS2etse_--

Date: Fri, 13 Feb 2009 16:55:12 -0500
From: Brian Haberman <[email-masked]>
To: "Schirl, Paul" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [magma] draft-ietf-magma-mgmd-mib-15.txt

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

To: [email-masked]
From: "K.Kawaguchi" <[email-masked]>
Date: Wed, 25 Feb 2009 10:52:06 +0900
Subject: [magma] Mailing Lists Archive

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