Subject: Re: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re: Finishing RFC 3775bis

From: <[email-masked]>
Date: Fri, 1 Oct 2010 13:00:22 +0200

Hi Charlie,

... and I MAY have detected further very minor nits like

P.21
"Home Address Destination option" => "Home Address destination option" 
P.22
"the Binding Updates messages" => "the Binding Update messages"
P.66 
"is the first Prefix Length bits" => "is given by the first Prefix Length bits"
P.106
"Mobile Prefix
   Advertisements messages" => "Mobile Prefix
   Advertisement messages"

... and finally beside 50 something times spelling "Binding Cache entry" we also have still 8 times "binding cache entry" within the document - IMHO this should be harmonized ;-) 

Otherwise it's fine with me - thanks!

Best regards

Dirk  

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Laganier, Julien
Gesendet: Freitag, 1. Oktober 2010 00:56
An: Charles E. Perkins; [email-masked]
Cc: [email-masked]
Betreff: Re: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re: Finishing RFC 3775bis

Hello Charlie,

Charles E. Perkins wrote:
> 
> Hello again folks,
> 
> I made a slight boo-boo in my previous message
> about finishing rfc3775bis.  Namely...
> 
> On 9/27/2010 4:44 PM, Charles E. Perkins wrote:
> 
> > #18 Subject: Issues regarding Home Address Option & ICMP /
> > Binding errors
> > [Fabian Mauchle]
> ...
> > Proposal: To avoid spoofing, add to the first paragraph in
> > 11.3.6: If the source of the ICMP error message is a Home
> > Agent, it MUST be ignored.
> 
> It was decided not to incorporate this proposal, after all.
> 
> I have made the next revision of rfc3775bis:
>   www.psg.com/~charliep/txt/ietf79/draft-ietf-mext-rfc3775bis-07.txt
> 
> I expect to submit it very soon unless there is some
> gross error somewhere.

Thanks, I've only found two nits that you might want to fix before submitting:

1. "A more detailed list of the changes since RFC 3775 may be found in (see Appendix A)" => "A more detailed list of the changes since RFC 3775 may be found in Appendix A."

2. I'd personally prefer to have the changes in the last Appendix, so B instead of A.

--julien

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 01 Oct 2010 10:36:43 -0700

Hello Julien,

> 2. I'd personally prefer to have the changes in the last Appendix, so B instead of A.

Done!

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 01 Oct 2010 11:38:48 -0700

Hello Dirk,

Thanks for your observant review!

On 10/1/2010 4:00 AM, [email-masked] wrote:
> ... and finally beside 50 something times spelling "Binding Cache entry" we also
> have still 8 times "binding cache entry" within the document - IMHO this should
> be harmonized ;-)

Done!  ... although I won't absolutely guarantee all
instances of the latter...

I also fixed "binding update" to be "Binding Update".

I put the revised document again at the following URL:
   www.psg.com/~charliep/txt/ietf79/draft-ietf-mext-rfc3775bis-07.txt

Regards,
Charlie P.

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 1 Oct 2010 13:33:36 -0700

Thanks Charlie, I think you can post the revised version and I will follow up with requesting publication.

--julien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Charles E. Perkins
> Sent: Friday, October 01, 2010 11:39 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re:
> Finishing RFC 3775bis
> 
> 
> Hello Dirk,
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 6 Oct 2010 15:41:35 -0400

Hi Charlie,
   I am happy with the resolution for issue #13 and I think the document 
is ready to go forward on the publication process.

Thanks
Suresh

On 10-09-27 07:44 PM, Charles E. Perkins wrote:
> Hello folks,
> 
> One of the new requirements for rfc3775bis is a section
> detailing the changes from RFC 3775.  Here's what I wrote
> up.  If I forgot one, please remind me and I will
> add it.  It's quite painful to go through rfcdiff, yow.
> The numbers are the issue numbers from:
> 	http://trac.tools.ietf.org/wg/mext/trac/report/6
> 
> ===========================================================
> 
> #1 	Last Accepted SQN [Ahmad Muhanna] 	
> 
> 	Solution: specify that the mobile node update its binding
> 	sequence number to match the sequence number given in the
> 	Binding Acknowledgement (if the Binding Acknowledgement
> 	correctly passes authentication and the status is 135
> 	(Sequence Number out of window).
> 
> 
> #4 	Remove references to site-local addresses [George Tsirtsis] 	
> 
> 	fixed.
> 
> #5 	Wrong protocol number used in discussion about checksum
> 		pseudo-header: 	
> 
> 	fixed.
> 
> #8 	Application using the care-of address [Julien Laganier]
> 
> 	Cite IPv6 Socket API for Source Address Selection [RFC5014].
> 
> #10 	The usage of "HA lifetime" [Ryuji Wakikawa] 	
> 
> 	The mobile node SHOULD store the list of home agents for later
> 	use in case the home agent currently managing the mobile node's
> 	care-of address forwarding should become unavailable.
> 
> #11 	De-registration when returning home [Vijay Devarapalli] 	
> 
> 	To be able to send and receive packets using its home address
> 	from the home link, the mobile node MUST send a Binding Update to
> 	its home agent to instruct its home agent to no longer intercept
> 	or tunnel packets for it. Until the mobile node sends such a
> 	de-registration Binding Update, it MUST NOT attempt to send and
> 	receive packets using its home address from the home link.
> 
> 
> #12 	BErr sent by HA too, not only by CN [Alexandru Petrescu]
> 
> 	Fixed.
>   	
> #13 	Home Link Detection [Suresh Krishnan] 	
> 
> 	Proposal: add new section [11.5.2] for Home Link Detection,
> 	drawing on Internet Draft draft-krishnan-mext-hld.
> 
> #14 	References to Bootstrapping [Vijay Devarapalli] 	
> 
> 	Cited "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026
> 
> #17 	Multi-homed mobile node can cause routing loop between
> 		home agents [Benjamin Lim]
> 
> 	Added advisory security considerations in section 15.1, to
> 	highlight risk of routing loop among HAs (e.g., in 3GPP):
> 
> 	A malicious mobile node associated to multiple home agents
> 	could create a routing loop amongst them. This would happen
> 	when a mobile node binds one home address located on a first
> 	home agent to another home address on a second home agent.
> 
> 	Proposal: Use the value in the Next Header field {50 (ESP),
> 	51 (AH), 135 (Mobility Header)} to determine, if a Binding
> 	Cache entry is required.
> 
> 	Proposal: If the Binding Error Message was sent by the Home
> 	Agent, the Mobile Node SHOULD send a Binding Update to the
> 	Home Agent according to Section 11.7.1.
> 	
> 
> #19 	BU de-registration race condition [Kilian Weniger] 	
> 
> 	Problem arises if de-registration arrives at Home Agent
> 	before an immediately preceding Binding Update.
> 
> 	Solution: Home Agent defers BCE removal after sending
> 	the Binding Acknowledgement.
> 
> #6 	Minor editorial corrections and updates 	
> 
> NOT done:
> #3 	BRR, BErr are sent by HA too, not only by CN
> 					[Alexandru Petrescu] 	
> #7 	DSMIPv6 BU format and RFC 3775 [Tero Kauppinen] 	
> #9 	Simultaneous Mobility [Ashutosh Dutta] 	
> #15 	BRR sent by HA too, not only by CN [Ahmad Muhanna] 	
> #16 	HA behaviour upon MN returning Home [Pascal Thubert] 	
> 
> 
> ===========================================================
> 
> Regards,
> Charlie P.

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 6 Oct 2010 13:19:54 -0700

Just for clarification: We will request to IESG publication of the next version of the document that fixes remaining IDnits. 

--julien

> Suresh Krishnan
> Sent: Wednesday, October 06, 2010 12:42 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MEXT] Finishing RFC 3775bis
> 
> Hi Charlie,