Subject: [mpls-tp] High/level comment on G.8110.1

From: Loa Andersson <[email-masked]>
Date: Mon, 24 May 2010 13:37:15 +0200

The draft Recommendation from ITU-T SG15 is now in IETF review.
I have one rather high-level comment on the existing text.

The second paragraph in the summary now says:

"This Recommendation complies with the transport profile of MPLS 
Architecture as defined by the IETF in [IETF tp-fw] and [IETF tp dp]. In 
the event of a difference between this ITU-T Recommendation and the 
referenced IETF RFCs, the RFCs will take precedence."

I believe this has the possibility to be ambiguous, "the referenced
IETF RFCs" could be taken to mean the MPLS-TP farmework and the MPLS-TP
Data Plane Architecture documents only, in reality it is that if
there are conflicts between G.8110.1 (or any other ITU-T
recommendation) and any of the IETF MPLS-TP
RFCs, the RFCs takes precedence.

I therefore would like the text to read:

"This Recommendation complies with the transport profile of MPLS 
Architecture as defined by the IETF in [IETF tp-fw] and [IETF tp dp]. In 
the event of a difference between this or other ITU-T
Recommendation and the set of IETF MPLS-TP RFCs, the RFCs will take 
precedence."

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: [email-masked]
Date: Tue, 25 May 2010 11:48:18 -0400

Loa,

I do not agree with your proposal for a number of reasons:

- The current text is not ambiguous it scopes the RFCs to only those
  referenced.
- One Recommendation cannot make a statement about other
  Recommendations, we need to include this statement in all
  Recommendations as per the agreement.
- If we make a blanket "any" MPLS-TP RFC then in the future the IETF
  may approve a new RFC that invalidates the Recommendation.
  The correct procedure in this case would be to develop an amendment
  or revision to reflect the new RFC and have this approved by the ITU-T. 
- A part of the IETF review of the draft Recommendations should be a
  check that the appropriate set of (currently approved) RFCs have been
  referenced.

Regards,

Malcolm

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

---

From: Loa Andersson <[email-masked]>
Date: Tue, 25 May 2010 20:36:32 +0200

Malcolm,

how about:

"This Recommendation complies with the transport profile of MPLS
  Architecture as defined by the IETF in [IETF tp-fw] and [IETF tp
  dp]. In the event of a difference between this ITU-T Recommendation
  and any of the IETF RFCs referenced in this Recommendation, the
  RFCs will take precedence."

/Loa

--

---

From: Adrian Farrel <[email-masked]>
Date: Tue, 25 May 2010 19:53:38 +0100

Hello Malcolm,

> - The current text is not ambiguous it scopes the RFCs to only those

Indeeed.

There are two questions arising from the quoted text.

1. Is the intention to limit the scope of the sentence to only the RFCs 
referenced in this sentence, or to scope it to all RFCs referenced from the 
document? I believe it should be the latter and so a change as follows would 
be at least harmless and at best beneficial.

OLD
This Recommendation complies with the transport profile of MPLS
Architecture as defined by the IETF in [IETF tp-fw] and [IETF tp dp]. In
the event of a difference between this ITU-T Recommendation and the
referenced IETF RFCs, the RFCs will take precedence.
NEW

This Recommendation complies with the transport profile of MPLS
Architecture as defined by the IETF in [IETF tp-fw] and [IETF tp dp]. In
the event of a difference between this ITU-T Recommendation and any
IETF RFC referenced by this Recommendation, the RFCs take
precedence.
END

2. How do we handle the case where there is a discrepency between this 
Recommendation and an IETF RFC that is not referenced? I would say that, as 
according to the agreement between the ITU-T and the IETF, the definitive 
specification of MPLS-TP is found in IETF RFCs. Therefore, regardless of 
whether the RFC is referenced or not, the RFC takes precedence.

Therefore, I would propose:
OLD
This Recommendation complies with the transport profile of MPLS
Architecture as defined by the IETF in [IETF tp-fw] and [IETF tp dp]. In
the event of a difference between this ITU-T Recommendation and the
referenced IETF RFCs, the RFCs will take precedence.
NEW
This Recommendation complies with the transport profile of MPLS
Architecture as defined by the IETF in [IETF tp-fw] and [IETF tp dp]. In
the event of a difference between this ITU-T Recommendation and any
IETF RFC that defines MPLS or MPLS-TP technology, the RFCs takes
precedence.
END

>  Recommendations as per the agreement.

Correct.

>  may approve a new RFC that invalidates the Recommendation.

While the IETF is the design authority on MPLS-TP, this is a risk we have to 
accept.
But note that under the current agreement, the ITU-T has review of all 
MPLS-TP RFCs, so we may assume that if this happens it has at least been 
flagged, and is probably happening for a good reason.

>  or revision to reflect the new RFC and have this approved by the ITU-T.

Ammendments and Corrigenda can always be created for published 
Recommendations. This is, after all, what you would do if a disprenecy was 
created between Recommendations.

I think that part of the "cost" of doing this as a cooperaiton project is 
that we all have to show some flexibility in the way we build the documents.

>  check that the appropriate set of (currently approved) RFCs have been

Absolutely. And part of the author duties.

And, both the authorship and the review should eliminate any discrpenecies.

But we are writing text to cover the case where there is an error. A 
discrpency is clearly an error. Leaving out a necessary reference is also an 
error.

Let's just face the reality of the agreement that the RFCs are definitive, 
and focus on the considerable useful value that the Recommendations will 
add.

Thanks,
Adrian

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 25 May 2010 21:10:55 +0200

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Adrian Farrel
Sent: Tuesday, May 25, 2010 9:54 PM
To: Loa Andersson; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] High/level comment on G.8110.1

Hello Malcolm,

Indeeed.

1. Is the intention to limit the scope of the sentence to only the RFCs 
referenced in this sentence, or to scope it to all RFCs referenced from
the 
document? I believe it should be the latter and so a change as follows
would 
be at least harmless and at best beneficial.

OLD

2. How do we handle the case where there is a discrepency between this 
Recommendation and an IETF RFC that is not referenced? I would say that,
as 
according to the agreement between the ITU-T and the IETF, the
definitive 
specification of MPLS-TP is found in IETF RFCs. Therefore, regardless of

Correct.

>  may approve a new RFC that invalidates the Recommendation.

While the IETF is the design authority on MPLS-TP, this is a risk we
have to 
accept.
But note that under the current agreement, the ITU-T has review of all 
MPLS-TP RFCs, so we may assume that if this happens it has at least been

Ammendments and Corrigenda can always be created for published 
Recommendations. This is, after all, what you would do if a disprenecy
was 
created between Recommendations.

I think that part of the "cost" of doing this as a cooperaiton project
is 
that we all have to show some flexibility in the way we build the
documents.

And, both the authorship and the review should eliminate any
discrpenecies.

But we are writing text to cover the case where there is an error. A 
discrpency is clearly an error. Leaving out a necessary reference is
also an 
error.

Let's just face the reality of the agreement that the RFCs are
definitive, 
and focus on the considerable useful value that the Recommendations will

add.

Thanks,
Adrian

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 May 2010 20:47:22 +0100

Loa

I agree with your concern and was going to propose a similar solution.

Stewart

On 25/05/2010 19:36, Loa Andersson wrote:
>> dp]. In
>> dp]. In

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: John E Drake <[email-masked]>
Date: Tue, 25 May 2010 15:19:43 -0700

+1.

However, as one of the documents mentioned in the first sentence is informational, I would suggest that we change 'defined' to 'described' in that sentence.

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stewart Bryant
> Sent: Tuesday, May 25, 2010 12:47 PM
> To: [email-masked]

---

From: [email-masked]
Date: Tue, 25 May 2010 19:19:06 -0400

Stewart, Loa,

This works for me.

thanks,

Malcolm

Stewart Bryant <[email-masked]> 
Sent by: [email-masked]
25/05/2010 03:47 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [mpls-tp] High/level comment on G.8110.1

Loa

Stewart