Subject: [AAA-WG]: Diameter Base update

From: <[email-masked]>
Date: Thu, 25 Jul 2002 15:05:30 +0300

Hi all,

I have updated the base spec & sent it to the drafts editor
for publication.  For those of you who want to get an 
early look, it can be grabbed from here:

http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-12.txt

The major changes deal with the replacing of Vendor Command
Codes with Experimental Command codes.  Hopefully, the
change is sufficient & we can send this to the IESG.

John

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 25 Jul 2002 17:43:29 -0700

John Loughney [mailto://[email-masked]] writes:

> for publication.

I think that this move is at best premature.  Allison Mankin (the only IESG
member I could find who had even partially read a recent version of the
draft) has promised to produce a document 'in a couple of weeks' detailing
her objections (if any) to the draft and I think it would be far better to
wait and see what she has to say, instead of just caving in to Randy's
technically unjustified demands.  Furthermore, I find it difficult to
believe that there is any WG consensus on these changes.

> For those of you who want to get an

I may be alone on this, but I don't believe that our job as a WG is to twist
and spindle and mutilate our work until it is acceptable to the IESG (in
this case, actually just one IESG member).  Rather, our task is to produce
the best work we can _through the rough-consensus based IETF process_ and
submit it.  If the IESG refuses to even look at it, then we should abandon
our work, rather than participating in a clear violation of the process.
Let _them_ explain to ITU-T and TIA (not to mention Vodafone, Orange, SK
Telecom, etc.) why they are blocking the deployment of 3G, since they don't
seem to be disposed to explain it to us.

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Jul 2002 18:08:05 -0700

glen,

i am having a hard time finding any technical substance in your
argument.  could you please be more clear?

as 3gpp and all other actual users (including prominent cisco folk)
have agreed that this is a sufficient forward path, the end of the
world does not appear very nigh from this vantage point.  and the
ad homina are definitely not useful.

randy

---

From: Johan Johansson <[email-masked]>
Date: Fri, 26 Jul 2002 12:01:58 +0000

As far as I know 3gpp had no problem with the original solution either. 
In fact, you are the only one who has ever *had* a problem with it, and 
you refuse to tell us what the problem is. Did you really ask "all other 
actual users"? Are you sure you didn't miss some? Also, I beg to differ 
that this is a sufficient forward path. Merging the command code 
namespaces is a backward path. Since this is to be an IETF standard it 
would seem more important that the workgroup agrees with the solution 
than anyone else.

Glen's mail doesn't have technical substance since it's not about 
technical matters but about how to repair your blatant breach of IETF 
process, i.e. it does not express a technological argument but an 
administrative one. Even had it been lacking technical substance where 
such was merited, your first priority should be to explain your 
mysterious aversion to vendor specific commands and show why they are 
dangerous. This is and has been your task for the last month(s).

John, you have submitted a draft that you know there is not only no 
workgroup consenus around, but rather there
is workgroup opposition. Until Randy produces a solid case for his 
objections that will turn the workgroup's opinion in his favour, and 
note that I am still not excluding this possibility, the problem does 
not exist. If he refuses to pass the draft on without explaining in an 
acceptable way why he does so, we can always find another way to get it 
to the IESG.

j

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 26 Jul 2002 09:30:56 -0700

> argument.  could you please be more clear?

There is no technical substance in my argument, it is simply a matter of
process, and lack of WG consensus.

> as 3gpp and all other actual users (including prominent cisco folk)

Perhaps some of those people would like to comment; I know that I have
received several emails from 3GPP folk and others which were not happy in
the least.

> ad homina are definitely not useful.

I hardly think that calling your argument "technically unjustified"
qualifies as an ad hominem attack, nor does noting that the IESG members I
spoke to hadn't read the draft (it's not even a dig: I wouldn't read it,
either, unless I had to).

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Jul 2002 09:50:32 -0700 (PDT)

> technically unjustified demands.

While I am sure that Allison will find additional issues for us to be
concerned about, given our previous conversations, I doubt that her
additional analysis will absolve us of the need to address the issues that
Randy has raised.

> Furthermore, I find it difficult to

WG input is certainly required, and so I would suggest that the best thing
is to do a short AAA WG last call on -12, during which we can incorporate
additional IESG comments. I'd also like to start WG last call on a revised
NASREQ document at the same time, assuming that can be made available.

---

From: Pete McCann <[email-masked]>
Date: Fri, 26 Jul 2002 15:17:38 -0500

Hi,

Here are my comments on base-12.  I think at least some of these
issues are outright errors/omissions, while others relate to the
ongoing question of experimental/vendor specific application IDs.
Please consider this a set of issues for the last call.

-Pete

Submitter name:           Pete McCann
Submitter email address:  [email-masked]
Date first submitted:     26 July 2002
Reference: 
Document:                 base
Comment type:             T/E
Priority:                 1
Section:                  1, 3, and 11
Rationale/Explanation of issue: 

  1.2.3  Creating New Authentication Applications
  ...
     Every Diameter application specification MUST have an IANA assigned
     Application Identifier (see section 2.4) or a vendor specific
     Application Identifier.
  ...
  1.2.4  Creating New Accounting Applications
  ...
     Every Diameter accounting application specification MUST have an IANA
     assigned Application Identifier (see section 2.4) a vendor specific
     Application Identifier.

Last paragraph is missing the word "or".

Should we say instead, "or a vendor specific experimental Application
Identifier."?  Or should we delete the last clause, as all Application
Identifiers are now assigned by IANA, regardless of whether
vendor-specific or not?

Also from Section 1.2.4:

   This is why "disk writing" accounting servers should advertise
   themselves as "Relays" that can handle any Application ID, including
   Vendor-Specific.

There is an issue with this text that was raised by Glen Zorn but
never resolved: I think we mean to say "can handle any *Accounting*
Application ID.".  A disk-writing accounting server can handle only
ACR and ACA, not just any command.  Remember, the standards-track
application IDs that can appear in CER are split into normal App-IDs
and Accounting App-IDs.  I think a "disk writing" accounting server
should advertise support for the Relay applicationin an Accounting
App-ID *only*.  Also, I don't think such a server can handle any
Vendor-Specific application, because such an application can never
include standards-track commands such as ACR/ACA under the current
rules, as I understand them.

  3.3  Diameter Command Naming Conventions

     Diameter commands typically includes one or more English words

Should be, "Diameter command names typically include"

  3  Diameter Header
  ...
      Command-Code values in the range 0xfffff0 through 0xffffff are
                                       ^^^^^ this is only 16 commands.  It's conceivable
                                             that even a single application may need
                                             more.  Should we use 0xffff00 through
                                             0xffffff instead?  If so, also need to
                                             correct the range in Section 11.2.1.
      reserved for experimental use.  Commands in this range MUST use an
      IANA-assigned Application ID from the range 0xff00000000 -
      0xfffffffe (see Section 11.3).  Commands in this range MUST also
      include a Vendor-Specific Application ID  AVP (see section 6.11).

Should we clarify here that experimental use = vendor specific?  I.e.,
"Command-Code values in the range 0xfffff0 through 0xffffff are
reserved for use by vendor specific, experimental commands."

Also, remove extra space between "ID" and "AVP" in the last line.

  11.3  Application Identifiers

     As defined in section 2.4, the Application Identifier is used to
     identify a specific Diameter Application. There are standards-track
     application ids and vendor specific application ids.

     IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for
     standards-track applications; and 0xff00000000 - 0xfffffffe for
     vendor specific applications.
  
     Both Application-Id and Acct-Application-Id AVPs use the same
     Application Identifier space.

     Vendor-Specific Application Identifiers, encoded in the Vendor-
     Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to
     the vendor's enterprise number, is for Private Use.

I don't think this is strictly true anymore.  The Vendor-Specific
Application Identifiers are now from the experimental range
0xff00000000 - 0xfffffffe and are in fact managed by IANA.  Or perhaps
I've misinterpreted the intention here?

If the experimental command code space is to be managed by IANA, this
IANA Considerations section is inadequate.  It needs to give the
assignment policy (Expert Review, First-come-first-served, etc.).

We could leave the space for Private Use (I actually favor this
alternative), but I think that brought up the routing concerns raised
by Bernard - then we would need to parse the AVPs to find out how to
route the command.  Also such a policy conflicts with the language in
section 3 under "Command Codes", which I quoted above.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 26 Jul 2002 19:26:23 -0700

> additional analysis will absolve us of the need to address the issues that

For reference, here is reproduced the entire text of the relevant issue:

Issue 268: Diameter Extensibility
Submitter name: Randy Bush
Submitter email address: [email-masked]
Date first submitted: 29-Dec-01
Reference:
Document: Base 08
Comment type: Technical
Priority: S
Section:
Rationale/Explanation of issue:
is eeems that the results of the discussion last may of vendor-specific
commands never made it into the documents. in specific.

---

25 of the base:

"The Command-Code field is three octets, and is used in order to
communicate the command associated with the message. The 24-bit address
space is managed by IANA (see section 11.2).

In the event that the Command-Code field contains a vendor specific
command, the four octet Vendor-ID field contains the IANA assigned "SMI
Network Management Private Enterprise Codes" [2] value. If the
Command-Code field contains an IETF standard Command, the Vendor-ID field
MUST be set to zero (0). Any vendor wishing to implement a vendor-specific
Diameter command MUST use their own Vendor-ID along with their privately
managed Command-Code address space, guaranteeing that they will not
collide with any other vnedor's vendor-specific command, nor with future
IETF applications."

---

as i said last april,

> as an engineer, i sympathize with the excitement that the protocol is
> very extensible. otoh, an architect might view that the protocol is
> merely a list of name/value tuples to indicate a lack of bounding and
> understanding of the problems and/or inability to make a real design for
> it.
>
> open loop extensibility is really worrying the iesg.

---

and we discussed again in may:

> So, the WG questioned whether the specs could be more relax on the
> IANA requirements for extensibility. Specifically, could a
> vendor-specific extension be created without Standards Action.

i can see arguments for relaxing to info but not iana-only. a
documentation trail is needed.

---

and a number of iesg members made quite clear, or at least tried to, that
any extensions, vendor or otherwise, must require previous documentation
in an rfc.

---

please consider this a bug report. my apologies for not knowing how to
get a bug number etc.

So the question is, and has been, (please excuse my shouting) WHAT ISSUES?
All I can find in the text is rather vague philosophizing.  Outside of this
"issue", there have been a number of somewhat wild and uniformly spurious
claims made about the protocol (e.g., that VSEs may somehow be "mandatory"),
but when I and others asked for these "features" to be pointed out (so they
might be eradicated), only silence ensued.

> additional IESG comments.

Although it seems to be true that in many cases a last call is necessary to
get any WG input at alll these days, this doesn't appear to be the case in
this instance.  There have been several messages (all negative) about this
already.

> I'd also like to start WG last call on a revised