Re: [DNA] Updates to dna-protocol3

[Sathya Narayanan <sathya@research.panasonic.com>]

Brett -

I sent the following email to you last week (02/08). I don't know if you
received it. Please see below.

thanks,
Sathya
--------------------------------------------------------------------------------------------------------

Brett -

Atlast, I got to look at the DNA soln. draft. I have the following
questions/comments:

Comment 1)
The solicited router advertisement case as is written now seems to me as
follows as:

- SHOULD do completeRA (MUST include LindID even if complete RA is not
possible due to length of the packet).
- MAY do landmark response if the RS contains landmark question
{
              - LinkID is not needed for "Y" response
              - LinkID MUST be present in "N" response with as many of
the prefixes as possible (if all prefixes included then set the Complete
bit).
}

Is this the intended recommendation?

My understanding was,

If landmark question in RS
{
   SHOULD Send landmark response
             - LinkID is not needed for "Y" response
             - LinkID MUST be present in "N" response with as many of
the prefixes as possible (if all prefixes included then set the Complete
bit).
}
else
   SHOULD do completeRA (MUST include LinkID even if complete RA is not
possible due to length of the packet).

Am I missing something? (or starting the debate all over again? - my
apologies if I am  :-)  ). I can do the changes if necessary.

Comment 2)
I think it makes sense to change the terminology from 'LinkID prefix' to
just 'LinkID' in the text to keep it clean in terms of future
compatibility as discussed in 5.1.7.1.1.
Section 5.1.7 can be LinkID and the text will describe how a prefix
should be selected as the LinkID. I think this will reduce any confusions.

Comment 3)
For host operations,
Section 5.2.5: Processing Router Advertisments
The conditions should be classified into two subsets, one if the 'F' bit
is set and another if the 'F' bit is not set.

The last condition starting "If the received RA is not complete,
contains no prefixes ..." should be replaced with just the condition "If
the 'F' bit is not set" and the all the other conditions before are
under "If the 'F' bit is set".

Comment 4)
Minor changes:

Section 4.1: s/flag bit/bit

I couldn't understand section 5.1.10 (this is not so minor  :-)  )

Section 5.2.5.1: has few lower case shoulds, may be they MUST be changed
to SHOULDs.

I can do the changes if you ok them.

thanks,
Sathya


> Before submitting the draft to become draft-ietf-dna-protocol-00.txt I
> have some updates to reflect the feedback that we've had so far.  The
> update can be viewed at:
>
> http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00.txt
>
> And a diff from protocol3 can be seen at:
>
> http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00-from-draft-pentland-dna-protocol3-00.diff.html
>
>
> Does anyone have any objections to the amendments made so far?  Do they
> break anything?  Positive ACKs are ok too. :)
>
> There's a few issues that have come up while making the edits.  They
> don't necessarily have to be resolved before submission of the -00, but
> some input would be useful.
>
> - Should the explicit linkid always be in the LPO or can it be a flag in
>   a PIO (the latter is in the draft)?
>
> - What order do the hosts treat the indications (land mark option,
>   prefixes, linkid in the draft at present)
>
> - Given that we now have an explicit linkid, should we get rid of all of
>   the flags in the landmark option - the no flag is not really needed
>   and since taking that out would leave only one, we can probably get
>   rid of that as well - LO in RA = yes (at present the flags are still
>   there)
>
> Regards,
> Brett.