[Gen-art] Gen-ART review of draft-ietf-adslmib-gbond-mib-09.txt

[Miguel A. Garcia]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ at


Please resolve these comments along with any other comments you may receive.

Document:draft-ietf-adslmib-gbond-mib-09.txt
Reviewer: Miguel Garcia 
Review Date: 2012-02-24
IETF LC End Date: 2012-02-28

Summary: The document is ready for publication as a standards track RFC.

Major issues: none

Minor issues: none

Nits/editorial comments:

- I have not reviewed Section 6 of this document, which is the actual MIB 
structure, because there is nothing I can comment on it. Considering that 
this draft has been produced in the ADSLMIB working group, I believe the 
expertise lies in the WG.


- I've noticed in the data tracker that IANA has requested a 
clarification with respect to the IANA Considerations section. The 
resolution of this discussion should be documented in the IANA 
Considerations section.


/Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-shin-augmented-pake-12

[Vijay K. Gurbani]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-shin-augmented-pake-12
Reviewer: Vijay K. Gurbani
Review Date: Feb-24-2012
IETF LC End Date: Not known
IESG Telechat date: March-15-2012

Summary: This draft is ready as an Experimental.

Some minor comments and nits follow.

Major issues: 0
Minor issues: 3
Nits/editorial comments: 2

Minor:

1. Section 1 (S1), first paragraph:
 s/session key would be used/session key is used/

2. S1, second paragraph: "...The AugPAKE protocol described in
 this document is an augmented PAKE which also achieves measurable
 efficiency over some previous works."

 For sake of completeness, it may help to provide references to
 the "previous works".

3. S1, second paragraph: "We believe the followings [SKI10]:" ---
 s/followings/following/
 but besides this, I am not sure what you are trying to say
 here.  Maybe a matter of expressing it in alternate English?

Nits:

1. S1, second paragraph: s/one and 1.17/1 and 1.17/
 This makes it congruent with "2 and 2.17" that appears a
 few lines above.

2. Email for author Kazukuni Kobara is missing.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review:draft-ietf-netext-pmip-lr-08.txt

[Mary Barnes]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at <
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-netext-pmip-lr-08.txt
Reviewer:  Mary Barnes
Review Date:  24 Feb 2012
IETF LC End Date: 21 Feb 2012
IESG Telechat Date: 01 March 2012

Summary:  Almost ready.

Minor issues:

1) General: There is an inconsistent usage and lack of normative language
in parts of the document.  The following summarizes the majority of the
cases that I encountered:
- Section 4:
-- Text after Figure 2 (before section 4.1).  There is no normative
language in these paragraphs.
--- For example in the first paragraph, I would expect that the elements
that ought to be included in the messages should be specified as "MUST
contain…". And, rather than "The LMA sends…", I would think it would be
"The LMA MUST send…"
--- 2nd paragraph: I would expect to see "…MUST send an LRA with status
code…" , "MUST then create Localized Routing Entries…" .  There's also a
"should contain" that I think ought to be "SHOULD contain"
--- 5th paragraph:  First sentence:
"and responds with.."  -> "MUST respond with"
and it seems that there is some other normative language that could be
added throughout that paragraph.

- Section 4.1:
-- 1st para, 1st sentence:  "needs to be" -> "MUST be"

- Section 5:
-- Paragraph after Figure 3.  Similar comments as above.  There's only one
normative statement in that paragraph.
-- Section 5.1:  "needs to be" ->  "MUST be", "It will hence initiate" ->
 "It MUST initiate LR.

- Section 6:
-- First paragraph after Figure 5:  "routing has to be initialized" ->
"routing MUST be initialized"
-- 2nd paragraph:  It would seem that somewhere it should be stated that
the Status value MUST be set to zero.  Also, I don't the the last MUST in
that paragraph is normative.  I would think it could be a "can" and maybe
the "it can provide" is where the MUST should be.

- Section 6.1:
-- "needs to be" -> "MUST be"

- Section 7:
-- last sentence: should the recommended be upper case?

- Section 8: shouldn't  the "must add the IPv4 HOAs" be a "MUST"

- Section 9.1: "The LMA sends.." -> "The LMA MUST send", "The MAG may…" ->
"The MAG MAY…"

- Section 9.2: "The MAG sends…" -> "The MAG MUST send", "An LMA may send"
-> "An LMA MAY send"

- Section 11:  "using IPSEC is required" -> "using IPSEC is REQUIRED"



2) Section 4: last sentence of paragraph after Figure 1.   The use of the
EnableMAGLocalRouting flag seems key to whether this functionality is
applied in some of the cases. It's first introduced as a "Please note",
although, it is clearly (but not normatively) specified in the 2nd
paragraph after Figure 2.

I would think it would be helpful to introduce this functionality in
section 2, specifically in Section 2.1 by adding something like the
following after the first sentence of that paragraph:
  The MAG MUST set the EnableMAGLocalRouting to a value of 1.

3) IANA Considerations: My understanding is that IANA wants a list of the
necessary registrations in the same form as they would appear in the
registries (per RFC 5226)  - i.e., something like:

Value  Description  Reference
-  ---
 -
TBD1   Localized Routing Initiation [RFC]
TBD2   Localized Routing Acknowledgment [RFC]
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art