Re: [Ecrit] DISCUSS on draft-ietf-ecrit-location-hiding-req

["Romascanu, Dan (Dan)" <[e-mail]>]

 

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo) 
> [mailto:[e-mail]] 
> Sent: Sunday, February 21, 2010 9:27 AM
> To: Romascanu, Dan (Dan)
> Cc: [e-mail]
> Subject: DISCUSS on draft-ietf-ecrit-location-hiding-req
> 
> Hi Dan, 
> 
> You wrote: 
> "
> I like the document and I belive that it's ready for 
> approval, but I have a rather minor detail to clarify.
> 
>  Req-6:  The solution MUST work if PSAP boundaries have holes.  (For a
>       discussion about holes in PSAP boundaries and their encoding the
>       reader is referred to [I-D.ietf-ecrit-specifying-holes].)
> 
> I do not see how the requirement can be understood without 
> understanding the concept of holes in PSAP or LoST service 
> boundaries. This being a MUST requirement it looks to me like 
> [I-D.ietf-ecrit-specifying-holes] should be a Normative 
> rather than Informative reference.
> "
> 
> [I-D.ietf-ecrit-specifying-holes] specifies one specific way 
> of encoding holes in PSAP boundaries but the requirement 
> itself is independent of the chosen approach. 
> 
> So, in that sense I would believe there is no normative dependency.
> However, if someone does not know what "a hole in a PSAP 
> boundary" means then they should better read a document and 
> there is only one document they can read from the IETF ECRIT 
> group that explains this aspect. 
> 
> So, what you you suggest me to do? 
> 
> Ciao
> Hannes
> 

Yes - the problem is that the document lacks a definition of what "a
hole in a PSAP  boundary" means. That 'one document they can read from
the IETF ECRIT group that explains this aspect' should be a normative
reference IMO. What document are we talking about -
[I-D.ietf-ecrit-specifying-holes] or something else? The alternative is
to define the term here. 

Regards,

Dan