[Ecrit] Review of draft-ietf-lost-sync-01

[Richard Barnes <rbarnes at bbn.com>]

This draft proposes an XML syntax for transferring LoST mappings between 
LoST nodes.  While this XML syntax seems to have most of the necessary 
features for the proposed use cases, the details of how the XML syntax 
is to be used to effect the transfer are either ambiguous or completely 
missing.  Specific comments below.
--Richard


Section 1. Introduction
-- This may reflect a misunderstanding of the mapping architecture on my 
part, but my impression was that the architecture envisioned query 
patterns similar to the DNS, either iterating or recursing through the 
tree.  This document seems to propose that instead, authoritative 
servers and branch nodes would push mapping up, presumably to FGs (this 
behavior has no analogue in the DNS to my knowledge).  It would be 
helpful if this document could clarify how these two patterns interact.

Section 3. Distributing Mappings via <pushMappings> ...
-- I think there's enough description here to basically understand how 
this is supposed to work, but there's not a clear, normative 
specification, not a single MUST in the whole section!  It would be 
helpful to have clear "Sender processing" and "Recipient processing" 
instructions.
-- Likewise, there's no clear description of who sends which messages to 
whom (except by example), and no description at all of how these 
messages are carried.  If this is an extension to LoST, please say so, 
or if it's another HTTP usage, or bare TCP, etc.  The absence of these 
details (particularly message flow patterns), it's a hard to understand 
the sequence of events.
-- The message pattern this seems to be following is a little weird; 
it's "pub/sub", but without the "sub".  There should be some comment on 
this, e.g., that there is an expectation that these peering 
relationships are established out of band, and thus no subscription or 
request is necessary.  Alternatively, <getMappings> could possibly 
support an "asynchronous" flag.
-- There's a stray " at the end of the fourth paragraph
-- The URIs in the example <uri> fields are invalid

Section 4. Synchronizing Mapping Stores via <getMappings> ...
-- Same first two comments as for Section 3.  There needs to be a much 
clearer, normative description of how the peers process and transmit 
messages.
-- Please change the <m> tag to something readable (<mapping-descriptor>?)
-- The description here seems to conflate two types of query parameters, 
"what I have" and "what I want".  If you separate these two out, it 
could simplify the semantics: the "what I have" section would have 
<mapping> elements that MUST have all three identifier fields, while the 
"what I want" section would have <mapping-descriptor> descriptions of 
mappings to be returned (using subsets of identifier fields).
-- Why can't a <getMappings> element have a lastUpdated attribute? 
Either it should have everything or nothing.  (IMO, the optimization 
isn't worth the extra complexity of merging attributes from 
<getMappings> and <m>)
-- Is there a reason no content-based queries are allowed?  For example, 
I could imagine that it would be useful to be able to query for all 
service boundaries that intersect a given region, or to constrain a 
query by service URN.

Section 5. Security Considerations
-- The document delegates security to LoST without ever having said that 
the XML defined here is carried by LoST.  In order for this stuff to be 
meaningful, there has to be a transport protocol defined.





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