Huub:
I was not in the meeting, but this does not fit the report of the meeting that
I have received. In particular, the ITU received many technical comments, and
then editing sessions were held to address them. However the stable version
that you reference is not the output of that editing session. How will those
technical comments be addressed? These outstanding technical comments is the
reason that I am asking about stability.
Russ
On Dec 21, 2011, at 5:51 AM, Huub helvoort wrote:
Hello Russ,
You wrote:
My understanding is that there is not a stable agreed G.8113.1 document to
reference.
Is my understanding incorrect?
Your understanding is partially incorrect:
The draft recommendation G.8113.1 is stable, there have been no major
technical
changes since it was sent to the IETF (when it still had the draft name
G.tpoam)
attache to liaison: https://datatracker.ietf.org/liaison/983/
This is also the status I reported when we did discuss this during IETF82 in
Taipei.
G.8113.1 could not be approved because of the technical reason that there is
no ACh codepoint assigned.
Best regards, Huub.
======
On Dec 20, 2011, at 11:09 AM, Malcolm(_dot_)BETTS(_at_)zte(_dot_)com(_dot_)cn
wrote:
Hi Adrian,
Thank you for finding time to respond to this request. As you know I was
attending the same 2 week SG 15 meeting and was probably at least as busy as
you given my official role in the meeting.
I will update draft-betts-itu-oam-ach-code-point early in the new year based
on the results of SG 15 the ended last Friday and your comments. I will
also discussan update of the shepherd write up with Huub.
Regards,
Malcolm
"Adrian Farrel" <adrian(_at_)olddog(_dot_)co(_dot_)uk>
Sent by: ietf-bounces(_at_)ietf(_dot_)org
09/12/2011 05:49 AM
Please respond to
adrian(_at_)olddog(_dot_)co(_dot_)uk
To
<draft-betts-itu-oam-ach-code-point(_at_)tools(_dot_)ietf(_dot_)org>, "'Huub
helvoort'" <huub(_dot_)van(_dot_)helvoort(_at_)huawei(_dot_)com>
cc
mpls(_at_)ietf(_dot_)org, ietf(_at_)ietf(_dot_)org
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf