[Ecrit] Comments on draft-ietf-ecrit-mapping-arch-01

[Matt Lepinski <mlepinski at bbn.com>]

Henning,

Here are some comments on draft-ietf-ecrit-mapping-arch-01. In general, 
I like the current state of the document and therefore many of my 
comments are just minor editorial suggestions.

3. Definitions
-----------------
- The term "coverage region" is used frequently throughout the document 
but is not defined. Consider inserting a definition such as:
"The coverage region of an AMS is the geographic region within which the 
AMS is able to authoritatively answer mapping queries. Coverage regions 
are generally, but not necessarily, contigous and may be represented as 
either a subset of a civic address or a geometric object."

- The term "region map" is defined but the term only appears in the 
Security Considerations section. This may be acceptable, however, 
consider deleting this definition and rewording the security 
considerations section to use other terms. (Note: If the term 'coverage 
region' were specifically defined, its definition could include

- In Section 7.1 you state "The collection of all trees for one service 
is known as a forest". For consistancy, you may want to augment the 
definition of a Forest Guide as follows: "... the coverage regions of 
all trees for a particular service". Additionally,  Section 7.1 
indicates that (in a logical sense) each tree provides mappings for a 
particular service. Therefore, you might want to consider augmenting the 
definitoin of a tree in a similar fashion: "... of authoritative mapping 
servers for a particular service."

- The term "resolver" is definded twice. The first of the two resolver 
definitions (the between parent and seeker) appears to be the better 
one, and so I would recommend deleting the second definition (and 
adjusting the order of the other entries to preserve alphabetical 
ordering). However, consider adding a second sentance to the definition 
indicating that a resolver may also cache mapping results.

- I agree with Otmar Lendl regarding the change to the definition of 
"parent". (I.e., change root resolver to root AMS).

- The last sentance of the definition of AMS is unclear: consider "An 
AMS may redirect or forward a query to another AMS within the tree."

6. Resolver
--------------
- The second paragraph states "From a protocol perspective, a resolver 
acts in the same way as a seeker, except that it knows one or more 
forest guides."
I'm not sure what the phrase "from a protocol perspective" means in this 
context. In particular, resolvers accept queries from seekers, whereas 
seekers "have no obligations to other entities in the system" ... this 
would seem to me to be a difference in behaivor from a protocol 
perspective.

7.1 Basic Operation
------------------------
- Consider rewording the first sentance of the first paragraph as 
follows:  "... entities, but clients (seekers) may potentially need to 
find out mapping information for any spot on Earth."

- I believe that a location in a query is typically described by either 
civic or geospatial coordinates (but not both). Therefore, consider 
rewording the first sentance of the second paragraph as follows: "Each 
tree can map a location described by civic or geospatial coordinates for 
..."

- In the second to the last paragraph, you indicate that the difference 
between coverage region data (stored at non-leafs) and mapping data 
(stored at leafs) is that coverage regions return LoST URLs whereas 
mapping entries contain service URLs. However, in your example of data 
at a leaf node includes an entry with a LoST URL, which seems to imply 
that leaf node mapping data can include LoST URLs.

8. Forest Guides
--------------------
- Section 7.1 indicates that a forest consists of all trees for one 
service. For consistency, consider rewording the third sentance of the 
first paragraph as follows:  "It is a server that keeps track of the 
coverage regions of all trees for one service."

- The second paragraph states: "For authenticity, the records SHOULD be 
digitally signed."
This is the first (and I believe, only) use of the term "records", 
therefore I would clarify. Perhaps "the coverage regions returned by a 
forest guide SHOULD be digitally signed."
Also, I fear that it might be unclear to a reader who it is that should 
be digitally signing the records. (e.g., Might a reader think that the 
forest guide should be signing the records it sends out?) There is some 
discussion of this in the security considerations section, however, I 
think it might be useful to include a forward reference here to the 
discussion in Section 10.

- As Otmar Lendl pointed out, there is a contradiction regarding whether 
or not all forest guides (for a particular service) contain the same 
information. My personal viewpoint is that we should accept the fact 
that all forest guides will not necessarily have consistant information. 
This is the price we pay for not having a global root. Therefore, I 
think the less we say about forest guide synchronization the better. 
It's reasonable to expect that some (hopefully many) forest guides will 
peer with each other and that each forest guide will share its records 
with all its peers. However, I don't think its reasonable to expect (as 
stated in the final sentance of paragraph 3) that each forest guide wil 
distribute coverage region announcements to ALL other forest guides.

- Consider deleting the second sentance of paragraph 4, I believe this 
has been sentance is redundent given what's been said in paragraphs 1, 2 
and 3. If this sentance is deleted, perhaps the 4th and 5th paragraphs 
could be merged into a single paragraph.

9. Configuring Service Numbers
---------------------------------------
- In the last sentance of paragraph 6, delete the word "to" so that the 
sentance reads: "... uncertain origin, as a user may contact the home 
network or some local branch office of the corporate network."

- In the last paragraph, I think the third sentance would be more clear 
if it were reworded as follows: "The mapping can be obtained either 
along with the service URL or through a separate request."

- In the last sentance of the last paragraph, replace the final 
occurance of "the" with "its" so the sentance reads: "... service number 
for its home location, not just its current its current (visited) 
location."





_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit