Subject: [MBONED] addrarch: eGLOP and MADCAP to historic?

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Dec 2006 13:32:40 +0200 (EET)

AD review issue: eGLOP and MADCAP to historic?

2) Some mechanisms described in the draft haven't been used (at least
    very much).  Should we do something about them?

    2.1) RFC 3138 ("eGLOP") was never carried out; the draft states
    procedural reasons why IANA didn't allocate RIRs addresses, but the
    real reason may have been lack of IETF guidance or lack of demand.
    Should we mark it obsolete and Historic or do something about it?

    2.2) Since MADCAP implementations are few and in between and it
    hasn't been significantly deployed, should we do anything about it
    -- for example, reclassify both RFC2730 and RFC2907 as Historic or
    Experimental?

    Given that there are at least two implementations (AFAIK, Windows
    and an open-source project) even though not a lot of deployment,
    Historic would seem a bit big action.  Personally, I wouldn't have
    a problem with Experimental if it's worth the effort though.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Dec 2006 07:37:03 -0800

>    real reason may have been lack of IETF guidance or lack of demand.
                 ^^^^^^^^^^^^^^

	That is pure speculation. The reason was because no RIR
	ever saw the benefit (read: way to make money) on
	this. There were/are various reasons for that.

>    Should we mark it obsolete and Historic or do something about it?

	Given the advent of 4 byte ASes, my sense is that all of
	this is about to become quite a bit less useful. So I
	have no objection to making it Historic unless someone
	from an RIR (or one or more of their customers) see it as
	useful.
>    -- for example, reclassify both RFC2730 and RFC2907 as Historic or

	Experimental? Dave Thaler is more of an expert on this
	than I, so perhaps he can speak on this, but I believe
	there are a few implementations out there (possibly still
	in use).

>    a problem with Experimental if it's worth the effort though.

	Oh, ok. Agreed.

	--dmm

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Dec 2006 07:37:03 -0800

^^^^^^^^^^^^^^

	Oh, ok. Agreed.

	--dmm

---

From: David Kessens <[email-masked]>
Date: Wed, 20 Dec 2006 15:04:20 -0800

Pekka,

>    a problem with Experimental if it's worth the effort though.

We don't really have a mechanism to reclassify something to 'Experimental'.

Also, if there are indeed implementations, but still nobody seems to
use it, this might be even more of an indication that a technology is
for whatever reason not useful and should be moved to Historic as
opposed to mentioning it in the multicast address architecture
document as an option for operators.

David Kessens
---

---

From: David Kessens <[email-masked]>
Date: Wed, 20 Dec 2006 15:04:20 -0800

Pekka,

David Kessens
---

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 16:08:12 -0800

>    Should we mark it obsolete and Historic or do something about it?

Not sure. Depends on outcome of other considerations for IPv4
ASM adress allocation.

>    a problem with Experimental if it's worth the effort though.

I think experimental is fine because there's not enough evidence
that future development would continue to make MADCAP irrelevant.
MADCAP is IMHO the only protocol of the infamous multicast address
architecture that could have use even outside ofit.

I think MASC (rfc2909) and MZAP should be moved to historic though.
Class of problems: Stuff that's a problem in IPv4, where the solution
is so complex that it was never widely used, doesn't seem to have any uptake
at all, and is not a problem in IPv6 anymore (rfc3306).

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 16:08:12 -0800

Cheers
    Toerless

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Dec 2006 21:36:51 -0500

> Not sure. Depends on outcome of other considerations for IPv4

The feedback I got here was that instantiating 3138 would require  
passing the appropriate policy through
the RIR's, which is a very sensible way to go and could I think  
realistically be done in 2007, given that
there is a RFC here.

My feeling is that should be pursued, and will try and prepare a  
draft proposal this week. Comments on this course would be welcomed.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Dec 2006 21:36:51 -0500

Regards
Marshall

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 19:03:49 -0800

> draft proposal this week. Comments on this course would be welcomed.

See my other mail with respect to how i think eGLOB could best be morphed
to direct the solution more towards SSM.

As far as developers trying to hardcode an ASM adress into their
apps to give resource-discovery: I'd recommend to allow single-adress
assignments in some 224.0.x.y range.

Aka: Overall, like SSM: I'd open up floodgates by recognizing 
specific classes of requests/applications and define exact procedures for such.

CHeers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Dec 2006 19:03:49 -0800

CHeers
    Toerless