Subject: RE: [MIPSHOP-MIH-DT] technical stuff - how to begin the work

From: Srinivas Sreemanthula <[email-masked]>
Date: Thu, 22 Feb 2007 09:31:55 +0200 (EET)

hello Stefano,
We are yet to start on this work. IMO. it is too late for us to deliberate and produce the result as a first draft before 26th. But I believe we can still do meannigful work before march meeting and report to the wg. But this will just have to be in a ppt form (not as an ID). We could make the ID soon after. Do you think this is a reasonable way forward?  Another approach would be reevaluate existing design-considerations draft and update it with another week's time. It would be good to get other's opinion on this.
This is, BTW, not to slow down any technical discussion. but only to make it faster.

Regards,
Srini

> -----Original Message-----
> From: ext Stefano Faccin
> Received: Thu Feb 22 01:17:27 EET 2007
> To: Hancock, Robert, Telemaco Melia, Zuniga, Juan Carlos
> Cc: [email-masked]
> Subject: RE: [MIPSHOP-MIH-DT] technical stuff - how to begin the work
> 
> Hi guys,
> 
> I am concerned about the progress in this area. I strongly encourage you
> to "sit down" and start the work. May I suggest that somebody takes a
> stab at it, to create a starting point? You seem to be at an impasse
> here. And just 6 days to go.
> 
>  
> 
> Stefano
> 
> P.S. I apologize for being off the list for a while (issues with my
> e-mail address). 
> 
>  
> 
> ________________________________
> 
> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Wednesday, February 21, 2007 1:47 AM
> To: Telemaco Melia; Zuniga, Juan Carlos
> Cc: [email-masked]
> Subject: RE: [MIPSHOP-MIH-DT] technical stuff - how to begin the work
> 
>  
> 
> hi tele, juan,
> 
>  
> 
> I would certainly be happy to do an update to the design considerations
> draft (I can certainly get all the current authors to transfer
> responsibility for it to the design team, and it gives us an extra
> week).
> 
>  
> 
> the question is, what are the technical opinions of the design team on
> the content of that draft. it's very easy for me to express my opinion:
> I agree with all of it. If the rest of the design team agrees with all
> of it, then that would be significant progress, but I've been trying to
> be careful not to impose that view on other people. If there are bits
> which other people in the design team don't agree with, then I need them
> to speak up and say which bits and where the disagreements would be - I
> can't guess this myself. maybe people with input could start a mail
> thread on each issue? (I can always set up a tracker in the future, but
> at the moment it doesn't seem necessary.)
> 
>  
> 
> cheers,
> 
>  
> 
> robert h. 
> 
> ________________________________
> 
> From: Telemaco Melia [mailto:[email-masked]] 
> Sent: 20 February 2007 12:10
> To: Zuniga, Juan Carlos
> Cc: [email-masked]
> Subject: Re: [MIPSHOP-MIH-DT] technical stuff - how to begin the work
> 
> 	Hi all,
> 	
> 	Any chance to advance the proposed design considerations draft
> (maybe a reduced version) and write up a first doc?
> 	
> 	Cheers
> 	Telemaco
> 	
> 	Zuniga, Juan Carlos wrote: 
> 
> 	Robert,
> 	 
> 	Srini's approach makes a lot of sense to move forward, but time
> keeps
> 	running and we only have 2 weeks before the Feb 26th deadline. 
> 	 
> 	- Could you let the DT know if you agree, and what do you expect
> to
> 	produce and report to the WG?
> 	 
> 	Regards,
> 	 
> 	Juan Carlos
> 	 
> 	-----Original Message-----
> 	From: Subir Das [mailto:[email-masked]] 
> 	Sent: February 8, 2007 11:47 AM
> 	To: [email-masked]
> 	Cc: [email-masked]
> 	Subject: Re: [MIPSHOP-MIH-DT] technical stuff - how to begin the
> work
> 	 
> 	I agree with this approach.
> 	 
> 	Robert: Are you planning to put them in a doc and circulate this
> 	quickly?
> 	 
> 	regards,
> 	-Subir
> 	 
> 	[email-masked] wrote:
> 	  
> 
> 		Hello all,
> 		Let's proceed over emails to make some progress. Before
> we jump into
> 		serious technical discussions it would be good to make a
> ppt of the
> 		    
> 
> 	work
> 	  
> 
> 		scope, expectation from the team and how and when the
> results are made
> 		open. There also have been some emails on these aspects
> on the mailing
> 		list. 
> 		 
> 		Some points to capture:
> 		O. Write down what, how and when aspects of the DT work
> 		o. Publish the results for review by MIPSHOP and 802.21.
> e.g. write a
> 		new draft or update the existing one (better to announce
> it now ) 
> 		O. deadline to remember is Feb 26th for 00 version.
> 		o. Periodically announce the work progress on the
> mailing list
> 		(Qiaobing's request)
> 		 
> 		Robert, can we take some time and summarize these? You
> may have
> 		    
> 
> 	already
> 	  
> 
> 		captured it in various emails, just put in ppt and a
> timeline.
> 		 
> 		 
> 		Regards,
> 		Srini
> 		 
> 		 
> 		-----Original Message-----
> 		From: ext Sam Xia [mailto:[email-masked]] 
> 		Sent: Thursday, February 01, 2007 1:23 AM
> 		To: 'Robert Hancock'; Sreemanthula Srinivas
> (Nokia-SIR/Dallas);
> 		[email-masked];
> [email-masked];
> 		[email-masked]
> 		Cc: [email-masked]
> 		Subject: RE: [MIPSHOP-MIH-DT] technical stuff - how to
> begin the work
> 		 
> 		Hi, all,
> 		  I think that it is good for us to determine more
> specific
> 		    
> 
> 	discusssing
> 	  
> 
> 		items before teleconference. If not, I don't see that it
> will be an
> 		efficient meeting. So I do agree with what Robert said.
> 		 
> 		 Best Regards, Sam Xia 
> 		 
> 		  
> 		    
> 
> 			-----Original Message-----
> 			From: Robert Hancock
> [mailto:[email-masked]]
> 			Sent: Thursday, February 01, 2007 2:16 AM
> 			To: [email-masked];
> 			[email-masked];
> 			[email-masked];
> [email-masked]
> 			Cc: [email-masked]
> 			Subject: RE: [MIPSHOP-MIH-DT] technical stuff -
> how to begin the work
> 			 
> 			hi all,
> 			 
> 			while i appreciate the attraction of a phone
> conference (at least for
> 			      
> 
> 	 
> 	  
> 
> 			some), please bear in mind that AFAIK we have
> people in the DT from 
> 			US, Europe and Far East. So fair scheduling is
> pretty tricky. For
> 			      
> 
> 	that
> 	  
> 
> 			    
> 			      
> 
> 		  
> 		    
> 
> 			reason, I would really like people to comment on
> the technical
> 			      
> 
> 	aspects
> 	  
> 
> 			    
> 			      
> 
> 		  
> 		    
> 
> 			of the original email (as well as the
> organisation of how to discuss 
> 			them).
> 			 
> 			r. 
> 			 
> 			    
> 			      
> 
> 				-----Original Message-----
> 				From: [email-masked] 
> 				[mailto:[email-masked]]
> 				Sent: 31 January 2007 17:24
> 				To: [email-masked];
> 				[email-masked];
> [email-masked]
> 				Cc: [email-masked]
> 				Subject: RE: [MIPSHOP-MIH-DT] technical
> stuff - how to
> 				      
> 				        
> 
> 			begin the work
> 			    
> 			      
> 
> 				Me too.
> 				 
> 				Regards,
> 				Srini
> 				 
> 				-----Original Message-----
> 				From: ext Zuniga, Juan Carlos
> 	
> [mailto:[email-masked]]
> 				Sent: Wednesday, January 31, 2007 9:15
> AM
> 				To: Subir Das; Telemaco Melia
> 				Cc: [email-masked]
> 				Subject: RE: [MIPSHOP-MIH-DT] technical
> stuff - how to
> 				      
> 				        
> 
> 			begin the work
> 			    
> 			      
> 
> 				I'm also fine with the rest of this
> week, or Monday next week.
> 				 
> 				Regards,
> 				 
> 				Juan Carlos
> 				 
> 				 
> 				-----Original Message-----
> 				From: Subir Das
> [mailto:[email-masked]]
> 				Sent: January 30, 2007 5:12 PM
> 				To: Telemaco Melia
> 				Cc: [email-masked]
> 				Subject: Re: [MIPSHOP-MIH-DT] technical
> stuff - how to
> 				      
> 				        
> 
> 			begin the work
> 			    
> 			      
> 
> 				 I am fine with any time in the morning,
> EST (US)  rest of
> 				      
> 				        
> 
> 			this week.
> 			    
> 			      
> 
> 				Thanks,
> 				-Subir
> 				 
> 				Telemaco Melia wrote:
> 				      
> 				        
> 
> 				Hi all,
> 				 
> 				I support Robert's suggestion about
> splitting the work. 
> 				What about an AC next week (e.g. Monday,
> Wednesday)?
> 				Comments?
> 				 
> 				Cheers,
> 				Telemaco
> 				 
> 				 
> 				-----Original Message-----
> 				From: Robert Hancock
> [mailto:[email-masked]]
> 				Sent: Wednesday, January 24, 2007 4:36
> PM
> 				To: [email-masked]
> 				Subject: [MIPSHOP-MIH-DT] technical
> stuff - how to begin the work
> 				 
> 				Hi,
> 				 
> 				We now have the question how to begin
> the work on a solution.
> 				 
> 				One thing i want to avoid is starting
> off with a 'who likes what
> 				        
> 				          
> 
> 				solution'
> 				      
> 				        
> 
> 				discussion. My perception is that once
> we all have a
> 				        
> 				          
> 
> 			common view on
> 			    
> 			      
> 
> 				the problem, choosing a solution will
> actually be the
> 				      
> 				        
> 
> 			simpler part of
> 			    
> 			      
> 
> 				the problem.
> 				      
> 				        
> 
> 				>From that point of view, I'd rather
> have a higher level
> 				        
> 				          
> 
> 			discussion
> 			    
> 			      
> 
> 				  
> 				        
> 				          
> 
> 				about the
> 				    
> 				          
> 				            
> 
> 				issues which a solution has to take
> account of. For that, we
> 				        
> 				          
> 
> 				previously wrote the design
> considerations draft (still at 
> 	
> http://tools.ietf.org/wg/mipshop/draft-hepworth-mipshop-mih-de
> 				sign-consi
> 				dera
> 				      
> 				        
> 
> 				tions-01.txt) which I humbly claim at
> least provides a set
> 				        
> 				          
> 
> 				of headings
> 				for the things that we have to worry
> about. Please note:
> 				      
> 				        
> 
> 				- I'm not claiming that people have to
> agree that the
> 				        
> 				          
> 
> 				analysis in that
> 				draft is correct. That is what we are
> discussing. I am
> 				      
> 				        
> 
> 			claiming that
> 			    
> 			      
> 
> 				the list of issues is pretty good.
> 				      
> 				        
> 
> 				- I'm not even claiming that we have to
> construct an
> 				        
> 				          
> 
> 			update to this
> 			    
> 			      
> 
> 				draft or follow its structure; but it
> would be nice to capture the 
> 				conclusions of our discussions in some
> way.
> 				      
> 				        
> 
> 				Please can people say what they think
> about this approach. We can
> 				        
> 				          
> 
> 				split up the small problems (1 each or
> so) and argue out
> 				      
> 				        
> 
> 			any issues on
> 			    
> 			      
> 
> 				this list.
> 				      
> 				        
> 
> 				I think there are a few bigger issues
> for which we could
> 				        
> 				          
> 
> 				form smaller
> 				groups to look at things. They are
> either harder, or require closer 
> 				work with the details of the .21
> standard:
> 				      
> 				        
> 
> 				- one is discovery. here, there just
> seem to be too many different
> 				        
> 				          
> 
> 				options, and we have to think about the
> tradeoff between 
> 				allowing/supporting many and being able
> to enforce a universal one
> 				      
> 				        
> 
> 				- another is security. we need to have a
> view on what security
> 				        
> 				          
> 
> 				services the MIH transport actually
> needs (who
> 				      
> 				        
> 
> 			authenticates who, what
> 			    
> 			      
> 
> 				identity infrastructures that
> authentication might be based on)
> 				      
> 				        
> 
> 				- another is the transport/application
> service interface. 
> 				        
> 				          
> 
> 				.21 is going
> 				through various versions of this, which
> it would be ideal to align 
> 				with what we actually propose.
> 				      
> 				        
> 
> 				What would be nice now is if people can
> say what they think
> 				        
> 				          
> 
> 				about this
> 				as an approach for the work; and, if
> they approve of the approach, 
> 				what parts of the analysis they would
> feel happy to take
> 				      
> 				        
> 
> 			the lead on
> 			    
> 			      
> 
> 				or take part in.
> 				      
> 				        
> 
> 				cheers,
> 				 
> 				robert h.
> 				 
> 				 
> 	
> _______________________________________________
> 				MIPSHOP-MIH-DT mailing list
> 				[email-masked]
> 	
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> 				 
> 	
> _______________________________________________
> 				MIPSHOP-MIH-DT mailing list
> 				[email-masked]
> 	
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> 				  
> 				        
> 				          
> 
> 	
> _______________________________________________
> 				MIPSHOP-MIH-DT mailing list
> 				[email-masked]
> 	
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> 				 
> 	
> _______________________________________________
> 				MIPSHOP-MIH-DT mailing list
> 				[email-masked]
> 	
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> 				 
> 	
> _______________________________________________
> 				MIPSHOP-MIH-DT mailing list
> 				[email-masked]
> 	
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> 				 
> 				      
> 				        
> 
> 			_______________________________________________
> 			MIPSHOP-MIH-DT mailing list
> 			[email-masked]
> 	
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> 			 
> 			    
> 			      
> 
> 		 
> 		_______________________________________________
> 		MIPSHOP-MIH-DT mailing list
> 		[email-masked]
> 		https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> 		  
> 		    
> 
> 	 
> 	_______________________________________________
> 	MIPSHOP-MIH-DT mailing list
> 	[email-masked]
> 	https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> 	 
> 	_______________________________________________
> 	MIPSHOP-MIH-DT mailing list
> 	[email-masked]
> 	https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> 	  
> 
> 	
> 	
> 	
> 	
> 
> 	-- 
> 	Telemaco Melia               [email-masked]
> 	Research Staff Member               Tel: +49 (0) 6221 4342- 142
> 	Network Laboratories         Fax: +49 (0) 6221 4342- 155
> 	NEC Europe Ltd.              Web: http://www.netlab.nec.de
> 	Network Laboratories           
> 	Kurfuersten-Anlage 36       
> 	69115 Heidelberg
> 	GERMANY   
> 	 
> 	 
> 	NEC Europe Limited | Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL | Registered in England 2832014 
> 
> 
> 
> 

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 22 Feb 2007 11:26:24 -0000

dear all,

here is a suggestion for what to do.

- I still think we need a consensus in the DT about what problem we are
solving and what issues we have to take into account in solving it
before getting into protocol work

- I believe we have agreement that the design considerations (DC) draft
is a good list of issues (at least, some people have said yes and no-one
has objected to that)

therefore I propose the following:

- everybody has until 27th feb 9AM GMT (a.k.a. 17 hours after the -00
cutoff) to provide comments on the DC draft. no comment = either 
(a) you are happy with the content, or 
(b) you trust the expertise of the others in the DT to get it right. 
that process can start discussions on this list if people want, but the
main thing is to get people's views into the open.

- i then get tuesday to pull it all together in my head and make a
proposal, which would be either
(a) we rev the DC draft as a design team output with me as editor, and
for each issue having either agreed text or a statement about what is
open; we can do this for the -0n cutoff, OR
(b) we take the discussion and make a brief summary for the mipshop m.l.
and presentation for the meeting

[nothing prevents us doing both, of course]

- either way, we continue to work on any issues up to the meeting start.

views?

robert h.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 23 Feb 2007 18:06:02 -0500

Robert,

We definitely have to agree on the general work scope and tenets for the
DT before digging into more technical discussions. That's why I thought
that Srini's proposal of 3 weeks ago made a lot of sense. 

IMHO, there is not much technical work that we can accomplish before the
deadline, but a presentation of the work plan is definitely something
meaningful and achievable. This pretty much matches your second (b)
proposal of taking the discussion and making a brief summary for the
MIPSHOP and presentation for the meeting, where we could show the DT
work plan and get feedback from the Working Group.

Of course, nothing stops us from starting the technical discussions now.
However, with a common understanding about the DT goals, we can then
proceed to having more detailed technical discussions and move much
faster this time. 

For instance: I believe that a major agreement that we should have is
that we must not create redundant functionalities from the ones already
defined in 802.21. The 802.21 group just met this week in Santa Clara,
CA and we were discussing solutions to a lot of issues that are
described in the current Design Considerations document and there is no
need for MIPSHOP to reinvent the wheel. 

Do we all agree in the DT? In the WG? Are there any other major
agreements people believe we should have?

I think that if we showed a work plan to the WG it would be very useful.
These are some of the points that should be covered:

- What

	- Provide a solution to the MIH information transport and
discovery over L3 that suits the needs and complements the existing MIH
functionalities defined in IEEE 802.21
	- Other tenets?

- How

	- Producing a Design Considerations document (Optional)
	- Producing a Draft solution

- When

	- First document (internal to DT / external to all WG) - date?
	- Second document (if any) (internal to DT / external to all WG)
- date?
	- Third document ...

This is my view, but it would be helpful to have everybody's views on
this.

Also, just want to let all know that due to the slow progress in the DT,
we have been working on a new revision of our proposal, which we are
planning to submit soon.

Regards,

Juan Carlos

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]] 
Sent: February 22, 2007 6:26 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] A modest proposal

dear all,

views?

robert h.

---

From: Telemaco Melia <[email-masked]>
Date: Mon, 26 Feb 2007 11:56:46 +0100

Juan, all,

A couple of comments.
First of all it would be nice to have a short summary of the issues 
discussed in Santa Clara.
Second taking into account the above and the initial splitting Robert 
provided,
we should compile a first list of what is in scope and what is not. The 
presentation could help in defining the
TOC for the new document while providing a good overview to WG.

Comments?

regards,
telemaco

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Subir Das <[email-masked]>
Date: Mon, 26 Feb 2007 11:12:50 -0500

Hi Robert,
Sorry for my late response. Answers inline.

Thanks,
-Subir

> before getting into protocol work 
   This is a good point and we do need to list them. This was my 
suggestion few weeks back as well.
   Why don't you simply list them in a slide deck and circulate? We  can 
then go from there. This will be
    an easy way to start the discussion.
> is a good list of issues (at least, some people have said yes and no-one
    Yes, that's true but it contains lot of additional things and the 
draft needs to be rewritten/restructured.
     IMO, if we take this path, it may take longer time to converge. 
Instead, we can start with the problem
     scope and issues as you have mentioned in your first bullet.
> main thing is to get people's views into the open. 
  If you plan to issue a draft revision with this approach before the 
March cut-off,  I see few problems:

  i) First of all, time is very short and I do  not know all DT members are
    reading the mails since the mailing list is quiet for sometime.

 ii)  All comments/issues should be compiled and circulated to the DT 
members (if
      not circulated by the individual member) and should have some time 
for discussion.

 iii)  We need few telecons ( at least) and some serious work before we 
report to the WG. 

Therefore, I would agree with Srini that let's plan for a presentation 
during March meeting.
Just create few slides and jump start the discussion. I know this is not 
a satisfactory progress
but we can get good feedback from the WG.

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 26 Feb 2007 16:30:56 -0000

hi all,

just commenting on tele's mail: 

> Sent: 26 February 2007 10:57
> To: Zuniga, Juan Carlos
> Cc: Hancock, Robert; [email-masked]
> Subject: Re: [MIPSHOP-MIH-DT] A modest proposal
> 
> Juan, all,
> 
> A couple of comments.
> First of all it would be nice to have a short summary of the 
> issues discussed in Santa Clara.

yes please.

> Second taking into account the above and the initial 
> splitting Robert provided, we should compile a first list of 
> what is in scope and what is not. The presentation could help 
> in defining the TOC for the new document while providing a 
> good overview to WG.

yes. and people already know what is on my list ;-)

robert h.

> > We definitely have to agree on the general work scope and 
> tenets for 
> > the DT before digging into more technical discussions. That's why I 
> > thought that Srini's proposal of 3 weeks ago made a lot of sense.
> >
> > IMHO, there is not much technical work that we can 
> accomplish before 
> > the deadline, but a presentation of the work plan is definitely 
> > something meaningful and achievable. This pretty much matches your 
> > second (b) proposal of taking the discussion and making a brief 
> > summary for the MIPSHOP and presentation for the meeting, where we 
> > could show the DT work plan and get feedback from the Working Group.
> >
> > that we must not create redundant functionalities from the ones 
> > already defined in 802.21. The 802.21 group just met this week in 
> > Santa Clara, CA and we were discussing solutions to a lot of issues 
> > that are described in the current Design Considerations 
> document and 
> > there is no need for MIPSHOP to reinvent the wheel.
> >
> > 	- Provide a solution to the MIH information transport 
> and discovery 
> > over L3 that suits the needs and complements the existing MIH 
> > Also, just want to let all know that due to the slow 
> progress in the 
> > DT, we have been working on a new revision of our proposal, 
> which we 
> > are planning to submit soon.
> >
> > Regards,
> >
> > Juan Carlos
> >
> >  
> >
> >
> > - I still think we need a consensus in the DT about what problem we 
> > are solving and what issues we have to take into account in 
> solving it 
> > - I believe we have agreement that the design considerations (DC) 
> > draft is a good list of issues (at least, some people have said yes 
> > and no-one has objected to that)
> >
> > that process can start discussions on this list if people want, but 
> > the main thing is to get people's views into the open.
> >

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 26 Feb 2007 16:52:07 -0000

hi juan carlos, 

> From: Zuniga, Juan Carlos [mailto:[email-masked]] 
> Sent: 23 February 2007 23:06
> To: Hancock, Robert
> Subject: RE: [MIPSHOP-MIH-DT] A modest proposal
> 
> Robert,
> 
> tenets for the DT before digging into more technical 
> discussions. That's why I thought that Srini's proposal of 3 
> weeks ago made a lot of sense. 

i agree that srini's mail is a good summary of some of the
organisational points, and I can try to formalise that for
comments before sending to the wider world during this week.
however, this mail was more about how to stimulate some
specifically technical discussions; for that, it seemed 
interesting to experiment with being a bit more provocative.
i hope people don't mind that too much.

> 
> IMHO, there is not much technical work that we can accomplish 
> before the deadline, but a presentation of the work plan is 
> definitely something meaningful and achievable. This pretty 
> much matches your second (b) proposal of taking the 
> discussion and making a brief summary for the MIPSHOP and 
> presentation for the meeting, where we could show the DT work 
> plan and get feedback from the Working Group.

ok

> However, with a common understanding about the DT goals, we 
> can then proceed to having more detailed technical 
> discussions and move much faster this time. 
> 
> For instance: I believe that a major agreement that we should 
> have is that we must not create redundant functionalities 
> from the ones already defined in 802.21. The 802.21 group 
> just met this week in Santa Clara, CA and we were discussing 
> solutions to a lot of issues that are described in the 
> current Design Considerations document and there is no need 
> for MIPSHOP to reinvent the wheel. 

for that, i think there is a specific issue and a general
point.

1) specifically, it would be good if you can point out where
you think that the DC discusses functionality that would already
be implemented in .21. (I am sure there are areas where it 
talks about stuff that .21 will do in the L2 transport case, but
that is a different issue.)

2) generally, my belief is that it is much better to design a
protocol which does not make strong assumptions about exactly
how it will be used (e.g. does not harm the network or break
itself if it is used differently from how it was originally
imagined). The concept is that the IETF designs protocols for
'the Internet' i.e. an open set of interconnected networks; it
doesn't design protocols for closed environments which happen
to use IP as a datagram protocol. this means that it is not 
unknown for protocols to have robustness or extensibility 
features which are not directly asked for in the original
problem. Of course, there is a tradeoff to be made: if a radical
simplification can be made by making some strong environmental
assumptions, then this has to be discussed.

i suspect that point (2) may be an area where there is a divergence
of views, so we need to bring this out. but again, I would find it
much easier to do that in the context of some specific examples;
hence point (1).

> 
> Do we all agree in the DT? In the WG? Are there any other 
> major agreements people believe we should have?
> 
> and discovery over L3 that suits the needs and complements 
> the existing MIH functionalities defined in IEEE 802.21
> 	- Other tenets?
> 
>  
> - How
> 

in any case, not a deliverable from the DT, just something for
our own convenience.

> 	- Producing a Draft solution

formally, an internet draft intended for adoption by the WG
as a WG item, with the intended final status of Proposed Standard.

> 	- Second document (if any) (internal to DT / external to all WG)

i would like to get some more work done before putting dates on
things.

> 
> 
> This is my view, but it would be helpful to have everybody's 
> views on this.
> 
> Also, just want to let all know that due to the slow progress 
> in the DT, we have been working on a new revision of our 
> proposal, which we are planning to submit soon.

that is of course your privilege.

r.

> - I still think we need a consensus in the DT about what 
> problem we are solving and what issues we have to take into 
> account in solving it before getting into protocol work
> 
> - I believe we have agreement that the design considerations 
> (DC) draft is a good list of issues (at least, some people 
> have said yes and no-one has objected to that)
> 
> that process can start discussions on this list if people 
> want, but the main thing is to get people's views into the open.
> 
> - i then get tuesday to pull it all together in my head and 
> make a proposal, which would be either
> (a) we rev the DC draft as a design team output with me as 
> editor, and for each issue having either agreed text or a 
> statement about what is open; we can do this for the -0n cutoff, OR

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 26 Feb 2007 16:52:10 -0000

hi subir, 

> Sent: 26 February 2007 16:13
> To: Hancock, Robert

any response is welcome. my answers in line also.

>    This is a good point and we do need to list them. This was 
> my suggestion few weeks back as well.
>    Why don't you simply list them in a slide deck and 
> circulate? We  can then go from there. This will be

because we already have a list in the DC draft? (see further
below.)

>     Yes, that's true but it contains lot of additional things 

one possible comment would then be to say "these are the things
which I think we don't need to worry about".

> and the draft needs to be rewritten/restructured.

i'm not wedded to releasing an update of the draft; it has only
ever been a means to an end. however, i'm very opposed to working
at the level of bullet point issue summaries, because it is too
easy for people to spend time working at cross-purposes (thinking
they are discussing the same problem but actually not).

>   If you plan to issue a draft revision with this approach 
> before the March cut-off,  I see few problems:
> 
>  ii)  All comments/issues should be compiled and circulated 
> to the DT members (if
>       not circulated by the individual member) and should 
> have some time for discussion.
> 
>  iii)  We need few telecons ( at least) and some serious work 
> before we report to the WG. 

that's fine. but it seems also that we need to propose some deadlines
to get some progress. at least I would assume that most people are
in the office around the time of the -00 deadline ;-)

> but we can get good feedback from the WG.

to get feedback we need to ask questions and say we have some
open points and some closed points. at the moment, all I can say
is that "everything is open".

r.

> editor, and

---

From: Subir Das <[email-masked]>
Date: Mon, 26 Feb 2007 12:01:13 -0500

> in the office around the time of the -00 deadline ;-)
    Yes, propose some deadlines for DT so that folks can plan early.

---

From: <[email-masked]>
Date: Mon, 26 Feb 2007 11:41:04 -0600

Dear All,
OTH, without ignoring all the current design considerations in the
draft, we can take a differential approach and try to analyse what's
missing. Of course, if the changes warrant for a new draft or if the DT
thinks we should have a new draft we can proceed that way.

Robert has set a deadline for tomorrow, I hope we can stick to it and
make a first attempt.

Regards,
Srini

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 11:01 AM
To: Hancock, Robert
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] A modest proposal

>> members (if
>>       not circulated by the individual member) and should have some 
>> time for discussion.
>>
>>  iii)  We need few telecons ( at least) and some serious work before 
>> we report to the WG.
>>     
>
> to get some progress. at least I would assume that most people are in 
> the office around the time of the -00 deadline ;-)
>

---

From: <[email-masked]>
Date: Mon, 26 Feb 2007 23:53:23 -0600

Hi all.

Keeping the procedural stuff aside, here are the first set of comments
from my side. My approach was to take DC draft and update it based on
(my) latest thinking and developments in .21 wg.

o. [section 2. para 2] The MIH service layer does indeed know the peer
function (as an MIH identity) and the corresponding local transport
connection (and ids) to be used for communication. I am not sure if this
is a specific issue for NAT traversal.
o. [2, 5] Clarify that the service interface is dependent on the
transport choice. Simple TCP/UDP already have socket i/f. There may be
no additional work needed.
o. [2,?] design goals wrt mobility should be discussed here, as
precursor to section 3.2 What are the design implications on the MIH
service layer when the underlying transport connection changes? Or just
assume permanent addresses? There are implications both ways. 
o. [3.1] Good to break up the aspects related to discovery, name
resolution and routing separately. Identify discovery is avoided by
static configurations. Discovery must be scoped to a specific [domain,
service, transport(if there are options), [transport_options]]. The
discovery of specific transports and its options can be done as node
capabilities but MIH does not provide that service, so the transport
layer must provide that mechanism.  
o. [3.2] we need a little more depth in mobility discussion. What are
the implicaitons on the MN and the serving node that relies on the
mobility events from the node. My thinking is that the MIH services
themselves are independent of the transport connection but as the
delivery mechanism changes and being reestablished there is a cutoff
period and it must be handled graciously. This reconnection may not be
in realtime (or is there a requirement at all?). The discovery of MIH
services upon transport changes is not urgent. It can happen offline, if
necessary. What is important is to reestablish the transport connection
to the old nodes with the SA.
o. [3.3] Let's call this transport configuration options. 
	o. congestion avoidance: also frequent data. How to measure
this? One of the earlier concerns in IETF was related to events being
flooded with improper settings. We cannot leave it to mih service layer.
Would be good to have some transport consideration and a feedback
mechanism to service layer of congestion notice. Better to club with
section 3.9.
	o. fragmentation at IP may not be good especially for firewall
and nat purposes. Transport should provide this, IMO.
	o. duplicate message detection. MIH service has this. But good
to have in transport.
	o. (new one) real time delivery of messages or almost.
O. [3.4] good discussion. 
o. [3.5] multiplexing depends on the usage of same transport options.
o. [3.6] do we need this discussion? The network layer must be
abstracted by the transport signaling layer.
o. [3.7] the security is limited only to transport. Mih services must
employ their own.
o. [3.9] combine with [3.3, congestion avoidance]
O. [new] overhead due to transport options on the bandwidth usage (e.g.
maintaining the connection due to mobility, keep alive etc)

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 27 Feb 2007 16:11:14 +0100

Hi all,

Please see in line.

> no additional work needed.
Probably some clarifications would be required in the case a solution 
similar to draft-hancock-mipshop-gist-for-mih-00 is selected.
Opinions?
> assume permanent addresses? There are implications both ways.
Would be an option having considerations discussing where the MIHF is 
co-located/located?
As an example, in the case it is co-located with the AR and we could use 
the proxy mode
support from 802.21 (especially for ES and CS) to reduce the problem space.

> layer must provide that mechanism.  
I think it would be interesting to agree on few scenarios to show how 
discovery of MIH peers works.
I recall a discussion I had with Robert last meeting in San Diego about 
path decoupled discovery mechanisms.
I guess some of the concepts (just discard the specific solution) can be 
derived from draft-hancock-nsis-pds-problem-04.
Comments?
> to the old nodes with the SA.
Agreed.
> 	o. (new one) real time delivery of messages or almost.
We should also be able to configure the transport layer to work with the 
Ack system specified in 802.21.
The reason is that events are time critical and timely delivery is 
important. In the case we rely on the transport layer retransmission
mechanism the information to be re-sent is always the same. If the 
802.21 acknowledgment system is used instead we might be
able to update information while being re-sent.

regards,
tele

---

From: Subir Das <[email-masked]>
Date: Tue, 27 Feb 2007 11:16:09 -0500

All,
I put some of my quick comments in the draft version.
Pl. search by name. 

Thanks,
-Subir

> - either way, we continue to work on any issues up to the meeting start.

MIPSHOP                                                      E. Hepworth
Internet-Draft                                                R. Hancock
Intended status: Informational                                      Roke
Expires: April 26, 2007                                  S. Sreemanthula
                                                   Nokia Research Center
                                                               S. Faccin
                                                       Intel Corporation
                                                        October 23, 2006

      Design Considerations for the Common MIH Protocol Functions
          draft-hepworth-mipshop-mih-design-considerations-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The MIPSHOP working group is currently developing functionality to
   support media independent handover services, which are intended to
   aid IP handover mechanisms between heterogeneous wired and wireless
   access systems.  These handover services provide a mechanism by which

Hepworth, et al.         Expires April 26, 2007                 [Page 1]

Internet-Draft          MIH Design Considerations           October 2006

   information such as the presence of neighbouring links and networks,
   and their associated characteristics, can be delivered to mobile and
   other network nodes for the purposes of supporting better handover
   decisions.  A key component of the solution is the set of protocols
   that is used to deliver the various types of information to the
   appropriate destination node.  A separate problem statement draft
   outlines a structure for this set of protocols as a unified set of
   common functions, supporting a more diverse set of application
   specific protocols.  This draft outlines the key considerations that
   have to be considered when selecting or designing protocols for such
   common functionality.  This draft is offered for use as a mechanism
   to capture working group discussions on the design of the common
   protocol functions during their initial development, without imposing
   a particular solution on the discussion process.  It is not intended
   as a long term output.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Inter-layer Interactions . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Design Considerations . . . . . . . . . . . . . . . .  5
     3.1.  Initial Discovery and Routing  . . . . . . . . . . . . . .  5
     3.2.  Signalling Peer Changes  . . . . . . . . . . . . . . . . .  8
     3.3.  Message Transport  . . . . . . . . . . . . . . . . . . . .  9
     3.4.  State Management . . . . . . . . . . . . . . . . . . . . . 10
     3.5.  Mutiplexing and Extensibility  . . . . . . . . . . . . . . 12
     3.6.  Network Layer Interactions . . . . . . . . . . . . . . . . 12
     3.7.  Message Security . . . . . . . . . . . . . . . . . . . . . 13
     3.8.  Overload Management  . . . . . . . . . . . . . . . . . . . 14
     3.9.  Failure Handling . . . . . . . . . . . . . . . . . . . . . 15
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

Hepworth, et al.         Expires April 26, 2007                 [Page 2]

Internet-Draft          MIH Design Considerations           October 2006

1.  Introduction

   The MIPSHOP working group is currently developing functionality to
   support media independent handover services, which are intended to
   aid IP handover mechanisms between heterogeneous access systems, both
   wired and wireless.  These handover services provide a mechanism by
   which information such as the presence of neighbouring links and
   networks, and their associated characteristics, can be delivered to
   mobile and other network nodes for the purposes of supporting better
   handover decisions.  An initial set of handover services, and the
   information that these services exchange between two peers, is under
   development within IEEE 802.21.  These services are referred to as
   the Media Independent Handover Services (MIH Services) and the
   initial set consists of the event, command and information services
   (ES, CS and IS); there are also System Management messages which
   configure the operation of the other MIH protocols themselves.  The
   transport security and related aspects associated with delivery of
   these messages across the network at the IP level (including over the
   air where direct layer 2 transport is not being used) will not be
   addressed by IEEE 802.21.  It is the expectation that this area will
   be addressed by the MIPSHOP working group.

   An architectural framework and set of common requirements is proposed
   in the problem statement draft [1], which includes a decomposition of
   the overall MIH problem into a common part and a set of MIH services
   that are layered over the top.  It is intended that the common part
   is suitable not only for the delivery of IEEE 802.21 MIH services
   (ES/CS/IS), but can also be applied to non-802.21 architectures and
   handover services.

   This draft outlines detailed design considerations for the common
   part delivery mechanism, with the goal of providing a basis for
   discussing different solutions and providing a means to ensure that
   important solution requirements are considered by subsequent
   proposals.  This draft is not intended as a comprehensive analysis of
   different solutions, but does include some discussion of solution
   characteristics and possible solution options as examples where
   appropriate.  It is assumed that the requirements on the common part
   imposed by the IEEE 802.21 MIH services are wholly captured in the
   problem statement draft [1].  This draft is offered for use as a
   mechanism to capture working group discussions on the design of the
   common protocol functions during their initial development, without
   imposing a particular solution on the discussion process.  It is not
   intended as a long term output.

   The structure of this document is as follows.  Section 2 introduces
   some general design goals for the common part, Section 3 describes a
   set of design considerations that should be taken into account when

Hepworth, et al.         Expires April 26, 2007                 [Page 3]

Internet-Draft          MIH Design Considerations           October 2006

   developing a solution, Section 4 provides security considerations,
   and Section 5 summarises the conclusions and open issues.

2.  Inter-layer Interactions

   The framework presented in [1] decomposes the MIH protocol problem
   into two parts; the Information and Information Exchange mechanism,
   and the functionality common to all MIH services.  This is
   subsequently referred to as common protocol functionality.  The
   intention of the separation is to allow all MIH services access to
   this functionality from a single protocol module without having to
   re-implement or re-integrate the same functionality individually for
   each MIH service.  The problem statement presents an outline of this
   decomposition; however, the precise details of the split of
   functionality and interaction between the layers need to be refined
   as the design of the common part proceeds.  Indeed, one important
   design consideration is that it should be possible to define these
   interactions precisely and in an easily implementable manner.  This
   section indicates some specific inter-layer interaction issues that
   need to be taken into account in this way.

  Subir> The goal and motivation of this section is not clear. I do not understand the why MIH protocol needs to be decomposed like this. It seems that the whole document is based upon this split functionality. We need some good discussions on this. Information exchange mechanism is a part of information service and the information database 
  (if that is meant by information) is a separate thing. 

   One of the key questions is how MIH service peer identity knowledge
   is split between the service and the common part.  In other words,
   does the MIH service have knowledge about the location of a peer (in
   terms of IP address), or does it simply pass a message to the common
   protocol functionality and expect it to be delivered.  If the MIH
   service manages the resolution of peer identities to IP addresses,
   issues such as NAT traversal can become more complicated (as
   discussed in Section 3.6). 

Subir> Again why do we need to split the functionality? Are we designing the MIH function here? IMO, this is no different than any other application.  

   It is assumed that the peer entities supporting an MIH service hold
   some sort of service layer state information (such as link
   measurements or event subscriptions) that is being accessed or
   updated in some way.  So, a second issue is whether there is any
   relationship between the management of this state lifetime and the
   common protocol functionality.  This draft assumes that service layer
   state lifetime is transparent to the common protocol functionality,
   and operations such as soft state refresh are not explicitly visible
   at the lower level.  However, note that the common protocol
   functionality can be used to transmit refresh messages generated by
   an MIH service if such a refresh mechanism is required, but the
   generation and timing of these messages is the responsibility of the
   MIH service.

   In the overall problem description it can be seen that some
   signalling transactions involve a sequence of three or more nodes
   rather than a simple peer to peer communication.  There is therefore

Hepworth, et al.         Expires April 26, 2007                 [Page 4]

Internet-Draft          MIH Design Considerations           October 2006

   a question of whether the common protocol functionality should be
   explicitly aware of the complete chain of nodes involved in a
   transaction, or whether it should see only the directly adjacent
   peers.  In this draft, we assume the latter case; therefore, the
   concatenation of message exchanges along a sequence of nodes is
   something that has to be managed within the MIH service itself; it
   may even be an implementation issue for the MIH services, in the same
   way that chains of SIP signalling nodes can be built up out of back-
   to-back user agents. 

   Subir> This is under discussion within 802.21. It is not clear whether we 
   need routing at the MIH layer. 

   In the long term, in order to make the inter-layer separation
   precise, a service interface between the MIH service and the common
   protocol functionality should be defined.  This service interface
   would expose a set of functionality that can be used by the MIH
   service to discover and send messages to peer entities, and could
   allow the common protocol functionality to be configured to suit
   particular needs associated with an MIH service. 

Subir> Again the motivation for this is not clear. 

3.  Protocol Design Considerations

   There are a number of key considerations that should be considered
   when designing a solution to support MIH message delivery.  These are
   described in the following subsections.

3.1.  Initial Discovery and Routing

   When an MN joins a network, it must be able to discover various
   network nodes that support the MIH services that it wishes to use.
   The location of the MIH services in the network is not fixed.  Some
   may be supported locally by the access network, whilst others may be
   supported by a node deeper in the network, or a sequence of such
   nodes.  The sequence may reach back all the way to the user's home
   network.

   The process of discovering a suitable peer and establishing a route
   towards it has a number of aspects that need to be considered.  The
   first of these is how MIH services are identified.  For an MN
   interested in a particular MIH service, the identity of the service
   must be usable in some discovery and name resolution procedure that
   ultimately returns an IP address to the interested MN.  Therefore,
   the name space within which MIH services are identified has an
   interaction with the set of possible discovery mechanisms.  For
   example, use of a particular discovery procedure may require
   extensions to support a new namespace or new registrations within an
   existing one.   

   Subir> This is something that need further discussion. Do we need this as a requirement? 

The selection of a suitable peer and its subsequent
   use may be based on a number of aspects including the capabilties of
   the MIH peer and the ability to setup a secure communications channel

Hepworth, et al.         Expires April 26, 2007                 [Page 5]

Internet-Draft          MIH Design Considerations           October 2006

   to that device.  Therefore, the discovery process has interactions
   with other transport layer functionality, which may need to be
   considered as part of the discovery procedure itself.

   Subir> Secure discovery is a strict requirement. We need to revisit and 
   IMO, we do not need this one. If at all it is required in some cases, it 
   Should be SHOULD NOT MUST. 

   In the simplest case, the selection of an appropriate peer can be
   left entirely to the network, based purely on the service identifier.
   Where the MIH service is entirely implemented in the local access
   network, this is probably sufficient.  In such a scenario, the MN
   could send a query to the network requesting support for a particular
   MIH service, and allow the network to select the most appropriate MIH
   peer.  Some options for this are discussed below.

   More sophisticated services may require interactions further into the
   network, for example involving the user's home operator; this would
   be an example of "proxy operation".  This may be influenced by
   configuration information provided by the MN, such as operator
   identity.  There are two basic approaches that can be considered:

   o  a simple method, especially from the MN perspective, is to treat
      this as a generalisation of the basic case where the discovery
      process is repeated recursively along the proxy chain.

   o  a more complex method is to require the MN to discover the
      complete set of nodes up to and including the signalling endpoint.
      This gives more control over the process to the MN at the cost of
      having to expose more details about inter-network relationships.

   A particular issue is the precision with which the initial discovery
   process takes place.  One possibility is that the initial discovery
   detects a candidate set of nodes supporting any MIH services;
   subsequently, messages within the MIH protocols themselves determine
   the detailed capabilities of each node, and decide which nodes to use
   for which specific purpose.  The alternative is that the initial
   discovery process incorporates these selection criteria directly,
   which allows a more targeted discovery of the initial candidate set,
   at the cost of requiring a richer definition of the set of possible
   service at the layer boundary between the MIH services and the common
   protocol functions.  The first approach is simplest and may be
   appropriate in limited scale networks (or where the equivalent
   functionality is being developed at Layer 2).  However, it can easily
   lead to scaling difficulties in larger scale networks, where, even
   though the final set of communicating nodes may be small, the size of
   the candidate set could be very large.  

   Subir> From 802.21 perspective, the earlier approach is sufficient. We need 
   to understand the use case scenario before discussing the latter approach. 
   IMO, the discovery should not be a complex one in order to provide the MIH 
    services. 

   Therefore, the ability of the
   initial discovery criteria to include such additional criteria needs
   to be considered.  The openness in this question is reflected in the
   openness of the term 'MIH service'; in the 802.21 context for
   example, it could refer either to the complete set of 802.21 MIH
   services, or to a specific one, such as IS.  This issue affects

Hepworth, et al.         Expires April 26, 2007                 [Page 6]

Internet-Draft          MIH Design Considerations           October 2006

   primarily the discovery process; for the rest of this document, we
   continue to use the term MIH service, always bearing in mind this
   spectrum of possibilities for what it could refer to.

   The discovery and routing functionality could either be invoked
   directly by the MIH service, or could be integrated with the common
   protocol functionality.  In the former case, the MIH service would be
   responsible for carrying out the discovery exchange with the network,
   and would have to indicate the results of the discovery procedure to
   the common part to allow delivery of mesasges to the appropriate
   peer.  In the latter case, the MIH service would simply request the
   delivery of a message from the common protocol functionality, and
   leave the discovery and resolution procedures to the lower layers.
   Either approach is feasible, but the following issues should be
   considered when designing a solution: 

  Subir> Again the motivation for splitting the functionalities is not clear to me.

   o  support for discovery before full IP connectivity.  In some cases,
      the MN may want to communicate with an MIH service before full IP
      connectivity is available.

   o  transparency of the network topology.  The internal structure of
      the network should be hidden from the MIH service, which allows
      arbitrary network deployments, and changes to those deployments
      without impacting the MIH service.

   o  localisation of information.  The information associated with
      supporting a particular MIH service should be located in as few
      places as possible to aid failure recovery, and reduce
      requirements on MNs to hold large amounts of state information. 
 
  Subir> I do not understand the purpose of the above requirement. 

   o  elimination of duplicates and reduction of round trips.  To reduce
      latency and network load, the required information should be
      discovered using as few signalling messages as possible both in
      the initial discovery case and post handoff where it is necessary
      to check that the signalling relationships are still valid.  For
      example, if a peer for a particular MIH service has already been
      discovered that can be used for an alternative MIH service as
      well, it would be preferable to avoid performing a duplicate
      discovery procedure when the information is already known.

   o  adaptation of the discovery mechanisms.  Some approaches to
      discovery may be particularly applicable to specific technologies
      or in particular administrative environments and therefore a
      single perfect solution may not be attainable.  However, it is
      important to localise the impact of this variability as much as
      possible.

   Given the above considerations, it seems likely that the most

Hepworth, et al.         Expires April 26, 2007                 [Page 7]

Internet-Draft          MIH Design Considerations           October 2006

   appropriate place to implement the discovery and routing
   functionality is as part of the common protocol functionality.  

   Subir> I think we need some discussions here. It is not clear how this conclusion has been made. 

   It is
   possible that the discovery process could be bootstrapped from other
   protocol state or protocol exchanges, but the suitability of these
   approaches and the architectural assumptions associated with their
   use needed to be assessed.  For example, DHCP [3][4] is a possible
   candidate, but would only be most suitable for link technoloiges
   where this is used as an address assignment method.  Another
   possibility is SLP [5], although this is not curently widely
   deployed; mDNS [2] falls into the same category.  DNS itself can also
   be used (for example, SRV records [6] support the discovery process
   for services associated with a particular DNS domain), however, it is
   difficult to use them to do service discovery in a way that
   automatically takes into account the current network point of
   attachment.  Router level advertisements are also an option, but the
   mechanism may be hard to extend to support advertisement of all MIH
   services, so this would be mainly to provide bootstrap to some other
   approach.

3.2.  Signalling Peer Changes

   As well as the initial discovery of the peers for signalling, it must
   also be considered how to handle the case where the correct
   signalling peer changes while the MN is attached to the network. 

  Subir> I assume this should be transparent to the end users. I can think 
  Of two scenarios: i) peer changes while providing the services: this should 
  be taken care by existing mechanisms such as server pooling or backup servers.
  ii) Peer changes while they are not in service: this should be discovered easily if the discovery mechanism uses a logical namespace

   Several scenarios can be considered:

   o  The MN point of attachment changes, and according to the local
      network architecture a new signalling peer is now the appropriate
      serving node for it.

   o  The signalling peer fails, and a backup must be used instead.

   o  The network infrastructure is reconfigured internally (changing
      the topology or set of available services at a given node), which
      means that a different peer or set of peers should be used.

   In so far as the common protocol functions take responsibility for
   the initial discovery process, they must also take care of the
   rediscovery and rerouting needed in these types of circumstances.
   (Conversely, if external discovery approaches are used, then it must
   be defined how these handing the peer change problem.)

   A very simple and robust approach is simply to repeat the initial
   discovery process periodically.  This always works after some time
   lag, but leads to an awkward tradeoff between efficiency (which is
   reduced if the repetition rate is high) and reactiveness (which
   requires a high refresh rate).  This problem can be mitigated if a
   long period is used but hints are allowed to trigger the process on

Hepworth, et al.         Expires April 26, 2007                 [Page 8]

Internet-Draft          MIH Design Considerations           October 2006

   particular events.  Indeed, the MIH services themselves can be used
   to deliver such triggers during periods of correct operation,
   requiring fallback to periodic discovery only to handle failure
   scenarios.

   Whatever approach is used here, it should be noted that there needs
   to be an interaction between the service layer and common protocol to
   convey not just the possibility that rediscovery is needed, but also
   to indicate that a peer change has taken place. 

 Subir> This should not be a requirement, IMO. 

3.3.  Message Transport

   Message transport is responsible for the actual delivery of messages
   between peer entities, and should be configurable to suit the needs
   of the particular MIH service, for example, reliable versus expedited
   delivery.  Note that it is not assumed that a single instance of the
   common protocol functions has to be configured and used in exactly
   the same way by all the MIH services at any given node.  Different
   services might request different levels of transport support from a
   single instance; indeed, a service might request different transport
   characteristics for different transaction types.  

   Subir> My understanding is that MIH services are agnostic to underlying    transport. Therefore, I do not understand what do we mean by `Different
   services might request different levels of transport support from a
   single instance`. 

  The main transport considerations include:

   Congestion Avoidance:  some form of congestion control is required to
      guarantee that MIH service operation cannot damage the network.
      This is particularly critical for services that may transport
      large volumes of data (e.g. to prevent them issuing large numbers
      of parallel requests if messages are already being dropped because
      of congestion effects).  Congestion control could either be
      provided in a specialised way as part of a custom transport
      protocol directly over IP, or provided through the use of an
      existing protocol such as TCP or SCTP.  In the latter case,
      standard transport parameter estimation algorithms may need to be
      assessed in order to work out their suitability for different MIH
      services.  It is assumed that the various MIH services do not have
      specialised requirements for congestion handling. 

  Subir> Congestion control is mentioned in current 802.21 draft and suggested 
  to use TCP like congestion control.

   Reliability:  some MIH services require reliable delivery of their
      messages and this has to be achieved efficiently in an environment
      (i.e. mobile/wireless) where data transfer latency can be highly
      variable between different technology types and data loss may be
      high.  This reliability can either be implemented within the MIH
      services themselves or provided by the common transport.  While
      implementation within the MIH service is technically possible, it
      does not make best use of the sophistication that has been
      achieved in transport layer optimisation in recent years.  For
      example, a full implementation would need to consider
      functionality such as windowing, adaptive retransmission timeouts

Hepworth, et al.         Expires April 26, 2007                 [Page 9]

Internet-Draft          MIH Design Considerations           October 2006

      and loss detection mechanisms, which are non-trivial to design.
      In addition, relying on the service layer to handle all
      reliability issues opens the question of whether timer values
      should be based on message transfer latency or application
      processing latency, and these two can differ significantly.
      Allowing the option of a reliable transport service means that the
      additional recovery mechanisms within the service layer can be
      made very simple and robust because they do not need to be
      optimised for efficient recovery of message loss within the
      network.

   Fragmentation:  the transport protocol must be capable of performing
      fragmentation when the amount of data in a message to be sent is
      too big to fit into a single IP packet.  IP fragmentation could be
      used, but would require Path MTU discovery procedures to be
      supported, unless very conservative path MTU estimates could be
      assumed by default.  However, note that fragmentation at the IP
      layer amplifies packet loss rates because the loss of a single
      fragment destroys the entire packet, and also the entire packet
      has to be retransmitted.  Therefore, it is preferable to support
      the fragmentation requirements within a reliable transport.

   Re-ordering and Head of Line Blocking:  depending on the lower layer
      in use, messages may arrive out of order.  If the transport does
      not provide in order delivery, it will be the responsibility of
      the MIH services themselves to handle this problem.  In addition,
      head of line blocking may be an issue in cases where multiple MIH
      services are using a single connection between two peer entities.

   Duplicate Message Detection:  multiple copies of a message may arrive
      at a node.  Does the transport layer provide duplicate message
      detection, or is this left up to the MIH service? 

 Subir> We need to discuss this. Currently there is no mechanism in the MIH 
 Protocol but left as implementation. 

3.4.  State Management

   The operation of the MIH services requires the existence of service
   layer state within the network, for example, registrations of
   interest for particular types of events or location information to
   configure the delivery of neighbourhood lists.  Various transaction
   models can be identified that allow different entities to initiate an
   MIH message exchange to set up such state.  The transaction sequences
   that are permitted to install and manipulate this state will most
   likely be MIH specific (it is unlikely that a single transaction
   model will be applicable to all MIH services), but even so there will
   be impacts on the common protocol functionality, for example,
   influencing the symmetry required in the message delivery mechanism.

   Subir> State management for MIH services is within MIH protocol transaction. 
   There is no need to consider that within the transport, IMO. 

   In addition, the dependency of one set of MIH transactions on another
   has to be considered, for example, can transactions be nested, or can

Hepworth, et al.         Expires April 26, 2007                [Page 10]

Internet-Draft          MIH Design Considerations           October 2006

   they overlap with each other.

   Example transaction sequences include:

   1.  MN initiated only; where exchanges can only be initiated by the
       MN, and the network only responds to explicit requests for
       information.

   2.  MN and NN intiated; where both the MN can request information,
       and the NN can deliver information asynchronously to the MN.

   The current MIH services that have been identified require MN and NN
   initiated exchanges as a minimum.

   Subir> There is no way .21 can restrict this kind of behavior. Also one 
   Scenario is missing here: 

   XX: Network Initiated only: where exchanges can only be initiated by the
       Network, and the MN only responds to explicit requests for
       Information/service.

   The types of state information that are manipulated during an MIH
   exchange include:

   o  MIH Service Layer State: information related to the particular MIH
      service, that is accessed and maintained by that service.

   o  Peer State: including peer capabilities, and any negotiated
      parameters.

   o  Routing State: such as next hop information for routing to a peer
      entity.

* Security State: associated with a particular message exchange.

   Subir> Above points need further discussion. 

   o  Transport State: counters and timers associated with the delivery
      of individual message fragments (datagrams) and their
      retransmission and reassembly.

   The first type of state is MIH service specific, and should be
   transparent to the common protocol functionality.  The latter four
   types could be managed by either the MIH service or the common
   protocol functionality, although the second option seems preferable
   (as will be discussed in Section 3.1 and Section 3.7).  A fundamental
   question that has to be considered is how these different types of
   state information are related to each other.  For example, if a
   connection to a peer entity is lost, is the MIH service state now
   considered to be invalid?  Typically, it is preferable to avoid such
   hard dependencies between the state at different layers, since it
   reduces the freedom within the common protocol part to manage
   connections most efficiently.  In other words, the service layer
   state is assumed to be managed entirely within the service layer
   itself.

Hepworth, et al.         Expires April 26, 2007                [Page 11]

Internet-Draft          MIH Design Considerations           October 2006

3.5.  Mutiplexing and Extensibility

   Multiple MIH services have already been defined, and it is highly
   likely that different MIH services will be co-located within single
   nodes (this will definitely be true of the MN, and may be true for
   infrastructure nodes depending on the MIH deployment).  A
   consideration that needs to be addressed is how multiple MIH services
   are handled by the common protocol functionality.

   One option would be to hide the presence of multiple MIH services
   completely.  However, this would limit the ability of a node to talk
   to different MIH peers depending on which service is being used, if
   the discovery is handled as part of the common protocol
   functionality.  An alternative is to expose the multiple MIH services
   individually to the common protocol functionality, and allow it to
   multiplex MIH service messages at the transport level if appropriate
   (for example, if both messages are destined for the same peer entity
   and have the same transport requirements).

   In addition, the extensibility of the MIH services needs to be
   considered.  For example, if multiple versions of an MIH service are
   available, this may impact the common protocol functionality in terms
   of discovery of compatible MIH service implementations  (see
   Section 3.1).

Subir> The above section is not very clear. In particular, the example 
Of `multiple versions of an MIH service`. What is the version here? Is it 
802.21 specification version? If so, do we expect to have two versions 
Implemented within a device?

3.6.  Network Layer Interactions

   The MIH functionality interacts with the network layer in two
   distinct ways.

   Firstly, the signalling messages must be able to pass through the
   network between signalling peers even when the network infrastructure
   contains addressing boundaries and firewalls where policies on
   allowed traffic types are imposed.  Therefore, it is important to
   limit the protocols used to support the common functionality as far
   as possible to those that such middlebox devices can be configured to
   process and support.  For example, standard transport protocols such
   as TCP or UDP are relatively easy to deploy especially if
   transactions are initiated from the internal side of the middlebox
   whereas ICMP extensions are much more problematic.

   Secondly, if some parts of the MIH service payload contain addressing
   information, such as the current IP address associated with a device
   or addresses of other access routers, NAT traversal becomes much more
   difficult as the NAT may have to change these payloads.  It is
   preferable to standardise the location of such information across all
   the different MIH services so that NATs do not have to support
   different Application Layer Gateways for each and every MIH service

Hepworth, et al.         Expires April 26, 2007                [Page 12]

Internet-Draft          MIH Design Considerations           October 2006

   that has been or will be defined.  This suggests that addressing
   information should be carried at the lowest possible level in the MIH
   protocol stack.

3.7.  Message Security

   Message security is needed to protect the information exchanges
   between MIH service peers.  This section focuses on authentication
   and authorisation aspects associated with MIH service support; DoS
   and overload situations are considered in Section 3.8.

   It is highly desirable to reuse standard channel security protocols,
   but there are still several possible protocol choices.  There are a
   number of considerations:

   Authentication and Key Management:  authentication can either be
      performed unilaterally, where only one party confirms the identity
      of the other, or mutually, where both parties confirm each other's
      identity.  For some MIH services, it is important that mutual
      authentication is possible, since the information exchanged
      initiates complex processing in both peers.  Although this does
      not necessarilty imply that the MIH service must perform the
      authentication itself, it may still be important for the service
      to be aware of the authenticated identity of the peer it is
      communicating with.  Because standard channel security protocols
      necessarily include peer authentication to provide keying
      material, it is natural to think of the authentication
      functionality as being part of the common protocol functionality. 

  Subir> The common functionality part is not clear to me. 

   Credential Reuse:  message security depends on the existence of
      credentials to identify the peers taking part in the signalling
      exchange; the credentials are used in the protocols to provide
      node authentication and keying material for message protection
      itself.  Different protocols can exploit different credential
      types and so it may be possible to select protocols in order to
      build on existing relationships in the network. 

Subir> The above is not clear. 

   Authorisation:  authorisation controls who is allowed to perform what
      actions on state information and message exchanges between MIH
      peers.  It may also be possible to build MIH trust models that
      reuse existing relationships in the network, for example, if an
      MIH service is provided locally by an access network to an MN, the
      fact that the information is being relayed by a trusted AP may
      indicate to the MN that the information is from a valid source.
      In cases where the MIH service is provided by an operator deeper
      in the network, roaming relationships could be re-used to support
      delivery of MIH information.  However, in this draft we assume
      that the authorisation problem is handled primarily within the MIH

Hepworth, et al.         Expires April 26, 2007                [Page 13]

Internet-Draft          MIH Design Considerations           October 2006

      services themselves.

   Privacy:  various identifiers will be used by the MIH service and the
      common protocol functionality to support authentication, peer
      discovery and message delivery.  These identifiers will relate in
      some cases to users and organisations whose privacy needs to be
      respected and whose identity should not be freely disclosed except
      to authorised parties.  Therefore, any security solution needs to
      consider how such identifier information is protected. 

  Subir> Not all 802.21 identifiers required to support the security requirements as mentioned above. Need further discussion. 

   The visibility that the MIH service has of the security functionality
   also needs to be thought about.  One extreme would be for the MIH
   service to be responsible for setting up the secure channel over
   which to communicate, but this may require the MIH service to have
   more knowledge about the underlying network topology than is
   otherwise necessary.  Alternatively, the common protocol
   functionality can include the security aspects, and the MIH service
   can request a secure channel from the lower layers when establishing
   a relationship with an MIH peer based on some MIH specific security
   policy.  This has the added advantage that different security
   protocols can more easily be integrated into the MIH protocol suite
   (once into the common part, as opposed to once for every MIH
   service).

3.8.  Overload Management

   Overload management handles situations where a node is flooded with
   messages.  These situations can occur both during normal use, or as a
   result of a flooding attack by a malicious user.  In either case, the
   common protocol functionality has a role to play in handling such
   situations needs to be considered, because these problems are closely
   associated with the message security and congestion control aspects.
   In particular, it is important that overload situations are
   considered for the design of the common protocol functionality as it
   is impossible to support reliability without overload management
   strategies in place.

   The overload issue is related to processing within a node when it
   starts to receive messages faster than it can process them, and what
   facilities are provided within the common protocol functionality and
   MIH service to handle these situations.  In addition, nodes should
   also detect that a peer is overloaded, and try and mitigate the
   situation somehow.  One solution is to provide some rate control
   either at the MIH service, in the common protocol functionality or
   both.  The common protocol functionality cannot entirely solve this
   problem because the adaptation to overload situations may be MIH
   service specific.  However, the overload situation can be detected
   and indicated to the MIH service.  It may be necessary to provide one

Hepworth, et al.         Expires April 26, 2007                [Page 14]

Internet-Draft          MIH Design Considerations           October 2006

   or more signalling channels to cope with different message priorities
   in this case.  Some elements of the common functionality must operate
   even in the absence of a congestion or flow-controlled transport
   connection, such as the initial discovery process.  Typically their
   design must incorporate some sort of robust overload management
   mechanism, such as exponential backoff.  If a standard discovery
   protocol (like DHCP) is being used, this behaviour is built in. 

3.9.  Failure Handling

   Nodes may fail at any time, and some mechanism is needed to allow
   graceful recovery.  Failure situations include:

   o  inability to discover a peer - this is related to discovery and
      routing Section 3.1.

   o  the loss of a peer, which must be detected.

   o  local shutdown, and informing current peer nodes.

   As for overload management, the common protocol functionality cannot
   be solely responsible for addressing this issue since some failure
   conditions will affect only the MIH service and not the lower
   communications layers.  Also, the recovery procedure will be partly
   application specific.  However, other failure conditions can be
   detected more rapidly and efficiently at lower layers of the protocol
   stack; for example, rather than implementing a keepalive mechanism
   within each MIH service, a single mechanism at the lower level can be
   used to check the overall status of a given node.  Therefore, the MIH
   service must be partially responsible for detecting the loss of an
   MIH peer, but may use hints provided by the common protocol
   functionality to speed up the detection process.

   For local shutdown cases, it should be the responsibility of the MIH
   services to inform peer nodes of the situation.

Subir> It seems that Load management and failure handling are too generic and It should be handled by error handling. 

4.  Security Considerations

   When developing a solution for supporting the exchange of MIH service
   information between two peer devices, there are a number of security
   issues that need to be taken into account.

   The discovery and information exchange may occur in situations where
   full IP connectivity is unavailable.  In this case, the secure
   transport cannot be provided end-to-end, but could potentially be
   provided between a proxy device and the peer MIH, for example,
   between an access router and appropriate server.  The trust model and

Hepworth, et al.         Expires April 26, 2007                [Page 15]

Internet-Draft          MIH Design Considerations           October 2006

   security implications of supporting this mode of operation needs to
   be investigated.  In the alternative scenario with end-to-end IP
   connectivity, the security issues are slightly simpler though
   securing the discovery remains an issue.  The co-existence of the
   security mechanisms for the full and partial IP connecivity will need
   to be considered.

   The effect of Denial of Service attacks also needs to be managed, for
   example, by reacting to overload situations (see Section 3.8).  State
   information is installed in nodes for both transport and MIH service
   purposes; the processing associated with installing or managing this
   state by nodes in the network should be kept to a minimum prior to
   secure channel setup.

   The identifier space that is used to support authentication, and how
   privacy is managed for these identities is also a key concern.  The
   use of these identifiers to support authorisation needs to be
   analysed, and these issues are discussed in more detail in section
   Section 3.7.  It is currently assumed that the common protocol
   functionality must provide message (channel) security for the MIH
   services to support message integrity/authentication.

5.  Conclusions

   This Internet Draft outlined a number of design considerations that
   need to be taken into account when developing the common
   functionality required by MIH services to exchange information
   between peers.  The main issue that needs to be considered is how to
   split reponsibility for various parts of the functionality between
   the MIH service and the common protocol part.

   There is good justification for supporting certain aspects of the
   required functionality in a common part that can be used by multiple
   MIH services.  This independence provides a way to hide the specifics
   of a particular network from the MIH service, prevents the same
   functionality being re-implemented multiple times, and supports
   easier integration of new or enhanced protocols into the overall MIH
   solution.

   However, it is also possible that different MIH services will
   ultimately have slightly different requirements from the underlying
   transport, depending both on the type of information managed by the
   MIH service, and the particular message that is being exchanged.
   Therefore, it is important that the transport mode used for
   particular message exchanges can be configured in some way by the MIH
   service to suit its requirements.

Hepworth, et al.         Expires April 26, 2007                [Page 16]

Internet-Draft          MIH Design Considerations           October 2006

   It should also be noted that the common protocol functionality cannot
   be wholly responsible for providing some aspects of the solution, for
   example, reliability and overload management requires support at both
   the lower layer, where information about network conditions is
   readily available, and at the MIH service itself, where specific
   information about the state managed by the service and the strategies
   to react to certain conditions is maintained.

   In terms of the protocols used by the common part, it is clear that a
   single protocol will not be sufficient to meet all identified
   requirements.  Therefore, it is likely that the common part will in
   fact be implemented as multiple protocols that are integrated below a
   simple service interface exposed to the MIH services above.

6.  References

   [1]  Hepworth, E., "Mobility Services: Problem Statement",
        draft-melia-mipshop-mobility-services-ps-00 (work in progress),
        September 2006.

   [2]  Cheshire, S. and M. Krochmal, "Multicast DNS",
        draft-cheshire-dnsext-multicastdns-06 (work in progress),
        August 2006.

   [3]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

   [4]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
        RFC 3315, July 2003.

   [5]  Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
        Location Protocol, Version 2", RFC 2608, June 1999.

   [6]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.

Appendix A.  Acknowledgements

   Thanks to Andrew McDonald for his inputs.  This revised version of
   the draft followed comments from Subir Das, Junghoon Jee, Yoshihiro
   Ohba, Akbar Rahman, Behcet Sarikaya and Qiaobing Xie.

   Eleanor Hepworth and Robert Hancock are partly funded by Ambient
   Networks, a research project supported by the European Commission

Hepworth, et al.         Expires April 26, 2007                [Page 17]

Internet-Draft          MIH Design Considerations           October 2006

   under its Sixth Framework Program.  The views and conclusions
   contained herein are those of the authors and should not be
   interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the Ambient Networks
   project or the European Commission.

Authors' Addresses

   Eleanor Hepworth
   Roke Manor Research Ltd
   Roke Manor
   Romsey,   SO51 0ZN
   UK

   Email: [email-masked]

   Robert Hancock
   Roke Manor Research Ltd
   Roke Manor
   Romsey,   SO51 0ZN
   UK

   Email: [email-masked]

   Srinivas Sreemanthula
   Nokia Research Center
   6000 Connection Dr.
   Irving,   TX 75028
   USA

   Email: [email-masked]

   Stefano Faccin
   Intel Corporation
   Santa Clara, CA
   USA

   Email: [email-masked]

Hepworth, et al.         Expires April 26, 2007                [Page 18]

Internet-Draft          MIH Design Considerations           October 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Hepworth, et al.         Expires April 26, 2007                [Page 19]

---

From: Sam Xia <[email-masked]>
Date: Wed, 28 Feb 2007 18:09:23 +0800

Hi all, 
 please see the inline.

 Best Regards, Sam Xia 

  _____  

From: Telemaco Melia [mailto:[email-masked]] 
Sent: Tuesday, February 27, 2007 11:11 PM
To: Srinivas Sreemanthula
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] A modest proposal

Hi all,

Please see in line.

[section2. para5] the interface between the service layer and the common
protocol functionality is very important
and has the key impacts on the designing of the common protocol
functionality.

Would be an option having considerations discussing where the MIHF is
co-located/located?
As an example, in the case it is co-located with the AR and we could use the
proxy mode 
support from 802.21 (especially for ES and CS) to reduce the problem space. 

Since MIHF/802.21 does not address how to transport MIH service messages
between peers, could we 
extend MIHF and add a configure interface to the users of MIH services. The
configure interface
could be used to configure peer name etc. I think it is very important and
useful to provide the user 
of MIH service  with a sort of ability to set the peer name.
Comments?
 
Agree.
 
I recall a discussion I had with Robert last meeting in San Diego about path
decoupled discovery mechanisms. 
I guess some of the concepts (just discard the specific solution) can be
derived from draft-hancock-nsis-pds-problem-04.
Comments?

Agreed.

section 3.9.

to have in transport.

We should also be able to configure the transport layer to work with the Ack
system specified in 802.21.
The reason is that events are time critical and timely delivery is
important. In the case we rely on the transport layer retransmission 
mechanism the information to be re-sent is always the same. If the 802.21
acknowledgment system is used instead we might be 
able to update information while being re-sent.

regards,
tele

employ their own.

-----Original Message-----

To: Hancock, Robert

  

  

  i) First of all, time is very short and I do  not know all DT 

members are

  

members (if

time for discussion.

we report to the WG.

    

[email-masked]

[email-masked]