[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Request to advance drafts



I will work with the other authors to address the below comments and with
the WG chair on that last question. Thank you for the feedback!

-Diana

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
Sent: Tuesday, August 20, 2002 9:55 AM
To: Hahn, Scott; Mark Stevens (E-mail)
Cc: Rap-wg (E-mail)
Subject: RE: Request to advance drafts

RAP WG, I got this requestst from your WG chairs.
> 
> I would like to submit the following draft to the IESG for 
> consideration as a Informational RFC:
> http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-02.txt
> 

My AD-evaluation comments (I understand that a lot of it is 
admin/bureaucratic, but you basically knew that and it is always best
to avoid such comments at this late stage).:

1. Title and abstract contain Acronyms that RFC-Editor no
   longer want to see. You have to expand them.
   See: http://www.rfc-editor.org/policy.html

2. abstract should not have references. You have a [COPS] reference.
   I think you can just use RFC 2478 and leave the ref out.
   See: http://www.rfc-editor.org/policy.html

3. References need to be split in normative and informative references

4. You have text in "Conventions used in this document" on MUST
   language and such. That is good. Probably better to include it in
   the intro section (or at least after the abstract).
   But more important, you need to add [RFC-2119] reference to the
   references section

5. I think it would be good to do some sort of terminology at the
   beginning of the intro. Either explain terms like PDP, PEP, SIP, PRC
   (or at least extend the acronym first time it is used). Might also
   add a reference to the terminology as per RFC3198 

6. You seem to be using (what we call) redmond-characters in a few
   places: 2nd para sect 2, sdt para sect 7, may be other places

7. Last sect of para 4.1. 
   Could we add HOW a PDP may sollicit usage feedback/

8. sect 7, 2nd para
   Can you ellaborate on what sort of "additional information
   must be provided to uniquely identify...."

9. Sect 8, can you explain what a "context switch" is?

10. Security consideration.
    - You must specify one mandatory to implement.
      you are now just saying "...protection can be accomplished".
    - When you specify the use of IPsec, pls do not just say 
      "just use IPsec".  A clearer statement is needed, 
      specifying the necessary IPsec selectors (per RFC 2401)
      and the way the cryptographically protected endpoints are
      related to the authorization model, i.e., who can do what.

> 
> the following draft to the IESG for consideration as a 
> standards track RFC:
> http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt
> 
> Both have completed WG last call.
> 
The 2nd one I still need to review, will try to post later today or
tomorrow.

My main question is if we want to go through a similar process as we did
for the earlier PIBs, or if the WG rather decides that this PIB can be
also informational, just as the Framework PIB and the Diffserv PIB.

Bert