RE: [Gen-art] Gen-ART review of draft-ietf-ecrit-requirements-13.txt

["Roger Marshall" <[e-mail]>]

Suresh:
I apologize for not replying to your comments in a more timely manner
with which they were originally sent.  Despite this miss, Henning and I
have reviewed and provided comments back which should make it in before
publication.  These changes are captured as comments from me, "[rsm]"
and based on feedback (to me) from Henning, as "[hgs]".

Thank you. 

-roger s. marshall.

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]] 
> Sent: Friday, June 22, 2007 7:35 AM
> To: Suresh Krishnan; General Area Review Team; 
> [e-mail]; Roger Marshall
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Gen-art] Gen-ART review of 
> draft-ietf-ecrit-requirements-13.txt
> 
> I received this review after the IESG telechat.
> 
> At 07:18 PM 6/21/2007, Suresh Krishnan wrote:
> >I am the assigned Gen-ART reviewer for
> >draft-ietf-ecrit-requirements-13.txt
> >
> >For background on Gen-ART, please see the FAQ at 
> ><http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
> >
> >Please resolve these comments along with any other Last Call 
> comments 
> >you may receive.
> >
> >Summary: This draft is ready for publication, but I have 
> some suggestions.
> >
> >Comments: Overall the draft is well written and it is a really good 
> >idea to include the motivation along with the requirements. 

[rsm - thank you.]

> Since this 
> >is my first brush with this technology, please excuse me if 
> some of the 
> >comments are too basic.
> >
> >
> >Semi-substantial
> >================
> >
> >* Requirement Lo4
> >
> >If the location validation failed, it would be a good idea 
> to let the 
> >client know, Perhaps add something like this
> >
> >"If location validation fails, the mapping protocol MUST convey the 
> >error to the client"

[rsm: agreed, slightly reworded.  Also will remove "(street 
addresses)".]

[hgs: reworded it further, to make it less awkward, changed it as
follows:
OLD (*):
  Lo4. Validation ... for civic locations (street addresses).
NEW:
  Lo4. Validation of civic locations: The mapping protocol MUST be able
to report the results of validating civic locations.
]

> >
> >
> >* Requirement Re6
> >
> >Isn't this a requirement on the mapping server rather than 
> the protocol?

[rsm: it may be so, but it provides no harm left as is.]

[hgs: No change required.]

> >
> >
> >* Requirement Lo7
> >
> >Since I do not see how invalid locations will be mapped to a 
> PSAP, why 
> >is this required?

[rsm: see definition for "Location validation".  Here, lack of 
validation doesn't necessarily imply that the location is not useful 
in routing, rather that, the fact that it may not have been checked
(validated) beforehand is NOT reason enough to fail the call.  No 
change made.]

[hgs: No change made.]

> >
> >
> >Minor
> >=====
> >
> >* Requirement Re7
> >
> >I am not sure what "common data structures and formats" 
> means. Does it 
> >mean commonly used data structures and formats?

[rsm: Not really targeted at 'commonly used' data structures and formats
as much as it is saying that 'standard' formats for location data,
(e.g., a PIDF-LO). (Also, database structure would be beyond the scope
of this doc, despite what the motivation text may imply to some.)]

[hgs: Changed.
OLD:
  "Re7.  Common data structures and formats: The mapping
protocol SHOULD support common formats for location data."
NEW:
"Re7.  Common data structures and formats: The mapping
protocol SHOULD support common formats (e.g., PIDF-LO) for location
data."
]

> >
> >
> >* Requirement Lo8
> >
> >This perhaps needs to be a requirement on mapping clients, 
> servers and 
> >protocols and not just protocols

[rsm: Despite some slight variances contained herein, this set of
requirements is intended for the mapping protocol behaviour alone.  No
change made.]

> >
> >
> >* Requirement Id1
> >
> >Why does the mapping protocol need to distinguish between different 
> >emergency services? Isn't it the mapping service that needs 
> to be aware.

[rsm: True enough.  Therefore, the requirement has been reworded to
clarify what it is that the protocol has to do.]

[hgs: Changed as follows.
OLD (*):
  MUST be able to distinguish between different emergency services, ...
identifiers
NEW:
  MUST be able to support different emergency services, distinguished by
different service identifiers.
]

> >
> >
> >* Requirements Id5, Id7, Id9
> >
> >Not sure who this requirement is on. Perhaps reword the 
> requirements so 
> >that it becomes clear who needs to satisfy the requirements.

[rsm: Id5, This is a difficult problem, since it really gets into  
some of the aspects being discussed around loose routing, etc.]

[rsm: Id7, Agree that this is ambiguous, but have decided to leave 
it alone.]

[hgs: I would leave it alone, given that this is AUTH48, not working
group  
last call. They seem harmless, even if somewhat misplaced for a  
document titled "Requirement for Emergency Context Resolution".]

[hgs: Id9, Changed.
OLD:
  "Id9.  Discovery of visited emergency numbers:" There MUST
be a mechanism to allow the end device to learn visited emergency
numbers."
NEW:
  "Id9.  Discovery of visited emergency numbers:" The mapping protocol
MUST support a mechanism to allow the end device to learn visited
emergency numbers."
]


> >
> >
> >* Requirement Id6
> >
> >I am not sure about the scope of this requirement. What signaling 
> >protocols are covered by this requirement? Is it ALL 
> signaling protocols?

[hgs: Doesn't seem necessary to change, since the general "Signaling  
protocols" implies that this is a general statement.]

> >
> >
> >Editorial
> >=========
> >
> >* There are a few occurences of non-normative language where 
> normative
> >   language may be used in order to conform to the overall 
> style of the
> >   document.
> >
> >   - Perhaps use Normative MUST?
> >
> >    Id8.  Return fallback service identifier:  The mapping 
> protocol must
> >       be able to report back the actual service mapped if 
> the mapping
> >       protocol substitutes another service for the one requested.

[hgs: Changed.
OLD:
  must be able to report
NEW:
  MUST be able to report
]

> >
> >   - Perhaps use Normative MAY?
> >
> >    Lo8. 3D sensitive mapping:  The mapping protocol MUST implement
> >       support for both 2D and 3D location information, and 
> may accept
> >       either a 2D or 3D mapping request as input.

[hgs: Changed.
OLD (*):
  and may accept either
NEW:
  and MAY accept either
]

> >
> >* Newer draft versions are available for
> >
> >   draft-ietf-ecrit-security-threats &
> >   draft-ietf-ecrit-service-urn

[rsm: these should now be changed to link through to the latest drafts.]

> >
> >Cheers
> >Suresh
> >
> >
> >
> >
> >_______________________________________________
> >Gen-art mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/gen-art
> >
> 
> 


The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.



_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art