Re: [drinks] Comment on today's drinks discussion

["Cartwright, Kenneth" <[e-mail]>]

Thanks.

1)       The Speermint Arch doc only separates them logically.  It dose not separate them physically.  So Speermint certainly allows that a single piece of software could be both LUF and LRF or just LUF or just LRF.  So I think we're ok on that front.
2)       What complexity has "increased"?  iow, do you have some specific recommendations?

Ken

________________________________
From: PFAUTZ, PENN L, ATTCORP [mailto:[e-mail]]
Sent: Monday, August 03, 2009 3:37 PM
To: Cartwright, Kenneth; [e-mail]
Subject: RE: Comment on today's drinks discussion

Ken:
1) My take was that Speermint separates LUF/LRF. The protocol as defined can certainly support returning a LUF output, but folks seemed to want to push further than that or not make any distinction between the two functions.

2) my concern is the increasing complexity takes the protocol beyond our needs which might lead us to look towards something simpler.

Penn Pfautz
AT&T Access Management
[phone]


________________________________
From: Cartwright, Kenneth [mailto:[e-mail]]
Sent: Monday, August 03, 2009 3:28 PM
To: PFAUTZ, PENN L, ATTCORP; [e-mail]
Subject: RE: Comment on today's drinks discussion
Thanks for the feedback.

1) How do you feel that we are not supporting the LUF/LRF concepts?  Can't a Destination Group and its associated Route Group be used to return a URI whose domain name is the one that requires as an output of the LUF?  Or is there something that I'm missing?

2) What specifically would need to be done to the protocol to make it more useful for your company's likely applications?

Ken

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of PFAUTZ, PENN L, ATTCORP
Sent: Monday, July 27, 2009 12:46 PM
To: [e-mail]
Subject: [drinks] Comment on today's drinks discussion

I've been away from the design group for a while since the focus seemed to shift more to lower level design issues outside of my bailiwick but I came away from today's IETF discussion with an uncomfortable feeling about where the drinks effort is heading.
One the one hand I feel that some of the issues we agreed to set aside to narrow scope (LUF/LRF) are coming back to haunt us and on the other that the effort is straining as Otmar suggests to accommodate more and more complexity that should, perhaps be handled elsewhere. Perhaps these are different sides of the same coin.
I for one have concerns about how useful the resulting protocol is likely to be, at least for my company's likely applications.


Penn Pfautz
AT&T Access Management
[phone]


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

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