[Gen-art] Gen-ART Last Call review of draft-ietf-rmt-flute-sdp-03.txt

[Suresh Krishnan]

I am the assigned Gen-ART reviewer for
draft-ietf-rmt-flute-sdp-03.txt

For background on Gen-ART, please see the FAQ at
.

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

Summary: This draft is ready for publication as a Proposed Standard.

Thanks
Suresh

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

Re: [Gen-art] [PWE3] Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06

[Huub van Helvoort]

Hello Nabil,

Considering your response:


 Please, see above. There are different contexts per above where the
expanded terminology is applied. Are you suggesting still using Reverse
Defect Indication per above where needed but not to abbreviate it? RDI as
Remote Defect Indication part of Ethernet CFM is already there.


Would it be possible to remove the dependency on the context by
prepending the PW defect notifications by "P-". I.e.:

P-RDI  PW Reverse Defect Indication
P-FDI  PW Forward Defect Indication

And usinf RDI  Remote Defect Indication.

Regards, Huub.


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

[Gen-art] Telechat review of draft-ietf-dime-erp-16.txt

[Elwyn Davies]

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>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: 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>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: 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>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-dime-erp-16.txt
Reviewer: Elwyn Davies
Review Date: 20 Jan 2013
IETF LC End Date:
IESG Telechat date: 24 jan 2013

Summary: Not ready assuming I have correctly identified that the 
requirements specified in RFC 5295 below are not met by this usage of 
the DSRK.  Generally the use of the term 'domain' in this draft is 
rather cavalier, as it fails to explicitly tie it back to the restricted 
meaning of RFC 5295 and does not clarify how nodes find out what domain 
name they should be using.


Major issues:
s5, para 1:
Para 1 states:

  To
   achieve this, it must learn the domain name of the ER server. How
   this information is acquired is outside the scope of this
   specification, but the authenticator might be configured to advertize
   this domain name, especially in the case of re-authentication after a
   handover.

It appears that declaring learning the domain name out of scope for this 
specification is in conflict with RFC 5295, para 4 (top of page 12):

   Usages that make use of the DSRK must define how the peer learns the
   domain label to use in a particular derivation.

This matter escaped me on the previous pass, when I just asked whether 
there was any suggestions of how the advertisement might be done.


Minor issues:
s3:  In my Last call review of this document (version 12) I queried the 
use of the phrase 'the existence of at most one (logical) ER server 
entity' in two places in s3.  I received an answer from one of the the 
authors that suggested that the phrase was self-explanatory.  At the 
time I did not push back on this and no change has been made.  On 
re-reading the latest version of the draft and the author's reply, I 
(still) feel that it would help to explain:
(1) Why having more than one ER server in a domain is a mistake - 
apparently because this will result in EAP 'failing inappropriately' in 
some cases which would seem to be a reason to specifically deprecate 
having more then one, and explaining just what the inappropriate 
consequences would be.
(2) The consequences of having zero ER servers in a domain.  The reply 
to my comments seem to imply that this would just result in the 
'protocol failing gracefully'.  However, reading RFC 6695, para 2 of 
s5.1 seems to imply that having zero ER servers in the local (visited) 
domain may not be fatal if there is an ER server in the home domain (see 
also s4 of this draft).  If I have interpreted this correctly, then 
there is a distinction between the cases (home vs arbitrary visited 
domain) that could usefully be brought out here rather than leaving the 
reader to work it out from later reading.


s3, last sentence of para 1: ''we assume only one ER server that is 
*near* the peer involved in ERP": How are we to interpret 'near' here? 
Topologically or physically?  How would the peer know a server was 
'near' it or nearer than some other server?


Nits/editorial comments:
s2/s3:  I assume that the term 'domain' is intended to be interpreted as 
in  RFC 5295, i.e. as a shorthand for Key Management Domain.  This needs 
to be spelt out here.   Similarly 'home domain', 'local domain' and 
'visited domain' should be explicitly mentioned as (presumably) having 
the same meanings as in RFC 6696.


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

Re: [Gen-art] Gen-ART LC review of draft-ietf-eman-rfc4133bis-05.txt

[Benoit Claise]

Thanks Brian for your review,

Let me answer two points below, starting with BENOIT>

Regards, Benoit

draft-ietf-eman-rfc4133bis-05-carpenter.txt


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-ietf-eman-rfc4133bis-05.txt
Reviewer: Brian Carpenter
Review Date: 2013-01-19
IETF LC End Date: 2013-01-25
IESG Telechat date:

Summary:  Ready (nits)


Comment:


I didn't find any mention of a MIB Doctor review in the tracker. Since two
authors are MIB Doctors, it should be OK.


BENOIT> The MIB doctor review takes place now, part of the IETF LC
BENOIT> See http://www.ietf.org/iesg/directorate/mib-doctors.html
BENOIT> The doctor is Juergen Schoenwaelder.


I did not review the details of the MIB module.

Nits:
-

In the Abstract, "This document specifies version of the Entity MIB"
seems to lack a "4".

I would have expected a short paragraph starting "Version 4 of this MIB
addresses new requirements... " just before section 2.1.

BENOIT> That makes sense.
 

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