Subject: RE: [eap] Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request

From: "Lortz, Victor" <[email-masked]>
Date: Wed, 13 Aug 2003 08:24:23 -0700

Given that the current draft talks about the NUL character and the
undefined data after it, looks like we have everything we need for
the placeholder part in RFC 2284bis. Therefore, a future draft
could specify what the undefined data exactly is, and use as much
time as is needed to discuss XML vs. OIDs vs. ASCII and backwards
compatibility with current practise.

<vbl> We intend to actively work on this problem. If anyone is interested, please contact me or Farid ([email-masked])</vbl>

Personally, I like Victor's idea of a namespace separator. Another
possibility is simply allowing a vendor specific attribute (no need
for all the expressive power of XML). Say, vendor:5:foo where "vendor"
is the keyword that starts a VSA, "5" is the enterprise number of
the vendor, and "foo" is the real attribute name. Again, existing
implementations would probably think of "vendor:5:foo" as an
unidentified attribute. (Do the existing implementations consider
":" as a possible character in an attribute name?)

<vbl> The namespace separator is equivalent to your vendor:5:foo proposal, except that it can be more efficient space-wise at the cost of slightly more complex processing.  The name entropy needed to prevent collisions can be put in one place in the prefix definition rather than being repeated for every vendor-specific attribute (i.e., eapns:v=urn:vendor.com:net-info:1, v:foo=some value, v:bar=some other value).  If "vendor:5" is unique, then this example becomes:  eapns:v=vendor:5, v:foo=some value, v:bar=some other value.  Once you get beyond two or three custom attributes, the namespace notation begins saving space.  </vbl>

Anyway, I'm hoping we are not starting to employ EAP for all sorts
of parameter passing, as Bernard has pointed out there are indeed
some MTU issues. Lets be strict on what makes sense to carry over
EAP.

<vbl> Agreed.  The MTU limit is real, and we need to be conservative about what information would be appropriate for this particular EAP channel.  The lack of security for this message also limits what one might consider putting in the message.  I see this as one piece in a network bootstrapping problem, and it should not be used to solve every network discovery problem but rather work in complementary fashion with other mechanisms. </vbl>

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap