RE: [Gen-art] Gen-ART Review of draft-ietf-bfd-base-08

David,

	I agree with Spencer on the point of "system thoughts"
verses "system states."  This may appear to be a style issue,
but it is actually simply a matter of trying to be as precise
as the language allows.  Who knows what a system "thinks"?
But it should be clear if a system is in an appropriate state.

	On the next issue, I don't understand your argument: are
you saying that you believe it is necessary to explicitly say
that "defending against operator error is out of scope"?

	Finally, Spencer's (last?) comment on use of "stronger"
is (again) not a stylistic one, but an attempt to squeeze the
little bit of precision that can be achieved in English.  It
is apparent that you believe you are saying "Using SHA1 is 
believed to have stronger security properties than MD5" (as
indeed is suggested by Spencer), but you are not (exactly).
Change the statement to "drinking milk, as opposed to chewing
rocks, leads to stonger bones" and you will see that what you
have said makes no explicit comparison between SHA1 and MD5 
(or milk and rocks, in my example).  Because the statement is
already in passive voice (whose belief is this?), and is vague
enough as it is, then we should try to fix as much of it as we 
can.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
  --- [SNIP] ---
> 
> >   packet to the correct BFD session after it is looped back to the
> >   sender.  The contents are otherwise outside the scope of this
> >   specification.
> >
> > 6.6. Demand Mode
> >
> >   Demand mode is requested independently in each direction by virtue
of
> >   a system setting the Demand (D) bit in its BFD Control packets.
The
> >   Demand bit can only be set if both systems think the session is
up.
> >
> > Spencer (clarity): this doesn't seem quite right to me, because the

> > statement requires that my system knows what the other system  
> > thinks. Is it correct to say "a system can only set the Demand bit  
> > when a session has transitioned to UP"? It might be preferable to  
> > delete the second sentence, because the following text explains  
> > this in greater detail, anyway.
> >
> 
> DW: This appears to be a style comment on "is up" vs "has  
> transitioned to UP," right?
> 
> 
> >   The system receiving the Demand bit ceases the periodic
transmission
> >   of BFD Control packets.  If both systems are operating in Demand
> >   mode, no periodic BFD Control packets will flow in either
direction.
> >
> >   Note that this mechanism requires that the Detection Time
negotiated
> >   is greater than the round trip time between the two systems, or
the
> >   Poll mechanism will always fail.  Enforcement of this requirement
is
> >   outside the scope of this specification.
> >
> > Spencer (clarity): you're not describing a requirement, you're  
> > describing a constraint. Perhaps "Note that this mechanism will  
> > always fail unless the Detection Time negotiated is greater than  
> > the round trip time between the two systems", and drop the second  
> > sentence?
> >
> 
> DW: What we are trying to state is that BFD cannot keep an operator  
> from making a configuration error. There is a constraint due to  
> physics and a requirement that it be adhered to and ... BFD can't  
> stop anyone from doing something stupid. "Enforcing the requirement  
> to meet the constraint ..." may be clearer language although a nit.
> 
  --- [SNIP] ---

> >   transmission rate and/or the Detection Time).
> >
> > Security Considerations
> >
> >   Using SHA1 rather than MD5 is believed to have stronger security
> >   properties.  All comments about MD5 in this section also apply to
> >
> > Spencer (clarity): "stronger than"? would this be correct if it  
> > said "Using SHA1 is believed to have stronger security properties  
> > than MD5"?
> >
> >   SHA1.
> >
> 
> 
> DW: This seems a style choice.
> 
> 
> Many thanks for your thorough review.
> 
> -DWard
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf