Subject: Re: [mpls] MPLS-RT review of draft-cdh-mpls-tp-psc-non-revertive

From: Eric Gray <[email-masked]>
Date: Fri, 23 Aug 2013 13:17:01 +0000

Hi,

	I have been asked to review this draft, and to determine if it is in good enough
shape to be adopted by the MPLS working group.
	
	Although requested to include the MPLS working group mailing list as a "Cc", I
have included it as a "To" because of the questions I think need to be resolved either 
by discussion in the working group, or decision by the working group chairs.

	In general, I find this draft to be well written and may be ready for adoption by the 
MPLS working group.  There are two general questions about what may be acceptable to 
the working group that should be resolved in some way prior to adoption of this draft by 
the working group.  The questions are included as the first part of my comments below.

	I have the following comments and/or questions:

Major Comments/Questions:
======================

General questions for the MPLS working Group
----------------------------------------------------------

First Question --
The way that this draft is written is as a "delta" to RFC 6378.  I personally do not have any
problems with this, assuming that a reader can correctly (re)construct the resulting text
as applied to RFC 6378.  

However, over the long term, it is significant that this "delta" will not actually be applied
to RFC 6378 and may therefore lead to ambiguity and/or confusion if other subsequent
"deltas" are produced against the same RFC in the future.  When/if this happens, it is
likely that the combination of multiple "delta" RFCs will force a re-write of RFC 6378 to
remove ambiguity and/or confusion.

As an example, should a subsequent "update" to RFC 6378 suggest changes that result
in renumbering of the sections affected by this document, there will likely be confusion 
resulting from the order that a reader reads the set of documents, applying the changes 
in the order that they read them, as opposed to the order in which they were written and 
intended.

Is the working group generally okay with taking this approach?

(Alternatively, this draft could be re-written as a "bis" for RFC 6378, obsoleting that RFC
as opposed to updating it, or it could be re-written as a quasi-stand-alone document - 
rather than as a set of deltas to RFC 6378 - referring to RFC 6378 for protection switching 
behavior not explicitly described in this document.)

Second Question --
Is it simpler to deal with this draft as a separate draft, or should it be combined with the
other related drafts that are also (at least primarily) intended to update RFC 6378?

At least with the two drafts I've been asked to review (adding signal degrade, and making
corrections to non-revertive mode), the modifications to RFC 6378 appear to be distinct,
non-overlapping, changes throughout the drafts.  Where this is more difficult to be certain
of is in the changes to the state-machine tables - which are quite complex.

At various points in the process, when reviewing the draft, the best approach to verifying
that there is no overlap or inconsistency is to actually merge all of the changes and then
review the result.  If this turns out to be the case for every reviewer, then there is no
benefit to having these as separate drafts.

Should all of these related drafts be merged?

Minor Comments and NITs:
====================

You need to add "updates RFC 6378 (when published)" to the header of the first page.

I suggest omitting "contains the updates to" from the abstract, replacing it with "updates"
and adding a second comma after "Linear Protection" (the text "MPLS Transport Profile ...
Linear Protection" is a parenthetical description of RFC 6378).  The same comment applies
to the last paragraph in the Introduction section as well.

In the third paragraph of the Introduction section, the second sentence is an incomplete
sentence and does not make sense as is.  I believe the "period" after "Section 4.3.3.6" is
supposed to be a comma.

In the fourth paragraph, "missing" should be "omission" (possibly auto-correct?).

Abbreviations should be defined at least near where they are used - especially in section 
headers (see sections 1.1 and 1.2).  Preferably they should be defined (or expanded) 
before they are used, but this is awkward in section headers (and messes up the ToC).

I suggest adding a new first paragraph in each section where this occurs, with the express
purpose of at least expanding these acronyms/abbreviations.

The first paragraph in section 1.2 is awkwardly worded, creating an apparent inconsistency.
Perhaps the authors would consider re-wording the first sentence of the paragraph along 
the lines of:

"The MS-P and MS-W commands SHALL have the same priority, except in the case where
 both are received simultaneously."

It is worth noting that - possibly - this exception (and the text currently in the paragraph
that "justifies" it) could (and possibly should) be omitted.  Because "simultaneity" is not
a verifiable occurrence, the scenario this text describes is not testable or necessarily 
observable outside of the implementation.

In section 4, "Manual Switch to Working" should be in quotes as it not clear how the text
in the paragraph would otherwise be grouped to one not familiar with this command.
That is, it is currently possible to read this as "... add 'Manual Switch' to 'Working operator
command' ..." - which makes little sense (forcing the reader to re-read this until they've
worked out the intended meaning).

--
Eric Gray

---

From: "Taesik Cheung" <[email-masked]>
Date: Mon, 26 Aug 2013 11:55:02 +0900

Hi Eric (Gray),

Thank you for reviewing draft-cdh-mpls-psc-non-revertive-00.

As one of authors of the draft, I answered your comments.
Please see [Taesik] inline.

Best regards,
Taesik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Gray
Sent: Friday, August 23, 2013 10:17 PM
To: Taesik Cheung; Huub van Helvoort ([email-masked]);
Alessandro D Alessandro; [email-masked]
Cc: Ross Callon ([email-masked])
Subject: Re: [mpls] MPLS-RT review of draft-cdh-mpls-tp-psc-non-revertive

Hi,

	I have been asked to review this draft, and to determine if it is in
good enough shape to be adopted by the MPLS working group.
	
	Although requested to include the MPLS working group mailing list as
a "Cc", I have included it as a "To" because of the questions I think need
to be resolved either by discussion in the working group, or decision by the
working group chairs.

	In general, I find this draft to be well written and may be ready
for adoption by the MPLS working group.  There are two general questions
about what may be acceptable to the working group that should be resolved in
some way prior to adoption of this draft by the working group.  The
questions are included as the first part of my comments below.

First Question --
The way that this draft is written is as a "delta" to RFC 6378.  I
personally do not have any problems with this, assuming that a reader can
correctly (re)construct the resulting text as applied to RFC 6378.  

However, over the long term, it is significant that this "delta" will not
actually be applied to RFC 6378 and may therefore lead to ambiguity and/or
confusion if other subsequent "deltas" are produced against the same RFC in
the future.  When/if this happens, it is likely that the combination of
multiple "delta" RFCs will force a re-write of RFC 6378 to remove ambiguity
and/or confusion.

As an example, should a subsequent "update" to RFC 6378 suggest changes that
result in renumbering of the sections affected by this document, there will
likely be confusion resulting from the order that a reader reads the set of
documents, applying the changes in the order that they read them, as opposed
to the order in which they were written and intended.

(Alternatively, this draft could be re-written as a "bis" for RFC 6378,
obsoleting that RFC as opposed to updating it, or it could be re-written as
a quasi-stand-alone document - rather than as a set of deltas to RFC 6378 -
referring to RFC 6378 for protection switching behavior not explicitly
described in this document.)

[Taesik] This comment is not for the authors of this draft.

Second Question --
Is it simpler to deal with this draft as a separate draft, or should it be
combined with the other related drafts that are also (at least primarily)
intended to update RFC 6378?

At least with the two drafts I've been asked to review (adding signal
degrade, and making corrections to non-revertive mode), the modifications to
RFC 6378 appear to be distinct, non-overlapping, changes throughout the
drafts.  Where this is more difficult to be certain of is in the changes to
the state-machine tables - which are quite complex.

At various points in the process, when reviewing the draft, the best
approach to verifying that there is no overlap or inconsistency is to
actually merge all of the changes and then review the result.  If this turns
out to be the case for every reviewer, then there is no benefit to having
these as separate drafts.

[Taesik] This comment is not for the authors of this draft.

Minor Comments and NITs:
====================

You need to add "updates RFC 6378 (when published)" to the header of the
first page.
[Taesik] It can be reflected in the next revision of the draft.

I suggest omitting "contains the updates to" from the abstract, replacing it
with "updates"
and adding a second comma after "Linear Protection" (the text "MPLS
Transport Profile ...
Linear Protection" is a parenthetical description of RFC 6378).  The same
comment applies to the last paragraph in the Introduction section as well.
[Taesik] It can be reflected in the next revision of the draft.

In the third paragraph of the Introduction section, the second sentence is
an incomplete sentence and does not make sense as is.  I believe the
"period" after "Section 4.3.3.6" is supposed to be a comma.
[Taesik] It can be reflected in the next revision of the draft.

In the fourth paragraph, "missing" should be "omission" (possibly
auto-correct?).
[Taesik] It can be reflected in the next revision of the draft.

Abbreviations should be defined at least near where they are used -
especially in section headers (see sections 1.1 and 1.2).  Preferably they
should be defined (or expanded) before they are used, but this is awkward in
section headers (and messes up the ToC).

I suggest adding a new first paragraph in each section where this occurs,
with the express purpose of at least expanding these acronyms/abbreviations.
[Taesik] MS-W is already expanded in both Abstract and Section 1 of the
draft. For MS-P, it can be expanded in both Abstract and Section 1 in the
next revision of the draft. But, before doing this, we need to agree on the
renaming because there is another review's comment not supporting this
renaming.

The first paragraph in section 1.2 is awkwardly worded, creating an apparent
inconsistency.
Perhaps the authors would consider re-wording the first sentence of the
paragraph along the lines of:

"The MS-P and MS-W commands SHALL have the same priority, except in the case
where  both are received simultaneously."
[Taesik] I don't think that there is an inconsistency between the first
sentence and the rests of the first paragraph. If you see Sec 4.6 of the
draft, priorities of MS-P and MS-W are defined to be same. Sec 1.2 describes
how to resolve when those two commands are entered to the PSC logic
simultaneously.

It is worth noting that - possibly - this exception (and the text currently
in the paragraph that "justifies" it) could (and possibly should) be
omitted.  Because "simultaneity" is not a verifiable occurrence, the
scenario this text describes is not testable or necessarily observable
outside of the implementation.
[Taesik] I think that the PSC protocol state machine should be defined to
cover all the possible cases regardless of the difficulty in verification.
Moreover, this simultaneous condition is not so difficult to test because
"simultaneity" considered in this draft does not mean the absolutely same
time. Please see item c) in Sec 4.6 of this draft, which describes the
meaning of "simultaneous condition".

In section 4, "Manual Switch to Working" should be in quotes as it not clear
how the text in the paragraph would otherwise be grouped to one not familiar
with this command.
That is, it is currently possible to read this as "... add 'Manual Switch'
to 'Working operator command' ..." - which makes little sense (forcing the
reader to re-read this until they've worked out the intended meaning).
[Taesik] It can be reflected in the next revision of the draft.

--
Eric Gray

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls