Re: [Seamoby] CT Requirements Comments from IESG

Hmm.

So since there is no natural language conversation going on between these two routers, may I suggest that "meaning" is not a
sufficiently precise word to use in this context?

How about something along the lines of "usable to establish services on the new router" or something like that.

            jak

----- Original Message -----
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
Sent: Wednesday, July 10, 2002 7:08 AM
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Main Entry: mean·ing
Pronunciation: 'mE-ni[ng]
Function: noun

4 a : the logical connotation of a word or phrase

------------

I propose, for section 5.5.2, to replace "meaning" with
"original syntax and semantics", unless someone has a better
idea.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 9, 2002 16:56
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; <seamoby@ietf.org>
> Sent: Tuesday, July 09, 2002 12:50 PM
> Subject: RE: [Seamoby] CT Requirements Comments from IESG
>
>
> > James:
> >
> >   Sorry, but a small clarification: I did not say that
> dynamic context
> > was rejected, I said that I recalled that there was, at one time, a
> > requirement
> > that attempted to directly address dynamic context and the
> need to update it
> >
> > and that requirement was eventually removed. I think the
> reason was the
> > difficulty
> > in defining "dynamic" versus "static" context, as Charlie
> outlines in his
> > response.
> >
> >   There is, however, a requirement, 5.5, that speaks to
> context updates in
> > general:
> >
> > 5.5 Context Update and Synchronization
> >
> > 5.5.1 The context transfer protocol MUST be capable of updating
> >       context information when it changes.
> >
> > 5.5.2 A context update MUST preserve the integrity, and thus the
> >       meaning, of the context at each receiving AR.
> >
> >    The context at the AR actually supporting an MN's traffic will
> >    change with time. For example, the MN may initiate new
> microflow(s),
> >    or discontinue existing microflows. Any change of context at the
> >    supporting AR must be replicated at those ARs that have already
> >    received context for that MN.
> >
> > I am now wondering why this requirement did not answer the
> IESGs concerns?
> > Possibly because it does not explicitly mention "dynamic context" or
> > "dynamic
> > updates"?
> >
>
> I suspect that is it. What is "meaning"?
>
>             jak
>
>

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby