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

Note: This ballot was opened for revision 08 and is now closed.

(Bert Wijnen; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2005-12-15 for -)
No email
send info
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.

(Margaret Cullen; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2005-12-16 for -)
No email
send info
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/

(Jon Peterson; former steering group member) Yes

Yes ( for -)
No email
send info

(Brian Carpenter; former steering group member) (was Discuss) No Objection

No Objection (2005-11-29 for -)
No email
send info
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.]

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) (was No Record, Discuss) No Objection

No Objection (2005-12-14)
No email
send info
  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/

(Scott Hollenbeck; former steering group member) No Objection

No Objection (2005-10-24 for -)
No email
send info
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.

(Ted Hardie; former steering group member) (was Discuss) Abstain

Abstain (2006-08-08)
No email
send info
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.