Subject: [Gen-art] Re: Gen-ART review of IETF LC draft-narten-iana-considerations-rfc2434bis-07.txt

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Sep 2007 11:09:35 -0400

Hi Miguel.

Thanks for your comments.

Miguel Garcia <[email-masked]> writes:

> Thomas, Harald:

> 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 resolve these comments along with any other Last Call comments
> you may receive.

> Document: draft-narten-iana-considerations-rfc2434bis-07.txt
> Reviewer: Miguel Garcia <[email-masked]>
> Review Date: 2007-08-11
> IETF LC End Date: 2007-08-17

> Summary: The document is almost Ready for publication as a BCP.

> Comments:

> 1) My general comment is related to the relation of this draft to RFC 
> 4858 (Document Shepherding from WGLC to publication). Especially, 
> Section 4 of RFC 4585 says:

>     At the time of this publication, RFC 2434 is under revision
>     [RFC2434bis], and the updates are and will be of value to the
>     Document Shepherd.  Note that the Document Shepherd MUST determine
>     (by individual review and consultation with others) what is the most
>     recent and the most applicable IANA information and guidance for his
>     or her document, be it the overall guidance, or external documents in
>     his or her area, or in other areas.  An example of an external
>     document is [RFC4020].

> So, I was expecting that the draft, which is the mentioned revision of 
> RFC 2434, mentions the role of the Document Shepherd with respect IANA 
> considerations and IANA experts. At the moment, it is left to the 
> reader's interpretation. My suggestion is to clarify the role of the 
> Document Shephard and the IANA process.

I can't think if anything right off about document shepherding that
should go into 2434bis. I think that the text you cite above (and the
rest of that section) talk about the role of the shepherd, their
responsibilities, and interactions between the shepherd and
IANA. However, 2434bis really is targetted toward the document author,
and what they need to do to make their IANA intentions clear. 2434bis
does not at all deal with operational aspects of document processing
(e.g., what the IESG does with IANA comments, or what a shepherd does,
etc.)

So, my take is that no changes are needed in 2434bis. Indeed, it's
really unclear what would be appropriate to say, or what you would
expect to see.

If you disagree, could you be more specific about what you think is
needed?  I.e., what text should change, and where?

> 2) Although the document uses normative term (e.g., MUST), and
> includes a reference to RFC 2119, it is not done accurately. First,
> the RFC 2119 boilerplate is out of date (and id-nits
> complains). Then, the boilerplate is typically written in a separate
> section titled 'Terminology', rather than buried at the end of the
> Introduction section. Last, RFC 2119 must be a normative reference.

I have made some changes to the text, but I did not move it to a
separate section. 

> 3) Small contradiction in Section 11, IANA Considerations. While the 
> document indicates that "this document is all about IANA 
> considerations", it fails to comply with its own Section 6.1 to say 
> whether the document itself mandates actions to IANA. I would suggest to 
> add or replace the existing sentence with:

>    This document has no IANA actions.

:-)

> 4) id-nits reveals some other very minor nits:
> - missing expiration date in the draft
> - no 'intended status'
> - A number of obsolete references, although I think they some of them 
> might be intentional, because they are examples of existing IANA registries.
> - draft-carpenter-protocol-extensions in now RFC 4775

Fixed (mostly). In some cases, the idnits warnings can't really be
addressed. And they are just warnings.

Thomas

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 17 Sep 2007 09:51:28 +0300

Hi Thomas:

With the first point, I am not trying to be picky, so, whatever you 
decide I have no problem. My only comment is that RFC 4858 made a 
forward statement, by saying: "hei, there is a coming document that is 
going to say more about the Document Shepherd responsibilities with 
respect IANA, so please, keep tuned". This document is your document, 
but does not say anything. So, I felt curious to know what your document 
should say about the Document Shepherd role. But perhaps I misinterpret 
RFC 4585, so if you think your document is ok, I am fine too.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Sep 2007 08:16:33 +1200

> RFC 4585, so if you think your document is ok, I am fine too.

As the ex-shepherd for 2434bis itself, I tend to agree with
Thomas - it seems obvious that the shepherd for a given draft
should check that it does what 2434bis says it should do,
but it seems redundant to say that in 2434bis.

Regards
    Brian Carpenter
    University of Auckland
>>> So, I was expecting that the draft, which is the mentioned revision 
>>> of RFC 2434, mentions the role of the Document Shepherd with respect 
>>> IANA considerations and IANA experts. At the moment, it is left to 
>>> the reader's interpretation. My suggestion is to clarify the role of 
>>> the Document Shephard and the IANA process.
>>
>>> whether the document itself mandates actions to IANA. I would suggest 
>>> to add or replace the existing sentence with:
>>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 17 Sep 2007 22:49:53 +0200

> but it seems redundant to say that in 2434bis.

I'd go as far as saying that the forward pointer in 4858 was a mistake, and 
the next revision of that document should drop the reference....