Subject: [midcom] STUN issue #4: IANA procedures

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Nov 2002 03:04:39 -0500

The IESG commented that there were no IANA procedures defined for 
registering new attributes, messages, etc.

Proposal: history shows that protocols that are often extended even when 
not originally intended. As such, we should prepare for this better, and 
therefore, define an iana registry for (1) messages, (2) resposne codes, 
(3) attributes, (4) flags.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 19 Nov 2002 09:29:06 -0500

> (3) attributes, (4) flags.

I am unenthusiastic about this.  From talking with various
implementers it's pretty clear that even though the protocol
isn't standardized yet and even though we're clear (are we
not?) that this is to be a short-lived protocol and that it
has a number of serious limitations that make it unsuitable
for longer-term use, we're already looking at feature
creep.  I'd really like to discourage this or, at least,
avoid suggesting that the working group thinks this is a
good thing.  

If somebody wants to talk about the need to have a
reasonable mechanism for fixing errors that are discovered
in the future that's reasonable, but extending STUN?  That's
a problem.

Melinda

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 19 Nov 2002 15:38:25 -0000

I'm inclined to agree with you Melinda.  (When I did SPAN I ripped most of
the extensibility stuff out of it for this reason.)

I don't see why we can't define such procedures as and when they become
necessary - hopefully they won't - in a separate RFC (or a STUN v2 if
required).  That should raise the barrier for minor extensions that are
feature creep with little merit.  In other words, it would mean that it
would require significant group consensus before the changes could be made.

Pete.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Nov 2002 02:14:02 -0500

This was contentious during the meeting, and merits further discussion.

Upon further reflection, I too am inclined to agree that the IANA 
registry serves no purpose. I believe the protocol must be extensible in 
the sense that we can add things if necessary, but that is different 
from making it easy to be extended - i.e., that the protocol was built 
with the intent that there would be lots of extensions. An IANA registry 
is really needed only in the latter case.

So, I would propose that we add an IANA considerations section stating 
that there are no IANA registries defined.

-Jonathan R.

---

From: Scott Bradner <[email-masked]>
Date: Tue, 26 Nov 2002 07:12:38 -0500 (EST)

> that there are no IANA registries defined.

it shoudl also state how the protocol gets extended - e.g., it gets
extended only thorugh IETF standards action - to keep other stds orgs
from thinking they can extend it on their own

Scott