RE: Action item from yesterday's meeting

Juergen,

The change is really as simple as follows. The PRR and PER will specify an
input realm field indicating INTERNAL or EXTERNAL. INTERNAL will indicate (A0,
A1) as input. EXTERNAL will indicate (A2, A3) as input. That is all there is to
this. This is not complex. But, the change will make the MIDCOM workable for
all flavors of NAT. 

Hope you understand. Thanks.

regards,
suresh

--- Juergen Quittek <[email protected]> wrote:

> Mary,
> 
> --On 19.11.2004 17:09 h -0500 Mary Barnes wrote:
> 
> >
> > I think I understand the concerns as presented by both sides of this issue.
>  However, the concerns raised by Suresh appear able to be addressed outside
> the scope of the MIB, based on Juergen's response (i.e. I don't see Suresh's
> requirements for making
> > the change to be compelling).  That said, as Christian mentioned, if both
> models could be supported without a huge amount of effort in the current
> version of the MIB (and not impacting the current functionality provided by
> the MIB), I would also be
> > okay with that.  Is this a simple change/extension or does it have a
> broader impact on the MIB?
> 
> Of course we can extend the semantics to support not just (A0,A3) as input,
> but also as Suresh suggested (A0,A1) and (A2,A3).  We could for example add
> a switch object that indicates which of the three choices is used by the
> MIDCOM client.
> 
> This requires some extra effort of specification and implementation.
> We need to specify the semantics of all three alternative procedures
> for PRR and PER and of course have a more flexible (and error-prone)
> implementation. Currently, there is only one procedure with writeable
> input objects and read-only output objects, some of them related to
> A1 and A2 (see MIB definition).  We would have to make the A1- and
> A2-related objects writeable in general.  Then the value of the new
> switch object would indicate which objects are writeable inpt objects
> and which are output objects.  The implementation would loose the
> safety of static access checks for output objects that we have now.
> 
> With no doubt we can realize the discussed extension but in order to
> do so, we need a convincing reason that justifies the effort.
> I do not think we have found such a reason yet.
> 
> We should further be aware of the fact that (typically) increasing
> complexity implicitly reduces acceptance of the new standard at
> potential implementers.
> 
> Thanks,
> 
>     Juergen
> -- 
> Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
> 
> 
> > Mary
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of
> Melinda Shore
> > Sent: Tuesday, November 16, 2004 12:19 PM
> > To: [email protected]
> > Subject: Re: [midcom] Action item from yesterday's meeting
> >
> > I'm intending to get this issue closed in the next week (or sooner,
> > if possible).  Juergen and Suresh have presented their concerns, and
> > if there are other people who have opinions or questions or even
> > just want to indicate how they're leaning, that would be a big help.
> >
> > Thanks,
> >
> > Melinda
> >
> > _______________________________________________
> > midcom mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/midcom
> 
> 
> 
> 
> 


=====