I agree to Dave's point but that should be
description vs. operation + Prohibition also. We need to add a prohibition protocol field in the TCP/IP suite. that should be in IP Packet with perfect 8 bits field ... what say???
greetings,
Sanjay Chalikar
+91- 96 37 43 62 87.
On Mon, Jan 9, 2012 at 11:11 PM, <ietf-request@xxxxxxxx> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. To do so, go to
https://www.ietf.org/mailman/listinfo/ietf
Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME. You can set this option
globally for all the list digests you receive at this point.
Send Ietf mailing list submissions to
ietf@xxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ietf
or, via email, send a message with subject or body 'help' to
ietf-request@xxxxxxxx
You can reach the person managing the list at
ietf-owner@xxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ietf digest..."
Today's Topics:
1. Re: Protocol Definition (Dave CROCKER)
2. Re: Protocol Definition (John Day)
3. FW: New Liaison Statement, "LS370 - Current status of
Recommendation ITU-T G.8113.1/Y.1372.1, Operations,
Administration and Maintenance mechanism for MPLS-TP in Packet
Transport Network (PTN)" (Scott Mansfield)
4. FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations"
(Scott Mansfield)
5. Re: Requirements for improving IETF remote participation
(Joel jaeggli)
6. RE: Questions about draft-betts-itu-oam-ach-code-point
(Adrian Farrel)
7. RE: [CCAMP] New Liaison Statement, "LS370 - Current status
ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations,
Administration andMaintenance mechanism for MPLS-TP in
PacketTransport Network (PTN)"
(Sprecher, Nurit (NSN - IL/Hod HaSharon))
----------------------------------------------------------------------
Message: 1
Date: Mon, 09 Jan 2012 06:39:24 -0800
From: Dave CROCKER <dhc@xxxxxxxxxxxx>
To: "t.petch" <daedulus@xxxxxxxxxxxxx>
Cc: dcrocker@xxxxxxxx, IETF-Discussion <ietf@xxxxxxxx>
Subject: Re: Protocol Definition
Message-ID: <4F0AFC1C.1060905@xxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 1/8/2012 12:03 AM, t.petch wrote:
> I agree that a message is not the right word, but I think that protocol is:-)
There is a specific distinction that is intended by having two different words:
description vs. operation.
A program is a description of behavior. A process is the operation of the
description. It is the behavioral performance.
Protocol refers to the description of an interaction. The term being explored
is for the operation of that description. It is the interaction.
> For the abstract side of networking, I would use the same terminology as I would
> use for a 'program'.
If you mean that you would say 'process' for both, that does have the appeal of
familiarity, but the problem of overloading. Worse, I'd fear that it encourages
a failure to appreciate the differences between networking architecture and
software implementation. Since this failure is quite prevalent, I suggest we
not encourage it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
------------------------------
Message: 2
Date: Mon, 9 Jan 2012 10:36:59 -0500
From: John Day <jeanjour@xxxxxxxxxxx>
To: dcrocker@xxxxxxxx, "t.petch" <daedulus@xxxxxxxxxxxxx>
Cc: dcrocker@xxxxxxxx, IETF-Discussion <ietf@xxxxxxxx>
Subject: Re: Protocol Definition
Message-ID: <a06240809cb30b7a03ac3@[10.0.1.26]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 6:39 -0800 2012/01/09, Dave CROCKER wrote:
>On 1/8/2012 12:03 AM, t.petch wrote:
>>I agree that a message is not the right word, but I think that protocol is:-)
>
>There is a specific distinction that is intended by having two
>different words: description vs. operation.
>
>A program is a description of behavior. A process is the operation
>of the description. It is the behavioral performance.
>
>Protocol refers to the description of an interaction. The term
>being explored is for the operation of that description. It is the
>interaction.
>
Agreed.
>>For the abstract side of networking, I would use the same
>>terminology as I would
>>use for a 'program'.
>
>If you mean that you would say 'process' for both, that does have
>the appeal of familiarity, but the problem of overloading. Worse,
>I'd fear that it encourages a failure to appreciate the differences
>between networking architecture and software implementation. Since
>this failure is quite prevalent, I suggest we not encourage it.
Well, pretty close. There is a copious literature on the formal
description and verification of protocols beginning in the 70s.
There are two major issues that is not normally found in defining a
"program": 1) is specifying the asynchrony, ensuring no races, and
2) keeping the specification implementation independent. One does
not want the specification to unnecessarily constrain the
implementation strategy. The general rule is Day's First Rule of
Architecture: Anything you can get away with that is undetectable
from the outside is legal. Or when it comes to implementation sleaze
the architecture.
We have seen the problems of code monoculture or just assuming the
other guys knew how to code.
Take care,
John
------------------------------
Message: 3
Date: Sun, 8 Jan 2012 08:53:05 -0500
From: Scott Mansfield <scott.mansfield@xxxxxxxxxxxx>
To: "ietf@xxxxxxxx" <ietf@xxxxxxxx>, "mpls@xxxxxxxx" <mpls@xxxxxxxx>,
"pwe3@xxxxxxxx" <pwe3@xxxxxxxx>, "ccamp@xxxxxxxx" <ccamp@xxxxxxxx>
Cc: "swallow@xxxxxxxxx" <swallow@xxxxxxxxx>, "stbryant@xxxxxxxxx"
<stbryant@xxxxxxxxx>, "adrian@xxxxxxxxxxxx" <adrian@xxxxxxxxxxxx>,
"andrew.g.malis@xxxxxxxxxxx" <andrew.g.malis@xxxxxxxxxxx>,
"dbrungard@xxxxxxx" <dbrungard@xxxxxxx>
Subject: FW: New Liaison Statement, "LS370 - Current status of
Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration and
Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)"
Message-ID:
<FDC72027C316A44F82F425284E1C4C321736E51ABE@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
This is a liaison from the ITU-T SG15 WP3 providing a copy of the Determined recommendation G.8113.1 (May 2011). The liaison also provides a pointer to the internet draft draft-betts-itu-oam-ach-code-point that requests an ACh code point that is needed by G.8113.1. This is a liaison that will require a response and the ITU-T has requested a response no later than 1 August 2012. I would suggest that we use the liaison response to provide the outcome of running the IETF process required to assign the requested code point.
Regards,
-scott.
IETF-ITU Liaison Manager for MPLS
> -----Original Message-----
> From: Liaison Statement Management Tool [mailto:lsmt@xxxxxxxx]
> Sent: Sunday, January 08, 2012 3:23 AM
> To: chair@xxxxxxxx
> Cc: yoichi.maeda@xxxxxxxxx;
> steve.trowbridge@xxxxxxxxxxxxxxxxxx; iesg@xxxxxxxx;
> lear@xxxxxxxxx; Scott Mansfield; malcolm.betts@xxxxxxxxxx;
> tsbsg15@xxxxxxx; greg.jones@xxxxxxx; hiroshi.ota@xxxxxxx
> Subject: New Liaison Statement, "LS370 - Current status of
> Recommendation ITU-T G.8113.1/Y.1372.1, Operations,
> Administration and Maintenance mechanism for MPLS-TP in
> Packet Transport Network (PTN)"
>
> Title: LS370 - Current status of Recommendation ITU-T
> G.8113.1/Y.1372.1, Operations, Administration and Maintenance
> mechanism for MPLS-TP in Packet Transport Network (PTN)
> Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/
>
> From: ITU-T SG 15 (Greg Jones <greg.jones@xxxxxxx>)
> To: The IESG (chair@xxxxxxxx)
> Cc:
> yoichi.maeda@xxxxxxxxx,steve.trowbridge@xxxxxxxxxxxxxxxxxx,ies
> g@xxxxxxxx,lear@xxxxxxxxx,Scott.Mansfield@xxxxxxxxxxxx
> Reponse Contact:
> tsbsg15@xxxxxxx,greg.jones@xxxxxxx,hiroshi.ota@xxxxxxx
> Technical Contact: malcolm.betts@xxxxxxxxxx
> Purpose: For information
>
> Body: The December meeting of ITU-T Study Group 15 considered
> the approval of Recommendation ITU-T G.8113.1/Y.1372.1,
> Operations, Administration and Maintenance mechanism for
> MPLS-TP in Packet Transport Network (PTN). Unfortunately the
> Study Group could not approve this Recommendation so it was
> forwarded to the WTSA (20-29 November 2012) for approval.
> One of the issues that prevented the approval in SG 15 was
> the lack of an ACh code point to support this Recommendation.
> To resolve this issue SG 15 therefore requests the IETF to
> assign an ACh code point. An IETF draft
> draft-betts-itu-oam-ach-code-point has been submitted to
> request this code point.
> We have attached the text of the current draft of
> Recommendation ITU-T G.8113.1/Y.1372.1 that has been
> forwarded to the WTSA for approval.
> Attach: COM15R-22.
>
> Attachment(s):
>
> LS370 - pdf body
> https://datatracker.ietf.org/documents/LIAISON/file1306.pdf
>
> LS370 - pdf attachment
> https://datatracker.ietf.org/documents/LIAISON/file1307.pdf
>
>
>
------------------------------
Message: 4
Date: Sun, 8 Jan 2012 09:01:22 -0500
From: Scott Mansfield <scott.mansfield@xxxxxxxxxxxx>
To: "ietf@xxxxxxxx" <ietf@xxxxxxxx>, "mpls@xxxxxxxx" <mpls@xxxxxxxx>,
"pwe3@xxxxxxxx" <pwe3@xxxxxxxx>, "ccamp@xxxxxxxx" <ccamp@xxxxxxxx>
Cc: "swallow@xxxxxxxxx" <swallow@xxxxxxxxx>, "stbryant@xxxxxxxxx"
<stbryant@xxxxxxxxx>, "adrian@xxxxxxxxxxxx" <adrian@xxxxxxxxxxxx>,
"andrew.g.malis@xxxxxxxxxxx" <andrew.g.malis@xxxxxxxxxxx>,
"dbrungard@xxxxxxx" <dbrungard@xxxxxxx>
Subject: FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations"
Message-ID:
<FDC72027C316A44F82F425284E1C4C321736E51ABF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
This is a liaison from SG15 Q9, Q12, and Q14 providing the text of G.8110.1, G.8121, and G.8151. This liaison is for information only. G.8110.1 was approved at the SG15 plenary meeting in December 2011. G.8121 and G.8151 entered the alternative approval process (AAP) and will enter a 4 week last call (the last call hasn't been initiated yet).
Regards,
-scott.
IETF-ITU Liaison Manager for MPLS
> -----Original Message-----
> From: Liaison Statement Management Tool [mailto:lsmt@xxxxxxxx]
> Sent: Sunday, January 08, 2012 3:51 AM
> To: rcallon@xxxxxxxxxxx; swallow@xxxxxxxxx; loa@xxxxx
> Cc: yoichi.maeda@xxxxxxxxx;
> steve.trowbridge@xxxxxxxxxxxxxxxxxx; mpls@xxxxxxxx;
> lear@xxxxxxxxx; Scott Mansfield; stbryant@xxxxxxxxx;
> adrian@xxxxxxxxxxxx; malcolm.betts@xxxxxxxxxx; Ghani Abbas;
> Kam.Lam@xxxxxxxxxxxxxxxxxx; tsbsg15@xxxxxxx;
> greg.jones@xxxxxxx; hiroshi.ota@xxxxxxx
> Subject: New Liaison Statement, "LS368 - MPLS-TP Recommendations"
>
> Title: LS368 - MPLS-TP Recommendations
> Submission Date: 2012-01-08
> URL of the IETF Web page: /liaison/1126/
>
> From: ITU-T SG 15 (Greg Jones <greg.jones@xxxxxxx>)
> To: Multiprotocol Label Switching (rcallon@xxxxxxxxxxx,
> swallow@xxxxxxxxx, loa@xxxxx)
> Cc:
> yoichi.maeda@xxxxxxxxx,steve.trowbridge@xxxxxxxxxxxxxxxxxx,mpl
> s@xxxxxxxx,lear@xxxxxxxxx,Scott.Mansfield@xxxxxxxxxxxx,stbryan
> t@xxxxxxxxx,adrian@xxxxxxxxxxxx
> Reponse Contact:
> tsbsg15@xxxxxxx,greg.jones@xxxxxxx,hiroshi.ota@xxxxxxx
> Technical Contact:
> malcolm.betts@xxxxxxxxxx,Ghani.Abbas@xxxxxxxxxxxx,Kam.Lam@alca
> tel-lucent.com
> Purpose: For information
>
> Body: At the December 2011 meeting of ITU-T Study Group 15,
> Recommendation ITU-T G.8110.1/Y.1370.1 "Architecture of MPLS
> Transport Profile (MPLS-TP) layer network" was approved. A
> copy is attached for your information.
> We would like to draw your attention to clause 10 that
> describes the MPLS-TP Diff-Serv Architecture.
> In addition, the approval process was initiated for
> Recommendations ITU-T G.8121/Y.1381 "Characteristics of
> MPLS-TP Network Equipment Functional Blocks" and ITU-T
> G.8151/Y.1374 "Management aspects of the MPLS-TP network element".
>
> Attach: TD517/PLEN Rev.3, TD540/PLEN Rev.1, TD543/PLEN Rev.1.
>
> Attachment(s):
>
> LS368 - pdf body
> https://datatracker.ietf.org/documents/LIAISON/file1308.pdf
>
> LS368 - Att1_PLEN-517Rev3
> https://datatracker.ietf.org/documents/LIAISON/file1309.pdf
>
> LS368 - Att2_PLEN-540Rev1
> https://datatracker.ietf.org/documents/LIAISON/file1310.pdf
>
> LS368 - Att3_PLEN-543Rev1
> https://datatracker.ietf.org/documents/LIAISON/file1311.pdf
>
>
>
------------------------------
Message: 5
Date: Mon, 09 Jan 2012 09:09:48 -0800
From: Joel jaeggli <joelja@xxxxxxxxx>
To: SM <sm@xxxxxxxxxxxx>
Cc: IETF Discussion <ietf@xxxxxxxx>, Paul Hoffman
<paul.hoffman@xxxxxxxx>
Subject: Re: Requirements for improving IETF remote participation
Message-ID: <4F0B1F5C.10400@xxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1
On 1/6/12 02:00 , SM wrote:
> "The RPS tools must be available for lunch meetings scheduled by
> the IETF Secretariat, such as for the Security Directorate"
>
> I object to the non-inclusion of the kangaroo directorate (no offense
> intended). :-)
That implies coverage of a much greater number of rooms, e.g. 16 or more
potentialy. when you count the offices and small breakout rooms in
addition to the 8 scheduled meeting rooms.
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
>
------------------------------
Message: 6
Date: Mon, 9 Jan 2012 17:33:16 -0000
From: "Adrian Farrel" <adrian@xxxxxxxxxxxx>
To: <draft-betts-itu-oam-ach-code-point@xxxxxxxxxxxxxx>, "'Huub
helvoort'" <huub.van.helvoort@xxxxxxxxxx>
Cc: mpls@xxxxxxxx, ietf@xxxxxxxx
Subject: RE: Questions about draft-betts-itu-oam-ach-code-point
Message-ID: <01cf01cccef4$c5e6ef90$51b4ceb0$@olddog.co.uk>
Content-Type: text/plain; charset="us-ascii"
Hi Huub and Malcolm,
I recognise that the intervening month between my original email and this one
included an SG15 meeting, Christmas, and New Year, but I had hoped for a
response by now so that we could work out what to do with the document.
In the meantime, at least my question 4 has progressed. Can you confirm that the
version of G.8113.1 for which a code point is requested is that which has been
sent to WTSA by SG15 (i.e., that which was determined), and that there are no
plans to make any updates or revisions to that document until after it has been
approved.
Thanks,
Adrian
> -----Original Message-----
> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Adrian
> Farrel
> Sent: 09 December 2011 10:49
> To: draft-betts-itu-oam-ach-code-point@xxxxxxxxxxxxxx; 'Huub helvoort'
> Cc: mpls@xxxxxxxx; ietf@xxxxxxxx
> Subject: Questions about draft-betts-itu-oam-ach-code-point
>
> Hi Malcolm and Huub,
>
> I have squeezed a little time from the current ITU-T meeting to look at your
> draft and write-up. I have also read the email threads on the IETF discussion
> list and the MPLS list. Sorry that this has taken me a week to process, but
your
> publication request came at pretty much the worst possible time for getting me
> to do this task.
>
> I don't like proliferating threads across multiple mailing lists. On the other
> hand it is difficult to ensure that all the constituencies are present, so I
am
> perpetuating the cross-posting.
>
> My review of the document...
>
> 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think
> only one of these is real (the spurious space in a citation). The other nits
are
> spurious caused by citations wrapping across lines. Could you please keep a
note
> of the nit so that you can fix it the next time the draft is respun or so it
can
> be captured in an RFC Editor Note at a later stage (you don't have to post a
new
> revision to address this now unless you really want to).
>
> 2. This document requests a code point from a registry that contains code
points
> that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D
> whether it is your intention that your code point would also be applicable in
> both cases. What is your intention? Is this "obvious" from G.8113.1 or does it
> need to be clarified?
>
>
> My review of the write-up and discussions...
>
> 3. There seems to be quite a feeling on the mailing lists that this document
> should be run through the MPLS working group. The write-up makes a case for
> progressing it as AD sponsored. As far as I can see, the main assertions to
> answer are as follows. Do you have a view on these points before I make a
> decision on what to do?
>
> a. This is a proposal to use an MPLS code point and so is part of MPLS by
> definition.
>
> b. The type of network being managed by the OAM described in G.8113.1 is an
> MPLS network. Therefore, this is clearly relevant to the MPLS working .
>
> Do you object to this going through the MPLS on principle, or were you just
> hoping to save the WG the work? If the latter, and if the WG wants to look at
> the draft, the easiest approach seems to be to redirect the work to the
working
> group.
>
> 4. G.8113.1 is clearly important to understanding to which the code point is
> being put. Thus, an available and stable copy of group. G.8113.1 will be key
to
> the last call review of you I-D. Can you make a stable copy available (for
> example, through liaison)? How does the editing work currently in progress in
> the SG15 meeting affect that availability?
>
> 5. Can you clarify for me why the suggested value has been suggested. This
will
> help guide IANA who would normally do their allocation in a "tidy" way.
>
> Looking forward to your reply.
>
> Thanks,
> Adrian
------------------------------
Message: 7
Date: Mon, 9 Jan 2012 18:41:43 +0100
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<nurit.sprecher@xxxxxxx>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<nurit.sprecher@xxxxxxx>, "ext Scott Mansfield"
<scott.mansfield@xxxxxxxxxxxx>, <ietf@xxxxxxxx>, <mpls@xxxxxxxx>,
<pwe3@xxxxxxxx>, <ccamp@xxxxxxxx>
Cc: andrew.g.malis@xxxxxxxxxxx, dbrungard@xxxxxxx
Subject: RE: [CCAMP] New Liaison Statement, "LS370 - Current status
ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration
andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)"
Message-ID:
<077E41CFFD002C4CAB7DFA4386A5326405178E7C@xxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="windows-1255"
When saying support, I mean of course that I fully support the proposal of Scott!
-----Original Message-----
From: ccamp-bounces@xxxxxxxx [mailto:ccamp-bounces@xxxxxxxx] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: ? 09 ????? 2012 19:20
To: ext Scott Mansfield; ietf@xxxxxxxx; mpls@xxxxxxxx; pwe3@xxxxxxxx; ccamp@xxxxxxxx
Cc: andrew.g.malis@xxxxxxxxxxx; dbrungard@xxxxxxx
Subject: Re: [CCAMP] New Liaison Statement,"LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1,Operations,Administration andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)"
Support
-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of ext Scott Mansfield
Sent: ? 08 ????? 2012 15:53
To: ietf@xxxxxxxx; mpls@xxxxxxxx; pwe3@xxxxxxxx; ccamp@xxxxxxxx
Cc: swallow@xxxxxxxxx; stbryant@xxxxxxxxx; adrian@xxxxxxxxxxxx; andrew.g.malis@xxxxxxxxxxx; dbrungard@xxxxxxx
Subject: FW: New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)"
This is a liaison from the ITU-T SG15 WP3 providing a copy of the Determined recommendation G.8113.1 (May 2011). The liaison also provides a pointer to the internet draft draft-betts-itu-oam-ach-code-point that requests an ACh code point that is needed by G.8113.1. This is a liaison that will require a response and the ITU-T has requested a response no later than 1 August 2012. I would suggest that we use the liaison response to provide the outcome of running the IETF process required to assign the requested code point.
Regards,
-scott.
IETF-ITU Liaison Manager for MPLS
> -----Original Message-----
> From: Liaison Statement Management Tool [mailto:lsmt@xxxxxxxx]
> Sent: Sunday, January 08, 2012 3:23 AM
> To: chair@xxxxxxxx
> Cc: yoichi.maeda@xxxxxxxxx;
> steve.trowbridge@xxxxxxxxxxxxxxxxxx; iesg@xxxxxxxx;
> lear@xxxxxxxxx; Scott Mansfield; malcolm.betts@xxxxxxxxxx;
> tsbsg15@xxxxxxx; greg.jones@xxxxxxx; hiroshi.ota@xxxxxxx
> Subject: New Liaison Statement, "LS370 - Current status of
> Recommendation ITU-T G.8113.1/Y.1372.1, Operations,
> Administration and Maintenance mechanism for MPLS-TP in
> Packet Transport Network (PTN)"
>
> Title: LS370 - Current status of Recommendation ITU-T
> G.8113.1/Y.1372.1, Operations, Administration and Maintenance
> mechanism for MPLS-TP in Packet Transport Network (PTN)
> Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/
>
> From: ITU-T SG 15 (Greg Jones <greg.jones@xxxxxxx>)
> To: The IESG (chair@xxxxxxxx)
> Cc:
> yoichi.maeda@xxxxxxxxx,steve.trowbridge@xxxxxxxxxxxxxxxxxx,ies
> g@xxxxxxxx,lear@xxxxxxxxx,Scott.Mansfield@xxxxxxxxxxxx
> Reponse Contact:
> tsbsg15@xxxxxxx,greg.jones@xxxxxxx,hiroshi.ota@xxxxxxx
> Technical Contact: malcolm.betts@xxxxxxxxxx
> Purpose: For information
>
> Body: The December meeting of ITU-T Study Group 15 considered
> the approval of Recommendation ITU-T G.8113.1/Y.1372.1,
> Operations, Administration and Maintenance mechanism for
> MPLS-TP in Packet Transport Network (PTN). Unfortunately the
> Study Group could not approve this Recommendation so it was
> forwarded to the WTSA (20-29 November 2012) for approval.
> One of the issues that prevented the approval in SG 15 was
> the lack of an ACh code point to support this Recommendation.
> To resolve this issue SG 15 therefore requests the IETF to
> assign an ACh code point. An IETF draft
> draft-betts-itu-oam-ach-code-point has been submitted to
> request this code point.
> We have attached the text of the current draft of
> Recommendation ITU-T G.8113.1/Y.1372.1 that has been
> forwarded to the WTSA for approval.
> Attach: COM15R-22.
>
> Attachment(s):
>
> LS370 - pdf body
> https://datatracker.ietf.org/documents/LIAISON/file1306.pdf
>
> LS370 - pdf attachment
> https://datatracker.ietf.org/documents/LIAISON/file1307.pdf
>
>
>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
CCAMP mailing list
CCAMP@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ccamp
------------------------------
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
End of Ietf Digest, Vol 44, Issue 17
************************************
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf