A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain
draft-ietf-ieprep-domain-frame-08

[Ballot discuss]
A re-review confirms that most issues have been resolved,
thank you!

However,  in Section 3 change the explanation about
mobility a little bit. First of all, the text
promises further discussion in Sect 4 but such discussion
was removed as a part of the earlier revision.
Secondly, I do not think we should claim that
mobility is not available in most domains;
some forms of mobility are not dependent on
local domain assistance. But it is true that
not all home domains or client devices are
configured or even equipped to handle
mobility.

Also, need to take Henrik Levkowetz's
review into account. He complained
about triangle, beaconing, etc.

With this in mind, I would
suggest the following change:

OLD:
  A more ambitious way of supporting the mobile user is through the use
  of the Mobile IP (MIP) protocol.  In this case and at the IP level,
  foreign networks introduce the concept of triangle routing and the
  potential for multiple access points and service context within a
  subnetwork.  In addition, policy plays a critical role in dictating
  the measure of available services to the mobile user.

  The beaconing capability of MIP allows it to offer a measure of
  application transparent mobility as a mobile host (MH) moves from one
  subnetwork to another.

  However, this feature may not be available in
  most domains.  In addition, its management requirements may
  discourage its widespread deployment and use.  Hence, users should
  probably not rely on its existence, but rather may want to expect a
  more simpler approach based on DHCP as described above.  The subject
  of mobile IP is discussed below in Section 4.
NEW:
  A more ambitious way of supporting the mobile user is through
  the use of the Mobile IP (MIP) protocol. MIP offers a measure of
  application transparent mobility as a mobile host moves
  from one subnetwork to another while keeping the same stable
  IP address registered at a global anchor point. However, this
  feature may not always be available or in use. In any case,
  where it is in use, at least some of the packets destined to
  and from the mobile host go through the home network.

[Ballot discuss]
A re-review confirms that most issues have been resolved,
thank you!

However,

In Section 3 change the explanation about
mobility a little bit. First of all, the text
promises further discussion but such discussion
was removed as a part of the earlier revision.
Secondly, I do not think we should claim that
mobility is not available in most domains;
some forms of mobility, Mobile IPv6 and
MOBIKE in particular, are not dependent on
local domain assistance. But it is true that
not all home domains or client devices are
configured or even equipped to handle
mobility.

Also, need to take Henrik Levkowetz's
review into account. He complained
about triangle, beaconing, etc.

With this in mind, I would
suggest the following change:

OLD:
  A more ambitious way of supporting the mobile user is through the use
  of the Mobile IP (MIP) protocol.  In this case and at the IP level,
  foreign networks introduce the concept of triangle routing and the
  potential for multiple access points and service context within a
  subnetwork.  In addition, policy plays a critical role in dictating
  the measure of available services to the mobile user.

  The beaconing capability of MIP allows it to offer a measure of
  application transparent mobility as a mobile host (MH) moves from one
  subnetwork to another.

  However, this feature may not be available in
  most domains.  In addition, its management requirements may
  discourage its widespread deployment and use.  Hence, users should
  probably not rely on its existence, but rather may want to expect a
  more simpler approach based on DHCP as described above.  The subject
  of mobile IP is discussed below in Section 4.
NEW:
  A more ambitious way of supporting the mobile user is through the use
  of the Mobile IP (MIP) protocol. MIP offers a measure of
  application transparent mobility as a mobile host (MH) moves
  from one subnetwork to another while keeping the same stable
  IP address registered at a global anchor point. However, this
  feature may not always be available or in use.

[Ballot comment]
This text was the original text of my DISCUSS.  I have moved to abstain after seeing a draft of the -07.txt.

In Section 4.6, the document says:

Anycasting [rfc1546] is another means of discovering nodes that sup-
  port a given service.  Interdomain anycast addresses, propagated by
  BGP, have been used by multiple root servers for a while.  [rfc3513]
  covers the topic of anycast addresses for IPv6.  Unlike SLP,
  users/applications must know the anycast address associated with the
  target service.  In addition, responses to multiple requests to the
  anycast address may come from different servers.  Hence, applicabil-
  ity of anycast may be narrow in scope.  Detailed tradeoffs between
  this approach and SLP is outside the scope of this framework docu-
  ment.

This isn't really discovery.  As the paragraph says, the client must start out
knowing the address it wants to reach; anycast uses the routing system to
deliver the packets from the client to a topologically close instance of the
server. 

On a broader note, I think it might be helpful to break the discovery section into at least two
subsections.  One might be on discovery in the SLP sense (and I would include
DDDS as a second possible mechanism for discovering services); the other would
be on redundancy.  DNS-based mechanisms provide easy mechanisms for
redundancy (multiple records which can be tried in turn); anycast can also allow
for multiple servers to be present, in different parts of the network topology.

The mobility section should probably reference RFC 3775, and it might want to
clarify whether the client should understand that it is using Mobile IP when using
ETS, or whether it can treat it itself as using the IP layer without regard to mobility.

[Ballot discuss]
Holding a discuss based on MDIR reviews by myself, Henrik Levkowetz, and Thomas Narten. For the actual reviews see the earlier data entered by Margaret Wasserman.

[Ballot comment]
I think that Jari Arkko's review (see discuss) captures the main issues with this document, but I received two other Mobility Directorate reviews that I think that the authors should consider in their update -- one form Henrik Levkowetz (henrik@levkowetz.com) and one form Thomas Narten (narten@us.ibm.com).  Please cc: the Mobility Directorate (mdir@machshav.com) on discussions of these reviews.  Thanks!

---

Henrik's Review:

The document seems to be a reasonable overview of transport issues relevant to ETS, but unfortunately the rather grave deficiencies I see in the parts I'm most familiar with makes me wonder how accurate the document is with respect to other technologies...

Regarding the mobility parts, the material (both regarding MIP and NEMO) seems to be woefully out of date.  Some examples are given below.  In particular, the author seems to assume that MIPv4 is normally deployed with Foreign Agents, while the practice is to almost exclusively use Co-located Care-Of Address operation, which today, with NAT traversal for MIPv4 in place for quite some time, makes MIPv4 work just about everywhere.

Henrik

Section 3.1., para. 5:

>    A more ambitious way of supporting the mobile user is through the use
>    of the Mobile IP (MIP) protocol.  In this case and at the IP level,
>    foreign networks introduce the concept of triangle routing and the
>    potential for multiple access points and service context within a
>    subnetwork.  In addition, policy plays a critical role in dictating
>    the measure of available services to the mobile user.

s/triangle/triangular/  (Established technical MIP term)
I don't understand what is meant by service context above
but you probably should have
s/service context/service contexts/

Section 3.1., para. 6:

>    The beaconing capability of MIP allows it to offer a measure of
>    application transparent mobility as a mobile host (MH) moves from one
>    subnetwork to another.  However, this feature may not be available in
>    most domains.  In addition, its management requirements may
>    discourage its widespread deployment and use.  Hence, users should
>    probably not rely on its existence, but rather may want to expect a
>    more simpler approach based on DHCP as described above.  The subject
>    of mobile IP is discussed below in Section 4.

I have no idea what is meant by 'The beaconing capability of MIP'.
There is no feature that goes by that name.
This paragraph gives me the impression that the author doesn't know
too much about MIP, or has knowledge which is severely outdated.
MIPv4 is reliably deployed and deployable today, and the advice above
does not seem like good advice...

Section 4.7.2., para. 2:

>    The Network Mobile (NEMO) working group has just recently been formed
>    to address the issues that arise when entire networks move in rela-
>    tion to each other.  A baseline protocol that specifies extensions to
>    IPv6 mobility support has been defined in [rfc3963], but much work
>    still needs to be done.  And so we consider the NEMO effort at the
>    time of this writing to be considered too immature for supporting
>    ETS.

NEMO has by now completed its first and basic set of work items, and
is in the process of re-chartering to look at refinements and
optimization.  The above paragraph seems to be outdated advice.



Some nits I noticed:

Section 1., para. 1:

>    This document presents a framework for supporting Emergency Telecom-
>    munications Services (ETS) within the scope of a single administra-
>    tive domain.  This narrow scope provides a reference point for con-
>    sidering protocols that could be deployed to support ETS.  [REQ] is a
>    complimentary effort that articulates requirements for a single
>    administrative domain and defines is as "collection of resources
>    under the control of a single administrative authority".  We use this
>    other effort as both a starting point and guide for this document.

s/complimentary/complementary/
s/is as/it as/


Section 1.1., para. 2:

>    a) Congruent with physical topology of resources, each domain
>        is an authority zone and there is currently no scalable way
>        to transfer authority between zones.

I don't see the relevance of the authority zone being congruent with
the physical topology of resources.  If this is relevant, some
explanation might be in order.  If it's not relevant, you could start
the first sentence at "Each domain is ..."

>    b) Each authority zone is under separate management
>    c) Authority zones are run by competitors, which acts as
>        further deterrent to transferring authority.


Section 4.2., para. 2:

>    [rfc3209] is one example of how RSVP has evolved to compliment
>    efforts that are scoped to operate within a domain.  In this case,
>    extensions to RSVP are defined that allow it to establish intra-
>    domain Labeled Switched Paths (LSP) in Multi-Protocol Labeled Switch-
>    ing (MPLS).

s/compliment/complement/


Section 4.2., para. 3:

>    [rfc2750] specifies extensions to RSVP so that it can support generic
>    policy based admission control.  This standard goes beyond the sup-
>    port of the POLICY_DATA object stipulated in [rfc3209], by defining
>    the means of control and enforcement of access and usage policies.
>    While the standard does not advocate a particular policy architec-
>    ture, the IETF has defined one that can compliment [rfc2750] -- we

s/compliment/complement/
>    expand on this in subsection 4.3 below.


Section 4.3., para. 1:

>    The Common Open Policy Service (COPS) protocol [rfc2748] was defined
>    to provide policy control over QoS signaling protocols, such as RSVP.
>    COPS is based on a query/response model in which Policy Enforcement
>    Points (PEPs) interact with Policy Decision Points (i.e., policy
>    servers) to exchange policy information.  COPs provides application
>    level security and can operate over IPSEC or TLS.  COPS is also
>    stateful protocol that also supports a push model.  This means that
>    servers can download new policies, or alter existing ones to known
>    clients.

s/COPS is also/COPS is also a/
s/COPs/COPS/
s/IPSEC/IPsec/

Section 4.3., para. 3:

>    A complimentary document to the COPS protocols is [rfc3084], which
>    describes the use of COPS for policy provisioning.

s/complimentary/complementary/


Section 4.5.1., para. 1:

>    The value of IP multicast is its efficient use of resources in send-
>    ing the same datagram to multiple receivers.  An extensive discussion
>    on the strengths and concerns about multicast is outside the scope of
>    this document.  However, one can argue that multicast can very natur-
>    ally compliment the push-to-talk feature of land mobile radio net-
>    works (LMR).

s/compliment/complement/


Section 4.7.1., para. 2:

>    The Mobile IP protocol (MIP) and architecture addresses the fundamen-
>    tal characteristics of a ETS user migrating to a foreign network and
>    attempting to contact other users.  One can also make an argument
>    that the perceived needs of an ETS user, e.g., labeling traffic to
>    distinguish it from other flows can also be achieved independent of
>    the MIP.  A potential exception to this position is the "busy" bit
>    that can be set during the initial registration of the Mobile Host
>    (MH) to the Foreign Network.  If the bit is tied to a maximum number
>    of simultaneous number of MHs, then it may be of interest to specify
>    an extension that distinguishes an ETS capable MH from other MHs.
>    Local policy would determine the course of action to be taken.

MIP has no traffic labelling properties - any QoS handling or resource
reservation which is needed has to be arranged independently of MIP,
for each attachment to a network.  MIP simply provides a stable IP
address, with the QoS characteristics that can be provided by the
underlying access network.  I think this paragraph may need some
re-writing.


Section 6., para. 1:

>    This document has presented a number of protocols and complimentary
>    technologies that can be used to support ETS users.  Their selection
>    is dictated by the fact that all or significant portions of the pro-
>    tocols can be operated and controlled within a single administrative
>    domain.  It is this reason why other protocols like those under
>    current development in the Next Steps in Signaling (NSIS) working
>    group have not be discussed.

s/complimentary/complementary/

---
Thomas' Review:

Here is my  take on the document:

General:

Document seems harmless, so no objection to seeing it go forward. I do wonder to what degree it is useful though.

I have a hard time seeing this document as a "framework". Mostly, it just talks about various IETF protocols and how they might relate to ETS. But the protocols discussed seem like a somewhat random selection of topics and I wouldn't say that the collection of protocols is any kind of "framework".

On the specific area of mobility, I'm not really sure what the point of the dicussions  are or what imporant points are being made.
As an example:

>    The Mobile IP protocol (MIP) and architecture addresses the fundamen-
>    tal characteristics of a ETS user migrating to a foreign network and
>    attempting to contact other users.  One can also make an argument
>    that the perceived needs of an ETS user, e.g., labeling traffic to
>    distinguish it from other flows can also be achieved independent of
>    the MIP.  A potential exception to this position is the "busy" bit

I really don't understand what this is trying to say..

>    The Network Mobile (NEMO) working group has just recently been formed
>    to address the issues that arise when entire networks move in rela-
>    tion to each other.  A baseline protocol that specifies extensions
> to

"just recently been formed"? That text suggests this section needs updating...

this section (about nemo) makes me wonder what the ieprep folk are doing w.r.t. bringing requirements to nemo. Are they engaging nemo at all? Should they?

nits:

>    administrative domain and defines is as "collection of resources

s/is/it/ ??

>    An arguement can be made that Diff-Serv, with its existing code
> point

s/arguement/argument/

>    (EF), goes beyond what could be needed to support ETS within a

s/could/would/ ?

[Ballot discuss]
I am holding a discuss based on the attached Mobility Directorate review from Jari Arkko (jari.arkko@piuha.net).  Please cc: the Mobility Directorate (mdir@machshav.com) on discussions of this review.  Also, see additional mdir reviews in the comments section.

Thanks,
Margaret

---

Overall:

Overall seems like a useful document, but probably needs another rev to get the scope well defined.

I am not very convinced that this document needs to talk about mobility protocols at all. The mobility handling within a domain or inter-domain appears to be largely independent of the main topic of the document, ensuring QoS for emergency traffic (at least this is what I believe the topic is). The treatment of mobility issues is rather shallow.

But at the same time, I believe the document is missing aspects that probably should be discussed. For instance, it claims to talk about the ability of foreign nodes to access the local network in an emergency situation. But such usage would have a number of roadblocks to solve, such as getting past network access authentication schemes.

Technical:

>  Case (b) above may sim-
>  ply be supported by the Dynamic Host Configuration Protocol (DHCP)
>  [rfc2131], or a static set of addresses, that are assigned to 'visi-
>  tors' of the network.  This effort is predominantly operational in
>  nature and heavily reliant on the management and security policies of
>  that network.
> 
>
Its not that simple. You need network access, but we (the IETF and vendors) keep on adding functions that may not make it very simple for foreign nodes to attach to the network. For instance, if you have L2 authentication, getting to the network is impossible unless you have roaming or have set aside some "guest" network that can also be used for emergencies.

>  A more ambitious way of supporting the mobile user is through the use
>  of the Mobile IP (MIP) protocol.  In this case and at the IP level,
>  foreign networks introduce the concept of triangle routing and the
>  potential for multiple access points and service context within a
>  subnetwork.  In addition, policy plays a critical role in dictating
>  the measure of available services to the mobile user.
> 
>
Only MIPv4 introduces triangle routing, and it doesn't even always do it.

>  The mobile user extends the scenario of how an ETS user operates
>  within a domain.  While the ownership of the mobile host may be dif-
>  ferent from other nodes in the same domain, the management of that
>  node in terms of policies and administration is still defined by the
>  foreign network (i.e., domain) that it is attached to.
> 
>
I am not sure I agree. The management of the node appears to be always under the owner/home domain, but certainly the local network enforces some policies on e.g. QoS allocations, ability to use MIP to begin with etc.

>  One can also make an argument
>  that the perceived needs of an ETS user, e.g., labeling traffic to
>  distinguish it from other flows can also be achieved independent of
>  the MIP.
>

What? Surely IP itself already "labels traffic to distinguish it from other flows"... and Mobile IP is not a QoS marking function, if you meant that... nor is it an emergency communication marking function either.

>4.7.2.  Other Areas of Mobility
>
Seems like a non-complete listing of IETF mobility work. What about MOBIKE, for instance? But then again, I am not completely sure why we need to talk about these things in the first place.

>4.7.3.  AAA
>
>  Authentication, Authorization, and Accounting (AAA) is an important
>  subject for mobility since users may access resources from other
>  domains outside of their own zone of authority.  [rfc2977] presents a
>  set of requirements for AAA and the MIP.  When we add the caveat of
>  the ETS user, we add an additional level of filtering specific sets
>  of users, which makes the problem of AAA more difficult to support.
>
>  In the case of NEMO, SEAMOBY, AAA remains an open issue to be solved.
>  There are some deployed MANET protocols that have rudimentary AAA
>  support, but the support is unique to that implementation and not
>  based on an IETF standard -- which is reasonable since current MANET
>  protocols are experimental.
> 
>
This does not even begin addressing the issues that in my opinion would be relevant for the problem at hand. We need AAA for a number of purposes, including mobility but also simply network access, SIP infrastructure access, etc. The document claims to support case b (visiting a foreign network) and with or without mobility, they need access to the network itself. How do we achieve that -- say in the case of an emergency communication that originates from a user that is NOT a subscriber of this network?

Editorial:

>  An arguement can be made that Diff-Serv, with its existing code
> point
>
s/arguement/argument/

> may involve QoS, traffic engineering, or simply portection against

s/portection/protection/

>      (e.g. Access Control Lists) into each and every edge device
>
I thought that you have to put "," after "e.g.", but I could be mistaken.

>  [rfc3270] is a Request For Comment (RFC) describing how MPLS can be
>
No need to open up this term in an RFC...

>  proto- cols.
>
Hyphenation gone wrong...

>  and its support based on the Mobile IP protocol [rfc3344].  In this

One would perhaps expect both IPv4 and IPv6 be referenced/talked about in this document. There might even be functional differences wrt this problem area. (E.g. the busy bit that is talked about somewhere else in the document.)

>the MIP.
>
s/the MIP/MIP/

[Ballot discuss]
I am holding a discuss based on the attached Mobility Directorate review from Jari Arkko (jari.arkko@piuha.net).  Please cc: the Mobility Directorate (mdir@machshav.com) on discussions of this review.

Thanks,
Margaret

---

Overall:

Overall seems like a useful document, but probably needs another rev to get the scope well defined.

I am not very convinced that this document needs to talk about mobility protocols at all. The mobility handling within a domain or inter-domain appears to be largely independent of the main topic of the document, ensuring QoS for emergency traffic (at least this is what I believe the topic is). The treatment of mobility issues is rather shallow.

But at the same time, I believe the document is missing aspects that probably should be discussed. For instance, it claims to talk about the ability of foreign nodes to access the local network in an emergency situation. But such usage would have a number of roadblocks to solve, such as getting past network access authentication schemes.

Technical:

>  Case (b) above may sim-
>  ply be supported by the Dynamic Host Configuration Protocol (DHCP)
>  [rfc2131], or a static set of addresses, that are assigned to 'visi-
>  tors' of the network.  This effort is predominantly operational in
>  nature and heavily reliant on the management and security policies of
>  that network.
> 
>
Its not that simple. You need network access, but we (the IETF and vendors) keep on adding functions that may not make it very simple for foreign nodes to attach to the network. For instance, if you have L2 authentication, getting to the network is impossible unless you have roaming or have set aside some "guest" network that can also be used for emergencies.

>  A more ambitious way of supporting the mobile user is through the use
>  of the Mobile IP (MIP) protocol.  In this case and at the IP level,
>  foreign networks introduce the concept of triangle routing and the
>  potential for multiple access points and service context within a
>  subnetwork.  In addition, policy plays a critical role in dictating
>  the measure of available services to the mobile user.
> 
>
Only MIPv4 introduces triangle routing, and it doesn't even always do it.

>  The mobile user extends the scenario of how an ETS user operates
>  within a domain.  While the ownership of the mobile host may be dif-
>  ferent from other nodes in the same domain, the management of that
>  node in terms of policies and administration is still defined by the
>  foreign network (i.e., domain) that it is attached to.
> 
>
I am not sure I agree. The management of the node appears to be always under the owner/home domain, but certainly the local network enforces some policies on e.g. QoS allocations, ability to use MIP to begin with etc.

>  One can also make an argument
>  that the perceived needs of an ETS user, e.g., labeling traffic to
>  distinguish it from other flows can also be achieved independent of
>  the MIP.
>

What? Surely IP itself already "labels traffic to distinguish it from other flows"... and Mobile IP is not a QoS marking function, if you meant that... nor is it an emergency communication marking function either.

>4.7.2.  Other Areas of Mobility
>
Seems like a non-complete listing of IETF mobility work. What about MOBIKE, for instance? But then again, I am not completely sure why we need to talk about these things in the first place.

>4.7.3.  AAA
>
>  Authentication, Authorization, and Accounting (AAA) is an important
>  subject for mobility since users may access resources from other
>  domains outside of their own zone of authority.  [rfc2977] presents a
>  set of requirements for AAA and the MIP.  When we add the caveat of
>  the ETS user, we add an additional level of filtering specific sets
>  of users, which makes the problem of AAA more difficult to support.
>
>  In the case of NEMO, SEAMOBY, AAA remains an open issue to be solved.
>  There are some deployed MANET protocols that have rudimentary AAA
>  support, but the support is unique to that implementation and not
>  based on an IETF standard -- which is reasonable since current MANET
>  protocols are experimental.
> 
>
This does not even begin addressing the issues that in my opinion would be relevant for the problem at hand. We need AAA for a number of purposes, including mobility but also simply network access, SIP infrastructure access, etc. The document claims to support case b (visiting a foreign network) and with or without mobility, they need access to the network itself. How do we achieve that -- say in the case of an emergency communication that originates from a user that is NOT a subscriber of this network?

Editorial:

>  An arguement can be made that Diff-Serv, with its existing code
> point
>
s/arguement/argument/

> may involve QoS, traffic engineering, or simply portection against

s/portection/protection/

>      (e.g. Access Control Lists) into each and every edge device
>
I thought that you have to put "," after "e.g.", but I could be mistaken.

>  [rfc3270] is a Request For Comment (RFC) describing how MPLS can be
>
No need to open up this term in an RFC...

>  proto- cols.
>
Hyphenation gone wrong...

>  and its support based on the Mobile IP protocol [rfc3344].  In this

One would perhaps expect both IPv4 and IPv6 be referenced/talked about in this document. There might even be functional differences wrt this problem area. (E.g. the busy bit that is talked about somewhere else in the document.)

>the MIP.
>
s/the MIP/MIP/

[Ballot comment]
I think that Jari Arkko's review (see discuss) captures the main issues with this document, but I received two other Mobility Directorate reviews that I think that the authors should consider in their update -- one form Henrik Levkowetz (henrik@levkowetz.com) and one form Thomas Narten (narten@us.ibm.com).  Please cc: the Mobility Directorate (mdir@machshav.com) on discussions of these reviews.  Thanks!

---

Henrik's Review:

The document seems to be a reasonable overview of transport issues relevant to ETS, but unfortunately the rather grave deficiencies I see in the parts I'm most familiar with makes me wonder how accurate the document is with respect to other technologies...

Regarding the mobility parts, the material (both regarding MIP and NEMO) seems to be woefully out of date.  Some examples are given below.  In particular, the author seems to assume that MIPv4 is normally deployed with Foreign Agents, while the practice is to almost exclusively use Co-located Care-Of Address operation, which today, with NAT traversal for MIPv4 in place for quite some time, makes MIPv4 work just about everywhere.

Henrik

Section 3.1., para. 5:

>    A more ambitious way of supporting the mobile user is through the use
>    of the Mobile IP (MIP) protocol.  In this case and at the IP level,
>    foreign networks introduce the concept of triangle routing and the
>    potential for multiple access points and service context within a
>    subnetwork.  In addition, policy plays a critical role in dictating
>    the measure of available services to the mobile user.

s/triangle/triangular/  (Established technical MIP term)
I don't understand what is meant by service context above
but you probably should have
s/service context/service contexts/

Section 3.1., para. 6:

>    The beaconing capability of MIP allows it to offer a measure of
>    application transparent mobility as a mobile host (MH) moves from one
>    subnetwork to another.  However, this feature may not be available in
>    most domains.  In addition, its management requirements may
>    discourage its widespread deployment and use.  Hence, users should
>    probably not rely on its existence, but rather may want to expect a
>    more simpler approach based on DHCP as described above.  The subject
>    of mobile IP is discussed below in Section 4.

I have no idea what is meant by 'The beaconing capability of MIP'.
There is no feature that goes by that name.
This paragraph gives me the impression that the author doesn't know
too much about MIP, or has knowledge which is severely outdated.
MIPv4 is reliably deployed and deployable today, and the advice above
does not seem like good advice...

Section 4.7.2., para. 2:

>    The Network Mobile (NEMO) working group has just recently been formed
>    to address the issues that arise when entire networks move in rela-
>    tion to each other.  A baseline protocol that specifies extensions to
>    IPv6 mobility support has been defined in [rfc3963], but much work
>    still needs to be done.  And so we consider the NEMO effort at the
>    time of this writing to be considered too immature for supporting
>    ETS.

NEMO has by now completed its first and basic set of work items, and
is in the process of re-chartering to look at refinements and
optimization.  The above paragraph seems to be outdated advice.



Some nits I noticed:

Section 1., para. 1:

>    This document presents a framework for supporting Emergency Telecom-
>    munications Services (ETS) within the scope of a single administra-
>    tive domain.  This narrow scope provides a reference point for con-
>    sidering protocols that could be deployed to support ETS.  [REQ] is a
>    complimentary effort that articulates requirements for a single
>    administrative domain and defines is as "collection of resources
>    under the control of a single administrative authority".  We use this
>    other effort as both a starting point and guide for this document.

s/complimentary/complementary/
s/is as/it as/


Section 1.1., para. 2:

>    a) Congruent with physical topology of resources, each domain
>        is an authority zone and there is currently no scalable way
>        to transfer authority between zones.

I don't see the relevance of the authority zone being congruent with
the physical topology of resources.  If this is relevant, some
explanation might be in order.  If it's not relevant, you could start
the first sentence at "Each domain is ..."

>    b) Each authority zone is under separate management
>    c) Authority zones are run by competitors, which acts as
>        further deterrent to transferring authority.


Section 4.2., para. 2:

>    [rfc3209] is one example of how RSVP has evolved to compliment
>    efforts that are scoped to operate within a domain.  In this case,
>    extensions to RSVP are defined that allow it to establish intra-
>    domain Labeled Switched Paths (LSP) in Multi-Protocol Labeled Switch-
>    ing (MPLS).

s/compliment/complement/


Section 4.2., para. 3:

>    [rfc2750] specifies extensions to RSVP so that it can support generic
>    policy based admission control.  This standard goes beyond the sup-
>    port of the POLICY_DATA object stipulated in [rfc3209], by defining
>    the means of control and enforcement of access and usage policies.
>    While the standard does not advocate a particular policy architec-
>    ture, the IETF has defined one that can compliment [rfc2750] -- we

s/compliment/complement/
>    expand on this in subsection 4.3 below.


Section 4.3., para. 1:

>    The Common Open Policy Service (COPS) protocol [rfc2748] was defined
>    to provide policy control over QoS signaling protocols, such as RSVP.
>    COPS is based on a query/response model in which Policy Enforcement
>    Points (PEPs) interact with Policy Decision Points (i.e., policy
>    servers) to exchange policy information.  COPs provides application
>    level security and can operate over IPSEC or TLS.  COPS is also
>    stateful protocol that also supports a push model.  This means that
>    servers can download new policies, or alter existing ones to known
>    clients.

s/COPS is also/COPS is also a/
s/COPs/COPS/
s/IPSEC/IPsec/

Section 4.3., para. 3:

>    A complimentary document to the COPS protocols is [rfc3084], which
>    describes the use of COPS for policy provisioning.

s/complimentary/complementary/


Section 4.5.1., para. 1:

>    The value of IP multicast is its efficient use of resources in send-
>    ing the same datagram to multiple receivers.  An extensive discussion
>    on the strengths and concerns about multicast is outside the scope of
>    this document.  However, one can argue that multicast can very natur-
>    ally compliment the push-to-talk feature of land mobile radio net-
>    works (LMR).

s/compliment/complement/


Section 4.7.1., para. 2:

>    The Mobile IP protocol (MIP) and architecture addresses the fundamen-
>    tal characteristics of a ETS user migrating to a foreign network and
>    attempting to contact other users.  One can also make an argument
>    that the perceived needs of an ETS user, e.g., labeling traffic to
>    distinguish it from other flows can also be achieved independent of
>    the MIP.  A potential exception to this position is the "busy" bit
>    that can be set during the initial registration of the Mobile Host
>    (MH) to the Foreign Network.  If the bit is tied to a maximum number
>    of simultaneous number of MHs, then it may be of interest to specify
>    an extension that distinguishes an ETS capable MH from other MHs.
>    Local policy would determine the course of action to be taken.

MIP has no traffic labelling properties - any QoS handling or resource
reservation which is needed has to be arranged independently of MIP,
for each attachment to a network.  MIP simply provides a stable IP
address, with the QoS characteristics that can be provided by the
underlying access network.  I think this paragraph may need some
re-writing.


Section 6., para. 1:

>    This document has presented a number of protocols and complimentary
>    technologies that can be used to support ETS users.  Their selection
>    is dictated by the fact that all or significant portions of the pro-
>    tocols can be operated and controlled within a single administrative
>    domain.  It is this reason why other protocols like those under
>    current development in the Next Steps in Signaling (NSIS) working
>    group have not be discussed.

s/complimentary/complementary/

---
Thomas' Review:

Here is my  take on the document:

General:

Document seems harmless, so no objection to seeing it go forward. I do wonder to what degree it is useful though.

I have a hard time seeing this document as a "framework". Mostly, it just talks about various IETF protocols and how they might relate to ETS. But the protocols discussed seem like a somewhat random selection of topics and I wouldn't say that the collection of protocols is any kind of "framework".

On the specific area of mobility, I'm not really sure what the point of the dicussions  are or what imporant points are being made.
As an example:

>    The Mobile IP protocol (MIP) and architecture addresses the fundamen-
>    tal characteristics of a ETS user migrating to a foreign network and
>    attempting to contact other users.  One can also make an argument
>    that the perceived needs of an ETS user, e.g., labeling traffic to
>    distinguish it from other flows can also be achieved independent of
>    the MIP.  A potential exception to this position is the "busy" bit

I really don't understand what this is trying to say..

>    The Network Mobile (NEMO) working group has just recently been formed
>    to address the issues that arise when entire networks move in rela-
>    tion to each other.  A baseline protocol that specifies extensions
> to

"just recently been formed"? That text suggests this section needs updating...

this section (about nemo) makes me wonder what the ieprep folk are doing w.r.t. bringing requirements to nemo. Are they engaging nemo at all? Should they?

nits:

>    administrative domain and defines is as "collection of resources

s/is/it/ ??

>    An arguement can be made that Diff-Serv, with its existing code
> point

s/arguement/argument/

>    (EF), goes beyond what could be needed to support ETS within a

s/could/would/ ?

[Ballot discuss]
I am holding a discuss based on the attached Mobility Directorate review from Jari Arkko (jari.arkko@piuha.net).  Please cc: Jari or the Mobility Directorate (mdir@machshav.com) on discussions of this review.

Thanks,
Margaret

---

Overall:

Overall seems like a useful document, but probably needs another rev to get the scope well defined.

I am not very convinced that this document needs to talk about mobility protocols at all. The mobility handling within a domain or inter-domain appears to be largely independent of the main topic of the document, ensuring QoS for emergency traffic (at least this is what I believe the topic is). The treatment of mobility issues is rather shallow.

But at the same time, I believe the document is missing aspects that probably should be discussed. For instance, it claims to talk about the ability of foreign nodes to access the local network in an emergency situation. But such usage would have a number of roadblocks to solve, such as getting past network access authentication schemes.

Technical:

>  Case (b) above may sim-
>  ply be supported by the Dynamic Host Configuration Protocol (DHCP)
>  [rfc2131], or a static set of addresses, that are assigned to 'visi-
>  tors' of the network.  This effort is predominantly operational in
>  nature and heavily reliant on the management and security policies of
>  that network.
> 
>
Its not that simple. You need network access, but we (the IETF and vendors) keep on adding functions that may not make it very simple for foreign nodes to attach to the network. For instance, if you have L2 authentication, getting to the network is impossible unless you have roaming or have set aside some "guest" network that can also be used for emergencies.

>  A more ambitious way of supporting the mobile user is through the use
>  of the Mobile IP (MIP) protocol.  In this case and at the IP level,
>  foreign networks introduce the concept of triangle routing and the
>  potential for multiple access points and service context within a
>  subnetwork.  In addition, policy plays a critical role in dictating
>  the measure of available services to the mobile user.
> 
>
Only MIPv4 introduces triangle routing, and it doesn't even always do it.

>  The mobile user extends the scenario of how an ETS user operates
>  within a domain.  While the ownership of the mobile host may be dif-
>  ferent from other nodes in the same domain, the management of that
>  node in terms of policies and administration is still defined by the
>  foreign network (i.e., domain) that it is attached to.
> 
>
I am not sure I agree. The management of the node appears to be always under the owner/home domain, but certainly the local network enforces some policies on e.g. QoS allocations, ability to use MIP to begin with etc.

>  One can also make an argument
>  that the perceived needs of an ETS user, e.g., labeling traffic to
>  distinguish it from other flows can also be achieved independent of
>  the MIP.
>

What? Surely IP itself already "labels traffic to distinguish it from other flows"... and Mobile IP is not a QoS marking function, if you meant that... nor is it an emergency communication marking function either.

>4.7.2.  Other Areas of Mobility
>
Seems like a non-complete listing of IETF mobility work. What about MOBIKE, for instance? But then again, I am not completely sure why we need to talk about these things in the first place.

>4.7.3.  AAA
>
>  Authentication, Authorization, and Accounting (AAA) is an important
>  subject for mobility since users may access resources from other
>  domains outside of their own zone of authority.  [rfc2977] presents a
>  set of requirements for AAA and the MIP.  When we add the caveat of
>  the ETS user, we add an additional level of filtering specific sets
>  of users, which makes the problem of AAA more difficult to support.
>
>  In the case of NEMO, SEAMOBY, AAA remains an open issue to be solved.
>  There are some deployed MANET protocols that have rudimentary AAA
>  support, but the support is unique to that implementation and not
>  based on an IETF standard -- which is reasonable since current MANET
>  protocols are experimental.
> 
>
This does not even begin addressing the issues that in my opinion would be relevant for the problem at hand. We need AAA for a number of purposes, including mobility but also simply network access, SIP infrastructure access, etc. The document claims to support case b (visiting a foreign network) and with or without mobility, they need access to the network itself. How do we achieve that -- say in the case of an emergency communication that originates from a user that is NOT a subscriber of this network?

Editorial:

>  An arguement can be made that Diff-Serv, with its existing code
> point
>
s/arguement/argument/

> may involve QoS, traffic engineering, or simply portection against

s/portection/protection/

>      (e.g. Access Control Lists) into each and every edge device
>
I thought that you have to put "," after "e.g.", but I could be mistaken.

>  [rfc3270] is a Request For Comment (RFC) describing how MPLS can be
>
No need to open up this term in an RFC...

>  proto- cols.
>
Hyphenation gone wrong...

>  and its support based on the Mobile IP protocol [rfc3344].  In this

One would perhaps expect both IPv4 and IPv6 be referenced/talked about in this document. There might even be functional differences wrt this problem area. (E.g. the busy bit that is talked about somewhere else in the document.)

>the MIP.
>
s/the MIP/MIP/

[Ballot discuss]
On page 8, it states:
  A complimentary document to the COPS protocols is [rfc3084], which
  describes the use of COPS for policy provisioning.

  As a side note, the current lack in deployment by network administra-
  tors of RSVP has also played at least an indirect role in the subse-
  quent lack of implementation & deployment of COPS.  [rfc3535] is an
  output from the IAB Network Management Workshop in which the topic of
  COPS and its current state of deployment was discussed.  At the time
  of that workshop in 2002, COPS was considered a
  technology/architecture that did not fully meet the needs of network
  operators.  It should also be noted that at the 60'th IETF meeting
  held in San Diego in 2004, COPS was discussed as a candidate protocol
  that should be declared as historic because of its lack of use and
  concerns about its design.  In the future, an altered design of COPS
  may emerge that addresses the concern of operators, but speculation
  of that or other possibilities is beyond the scope of this document.

I think this whole piece of text refers to COPS-PR as opposed to COPS.
I think it is best to fix that to reduce possible confusion for the
readers of this document.

[Ballot comment]
Please turn off hyphenation.

  Section 1.1: s/following"/following:/

  Please change the section heading doe section 4.4.1, 4.4.2, and 4.5.2:
    Section 4.4.1: s/802.1/IEEE 802.1 VLANs/
    Section 4.4.2: s/802.11e/IEEE 802.11e QoS/
    Section 4.5.2: s/802.1d/IEEE 802.1D MAC Bridges/

[Ballot comment]
Please turn off hyphenation.

  Section 1.1: s/following"/following:/

  Please change the section heading doe section 4.4.1, 4.4.2, and 4.5.2:
    Section 4.4.1: s/802.1/IEEE 802.1 VLANs/
    Section 4.4.2: s/802.11e/IEEE 802.11e QoS/
    Section 4.5.2: s/802.1d/IEEE 802.1d MAC Bridges/

[Ballot discuss]
Can Section 5 include a discussion of authorization?  Section 1.1
  includes a list of differences between Single and Inter-domain cases.
  Item g) in the list refers to authorization.  How does an authority
  determine authorization?  Are there any observations that are not
  unique to a specific domain?

[Ballot discuss]
In Section 4.6, the document says:

Anycasting [rfc1546] is another means of discovering nodes that sup-
  port a given service.  Interdomain anycast addresses, propagated by
  BGP, have been used by multiple root servers for a while.  [rfc3513]
  covers the topic of anycast addresses for IPv6.  Unlike SLP,
  users/applications must know the anycast address associated with the
  target service.  In addition, responses to multiple requests to the
  anycast address may come from different servers.  Hence, applicabil-
  ity of anycast may be narrow in scope.  Detailed tradeoffs between
  this approach and SLP is outside the scope of this framework docu-
  ment.

This isn't really discovery.  As the paragraph says, the client must start out
knowing the address it wants to reach; anycast uses the routing system to
deliver the packets from the client to a topologically close instance of the
server. 

On a broader note, I think it might be helpful to break the discovery section into at least two
subsections.  One might be on discovery in the SLP sense (and I would include
DDDS as a second possible mechanism for discovering services); the other would
be on redundancy.  DNS-based mechanisms provide easy mechanisms for
redundancy (multiple records which can be tried in turn); anycast can also allow
for multiple servers to be present, in different parts of the network topology.

The mobility section should probably reference RFC 3775, and it might want to
clarify whether the client should understand that it is using Mobile IP when using
ETS, or whether it can treat it itself as using the IP layer without regard to mobility.

[Ballot comment]
From MIB doctor Dan Romascanu:

I believe that Section 4.4.2  in this document includes a typo:

  Previously, 802.11 had two modes of operation.  One was Distributed
  Coordination Function (DCF) , which is based on the classic collision
  detection schema of "listen before sending".  A second optional mode
  is the Point Coordination Function (DCF).  The modes splits access
  time into contention-free and contention-active periods -- transmit-
  ting data during the former.

The second acronym should be PCF rather than DCF.

Another one. Section 4.5.2 mentions IEEE 802.1d. In fact, the correct
denomination is IEEE 802.1D, and using a capital letter has a
significance in the IEEE 802 standard denomination. Also, an informative
reference needs to be added for this standard.

[Ballot comment]
From MIB doctor Dan Romascanu:

I believe that Section 4.4.2  in this document includes a typo:

  Previously, 802.11 had two modes of operation.  One was Distributed
  Coordination Function (DCF) , which is based on the classic collision
  detection schema of "listen before sending".  A second optional mode
  is the Point Coordination Function (DCF).  The modes splits access
  time into contention-free and contention-active periods -- transmit-
  ting data during the former.

The second acronym should be PCF rather than DCF.

[Ballot comment]
I hovered on the edge of a DISCUSS for this.

Several inaccurate references - e.g. RFC 3668, which is obsolete, is listed
as a normative reference but not cited; the reference [REQ]
has been updated several times since listed here - I really think
these errors are only borderline editorial.

From Gen-ART review by Joel Halpern:

Moderate:  Describing MPLS as a routing protocol seems wrong in at least two regards:
1) MPLS control can be described as a path placement protocol.  But is not what we usually describe as a routing protocol.
2) The MPLS data plane which is necessary for the ETS work and which is described by the paragraph is a packet forwarding behavior, not a routing protocol.

Minor: The document would be helped by an early explicit definition of "administrative domain".  While this is actually included in [REQ], it would be helpful if it was in this document, as the concept is so central to the work.

Minor: IdNits indicates part of the 3978 / 3979 material is missing.
[BC - no surprise since the author attempted to cite 3668.]

[Ballot comment]
I hovered on the edge of a DISCUSS for this.

Several sloppy references - e.g. RFC 3668, which is obsolete, is listed
as a normative reference but not cited; the reference [REQ]
has been updated several times since listed here - I really think
these errors are only borderline editorial.

From Gen-ART review by Joel Halpern:

Moderate:  Describing MPLS as a routing protocol seems wrong in at least two regards:
1) MPLS control can be described as a path placement protocol.  But is not what we usually describe as a routing protocol.
2) The MPLS data plane which is necessary for the ETS work and which is described by the paragraph is a packet forwarding behavior, not a routing protocol.

Minor: The document would be helped by an early explicit definition of "administrative domain".  While this is actually included in [REQ], it would be helpful if it was in this document, as the concept is so central to the work.

Minor: IdNits indicates part of the 3978 / 3979 material is missing.
[BC - no surprise since the author attempted to cite 3668.]

[Ballot comment]
Section 2, 4th paragraph:
"Beyond cost the subject of cost, some domains are comprised of physical networks that support wide disparity in bandwidth capacity -- e.g., attachment points connected to high capacity fiber and lower capacity wireless links."

Beyond cost AND the subject of cost?  It looks like there's a word missing in the first part of this sentence.