Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain
RFC 4375

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

(Jon Peterson) Yes

(Brian Carpenter) No Objection

Comment (2005-10-24 for -)
No email
send info
Gen-ART comments from Scott Brim (two fixes needed)

>>    Any application layer label mechanisms used to support ETS MUST be
>>    capable of supporting both the set of ETS and non-ETS (presumably,
>>    normal) users.
>
>
> I'm not sure about this one, perhaps because I don't understand what
> it means.  I can envision, for example, applications that are only
> used in ETS situations, and are only capable of running with ETS
> labels.  Are they disallowed?  No special apps?
>
> I can see a requirement that any application which is used during
> normal times must still be usable during "medium emergencies".  Is
> that the goal?


the intent of the requirement was to discourage designs/ specifications that totally ignore a "normal" condition -- even if  the application is used exclusively by ETS type users (e.g., first  responders like Fireman).  The practice of taking into account the  "normal" condition is found in existing specifications of MLPP, eMLPP  for GSM, and Project 16 for mobile radio.

admittedly, when the above requirement was written, I had in mind  existing IETF applications and I wanted to squash any attempted  augmentation that damaged its legacy operation for "normal" or non- ETS type users.

How does the following sound?

     Regarding existing IETF specified applications, augmentations  in the form
     of labeling mechanisms to support ETS  MUST NOT adversely  affect its
     legacy usage by non-ETS users.  With respect to future  applications, such
     labeling mechanisms SHOULD allow the application to support a  "normal"
     (non-emergency) condition.


> Also a nit in case there is another version ...
>
>
>>    If proxies take such action, then the security measures  discussed in
>>    [rfc3689] MUST be considered.  More discussion about security  in the
>>    single domain context is discussed in section 5.
>>
>
> You don't mean to say that the discussion is discussed. :-)


thanks for catching that.  it will be fixed :)

-ken

(Bill Fenner) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

(Bert Wijnen) No Objection

Comment (2005-10-25 for -)
No email
send info
I see:
   3.8 MIB

   Management Information Bases (MIBs) SHOULD be defined for mechanisms
   specifically in place to support ETS.  These MIBs MAY include objects
   representing accounting, policy, authorization.

I suggest to change to:

   3.8 MIB

   Management Information Base (MIB) modules SHOULD be defined for
   mechanisms specifically in place to support ETS.  These MIB
   modules MAY include objects representing accounting, policy,
   authorization.

That is: there is one single MIB, which is composed of many MIB modules.
I am not sure I understand the capitalized MAY in the 2nd sentence. I
can live withit, but porbably better to just use lowercase "may".

The discussion about MIB and SNMP in the Security Considerations section
is porbably best changed/updated to state a subset of the text in the
common MIB Security Template as found at 
  http://ops.ietf.org/mib-security.html

Specifically, I think I would like to see text aka:

SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

Which I think covers the considreations that are relevant for this
MIB document.

(Alex Zinin) No Objection

Comment (2005-10-27 for -)
No email
send info
A small note on the following para:

4.2 Redundancy

   The issue of making networks fault tolerant is important and yet not
   one that can be easily articulated in terms of requirements of
   protocols.  Redundancy in connectivity and nodes (be it routers or
   servers) is probably the most common approach taken by network
   administrators, and it can be assumed that administrative domains
   apply this approach in various degrees to there own resources.

Actually, as far as articulation of network fault tolerance is concerned, 
work that's been done on MPLS and IP Fast Reroute gives us a very good
idea how this can be quantified: the major two parameters are the service restoration delay (in ms), and failure coverage (in %% of ingress-egress
router pairs). For the former, the commonly accepted target is 50ms,
and the latter entirely depends on the level of redundancy in the network,
and as such can be used as a quantative metric for it.