Subject: [Dime] [Q5/11] Fw: how to update Q.3303.3

From: Tina TSOU <[email-masked]>
Date: Fri, 19 Sep 2008 09:58:01 +0800

Hi Dong,
Thank you for letting us to know the situation.
 
The situation of Q.3303.3 is in this link - pre-published.
http://www.itu.int/rec/T-REC-Q.3303.3
 
If it is easy, clear, you could contact TSB to update it during the publication process.
If not, you could select any of the following ways.
A) Create a separate document of Amendment for Q.3303.3
B) Do it in Q.3323 Rw Diameter version 2
 
If I'm wrong in the procedure, anyone in the list please correct me.

-HTH-

B. R.
Tina
ITU-T Q.5/11 Rapporteur

----- Original Message ----- 
From: Sun, Dong (Dong) 
To: Tina TSOU 
Cc: Tom Taylor ; Huanghexian 
Sent: Friday, September 19, 2008 3:01 AM
Subject: how to update Q.3303.3

Tina et al,

as a follow-up for the q.3303.3, i am responding to Hannes's comments (attached). Since those issues are originally from other SDO's specs not by this spec. I am not sure if we can fix all them alone (e.g. the change of ANBF for some madantory AVPs) since it will cause inerop issue. Meanwhile it is possible to remedy some "M/P" bit problems although they are copied from other specs. 

Just wonderin what's the procedure to update the Q.3303.3?

Thanks,
Dong

--------------------------------------------------------------------------------
From: Sun, Dong (Dong) 
Sent: Sunday, August 31, 2008 9:39 PM
To: 'Tina TSOU'; 'Huanghexian'
Cc: 'Tom Taylor'
Subject: RE: [Q5/11] Re: DISCUSS: draft-sun-dime-itu-t-rw

Tina,
I am doing well. Thanks for the caring.
this is just a suggestion to minimize the impact on Rw work.  I personally can follow up the IETF mess, but does not expect they will resolve it soon since it is totally out of my control in IETF (and not my main focus at the moment). hope it will not affect the Q5/11 work too much.

Dong

--------------------------------------------------------------------------------
From: Tina TSOU [mailto:[email-masked]] 
Sent: Sunday, August 31, 2008 8:44 PM
To: Huanghexian; Sun, Dong (Dong)
Cc: Tom Taylor; [email-masked]
Subject: [Q5/11] Re: DISCUSS: draft-sun-dime-itu-t-rw

Hi Dong,
We all hope you get out the mess soon. I sent you a SMS, no response, so we are concerned about your current situation.
You are the editor of Rw version 1. IETF Diameter ID is only assigned to those published standards, in other words Rw v1 rather than Rw v2.

B. R.
Tina
  ----- Original Message ----- 
  From: Sun, Dong (Dong) 
  To: Tina TSOU ; Huanghexian 
  Cc: Tom Taylor 
  Sent: Sunday, August 31, 2008 2:05 PM
  Subject: FW: DISCUSS: draft-sun-dime-itu-t-rw

  Tina, Hexian,

  FYI. It looks like the IETF has some problem to approve the
  informational RFC for the Rw application ID due to its own internal
  issue (sort of bureaucracy :-).
  In order to complete the Rw spec asap, I think we may find a way out
  ourselves. I remembered Tom ever mentioned to get new application ID for
  the Rs. Maybe we could do the same thing . 

  In addition, since I am in this mess and not the editor anymore, It is
  more appropriate to let Hexian follow up as Tom suggests.

  What do you think?

  Tom,

  Could you elaborate on the steps to register a new application ID to
  IANA without sending the informational RFC?

  BTW, I will not attend the Sep meeting in persion. 
  Wish your guys have good time there.

  Rgs,
  Dong

  -----Original Message-----
  From: Mark Townsley [mailto:[email-masked]] 
  Sent: Saturday, August 30, 2008 9:14 AM
  To: Hannes Tschofenig
  Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked];
  [email-masked]; Sun, Dong (Dong)
  Subject: Re: DISCUSS: draft-sun-dime-itu-t-rw

  Hannes Tschofenig wrote:
  > 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. 
  If that is truly the consensus of the IETF, then the IANA policies and
  protocol itself should allow a clean division between one SDO and
  another. The existence of this RFC would seem to be proof point that
  this is not the case.
  > 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.
  This may be the case with Diameter, and that is perfectly fine if in
  fact that is the consensus of the IETF. But understand that it is very
  much not the case with other IETF protocols. The IETF community tends to
  be *quite* concerned when other SDOs want to extend our protocols
  without our knowledge or consent.
  > * 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. 
  It's not about the SDOs themselves as much as it is about the mechanism
  being proposed. That is why some of us are concerned as to whether the
  documents that this ID point to have been reviewed. It's the mechanism
  itself that is important, not just the container.

  If you are saying that the IETF wants to draw an architectural line such
  that anyone can use Diameter in anyway they choose without involving the
  IETF, that's fine, but there needs to be consensus on that and the
  policies need to reflect it. Since this is most definitely not always
  the case for other protocols, we need to be very clear to ourselves, and
  to other SDOs, on this matter.
  > 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). 
  I would be far, far, more comfortable seeing IETF consensus on the
  interaction policies with other SDOs with respect to Diameter before
  approving draft-sun-dime-itu-t-rw. If the revision to RFC3588 helps to
  clarify that, please accelerate its publication.

  Thanks,

  - Mark
  > 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.
  >>>
  >>>
  >>>
  >>>       
  >
  >   

Subject: [Dime] Review of draft-sun-dime-itu-t-rw-01
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 28 Aug 2008 08:52:39 -0500

I reviewed draft-sun-dime-itu-t-rw-01 the normative reference:

   [Q.3303.3]
              ITU-T Recommendation Q.3303.3, "Resource control protocol
              no. 3 (rcp3): Protocol at the Rw interface between the
              Policy Decision Physical Entity (PD-PE) and the Policy
              Enforcement Physical Entity (PE-PE): Diameter", 2008.

I think it is the right decision to define two new command codes (PIR /
PIA) as it is done in [Q.3303.3]. 

HOWEVER, more command codes must be specified as the ABNF of existing
Diameter Base Protocol and Diameter Credit Control Commands has been
modified. I therefore request that [Q.3303.3] be changed in the
following way since they would cause interoperability problems with
existing Diameter Base Protocol and Diameter Credit Control
implementations. 

* CCR Command 

The ABNF of the original CCR command is modified by removing the
required Service-Context-ID AVP. 

* CCA Command

The ABNF of the original CCA command is modified by turning the required
Result-Code AVP into an optional one. 

* RAA Command

The ABNF of the original RAA command is modified by turning the required
Result-Code AVP into an optional one. 

* ASR Command

The ABNF of the original ASR command is modified by adding the required
Abort-Cause AVP. 

* ASA Command 

The ABNF of the original ASA command is modified by turning the required
Result-Code AVP into an optional one. 

The simplest way to solve these issues is to register new command codes.
Alternatively you could think about why you actually need to modify the
ABNF of these commands. 

Another remark: A couple of tables are listed with AVP flag settings. I
got the impression that these flag settings got copied from other
documents. This could be a problem since the M-bit (and other flags)
meaning is specific for the specific application and command. A new
Diameter application/Command may require a different flag setting. I
hope that the ITU-T checked this aspect since otherwise they will
experience a lot of interop issues. 

Table 2 is missing indications about the M bit usage. 
Table 3 is missing indications about the P bit usage. 
Table 4 is missing indications about the P bit usage. 

A minor issue: 

The description about soft-state vs. hard-state was confusing since
there is no Reservation-Lifetime AVP specified.
Furthermore the text refers to NASREQ and the specification does not use
NASREQ. 

Ciao
Hannes
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime