[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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]
Sent: Monday, August 03, 2009 3:37 PM
To: Cartwright, Kenneth; drinks at ietf.org
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

+1-732-420-4962

 

 


From: Cartwright, Kenneth [mailto:kcartwright at tnsi.com]
Sent: Monday, August 03, 2009 3:28 PM
To: PFAUTZ, PENN L, ATTCORP; drinks at ietf.org
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: drinks-bounces at ietf.org [mailto:drinks-bounces at ietf.org] On Behalf Of PFAUTZ, PENN L, ATTCORP
Sent: Monday, July 27, 2009 12:46 PM
To: drinks at ietf.org
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

+1-732-420-4962

 

 


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.


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.