Subject: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 6 Mar 2006 13:57:35 +0100

Hi John,
 
last weekend we had a face-to-face meeting with Martin, Cedric, Elwyn and myself. 
We went through the NATFW NSLP and looked also at the QoS NSLP draft. 
 
Particuarly, the IANA consideration section in the QoS NSLP document seems to require a major re-write. 
 
It might be interesting to take a look at the proposal we came up with. See Section 7 of 
<ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp> ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp <ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp-natfw-10.txt> -natfw-10.txt

We will send a more detailed mail  (after the deadline) with a list of questions.

Ciao
Hannes

________________________________

	Von: [email-masked] [mailto:[email-masked]] 
	Gesendet: Montag, 6. März 2006 13:52
	An: Kappler, Cornelia
	Cc: [email-masked]; [email-masked]; [email-masked]
	Betreff: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs

	when studying the NSIS Ext. ID I noticed the text in Sec. 5 needs to be updated. It is too unprecise currently. 

		It says: "New QSPECs require IETF action which defines the elements within the QSPEC". 

		(i) it probably should be "QoS Models" rather than QSPECs. One could go on and say how new QSPEC parameters (elements???) are defined but this is detailed in the QSPEC ID so it should suffice to provide a pointer. 

		Fixed. 

		 (ii) "IETF Action" what exactly is that? I've recently been studying the IANA RFC 2434 and this is not defined there. Or is this vague on purpose / defined elsewhere?

		Along the same lines, when updating the QSPEC IANA section we were wondering what kind of IETF action is required for defining new QOSMs / QOSM IDs: Will the QOSM IDs be informational RFCs (=> "specification required" or "IETF Consensus" in IANA language !?) or standards track (=> "standards action" in IANA language)? We are currently assuming it is just "specification required" and updated the QSPEC ID accordingly. Note this implies that new  _optional_ QSPEC parameters will receive this same IANA treatment because they can be defined by QOSMs. (New _mandatory_ QSPEC parameters would require standards action, because they "MUST be interpreted" by all QNEs)

		My proposal for new text in the NSIS Ext ID is "New QoS Models can be defined by providing a specification. A new QoS Model would define the QoS parameters to be carried in the QSPEC. For details see [QSPEC ID]". 

		 IETF action means: 

		<t>Extensions subject to "IETF Action" require either a Standards Track   RFC, Experimental RFC or an Information RFC.</t> 

		Is this OK? 

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

---

From: <[email-masked]>
Date: Mon, 6 Mar 2006 15:02:39 +0200

The NATFW draft (& QoS draft) should actually detail the values for the registries in the IANA section, that way IANA can just review the IANA section - if they have to dig through the document, it'll be a mess.
 
I also was wondering if we should have a common registry for NSIS - or seperate.  Any thoughts?
 
John

	From: ext Tschofenig, Hannes [mailto:[email-masked]] 
	Sent: 06 March, 2006 14:58
	To: Loughney John (Nokia-NRC/Helsinki); Kappler, Cornelia
	Cc: [email-masked]; [email-masked]; [email-masked]
	Subject: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status / NSIS Extensibility Doc on QOSMs

	Hi John,

	 

	Ciao
	Hannes

			Fixed. 

			 IETF action means: 

			Is this OK?

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 6 Mar 2006 15:16:44 +0200 (EET)

Ack. I'll do that once all comments from this extended WGLC have been
received, and we have a final spec to send to the ADs&IESG. A common
registry would of course be nice, but is that possible?

Jukka

---

From: Andrew McDonald <[email-masked]>
Date: Mon, 06 Mar 2006 13:16:30 +0000

Tschofenig, Hannes wrote:
> __ 
> <ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp>_ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp 
> <ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp-natfw-10.txt>_-natfw-10.txt
> 

I'd agree with that, I even created a QoS NSLP issue for it yesterday 
(issue #45) :-)
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue45

The GIST specification goes a bit further and splits up the registries, 
e.g. to allocate parts of the ranges to experimental use.

I also noticed that the QoS NSLP fails to define the values for the 
objects that go in to messages, which surprises me since some people 
claim to have implemented it. :-) Logged as issue #46:
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue46

Andrew

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 06 Mar 2006 14:31:47 +0100

Hi Andrew,

we also wanted to allocate vendor specific and experimental regions for 
the registries we create. However, this depends a little bit on the 
decision whether we want to have a common registry for the NSLP object 
types, for example.

Ciao
Hannes

---

From: <[email-masked]>
Date: Mon, 6 Mar 2006 15:35:18 +0200

>Ack. I'll do that once all comments from this extended WGLC 
>have been received, and we have a final spec to send to the 
>ADs&IESG. A common registry would of course be nice, but is 
>that possible?

One potential model:

http://www.iana.org/assignments/aaa-parameters

Another model:

http://www.iana.org/numbers.html - under SIP.

John

---

From: Roland Bless <[email-masked]>
Date: Tue, 07 Mar 2006 12:14:46 +0100

Hi Andrew,
> claim to have implemented it. :-) Logged as issue #46:

:-) Yep, implementation is basically no problem if you pick some values,
but interoperability might be an issue :-) So far we had no inter-op
tests for QoS NSLP.

Regards,
 Roland