|
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:ppfautz at att.com]
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 +1-732-420-4962 From: Cartwright,
Kenneth [mailto:kcartwright at tnsi.com] 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: drinks-bounces at ietf.org [mailto:drinks-bounces at ietf.org]
On Behalf Of PFAUTZ, PENN L, ATTCORP 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 +1-732-420-4962 This e-mail message is for the sole use of the intended recipient(s)and may 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. |
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.