Subject: [magma] MLDv2: relationship to RFC 2710

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Feb 2003 17:27:26 +0100 (CET)

The document obsoletes RFC 2710 (MLDv1). This means that an implementor should
not need to read RFC 2710 when implementing MLDv2. This doesn't seem
possible since the MLDv1 packet formats (and perhaps some MLDv1 behavior
needed for interoperability with v1 peers) are not contained in the 
specification.

For instance, when it says "send a MLDv1 query" it is not defined in
this document.

In addition, having MLDv1 as a normative reference while obsoleting it 
doesn't work, since in order to advance MLDv2 to draft standard
all the normative references need to be at least draft standard
and MLDv1 will never go there if it is obsoleted.

I see two different ways of resolving this.
1. Make the document self-contained so that all aspects of MLDv1 that
   a listener or router needs to do (packet formats, behavior, timers)
   are in this document. Then it can obsolete MLDv1 and have MLDv1
   be an informational reference (for those that want to look at
   the previous version for curiosity reasons).
2. Leave the document content as is and make it *update* RFC 2710.
   Leave RFC 2710 as a normative reference.
   When it is time to advance this document to draft either
   fold it together with MLDv1, or advance both document.
   If both documents are advanced then it will result in rfc-index  showing
   MLDv1 and MLDv2 as draft standards with the MLDv1 spec having a note
   about "updated by RFC <MLDv2>".

I think having two documents when going to draft standard would be a bad
idea from a readability perspective. Thus I think the question is really
whether the documents should be merged now or later.

   Erik

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 17 Feb 2003 02:01:36 -0800

> needed for interoperability with v1 peers) are not contained in the 

The IETF spent the better part of 6 years to release IGMP version 3
as an RFC. One would think that if your argument was correct, someone
would have cought this same issue in the IGMPv3 spec, right ?

[...]

> whether the documents should be merged now or later.

I agree that MLDv2 primary purpose ha to be to obsolete MLDv1.
I leave it up to others to determine as to how independent the document really
has to be. Certainly the practice in IPv4 doesn't seem to make it
necessary to replicate all formats from MLDv1.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 17 Feb 2003 02:01:36 -0800

[...]

Cheers
	Toerless

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Feb 2003 16:55:35 +0100 (CET)

> > The document obsoletes RFC 2710 (MLDv1). This means that an implementor
> should > not need to read RFC 2710 when implementing MLDv2. This doesn't seem
> > possible since the MLDv1 packet formats (and perhaps some MLDv1 behavior >
> needed for interoperability with v1 peers) are not contained in the  >
> specification.
> 

We know from history that this didn't happen.
Doesn't mean we should repeat it.

> I leave it up to others to determine as to how independent the document
> really has to be. Certainly the practice in IPv4 doesn't seem to make it

But the IGMPv3 spec hasn't run into trying to go to draft standard
which is when somebody would ask "are all the normative references
at draft standard or higher?".

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Feb 2003 16:55:35 +0100 (CET)

Erik

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 18 Feb 2003 08:39:12 -0800

> at draft standard or higher?".

So you're implying that you'd opt to refuse letting rfc3376 go up
further in the standards game on grounds of the same argument ? Fair
enough. But then i'd really say let's fix the text in an updated IGMPv3
spec first, and then think about how to continue on MLDv2 - after all,
one of the things that might be done to simplify matters would be to rethink
merging texts - MLDv2 is 99% just IGMPv3 with IPv6 addresses (+ link local
source address of reports).

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 18 Feb 2003 08:39:12 -0800

Cheers
	Toerless

---

From: "Rolland Vida" <[email-masked]>
Date: Tue, 18 Feb 2003 18:04:24 +0100

> source address of reports).

I do not think that merging documents is a clean and proper solution. Erik
complains about readability. I do not really see how could a document be
readable, if it is written as follows:

If [igmpv2] then ...
 else if [igmpv3] then...
  else if [mldv1] then...
   else if [mldv2] then...

At the beginning, when we started to write MLDv2, we discussed the issue
with Bill, Brian, Isidor, etc.. The consensus was that it is better to have
separate texts for MLD and IGMP. I think it was a good choice.

Why can't we target for the moment MLDv2 being only a proposed standard?

Rolland

---

From: "Rolland Vida" <[email-masked]>
Date: Tue, 18 Feb 2003 18:04:24 +0100

If [igmpv2] then ...
 else if [igmpv3] then...
  else if [mldv1] then...
   else if [mldv2] then...

Rolland

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 15:09:08 +0100 (CET)

> further in the standards game on grounds of the same argument ? 

There are two options for both IGMPv3 and MLDv2 in my opinion - 
each a set of two documents or each a single document when they move
to draft standard.
For MLDv2 we can at least say "updates RFC 2710" instead of "obsoletes RFC
2710" at this point in time since that is the more accurate statement.

> Fair

I know. 
Note however that the IGMPv* specification would be more complicated than the
MLDv* specification because it deals with 3 versions instead of 2.
Thus the backwards compatibility parts of the specification 
should be different.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 15:09:08 +0100 (CET)

I know. 

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 15:13:47 +0100 (CET)

> readable, if it is written as follows:

I don't think Toerless is arguing that IGMP+MLD be one specification.
But there are benefits in having a single IGMPv3 and a single MLDv2 draft
standard document.

I didn't and have not complained about readability and comprehensibility
for the backwards compatible aspects (apart from some details).
But there is an added burden on the implementor to figure out exactly
which parts of MLDv1 s/he needs to implement in order to satisfy MLDv2.

It isn't rocket science to make this clear in one specification.

> Why can't we target for the moment MLDv2 being only a proposed standard?

Did I not propose that as one of the options in my original email
on this subject?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 15:13:47 +0100 (CET)

Erik

---

From: Brian Haberman <[email-masked]>
Date: Thu, 20 Feb 2003 09:48:22 -0500

> 2710" at this point in time since that is the more accurate statement.

This approach should work fine in my opinion.  At the point that MLDv2
is ready for DS, we can merge it with the needed pieces from 2710.

> Thus the backwards compatibility parts of the specification 

Actually, MLD will be three documents as well.  Lest we forget the
source address selection draft.  Of course, MLD won't be as complex
as IGMPv1,2, & 3.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 20 Feb 2003 09:48:22 -0500

Brian