Subject: [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960)

From: Adrian Farrel <[email-masked]>
Date: Wed, 10 Nov 2010 07:38:36 +0000

All,

Thank you for your input and suggestions on this topic.

To be clear, we are not attempting to reach consensus on what change to make,
but I am listening to your individual opinions.

In deciding what Erratum to post, I will select a form of words that clarifies
the published RFC text, but which does not make a technical change. I intend to
reflect the consensus of the IETF that was demonstrated by the publication of
this document.

The Erratum process is intended to correct typographic or rendition issues that
produce Editorial or Technical issues in the published text. The process is not
intended to make technical changes or fixes. Such issues should be handled by
revising the work through the IETF consensus process. draft-ietf-mpls-tp-uni-nni
is a good example of how that is done.

Now, with regard to this particular Erratum.

It seems to me that there are two separate concerns.

The first concern is about identification of payloads. This is needed for a
range of reasons, and is a firm requirement in the existing text (and, indeed in
the MPLS architecture). However, it is noted that the identification may be
explicit or implicit. The text also notes that the use of explicit
identification of payload is a facilitator for demultiplexing multiplexed
payloads.

The second concern is whether there is a requirement to support payload
multiplexing. I do not believe there is any statement about the support for
multiplexing in RFC 5960. The only mention of the subject is in the filed
Erratum. It would be wrong to introduce any statement of requirement or
non-requirement through an Erratum.

So, I'm not hearing anything that persuades me that the Erratum should be
different from what I wrote. If folk want to establish a specific requirement
that multiplexing is not required, then they can go ahead and write  a draft. I
cannot speak for how the WG will greet such a draft.

Thanks,
Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 10 Nov 2010 09:46:38 +0200

Adrian,
Sounds OK.
Lots of thanks for the clarification of the process.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, November 10, 2010 9:39 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [mpls] Progressing Resolution of Erratum 2533 (RFC 5960)

All,

Thanks,
Adrian

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

---

From: <[email-masked]>
Date: Wed, 10 Nov 2010 09:00:38 +0000

These are the same issue Adrian.  That is, if the server respects the single-source requirement of a connection (crucial for deterministic resource management anyway) then provided it carries only a single client over its (connection) lifetime one does not require a PID field...this information is carried as a semantic by the parent connection construct.  We can also omit a SA from the child traffic units of a connection for exactly the same (single source) reason.

Note that this is not true for a cl-ps server...such as native Ethernet say.  In a cl-ps layer network the traffic unit MUST carry 3 absolute labels:
-	full SA label
-	full (unswapped) DA label (for forwarding)
-	PID label 

However, since a cl-ps server cannot provide deterministic resource management it is not a good idea to use it as a transport network.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 10 November 2010 07:39
> Subject: [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960)
> 
> All,
> 
> To be clear, we are not attempting to reach consensus on what 
> change to make, but I am listening to your individual opinions.
> 
> In deciding what Erratum to post, I will select a form of 
> words that clarifies the published RFC text, but which does 
> not make a technical change. I intend to reflect the 
> consensus of the IETF that was demonstrated by the 
> publication of this document.
> 
> The Erratum process is intended to correct typographic or 
> rendition issues that produce Editorial or Technical issues 
> in the published text. The process is not intended to make 
> technical changes or fixes. Such issues should be handled by 
> revising the work through the IETF consensus process. 
> draft-ietf-mpls-tp-uni-nni is a good example of how that is done.
> 
> The first concern is about identification of payloads. This 
> is needed for a range of reasons, and is a firm requirement 
> in the existing text (and, indeed in the MPLS architecture). 
> However, it is noted that the identification may be explicit 
> or implicit. The text also notes that the use of explicit 
> identification of payload is a facilitator for demultiplexing 
> multiplexed payloads.
> 
> The second concern is whether there is a requirement to 
> support payload multiplexing. I do not believe there is any 
> statement about the support for multiplexing in RFC 5960. The 
> only mention of the subject is in the filed Erratum. It would 
> be wrong to introduce any statement of requirement or 
> So, I'm not hearing anything that persuades me that the 
> Erratum should be different from what I wrote. If folk want 
> to establish a specific requirement that multiplexing is not 
> required, then they can go ahead and write  a draft. I cannot 
> speak for how the WG will greet such a draft.
> 
> Thanks,
> Adrian
> 
> 
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: [email-masked]
Date: Wed, 10 Nov 2010 07:09:03 -0500

Adrian,

Thank you for the clarification the process. I now understand that the 
erratum was the wrong  approach to address this comment from the ITU.

Unfortunately I don't think that the change you are proposing will address 
the comment raised in the liaison from the ITU. 
"This change is intended to clarify that providing a multiplexing 
capability for a section layer is optional." 

My understanding is that the only motivation for the erratum was to 
address this comment, if this is the case then I see little point in 
progressing the erratum.

Regards,

Malcolm

Adrian Farrel <[email-masked]> 
Sent by: [email-masked]
10/11/2010 02:38 AM
Please respond to
[email-masked]

To
[email-masked], [email-masked], [email-masked]
cc

Subject
[mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960)

All,

To be clear, we are not attempting to reach consensus on what change to 
make,
but I am listening to your individual opinions.

In deciding what Erratum to post, I will select a form of words that 
clarifies
the published RFC text, but which does not make a technical change. I 
intend to
reflect the consensus of the IETF that was demonstrated by the publication 
of
this document.

The Erratum process is intended to correct typographic or rendition issues 
that
produce Editorial or Technical issues in the published text. The process 
is not
intended to make technical changes or fixes. Such issues should be handled 
by
revising the work through the IETF consensus process. 
draft-ietf-mpls-tp-uni-nni
is a good example of how that is done.

The first concern is about identification of payloads. This is needed for 
a
range of reasons, and is a firm requirement in the existing text (and, 
indeed in
the MPLS architecture). However, it is noted that the identification may 
be
explicit or implicit. The text also notes that the use of explicit
identification of payload is a facilitator for demultiplexing multiplexed
payloads.

multiplexing. I do not believe there is any statement about the support 
for

So, I'm not hearing anything that persuades me that the Erratum should be
different from what I wrote. If folk want to establish a specific 
requirement
that multiplexing is not required, then they can go ahead and write  a 
draft. I
cannot speak for how the WG will greet such a draft.

Thanks,
Adrian

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Wed, 10 Nov 2010 16:57:42 +0100

I agree that the changes proposed by Adrian are not resolving the ITU-T comment. I also understand NOW that the erratum was the wrong approach to resolve the comment.

Note that in the reply sent by the IETF chair to the ITU-T LS it was explicitly said:

"
If IETF contributors feel that there is an issue to be resolved, there are two processes that are available to make changes to published RFCs.
One method is to submit an Erratum Notice using the IETF web pages (http://www.rfc-editor.org/errata.php). The other method is to produce a revision or modification to the published RFC by submitting an Internet-Draft and taking it through the IETF consensus process. Both methods are subject to review before approval.
"

I am very concerned by the way this issue has been managed by the IETF.

The Routing ADs attended, as ISOC representatives, the ITU-T meeting where the comment was developed; so they were fully aware of its technical content. A proper instruction from them at the time the Erratum was submitted (i.e., 30 September) would have saved a lot of time and speeded up the resolution of the ITU-T comment.

I was also confused by the fact that one of the two Routing AD during the same ITU-T meeting claimed that the proposed text was just a minor editorial change the editors could have easily fixed despite the document was in the RFC Editor Queue.

I am very concerned to see that people are speaking with different voices in different SDOs: this behaviour is not helping the standardization work to progress in the right direction nor the convergence between ITU-T and IETF.

Italo

________________________________
Da: [email-masked] [mailto:[email-masked]] Per conto di [email-masked]
Inviato: mercoledì 10 novembre 2010 20.09
A: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Oggetto: Re: [mpls-tp] Progressing Resolution of Erratum 2533 (RFC 5960)

Adrian,

Thank you for the clarification the process. I now understand that the erratum was the wrong  approach to address this comment from the ITU.

Unfortunately I don't think that the change you are proposing will address the comment raised in the liaison from the ITU.
"This change is intended to clarify that providing a multiplexing capability for a section layer is optional."

My understanding is that the only motivation for the erratum was to address this comment, if this is the case then I see little point in progressing the erratum.

Regards,

Malcolm

10/11/2010 02:38 AM
Please respond to
[email-masked]

To

cc

Subject

All,

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Nov 2010 17:49:45 -0000

Italo,

> I agree that the changes proposed by Adrian are not resolving the ITU-T
> comment. I  also understand NOW that the erratum was the wrong
> approach to resolve the comment.

Indeed, the work on the erratum was designed to address your comment, not the
ITU-T comment. Will you be withdrawing the erratum you raised?

If so, you will need to do it quickly as it is likely to get approved within 48
hours.

> If IETF contributors feel that there is an issue to be resolved, there are two
> processes that are available to make changes to published RFCs.
> One method is to submit an Erratum Notice using the IETF web pages
> (http://www.rfc-editor.org/errata.php). The other method is to produce a
> revision or modification to the published RFC by submitting an Internet-Draft
> and taking it through the IETF consensus process. Both methods are subject
> to review before approval.

Yes, that seems to reflect reality.

Since you used this web page to file the errata, you will have read the material
linked at the bottom of the page. This includes
http://www.ietf.org/iesg/statement/errata-processing.html which says:

   Errata are meant to fix "bugs" in the specification and should not be used to
change
   what the community meant when it approved the RFC.

> The Routing ADs attended, as ISOC representatives, the ITU-T meeting
> where the comment was developed; so they were fully aware of its
> technical content. 

Attending an SG15 meeting is not quite the same as participating fully in the
specific discussions within in one of the side meetings. As I recall, I dipped
into this meeting for a few minutes and made some observations about the need
for clarity in the liaison, but I did not stay until the end of the discussion.
It is further not my practice to interfere in the construction of liaisons to
the IETF, and I assumed that the text of the liaison was to be taken at face
value.

It now transpires that the wording change was a specific request to change the
requirements (i.e. to set a non-requirement on the support of multiplexing).
Notwithstanding that there is no stated requirement for multiplexing, this
requested change is obviously a technical change to the RFC. Had the liaison
been more explicit about what functional changes to the document were required
(as well as helpfully providing text) this fact would have been more obvious,
and better advice could have been given.

>  proper instruction from them at the time the Erratum was submitted 
> (i.e., 30 September) would have saved a lot of time and speeded up
> the resolution of the ITU-T comment.

Note that the erratum may be derived from an ITU-T comment, but it is not of
itself an ITU-T comment. The erratum is raised by one individual, and is treated
as such.

As has been blatantly obvious from the discussions, the intention of the erratum
(as with the liaison comment) is far from obvious. Had it been clear that the
intention was to make a technical change, the erratum could have been rejected
immediately. However, the text supplied in the erratum looked like an attempt to
make an editorial clarification and was treated accordingly.

> I was also confused by the fact that one of the two Routing AD during
> the same ITU-T meeting claimed that the proposed text was just a minor
> editorial change the editors could have easily fixed despite the document
> was in the RFC Editor Queue.

Looks like you have every cause to be glad the change was not made during the
RFC Editor process. This way of handling it would have given you no chance to
comment, and it looks like the change that would have been made would not have
provided what you wanted.

In this, as in so many things, we have to be grateful for the wisdom of the IETF
chair in directing that the change should not be handled at such a late stage,
but should be sorted out through one of the available post-publication
mechanisms.

> I am very concerned to see that people are speaking with different
> voices in different SDOs: this behaviour is not helping the standardization
> work to progress in the right direction nor the convergence between 
> ITU-T and IETF.

This tendency to speak differently in different places also bothers me. As,
indeed it bothers me when we lose focus through not trying to do all the
development work (including reviewing documents) in the agreed forum.

Please consider whether you plan to withdraw this Erratum and also number 2534. 

Adrian

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 10 Nov 2010 18:24:30 +0000

[Trimmed to MPLS-TP list only]

Italo,

Maybe you or one of the other folks that attended the ITU-T meeting can help me out as I neither attended the meeting nor subscribe to any ITU-T mailing lists.

What is the background/motivation to the ITU-T comment? i.e. why is it so important that multiplexing at the data-link layer be declared optional?

I appreciate that the comment came via liaison and should be given due consideration but I see an awful lot of effort & time being expended on what is essentially a NOOP.

Given the amount of technical work still to be completed with MPLS-TP and that some folks are concerned at the time it is taking to get MPLS-TP "out the door" expending so much time & energy on a NOOP is IMO extremely counter-productive.

Can we take a step back and ask ourselves if the text in 5960 stays as-is (or we use Adrian's proposed text change) what breaks? What do we preclude implementations from doing? What pain do we cause implementers and Operators? I posit the answer to all three questions is "Nothing".

Can we not just drop this and get on with real technical work?

Ben
 
On 10 Nov 2010, at 15:57, BUSI, ITALO (ITALO) wrote:

> “
> “

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Thu, 11 Nov 2010 02:49:37 +0100

Adrian,

I raised the comment to facilitate the resolution of the outstanding comment from ITU-T and enable ITU-T to make normative reference to RFC 5960.

As such I will withdraw the Errata 2533.

Can we meet just after the MPLS WG session to get specific instructions of what I have to do?

Thanks for raising the flag also about Errata 2534 (you anticipated another mail I was going to write this morning): I did not see any discussion on it. Does it fall into the same category as Errata 2533 (i.e., proposing changes to the original intent of the WG decisions)?

Just a note, the intention of the comment were clearly stated in the ITU-T liaison and reported in the note to the Errata:

"
This change is intended to clarify that providing a multiplexing capability for a section layer is optional.
"

What was not clear to me at the time I submitted the Errata is that this change was changing the intent of the text in RFC 5960 given the way the comment was qualified by one of the editor during the ITU-T discussion.

Italo

> -----Messaggio originale-----
> Da: Adrian Farrel [mailto:[email-masked]]
> Inviato: giovedì 11 novembre 2010 1.50
> A: BUSI, ITALO (ITALO); [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Oggetto: RE: [mpls-tp] R: Progressing Resolution of Erratum 2533 (RFC
> 5960)
> 
> Italo,
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 11 Nov 2010 01:58:19 +0000

Italo

You should use this draft as a template

http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00

Of course it will have to start at draft-busi-mpls-tp-data-plane-bis, 
and the MPLS WG will have to decide whether it wishes to adopt the draft.

- Stewart

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Thu, 11 Nov 2010 03:11:16 +0100

Adrian,

I change the subject given the different topic of the discussion.

In a previous mail (on another topic) you wrote:

> As,

First of all, thanks for having raised your concerned.

I would like to briefly summarize the history.

At the beginning of the process, ITU-T experts were sending their comments, as IETF participants, directly to the IETF mailing lists (MEAD, MPLS WG and MPLS-TP).

This way of working resulted in a complain from IETF leadership to the ITU-T leadership against the fact that ITU-T was not providing comments to the work in IETF.

As a consequence, it was decided that LS for comments would have been exchanged between the two SDOs to force ITU-T participants to raise comments as early as possible in the development process.

As a consequence many ITU-T experts (including myself) started to raise their comments in ITU-T to fulfill ITU-T obligations to provide comments to IETF.

In addition to this, cross-posting between ITU-T and IETF mailing lists is constantly discouraged by one MPLS WG co-chair because this confuses the editors.

So in a nutshell for an ITU-T expert:

- commenting on the IETF list as an IETF participant is a bad behavior because this means that ITU-T does not collaborate;

- commenting on the ITU-T list is a bad behavior because this means that we are loosing focus;

- commenting on both ITU-T and IETF lists is a bad behavior because it confuses the editors.

Could you please help the ITU-T experts to understand what it the best behavior to provide comments to the process?

Thanks, Italo

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Thu, 11 Nov 2010 03:30:49 +0100

Ben,

Your questions are valid and I am going to work on them.

However, I fail to understand the difficulties in making a change that is considered a NOOP but would improve the relationship between ITU-T and IETF.

I was not the one who raised the comment at the ITU-T.

I am just trying to do all my best to resolve the issue that was created by the IETF management when they decided to move forward and publish RFC 5960 without resolving the outstanding ITU-T comments.

If IETF had followed the process that it agreed with ITU-T we all would have save a lot of time and speeded up the work.

Italo

> Da: Ben Niven-Jenkins [mailto:[email-masked]]
> Inviato: giovedì 11 novembre 2010 2.25
> A: BUSI, ITALO (ITALO)
> Cc: [email-masked]; Adrian Farrel; [email-masked]
> Oggetto: Re: [mpls-tp] R: Progressing Resolution of Erratum 2533 (RFC
> 5960)
> 
> Maybe you or one of the other folks that attended the ITU-T meeting can
> help me out as I neither attended the meeting nor subscribe to any ITU-T
> mailing lists.
> 
> What is the background/motivation to the ITU-T comment? i.e. why is it so
> important that multiplexing at the data-link layer be declared optional?
> 
> I appreciate that the comment came via liaison and should be given due
> consideration but I see an awful lot of effort & time being expended on
> what is essentially a NOOP.
> 
> Given the amount of technical work still to be completed with MPLS-TP and
> that some folks are concerned at the time it is taking to get MPLS-TP "out
> the door" expending so much time & energy on a NOOP is IMO extremely
> counter-productive.
> 
> Can we take a step back and ask ourselves if the text in 5960 stays as-is
> (or we use Adrian's proposed text change) what breaks? What do we preclude
> implementations from doing? What pain do we cause implementers and
> Operators? I posit the answer to all three questions is "Nothing".
> 
> comment. I also understand NOW that the erratum was the wrong approach to
> resolve the comment.
> >
> > If IETF contributors feel that there is an issue to be resolved, there
> are two processes that are available to make changes to published RFCs.
> revision or modification to the published RFC by submitting an Internet-
> Draft and taking it through the IETF consensus process. Both methods are
> subject to review before approval.
> > "
> >
> where the comment was developed; so they were fully aware of its technical
> content. A proper instruction from them at the time the Erratum was
> submitted (i.e., 30 September) would have saved a lot of time and speeded
> up the resolution of the ITU-T comment.
> >
> voices in different SDOs: this behaviour is not helping the
> standardization work to progress in the right direction nor the
> convergence between ITU-T and IETF.
> >
> > Italo
> >
> > Unfortunately I don't think that the change you are proposing will
> address the comment raised in the liaison from the ITU.
> multiplexed