Subject: [Ietf-behave] Re : turn-01 and REQUESTED-PORT-PROPS

From: "BREARD Gael RD-MAPS-ISS" <[email-masked]>
Date: Wed, 20 Sep 2006 08:06:42 -0500 (CDT) (envelope-from [email-masked])

>The layout of REQUESTED-PORT-PROPS in turn-01 is very different from 
>REQUESTED-PORT in turn-00. Among other things, there is no longer any place to 
>specify a port when you want to request one (28 of the 32 bits are "reserved", 
>where previously 16 bits were used for the "Port Filter" field). I also notice 
>that REQUESTED-PORT is still referred to in several places (eg in sec 10.8). 
>Was the intent to move the location of this data somewhere else (perhaps start 
>using the unused port field in REQUESTED-IP) and the document was released 
>before editing was finished, or was the removal of the "Port Filter" field 
>when going from REQUESTED-PORT to REQUESTED-PORT-PROPS just an oversight? (Or 
>did I miss something somewhere?)

Just have the same problem. No response for that ?

I would agree to use the unused port field of REQUESTED-IP (and so rename it 
REQUESTED-ADDRESS).
And why do not use reserved 8 bits of this attribute for coding requested 
transport, port alignment and allocation behavior ?
One bit should then be added to code if specific IP is requested. (if not : 
address field could be removed)

So it would give for example (field order...) :

REQUESTED-ADDRESS :

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |D|C|B| A |  E  |    Family     |           Port                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   Address  (variable)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A : for requested port alignment (idem turn-01)

   00 no specific port alignment
   01 odd port number
   10 even port number
   11 even port number; reserve next higher port

B & C : for requested port allocation behavior. (idem B turn-01)

B:
   0 no specific port requested
   1 specific port requested            (port field used only with this 
property)
C:
   1 door requested
   1 door not requested

C&&B = forbidden

D: for requested IP
   0 no specific IP requested ( => address field absent)
   1 specific IP requested      ( => address field present / family field used 
only with this property)

E: for requested transport
   000: UDP
   001: TCP

Bad (?) : only 3 bits for transport (could take some bits in family field ?)

Gaël

---

From: Laine Stump <[email-masked]>
Date: Fri, 22 Sep 2006 08:48:09 -0500 (CDT) (envelope-from [email-masked])

At 09:06 AM 9/20/2006, BREARD Gael RD-MAPS-ISS wrote:

>The layout of REQUESTED-PORT-PROPS in turn-01 
is very different from REQUESTED-PORT in 
turn-00. Among other things, there is no longer 
any place to specify a port when you want to 
request one (28 of the 32 bits are "reserved", 
where previously 16 bits were used for the 
"Port Filter" field). I also notice that 
REQUESTED-PORT is still referred to in several 
places (eg in sec 10.8). Was the intent to move 
the location of this data somewhere else 
(perhaps start using the unused port field in 
REQUESTED-IP) and the document was released 
before editing was finished, or was the removal 
of the "Port Filter" field when going from 
REQUESTED-PORT to REQUESTED-PORT-PROPS just an 
oversight? (Or did I miss something somewhere?)

No, there was never a response. For awhile I 
thought maybe I was the only one actually 
implementing code based on this spec ;-)

After reading the minutes of the last wg meeting, 
it seems like this part will change again soon 
anyway. In light of that, and lacking any 
response, I've just left our implementation using 
the old REQUESTED-PORT format (from turn-00) for 
now (which works, since I didn't put in the 
ill-fated "door" stuff), and will update it when the next draft is available.

I would agree to use the unused port field of 
REQUESTED-IP (and so rename it REQUESTED-ADDRESS).
And why do not use reserved 8 bits of this 
attribute for coding requested transport, port 
alignment and allocation behavior ?
One bit should then be added to code if specific 
IP is requested. (if not : address field could be removed)

REQUESTED-ADDRESS :

         0                   1                   2                   3

B:
   0 no specific port requested
   1 specific port requested            (port 
field used only with this property)

C:
   1 door requested
   1 door not requested

C&&B = forbidden

D: for requested IP
   0 no specific IP requested ( => address field absent)
   1 specific IP requested      ( => address 
field present / family field used only with this property)

Gaël

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 3 Oct 2006 22:21:51 -0500 (CDT) (envelope-from [email-masked])

On Sep 20, 2006, at 6:06 AM, BREARD Gael RD-MAPS-ISS wrote:

B:

C:
   1 door requested
   1 door not requested

C&&B = forbidden

As a slight tweak to what you are suggesting, I would rather see the  
protocol design enforce the C&&B forbidden by encoding this more like

00 no specific port requested and no door
01 no specific port requested and no door
10 specific port requested and no door requested
11 no specific port requested and door requested

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 3 Oct 2006 22:23:51 -0500 (CDT) (envelope-from [email-masked])

Oh, on a side note, I should mention I really have not figured out if  
I think the doors are needed or not.

The layout of REQUESTED-PORT-PROPS in turn-01 is very different  
from REQUESTED-PORT in turn-00. Among other things, there is no  
longer any place to specify a port when you want to request one  
(28 of the 32 bits are "reserved", where previously 16 bits were  
used for the "Port Filter" field). I also notice that REQUESTED- 
PORT is still referred to in several places (eg in sec 10.8). Was  
the intent to move the location of this data somewhere else  
(perhaps start using the unused port field in REQUESTED-IP) and  
the document was released before editing was finished, or was the  
removal of the "Port Filter" field when going from REQUESTED-PORT  
to REQUESTED-PORT-PROPS just an oversight? (Or did I miss  
something somewhere?)

I would agree to use the unused port field of REQUESTED-IP (and so  
rename it REQUESTED-ADDRESS).
And why do not use reserved 8 bits of this attribute for coding  
requested transport, port alignment and allocation behavior ?
One bit should then be added to code if specific IP is requested.  
(if not : address field could be removed)

REQUESTED-ADDRESS :

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  
9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+-+
        |D|C|B| A |  E  |    Family     |            
Port                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+-+

        |                   Address  (variable)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+-+

B:

C:
   1 door requested
   1 door not requested

C&&B = forbidden

D: for requested IP
   0 no specific IP requested ( => address field absent)
   1 specific IP requested	( => address field present / family  
field used only with this property)

Bad (?) : only 3 bits for transport (could take some bits in family  
field ?)

Gaël

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Oct 2006 22:48:30 -0500 (CDT) (envelope-from [email-masked])

The introduction of "doors" in turn-01 did not achieve WG consensus at the
Montreal meeting.  This was reflected in the minutes,
http://www3.ietf.org/proceedings/06jul/minutes/behave.html, which concluded
with:

  "Will remove the Door from next version of the draft."

The authors of turn have not yet to honored the working group with a new
version of the document reflecting that consensus.

-d

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Cullen Jennings
> Sent: Tuesday, October 03, 2006 8:24 PM
> To: BREARD Gael RD-MAPS-ISS
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] Re : turn-01 and REQUESTED-PORT-PROPS
> 
> 
> >          0                   1                   2          
>          3

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 4 Oct 2006 00:27:11 -0500 (CDT) (envelope-from [email-masked])

Ah, excellent - thanks for memory jog :-)

On Oct 3, 2006, at 8:48 PM, Dan Wing wrote:

The introduction of "doors" in turn-01 did not achieve WG consensus  
at the

Montreal meeting.  This was reflected in the minutes,
http://www3.ietf.org/proceedings/06jul/minutes/behave.html, which  
concluded

with:

The authors of turn have not yet to honored the working group with  
a new

-d

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

Oh, on a side note, I should mention I really have not
figured out if
I think the doors are needed or not.

REQUESTED-ADDRESS :

         0                   1                   2

         3

+-+-+
        |D|C|B| A |  E  |    Family     |
Port                |

+-+-+
        |                   Address  (variable)

+-+-+

B:
   0 no specific port requested
   1 specific port requested            (port field

used only with this

property)
C:
   1 door requested
   1 door not requested

C&&B = forbidden

D: for requested IP

Bad (?) : only 3 bits for transport (could take some bits

in family

field ?)

Gaël