Subject: [Gen-art] Gen-ART LC review of draft-sun-dime-itu-t-rw-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Jul 2008 20:29:43 +1200

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 11:47:13 +0300

A short note on: 

> I am rather surprised that it is proposed to assign a "vendor-specific"
> application identifier when the primary usage is not specific to a vendor;
> an ITU-T Recommendation is not a vendor. RFC3588 says
> "Vendor-Specific Application Identifiers, are for Private Use." This is
> not for private use. Why isn't this a standards track application identifier?

This is common practise in this space to use the so-called vendor-specific space for SDOs. The same approach is applied in RADIUS as well. 

When you look at the enterprise numbers 
http://www.iana.org/assignments/enterprise-numbers
then you will notice that there are a couple of SDOs in there: 

24757: WiMAX Forum

5535: 3rd Generation Partnership Project 2 (3GPP2)

10415: 3GPP

We use this approach already for many years in Diameter.

Ciao
Hannes

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Jul 2008 20:57:00 +1200

Hi Hannes,

On 2008-07-29 20:47, Hannes Tschofenig wrote:
> This is common practise in this space to use the so-called
> vendor-specific space for SDOs. The same approach is applied in RADIUS
> as well.

Thanks for the explanation. I understand the need for
pragmatic solutions for other SDOs. I wonder though whether it
wouldn't be better to be explicit in the base documents, perhaps
by labelling the ranges concerned as "Vendor-Specific or
SDO".  It's particularly strange to tell another SDO that its
usage is "private". However, this clearly isn't a problem
that draft-sun-dime-itu-t-rw can fix.

    Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Jul 2008 11:59:51 +0300

> that draft-sun-dime-itu-t-rw can fix.

We are currently finishing RFC3588bis and that's one of the things that 
will be fixing, if not done already. Need to check.

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Tue, 29 Jul 2008 16:22:32 -0500

Brian,

Concerning your comment: 
""The main information is conveyed by the Rw interface:

   o  Resources reservation and/or allocation request for media flows;
   o  QoS handling request such as packet marking and policing to use;
   o  Gate control (opening/closing) request for a media flow;
   o  NAPT and NAT traversal requesting the necessary address mapping
      information;
   o  Resource usage information request and report for media flows"

The IANA Considerations of RFC3588 says:

  "Diameter is not intended as a general purpose protocol, and
   allocations SHOULD NOT be made for purposes unrelated to
   authentication, authorization or accounting."

I would like to ask whether there has been discussion of the apparent
conflict between these two statements. It doesn't seem that the Rw
interface
is primarily a AAA interface; the resource reservation, QOS policy and
NAT 
traversal signaling in particular do not seem to be AAA functions.

I think the draft should at least explain why it is OK to ignore
the SHOULD NOT in RFC3588." 

In fact, the Diameter is being extended for a variety of applications
that do not look like a pure AAA functions, for example, in the IETF
DIME, we are developing a similar document for QoS application.
Moreover, to some extent, the Rw interface can be viewed as sort of
authorization interface in the context of the AAA.

Does it help answer your question?

Regards,

Dong Sun 
Alcatel-Lucent 
Chief Technology Office
600 Mountain Ave
Murray Hill, NJ 07974 USA
Tel/Fax: +1 908-582-2617 
Email: [email-masked]   

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 4:30 AM
To: General Area Review Team
Cc: Dan Romascanu; [email-masked];
[email-masked]
Subject: Gen-ART LC review of draft-sun-dime-itu-t-rw-01.txt

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jul 2008 17:46:38 +1200

See below...

> Does it help answer your question?

Well, it helps, but IMHO Rw seems to have more functions than
just AAA. However, if your comment applies to other extensions
as well as Tw, this becomes a comment on draft-ietf-dime-rfc3588bis.
IMHO the SHOULD NOT statement that I quoted needs to be
significantly modified (at the moment it's identical to RFC3588).

So both my comments on your draft are actually comments on 3588bis.

Thanks

     Brian