Subject: [AVT] Further comments on Section 4 of draft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt

From: "Glen Zorn" <[email-masked]>
Date: Thu, 16 Dec 2010 19:59:42 +0700

I wonder why the Control Packet Type is hard-coded here & not requested from
IANA.

Section 4.2 says "A relative expiration time of zero indicates that the
accompanying Token is not valid."  Why would a server return an invalid
token?  It seems that this constitutes an error indication; what remedying
action (if any) should the client take?

Section 4.3 says "The client MUST NOT send a Token Verification Request
message with a Token that has expired."  Why not?  More precisely, why is
this a MUST NOT instead of a SHOULD NOT?  Does something catastrophic
happen?  What if a client sends a Token Verification Request containing an
invalid token (e.g., one received in a Port Mapping Response message
containing a relative expiration time of 0)?

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 16 Dec 2010 05:11:31 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Zorn
> Sent: Thursday, December 16, 2010 8:00 AM
> To: [email-masked]
> Subject: [AVT] Further comments on Section 4 ofdraft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt
> 

This is mostly to let others know that we reserved that value. Not that we strictly need that value, but letting others know sounded like a good idea. The work is close to be completed and we can change it if IANA will register that value till they review our material.

Co-chairs, if there is a way to reserve a value, could you let us know? I recall 5760 having some issues with this late in the game.
 
> action (if any) should the client take?

There could be multiple reasons. E.g., the client may not be eligible for that service anymore or was not eligible in the first place. 

It is up to the client what to do. It could try again later or could try another server if one is available.
 
> this a MUST NOT instead of a SHOULD NOT?  Does something catastrophic

That token will not be accepted, what is the point is sending it? "SHOULD NOT" would imply that there could be at least one scenario where it would be ok sending it. But there is none unless I am missing something.

> containing a relative expiration time of 0)?

It will generate a failure message from the server. Nothing catastrophic will happen.

-acbegen

> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 16 Dec 2010 14:38:34 +0100

> Co-chairs, if there is a way to reserve a value, could you 
> let us know? I recall 5760 having some issues with this late 
> in the game.

As far as I know, there is no way to reserve it.

The registration requirements are specification required or expert review - so there is nothing to stop IANA assigning any value elsewhere. 

It would probably be safer to use XX with a note to the RFC editor to replace it with the assigned value.

regards

Keith 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ali C. Begen (abegen)
> Sent: Thursday, December 16, 2010 1:12 PM
> To: Glen Zorn; [email-masked]
> Subject: Re: [AVT] Further comments on Section 4 
> ofdraft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt
> 
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > Glen Zorn
> > Subject: [AVT] Further comments on Section 4 
> > ofdraft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt
> > 
> > I wonder why the Control Packet Type is hard-coded here & not 
> > requested from IANA.
> 
> This is mostly to let others know that we reserved that 
> value. Not that we strictly need that value, but letting 
> others know sounded like a good idea. The work is close to be 
> completed and we can change it if IANA will register that 
> value till they review our material.
> 
> Co-chairs, if there is a way to reserve a value, could you 
> let us know? I recall 5760 having some issues with this late 
> in the game.
>  
> > Section 4.2 says "A relative expiration time of zero indicates that 
> > the accompanying Token is not valid."  Why would a server return an 
> > invalid token?  It seems that this constitutes an error indication; 
> > what remedying action (if any) should the client take?
> 
> There could be multiple reasons. E.g., the client may not be 
> eligible for that service anymore or was not eligible in the 
> first place. 
> 
> It is up to the client what to do. It could try again later 
> or could try another server if one is available.
>  
> > Section 4.3 says "The client MUST NOT send a Token Verification 
> > Request message with a Token that has expired."  Why not?  More 
> > precisely, why is this a MUST NOT instead of a SHOULD NOT?  Does 
> > something catastrophic
> 
> That token will not be accepted, what is the point is sending 
> it? "SHOULD NOT" would imply that there could be at least one 
> scenario where it would be ok sending it. But there is none 
> unless I am missing something.
> 
> > happen?  What if a client sends a Token Verification Request 
> > containing an invalid token (e.g., one received in a Port Mapping 
> > Response message containing a relative expiration time of 0)?
>