Re: [Gen-art] Gen-ART review of draft-ietf-dmm-requirements-14

[H Anthony Chan]

Thanks.

Regarding the first comment, the abstract can be elaborated a little more as 
follows:

   This document defines the requirements for Distributed Mobility
   Management (DMM) at the network layer.  The hierarchical structure in
   traditional wireless networks has led primarily to centrally deployed
   mobility anchors.  As some wireless networks are evolving away from
   the hierarchical structure, it can be useful have a distributed model
   for mobility management in which traffic does not need to traverse
   centrally deployed mobility anchors far from the optimal route.

Regarding the second comments on defining the acronyms:
It appears there are 3 such instances: EPC, 3GPP, WLAN. All other acronyms have 
been properly defined. 

EPC needs to be spelled out before the acronym appears.
3GPP was spelled out in Section 3.1 but was also used in Section 1. It needs to 
move to Section 1. 
WLAN is also spelled out. 

H Anthony Chan

From: Russ Housley 
Sent: Monday, February 10, 2014 1:51 PM
To: draft-ietf-dmm-requirements@tools.ietf.org 
Cc: IESG ; IETF Gen-ART 
Subject: Gen-ART review of draft-ietf-dmm-requirements-14


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-dmm-requirements-14
Reviewer: Russ Housley
Review Date: 2014-02-10
IETF LC End Date: 2014-02-17
IESG Telechat date: Unknown

Summary:  Ready for publication.


Major Concerns:  None.


Minor Concerns:  None.


Other Comments:

I think that the Abstract could be more polished.  Some mention of the
anchor point seems desirable.

Spell out acronyms the first time they are used. EPC is an example that
needs to be expanded.___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-vanelburg-dispatch-private-network-ind-05

[Scott Brim]

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-vanelburg-dispatch-private-network-ind-05
Reviewer: Scott Brim
Review Date: 2014-02-24
IETF LC End Date: 2014-03-14
IESG Telechat date:

Summary: This draft is ready for publication as an informational RFC.

Major issues:

Minor issues:

Nits/editorial comments:

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

[Gen-art] GEN-ART review of draft-vanelburg-dispatch-private-network-ind-05

[Scott Brim]

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-vanelburg-dispatch-private-network-ind-05
Reviewer: Scott Brim
Review Date: 2014-02-24
IETF LC End Date: 2014-03-14
IESG Telechat date:

Summary: This draft is ready for publication as an informational RFC.

Major issues:

Minor issues:

Nits/editorial comments:

___
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-mpls-tp-psc-itu-02.txt

[Huub Van Helvoort]

Hello Elwyn,



Thank you for your review.



See my response in-line [Huub]

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-mpls-tp-psc-itu-02.txt
Reviewer: Elwyn Davies
Review Date: 24 Feb 2014
IETF LC End Date: 24 Feb 2014
IESG Telechat date: (if known) -

Summary:
Almost Ready for IESG.  There is a statement in s1 that could indicate
that the consequences of turning on a subset of the new capabilities has
not been fully thought through.  I am also not clear whether EXER
fulfils the intentions of R84 in RFC 5654 as stated.  The repeated
transmission of the advertised capabilities adds to the scope for random
bit errors to halt protection operation.  A few minor nits noted below.

[Huub] I have addressed these below.

Major issues:
None

Minor issues:
s1, next to last para:

>This document describes the behavior of the PSC protocol including
>the priority logic and the state machine when all the capabilities
>associated with the APS mode are enabled.  The PSC protocol behavior
>for the PSC mode is as defined in RFC 6378.

APS mode involves five capabilities which can, apparently, be
implemented and advertised indpendently, so presumably there might be
reasons for either implementing or turning on just a subset.



[Huub] There were originally separate drafts for each of the capabilities.

However, it was very complex to define the effect on the state

transition tables for each capability or combination of capabilities.



[Huub] to resolve this issue it was deceided that for any permitation

of the possible combinations of capabilities a separate draft should be

developed. RFC6378 is the one where none of the capabilities is

used, and this draft is the one where all capabiliies are used. So far

none of the other possible drafts is written.



[Huub] This draft provides the behavior similar to APS used in ITU-T

for other technologies.



Are there

any implications for the PSC protocol if only some subset of the the
capabilities are available in a given node?  (This may be a dumb
question and I haven't tried to work out what might go wrong if you did
have any of the available subsets.)



[Huub] both nodes MUST support the same subset, if they don't the

result will be unpredictable because the state machines are different.

s9.1.1/s9.2: Following on from the previous point, s9.1.1 implies that
the system can operate happily with some subset of the five capabilities
turned on provided that both ends concur.  However there is no mode name
that would cover such a subset.



[Huub] as indicated above, the mode name does not exist because the

draft that describes that mode does not (yet) exist.



Does this actually mean that turning on
a subset doesn't really work?



[Huub] indeed, not until there is a draft that describes it.



And if it doesn't work why bother with
five flag bits?



[Huub] to give others the opportunity to write the missing draft(s), this

was the agreed by the WG chairs.



Also the phraseology used here could lead to future
problems if more capabilities are defined:  suppose some future new mode
(FOO) adds  more capabilities but the two 'modes' can be turned on
independently - as currently expressed you would have to define three
mode names for APS only, FOO only and APS + FOO.. and so on with more
capability sets.  Unintended consequence? Oh, and what if a capability
is used in more than one mode?



[Huub] it is up to the authors of additional drafts to come up with a name

for the mode described in their draft.

s8: EXER appears to test the PSC channel but nothing else.  I am not
clear that this fully satisfies R84 in RFC 5654.



[Huub] EXER verifies that the PSC engine at the far end is still running

properly and not stuck at sending the same PSC message continuously.

The PSC channel is tested by sending PSC messages regularly.

(see RFC6378 s4.1)



It may be that I don't
know what information would go back in the RR response, but should the
response say anything about the state in the remote node (like the
remote end of the working path is not working in some way and/or what is
the PSC state - RFC 6378 s3.6)?



[Huub] the fact that RR is received after sending EXER is proof that the

PSC engine is healthy. If it was not healty it would not have sent the RR.

Because EXER has the lowest priority is can only be used in the IDLE

state, so the far end could only send one state.

s13: The addition of the Capabilities TLV and the requirement that it is
carried accurately and repeatedly in every PSC message introduces a new
aspect to the DoS/random corruption problem mentioned in s6 of RFC 6378.
A single bit corruption in a PSC message will lead to disablement of
protection switching and requirement of operator intervention.  I am not
sure 

[Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt

[Elwyn Davies]

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-mpls-tp-psc-itu-02.txt
Reviewer: Elwyn Davies
Review Date: 24 Feb 2014
IETF LC End Date: 24 Feb 2014
IESG Telechat date: (if known) -

Summary:
Almost Ready for IESG.  There is a statement in s1 that could indicate
that the consequences of turning on a subset of the new capabilities has
not been fully thought through.  I am also not clear whether EXER
fulfils the intentions of R84 in RFC 5654 as stated.  The repeated
transmission of the advertised capabilities adds to the scope for random
bit errors to halt protection operation.  A few minor nits noted below.

Major issues:
None

Minor issues:
s1, next to last para:

>This document describes the behavior of the PSC protocol including
>the priority logic and the state machine when all the capabilities
>associated with the APS mode are enabled.  The PSC protocol behavior
>for the PSC mode is as defined in RFC 6378.

APS mode involves five capabilities which can, apparently, be
implemented and advertised indpendently, so presumably there might be
reasons for either implementing or turning on just a subset.  Are there
any implications for the PSC protocol if only some subset of the the
capabilities are available in a given node?  (This may be a dumb
question and I haven't tried to work out what might go wrong if you did
have any of the available subsets.) 

s9.1.1/s9.2: Following on from the previous point, s9.1.1 implies that
the system can operate happily with some subset of the five capabilities
turned on provided that both ends concur.  However there is no mode name
that would cover such a subset.  Does this actually mean that turning on
a subset doesn't really work? And if it doesn't work why bother with
five flag bits?  Also the phraseology used here could lead to future
problems if more capabilities are defined:  suppose some future new mode
(FOO) adds  more capabilities but the two 'modes' can be turned on
independently - as currently expressed you would have to define three
mode names for APS only, FOO only and APS + FOO.. and so on with more
capability sets.  Unintended consequence? Oh, and what if a capability
is used in more than one mode?

s8: EXER appears to test the PSC channel but nothing else.  I am not
clear that this fully satisfies R84 in RFC 5654.. It may be that I don't
know what information would go back in the RR response, but should the
response say anything about the state in the remote node (like the
remote end of the working path is not working in some way and/or what is
the PSC state - RFC 6378 s3.6)?

s13: The addition of the Capabilities TLV and the requirement that it is
carried accurately and repeatedly in every PSC message introduces a new
aspect to the DoS/random corruption problem mentioned in s6 of RFC 6378.
A single bit corruption in a PSC message will lead to disablement of
protection switching and requirement of operator intervention.  I am not
sure if this is a serious issue, but it probably merits a comment in s13
and verification that it does match with the words in RFC 6378 as
regards 'converging on a stable state'.

Nits/editorial comments:
s4.4, title: s/Capability 1/Priority Modifications/ (Ok, its accurate
but bald)

s7.3 et seq: The term "selector bridge" is introduced without
definition.  I suspect it is a piece of jargon I am supposed to know but
I think a reference would help.

s7.4, para 1: 

> the rules to resolve the equal priority requests are
>required.
Should this be s/the rules/some rules/?

s8, definition of Exercise (EXER): Describing EXER as 'replacing' one of
NR, RR or DNR seems a bit odd.  Mentioning RR is particularly
problematic since it makes the definitions sort of circular as RR is the
response to EXER.  I guess what is probably appropriate is to say that
it is built in the same way as an NR message would be built. 

s9.1: RFC 6378 doesn't define the encoding of the TLV type and TLV
length fields, so it needs to be done here (Unsigned integers). (It also
doesn't define encoding of the (unnecessary) overall TLV length field in
the PSC header.

s9.1: What happens if the receiver gets a TLV with some a flags length
that isn't a multiple of 4 (or indeed a TLV it deosn't recognize?)  It
might be cleaner to define the length in terms of units of 32 bits.

s10.3, para 2: s/they SHALL be disappeared./they SHALL be discarded./




___
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-mpls-special-purpose-labels-05

[Roni Even]

Hi Adrian,
I do not have a strong position on this topic ( I can agree that deprecating
a code point is a rare case) , I was wondering why the difference and I can
agree with any direction that you will choose about the maturity level
needed
Roni

> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: 24 February, 2014 1:55 PM
> To: 'Roni Even'; draft-ietf-mpls-special-purpose-labels@tools.ietf.org
> Cc: i...@ietf.org; gen-art@ietf.org
> Subject: RE: Gen-ART LC review of
draft-ietf-mpls-special-purpose-labels-05
> 
> Hi Roni,
> 
> Thanks for taking the time.
> 
> > Minor issues:
> > 1. In section 3.2 (a):  I noticed that the policy to update the
> > registry
> according
> >  to section 5 is standard action so it should be the same here since
> >this is
> an
> > update to the registry.
> 
> Hmmm, but I don't think so.
> Section 5 (and the existing registry) define the procedures to be used for
> assigning new values from a namespace per 5226. Procedures for
> retiring/deprecating values are rarely, if ever, documented and do not
need to
> follow the same rules as are used for assignments.
> 
> That said, I think I can see some value in symmetry. but it seems a bit
OTT to
> have a Standards Track RFC saying "this code point is not used". What is
certain
> (and we appear to agree on this) is that IETF consensus is needed
(presumably
> as tested by IETF last call on the relevant I-D).
> 
> Since we disagree, but my disagreement is not too strong, I will be guided
by
> the IESG (and specifically our sponsoring AD) as to whether to change:
> OLD
>An RFC with at
>least Informational status is required.
> NEW
>   A Standards
>   Track RFC is required.
> END
> 
> > Nits/editorial comments:
> > 1. In section 3 last sentence “This answer to this” should be “The ..”
> 
> Ack
> 
> > 2. In section 3.2 item c you have “for for”
> 
> Ack
> 
> Cheers,
> Adrian

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

[Gen-art] Gen-ART review for draft-ietf-mpls-ldp-applicability-label-adv-02

[Romascanu, Dan (Dan)]

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-mpls-ldp-applicability-label-adv-02

Reviewer: Dan Romascanu

Review Date: 2/24/14

IETF LC End Date: 2/24/14

IESG Telechat date:



Summary: ready with minor issues



Major issues:



Minor issues:



In the table in 2.2 - the RFC column points to RFC 5036 for the first two 
entries. Actually RFC 5036 defines only the range for LDP FEC types, but says 
nothing about the values. The right information seems to be ' (this RFC)' 
or '5036 and  (this RFC)'



Nits/editorial comments:


Some acronyms are not expanded at first occurrence - FEC, LSR


Regards,

Dan

___
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-mpls-special-purpose-labels-05

[Adrian Farrel]

Hi Roni,

Thanks for taking the time.

> Minor issues:
> 1. In section 3.2 (a):  I noticed that the policy to update the registry
according
>  to section 5 is standard action so it should be the same here since this is
an
> update to the registry.

Hmmm, but I don't think so.
Section 5 (and the existing registry) define the procedures to be used for
assigning new values from a namespace per 5226. Procedures for
retiring/deprecating values are rarely, if ever, documented and do not need to
follow the same rules as are used for assignments.

That said, I think I can see some value in symmetry. but it seems a bit OTT to
have a Standards Track RFC saying "this code point is not used". What is certain
(and we appear to agree on this) is that IETF consensus is needed (presumably as
tested by IETF last call on the relevant I-D).

Since we disagree, but my disagreement is not too strong, I will be guided by
the IESG (and specifically our sponsoring AD) as to whether to change:
OLD
   An RFC with at
   least Informational status is required.
NEW
  A Standards 
  Track RFC is required.
END

> Nits/editorial comments:
> 1. In section 3 last sentence “This answer to this” should be “The ..”

Ack

> 2. In section 3.2 item c you have “for for”

Ack

Cheers,
Adrian

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

[Gen-art] Gen-ART LC review of draft-ietf-mpls-special-purpose-labels-05

[Roni Even]

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-mpls-special-purpose-labels-05

Reviewer: Roni Even

Review Date:2014-2-24

IETF LC End Date: 2014-3-3

IESG Telechat date: 

 

Summary: This draft is almost ready for publication as Standard track RFC.

 

 

Major issues:

 

Minor issues:

1.  In section 3.2 (a):  I noticed that the policy to update the registry
according  to section 5 is standard action so it should be the same here
since this is an update to the registry.

 

 

Nits/editorial comments:

1.  In section 3 last sentence "This answer to this" should be "The .."
2.  In section 3.2 item c you have "for for"

 

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

[Gen-art] Gen-ART review of draft-ietf-roll-trickle-mcast-07

[Christer Holmberg]

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

Document: draft-ietf-roll-trickle-mcast-07

Reviewer:   Christer Holmberg

Review Date: 24 February 2014

IETF LC End Date: 7 February 2014

IETF Telechat Date: N/A

Summary:I provided comments on a previous version (-05) of this 
document. Unfortunately I can't find the reply to my comments from the authors, 
so some of my comments may not have been valid, or the authors may have 
disagreed with my change suggestions.

However, when I check the -07 version of the document I see that some of my 
comments have not been addressed, so I'll re-submit them again - just in case.


Major Issues: None

Minor Issues: None

Editorial nits:

Section 1:


Q_1_1:

I assume "LLN" stands for "Low power and Lossy Networks", but there is no 
extension anywhere. Please insert "Low power and Lossy Networks (LLN)" on first 
occurance.


Section 3:


Q_3_1:

In a few places the text says "this protocol". I would suggest to replace that 
with "MPL".


Section 4:
---

Q_4_2:

I would suggest to add something in front of "Overview" in the subject of 
section 4.3. Overview of what? :)




Regards,

Christer



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

[Gen-art] Gen-ART review of draft-ietf-eman-framework-15

[Christer Holmberg]

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-eman-framework-15.txt

Reviewer: Christer Holmberg

Review Date:   24 February 2014

IETF LC End Date:   24 February 2014

IESG Telechat date:   N/A



Summary: I have no major issues with the 
document, but I have a few editorial comments that I ask the authors to 
consider addressing.

Major issues: -



Minor issues: -



Nits/editorial comments:







Section 4:





Q4_1: The 3rd picture (Single Power Supply with Multiple 
Devices) is split between two pages. Would it be possible to make sure the 
whole picture is on a single page?



Q4_2: In the 4th picture (Multiple Power Supplies with Single 
Devices), there are two "##" lines between 'power source 1' and 'device'? 
Is there a  reason for that?





Section 5:





Q5_1: I think it would be useful to have a few general words 
about what is not covered also in the Abstract and Introduction.





Section 6.2:

--



Q6_2_1:Within section 6.2, and the subclasses, do you need to 
indicate '(Class)'? The section name already indicates '(Class)'?



Q6_2_2:Shall 'Component (Component)' be 'Component (Class)'?





Section 6.3:

--



Q6_3_1:For section 6.3.2, I suggest to change the section title 
from 'Context in General' to 'Context: General', to be aligned with the other 
Context related attributes.





Regards,



Christer

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