Subject: [Ecrit] AD review: draft-ietf-ecrit-unauthenticated-access

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Sep 2013 23:53:17 -0400

I have reviewed this document and requested an IETF LC.  I have a few minor
comments, which can be handled along with the IETF LC comments.

-- In the Abstract and Introduction: It might be helpful to mention the
precedent in the PSTN for context.  The analogy to SIMless or zero-balance
emergency calls could help people understand the feature that this document
is trying to enable.

-- In Section 5: Since these steps are performed in sequence, they should
be numbers.  Also, it would be helpful if you could highlight which of
these steps might be different from the normal PhoneBCP behavior -- namely,
steps 4 (UA does LoST instead of VSP) and 5 (INVITE to ESRP instead of VSP).

-- In a few places, the phrase "mandated" is used.  Should this be
"REQUIRED"?

-- In Section 5.3.3., it seems like it would be helpful to emphasize that
if a PSAP wants to support NASP calls, then it MUST NOT restrict incoming
calls to a particular set of ASPs.  This seems kind of obvious, but I
expect it will be tempting for PSAPs to impose those sorts of limitations,
so it's important to remind them that it breaks this use case.

-- In Section 6: s/radio networks/networks/.  A note at the top to set
context would be helpful, noting that the NAA case is inherently a layer 2
problem, and the general form of the solution is to provide an "emergency
only" access type, with appropriate limits/monitoring to prevent abuse.  It
would be helpful to have references where specific link-layer technologies
are referenced.

Thanks,
--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Sep 2013 11:03:35 +0300

Hi Richard,

thanks for the review.

On 13.09.2013 06:53, Richard Barnes wrote:
> I have reviewed this document and requested an IETF LC.  I have a few
> minor comments, which can be handled along with the IETF LC comments.
>
> precedent in the PSTN for context.  The analogy to SIMless or
> zero-balance emergency calls could help people understand the feature
> that this document is trying to enable.

Good idea.

>
> -- In Section 5: Since these steps are performed in sequence, they
> should be numbers.  Also, it would be helpful if you could highlight
> which of these steps might be different from the normal PhoneBCP
> behavior -- namely, steps 4 (UA does LoST instead of VSP) and 5 (INVITE
> to ESRP instead of VSP).

The problem with the number is that there are different paths taken 
depending on the scenario you are in. Hence, the numbers are a bit 
misleading unless we replicate the diagram several times for the 
different scenarios. This would also allow us to illustrate the 
difference with the normal PhoneBCP procedure more easily. Overloading 
everything into one diagram might be tough -- we are talking about ASCII 
art here rather than YouTube videos.

> -- In a few places, the phrase "mandated" is used.  Should this be

Yes, that would be better.

>
> -- In Section 5.3.3., it seems like it would be helpful to emphasize
> that if a PSAP wants to support NASP calls, then it MUST NOT restrict
> incoming calls to a particular set of ASPs.  This seems kind of obvious,
> but I expect it will be tempting for PSAPs to impose those sorts of
> limitations, so it's important to remind them that it breaks this use case.

Certainly makes sense. I will update that part.
> context would be helpful, noting that the NAA case is inherently a layer
> 2 problem, and the general form of the solution is to provide an
> "emergency only" access type, with appropriate limits/monitoring to
> prevent abuse.  It would be helpful to have references where specific
> link-layer technologies are referenced.

OK.

Ciao
Hannes

>
>
> Thanks,
> --Richard
>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit