Vijay,
> [EMAIL PROTECTED] wrote:
> > Hi Brian,
> >
> > Thanks for the review! I have included answers & comments to your
> > comments below:
> >
> >> 3. Service Selection Mobility Option
> >>
> >> The Service Selection mobility option MAY be included in
> any Binding
> >> Update message. It SHOULD be included at least in the Binding
> > Update
> >> message that is sent for the initial binding
> registration when the
> >> mobile node and the home agent do not have an existing
> binding. If
> >> the Binding Update message includes any authorization related
> > options
> >> (such as the Binding Authorization Data option [1]) or
> > authentication
> >> related options (such as the Mobility Message
> Authentication option
> >> [8]), then the Service Selection option MUST appear before any
> >> mobility message authorization or authentication related options.
> >>
> >> (1) I don't understand the SHOULD. Surely the default case (we just
> > want
> >> basic Internet access) doesn't need this option?
> >
> > The default case does not need to include the option. In that case
> > whatever the HA understands as a default behavior &
> connectivity gets
> > applied.
> > What
> > about rephrasing:
> >
> > The Service Selection mobility option MAY be included in
> any Binding
> > Update message. If the Binding Update message includes any
> > authorization related options (such as the Binding
> Authorization Data
> > option [1]) or authentication related options (such as
> the Mobility
> > Message Authentication option [8]), then the Service
> Selection option
> > when present MUST appear before any mobility message
> authorization or
> > authentication related options.
>
> This is ok, but we still need some text that says, if the
> service selection mobility option is used, it needs to appear
> only in the initial BU and not required in the BUs sent to
> refresh a binding.
IMO Section 4.1 mobile node considerations state this
pretty clearly. Is that enough to be there or should it
also be under the option format description?
> >> (2) The final MUST could be read in two ways. Does it need
> clarifying
> > thus:
> >> [8]), then the Service Selection option _when present_
> MUST appear
> > before any
> >> mobility message authorization or authentication related options.
> >
> > Yes. See above.
> >
> >> ...
> >> o Identifier: A variable length UTF-8 [3] encoded service
> > identifier
> >> string used to identify the requested service.
> >>
> >> 'ims', 'voip' and 'voip.companyxyz.example.com' are valid
> > examples
> >> of Service Selection option Identifiers. At minimum the
> >> Identifier MUST be unique among the home agents the
> mobile node
> > is
> >> authorized to register to.
> >>
> >> (3) Does this mean that a mobile node can request exactly
> one service?
> > Or
> >> is it possible to send more than one Service Selection mobility
> >> option with different identifiers, in order to request access to
> >> several services? If it's restricted to one service, why?
> >
> > The intention is that only one dedicated service per mobile
> ip tunnel
> > is allowed. This is because the selected service may affect the
> > allocation of the home address & home network prefix and thus the
> > routing in the HA. For each mobile ip tunnel we can assign only one
> > address / prefix.
> >
> > If we were only after different QoS treatment or filtering
> of packets
> > then multiple options could probably be allowed.
> >
> > The draft should say something about the number of service
> selection
> > options in the binding update. I would go for maximum one. At least
> > that was my original idea.
>
> Do we have to say "one"? For example, it might be possible to
> provide two different services on the same Mobile IP tunnel.
> We could leave this up to folks who might use this option.
Do you mean that we would allow zero or more services in a (P)BU
and then how the HA processes that is up to deployment?
Cheers,
Jouni
>
> Vijay
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
