Subject: draft-ietf-krb-wg-gss-cb-hash-agility-01.txt

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 19 Mar 2007 03:22:56 -0700

This ID talks about "channel binding identifies", do you mean
"entities"?

Section 3 seems to have a mixed up in using "typed data" encoding and
the new extension encoding". Can you look into this.

"network-byte order" is not referenced, do you mean big endian order?

The extension field should have an label for criticality. 

The client does not know if the server understands the new channel
binding mechanisms. Do we want to solve this issue now?

---

From: Shawn M Emery <[email-masked]>
Date: Mon, 19 Mar 2007 07:29:27 -0600

Liqiang(Larry) Zhu wrote:
>
> This ID talks about “channel binding identifies”, do you mean “entities”?
>

Identity of a communication channel.

> Section 3 seems to have a mixed up in using “typed data” encoding and 
> the new extension encoding”. Can you look into this.
>

data-type and data-value is an "Exts" where the length field is implied 
(from data-value's length).

> “network-byte order” is not referenced, do you mean big endian order?
>

Yes.

> The extension field should have an label for criticality.

The GSS checksum structure specifies one, which includes "Exts".

> binding mechanisms. Do we want to solve this issue now?

It does in the case that the initiator policy dictates that it must not 
use MD5. Acceptors would then return GSS_S_BAD_BINDINGS.

For the case in which a new initiator does not have a strict policy then 
yes, it will not know if the acceptor had used the new checksum. 
However, I don't think that this has to be known as the 
application/platform will need to negotiate channel binding outside of 
the mechanism (e.g. GSS_C_NO_CHANNEL_BINDING would not be used).

Shawn.
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Mar 2007 04:36:12 -0500

> This ID talks about "channel binding identifies", do you mean

"channel binding identifiers" is fine, as is "channel binding octet
string" and what not.  It's just an octet string really (RFC2744
notwithstanding).

> "network-byte order" is not referenced, do you mean big endian order?

"network-byte order" is widely understood to mean big-endian.  Is there
a definition for either term that RFCs should normatively reference?

> The extension field should have an label for criticality. 

This was discussed at yesterday's meeting.  I believe we don't need such
a thing and we can always add one later (the reverse of AD-IF-RELEVANT)
if we need it.

> binding mechanisms. Do we want to solve this issue now?

This was discussed at yesterday's meeting as well.  The answer is no,
because the initiator as it is doesn't get any indication that the
acceptor application did provide channel bindings and that the acceptor
mech verified them (if the app provides null bindings then the mech will
ignore the initiator's bindings).  And that's OK because apps have to
negotiate the use of channel binding before initiating the security
context anyways.  If we really have to we can provide feedback to the
initiator when rfc1510ter is finished using a typed-hole in the AP-REP.

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 20 Mar 2007 03:14:12 -0700

>string" and what not.  It's just an octet string really (RFC2744
 
good. fix the spelling error then. i.e. replace "identities" with "identifiers". 
 
>a thing and we can always add one later (the reverse of AD-IF-RELEVANT)
I like this idea. this addresses my concern for this.
 
>"network-byte order" is widely understood to mean big-endian.  Is there
just use the term big-endian order, this is to be consistent with RFC4121.
 
> initiator when rfc1510ter is finished using a typed-hole in the AP-REP.

given that the criticality concern is addressed, I can withraw this comment.

________________________________

From: Nicolas Williams [mailto:[email-masked]]
Sent: Tue 3/20/2007 2:36 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: draft-ietf-krb-wg-gss-cb-hash-agility-01.txt

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 25 Mar 2007 17:16:38 -0400 (EDT)

> a definition for either term that RFCs should normatively reference?

See RFC2223bis and IEN 137.  But generally, no.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Mon, 26 Mar 2007 17:39:28 +0200 (MET DST)

> a definition for either term that RFCs should normatively reference?

I find both "network-byte-order" and "big-endian" confusing,
and would really prefer the self-explaining term

    most significant octet first
 or
    least significant octet first

which is also used in RFC-2743 (GSS-APIv2u1)
Section 3.2 Mechanism-independent exported name object format.

The term "network-byte order" is bad because it contains no clue
whatsoever, one could equally say "foo" or "bar".  I would still
need to google or wikipedia to find out even today.

The term "big-endian" is a problem because it is ambiguous.
When I first try to implement big-endian, I implemented it as "big end",
which is *NOT* how it is meant.

A self-descibing term is much better than a "pretty name".
I got "most significant octet first" intuitively right, and I'm pretty
confident that others will understand it, too.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Mar 2007 11:25:21 -0500

> Section 3.2 Mechanism-independent exported name object format.

Following the lead of RFC2743 here is certainly fine, but I do believe
that "network-byte-order" and "big-endian" are generally as well-
understood as the term "byte" -- or at least they used to be.

The term "little-endian" is less well understood (since for values
larger than 16-bits there are multiple possible non-big-endian byte
orders).

> need to google or wikipedia to find out even today.

Network-byte order goes back a long way and means big-endian.  It seems
a bit unfair and non-representative since it's a way of saying that
little-endian systems are not the norm (when, in fact, they are).

> which is *NOT* how it is meant.

?

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Mon, 26 Mar 2007 19:32:01 +0200 (MET DST)

> understood as the term "byte" -- or at least they used to be.

Those who *are* using the terms "network byte order" and "big-endian"
should be aware of what they mean (I assume).  For those that don't
know these terms will have to use google to find out what they mean.

I would really prefer a self-describing term.  

> > which is *NOT* how it is meant.

A big-endian has actually a little end, and the big end FIRST.
Maybe that confusion is only about non-native speakers, but
I believe that "big-endian" is bad, because it has been used to
describe just the opposite of what the two words itself appear to imply.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Mar 2007 12:41:03 -0500

> describe just the opposite of what the two words itself appear to imply.

Being a native English speaker is not very relevant to understanding the
etymology of "big-endian" and "little-endian" (see the wikipedia page).

Nico
--

---

From: Shawn M Emery <[email-masked]>
Date: Tue, 27 Mar 2007 13:47:49 -0600

Earlier in the document, it defines "big endian order" as "the 
most-significant-octet-first encoding".
I should be sufficient. The next revision of the draft will use "big 
endian order", instead
of "network-byte order".  I think that this was the only issue so far 
with revision 1 of the document?

Shawn.
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 28 Mar 2007 00:24:39 +0200 (MEST)

> with revision 1 of the document?

I really want to see the terms "big endian" and "network-byte order"
removed entirely from the document and only an expression like

being used.

I think it is a bad idea to use funky and confusing
names where a suitable self-describing term is available.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Mar 2007 17:54:31 -0500

> names where a suitable self-describing term is available.

So you object even to the use of one idiom with the other in
parenthesis?

Let's find a reasonable way to resolve this, such as: whatever is the
common idiom for describing byte order on the wire in IETF documents is
what we should do.  If you wish make that _recent_ IETF docs.

Since you're the one complaining :) I nominate you to find out what that
idiom is ;)

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Mar 2007 19:04:59 -0400

> names where a suitable self-describing term is available.

Martin, these terms are neither funky nor confusing; they are 
well-established terms of art.  The terms "little-endian" and "big-endian", 
as they apply to byte order, were defined over 25 years ago in IEN137; 
please read that document.  If you have a chance, you should also read 
reference [6] therein, which, besides being a timeless example of good 
social commentary, is also a pretty good story.

<hat type="chair" state="on">
This whole argument is getting a little silly, and I'd like to see it end 
sooner, rather than later.  Please reach a compromise, and soon.
</hat>

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Wed, 28 Mar 2007 01:10:26 +0200 (MEST)

> So you object even to the use of one idiom with the other in

It should be ok to mention at one place in the document that
"most significant octet first" is sometimes also refered to as
"big-endian" or "network byte order",  but none of the latter
two should ever be mentioned without being accompanied what it
really means, i.e. most significant octet first" 

-Martin

> Since you're the one complaining :) I nominate you to find out what that

As I said, this is not about preference of one funky word over another,
it is about using an intuitivly self-describing term instead of one for
which you need a dictionary to understand how to implement on your
first encounter.

I really don't care how often "network byte order" and/or "big-endian"
is used elsewhere.  I have seen these terms often during the last
15 years.  But I also have had to look them up at least 10 times
during that time (the last time was yesterday) to find out that
they refer to "most significant byte first".

-Martin