Subject: [drinks] LUF and LRF (again)

From: David Schwartz <[email-masked]>
Date: Thu, 18 Feb 2010 13:54:57 +0200

In our discussions on the weekly call the issue of scope of charter came up again (sigh) with the age old question of do we limit ourselves to target definition (i.e. WHO --> LUF) or do we tackle the bigger issue of target routing (i.e. HOW or WHERE --> LRF). The answer to this question affects many aspects of what is being provisioned and as such it is crucial to resolve at this stage.

Can people weigh in on this now please so we can better prepare for Anaheim?

(Personally, I am in favor of including the LRF - will send a more detailed email at a later point explaining my thoughts on this)

David

---

From: "Maharishi, Manjul" <[email-masked]>
Date: Thu, 18 Feb 2010 09:16:40 -0500

Hi David,

I liked the way you characterized it - Who->LUF, How/Where->LRF (maybe this was discussed earlier, and I just didn't catch it).

I am in favor of including LRF in the DRINKS charter/scope. Without that, the scope gets severely limited, and becomes just one step away from any of the regulatory bodies data (line ownership and portability).

Manjul

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Schwartz
Sent: Thursday, February 18, 2010 6:55 AM
To: [email-masked]
Subject: [drinks] LUF and LRF (again)

David
_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 18 Feb 2010 09:58:49 -0500

Maybe I missed something, but I did not know there was any question about this.  We are definitely covering LRF and the LUF.

But just on a side note, I'd not say that the LUF = Who  and the LRF = WHERE.

I'd say that the LUF = WHERE (where is the ultimate destination) and the LRF = HOW (how to get to the ultimate destination).

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Schwartz
Sent: Thursday, February 18, 2010 6:55 AM
To: [email-masked]
Subject: [drinks] LUF and LRF (again)

David

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Thu, 18 Feb 2010 10:27:21 -0500

I think the issue is at least partly that of *distinguishing* LUF and
LRF per the Speermint model in a drinks implementation. There are use
cases in which one wants drinks to handle the LUF function and leave the
LRF to other means and some in which the functions may be combined.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cartwright, Kenneth
Sent: Thursday, February 18, 2010 9:59 AM
To: David Schwartz; [email-masked]
Subject: Re: [drinks] LUF and LRF (again)

Maybe I missed something, but I did not know there was any question
about this.  We are definitely covering LRF and the LUF.

But just on a side note, I'd not say that the LUF = Who  and the LRF =
WHERE.

I'd say that the LUF = WHERE (where is the ultimate destination) and the
LRF = HOW (how to get to the ultimate destination).

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Schwartz
Sent: Thursday, February 18, 2010 6:55 AM
To: [email-masked]
Subject: [drinks] LUF and LRF (again)

In our discussions on the weekly call the issue of scope of charter came
up again (sigh) with the age old question of do we limit ourselves to
target definition (i.e. WHO --> LUF) or do we tackle the bigger issue of
target routing (i.e. HOW or WHERE --> LRF). The answer to this question
affects many aspects of what is being provisioned and as such it is
crucial to resolve at this stage.

Can people weigh in on this now please so we can better prepare for
Anaheim?

(Personally, I am in favor of including the LRF - will send a more
detailed email at a later point explaining my thoughts on this)

David

This e-mail message is for the sole use of the intended recipient(s)and
may
contain confidential and privileged information of Transaction Network
Services.
Any unauthorised review, use, disclosure or distribution is prohibited.
If you
are not the intended recipient, please contact the sender by reply
e-mail and destroy all copies of the original message.

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 18 Feb 2010 11:10:33 -0500

Agreed.  After discussing this further I see the point that the LUF may or may not return the ultimate destination (the WHERE).  So perhaps my statement that LUF always returns the ultimate destination was too strict.  There are cases where the LUF would just return some identifier that represents the WHO, while not returning the ultimate destination.

Mapping what is happening in the real world onto these Speermint abstractions is "interesting".

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L (ATTCORP)
Sent: Thursday, February 18, 2010 10:27 AM
To: [email-masked]
Subject: Re: [drinks] LUF and LRF (again)

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----

Ken

-----Original Message-----

David

---

From: [email-masked]
Date: Thu, 18 Feb 2010 16:21:47 +0000

> There are cases where the LUF would 
> just return some identifier that represents the WHO, while not 
> returning the ultimate destination.

That's closest to my vision for DRINKS et al.

The LUF says "WHO", and in many cases "roughly WHERE".

That "roughly WHERE" corresponds to the "destination group" term that I 
introduced.

The LRF then turns "roughly WHERE" into "this particular ingress point".

> abstractions is "interesting".

It sure is, although FWIW what I've described above is pretty much the 
proposed model for the UK number portability database, should OFCOM ever 
decide to mandate one.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Sumanth Channabasappa <[email-masked]>
Date: Thu, 18 Feb 2010 15:15:33 -0700

As an FYI, some of us who expressed interested in DRINKS have gotten together since late-Jan, with weekly calls, to discuss and make progress. To clarify, these calls were/are not "official DRINKS calls", but offline calls between interested participants aimed at re-building the momentum, which we seemed to have lost late last year. The plan has always been to get the discussions jumpstarted on the DRINKS mailing list.

This email is an attempt to summarize the current thoughts, and an effort to solicit feedback on the DRINKS list going forward (as planned).

= The I-D authors and the participants suggest the following prior to the cutoff for the next IETF:
a) Address comments and questions raised on the I-Ds so far (see below)

b) Update the following I-Ds, based on a): 
- Requirements (http://tools.ietf.org/html/draft-ietf-drinks-usecases-requirements-00)
- Protocol (http://tools.ietf.org/html/draft-mule-drinks-proto-01)

c) Based on the recommendation/decision in Stockholm, the decision is to separate the protocol definition into two parts: transport-agnostic details (e.g., data models) and transport-specific extensions (e.g., use with SOAP/HTTP, RESTful web services etc.). Accordingly, draft-mule-drinks-proto will continue to be transport-agnostic, and we plan to submit a *new* I-D for SOAP/HTTP as the transport (again, based on discussions in Stockholm). The understanding is that if participants are interested in alternative transports, they will submit additional I-Ds specifying usage.  

==================================================================
SUMMARY of unaddressed comments, specific thoughts and open issues
==================================================================

> Should we, or should we not use, NAPTRs within the provisioning data structure?
  After discussing the pros and cons of this topic, the current proposal is to keep the NAPTR data structure as-is, and we can add non-NAPTR data in separate data structures. If there is disagreement, please volunteer to help us change the data structure.
    
> Questions around LUF and LRF (again!)
  While we can address some of this in DRINKS (see thread already started by David, earlier today), perhaps SPEERMINT should tackle this? Specifically, there is confusion as to whether the LUF is a domain name or an AoR (we think it is the latter). Some of the participants (Alex, Ken, Manjul, David) plan to check with SPEERMINT on this.

> Support for portability use cases, specifically around TN public identities
  This is important, and volunteers (primarily David) are discussing use cases that will be proposed for this topic.

> Suggestions to simplify the data model
  Volunteers (primarily Alex) are trying to address this. Specific suggestions are encouraged.

> Questions around the requirements or use cases
  Please provide specific comments on any use case or requirement that is unclear or contentious

> Open questions under discussion
  What is the scope of the LRF functionality within the protocol?
  What comprises the SED?

====

If I missed anything, I encourage others to chime in.

Thanks!
- S