draft-ietf-dhc-dhcpv6-opt-netboot-07

[Alfred Hönes]

Hello again,
I have studied the most recent DHCPv6 Netboot draft,
draft-ietf-dhc-dhcpv6-opt-netboot-07, from scratch and have
one serious concern, one security considerations issue,
and a few editorials to mention.


(1) Major issue:
  Confusion about URIs, IRIs, and URLs, and appropriate charsets.

The draft is inconsistent in the use of "URL" vs. "URI".
If it really wants to use URIs, it should use the more modern
term, and not "URL".
Per STD 66 (RFC 3986) URIs per definition are tied to the US-ASCII
charset.  You specify UTF-8 for the "boot-file-url" field.
That does not make sense.  Even if you have an IRI (represented in
UTF-8), it would have to be converted to US-ASCII, according to
RFC 3987, before it can be handed out as a URI (or "URL").
If you really want to use IRIs instead (PS so far, subject to
revision), you can stay with UTF-8, but **please** refrain from
calling them "URL", and rename all fields and code point identifiers
to clearly say so.
For IRIs, there's no such term like "IRL"; this might be interpreted
as RFC 3987 envisioning that, for the foreseeable future, an IRI
intended to be specifically used as *locators* would have to be
transformed into a URI to be called "URL".

Arguably, there is value in emphasizing that the URI/IRI passed in
the Boot URI/IRI Option must be a resource _locator_, i.e. directly
resolvable to a protocol and a network object addressable and
accessible via that protocol; but if you want UTF-8 and hence IRIs,
the language needs to be changed, e.g.:
  an URL to a boot file  -->  an IRI directly resolving to a boot file

The most striking examples of inconsistency are ...
in the 1st para of Section 3.1,
                              vvvvv
|  This option consists of an UTF-8 string.  It is sent by the server to
|  inform the client about an URL to a boot file.
                              ^^^
and in the field explanation near the end of that section,

|  boot-file-url     This UTF-8 string is the URL for the boot file, as
|                    defined in [RFC3986].  The string is not NUL-
                     terminated.

STD 66, [RFC3986], specifies US-ASCII for URLs/URIs, not UTF-8.


(2)  Issue: Unrealistic text in Security Considerations

Section 7, in its last paragraph, contains an allusion to HTTPs usage.
Is that, realistically, an option in a Boot ROM environment???
Serious use of HTTPS includes certificate and certificate path
validation, online CRL lookup, or OCSP or SCVP usage, etc.
Where should the necessary trust anchors come from at the Boot ROM
level?
(And also please note that RFC 2817 is _not_ related to HTTPS;
 it describes the inband protocol mechanism to "upgrade" to TLS
 after establishing a HTTP connection, as it is done for POP, IMAP,
 NETCONF, etc., and would be preferred by the management of the
 Port Numbers registry, which in the future will no more admit
 registering a distinct port number for the same protocol/service
 over TLS, as did RFC 2818 for HTTPS.)

More realistically, physical network security or link-layer crypto
might be an option for specific deployments, and that should perhaps
be spelled out in the draft.
In some environments, the TCP MD5 option (RFC 2385) or its possible
successor discussed in TCPM (TCP-AO, the TCP Authentication Option)
with preconfigured static keys may be a perspective for integrity
protection of the boot file download in certain scenarios where
link-level crypto is not available.


(3) General textual issue: length field descriptions

There seems to be textual confusion between the length of a field
and the (overall) length of a DHCP option, with much verbiage added
with the apparent intent to clarify the (IMO) improper terms used.
The length field of a DHCPv6 Option generally specifies the length
ot the option value.  If the option value consists of a single data
field, the shortmost and most precise phrase possible would be to
simply say so for the length.  Using positive language enumerating
what is included seems to be much more clear and preferable over
using "subtractive" notion.

(3a)  in Section 3.1

|  option-len        Length of the Boot File URL option in octets (not
|                    including the size of the option-code and option-
|                    len fields).
---
|  option-len        Length of the boot-file-url in octets.

(Or substitute "boot-file-uri" or "boot-file-iri" as appropriate
based on the resolution for item (1) above.)

(3b)  in Section 3.2

|  option-len        Length of the Boot File Parameters option in octets
|                    (not including the size of the option-code and
|                    option-len fields).
---
|  option-len        Cumulative length of the boot file parameters and
|                    their length fields, in octets.

(3c)  in Section 3.3

Please also not that the specific designation of the field from the
diagram should be used for clarity!

|  option-len          Length of the "processor architecture type" field
|                      in octets (not including the option-code and
|                      option-len fields).  It MUST be an even number
                       greater than zero.  See [RFC4578] section 2.1 for
                       details.
---
|  option-len          Length of the "Architecture Types" field in
|                      octets.  It MUST be an even number greater than
                       zero.  See [RFC4578] section 2.1 for details.


(4)  more editorial nits

(4a)  Section 1, 3rd para

missing article:

|                 ... configuration files from central server, ...
---
|                 ... configuration files from a central server, ...

(4b)  Section 3.3, 2nd-to-last para -- singular/plural issues

   The client can use this option to send a list of supported
   architecture types to the server, so the server can decide which boot
|  file should be provided to the client.  If a clients supports more
        vvv                     v             ^       ^
|  than one pre-boot environments (for example both, 32-bit and 64-bit
   executables), the most preferred architecture type MUST be listed as
   first item, followed by the others with descending priority.
---
   The client can use this option to send a list of supported
   architecture types to the server, so the server can decide which boot
|  file should be provided to the client.  If a client supports more
|  than one pre-boot environment (for example both, 32-bit and 64-bit
   executables), the most preferred architecture type MUST be listed as
   first item, followed by the others with descending priority.

(4c)  Section 3.4

Please expand the acronym "UEFI" on first use.

Isn't UNDI and this option very much vendor specific for a specific
kind of processor architecture?  Therefore, the first sentence,

|  The Client Network Interface Identifier option is sent by a DHCP
|  client to a DHCP server to provide information about its level of
|  Universal Network Device Interface (UNDI) support (see also [PXE21]
|  and [UEFI23]).

seems to express the need to send this option in too strong language.
How about (and changing from passive to active voice as well, as
recommended by the RFC style guide):

|  If the client supports the Universal Network Device Interface (UNDI)
|  (see [PXE21] and [UEFI23]), it may send the Client Network Interface
|  Identifier option to a DHCP server to provide information about its
|  level of UNDI support.

(maybe s/may/MAY/ )

(4d)  Section 5, 1st para -- missing article

                                                    [...]  Please note
   that for IPv6, this supersedes [RFC906] which recommended to use TFTP
|  for downloading (see [RFC3617] for TFTP URL definition).
---
                                                    [...]  Please note
   that for IPv6, this supersedes [RFC906] which recommended to use TFTP
|  for downloading (see [RFC3617] for the TFTP URI definition).
                                      ^^^^       ^
or:
                                                    [...]  Please note
   that for IPv6, this supersedes [RFC906] which recommended to use TFTP
|  for downloading (see [RFC3617] for the 'tftp' URI definition).
                                      ^^^^^^^^^^   ^

(4e)  Section 5, 2nd para

Note that it has turned out to be convenient to enclose URI Scheme
names in single quotes, because they frequently occur in document
titles and headlines, which often get quoted and thereby enclosed
in double quotes; thus, syntax confilcts with nested double-quotes
can be avoided easily.
Furhter, anecdotal evidence has shown that presenting text that
apparently pretends the trailing colon to be part of a URI Scheme
name has caused trouble.  RFC 3986 makes it clear that the colon is
_not_ part of the URI Scheme name.

Therefore, I suggest to change:

|  When using iSCSI for booting, the "iscsi:"-URI is formed as defined
   in [RFC4173].  [...]
---
|  When using iSCSI for booting, the 'iscsi' URI is formed as defined
   in [RFC4173].  [...]

(4f)  general: detailed citations

Please enhance the language and readability by switching from
terse  "[RFCxxxx] section zz"  style to  "Section zz of [RFCxxxx]".


Kind regards,
  Alfred Hönes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@...                     |
+------------------------+--------------------------------------------+

_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg

[Thomas Huth]

Hello Alfred!

Sorry for the late reply, but I got a lot of holiday stress
recently ... ;-)

Alfred Hönes <ah@...> wrote on 22/12/2009 14:47:56:

> (1) Major issue:
>   Confusion about URIs, IRIs, and URLs, and appropriate charsets.
>
> The draft is inconsistent in the use of "URL" vs. "URI".
> If it really wants to use URIs, it should use the more modern
> term, and not "URL".

Actually we really mean URL, not URI, since IMHO it does not make too much
sense to boot from a URN.

> Per STD 66 (RFC 3986) URIs per definition are tied to the US-ASCII
> charset.  You specify UTF-8 for the "boot-file-url" field.

That's also what I've originally thought and we had this in an older
version of our draft, but Ted Lemon told us to use UTF-8 instead:

http://www.ietf.org/mail-archive/web/dhcwg/current/msg10165.html

Ted, any comments on this?

> That does not make sense.  Even if you have an IRI (represented in
> UTF-8), it would have to be converted to US-ASCII, according to
> RFC 3987, before it can be handed out as a URI (or "URL").
> If you really want to use IRIs instead (PS so far, subject to
> revision), you can stay with UTF-8, but **please** refrain from
> calling them "URL", and rename all fields and code point identifiers
> to clearly say so.

I think we should not use IRIs here. I guess most firmware implementations
do not have a full blown i18n implementation and if I've got RFC3987 right,
HTTP also does not work well with IRIs:

"On the other hand, in the HTTP protocol [RFC2616], the Request URI is
defined
 as a URI, which means that direct use of IRIs is not allowed in HTTP
requests."

So I think we should stay with URLs in our draft.,

> (2)  Issue: Unrealistic text in Security Considerations
>
> Section 7, in its last paragraph, contains an allusion to HTTPs usage.
> Is that, realistically, an option in a Boot ROM environment???
> Serious use of HTTPS includes certificate and certificate path
> validation, online CRL lookup, or OCSP or SCVP usage, etc.
> Where should the necessary trust anchors come from at the Boot ROM
> level?

I think this is just a matter of firmware implementation. If somebody has
really need for this, it can be implemented in firmware, too.>
And IIRC, HTTPS for booting has been suggested by someone at the IETF 74
meeting in San Francisco, so there seems to be real interest in this topic
(I wasn't there at that meeting, so maybe one of the attendees can say
something about this? Vincent?)

> (3) General textual issue: length field descriptions
>
> There seems to be textual confusion between the length of a field
> and the (overall) length of a DHCP option, with much verbiage added
> with the apparent intent to clarify the (IMO) improper terms used.
> The length field of a DHCPv6 Option generally specifies the length
> ot the option value.  If the option value consists of a single data
> field, the shortmost and most precise phrase possible would be to
> simply say so for the length.  Using positive language enumerating
> what is included seems to be much more clear and preferable over
> using "subtractive" notion.

Ok... I thought some explicit words might help here to make it easier to
read, but if people prefer it more condensed, that's fine for me, too. So
has anybody else any thoughts on this?

> (4)  more editorial nits
>
[...]

Ok, thanks for spotting these! I will correct them with the next update.


Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Dirk Wittkopp        
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen      
    Tel.: [phone]          Registergericht: Amtsgericht          
                                    Stuttgart, HRB 243294                  
                                                                           


_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg

[Ted Lemon-2]

On Dec 27, 2009, at 6:14 AM, Thomas Huth wrote:
> That's also what I've originally thought and we had this in an older
> version of our draft, but Ted Lemon told us to use UTF-8 instead:
> Ted, any comments on this?

I think going against the RFC is a bad idea.   I agreed to UTF8 because someone proposed it and it sounded right.   What I would do is make sure that this RFC isn't being revised now to allow UTF8.   Lisa Dusseault would probably know one way or the other.   If it's not being revised, go with the current spec.   If it is being revised, and now specifies UTF8, go with that.

> Ok... I thought some explicit words might help here to make it easier to
> read, but if people prefer it more condensed, that's fine for me, too. So
> has anybody else any thoughts on this?

Less is more.   :')

_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg

[Zimmer, Vincent]

Yes.   There are a plurality of security considerations possibly.   Given the state of DHCP security and our attempt to have some behavior parity with IPV4 netboot, we were not intending exhaustive treatment of this subject area.

You are correct Thomas that HTTP-S was added based upon the suggestion of a Lucent engineer during IETF74 dhc session in SF as a possibility.  

From the UEFI perspective, we prefer the following approach as described in the draft:

   or that the boot loader
   implementation implement a mechanism for signing boot images and a
   configurable signing key in memory, so that if a malicious image is
   provided, it can be detected and rejected.

to address issues of a DHCP hijacking or other MITM attacks.

Vincent


-----Original Message-----
From: dhcwg-bounces@... [mailto:dhcwg-bounces@...] On Behalf Of Thomas Huth
Sent: Sunday, December 27, 2009 3:14 AM
To: Alfred Hönes; dhcwg@...
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

Hello Alfred!

Sorry for the late reply, but I got a lot of holiday stress
recently ... ;-)

Alfred Hönes <ah@...> wrote on 22/12/2009 14:47:56:

> (1) Major issue:
>   Confusion about URIs, IRIs, and URLs, and appropriate charsets.
>
> The draft is inconsistent in the use of "URL" vs. "URI".
> If it really wants to use URIs, it should use the more modern
> term, and not "URL".

Actually we really mean URL, not URI, since IMHO it does not make too much
sense to boot from a URN.

> Per STD 66 (RFC 3986) URIs per definition are tied to the US-ASCII
> charset.  You specify UTF-8 for the "boot-file-url" field.

That's also what I've originally thought and we had this in an older
version of our draft, but Ted Lemon told us to use UTF-8 instead:

http://www.ietf.org/mail-archive/web/dhcwg/current/msg10165.html

Ted, any comments on this?

> That does not make sense.  Even if you have an IRI (represented in
> UTF-8), it would have to be converted to US-ASCII, according to
> RFC 3987, before it can be handed out as a URI (or "URL").
> If you really want to use IRIs instead (PS so far, subject to
> revision), you can stay with UTF-8, but **please** refrain from
> calling them "URL", and rename all fields and code point identifiers
> to clearly say so.

I think we should not use IRIs here. I guess most firmware implementations
do not have a full blown i18n implementation and if I've got RFC3987 right,
HTTP also does not work well with IRIs:

"On the other hand, in the HTTP protocol [RFC2616], the Request URI is
defined
 as a URI, which means that direct use of IRIs is not allowed in HTTP
requests."

So I think we should stay with URLs in our draft.,

> (2)  Issue: Unrealistic text in Security Considerations
>
> Section 7, in its last paragraph, contains an allusion to HTTPs usage.
> Is that, realistically, an option in a Boot ROM environment???
> Serious use of HTTPS includes certificate and certificate path
> validation, online CRL lookup, or OCSP or SCVP usage, etc.
> Where should the necessary trust anchors come from at the Boot ROM
> level?

I think this is just a matter of firmware implementation. If somebody has
really need for this, it can be implemented in firmware, too.>
And IIRC, HTTPS for booting has been suggested by someone at the IETF 74
meeting in San Francisco, so there seems to be real interest in this topic
(I wasn't there at that meeting, so maybe one of the attendees can say
something about this? Vincent?)

> (3) General textual issue: length field descriptions
>
> There seems to be textual confusion between the length of a field
> and the (overall) length of a DHCP option, with much verbiage added
> with the apparent intent to clarify the (IMO) improper terms used.
> The length field of a DHCPv6 Option generally specifies the length
> ot the option value.  If the option value consists of a single data
> field, the shortmost and most precise phrase possible would be to
> simply say so for the length.  Using positive language enumerating
> what is included seems to be much more clear and preferable over
> using "subtractive" notion.

Ok... I thought some explicit words might help here to make it easier to
read, but if people prefer it more condensed, that's fine for me, too. So
has anybody else any thoughts on this?

> (4)  more editorial nits
>
[...]

Ok, thanks for spotting these! I will correct them with the next update.


Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Dirk Wittkopp        
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen      
    Tel.: [phone]          Registergericht: Amtsgericht          
                                    Stuttgart, HRB 243294                  
                                                                           


_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg

[Theodore Vojnovich]

Arent you really going to want to say key is provide by independent resource from the boot image resource.   Ie if key is in memory, how did it get there?   This leads to the whole thread of key mgmt and deployment.
I dont think you want to get into all that but also dont think you want limit this to just  "configurable key in memory"...maybe at least hint at the fact there may be
several simple to substantive approaches supported (since you may not care how the key got into memory....just that it did not come from same resource as boot image....otherwise might be hackable/spoofable/etc)

Just my 2 cents.

Thanks

Ted Vojnovich
STSM Blade Center Storage Solutions
IBM Corp.
N202 / B205
3039 Cornwallis Dr
RTP NC, 27709
Voice:  919-254-0730 (T/L 444-0730)
Fax: [phone]
Cell Phone:   [phone]
Email:  tbvojnov@...

"Zimmer, Vincent" <vincent.zimmer@...>
Sent by: dhcwg-bounces@...

01/06/2010 04:51 PM

To	Thomas Huth <THUTH@...>, Alfred Hönes <ah@...>, "dhcwg@..." <dhcwg@...>
cc
Subject	Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

Yes.   There are a plurality of security considerations possibly.   Given the state of DHCP security and our attempt to have some behavior parity with IPV4 netboot, we were not intending exhaustive treatment of this subject area.

You are correct Thomas that HTTP-S was added based upon the suggestion of a Lucent engineer during IETF74 dhc session in SF as a possibility.  

From the UEFI perspective, we prefer the following approach as described in the draft:

  or that the boot loader
  implementation implement a mechanism for signing boot images and a
  configurable signing key in memory, so that if a malicious image is
  provided, it can be detected and rejected.

to address issues of a DHCP hijacking or other MITM attacks.

Vincent


-----Original Message-----
From: dhcwg-bounces@... [mailto:dhcwg-bounces@...] On Behalf Of Thomas Huth
Sent: Sunday, December 27, 2009 3:14 AM
To: Alfred Hönes; dhcwg@...
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

Hello Alfred!

Sorry for the late reply, but I got a lot of holiday stress
recently ... ;-)

Alfred Hönes <ah@...> wrote on 22/12/2009 14:47:56:

> (1) Major issue:
>   Confusion about URIs, IRIs, and URLs, and appropriate charsets.
>
> The draft is inconsistent in the use of "URL" vs. "URI".
> If it really wants to use URIs, it should use the more modern
> term, and not "URL".

Actually we really mean URL, not URI, since IMHO it does not make too much
sense to boot from a URN.

> Per STD 66 (RFC 3986) URIs per definition are tied to the US-ASCII
> charset.  You specify UTF-8 for the "boot-file-url" field.

That's also what I've originally thought and we had this in an older
version of our draft, but Ted Lemon told us to use UTF-8 instead:

http://www.ietf.org/mail-archive/web/dhcwg/current/msg10165.html

Ted, any comments on this?

> That does not make sense.  Even if you have an IRI (represented in
> UTF-8), it would have to be converted to US-ASCII, according to
> RFC 3987, before it can be handed out as a URI (or "URL").
> If you really want to use IRIs instead (PS so far, subject to
> revision), you can stay with UTF-8, but **please** refrain from
> calling them "URL", and rename all fields and code point identifiers
> to clearly say so.

I think we should not use IRIs here. I guess most firmware implementations
do not have a full blown i18n implementation and if I've got RFC3987 right,
HTTP also does not work well with IRIs:

"On the other hand, in the HTTP protocol [RFC2616], the Request URI is
defined
as a URI, which means that direct use of IRIs is not allowed in HTTP
requests."

So I think we should stay with URLs in our draft.,

> (2)  Issue: Unrealistic text in Security Considerations
>
> Section 7, in its last paragraph, contains an allusion to HTTPs usage.
> Is that, realistically, an option in a Boot ROM environment???
> Serious use of HTTPS includes certificate and certificate path
> validation, online CRL lookup, or OCSP or SCVP usage, etc.
> Where should the necessary trust anchors come from at the Boot ROM
> level?

I think this is just a matter of firmware implementation. If somebody has
really need for this, it can be implemented in firmware, too.>
And IIRC, HTTPS for booting has been suggested by someone at the IETF 74
meeting in San Francisco, so there seems to be real interest in this topic
(I wasn't there at that meeting, so maybe one of the attendees can say
something about this? Vincent?)

> (3) General textual issue: length field descriptions
>
> There seems to be textual confusion between the length of a field
> and the (overall) length of a DHCP option, with much verbiage added
> with the apparent intent to clarify the (IMO) improper terms used.
> The length field of a DHCPv6 Option generally specifies the length
> ot the option value.  If the option value consists of a single data
> field, the shortmost and most precise phrase possible would be to
> simply say so for the length.  Using positive language enumerating
> what is included seems to be much more clear and preferable over
> using "subtractive" notion.

Ok... I thought some explicit words might help here to make it easier to
read, but if people prefer it more condensed, that's fine for me, too. So
has anybody else any thoughts on this?

> (4)  more editorial nits
>
[...]

Ok, thanks for spotting these! I will correct them with the next update.


Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                         
   IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
   Research & Development GmbH     Martin Jetter                          
   Schönaicher Str. 220            Geschäftsführung: Dirk Wittkopp        
   71032 Böblingen                 Sitz der Gesellschaft: Böblingen      
   Tel.: [phone]          Registergericht: Amtsgericht          
                                   Stuttgart, HRB 243294                  
                                                                         


_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg

[H. Peter Anvin]

On 01/06/2010 02:27 PM, Theodore Vojnovich wrote:

>
> Arent you really going to want to say key is provide by independent
> resource from the boot image resource.   Ie if key is in memory, how did
> it get there?   This leads to the whole thread of key mgmt and deployment.
> I dont think you want to get into all that but also dont think you want
> limit this to just  "configurable key in memory"...maybe at least hint
> at the fact there may be
> several simple to substantive approaches supported (since you may not
> care how the key got into memory....just that it did not come from same
> resource as boot image....otherwise might be hackable/spoofable/etc)
>
> Just my 2 cents.
>

Well, there really are only two options, aren't there... either the key
came from somewhere physically on the system (ROM, TPM, or even disk),
installed through some previous means, or it was fetched from some
trusted portion of the network...  Either which way it seems somewhat
outside the scope of this particular RFC.

        -hpa

_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg

[Thomas Narten]

I think I'm too blame for rasing the UTF-8 issue.

I think we want UTF-8 for the "Boot File Parameters Option". That is
just data (bytes) passed from the server to the client. The current
wording on the documents calls for UTF-8 here now and is good IMO.

For the URI/URL, I don't know the right answer. Getting someone from
that community to help us get the details right is what we need to do.

Thomas
_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg

[Thomas Huth]

Thomas Narten <narten@...> wrote on 07/01/2010 19:58:39:
>
> I think I'm too blame for rasing the UTF-8 issue.
>
> I think we want UTF-8 for the "Boot File Parameters Option". That is
> just data (bytes) passed from the server to the client. The current
> wording on the documents calls for UTF-8 here now and is good IMO.
>
> For the URI/URL, I don't know the right answer. Getting someone from
> that community to help us get the details right is what we need to do.

I've discussed this with Ted Lemon and Lisa Dusseault: RFC3986 / STD66
currently requires ASCII encoding (with percent encoding for non-ASCII
characters). But since this might be subject to change in the future, we
now simply say in version 08 of our draft that the URL string must comply
with STD66, without specifying the encoding there. So when STD66 gets
updated one day, we do not have to update the netboot document anymore.

Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Dirk Wittkopp        
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen      
    Tel.: [phone]          Registergericht: Amtsgericht          
                                    Stuttgart, HRB 243294                  
                                                                           



_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg

[Alfred Hönes]

Thomas Narten wrote:

> I think I'm too blame for raising the UTF-8 issue.
>
> I think we want UTF-8 for the "Boot File Parameters Option". That is
> just data (bytes) passed from the server to the client. The current
> wording on the documents calls for UTF-8 here now and is good IMO.

Agreed, that sounds reasonable, and that meets my expectations.

>
> For the URI/URL, I don't know the right answer. Getting someone from
> that community to help us get the details right is what we need to do.
>
> Thomas


The advice from W3C already has been fed into an IETF Full Standard:

Quoting from STD 66, RFC 3986 (Section 1.1.3, bottom of page 7):

         [...]  Future specifications and related documentation should
   use the general term "URI" rather than the more restrictive terms
   "URL and "URN" [RCF3305].

Indeed, RFC 3305 (co-published as a W3C NOTE in 2002) contains the
applicable rationale.  However, please note that a significant part
of RFC 3305 now is OBE (outdated by events), in what RFC 3305 says
"should be done" (in the IETF) has been done subsequently, to a great
extent; RFCs 3986, 3987, and 4395 are the result; unfortunately, the
URN namespace related RFCs have not been updated so far (source of
some repeated confusion!).


Kind regards,
  Alfred Hönes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@...                     |
+------------------------+--------------------------------------------+

_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg