Re: [Dime] [Technical Errata Reported] RFC6733 (4209)

[<[e-mail]>]

Here is my view on this erratum:

The text describing the "BUSY" and "DO_NOT_WANT_TO_TALK_TO_YOU" cases is consistent with the text found in the introduction of the section 5.4.

  "In the event that the
   disconnect was a result of either a shortage of internal resources or
   simply that the node in question has no intentions of forwarding any
   Diameter messages to the peer in the foreseeable future, a periodic
   connection request would not be welcomed.  The Disconnection-Reason
   AVP contains the reason the Diameter node issued the Disconnect-Peer-
   Request message.

   The Disconnect-Peer-Request message is used by a Diameter node to
   inform its peer of its intent to disconnect the transport layer and
   that the peer shouldn't reconnect unless it has a valid reason to do
   so (e.g., message to be forwarded). " 

So the main purpose for sending a DPR with the causes "BUSY" and "DO_NOT_WANT_TO_TALK_TO_YOU" is actually to avoid the periodic reconnection attempts governed by the Tc timer.
These exceptions are mentioned in the section 2.1:

  "When no transport connection exists with a peer, an attempt to
   connect SHOULD be made periodically.  This behavior is handled via
   the Tc timer (see Section 12 for details), whose recommended value is
   30 seconds.  There are certain exceptions to this rule, such as when
   a peer has terminated the transport connection stating that it does
   not wish to communicate."

Now, it is true that there is no clear guideline on how to behave when receiving the cause "BUSY" and this explains why some implementations in the field still attempt to re-open the connection, as after a normal transport failure detection. But it does not mean that the text in the RFC6733 is wrong.

Finally, if it is an attempt to clarify/modify the behavior of the peer receiving DPR with the "BUSY" cause, I don't think that using errata would be the most appropriate way.

Let see if there are other views on this issue.

Regards,

Lionel 

-----Message d'origine-----
De : Benoit Claise [mailto:[e-mail]] 
Envoyé : mercredi 14 janvier 2015 12:09
À : [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; MORAND Lionel IMT/OLN
Cc : [e-mail]; [e-mail]
Objet : Re: [Technical Errata Reported] RFC6733 (4209)

Document authors, DIME participants,

Can we please have a discussion on this errata validity.

Regards, Benoit
> The following errata report has been submitted for RFC6733, "Diameter 
> Base Protocol".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4209
>
> --------------------------------------
> Type: Technical
> Reported by: Hans Liu <[e-mail]>
>
> Section: 5.4.3
>
> Original Text
> -------------
>        BUSY                              1
>           The peer’s internal resources are constrained, and it has
>           determined that the transport connection needs to be closed.
>           A receiver of a DPR with above result code SHOULD NOT attempt
>           reconnection.
>
> Corrected Text
> --------------
>        BUSY                              1
>           The peer’s internal resources are constrained, and it has
>           determined that the transport connection needs to be closed.
>           A receiver of a DPR with above result code SHOULD either
>           connect to an alternate node, or attempt reconnection
>           after a time period.
>
> Notes
> -----
> In most implementations, the Diameter node will continue to serve its peer after the resources recover and expect reconnection. If the Diameter node won't like reconnection from peer, DO_NOT_WANT_TO_TALK_TO_YOU can be used instead of BUSY.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please 
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party (IESG) can log in to 
> change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6733 (draft-ietf-dime-rfc3588bis-33)
> --------------------------------------
> Title               : Diameter Base Protocol
> Publication Date    : October 2012
> Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
> Category            : PROPOSED STANDARD
> Source              : Diameter Maintenance and Extensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
>
> .
>


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.