[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NSIS] new GIMPS version
Hi Robert,
I understand. Thank you!
--Takako
On Wed, 02 Jun 2004 17:34:09 +0100
"Hancock, Robert" <robert.hancock at roke.co.uk> wrote:
> Hi Takako,
>
> The phrasing is sloppy (my fault).
>
> Case 1 could better say "... the RAO is relevant to NSIS but
> not the specific node, but the IP layer is unable to recognise
> whether it needs to be passed to GIMPS for further processing
> or whether the packet should be forwarded just like a normal
> IP datagram."
>
> (In this case, because the RAO is not relevant to the specific
> node, the GIMPS processing is to do whatever should have
> been done to a normal datagram. In some implementations,
> GIMPS would not be invoked at all here.)
>
> Case 2 is different because the RAO *is* associated with a set
> of signaling applications, some of which are processed on the
> node (but not this specific one).
>
> Section 8.4 is also relevant here.
>
> Hope this helps,
>
> robert h.
>
> > -----Original Message-----
> > From: Takako Sanda [mailto:sanda.takako at jp.panasonic.com]
> > Sent: 02 June 2004 08:35
> > To: Hancock, Robert
> > Cc: nsis at ietf.org
> > Subject: Re: [NSIS] new GIMPS version
> >
> >
> > Hi Robert,
> >
> > I have a question about section 4.2.4 (Bypass Forwarding).
> >
> > What is a difference between:
> > 1. A downstream datagram mode message contains an RAO value associated
> > with NSIS, and the IP layer is unable to determine whether
> > to forward
> > it.
> > and
> > 2. A downstream datagram mode message contains an RAO value which is
> > relevant to the node, but the signaling application for the actual
> > NSLPID is not processed.
> >
> > I cannot understand the situation "IP layer is unable to
> > determine whether to forward it" in case 1.
> >
> > Best Regards,
> > Takako
> >
> >
> >
> > On Mon, 31 May 2004 01:23:18 +0100
> > "Hancock, Robert" <robert.hancock at roke.co.uk> wrote:
> >
> > > Dear all,
> > >
> > > There is a new version of the GIMPS draft just in time (OK,
> > not really
> > > in time,
> > > but I plead excessive viral computer fun as a
> > distraction...) for the
> > > interim.
> > > Catch it now at http://nsis.srmr.co.uk/draft-ietf-nsis-ntlp-02.txt.
> > >
> > > The change log in 9.1 summarises what has changed since the -01
> > > version.
> > >
> > > We've been asked to indicate how the early review comments
> > have been
> > > taken into account in this version. Most of the details are in the
> > > change log, so I'll just provide some pointers at the end of this
> > > mail.
> > >
> > > Happy reading!
> > >
> > > Robert H.
> > >
> > > Early Review Comment Resolution:
> > >
> > > From Alex (see
> > > http://www.tschofenig.priv.at/nsis/IETF59/nsis-zinin-ietf59.ppt)
> > > Q: Why per-flow routing info in NTLP?
> > > A: More explanation added at end of 4.1.1
> > > Q: Suggests flow based routing?
> > > A: This is a misunderstanding; in any case, related
> > developments have
> > > changed the text (see change number 6)
> > >
> > > From Dave (see
> > > http://www.ietf.org/mail-archive/web/nsis/current/msg03809.html)
> > > Q: Flow definition excludes multicast, splitting
> > > A: Definitions modified, see change number 1
> > > Q: How do you handle not-on-path proxies
> > > A: We don't - clarified proxy definition in 3.2
> > > Q: Why a hop count rather than a VIA header?
> > > A: The rationale is in the mailing list archive for March;
> > we haven't
> > > put this in the document in the interest of brevity.
> > (However, there is
> > > improved text on loop handling, see change number 8)
> > > Q: The D-mode messages have to follow the data flow
> > > A: Yes, existing text on the subject has been gathered
> > (from the rest of
> > > the document) into section 5.3
> > > Q: Does having GIMPS do NAT traversal hijack signaling
> > application role?
> > > A: This is still open for discussion. The text in section
> > 6.3 is clear
> > > on this. It needs discussion with the NATFW people (i.e. it
> > is not just
> > > a GIMPS issue); at the moment, the NATFW NSLP regards handling NAT
> > > traversal aspects of non-NATFW NSLPs as out of scope, so
> > the boundary is
> > > consistent
> > > Q: Tunneling nit
> > > A: Text in 6.4 adjusted accordingly
> > > Q: Does 8.2 really rule out raw-IP?
> > > A: The text in 8.2 on the subject has been expanded to say why.
> > > Q: Aggregation is per-interface, not per-node
> > > A: Text in 8.4 on aggregation handling adjusted accordingly
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > nsis at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis at ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>
> --
>
> Visit our website at www.roke.co.uk
>
> Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
>
> The information contained in this e-mail and any attachments is confidential to
> Roke Manor Research Ltd and must not be passed to any third party without
> permission. This communication is for information only and shall not create or
> change any contractual relationship.
-----
Takako SANDA <sanda.takako at jp.panasonic.com>
Next-Generation Mobile Communications Development Center,
Matsushita Electric Industrial Co., Ltd. (Panasonic)
Phone: +81 46 840 5764 Fax: +81 46 840 5122
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis