Re: Proposed Up/Down protocol description

[Randy Bush <randy@psg.com>]

many are nits

--

section 1 could use a bit that the words "IR" and "ISP" are really
turtles all the way down.  i.e. could be IANA/RIR, RIR/LIR, ...

did i not hear a pretty sensible suggestion that it be called parent
and child or something?

--

2 - should mention that the parent's IRBE is considered the authority on
the child's holdings

--

3.1 - "Conforming parsers MUST ignore all elements and attributes that
are not a part of this document."

being a naggumite, i might be more stringent.  if you see something you
do not understand, raise an error condition.  it really should not have
been there.  keep life simple and keep the road safe.

--

similarly, i would drop

  This document defines version 1 of this protocol. It is noted that there
  may be a requirement for explicit version negotiation in future versions
  of this protocol, but the specification of any such version negotiation
  is deferred until the next version of this protocol.

a future version may do all sorts of things.  no need to presuppose
(some of) them now.  it only adds unnecessary text and sets us up to be
incorrect.

--

you may want a more canonic reference than http://rfc3852.potaroo.net
RFC3852

--

please delete the second clause in

   7. The value of the version number of the message is 1, or the
      recipient understands the namespace and all elements and attributes
      that are used in the message.

this is the protocol, the whole protocol, and nothing but the protocol.

--

"Messages are checked using the following sequence of tests:"
   is followed by the looser (at least in american) condition
"The checks should generally be applied in the order specified."

s/sequence of//  if you really want to loosen it

--

you use the terms "server" and "client."  let's choose one pair of nouns
and stick to them rigorously.

--

you use the phrase "granularity of seconds or higher."  is a minute
higher granularity than a second or is a millisecond higher?  perhaps
you want to say "finer" or something similar.

--

        - The server checks that the msg-ref value is valid. If the
          message's msg_ref value is 0, or negative, then the message is
          rejected with an "invalid msg_ref" code, and the server's value
          for last_msg_ref is placed in the last_msg_processed attribute of
          the error response.

tells an attacker what sequence number to select from its list of
replayable attack messages in the subsequent attacking message.

--

       - If this is a new message channel, or if the message channel has
         been idle for a reset_interval period of time, then the server
         will set its own msg_ref counter to that of the incoming message
         (msg-ref counter reset).

should it not set it to 0?  if not, then the attacker wins on the first
message in the channel, replaying something it overheard on a different
channel.

--

	  If the last_msg_time for this client is 0, or if the
          last_msg_time is less than the server's clock- reset_interval,

how can i time value be compared to a time interval?  do you mean "if the
time since the last message is longer than the interval?"

          then the last_msg_ref for this client is set to the msg_ref
          value in this message, and the message is accepted for
          processing.

same attack as in previous.

--

        - The server then checks for out-of-order and duplicate messages.
          If the msg_ref value is less than or equal to the last_msg_ref
          for this client, then the message is rejected with an "incorrect
          msg_ref" code, and the server's value for last_msg_ref is placed
          in the last_msg_processed attribute of the error response.

i do not see why the parent wants or needs to tell the child what the
server expected as a sequence number.  are we doing a reliable protocol
on top of tcp and requesting a resend?

if i was a client, and my parent told me she received an out of sequence
message, i think i would want to disconnect whone or start again with
what i intended, the next request after the one to which the parent gave
me a positive response.

--

it's late here.  so i will spare the payload part of the song for the
moment.

randy