RE: AD-review of draft-ietf-rap-feedback-frwk-03.txt

OK, so Just reviewed revison 3.

A few minor nits remain, see below.
But I can address these with an RFC Editor note as follows:

- On first page, change [RFC-2119] into [RFC2119]
- in the Abstract, change [RFC2748] into (RFC2748)
- Move reference to RFC2119 from Informative to Normative section

I will put doc on IESG agenda.

See details below.

My original comments on rev 02 were:

> > > 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-fr
> > > wk-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
> > > 
OK, fixed.

> > > 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
> > > 
What I meant was to use (RFC2748) instead of [RFC2748].
The RFC-Editor policy does not allow references in the abstract.

> > > 3. References need to be split in normative and informative references
> > > 
OK, thanks.
RFC2119 needs to be a normative reference though

> > > 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
> > > 
Done, thanks. The [RFC-2119] on the fromt page however does not
match up with the [RFC2119] in the References section itself.

> > > 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 
> > > 
I see the Glossary, Thanks

> > > 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
> > > 
OK, they seem to have dissapeared.

> > > 7. Last sect of para 4.1. 
> > >    Could we add HOW a PDP may sollicit usage feedback/
> > > 
Thanks, I see it

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

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

> > > 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 changes you made are fine with me (and porbably with sec ADs too,
but we'll see when it goes to IESG).

> > Bert
> > 
> 

Bert