Subject: [martini] martini-gin-02: profound impact

From: Martien Huysmans <[email-masked]>
Date: Fri, 21 May 2010 08:42:00 +0200

martini-gin-02, chapter 2 contains the following text
  The following paragraph is perhaps the most important in
  understanding the solution defined in this document.
  ...
  In terms of impact to the solution at hand,
  the following two constraints have the most profound effect: ....
  ...

These are some heavy words: "most important" and "profound ".
So I know that I really need understand this chapter.
But I do not. Can somebody explain?

/Martien

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 May 2010 08:57:54 -0500

> understanding the solution defined in this document.

That can probably be tightened up. One can actually implement the 
solution without understanding these constraints, but such a person may 
be left boggled by why things are done the way they are. So I'll revise 
to read "...in understanding the reasons for the design decisions made 
in this document."

 > the following two constraints have the most profound effect: ….
 > ...
 >

Wow. I thought the two highlighted constraints were written in clear, 
concise, unambiguous, and easy-to-understand language. Perhaps I presume 
too much knowledge on behalf of my audience. For your benefit, I'll try 
to explain these two constraints more explicitly below. Let me know if 
there's something regarding which you need further explanation.

"(1) The PBX cannot be assumed to be assigned a static IP address"

This means that the PBX may or may not have a static (unchanging) IP 
Address (the unique identifier used to indicate end-points on the 
Internet), and that we, as designers of the GIN solution, cannot make 
any assumptions one way or the other about whether this is true.

"(2) No DNS entry can be relied upon to consistently resolve to the IP 
address of the PBX."

This means that there may or may not be an entry in the global Domain 
Name Service database (the distributed database used on the internet to 
convert human-readable names into IP addresses) that, when resolved, 
produces that IP address of the PBX, and that we, as designers of the 
GIN solution, cannot make any assumptions one way or another about 
whether this is true.

If your confusion was in relation to any of the other three sentences in 
the section, let me know, and I can try to clear up their intended 
meaning. They're less central to the thesis of this section, but I don't 
want them to leave you confused.

And, if your confusion isn't regarding any single sentence, but rather 
the gestalt of the whole section, the short summary is: "This document 
proposes doing some things that seem pretty stupid to anyone who really 
understands SIP, but we have some good reasons for doing so. These 
reasons are explained by the requirements document, and here are the two 
that make the biggest difference."

Does any of that help?

/a

---

From: Martien Huysmans <[email-masked]>
Date: Tue, 25 May 2010 13:55:44 +0200

Adam

I appreciate your effort.
I do not want to change the text in section 2. I just want to understand it's message.
So perhaps I do not really understand SIP, but this is a good time to learn.

What I fail to understand (from section 2) is
how this (the PBX properties (1) and (2)) is different compared to a regular user signing up with a SSP
which doesn't have (1) and (2) either. To me these (1) and (2) feel like normal properties, nothing unique for a PBX.

/Martien  

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Friday, May 21, 2010 3:58 PM
To: Martien Huysmans
Cc: [email-masked]
Subject: Re: [martini] martini-gin-02: profound impact

On 5/21/10 01:42, May 21, Martien Huysmans wrote:
 > martini-gin-02, chapter 2 contains the following text  > The following paragraph is perhaps the most important in  > understanding the solution defined in this document.

That can probably be tightened up. One can actually implement the solution without understanding these constraints, but such a person may be left boggled by why things are done the way they are. So I'll revise to read "...in understanding the reasons for the design decisions made in this document."

 > ...
 > In terms of impact to the solution at hand,  > the following two constraints have the most profound effect: ....
 > ...
 >

Wow. I thought the two highlighted constraints were written in clear, concise, unambiguous, and easy-to-understand language. Perhaps I presume too much knowledge on behalf of my audience. For your benefit, I'll try to explain these two constraints more explicitly below. Let me know if there's something regarding which you need further explanation.

This means that the PBX may or may not have a static (unchanging) IP Address (the unique identifier used to indicate end-points on the Internet), and that we, as designers of the GIN solution, cannot make any assumptions one way or the other about whether this is true.

"(2) No DNS entry can be relied upon to consistently resolve to the IP address of the PBX."

This means that there may or may not be an entry in the global Domain Name Service database (the distributed database used on the internet to convert human-readable names into IP addresses) that, when resolved, produces that IP address of the PBX, and that we, as designers of the GIN solution, cannot make any assumptions one way or another about whether this is true.

If your confusion was in relation to any of the other three sentences in the section, let me know, and I can try to clear up their intended meaning. They're less central to the thesis of this section, but I don't want them to leave you confused.

And, if your confusion isn't regarding any single sentence, but rather the gestalt of the whole section, the short summary is: "This document proposes doing some things that seem pretty stupid to anyone who really understands SIP, but we have some good reasons for doing so. These reasons are explained by the requirements document, and here are the two that make the biggest difference."

Does any of that help?

/a

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 26 May 2010 01:00:19 +0200

I think only the following sentences in this chapter provides useful
information:
"Within the problem space that has been established for this work,
   several constraints shape our solution.  These are being defined in
   the MARTINI requirements document [8]."

The rest seems very subjective, because other readers can easily argue
that other aspects are far more profound. Suggest to remove the other
sentences.

/Hans Erik van Elburg

On Fri, May 21, 2010 at 3:57 PM, Adam Roach <[email-masked]> wrote:
> That can probably be tightened up. One can actually implement the solution
> without understanding these constraints, but such a person may be left
> boggled by why things are done the way they are. So I'll revise to read
> "...in understanding the reasons for the design decisions made in this
> document."
>
>> ...
> concise, unambiguous, and easy-to-understand language. Perhaps I presume too
> much knowledge on behalf of my audience. For your benefit, I'll try to
> explain these two constraints more explicitly below. Let me know if there's
> something regarding which you need further explanation.
>
> This means that the PBX may or may not have a static (unchanging) IP Address
> (the unique identifier used to indicate end-points on the Internet), and
> that we, as designers of the GIN solution, cannot make any assumptions one
> way or the other about whether this is true.
>
>
> This means that there may or may not be an entry in the global Domain Name
> Service database (the distributed database used on the internet to convert
> human-readable names into IP addresses) that, when resolved, produces that
> IP address of the PBX, and that we, as designers of the GIN solution, cannot
> make any assumptions one way or another about whether this is true.
>
> If your confusion was in relation to any of the other three sentences in the
> section, let me know, and I can try to clear up their intended meaning.
> They're less central to the thesis of this section, but I don't want them to
> leave you confused.
>
> And, if your confusion isn't regarding any single sentence, but rather the
> gestalt of the whole section, the short summary is: "This document proposes
> doing some things that seem pretty stupid to anyone who really understands
> SIP, but we have some good reasons for doing so. These reasons are explained
> by the requirements document, and here are the two that make the biggest
> difference."
>
> Does any of that help?
>
> /a
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>