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

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 21 Feb 2010 09:27:19 +0200

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 21 Feb 2010 08:46:06 +0100

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo) 
> [mailto:[email-masked]] 
> Sent: Sunday, February 21, 2010 9:27 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> 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.
> 
> 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. 
> 
> 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. 
> 

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 21 Feb 2010 15:50:12 +0800

Holes in Polygons has been waiting for nearly 18 months to actually appear on an IESG telechat.
I don't know what the hold up has been, but hopefully the incoming AD for this area will speed things up a bit.. *hint* hint*

Cheers
James

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Romascanu, Dan (Dan) [[email-masked]]
Sent: Sunday, February 21, 2010 1:46 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email-masked]
Subject: Re: [Ecrit] DISCUSS  on draft-ietf-ecrit-location-hiding-req

Regards,

Dan
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 21 Feb 2010 10:14:50 +0200

I did see the differentiation between normative and information in a
slightly different fashion, as I responded to Alexey. 

With the holes document there would not necessarily be a problem to put
it into the normative dependency section but then I would have to follow
the suggestion by Alexey as well and the consequence is that there is a
large list of informative documents in the normative reference section
that only provide background on certain subjects. 

I could, to address your specific comment, also add a sentence saying
what a "hole in a PSAP boundary" means. 

Ciao
Hannes

>From: ext Romascanu, Dan (Dan) [mailto:[email-masked]] 
>Sent: 21 February, 2010 09:46
>Subject: RE: DISCUSS on draft-ietf-ecrit-location-hiding-req
>
> 
>
>> have a rather minor detail to clarify.
>> 
>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.
>> 
>> 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.
>> 
>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
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 21 Feb 2010 14:07:47 +0100

Hannes, 

I can go with the later proposal. The rough rule of thumb in such
situations is that if a reference is needed in order to understand the
document in review than this reference should be normative. In this case
adding a sentence that explains what a "hole in a PSAP boundary" means
would eliminate the need for another document where a definition of the
hole can be found to be made a normative reference. 

Dan

> Sent: Sunday, February 21, 2010 10:15 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> I did see the differentiation between normative and 
> information in a slightly different fashion, as I responded 
> to Alexey. 
> 
> With the holes document there would not necessarily be a 
> problem to put it into the normative dependency section but 
> then I would have to follow the suggestion by Alexey as well 
> and the consequence is that there is a large list of 
> informative documents in the normative reference section that 
> only provide background on certain subjects. 
> 
> I could, to address your specific comment, also add a 
> sentence saying what a "hole in a PSAP boundary" means. 
> 
> Ciao
> Hannes
> 
>