Subject: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 4 Apr 2011 15:25:19 +0200

Following a comment and recommendation from the Gen-ART review, the WG
discussed the topic of naming the Diameter entities in
draft-ietf-dime-nat-control again at IETF 80 (1st round of discussions
happened at IETF 77):

The outcome of the discussion was the following recommended approach
(hope that I captured things the right way, otherwise, please chime in):

* draft-ietf-dime-nat-control should use the generic term "Diameter
peer" when referring to the two interacting Diameter entities (i.e. we'd
neither create new names for the Diameter entities in DNCA, nor would we
name them client and server).
* for those cases, where procedures/actions of the two peers need to be
differentiated, one would use the description of the function of the
peer in question, i.e. "NAT Controller" and "NAT". 

Although we reached consensus in the WG meeting in Prague, the decision
would need re-confirmation from the list.

Appreciate your support, so that we can get this issue off the table.

Thanks, Frank

Some additional background on the above recommendation: 
Quick summary of the reasoning expressed during the WG meeting:
* DNCA is not a typical client-server application, but represents an
exchange between two Diameter protocol peers; hence "client" and
"server" nomenclature does not really apply to this application. The
descriptions for "server" and "client" roles in RFC 3588, section 1.1
could be misleading when applied to non client-server protocols or non
pure AAA-protocols.
* The DNCA can be implemented per the current I-D without designating
devices as "client" or "server".
* If DNCA would be implemented within an architecture defined by a
different SDO, the names of the two Diameter protocol peers would be
named corresponding to the peering elements within the overall
architecture, i.e. naming from DNCA isn't likely to be leveraged, hence
naming should be as generic as possible.

---

From: Shwetha <[email-masked]>
Date: Wed, 06 Apr 2011 10:00:19 +0530

I support the below proposal of referring to DNCA entities as "Diameter
peer" and explicitly use "NAT Controller" and "NAT" when required.

Thanks,
Shwetha

On 4/4/11 6:55 PM, "Frank Brockners (fbrockne)" <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 19:06:58 +0200

Hi Frank,

Just to confirm that your summary is correct according the consensus reached during the meeting.
I hope that other Dime guys will provide their views on this trivial point that should no longer block the publication of the draft IMHO.

BR,

Lionel 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Shwetha
Envoyé : mercredi 6 avril 2011 06:30
À : Frank Brockners (fbrockne); [email-masked]
Objet : Re: [Dime] call for consent - naming the entities in draft-ietf-dime-nat-control

Thanks,
Shwetha

---

From: Tom Taylor <[email-masked]>
Date: Wed, 6 Apr 2011 17:04:06 -0400

I agree.

---

From: Mark Jones <[email-masked]>
Date: Wed, 6 Apr 2011 18:52:06 -0400

Hi Frank,

I agree with defining the "NAT" and "NAT Controller" roles and using
these terms in the procedures. I also agree with using "Diameter peer"
in text where the role is irrelevant.

Regards
Mark

---

From: Avi Lior <[email-masked]>
Date: Wed, 6 Apr 2011 22:01:38 -0400

I agree with the terminology usage when there are no specific
server/client roles.

After all, Diameter is a peer-to-peer protocol - we tend to forget that.

-- Avi Lior
--Bridgewater Systems

---

From: Qin Wu <[email-masked]>
Date: Thu, 07 Apr 2011 11:31:06 +0800

+1
NAT controller should be defined in this document.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 7 Apr 2011 09:55:44 +0300

Looks good to me.

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Thu, 07 Apr 2011 15:42:10 +0700

> Looks good to me.

Ditto.

---

From: <[email-masked]>
Date: Tue, 19 Apr 2011 13:36:26 +0200

Any other view?
At the end of this week, I think that we can consider that the consensus reached during the meeting is confirmed. It is not necessary to postpone further the RFC publication process of this draft.

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de jouni korhonen
Envoyé : jeudi 7 avril 2011 08:56
À : Frank Brockners (fbrockne)
Cc : [email-masked]
Objet : Re: [Dime] call for consent - naming the entities indraft-ietf-dime-nat-control

Looks good to me.

- Jouni