Re: #D101: design draft issue: editorial

Tero Kivinen wrote:

>  
>
>>>      This definition is taken from [I-D.arkko-multi6dt-failure-
>>>      detection], and adapted to the MOBIKE context (we do allow
>>>      [RFC1918] addresses here, they are very common addresses used
>>>      inside NATs).
>>>      
>>>
>>Just add a plain reference, not explain the differences, since the
>>differences keep changing as the SHIM6 work proceeds. Also, the
>>reference is I-D.ietf-shim6-failure-detection.
>>    
>>
>
>I was wondering that if someone who is very familiar with the shim6
>work would not notice that we are using different definition here, so
>we should point out the differences, but if the terms defined there
>are not well defined yet, then better remove the differences part.
>  
>
Right. Yes, remove the differences.

>>Similar for the other definitions.
>>    
>>
>
>I do not think there was differences in other terms, but fixed the
>references. 
>  
>
Ok.

>>"mainly"?
>>    
>>
>
>There used to be some more text about transport mode here, but now we
>only say that there will be future ducouments, so removed "mainly"
>  
>
Ok.

>>And there's some duplication with end of Section 3. Suggest: merge
>>the paragraphs and place them in Section 4.
>>    
>>
>
>Can you give more exact editing instructions, so I can do the changes.
>  
>
Looks OK now, not sure if you already edited this or not,
but I don't remember the context anymore.

>>>   MOBIKE
>>>   does not support unidirectional address pairs (i.e. where you can
>>>   only send traffic in one direction when using single address pair).
>>>      
>>>
>>No need to redefine the term here. Just end after the word "pairs".
>>    
>>
>
>Removed the definition. This used to be the only place earlier, but
>forgot to remove this when added the definition to the terminology
>section. 
>  
>
Ok.

>>>   There are some cases which cannot be carried out within the
>>>   restrictions of the MOBIKE charter. 
>>>      
>>>
>>To avoid talking about the charter, just say "... within MOBIKE".
>>    
>>
>
>Hmm.... Then reader might be wondering why we cannot do that. Protocol
>might be able to be designed to support those cases, but they are out
>of scope of the charter, thus we cannot do them with MOBIKE.
>
>Anyways removed the text about charter restrictions. 
>  
>
Ok. (You could also say that it was decided that those
issues were not in the scope of the MOBIKE protocol
version 1.)

>>(Its better style to not use "we", I think. Go through the rest of
>>the document, too, there are multiple occurrences. Such as in the
>>next paragraph.)
>>    
>>
>
>There is way too many occurrences that I do not want to start fixing
>them all now. Actually I myself find it sometimes easier to read text
>that uses "we" than text written to avoid using "we". 
>  
>
Ok, nevermind...

>>>   The working group decided that MOBIKE uses NAT-T mechanisms from the
>>>   IKEv2 protocol as much as possible, but decided to change the dynamic
>>>   address update for IKEv2 packets to MUST NOT (it would break path
>>>   testing using IKEv2 packets, see Section 6.2).  The working group
>>>   also decided to only send keepalives to the current address pair.
>>>      
>>>
>>Dynamic address update for IPsec packets? I'm unsure what you mean
>>here. In any case, pointing to the actual requirement in IKEv2 spec
>>would be useful here.
>>    
>>
>
>RFC 4306, section 2.23 second last paragraph. It is little bit hard to
>put exact references to the section 2.23 as it is several pages long
>and this text refers to the one paragraph in there.
>  
>
You just did it :-)

>>>   From a technical point of view this feature addresses two issues:
>>>
>>>   o  There is no need to transmit IPsec data traffic.  IPsec protected
>>>      data can be dropped which saves bandwidth.  This does not provide
>>>      a functional benefit, i.e., nothing breaks if this feature is not
>>>      provided.
>>>
>>>   o  MOBIKE signaling messages are also ignored.  The IKE-SA must not
>>>      be deleted and the suspend functionality (realized with the zero
>>>      address set) may require the IKE-SA to be tagged with a lifetime
>>>      value since the IKE-SA should not be kept alive for an undefined
>>>      period of time.  Note that IKEv2 does not require that the IKE-SA
>>>      has a lifetime associated with it.  In order to prevent the IKE-SA
>>>      from being deleted the dead-peer detection mechanism needs to be
>>>      suspended as well.
>>>      
>>>
>>... this feature raises two issues?
>>    
>>
>
>As zero address set functionality would be solving those two issues, I
>would say it addresses those issues, not raises them. They are already
>present in the current protocol, and we do not propose any solution
>for them now. I.e the issues is that we waste bandwidth by sending
>data which will be ignored by the other end, and we tear down the IKE
>SA because the other end cannot reply to our signaling packets.
>
>Perhaps better way woud be to say "From a technical point of view this
>would provide following two features:"?
>  
>
Ok.

--Jari