Subject: [Gen-art] A *new* batch of IETF LC reviews - 10 Jan 2007

From: "Mary Barnes" <[email-masked]>
Date: Thu, 10 Jan 2008 20:38:16 -0600

Hi all,

Here's the link to the LC assignments for this week:
http://www.alvestrand.no/ietf/gen/art/reviewers-080110-lc.html

With the assignments captured in the spreadsheets: 
http://www.alvestrand.no/ietf/gen/art/gen-art.html 
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html 

The standard template is included below.

Thanks, 
Mary. 

-------------------------------------------------------------------

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
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.

Document: 
Reviewer: 
Review Date:  
IETF LC End Date: 
IESG Telechat date: (if known)

Summary:

Comments:

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

---

From: "Eric Gray" <[email-masked]>
Date: Thu, 17 Jan 2008 16:39:29 -0600

Author(s), 

Document: Time TLV (draft-ietf-manet-timetlv-04)

Reviewer: Eric Gray
Review Date: January 17, 2008

IETF LC End Date: January 17, 2008

Summary: 

It is hard for me to be sure this specification is ready for publishing
as a 
Proposed Standard RFC.  Primarily this is because I have no clear idea
how
readable the specification is intended to be for a general (technical)
reader.

However, if there is a reasonably large readership that is able to
comprehend
readily what this specification actually specifies, and that readership
finds
this useful, then this specification may be nearly ready for publishing
as a 
Proposed Standard RFC.

Minimally, the author(s) should expand on the Security Considerations
section
by at least describing measures that any protocol using the TLVs defined
here
should define to ensure - for example - the authenticity of the values
given.

	Comments: 

One of the immediate problems I had with this specification is with the
concept 
of "Distance" which initially seemed seriously under-specified.

One of the possible ways to assign a value to "Distance" is in terms of
"hop
count", which - when applied in the way the specification discusses -
might
be equated to a time-correction.  However, one has to read fairly far
into
the specification in order to understand how this would work in
practice, if 
the actual time associated with traversal on a hop-by-hop basis is
(AFAIK) 
non-deterministic.  

Moreover, this is listed as merely one way to determine a value for
Distance 
- no other scheme is explicitly proposed, nor is there an explanation of
how 
additional schemes might be proposed later, nor is there any
specification of 
units to be associated with any value proposed (beyond "hops").

If one dives into the specification, however, one can begin to
understand how
this is expected to work - at least for the hop-count case.  The
terminology
used is probably somewhat less incomprehensible to someone very familiar
with
most of the references, and this does not help.  For example, a "single
value
TLV" appears to have structure which makes it hard to recognize using
any of
the reasonably intuitive definitions of "single" that I've seen in
common use.

If I understand the description at the bottom of page 8, and top of page
9,
correctly, distance is a unit-less value that the TLV interpreter is
supposed
to know - either a priori, or as derived (e.g. - from message contents,
such 
as with hop-count).  Distance is then used for comparison with
"Distance"
values to determine which of the "Time" values is most correct.  In the
hop
count case, a hop-count value might - for example - be used to derive
the
offset around which the value interpreter would expect to find the
correct
(or most correct) time value.

For a first time reader, this is fairly opaque - even assuming I've
gotten
it right.  If I've not understood it correctly, please explain.

Even if I have understood it correctly, it would be useful - if not
really
absolutely necessary - to provide a bit more clarification and possibly
one
or more examples.

Also, the Security Considerations section can be a bit more useful than
it
is now.  Minimally, it should make the obvious statement that any use of
the TLVs defined in this specification that relies on authenticity,
should
include specification of mechansisms for authentication.  Similarly, if
it
is desirable to conceal time and distance values (to prevent inferring
of
station locations, for instance) in any particular use, specification of
that use should include a description of how this would be done.

These things seem obvious, but including this sort of text gives someone

who plans to use these TLVs a gentle reminder of some things they should
consider.