Subject: [Gen-art] Genart review: draft-ietf-6man-reserved-iids-01

From: Robert Sparks <[email-masked]>
Date: Mon, 1 Dec 2008 16:22:52 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-6man-reserved-iids-01
Reviewer: Robert Sparks
Review Date:  01 Dec 2008
IESG Telechat date: 04 Dec 2008

Summary: This draft is basically ready for publication. I have a  
couple of questions below.

Major issues: none

Minor issues:

The last sentence of section 3 seems to put a (new?) normative  
restriction on the behavior of protocols (like dhcpv6) defined in  
other documents. Should this document call out what it's updating?

Nits/editorial comments:

Nit - I'm probably missing a point in the "Possible solutions" section  
- as I read it, it is attempting to justify using a registry instead  
of asking documents to explicitly point to the two RFCs it calls out  
as defining reserved IID ranges because the number of specifications  
to be updated would be large (the sentence here has a grammar problem  
that I'll send directly to the editor). Why would these same documents  
not need to be updated to point to the registry? (I'm not disagreeing  
with the registry - I just don't understand what is being argued in  
this part of the section.)

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

---

From: Robert Sparks <[email-masked]>
Date: Mon, 1 Dec 2008 16:51:53 -0600

I hit send one paragraph too soon - sorry. One additional nit below.

On Dec 1, 2008, at 4:22 PM, Robert Sparks wrote:

> Nit - I'm probably missing a point in the "Possible solutions"  
> section - as I read it, it is attempting to justify using a registry  
> instead of asking documents to explicitly point to the two RFCs it  
> calls out as defining reserved IID ranges because the number of  
> specifications to be updated would be large (the sentence here has a  
> grammar problem that I'll send directly to the editor). Why would  
> these same documents not need to be updated to point to the  
> registry? (I'm not disagreeing with the registry - I just don't  
> understand what is being argued in this part of the section.)
>

Nit - The first sentence in the security considerations section is  
confusing. To me it says 'standard track rfcs that change this  
registry need to be authenticated and authorized'. What does it really  
intend to say?

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 01 Dec 2008 18:02:04 -0500

Hi Bob,
   Thanks for the comments. Please find responses inline.

Robert Sparks wrote:
> restriction on the behavior of protocols (like dhcpv6) defined in other 
> documents. Should this document call out what it's updating?

It is not really a normative restriction. It is more an opt-in behavior 
that documents can use to avoid using these IIDs. I do have a list of 
RFCs that need to be updated, but I did not know if I should put them 
here in this document as the list might be out of date very quickly.

> 
> Nits/editorial comments:
> 
> Nit - I'm probably missing a point in the "Possible solutions" section - 
> as I read it, it is attempting to justify using a registry instead of 
> asking documents to explicitly point to the two RFCs it calls out as 
> defining reserved IID ranges because the number of specifications to be 
> updated would be large (the sentence here has a grammar problem that 
> I'll send directly to the editor). Why would these same documents not 
> need to be updated to point to the registry? (I'm not disagreeing with 
> the registry - I just don't understand what is being argued in this part 
> of the section.)

Maybe it is not clear in the text but I will try to explain my reasoning.

Let's say this change affects 10 RFCs that would need to point to this 
registry. If we take the other path of referring to the two existing 
RFCs that allocate this reserved IIDs, if a new spec pops up to reserve 
an IID, each of the 10 RFCs need to be updated again. And there would 
still be no place that contains a complete listing of RFCs that reserve 
IIDs.

Thanks
Suresh