Subject: Re: [Ecrit] Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 26 Jul 2011 17:07:47 +0200

Hi, 

Thanks for the clarifications. I am looking for the updated version to
be able to clear. 

Regards,

Dan 

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2011 5:57 PM
> To: Romascanu, Dan (Dan)
> Cc: The IESG; [email-masked]; draft-ietf-ecrit-
> [email-masked]; [email-masked]
> Subject: Re: Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17:
> (with DISCUSS and COMMENT)
> 
> I thought I had replied to this, but I don't see it it.
> 
> ED-10 is SHOULD NOT because of the discussion in -framework about user
> interfaces.  Can't make any hard and fast rules, but our experience is
> bad.
> 
> ED-73 is self explaining.  The endpoint must support G.711 or
> transcoding must be available.  If the PSAP supports the narrowband
> codec the endpoint supports, than transcoding isn't necessary, which
is
> desirable.
> 
> I will add a reference NENA using this document:
> Other organizations, such as the North American Emergency Number
> Association (NENA), define the PSAP interface.  NENA's documents
> reference this document.
> 
> 
> 
> Brian
> 
> 
> On Jun 22, 2011, at 4:15 AM, Romascanu, Dan (Dan) wrote:
> 
> >
> >
> > Hi Brian,
> >
> > I will add one level of quoting, but take out all that is agreed.
> Very
> > little is left.
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >> -----Original Message-----
> >> From: Brian Rosen [mailto:[email-masked]]
> >
> >
> >>>>>
> >>>>> In a number of cases normative language appears to be used in
> ways
> >>>>> different from those described in RFC 2119.  In some cases,
> >>>> the term
> >>>>> "SHOULD" is used in situations where statutes or
> >>>> regulations may mandate behavior.
> >>>> We believe this to be the best choice.  It's MUST except in
> >>>> specified circumstances.  The circumstances are when
> >>>> regulations say otherwise.
> >>>
> >>> It would be good to clarify this in the document.
> >> I went through the document SHOULDs and looked for cases where we
> >> should say that.  I didn't spot any.  Could you point some out for
> me?
> >>
> >
> > What about ED-10 and ED-73? What are the reasons for these SHOULD
not
> to
> > be MUST?
> >
> >
> >>>>>
> >>>>> I also find odd the fact that the document does not refer
> >>>> at least informationaly to the NENA i2 and i3 architectures.
> >>>> The behavior of the system and requirements may be different
> >>>> in i2 and i3 environments. There are places where behavior
> >>>> should be configurable or negotiated to allow for better
> >>>> behavior in a transitional environment. There are also places
> >>>> where behavior will be prescribed by local statues or
> >>>> regulations, so that configuration and/or negotiation is a
> >>>> practical requirement.
> >>>> It would be inappropriate to refer to i2 and i3 in -phonebcp.
> >>>
> >>> Why? It's not about the specific North-American regulatory
aspects,
> >> it's
> >>> about the fact that the document targets an all-IP architecture
> > which
> >> is
> >>> associated to i3 for everybody who deals with emergency.
> >> I covered "all-IP".   Therefore i2 is not relevant.
> >>
> >> i3 might be relevant only in that it defines PSAP requirements, the
> >> mirror of this document.  I still don't understand the value of a
> >> reference here.  I'll put one in -framework.
> >>
> >> The only thing we could say is kind of weird - "This document is
> used
> >> by other organizations who define PSAP interfaces, such as NENA
i3".
> >>
> >> We don't say anything in i3 that this document is dependent upon -
> > it's
> >> the other way around.
> >>
> >
> > Understood and agreed. Yet, any user, implementer, lawmaker, etc.
> > looking into the requirements and architecture of an IP-based
> solution
> > in North America will need to look at these two documents (at least)
> in
> > tandem to have an understanding. This is why even the 'kind of
weird'
> > phrase would be useful IMO.
> >
> >>
> >>>
> >>>> I do think we could refer to it in -framework however, and
> >>>> we will draft a paragraph that does that.
> >>>>
> >