Subject: Re: Ietf Digest, Vol 44, Issue 17

From: Sanjay Chalikar <[email-masked]>
Date: Tue, 10 Jan 2012 18:49:00 +0530

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, <[email-masked]> 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
>        [email-masked]
>
> 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
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> 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 <[email-masked]>
> To: "t.petch" <[email-masked]>
> Cc: [email-masked], IETF-Discussion <[email-masked]>
> Subject: Re: Protocol Definition
> Message-ID: <[email-masked]>
> 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 <[email-masked]>
> To: [email-masked], "t.petch" <[email-masked]>
> Cc: [email-masked], IETF-Discussion <[email-masked]>
> 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 <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
>        "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>,    "[email-masked]"
>        <[email-masked]>,   "[email-masked]" <[email-masked]
> >,
>        "[email-masked]" <[email-masked]>,
>        "[email-masked]" <[email-masked]>
> 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:
>        <
> [email-masked]>
>
> 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:[email-masked]]
> > Sent: Sunday, January 08, 2012 3:23 AM
> > To: [email-masked]
> > Cc: [email-masked];
> > [email-masked]; [email-masked];
> > [email-masked]; Scott Mansfield; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > 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 <[email-masked]>)
> > To: The IESG ([email-masked])
> > Cc:
> > [email-masked],[email-masked],ies
> > [email-masked],[email-masked],[email-masked]
> > Reponse Contact:
> > [email-masked],[email-masked],[email-masked]
> > Technical Contact: [email-masked]
> > 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 <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
>        "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>,    "[email-masked]"
>        <[email-masked]>,   "[email-masked]" <[email-masked]
> >,
>        "[email-masked]" <[email-masked]>,
>        "[email-masked]" <[email-masked]>
> Subject: FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations"
> Message-ID:
>        <
> [email-masked]>
>
> 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:[email-masked]]
> > Sent: Sunday, January 08, 2012 3:51 AM
> > To: [email-masked]; [email-masked]; [email-masked]
> > Cc: [email-masked];
> > [email-masked]; [email-masked];
> > [email-masked]; Scott Mansfield; [email-masked];
> > [email-masked]; [email-masked]; Ghani Abbas;
> > [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > 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 <[email-masked]>)
> > To: Multiprotocol Label Switching ([email-masked],
> > [email-masked], [email-masked])
> > Cc:
> > [email-masked],[email-masked],mpl
> > [email-masked],[email-masked],[email-masked],stbryan
> > [email-masked],[email-masked]
> > Reponse Contact:
> > [email-masked],[email-masked],[email-masked]
> > Technical Contact:
> > [email-masked],[email-masked],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 <[email-masked]>
> To: SM <[email-masked]>
> Cc: IETF Discussion <[email-masked]>, Paul Hoffman
>        <[email-masked]>
> Subject: Re: Requirements for improving IETF remote participation
> Message-ID: <[email-masked]>
> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 9 Jan 2012 17:33:16 -0000
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>,        "'Huub
>        helvoort'" <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: RE: Questions about draft-betts-itu-oam-ach-code-point
> Message-ID: <[email-masked]>
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adrian
> > Farrel
> > Sent: 09 December 2011 10:49
> > To: [email-masked]; 'Huub helvoort'
> > Cc: [email-masked]; [email-masked]
> > 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)"
>        <[email-masked]>
> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
>        <[email-masked]>,       "ext Scott Mansfield"
>        <[email-masked]>, <[email-masked]>,        <
> [email-masked]>,
>        <[email-masked]>, <[email-masked]>
> Cc: [email-masked], [email-masked]
> 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:
>        <[email-masked]>
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Sent: ? 09 ????? 2012 19:20
> To: ext Scott Mansfield; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Scott Mansfield
> Sent: ? 08 ????? 2012 15:53
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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:[email-masked]]
> > Sent: Sunday, January 08, 2012 3:23 AM
> > To: [email-masked]
> > Cc: [email-masked];
> > [email-masked]; [email-masked];
> > [email-masked]; Scott Mansfield; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > 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 <[email-masked]>)
> > To: The IESG ([email-masked])
> > Cc:
> > [email-masked],[email-masked],ies
> > [email-masked],[email-masked],[email-masked]
> > Reponse Contact:
> > [email-masked],[email-masked],[email-masked]
> > Technical Contact: [email-masked]
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
> ------------------------------
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>
>
> End of Ietf Digest, Vol 44, Issue 17
> ************************************
>