Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

[Loa Andersson <[e-mail]>]

Zafar, authors,


I think most of what you done is fine. There are still somr things
to do, e.g. align with 7322, rewrite the Abstract and work with the
authors of draft-ietf-6man-segment-routing-header to make their IANA 
considerations are correct from your point of view.

Then this


       The IPv6 address of the nth Link  between node X and Y at the X
       side is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address
       of link6 (the 2nd link) between N3 and N4 at N3 in Figure 1 is
       link between N3 and N4) at node 3 is 2001:DB8:3:4:31::.

I'd like to drill down a bit more on this paragraph.

In the generic example "Xn" represents the n-th link between node
x and Y, right? And you need the first "X" in "X:Y:Xn" to identify
the node?

SInce the first X uniquely identify the node, why is X needed in
the second field.

In a specific case the 11th lik of node 3 and the 1st link of
node 31 would bive the same result - "311". You disambiguate by the
node number of the first "X".

So for the eleventh link of nod 3 to node y:

3:y:311

And for the first link of node 31 to node y:

31:y:311

Right?

So why should not 3:y:11 and 31:y:1 work.

/Loa



On 21/02/2020 13:41, Zafar Ali (zali) wrote:
> Hi Loa,
> 
> We have addressed most of your comments in the enclosed .txt file.
> 
> We have also uploaded updated XML file to the 6man/OAM repository (but 
> please use the enclosed .txt file for diffs. Somehow “Compare Editor's 
> Copy to Working Group Draft” is pointing to older diffs.
> 
> Details of how your comments are addressed are listed in the following 
> as well as in the enclosed updated diffs file that you shared earlier.
> 
> We plan to address the remaining comments very soon.
> 
> Many thanks again for detailed review.
> 
> Thanks
> 
> Regards … Zafar
> 
> *How comments were addressed*:
> 
> [LA1]The Abstract seems to be a bit ìbareî, it should be a stand-alone 
> text, this seem to pre-suppose an high level of familiarity with the topic.
> 
> [ZA] rewrite TBD.
> 
> [LA2]Dataplane or data pale,  us one both not both.
> 
> [ZA] Changed.
> 
> [LA3]îsomeî, this begs for an explanation of what has been left out and why.
> 
> [LA4]There is an RFC 7322, please make sure that you are following these 
> guidelines.
> 
> S for the placement of the ìRequirement Languageî, the style guide says 
> that it should be placed as a top level section after the Introduction, 
> however not even the RFC Editor follow that guidance, the Requirement 
> Language are most often placed as a subsection of the introduction.
> 
> [ZA] Changed the text to follow the RFC7322 guideline.
> 
> [LA5]There is a new template for this, BCP BCP 14 which consists of twp 
> RFCs ([RFC2119] [RFC8174]) should be referenced.
> 
> [ZA] Reference to [RFC8174] added.
> 
> [LA6]Thos is very sparse, and it is also a direct copy og the abstract 
> (or the other way around). I donít think this is allowed.
> 
> [ZA] rewrite TBD.
> 
> [LA7]I think you could remove this header and make îAbbreviationsî 
> section 1.1
> 
> [ZA] Fixed.
> 
> [LA8]RFC 8402 define this is as îSegemetns Leftî
> 
> [ZA] Good catch! Fixed.
> 
> [LA9]Also this document uses îSegments Leftî
> 
> [ZA] Fixed.
> 
> [LA10]Admittedly the topology is simple, but the figure could be much 
> clearer.
> 
> I agree that it is a good idea to define a simple topology and use it 
> throughout the document.
> 
> [ZA] Thanks. Any suggestion to simplify is welcomed.
> 
> [LA11]This could be a good place to explain the use of înode kî.
> 
> [ZA] Moved.
> 
> [LA12]Probably not a very strong point, ìclassicî is already a bit 
> ambivalent, and will be more so as the time goes by. Iíd say just drop 
> it, or make it ìnon-SRv6 IPv6 nodesî.
> 
> [ZA] Fixed.
> 
> [LA13]îNode kî is not in the reference topology.
> 
> [ZA] Node k is used to refer to all nodes collectively (e.g., to define 
> the IPv6 addressing scheme for them.). IMO this should be fine.
> 
> [LA14]If you are going to push the link number into the IPv6 address, it 
> would be better to start numbering from zero.
> 
> [ZA] There is no node 0 in the topology. The addressing example is based 
> on node names. IMO this should be fine.
> 
> [LA15]This three is redundant, the î3:4î in the two previous positions 
> uniquely identify the link,
> 
> [ZA] Actually it is not redundant as the last :3 represents the link 
> address at node 3 side. IMO this should be fine.
> 
> [LA16]After going through this a number of time Iím convinced that this 
> is correct. However, it takes quite an effort to go through a rather 
> cryptic text. Is it possible to clarify.
> 
> [ZA] Thanks for your feedback. Actually there was a typo and I fixed it.
> 
> [LA17]This îS1î means îSID1î, why do we need the ìSî as a special 
> notation when we already have ìSIDî
> 
> [ZA] Si is a notation that relates to a topology or service segment. 
> S[j] represents the SID pointed by the SL field in the SRH. S[j] is like 
> a index in sid-list in the SRH. IMO this should be fine.
> 
> [LA18]When we were specifying MPLS-TP we diid a lot of OAM work, 
> concepts like MIPs and MEPs were introduced. Do these concepts have any 
> bearing on SRv6 OAM?
> 
> [ZA] Thanks for your feedback. SRv6 OAM is in-line with OAM in IPv6 
> networks, which are not of transport nature.
> 
> [LA19]This is a double reference to the same document and strictly note 
> necessary The format of the second reference is also wrong and does not 
> appear in the reference list.
> 
> [ZA] Fixed.
> 
> [LA20]Well, if you do you need a subsection in the IANA Consideration. 
> The flag field is defined in ietf-6man-segment-routing-header, but it is 
> still a draft.
> 
> As this document stands now you canít find the IANA allocations. Partly 
> depending on that IANA not yet done the allocations, but also because if 
> they were done there is no clear reference to the registry. SRH.Flags is 
> not the name of the registry.
> 
> [ZA] Fixed.
> 
> [LA21]The notation îSRH.Flagsî is invented here, right?  
> draft-ietf-6man-segment-routing-header, and the SRV6 Networking 
> programming draft (which is referenced for terminology) simply talks 
> about SRH or ìSRH Flagsî.
> 
> [ZA] The SRH.Flags is defined in draft-ietf-6man-segment-routing-header. 
> The IANA registry for SRH.Flags is requested in 
> draft-ietf-6man-segment-routing-header. This document just defined a 
> flag to identify OAM packets.
> 
> [LA22]Why start with bit 2, why not 0 or 7?
> 
> [ZA] There is a long history. This O-flag flag were originally defined 
> in the
> 
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-11.
> 
> During the LC review, it was moved to OAM draft. But the position has 
> been already defined and used by the ASICs. Hence, keeping the same bit 
> position.
> 
> [LA23]We are allocating a flag from a registry defined in 
> draft-ietf-6man-segment- routing-header. Since this is still in IESG 
> review it will not be possible progress this document until the routing 
> header document is in the RFC Editors queue, and it canít become an RFC 
> until the document defining the registry is also an RFC.
> 
> I think the SRH flags registry should be properly named here, "Segment 
> Routing Header Flags"
> 
> [ZA] Yes, the SRH flags registry is named as "Segment Routing Header 
> Flags". Please see IANA section in the new revision.
> 
> [LA24]I think the should be either OAM, Operation Administration and 
> Maintenance; or O&M, OAM and Management.
> 
> See RFC 6291.
> 
> [ZA] Fixed.
> 
> [LA25]Note: Chapter 3 is well written and easy to understand
> 
> [ZA] Will fix it - TBD.
> 
> [LA26]Comment added after reading the entire section, the procedures and 
> mechanisms described is as far as I can judge well and clearly documented.
> 
> [ZA] Thanks.
> 
> [LA27]An Extreme nit, but I would call this îPing in SRv6 Networksî
> 
> [ZA] Fixed
> 
> [LA28]I said it before ñ I donít like ìClassicî, and I donít thnk it is 
> necessary or contribute significantly.
> 
> [ZA] We will think about renaming. TBD.
> 
> [LA29]I think this procedures is well and clearly documented.
> 
> [ZA] Thanks.
> 
> [LA30]As far as I can see this works.
> 
> [ZA] Thanks.
> 
> [LA31]We might want a reference.
> 
> [ZA] This should be fine as this is well know.
> 
> [LA32]At this point I start think of SRv6 as îconnection oriented.
> 
> [ZA] SRv6 enables source routing.
> 
> [LA33]I see no immediate technical problems here.
> 
> [ZA] Thanks
> 
> [LA34]I defer to the security experts on this section.
> 
> [ZA] Yes that is part of the review process.
> 
> [LA35]You need text in this section describing the allocation of the O-flag.
> 
> [ZA] Fixed.
> 
> [LA36]What are the registration procedures???
> 
> If I understand correctly we want to take one of the unused ICMPv6 Type 
> Numbers and create the ìICMP Type Numbers ñ SRv6 OAM messagesî registry.
> 
> But with all due respect the text is a bit tangled.
> 
> [ZA] Fixed the text. Thanks for the good catch.
> 
> [LA37]This allocation is in itself not problematic, but the registries 
> are not yet in place., weíll have to wait for the network programming 
> draft to progress.
> 
> [ZA] Agreed!
> 
> Thanks
> 
> Regards … Zafar
> 
> *From: *"Zafar Ali (zali)" <[e-mail]>
> *Date: *Thursday, February 20, 2020 at 12:30 PM
> *To: *Loa Andersson <[e-mail]>, Brian E Carpenter 
> <[e-mail]>, Ole Troan <[e-mail]>, 6man WG 
> <[e-mail]>, SPRING WG <[e-mail]>
> *Cc: *6man Chairs <[e-mail]>, "Zafar Ali (zali)" 
> <[e-mail]>
> *Subject: *Re: [spring] 6man w.g. last call for 
> <draft-ietf-6man-spring-srv6-oam>
> 
> Hi Loa,
> 
> Sorry, I could not get back to your other comments, earlier.
> 
> I am starting to look into all outstanding comments.
> 
> It will be great if you could send me copy of the word document diffs 
> (privately).
> 
> But either way, your comments are quite clear.
> 
> Many Thanks
> 
> Regards … Zafar
> 
> *From: *"Zafar Ali (zali)" <[e-mail]>
> *Date: *Thursday, January 23, 2020 at 6:46 PM
> *To: *Loa Andersson <[e-mail]>, Brian E Carpenter 
> <[e-mail]>, Ole Troan <[e-mail]>, 6man WG 
> <[e-mail]>, SPRING WG <[e-mail]>
> *Cc: *6man Chairs <[e-mail]>, "Zafar Ali (zali)" 
> <[e-mail]>
> *Subject: *Re: [spring] 6man w.g. last call for 
> <draft-ietf-6man-spring-srv6-oam>
> 
> Loa,
> 
> Many thanks.
> 
> The comments in your email has been addressed in latest version in the 
> GitHub.
> 
> We are working to address the rest of your comments.
> 
> Thanks
> 
> Regards … Zafar
> 
> *From: *Loa Andersson <[e-mail]>
> *Date: *Wednesday, January 22, 2020 at 5:03 AM
> *To: *"Zafar Ali (zali)" <[e-mail]>, Brian E Carpenter 
> <[e-mail]>, Ole Troan <[e-mail]>, 6man WG 
> <[e-mail]>, SPRING WG <[e-mail]>
> *Cc: *6man Chairs <[e-mail]>
> *Subject: *Re: [spring] 6man w.g. last call for 
> <draft-ietf-6man-spring-srv6-oam>
> 
> Zafar,
> 
> Tnx - 1 down 36 to go!
> 
> Actually a bit more with the NITs output. Can you take a look at the
> 
> long lines next, it should be easy edits.
> 
> The first two long lines are in this paragraph:
> 
> 248     S01.1. IF SRH.Flags.O-flag is set and local configuration permits
> 
> 249            O-flag processing THEN
> 
> 250            a. Make a copy of the packet.
> 
> 251            b. Send the copied packet, along with a timestamp
> 
> 252               to the OAM process.      ;; Ref1
> 
> 253     Ref1: An implementation SHOULD copy and record the timestamp as
> 
> soon as
> 
> 254     possible during packet processing. Timestamp is not carried in
> 
> the packet
> 
> 255     forwarded to the next hop.
> 
> Line 253 has four characters "n as" outside the allowed 72 characters
> 
> Line 254 has the word "packet" outside the allowed 72 characters
> 
> This is inside the figure and I think that you can left shift the
> 
> enire figure, otherwise I don't see a problem with introducing line
> 
> breaks.
> 
> In figure 4:
> 
> 639     > traceroute srv6 B:4:C52 via segment-list B:2:C31
> 
> 641     Tracing the route to SID function B:4:C52
> 
> 642      1  2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec
> 
> 643         SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2)
> 
> 644      2  2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec
> 
> 645         SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1)
> 
> 646      3  2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec
> 
> 647         SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1)
> 
> 649        Figure 4 A sample output for hop-by-hop traceroute to a SID
> 
> function
> 
> Line 649 has "tion" of "SID function" (fig numbring) outside the allowed
> 
> 72 characters, again should be easy to left shif or introduce line
> 
> breaks.
> 
> The reason I want to address this first is that it is easy, but also
> 
> a show stopper.
> 
> And last, thugh I hate to add late comments - abbreviations, I have not
> 
> gone through the entire document to look for unexpanded abbreviations,
> 
> but there is at least one "NPU". Which I read as Network Processing Unit,
> 
> what confuses me is that it is not in the RFC Editors abbreviation list
> 
> at all. I think there is an action point for the wg chairs to have it
> 
> introduced, and for the authros to expand, as well as going through the
> 
> document an d make sure that everthing that should be expanded is.
> 
> /Loa
> 
> On 22/01/2020 13:15, Zafar Ali (zali) wrote:
> 
>     Hi Loa,
> 
>     Many thanks for your follow-up.
> 
>     Based on your feedback, we have updated the version in the GitHub.
> 
>     Thanks
> 
>     Regards … Zafar
> 
>     *From: *Loa Andersson <[e-mail] <mailto:[e-mail]>>
> 
>     *Date: *Tuesday, January 21, 2020 at 9:59 PM
> 
>     *To: *"Zafar Ali (zali)" <[e-mail] <mailto:[e-mail]>>,
>     Brian E Carpenter
> 
>     <[e-mail] <mailto:[e-mail]>>,
>     Ole Troan <[e-mail] <mailto:[e-mail]>>, 6man WG
> 
>     <[e-mail] <mailto:[e-mail]>>, SPRING WG <[e-mail]
>     <mailto:[e-mail]>>
> 
>     *Cc: *6man Chairs <[e-mail] <mailto:[e-mail]>>
> 
>     *Subject: *Re: [spring] 6man w.g. last call for
> 
>     <draft-ietf-6man-spring-srv6-oam>
> 
>     Zafar,
> 
>     Thanks for addressing this. However one thing remains. The text is now:
> 
>     "There MAY be additional segments preceding the END.OP/ END.OTP SID."
> 
>     I don't think there is a need for requirement language in that sentence,
> 
>     I read it as straightforward English:
> 
>     "There may be additional segments preceding the END.OP/ END.OTP SID."
> 
>     Would do very well.
> 
>     Can you explain the need for requirement language?
> 
>     /Loa
> 
>     On 22/01/2020 01:55, Zafar Ali (zali) wrote:
> 
>           Hi Brian,
> 
>           Many thanks for your comments. Much appreciated.
> 
>           The working copy of the new version in the repository
>     addresses your/
> 
>           Loa’s comment highlighted in your email.
> 
>     https://github.com/ietf-6man/srv6-oam
> 
>           Thanks
> 
>           Regards … Zafar
> 
>           *From: *spring <[e-mail]
>     <mailto:[e-mail]>
> 
>           <mailto:[e-mail]>
>     <mailto:[e-mail]%3e>> on behalf of Brian E Carpenter
> 
>           <[e-mail]
>     <mailto:[e-mail]>
>     <mailto:[e-mail]>
>     <mailto:[e-mail]%3e>>
> 
>           *Organization: *University of Auckland
> 
>           *Date: *Monday, January 20, 2020 at 2:57 PM
> 
>           *To: *Loa Andersson <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail]> <mailto:[e-mail]%3e>>, Ole Troan
> 
>           <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail]> <mailto:[e-mail]%3e>>, 6man
> 
>           WG <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail]> <mailto:[e-mail]%3e>>, SPRING WG
> 
>           <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail]> <mailto:[e-mail]%3e>>
> 
>           *Cc: *6man Chairs <[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]>
>     <mailto:[e-mail]%3e>>
> 
>           *Subject: *Re: [spring] 6man w.g. last call for
> 
>           <draft-ietf-6man-spring-srv6-oam>
> 
>           To be clear about one of the points in the review, MAY NOT is not
> 
>           allowed by RFC2119 because it is totally ambiguous in English
>     (since it
> 
>           can mean either "must not" or "might not"). In any case the
>     phrase "MAY
> 
>           or MAY NOT" is not of any normative value. It presumably
>     simply means
> 
>           "MAY" in all cases in this draft.
> 
>           Regards
> 
>                 Brian
> 
>           On 20-Jan-20 20:54, Loa Andersson wrote:
> 
>                 WG,
> 
>                 I have reviewed the entire document.
> 
>                 First, I'm not an IPv6 expert.
> 
>                 As far as I can see the sued on
> 
>                 I have not used github, I had a couple of attempts to learn
> 
>           the tools,
> 
>                 but so far I have failed.
> 
>                 I have instead done what I use to do, use the review
>     tool with
> 
>           Word.
> 
>                 Since I sometimes have a pushback on the docx-format I save
> 
>           the result
> 
>                 as a .txt-file. Drawback is that all comment show up as
> 
>           refrences to a
> 
>                 list at the end of the document. But you can't get
>     everything.
> 
>                 /Loa
> 
>                 PS gives this output for this draft; it is quite a lot
>     and in
> 
>           itself are
> 
>                 so much that it is worth sending it bck to the authors and
> 
>           asking them
> 
>                 to fix it. Was the noits tool checked at all before starting
> 
>           the wglc?
> 
>                 idnits 2.16.02
> 
>                 /tmp/draft-ietf-6man-spring-srv6-oam-03.txt:
> 
>                      Checking boilerplate required by RFC 5378 and the IETF
> 
>           Trust (see
> 
>     https://trustee.ietf.org/license-info):
> 
>          
>     ----------------------------------------------------------------------------
> 
>                         No issues found here.
> 
>                      Checking nits according to
> 
>     https://www.ietf.org/id-info/1id-guidelines.txt:
> 
>          
>     ----------------------------------------------------------------------------
> 
>                         No issues found here.
> 
>                      Checking nits according to
> 
>     https://www.ietf.org/id-info/checklist :
> 
>          
>     ----------------------------------------------------------------------------
> 
>                      ** There are 3 instances of too long lines in the
> 
>           document, the
> 
>                 longest one
> 
>                         being 6 characters in excess of 72.
> 
>                      == There are 5 instances of lines with
> 
>           non-RFC3849-compliant IPv6
> 
>                 addresses
> 
>                         in the document.  If these are example
>     addresses, they
> 
>                 should be
> 
>                 changed.
> 
>                      Miscellaneous warnings:
> 
>          
>     ----------------------------------------------------------------------------
> 
>                      == The copyright year in the IETF Trust and authors
> 
>           Copyright Line
> 
>                 does not
> 
>                         match the current year
> 
>                      -- The exact meaning of the all-uppercase
>     expression 'MAY
> 
>           NOT'
> 
>                 is not
> 
>                         defined in RFC 2119.  If it is intended as a
>     requirements
> 
>                 expression, it
> 
>                         should be rewritten using one of the combinations
> 
>           defined in
> 
>                 RFC 2119;
> 
>                         otherwise it should not be all-uppercase.
> 
>                      == The expression 'MAY NOT', while looking like RFC
>     2119
> 
>                 requirements
> 
>                 text,
> 
>                         is not defined in RFC 2119, and should not be
> 
>           used.  Consider
> 
>                 using 'MUST
> 
>                         NOT' instead (if that is what you mean).
> 
>                         Found 'MAY NOT' in this paragraph:
> 
>                         To perform ICMPv6 ping to a target SID an echo
>     request
> 
>                 message is
> 
>                         generated by the initiator with the END.OP or
>     END.OTP
> 
>           SID in the
> 
>                         segment-list of the SRH immediately preceding the
> 
>           target SID.
> 
>                 There MAY
> 
>                         or MAY NOT be additional segments preceding the
>     END.OP/
> 
>                 END.OTP SID.
> 
>                      == The expression 'MAY NOT', while looking like RFC
>     2119
> 
>                 requirements
> 
>                 text,
> 
>                         is not defined in RFC 2119, and should not be
> 
>           used.  Consider
> 
>                 using 'MUST
> 
>                         NOT' instead (if that is what you mean).
> 
>                         Found 'MAY NOT' in this paragraph:
> 
>                         To traceroute a target SID a probe message is
> 
>           generated by the
> 
>                         initiator with the END.OP or END.OTP SID in the
> 
>           segment-list of
> 
>                 the SRH
> 
>                         immediately preceding the target SID.  There MAY or
> 
>           MAY NOT be
> 
>                 additional
> 
>                         segments preceding the END.OP/ END.OTP SID.
> 
>                      -- The document date (December 18, 2019) is 32 days
>     in the
> 
>                 past.  Is this
> 
>                         intentional?
> 
>                      Checking references for intended status: Proposed
>     Standard
> 
>          
>     ----------------------------------------------------------------------------
> 
>                         (See RFCs 3967 and 4897 for information about using
> 
>           normative
> 
>                 references
> 
>                         to lower-maturity documents in RFCs)
> 
>                      == Missing Reference: 'SL' is mentioned on line
>     190, but not
> 
>                 defined
> 
>                      -- Looks like a reference, but probably isn't: '2' on
> 
>           line 191
> 
>                      -- Looks like a reference, but probably isn't: '1' on
> 
>           line 191
> 
>                      -- Looks like a reference, but probably isn't: '0' on
> 
>           line 192
> 
>                      == Missing Reference: 'RFC7011' is mentioned on
>     line 230, but
> 
>                 not defined
> 
>                      == Missing Reference: 'I-D.ietf-idr-bgpls-srv6-ext' is
> 
>                 mentioned on line
> 
>                         241, but not defined
> 
>                      == Missing Reference: 'RFC792' is mentioned on line
>     701, but
> 
>                 not defined
> 
>                      == Missing Reference: 'RFC 8403' is mentioned on line
> 
>           660, but not
> 
>                 defined
> 
>                      == Unused Reference: 'RFC0792' is defined on line
>     823, but no
> 
>                 explicit
> 
>                         reference was found in the text
> 
>                      == Unused Reference: 'RFC8403' is defined on line
>     843, but no
> 
>                 explicit
> 
>                         reference was found in the text
> 
>                      == Outdated reference: A later version (-08) exists of
> 
>                         draft-ietf-spring-srv6-network-programming-06
> 
>                         Summary: 1 error (**), 0 flaws (~~), 12 warnings
>     (==), 5
> 
>                 comments
> 
>                 (--).
> 
>                         Run idnits with the --verbose option for more
>     detailed
> 
>                 information
> 
>                 about
> 
>                         the items above.
> 
>                 On 05/12/2019 04:53, Ole Troan wrote:
> 
>                     Hello,
> 
>                          As agreed in the working group session in
>     Singapore, this
> 
>                     message starts a new two week 6MAN Working Group
>     Last Call on
> 
>                     advancing:
> 
>                          Title    : Operations, Administration, and
>     Maintenance
> 
>                     (OAM) in Segment Routing Networks with IPv6 Data
>     plane (SRv6)
> 
>                          Author   : Z. Ali, C. Filsfils, S. Matsushima, D.
> 
>           Voyer, M.
> 
>                     Chen
> 
>                          Filename : draft-ietf-6man-spring-srv6-oam-02
> 
>                          Pages    : 23
> 
>                          Date     : 2019-11-20
> 
>     https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/
> 
>                     as a Proposed Standard.
> 
>                     Substantive comments and statements of support for
>     publishing
> 
>                     this document should be directed to the mailing list.
> 
>                     Editorial suggestions can be sent to the author.
>     This last
> 
>           call
> 
>                     will end on the 18th of December 2019.
> 
>                     To improve document quality and ensure that bugs are
>     caught as
> 
>                     early as possible, we would require at least
> 
>                     two reviewers to do a complete review of the
>     document.  Please
> 
>                     let the chairs know if you are willing to be a reviewer.
> 
>                     The last call will be forwarded to the spring
>     working group,
> 
>                     with discussion directed to the ipv6 list.
> 
>                     Thanks,
> 
>                     Bob & Ole, 6man co-chairs
> 
>          
>     --------------------------------------------------------------------
> 
>                     IETF IPv6 working group mailing list
> 
>     [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>     <mailto:[e-mail]>
> 
>                     Administrative Requests:
> 
>     https://www.ietf.org/mailman/listinfo/ipv6
> 
>          
>     --------------------------------------------------------------------
> 
>          
>     --------------------------------------------------------------------
> 
>                 IETF IPv6 working group mailing list
> 
>     [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>     <mailto:[e-mail]>
> 
>                 Administrative Requests:
> 
>     https://www.ietf.org/mailman/listinfo/ipv6
> 
>          
>     --------------------------------------------------------------------
> 
>           _______________________________________________
> 
>           spring mailing list
> 
>     [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>     <mailto:[e-mail]>
> 
>     https://www.ietf.org/mailman/listinfo/spring
> 
>     -- 
> 
>     Loa Andersson                        email: [e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]>
> 
>     Senior MPLS Expert
> 
>     Bronze Dragon Consulting             phone: [phone]
> 
>     _______________________________________________
> 
>     spring mailing list
> 
>     [e-mail] <mailto:[e-mail]>
> 
>     https://www.ietf.org/mailman/listinfo/spring
> 
> -- 
> 
> Loa Andersson                        email: [e-mail] <mailto:[e-mail]>
> 
> Senior MPLS Expert
> 
> Bronze Dragon Consulting             phone: [phone]
> 
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]