Subject: [dhcwg] Errata of RFC3633 ?

From: Leaf yeh <[email-masked]>
Date: Tue, 20 Sep 2011 08:06:49 +0000

Section 11.2 - Delegating router behavior

http://datatracker.ietf.org/doc/rfc3633/?include_text=1

Original Text

   "Examples of ways in

   which the delegating router might select prefix(es) for a requesting

   router include: static assignment based on subscription to an ISP;

   dynamic assignment from a pool of available prefixes; selection based

   on an external authority such as a RADIUS server using the Framed-

   IPv6-Prefix option as described in RFC 3162 [5]."

Corrected Text

 "... selection based on an external authority such as a RADIUS server using the Delegated-IPv6-Prefix attribute (123) as described in RFC 4818 [5]."

Notes

  The [5] of normative references in section 18.1 should be revised to be 'Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.'

Am I right?

Best Regards,

Leaf

-----Original Message-----
From: Ole Troan [mailto:[email-masked]]
Sent: Friday, July 29, 2011 5:09 AM
To: Leaf yeh
Cc: [email-masked]
Subject: Re: [dhcwg] Correction Item - Errata of RFC3633 ?

Leaf,

> I might get a correction item for the Errata of RFC3633 this morning.

> http://www.rfc-editor.org/errata_search.php?rfc=3633 - Errata ID: 2468

>  New last paragraph of 12.2:

>  When the DR delegates prefixes to a Requesting Router, the

>  Requesting Router has sole authority for assignment of those

>  prefixes, and the Delegating Router MUST NOT assign any prefixes

>  from that delegated prefix to any of its own links.

>  Notes:

>  This change clarifies that the authority over the address space is delegated to the RR. Moving the use restriction for the address space from the RR to the DR.

> I think the correct Notes might be '.... Moving the use restriction for the address space from the DR to the RR.'

absolutely.

the text is correct though. don't know if notes can be updated in the tool?

cheers,

Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 20 Sep 2011 11:17:27 +0200

Leaf,

>  The [5] of normative references in section 18.1 should be revised to be 'Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.'

well, sort of. the "Delegated-IPv6-Prefix" attribute was defined way later than RFC3633. I don't know if the correct procedure is to update 3633 with an Errata??
perhaps time to do 3633bis, and get all these things fixed? and get it to draft standard (or whatever the new document statuses will be).

cheers,
Ole

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

---

From: Leaf yeh <[email-masked]>
Date: Tue, 20 Sep 2011 09:57:34 +0000

Ole,

I guess Errata might be the best way we have today to make this kind of correction for the reader of this RFC. I wish the ML of DHC could make a judge on this correction and output the right procedure for the real-time correction against the RFC.

Best Regards,
Leaf

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: Tuesday, September 20, 2011 4:58 PM
To: Leaf yeh
Cc: [email-masked]
Subject: Re: [dhcwg] Errata of RFC3633 ?

Leaf,

cheers,
Ole

---

From: Glen Zorn <[email-masked]>
Date: Tue, 20 Sep 2011 17:43:35 +0700

> I guess Errata might be the best way we have today to make this kind of correction for the reader of this RFC. I wish the ML of DHC could make a judge on this correction and output the right proced…

The problem is that 1) it's not an error to refrain from referencing a
document that didn't exist at the time of writing ;-), 2) it's also not
an error to specify an action that may not be optimal but is serviceable
nonetheless (i.e., Framed-IPv6-Prefix vs. Delegated-IPv6-Prefix) & 3) if
the RADIUS attribute is changed then existing implementations may break.
 I would suggest just leaving it be (except, of course, that
Framed-IPv6-Prefix is an attribute, not an option -- that _is_ an error ;-).

...