Subject: [Ecrit] [ecrit] #6: Shida's comments

From: "ecrit issue tracker" <[email-masked]>
Date: Thu, 21 Apr 2011 22:59:45 -0000

#6: Shida's comments

 From: shida at ntt-at.com
 Date: Wed, 20 Apr 2011 11:27:33 +0900
 To: ecrit at ietf.org
 Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01

 I reviewed the document and followings are some comments/questions.

  In general, I am having a hard time understanding the intent of the
 draft. Is it defining a CAP document composition rule (4.2) for delivering
 the CAP message from citizen to authority only? OR is it defining a SIP
 usage to transport CAP message as well? If it's latter I think more should
 be said about how SIP entities should behave. I understand it is an
 experimental document but I think we need to clarify the scope of the
 document somewhat.

  1. For scenario 1, I really don't think in reality a sensor will be
      implementing a SIP stack simply to support the transport of
      CAP message, it just seems like an overkill. I understand how
      aggregator to PSAP should be SIP to re-use what is defined
      in Phone-BCP and pre-exising infrastructure. May be text can
      be added that some other means may be used to deliver a CAP
      message from CAP to aggregator.

  2. I am assuming that any SIP device can use MESSAGE to
      send CAP to PSAP. If so, some device will be able to handle
      call-back and some won't. Do we need to distinguish devices
      that will be issuing the MESSAGE to see whether call-back
      can be established etc?  (I guess PSAP can look at allow header
      to see if the device can accept INVITE etc.)

  3. For both cases, should there be any recommendation on how
      sensor should behave in case 200 OK is not received or error
      is received from downstream? Again related to the scoping of
      the document, this may not be necessary if the main intent is
      to recommend CAP document composition rule.

  4. If non SIP device is used what should be set in "sender" of CAP?
      What if the CAP message is sent by a sensor which doesn't support
      SIP and it is the aggregator that acts as the SIP intermediary and
      SIP endpoint?

  5. Use of P-Asserted-Identity doesn't provide any integrity so I would
      take it out of section 6.3.

  6. Why is RFC3265/RFC3903 a normative reference? I think they
      should be in an informative reference as there is no normative text
      surrounding their uses.

  7. Shouldn't RFC3261(SIP)/RFC3428(MESSAGE)/location-conveyance/
      RFC4119(PIDF-LO) be in a normative reference?

 **Some nits**

   Section 6:

   OLD ".. this document and the discussion in.."

   NEW ".. this document and are discussed in.."

   Section 6.2

   OLD "..alerts and reply them at a later time.."

   NEW "..alerts and replay them at a later time.."

 Regards
   Shida

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  data-only-ea               |     Version:  1.0       
 Severity:  In WG Last Call            |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/ecrit/trac/ticket/6>
ecrit <http://tools.ietf.org/ecrit/>