Subject: Re: [Speermint] Meeting minutes from IETF 73 Speermint session

From: "James McEachern" <[email-masked]>
Date: Mon, 26 Jan 2009 22:27:59 -0500

Daryl,
I volunteered to do a detailed review of the SPEERMINT Peering
Architecture draft, so in the spirit of "better late than never" I will
begin sending my comments to the list for consideration.  My comments
will be in several emails over the rest of the week...

First a nit:

1. References.  It appears that the references (at least in the
introduction) are off by one. SPEERMINT Requirements is shown as [13],
but is actually [14] while Terminology is shown as [12] but is [13] in
the reference section.  I didn't go further, but please check to ensure
references are correct.

Next, a couple of general comments related to consistency:

2. Originating vs. Initiating SSP: Sometimes we use one, sometimes the
other. In this case I'm pretty sure everyone agrees on what we mean, so
let's pick one or the other and use it throughout.  (I'm kind of leaning
toward "initiating" but cold live with either.)

3. SSP vs. peer: Most of the time we use "SSP", but in some sections we
begin to use "peer". I think the term "peer" is relative, and leaves us
open to all sorts of confusion, while the SSP is clear. My preference is
to use SSP throughout, and I will assume that in any remaining comments.

4. Target vs. Terminating:  I'll save that one for later, as I don't
believe we all are in agreement just yet on that particular one.

Now on to section specific comments:

5. Section 2. Network Context, final paragraph says:
" The members of a federation may jointly use a set of functions such 
   as location function..."
Comment: The terminology draft defines LUF and LRF, but does not define
"location function".  Similarly, this draft also discusses LUF and LRF,
but not "location function". 
Recommended Solution:  Change "location function" to "Look-Up Function,
Location Routing Function,".  While we are at it, we probably should
capitalize the other functions the way we have done in the Terminology
draft.

6. Section 3. Procedures, 
Bullet 5 states " the determination of the UAS,".
Comment: This is unclear to me.  I think we are determining something
about the UAS, perhaps the location of the UAS.  If this is correct,
then we should change it to say this.

7. Section 3. Procedures
This section might be strengthened by changing to the active voice.  For
example, bullet 6 would be a lot clearer (to me at least) if we just
said "establish the session".  However, I'm ok with group consensus on
this one.

8. Section 3. Procedures: 
The final paragraph states that "In the case the target SSP is different
from the terminating SSP ...".  
Comment: If we are going to open this can of worms (and I fear we must)
then it is crucial that we clearly define what terminating and target
SSP mean, and use them with absolute consistency throughout the
document.  If there was a consensus on the list after Minneapolis, I
missed it; to me it sounded like two solitudes. 

Since I don't want to just raise issues, I am going to propose what I
think makes sense here, and let people react.
Target SSP = the SSP we are currently trying to reach.  If the session
is "retargeted" then it is given a new target SSP (unless of course the
new target is in the same SSP).  This seems consistent with general
usage.
Terminating SSP = the SSP where the session actually does terminate. 

The remainder of my comments assume these definitions.  

In the spirit of making concrete suggestions, I would suggest that the
final paragraph of Section 3 be modified as follows:

Current text:
"In the case the target SSP is different from the terminating SSP it 
   would repeat steps 1-4. This is reflected in Figure 2 that shows the 
   target SSP with its own peering functions."

Change to:
" In the case the initial target SSP is different from the terminating
SSP it would repeat steps 1-4. This is reflected in Figure 2 that shows
the 
   target SSP with its own peering functions."

9.  Section 5.1. Originating SSP Procedures
We use "originating SSP" in the section heading, but "initiating SSP" in
the body.

10. Section 5.1.1. The Look-Up Function
Currently states "Purpose is to determine the SF of the target domain
..."
Comment: Earlier in this document, and in the Terminology draft, we
state that the LUF determines the target domain - not the SF of the
target domain. In addition, we later state that the LRF determines the
location of the SF.  Therefore I believe we should change as follows:
Current text:
"Purpose is to determine the SF of the target domain ..."

Change to:
"Purpose is to determine the target domain ..."

11. Section 5.1.1. The Look-Up Function
Currently states "...optionally develop Session Establishment Data (SED)
[12]."  
Comment: I believe this is only true when the target address is in the
same domain as the initiating SSP, otherwise the LRF develops the SED.
Therefore I suggest we change as follows:
Current text:
"... optionally develop Session Establishment Data (SED) [12]. "

Change to:
"... if the target address is in the same administrative domain as the
initiating SSP, optionally develop Session Establishment Data (SED)
[12]. "

12. Section 5.1.1.1 Target address analysis.
Second paragraph states that 
"... the initiating SSP resolves the call routing data by using the
Location Routing Function (LRF)"

I suggest we recognize the step where the LUF first determines the
target domain, by changing the above to read:
"... the initiating SSP first determines the target domain, and then
resolves the call routing data by using the Location Routing Function
(LRF)"

13. Section 5.1.1.1 Target address analysis.
The third paragraph begins with "For example...".  This confuses me.
The previous paragraph ends by saying what the LRF does, but then
immediately gives examples of how the LUF works - at least I think this
is what it is providing.  At the very least we need to somehow qualify
the examples, though to be honest I'd be happy if we just deleted the
third and fourth paragraphs..

---- end of first set of comments ----

More comments to follow in a day or so.

Jim McEachern
T:+1 613 763-3419
M:+1 613 853-0176

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Daryl Malas
Sent: Thursday, December 18, 2008 8:24 PM
To: [email-masked]
Cc: Alexander Mayrhofer; Livingood,Jason
Subject: [Speermint] Meeting minutes from IETF 73 Speermint session

All,

The meeting minutes for the IETF 73 Speermint session can be found here:

http://www.ietf.org/proceedings/08nov/minutes/speermint.txt

Please check the notes, as some of you volunteered to do things...and,
some by the end of the year (2008).  Also, there were several issues
that were going to be further discussed on the mailing list.  Those of
you presenting on these topics, please start the threads.

If you have questions, concerns, or feel like something important was
left out let us know.

Thank you for your participation in Minneapolis.

Regards,

Daryl

Speermint co-Chair

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint