This section was changed based on comments from Pekka and yourself. Note that
(BI'm referring to the section as a whole and not only the first paragraph. I 
(Bdon't remember
(Bthe intent of changing every line since I changed the whole section in rev 2. 
(BBut 
(Bthe main reason for the change was clarifications and no substantial change was 
(Bmade.
(B
(BThe current text, I believe (please correct me if I'm wrong) conveyed the same 
(Bmessage as the previous section in 2461. It seems that one of the sources 
(Bof the confusion is that you're assuming the "two things" text must refer to
(Bthe same thing in 2461bis as it did in 2461. That's not the case of course. 
(B
(BSo to avoid meddling with text unnecessarily, I would ask you to tell me 
(Bif this section (in 2461bis) does anything differently to implementations from 
(Bthe same section in 2461. If that's the case, please let us know and I'll fix 
(Bit. 
(BOr, if the text is not clear, I'm happy to fix it. But the only lack of clarity 
(Byou 
(Bpoint to below is a result of comparing ordering of text in the current 
(Brevision with
(Bthe corresponding one in 2461. It doesn't need to be the same thing (as you 
(Bpoint out below) as long as 
(Bthe result is the same for implementations. 
(B
(BIn any case, if there is anything to be done, I think we should add that to the 
(BIESG
(Bcomments. I'm sure they'll require changes to text. 
(B
(BHesham
(B
(B > But, in case I was not clear enough, the point is that the relevant
(B > change from RFC2461 to rfc2461bis makes the text rather unreadable.
(B > So, I'd first like to know the intent of the change.
(B > 
(B > One specific point at the moment: Section 7.2.5 of
(B > draft-ietf-ipv6-2461bis-03.txt reads:
(B > 
(B >    If the target's Neighbor Cache entry is in the INCOMPLETE 
(B > state when
(B >    the advertisement is received, one of two things happen: If the
(B >    advertisement were solicited, the state is changed to REACHABLE.
(B >    Otherwise, the state is set to STALE. Note that the 
(B > Override flag is
(B >    ignored if the entry is in the
(B >    INCOMPLETE state.
(B > 
(B > From this paragraph, the "two things" would be:
(B > 
(B >   1. If the advertisement were solicited, the state is changed to
(B >      REACHABLE.
(B >   2. Otherwise, the state is set to STALE.
(B > 
(B > On the other hand, the corresponding part of RFC2461 was:
(B > 
(B >    If the target's Neighbor Cache entry is in the INCOMPLETE 
(B > state when
(B >    the advertisement is received, one of two things happens.  If the
(B >    link layer has addresses and no Target Link-Layer address 
(B > option is
(B >    included, the receiving node SHOULD silently discard the received
(B >    advertisement.  Otherwise, the receiving node performs 
(B > the following
(B >    steps:
(B >        (....)
(B > 
(B > From this paragraph, the "two things" would be:
(B > 
(B >   1. If the link layer has addresses and no Target Link-Layer address
(B >      option is included, the receiving node SHOULD silently discard
(B >      the received advertisement.
(B >   2. Otherwise, the receiving node performs the following steps:
(B >        (....)
(B > 
(B > So, while the beginning part is exactly the same, the "two things"
(B > seem to refer to completely different things.
(B > 
(B > The difference itself is not necessarily a problem.  However,
(B > rfc2461bis-03 then repeats its "two things":
(B > 
(B >     - If the advertisement's Solicited flag is set, the state of the
(B >       entry is set to REACHABLE, otherwise it is set to STALE.
(B > 
(B > Now this make me really confused...
(B > 
(B > Additionally, the relationship between the two parts beginning with
(B > "If the (target's) Neighbor Cache entry is in the INCOMPLETE 
(B > state" is
(B > not very clear to me:
(B > 
(B >    If the target's Neighbor Cache entry is in the INCOMPLETE 
(B > state when
(B >    the advertisement is received, one of two things happen: (...)
(B > 
(B >    If the Neighbor Cache entry is in INCOMPLETE state, the receiving
(B >    node performs the following steps:
(B >       (...)
(B > 
(B > Note that the second part was one of the "two things" in original
(B > RFC2461.
(B > 
(B > All of these things just confused me about what this part wanted to
(B > convey.
(B > 
(B > So, again, I'd first like to know the intent of the change, and then
(B > I'm willing to suggest explicit text according to the intent.
(B > 
(B > I hope this time I'm clear enough.  Thanks,
(B > 
(B >                                      JINMEI, Tatuya
(B >                                      Communication Platform Lab.
(B >                                      Corporate R&D Center, 
(B > Toshiba Corp.
(B >                                      [EMAIL PROTECTED]
(B > 
(B
(B===========================================================
(BThis email may contain confidential and privileged material for the sole use
(B of the intended recipient.  Any review or distribution by others is strictly
(B prohibited.  If you are not the intended recipient please contact the sender
(B and delete all copies.
(B===========================================================
(B
(B
(B--------------------------------------------------------------------
(BIETF IPv6 working group mailing list
([email protected]
(BAdministrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
(B--------------------------------------------------------------------

Reply via email to