[Gen-art] Gen-art review of draft-ietf-iptel-tel-np-09

[Ron Bonica]

Attached is my review of the specified document, submitted as part of
the Gen-ART process.  For background on Gen-ART, please see the FAQ at
.


Document:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-09.txt

Comments:

The document is well written and generally ready for publication. I
understood it even though I am not a VOIP guy. The following are very
small comments:

- In Section 5, are you sure that you want to refer to the two database
access as "first" and "second"? Would words like "originating network"
and "serving network" be more descriptive? (This is a question, not a
comment?)

- In Section 5.1, you talk about "cic" and "rn" information that is "not
useful". A few paragraphs later, you talk about what to do if the "cic"
represents the local network or the "rn" represents the local node. I
assume that this is what you mean by "not useful". If so, would the word
 "local" be more descriptive than "not useful"? (Again, just a question).

 Ron



___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

[Gen-art] review of draft-kornijenko-ivis-urn-00.txt

[Francis Dupont]

Summary: basically ready with nits

I strongly recommend to convert the document to a tool like xml2rfc
before to send it to the RFC editor!

Other concerns:
 - the document should specify which kind of namespace registration is
   asked for (I've assume "formal")
 - so there must be an IANA consideration asking for the registration
 - and compliance to RFC 3406 should be more evident (i.e., stressed)
 - note that I am not in urn-nid ML so I don't know if this step of
   the procedure was done nor if there were interesting comments...
   (I've checked the urn-nid archive, the procedure was followed
in a burial silence (:-), only Leslie Daigle helped the author)
 - 2.2 page 2: the declared registrant should be an organization
   and the human the contact person for obvius stability reasons
 - 2.22 page 3: un -> and
 - Acknowledgments page 5: there is only one author who should not be
   acknowledged (:-)
 - 7.1 page 5: perhaps the RFC 2141 should be referenced
 - 7.2 [3] page 5: misplaced closing "
 - 7.2 [7] page 5: where are the acknowlegdments to see?

Regards

[EMAIL PROTECTED]

___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

RE: [Gen-art] Assignments for April 27th, 2006

[Mary Barnes]

I've uploaded the most recent reviews (mostly LCs) and updated the
spreadsheet accordingly. 

Please let me know if I've missed anything.

Mary

-Original Message-
From: Barnes, Mary [RICH2:B601:EXCH] 
Sent: Thursday, April 20, 2006 8:03 PM
To: gen-art@ietf.org
Subject: [Gen-art] Assignments for April 27th, 2006 


Here's the assignments for the April 27th, 2006 telechat: 
http://www.alvestrand.no/ietf/gen/art/reviewers-060427.html

with the corresponding spreadsheets available at: 
http://www.alvestrand.no/ietf/gen/art/gen-art.html 
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html 

I've also uploaded the reviews received since the end of last week, so
let me know if you see any problems or omissions. 

Mary. 



___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art


___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

RE: [rddp] Re: [Gen-art] IETF LC reviews: rddp security andapplicability

[Joel M. Halpern]

Thank you.  The changes you propose would address the minor issues.
Yours,
Joel

At 10:31 AM 4/25/2006, Jim Pinkerton wrote:

Thanks for the feedback Joel. Comments in-line.


Jim



___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

RE: [rddp] Re: [Gen-art] IETF LC reviews: rddp security andapplicability

[Jim Pinkerton]

Thanks for the feedback Joel. Comments in-line.


Jim



> -Original Message-
> From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 21, 2006 6:10 PM
> To: Mary Barnes; gen-art@ietf.org
> Cc: [EMAIL PROTECTED]; rddp@ietf.org
> Subject: [rddp] Re: [Gen-art] IETF LC reviews: rddp security
> andapplicability
> 
> I was selected as General Area Review Team reviewer for this
specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> (These reviews treat DDP and RDMAP as given, and do not comment
> directly on those protocols.)
> 
> RDDP/ RDMAP Security
> Given the nature of RDDP, this document is a very good idea.  I
> am glad to see it.
> This review does not check the completeness of the security
> coverage.  However, as a lay reader I am quite impressed.
> 
> The document is ready for publication as an Informational RFC,
> and probably ready as a Proposed Standard.
> Personally, I would put the one IPSec requirement into the main
> document, and consider the rest of the material to be in the category
> of good advice.  This is driven by the fact that the actual advice is
> somewhere between difficult and impossible to observe on the wire.
> 
> minor point:  The last sentence of the introduction reads:
> 
> If all recommended mitigations are in place the implemented usage
> models, the RDMAP/DDP protocol can be shown to not expose any new
> security vulnerabilities.
> 
>Aside from the linguistic oddity of this sentence, it is unclear
> what state is being compared.  I.e., compared with what condition is
> there an absence of new security vulnerabilities.   (Presumably some
> state other than "not communicating".)  There are scattered other odd
> English usages.
[] 

Good point. Below is the suggested rewording to address your concerns,
plus after rereading the section, it doesn't summarize the appendices
(it does summarize all the other sections), so I add some informative
text describing them just before this text.

The appendices provide focused summaries of this specification. Section
11 Appendix A: ULP Issues for RDDP Client/Server Protocols focuses on
implementers of traditional client/server protocols. Section 12 Appendix
B: Summary of RNIC and ULP Implementation Requirements summarizes all
normative requirements in this specification. Section 13 Appendix C:
Partial Trust Taxonomy provides an abstract model for categorizing trust
boundaries.

If an RDMAP/DDP protocol implementation uses the mitigations recommended
in this document, that implementation should not exhibit additional
security vulnerabilities above and beyond those of an implementation of
the transport protocol (i.e., TCP or SCTP) and protocols beneath it
(e.g., IP) without RDMAP/DDP.

> minor: In section 2.3.2, in describing three mechanisms, the text
> refers to one mechanism (X) and one mechanism (Y and Z).  It should
> refer to two mechanisms (Y and Z).
> 
[] 
Thanks. Fixed.



>  IDNits reports some references missing and some unused.
> 
> 
[] 
Thanks. Reran and fixed the issues.


Jim



> RDMA/DDP Applicability:
> Other than needing a good English language editor, this document
> appears ready for publication as an Informational RFC.
> An example of this is that the references ought to actually be
> referenced in the body of the document.
> 
> 
> 
> At 03:46 PM 4/13/2006, Mary Barnes wrote:
> >Reviewer: Joel Halpern
> >
> >- 'DDP/RDMAP Security '
> > as a Proposed Standard
> >- 'Applicability of Remote Direct Memory Access Protocol (RDMA) and
> >Direct Data
> >Placement (DDP) '
> > as an Informational RFC
> >
> >IETF LC ends on 2006-04-19.
> >
> >The file can be obtained via
> >http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-08.txt
>
>http://www.ietf.org/internet-drafts/draft-ietf-rddp-applicability-05.tx
t
> 
> 
> ___
> rddp mailing list
> rddp@ietf.org
> https://www1.ietf.org/mailman/listinfo/rddp

___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art