Subject: [Dime] Is DNS-based diameter peer discovery mandatory to implement?

From: Robert Sparks <[email-masked]>
Date: Thu, 08 Mar 2012 14:02:13 -0600

Question: Is the DNS-based peer discovery mechanism mandatory to implement?

The first paragraph of 5.2 speaks in terms of "supported" and if you 
read that to mean "implemented" the answer is no, but after talking to 
some folks I'm not sure that was the intent. Was the intent mandatory to 
implement, optional to use? That would ensure that an operator had the 
option to start using the DNS-based discovery mechanism when it was the 
right thing to do.

RjS

---

From: Jouni <[email-masked]>
Date: Thu, 8 Mar 2012 23:20:24 +0200

Robert,

> Question: Is the DNS-based peer discovery mechanism mandatory to implement?

No.

> 
> The first paragraph of 5.2 speaks in terms of "supported" and if you read that to mean "implemented" the answer is no, but after talking to some folks I'm not sure that was the intent. Was the intent mandatory to implement, optional to use? That would ensure that an operator had the option to start using the DNS-based discovery mechanism when it was the right thing to do.

Optional to implement and optional to use.

- Jouni

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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 08 Mar 2012 15:52:21 -0600

> Optional to implement and optional to use.
Is there a thread you can point to where the WG discussed this?

---

From: Jouni <[email-masked]>
Date: Fri, 9 Mar 2012 00:51:43 +0200

Robert,

> Is there a thread you can point to where the WG discussed this?

Hmm.. I don't recall any with any analysis or such. It has been
asked few times though. Optional to implement & use has been my
interpretation since all time.

Maybe Glen remembers discussions from the early days.

- Jouni

---

From: <[email-masked]>
Date: Fri, 9 Mar 2012 01:56:06 +0100

Hi Robert,

Sorry but I failed to understand how 
 
 "The first option (manual configuration) MUST be supported by all Diameter nodes, while the latter option (DNS) MAY be supported."

can be interpreted as "DNS option is mandatory to implement and optional to use".

For me, the meaning of this sentence is clear, if not crystal clear: the DNS-based mechanism was optional to implement (supported) and therefore optional to use too.

Regards,

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jouni
Envoyé : jeudi 8 mars 2012 23:52
À : Robert Sparks
Cc : [email-masked]
Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?

Robert,

- Jouni

---

From: Robert Sparks <[email-masked]>
Date: Thu, 08 Mar 2012 19:14:13 -0600

> can be interpreted as "DNS option is mandatory to implement and optional to use".
Reread my question - I'm not suggesting it does. I'm asking if what's 
written reflects what the working group decision was, and for a pointer 
into that working group discussion.
> asked few times though. Optional to implement&  use has been my

---

From: Glen Zorn <[email-masked]>
Date: Fri, 09 Mar 2012 10:01:01 +0700

On 3/9/2012 3:02 AM, Robert Sparks wrote:
> implement, optional to use? 

Good question.  The text in question uses the term "Diameter node",
which is a computer actually running Diameter, so my take on it would be
that the node might not support the option (in terms of actually using
it)but that the option would nevertheless be available (i.e.,
implemented).  It seems like the text could be clearer though -- any
suggestions?

> That would ensure that an operator had the

---

From: jouni korhonen <[email-masked]>
Date: Fri, 9 Mar 2012 10:17:22 +0200

Hi,

> implemented).  It seems like the text could be clearer though -- any

How about:

   ..
   discovery, the following mechanisms are described.  These are based
   on existing IETF standards.  The first option (manual configuration)
   MUST be implemented and supported by all Diameter nodes, while the
   latter option (DNS) MAY be implemented and MAY be supported  by
   Diameter nodes.

However, we could also try to make DNS option more widely used, since
every box in practice has to have some level of DNS resolver capability:

   ..
   MUST be implemented and supported by all Diameter nodes, while the
   latter option (DNS) SHOULD be implemented and if implemented MAY be
   used by Diameter nodes.

Opinions?

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Fri, 09 Mar 2012 15:27:46 +0700

>    latter option (DNS) SHOULD be implemented and if implemented MAY be

As I mentioned, I had always thought that it was a requirement of an
implementation, just that you don't have support it in a deployment due
to the use of the term "node".

---

From: jouni korhonen <[email-masked]>
Date: Fri, 9 Mar 2012 10:40:46 +0200

Glen,

> to the use of the term "node".

My interpretation has always been not mandatory/required to implement.
What the others think? If folks think it has always been required we
need to make the wording explicit. If there are others (apart from me
and Lionel) who read it as not required to implement, I guess SHOULD
is the strongest we can have here.

- Jouni

---

From: Krishna Prasad <[email-masked]>
Date: Fri, 9 Mar 2012 08:46:23 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni korhonen
Sent: Friday, March 09, 2012 2:11 PM
To: Glen Zorn
Cc: [email-masked]
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement?

Glen,

- Jouni

I agree with Joni & Lionel, I never interpreted this as mandatory/required and always thought it is optional. 

-Prasad

---

From: <[email-masked]>
Date: Fri, 9 Mar 2012 10:34:32 +0100

If it is only about the node, is there even any reason to "mandate" the implementation of DNS in a node?

What about:

"A Diameter implementation MUST include the first option (manual configuration) and MAY [or "SHOULD" if preferred] include the latter option (DNS)."

Regards,

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Krishna Prasad
Envoyé : vendredi 9 mars 2012 09:46
À : jouni korhonen; Glen Zorn
Cc : [email-masked]
Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatoryto implement?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni korhonen
Sent: Friday, March 09, 2012 2:11 PM
To: Glen Zorn
Cc: [email-masked]
Subject: Re: [Dime] Is DNS-based diameter peer discovery mandatory to implement?

Glen,

- Jouni

-Prasad

---

From: Robert Sparks <[email-masked]>
Date: Fri, 09 Mar 2012 09:19:41 -0600

>> implemented).  It seems like the text could be clearer though -- any

It's not sufficient to rely on the underlying computer having DNS libraries.
You specified DIAMETER specific logic - the person that wrote the 
diameter code
is going to have to write code - it might _use_ a DNS library on an 
underlying
OS, but it's the DIAMETER code that's going to have to provide the 
inputs to the
NAPTR queries, (or SRV queries, if starting at that level), and follow 
the rules in
this document on interpreting the results. _Thats_ the code that needs 
to be mandatory
to implement.

---

From: <[email-masked]>
Date: Fri, 9 Mar 2012 18:12:39 +0100

What about:

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Robert Sparks
Envoyé : vendredi 9 mars 2012 16:20
À : jouni korhonen
Cc : [email-masked]
Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?

---

From: Robert Sparks <[email-masked]>
Date: Fri, 09 Mar 2012 12:52:08 -0600

I think we must be talking past each other. That suggestion doesn't look 
different than what's in -30, and
doesn't address the point I made in the message you responded to.

Let me try this a different way. The text in -30 and the text you 
propose below say that it's OK for
an operator to have deployed a "conformant" diameter implementation and 
later discover that he
can't use the DNS-based peer discovery mechanism without acquiring 
another one (or going back to
the original provider for a code change). Is that really what the group 
concluded? That would surprise me,
and I'd like to read the discussion so I can see how the group landed there.

I could see a decision that would say that manual configuration still 
needs to be an option available to the operator.

RjS

---

From: Glen Zorn <[email-masked]>
Date: Sun, 11 Mar 2012 14:10:26 +0700

> "A Diameter implementation MUST include the first option (manual configuration) and MAY [or "SHOULD" if preferred] include the latter option (DNS)."

I see know reason for this: we're talking about writing code here, not
forcing deployment of an option; by requiring implementations to include
DNS as running code we may make developers' lives a bit more stressful
but ease that of their customers.

---

From: jouni korhonen <[email-masked]>
Date: Sun, 11 Mar 2012 22:04:42 +0200

Hi,

On Mar 9, 2012, at 8:52 PM, Robert Sparks wrote:

> I think we must be talking past each other. That suggestion doesn't look different than what's in -30, and
> Let me try this a different way. The text in -30 and the text you propose below say that it's OK for
> an operator to have deployed a "conformant" diameter implementation and later discover that he
> can't use the DNS-based peer discovery mechanism without acquiring another one (or going back to
> the original provider for a code change). Is that really what the group concluded? That would surprise me,

Vendors can always build a nice licensing scheme around this ;-)

I could be OK with "MUST implement, MAY use" for DNS-based peer discovery
if that is what WG wants. The issue I have in general with "MUST" in current
DNS-based peer discovery is its limited usability in deployments. A peer does
(S-)NAPTR/SRV query for another domain (realm) and finds an address etc of
its node representing the entire realm. However, this does not help me if
there are intermediates that my requests must go through e.g. before leaving
my own realm. It then ends up only specific type of nodes (like edge agents
of some administrative domain) even needing DNS functionality for DNS-based
dynamic peer discovery.

Anyway, as said, I am mostly open for anything.

> I could see a decision that would say that manual configuration still needs to be an option available to the operator.

Yes. Manual is must.

- Jouni

---

From: <[email-masked]>
Date: Mon, 12 Mar 2012 09:29:01 +0100

Hi,

I could also agree on the "MUST implement/MAY use" but would it mean that existing Diameter implementations that do not provide DNS-based discovery mechanism would be not anymore compliant with the Base protocol and would have to be upgraded?

Regards,

Lionel

-----Message d'origine-----
De : jouni korhonen [mailto:[email-masked]] 
Envoyé : dimanche 11 mars 2012 21:05
À : Robert Sparks
Cc : MORAND Lionel RD-CORE-ISS; [email-masked]
Objet : Re: [Dime] Is DNS-based diameter peer discovery mandatory toimplement?

Hi,

Yes. Manual is must.

- Jouni

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 12 Mar 2012 13:59:18 +0100

This would be my reading. 

Regards,

Dan

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, March 12, 2012 10:29 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Dime] Is DNS-based diameter peer discovery
> mandatorytoimplement?
> 
> Hi,
> 
> I could also agree on the "MUST implement/MAY use" but would it mean
> that existing Diameter implementations that do not provide DNS-based
> discovery mechanism would be not anymore compliant with the Base
> protocol and would have to be upgraded?
> 
> Regards,
> 
> Lionel
> 
> >> "A Diameter implementation MUST include the first option (manual
> configuration) and MAY [or "SHOULD" if preferred] include the latter
> option (DNS)."
> >>
> >> Lionel
> >>

---

From: Glen Zorn <[email-masked]>
Date: Tue, 13 Mar 2012 13:12:11 +0700

> This would be my reading.

Not mine: implementations that are RFC 3588 compliant would remain so.
We even specifically call out various conditions under which
implementations that only comply with RFC 3588 can interoperate with
this version.  In any case, who cares?  there is a reason why it's
called "soft" ware...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 13 Mar 2012 11:45:49 +0100

Sure - implementations that are RFC 3588 compliant would remain so (i.e. compliant to RFC 3588). It is just that RFC 3588 will not be any longer the latest standards track RFC for Diameter after rfc3588bis is published and obsoletes it. 

Regards,

Dan

> From: Glen Zorn [mailto:[email-masked]]
> Sent: Tuesday, March 13, 2012 8:12 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> >> (S-)NAPTR/SRV query for another domain (realm) and finds an address
> etc
> >> of
> >> its node representing the entire realm. However, this does not help
> me
> >> if
> >> of some administrative domain) even needing DNS functionality for
> DNS-
> >> based
> >> dynamic peer discovery.
> >>
> >>> and I'd like to read the discussion so I can see how the group
> landed
> >> there.
> >>>
> >>>> De : [email-masked] [mailto:[email-masked]] De la
> part
> >> de Robert Sparks
> >>>>>>> Question: Is the DNS-based peer discovery mechanism mandatory
> to
> >> implement?
> >>>>>>>
> >>>>>>> The first paragraph of 5.2 speaks in terms of "supported" and
> if
> >> you
> >>>>>     MUST be implemented and supported by all Diameter nodes,
> while
> >> the
> >>>>>     MUST be implemented and supported by all Diameter nodes,
> while
> >> the

---

From: jouni korhonen <[email-masked]>
Date: Tue, 13 Mar 2012 13:15:16 +0200

We'll discuss this during the Dime meeting for sure if there
is no clear consensus before that.

As an individual I tend to belong to "SHOULD/MAY" implement
camp for the reason stated earlier.

- Jouni