Re: [Speermint] Meeting minutes from IETF 73 Speermint session (Arch Draft Review)

["James McEachern" <jmce at nortel.com>]

Daryl,
Your comments generally look good to me. Now that I know someone is
listening, I will continue my review over the next few days.  Based on
your comments, I will assume the following for the remainder of my
review:

- I will use Originating SSP rather than Initiating SSP
- I will assume we are using SSP rather than peer
- I will try to use only Target SSP  
- I will only use UA

All your other specific suggestions are fine with me.

Jim McEachern
T:+1 613 763-3419
M:+1 613 853-0176
-----Original Message-----
From: Daryl Malas [mailto:D.Malas at cablelabs.com] 
Sent: Tuesday, February 03, 2009 12:02 PM
To: speermint at ietf.org
Cc: McEachern, James (CAR:AR00)
Subject: [Speermint] RE: Meeting minutes from IETF 73 Speermint session
(Arch Draft Review) 

Jim,

Thanks for the review.

Comments in-line...


----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.malas at cablelabs.com
 

> -----Original Message-----
> From: James McEachern [mailto:jmce at nortel.com] 
> Sent: Monday, January 26, 2009 8:28 PM
> To: speermint at ietf.org
> Cc: Daryl Malas
> Subject: RE: [Speermint] Meeting minutes from IETF 73 
> Speermint session
> 
> 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.)

I personally prefer "originating".

> 
> 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.

I agree with using SSP.

> 
> 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.

I think Jon made valid points at the last WG meeting that 'Target' is a
better term, since a call may be transferred or re-targeted later.  I
suggest we use 'Target'.

> 
> 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.

I agree this is a little too ambiguous.  I recommend we change it to
"determine the location of the target UA".  On a separate note, there
has been previous discussion on the use of UAC or UAS versus simply UA.
I believe in those previous discussions it was determined the preference
was to simply refer to either as a 'UA'.  This is a minor nit, but
believe it will make the draft more consistent with other similar IETF
works.

> 
> 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.

I am okay with either.  To me, they mean the same thing.

> 
> 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. 

I am glad you brought this issue up.  My preference is to simply scrap
"Terminating SSP" altogether.  IMO, it is to difficult for it to be
consistent.  If we must use it, I prefer we refer to "Terminating SSP"
only if the session actually *ends* there.  In this case, I mean a
successful "BYE" dialog occurs.  All other references should refer to
"Target SSP".

> 
> 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."

Keeping in the spirit of removing Terminating SSP, I would suggest we
change it to "In the case the target SSP changes during the session 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: speermint-bounces at ietf.org 
> [mailto:speermint-bounces at ietf.org] On Behalf Of Daryl Malas
> Sent: Thursday, December 18, 2008 8:24 PM
> To: speermint at ietf.org
> 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:d.malas at cablelabs.com
> _______________________________________________
> Speermint mailing list
> Speermint at ietf.org
> https://www.ietf.org/mailman/listinfo/speermint
>