Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 19 Dec 2002 09:43:47 -0500

Patrik Fältström wrote:

>> To be clear, I have removed flag extensibility altogether (in fact, 
>> the attribute is no longer named FLAGS). SO, its just attributes. 
>> Anyway, the idea is that since we don't anticipate extensions, an IANA 
>> registry need not be set up at this time.
> 
> 
> The problem I have is that you in the previous issue above talk about 
> "Extensions, documented in standards track IETF RFCc, MAY define new 
> attributes. Attributes...".
> 
> The document is not consistent.
> 
>> However, if we do get any, we can create the registries at that time. 
>> I would propose the following new text for IANA considerations:
>>
>>> STUN can be extended by defining new attributes in standards track
>>> extensions. However, since it is anticipated that no extensions will
>>> be needed or defined, no IANA registry is to be created at this
>>> time. Should an extension to STUN be defined, that extension can
>>> establish any necessary registries.
>>
> 
> See above. I have problems with you talking about extensions, and in the 
> IANA considerations section claim no registry is needed. It is clearly 
> needed for attributes, given the text above.

OK, so that leaves two choices:

1. allow extensibility and define an IANA registry,
2. disallow extensibility, state that protocol changes need to be 
affected by revising the specification, and then there is no need for an 
IANA registry. The attribute usage (criticial attributes < 0x7fff) would 
remain to handle the possibility of a specification revision.

The group has been somewhat divided on extensibility. I will, therefore, 
make a concrete proposal: let us do option 2, disallow attribute 
extensibility through separate RFCs. The primary motivation for this is:

1. keep things simple
2. there is risk of the protocol being abused
3. if there are real needs or problems we can always revise the spec

Comments?

I'd like to reach closure on this one very quickly....

-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: Scott Bradner <[email-masked]>
Date: Thu, 19 Dec 2002 09:48:29 -0500 (EST)

that works for me

----

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 19 Dec 2002 09:43:47 -0500

1. keep things simple

Comments?

-Jonathan R.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 19 Dec 2002 16:03:55 +0100

Works for me as well.

    paf

On torsdag, dec 19, 2002, at 15:48 Europe/Stockholm, Scott Bradner 
wrote:

> that works for me
>
> ----
> From [email-masked]  Thu Dec 19 09:44:09 2002
> Date: Thu, 19 Dec 2002 09:43:47 -0500
> From: Jonathan Rosenberg <[email-masked]>
> Organization: dynamicsoft
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) 
> Gecko/20020826
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
> CC: Melinda Shore <[email-masked]>, [email-masked],
>    Scott Bradner <[email-masked]>
> Subject: Re: [midcom] Scott Bradner: response from the IESG on stun 04
> References: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 8bit
>
>
>
> Patrik Fältström wrote:
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 19 Dec 2002 11:39:05 -0500

Just a followup on exactly what I meant by proposal (2) below. The 
specific text I would change is:

OLD:

Extensions, documented in standards track IETF RFCs, MAY define new
attributes. Attributes with values greater than 0x7fff are optional,
which means that the message can be processed by the client or server
even though the attribute is not understood. Attributes with values
less than or equal to 0x7fff are mandatory to understand, which means
that the client or server cannot process the message unless it
understands the attribute.

NEW:

To allow future revisions of this specification to add new attributes
if needed, the attribute space is divided into optional and mandatory
ones. Attributes with values greater than 0x7fff are optional, which
means that the message can be processed by the client or server even
though the attribute is not understood. Attributes with values less
than or equal to 0x7fff are mandatory to understand, which means that
the client or server cannot process the message unless it understands
the attribute.

and

OLD:

\section{IANA Considerations}

NEW:

\section{IANA Considerations}

STUN cannot be extended. Changes to the protocol are made through a
standards track revision of this specification. As a result, no IANA
registries are needed.

-Jonathan R.

Jonathan Rosenberg wrote:

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 19 Dec 2002 19:12:57 +0100

Perfect according to my taste.

   paf

On torsdag, dec 19, 2002, at 17:39 Europe/Stockholm, Jonathan Rosenberg 
wrote:

>> affected by revising the specification, and then there is no need for 
>> an IANA registry. The attribute usage (criticial attributes < 0x7fff) 
>> would remain to handle the possibility of a specification revision.
>> The group has been somewhat divided on extensibility. I will, 
>> therefore, make a concrete proposal: let us do option 2, disallow 
>> attribute extensibility through separate RFCs. The primary motivation 
>> for this is:
>> 1. keep things simple

---

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 20 Dec 2002 15:50:28 -0800

Looks great. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jonathan Rosenberg
> Sent: Thursday, December 19, 2002 8:39 AM
> To: Jonathan Rosenberg
> Cc: Patrik Fältström; Melinda Shore; [email-masked]; Scott Bradner
> Extensions, documented in standards track IETF RFCs, MAY 
> define new attributes. Attributes with values greater than 
> 0x7fff are optional, which means that the message can be 
> processed by the client or server even though the attribute 
> is not understood. Attributes with values less than or equal 
> to 0x7fff are mandatory to understand, which means that the 
> client or server cannot process the message unless it 
> To allow future revisions of this specification to add new 
> attributes if needed, the attribute space is divided into 
> optional and mandatory ones. Attributes with values greater 
> than 0x7fff are optional, which means that the message can be 
> processed by the client or server even though the attribute 
> is not understood. Attributes with values less than or equal 
> to 0x7fff are mandatory to understand, which means that the 
> client or server cannot process the message unless it 
> STUN can be extended by defining new attributes in standards 
> track extensions. However, since it is anticipated that no 
> extensions will be needed or defined, no IANA registry is to 
> be created at this time. Should an extension to STUN be 
> defined, that extension can establish any necessary registries.
> 
> NEW:
> 
> STUN cannot be extended. Changes to the protocol are made 
> through a standards track revision of this specification. As 
> a result, no IANA registries are needed.
> 
> 
> -Jonathan R.
>