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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Jun 2011 10:15:28 +0200

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.
> >>