Subject: [dhcwg] [Editorial Errata Reported] RFC3495 (4128)

From: RFC Errata System <[email-masked]>
Date: Fri, 10 Oct 2014 14:14:37 -0700 (PDT)

The following errata report has been submitted for RFC3495,
"Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3495&eid=4128

--------------------------------------
Type: Editorial
Reported by: Bernie Volz <[email-masked]>

Section: 5.5.

Original Text
-------------
   The PacketCable architecture requires an MTA to authenticate itself
   to the TSP's network via the Kerberos protocol.  A Kerberos Realm
   name is required at the MTA to permit a DNS lookup for the address of
   the TSP's Kerberos Key Distribution Center (KDC) entity.

   The Kerberos Realm name MUST be encoded per the domain style realm
   name described in RFC 1510 [5].  This realm name MUST be all capital
   letters and conform to the syntax described in RFC 1035 [3] section
   3.1.  The sub-option is encoded as follows:

       Code   Len   Kerberos Realm Name
      +-----+-----+-----+-----+   +-----+
      |  6  |  n  |  k1 |  k2 |...|  kn |
      +-----+-----+-----+-----+   +-----+

Corrected Text
--------------
   The PacketCable architecture requires an MTA to authenticate itself
   to the TSP's network via the Kerberos protocol.  A Kerberos Realm
   name is required at the MTA to permit a DNS lookup for the address of
   the TSP's Kerberos Key Distribution Center (KDC) entity.

   The Kerberos Realm name MUST be use a domain style realm name
   described in RFC 1510 [5].  This realm name MUST be all capital
   letters and be encoded as described in RFC 1035 [3] section 3.1.
   The sub-option is encoded as follows:

       Code   Len   Kerberos Realm Name
      +-----+-----+-----+-----+   +-----+
      |  6  |  n  |  k1 |  k2 |...|  kn |
      +-----+-----+-----+-----+   +-----+

   Where k1...kn is the "DNS wire" encoded realm name (see RFC 3315,
   section 8). Thus, the realm "BASIC.1" is encoded as
   "RFCCORRECTED_TEXT5BASICRFCCORRECTED_TEXT11RFCCORRECTED_TEXT0".

Notes
-----
This text is not completely clear about how the realm name is to be encoded - as a 'string' or 'fqdn'.

RFC 1510 states:

   Kerberos realms are encoded as GeneralStrings. Realms shall not
   contain a character with the code 0 (the ASCII NUL).  Most realms
   will usually consist of several components separated by periods (.),
   in the style of Internet Domain Names, or separated by slashes (/) in
   the style of X.500 names.

And the reference to RFC 1035 section 3.1 is "conform to the syntax" which isn't the same as use this encoding - though I do agree that section 3.1 is mostly about "DNS wire encoding". It is just the use of "encoded" and "confirm to the syntax" combination that makes this unclear.

It is believed that the intended encoding is in DNS wire format. And, this should be clarified.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3495 (draft-ietf-dhc-packetcable-06)
--------------------------------------
Title               : Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration
Publication Date    : March 2003
Author(s)           : B. Beser, P. Duffy, Ed.
Category            : PROPOSED STANDARD
Source              : Dynamic Host Configuration
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 10 Oct 2014 22:16:18 +0000

Yes, I forgot to fix that before hitting submit and there is no way to edit. (I think a should be the too.)

I like you change, so the 2nd paragraph could be:

	The Kerberos Realm name MUST use the domain style realm name
   	described in RFC 1510 [5]. This realm name MUST be encoded as
	described in RFC 1035 [3] section 3.1, with the additional constraint
	that any letters in the realm name MUST be in upper case.

I don't understand why it put the "RFCCORRECTED" in there. The online version (URL) is correct.  See http://www.rfc-editor.org/errata_search.php?rfc=3495&eid=4128:

	Thus, the realm "BASIC.1" is encoded as "\005BASIC\0011\000".

- Bernie

-----Original Message-----
From: Karl Auer [mailto:[email-masked]] 
Sent: Friday, October 10, 2014 6:03 PM
To: RFC Errata System
Cc: [email-masked]; Paul Duffy (paduffy); [email-masked]; [email-masked]; Bernie Volz (volz); [email-masked]; [email-masked]
Subject: Re: [dhcwg] [Editorial Errata Reported] RFC3495 (4128)

On Fri, 2014-10-10 at 14:14 -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC3495, "Dynamic 
> Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration".

The first sentence of the second paragraph of the corrected text is broken. It looks as if the word "be" should be removed.

The same sentence should also contain the word "as" immediately before the word "described".

RFC 1035 section 3.1 doesn't mandate capital letters, so I suggest that the second sentence of the second paragraph of the corrected text be something like: "This realm name MUST be encoded as described in RFC
1035 [3] section 3.1, with the additional constraint that any letters in the realm name MUST be in upper case."
 
The example encoding looks wrong, but maybe I didn't dig deep enough. Is the literal string "RFCCORRECTED" really part of the encoding?

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A

---

From: Karl Auer <[email-masked]>
Date: Sat, 11 Oct 2014 09:03:10 +1100

> "Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration".

The first sentence of the second paragraph of the corrected text is
broken. It looks as if the word "be" should be removed.

The same sentence should also contain the word "as" immediately before
the word "described".

RFC 1035 section 3.1 doesn't mandate capital letters, so I suggest that
the second sentence of the second paragraph of the corrected text be
something like: "This realm name MUST be encoded as described in RFC
1035 [3] section 3.1, with the additional constraint that any letters in
the realm name MUST be in upper case."
 
The example encoding looks wrong, but maybe I didn't dig deep enough. Is
the literal string "RFCCORRECTED" really part of the encoding?

Regards, K.

GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Oct 2014 17:19:44 -0500

> the literal string "RFCCORRECTED" really part of the encoding?

RFC 1510 does mandate capital letters, so I think that base is covered.   I agree with Bernie that the text here doesn't draw the reader's attention to the fact that the encoding is DNS wire format.   Bernie, can you send me corrected text?   I don't think you need to give an actual example, just make it clear that it's DNS wire format.   Unfortunately I think without updating this RFC, it's unlikely that anybody who would miss this detail would not fail to miss the erratum.   So let's keep the erratum tight and not try to add a ton of new text.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 10 Oct 2014 23:01:54 +0000

While the extra text about an example isn't required, I think it serves a useful purpose to assure people understand how it is encoded. But if you feel we should not include it, I am fine with dropping it.

I don't know how to edit the ERRATA. Is this something that requires you're doing? Or?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, October 10, 2014 6:20 PM
To: Karl Auer
Cc: RFC Errata System; [email-masked]; Paul Duffy (paduffy); Brian Haberman; Bernie Volz (volz); Tomek Mrugalski; [email-masked]
Subject: Re: [dhcwg] [Editorial Errata Reported] RFC3495 (4128)

On Oct 10, 2014, at 5:03 PM, Karl Auer <[email-masked]> wrote:
> RFC 1035 section 3.1 doesn't mandate capital letters, so I suggest 
> that the second sentence of the second paragraph of the corrected text 
> be something like: "This realm name MUST be encoded as described in 
> RFC
> 1035 [3] section 3.1, with the additional constraint that any letters 
> in the realm name MUST be in upper case."
> 
> The example encoding looks wrong, but maybe I didn't dig deep enough. 
> Is the literal string "RFCCORRECTED" really part of the encoding?

---

From: Ted Lemon <[email-masked]>
Date: Sat, 11 Oct 2014 09:32:47 -0500

> I don't know how to edit the ERRATA. Is this something that requires you're doing? Or?

I can do the editing.   The point is that adding a lot of text in an erratum isn't really kosher.  An erratum is supposed to be pointing out an error in a document, not updating the document.   This is borderline, since what you are reporting isn't an error, just a lack of explicitness that might result in someone doing the implementation wrong.

If the document needs updated, you update it.

Personally, I think if you really care about addressing this problem, we should just quickly respin the document, because people hardly ever look at errata anyway.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 11:57:26 -0500

> I can do the editing.   The point is that adding a lot of text in an erratum isn't really kosher.  An erratum is supposed to be pointing out an error in a document, not updating the document.   Thi…

BTW, I may have been unclear when I said this.   What I mean by "I can do the editing" is that if you send me text, I can edit the document in the errata tracker.   I wasn't offering to write the text.   :)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 14 Oct 2014 17:31:43 +0000

Ted:

I'm not sure what is needed/missing. I didn't think the errata was that long (we can drop the example if people don't think it is required), so not sure how much it can be 'shortened'.

I think Karl had a good suggested correction. So, the "It should say:" portion of the errata should be updated with the following (you can drop the example if you don't think it is needed, though I think it adds a lot of clarify - the only required change is to replace the 2nd paragraph; there is no change in the first paragraph or the diagram):

   The Kerberos Realm name MUST be a domain style realm name
   described in RFC 1510 [5].  This realm name MUST be encoded as
   described in RFC 1035 [3] section 3.1, with the additional constraint
   that any letters in the realm name MUST be in upper case. The
   sub-option is encoded as follows:

   "\005BASIC\0011\000".

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 12:43:42 -0500

>   section 8). Thus, the realm "BASIC.1" is encoded as

Okay, this makes more sense now, but is it correct?   That is, given that the realm name doesn't end in dot, should there be a \000 at the end of the string?   Is "\005BASIC\0011\000" equivalent to "\005BASIC\0011" or different?   I question whether we actually can do this in an erratum: I don't think that the document as previously written addresses this issue.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 14 Oct 2014 17:48:56 +0000

DNS wire encoding says that the dot should be there if I recall. Whether that final dot is actually added to the domain name has, I believe, always been "optional".

RFC 1035 says:

   Domain names in messages are expressed in terms of a sequence of labels.
   Each label is represented as a one octet length field followed by that
   number of octets.  Since every domain name ends with the null label of
   the root, a domain name is terminated by a length byte of zero.  The
   high order two bits of every length octet must be zero, and the
   remaining six bits of the length field limit the label to 63 octets or
   less.

So, I think the encoding is clear. Dropping (not adding) the final dot is fairly common. Look at the email list above - the domain names are not "ietf.org.". Thus, I don't think this is an issue?

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, October 14, 2014 1:44 PM
To: Bernie Volz (volz)
Cc: Paul Duffy (paduffy); [email-masked]; Brian Haberman; Karl Auer; RFC Errata System
Subject: Re: [dhcwg] [Editorial Errata Reported] RFC3495 (4128)

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 13:05:28 -0500

> So, I think the encoding is clear. Dropping (not adding) the final dot is fairly common. Look at the email list above - the domain names are not "ietf.org.". Thus, I don't think this is an issue?

Actually, the problem here is that RFC 1035 is referring to FQDNs.   FQDNs do end with an implicit dot, but is a realm name an FQDN, or just something that looks like a domain name?   I think the answer is probably what you said, but I think it needs to be said explicitly, and I think saying it in an erratum is not the right thing to do.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 14 Oct 2014 19:04:46 +0000

Ted:

How this issue came up is rather lengthy and I'm not sure I have the full recollection as it happened over a period of time. But I think most people got it right and are sending/expecting an FQDN. So, I'm not sure how big an issue this is. But it did create some confusion and it isn't as clear as it could be.

I am not sure it would be worth the effort to issue an updated RFC - as that may open up more issues.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 16:34:28 -0500

> I am not sure it would be worth the effort to issue an updated RFC - as that may open up more issues.

Understood.   But there is a limit to what errata can do.   If the errata meaningfully changes what the document actually recommends, you're breaking the IETF consensus process.   So as soon as you get into a situation like this, the errata mechanism becomes an inadequate choice.

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Oct 2014 04:34:53 +0700

Date:        Tue, 14 Oct 2014 12:43:42 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  |  That is, given that the realm name doesn't end in dot, should there
  | be a \000 at the end of the string?

There has to be.

  | Is "\005BASIC\0011\000" equivalent to "\005BASIC\0011" or different?

Different, obviously, but the latter isn't a valid DNS on the wire encoding,
and that is what is required, is it not?  There's no overall length field 
anywhere in DNS name encoding (whatever may be the case in DHCP), the \0 must
always be there to terminate the name.   There's no way to have a binary
encoded DNS domain name without it (and yes, they are always FQDNs, there's
no way to encode an incomplete domain name, in the DNS, it simply makes no
sense).

kre

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 16:51:32 -0500

On Oct 14, 2014, at 4:34 PM, Robert Elz <[email-masked]> wrote:
> There's no overall length field 
> always be there to terminate the name.

The length of the buffer also indicates the length of the name.   Having a length and a NUL terminator is redundant, and indeed the RFC that is referenced to talk about what realm names look like says that the realm name is not NUL terminated.   So it's pretty easy to imagine an implementor interpreting this as meaning that the terminal label should be omitted.   Hence my claim that you have to update the document in order to make it clear enough to ensure interoperability.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 14 Oct 2014 22:07:50 +0000

BTW: Here's a reference to what the encoding is in CableLabs documents:

http://www.cablelabs.com/wp-content/uploads/specdocs/PKT-SP-PROV-I08-040113.pdf

8.1.5 Kerberos Realm of SNMP Entity (sub-option 6) 
In conjunction with the Provisioning Entity Address, the Kerberos Realm is used as a means of contacting a 
SNMP Entity in the provisioning realm. The realm name is used to perform a DNS SRV lookup for the 
realm's KDC. 
Sub-option 6 MUST be included in the DHCP OFFER/ACK to the MTA. Sub-option 6 MUST only
contain the realm name in the format of FQDN (type=0 as per [13]). 
The encoding of this sub-option is defined in [13].

(Reference [13] is to the RFC 3495. And here is does say "format of FQDN".)

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, October 14, 2014 5:52 PM
To: Robert Elz
Cc: Brian Haberman; Bernie Volz (volz); Paul Duffy (paduffy); Karl Auer; [email-masked]; RFC Errata System
Subject: Re: [dhcwg] [Editorial Errata Reported] RFC3495 (4128)

On Oct 14, 2014, at 4:34 PM, Robert Elz <[email-masked]> wrote:
> anywhere in DNS name encoding (whatever may be the case in DHCP), the 
> \0 must always be there to terminate the name.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 17:09:04 -0500

> BTW: Here's a reference to what the encoding is in CableLabs documents:

Given the existence of the cablelabs doc and that this is cablelabs-specific, I don't think there's a need to clarify this with an erratum, since people are much more likely (indeed, really required) to read the cablelabs document.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 14 Oct 2014 23:00:14 +0000

Not sure why you're against an errata. It is an IETF document. And if it helps one person at some point, what's the harm? If no one cares about the IETF documents, then the errata will be of neither harm nor benefit.

Probably could not hurt in the justification for the errata to include the reference to the Cablelabs document?

But, I guess I'll leave it up to you as to whether you want to 'retract' the errata or let it go forward.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 20:22:47 -0500

> Not sure why you're against an errata. It is an IETF document. And if it helps one person at some point, what's the harm? If no one cares about the IETF documents, then the errata will be of neithe…

Errata aren't very useful.   Mostly people don't read them.   And this isn't technically an error.   And errata are outside the IETF consensus process.   It's not so much that I'm _against_ them, but I don't want there to be errata that change the meaning of a consensus document, or that clarify the meaning of the document in a way that doesn't clearly have consensus.

So I don't mind confirming the erratum, but if I'm going to confirm it it needs to be done carefully, so as to fit within the very constrained bounds of what is appropriate in an erratum.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Oct 2014 21:13:33 -0500

On Oct 14, 2014, at 8:43 PM, Paul Duffy <[email-masked]> wrote:
> Bernie, if IETF is too tough sledding for this, an ECR with PacketCable may be an easier path.  They can rev the relevant specs.

Excuse me, but I already told you how to do this, and it's dead trivial: re-issue the RFC with the text corrected and do a new last call.   I can even AD-sponsor it if you want.   This would take about six weeks.

The reason for opposing the erratum with the change that Bernie's suggested is that it's not my job to second-guess the working group, nor is it your or Bernie's prerogative to do so.   I'm sorry if that seems like opposition to you, but it's not opposition.  It's me trying to provide guidance as to how to correctly address the problem that Bernie has raised.

I realize that it seems stupid that you can't say what you want in an erratum, but we fairly routinely have people trying to actually make changes to protocols by submitting errata, and setting a precedent on this document that could later be used in an appeal on a different document would be damaging, even if it seems like a no-brainer in this case.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Oct 2014 03:32:26 +0000

Paul:

If you want to re-issue that would be fine. If you need help, I can assist.

Et al:

While Ted has way more history here, I do want to point out the following from the www.ietf.org/rfc.html page (which may just be paraphrasing - there's probably an RFC that describes it), but:

"RFC Errata

Published RFCs never change. Although every published RFC has been submitted to careful proofreading by the RFC Editor and the author(s), errors do sometimes go undetected. Technical Errata are errors in the technical content. Editorial Errata are spelling, grammar, punctuation, or syntax errors that do not affect the technical meaning."

So, this would a Technical Errata that the CLARIFIES technical content. I am not trying to change anything - just clarify. If there is still doubt as to the intended encoding, then let's make sure we resolve that.

- Bernie

-----Original Message-----
From: Paul Duffy (paduffy) 
Sent: Tuesday, October 14, 2014 10:41 PM
To: Ted Lemon
Cc: Bernie Volz (volz); Brian Haberman; Robert Elz; Karl Auer; [email-masked]; RFC Errata System
Subject: Re: [dhcwg] [Editorial Errata Reported] RFC3495 (4128)

> Excuse me, but I already told you how to do this, and it's dead trivial: re-issue the RFC with the text corrected and do a new last call.   I can even AD-sponsor it if you want.   This would take a…

Actually, I mis-read your statement that a CableLabs fix would be more effective? "Given the existence of the cablelabs doc and that this is cablelabs-specific, I don't think there's a need to clarify this with an erratum, since people are much more likely (indeed, really required) to read the cablelabs document."

And the six week turn is new info.  But glad to have it!  Thank you.

If six weeks is truly the turn time, Bernie ... re-issue seems reasonable to me?

> .

---

From: Paul Duffy <[email-masked]>
Date: Tue, 14 Oct 2014 21:43:28 -0400

Time for the author to chime in.

What Bernie has described is indeed what was intended and most often 
implemented in the field.  The text is remarkably confused in very few 
words.  Don't know how this got past the RFC process, CableLabs review, 
etc.  Who wrote this crap ... oh damn ... I DID!  :(

I agreed with Bernie's proposed errata.  I don't understand the opposition.

Bernie, if IETF is too tough sledding for this, an ECR with PacketCable 
may be an easier path.  They can rev the relevant specs.

---

From: Paul Duffy <[email-masked]>
Date: Tue, 14 Oct 2014 22:41:18 -0400

> Excuse me, but I already told you how to do this, and it's dead trivial: re-issue the RFC with the text corrected and do a new last call.   I can even AD-sponsor it if you want.   This would take a…

Actually, I mis-read your statement that a CableLabs fix would be more 
effective? "Given the existence of the cablelabs doc and that this is 
cablelabs-specific, I don't think there's a need to clarify this with an 
erratum, since people are much more likely (indeed, really required) to 
read the cablelabs document."

If six weeks is truly the turn time, Bernie ... re-issue seems 
reasonable to me?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 09:54:20 -0500

> Actually, I mis-read your statement that a CableLabs fix would be more effective? "Given the existence of the cablelabs doc and that this is cablelabs-specific, I don't think there's a need to clar…

Ah, no, I just meant that since the cablelabs document is more explicit, and people are quite likely to read it, it should be sufficient.   But I think clarifying the RFC is also good; in particular, I think it would be good to be clear about the non-terminal label.   I think that's a change that requires a new consensus call--that's the only reason I'm pushing back on it.