Subject: [Dime] rfc3588bis-18 comments/questions (message / grouped avp grammar; peer election)

From: Anders G S Svensson <[email-masked]>
Date: Sun, 19 Jul 2009 12:45:41 +0200

I have some comments/questions on
http://www.ietf.org/id/draft-ietf-dime-rfc3588bis-18.txt.

=======================
3.2 and 4.4 specify

   command-def      = command-name "::=" diameter-message
   command-name     = diameter-name
   diameter-name    = ALPHA *(ALPHA / DIGIT / "-")

and

   grouped-avp-def  = name "::=" avp
   name-fmt         = ALPHA *(ALPHA / DIGIT / "-")
   name             = name-fmt

respectively but most specifications in the document include angle
brackets around command-name/name. For example:

   <CER> ::= < Diameter Header: 257, REQ >

These brackets would complicate the parsing a bit since <CER> could be
interpreted as a "fixed" in a previous command-def until "::=" is
parsed.

=======================
3.2 and 4.4 also specify

   diameter-message = header  [ *fixed] [ *required] [ *optional]

and

   avp              = header  [ *fixed] [ *required] [ *optional]

respectively but the distinction between required and optional is a
bit unclear. The production for qual has a comment that min on an
optional avp must be 0 if present but there's no corresponding comment
that min on a required should be at least 1 if present.

In any case, I find comment

                      ; NOTE:  "[" and "]" have a different meaning
                      ; than in ABNF (see the optional rule, above).

on the qual production a bit cryptic. All the optional rule states  is

                      ; The avp-name in the 'optional' rule cannot
                      ; evaluate to any AVP Name which is included
                      ; in a fixed or required rule.  The AVP can
                      ; appear anywhere in the message.

so if the comments are explaining to me that optional doesn't mean
what the word and ABNF would usually convey then I don't see it. The
only point I can see being made (implicitly) is that an avp-name in a
'required' rule *can* evaluate to an avp name included in a fixed or
required rule.

Is there really a required/optional distinction here or is the
distinction just between fixed or not?

=======================
5.6.1 notes that it's not possible to know the identify of a peer
initiating a connection until a CER is received from it, motivating
the R-Conn-CER event in the Peer State Machine. However, the same
problem exists on the initiating side: the peer's identity isn't truly
known until the CEA is received. As a result, the election mandated by
a R-Conn-CER event in state Wait-I-CEA can't take place since one
party in the election isn't yet known.

Am I missing something here?

/Anders

---

From: "Victor Fajardo" <[email-masked]>
Date: Mon, 20 Jul 2009 14:15:36 -0400

Hi Anders,

Thanks for the comments. Replies inline:

=======================
3.2 and 4.4 specify

and

[Victor]: I'm not really sure what you mean. Is this an implementation
specific parsing algo that feed's of the actual text in the document ? If
so, that maybe a implementation specific issue.

=======================
3.2 and 4.4 also specify

and

[Victor]: I can understand that text is really a bit vague. That needs to be
fixed. Anyway, if I understand your last question correctly, a "[..]" is
present in [*required] to provide rules when designing a command ABNF, i.e.
it is possible that a command ABNF may did not define any required avps
(min==0 for required). Within the "diameter-message" ruleset, "[..]" for
*required and *optional are the same but they refer to the ruleset when
designing message.

=======================

[Victor]: 5.6.1 seems clear to me. I'm not sure if waiting for a CEA to
correctly identify a peer your connecting to is logical. You have to know
who you want to talk to so you can connect to begin with. That's why we have
peer discovery. Typically, the host identity in the CEA should match the
identity of the host you connected to.

Regards,
victor

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

---

From: Anders G S Svensson <[email-masked]>
Date: Tue, 21 Jul 2009 00:34:56 +0200

Hi Victor.

Thanks for the reply. Response below.

Yes, the parsing is of definitions written according to the grammar.
My point was simply that angle brackets around command-name aren't
specified in the grammar but are present in all the definitions in the
document.

Yes, this I understand. However, I took the comment's "[" and "]" to
refer to the literal tokens in the optional production:

   optional         = [qual] "[" avp-name "]"

Possibly the wrong reading but, as you say, the text is quite vague.

My point here was that if I can specify

  *{XXX}

for a "required" AVP then it doesn't seem particularly required.
(Since 0 occurrences is acceptable.)

I'm missing a statement that min must be at least 1 for a required avp.

> *required and *optional are the same but they refer to the ruleset when

Well, I have to know the peer's IP address and port to connect. I
don't have to know, and can't know for certain, what Origin-Host the
peer will identify itself as, and it's this that's needed to perform
the election.

Anders

---

From: "Victor Fajardo" <[email-masked]>
Date: Tue, 21 Jul 2009 09:08:39 -0400

Hi Andes,

[Victor]: I see. Seems all diameter related documents follow this convention
of "<cmd-name>" in their definition. Not really sure what about the origins
nor the reasoning behind this practice but we may need to update the grammar
to maintain the well-known practice ... unless you see something else wrong
with it (other than complicating your parser).

  *{XXX}

[Victor]: Now that you mention it, I wonder if  the "[..]" in
"diameter-message = header  [ *fixed] [ *required] [ *optional]" really
follows the "[qual] [ avp-name ]" ruleset or where those "[..]" place there
to delineate fixed, required and optional avp types given that the 'qaul' is
inside the braces. If this is the case then this is what we may want to
clarify.

[Victor]: Then perhaps we should mandate the use or host/identities when
peer makes connection attempts as is already implied by the discovery
schemes (and common practice). It may also be useful since we can validate
the origin-host against the identity that we use to initiate the connection
to. I know that some implementations does this already but I'm not sure if
there's going to be problems during deployment when a node's may not be
completely in sync with the responsible DNS, i.e. a node may have several
registered names, which one does it use for origin-host, or is this a
policy/configuration issue and specs should not really worry about it.

Regards,
Victor

Anders