Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Tue, 11 Nov 2008 11:39:14 -0600

Following up the discussion, in order to answer the question
"Propose text for an update to the document including reasoning for 
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal "

The following texts are proposed (based on the online/offline discussion
with Dan/Hannes and DIME group):
"" This application is used to authorize the network QoS resources
(including amount of bandwidth, QoS class and traffic flow processing)
based on the Diameter application [RFC4006]. The request is based on the
Diameter extensibility discussions in the DIME WG that  led to the
conclusion that it is better to define new Command Codes whenever the
ABNF of a command is modified by adding, removing or semantically
changing required AVP in order to avoid interoperability problems.  The
document is utilizing authorization and accounting functionality and the
entire exchange is related to users utilizing applications that require
QoS treatment. This approach is consistent with the practice and
experience gained since the publication of [RFC3588] (see for example
[RFC5224]) which is now under revision by the DIME Working Group and
will provide a revised set of recommendations and procedures for IANA
considerations [draft-ietf-dime-rfc3588bis]."

Please let me know if you have any objection or comments.

I will submit a revised version of this I-D for the review.

Regards,
Dong

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, August 29, 2008 3:48 AM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Cc: Sun, Dong (Dong); [email-masked]
Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw

Hi Dan, 

let me quickly respond to this issue: 

> As expected the document was not approved by the IESG and is now in AD

> Follow-up.
> 
> Beyond the two DISCUSSes there were two ABSTAIN ballots. 
> 
> The principal concern that I heard was related to the fact that the 
> current process followed by the draft did not ensure a sufficient 
> level of review from the IETF to ensure that it really meets the IETF 
> consensus.
> 
> In order to overcome this I suggest that we do the following: 
> 
> 1. Ask for at least one more review (two is better) from the 
> AAA-Doctors team or DIME WG making also sure that the reviewers also 
> include reading the relevant parts in the ITU-T document in their 
> review (Hannes, can you ask Bernard to be one of the reviewers?)

I sent a mail to him. 

> 
> 2. Explain to the IESG why the DIME Working Group did not take this 
> work as a WG chartered item (hannes, please write a short explanation,

> also include the discussions around 3588bis)

draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using
Diameter. In the DIME working group we also have a document that deals
with QoS signaling, namely
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt.
It does, however, not cover NAT and Firewall signaling aspects. 

Other SDOs are, however, not required to use the work we do in the IETF
on certain Diameter applications. Additionally, they may enhance or
modify it. There are many reasons why this happens and I will not go
into the details of those. Call it a matter of life that has todo with
psychology rather than technical arguments. 

For us in DIME it does not really matter why ITU-T works on this
specific subject and it does not matter to us from a review point of
view either. 

The reason why the ITU-T (and previously OMA with
http://tools.ietf.org/html/rfc5224) came to the DIME working group is
actually related to a suggestion from our side (based on the Diameter
extensibility discussions we had) to define new Command Codes whenever
the ABNF of a command is modified by adding, removing or semantically
changing required AVP (i.e, those marked as {}). By defining new Command
Codes we believe to better avoid interoperability problems. 

The OMA has followed that suggestion (and so did ITU-T, to some extend)
but obviously ran into an issue with the requirements for the allocation
of Command Codes (compared to the allocation of Application IDs) based
on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) to
register applications without going through the IETF process but has
different rules for the allocation of Command Codes. The DIME working
group had a long discussion about this issue and decided to change the
rules for allocating Command Codes with the revision of RFC 3588 (see
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt)
and to align the procedure with the way how Application IDs are
requested. The main reasons for this decision were the following: 

* We did not want to encourage SDOs to misuse Diameter Command Codes
when they don't want to come to the IETF (and thereby causing
interoperability issues). 

* We did not want to drag all the SDOs to the IETF when it comes to
extending Diameter. Diameter is a very popular protocols among other
SDOs and this approach would not scale very well nor are we the experts
in all the applications areas people have in mind where Diameter could
be used.

* Some of us believe that the decision to have different rules for
Application ID allocation and Command Code assignment was a mistake
since it does not make a lot of sense from a logical point of view. 

* We should not treat the 3GPP differently to other SDOs since the 3GPP
was given a bunch of Command Codes without a corresponding specification
(see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to be
consistent in our behavior. 

As such, we came up with the idea to have an "interim" solution for
dealing with requests regarding Diameter Command Codes before RFC
3588bis gets published as an RFC. 

> 3. Propose text for an update to the document including reasoning for 
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will 
> draft such a text

I will think about text. Maybe it is lack of imagination on how
protocols could be used? Wouldn't be the first time that a protocol is
used in a way not originally envisioned. Example: RSVP - RSVP-TE

Funny enough, the idea about using Diameter for the purpose of NAT and
firewall signaling actually came from the IETF MIDCOM working group, see
http://www.ietf.org/rfc/rfc4097.txt
Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their favorite
protocol and it turns out that this was the wrong decision. Hard to
predict preferences...

> 
> Also in parallel the DIME WG should do the best to accelerate the 
> approval and submission of RFC3588 to the IESG so that we will need to

> deal with as few such cases in the future as possible (ideally zero).

That's certainly a good idea. We are having a final round of reviews and
I have asked the authors of the draft to also re-read the document to
avoid problems in later stages (as they have happened with other
Diameter documents already). 

Ciao
Hannes

> 
> Thanks and Regards,
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf

> > Of Chris Newman
> > Sent: Thursday, August 28, 2008 7:29 PM
> > To: [email-masked]
> > Cc: [email-masked];
> > [email-masked]; [email-masked]
> > Subject: DISCUSS: draft-sun-dime-itu-t-rw
> > 
> > Discuss:
> > As this issue was raised during IETF review and appears to concern a

> > number of area directors, I'm holding an actionable discuss 
> > position:
> > 
> > Based on GEN-ART review responses, it appears this statement in the 
> > DIAMETER base spec:
> > 
> >   "Diameter is not intended as a general purpose protocol, and
> >    allocations SHOULD NOT be made for purposes unrelated to
> >    authentication, authorization or accounting."
> > 
> > is spurious and not being followed.  If we're not going to follow 
> > this rule (which is fine if there's rough consensus not to follow 
> > it), I believe it's important that it be documented why we're not 
> > following the rule (a "SHOULD NOT"
> > requires justification).  Various approaches I find acceptable are:
> >  1. The document approval text includes reasoning for ignoring 
> > SHOULD NOT  2. An update to the document text includes reasoning for

> > ignoring
> >     SHOULD NOT
> >  3. Hold this until a small RFC is published that updates 3588 to
> >     change or remove the SHOULD NOT restriction.
> > 
> > 
> > 
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Tina TSOU <[email-masked]>
Date: Fri, 14 Nov 2008 12:11:07 +0800

ITU-T is waiting for command code allocated by IETF for ITU-T Recommendation Q.3303.3 Rw Diameter.

B. R.
Tina
  ----- Original Message ----- 
  From: Sun, Dong (Dong) 
  To: [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Wednesday, November 12, 2008 1:39 AM
  Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw

  Regards,
  Dong

  -----Original Message-----
  From: Hannes Tschofenig [mailto:[email-masked]] 
  Sent: Friday, August 29, 2008 3:48 AM
  To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
  Cc: Sun, Dong (Dong); [email-masked]
  Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw

  Hi Dan, 

  I sent a mail to him. 

  Ciao
  Hannes

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 14 Nov 2008 18:22:51 -0600

ITU-T is waiting for command code allocated by IETF for ITU-T Recommendation
Q.3303.3 Rw Diameter.

It doesn't look to me as if Hannes' excellent AAA Doctors review has been
responded to, however, at least in the draft.  Has the ITU-T specification
been modified appropriately?

B. R.
Tina

----- Original Message ----- 

From: Sun, Dong (Dong) <mailto:[email-masked]>  

To: [email-masked] 

Regards,
Dong

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, August 29, 2008 3:48 AM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Cc: Sun, Dong (Dong); [email-masked]
Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw

Hi Dan, 

I sent a mail to him. 

Ciao
Hannes

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Fri, 14 Nov 2008 20:49:41 -0600

Glen,
 
Yes. The ITU-T Rec has been updated based on Hannes' comments e.g. the
ABNF issue, and a response was sent to the exploder a while ago. I don't
see any further comments/objection.
 
certainly, some of those comments (e.g. CCR/CCA), as indicated by
Hannes, are related to 3GPP Gx 29.212 spec since the ITU-T Rw adopts
some of Gx spec. For the interoperability issue, they have to be
resolved by 3GPP. Moreover, they are irrelevant to this ID for the
request of new command code PIR/PIA (There is no question about the use
of PIR/PIA). 
 
Hope this help clarify your question.
 
Thanks,
Dong

________________________________

From: Glen Zorn [mailto:[email-masked]] 
Sent: Friday, November 14, 2008 7:23 PM
To: 'Tina TSOU'
Cc: [email-masked]; [email-masked]; [email-masked]; Sun, Dong (Dong)
Subject: RE: [Dime] DISCUSS: draft-sun-dime-itu-t-rw

ITU-T is waiting for command code allocated by IETF for ITU-T
Recommendation Q.3303.3 Rw Diameter.

It doesn't look to me as if Hannes' excellent AAA Doctors review has
been responded to, however, at least in the draft.  Has the ITU-T
specification been modified appropriately?

B. R.
Tina

	----- Original Message ----- 

	To: [email-masked] 

	
	Following up the discussion, in order to answer the question
	"Propose text for an update to the document including reasoning
for 
	> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal "
	
	The following texts are proposed (based on the online/offline
discussion
	with Dan/Hannes and DIME group):
	"" This application is used to authorize the network QoS
resources
	(including amount of bandwidth, QoS class and traffic flow
processing)
	based on the Diameter application [RFC4006]. The request is
based on the
	Diameter extensibility discussions in the DIME WG that  led to
the
	conclusion that it is better to define new Command Codes
whenever the
	ABNF of a command is modified by adding, removing or
semantically
	changing required AVP in order to avoid interoperability
problems.  The
	document is utilizing authorization and accounting functionality
and the
	entire exchange is related to users utilizing applications that
require
	QoS treatment. This approach is consistent with the practice and
	experience gained since the publication of [RFC3588] (see for
example
	[RFC5224]) which is now under revision by the DIME Working Group
and
	will provide a revised set of recommendations and procedures for
IANA
	considerations [draft-ietf-dime-rfc3588bis]."

	
	Regards,
	Dong
	
	-----Original Message-----
	From: Hannes Tschofenig [mailto:[email-masked]] 
	Sent: Friday, August 29, 2008 3:48 AM
	To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
	Cc: Sun, Dong (Dong); [email-masked]
	Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw
	
	Hi Dan, 

	
	
	I sent a mail to him. 

	> also include the discussions around 3588bis)
	
	draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling
using
	Diameter. In the DIME working group we also have a document that
deals
	with QoS signaling, namely

	Other SDOs are, however, not required to use the work we do in
the IETF
	on certain Diameter applications. Additionally, they may enhance
or
	modify it. There are many reasons why this happens and I will
not go
	into the details of those. Call it a matter of life that has
todo with
	psychology rather than technical arguments. 
	
	For us in DIME it does not really matter why ITU-T works on this
	specific subject and it does not matter to us from a review
point of
	view either. 
	
	The reason why the ITU-T (and previously OMA with
	http://tools.ietf.org/html/rfc5224) came to the DIME working
group is
	actually related to a suggestion from our side (based on the
Diameter
	extensibility discussions we had) to define new Command Codes
whenever
	the ABNF of a command is modified by adding, removing or
semantically
	changing required AVP (i.e, those marked as {}). By defining new
Command
	Codes we believe to better avoid interoperability problems. 
	
	The OMA has followed that suggestion (and so did ITU-T, to some
extend)
	but obviously ran into an issue with the requirements for the
allocation
	of Command Codes (compared to the allocation of Application IDs)
based
	on what RFC 3588 says. RFC 3588 allows vendors (in this case
SDOs) to
	register applications without going through the IETF process but
has
	different rules for the allocation of Command Codes. The DIME
working
	group had a long discussion about this issue and decided to
change the
	rules for allocating Command Codes with the revision of RFC 3588
(see
	
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt)
	and to align the procedure with the way how Application IDs are
	requested. The main reasons for this decision were the
following: 
	
	* We did not want to encourage SDOs to misuse Diameter Command
Codes
	when they don't want to come to the IETF (and thereby causing
	interoperability issues). 
	
	* We did not want to drag all the SDOs to the IETF when it comes
to
	extending Diameter. Diameter is a very popular protocols among
other
	SDOs and this approach would not scale very well nor are we the
experts
	in all the applications areas people have in mind where Diameter
could
	be used.
	
	* Some of us believe that the decision to have different rules
for
	Application ID allocation and Command Code assignment was a
mistake
	since it does not make a lot of sense from a logical point of
view. 
	
	* We should not treat the 3GPP differently to other SDOs since
the 3GPP
	was given a bunch of Command Codes without a corresponding
specification
	(see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to
be
	consistent in our behavior. 
	
	As such, we came up with the idea to have an "interim" solution
for
	dealing with requests regarding Diameter Command Codes before
RFC
	3588bis gets published as an RFC. 

	I will think about text. Maybe it is lack of imagination on how
	protocols could be used? Wouldn't be the first time that a
protocol is
	used in a way not originally envisioned. Example: RSVP - RSVP-TE
	
	Funny enough, the idea about using Diameter for the purpose of
NAT and
	firewall signaling actually came from the IETF MIDCOM working
group, see
	http://www.ietf.org/rfc/rfc4097.txt
	Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their
favorite
	protocol and it turns out that this was the wrong decision. Hard
to
	predict preferences...

	> deal with as few such cases in the future as possible (ideally
zero).
	
	That's certainly a good idea. We are having a final round of
reviews and
	I have asked the authors of the draft to also re-read the
document to
	avoid problems in later stages (as they have happened with other
	Diameter documents already). 
	
	Ciao
	Hannes

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 14 Nov 2008 21:00:27 -0600

Sun, Dong (Dong) [mailto:[email-masked]] writes:

Glen,

Yes. The ITU-T Rec has been updated based on Hannes' comments e.g. the ABNF
issue, and a response was sent to the exploder a while ago. I don't see any
further comments/objection.

certainly, some of those comments (e.g. CCR/CCA), as indicated by Hannes,
are related to 3GPP Gx 29.212 spec since the ITU-T Rw adopts some of Gx
spec. For the interoperability issue, they have to be resolved by 3GPP.
Moreover, they are irrelevant to this ID for the request of new command code
PIR/PIA (There is no question about the use of PIR/PIA). 

It does; however, it appears that the next IESG telechat is not until 4
December & this document is not on that agenda.  Perhaps it could be added?

Thanks,

Dong

  _____  

B. R.
Tina

----- Original Message ----- 

To: [email-masked] 

Regards,
Dong

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, August 29, 2008 3:48 AM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
Cc: Sun, Dong (Dong); [email-masked]
Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw

Hi Dan, 

I sent a mail to him. 

Ciao
Hannes

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sat, 15 Nov 2008 04:06:33 +0100

It can be added as a returning item, or we can even try to clear the
existing DISCUSSes before - as it was already once on the IESG agenda.
Yet, the first thing that needs to happen is to have the revised ID
published as soon the submission blackout period ends the coming Monday.

Dan

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Glen Zorn
	Sent: Saturday, November 15, 2008 5:00 AM
	To: 'Sun, Dong (Dong)'; [email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: Re: [Dime] DISCUSS: draft-sun-dime-itu-t-rw

	Glen,

	Yes. The ITU-T Rec has been updated based on Hannes' comments
e.g. the ABNF issue, and a response was sent to the exploder a while
ago. I don't see any further comments/objection.

	certainly, some of those comments (e.g. CCR/CCA), as indicated
by Hannes, are related to 3GPP Gx 29.212 spec since the ITU-T Rw adopts
some of Gx spec. For the interoperability issue, they have to be
resolved by 3GPP. Moreover, they are irrelevant to this ID for the
request of new command code PIR/PIA (There is no question about the use
of PIR/PIA). 

	It does; however, it appears that the next IESG telechat is not
until 4 December & this document is not on that agenda.  Perhaps it
could be added?

	Thanks,

	Dong

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Fri, 14 Nov 2008 21:13:39 -0600

Dan,
 
I have submitted a revised I-D draft-sun-dime-itu-t-rw-02 to the
Internet-Drafts team. They promised to have it posted next Monday
(11/17).
 
Regards,
Dong

From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Friday, November 14, 2008 10:07 PM
To: Glen Zorn; Sun, Dong (Dong); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Dime] DISCUSS: draft-sun-dime-itu-t-rw

Dan

	Glen,

	Thanks,

	Dong