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

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 6 Mar 2006 13:12:23 -0000

I went through the GIST IANA section with the IANA people in Vancouver. They seemed broadly happy with the format and content. The question did come up of whether there was going to be a GIST registry or an NSIS registry, and at the time I don't think I had a clear view one way or the other (or even understand the significance of the question).
 
However, GIST creates 2 registries (NSLPID and MRMID) which are referred to by all NSLPs. In addition, AFAIK the NSLP object type registry is shared between all NSLPs, but GIST doesn't create it (its object types are its own), so some other mechanism is needed for that. 
 
The above implies to me that a single NSIS registry is more sensible.
 
r.

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] 
	Sent: 06 March 2006 13:03
	To: [email-masked]; [email-masked]
	Cc: [email-masked]; [email-masked]; [email-masked]
	Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs

	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,
		 
		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:14:50 +0200

This is what was thinking of as well, we can have a chat about that in Dallas (during WG time), and then we'd be in good shape.
 
John

	From: ext Hancock, Robert [mailto:[email-masked]] 
	Sent: 06 March, 2006 15:12
	To: Loughney John (Nokia-NRC/Helsinki); [email-masked]; [email-masked]
	Cc: [email-masked]; [email-masked]; [email-masked]
	Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status/NSIS Extensibility Doc on QOSMs

	 
	 
	r.

		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]] 
		Sent: 06 March 2006 13:03
		To: [email-masked]; [email-masked]
		Cc: [email-masked]; [email-masked]; [email-masked]
		Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM IANA Status /NSIS Extensibility Doc on QOSMs

		 
		John

			Hi John,

			 

			Ciao
			Hannes

					Fixed. 

					 IETF action means: 

					Is this OK?

---

From: Roland Bless <[email-masked]>
Date: Tue, 07 Mar 2006 13:29:19 +0100

Hi Robert,

> However, GIST creates 2 registries (NSLPID and MRMID) which are
> referred to by all NSLPs. In addition, AFAIK the NSLP object type
> registry is shared between all NSLPs, but GIST doesn't create it (its
> object types are its own), so some other mechanism is needed for
> that.

Does it really make sense to have a shared NSLP object type registry?
Do we have common objects? Any advantages compared to NSLP specific
types?

> The above implies to me that a single NSIS registry is more sensible.

Sure, NSLPID and MRMID are related to NSLPs because they are used
at the interface between GIST and NSLPs. However, one could also
assign them to a GIST related registry.
Moreover, if we decide that NSLP object type IDs are not shared
between all NSLPs, I don't see a compelling reason for a single NSIS
registry.

Regards,
 Roland

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 8 Mar 2006 09:53:03 +0100

hi all,

I would in favour of discussing this during the WG time in Dallas,  
since it involves (probably) GIST, QoS NSLP, and the NATFW NSLP.

   Martin

Am 06.03.2006 um 14:14 schrieb <[email-masked]>  
<[email-masked]>:

> This is what was thinking of as well, we can have a chat about that  
> in Dallas (during WG time), and then we'd be in good shape.
>
> John
>
> To: Loughney John (Nokia-NRC/Helsinki);  
> [email-masked]; [email-masked]
> Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM  
> IANA Status/NSIS Extensibility Doc on QOSMs
>
> I went through the GIST IANA section with the IANA people in  
> Vancouver. They seemed broadly happy with the format and content.  
> The question did come up of whether there was going to be a GIST  
> registry or an NSIS registry, and at the time I don't think I had a  
> clear view one way or the other (or even understand the  
> significance of the question).
>
> registry is shared between all NSLPs, but GIST doesn't create it  
> (its object types are its own), so some other mechanism is needed  
> for that.
>
> Subject: RE: IANA Considerations for QoS workAW: [NSIS] RE: QOSM  
> IANA Status /NSIS Extensibility Doc on QOSMs
>
> 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.
>
> Particuarly, the IANA consideration section in the QoS NSLP  
> document seems to require a major re-write.
>
> ftp://kyoto.netlab.nec.de/pub/internet-drafts/draft-ietf-nsis-nslp- 
> natfw-10.txt
>
> when studying the NSIS Ext. ID I noticed the text in Sec. 5 needs  
> to be updated. It is too unprecise currently.
> (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?
>
>