Subject: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt

From: "Adam Fisk" <[email-masked]>
Date: Wed, 16 May 2007 14:36:17 -0400

As others have mentioned, I found the Message Type section to be a little
opaque.  Is the diagram a format that's in common use, and I just haven't
seen it?  Why does it start with M11 and opposed to M0, reading from left to
right?

I understand the unique location of the class bits is for backwards
compatibility, but I just found it difficult to quickly grok where I should
put those darn bits for the field as a whole (C1 and C0 weren't the
confusing part).  The "1" and "0" on the second line appear to be there to
keep everything aligned, but couldn't there just an extra space after those
two "M"s, as in:

+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
|M |M |M|M|M|C|M|M|M|C|M|M|M|M|
|11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+

I at first thought the extra lines signified extra mysterious bits.  I also
still don't understand why it doesn't start with 0 reading from left to
right.

Thanks.

-Adam
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 May 2007 11:47:01 -0700

I agree your figure is easier to read.  We'll adopt that for the next
revision of rfc3489bis.  

I don't understand, though, why you would want to reverse the bit numbering?

-d

> -----Original Message-----
> From: Adam Fisk [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2007 11:36 AM
> To: [email-masked]
> Subject: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt
> 
> As others have mentioned, I found the Message Type section to 
> be a little opaque.  Is the diagram a format that's in common 
> use, and I just haven't seen it?  Why does it start with M11 
> and opposed to M0, reading from left to right?  
> 
> I understand the unique location of the class bits is for 
> backwards compatibility, but I just found it difficult to 
> quickly grok where I should put those darn bits for the field 
> as a whole (C1 and C0 weren't the confusing part).  The "1" 
> and "0" on the second line appear to be there to keep 
> everything aligned, but couldn't there just an extra space 
> after those two "M"s, as in: 
> 
> I at first thought the extra lines signified extra mysterious 
> bits.  I also still don't understand why it doesn't start 
> with 0 reading from left to right. 
> 
> Thanks.
> 
> -Adam
> 
>

---

From: "Adam Fisk" <[email-masked]>
Date: Wed, 16 May 2007 15:25:00 -0400

I guess I'm asking a question as much as suggesting a revision with the bit
numbering.  Since bit twiddling is right up there with complicated threading
as far as making my head hurt quickly, I'll be explicit.  In my
understanding, a binding request is:

0x0001

and a successful binding response is:

0x0101

Assuming that's right, I guess I just think of numbering of the bits as
moving from left to right, much as it does in the previous diagram "Figure
2: Format of a STUN Message Header" right above the one in question.  I
guess the "11" is to signify that it's the most significant bit?  Maybe
that's seen as helpful in the subsequent discussion of the class numbering?

Please forgive me if I'm just confused.

-Adam

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 May 2007 12:55:33 -0700

> Sent: Wednesday, May 16, 2007 12:25 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [BEHAVE] message type in 
> draft-ietf-behave-rfc3489bis-06.txt
> 
> I guess I'm asking a question as much as suggesting a 
> revision with the bit numbering.  Since bit twiddling is 
> right up there with complicated threading as far as making my 
> head hurt quickly, I'll be explicit.  In my understanding, a 
> binding request is: 
> 
> 0x0001

Yes, C=00, and M=000000000001

> and a successful binding response is:

Yes, C=1, and M=000000000001.  The on-the-wire representation would be
100000001 which is 0x0101 in hex.  Google has a hex calculator with more
binary digits than my old TI calculator,
http://www.google.com/search?q=0b100000001+in+hex

> Assuming that's right, I guess I just think of numbering of 
> the bits as moving from left to right, much as it does in the 
> previous diagram "Figure 2: Format of a STUN Message Header" 
> right above the one in question.  I guess the "11" is to 
> signify that it's the most significant bit? 

Correct.

> Maybe that's 
> seen as helpful in the subsequent discussion of the class numbering? 
> 

If you're confused, the text or figure needs improvement or needs an
example.  This isn't the first time this was brought up.  It is
unfortunately unavoidable at this point and is a pain.

Would C examples, such as from
http://www1.ietf.org/mail-archive/web/behave/current/msg01955.html, be
helpful?  I expect we could put that into an appendix.

-d

> 	> From: Adam Fisk [mailto:[email-masked] ]

---

From: Parakram Khandpur <[email-masked]>
Date: Wed, 16 May 2007 13:38:23 -0700

Hi
I am looking to get some data on NAT deployments in home scenarios. Specifically, I'm trying to find out the %age numbers (or even a qualitative measure) for the scenario where there are multiple network subnets or multilevel NAT'ing within the same home. One possible way of having multiple subnets/multilevel NAT'ing would be if a user buys a wireless router and plugs its WAN port into the one of the LAN ports of an existing wired router.

Thanks
-Parakram

-----Original Message-----
From: Dan Wing [mailto:[email-masked]]
Sent: Wednesday, May 16, 2007 12:56 PM
To: 'Adam Fisk'
Cc: [email-masked]
Subject: RE: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt

Correct.

-d

---

From: "Adam Fisk" <[email-masked]>
Date: Wed, 16 May 2007 18:26:43 -0400

I think just one example would do wonders, Dan, yeah.  The earlier thread
you referenced was useful in verifying I was reading the diagram correctly,
but it seems like overkill for the draft itself.

Just having the example of a successful binding response as 0x0101 would
have been sufficient to move me along a little faster, or any example along
those lines.

Thanks very much.

-Adam

---

From: Benny Prijono <[email-masked]>
Date: Fri, 18 May 2007 17:57:32 +0100

I think this topic has been going over and over again on this list, 
so putting a C snippet to confirm the bits interpretation in 
appendix would clarify this once and for all, so I support that. I 
don't think it's overkill, RTP also has C snippet and it's been very 
useful for implementors.

Just my 0.02p.

  -benny

Adam Fisk wrote:
> I think just one example would do wonders, Dan, yeah.  The earlier 
> thread you referenced was useful in verifying I was reading the diagram 
> correctly, but it seems like overkill for the draft itself. 
> 
> have been sufficient to move me along a little faster, or any example 
> along those lines.
> 
> Thanks very much.
> 
> -Adam
> 
> 
> On 5/16/07, *Dan Wing* <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>      > From: Adam Fisk [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      > Cc: [email-masked] <mailto:[email-masked]>

-- 
Benny Prijono
http://www.pjsip.org

---

From: Colin Perkins <[email-masked]>
Date: Mon, 21 May 2007 12:14:58 +0100

On 18 May 2007, at 17:57, Benny Prijono wrote:
> don't think it's overkill, RTP also has C snippet and it's been  
> very useful for implementors.

Sure, but be careful about portability - the code in RFC 3550  
confuses many since it assumes a big-endian system, which is less  
than common these days.

-- 
Colin Perkins
http://csperkins.org/