Subject: Re: [Dime] [Fwd: draft-ietf-dime-rfc3588bis review (1/3)]

From: Victor Fajardo <[email-masked]>
Date: Sun, 02 Nov 2008 08:53:59 -0500

Hi Hannes,

I've incorporated majority of the editorial items you mentioned below. 
Others I've commented below. The changes here should be incorporated 
into draft*-13.txt

> s/The base Diameter protocol is run on port 3868 of both TCP [RFC793] and
>
> SCTP [RFC2960] transport protocols./The base Diameter protocol is run on 
> port
>
> 3868 of both TCP [RFC793] and SCTP [RFC2960].
>
> Delete "Future versions of this specification MAY
>   mandate that clients support SCTP."
>
> I also do not understand why we require that agents and servers must 
> support
>
> SCTP. That does not sound realistic if I consider our interop testing
>
> experience.
>   

It seems expected that during the interop most folks would support TCP 
since that would be the easiest/most natural to implement first. I could 
not remember if there was consensus for requiring SCTP for servers was 
impractical. I would think that at this point (a few years after the 
interop) SCTP support would be generally supported (??) by most diameter 
implementations. I'm ok with relaxing the rule if folks think that 
required support for SCTP is really cumbersome. AFAIK, supporting SCTP 
should be readily available on most stacks and socket APIs.

> 2.8.1.  Relay Agents
>
> s/
>   Relays MAY be used to aggregate requests from multiple Network Access
>   Servers (NASes) within a common geographical area (POP).
> /
>   Relays may, for example, be used to aggregate requests from multiple
>
> Network Access Servers (NASes) within a common geographical area (POP).
>
>
> I think we can delete this sentence since it essentially reflects the
>   

which sentence ?

> definition of a relay:
>
>   Relays SHOULD NOT maintain session state but MUST maintain
>   transaction state.
>   

If you meant the example, then it maybe better to keep it to have a 
clear re-enforcement of the relay definition; i.e. giving examples is 
helpful.

>
>
>
>   Proxies that wish to limit resources MUST maintain session state.
>   All proxies MUST maintain transaction state.
>
> I don't really understand what the first sentence should tell us and the 
> 2nd
>
> one is essentially already described with the definition of the proxy.
>   

Agree. I've removed it.

>   Some AVPs MAY be listed more than once.  The effect of such an AVP is
>   specific, and is specified in each case by the AVP description.
>
>
> There is something wrong with this sentence.
>   

Agree. Not sure what exactly its trying to say but its implying 
something really vague ... better remove it.

> 4.3.  Derived AVP Data Formats
>
>   In addition to using the Basic AVP Data Formats, applications may
>   define data formats derived from the Basic AVP Data Formats.  An
>   application that defines new AVP Derived Data Formats MUST include
>   them in a section entitled "AVP Derived Data Formats", using the same
>   format as the definitions below.  Each new definition MUST be either
>   defined or listed with a reference to the RFC that defines the
>   format.
>
>
> This is sort of interesting, particularly when you look at the 
> IPFilterRule,
>
> as the boundary between Derived AVP Data Formats and AVP definitions is 
> sort
>
> of fuzzy.
>
> Does any other Diameter document ever tried to define new derived Data
>
> Formats?
>   

Not sure. Low probability that other docs would have a derived Data 
format section.

> 4.4.   Grouped AVP Values
>
>   However, the encapsulated AVPs with 'M' (mandatory) bit set MUST
>   belong to the Diameter application the Grouped APV is used in.
>
> I don't quite understand that sentence. Could you explain it a bit?
>   

This was Lionels description. If I'm translating correctly I think it 
meant that inner AVPs with M-bit set must be defined or at the least 
known by the Diameter application using the grouped avp. Does this mean 
the app has the possibility of not recognizing the parent AVP but it has 
knowledge about the children AVPs ? Would it be better to just make this 
'M' bit check relevant to the root Grouped-AVP ?

> 3.  If no NAPTR records are found, the requester queries for those
>       address records for the destination address,
>       '_diameter._sctp'.realm or '_diameter._tcp'.realm.
>
> Why is it necessary to specify two mechanisms to query the DNS?
>
> I will distribute a separate mail about the domain certificate stuff.
>   

Ok.

>
>
> 5.3.5.  Host-IP-Address AVP
>
>
>   The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
>   to inform a Diameter peer of the sender's IP address.  All source
>   addresses that a Diameter node expects to use with SCTP [RFC2960]
>   MUST be advertised in the CER and CEA messages by including a
>   Host-IP- Address AVP for each address.  This AVP MUST ONLY be used in
>   the CER and CEA messages.
>
> s/Host-IP- Address/Host-IP-Address
>
> I wonder why there is the last sentence in there? It is fine to use the AVP
>
> in the CER and CEA message but why is there a need to say that it must only
>
> be used there? That does not make a lot of sense.
>   

good point. it should be removed.

> 5.3.6.  Supported-Vendor-Id AVP
>
>   Multiple instances of this AVP containing the same value SHOULD NOT
>   be sent.
>
> Why not MUST NOT be sent?
>   

agree as well. it should be MUST NOT.

>
> I was also wondering why only a selection of AVPs is listed in Section 5.3
>
> instead of all of them? Any special reason?
>   

I think all  of the AVPs in 5.3 maybe represented/listed but just spread 
throughtout the document.

>
>
> 5.5.4.  Failover and Failback Procedures
>
> Shouldn't it actually read "Fallback" instead of failback?
>
>
>   

AFAIK, I think it the term for service restoration has always been failback.

> 6.1.2.  Sending a Request
>
>   When sending a request, originated either locally, or as the result
>   of a forwarding or routing operation, the following procedures MUST
>   be followed:
>
>   o  the Hop-by-Hop Identifier should be set to a locally unique value.
>
> s/should/SHOULD
>
>   o  The message should be saved in the list of pending requests.
>
> s/should/SHOULD
>
>
> Given that the introductory sentence says "MUST be followed" I was 
> wondering
>
> whether SHOULD is actually too weak here.
>   

Then I think the introductory sentence should be set to SHOULD instead 
of MUST because these recommendations have obvious "preference " 
constraints from the implementor; i.e. implementations my choose not to 
store all pending request because of storage constraints.

> 6.7.2.  Proxy-Info AVP
>
>
> The description for the AVP does not describe the semantic.
>   

Ok. How about modifying the 1st paragraph to:

         "The Proxy-Info AVP (AVP Code 284) is of type Grouped. This AVP
          contains the identity and local state information of Diameter node
          that creates and adds it to a message. The Grouped Data field 
has the
          following ABNF grammar:"

> 6.7.4.  Proxy-State AVP
>
> s/
>
>   The Proxy-State AVP (AVP Code 33) is of type OctetString, and
>   contains state local information, and MUST be treated as opaque data.
>
> /
>
>   The Proxy-State AVP (AVP Code 33) is of type OctetString, and
>   is created by the Diameter server and passed on to the Diameter 
> client. It contains state information that would otherwise be stored at 
> the Diameter.
>   As such, this AVP MUST be treated as opaque data by entities other 
> than the Diameter server that created it.
>   

Proxy-State AVP can be created and inserted by proxies as well (not only 
servers). So we should rephrase the 1st sentence of your suggestion to:

         "The Proxy-State AVP (AVP Code 33) is of type OctetString. It
          contains state information that would otherwise be stored at
          the Diameter entity that created it. As such, this AVP MUST be
          treated as opaque data by entities other Diameter entities."

> 6.8.  Auth-Application-Id AVP
>
>   The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and
>   is used in order to advertise support of the Authentication and
>   Authorization portion of an application (see Section 2.4).  If
>   present in a message other than CER and CEA, the value of the Auth-
>   Application-Id AVP MUST match the Application Id present in the
>   Diameter message header.
>
> If it always matches then does it make a lot of sense?
>   

Yes. This has a lot of history at the interop since there's confusion on 
what these Id's really represent or what its purpose was given that 
there's already and id in the header. Since there is no specified 
concept of a command carrying multiple apps ids we decided to make it 
the same as the header if it is present (for compatibility purposes).

>   This AVP MUST also be present as the first AVP in all experimental
>   commands defined in the vendor-specific application.
>
>   This AVP SHOULD be placed as close to the Diameter header as
>   possible.
>
>
> "This" in the above two sentences refers to the 
> Vendor-Specific-Application-Id AVP. Right?
>   

Yes. I've cleaned them up.

>  If a Vendor-Specific-Application-Id is received that contains both
>   Auth-Application-Id and Acct-Application-Id, then the recipient
>   SHOULD issue an answer with Result-Code set to
>   DIAMETER_AVP_OCCURS_TOO_MANY_TIMES.  The answer SHOULD also include a
>   Failed-AVP which MUST contain the received Auth-Application-Id AVP
>   and Acct-Application-Id AVP.
>
> Why are these only SHOULD level requirements? What happens in the other 
> cases?
>   

Yes your right.

>
> 6.14.  Redirect-Max-Cache-Time AVP
>
>
>
>
>   This AVP contains the maximum number of seconds the peer and route
>   table entries, created as a result of the Redirect-Host, will be
>   cached.  Note that once a host created due to a redirect indication
>   is no longer reachable, any associated peer and routing table entries
>   MUST be deleted.
>
>
> "will be cached" does not provide a good indication how the value provided
> by this AVP should actually be treated. Is this
> * MUST be cached
> * SHOULD cached
> * MAY be cached
>   

Agree. Let's set it to SHOULD be cached ... implementations can have 
room for other techniques.

> I think that the semantic is a bit weak. What can the sender really expect
> when it provides a value with AVP to the receiver?
>   

In this case, the sender does not have any expectation of what the 
receiver eventually decides to do since it is only a passive entity 
(i.e. it never carries state). The redirect agent is similar to a "sign 
post", it provides information but the receiver eventually has to decide 
how to route the message.

>   Diameter may also be used for services that cannot be easily
>   categorized as authentication, authorization or accounting (e.g.,
>   certain 3GPP IMS interfaces).  In such cases, the finite state
>   machine defined in subsequent sections may not be applicable.
>   Therefore, the applications itself MAY need to define its own finite
>   state machine.  However, such application specific state machines
>   MUST comply with general Diameter user session requirements such co-
>   relating all message exchanges via Session-Id AVP.
>
> What specifically is meant by saying that such applications must comply 
> with the
> general Diameter user session requirements?
>   

Hmm... I think that should be re-phrased to:

"However, such application specific state machines SHOULD follow the 
general state machine framework outlined in this document such as the 
use of Session-Id AVPs and the us of STR/STA, ASR/ASA messages for 
stateful sessions."

> 8.6.  Inferring Session Termination from Origin-State-Id
>
> this section is a bit confusing as it talks about CER/CEA and the 
> hop-by-hop processing
> but then refers to end-to-end processing as well.
>   

I've re-factored the section to:

        "The Origin-State-Id is used to allow detection of terminated
          sessions for which no STR would have been issued, due to
          unanticipated shutdown of an access device.

         A Diameter client or access device increments the value of the 
Origin-State-Id
         every time it is started or powered-up. The new Origin-State-Id is
         then sent in the CER/CEA message immediately upon connection to 
the server.
         The Diameter server receiving the new Origin-State-Id can determine
         whether the sending Diameter client had abrubtly shutdown by 
comparing
         the old value of the Origin-State-Id it has kept for that specific
         client is less than the new value and whether it has un-terminated
         sessions originating from that client.

         An access device can also include the Origin-State-Id in request
         messages other than CER if there are relays or proxies in 
between the
         access device and the server. In this case, however, the server 
cannot
         discover that the access device has been restarted unless and 
until it
         receives a new request from it. Therefore this mechanism is more
         opportunistic across proxies and relays.

         The Diameter server may assume that all sessions that were active
         prior to detection of a client restart have been terminated. 
The Diameter
         server MAY clean up all session state associated with such lost 
sessions,
         and MAY also issues STRs for all such lost sessions that were 
authorized
         on upstream servers, to allow session state to be cleaned up 
globally."

>
>
> 8.7.  Auth-Request-Type AVP
>
>   The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is
>   included in application-specific auth requests to inform the peers
>   whether a user is to be authenticated only, authorized only or both.
>   Note any value other than both MAY cause RADIUS interoperability
>   issues.
>
> What are the RADIUS interoperability issues?
>
>   

... have to investigate

>
> 8.9.  Authorization-Lifetime AVP
>
>
> This is typically used in cases where multiple
>   authentication methods are used, and a successful auth response with
>   this AVP set to zero is used to signal that the next authentication
>   method is to be immediately initiated.
>
> Where is this used?
>   

The description is really bad. I'm guessing the original intent is when 
you have multiple EAPs for a single auth session. I think this text is 
just confusing. Multiple auth's are built into the diameter app 
exchanges so the generic base protocol fsm should not concern itself 
with such details. We should just remove that text.

>
>   This AVP MAY be provided by the client as a hint of the maximum
>   lifetime that it is willing to accept.  However, the server MAY
>   return a value that is equal to, or smaller, than the one provided by
>   the client.
>
>
> There are many MAYs in there. Does it mean that a value that is larger 
> can also be provided by the server?
> If not, then shouldn't the second sentence say MUST?
>   

Yes your right. the second sentence should say MUST otherwise the 
negotiation does not make sense.

regards,
victor

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

---

From: Jan Engelhardt <[email-masked]>
Date: Sun, 2 Nov 2008 19:38:46 +0100 (CET)

On Sunday 2008-11-02 14:53, Victor Fajardo wrote:

> Hi Hannes,
>
> I've incorporated majority of the editorial items you mentioned below. Others
> I've commented below. The changes here should be incorporated into
> draft*-13.txt

So let me chime in here then, because I have noticed a number of 
oddities too.

>> s/The base Diameter protocol is run on port 3868 of both TCP [RFC793] 
>> and SCTP [RFC2960] transport protocols./The base Diameter protocol is 
>> run on port 3868 of both TCP [RFC793] and SCTP [RFC2960].
>>
>> support SCTP. That does not sound realistic if I consider our interop 
>> testing experience.
>
> since that would be the easiest/most natural to implement first. I 
> could not remember if there was consensus for requiring SCTP for 
> servers was impractical.

The only problem I see here is operating systems lacking support for 
SCTP right now. Windows might fall under that. To my knowledge, Solaris 
(10) does too somewhat -- because it does not seem to autoload the 
module like a Linux kernel would do. Mac OS X I do not know, but if it 
has, autoload is not happening either. And then of course every Linux 
kernel installation which has SCTP compiled out.