Subject: [AAA-WG]: 4 proposals for solving vendor specific commands

From: <[email-masked]>
Date: Tue, 11 Jun 2002 15:45:14 +0300

Hi all,

Let's approach this problem from a higher-level.  I think that no matter what,
folks will implement extensions.  Having a paper trail, even on vendor specific
commands, is useful.  Whatever system is used for capturing the paper trail
should be as straight forward as possible, so that folks do create paper trails.
Additionally, technical reviews on extensions are not a bad thing.

It seems that there are the following options for resolving this.

1) 	Solution: Do nothing.  
   	Result: the area directors will not let the Diameter progress.

2)	Solution: prohibit vendor extensions.
	Result: extensions will be implemented anyway & no way to control them,
		  no paper trail.

3)	Solution: Mandate Informational RFCs on vendor extensions
	Result: May get paper trail, get control of specs, but still may result in 
	    	  folks not documenting anything

4)	Solution: IANA registry, with pointer to further documentation
	Result: Will most likely get paper trail, may not have any way of preventing bad 
		  behavior.

I think that that points 3 or 4 are the way forward.  We need confirmation on which
is the proper way forward from the chairs and area directors.

My gut feeling is recommending Information RFCs (maybe not mandating them) is a good thing.
Additionally, defining default behavior is needed.

The default behavior being that Diameter peers should disregard unknown / unsupported vendor 
commands.  Senders of unsupported commands are at fault.

Comments?
John

---

From: Erik Guttman <[email-masked]>
Date: Tue, 11 Jun 2002 06:25:39 -0700 (PDT)

> 4)	Solution: IANA registry, with pointer to further documentation

Experience with SLP extensions has shown that route '4' is a lot
less painful than '3'.  We have gotten extensions registered with
IANA in under two weeks.  

The result is that those who want to interoperate can get the 
specification easily.  Those who have vendor extensions and do not 
have years to spend on the IETF process can easily get their 
specifications published.  Peer review is still possible on these
specs, for example, on a mailing list dedicated to such discussion.

Erik

---

From: Sakthidaran V <[email-masked]>
Date: Wed, 12 Jun 2002 07:16:25 +0530

Hi ,

I think 4 is the way to go and it would be efffective (from the generate_a_trail
perspective) if we REQUIRE rather than RECOMMEND an information RFC .

My 2 cents ...

Thank you for your time .

Regds
Shakthi
[email-masked]

--